First install ruby, gem and god.

apt-get install ruby, rubygems
gem install god

Then paste this initscript into /etc/init.d/god: got init script. Configure it to use /etc/god/config.rb for example, and there do some minor setup (using ruby, yay) so we can get emails if something happenes:

And then all that’s left to implement is a watch, so create an /etc/god/watches/xvbf.rb. It’s using a nice DSL to configure how God should act when a process dies etc:

The code is pretty much self explanatory. We watch if the process Xvfb is running, and if not, after the grace period we restart it. Optional info email could also be sent using the notify property.

That’s it, have fun automating your build environments!

As the Sidewinder is an Microsoft keyboard, it obviously does all it can to not work at it’s full potential on GNU/Linux systems ;-) What my script does is watch for usb events, using usbmon, then it filters it searching for events from this keyboard, and then it filters out the discrete keystrokes for them. When such keystroke is found, we launch an bash script located in actions/S##.sh which can then do anything you want it to do – fire up intellij, or send keystrokes. I’d advice the second idea – use xdotool to send keyboard events, which you then map in Intellij or Netbeans or KDE/GNOME. Such keycode send looks like this:

xdotool key --clearmodifiers ctrl+shift+F1

That’s about it. I also wanted to thank some guys on github, who found my project and it really helped them out :-) Just to cite my fav email:

[...]
I’m amazed to see that somebody made this keyboard work under linux, I was beggining to lose hope. Great job!
[...]

Thanks for the feedback, it’s what keeps me going with opensourceing projects like this :-)

Well, that was all nice and cool but git (other DVCS have this too) has a lot more to offer! :-) Today we’ll look into git bisect and how to automate it’s execution using maven to look for a commit that breakes something. You may run ANY SCRIPT and even write your own and git will use it to test if a commit is “bad” or “good”. Ok, but let’s slowdown a little… What git bisect basically does is performing an binary search, between a range of commits you specify looking for “the first bad commit” you you can easily find what caused the bug and fix it. You can drive it by hand and after starting git bisect just test the commit by hand and tell git if it’s good or bad by “git bisect bad” “git bisect good”. Git is smart enough to find what commit he should “git checkout …” next to perform a binary search based on your anwsers.

Today we’ll learn how to make git cooperate with maven and find the first commit that introduced a test failure. See bellow for the full workflow you showcasing this:

Ok up until now we’ve just created a simple repository we’ll be running the tests on. Let’s tag this state as “yeah it’s working here” just so that I don’t have to remeber the SHA-1 of this commit.

And now we’ll run a script that does some random commit action, just so that bisect has a lot of commits to work on.

The tests are still passing… time to change that! We’ll break the build with the following commit. And then generate yet another 50 commits to “hide it”… ;-)

Ok the test’s fail now. But suppose you didn’t know which commit introduced the bug (in our case made the test’s fail). You’d have to guess which one, or check them all or just work it out by looking at your current repository state. But since you’re doing small commits and do them often – it’ll be great if you found out which commit caused this failure. As it’s preferably small, it’ll be very easy to find out what change caused the build to fail. No is the time to use git bisect!

We’ve started bisect, and told him which commit we’re sure is working and which we’re sure is failing. Git will now checkout a commit he found “somewhat in the middle” and will continue to bisect (binary search) the commit history based on wether a commit is “good” or “bad”. We could just tell it git by hand by doing “git bisect good/bad” etc. But let’s git bisect run a script to do this for us :

Yeah, we’ve found our failing commit :-) You could use any script you want here, it just has to return 0 if git should think it’s a “good commit” and “not 0″ if it’s a “bad commit”. I’ve even seen runners written in PHP running or spellcheckers – you name it… :-) Ok but how does this magical script that we’ve just run look like?

Whoa, that’s simple… :-) Keep on git hacking guys! See you soon, with some more git or java tips… :-) Oh and I’ll post my presentation (holefully with video) from SFI soon, so keep an eye out! :-)

PS: Yup, the code retreat we’re (SCKRK with a little help from the PolishJUG) organizing got “sold out” after just 3h… ;-) Be sure to take a look and be quicker next time! http://coderetreat.sckrk.com

The code comes from http://arnorehn.de/cgi-bin/weblog_basic/index.php?p=34 so big kudos too him :-)

Cheers and happy hacking!

