shezi's blog

shezi's blog

Johannes Spielmann  //  I am a nerd, and a geek. I do programming for a living as well as for fun. You should check out my business, http://imprys.com/ for the most awesome presentations you'll ever create.

Apr 26 / 1:54pm

Simple APIs

I like simple APIs.

Simple in the sense of small, with few options and few available calls, as opposed to monstrous can-do-everything-APIs. Alright, so maybe I should say small from now on.

Before I tell you why I like small APIs more than bigger ones, let me first tell you why I don't like large ones. There are actually severe drawbacks associated with larger APIs and a bigger selection of available methods and options, but not many people seem to notice, or care.

The first thing that large APIs do with me is make me feel lost. That is obviously true for really large APIs (like the MFC, with which I had first contact when I was fifteen and which probably delayed my programming career by a few years), because there's just so much to see and so much to do that you suffer from the well-known choice paradox as well as sensory overload -- you simply don't know where to look at first, so instead of finding an entry point, I just gave up. But this also applies to smaller libraries where many options are exposed that look like very similar at first glance. Case in point here is the wonderful ELCImagePicker, that I'm using on Imprys. I don't want to bash on this library, it's quite excellent indeed, and I would have had a hard time implementing it myself.

However, and this is the second things that bugs me about large APIs, every time I use the ELCImagePicker, I am left unsure whether I did everything right. Instead of providing a single entry point with a single method and a single callback protocol, I have to compose two classes myself. Two classes. This is about as simple as it gets, but still, it's more complicated than I would like.

Call me lazy (and laziness is probably one part of it), but the more important part is decisions. Programs and program libraries are collections of decisions. The more decisions are encapsulated in a library, the more I can feel safe that these decisions are right in that context, because someone (and probably someone smarter than me) thought about that decision, weighed the pro's and con's of each possible option and then just made the decision. So I don't have to.

This is why I like small APIs: They make me feel safe in my choices.

So what can you do about large APIs? That question is actually quite a philosophical topic, because in a way, each component in a computer program, down to the language you are using, is an API. I think that the only way to handle each and every of these APIs is to make your own, for the situation that you're in. Wrapping lower-level APIs, more or less, because that's what writing programs is, anyway.
So, create a DSL, even if that DSL is "just" a class with two methods. In fact, I think that a class with two methods is probably a really, really good API, and if it fits your program, you should use that. Your program should look like this:

#import "mylib.h"
int main()
{
  mylib.choice choice = mylib.mainmenu();
  mylib.mainprogram(choice);
}  

That, right there, is an awesome program. It's powerful, it does what it's supposed to, I can understand it. And it uses all of its underlying APIs.

And that's why I like simple APIs.
Apr 25 / 11:37am

Starting up again

After my vacation and another week of hanging around, I started up again today. Feels good to be back in the programmer's seat.

Imprys can now do graphics, although they aren't saved in the right format yet, and they don't get exported to HTML, neither. Before that can happen, I will have to restructure my output writer to use a templating system, most probably the wonderfully simple Mustache.

One more annoyance: I've tried to use the Apple-supplied UIImagePicker. There are some strange design decisions in there, for example, in the iPad, you can only show the UIImagePicker in its own UIPopoverController.
Also, it doesn't allow picking more than one image at a time, which feels a bit silly when you try to add ten or twenty images to your presentation. So I've looked around the web and, behold, there is an alternative implementation on Github, ELCImagePickerController, which works beautifully. Until the moment when you find out that this image picker needs to have the Location API enabled and needs access to it. Mind you, none of the images on my iPad is location-encoded, because I have locations disabled. Still, to read the album headings, location API needs to be enabled. Which is a bit of a shame, because for those users that don't have that enabled, I'll have to fall back on the regular UIImagePicker.
Oct 6 / 1:26am

Charlemagne: Keep the fire burning | The Economist

Charlemagne

Keep the fire burning

Why Germany seems not to want a quick fix for the euro crisis

TO HEAR Germany say no to fiscal stimulus, no to boosting the euro zone’s rescue fund, no to joint Eurobonds, one begins to wonder: does it really want to resolve the euro zone’s crisis? Of course we do, most Germans would reply. Is not the chancellor, Angela Merkel, the first to declare that “if the euro fails, Europe will fail”? Is Germany not the main provider of rescue loans to Greece, Ireland and Portugal?

