Coding Precondition

I think there are certain conditions that need to exist for a programmer to start coding. This is the condition that if not fulfilled can make the programming task harder, unfocused, distracted and will produce mostly suboptimal result.

This is different for everybody and depend on many factors like exposure to available technologies, experiences, working environment. However, the same theme here is that those things need to be available before we can do main task with flow and minimum distraction.

Here's an example on the things that I find as a precondition :

• Roadmap. However vague, without it the coding feels like going nowhere, we are also have little structure to based our technical choices.
• Issue Tracker. Beyond coding for practice, you will need some kind of tracking of what you want to achieve, what you currently are and what the next step is. It could range from a mere text file or something monstrous, pick your choice.
  
• Revision Control. Coding without it will feels like coding in the middle of land-mines. The feeling of safety that if we make mistakes we could always mistake leverage the way our brain solve the current problem since it is now feel more free to experiment and explore solutions.
  
• Integrated Environment. It could be several tools that you combine yourself and make work together or a full-blown IDE or any other combination. The key is to make them work seamless as from coding to running and work naturally as the extension of your thoughts to concrete implementation. This is also include the libraries you are depend on, it should be in-place, tested and integrated first.
  
• References. Gather relevant core references of what you currently working on within short reach, it will speed things up compare to relying solely on just-in-time research.
  

The ideal to be achieved is the condition where the programmer would only do mostly : think about the problem, test, code, debug, commit with minimum unrelated task come up.

Programming precondition worth to be prioritized whenever any of them is a little broken. Personally, I think it's worth to stop whatever I am doing to get those precondition work/clear in top shape first before start moving on again with the main work.

