Sone Topics

Biznis iz gettin’ siriuz

It is amazing how often I manage to code myself into a corner, or at least halfway there, before realizing my mistake. In order to prepare Sone for a persistent database, i.e. the situation that it starts up and everything is already there, I thought I had to make the current in-memory database persistent.

But I think I actually don’t have to do that. Nothing in Sone really assumes that the initial database is empty; everything is cleared when new data arrives, i.e. all data of a Sone is dropped when a new edition is loaded, anyway. This means that it should be perfectly fine to simply start with the new database (yes, it’s finally getting serious!) and see how that works out.

Sone Topics

We Are Getting Closer

I finally managed to get the beast below 2000 lines of code. I have extracted various parts from it and put them into their own classes, with their own unit tests, and I have been pulling almost all Sone-related storing out of there, too. I’m still not done with it, there’s a lot more that will have to go because it shouldn’t have been there in the first place. However, it will probably not take too long anymore until I can start using a real database to store Sone data which I am really looking forward to.


Code Comments Are Useless!

Some years ago I would have refuted above statement with all my might. “No, code comments ensure that you still know what the code is about in two years!” Unfortunately, they won’t.

  • Most likely you will have documented the wrong things. Some constants are explained, maybe a tiny piece of an algorithm but the bigger picture is probably missing. Because there is no commonly accepted place for a description of the bigger picture.
  • Code comments will not be maintained. You say, they will but they really won’t. Recently at work I had to touch a class called KafkaTrackingEventWriter. Apparently this class writes TrackingEvents to Kafka. Its javadoc comment began with “ProfilingEventLogger which…”. The signature of the method doing the work was “void write(UserInteractionResult).” What was your point again, comment?
  • Code comments will not be maintained. This warrants a second entry in this list because sometimes the comments are not clearly recognizable as wrong or outdated. Instead, they look like that are still valid but they introduce (or omit) subtle details about what really happens, leading to hard-to-trace bugs and many wasted hours.
  • Most code comments really are useless, as in: they do not add any value to the source code whatsoever. How many times have you seen a constructor commented with “creates a new thingamajing” or “constructor?” Do you really need a javadoc comment to know that a “Thing getThing()” method returns a Thing? I have seen them more than just a few times and frankly, when I see one of those now, I simply delete the comments.

So, recap time! What is there to use instead of code comments? Source code, of course. Method signatures can be way more expressive than comments, and contrary to comments they will always be true.

Instead of

* Returns an address for the user, or null if no address is found.
* @param user The user
public String getAddress(String user) { … }


public Optional<Address> getAddress(User user) { … }

Even though the second method has no comments, it is a lot clearer what this method actually does.


So, We Meet Again…

The day has finally come! My decision to keep all objects (Sones, posts, replies, etc.) in memory and never re-create them is finally coming back to bite me in the ass. And even though I knew for a long time that it was coming I was kind of surprised and relieved this morning when I realized why I even did that in the first place: because I thought I had to create Sone (and post and reply) objects before I ever had any real data for them!

Now that I finally rediscovered the reason behind this ancient decision I should be able to rework the parts in question to fit in better with the database changes. Just having discovered this makes me have a much more positive outlook on the whole database topic than I had before. :)


So Many Things to Code

Once again, I got sidetracked from Sone development. More or less caused by my moving from Linux (and Windows) to OS X I am currently developing a replacement for the software I used for tagging and organizing my audio files. I used to use JRiver’s Media Center for that but as its OS X port still has a very long way to go to be at least partially usable I decided to write my own software, at least for tagging, converting, and organizing my audio files. So, if I’m currently coding, I’m probably working on AMS.


Why Sone Is Stalling Again…

At work we started watching “Clean Code” by Robert C. Martin (“Uncle Bob”) a couple of weeks ago. While some colleagues are of the opinion that these videos are unbearably stupid (and they do have a point: the way all the knowledge is presented is… uhm… questionable, at least) I have grown quite fond of some of the things Uncle Bob has shown us.

Two points that have especially struck home for me: keeping methods short and test-driven development. While the former is (more or less) easy to implement the latter requires more discipline and is also difficult to work with when a sufficiently large codebase already exists.

So lately I have been writing tests. Thousands and thousands of lines of test code have been added to Sone; in the process I was able to eliminate almost the same amount of lines from the production code because it proved to be unnecessary after various refactorings have performed.

However, one of the targets of the current refactoring still has not been achieved: storing everything in a database. I am a lot closer to finishing this task, though: most objects and their relationships are already managed by a non-persisted, in-memory database. Persisting the database will be a second step that follows later.

I will continue writing tests and increasing coverage to make it easier to finish the big refactoring. Unfortunately that will mean that there won’t be a new Sone version in the near future.