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.
Spell checker 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.
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 coupleofbugs so far.
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.
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.
In the meantime all references to the Open Streams developer documentation have been removed. Looking at the current Graph API it doesn’t seem to conform to the JSON activity stream 1.0 format. Did Facebook (silently) stopped supporting this format?
Currently I’m using the build-in HTTP server in Java 6 for (integration) testing RESTful services. Although this has the advantage of adding zero dependencies, the API of REST-assured looks cleaner. Something to keep in mind when you need to test (many) services.
Like my colleagues at Avisi I’m an avid OSX user. One of the reasons I like OSX is it gives you the power of Unix right under your fingertips while still providing a nice user interface.
Now suppose you’re working on RESTful services and you need to verify or debug some JSON output. Digging through an unformatted JSON string can be a real pain. To make a JSON string human readable open up the Terminal and type:
This will pretty-print the contents of “unformatted.json” to a new file called “formatted.json”. For this to work you need to have at least Python 2.6 installed. Which is the case when your running Snow Leopard or higher.
The above command assumes you have a file containing the JSON content. When you’re debugging it’s more likely you copied a JSON string to your clipboard from a (remote) log file. To pretty-print the JSON content on your clipboard type:
pbpaste | python -m json.tool > formatted.json
Likewise when you’re dealing with XML instead of JSON type in:
pbpaste | xmllint --format - > formatted.xml
The xmllint program is part of libxml2 and installed by default on OSX.
There’s an annoying issue when using Maven from IntelliJ IDEA on OSX. You might encounter the following error when building a Maven project.
No valid Maven installation found. Either set the home directory in the configuration dialog or set the M2_HOME environment variable on your system.
The issue is well known and there are varioussolutions to the problem. The trouble with some is they apply to old versions of OSX, specifically Leopard. If your running Snow Leopard or higher you don’t need to alter your launchd configuration. The following will suffice:
1) Check you Maven home directory.
2) Create the following file in ~/.MacOSX/environment.plist.
Welcome to my new blog or more accurately “tumblelog”. Here I’ll occasionally share my experiences as a software engineer. Themes include Java, agile, open source, architecture and pretty much anything in between.