TextMate

Allan Odgaard, the author of TextMate, still denies to make a Windows version of his famous editor.

He misses a very lucrative market with profits guaranteed (Windows users are begging him to port it), still he won’t do it. Instead he points to other editors copying his ideas, innovations etc!

(He even goes a step further and may drop backwards compatibility for Mac OS X with the next major TextMate release.)

And guess what? Right he is! If working on TextMate wouldn’t be fun, it wouldn’t be such a great product.

Keep up the good work Allan, I never felt sorry for a single cent I spent on TextMate.


You have to start doing something and trust the muse will follow, not the other way ‘round. —Kathy Sierra

Blue on red

Del.icio.us is an amazing service1, clean, fast, and usable – except for one thing, it’s color scheme.

Continue to full post...

How to read a paper

Since I’m writing my master’s thesis, I have to read a lot of scientific papers. In my previous years it wasn’t necessary to read those, so I’m not used to it.

Here a few tips which might help you to read and hopefully understand scientific papers.

Continue to full post...

Java is OpenSource

Java is going open (really open as in GPL2).

They were talking about it for a long time, now it’s real! Java is (going) OpenSource!

Continue to full post...

Zooomr gives away free pro accounts

Zooomr (note: three “o”s) offers free pro accounts to any blogger out there, you just have to link one picture, so here it is.

Continue to full post...

Brand new MacBook Pro

Today I’ve got my brand new MacBook Pro, so I thought I share some observations for those who are tempted to buy one too.

Continue to full post...

Let Bookmarklets do their work

Firefox 2.0 is out, but has a little configuration annoyance: it prevents JavaScript to raise windows. This feature is pretty essential for some Bookmarklets (like Google’s Bookmark Bookmarklet).

Here is how to get Firefox to work like it did before.

Continue to full post...

Using Google's Blogsearch

I’m using hobix to power my blog. Unfortunately it requires some work to get the dynamic components up and running (search and comments).

So I decided to use Google’s Blogsearch which is pretty powerful.

Continue to full post...

Google Bookmarks

Google launched it’s bookmarking service quite some time ago. Until recently it didn’t seem very interesting to me since I liked del.icio.us a lot.

I tried to use it several times but always came back to del.icio.us, either because of it’s tagging capabilities or some other feature. Yet the full-text search of Google’s Bookmarks is a killer feature!

Times change, now I made the switch to Google Bookmarks (for good).

Continue to full post...

GMail User Interface

I really like Google’s user interfaces. Most of them are really good and their search interface changed the whole industry.

There’s currently only one thing I don’t get – the Delete button in GMail.

Continue to full post...

Why Darcs

One of my colleagues keeps asking my why I prefer Darcs over Subversion.

The question isn’t easy to answer. I think it’s mostly because of personal preferences and not because of objective advantages. Anyway I’ll try to explain it in this article.

Continue to full post...

Rethink your Web-Interfaces

Forbes recently published a list of Web-Applications for small businesses. Google won in several categories (Calendar, E-Mail, Information Managers, Spreadsheets), my question is why?

Continue to full post...

ICFP Programming Contest

The ICFP Programming Contest is a little competition just before the International Conference on Functional Programming. Anyone can subscribe and attend. This year 364 teams took the challenge with their programming language of choice.

The contest is not tied to functional programming languages, you can choose whatever language you want. That’s the reason for this article. Which language has proven itself in this contest?

I’ll include the first, second and the Judge’s price here.

Year First Second Judge
1998 Cilk OCaml J http://www.ai.mit.edu/extra/icfp-contest/
1999 OCaml Haskell Haskell http://www.cs.virginia.edu/~jks6b/icfp/
2000 OCaml OCaml GML http://www.cs.cornell.edu/icfp/
2001 Haskell Dylan Erlang http://cristal.inria.fr/ICFP2001/prog-contest/
2002 OCaml C Python http://icfpcontest.cse.ogi.edu/
2003 C++ C++ Dylan http://www.dtek.chalmers.se/groups/icfpcontest/
2004 Haskell Haskell/C++ OCaml http://www.cis.upenn.edu/~plclub/contest/
2005 Haskell Dylan Dylan http://icfpc.plt-scheme.org/index.html