PS: I’m waiting for my T-shirt and stickers (for training participants) to arrive from github. I’d love they make it in time for SFI but I’m not sure if it’s even possible hmmm…

The G73 has an backlit keyboard, which may come in handy while late night coding without lights on as I like to code sometimes. (I’m using a X6 Sidewinder, even with this Notebook so it’s not like it’s keyboard matters to me most of the time ;-)) As usual with such “super cool addons” the funtion keys regulating the keyboard backlight seemed to only work on Windows – which I’m only using for gaming (but rarely) and testing if the software I happened to write runs ok on it. Anyways, turns out that the keyboard does really well integrate with linux, and you just need a few simple commands to use it, I’ve made them available on github :-)

https://github.com/ktoso/g73-keyboard-backlight-sh <- Go here to check it out :-)

So… Since I’ve started using git-svn at work, I do have an possibility to make things better now! The answer lies in client-side-hooks and git aliases (“custom commands”). First let’s write this as an simple bash script, that we’ll locate in the .git/hooks/ folder:
It’s a fairly simple script, so I wont bore you explaining it in detail – if in doubt, feel free to ask. We only need to place this script as “.git/hooks/pre-commit” and make it executable and git will take care of the rest for us. Oh and in case you’re wondering where that org.eclipse.jdt.core.prefs came from. It’s created by eclipse into the .settings folder when you check some option to “use formatter per project” – that’s the only time I had to fire up and click around in eclipse to get it’s formatter running “headless”. Ok, let’s check if it works…

Yup, you can agree or not with the formatting rules – but what matters is that the whole team decided on it and that we keep it consistent throughout the whole project. This hook will definitely help with this. :-) Step two for me was changing this into a git command, so that I wouldn’t launch eclipse each time I just do some quick local commiting. The solution is to drop the hook idea (although it’s quite nice) and create an custom git command. We do this by doing an alias like that:

git config --global alias.eclipse-formatter '!~/git-hook-eclipse-formatter'

The !command alias support is with us in git since 1.5.0 and it enables us to launch any program/script as an git command. Great, just what I wanted! Let’s now see what this command really did:

As you can see, adding an alias is as simple as adding it to your ~/.gitconfig or, if you want to setup the alias “per project”, to .git/config – pretty cool, ay? Also, this command will be included in bash-autocompletition suggestions! :-)

That’s it for today… happy hacking!

Yup, that’s basically it. You may also apply this directly in vim as I’ve showed here a few years ago and you’ll probably need to look some stuff up here or on this awesome sed guide.

aspell --lang pl dump master | aspell --lang pl expand | tr ' ' '\n' > polish.dic

You’ll have to install the polish aspell package of your distro of course before you launch this command ;-) Then just create an dedicated folder dor *.dic files and show IntelliJ to use it. Done – perfect spell checking in your IDE… and even while committing changes: http://blogs.jetbrains.com/idea/2010/08/no-more-misspellings-in-your-vcs-commit-comments/

memused

Sample output:
VPS memory usage:
Used: 296 MB
Total: 256 MB
Burstable to: 512 MB

memfree

Sample output:
VPS Memory:
Total: 256 mb Used: 302 mb (100%) Free: -46 mb (0%)

memheld

Sample output:
VPS Memory Usage
Current Held: 160.832MB
Max Held: 294.605MB
Barrier: 256MB

memps

Sample output:
ps axo pmem,pcpu,comm | sort
0.0 0.0 script
0.0 0.0 script
0.1 0.0 init
#...
2.2 0.0 httpd
4.0 0.0 mysqld
7.3 0.0 httpd
8.0 0.0 httpd
%MEM %CPU COMMAND

memprivmpages

Sample output:
privvmpages usage: 296 MB (57% of 512)
For those wondering, yes I do have memory usage above “100%” in the output of some of these scripts, and it’s partially true. A VPS does usually have some guaranteed memory, and some “burstable” – so you can use more than just the guaranteed memory for some period of time. On the mashine I ran this I have 256 guaranteed and a “total” of 512MB – including the burstable memory.

If you like any of these, feel free to use them. I use them by creating a scripts directory and adding it to the PATH, so I can simply invoke them from anywhere.

PS: For more detailed memory usage information (as graphs etc), I’m using Munin and really recommend it. The graphs it draws are really nice, and it doesn’t inflict heavy load on the server, and it can monitor remote hosts if needed!