PascalCase and camelCase Convention (in C#)

Coming from C++ world I am a bit disturbed with how things written/named in C# world. The IDE, code samples, books write something that I have been learn to avoid : write function name starting with capital.

I used to follow a convention that only use name beginning capital very sparingly i.e: for Class names. Suddenly seeing capitals everywhere got me wondering didn't they read stroustrup books and other C++ guru?. Overtime I learn to accept it although I still many times, by reflex, naming properties and functions starting with lower case but I can live with generated code and keep up with whatever convention already existing in the code I am working on.

I mainly thought there some kind of convention that these guys are following although I haven't read it explicitly somewhere. Until today, when reading book "C# in a Nutshell, 3rd Edition", I stumble upon this

By convention, arguments, local variables, and private fields should be in camel case (e.g., myVariable ), and all other identifiers should be in Pascal case (e.g., MyMethod ).

I still wonder where there's come from initially, but at least I now saw it written explicitly that, somehow, it's a convention. Thinking that all those people "incidentally" have the same urge to broke the rules and naming things by Capital Letter is kinda creepy, so it's better like this :).

I don't mind following them, although my brain now have to keep two convention inside it since I still keep the other convention in C++. There's still some nagging feeling that you broke something sacred when you try to start name of something beside class with capital in C++.

PascalCase is ok, (Lower)camelCase is ok too, as long as it gets the job done, I guess.

Using Jude : Seperate Model and View

More...(drag mouse)

Open Link

Close Other Tabs

Forward

Duplicate Window

Close Tab

Copy Link

Save Link As...

Jude is a UML tools that I find very flexible since let the user do the way he likes it to without forcing certain structure. The user could determine what certain structure of the components and diagrams are meant to himself.

Here's one way of using it that is quite useful to me : make a separate model and diagram folder. I put all the UML components e.g: Class, under model and make all diagrams under diagram folder. With this I could reuse the same classes definition on several different diagrams. Any change to the class will be reflected automatically to others.

It's a bit more work since you have to do things in several steps :

• add any model under folder model e.g: right click on the folder -> Create Model -> Add Class
• Open the diagram and drag the Class there from structure view
  

With standard way of drawing, I could just click on the toolbar and I got the model I want in that diagram instantly. It's quick but it makes the model less reusable/centralized.

It's not always seems practical to do so though, for quick "drawing" I just use the toolbar and let everything e.g: classes and diagrams on the same folder. However, for relatively serious UML Diagramming separating models and diagrams is more convenient.

Using (Manually-Generated) UML to Track Code's Conceptual Growth

One of the usefulness of drawingUML ourselves (as oppose to rely on automatically-generated ones) is to track classes growth (it's numbers, associations among themselves). It's refreshing to occasionally pause a little from coding work and update those dusty old diagrams that we've updated last week/month. It helps us to review and maintain the integrity of the code and, somehow, feel still in control of all of it.

There are things that does not appear on source code or IDE in apparent manner and without tracking in high level view there can be trouble related to conceptual integrity of the code that creep up and accumulate over time. Even with lots of features that help to get a high level view of classes e.g: ctag-based tools, or automatically generated diagrams, nothing can replace manually-drawn visual diagram role on this.

Somehow it's not really about the diagram itself but the act of clarifying what's inside our head in a more visible manner for us to digest, the byproduct, the diagram, is just a nice bonus. It's not really the diagram that we've updated but it's our view about the whole thing that got refreshed periodically. It gives fresh view and the feel that we are still in-touch with the code. Also, in the process where we see, stare (and reflect) on associations that could fuel another insights, breakthroughs or just clarifying our already-outdated understanding.

Conceptual integrity can deteriorate over time and taking occasional visual view could help in dealing with it.

Script/Executable-Based Application

There is a certain model application that function as a wrapper to an already-established/existing script/executable. I already stumble upon many applications written this way, even wrote one myself sometime ago (a gui wrapper for certain cli app in-house). There are even application that is written from the start by writing scripts first then wrap them in application-style user interface e.g: kalva.

It's not a sin, of course, to write this kind of application. I think it's a good way to go given conditions :

• The executable/script is well-established
  
• There's no library that wrap the functionality in a modular way
• You have little time on your hand

However, visually, you'll have quite a monolithic application that looks like :


Which ideally can be made more modular and testable architecture like below :



If you have the resources and chance your 2-tier application can be made to evolve like the above. You start by extracting the executable into library step by step until all the necessary logic are on the lib and the script is merely a caller to it. Once you have library, you can link your application to it which make your app relatively cleaner and more cohesive.

Still, despite my preference for cleaner, more cohesive application, Script/Executable-Based Application is quite an interesting approach to rapidly develop something and/or reuse an established CommandLineInterface.

Tools for Server-Related Development

Here's some (free) tools I use in server-related development in Windows. The combination of them ease the development considerably, almost like all related-things are on local.

• Putty. This one is the most basic. It's an SSH client, got you connected to the shell where you can do virtually everything on the server. However, for operation that related to file/directory management, you'll need...
• WinSCP. It's an SFTP/FTP client with the look and feel of midnight commander, very handy for file/directory-related operation. It has a large number of feature that I find really useful e.g: shell command execution (you send the whole command instead of typing each character to server), directory synchronization (this sync feature has large number of option with convinient interface).
  
• JEdit with FTP and SshConsole plugin. Despite it's name, FTP plugin could also connect using SFTP and enable you to deal with the file in the server like you do with the local one. SshConsole work together with the FTP Plugin to enable you to send command with the current opened dir as working dir. You don't know what you've missed until you try this one. It's very helpful if you edit lots of files on the server e.g: working with several configuration files. Within JEdit, almost every aspect of editing file on the server feels like working the local ones, from browsing/opening, speed (it's cached on local buffer), savings, highlighting, history, etc.

As an addition, I think you'll find network monitoring tools would come in handy too when something does not look right. Here are two of them that I have ready to be used :

• NetLimiter free version. The free one enable you to monitor the traffic of your connection e.g: how many bandwidth certain application used, overall bandwidth usage also the detail of what kind of connections (ip, port) that certain application open.
  
• Whiteshark. Very advanced tool to monitor your network packets. It takes time to get used to this one, but really useful once you get the hang of it.
  

Given the right setup and some mix and match of tools, server-related development could still be fun and convenient.