All this is true. Yet Mrs Merkel seems to lack a sense of urgency. Despite the world’s calls for action, she does not believe in bold strokes—be it letting Greece default, or issuing Eurobonds to mutualise governments’ debt. Only a slow, step-by-step approach will work. In other words, the pain, austerity and market turmoil will go on for the foreseeable future.

  • Economist.com/blogs/charlemagne

Even though it pains me to bring attention to a rather silly opinion piece on the Economist, I just have to point out a few things about the piece linked above.

First of all, having a sense of urgency is not the same as panicking, which, to a German, is how many of the bold-stroked measures implemented by the USA or Great Britain feel like. "How much money can we find to just give away?" is not a position I would like my government to take.

Second, I object to the off-handed description of Germanys institutions. The "complex federal system" isn't any more complex than any other federal system, like, say, that of the USA. A sceptical public is a good thing for a democracy. Coalition politics are about finding compromises and will only appear messy to someone coming from an either/or-system, which feels very primitive to many Europeans. And finally, "jealous institutions such as the constitutional court"? Really? Jealous? A working, well-respected institution that upholds the central law code of a country is "jealous"? This, as well, coming from a resident of a country where the constitutional court feels like just another venue for political puppery, doesn't actually feel like an insult and instead more like a praise.

Third, there is growth. I don't want to comment more on that topic than saying that "X is weakening growth, thus X is bad" is not a valid argument until you have proven that growth is important. I know that many people assume this automatically in the United States, but it's not a given in other places. And, at least from time to time, you should think about it.

Then there are the weak arguments. Charlemagne quotes that one problem with seeing slow steps as a problem "is that market panic can become self-fulfilling, in many different ways". This is supposed to be an argument against a transaction tax. A tax that would temper the possibility for panic and create a cushion for when it occurs is held as an argument against that tax.

And, finally, there is the obsession with the german language. Yes, "Schulden" does share the same stem as "Schuld", just like, for example, "candidate" and "candid" share the same stem, even though most candidates aren't. Or "champion" and "Kampf" (which means struggle or fight). Language is a strange beast and goes wounded ways. Bringing up the similarity between Schulden and Schuld (which, by the way, also means "debt" in this context) feels like filling up for missing real arguments. Oh, and also, bringing up the protestant past for a country where less than half of its inhabitants believe in any spiritual force isn't really a strong point, either.

Actually, the more I read this piece, the more I get the feeling of a very strong cognitive dissonance. On the one hand, Germany is bad for letting "the fires burn", on the other hand, Germany seems to be very stable and financially secure at the moment. It's sad that even such a careful observer as Charlemagne seems to be likes to forgo arguments for rhetoric once in a while.

Sep 29 / 2:16pm

A very nice experience

Today, I joined Bitbucket. A friend invited me. And, I must say, I am very pleasantly surprised. I have used Github before, but I just can't get warm with git, and of course that colours the experience for Github.

However, the experience for BitBucket is also very friendly, and very simple. They even send you a welcome-email with pointers to the next steps, including a tutorial for newbies and a tutorial for Subversion switchers.

And one factor, naturally, is always price. BitBucket has the best price you can get, because it's free. Other than GitHub, you can have as many repositories as you want, and as long as you don't have more than five collaborators, everything's free.

If you're interesting in trying out a DVCS, or find a nice host for Mercurial, I urge you to try BitBucket.

Sep 22 / 3:25am

Foreign code

On last weeksSea Of Memes the topic of using libraries, working together with other people and copyright issues came up.

Then, a few days later, Shamus Young discussed the article on his blog Twenty Sided.

I disagree, with both of them, on almost all the issues raised.

The first issue is "working with strangers". Here's the quote:

I'm also trying to learn things about graphics programming and game programming. You don't really learn something unless you try to do it yourself. Using a big multi-platform library or an existing game engine wouldn't teach me much.

Then there's the problem of debugging. Things go wrong and you need to isolate the problem down to a particular piece of code. It helps enormously if you've written it all yourself. If other people are working in the same area, it's practically impossible to know whether the bug was caused by the thing you just changed, or by someone else's change. It also helps that I know my own style and the kinds of mistakes I tend to make.