The results of the 2006 ICFP contest are not included since they weren’t published at the time of this writing.

To sum it up:

Language First Second Judge Sum
Haskell 3 2 1 6
OCaml 3 2 1 6
Dylan 0 2 2 4
C++ 1 2 0 3
Cilk 1 0 0 1
C 0 1 0 1
J 0 0 1 1
GML 0 0 1 1
Erlang 0 0 1 1
Python 0 0 1 1

Interesting, isn’t it? There are few well known programming languages in this table. Haskell and OCaml both won six times! No Java, no Ruby, no Perl program made it to the top, what’s up with those languages (Again, the contest is not limited to functional programming languages…)?

What are the possible interpretations of such a result?

  1. Functional programming is pretty good (at least in Haskell and OCaml)
  2. The tasks are “functional-friendly” (at least we know that there are differences and you should choose your tools to suit your task)
  3. Only teams using obscure functional programming languages submit to ICFP (sorry, not true)
  4. ICFP isn’t able to run programs written in other languages
  5. Libraries don’t help you that much
  6. Only smart people learn obscure programming languages

Do you think your language is better than the other ones? Prove it, and sign up for the ICFP 2007 :-).


After more than 45 years in the field, I am still convinced that in computing, elegance is not a dispensable luxury but a quality that decides between success and failure;—Edsger Dijkstra

The Programmer's Bill of Rights

Jeff Atwood over at Coding Horror wrote The Programmer’s Bill of Rights I like the idea, but some points aren’t how I’d like to have them.

So here my own “Programmer’s Bill of Rights”.

Continue to full post...

Hobix

Hobix is the weblog system written by why the lucky stiff. It builds upon Ruby, YAML, Textile and generates static HTML.

Continue to full post...

Darcs

Common version control tasks, and how they’re done using Darcs, a fresh approach to version control.

Continue to full post...

Nintendo DS Lite

Recently I bought myself a Nintendo DS Lite handheld. It’s amazing so I thought I could share a few observations.

Continue to full post...

Ten questions

Jaroslaw Rzeszótko sent a list of ten questions to some of the best known programmers in/on the net. It was a great idea, I love it. The questions are very basic, but what else would you ask? Anyway I started to answer them myself, so here they are…

Continue to full post...

Don't over-reuse

I’m no big fan of frameworks. This comes from bad experience with a framework drawn out of a specialized project. It had to be used in every project we had to implement whether it was appropriate or not. The argument was something like “it provides features you’d have to implement yourself, so it saves you time”. Usually these features would take about one hour to half a day to implement new—exactly fitting the problem. But we had to take all the clutter and deal with it. This was about six years ago, and as far as I know they still use this exact framework… .

Reuse is a good thing, we all know that, and we all draw our benefits from it. But you can certainly overdo it, not every project fits a specific framework.

Ben had a link to recordings of the last RailsConf (and insisted that I watch them) where Martin Fowler and David Heinemeier Hansson talked about what the essence of Rails really is. It does fit a few particular cases very well, but it doesn’t solve all problems for Web developers. Fowler’s talk is a bit more general on Software development, and DHH’s talk presents new ideas for the upcoming version of Rails, but starts with the philosophy and the goal as well as the non-goals of Rails. Both talks are highly recommended.

The reason I write about it is Bruce Eckel’s articel ‘When Reuse Goes Bad’.

This resulted in classic framework-itis. The contractor was no longer just trying to solve the customer’s problem, they were trying to solve all problems that looked like it. So for that reason alone the project would have required 10x the original time and money.

Read it, it’s a short one. I really felt affected by it.


Before software can be reusable it first has to be usable. —Ralph Johnson

How to make Firefox look good on Mac OS X

This tutorial shows how to pimp your Firefox to look good on Mac OS X. After it’s beauty-session it integrates itself nicely into the overall Mac experience.

Continue to full post...

Gmail with your domain

Google provides a service to host your company’s (or personal) mails at their servers via your own domain. They currently provide a limited (invitation only) beta test. You can sign up at Gmail for your domain and they’ll send you an invitation. I had to wait quite a time: signed up in February and received the invitation in July.

Continue to full post...

Mental workout

