Flo Ledermann

This blog will move!

2011-06-06T10:12:00.003+02:00

[English]

I am in the process of refurbishing my website, which will allow me to host my blog as part of my own site from now on. This means that this Blogspot blog will be retired, and you will be able to find my blog from now on at its new, and permanent address. I am planning on posting more frequently again, so please check it out—I even made the effort to move all the old posts that still seemed relevant to me over there, so you won't miss anything. Please make sure to update the feed URL in your RSS reader!

Go to Flo's new blog now

[Deutsch]

Im Zuge der Erneuerung meiner Website übersiedelt mein Blog an seine neue, selbstgehostete und permanente Adresse. Der Blogspot-Blog wird damit nach einer langen Phase der Inaktivität eingestellt, ich habe aber vor an der neuen Adresse wieder öfter zu posten. Also, bitte denkt daran auch die Feed Adresse in eurem RSS Reader umzustellen!

Zu Flo's neuem Blog

The Beauty Of The Earth's Surface

2009-12-18T15:05:00.007+01:00

NASA's Shuttle Radar Topography Mission measured the earth's surface elevation in february 2000 using radar interferometry. The resulting data is available to the public and can be used for various purposes. I have been playing with the data over the last days and experimented with different methods for visualizing terrains in 2d and 3d, primarily in the context of Openstreetmap rendering. However, nothing has impressed me more than the very first plain grayscale image I produced (showing the area around and to the north of Vienna):

(click for a slightly larger version)

I have never seen so clearly the details and variation of the earth's relief. On most maps, data like this is rendered in the background to give the viewer a sense of depth, but map graphics and surface textures are usually layered on top and take away a lot of the clarity that is so stunning here. One has to consider that the image shows an area that is usually considered to be rather "flat" - but look at how one can see the thousands and thousands of years of wind and rain working on the "Weinviertel" area to the north. Or look at the sharp edge of the "Wienerwald" area, suddenly dropping down to the really flat plains of the "Tullner Becken" and "Wiener Becken".

I considered adding some labels and paths as means of orientation, but then I liked the idea to leave it like it is as a puzzle for you to figure out the locations of places you know in the image.

Addendum: In the light of the current issue of "protecting the planet", pictures like these make me quite confident that the planet will do fine - even long after we humans managed to remove ourselves from it after a short, rather irrelevant episode of civilization...

Augmented Reality in “Print 2.0”

2009-10-26T19:17:00.006+01:00

It's nice to see a project I have been involved with going live: The October issue of Red Bull's “Red Bulletin” magazine features augmented reality content that supplements the printed articles. But see for yourself:

Two groundbreaking new features made this move of augmented reality into mainstream media possible. Markerless tracking technology, developed by my former colleagues at TU Graz, allows the system to identify and locate pages in the camera image without requiring special layout or patterns on the page. And even more important, implementing the base technologies in Flash (done by Imagination in Vienna) allows end users to explore the content within their browser, requiring only a webcam connected to or built into their computer. If you want to try for yourself, grab a copy of the magazine and go to http://en.redbulletin.com/print2.0 (or to de. for the german version) to see it in action.

I was involved early in the project as a consultant, implementing a prototype to experiment with various content formats and bringing together the right people to realize the project. It was clear that Red Bull as a customer would require a seamless and direct user experience to suit their brand, and fortunately some of my former colleagues at Vienna University of Technology are now among the top players in the worldwide augmented reality research community and were able to deliver the necessary technology. I am quite happy how this worked out, as it was an important step for me to move away from doing a lot of implementation work by myself to a more conceptual level, bringing together people and using my experience to move the project in the right direction early on.

