elidev

Posted by eli at 31 October , 2011

A couple of weeks after Dennis Ritchie died, I am sitting at a Windows desktop trying to debug connection problems together with another developer. The web server we are working with establishes a lot of TCP connections to an external web service, and once we put load on the system we start getting connection timeouts or error messages indicating that the sockets cannot be opened. We suspect this may be caused by the system running out of ephemeral ports, and we want to test this hypthesis.

By running netstat we can get a list of all active ports, and we can see what state they are in (the most interesting issue is whether there are lots of sockets in TIME_WAIT). What we would ultimately like to do is to run netstat over and over again counting the number of sockets in TIME_WAIT and correlate this information against the error messages from the web server.

In Linux, this would have been a piece of cake. Write a bash-script that loops netstat | grep TIME_WAIT | wc -l, redirect output to a file or even pipe it to another program, and we are done. How do you accomplish this in Windows? There may be a way, but I am not familiar with it. The corresponding bat script would be much more complicated, so much that the whole approach is probably not advisable. You probably will end up installing or using some software providing exactly the information you want in a cute little UI, but for every single case you would have to repeat this procedure.

For these “ad-hoc” diagnostic tasks, Unix simply outclasses Windows, which is one of  the reasons I vastly prefer Linux to Windows as a server OS. I am amazed with how well the fundamental Unix design principles continue to hold up.

When we think of “design” what we typically think of is the slick GUIs created by the likes of Apple, but the Unix shell is also an example of excellent design. And yes, it is also extremely usable, especially for diagnostic tasks like the one outlined above. Rest in peace, Dennis Ritchie, and thank you for everything.

As a final note I can recommend Joel Spolsky’s excellent article from 2003 about Unix/Windows biculturalism which is well worth a read.

Tags: linux, unix, windows
Posted in: Uncategorized | No Comments »

Posted by eli at 30 August , 2011

Today at work I ran into some issues with cron. One of my Java programs would run fine when executing manually, but would throw a ClassNotFoundException for StringBuilder when executing under cron. Since StringBuilder is a somewhat “recent” (haha) addition to the Java API, I suspected that it had to do with crontab running an older version of Java, probably the 1.4.2 version bundled in the Linux dist. I could verify this quickly by adding some debug print to the startup script.

A really nice feature of crontab is that you can set environment variables at the top like this:

SHELL=/bin/bash
JAVA_HOME="/opt/java"
#Minute   Hour   Day   Month   DayOfWeek   Command
* * * * * /path/to/script/script.sh > /path/to/script/log 2>&1

and then just have your script use $JAVA_HOME to locate java. This means that the script can be recycled in different environments with different Java versions.

Of course, even better would be to  not have to wory about $JAVA_HOME at all, and just use the “java” command in the script. This assumes that the java command first found in the path references the correct Java version. In the bash shell this is usually set in the file ~/.bash_profile like this:

JAVA_HOME=/opt/java
PATH=$JAVA_HOME/bin:$PATH
export PATH JAVA_HOME

However, cron does not read these settings, so they must be set up manually in the crontab file according to above. Which was exactly what had been done in my case:

SHELL=/bin/bash
JAVA_HOME="/opt/java"
PATH=$JAVA_HOME/bin:$PATH
#Minute   Hour   Day   Month   DayOfWeek   Command
* * * * * /path/to/script/script.sh > /path/to/script/log 2>&1

and this is where it falls apart. This would be nice if it worked, but it does not. Specifically, the leading lines in the cronab syntax are not a script, just a collection of name-value assignments. This means that the expansion of $PATH and $JAVA_HOME fails in the example above. To remedy this you have to repeat the JAVA_HOME variable in the PATH assignment, and also make sure to include everything else of interest, which means you need to do something like this:

SHELL=/bin/bash
JAVA_HOME="/opt/java"
PATH=/opt/java/bin:/sbin:/bin:/usr/sbin:/usr/bin
#Minute   Hour   Day   Month   DayOfWeek   Command
* * * * * /path/to/script/script.sh > /path/to/script/log 2>&1

Of course, this is all detailed in the manual for crontab. It still took me some time (and help) to fully diagnose the error (mostly due to the fact that I missed that the debug print of the $PATH variable did not expand $JAVA_HOME).

Tags: cron, linux
Posted in: Uncategorized | No Comments »

Posted by eli at 22 April , 2011

In the past couple of weeks I have been programming in .NET for the first time since 2006. My last stint was actually mostly C++-stuff in a code base based on MFC, so the .NET parts were really not that prominent, and I did not touch C# at all. This means that I was new to C# in all relevant aspects when the current project started. The project is integration work – we are embedding a thin C# client in third party software to enable integration between that software and our main product implemented in Java.

