« November 2007 | Main | January 2008 »

December 31, 2007

Chicken Pox

My oldest kid has chicken pox. It started showing up last friday.

For bonus points, and given that I never had it, I also started getting the symptoms saturday night and by sunday, it became official.

I'm also laptop-less, so my only Mac is at the office.

This all means is that I'll be reading a lot of books in the next 5 to 6 days, and that my mail reading will be mostly non-existing. Same goes for RSS feeds. All I can use right now is things with Web interfaces.

So have a nice week and a happy new year. My festivities will involve lubricating myself in gels to prevent scratching, something that some of you might find exciting.

December 27, 2007

Sapphire

The best Apple TV plugin, Sapphire, is now open source.

Very cool.

December 21, 2007

£ 1,950,000

That's how much Amazon payed for the copy of the The Tales of Beedle the Bard by J.K. Rowling. The proceeds will be donted to The Children's Voice campaign.

Ttobtb 07. V1302598

The book is beautiful. Scroll down and see all the pictures.

Compiling git on Mac OS X

I had to install git on my temporary G4, and I didn't kept proper notes before, so for future reference, here is my way of compiling git.

This was tested on 10.4.11. I haven't upgraded to 10.5.x yet, maybe when 10.5.2 comes out.

I don't use MacPorts or fink, I don't like them. Its a personal thing, and if you do like them, you might as well use them instead.

First, let me tell you that I keep several git versions around. I install them in /usr/local/git-VERSION and switch a symbolic link at /usr/local/git to point to the version I want. Also, when I compile directly from a git checkout, I use the SHA1 of the HEAD as my VERSION. My PATH includes /usr/local/git/bin to find the latest version.

Second, I haven't bothered yet to compile asciidoc, so I don't compile/install the documentation.

Compiling the released version

Download the latest version of git from the git home-page.

mkdir ~/src
cd ~/src
GIT_VERSION=1.5.3.7
curl -O http://kernel.org/pub/software/scm/git/git-${GIT_VERSION}.tar.gz
tar zxf git-${GIT_VERSION}.tar.gz
cd git-${GIT_VERSION}
./configure --prefix=/usr/local/git-${GIT_VERSION}
make all

If you get a compile error, something like:

    SUBDIR git-gui
    MSGFMT    po/de.msg make[1]: *** [po/de.msg] Error 127
make: *** [all] Error 2

It means that you would need to compile GNU gettext to get msgfmt. Just do:

export NO_MSGFMT=1
make all

and it will use a alternative TCL script instead. According to pfig, 10.5.x does not need this export at all.

To install:

sudo make install

Now, create a symlink:

sudo ln -s /usr/local/git-${GIT_VERSION} /usr/local/git

And add /usr/local/git/bin to your PATH:

echo 'export PATH=$PATH:/usr/local/git/bin' >> ~/.bashrc

Make sure you have the new PATH:

exec bash --login
git --version

Now go play with it.

Living on the edge

But I don't stop here. The stock version of git is fine, but I usually use the master branch. So after you gone through all that, you do it again.

I keep a clone of the git master branch and update it from time to time. To clone the first time, do:

mkdir ~/projects
cd ~/projects
git clone git://git.kernel.org/pub/scm/git/git.git

If your firewall doesn't allow outgoing TCP on port 9418, try:

git clone http://www.kernel.org/pub/scm/git/git.git

You only need to do this steps once. From then on, whenever you want to update to the latest git, do:

cd ~/projects/git
git-pull
make distclean
GIT_VERSION=`git-show | head -1 | cut -c8-`
# I should be able to do GIT_VERSION=`git-show --pretty=format:"%H"`
# but I could not get it to work...
autoconf
./configure --prefix=/usr/local/git-${GIT_VERSION}
export NO_MSGFMT=1
# See above why export NO_MSGFMT=1
# You can try without it and use it only if it fails...
make all
sudo make install
sudo rm -f /usr/local/git
sudo ln -s /usr/local/git-${GIT_VERSION} /usr/local/git
git --version

That's it. You should be using the latest git available now.

December 20, 2007

cpan tricks

Our beloved cpan command line has some tricks up his sleave. In case you haven't read the fine CPAN manual in a while, let me point out some features I'm using right now to install all the needed modules for my day-to-day operation.