Although I am happy to see the results, I also see augmented reality, even in this very simple yet compelling form, still suffering from the same problems and obstacles like when I first experimented with it several years ago: Lighting (the real, not the virtual) is incredibly important and difficult to get right, because reflections on the page can make tracking impossible (especially in glossy magazines like Red Bulletin). In low lighting, the noise from the camera makes tracking impossible. Furthermore, the performance of the Flash implementation is a little below my expectations, requiring the application to use a camera resolution of 320x240 (!), further diminishing tracking and image quality. I believe there is a lot of potential for improvement here by optimizing either the implementation or Flash itself. (Hey Adobe, please note this down and check what you can do to optimize. And while you're at it, please add multi-threading capabilities to Actionscript if you want to see killer applications like this with decent performance - in a future of heavily parallelized systems this will be inevitable anyway.)

Talking about the application itself, this is obviously nothing new. Basically, there is still no more compelling augmented reality application in sight than simply placing virtual stuff on real objects - Flash's built in capability to display streamed videos just adds a very nice content type to it. Worldwide, hundreds of researchers are still looking for the “killer app” that will only be possible with augmented reality (I tried for myself for some years). Until a genius comes up with a truly revolutionary idea, we will have to stick with permutations of ARToolkit's cube demo as the mainstream application - and work on providing stable tracking, good performance (possibly on mobile devices) and a seamless user experience as icing on the cake. If done right, this can be great added value for dead-tree publications.

Here is Red Bull's promotion video for the project:

Playing with Arduino

2009-06-04T10:06:00.007+02:00

Finally I found some time to do a little hardware hacking on the Arduino platform. As a quick first project and a first step towards much larger things we are planning at Maschinenring I came up with something that a) makes sense and b) can be done with a minimum of money (€10 if you already have an Arduino) and a main focus on programming: A two-joint articulated plotting robot.

Unfortunately, this picture is a fake :)) but I could not resist using this Escher quote (actually i guess the hand should carry a screwdriver to make it symmetrical but I didn't want to spend too much time in Photoshop for now). The real plotting results are much more disappointing because of mechanical errors which are not really controllable in software (and no, it's not the fault of the cardboard used for building the robot arms) and accumulate to an error of approximately +/- 0.5cm in the output.

Nevertheless, it was a fun project and great for getting back into some hardware-oriented programming and thinking about things like optimizing calculations for integer math. More details (including a video of the robot in action and the Arduino source code) can be found at the Maschinenraum blog.

Heres a picture of the actual output: this should be an orthogonal spiral with a winding width of 1cm. (Sorry for the crappy quality, I only have a webcam for taking pictures right now.)

Because of the low precision I didn't bother to program a way to upload more complex graphics to the robot yet, so output geometry is limited to things one can easily implement procedurally. Send me code if you want something drawn, and I send you an arm-signed drawing from the artist ;).

Empty Inbox!

2008-07-29T22:50:00.003+02:00

Usually I sort incoming mails into folders immediately, besides the ones that require some kind of action or a reply, which I leave in my inbox (I sometimes even pull automatically sorted emails back into the inbox if I want to remind myself to act upon them). This means there are always some messages in my inbox, usually between 10 and 30, depending on my workload and other factors. Some of these emails can get very old in there, years in some cases where I just don't find the right mindset for a reply.

I am leaving for holiday tomorrow and wanted to answer some of these long waiting emails before that. The basis was laid already a few months ago when I decided to declare as abandoned some private email threads that have been waiting for multiple years, but now the impossible has happened:

Empty Inbox! I can't remember if this has ever happened before since I started using email in ... 1995 I guess.

How do you handle your inbox?

Jetzt geht's los!

2008-06-12T14:09:00.003+02:00

[This is a German post – if you want to receive only English posts, you may subscribe to the english feed]

Proletarier bekriegen sich gegenseitig und fordern, den Ölmultis Steuergeld in die Tasche zu schaufeln:

Telepolis: Massive Streiks in Spanien und Portugal

Manchmal wünsche ich mir schon, dass ein BWL-Gundkurs zur Allgemeinbildung gehört: Wenn der Produzent entdeckt, dass die Preiselastizität für ein Produkt gegen Null geht, wird er den Preis endlos steigern und sich dabei eins lachen. Einziger Ausweg: weniger zu verbrauchen!

syn:wall at ITNOA exhibition