According to this article from Popular Science thinking really hard causes your brain to consume 15 times more calories than in “stand-by mode”. The calorie consumption goes up from 0.1 calorie per minute to 1.5 calories per minute.

So let’s do some (brain) workout and loose some weight.

Continue to full post...

The year 2038 problem

I just found some information on an upcoming problem, the year 2038 problem. On that page is also an program to test whether your operating system has a problem or not.

In summary: the system time is usually stored as seconds since 1970 in a 32-bit register (or variable). On 2038-01-19 at 03:14:07 the register will overflow… . The solution is to switch to an 64-bit register (sufficient more than 4,000,000,000,000 years).

Usually not only the operating system has to be tuned, all time variables have to be large enough. 32 years aren’t that much for some programs (I’ve heard :-)). BIOS variants may also have problems on that day.

Some operations do have that problem now! Just think of an average of two dates after Jan 2004 (a+b)/2! a+b is already too large for 32 bits.

I couldn’t resist to check it on my systems

Linux currently has a problem, Mac OS X doesn’t.

Mac OS X Tiger on a G5

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

Mac OS X Tiger on a G4

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

Linux (Kernel 2.6.16)

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901


We are at the very beginning of time for the human race. It is not unreasonable that we grapple with problems. But there are tens of thousands of years in the future. Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. —Richard Feynman

Growth

I’ve seen companies which try hard to grow1. I often can’t see the point in getting more people to work for them. Investing in the current people pays much more, I think. If you take the span of bad people to very good people which can be ten times more productive2, wouldn’t it be worth to invest five times more money and time into these people than hiring more and more? Every single person increases the communication effort and slows the whole organization down. Whereas a slim, highly productive team increases the quality and lowers communication effort.

More productive?

There are many factors which influence the productivity of people in software development.

  • Speed (Function Points per Week)
  • Defect rate (bugs per Function Point)
  • Communication effort (knows how to use Google and Books)
  • Cost (Cost per Function Point)
  • many many more…

Lets compare two groups of developers, one slightly better than the other5.

Developer FPs/Week Bugs/Fp Euro/Week Euro/FP Additional communication-effort
A 100 0.01 1200 12 0.05
B 66 0.02 800 12 0.10

So, developer A is clearly more productive than developer B, but costs more.

Imagine a project with 1,000 Function Points. It has to be code complete in five weeks.

Group of A-Developers

1,000 Function Points in five weeks are 200 Function Points per week. Our team has to consist of three A-developers. Ideally, three developers produce 300 Function Points, but we have to consider the communication effort: (3×100) x (0.953) = max. 257 Function Points. Cost: 18,000 Euro with a combined defect rate of 0.02973.

Group of B-Developers

This group has to consist of six developers. (6×66) x (0.96) = max 210 Function Points. Cost: 24,000 Euro with a combined defect rate of 0.114.

Summary

As you can see, a few developers which are slightly better than another group can easily outperform a double sized team:

Team Number of developers max. FPs Cost Defect rate Communication effort
A 3 257 18,000 0.0297 0.1426
B 6 210 24,000 0.114 0.4686

You could easily pay the A-Developers the double amount of the B-Developers and you would still produce a better4 product in the same time with the same expenses! Additionally the A-team still has more capacity left for changing requirements or unforeseen problems.

Again, wouldn’t it be far better to support and develop your current staff than simply adding more people?

1 In terms of “hiring people”.

2 The numbers came from two different sources. The first one is senior Siemens manager, and the second one is Paul Graham.

3 One minus the probability of no error: 1 – 0.993

4 More features or superior usability and less defects.

5 Never trust a statistic you didn’t fake yourself.


Adding manpower to a late software project makes it later. —Fred Brooks

Manage your people

Whereas I don’t have the experience to write about it, I’d like to show some lecture notes and summaries about leading in high-tech.

Science, technology and tools often hide the most important fact: your people are your capital! The better your people the better your products. Of course you can hire highly trained people, but it’s your obligation to give them space and opportunity to evolve.

Your employees are highly motivated and highly trained after their schooling, but all to often the get demotivated far too fast. Why? One thing I’ve blogged about earlier is to tell them how to do their task instead the goal. This leads to an interest conflict, the requirements may conflict with the employees liability. Simply put: I can’t be responsible for things I was forced to do.

