Slightly amusing

So, I've been interested in parsers for a while. There are plenty of opportunities to use a parser in our every day jobs, but for some reason, it does not happen very often.  Most of the time, when some task presents us that requires us to recognize some user input, we almost instinctively reach for regular expressions. Regular expressions are a very powerful tool, to be sure. Maybe even too powerful. With all the fancy additions like non-capturing lookahead and back references — regular expressions have become legendary source of obfuscation and subtle bugs in user input verification.  Over the years, I've tried my hand with various parser generator and combinator libraries (ANTLR, JavaCC, JParsec to name the few) and hand-rolled my own in couple of instances. Most of the time when using parser generators, I've felt like I am invoking this big machinery just to get something simple up. And then there's specific parsing technology quirks that I just have to know...

Have you ever seen or used this pattern of code: I've seen the above code and many variations of this pattern scattered all over the various java code bases I've read and it has always nagged me that although we have had the power of generics and the associated type-safety guarantees available at our fingertips for a long time now, this type of general registries of key-value pairs still involve this type of cast-heavy boilerplate. It stroke me then how often I have I seen just this pattern appear and re-appear so many times that I have all but stopped thinking about it.- "Of course, if you need an extensible registry of values, you use a Map of key-value pairs (or a Dictionary )" . And usually you either engineer your registry around same type of objects or you throw the generic typesafety out with a proverbial bathwater and map your keys (usually of the type String ) to values of type, well .. Object . Would'nt it be nice if we could actually ma...

I am slowly but firmly falling in love with the functional approach to programming. I know, it is not a silver bullet and it cant solve all of your problems, but there are aspects of functional style programming that I am beginning to appreciate more and more. Take for example Monads. There is a whole lot of talk about monads, monoids and whatnot floating around the intertubes, and through all that almost hard core mathematical chatter that is sometimes quite hard to see what one can benefit from using such a convoluted concept. Specially you get this question a lot when talking to Java programmers. Functional style programming can feel quite awkward in Java, with all the character noise inner classes bring with them, but sometimes it is not all that bad. Some of the functional style concept I've been exploring lately is what Haskell calls the Maybe monad . (Scala has it in it's Option class) Essentially, the Maybe class is all about entirely elliminating null refer...

Although in general I like what MS has done with Windows 7 (it genuinely is the best Windows so far), there is one constant gripe I have with Windows Explorer, that is they've "unified" the keybinding for Backspace to work just like in IE. That is - instead of navigating up one level in the filesystem hierarchy, it goes back in the navigation history. It is highly confusing, because you might not notice it for a while, if you've navigated to your desired destination by drilling down folder by folder and then pressing Backspace to get back to the parent folder. Where it breaks down though is with the nice new addressbar acting like a double for a navigatable breadcrumbs (a pretty nice and useful feature in it's own right) and an address input widget, when you've navigated in any other direction than one level down the hierarchy, you start getting into the apparently weird navigation behavior. I can\t count how many times I've pressed Backspace multi...

I've been playing around with a crazy idea of recreating Eclipse JDT tooling with XText. While it does sound a fair bit more than a little crazy, it appeals to me for few reasons: It would give me great opportunity to learn XText and test it in a non-trivial setting. It would give me great opportunity to learn more about Java the language. Having Java source code parsed into a well defined EMF structure opens up JDT to all the  goodness of EMF tooling that has been developed over these past years. It seems like an interesting idea. I wonder if I actually get around to giving it a try...

This is a second installment in a series of posts that tries to compare two continuous integration and build automation server products. In my previous post I briefly introduced the contenders open source developed Jenkins and a commercial offering from JetBrains called TeamCity and compared their respective installation experience. This time I'll try to cover the post-installation configuration steps I need to make before I can start putting some builds into them. Configuration No server software is usually useful out of the box in and by itself. You almost always need to tweak and configure it before you can really reap the benefits. Continuous integration is just another type of server and it needs to be configured before it becomes really useful. TeamCity After you've installed your copy of TeamCity and opened up it's web interface for the first time, it greets you with a nice little license agreement, you need to agree to in order to be able to continue. ...

As some of my closest friends already know, I decided to bite the bullet and switched jobs recently. As the new company I now work for is really small compared to the one I left, it also means that as a developer I am also involved in more than just programming. One of the decisions I had to make and implement was selecting and setting up a CI server for continuous building and deployment of our next product. Having had extensive exposure to CruiseControl, I immediately discarded it as I've developed a particular dislike for this product. The next alternative I had had any exposure to was Hudson ( now renamed to Jenkins ) and JetBrains's TeamCity , which I had heard a lot of nice things about. Adding to the mix that first project to hit our CI server would be .NET project, I needed a solution that would run on Windows and build .NET projects using MSBuild. I settled on Jenkins and TeamCity as the two major contenders. I would like to point out that this post is ful...