Top-down or bottom-up architecture? -
Slides of my talk at the Agile Software Architecture Symposium 2012 in Elst.
In my last blog I talked about exploring Kotlin, a JVM language in development by JetBrains. In this blog I’ll walk through a larger piece of Kotlin code.
The program we’re talking about is a simple spell checker. It reads a dictionary of words from a file (/usr/share/dict/words) into a set. Then it reads a sentence from stdin and checks if every word is in the dictionary. Finally it informs the user whether or not the sentence is spelled correctly, i.e. every word is known in the dictionary.
The spell checker is available on my GitHub. Take a moment to study the Java version, we’ll discuss the Kotlin version next.
I’ve been exploring Kotlin recently. Kotlin is a new statically typed JVM language and was announced about half a year ago. This month JetBrains released its first milestone candidate which I decided to have a closer look at.
First of Kotlin is still in its early stages. A lot of things work pretty well (I’m especially impressed by the IDE support) but there are still numerous issues. I’ve hit a couple of bugs so far.
NoSQL techday -
Recap of the techday that I organized last week at Avisi.
Disabling caching in Apache Shindig -
I’m currently working on a project that involves using Apache Shindig. As you may know Shindig relies heavily on caching. While generally a good thing caching is a pain during development. See my post at the Avisi blog on how to disable this in Shindig.
When you are working on OS X - I’m not sure if other OS’es have the same issue - your Talend Open Studio workspace is located under
That’s right the workspace is placed inside TalendOpenStudio.app, which isn’t a very convenient place. Although Talend Open Studio is based on Eclipse it isn’t keen on moving your workspace to a different location. The easiest way around this issue is to replace the above workspace directory with a symlink:
ln -s ~/workspace
From now on all your Talend jobs are created in a workspace under your home directory. To put the contents of this workspace under version control I recommend the following principles (source: bowerstudios.com):
First, avoid Subversion/CVS as they will likely get you into trouble since they add info to each directory that is in version control. Talend Open Studio (TOS) tends to wipe out directories and recreate them, so you will have problems with those two tools complaining that they have lost information. Try to use a tool that does not add per directory entries (like git). I chose git.
You will need to enter the entire workspace into version control, including the hidden metadata and compilation directories (.metadata, .JETEmitters and .Java). With each commit, make sure you grab all of those files that have changed.
For each commit, do not commit until after you have exited TOS.
If sharing across platforms, or with other developers, you may need to keep track of the different paths on your machines:
For example, when you export a job, it will successfully export, but with previously compiled classes if the .classpath file in the .Java directory contains paths not on your local machine. Another way to put it, If someone else commits the project, you check it out, you make changes, you export it, the running code will not reflect the changes you made, even though the source does reflect those changes.
While versioning an entire workspace isn’t ideal it’s the one solution that’s guaranteed to work. If you can suggest better alternatives please let me know.
Finally to verify whether your workspace is still valid after performing the above, just open a job and click on the ‘code’ tab. If you see generated Java code you know your workspace isn’t corrupted.