2008-04-22T11:19:00.002+02:00

I just finished my first Flex project, an interactive projection wall for the exhibition ITNOA - In The Name Of Architecture. The exhibition brings together projects of students of the three universities in Vienna teaching architecture (TU Wien, Akademie der Bildenden Künste, Die Angewandte) in a self-curated setting. While the projects coming from different universities are presented in different areas of the printed-out part of the exhibition, syn:wall brings all projects together on one surface and creates neighborhood relationships between similar projects using quantitative attributes and tags.

The result of such an exploration can be printed out on a color laser printer and taken home by the visitor as an individual page of a distributed, virtual exhibition catalog.

One thing I learned (again) in this project is how inferior projectors are as an output medium. In a single grid cell of the exhibition, measuring 120 x 45 cm, a whole architecture project can be communicated in printed form, including texts, diagrams, plans and renderings. In the same area of the projected image there are 240 * 100 pixels, which can hold a lousy, pixelated thumbnail of the same project. Therefore I really like the idea of on-demand printing, and I would like to investigate this further in future projects, including producing larger prints with a plotter (something we originally planned to do but could not realize within the given budget and time).

ITNOA will be on until the end of the week, with a closing down party on Friday, the 25th of April (unfortunately I cannot be there on Friday because of two other appointments). It is located in the "Albertinapassage", the underpass under the Ring on the Albertina side of the Opera. ITNOA is also probably the last chance to have a drink at the infamous "Gaudí Bar" there, since the underpass will be closed down shortly after the exhibition. This place somehow always inspires me to get totally wasted every time I am there...

Thanks to Rüdiger Suppin for working on the concept with me and to all ITNOA people who helped entering the project information and crop all the images.

A weekend with the iPod touch

2008-03-13T21:28:00.003+01:00

Last week I got myself an iPod touch, because I had to spend money from a grant on hardware quickly and there is currently nothing else that I need. I got it primarily for testing web apps on its mobile Safari browser and to optimize them for its screen dimensions and touch interface. The iPod touch shares the same interface, operating system and applications with the iPhone (which becomes available in Austria tomorrow), but lacks three of its features: cellphone capabilities, camera and Bluetooth - I actually own a cellphone which does all this, so I am quite happy feature-wise, but naturally cannot comment on these aspects of the iPhone.

After a week of use I now want to share some of my experiences and observations with you. The first thing that stunned me is that they ship this thing a-maz-ing-ly fast! I ordered it on Monday afternoon, and on Tuesday early afternoon it was delivered to my door! Next: over at Apple, they know how to package their stuff - the packaging is so nicely done it is really a fetish on its own.

The touch interface is really good for a "wow" from everyone, especially with the nicely done details I admire Apple for: Lists don't just stop scrolling at the end, but you can scroll a bit further and they will elastically go back after you release your finger. Applications zoom into view when you start them, and the thing emits this perfectly designed click sound on every action. Multi-touch is overrated IMHO, since I very rarely use it and would find it more convenient to have a single-finger gesture for zooming (multi-touch always also means multi-hand, which is annoying - you cannot hold the thing and perform a multi-touch gesture with the same hand). The complete absence of haptic feedback also quickly turned out to be a caveat: simply no way of reliably controlling the audio player (volume, next song) while it is inside your pocket - you have to take it out, unlock, look at it, every time you want to change the volume. Also I found especially the volume slider would recognize gestures with my thumb unreliably, which is most annoying when the music is too loud and you have to fiddle around for seconds to be able to turn the volume down. Generally, a few (freely assignable?) physical buttons on the side of the thing would probably spoil the super-minimalistic design but would improve usability a lot for me.

Speaking of design: Maybe my hands are just too sweaty, but after a short time of usage the thing looks really ugly, on both sides. Finger taps and grease all over the screen and the shiny back makes you want to clean it all the time, which really is a Sisyphus thing. So its not exactly the kind of device you want to give out of your hand for business presentations, as everyone will go 'yuck, I'd better wash my hands...'