cpan .

You have a local directory with a module already unpacked, or your own personal module. The usual way to install them is doing the dance:

perl Makefile.PL
(manually deal with missing dependencies here)
make
make test
make install

The second step, the missing dependencies part, is the not so good part of the whole experience. Module::Build authors and users would suggest that the first step is the really not so good part, but I digress.

A better way is to do:

cpan .

This will start a CPAN shell, and run the install process on the local directory, including fetching dependencies from you preferred CPAN site.

failed command

Inside the shell, after you installed a long list of modules, the failed command will list all the modules that failed the tests and did not install.

o conf init /REGEXP/

The command o conf init will go through the entire configuration process. In recent versions it has become a long process and one of the things I tweak from time to time, the URL list of CPAN mirrors, is the last item asked.

To speed up the process you can o conf init /urllist/ and only configuration options matching urllist will be asked.

Don't forget to o conf commit at the end.

The smart CPAN urllist

The urllist parameter lists the CPAN mirror sites that the shell will try to use to fetch the packages.

My favorite site is a local CPAN::Mini mirror, the best 750Mb used space I have on my systems. It allows me to install any module from CPAN even when I'm offline.

But this requires that I keep updating the mirror, and sometimes, I just forget. And I don't want to cron it because I don't want to run it while I'm connected via UMTS.

A trick here is to set urllist to several CPAN mirrors in your country and include your local CPAN::Mini mirror at the end with a file: URL.

CPAN is smart and will fetch the CPAN indexes from one of the sites (see o conf init /random/ for some fun) but will always try to download the actual package from the file: url first.

So you get up-to-date indexes for free.

5.10

Just a quick word pointing out that perl 5.10 was released the 18th, 20 years after the first perl release. As Grubber says, Perl is the best language in the world. At least to both of us.

The 5.10 release adds a lot of improvements to Perl over the 5.8.x series. I would recommend that you take the time to read through perl5100delta, it should take less than an hour, but its definitively worth it.

My list of favorite features, in order:

The first will make DBIx::Class, Catalyst, and Moose faster and the second provides a clean path to add new features in future versions of perl.

The third is just too cool for words. You have to see it in action. It's a back-port of a Perl6 operator. As always, Perl has no shame to copy from the [rb]est, even from projects still in development.

The last one brings perl on par with other engines out there, and adds a nice non-recursive implementation and other performance improvements.

Congratulations to all perl-porters out there.

Just what I needed...

... a 18 months old kid with a death wish.

My youngest soon though that my iPod 5G was thirsty, so he offered it a bottle of water. The iPod was stupid enough to accept it, and now, not only I'm out of a Macbook Pro, I'm also iPod-less.

Merry Christmas to me!

PS: anybody going the the US soon? I have a order for you!

SSHKeychain `Buggy password in keycahin workaround` error

If you upgrade SSHKeychain to 0.8.2, and start seeing

Buggy password in keycahin workaround

in Console.app (btw, it really is spelled keycahin in the source :) ), then go into Keychain Access and remove all SSHKeychain entries.

Problem solved.

Back to G4

While my Macbook is in the shop, I "borrowed" my sisters Mac Mini G4.

Oh, G4, how much I loathe you... Let me count the ways:

cd ~/src/some_software && time make

Update: for future reference - starting a Catalyst app I'm working on, it takes 17 seconds. Previous Macbook Pro: 2.

December 18, 2007

Fluid

With three quick releases, Fluid has been getting a lot of attention. Given that it is Leopard only, I haven't tried it yet, but looking at the feature list, it doesn't seem to offer much more than Prism, Mozilla Labs version of the same concept (on which Fluid was inspired).

The best update so far was 0.3 adding auto-updates via Sparkle.

My take on Prism and Fluid, is that they don't go far enough. This is just a clever way to run a browser with a customized homepage, in a different process space. Its nice, but not good enough.

To really be helpful, I would suggest a couple of features:

  • Webapps should be able to replace the Menubar with something specific to them, including keyboard shortcuts. Selections of menu items should be forward to the Webapp via Javascript events;
  • Include some sort of offline plugin by default. I would suggest Google Gears just because its the most complete right now;
  • New DOM objects to generate Growl notifications;
  • New DOM objects to access Address Book and Calendar APIs: when a application tries to access those APIs, access would have to be approved.

