Moving blog to Posterous

Gave Tumblr a go since it’s super duper easy but I guess it’s just a little bit too easy.

Some things that made me leave tumblr:

• Bogus search results. Searching for “css” on tumblr: 0 results. Searching through the same, imported, posts on posterous: 4 results. It’s really broken.
• Very limited browsability. On tumblr, you can not browse posts through tags, in fact, you can’t see a list of all tags used.

Some things I will miss:

• The admin GUI, clean and optimized for quick publishing. This actually concerns all of the tumblr UI, great work
• The bookmarklet, it’s great
• Getting an email response for each support question after a couple of hours tops (still waiting for a couple of responses @ posterous)
• The themes

… hopefully I’ll be staying at posterous for a while, otherwise I guess it’s wordpress’ turn.

Cheers and welcome in to

iamnearlythere.posterous.com

tail -n 0 -f /var/log/…

Wow, just discovered the -n 0 argument of tail, making it

tail -n 0 -f /var/log/lighttpd/php_error.log

Now I finally get an empty/clean start of tail.

Leaving out (pdf)

… or rather - welcome in, pdf!

I just posted a link to a pdf and named it Title of important document here (pdf).

Is that really necessary anymore? As a Google Chrome user, I don’t really have to bother checking the target of a link anymore because of the built in PDF-reader. It deserves so much cred, it’s unbelievable.

PDF used to be unbearable in web context, now it’s like any other page. Huge thumbs up for making us leave out the “WATCH OUT, PDF INCOMING” warning at each link (ok, starting now..)

Redmine and lighttpd got into a brawl, came out as friends

So much for the easy setup of Redmine, our server gazed at me with a 500 Internal Server error the following monday morning.

To track down the error, I started out by tailing Redmine’s error log that I previously defined in /etc/lighttpd/lighttpd.conf, showing:

$ tail -f /var/log/lighttpd/redmine_error.log
2010-12-20 12:09:04: (mod_fastcgi.c.2582) unexpected end-of-file (perhaps the fastcgi process died): pid: 6425 socket: unix:/tmp/redmine.socket-0
2010-12-20 12:09:04: (mod_fastcgi.c.3367) response not received, request sent: 909 on socket: unix:/tmp/redmine.socket-0 for /dispatch.fcgi?, closing connection                                                                          
2010-12-20 12:09:04: (mod_fastcgi.c.1734) connect failed: Connection refused on unix:/tmp/redmine.socket-3
2010-12-20 12:09:04: (mod_fastcgi.c.3037) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1

What I did to solve it was (after some googling) to change the lighttpd conf setting for Redmine’s socket from /tmp/redmine.socket to /tmp/lighttpd/redmine.socket. Before I could do that, I had to

$ sudo mkdir /tmp/lighttpd
$ sudo chown -R www-data:www-data /tmp/lighttpd

to make sure it was going to be writable. Restarting lighttpd after that seems to have solved the issue, permanently I hope.

Installing Redmine on Ubuntu and lighttpd

I just finished the installation of the project tool Redmine and will be enjoying using it soon.

However, the official installation hints were far from good, in fact, they previously led me to an aborted installation session. Really annoying.

Instead, I used the perfectly concise and error free guide called:

Redmine 0.9.3, Ubuntu 9.10, Lighttpd 1.4.x, MySQL 5.1.x - jonathanrobson.me

The only diversion was that I installed the 1.0.4 version of Redmine, which seems to be the latest one.

New dev area with gitweb

I’m currently setting up a new dev server at work. This includes hands-on work such as writing PHP organized in namespaces, but at a more technical level, modifying lighttpd and installing lots of packages on a Ubuntu server.

The dev server which is being deprecated is equipped with svn & trac, which has been really nice, especially for browsing the source code, code reviews and managing tickets, so the goals are set for this new server.

Gitweb will correspond to the demands for viewing source code, diffs and branches. Installing it and getting it up on lighttpd was a breeze, thanks to the guide How to setup gitweb with lighttpd on Ubuntu - jonathanrobson.me.

I used his config with some tweaks. The $projectroot variable in /etc/gitweb.conf now points at a directory which has a clone of each of our reposes. I.e.

$ cd /home/git/projects

if /home/git/projects/ is where you store all of your repositories, in a common place as a base for your dev or stage area. Read my entry Using git init —bare for a slim repository look for a directory layout that works.

If you followed my approach,

$ ls /home/git/projects

should only consist of directories called project-1.git, project-2.git and so forth. This is ideal for gitweb, which prefers to have a single directory to check for git repositories. (Check jonathanrobson’s link above for the whole shebang.)

Bonus feature: styling

There’s a github repository on https://github.com/kogakure/gitweb-theme which has an easily installed theme that looks much better than the original bundled with gitweb.

Trying out closure

Very easy way of minimizing a few bytes of every request using Google’s Closure Compiler which is a java program for compressing javascript.

$ curl -0 http://closure-compiler.googlecode.com/files/compiler-latest.zip
$ unzip compiler-latest.zip -d ~/Applications/closure-compiler ; cd ~/Applications/closure-compiler
$ echo "// A simple function.
function hello(longName) {
  alert('Hello, ' + longName);
}
hello('New User');" > hello.js
$ java -jar compiler.jar --js hello.js --js_output_file hello-compiled.js
$ cat hello-compiled.js
function hello(a){alert("Hello, "+a)}hello("New User");
$ wc -c hello.js
101 hello.js
$ wc -c hello-compiled.js
56 hello-compiled.js

Rinse and repeat

$ curl -0 http://closure-compiler.googlecode.com/files/compiler-latest.zip

Download the good stuff

$ unzip compiler-latest.zip -d ~/Applications/closure-compiler ; cd ~/Applications/closure-compiler

Locate the executable in a standard location and go there

$ echo "// A simple function.
function hello(longName) {
  alert('Hello, ' + longName);
}
hello('New User');" > hello.js

Create a file with valid javascript in it

$ java -jar compiler.jar --js hello.js --js_output_file hello-compiled.js

Use the recently unzipped compiler.jar to take input from hello.js and generate its optimized version at hello-compiled.js. Note that there’s only one file to use, compiler.jar. Usable.

$ cat hello-compiled.js
function hello(a){alert("Hello, "+a)}hello("New User");

Dump the contents of the newly created file, just to verify what a minified javascript file could look like

$ wc -c hello.js
101 hello.js
$ wc -c hello-compiled.js
56 hello-compiled.js

Comparing bytes in each file shows almost 50% winnings, both in terms of lowering the storage needed but also for each request of that file.