Interestingly I already had several occasions where the much-appraised tilt sensor turned out to be annoying. Obviously, if gravity doesn't point in the direction of your own 'down' vector, you are in trouble, which happened to me in bed several times. I wanted to browse some pictures before going to sleep, and they all would turn to their sides. The other day, Patrizia wanted to turn a photo to look at some detail, but the photo would just turn together with the device and there was no way of stopping it from doing so. So there are situations where it would be nice to be able to deactivate or override that tilt sensor thingy.

What surprised me is how little you can actually do with that thing, in terms of producing or editing content. You cannot edit song information. You cannot reorder the pictures in a folder. You basically cannot delete anything that's on there while on the go. Speaking of limitations, this brings me to the iTunes software you are forced to use. But I do not want to go into the details here, in short: iTunes on Windows is utter crap! I just hate it, and I will never understand how iTunes got the reputation it has... bleh! I hate it, hate it, hate it, and it will probably be the reason why my iPod will soon sit somewhere collecting dust, because actually they force you to use iTunes with the iPod touch - it is not possible to activate "disk mode" on this device which would allow you to use alternative programs. I guess this also means no chance for Linux users to ever sync their stuff with an iPod touch.

The full meanness of the Apple corporation is revealed when you look at the syncing options for calendars and address books on Windows: Outlook and Windows Address Book are the only supported options. Importing bookmarks only from Internet Explorer! No Mozilla, no iCal, no standards support. They have their deals with Microsoft, and they don't give a dime about standards or open products. But it all comes in a nice package, and hey the user interface is nicely animated, so the geeks are flying for Apple. Pfui!

What really surprises me is that they seem to get away with it, and the competition is screwing up so badly that Apple still, after all these years after the first iPod was released, looks like the only company that understands designing products. It's just unbelievable. Even though I hate this closed, proprietary, unhackable thing for its political implications, I wouldn't want to use any of the alternatives out there I have seen so far.

My Teeth

2007-12-19T20:48:00.001+01:00

I guess I really am one lucky guy... After seven years of avoiding it, I went to the dentist last week for a checkup, and guess what — nothing! Not one little hole in my denture to spoil the glory:

I borrowed the X-Ray image for those of you who complain that I don't smile often enough. Thanks to padme for making a contact print and scanning it!

Note that above image is copyright by me and I explicitly disallow any form of copying, reproduction or use other than viewing it on this blog - Although I strongly believe in open source and creative commons, I am not willing to provide data about my body to anyone currently.

Towards the perfect URL scheme for web applications. Part 1: Requirements

2007-12-10T16:35:00.000+01:00

[This is part one of a four-part article. I will add links to the other parts here as they become available.]

