New home

This blog has moved to javanto.com/blog. See you there!

Fixing Mozilla Thunderbird Icon in Unity, Docky, GNOME Do and Indicator

Annoyed by the low-resolution icon that comes with Thunderbird in Ubuntu? At least it looks butt-ugly on Unity menu, Docky dock or GNOME Do dialog.

Of course you could just edit /usr/share/applications/thunderbird.desktop and make its Icon property to point to a higher resolution one, but that’ll mess up the icon shown on the indicator (if you’re using the great Thunderbird indicator plugin).

For proper replacement download XPM version of the Thunderbird icon from Mozilla (right click the “Raw file” link and “Save link as” using thunderbird.xpm as the file name). And then execute few commands, which namely remove the crappy PNG icon and replace it with the XPM version.

sudo rm /usr/share/pixmaps/thunderbird.png
sudo mv ~/Downloads/thunderbird.xpm /usr/share/pixmaps/thunderbird.xpm
sudo chown root:root /usr/share/pixmaps/thunderbird.xpm

After that everything works as they’re supposed to and I see no ugly pixels!

HTML, CSS and Web Design Rant

I don’t know if these are widely accepted, but the following practices in HTML and CSS, or web design in general are pissing me off.

Using font thickness as a hover effect. Not using this should be quite obvious but still I keep seeing it. Jumpy layouts suck, mmkay?

<br /> all over the place. It’s okay when formatting text (poems or such), but do not use it for creating empty space in layout, that’s what CSS is for!

CSS padding makes me crazy. It’s probably one of the easiest ways to get yourself totally lost in how and why some element you’ve set to occupy 100% of the width, takes some extra space. There’s nothing you can do with it then.

Probably the most horrible naming I’ve seen has been on CSS classes. Naming them red, floatRight, witdh100 etc. is reusable, but utterly retarded if you think about it for a while. Separating the layout from the content is the purpose of CSS, now when you’ve got an element with class="red floatRight" it’s no different from color="red" float="right". You should not use the elements visual properties in class naming! Common properties that tend to become parts of the class name are darkness variations ie. if in a list every other row has to have a different shade of gray, then try not to name the classes as some-list-row-dark and some-list-row-light, but instead use the rows’ non-visual properties, like odd and even.

Go ahead and post your biggest annoyances in HTML and CSS implementations!

Running Sinatra on Ruby 1.9.2 Stack at Heroku

As my dear Twitter followers may know, I’ve got a pet project called HashFresh (among others). Originally written in Python for Google App Engine, I decided to port it to Sinatra and host it on Heroku. This post documents the challenges I faced as a Ruby newbie during the work I expected to be pretty trivial.

First of all, installing the latest Ruby version on Ubuntu. Currently the latest release is 1.9.2 and after reading from Heroku documentation that 1.9.1 has a bug making Rails3 unusable, I decided – just to be safe – to go with the newest one. Boom! Lucid Lynx repositories’ default Ruby version is 1.8.7 and Ruby 1.9.1 is provided as package named ruby1.9.1. Thankfully the Maverick Meerkat repository was already up and running and it contained Ruby 1.9.2 in the ruby1.9.1 package, oddly enough. Since I was not planning to go back to 1.8 and all the executables were named like ruby1.9.1, I created symbolic links from ruby, gem, rake etc. to ruby1.9.1, gem1.9.1, rake1.9.1 etc.

After that I had to install the gems my project required; sinatra, heroku, haml and maruku. That being done, I noticed I wasn’t able to use them since they weren’t on the $PATH, so up to editing ~/.profile and adding to the end:

PATH="/var/lib/gems/1.9.1/bin:$PATH"

Sidenote: If you want to skip most of this, use RVM. It requires you to edit ~/.bashrc if you’re on Ubuntu as described on the installation instructions, but I think it’s definitely worth it. And it allows me to run multiple Ruby environments like JRuby, which is my next take.

All that Linux stuff now done, I could start the porting work which went all fine until I used String#split. While working locally, it didn’t work on Heroku. Running heroku stack showed me why, I was still using Ruby 1.8.7 as the production environment. But that shouldn’t be a problem at all since Heroku supports also 1.9.2 stack.

But still, something has changed somewhere between the stacks. On 1.9.2 "foo".split results ["foo"] in the HTML whereas on 1.8.7 it results "foo". At least it is not the String API that has changed, because on both stack versions return ["foo"] on heroku console '"foo".split'.

So, running heroku stack:migrate bamboo-mri-1.9.2 was all I need to do for switching to 1.9.2, I thought. The truth is, it wasn’t. The application crashed during startup and heroku logs didn’t quite explain why. The error message was:

