published on 03.02.2013 15:27.

Why I really like the Slim template language

I recently discovered the Slim template language. My first thought was: why bother, HAML is already much better than plain HTML/ERB, so there’s really no point in learning yet another template language.

But I still find some things in HAML awkward or hard to remember, so I gave Slim a try on a recent project. Here’s what I found:

  • even less syntax noise, for example: no leading % for HTML tags, cleaner multiline
  • consistent, shorter attribute syntax (see the example here)
  • regular HTML is allowed in templates. Among other things, this helps converting ERB templates by hand.
  • slim/translator: no need to wrap I18n keys in = t(’.your_key’)
  • (claims to be) very fast.
  • after having used it for ~10 templates, there were no weird errors or stuff I couldn’t do.

The only downside I found is that there doesn’t seem to be a reliable HTML/HAML to Slim converter, yet.

You don’t have to actually learn Slim. The syntax is extremely similar to HAML: leave out %, (), {} and ”” in most places, and you get Slim. Where not, things can be looked up in the documentation just as quickly as for HAML.

Replacing HTML/ERB with HAML still is the biggest win, but Slim is the better HAML to me. I’ll be playing with it on a side project (shameless plug) and may use it from the start for the next big one.


Two real world examples:

Posted in ,  | no comments | no trackbacks

published on 15.08.2012 12:00.

Software idea: find what you read

Find What you Read

Intended to be hosted on your own private server on the internet (or internally, like a Protonet node), to make it accessible from everywhere.

Browser plugin
  • sends every viewed page to the server (data: url, and date viewed)
  • available for Firefox and Chrome
Server component
  • Indexes each document in a fulltext search engine
  • has a web interface which:
    1. list all indexed documents
    2. has a fulltext search
    3. has relevant facets (date read, domain, ... some would need to be generated)
    4. can group documents by semantic analysis
    5. can derive tags automatically
    6. knows which documents were read together and shows these
    7. document previews and screenshots
    8. normalization of tag variations: synonyms, ontologies, German/English tags

Later: add a browser plugin to do the same as the web interface.

See also:

Posted in  | no comments | no trackbacks

published on 03.08.2012 12:20.

Plenty of sharp knives.

> 22.12.2005
>"open class" is so strong (often too strong), we can break 
> things easily.  In other word, Ruby trust you to give you
> sharp knives, where Python don't.  From the Python point 
> of view, it's wrong, I guess.
>                                                matz.

Posted in ,  | Tags ,  | no comments | no trackbacks

published on 13.02.2012 12:58.

The value of readable code

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.”
—Tony Hoare, 1991

Posted in  | no comments | no trackbacks

published on 16.12.2011 19:56.

The origin of vi