I am currently working on a prototype for a small, new, top-secret web application (don't worry, I will let you know as soon as there is something online to show). When I sat down to start coding, the first thing I had to decide on was what the URLs inside the application should look like and how the URL space should be structured. I always had the impression that the question of how to design URLs for web applications has been largely neglected by the web developer community as I never read anything about a structured approach towards the problem — although it is a very visible feature and often the first usability test a site has to pass. So many apps and websites out there come with unreadable, unhackable URLs and/or, even worse, do not produce meaningful filenames when you try "save as..." on a page or downloadable file. I wanted to really get this right in the first place, so I started with writing down the things that annoy me regarding how URLs are constructed elsewhere, added a few "nice to have" features and lessons learned from my own previous experiences and compiled a requirements list that my scheme⁽¹⁾ should meet.

Requirements for a perfect URL scheme

When I talk about "modern web applications" here I have a rough concept of the state of the art in mind (buzzword alert!): AJAX interface with a fallback to server-driven interactivity, REST APIs⁽²⁾, widgetizable applications and an object-oriented data model. Other websites may have different requirements, but most of what I say here will apply to a broad range of applications.

1. URLs should be human readable, rememberable and robust for voice communication (e.g. phone)

One of the most important requirements for URLs is that they should make sense to a human. Machine-generated identifiers, deep folder hierarchies, special characters, strange extensions or query parameters are examples for URL parts that humans cannot easily parse or remember. More often than you think URLs are communicated by voice communication, over the phone or in the radio, therefore they should unambiguously serialze and deserialize from spoken language (which, by the way, is also a strong case for non-case sensitive or all-lowercase URLs).

Obviously this requirement cannot be solved by a specification or scheme alone, but also lies in the application's responsibility. For example, if you have a document with the name 'qa4@@67g$O', the best scheme will not help you to provide a human readable URL.

2. URLs should be short

While this requirement is slightly related to the previous one, it is not the same. A longer URL may be much easier to remember, as you can easily try by using one of these tinyurl.com generated URLs. Still, partly for the reason of transmitting and displaying on devices with limited capabilities (think text messages), the URLs of our system should be naturally short with no superfluous namespaces, extensions or query parameters.

3. The scheme should produce meaningful filenames & extensions for every page and file served

This is one of my top annoyances on the web, as most web applications fail to fulfill this requirement. Even with document servers that are supposed to provide files for download (e.g. PDFs), I frequently encounter missing extensions, not to speak of meaningful and unambiguous filenames. Whenever we serve a non-temporary page or document for viewing
it should be possible for the user to save that page to her local machine, getting a meaningful filename with the correct filename extension.

4. The scheme should make use of established specifications and conventions — filename extensions ('.'), hierarchy ('/'), queries ('?'), fragments ('#')

Obviously I do not want to reinvent URLs, but build on top of established standards and conventions. The problem is that these standards have emerged in a time before XML, Javascript and AJAX, and so we have to find an interpretation of the concepts offered to us that match the requirements of modern web applications.

5. The scheme should use as few reserved characters as possible, leaving most of the allowed character set for the application

I want to avoid introducing reserved characters in addition to the ones mentioned above - partly because it would be a nonstandard extension to what we already have, partly because human readability would suffer by introducing additional non-letter characters.

6. URLs should be "hackable"

Closely related to human parseability requested in requirement 1, "hackability" means that parts of the URL could be removed or added by users, leading to deterministic, meaningful results. Some examples of this would be: removing everything after the last '/' should give you an overview of the content one level up a hierarchy, removing or changing extensions should change the content type served, adding parts of an URL seen elsewhere on the site should result in similar behavior on any other resource etc.. Note that a system with "hackable" URLs should also protect the user from accidentally modifying or deleting resources this way, so that users can safely play around with the URL scheme without causing damage.

7. URLs should be able to address resources AND actions to be performed on these resources

This is the major new requirement I see with modern web applications. When HTTP was designed, URLs were meant as a way to access resources, in most cases static files. The operations to be performed on these resources were pushed into the HTTP protocol in form of the GET, PUT, POST, ... methods. In modern web applications it turned out that a predefined set of methods cannot cover all the different requirements that may emerge. We therefore need a way to express actions to be performed on resources within the URL, since no other method is provided by the HTTP protocol.

8. Resources or results of an action should be presentable in different formats (HTML, XML, JSON, plain text, ...), providing correct file name extensions

As static pages play a less important role in modern web applications and standards for the exchange of various data flavours emerge, it is important to be able to present a resource (e.g. an article) in different formats (e.g. HTML, Plain Text and RSS). New standards are emerging all the time and may become relevant in the future, so the pool of formats to choose from should be expandable in the future to support yet unanticipated usage of the data.

9. The scheme should support content to be served in a format determined by the preferences of the client application

In addition to the explicit choice of format through the URL scheme discussed in the last item, the mechanism of implicit content format selection offered by HTTP through the "Accept" header⁽³⁾ should be supported. The Accept header allows the client to send a list of supported content types along with each request, allowing the server software to select a content type best suited for the task.

This way our system can send different responses to a mobile phone and a full-fledged web browser, although both are using the same URL to access the content.

10. It should be possible to mix static files and generated content

Although static files play a less important role in modern web applications, it is obvious that every web application will need to serve static files form the file system to the client. While in production environments this is often solved by a dedicated subdomain (e.g. static.foo.com), it should still be possible to serve static files and generated content from a single server.

11. A single resource should have a single (normalized) URL

Flexible URL schemes often provide multiple paths to a single resource, leading to problems in unambiguously identifying resources. Search engines, for example, may not be able to conclude that two different URLs point to the same resource, usually leading to a reduced ranking for both pages. If multiple paths to a single resource are possible, an unambiguous normalization method (often called 'URL canonicalization') should be provided.

12. Support the features of "standard" global filenames like robots.txt, sitemap.xml, favicon.ico

Due to very unfortunate historical developments, some "standards" have emerged (none of them is actually a standard accepted by any official standardization authority) that rely on the presence of static files in the URL hierarchy of a server. Since these "standards" provide convenient or important functionality for many web applications, the URL scheme must either support these filenames by ensuring that no other resource can exist with an identical URL, or we need to find ways to support the features provided by these files through other means.

This concludes the requirements for a perfect URL scheme I have discovered and found important. In the next part (coming up soon!) I will discuss the constraints we face from the URL and HTTP specifications for designing our URLs. Part 3 will present the proposed URL scheme and Part 4 will discuss implementation issues. Stay tuned!

Footnotes

1 - Let me state in advance that when I say "URL scheme" here, I do not mean to propose a new scheme outside the scope of what HTTP already supports. My intention is to find a way to structure the path component (everything that comes after the server name and port in the URL) in a way that reflects the needs of modern web applications.

2 - I have to admit here I have never quite grasped what REST really is or why everyone is talking about it. As far as I understand, it is simply the concept of having a stateless API where every call is simply a HTTP request, and I have the vague idea that the URL scheme proposed here goes well along with it. If anyone has any further insigts, please enlighten me! (And yes, I have skimmed through the dissertation)

3 - The Accept header is discussed in detail in the HTTP/1.1 specification (RFC2616), section 14.

Updates

2007-12-19: Added numbering to the individual requirements and added requirement 7 (Hackability)

Beautiful Code - grausame Sprache?

2007-11-18T14:43:00.000+01:00

Auf der Web2.0 Expo Berlin verteilte der O'Reilly Verlag Heftchen mit Auszügen aus der deutschsprachigen Übersetzung von "Beautiful Code". Darin habe ich gerade folgenden Satz gelesen:

Wir sahen (oder glaubten zu sehen) ähnliche Probleme beim Nachhalten committeter Targets während der Übertragung von Änderungen vom Client zum Server, bei der Fortschrittsanzeige für den Benutzer während Update- oder Commit-Operationen und in verschiedenen anderen Fällen.

Aah, ja. Ich fände es doch angemessen, die Schönheit von Code in einem Druckwerk eines namhaften Verlags auch mittels halbwegs vernünftiger Sprache zum Ausdruck zu bringen. Oder bin ich nur von der Grippe zu sehr geschwächt, um den Satz auf Anhieb zu kapieren?

Generell bemerke ich in letzter Zeit ein besorgniserregendes Absinken der Qualität von Lektorat und Übersetzungen, auch bei Verlagen die es sich leisten können (sollten). Was kann man dagegen tun? Wenn ich mich, gelangweilt und frustriert von der teils katastrophalen Qualität der Sprache in online Medien — ob "user generated" oder professionell — einem Druckwerk zuwende, möchte ich dort eigentlich nicht wieder mit der selben Schludrigkeit konfrontiert sein.

Berlin slides!

2007-11-12T13:59:00.000+01:00

The slides of my presentation at Web2Open Berlin, titled "Advanced GPolyline usage — Interactivity and performance issues", are online now. I could not resist to create my own rudimentary HTML slide show framework for the presentation, so excuse the spartanic layout :)