I also though of including a AppleScript bridge in that list, but I'm not a big user of AppleScript, so I'll leave it out for now.

Decisions

So I need to decide what to do with my broken 17" laptop.

I'll try and see how much would it cost to fix this, but replacing a LCD is always the most expensive operation.

If I have to buy something new, I'll probably won't buy a Macbook Pro again. I spend a lot of time in the office now a days, so I can work on the road with a smaller laptop.

A combo of a low-end iMac plus a low-end Macbook is cheaper than my Macbook Pro 17", anyway.

I'll wait for Macworld 2008 (less than a month away) to decide. Time to put my APPL gains to some good use, I think.

Not in a good mood, however...

December 16, 2007

Panic...

Ok, time to panic.

My laptop LCD is going bonkers.

A ruined laptop is something I do not need now.

Update: yep, I'm severely fsck'ed. The lower half of the LCD on my 17" Macbook Pro is berserk. Running with external LCD for now, while I decide what to do. Happy Christmas to me.

Update 2: Left the laptop at the most recommended Authorized Apple support shop. Hope to hear from them today. It appears that its just a loose cable, because if you wiggle the LCD, the screen shows up perfectly. However, a loose cable is not something that you easily swap apparently.

Update 3: Out of warranty, I'm afraid. Apple gives you 1 year (no AppleCare in Portugal), Portuguese laws give you 2 years if you bought your computer as an individual but mine was bought by my company, and in that case, you only get 6 months.

I'm waiting for a call to know how much does it cost to buy a new LCD for the 17". I'm don't expect a good deal, so I think I'll be counting the days until MacWorld 2008.

In the meantime, I'm using a Mac mini G4 (oh the pain...) and a friend is going to lend me a Mac mini Intel.

I guess its time to try Mac OS X Server running on the Macbook Pro.

Update 4: over €800 for the new LCD. I'll wait until MacWorld 2008 to decide the next step then.

December 10, 2007

Sheesh

Talk about targeted advertising...

Stoned-1

(via Worse than Failure)

Three letter salute

In RFC: Dropping namespaces:

I still have not heard any good reason why namespaces in the current implementation are actually useful - or what particular case they solve... so I am wondering, are they really useful? I come now to the conclusion that they are not, and for myself (and most likely my work projects) I would have to decide not to go with namespaces, but instead stick with the 3 letter prefixing. Something that I have totally no problem with, as it is nice and easy.

The design of PHP6 has very smart proposals...

(via chromatic)

December 09, 2007

Drought

So it seems that a lot of usual friends are going away for a while.

I'm mostly concerned with BSG season 4. I mean, its the last season, it would suck big time if it didn't get back to production.

I don't need no stinking branches

A friend of mine was teasing me last week about my recent posts about Git, and wondered why am I using distributed Source Code Management (SCM) system for all my projects, even those where I'm the sole developer. He is not the first and I tend to have the same conversation with all of the ones who ask me about it.

Usually I start by telling them about offline-mode and the fact that I spend a lot of time off-the-net, which ends up being the least important reason.

Then I usually talk about the fact that I get backups for free because I can just push my work to far away servers.

But one thing gets the discussion a couple of degrees hotter: branches.

What I notice in these encounters is that they just don't do use them at all. And the reason is simple. Most of them used CVS and moved on to Subversion. With CVS branches where possible, and with Subversion, branches became easy and cheap. What both of them failed spectacularly at was merging.

There are situations where you branch not to merge "ever" again, like the maintenance or stable or stabilization branch approach. Those who look through a Subversion timeline of a project that uses maintenance branches will get accustomed to see commits in trunk with the cute message "Back-ported rNUMBER to trunk". What that means is that some changes in the maintenance branch where applied (not merged) to the trunk.

So now you have two commits exactly the same, one in the maintenance branch and one in the trunk, when you should have just one.

