Category Archives: developement

Reviewing old code

Posted on by

I’ve been reviewing some of my old codes that I wrote about two years ago. Partly for fun, partly because I wanted to take a look at writing the MTA I’ve been thinking about for the last couple of years. Like creative writers, or any creative works, I guess, you always have a nagging feeling that your work is never done. You just run out of time. Well, the thing about personal project is, you never run out of time.

Looking at the code, I can only come to one conclusion: It’s utterly crap. Sure, it’s well formatted and it’s tested (somewhat), but below the surface is really bad spaghetti code. It’s interesting for the little reason that I had written that code four years of professional work. I thought I was better at the time. Granted, I think I have grown as a coder, but I didn’t realize that much.

I just went through C++ version of the cdb code, and all the stuff I hate in code is there. Multiple levels of for-if-loops statements. Unclear code paths. And most importantly, mixing multiple classes in the same file.

Maybe it’s the Java developer in me speaking now, but the idea of one class pr file was a really brilliant idea (OK, admittedly it’s not really one class pr file per se since you have inner classes in Java). Given a public class, you know exactly where the definition of that class is. Not a given in C++. And I’m not really unit testing. I’m system testing the code, and not even covering all the code paths. The code is hard to read because I’m mixing comments and code, with callee functions all over the place. No real story, or clear path through the code. Looking at the code, it feels like it’s written by a recent graduate from college…

Horrible, just horrible…

It was interesting to see how far I’ve gotten in the last two years. It’s going to be interesting to see where I’m going in the next two (especially if I ever get around to learning Scala or any of the other functional languages)

Challenging stagnation

Posted on by

I felt like I hit the wall lately, professionally speaking. I’m not sure there is anything new I can learn in Java, my current professional endeavor, unless I’m going for guru status. At least until Java 7 gets releases with the new closure features, but even then, it’s just another interface I need to learn. It’s not mastering software development per se.

I’ve started to look around for other stuff to learn. I could either go back and look at C++, but until C++0x gets released, there aren’t any new features there either. And I’m kinda aware of the new features that they did plan, but probably won’t. So I’m actually looking into either SQL or something like Scala.

From a career path POV, SQL is probably the more useful subject to study, but Scala would probably the more personally satisfying.

It’s actually interesting to see functional languages like Scala and Erlang starting to shine in industry. Functional languages seemed to always been more popular in academia than industry, while procedural languages pretty much rules the latter. Probably because functional languages are more mathematically rigorous, while you could probably train any monkey to write in a procedural language => cheaper labor.

Now, modern procedural languages, like C++ and Java has picked up some functional patterns. Closure and lambda functions might come in with Java 7. Lambda functions have already been introduced to C++ through the boost library. And more importantly, most software engineering books talk about the importance of trying to get stateless, immutable objects.

Still, it’s interesting to see stuff I worked in academia seeping into the mainstream industry. I just might try to pick up Scala.

JavaZone 2010

Posted on by

I went to the big Java conference here in Norway last week. It was really fun being back in a geek zone environment. I miss that from my time in Silicon Valley. This is my second Java conference in Norway.

What I find interesting is the emphasis in the conference. Back in my days, for the C++ and network conferences, the emphasis was more on the technology. What was coming up in C++0x, what people were doing with WBEM and CIM etc. The Java conference is more geared towards best-practices, software development as a profession.

Maybe because I’m getting better at this because I’m getting older, but I’m looking back at my old code, and I keep thinking “what was I thinking at the time”. Sure, the formatting is good and all that, but the ideas, the emphasis on clarity is not there.

I don’t know if a programmer is the best future career path for me, but I do think I still has so much to learn.

Coding – home vs work

Posted on by

One thing many of my non-developer friends ask me is why I would code at home when I do the same for work. For me, there is a world of difference between coding at home and coding at work.

Coding at work means that you are basically stuck with the technology and project that management decided. If you are lucky, you might be part of a project from the beginning and can influence some of the decisions. Still, once decided, there are probably not enough time to make changes later (as much as the agile paradigm promises otherwise).

Working at home means you set the speed. If you do something you are unhappy with, whether it works or not, you can always change it. Since you are basically the management team, you can choose the technology and tools. I also feel like I learn more coding at home, since there is more time for experimentation.

One thing that you need to be conscious of when coding without deadline is limiting the scope. It’s much easier to never be happy with the work, and therefore never finish. One of my favourite windows managers, Enlightenment, seems to be a example of this (DR17 has been in development since 2000).

