GitMon Quick Start Screencast

A screencast showing how to install GitMon in 5 minutes on a Mac.

GitMon 0.3 - Easy Install!

Since the last post GitMon has got many improvements, including the easy_install support (GitMon is hosted at Python Package Index), so to install it, simply do:

sudo easy_install gitmon

Then run gitmon from terminal and it will create a default configuration file for you (~/.gitmon.conf). Edit it and you're good to go!

Mac OS X users who have Growl installed can get it all working in 3 minutes. It will involve some additional configuration twiddling for Linux and Windows guys, but that will be improved in future releases.

GitMon - the git repository monitor

Dozens of git repositories? Want to know what's happening?

If you are actively using git (which you should, because it's awesome), you may have looked for a way to get those nice popup notifications when something is pushed to remote origin. When you have dozens of repositories to work with, it may get annoying to go through all of them and check for updates. I haven't found anything mature and worth using, so I decided to get my hands dirty...

And finally, after many joyful hours of coding... Meet GitMon - an open source git monitoring tool. Here's how it looks like:

You may have noticed that it's a typical Growl notification. GitMon can also be configured to use libnotify-bin on Linux and there is Growl for Windows which may do the job (I haven't tried that yet though).

GitMon Features (0.1.6):

• Configurable notifications via command-line tools (growlnotify, notify-send, ...)
• Scheduling via standard tools (like crontab)
• Support for multiple git repositories
• Possibility to give repositories custom names
• Possibility to notify about new branches
• Possibility to notify about new tags
• Configurable limit of new commits in notification
• Configurable limit of file details in notification
• Possibility to perform 'git pull' automatically
• Variables in configuration file
• Recursive file system scanning for repositories (configurable roots)

Installing GitMon

If you're willing to try it, there is no "next", "next", "finish" installation so far, so you will have to do this (shouldn't be too difficult to do for any developer):

1. Clone the repo:
Fire up the terminal and go where you want 'gitmon' dir to appear. Then do:

git clone git://github.com/spajus/gitmon.git

2. Add gitmon to path:
You may want to put this in your ~/.profile:

export PATH="$PATH:/path/to/gitmon"

3. Make sure you have growlnotify (Mac) or notify-send (Linux).
You can install notify-send command easily:

apt-get install libnotify-bin

4. Set up the configuration:

cp gitmon.conf.example ~/.gitmon.conf

Then edit ~/.gitmon.conf to suit your needs.

5. Make sure you have Python 2.6+ and GitPython:

python --version
easy_install gitpython

6. Test if your gitmon.conf works:

gitmon -v

A good output may look something like this:

GitMon v0.1.5
Loading configuration from /Users/tomasv/.gitmon.conf
Tracking repo: "GitMon Repo" at ~/Development/python/gitmon
Checking repo: GitMon Repo

7. Configure crontab:

crontab -e

Example:

#git must be in cron's path!
PATH=/usr/local/bin:/usr/bin:/bin
#check for repo updates every 5 minutes
*/5 * * * * gitmon

That's it. Now just wait for those notifications!

Roadmap

There is a small roadmap for future releases:
• Installation bundles for major operating systems
• Menubar / system tray icon
• GUI for configuration
• Integration with diff tools

Update!

I have just found Gitifier. Here's how GitMon and Gitifier notifications about same commit look next to each other:

XML Zen 0.2

After a long break a new version of XML Zen was finally released. It has several bug fixes along with some new features. The changelog:

Changes in version 0.2.0 (2010-08-15)

• Fixed a bug which prevented getting attribute values in some cases (Issue #11)
• Added a possibility to set some defaults for XmlBuilder (Issue #10)
• Added XmlBuilderOutput interface with String and OutputStream implementations (Issue #8)
• XmlBuilder builds formatted XML with declaration (if charset is provided) (Issue #9)
• File support in XmlBuilder (through XmlBuilderStreamOutput) and XmlSlicer (Issue #7)

I would like to thank JetBrains for IntelliJ IDEA license which was issued for this project. I’m trying to switch from Eclipse to IDEA, and so far I feel quite excited about it.

Compiling Java applications to native Windows executables

Being a Java developer really sucks when it comes to making end-user desktop applications. You want these applications to be light, fast and easily redistributable. Packaging a bunch of jars along with startup script is the worst thing you can do. It may work quite well in various Linux distributions, where you can make a .deb or .rpm which automatically installs JRE, puts startup script to /usr/local/bin and creates a nice launcher with icon in the applications menu. In Mac OS you can use that outdated JRE that comes by default and then easily bundle all scripts and jars into an .app. But in Windows it does not work that way. You can use JSmooth to make .exe out of .jar and use NSIS to create a nice installer, but there still is a problem. User may not have a compatible JRE, or he/she may choose not to have one just because Java sucks for running on it's bloated memory hogging virtual machine. I have to agree here. As a user, I have no faith in desktop applications that are written in Java.

So what is the solution? Compile to native executable and forget JRE. It is possible, but it will not be a walk in the park. First, you will have to get familiar with GNU Compiler Collection and particularly with GCJ.

Let's compile a Hello World application like this one:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello native world!");
    }
}

1. Get the patched GCJ here: http://www.thisiscool.com/gcc_mingw.htm (120 MB)
2. Extract it somewhere and add thisiscool-gcc/gcc-ejc/bin to your PATH
3. Compile Hello.java as Hello.exe: gcj --main=Hello -o Hello Hello.java
4. Enjoy your statically linked Hello.exe which prints Hello native world! and runs without JRE.

Wait. Hello.exe is 37MB? Holy crap! Well, it's a little overhead you have to pay for loosing the JRE, this .exe contains the whole garbage collection mechanism, etc. Also, you will be able to compile SWT GUI applications! It is possible to get smaller executables with MinGW tooling. Hello.java compiled with MinGW is about 3MB, but it has other issues, I couldn't manage to get the system output working. You may be more lucky though.

Anyway, when you compile native binaries, your Java code cannot be decompiled, so you have better protection than by using obfuscators. And the best thing is that end users won't complain that "it's crap because it's Java". They just wouldn't know.

I wish Sun (I just can't say Oracle when referring to Java, it makes me sick, sorry) could create an official AOT Java compiler so developers would not have to go through hellfire to make native executables.