10 thoughts on successful server programming

What defines succesful server software and how can it be programmed?

How to program server software successfully

Everyone uses server software nowadays, at least in the internet, but most time people are not aware of it. Therefore "successful" server software is boring. Not the technology or the creation process itself, but server software is succesful when it behaves boring. Or, in other words, it simply works. Most times you do not know it's there and if it behaves as it should one tends not to see it.

So at first, a definition of "server software" would be helpful. Server software(s) are programs that do not run on your computer directly. Results of input are computed on another peace of hardware but then the results are shown in your own program (or internet browser, this very page you are reading is nothing else than a computed result from the servers of blogspot.com).

But how are programs prepared to work in the daily server world? Just a few (apparently obvious) thoughts to achieve this goal.

10 thoughts on successful server programming

1. Be aware that a server program or script is not comparable with software running on your computer at home. Server software has to run self-sufficient to a high degree.
2. Think of an appropriate logging to relieve later-on forensic fault diagnostics. Better to log too much than nothing, users who access your server will do this in ways you never thought of while programming it. And there is a good chance that you need to narrow down what exactly happened.
3. Use all features your programming language provides to write solid software. If exception handling is available, use it. Finally-blocks to clean up your code? Definitely. And there is much more you can utilize, from assertions to the usage of complete testing systems etc.
   
4. In any case avoid memory leaks. If you program C / C++ be very careful, but even if you use Java / .NET or scripting languages this may get an issue for long running server software (just assume that a collection of data in Java / .NET will only get longer and longer and never shorter).
   
5. When you use external resources (i.e. databases, networks or file systems) be aware that they may fail. The least should be an explanative error message for your users. The best would be an email notification to the administrator and a retry / recover of the failing system automatically (to a second database, for example). The parts in programming I need to rely on external resources are the parts I spend the most time developing them, create fallbacks for or even use logging at most.
   
6. Try to get the configuration as precise as possible. The configuration(s) of your systems are the base your software is running on, keep it as simple as possible and as complex as necessary. To ease your way changing your configuration later on simply follow an old saying from Antoine de Saint Exupery: "Perfection is reached not when there is nothing left to add, but when there is nothing left to take away."
   
7. If possible try to set up a test system. If you do not have a spare server for that, do it on your own (development) computer. The moment you notice erratical behaviour is the moment where you do not want to mess around setting up a system to replay and find the error.
   
8. Make Backups. Nobody wants backup but everyone cries for recovery. Do not forget that you write server software and, in case something bad happened, you have to be up and running as fast as possible. Backups may help to recover fast, then you got time to search for the problem.
   
9. If you follow all these steps do not forget that "releasing" has other implications for server software. The good news is that you may not need to release client-software on hundreds or thounsands of computers. The bad news is that you might have to take your server down to release new program(part)s and believe it or not: Users don't like that ;-) . So releasing should be as fast and stable as possible. Best would be that it is rollback-able to an older (working) release.
   
10. Alas, there is one very unpopular thought left: Document it. Start documenting the structure (i.e. involved server machines, a top-down documentation of the different modules/parts of your software etc.) and the programming code inline itself. There are many guides and tools out there that help you get your documentation right, search and follow the ones that help you most here.
    

Though this all sounds pretty obvious it is astounding that you nearly never see systems that follow all this tips. Even if you want to you may not be able to follow all of them because of restrictions from the outer world (timelines, new "prio zero" features needed yesterday etc.). But often it helps just to keep them in mind in your daily work and introduce them eventually. And now, happy server-software-coding!

Why Java might lose against Ruby (or Python, or PHP ...) in web development

There I said it...

There I said it, Java might lose its rank in web development. Sun GPL'd Java and integrates scripting languages. Ruby is going on with JRuby, Python has it's JPython pendant, nowadays PHP runs/compiles on Java. But that is not enough, Java may lose the struggle for the #1 internet language.