Still, tinkering at home keeps me interested in coding, so that’s why I do it…

Amending the checkin

Posted on by

After finishing a particular software feature, I like to check in my work. The problem is, I get into a dilemma. Do I check in now, or wait until I’m sure the feature works as advertised. If I check in now, then I might discover that forgot to add something else to the checkin. If I don’t check in now, I might start on another feature, and then it gets messed up.

git has a wonderful feature that fixes this. git commit –amend. Basically, you commit your changes. Later on, you realize there were some other files that should have been committed alongside the first commit. So you just amend the previous commit with your new files. Really nice feature, and should make the history logs much nicer to look at.

cross-platform development

Posted on by

One of the problems of doing cross-platform development, is that you don’t necessary know what the environment will be at the person who is compiling your software. So, you need to be able to check this and maybe notify the user what additional software needs to be installed. You also want your build system to be flexible enough to maybe work around issues and options.

I used to write the build system for the unix development at my previous work. Since the target was limited to HP-UX and Solaris, it was somewhat easy to just create a script which figured out which platform we were at, and then copy the platform specific Makefile to the right location. When I started working on my own private projects, I wanted to make it more robust. Initially I was looking at the automake/autoconf systems. I found it a little too complicated for my needs, although autoconf by itself might have been useful. I still find it somewhat troubling to have to learn another language (M4) to write the configuration files. To me, configuration files that generate the Makefiles should be as simple as possible.

While I was investigating and trying out build systems, I heard that KDE had started using cmake. This made me at least a little curious about it.

The initial impression was that cmake makes it really easy to get started. I was up and running faster with cmake than I did with the autotools chaintools, and almost as fast as writing my own Makefiles. Now, my projects aren’t as big as the KDE project, but if it works for them, it should work for me.

One of the problem I found is the some problem I have found with most cross-platform tools: it has to target the least common denominator. Some of the features seem to indicate that cmake was first developed on Windows, or that developers were primary Windows developers. For instance, there wasn’t a good way to clean up custom generated files using cmake, as in you could make clean target in Make have a dependency on something else, so that that something else also got removed when clean was called. Reading the faq, this seems to have been fixed in 2.4.

Although I haven’t done anything complicated with cmake yet, so far I have been pretty happy with it. It isn’t much more complicated than handwritten Makefiles, and it should save me tons of work on porting.

Distributed Version Control Systems

Posted on by

I recently moved all my development over to a distributed version control system (dvcs) called git. I’m not going to write about dvcs and the difference/advantage/disadvantage between it and central version control systems, like Subversion. There several good articles and blogs on that topic around already [1][2][3]. This is more about my journey.

I started my (development) career using SCCS and RCS slowly moving towards CVS. They worked, with some warts. Some of the weaknesses are well-known, but for tracking individual files, they work really well, and I still use it. Once Subversion came on the scene and stabilized (with the introduction of fsfs repository type), I was hooked. One of the thing I really liked was the concept of change set, that is set of changes that logically belongs together. Like say, a header file and the source file. Change the header file and the source file needs to be changed too.

I recently got in trouble with my svn repository when my working set got into an invalid state as far as my repository was concerned. What happened was, when I moved back to Norway, I shipped my computers. I had made a backup, but had continued developing. And the shipping had taken time, so I had created a new repository from my backup. But since my working set was at a different version than my backup repository, svn wouldn’t let me checkin. Frustrated, I started looking at other vcs.

What got me first looking at git was the google talk by Linus Torvalds. I then read up at the current state of dvcs before I started testing out git, and I was hooked.

What I find interesting is that git feels ‘natural’. The impact on my development process is minimal. As an example, to create a tag in svn:

svn copy svn+ssh://server/path/to/project/trunk svn+ssh://server/path/to/project/tag/{version}

The same command in git:

git tag {version}

Branching is similarly easy in git. But I think the main advantage is that I now can I have multiple repositories for the same project.

My current work process is like this:
edit edit edit
checkin into local repository
edit edit edit
checkin into local repository
happy state
push to private server
edit edit …
once stable state
push to public repository

At at any time during the editing phase, if I’m unhappy with the track I’m on, I can always throw out the changes without messing up my private or public repository.

I really think you should at least take another look at the dvcs and see if it’s something for you.

[1] Wincent Colaiuta’s development blog
[2] Dave Dribin’s Choosing a Distributed Version Control System
[3] Ben Collins-Sussman’s The Risks of Distributed Version Control