<internal:lib/rubygems/custom_require>:29:in `require': no such file to load -- hashfresh (LoadError)
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from config.ru:1:in `block (3 levels) in <main>'
        ...
-----> Your application is requiring a file that it can't find.

       Most often this is due to missing gems, or it could be that you failed
       to commit the file to your repo.  See http://docs.heroku.com/gems for
       more information on managing gems.

       Examine the backtrace above this message to debug.

I did as it told me and examined the trace, but I couldn’t figure out why it couldn’t find the hashfresh.rb file, which clearly was in the root directory. config.ru stating require 'hashfresh', as instructed in the Heroku docs. After a Heroku support request and a Stack Overflow question, I found the answer. Between Ruby 1.9.1 and 1.9.2 they’ve changed the $LOAD_PATH not to include . directory automatically, so I had to state require './hashfresh' instead.

All’s well that ends well. Programming with Sinatra on a simple project like this is very pleasing.

GAE + Eclipse + Maven – Update for Helios

Help me in making the integration of GAE, Eclipse and Maven smoother and star this issue in AppEngine

You may have noticed that Eclipse 3.6 aka Helios is out. That meant some changes on the m2eclipse plugin, mainly removal of the external tools Maven builder, which made the previous GAE + Eclipse + Maven configuration unusable.

Sounds horrible? It shouldn’t, since I’ve fixed the archetype and example project to be compatible with Helios. To create a new project just run:

mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:generate \
  -DarchetypeGroupId=org.beardedgeeks \
  -DarchetypeArtifactId=gae-eclipse-maven-archetype \
  -DarchetypeVersion=1.3.2 \
  -DarchetypeRepository=http://beardedgeeks.googlecode.com/svn/repository/releases

If you already have a project and want to upgrade to Helios, change the contents of the content tag in the MavenBuilder to:

<![CDATA[<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.ui.externaltools.ProgramBuilderLaunchConfigurationType">
<stringAttribute key="org.eclipse.debug.core.ATTR_REFRESH_SCOPE" value="$${project}"/>
<booleanAttribute key="org.eclipse.debug.ui.ATTR_LAUNCH_IN_BACKGROUND" value="false"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="${maven.home}/bin/${maven.executable}"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_RUN_BUILD_KINDS" value="full,incremental,auto,"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="war:exploded"/>
<booleanAttribute key="org.eclipse.ui.externaltools.ATTR_TRIGGERS_CONFIGURED" value="true"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY" value="${basedir}"/>
</launchConfiguration>]]>

And set up a the maven.executable property. By default it’s mvn and I created a build profile for Windows environments that sets it to mvn.bat.

With the new 1.3 version the linked war folder is no longer required. Even with an existing project I’d suggest you to check out the new configuration from the example. If you’re facing problems (or just want to praise me), go ahead and comment!

Update: Version 1.3.1 now has proper support for Windows!

HOW-TO: GAE + Eclipse + Maven

Help me in making the integration of GAE, Eclipse and Maven smoother and star this issue in AppEngine

Update: This solution doesn’t work on Eclipse 3.6 Helios and newest version of m2eclipse, check out the new solution if you’re on the latest version.

Nowadays everybody wants to manage their Java projects with Maven. And that’s totally sensible since Maven makes some things pretty damn easy, mostly because there’s a plugin for about everything. Yes, there is a plugin for Google App Engine (GAE) too, with which you can run the local development server and deploy your app. The same features are available on the Google Plugin for Eclipse, which is the Google preferred way to develop Java-based App Engine applications. So of course you’d like to also utilize the IDE integration, especially when the startup time of the local GAE development server is significally faster, thus increasing your productivity. So far, the problem has been, how to enjoy the benefits of both worlds, and I’ve have to tell you, it is now solved. Another thing I have to tell you is, how, so here we go.

Requirements

• Google App Engine SDK for Java 1.3.0
• Eclipse == 3.5 (with Java Development Tools)
• Maven >= 2.0.9
• Google Plugin for Eclipse (link to the update site)
• m2eclipse (link to the update site)

The integration isn’t compatible with m2eclipse, but it’s required for attaching the Maven war:exploded goal to Eclipse compilation. Also the integration is not perfectly production ready since it has to rely on snapshot version of maven-eclipse-plugin hosted at Bearded Geeks’ Maven repository. It’s required for linkedResource configuration and using the Eclipse Java Compiler. For more details see plugin’s issue tracker for linkedResources and output classes (Voting the issue and by other means trying to get the patches in highly appreciated).