Software Engineering is somehow special in some cases:

  • Ideas are the driving force
  • The outcome is often unsure
  • Research leads to knowledge gain; Development to products; these two often get mixed up and lead to nowhere
  • Progress is hard to measure (90% syndrome)
  • Unsafe starting-point (changing requirements; incomplete foundation)
  • High complexity of modern software products

To support the worker, you must make sure

  • to give them enough freedom to think
  • to enable quiet and uninterrupted working
  • to enable communication between the people
  • to supply the needed tools
  • not to condemn errors – these are necessary within a creative environment

Important points to keep:

  • bad ideas lead to bad products (often the first idea won’t be the best)
  • the best idea won’t lead to success if the routine work fails
  • methods enable creative thinking (they free you from thinking about routine tasks)
  • processes make projects faster! If a process slows you down (long-term), it’s the wrong one.
  • your people want to be proud of their work, make sure they can.


Managers are hired to amplify the productivity of all people around them. —Scott Berkun; The Art of Project Management

The First Idea

I don’t like first ideas. Most people working with me may have painfully experienced that1.

I really think that idea generation is vital in our business. We can’t afford (anymore) to take the first idea and start working. Knowing the alternatives is much too important. All too often I see people thinking of a problem and the first idea that seems to make sense is it. These (non)efforts result in changing directions in the middle of the development, or in starting over. Both very expensive experiences.

Sometimes the fist glance (see Blink2) is very important and a very powerful tool. But in this case, with systems more complex than most other products in the world, that won’t work.

I really enjoyed Scott Berkuns “The Art of Project Management3”. Especially because he dedicated some pages on that problem. When we start to think about a problem we should explore the problem space as far as possible4. Know what’s allowed to do and think of as much possible solution within these boundaries as possible. At some point the solution space stops expanding and collapses. This is partly because some solutions are not feasible, and partly because the solutions overlap. At the end you should have a few very distinct solution-proposals. Now it’s time to analyze those. Do they really solve your problem? Is this what the users want? Is it feasible? How much does it cost?

At the end of this process you should have one solution which is very likely significantly different from the first idea. And you have a high chance that you’ve chosen one of the best solutions possible.

Bad ideas simply lead to bad products, but also good ideas lead to bad products if the rest fails. Nevertheless, many of the failing projects4 have problems with their foundation (requirements and ideas) than with the implementation (design and code). Unfortunately changing the foundation gets very expensive the further the project develops.

1 On the other hand, my blog-articles are rarely more than a blink of an early idea.

2 Blink by Malcolm Gladwell

3 The Art of Project Management by Scott Berkun

4 You have to know when to stop.

5 Number vary, but standish offered these: 31% are cancelled before completion, and 22% slip their schedules. Most of them had problems with their foundations.


I don’t stop searching for a needle in the haystack, even if I’ve already found one. —?

The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane. —Nikola Tesla

The Pragmatic Programmer

Wow, that’s a great book! I own over 80 non-fiction books but only few of them excite me that much. The Pragmatic Programmer from journeyman to master from Andrew Hunt and David Thomas is one of those. It’s stuffed full with practical wisdom and tips you can start using from the moment you read it.

They discuss all relevant topics of programming and software development, starting from text editors, IDEs, code generation, command line versus GUI etc… to estimation, handling requirements and documentation. It’s fantastic and really fun to read, too sad it has only 300 pages.

Usually the quotes on the back-flap of any book should be handled with care, but Ward Cunninghams quote If I’m putting together a project, it’s the authors of this book that I want. ... And failing that I’d settle for people who’ve read their book. doesn’t really surprise me after reading just a few chapters.

(The second one equally full of wisdom, but with another focus, is Robert C. Martins Agile Software Development. Principles, Patterns, and Practices. Before buying several books on Design Patterns, Agile Methodologies and Software Development guidelines buy this one.)

Even if these books are from programmers for programmers, they’re extremely well written (meaning they don’t use nested parentheses (like me))!


An investment in knowledge always pays the best interest. —Benjamin Franklin

Why you should use a plain text editor for programming

I’m always impressed if someone codes like it’s all he or she has ever done, without IDE and still n-times faster than anyone with an IDE.