<b>vi</b>: /V-I/, *not* /vi/ and *never* /siks/ n. 
[from `Visual Interface'] A screen editor crufted 
together by Bill Joy for an early {BSD} release. 
Became the de facto standard UNIX editor and a nearly
undisputed hacker favorite outside of MIT until the
rise of {EMACS} after about 1984. Tends to frustrate
new users no end, as it will neither take commands
while expecting input text nor vice versa, and the
default setup provides no indication of which mode
the editor is in (one correspondent accordingly 
reports that he has often heard the editor's name 
pronounced /vi:l/). Nevertheless it is still widely
used (about half the respondents in a 1991 Usenet
poll preferred it), and even EMACS fans often
resort to it as a mail editor and for small editing
jobs (mainly because it starts up faster than the
bulkier versions of EMACS). See {holy wars}.

LM:: What inspired you to write vi?
Billy Joy: What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the ed­itor we were using which was named ed. ed is certainly frustrating. We got this code from a guy named George Coulouris at University College in London called em - Editor for Mortals - since only immortals could use ed to do anything. By the way, before that summer, we could only type in uppercase. That summer we got lowercase ROMs for our terminals. It was really exciting to finally use lowercase.

LM: What year was that?
BJ: ‘76 or ‘77. It was the summer Carter was president. So we modified em and created en. I don’t know if there was an eo or an ep but finally there was ex. [laughter] I remember en but I don’t know how it got to ex. So I had a terminal at home and a 300 baud modem so the cursor could move around and I just stayed up all night for a few months and wrote vi.

LM: So you didn’t really write vi in one weekend like everybody says?
BJ: No. It took a long time. It was really hard to do because you’ve got to remember that I was try­ing to make it usable over a 300 baud modem. That’s also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow. 9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore. The people doing Emacs were sitting in labs at MIT with what were essentially fibre-channel links to the host, in contemporary terms. They were working on a PDP-10, which was a huge machine by comparison, with infinitely fast screens. So they could have funny commands with the screen shimmering and all that, and meanwhile, I’m sitting at home in sort of World War II surplus housing at Berkeley with a -modem and a terminal that can just barely get the cursor off the bottom line. It was a world that is now extinct. People don’t know that vi was written for a world that doesn’t exist anymore—unless you decide to get a satellite phone and use it to connect to the Net at 2400 baud, in which case you’ll realize that the Net is not usable at 2400 baud. It used to be perfectly usable at 1200 baud. But these days you can’t use the Web at 2400 baud because the ads are 24 kilobytes.

Peter Salus in his Open Source Library – Papers gives the following version of events: The original UNIX editor was ed. It was a line editor of reluctant and recalcitrant style. When UNIX (version 4) got to Queen Mary College, London, in 1973, George Coulouris - a Professor of Computing - wasn’t happy with it. So he wrote a screen editor, which he called “em,” or “ed for mortals.” Coulouris went on sabbatical to Berkeley, where he installed em on “his” machine. A graduate stu­dent noticed it one day, and asked about it. Coulouris explained. He then went off to New Jersey to Bell Labs, and when he returned to Berkeley, he found that em had been transmuted into ex, a dis­play editor that is a superset of ed and a number of extensions—primarily the one that enables display editing. At the beginning of 1978, the first Berkeley Software Distribution was available. It consisted of a tape of the Berkeley Pascal System and the ex text editor. The graduate student was Bill Joy, and the distribution cost $50. The next year Berkeley got some ADM-3a terminals, and Joy rewrote em to vi—a truly visual editor. In sum, ed came out of Bell Labs in New Jersey, went to Queen Mary College in London, from there to the University of California at Berkeley, and from there back to New Jersey, where it was incorporated into the next edition of UNIX.

Posted in  | no comments | no trackbacks

published on 31.10.2009 20:39.

NoSQL Berlin Meetup Notes

“The world is diverse. Act accordingly.”
—Prof. Dr. Stefan Edlich, in his talk on object databases.

Where do you store your data? In a relational database, of course. It’s so convenient to use the persistence store we are used to, which has been there for us since the day we started programming. But in the spirit of using the right tool for the job – and making our lives easier – it pays off to know other persistent storages—those which aren’t based on the RDBMS/SQL paradigma. They promise to be better suited for some of the problems we face day to day; mapping the real world to a persistent storage, scaling, and reliability being among them.

The NoSQL meetup in Berlin gave a great overview of this active and growing scene, and shed some light on the characteristics of the main tools. Here are some rough notes from the meetup. For the full monty, all video and slides of the talks are available at the NoSQL Berlin website. Thanks guys for the perfect organization!

Consistency in Key-Value Stores (Monika Moser)

The only talk which wasn’t about a specific database. It gave an introduction into the problems and solutions that we face when working with many database servers (nodes). Since the written data has to be distributed across many physical machines, there will be a noticable delay until every node has received the updated data—the replication lag. Only after the replication lag, all nodes will contain the same (=consistent) data.

Two types of consistency were distinguished: Strong consistency (updated data is immediately available to all processes in the system) and eventual consistency (at some point in time all processes will get the update).

Strong consistency is usually expensive to implement on larger systems and isn’t always necessary, so eventual consistency is often acceptable. Depending on the use case, one can go for one of these subtypes of eventual consistency:

  • “read your writes” consistency

The process that wrote the data will always get the latest data. Other processes may still get old data for some time.

  • session consistency

A special case of the above: only the session that wrote the data is guaranteed to get the latest data immediately.

  • monotonic read consistency

after one process has read the new data, all following reads get it. So once the new data is in the system, the old data doesn’t appear again.

Monika went on to describe the CAP theorem (choose 2 of 3 for your storage setup: partition tolerance, availability, consistency), the reasons strong consistency is expensive, and the Paxos algorithm (good trade off between fault tolerance and consistency). See the slides and video for details!

My personal summary of the talk: good overview with lots of pointers to further info. And I’ll care about the details I didn’t grasp when I first need them.

Redis, Fast and Furious (Mathias Meyer)

Redis is awesome, I heard someone say.

Oh … Redis is also like memcached, but with extra features: persistence, additional commands (increment values, sets, push/pop, sorting, a text-based simple protocol). It is also slower than memcache, but not so much you would care.

It is also like K.I.T.T., if you believe Mathias.

According to Mathias, Redis is put to good use when storing statistical data (as long as it fits in memory!) and implementing worker queues.

Peer-to-peer Applications with CouchDB (Jan Lehnardt)
  • Jan contradicted himself on the first slide. It read: “Relax.”. Then he started a 10_000 WPM (words per minute) presentation, that still managed to raise my interest in CouchDB again. The presentation was about the “what can it do” instead of “how to do it”. Good choice to go this way.
  • a nice explanation “CouchDB is built “of the Web””—REST, JSON and HTTP are core technologies of the database.
  • Learning curve: store full documents, not relations (JSON). No data normalization into tables => make developers happy, not computers.
  • meant to be robust: append-only design for the database file. on crash, old data is not damaged.
  • scales out (horizontally). Does Master-Master replication. No scaling built in, but prepared (use couchdb-lounge). Then a scaled CouchDB cluster looks like a single DB from the outside.
  • scales down (runs on small devices). Own your own data, take it with you on your device.
  • incremental map-reduce: after updates, only the affected documents get reindexed
  • as with any document-oriented database, store full documents as JSON, not relations. Good tip in the Q&A: a document is something that will be updated and used as a whole. “put stuff into seperate documents when it is updated seperately”. There’s no clear guideline however, it depends on the use case.
  • RESTful HTTP: “text-based protocol is not slower than binary” / “all HTTP infrastructure and tools can be used”
  • BBC uses CouchDB in production, after a survey/comparison of storage solutions.
Riak (Martin Scholl)
  • document-oriented DB like CouchDB. “Riak combines a decentralized key-value store, a flexible map/reduce engine, and a friendly HTTP/JSON query interface to provide a database ideally suited for Web applications.”
  • 100% awesome. Though disputable, even more awesome than CouchDB.
  • the Riak “Data-Sphere” consists of: Bucket x Key x Document
  • GET/POST/PUT /jiak/<bucket>/<key>
  • travel the graph/links between documents with map/reduce
  • but: travelling links is expensive (no caching of map/reduce result, although possible to implement it yourself)
  • Bucket: can have as many keys as you want
  • chainable map/reduce stages—unique feature of RIAK
  • “It is extensible and configurable in many ways. Riak is a perfect fit for buiding reliable and scalable custom data storage systems.”
  • unfortunately my brain went offline through the second half of the talk … See the video
MongoDB (Mathias Stearn)

Quote: “I won’t tell you MongoDB is awesome. But I hope you’ll know it is after my talk.”

  • Mongo as in “HuMONGOus” scaling
  • Schemaless; data organized into Databases and Collections (like tables). But document-oriented (not a K/V store)
  • Good when you don’t know up front what you will be looking for (example: logfile analysis), and want to store everything.
  • extended JSON with data types Date, Int32/64, OID, Binary and called it BSON. B as in binary.
  • Wants to integrate with native language as well as possible. I.e. “db.users.find({$where: “this.a + this.b >= 42”})” instead of “RestClient.get ‘’”. And, btw. old-school C++.
  • changing only part of a document is possible. features: $set, $inc, $push, $pull, $remove for subdocuments
  • “you can put all data in one place, MongoDB”. Get rid of RDBMS.
  • works for 1 billion documents.
  • map/reduce + finalizers.
  • uses the eventual consistency model (see first talk)
  • uses MMAP database files (OS kernel) to automatically use available RAM
  • async modifications: no server response, client doesn’t wait. good for bulk inserts.
  • good for: websites, complex objects, high and low volume sites, real-time analysis.
  • bad for: complex transactions, business intelligence
4th Generation Object Databases (Stefan Edlich)
  • these have been around for 15 years
  • “no impedance mismatch”. These DBs are very nice to work with OOP—no disassembling objects into tables required, and back. Just dump full objects, and load them again.
  • but: when refactoring code, DB has to change. No insulation between code and data.
  • looks as if they are alive and well in a specific niche (extremely large datasets)
  • db4o is a simple way to try a OO database.
  • typical applications: transportation networks, tree structures, social graphs, object traversal, capture space (grok this!). He gave an example of one OOD application which stores 3.2 Mio. objects per second, 1TB of data per hour.
  • no convincing answer why OO databases haven’t entered mainstream, while OO programming has—it sounds like such a good idea. My impression was they are a great tool for specific uses (high performance, huge scale), but exotic and commercial solutions with high up-front investment.
  • Somehow I wonder if document-oriented databases will make it, when object-oriented DBs haven’t …
A talk not held: Neo4j – The Benefits of Graph Databases

There was no talk on GraphDBs, which are designed to store nodes and the relationships between them. As in social networks (nodes = people, relationships = connections/friendships). Slideshare to the rescue, it has Neo4j – The Benefits of Graph Databases. There also was a talk on Neo4j at NoSQLEast.

Posted in  | Tags  | no comments | no trackbacks

published on 12.07.2009 15:52.

Updated is-gd for Ubiquity

See this post for a description of Ubiquity.

I adapted the script for the API changes introduced with 0.5, and put the script on github.

Posted in , ,  | Tags  | no comments | no trackbacks

published on 11.07.2009 12:12.

Cross-browser video support with HTML 5

Embedding video is easy in HTML 5, use the native <video> tag. Firefox 3.1+, Safari 4+ and Google Chrome (Windows) already have experimental support for it.

The HTML 5 spec does not specify which video format and codec should be used, so naturally ;-) the browser vendors have picked different formats. Getting videos to play cross-browser still is no problem, since the <video> tag can contain more than one source. So give an ogg and a quicktime version of the video, and all browsers currently supporting the <video> tag will be happy.


The code
<video controls width="320" height="240">

  <!-- Firefox 3.1+, Google Chrome -->
  <source src="/files/swiss.ogg" type="video/ogg">

  <!-- Safari 4+, Google Chrome -->
  <source src="/files/" type="video/quicktime">

  <!-- All others (including Internet Explorer and Opera) -->
  Sorry, your browser doesn't seem to support the <code>video</code> element.

How to create the video formats (OS X)

Easy. Use Quicktime Player’s export feature (File > Export). But first get the xiph Quicktime Components to add .ogg support to Quicktime.

Posted in ,  | Tags , , ,  | no comments | no trackbacks

published on 19.06.2009 23:19.

All tweets must die

I just published my first gem on github, all_tweets_must_die. It will become the core of a web app that regularly deletes your old tweets automatically. If you want to use twitter but value your privacy, this thing is for you.

I build the whole thing for fun and exercise. I’ll try to use as much new stuff as possible – Sinatra for the web app, Cucumber for testing it, CouchDB for storing user auth and preferences, and – if I actually get a couple of users on the site – possibly a small Erlang or Scala program for tweet deletion, connected to Ruby with Thrift. Lot’s of cool new technology, a lot of buzz. I know :-)

Posted in ,  | Tags ,  | no comments | no trackbacks

published on 28.03.2009 19:46.

Ubiquity is the shit!

Ubiquity is a Mozilla Labs add-on for Firefox. It’s a new way of interacting with the browser and web content. Imagine Quicksilver, but for everything that can be reached from the browser. Common examples are controllign the browser, translating text on a web page in-place, looking up an Google maps address in-place, you imagine. It let’s you throw out half of the other add-ons. Oh, and on the Mac, it integrates with Growl.

And it’s super-easy to extend with JavaScript!

Example – using to shorten URLs

I hacked this together using the pretty good documentation. The code takes the text selection (an URL) and shortens it via


  name: "is-gd",

  description: "Replaces the selected URL with a short URL generated with",

  author: { name: "Phillip Oertel" },

  takes: {"url to shorten": noun_arb_text},

  execute: function(urlToShorten) {
    var baseUrl = "";
    var params  = {longurl: urlToShorten.text};
    jQuery.get( baseUrl, params, function( shortUrl ) {
      CmdUtils.setSelection( shortUrl );


I embedded the above script into this page—if you installed the Ubiquity add-on, Firefox will notify you. Install the script, then select an URL anywhere on the page or in the location bar, press Alt-Space and type “is-gd”. The selected text will be replaced with a shortended URL. Neat!

They really have easy administration and extension in mind—go to chrome://ubiquity/content/cmdlist.html to get an in-browser interface to Ubiquity. You can directly write the scripts in there. Oh, and did I mention it already ships with jquery ?

Posted in , ,  | no comments | no trackbacks

Older posts: 1 2 3 ... 6