So, I’ve converted the Guestbook Example into a Maven managed one and I’m distributing it as a Maven archetype. So, here’s how you begin:

mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:generate \
  -DarchetypeGroupId=org.beardedgeeks \
  -DarchetypeArtifactId=gae-eclipse-maven-archetype \
  -DarchetypeVersion=1.1.2 \
  -DarchetypeRepository=http://beardedgeeks.googlecode.com/svn/repository/releases

By running that command you can create a Maven managed GAE app of your own. Just remember to change everything to match your application, like appId etc. To enable Eclipse integration run mvn eclipse:eclipse. After that you’ll need to import the project to Eclipse and after that and few project refreshs you should be fine (don’t mind it giving warnings about some missing libraries, they shouldn’t affect). Just run it as you usually run App Engine projects in Eclipse. Also on every Eclipse startup the Eclipse might put its GAE libraries back to war/WEB-INF/lib which’ll cause failure on startup, but cleaning the project solves the problem. You can also run your project using maven-gae-plugin by typing mvn gae:run on command line or deploy to App Engine by typing mvn gae:deploy.

If you’re not that into archetypes, you can find the project sources through SVN at Bearded Geeks’ Google Code project. The guestbook example can be found up and running at the project’s GAE page.

My Jump into the Modern SCMs

I’ve been a somewhat faithful user of SVN since I started programming some 7 years back. It’s better than CVS (which I’ve used for some time) or – I don’t even know what kind of perverted – methods people used to use before that. It has worked relatively well in my very own projects and inadequately in the company space. I think the case is quite similar for many projects, the switch from CVS to SVN is now followed with another switch.

In the last few years I’ve heard rumors about the next-generation SCMs like Mercurial, Git and Bazaar. I’ve heard huge open source projects moving out from SVN to one of those. As far as I understand, they’re all based on similar approach: You clone the whole repository to your computer as a local repository, make your commits to the local repository and then push the changes back to the distributed one. Then the changes from the distributed repository are pulled to other people’s local repositories and so should you do with the changes they have made.

For a while I’ve thought that the next-generation has already become current and I should really get back on track with the revision control. Few weeks ago a perfect moment appeared when I begun an open source pet project with a good friend of mine. We decided to use some modern technology for sharing the sources with each other. So we went on with Google Code which meant Mercurial.

First thing I want to know when introducing a new programming-related practice is its integration with the practices I already use. Read: I want IDE integration. And I also want to reserve the ability to change IDE and it still works. Of course I want to run it on multiple platforms, at least Windows and Linux. I want the ability to change from Eclipse + Windows to Netbeans + Linux or any combination of these, also as IntelliJ IDEA is being open sourced why not expect support for it too. I have to admit that that’s a bit tough requirement for any system, but coming from Java world that’s kind of a default expectation.

Mercurial works nicely out-of-the-box on Netbeans, probably because they use it a lot internally at Sun, for example on OpenSolaris. The Eclipse support is really impressive nowadays, the HgEclipse is reaching the standards set by Subversive and Subclipse.

The things are completely the opposite on Git, the Eclipse plugin is quite good – despite being still in incubation – and integrates well with the Team features. The Netbeans integration is not even able to push to the master, which makes it mostly unusable.

As a conclusion, my expectations have after all been reached, and I expect to see bigger change in the near future, when the integration level raises on top of that of SVN which might be the reason restricting wider adoption in the enterprise. I don’t know if there will be a single winner in the end. It seems that Mercurial and Git are quite even on features and adaption and Bazaar is not much behind. Mercurial is definitely ahead on IDE integration. If there will be a single winner, as a Finn, I have to hope my countryman‘s product Git to be victorious. (For the serious readers, former is intended to be a joke, I’m really not patriotic at all, though Linus is a nice guy) I want to wish a merry Christmas to all my few readers!

Creating A Simple Maven Plugin

I’ve been a big admirer of Maven for a long time. For some reason I have never made a plugin of my own. Today I did it, and I have to say it was a great learning experience. I will introduce all the neat things I figured out during the development. So let the story begin.

At work there was some need for a plugin that could help us with merging the propreties files. After trying to find a ready made solution it was quite clear that doing it in-house would be a very low priority since the result is already accomplished using Ant. But as the task being quite interesting, straightforward and nicely small, in addition to the fact of me being on a sick leave, I decided to do it on my own and release it under Apache v2 license. The requirement for the plugin was to have environment/user-specific properties files and merge them with some default ones, so that the more specific file’s properties override the ones from the default. The resulting properties files are then mainly used in Spring configurations. The fact of this being implemented with Ant has been the main issue preventing us from switching completely to Maven.