With care, you can use branches for real work, and merge to the trunk at the end. But in Subversion for example, you have to tell them what revisions you want to merge. So the branch is not an entity that you can manipulate. It's not a container. You, the developer, have to be the one that figures out what revisions need to be merged. And if you code a little bit more and want to merge again, you have to tell him to merge only the new revisions. And one side-effect of this kind of merge is that your beautiful history of the branch, explaining why things where done the way they where, is lost because the merge ends up as single huge commit.

You can play games with tags to help you. You tag the root of the branch with branch-root. When you need to merge, you just merge the differences between branch-root and branch. And then you'll tag the branch again with branch-last-merge-DATE, so that the next time you want to merge, you'll use the most recent branch-last-merge tag to compare the branch with. This works, I was doing this with CVS 5 years ago, but its painful.

So, with this lousy system of merge tracking, its no wonder that explaining the use of a different branch for each feature you develop and merge them into a staging branch for testing and then if all goes well merge that into the mainline branch for deployment, you get these eyes that say "Are you crazy??".

I'm not crazy, I just moved on. I refuse to be abused by inferior systems like CVS and Subversion no matter the following and success they have. Life is just to short.

Systems like Git and other decent distributed SCMs allow me to treat branches as containers of change-sets, containers that I can manipulate as a single entity and tell git-merge branch master repeatedly and have him "do the right thing" every time. It allows me to experiment new features without fear of messing up my repository, and knowing that if all goes well, merging back the changes will be easy. And if not I can always drop the branch.

So, if you decide to try one of these systems, please don't use it as a better Subversion. Make sure to abuse the new power, of branching, of merging, and split your work with topic branches.

The pasture is really greener on the other side of the fence, so hop over and grab a nice chunk of grass.

December 08, 2007

Learning Git

I'll be talking a lot about Git in the coming weeks. I'll update this post with the best references I can find about understanding, using, and maintaining Git and Git repos.

Understanding Git

Using Git

SVN deserters

Example project workflow's

I collect mail messages or URIs where project leaders explain their usage of Git, branch organization and merge policy. Some will be overkill for most of the projects I work on, but you can always tweak and simplify one of them to suite your needs.

General Reference

Git ramblings

December 07, 2007

Google Charts

The new Google Charts API is very very nice.

I still prefer Open Flash Chart for back-office use, but for front-end sites, this might be much better, given that it works everywhere.

One thing to take notice: there is a daily limit of charts that you can ask directly from Google, so if you think you'll use more than those, use a reverse-proxy with cache (like Varnish or Squid) or even have your code call Google API and cache the image locally.

Now, let's see how much longer we'll have to wait until we get a Perl module to generate those URLs. :)

Update: Google Charts API launched the 6th of December, Perl module Google::Chart the same day. Yeah, Perl is dead.

December 04, 2007

It's dead, Jim...

So after 6+ years of faithful service, my TiBook died just now, with a buzzing sound (not hard drive, somewhere in the upper right-hand corner of the logic board under the keyboard).

Dead TiBook logic board

I'll have to search around to see if this is something recoverable or not. I didn't have any important data on it, but he was the box that powered my third screen, as described previously.

Must... Resist... Buy... New... Mac...

Catalyst Advent Calendar

It's back! The new and improved 2007 Catalyst Advent Calendar. (Un)Fortunately its not a swim-suit edition yet.

The entry for today is about using the Open Flash Chart component, my favorite Flash-based chart component. It also uses the recent OFC::Chart module.

I just wish that the Calendar had a title attribute on each daily link. Finding the correct article can be painful without that.

http://host/file.txt#line=10

URI Fragment Identifiers for the text/plain Media Type: hope this gets approved. It would make source-code linking easy.

Facebook and decentralized identifiers

Nice write-up by Jens Afke about Facebook and decentralized identifiers.

I need a "link-blog"...

Favorite Leopard feature

If I had to choose one, it would be the support for message: URIs in Mail.app.

It allows you to:

  • send a link to a message to a friend: if he also got that message but "lost" it somehow, he can just click and let Mail.app find it;
  • you can store URIs to important messages on any other Mac application, and in a Cocoa app, just right-click to jump to it;
  • it allows interesting integration between web applications and your local mail client: it should be pretty simple for someone to write a "Open in Mail.app"-scriptlet that works inside GMail or others webmails.

I used to have MailTags installed just for this, but now, it just works out of the box.