I always thought that a language like C# will accomplish the task to overthrow the "heir to the throne", but that was a little bit naive and sounds ridiculous: Java and .NET are way too similar for that. Lisp? SML? OCaml? Haskell? No, these languages need (damn) good programmers to complete the task, and there are not enough good people out there. To shift the workload needed in IT-business kind of standardized people are needed (no offense meant!): People only thinking in mathematics, functional programming and definitions, or simply only programming recursions seem to be the wrong way to work this load. The industry needs standard tasks to be done in standard ways by standard workers. If it wouldn't be that way, no-one would program Perl/PHP/Java/C# or similiar languages/scripts any more, they would program such complex algorithms like Shell-sort in only four lines (as I did in SML more than one and a half decades ago).


The three frontier war

Many people are complaining about Java, it is fighting a three-frontier-war. The arguments:

1. Java is losing against Perl or PHP because they "get things done". Perl is "quick in programming". PHP is a starters programming language, fast and simple (be honest: nearly no good known project uses PHP5 with objects and Exception-handling) and, moreover, it's good for small to medium sized projects and has (like Perl) not to deal with the (typing and casting) overhead of strong typing.
   
2. Java is losing against Ruby or Python because they "get things done faster". Ruby on Rails seems to rock for (small to medsize) projects and Python seems at first glance to be a good replacement for all.
3. Java has, because of the mature kind and popularity, to match (or: to be a target of comparisons) with functional programming languages like Lisp and Haskell, for example, which "know what the programmer wants" without explicitely explaining it by syntax.
   

I do not even mention runtime behaviour, everyone knows that C (or even C++ compared to an old JVM) is magnitutes faster than Java and everyone thinks that Java still is slow. So, Java is dead, isn't it?

Let us, just for a minute, forget the discussions and the pro's and con's of the points mentioned above, all this was discussed endlessly all over the internet before. Let us not talk about the verbosity of Java programs compared with dynamic language A or the fact that programs can be written so much more elegant using language B, because in B there are not all those conventions which clog the programmer using Java.


Who is killing Java?

Though having the best intentions, Java programmers are killing Java. I know that sounds weird, but I watched that for nearly 5 years now. The fact that Java people, (better: Java software / better: Java frameworks) cannot simply "be simple" discourages. And directs programmers and projects got the train: Ruby on Rails, as an example, is the exact opposite by just being simple. Just "getting the thingies done" is what people want to see after endless fussing around with XML and EJB, hoping that it will work out anyhow. Having hundreds of pages of documentation explaining complex frameworks, who cares? Ever started a new experimental web container in Tomcat and not simply copied the web.xml without exactly knowing what's in there? It got far too complicated.


The world is watching

Continue doing complicated stuff and you will see the people running away from Java. The problem about Java is not the language, the problem about Java is that Java does not provide a "simple start" anymore, not with all the programmers using these fancy frameworks nowadays. I'm not talking J2EE - that is too complicated, too. But that's only interfacing, at least partly. Looking at the frameworks deriving from J2EE and even if you have an IDE like NetBeans or Eclipse installed, you cannot have a web/http-service up and running in 2 minutes. Too much configuration - which needs too much knowledge of how to be configured. And, yes, surely, you cannot simply talk to a database, that would not be 1337 enough, you need a second (third, fourth ...) layer like EJB/Hibernate etc., all XML / annotations configured. At least we can do it, who bothers if we need it? And who cares for SQL, anyway? There are so much frameworks, why bothering with the simple thingies 'round there?

C'mon. I heard of a project where four (practicvally immutable) database tables had to be filled with logging informations and they used the XML-ORM-Mapping iBatis framework for that. Be honest, ever heard of the word "overkill"? Nooooo, you are right: Better configuring it using XML, or even better, let the software write the configuration! Write your makefiles in XML (including self-injected file commands). Keep it unreadable, that's a kind of job-security, too! Why typing some 10 lines of code when we simply may let the preparser generate it by configuring all in fourty lines of XML?

Never mind. Just keep on killing Java.