The Twitter web interface allows you to take a look at older tweets in bunches of about a twenty each. And every time you want to fetch a new batch you have to click on the large “more” button. Which in turn often brings up the message features in this blog post’s title.

I’m annoyed as hell by this of course, but it also gives me the opportunity for a little analysis that will end in the conclusion: Twitter will fail (unless they take some spoons of Tech Clue and change radically, that is).

What’s behind the little error message? You can’t really say for sure what happened, but since these errors occur pretty randomly it’s probably just that their servers are very busy right now.

Plus Twitter is notoriously known for having problems with scalability. For roughly the last two years, in fact. If you ask me they must be pretty clueless about scalability issues. To my knowledge their last action to solve this was to switch to another programming language (Scala). This approach seems to be motivated more by the name of the language than the actual benefit derived from switching to it. I don’t know if they have made the switch yet or whether they changed their strategy, but chances are their scalability problems won’t be solved at all with this.

The only thing that could cure their scalability worries would be a proper protocol for distributed twittering. There are suitable and proven distributed protocols like XMPP. You know, that’s the thing the Jabber instant messaging network is built on. And Google Wave too. This is quite a clue on the ability of Wave to supersede Twitter. Instead the latter ones are wasting their time with fruitless efforts. Come on!

This is made worse by the sheer simplicity of their application. I mean, in one of my projects I’m the sole developer of a complex game application. It’s understandable that I can’t be all things for all people, and scalability is just one of many problems. But what the hell are they doing all day at Twitter? They have 29 employees right now (source: TechCrunch)! Are they all busy keeping the list of top tweets fresh, or making Excel diagrams to please their VCs?

What’s your opinion on Twitter, scalability and the future of micro-blogging?

In the last few days I especially noticed that hg is faster for me than git (even after repack of the git repository).

That said, git has some very cool features that are missing in Mercurial.
Two of them are local branches (helpful for feature development or bug isolation) and the stash command that lets you stash away local changes for later (sort of a simplified patch queue).

Fortunately there are two extensions that provide both local branching and stash functionality.

Localbranches extension

Wiki page

http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches

Repository

http://hg.kublai.com/mercurial/extensions/localbranch

Shelve extension

Wiki page

http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension

Repository

http://freehg.org/u/tksoh/hgshelve/

Installation

To use an extension just clone the repository and put the following line into the [extensions] section of your hgrc (create file and section if necessary):

EXTNAME=/path/to/EXTNAME.py

Usage examples are on the wiki pages.

Happy hacking!

Fortunately the PEAR project has a set of excellent (well, as close to excellency as PHP lets you get…) libraries for all sorts of purposes.

The only thing with them is that they have problems managing their releases. The main site of the popular HTML Quickform library sports a fat warning sign, claiming that this package had been superseded by the aptly named HTML QuickForm 2 package.

That’s funny, because most if not all other packages depending on QuickForm are still built for the old version. Even more funny is what a vanilla install of the PEAR package tool will throws at anyone attempting to install QuickForm2:

% sudo pear install HTML_QuickForm2
Failed to download pear/HTML_QuickForm2 within preferred state "stable", latest release is version 0.2.0, stability "alpha", use "channel://pear.php.net/HTML_QuickForm2-0.2.0" to install
Cannot initialize 'channel://pear.php.net/HTML_QuickForm2', invalid or missing package file
Package "channel://pear.php.net/HTML_QuickForm2" is not valid
install failed

Now take into account that this situation has been in place for at least one year. Not really a role model for a sane software development release process.

Evidence B: Structures_Datagrid and a bunch of other packages are also marked “beta” but have been used by the majority (I daresay) of developers without any problems over the course of the last dekamonths.

What gives, PEAR?

It looks pretty clean even to me, not being a Haskell programmer.

Who’s up for it in Common Lisp? :)

Very useful for testing local mail emitting routines.

Usage: download, extract, quickly edit the configuration files and execute bin/mail.sh.

Thanks, Eric!

:%s/FOO/BAR/g|:up

The pipe | lets you separate multiple commands and :up is like :w but only writes changed buffers.

Now for all open files:

:bufdo :%s/FOO/BAR/g|:up

Roughly translates to: for all open buffers, substitute FOO with BAR and write the changes.

Personally I feel that there’s a need for either a full-featured vi written in Common Lisp (no, not GUI-only and written in Python, sorry) or a vi mode for Emacs that is consistent and also full-featured.

Until then you have several possiblities, most of which have been devised pretty recently:

• Nekthuth uses the Swank/Slime model with a library on the Lisp side and a Python scripted Vim plugin on the editor side. It offers a bunch of good things, but I haven’t tried it, yet.
• Limp seems to be the current star among Vim/Lisp bridges, with an active community. I’m going to try this soon.
• Like Slime for Vim is a solution that relies almost solely on GNU Screen. No Hyperspec lookup or function completion without additional work, though.
• Use some additional hints for a comfortable setup.

These approaches have varying implementation support. You’re always fine with SBCL, but Nekthuth, for example, doesn’t support other implementations.

I’m currently using the plain rlwrap approach but I might take advantage of some other approach soon.

How old were you when you first started programming?

Ten or eleven.

How did you get started in programming?

Read books about it, peeked at other people’s code, got in front of a computer, started hacking. :)

What was your first language?

BASIC.

What was the first real program you wrote?

A BASIC program calculating the Least Common Multiple of two integers.
On paper.

What languages have you used since you started programming?

BASIC, Turbo Pascal, C, C++, Java, C#, Common Lisp, Scheme, Bourne Shell, Awk, Perl, x86 Assembler, MIPS Assembler, TeX, JavaScript, PHP, SQL.

What was your first professional programming gig?

Depends on what you’d call “professional”.

When I was about 15 years old I wrote a dBase3 to CSV converter in Turbo Pascal for which I received 20 DM (about 10 EUR).

If you knew then what you know now, would you have started programming?

You bet.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Don’t be content with your skills and work. Critically examine your own and others’ results.
Push your limits, push, push, push.

What’s the most fun you’ve ever had … programming?

Me and a friend hacking up a space game prototype with GCC and Allegro at night. I slowly discovered the joys of GNU/Linux and free software at that time.

Writing a boot loader in Assembler.

Letting creative impulses flow into Lisp code with little hindrance.

Who’s next?

Michael Prinzinger
Stephen Compall

I’d also tag Sebastian Heberer but he ain’t got a running blog right now.

• Git: Jeez, everyone seems to like this one. While I might agree that it’s powerful stuff, I do not wish to spend weeks figuring out the innards of my RCS. I got things like work to do, you know.
• SVK: SVK is a hack to make SVN distributed. ‘Nuff said.
• Monotone: Easier than Git, and does the job. But still too much boilerplate.
• Bazaar: Does the job, but is a little conservative in its approach.
• Darcs: Best candidate for me, were it only more performant. Importing the Yahoo! User Interface library takes ages and load of memory. No user-defined hooks and nested repositories either. Sorry. But still great for small projects.
• Mercurial (hg): Easy to get started with. Nested repositories. Fine-grained control over user-based hooks.
  Extensions for everything (e.g. cherry picking, selective recording).

Darcs is my personal favorite, but it’s not possible to manage bigger projects with it, and you can hardly automate deployment or testing without hooks. Plus, certain virtualization software has problems with GHC’s memory allocation.

So I’m going to stay with Mercurial. See also this comparison between Darcs and Mercurial.