I commend mgoodfel on his journey to learn an interesting skill and work his way towards a fully self-written game engine. I'd like to do that myself some day, so I understand that he wants to write most of the code himself. That shouldn't stop him from collaborating with other people towards this goal, however. In fact, most of the things I learned didn't come from myself sitting in the basement doing it alone, but from talking to other learners about it and talking them through my thought process, oftentimes finding crucial flaws in my thinking. Of course, listening to someone else's thought process and finding their flaws, all the while seeing a wholly different position. In a way, Sea Of Memes is mgoodfels way of achieving this, whereby he writes down his thought process, then waits for comments from his readers. He even states this specific goal in Part 29:

The writeups revolve around the code. A part gets done when I get a piece of code running, not on any regular schedule. And then I wait for feedback, either downloads of the demo, or comments or both.

But still, to me, it doesn't feel like collaboration, it's more like an improv performance, where the audience is allowed from time to time to yell a word or two about the next piece mgoodfel should perform and how it should look like.
What's even worse, there is a simple system that would address the issues cited above, as well as mine, and that is GitHub. The workflow for an open-source GitHub project is like this: You create a repository, then push your initial state there. Everyone can see this code and do a "fork", i.e. copy the repository into their own account, then check it out and work on it. Meanwhile, you've worked on it yourself, pushing code to the public front end only at times you choose (kind of like putting them into a Zip file on your blog, only that it's easier to see what changed). If someone else wants to take your code and work towards a different direction, that's fine because you won't even notice. If someone wants to contribute to your code, they push a change that implements what they want to show/give you and open a "Pull Request". This means you get a message that someone wants to contribute, a patch in regular diff format and a button that says "Do it!". You'd then read through their patch, thinking about the consequences the integration has for your code, thereby making it your own, and if you're satisfied with the integration, you pull it into your repository, merging the change. If you're not satisfied, you simply ignore the request. Happens all the time.
The point I'm trying to make is this: Pull Requests open your code up for collaboration if you choose to integrate. If not, you still saw someone else's thinking, which is always a good thing.

Oh, and you know what: The internet doesn't care when you're awake. It doesn't matter when you pull, when you push and when you work on your code, because everything is asynchronous. You and all of your potential collaborators, work at their own times, paces, and work styles.

The second issue that comes up is libraries. Here's what Shamus Young writes about using libraries:
Using code from strangers is always a gamble. Sometimes, on rare circumstances (perhaps only a few occasions in your career) the clouds will open and you’ll find yourself in a beam of sunlight, looking at a link to the perfect library while angelic music plays. It does happen. But more often than not, you run into the usual chain of dependencies, missing files, lack of documentation, version incompatibilities, inscrutable bugs, missing features, and poor programming interface.

To me, that sounds as if Mr Young was burned by some libraries or code snippets he tried to use for his own project, Project Frontier. It sounds as if he sees libraries as a time-saving tool. When he needs some functionality in his program, he thinks about the quickest way to achieve that functionality, which might be (a) writing it yourself or (b) taking code from someone else to do what you need. If you see it like that, then yes, every library is a gamble, where you wager time and hope to win back that time by not having to write the code yourself, i.e. you invest some time into integrating and probably bugfixing and working with the library, and earn back the time by saving implementation time. If the library is good, you have made a net time win, where you have the functionality quicker with option (b) than option (a). If you find out that the library isn't for you and "give up", your investment is lost and you'll have to start anew.
That's a bleak way to look at libraries, I think. To me, libraries are about focus, and not losing it. To me, the choice isn't "how much time will this cost?", instead it's "how well does this fit into my vision?". So, I ask myself: "Do I really want to write a JPEG loader?" and "Do I really want to mess with certificates myself?" (a topic I will discuss in the post after this one), or "Do I want to write a Minecraft chunk loader?". Some of the times, the answer is no, some of the times the answer is yes. When the answer is no, I'd rather spend an hour or two banging some library in shape and massaging my own code instead of looking at byte-descriptions and file signatures, until the question becomes "Do I want to maintain this ****** library or find some other way?", when I probably give up.

The third issue mgoodfel brings up is copyright and patents. This is a hairy one, and I can understand that he's afraid of being sued. On the other hand, what could anyone win from suing him? He doesn't appear to have a lot of money and if you wanted to stop him from distributing or using some piece of code, it'd probably be more effective to ask him. Most of the disputes in that area are settled out of court, anyway, and I don't think one should be scared by the way big companies with huge cash reserves behave towards each other. Also, note that Samsung and Apple are still cooperating on other areas of their businesses.
Perhaps I am too young, or haven't been burned by issues like these, or I am in a jurisdiction where it's easier to handle, but I don't think a programmer should care too much about patents, lawsuits and unintentional breach of copyright. In fact, my feeling is quite eloquently summarized by pud, when he writes "Fucking Sue Me".

So, there you have it. My personal, completely unfounded opinion on why you should do everything differently than you do. Note, again, that these are my opinions, my suggestions for thinking about it, not requests that anyone change anything about the way they do what they want.
Sep 16 / 10:25am

What’s wrong with this code, really? | CV Mountain.com

Media_httpcvmountainc_xbcja

A very nice example of bad, but correct code and the rationale for replacing it with a cleaner, better version.

Sep 15 / 1:40am

A powerful demonstration of Ghostery

I have used the excellent Ghostery for a few weeks now. What it does is it blocks a long list of web tracking and ad network services to make your browsing more private. Every time Ghostery blocks a service, it shows a little bubble with a message what was blocked. This way, you can easily see, who's tracking your browsing how. Also, it's simply interesting.

For example, this is yahoo.com:

Screen_shot_2011-09-15_at_10

google.com doesn't show any warnings, so I guess they track you on their servers, which you cannot block, of course.
For comparison, here's techdirt.com, anandtech.com and engadget.com

(download)

It's amazing that techdirt places a whole ten different services on their page that can track you. However, the funniest thing happened today, when a website I visited used Clicky (getclicky.com). I hadn't heard of it before, so I went and took a look. Unfortunately, they use similar addresses to their tracking scripts on their web page, which Ghostery blocked. The feature comparison chart is especially nice:

3screen_shot_2011-09-15_at_10

Well. That's a hard choice, there... =)

Sep 14 / 4:30pm

Focus puller - Wikipedia, the free encyclopedia

From Wikipedia, the free encyclopedia

A focus puller, or 1st assistant camera operator, is a member of a film crew’s camera department whose primary responsibility is to maintain image sharpness on whatever subject or action is being filmed.

“Pulling focus” refers to the act of changing the lens’ focus distance setting in correspondence to a moving subject’s physical distance from the focal plane. For example, if an actor moves from 8 m away from the focal plane to 3 m away from the focal plane within a shot, the focus puller will change the distance setting on the lens during the take in precise correspondence to the changing position of the actor. Additionally, the focus puller may shift focus from one subject to another within the frame, as dictated by the specific requirements of the shot (cinematic techniques).

A good focus puller will have an intimate knowledge of cinematographic and optical theory. Depending on the parameters of a given shot, there is often very little room for error. As such, the role of a focus puller is extremely important within the realm of a film production; a “soft” image will, in most circumstances, be considered unusable, since there is no way to fix such an error in post-production. One must also consider that an actor may not be able to duplicate his or her best performance in a subsequent take, so the focus puller is expected to perform flawlessly on every take. Because of these factors, most production personnel consider the focus puller to have the most difficult job on set.[citation needed]

Today I learned that there are many, many people, measurements, time and work involved in making sure that films stay in focus. It's a lot more complicated than I thought and explains long filming schedules and budgets. Amazing!

Sep 11 / 3:07am

Software’s Receding Hairline - raganwald's posterous

Interesting comparison between a comb-over and software development in the sense that both are the result of years of waiting for the right moment to change something.

Sep 1 / 6:12am

Today I learned something

So, yesterday was a good day, because I finally got a push to do something about my lingering ambitions. And that's what I did today. In the process, I learned that the MacOS X is not as stable as I thought.

As I was playing around with a simple application for monitoring the system clipboard (called Pasteboard in MacOS X), I managed to corrupt the clipboard. After my application quit, any other application that would try to access the clipboard would go into an infinite loop.

I have put some proof-of-concept code on GitHub, under https://github.com/shezi/ClipCrash