Btw.: you can find most of the slides of the main event online at slideshare!

My talk at Web2Open this wednesday

2007-11-05T10:52:00.000+01:00

I will be giving a talk at Web2Open in Berlin (a free event attached to the O'Reilly Web2.0 Expo) this Wednesday. The announced title and abstract of the talk are:

Advanced GPolyline usage - performance issues and interactivity

Due to different implementations on different browsers, complex and high resolution Google polylines can lead to surprising results up to non-responsive applications in some cases. I will present the - sometimes surprising - results of our performance measurements, performance improvement strategies and a comparison with an experimental alternative implementation that can be also used for improved interactivity like real-time editing or continuous panning along a line.

But maybe you can best decide whether you are interested by looking at a screencast of the implementation I did for maptales. In the talk, I will provide some details and hints how to implement the shown features for your own applications.

Looking forward to see you at Web2Open!

Procrastination

2007-11-03T22:56:00.000+01:00

I have heard the term Procrastination for the first time only a few months ago (I think it was in the very recommendable PhD Comics). Since then, the word keeps popping up more and more often on my radar, and so it was no big surprise (although worth a smile) to hear a session on the topic being announced at bar camp Berlin this morning. Of course you have experienced procrastination, everyone has I guess — and it can be frustrating at times. But is it really a call for self-discipline or productivity management techniques, as commonly suggested, or should you not rather listen carefully and even give in from time to time to the alarm signs of your brain that just doesn't seem to want to work on the tasks you (or someone else) are trying to force it to?

One of the main reasons for p. that were mentioned in the session was distractions by a never ending bombardment of emails, bog posts, tweets, calls and alerts. But distractions like these are not the reasons for procrastination but mere artifacts, things that your brain is looking for in its under- or overwhelmedness with the "important" tasks assigned. I am writing this blog post without constantly checking my email or twitter now, because I am really involved with it and I want to get it right.

My claim is that if you procrastinate regularly, there is something wrong. Deeply wrong. Try listening to yourself — if your brain needs idleness, go home or go for a walk. Be brave and do it, even if you are supposed to work! Neither you nor your boss will profit from continued procrastination and the unhappyness and frustration that comes with it. If you constantly think about other things to do, you are most probably bored. Then you should think really hard if what you do — or what you are supposed to be doing — is really worth it. Do I really need this job? Do I really want to do a PhD? Do I really have to get christmas presents for my family? What is worth spending your time on in your life? Think deeply. Now. No matter how you decide, if you decide honestly, everyone will profit — also the people you think you are doing a favor by keeping those tasks on the list.

I am not saying that complete drifting and laziness should be the goal of our existence or that procrastination cannot take pathological forms, but it always astonishes me how obsessed people are with "success" in the very narrow definition of accomplishing tasks, often other people's tasks, and they take that definition of their success from sources that are either manipulated (media) or far more powerful and in a better position to exploit them (their bosses), without thinking about what would make their lives really successful.

Overcoming procrastination is certainly not a matter of deciding between boring to-do's or twitter or cleaning — it's a decision between what really matters in life and what doesn't. We are a substitute society, and procrastination is our name for our addiction to substitutes. Feeds for adventures. Cleaning up for feeling at home. Tweets for love and friendship. Next time, step back for a minute, think about what you are missing and choose to make a real change, instead of trying to trick yourself back into the treadmill.

P.S. I want to share with you the hilarious video shown in the session:

Tagged: procrastination, barcampberlin2

Solving Hibernate Criteria's "Distinct Root Entity" limitation once and for all - including pagination

2007-10-28T12:34:00.001+01:00

I have to start with a rant: The Hibernate Criteria API, which I learned to at least partially like over the last months working on Maptales server code, has a few limitations which repeatedly make me wonder whether Hibernate really has been the right choice for a DB abstraction layer from time to time. It's not so much the limitations themselves, but rather the total lack of documentation of these limitations in the official Hibernate docs and examples and the generally rather arrogant tone on the Hibernate mailing Lists and FAQs — if you get an answer at all, that is — that annoy me and I guess a lot of other Hibernate users. The examples provided — and therefore copied blindly into nearly every Tutorial or Book about Hibernate out there — always avoid to show these limitations because of the triviality of the scenarios they cover. The purpose of a proper documentation would — for me — be to document especially such limitations and border cases where an API fails and provide solutions for these cases.

The problem is even amplified by the fact that googling for such limitiations rarely brings up a solution, since, as mentioned above, the hibernate documentation and inherited tutorials all do a good job in concealing the problems, and few coders out there seem to really use Hibernate in more sophisticated ways and publish their experiences. Which makes me wonder, because for these trivial cases too often good ol' SQL would have been perfectly sufficient — and advantageous to those lamer wannabee DB coders who would actually be forced to learn something about databases instead of replicating stupid Hibernate tutorial examples.

</rant>

OK now the specific limitation I want to talk about is: Hibernate does not return distinct results for a query with outer join fetching enabled for a collection. At least that's what they call it in the Hibernate advanced problems FAQ, failing to discuss this problem in deep and to give a general solution. Quote:

One day Hibernate might be smart enough to know that if you call setFirstResult() or setMaxResults() it should not use a join, but a second SQL SELECT. Try it, your version of Hibernate might already be smart enough. If not, write two queries, one for limiting stuff, the other for eager fetching.

And here they are again cutting of a large part of the problem. First, I checked an my version of hibernate is not "smart" enough, and it does not look like it will get any smarter soon. Second, the approach proposed there did not work for me when querying on properties of objects inside a collection - the collection has to always be JOINed for the query to work, therefore always producing results useless for pagination after transforming to distinct root entities. Generally, my problem was harder in a number of ways than the ususal examples:

I am nearly always using criterias on collection members, therefore I cannot revert to SELECT fetching.
I always have to use pagination (setFirstResult() and setMaxResults()), because in a web application it is not nice to return thousands of results on one page.
I am using PostGreSQL which adds a few oddities above it all (see below)

After digging through a lot of useless to semi-enlightening blog posts (thanks to Rick Hightower for providing two thirds of the solution) I could finally come up with the ultimate solution that works for me now:

First you have to accept that you have to live with 2 queries instead of one. You simply cannot do pagination and restrictions on collection members in hibernate in a single criteria query. Once you have accepted that fact, you can go ahead and construct your base query.

public List queryCats(Date queryDate) throws Exception {
Criteria criteria = getSession().createCriteria(Cat.class);
criteria.setFirstResult(offset).setMaxResults(num);
criteria.addOrder(Order.asc("age"));
if (queryDate != null) {
  Criteria subCrit = criteria.createCriteria("kittens", "kitten");
  subCrit.add(Expression.ge("birthDate", queryDate));
}

What you need to do then is to project the result to a collection of ids of the objects that match the query, eliminating duplicates. Here also the mentioned speciality of Postgres (at a second look it seems to be a general limitation) comes in: you have to include fields that are used for ordering in the projection clause. The nice thing is we can do the projection on demand and only if collection memebers are actually queried — this comes in handy for programatically constructed queries which can use the simple, single query way if collection properties are not used in the query:

  if (queryDate != null) {
  // project result to distinct ids,
  // including columns used for sorting
  criteria.setProjection(Projections.distinct(
    Projections.projectionList()
      .add(Projections.id())
      .add(Projections.property("birthDate"))
  ));
  List list = criteria.list();

  // unfortunately we have to copy the ids out of the
  // resulting Object[] List
  List idlist = new ArrayList<long>();

  for (Iterator iditer = list.iterator(); iditer.hasNext();) {
    Object[] record = (Object[]) iditer.next();
    idlist.add((Long)record[0]);
  }

  // another Hibernate stupidity: empty Lists cause
  // Expression.in to throw an error
  if (idlist.size() > 0) {
    criteria = getSession().createCriteria(Cat.class);
    criteria.add(Expression.in("id", idlist));
  }
  else {
    return new ArrayList();
  }
}

You can then transparently use the id-query in the complex case or issue the main query in the simple case:

  return criteria.list();
}

The presented approach has worked for me in a number of cases, and I am very happy now!