This blog has moved to javanto.com/blog. See you there!
Fixing Mozilla Thunderbird Icon in Unity, Docky, GNOME Do and Indicator
Published May 5, 2011 Linux , Ubuntu Leave a CommentTags: Docky, Gnome Do, Mozilla, Thunderbird, Ubuntu, Unity
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
Published January 19, 2011 Web Leave a CommentTags: CSS, HTML, web design, XHTML
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
Published October 20, 2010 Cloud , Programming , Ruby Leave a CommentTags: cloud, HashFresh, Heroku, Ruby, Ruby 1.9.2, Sinatra
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
Published July 25, 2010 Eclipse , Java , Maven , Programming 13 CommentsTags: 3.6, AppEngine, Eclipse, GAE, Google App Engine, Helios, Maven, Maven 2, mvn
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
Published January 26, 2010 Eclipse , Java , Maven , Programming 22 CommentsTags: App Engine, AppEngine, archetype, Eclipse, GAE, Google App Engine, Guestbook, Maven, Maven 2
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
Published December 25, 2009 Eclipse , Programming , SCM 3 CommentsTags: CVS, Git, Hg, Mercurial, SCM, Subversion, SVN, version control
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!