During the past few years I’ve done a lot of Java coding. I’ve used Eclipse most of the time, but until now I didn’t realize how little I really know about Java1—my skills largely depended on my IDE of choice.

Most of the time I don’t have a clue where (in which package) a specific class lies, as well as I don’t know (even roughly) what exceptions are thrown. For these tasks I asked my IDE to generate the code I needed (import, try/catch or throws statements).

The last few days I used ANTLR to generate a parser. I didn’t use an IDE (there is none for ANTLR 2 available for free), which meant I had to refer to the Java API to check whether my imports are right, how this or that method is named exactly and which arguments it’ll take (what Eclipse has done so far. It is to be blamed that I only know approximately the first three characters of a method name2).

If we are coding for productivity, in our day job or where time matters more than sharpening our skills, it’s fine (and sometimes crucial) to use an IDE. But if we want to learn something and get better (smarter) at our tasks it actually does harm: we’ll end up thinking man that’s easy I must know pretty much everything about this or that5... where in fact we only know how to use our IDE and don’t know s##t about the language itself3.

Another dangerous thing with code generators is, that it seems pretty easy to get up and running with a mid-sized application. We write a bit, generate a lot and we’re ready to go, isn’t that so? No, only at the beginning! If we (or someone else) need to change something in that code, maybe weeks or months later we have to understand every bit of the generated code (Ben has written about that too), now we’re screwed. If the code looks messy why should anyone bother to do his/her best to make clean changes?

If it’s easy to copy and generate lots of code why should one bother and think about abstraction, generalization and stuff? If I had to write getters and setters by hand, I would do anything to avoid it. Maybe (just maybe…) I’d just start designing my programs, making a real O-O design (or write a generator to write them for me, but that’s another story).

The previous problem can easily be avoided by hiding the generating the code. In Lisp one writes macros to generate code at compile time, xDoclet generates code as it’s own step, EJB 3 generates code at compile time too.

Now, what’s the point? Use a plain text-editor4 for educational purposes and avoid generating too much code with your IDE on your day job.

1 Java in terms of packages structure, method names etc. Meta-concepts like algorithms, techniques, patterns etc. are out of question.

2 That’s a great example for a quote out of Donald Normans book The Design of Everyday Things Knowledge in the head, and in the world: Precise behavior can emerge from imprecise knowledge, and, of course his Things that make us Smart book. None of these things make us an expert… merely an user.

3 You can be a pretty smart programmer, but don’t know a lot about the used programming language. To be a true expert you have to dive into the language itself and don’t rely on an IDE.

4 There are many high quality editors out there. I like TextMate most, but Emacs, Vim and JEdit are quite good too (and free, but keep the learning curve in mind).

5 See Unskilled and Unaware of it (PDF, 500kb). Somewhat related: Being a specialist (PDF, 164kb).


The Brain: Pinky, are you pondering what I’m pondering?
Pinky: I think so Brain, but if you replace the P with an O, my name would be Oinky, wouldn’t it?

Ruby: future and delayed (lazy) variables

Future variables

Future variables are a very popular technique to implement dataflow execution. A future variable gets assigned with a (potentially lengthy) operation which will be executed in a separated thread. The assignment is therefore non-blocking.

As soon as the variable gets read, it blocks if the calculation isn’t ready, or it immediately returns the result.

I’ve implemented that feature using some Ruby tricks, but the finest and most elegant solution would be in Lisp using it’s unique macros.

Anyways, here a quick example:


x = RFuture.future do
   # some lengthy operation with an interesting result
end

Now, that assignment doesn’t block, and we could do some other things, later on we may want to know what the result of our operation is:


puts x

This code could block if the result isn’t ready.

As you can see, there is no special handling for reading the variable (meaning using adopting future variables later on is quite easy).

In the best case scenario the saved execution time is pretty high (compared to sequential processing):

Delayed (lazy) variables

Another concept introduced in this library are delayed or lazy variables. These are variables which get assigned a operation which isn’t executed until we really need the result. Seems pretty pointless, but it’s used in some functional programming languages (like Hasekll).


x = RFuture.delay do
   # some operation with an interesting result we may need later on
end