While getting my hands dirty with the code I noticed that all Maven plugins are basically MOJOs (Maven plain Old Java Object). So it was a MOJO that I was after! I created one which I gave the name MergePropertiesMojo. Like all the other MOJOs, it extends the AbstractMojo class which gives access to some project attributes, but for this case I didn’t need any. I was just required to implement the execute() method.

In addition to the plain coding I had to figure out how the plugin would be used. After employing the little gray brain cells for a while my conclusion was that: first-of-all the user must configure the plugin by setting up the properties files to be merged, which consist of a target file and a bunch of files to merge. A good example tells more than thousand words:

<configuration>
	<merges>
		<merge>
			<targetFile>${build.outputDirectory}/application.properties</targetFile>
			<propertiesFiles>
				<propertiesFile>src/main/config/${user.name}/application.properties</propertiesFile>
				<propertiesFile>src/main/config/default/application.properties</propertiesFile>
			</propertiesFiles>
		</merge>
	</merges>
</configuration>

This is the plugin configutation. In this case we have a default properties file which we want to merge with the user’s own properties file. In some other case we could replace ${user.name} with something else. Note that the order of the propertiesFile elements matters since the properties from the file above override the ones from the files below it on the listing. As a result we get an application.properties file with the merged properties to appear in the output directory. As you might have noticed it uses src/main/config as the directory for storing the different properties files. It isn’t that clear (at least for me) what’s the directory for but it suits for this case quite well.

In Maven plugins the user can set up the execution phase in which the plugin executes. So that, if we want the merging to occur on every time the project is compiled we can do it. Here’s a proof:

<executions>
	<execution>
		<phase>compile</phase>
		<goals>
			<goal>merge</goal>
		</goals>
	</execution>
</executions>

This makes the merge occur automatically on each compilation. Different executions can also have different configurations, just by putting the configuration element under the execution. We could then merge some files on compilation and others on package for example. The whole execution thing is not mandatory, since the plugin can also be run manually using mvn merge-properties:merge, but it usually makes things easier as learning new goals and remembering to run them is not required.

Back to the configuration. The merges and merge elements specify that in my MOJO, there’s an array called merges which in my case is of type Merge. Merge is a simple POJO (Plain Old Java Object) that contains the fields targetFile of type File and an array of Files called propertiesFiles. There are some special Maven Javadoc annotations for both the class and the fields that are required for instance in injection of the configuration values to corresponding fields.

On the class I used @goal merge which specifies the name of the plugin goal to start execution (merge in this case) and @requiresProject which specifies that the plugin is required to be run inside of a project. For the fields I used @description and @required which I think are quite self descriptive and @parameter which specifies the field being Maven injected. The @parameter also allows us to set a default value or command-line parameter to use instead of configuration, but I didn’t use those. More details on these can be found on the Maven MOJO API.

After setting up these, the whole thing was all about implementing the execute() method. Since it’s relatively trivial Java code, it’s not relevant to go through it here. As code without a test doesn’t exist, I made unit test for my MOJO. Using EasyMock and its class extension in addition to PowerMock I was able to test the functionality. Also let’s not go into further detail with that since it’s completely off-topic and the Internet is full of great tutorials regarding that. You can always take a look at my implementation details on SVN.

Basically the job was now done, all there was left was the project administration. I chose Google Code as the project hosting platform and SVN as the version control system. I’ve setup these to the plugin’s POM. The nicest thing I found out was that I can use the SVN repository as a Maven repository and even deploy to there using the deploy plugin. How to do that is described in here. Now I’m off to making the first release of my plugin. I hope you find the plugin useful, or even better this article useful!

The home of maven-merge-properties-plugin at Google Code

Eclipse 3.5 Galileo and Classic Update

This is an update of my older post. Some update sites like the Galileo Discovery Site or Eclipse Project Updates doen’t seem to be compatible with the classic update due to them being solely P2 repositories. I keep getting: “Network connection problems encountered during search” when trying to get the plugin list from any those. Otherwise it seems to work well. Getting some of the Eclipse default plugins from other repositories was bit of a pain-in-the-ass, but after some manual labor the plugins started installing nicely.

Eclipse plugins are extremely cool, but the way they’re being configured in Galileo (Eclipse 3.5) seems unsuitable for my needs and makes transferring the configuration to another environment difficult. The “new new” software update doesn’t allow you to specify different install locations for different plugins, which is the case I’m after. Galileo – like Ganymede – also includes the “Classic Update”, but in most of the installations it’s not available. In Classic version you can enable it from Window -> Preferences -> General -> Capabilities.

