Archive for the ‘Java’ Category

Articles

Jetbrains in Unity integration

In Java,Ubuntu on 02/07/2012 by weirdfellow Tagged: , , , , , ,

I really really love products by . Those guys really know what a developer expects, needs and they deliver. However, the IDEs (I have been using IntelliJ IDEA, as well as PhpStorm) don’t integrate with Unity that well – it’s not possible to pin the icon to launch bar, the windows do not merge and you get duplicate icons etc.

To tackle this problem, you can create custom launchers and drop them into /usr/local/share/applications (you might need to create this directory first).

IntelliJ IDEA.desktop

[Desktop Entry]
Name=IntelliJ IDEA Community Edition
GenericName=Java Editor
Comment=Develop with pleasure!
Exec=/usr/local/programs/idea-ce/bin/idea.sh
Icon=/usr/local/programs/idea-ce/bin/idea.png
Type=Application
MimeType=text/plain;
Categories=Development;
StartupNotify=true
Terminal=false
NoDisplay=false
StartupWMClass=jetbrains-idea-ce

PhpStorm.desktop

[Desktop Entry]
Name=PhpStorm
GenericName=PHP Editor
Comment=Develop with pleasure!
Exec=/usr/local/programs/phpstorm/bin/phpstorm.sh
Icon=/usr/local/programs/phpstorm/bin/webide.png
Type=Application
MimeType=text/plain;
Categories=Development;
StartupNotify=true
Terminal=false
NoDisplay=false
StartupWMClass=jetbrains-phpstorm

The important thing is the StartupWMClass – it allows Unity to identify the windows and connect them to icon in the launcher, so that they merge nicely… Small thing, but makes me so much happier 🙂

Articles

I don’t believe in Groovy

In Java on 31/10/2010 by weirdfellow Tagged: ,

I always try to stay on the open minded part of the population. I have been trying with Groovy too… Half year later I can state – it is a fancy toy that looks great in the sample, but not a generic purpose language.

Groovy advocates usually have following reasoning:

Static typing doesn’t give any benefits – you have to unit test anyway
I am almost certain that nobody will ever hear from me that testing is unnecessary – quite the opposite.
But type checking allows to instantly identify a whole bunch of common coding mistakes, without need to wait for the tests to execute (and those can take some time)…

Java is too verbose, Groovy is much more compact.
Let’s make the identifiers optional wherever there is only one token in scope that fits! Compiler can figure things out and the code will be 17 bytes shorter!!! All this time I would have spent so much time on pressing the space…

Java is verbose – but what is wrong in being verbose? The more compact code, the more comments are required and it the end it sums up to the same number of bytes. I could start writing a more verbose, self explanatory Groovy code too. In other words – to make a code that is easier to read I would have to discard the compactness of Groovy. In such case – why bother with Groovy at all?

I don’t deny Groovy the right to exist – I definitely can see its the benefits. There are even things in Groovy I really like. Closures. Compact syntax for creating instances of ArrayList and HashMap. XML parsing. Groovy definitely can be useful.

However I am certain that those are only the situations when once you got working code, you never touch it again… Projects when the functionality has to be there now, and will be thrown away week later. Or tiny, very specialized classes you can throw away when they need to change and write them again. Refactoring a Groovy code will be a nightmare – because of its dynamic nature.

So – if doing anything with longer time frame, anything that might get refactored – keep away from Groovy.