I noticed this feature before but Gruber wrote a nice article about it that triggered my memory.

Git vs Mercurial

I've been talking about Git in the last posts, and Bär asked if I tried Mercurial.

I did try Mercurial, but very superficially. I used it with a project shared with Rui, who uses Mercurial and he seems to be very happy with it.

Whatever you choose, I would stick with either Mercurial or Git. CVS is dead, and Subversion is not good enough. And right now, all non-personal projects I work on use Subversion, so I have some experience with it. Of the others distributed systems, only Darcs, still the best out there in terms of day-to-day usage, deserves a honorable mention.

My take on Mercurial vs Git is this:

  1. when I started with Git, Mercurial was better if you need to run on Windows. Right now, Git has binaries available on the home-page but I don't do Windows, so I don't know if it is good enough, or stable enough. On Linux, Git just cannot be beaten in terms of performance. Update: Git seems to be doing fine on Windows now.

  2. I'm not comfortable with the code quality of Mercurial. I followed the Mercurial commit list for a month or so at the time, and some of the bugs where pretty nasty. It seems that Mercurial is still fixing core bugs. On the other hand, Git fixes in the past weeks are mostly cosmetic, and reorganization of code into a libgit. Also, the organization of Git release management is very conservative, and that feels good.

  3. I liked the GUI tools that come with Git better than those of Mercurial. I'm usually not a big fan of GUI tools to interact with SCMs but I admit that I've been using git-gui for all my commits. The history browser (hg view or gitk) are virtually identical (probably one of the projects "stole" the code from the other :) ).

  4. git-svn rocks my world. It makes working with Subversion less painful. Mercurial doesn't seem to have nothing as good.

In the end, there are big projects using either of them, so its no big deal. There are also tools to migrate repositories from one to the other, so I don't think there is much risk on any of those two.

I freely admit that I could choose any of the two, but the above 2), the need to keep on working with Subversion projects, and the fact that Git is used to manage the linux kernel, X.org, Samba and OLPC, made me trust Git more than Mercurial.

December 03, 2007

hunk-based commit with git-gui

I've being using git as a front-end to Subversion using git-svn (more on this later).

A cool feature that you just get for free is hunk-based commit. For those who haven't using Darcs, hunk-based commit allows you to select which parts of the diff you want to include. It allows for a much cleaner commit history.

With git, I've started using git-gui to create my commits. It's really useful. Inside, you can select a modified file, and then right-click the hunk you want to stage. Then, when you are happy with the staging area, type in the message, and commit.

I usually leave git-gui open, in the background, and have a Quicksilver shortcut to bring it to the front.

This setup works very well for me, and it almost makes me forget how much I miss Darcs.

(more info about git and hunk-based commit in this thread)

Importing HTML table into numbers?

I'm researching video cameras to buy one for Christmas. One of the requirements is support for iLife, and in particular, iMovie.

So I googled to see if I could find a compatibility list, and sure enough, we have technical article 306171.

The next step was filtering the table for HDD-based cameras. I copied the HTML table, fire up Numbers, and pasted it, and... WTF?? A single column of data? I fired up Excel and sure enough, pasting a HTML table produces a decent Excel worksheet, one that I can then AutoFilter and work with.

So unless I'm missing something obvious (not unheard of), Numbers just ignores the largest source of tabular data available, the Web.

Really smart...

Anybody has a quick AppleScript to import HTML tables?

Update: well, not a AppleScript, but Firefox. If you copy the table in Firefox and paste inside Numbers it will just work! Many many thanks to Jon Prettyman (via comments).

December 02, 2007

Perl preforce-to-git conversion

Very cool job by Sam, the current status of the Perl preforce-to-git conversion.

Preforce was indeed very advanced ten years ago.

The Eagle has landed

PEP was committed to the trunk of ejabberd. Probably the checking I was most anxious to see.

Facebook beacon

This last week, as I read through several posts about the Facebook Beacon, the only one word crossed my mind: lemmings.

And I was thinking on the people who own the sites that use the Facebook beacon, because in the end, they are giving their userbase for free to Facebook.

I think I'll just sudo sh -c 'echo 127.0.0.1 facebook.com www.facebook.com >> /etc/hosts'.

Update: a post by the Facebook CEO.