In reality, enabling that manually is quite simple, just browse to WORKSPACE/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.workbench.prefs and add a new line containing:

UIActivities.org.eclipse.equinox.p2.ui.sdk.classicUpdate=true

That’s it, now you have both the new and classic updates available.

I use the classic update for installing plugins to a directory other than eclipse/plugins. I’ve been installing for example JDT to eclipse/extensions/jdt folder. The advantage from this is that when a new plugin breaks your whole installation, removing it is a lot easier. Also transferring the installation to another computer or a different Eclipse version should relatively easy.

Due to more and more plugin repositories supporting only P2, the classic update will become quite unusable in the future, so enjoy while you still can!

Flex Builder and Maven: Part I – Simple SWC Project

I’ve fallen in love with Maven, which is a powerful tool for project (in sense of the environment in the computer) handling.

I’m doing lots of Flex stuff and Maven – though designed for Java environment – works for that too. Using Maven in a Flex project requires a Maven plugin capable of compiling the AS3/Flex sources to a SWF or SWC. While Adobe has rejected the idea of releasing official Maven support plugin they recommend using the most actively developed and probably the best one of the available alternatives, Flex-Mojos.

From this on I assume that you know the basics of the Maven POM. In this part I’ll describe how to use Maven and Flex-Mojos to create a Flex Builder Flex library project. Since Flex-Mojos is under heavy development so we’re using 3.1-SNAPSHOT version of it, so some of the mentioned things might be outdated or fixed soon (as of March 22th 2009 they aren’t). In addition we’re using Flex 3.3.0.

Since Maven projects are based on the POM, a Flex project requires some modifications there. First of all, we need to change the packaging to SWC:

<packaging>swc</packaging>

Apart from that we need the dependency to Flex framework. That is found in Sonatype public repository:

<repositories>
    <repository>
        <id>sonatype-flex</id>
        <url>http://repository.sonatype.org/service/local/repositories/flex/content</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>com.adobe.flex.framework</groupId>
        <artifactId>flex-framework</artifactId>
        <version>3.3.0.4852</version>
        <type>pom</type>
    </dependency>
</dependencies>

The last thing we need is the Flex-Mojos plugin which does all the hard work. It’s also found in the Sonatype repository:

    <pluginRepositories>
        <pluginRepository>
            <id>sonatype-flexmojos-snapshots</id>
            <url>http://repository.sonatype.org/service/local/repositories/flexmojos-snapshots/content</url>
        </pluginRepository>
    </pluginRepositories>

    <build>
        <sourceDirectory>src/main/flex</sourceDirectory>
        <outputDirectory>target</outputDirectory>
        <plugins>
            <plugin>
                <groupId>org.sonatype.flexmojos</groupId>
                <artifactId>flexmojos-maven-plugin</artifactId>
                <version>3.1-SNAPSHOT</version>
                <extensions>true</extensions>
                <configuration>
                    <includeClasses>
                        <class>com.googlecode.phlecks.example.Foo</class>
                    </includeClasses>
                    <includeFiles>
                        <param>foo.png</param>
                    </includeFiles>
                    <enableM2e>false</enableM2e>
                </configuration>
            </plugin>
        </plugins>
    </build>

Above we first specify the source folder which is src/main/flex instead of src/main/java. In includeClasses we specify the classes to be included in the library. Similarly we specify the other assets to be included in includeFiles. Also we specify that we’re not using the m2eclipse Eclipse plugin, in case you use that, feel free to set this to true.

Now we’ve got a POM for our Flex library project, the next thing is to generate the Flex Builder project files with the plugin. So we type:

mvn flexmojos:flexbuilder

And as the result our project becomes a Flex library project also in Flex Builder after refreshing. If take a look at the project’s properties and Flex library build path we see that in the classes tab src/main/flex is specified as the main source folder. In library path we notice that most of the Flex framework libraries are load from the local repository.

Also we notice that the current Flex-Mojos snapshot doesn’t yet implement adding the includeClasses or includeFiles to the library, the output folder is still bin-debug and in the source path tab src/main/flex is also added as an additional source folder outside the main source folder. These are smallish issues in the snapshot version, I’ve supplied the Flex-Mojos team a patch which fixes these.

So, now we’ve got a mavenized Flex library project that compiles in Flex Builder in the same way it would do if it was a Flex Builder created project. We can also compile it using Maven command:

mvn package

Which creates the SWC file, which is almost the same as the one created by Flex Builder. I think we’re done by now, here‘s the link for a sample project configured this way.