Again, reading the variable doesn’t differ from usual variables:


puts x

Download the file here.


From a programmer’s point of view, the user is a peripheral that types when you issue a read request. —P. Williams

Installing SQLite, Lighttpd, FastCGI and Ruby bindings on Mac OS X

I’ve had a hard time installing SQLite, Lighttpd, FastCGI together with Ruby bindings on OS X, so I thought I could share my experiences.

Continue to full post...

Emptiness

Usually, when I complete a program, not matter how small, I experience a fulfillment of having done something. Everyone knows that it feels great to build things, may it be a Lego town, a Snowman or a simple program to upload blog articles.

This time the only thing I felt was nothing but a hollow emptiness. I’ve spend a good week to understand Enterprise Java Beans. Now I’ve completed a huge part of the requirements and was watching the debug output of my program, waiting patiently for some kind of satisfaction… nothing.

Before working on the EJB assignment, I was working on a password cracker. It took me several days to discover that I had a silly bug and my program from the first day would have done well. Even then I had a feeling of satisfaction. It was fun building the cracker, I could play with a bunch of nice algorithms and do some bit-fiddling. It kept me working for hours without noticing it, even the completion of a small part (a nifty loop for example) gave me the motivation to dig deeper and solve the riddle.

Often the source of this kind of fulfillment is not the end-product itself but the way to get to it, or the way it was build.

I don’t know why it’s completely different with the EJB assignment. One guess is that the whole thing is so complex that I don’t have the feeling of understanding. I could not explain (in great detail) how Enterprise Beans work, not to speak how to implement them. It’s a pity, the aim of EJB is to ease the programmers tasks, now the programming is really easier (but counterintuitive in some cases), but the configuration of the whole thing is insane. I’m pretty sure that I spent 80-90 % of my time figuring out how to write the deployment descriptors and the configuration.

Addendum: I’ve been talking to Ben about this issue. He, as always a step ahead, said that the upcoming EJB 3 specification simplifies the whole story. It’s funny to see the typical complexity curve – at first it goes up until the users don’t get it anymore, then it goes down to an acceptable level. Why don’t we throw out the complexity at first? Ahh, no – that would be too good… .

Time to quote my favorite again:


The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay. —Sir Antony Hoare (oh so true!)

Mobile apps and services

A while ago I started reading Russell Beatties Weblog so, obviously mobile applications caught my interest.

According to his post here 800 million mobiles were sold this year alone, (500 million with camera) – compare these values to 800 million internet PCs (absolute value)!

So it’s pretty much obvious where the next big thing of information technology is: Mobiles!

A lot of products and services got published lately, here a list of interesting and cool applications and services. The list is pretty much Nokia – especially Series 60 – biased since I own a Nokia 6680

Apps:

  • Geominder is one of the most innovative applications I found! It reminds you at a specific location instead at a specific time! Cool idea – it doesn’t even need GPS.
  • Nokia Sensor it’s a nice demo for Bluetooth applications. While reading their intro I thought of a small Webserver with my personal homepage available via Bluetooth – nice idea!
  • KHTML (Safari) Browser for Series 60 3rd ed. mobiles I’m pretty jealous of the 3rd edition of the Series 60 mobiles (mine is a 2nd ed.), but the browser is so cool – you have to watch the demo.
  • Nokias Mobile Search is a simple meta search engine.
  • There is even a Python implementation available!
  • Romeo is a plugable OS X Application. It allows controlling your Mac via a compatible Bluetooth enabled phone – you can also define actions if you come into Bluetooth availability or leave it (eg start playing your favorite music).
  • Virgin Radio free for your 3G phone! I wish data would not be that expensive (1,5 Euro per Megabyte – crazy!) now with the ability to use bluetooth as internet connection it’s a semi mobile radio :-).
  • You don’t like these Java games? Me too, so go out and grab a GameBoy emulator :-) (somewhere is a free version of this emulator, but I couldn’t find it – only it’s source ).
  • Now something completely useless (or is it?): a real HTTP Server for your mobile! Incredible!

Here is a larger list of free mobile apps.

Services:


The future is so obviously in mobiles, why the hell are so many startups still screwing around on the desktop? Morons. —Russell Beattie