Starting out, the first expression is really how similar C# and Java are. As a Java developer there are no problems getting started – mostly it’s just new APIs to learn. You will also of course have to switch IDEs – in my case from Eclipse to Visual Studio .NET 2010. Still, the main difference is the keyboard shortcuts, and I am amazed how quickly my brain can replace hardwired shortcut commands such as Ctrl+/ for comment section to Ctrl+k, Ctrl+c. Even stranger is when you go back to Eclipse and you are suddenly dumbfounded when you can’t remember the old shortcut anymore.

Of course, after a while you start to notice other things – the perks, the annoyances and the little differences. I will spend the rest of this post listing some of the stuff I have noticed.

Visual Studio vs Eclipse

Visual Studio is more polished, feels quicker and is much more user friendly. I was surprised at this, because that was definitely not my impression five years ago. Now, Visual Studio just feels more modern. The one thing I lack is Maven, or something similar. We are two developers on our current project, and we have set up our projects a little bit differently, so we keep overwriting our project files in the SVN repository. It is annoying to have to manually update the project references after every SVN update, and I really detest having to include binaries in the SVN. Of course we could just work out a common setup, but in Eclipse with Maven this problem would not exist in the first place – dependencies would just be automagically resolved.

Properties

In C#, a class can have properties, which is basically variables with getters and setters. (The property concept allows for much more, but this is mostly how I have seen it used.) At times, this is really neat, but I don’t like it because it seems to promote get/set programming as opposed to Tell, Don’t Ask. Of course nobody is forcing you to use properties, but it is an easy enough trap to fall in – I feel I have already begun to overuse it.

Delegates

Delegates seems like a powerful thing, but I have not seen it used in the code base, which makes me kind of hesitant to try it out. The delegate concept actually promotes OOP (as opposed to e.g. properties) since it makes it possible to send a function as an argument to a method. In Java, this would be handled by declaring an interface with a single method and implementing an anonymous inner class. In comparison, the delegate concept seems much more elegant. Java apparently will get closures Any Day Now, which I really look forward to.

Naming of Classes and Interfaces

This really bugs me with C#. In something that must be the last remnant of the (blissfully) long dead Hungarian notation, interfaces in the .NET API are prefixed with the letter “I”. I don’t see the point of this at all – quite the contrary, it is downright harmful. Compare these two method declarations in C#:

void doStuff(IList<Stuff>);

void doStuff(List<Stuff>);

The second example just feels cleaner. It’s just not right that you are punished aesthetically by programming to an interface. Compare with these Java declarations:

void doStuff(List<Stuff>);

void doStuff(ArrayList<Stuff>);

Here, the declaration using the interface is much cleaner. This might seem like a small thing, but it’s really not – the Java API is subtly guiding you into OOP, while C# is doing the opposite. Another important issue is that in the C# version the reasons for programming to an interface are not clear. It looks as if List is the implementation of IList. In Java, it is clear that ArrayList is one implementation of List, and the name carries a hint as to how this implementation works. This is not unique to List either – the same is true for e.g. IDictionary/Dictionary (Map/HashMap in Java). Even as a professional programmer I have in the last weeks declared methods against a concrete class instead of an interface, which is something I would simply not do in Java. And why would I? The interface variant simply looks so much better.

 

Tags: C#, Java, OOP
Posted in: Uncategorized | No Comments »

Posted by eli at 16 April , 2011

Well, first of all the “Java Software Stack” is not so much a stack as it is a forest of possibilities. At every level there are multiple choices: what application server to use (Tomcat, JBoss, WebSphere, Jetty…), what IDE to use (Eclipse, NetBeans, IntelliJ…), what OS to run on (Windows, Linux…), what framework to use (Spring, Struts…), what to use for the database persistance layer (Hibernate, IBATIS…), what DBMS to use (Oracle, SQL Server, mySQL…) and so on. Even such basic things as choice of programming language can be put to the question, with other JVM languages such as Groovy and Scala vying for attention, and there are also multiple implementations of the JVM itself. How can a developer who is introduced to these choices possibly be expected to come up with a combination that works? Some of these choices are more important than others, and in other cases the choice is truly just a matter of personal preference. The fragmentation also leads to tools that are not exactly the most user friendly you will use (Eclipse – I am looking at you) since they need to support many different choices for other parts of the stack.

The fragmentation is somewhat paradoxical since the thing I like most about the Java programming language is that it is constrained. There is often just one way to do something. All code must be part of a class. All .java files must represent one class. Checked exceptions. Statical typing. Garbage collection. In my opinion, these features all contribute to make Java very maintainable. I do not think that it is a coincidence that Java and C# still rule the application programming space, even though more dynamic languages have taken over elsewhere. For teams of programmers, it is important that, in a sense, all code looks the same, as enforced by the language constraints and naming conventions. The constraints also makes it possible to implement really nice IDEs for development, lightening some of the burdens the constraints bring with them (such as verbosity).

For C#, the constraints continue all through the software stack. You run it on Windows in the .NET framework, with ASP as a template language, on IIS with an MS SQL Server database. You develop in MS Visual Studio. You can even extend the Microsoft stack even further, for example by adding their version control system. All this makes C# a really good choice for building Windows only applications. The integration is superb, and is something Java will never have.

I suppose it is the curse of “open” that fragments the Java stack. When something is “open”, everyone will have their own idea on how to use it, so the Java stack becomes a bazaar rather than a cathedral. This is, of course, both good and bad. The bad part is that you can easily get lost among the different alternatives, and get stuck trying to integrate different components with eachother. The C# programmer has no such problems – it Just Works. Microsoft is to developers what Apple is to end users.

Since my job involves mostly Java SE stuff, I can blissfully leave most of the difficult choices behind. And stripped down to its core, I will stick to my guns and proclaim Java a really nice language. Apart from the fact that it is constrained in a good way, the main advantage is one of the things that leads to fragmentation in the first place: its platform independence. Because, you know, sometimes you might actually want to run your program on Linux, or even (God forbid) Mac. In fact, these cases are really common. Without getting into details, I would say I vastly prefer Linux to Windows as a server platform, while on the desktop it is the other way around. With Java, this is no problem. The program works the same on both platforms, so I can happily develop and test on my Windows box, and still be certain that it will work on Linux as well, provided I implemented my program in a correct way (for example, remembering to handle character sets etc, which I really should take care to do in any case).

Sure, Java could use some tidying up, but until something better comes along, I will stick with it. I just wish that some things weren’t quite so, well, clunky.

Tags: Java, Programming languages
Posted in: Uncategorized | No Comments »

Posted by eli at 8 April , 2011

This week I decided to play around a little bit with Spring MVC. I am not a web programmer by occupation, but it is something I want to learn, and I decided to start with this tutorial. The choice of Spring was rather random, except for the fact that I wanted to use Java as a programming language since this is familiar territory for me.

To complicate matters, I decided to run the latest version of Spring, 3.1, instead of 2.x as suggested in the tutorial. With jar names changed I also quickly decided to abandon ant for Maven, which overall turned out to be a good choice. Maven can certainly be a little (or a lot) clunky, but the dependency management makes it all worthwhile. Luckily, I found another guide that comprehensively describes the Maven integration. For development environment I used Eclipse, which despite its various shortcomings is my first choice for Java development.

Setting up the Tomcat application server was more complicated. Keep in mind that I have only coded very basic web applications before, so it was a lot of work to get the debug environment up and running. While I am sure there must be an easier way to do it in Eclipse via a Server project, I ended up running a standalone Tomcat installation, redirecting via server.xml to my Maven target directory like so:

<Context docBase="C:\workspace\springapp\target\spring-mvc-trial-1.0" path="/spring-mvc-trial-1.0" reloadable="true"/>;

I then had to include all the Tomcat jars from the installation as external jars in my Eclipse project before I could finally start the server in debug mode by calling the startup class directly. Cumbersome as this may be it works for now, although I will probably have to revisit this in the future.

My general impression of Spring is mixed. On one hand, I suppose it is nice to have the code separated into Model/View/Controller with configuration in XML, but on the other hand it is easy to see how this whole approach could get completely out of hand. XML may be a good tool for many things (configuration, data specification etc), but it is crappy as a program language. Moving implementation into XML files via excessive use of beans seems like a terrible idea, yet I can easily imagine how one would end up in this situation in Spring when programming for “configurability”.

So does Spring speed up the process of getting a website up quickly? Well, not really. Of the limited options I have tried to get a website up in the quickest possible way PHP wins hands down. This is surprising to me, since I figured all the newer neat frameworks (Ruby on Rails, Grails, Spring etc) would help with this, but the reality is that they have a steep learning curve. In PHP, what you need to know from start basically boils down to the language itself and some basic SQL, while with these other frameworks you have to grasp the relationship between model, view and controller, and probably at least two different programming languages (one for templating and one for code) as well. Not to mention all the work you need to put in to get a test environment up and running, where in PHP you would just copy your files to a folder. PHP also seems to be supported more at inexpensive web hotels, at least in my limited experience. Having said this, PHP certainly has its drawbacks. It is a mess of black magic calls to global structures, and I suspect it fosters horrible programming habits when it comes to OOP concepts etc.

I think I will stick with Spring for now, mostly because it is based on something I have good knowledge of (Java). My next project will be to upgrade my code from the tutorial to use the Spring 3.1 features in full, by replacing all the calls to deprecated functions and take more advantage of the annotation based framework.

 

 

Tags: Java, Spring
Posted in: Uncategorized | No Comments »

Posted by eli at 6 April , 2011

Time to get my tech blogging rolling. Here we go.

Posted in: Uncategorized | No Comments »