The Exciter

Pausing and controlling the speed of Core Animation

2012-03-24T10:47:00+01:00

Core Animation is one of the finer frameworks in the SDK, it abstracts away a lot pesky details in a declaritive way. What declaritive means here is that you tell a CALayer to, for instance, go somewhere by changing its position property and it’ll animate it’s way there. You can also build up your own animations with the varius CAAnimation subclasses, such as CABasicAnimation and CAKeyframeAnimation. With these animation classes you set various properties (to/from values, keyframe values) along with things such as the length and the timing function, but I became curious on how one would stop an animation “mid-flight” or change the speed once it has started. Turns out it’s fairly easy.

Stopping and resuming animations

In Core Animation, time is modelled in a tree-like fashion, with the speed of one animation being relative to the speed of its parent animation. What that means that if you set a child animation to take 10 seconds it’ll still take 10 seconds, however, if you change the speed of the parent animation any child animations will will change its speed relative to that. Both CAAnimation and CALayer’s themselves adopt the CAMediaTiming protocol which models this time space relationship.

Like Apple describes in this Technote, in order to pause an animation you set the speed to 0.0 and its timeoffset to the current time (relative to its parent time). It may seem counter intuitive that just settings the speed to zero isn’t enough, but if you only did that then it would simply return to its initial starting point as we don’t freeze the time and the speed property simply maps the child animations time space from its parent time space.

layer.speed = 0.0;
layer.timeOffset = [layer convertTime:CACurrentMediaTime() fromLayer:nil];

Starting it involves setting the speed to 1.0, but also finding the current timeOffset (where we paused it), resetting it, and setting the beginTime based on the time difference between now and when it was paused so the animation will start exactly from where it was paused.

layer.speed = 1.0;
CFTimeInterval pausedTime = layer.timeOffset;
layer.timeOffset = 0.0;
layer.beginTime = 0.0;
CFTimeInterval timeSincePause = [layer convertTime:CACurrentMediaTime() fromLayer:nil] - pausedTime;
layer.beginTime = timeSincePause;

Slowing down time

Slowing down time or speeding it up becomes easy once we learn how Core Animation maps time spaces:

layer.timeOffset = [layer convertTime:CACurrentMediaTime() fromLayer:nil];
layer.beginTime = CACurrentMediaTime();
layer.speed = 0.5;

Chaning the speed of an animation means we have to change the speed obviously, but we also have to remap the time space into the current time. So we set the timeOffset to the layer’s current time and the beginTime to our global time.

I haven’t actually had a use for this in a real app, as it was one of those “I wonder how…” moments, but it might be useful for someone out there.

Headphones

2012-01-12T19:12:02+01:00

If you spend any amount of time in front your computer with headphones, you should invest in a decent pair. Just as you should invest in a decent desk and chair. I’ve been through a few headphones, from cheap and crap to expensive and wonderful and even expensive and crap.

Listening to music is very much an individual taste whether it’s genre or how the music actually sounds through a pair of speakers or headphones. Audiophiles will spend the gross national product of a small country (and half of that on cables) to try and figure it out, but even if you’ll only invest a smaller amount (say $170-$600), you’ll hear a difference when it comes to headphones and it’s definitely something I recommend investing in if you enjoy listening to music all day long. Even a specialized headphone-amplifier can lift some dull-sounding headphones to new heights.

Requirements

I have the following three requirements for a pair of headphones:

Comfort

They must be comfortable. No point in having a pair of expensive headphones if you can’t stand to wear them. In a perfect world you should forget you’re wearing them completely.

Things that may affect comfort are weight and how tight they clamp on your head and ears. Personally I only want to use full-size (circumaural) headphones, it’s the only kind of headphone that I can easily forget is there, as over- or in-ear headphones have a tendency to physically remind me that they’re there all the time either by squeezing on my ear or itching.

Sound quality

Sound quality must be enjoyable. They don’t have to measure perfectly on some random audiophile scale, but the sound must not wear me out or sound artificially enhanced. Those two usually go hand in hand, as headphones that enhance for instance the bass will over time wear my ears out due to being pumped full of bass all day long.

I find that I prefer headphones that seem light on bass when you try them in the store compared to other offerings, but when you get home and listen to them for extended periods my ears don’t get as worn out as with a pair of bass-heavy ones. The same goes for the upper tones, constantly having those high tones tickling your ears gets weary as well. So fairly neutral is what I’m going for in a pair of headphones.

If you troll any random audiophile forum you’ll read much about some hunt for the magically neutral sound, but with a wide soundstage that makes you feel like you where transported to the same room where the recording took place. Which is of course like hunting for a unicorn, the sound is already mutated by the microphone(s’) placement and how the sound engineer mixed the sound. The kind of neutral I’m hunting for is the kind that makes my ears feel comfortable and the music sound enjoyable, according to my own mental impression and scale.

No unwanted noise leaking

This one is optional. But not if you use them in a public place, whether that’s on the subway or in an office. Doesn’t matter if everyone share your taste in music, no-one wants to hear your muffled noise. At the office I only use closed headphones, in my home office I got a pair of open ones as I’m not likely to disturb any else in the same room.

There’s a tradeoff here between open and closed headphones, as open headphones generally tend to sound better, since it’s easier to control the sound as it doesn’t bounce around next to your ear so much.

Remember, not everyone listens to music when they work and they’ll hate you if they can hear you listening to something through your open headphones.

Ohms & Amplifiers

Generally headphones are rated, among other things, in impedance as a measure of how much power is required to drive them. As a rule of thumb, if your headphones have an impedance above around 32 Ohms your average computer, laptop or portable music player isn’t going to be able to drive them reasonably and you need an amplifier in-between.
Luckily the market for headphone specific amplifiers are equally vast (and confusing) as the actual headphones themselves and you can easily break your budget on these things as well. Not only that, but they also affect the sound a bit, making it sound “warmer” or “colder” or with less or more bass and so forth. But unless you’re a total audiophile the difference is negligible, but certainly something to pay attention to as it’s noticeable.

My headphones

I’ve been through a lot of headphones. Let’s take a look at some of the recent ones, there’s both good and terrible purchases here. I’m not going to do a full review here as frankly I’m not authoritative enough on this, but these are a few of my choices from the past year:

AKG K-271 MKII + Maverick Audio TubeMagic D1

My current office setup at work. While the K 271 will do fine without an amp, they really shine when they receive a bit of power. The TubeMagic D1 really makes them open up a bit more than straight from the iMac’s audio jack. The D1 is a tube amplifier but sadly you don’t get to hear any of those smooth tubes when using the headphone jack, only through the RCA analog out. Still the D1 is a dirt cheap DAC with decent quality and enough power to drive most headphones.

Monster Beats Pro

This was one of those regrettable spontaneous purchases. They fooled me completely, bought when I was at WWDC in San Francisco and sold when I got back to Norway. They enhance bass. They enhance bass a lot. They enhance bass a metric ton.

They ~~impressed~~ fooled me at the noisy store but when worn for any length of time the enhanced bass just got annoying and wore me out, in addition to the weight. All that aluminum really makes them heavy.

I really regretted buying ever buying these, probably because I mostly felt fooled when I got home and compared them to me existing headphones, so they got sold again quickly. One of my coworkers swear by them though, so each to their own.

Hifiman HE-300 + Nuforce Icon HDP

My home office setup. The HE-300 is currently my favorite pair of headphones. They’re open headphones so sadly I can’t use them at work, but I just love sitting and listening to these at home. They’re rated at 32 ohms so they can be driven by an iPhone or laptop, but like the K271 they really open up when given some power from an amp. The Nuforce HDP gives plenty of power to these and has a very good USB DAC (better than the TubeMagic D1).

Parting words

Must of the music I listen to is of the instrumental kind, various kind of classic and heavy rock all the way up to metal, so the choices above mostly reflect this and as you’ve already guessed I’m not a fan of artificially enhanced bass as it easily drowns out other details on headphones in this price range.

Like most gadgets, spending a lot of money upgrading headphone gear is easy once you get into it, but sooner or later you’ll find a sweet spot of price versus performance for your taste where upgrading doesn’t make any sense. While I’ve occasionally contemplated toying with other amplifier combinations I’m currently satisfied enough with my HE-300 setup at home and the K-271 at work.

You should buy some decent headphones. Try a few different ones first as there’s quite a difference and it is very much a matter of taste, but the reviews don’t always reflect that.

A scrollview in a tableview cell, properly

2011-12-21T08:58:02+01:00

Looking at what search terms people use to find this site I see that my article on embedding a UIScrollView inside a UITableViewCell is among the ones that gets the most hits. Which is a shame since that approach is a terrible way of solving it these days.

After iOS 2.1 (or iPhoneOS as it was called back then) or thereabout that terrible responder chain hack is no longer needed, all you need to do is add the scrollview as a subview of the cell and you’re good to go:


- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    return 50.0f;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *cellIdentifier = @"ScrollCell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier];
    if (!cell) {
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier];
        UIScrollView *scroller = [[UIScrollView alloc] initWithFrame:CGRectMake(0, 25, 320, 25)];
        scroller.showsHorizontalScrollIndicator = NO;

        UILabel *contentLabel = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 320*4, 25)];
        contentLabel.backgroundColor = [UIColor blackColor];
        contentLabel.textColor = [UIColor whiteColor];
        NSMutableString *str = [[NSMutableString alloc] init];
        for (NSUInteger i = 0; i < 100; i++) { [str appendFormat:@"%i ", i]; }
        contentLabel.text = str;

        [scroller addSubview:contentLabel];
        scroller.contentSize = contentLabel.frame.size;
        [cell addSubview:scroller];
    }

    cell.textLabel.text = [NSString stringWithFormat:@"cell #%i", indexPath.row];

    return cell;
}

Nothing fancy going on here, just creating a scrollview, add a wider subview, set the contentSize of the scrollview and add it to the UITableViewCells view hierarchy.
I usually prefer to use a UITableView subclass instead of setting up cell view hierarchies in the view controller, but you wouldn’t just copy-paste example code without thinking now would you?

Nibs vs. code, a journeyman's perspective (or lack thereof)

2011-08-06T01:18:02+02:00

Like all languages and frameworks, Cocoa has some topics that will polarize its programmers. This one isn’t about dot-notation, for once, but laying out user interface in nibs/xibs (interface builder files) versus building it in plain old Objective-C code. With nibs (even though their modern extension is .xib) you layout the user interface ín a graphical UI and connect it with your code. With code you allocate, initialize and place the UI element(s) entirely in code, most likely within your controller.

First things first, at its core programming is a discipline of balance. Balance with performance and implementation time. Balance between readability and understandability. Balance between implementation time and understanding it in one, two, twelve months from now ad infinium.
Some times it’s faster to add some UI elements in code, sometimes it’s faster with nibs. That’s the diplomatic aspect, let’s try and look at in what situations you might prefer one over the other, enumerated as a list since my editor let it slip through;

I like nibs when I have to layout UI elements from a mockup or “final” design.
I like nibs when I got the feeling my designer will change his mind and he can edit the nibs himself, or sit next to me dictating where the elements should be.
I like nibs when there’s lots of graphical elements to layout; writing code, compiling, running, editing, recompiling running is slower than seeing it WYSIWYG-ish in interface builder.
I like code when there’s dynamic “things” involved, except when it’s combined with one of the above, then it’s faster to just hook it up with an outlet.
I like code when I have to place elements relative to other elements (and I can’t use auto layout), as long as I cannot make it work with autoresizingMask’s in the nib.
I like nibs when it means there’s less -layoutSubviews or -initWithFrame: boilerplate code to scroll past.

The last one is probably the most important to me. A lot of programmers seem to take a Conan the Barbarian approach to code; “if you do not like code, then TO HELL WITH YOU” and forgetting that when they look at the code in six months from now they’ll wasting time scrolling past code that may be important layout logic or just simple layout logic or worst of all, they’ll waste lots of time compile-run cycles trying to get their CGRect’s to align properly.

Code is craft, crafting is balance between getting your message across and getting your message out there. And sometimes there’s not a single right answer. That’s what makes this profession a craft, the hard part is often crafting it together in a team.

Migrating from Google Apps email

2011-08-05T23:37:02+02:00

I’ve long been a paying user of Google’s Apps for Your Domain, in particular the email aspect of it. I don’t care for online documents, spreadsheets, buzz or whatever random flailing product they shove down your throat, only email. The web based gmail client showed the world how web applications should be done, for better or for worse.

One thing is the constant slowdowns, the 10-30 seconds waiting time for something to happen. The other being a matter of trust. Is it really wise to have so many things hosted and logged with one single provider? One who so obviously has only figured out how to earn money one one thing; namely selling your content and data for advertising? I decided it wasn’t.

I almost like the gmail interface, it’s one of the better web apps out there. But it still has all the flaws of a web app, along with questionable motives from its provider.

So in an effort to minimize risks, or at least distribute them a bit further, I decided to change my personal email provider away from Google to fastmail.fm.

My personal email address (first name @ johansorensen.com) has mostly been functioning as a dumpster for all sorts of email: some personal, but mostly mailing lists and automatic notifications from various projects I’ve either worked on, with or somehow needed temporarily knowledge of the development of. In other words, and non-practical implementation of the hoarding syndrome. Which sucks. So, a few days ago I unsubscribed from every single mailing list except a few and deleted seven gigabytes of archived email (of which I’ve contributed only a few megabytes), changed my MX records and am now only using fastmail.fm through IMAP. Click. Click. Done. Almost.

The migration was slightly annoying as Google has some pretty strict bandwidth and/or usage limits in place, preventing you from downloading all your email at once (ding ding), so the actual migration consisted of downloading all IMAP mailboxes over a few days, and re-uploading them to the fastmail.fm IMAP account (fastmail didn’t have any arbitrary limits in place preventing me from doing with my own data as I saw fit).

Email was a solved problem long before Gmail. My email is now stored offline and owned by me, I can move it anywhere I want to. With modern tablets and smartphones, “access anywhere” is also a solved problem.

Distributing your online “cloud-ness” is a must, don’t put all your personal data with one provider, no matter how much you trust them. It’s like backups; if you have them all in one place, you’re going to get burned sooner or later.

Diffing images with Core Graphics

2011-04-10T18:00:00+02:00

Few of the popular version control systems treat images as much more than the binary blobs they technically are. So it’s up to third party tools such as Github or Kaleidoscope to provide more reasonable and user-friendly means of comparing images.

On a whim, let’s explore how to implement one of the ways the above tools provides image comparison with Core Graphics; difference comparison. Conceptually it means we’ll blend the new image onto the old image and subtract any pixels that are different from the other and pixels that are unchanged will be black. It’s the same blending mode you’ll find in image editors such as Photoshop and Pixelmator.

Doing it with Core Graphics is pretty easy: draw the old image as-is into a drawing context, change the blendmode and draw the new image and extract the composed image.

First we need a method for creating a CGContextRef from a CGImage. I like boilerplate things like this to stay out of the main method and live in its own private method:

- (CGContextRef)createCGContextFromCGImage:(CGImageRef)img
{
    size_t width = CGImageGetWidth(img);
    size_t height = CGImageGetHeight(img);
    size_t bitsPerComponent = CGImageGetBitsPerComponent(img);
    size_t bytesPerRow = CGImageGetBytesPerRow(img);

    CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
    CGContextRef ctx = CGBitmapContextCreate(NULL, // Let CG allocate it for us
                                             width,
                                             height,
                                             bitsPerComponent,
                                             bytesPerRow,
                                             colorSpace,
                                             kCGImageAlphaPremultipliedLast); // RGBA
    CGColorSpaceRelease(colorSpace);
    NSAssert(ctx, @"CGContext creation fail");

    return ctx;
}

In other words, pretty much standard Core Graphics creation of a CGContext. In this example we just extract the size and pixel format from the supplied CGImageRef. As per normal Cocoa memory semantics we return an object which the caller is responsible for releasing since our method starts with create.

Now for the actual blending of the two images, represented as the _oldImage and _newImage UIImage’s:

- (UIImage *)diffedImage
{
    // We assume both images are the same size, but it's just a matter of finding the biggest
    // CGRect that contains both image sizes and create the CGContext with that size
    CGRect imageRect = CGRectMake(0, 0,
                                  CGImageGetWidth(_oldImage.CGImage),
                                  CGImageGetHeight(_oldImage.CGImage));
    // Create our context based on the old image
    CGContextRef ctx = [self createCGContextFromCGImage:_oldImage.CGImage];

    // Draw the old image with the default (normal) blendmode 
    CGContextDrawImage(ctx, imageRect, _oldImage.CGImage);
    // Change the blendmode for the remaining drawing operations
    CGContextSetBlendMode(ctx, kCGBlendModeDifference);
    // Draw the new image "on top" of the old one
    CGContextDrawImage(ctx, imageRect, _newImage.CGImage);

    // Grab the composed CGImage
    CGImageRef diffed = CGBitmapContextCreateImage(ctx);
    // Cleanup and return a UIImage
    CGContextRelease(ctx);
    UIImage *diffedImage = [UIImage imageWithCGImage:diffed];
    CGImageRelease(diffed);

    return diffedImage;
}

Core Graphics will do the hard work of subtracting the pixels, even if the two images are of different formats or sizes, however the example here doesn’t accommodate different sizes to keep things brief.

I always enjoy working with Apple’s C-based APIs, they’re often well designed both when it comes to naming and functionality, while feeling strangely familiar due to their memory management semantics.

Command line arguments with NSUserDefaults

2011-02-20T12:30:00+01:00

Whenever I’m in need of some quick and dirty command line arguments for a simple tool, I find using NSUserDefaults to be the easiest:

$ ./mjau -input mjau.m
#import 

int main (int argc, const char * argv[])
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    NSString *inputFile = [[NSUserDefaults standardUserDefaults]
                           objectForKey:@"input"];
    NSStringEncoding usedEncoding;
    NSError *error = nil;
    NSString *content = [NSString stringWithContentsOfFile:inputFile
                                              usedEncoding:&usedEncoding 
                                                     error:&error];
    if (error) {
        fprintf(stderr, "Error: %s\n",
                [[error localizedDescription] UTF8String]);
        return -1;
    }
    fprintf(stdout, "%s\n", [content UTF8String]);

    [pool drain];
    return 0;
}

No need to bother with getopt(3) if you just need some simple option parsing.

Of course, this also means you can use it to set existing NSUserDefaults from the command line. One such useful toggle is the -NSShowNonLocalizedStrings YES default, turning non-localized strings into all caps making them easier to spot.

It's the message

2011-02-11T17:30:00+01:00

Nokia/Microsoft

“By leveraging new synergies in partnerships that will escalate our mindshare to new global opportunities beyond this fiscal year we’re securing valuable fluff. Also, we’re still committed to Symbian and Meego. Except when we’re commited to Microsoft. Maybe next year. We’re not really sure what’s going on here either.”

Google

“We, the largest technology and advertising business in the world, is here to save you from an entirely different draconian future than ours. Also, we’re like open and junk and if you can’t update to Cherrybomb just tell your mom to flash her ROM!”

Blackberry

“Something something business something. Something QNX. Something something Flash.”

Apple, and now HP/Palm

“Here’s our things. This is what they do and this is what you can do with them.”

Simplified and obviously subjective, but which one of the above can the consumer relate to?

Passing on the Gitorious torch

2011-01-12T21:22:00+01:00

My initial, and the very first, commit to Gitorious was august 14th, 2007. It all started as scratching an itch I had about hosting my own Git repositories, eventually it was adopted by many others, then by commercial open source projects such as Nokias Qt and MeeGo and behind-the-firewall installations. My company did consulting and other work on custom features for Gitorious.org and custom installations.

Last year I started spending most of my time and energy on Objective-C and Cocoa applications again, while one of my fellow co-founders Marius kept chugging along and I did less and less work on Gitorious. Eventually we decided to formalize this whole arrangement.

Gitorious is now a wholly owned subsidiary of Shortcut, employing Marius and Christian full time. They’re running the show and got the keys now, which is great for all parties involved; I get to focus on other things, and Gitorious receives the full attention it deserves, while being developed and maintained by a company devoted exclusively to its cause.

Focusing on the Canon 7D

2010-12-28T23:57:00+01:00

Close to a decade ago I did a lot of photography, mostly black and white since I had free access to a darkroom but also with the one of the first digital flagships, the Nikon D1 with a whooping 2.7 megapixels. Film vs. digital was still a topic then. Then I went and pursued interests and the prosumer part of my photography was put on standby, apart from a short stint with a Konica-Minolta digital body (shortly before Sony bought their SLR division).

Earlier this year I decided to give it another go, bought a Canon 500D and some lenses. Thousands of exposures later (and relearning the tricks of the trade again) I upgraded to the 7D a few weeks ago.

One of the nicer features if the 7D is the focusing system, while it seems Canon is still behind Nikon a bit on this, they’re making progress. My favorite customization of the 7D is moving the half-press-shutter-to-focus to the AF-On button and setting the half-press shutter button to “metering start”. This is done under the “C.Fn IV” screen.
This allows me to stay in the continuous autofocus mode, while still being able to use the classic “focus, then recompose” approach, without losing the ability to quickly move to continuous focus on moving subjects, just by keeping the AF-On button pressed.

The problem I’ve always had is that by the time I’ve changed my camera focus setting from single shot to continuous autofocus whatever action I wanted to capture is long gone. Staying on continuous autofocus and remapping the focus button to the AF-On button allows me to keep the best of both worlds; focus, then recompose for single shots and continuous focus to nail the action, coupled with the 7D’s ~8 fps continuous shooting mode.

Why Google TV is fundamentally flawed

2010-05-21T09:57:02+02:00

Yesterday at Google’s I/O event they announced Google TV. It seems that Google is starting to look more and more like the Microsoft of the 90’s; partnering up with OEM vendors to get their products in front of as many people as possible. Granted, many businesses, if not all, partner with other businesses, but the Microsoft analogy seems more fitting than ever these days.

However I think that their approach for interaction is fundamentally flawed. In fact, I think everyone, such as Boxee and Apple TV, gets it completely wrong, especially as (or rather; if) they start to “enrich” their products with things such as web browsing and apps.

The problem is that they’re all viewing the TV is an input device, meaning that you interact directly with it via some kind of remote or keyboard and mouse-like device (or worst of all; an actual keyboard and mouse). This may make sense if you think of the TV as a “some kind of PC”, or because people of recent generations have always interacted with the TV via a remote.
However, as soon as the interaction goes beyond simple things such as volume control and channel flipping it becomes extremely painful. If you’re browsing a website you’re in a world of pain, even the on-stage demos looked extremely painful to navigate (if you look beyond the amount of technical issues with remotes/keyboards dropping connections and the terrible presentations with other presenters mumbling on the mic in the background while the main presenter was talking, I’ve seen high-school presentations better than that).

The TV shouldn’t be viewed as an interactive terminal, but rather as a passive projector that receives its input from other things. Imagine instead if the remote for a storage, OS and video-decoding “media box” was an iPad(-like) tablet on which you did all the interactions and the TV simply mirrored those when you where browsing, or presented the results of such interactions, like playing a show from a playlist you just created.

By interacting with the device directly in front of you, through a touch interface, you’ll have a much more user-friendly interaction model, especially when browsing but also when browsing the content on the media box and creating playlists, viewing IMDb entries on the movie you’re about to watch (or while watching it). Need to show other people what you’re viewing? Just flip on mirroring directly to the TV, or select an item from the tablet to play on the TV. Easy, fast and much more enjoyable.

Simple interactions works fine with a simple remote, but if there’s a lot of button clicking and text input having to do it in such a detached manner from the screen is a terrible idea, and the Google TV demos was chock-full of buttons and text input.

Why you wouldn't want to write your mobile application in a dynamic language

2010-04-12T21:36:42+02:00

With the current flavor of the week being a certain new section in Apple’s iPhone SDK license, there’s no shortage of sane and not-quite-as-sane commentary being thrown around. This post isn’t really about that, but it has triggered some people to argue that they should be able to write their applications in Ruby or any other interpreted language. Which shows that they either have no clue about mobile platforms, or think their users’ device is something they can just abuse at will.

I love Ruby, but it has little place running an entire application on a mobile device, as awesome as that would be. On a device (fruit logo engraved or not) with limited processing power, memory and battery time, do you really want to run an entire application that ~~wastes~~ spends many CPU hours just interpreting things? I’m pretty sure your potential users would have an issue with your application draining the battery much faster than your competitors application, or using substantially more memory.

“CPU time is cheap, programmer time is not” has become the mantra of the dynamic language world, with good reason. But it falls short when you’re no longer running on a machine with 16 or more CPU cores and eight gigabytes of RAM. In fact, if you spend some time reading through the iPhone SDK APIs you’ll find numerous encouragements to be mindful of battery use (I imagine the same being true for Android and other mobile platforms as well). CPU time and memory is the currency your application has to trade, if you waste it your users will not be too impressed with either your application or the platform as a whole (for good or for worse they reflect upon each other), both being a very bad thing for you.

Moore’s law of course applies to mobile CPUs as well, the difference between this years hardware and the previous one is significant regardless of manufacturer, but it’s more of a steady improvement than a giant leap forward, so you don’t quite have the luxury to trade in all your programmer time for CPU time just yet since there’s only so much to go around.

There’s also some interesting economics in this from the perspective of the mobile device manufacturers. Faster CPUs are more expensive, so if you can provide adequate performance at a reasonable price (cheaper CPUs means cheaper hardware for consumers, thus a competitive advantage) by only using a compiled language in your SDK (along with an API to save even more resources for things such as multitasking), then we’re suddenly talking about a significant difference in dollars and cents.

If your entire SDK is fairly resource intensive, such as Palm’s WebOS (both rendering HTML and interpreting javascript is a significant investment for a mobile CPU), then your device suddenly becomes much more expensive and it’ll still run out of battery in less than a day. The internet reviewers and know-it-alls does not approve of such shenanigans.

A Late Note About Recent Gitorious Developments

2009-05-20T10:02:42+02:00

Just under a week I deployed a new version of Gitorious.org and announced some big changes, not only in functionality but also some things that’ll make Gitorious live long and prosper.

The non-technical stuff

On the non-technical side, one of the bigger changes is that Gitorious is now officially a Shortcut production. Shortcut is a company I started together with three other gentlemen at the beginning of last year and we’re now a six person company who has been making money since day one, financial crisis or not. With Shortcut maintaining and developing Gitorious.org, as well as keeping Gitorious open source, we now have additional resources to bring the project forwards beyond what was feasible for me as a single developer doing Gitorious in my spare time.

A few months ago I was invited to the Qt offices and as it turned out they where running their own internal installation of Gitorious. Qt Software has been keeping busy since they got acquired by Nokia last year and one of the reasons I was invited was that they wanted to use Gitorious.org as the platform for the contribution model for the (then to be announced) LGPL licensed Qt products.

For the past few months Qt has funded development of new Gitorious features and continues to do so. Qt has been absolutely wonderful to work with. I’ve done my fair share of consulting over the years and it’s not often you get so much freedom to work on stuff that’s both important to your client and to yourself as we’ve gotten working while with Qt. Something I think is really a testament to the engineering culture at Qt.

However, our collaboration with Qt doesn’t end with Shortcut developing Gitorious. Since Qt wanted to use Gitorious for their contribution model it was only natural that we took care of hosting it as well so they could reap the benefits of a growing community. So they launched their contribution model on Gitorious.org.

Qt is now the first “premier hosting” customer of Gitorious, meaning they get to be a an intregrated part of Gitorious with custom branding for their projects and their own portal at qt.gitorious.org as well as other infrastructure needed for a big open source vendor, such as digitally signing off contribution agreements. The wonderful thing about this is that it goes full circle back to gitorious.org, with everybody benefitting along the way.

It’s worth pointing out that in no way is this premier hosting reserved for Qt alone. We don’t make a big fuzz about it on Gitorious.org, but we’re open for business from other companies who’d like to be a part of the growing community and in return pay for things like SLAs, support, reporting and customizations. Stay tuned for more announcements here.

The technical details

The Gitorious code has received some major overhauls in the past few months. Early on we decided to aim for Ruby 1.9 as the deployment target. That means for the past few months we have been developing 100% on Ruby 1.9. Why? Because it’s the only way we can move forward. Waiting for someone else is not going to cut it, especially not when the gains are this big, making the gems that break on 1.9 work isn’t a lot of work, really. The bad news is that if no-one else has done it you have to do it yourself, just don’t take it as a road-blocker (you do know how to code ruby after all, right?) but as an excuse to actually fix those gems. We did, and as a result Gitorious.org now runs on Ruby 1.9. I can’t see what everyone is waiting for, but we seem to be one of the few actually willing to take this step.

If you’re curious about what other changes we’ve made to Gitorious then head over to the Gitorious blog for the details on faster queuing, multiple repositories per project and namespaced user and team clones.

I’m really excited about the future of Gitorious and I hope you are as well. If not, then maybe consider submitting us a merge request with your patches if you find a feature lacking or missing. After all, Gitorious is open source for a reason.

Why You Should Deploy Your Next Application on Ruby 1.9 and a Rant in General

2009-02-25T22:47:43+01:00

No, it’s not speed. That’s just icing on the cake. The real reason is more obvious than that; library compatibility.

Dispite the fact the fact that the Ruby 1.9-preview releases has been out for months, there’s quite a few gems that’s not compatible. Rails works fine though. Can you believe that? Rails is better than most of your gems.

Targeting Ruby 1.9 for your next major deployment of your application (or your next application) is a perfect excuse to do some janitorial duty and make the gems not working 1.9 compatible. Don’t just report it on a site, fit it! Unless the gem does some hardcore thread scheduling in a C-extentions, chances are it’ll take you less than half an hour to make the tests pass on 1.9.

This post pretty much cover how you’ll fix 85% of the gems not working out of the box on 1.9, you’ll even manage to do it before your coffee is ready.

I know I’ll be launching my next application on 1.9. It’s the only way to move things forward.

But I can’t shake this feeling of that something is heading down the wrong path in the Ruby community at large. Nevermind the fact that most of us went oh shi- (that sound you’d make just before the universe blows up) when Ruby 1.9.1-p0 dropped and we act all surprised when nothing works, despite the fact that it’s been a long time coming, with several preview releases along the way. What’s more important is that the art of release management is slowly diminishing in certain parts of our little community. I happen to be of the persuasion that “just download whatever the current HEAD is” isn’t a proper deployment strategy. My clients sysadmins tend to agree, shuffling the responsibility of security updates back on me if it isn’t an “official” package. And that’s cool, I can wear both hats; the developer wanting the most whizz-bang for the buck and the sysadmin wanting the most stability-bang for the buck, there’s a balance in there somewhere. But there’s still this bearded guy sitting on my shoulder telling me something is wrong.

You see, I have little interest in spending time maintaining my own personal patches because that’s not going to scale in time and that’s not why I use open source to begin with. I have no problem in trusting that to someone who does it proper; spends a little bit of time writing up a release announcement and packages it all up on an pseudo-official community site. The problem is when that person goes away. Not so much the “why”, we all move on eventually. But more the “how”? Today, there’s a certain amount of digital paperwork involved; giving away admin permissions on rubyforge/sourceforge/whateverforge, communicating that change and so on. Of course, the post-modern developer might say “just find a git clone that works”. Except that means I have to do actual work (!), instead of putting that trust into the hands of the package maintainers, I have to go hunting for updated repositories, audit the code lightly to check if they’re high on crack or not and generally waste everyones time. There’s a reason debian (and many other projects) has successfully done this over the years. Yes, you may complain about the fact that they split up the ruby packages into many. But at least you have somewhere to direct that frustration, to everyones benefit, instead of simply acting nonchalantly and maintain it yourself, but only for as long as you can keep the steam running, thus degrading the system at large.

The rubyforge gems model may not be perfect, but damnit people, when there’s a gem update I know that it has actually been tested somewhat and it’s not just whatever random point HEAD happens to be at, at that point in time, by some random Joe who just bought TextMate.

Touches and UIScrollView inside a UITableView

2008-12-28T18:40:07+01:00

UPDATE: please don’t don’t do it like this, it was only needed on iPhoneOS 2.×. A lot have changed in iOS since then and you can now do it properly

"Trafikanten" for the iPhone is the iPhone incarnation of the betabrite-style signs hanging around Oslo, providing travellers with real-time departure information on busses, trams and subways. So incorporating some of that feeling into the application, while still maintaining that iPhone look n’ feel was a crucial UI design issue for us.

A betabrite sign is basically a set of LED lamps that turn on and off in sequences, usually to portray text scrolling across the screen. Bringing this metaphor over to the iPhone means that the user should be able to scroll said text across the screen with his fingers. When this text lives in a subview of UITableView (which in turn is a UIScrollView subclass), there be dragons ahead!

The thing is, a UITableView takes completely control of the responder chain (and therefore touches) so that it can try and figure out if the user intents to scroll the scrollview, as described in the documentation overview for the UIScrollView class. So in order to be able to scroll part of a single cell sideways, while still being able to scroll the entire tableview up and down, we have to do some careful juggling with events and the responder chain.

Please observe this artist rendition of the view hierarchy:

 ______________________
|  UITableView         |
|  __________________  |
| | UITableViewCell  | |
| |  ______________  | |
| | | UIScrollView | | |
| | |______________| | |
| |__________________| |
|  __________________  |
| | UITableViewCell  | |
| |  ______________  | |
| | | UIScrollView | | |
| | |______________| | |
| |__________________| |
|______________________|

The innermost UIScrollView holds the departure times and it’s the view we want to be able to move horizontally. It’s worth pointing out that generally, for UITableViewCells, you’d want to flatten the view hierarchy as much as posible (e.g. less subviews) to achieve smooth scrolling performance. But in this case we knew that there would always be less than two dozens or so of UITableViewCells displayed in the tableview.

I created a UIScrollView subclass for the innermost one, that overrides all the touchesMoved:withEvent: and friends delegates, and then in each one try to figure out which direction an ongoing touch was heading. If the touch went up or down we’d call super, otherwise pass it along the responder chain (up to the tableview), so that it can do its thing:

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
  if ([self isTouchGoingLeftOrRight:[touches anyObject]]) {
    [super touchesMoved:touches withEvent:event];
  } else {
    [self.nextResponder touchesMoved:touches withEvent:event];
  }
}

isTouchGoingLeftOrRight: tries to figure out the general direction of the gesture, by comparing the current location with the previous location, and sets an instance variable that things like touchesEnded:withEvent: can react to. Make sure to leave some “wiggle room” in the direction detection, since the user seldom moves completely linearly.

So that takes care of that right? We can go up and down, otherwise we pass it along to the next responder. Turns out there’s one more thing you’d need to pull out of the sleeve; hit detection.

We have to override hitTest:withEvent: on the actual UITableView itself. Remember that it takes control of the responder chain, so the subviews won’t get a chance to handle it first, unless we explicitly override that behavior:

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
  if (self.decelerating) {
    // don't try anything when the tableview is moving..
    return [super hitTest:point withEvent:event];
  }
  
  // Find the cell
  NSIndexPath *indexPathAtHitPoint = [self indexPathForRowAtPoint:point];
  id cell = [self cellForRowAtIndexPath:indexPathAtHitPoint];
  // if the cell has a scrollView property, it's the one we want
  if (cell != nil && [cell respondsToSelector:@selector(scrollView)]) {
    [[cell scrollView] setScrollEnabled:YES];
    // Return the innermost scrollview
    return (UIView *)[cell scrollView];
  }
  
  return [super hitTest:point withEvent:event];
}

hitTest:withEvent: is responsible for telling the system which view that was hit, by default UITableView assumes itself (or one of its cells), so we have to figure out if the user touches our inner scrollview, and if so return that view instead.

I can’t help but feel that there must be a better way of doing this, rather than try and outsmart the UIScrollView’s intended behaviour. But I guess that’s the tax for straying just a tad off the beaten path.

Getting Webby With It

2008-12-28T17:00:46+01:00

This site have been through its share of blogging systems over the years, wordpress, textpattern and mephisto in recent times. I finally grew tired of trying to bring my now ancient Mephisto install back to life whenever I wanted to write something (thankfully it writes completely cached pages on the frontend).

I decided to go with something a little more low-fi, and thus comfortable this time around. Webby is a nice little website generator framework that generates markup from static text files. No databases and myriad of frameworks to deal with, just plain old textfiles in a git repository with a post-commit hook. Another upside is the fact that I can “update” the site during offline periods, like a holiday season like this.

The only problem with static sites is the fact that they are static; no comments. So I’m trying out Disqus, even though I hate being dependent on other services like this.

Here’s the script I used to write out all the existing entries from Mephisto:

require "rubygems"
require "activerecord"

ActiveRecord::Base.establish_connection({
  :adapter =>  "mysql",
  :database => "theexciter_mephisto_prod",
  :username => "user",
  :password =>  "pass",
  :host => "localhost",
})

class Content < ActiveRecord::Base; end
class Article < Content
  has_many :comments
end
class Comment < Content
  belongs_to :article
end

Content.find(:all, :conditions => "type = 'Article'").each do |article|
  outfile = File.join(File.dirname(__FILE__), "content/articles", "#{article.permalink}.txt")
  header = <<-eoh
#{'-'*3}
layout:     post
title:      #{article.title}
created_at: #{article.published_at.to_yaml.sub(/^-\-\-\s/, "").chomp}
filter:
  - erb
  - textile
#{'-'*3}
eoh
  
  File.open(outfile, "w") do |f|
    f.puts header
    f.puts
    f.puts article.body
    f.puts
    article.comments.each do |comment|
      # comment markup omitted for brevity
    end
  end
end

Changing blog software is the ultimate exercise in yak-shaving, since what you really should be doing is writing posts instead…

"Trafikanten" for the iPhone

2008-12-27T17:30:10+01:00

Looking over my rather stale archives I realize I never wrote about the fact that I started a company together with three other guys back in march, called Shortcut.

So far, we’ve mostly spent our time on consulting and it’s still a bigger part of our core business. But we’ve also struck out into some product development, including acquiring a company that provides white-label mobile services such as SMS/MMS integration solutions. Good fun all around, including having a few employees now and a really exiting next year ahead of us. But enough of that.

Ever since the iPhone SDK was released, we’ve all been playing around with it. One of the most useful apps that we could think up for ourselves was something that combined the GPS, network connection and realtime information of some sort.

We all use public transportation between home, work and pubs. All the busses, tram-lines and subways in Oslo is equipped with a GPS that transmits information on whether they’re on time or not. This information is then in turn displayed on betabrite-like signs on various stops. However, what we really wanted is being able to get this information regardless on whether you’re waiting at the actual stop or not.

Enter the “Trafikanten” iPhone app. Using either CoreLocation, searching by name or the recently used list it fetches realtime departure info for the greater Oslo area. Being able decide whether or not to wait another five minutes before walking out into Scandinavia’s notoriously bad weather is turning out to be pretty damn useful.
Next to MobileMail, Trafikanten has turned out to be one of the most used applications I have on my iPhone.

Developing the application was a lot fun, the Cocoa Touch API quickly became familiar from when I dabbled with Cocoa on the desktop, and the framework is overall well thought out.
But there’s still a few things that turned out to be slightly non-trivial which I hope to blog some more about. Things such as how UITableView really deals with touches and how to work around it. In the case of the Trafikanten app, each UITableViewCell has information that can be slided sideways to mimic the way the public betabrite-style signs scrolls their departure info across (turns out most users we’ve tested this on understands the metaphor perfectly) as well as how we did custom font rendering, but had to cut it from the initial release due to unsatisfactional results.

But to be honest, the most important lesson I’ve learned developing for the iPhone is how much UI matters. Most, if not all, of the slightly “heated” discussions we’ve had internally has been about the UI and interaction, not the actual implementation in code. The device already looks and feels so polished that you’d feel like a fool pushing out something that looks and feels unpolished.

After release the application jumped to the number one spot in the “Top Free Apps” category of the norwegian App Store, after less than a day out in the wild.

The application is in Norwegian, and only useful in the general Oslo area. But if you’re in this area, you now as the chance to always appear superhuman by always arriving exactly when the bus arrives!

iTunes link

Comments:

Carl Youngblood Says:
December 19th, 2008 at 05:20 PM

Congrats on a great iphone app Johan! We are also starting to develop iphone apps in addition to our Rails work here at Surgeworks. There are even rumors that iphone development in Ruby will someday be possible. Right now it’s definitely more painful than it needs to be, despite Apple’s nice SDK.
Wevah Says:
December 20th, 2008 at 02:05 AM

Nice job!

What's interesting about MagLev

2008-06-02T21:15:00+02:00

One of the more interesting presentations at this years RailsConf seems (I wasn’t at the conference myself) to have been the one about MagLev. Lots of excitement, a fair bit of koolaid-drinking and a good round of healty sceptism.

But the real interesting part of MagLev to me isn’t the claimed performance numbers (though that in itself may be interesting, but not until we know how ruby-conformant the final product is going to be). What’s really interesting is the Gemstone/S based persistance part of MagLev, along with the distributed VM part, and not at least Gemstone (the company) itself, with a long experience of creating dynamic language VMs.

And yes, so far it might be mostly koolaid (since none of us outside Gemstone has used it), but I seem to remember a certain Ruby webframework being called samething similar in 2004, and continued to receive trash even after its release. History will probably repeat itself here with the arm-chair experts.

I for one find traditional relational databases lacking in a lot of problem-domains, that’s why I’m interested in (admititly young) projects such as CouchDB, StrokeDB and Neo4j, and anything else that teases my mind with new posibilities. Yes, Facebook, Skype and others scales MySQL/Postgres indeed, but it’s interesting to note that the reasons for that is probably more developer culture and experience related. While the Gemstone Smalltalk implementation seems to cater more towards wildly enterprising sectors, such as the financial and shipping markets, where the demand is quite different from sending virtual vampires to your friends. Then again, that argument works the other way as well.

I don’t think ActiveRecord is no-where near being the perfect way to persist objects, rather I think it’s one of the better ways to map objects to a relational database. There’s a small syntactic difference there, between an enhanced class (by inheriting from ActiveRecord::Base) and an object you interact with just as you would with any other object, which in turn is persisted across machines and sessions as those very same pure objects.

People playing around with a shared global object store made by a company who has been doing it for 15+ years is a good thing. Who knows, ~~maybe~~ hopefully someone will get inspired to write something new based on ideas we’ll get from using MagLev. Maybe Seaside (or something similar in spirit) will find its way back to its Ruby roots. Maybe even other Ruby implementation hackers will start to implement something similar to Gemstone at the bottom.

What’s also interesting is that Gemstone the company even does this to begin with. I hope it’s because they see Ruby as something they could help with their dynamic language VM experience. But moreso it might be because they see real business value in Ruby, and being able to provide a fast, scalable platform for enterprises who mgiht feel that Smalltalk is a bit old fashioned for todays developers, but dynamic enough to give them flexibility while being able lean against a vendor. Of course, I know little of Gemstone the company or their customers, but that that seems to be the tune as of lately.

From the sounds of it, MagLev is not going to be completely open source, but I’m with Giles Bowkett and Wincent Colaiuta on this one, while the majority of the Rails community says things should be F/OSS, that has never stopped them from using mostly closed-source things like Macs and Textmate. As long as it’s shiny, works great and gets the job done, the majority of Rails developers will happily use it. And that in itself is fine.

Maybe it’ll MagLev really will be fast, maybe it’ll inspire people and make their work enjoyable, maybe it’ll allow certain applications to scale easier, maybe it’s persistance model will be a joy to work with. And Maybe, just maybe, it’ll be friggin’ sweet. But I, for one, welcome our new Object overlords and can’t wait to see what they’re upto because anything doing interesting things to, or with, Ruby is a good thing.

Comments:

Dr Nic Says:
Jun 03 at 01:10
Whilst macs + textmate are closed-source they are both very extensible + configurable and have thriving OSS communities built off them, fwiw.
Johan Sørensen Says:
Jun 03 at 07:48
Indeed there is, and from the sound of it Maglev will also be partially OSS, so there’s no reason why the same kind of community couldn’t be built around it.
David Whittington Says:
Jun 03 at 14:23
I actually do not use Textmate or a Mac in large part because they are closed source. That’s not to say I mind other people using them, but it does make a difference to me.
Tammer Saleh Says:
Jun 03 at 16:24
Another difference is that we so far haven’t staked our production applications on close source platforms. There’s an easy migration path from textmate to any other editor (and the same is true for all development tools we use), but once you start using the object persistence of maglev, you’re locked in.
Adrian Madrid Says:
Jun 03 at 18:17
I wasn’t at RailsConf so I didn’t witness the presentation but I’m interested mostly in the replicated OODB built into the environment. If the performance was upto par with MRI I would still use something like that. My problem is that it is still something I can’t get my hands on and who knows when I would be able to. I don’t mind the business model either as long they only target Fortune 500 companies and poor folks like me can use it. I guess I’ll have to learn to be patient.

AEM
sensei Says:
Jun 04 at 06:32
Maybe it’ll sell more copies of GemStone/S ;-) GemStone is bloody awesome.

Gitorious, so far…

2008-03-19T01:00:00+01:00

It seems that Git is getting more and more mindshare by the day, which is great because I’m loving working with it. It’s a little over three months since I made Gitorious.org public and I’ve been having lots of fun with it since then.

In particular I’m happy about the wide range of projects there, ruby based projects are in the majority there including semi-official mirrors of both the Rails, RSpec and MacRuby projects. But some python things, such as gdb-python, a bit of lisp along with some Erlang, C/C++ and two linux kernel mirrors. Good times.

The last two are interesting because they are some of the biggest git repositories around, yet they only take up about 200 megs worth of diskspace. Heck, take all the repositories combined on Gitorious, and the cache for the web frontend of gitorious.org is still bigger than those. However neither disk nor bandwidth charges are anywhere near hurting my wallet, and it’ll stay that way for quite a while. I don’t contribute as much as I should back to most of the open-source projects I use on a day to day basis at the $dayjob (or otherwise) so I consider Gitorious as my way of giving back. Long term I have some ideas that would allow gitorious to give back even more (things like this is awefully inspiring), without resorting to cheap tricks such as ads all over the place.

So far, most of my focus on the Gitorious codebase has been on stability and speed (it’s really quite snappy now I think), but also a few new features such as merge requests and searching. But soon it’s time to add some of the bigger things on the list, that’ll help dealing with managing an open source project hosted on Gitorious.

But first I want to talk about “the competition”, namely github, “competition” is in quotes because I honestly don’t see it like that (git is distributed after all), however a lot of people seem to lay it out like that whenever the two are mentioned in the same sentence. It says a lot about the workflow that git presents, that we both had the same idea and ran with it, only to release each others thing publicly a week or so apart.

But I find it slightly peculiar that a lot of open-source projects (ruby/rails projects in particular) has jumped on it, despite it being closed-source. What’s the point of being myspace for hackers (not that that’s a particular flattering comparison to begin with) if I can’t hack on it? But that’s me being seemlingly more idealistic about this stuff than most people. Launchpad is closed-source and seems to be doing well despite it being a total mess to use, and even the Apache Foundation offers their incubator projects an option to use JIRA and/or Confluence (“The Enterprise Wiki” — that cracks me up everytime).
Anyway, not crying about this at night, just finding it interesting. What’s really important is that more people discover the advantages of a distributed SCM such as Git, even for internal (“dayjob”) projects, regardless of whether they host their code on a third-party server or on their own using Gitosis and gitweb, a custom Gitorious install (I hear there’s a few already) or just a plain old git repository somewhere.

I don’t want Gitorious to end up like the mess that is Launchpad, but I do think there’s a few good idaes floating around when it comes to dealing with the practicalities of running, or contributing to, an opensource project that’s worth looking into. In particular the notion of a distributed bug tracking system is too cool to pass up, even if distributed just means that I can track bugs across projects and different repositories. Imagine Jane having cloned Bobs project publicly and fixing that damn bug #2353, all Bob has to do now to fix the bug is to pull in Janes changes into the mainline repository. Boom, no need to mess around with patch files.

Having the ticket system truly distributed is of course something to strive for, but I think I’ll start with a slightly less lofty target for Gitorious and use tracer bullets from there to hit the sweetspot of a ticketing system that fits git, and humans, well.

Comments:

Ryan Tomayko Says:
Mar 19 at 05:35
Gitorious and GitHub (and repo.or.cz for that matter) definitely compete, IMO, but not in a who-can-make-the-same-exact-widget-most-efficiently type way. There’s so much room for innovation here and no one service is going to be able to experiment with all the interesting possibilities by themselves.

I’d actually like to see you guys collaborate a bit. The “Associated repositories” (Gitorious) and “Network page” (GitHub) could be so much better for everybody if they were capable of showing all clones everywhere. I realize that information isn’t really recorded anywhere in a Git repo but it seems like something that could be done with a bit of cooperation.

Or maybe not. But, ideally, the decision to put repos on GitHub vs. Gitorious should be made based on the service preferred by each individual. Right now, that decision is more likely to be made based on where the repo you’re cloning resides or where a majority of your collaborators hang out. That seems very much against the spirit of Git.

With regards to the phenomenon of F/OSS projects choosing GitHub over Gitorious, I’m afraid I can’t offer any single explanation, but I do have a few thoughts:

First, from what I can tell, idealists who care about (or even know about) Freedom 0 are actually a pretty tiny minority of the overall community. And a lot of people who claim to value open development don’t actually value it when compared to a bunch of other things. It’s sad, really.

Next, I’m not sure we’re at a place where the benefits of open development outweigh the benefits of focused, opinionated design. It’s definitely possible to build coherent, usable systems in an open model but you need a BDFL type personality to keep the crack out and you take on some not-insignificant overhead simply maintaining an open project; where, in a closed project, you can go cowboy for a while and focus purely on making the app meet your vision. The benefits of the open model clearly outweigh the benefits of the closed model in the long run but these are early days. (That’s a general observation – I’m not saying GitHub has a more coherent design or anything)

And finally, even though GitHub and Gitorious were released within a few days of each other, it sure feels like GitHub sucked up a bunch of projects right out of the gate somehow. I have no idea why. I can tell you that when I personally first looked at Gitorious, I somehow missed a whole bunch of great features. I’m more than willing to accept that it was me not being rigorous enough in my evaluation but if you get the same sort of feedback from others, I’d say it would be well worth it to spend some time ensuring that the first visit shows off as many of Gitorious’s features as possible. And, here, I really think its almost entirely about networking – the project search and code browser and everything that’s been a part of the forges is damned near irrelevant.

Keep up the good work, Johan. I’m absolutely blown away with what you’ve accomplished so far and am anxious to see what’s next.
Johan Sørensen Says:
Mar 19 at 13:04
Good comments

I’d actually like to see you guys collaborate a bit. The “Associated repositories” (Gitorious) and “Network page” (GitHub) could be so much better for everybody if they were capable of showing all clones everywhere. I realize that information isn’t really recorded anywhere in a Git repo but it seems like something that could be done with a bit of cooperation [..] That seems very much against the spirit of Git.

Me too, it’s actually been on the list since the beginning, but I imagine it no way being specific for repo.or.cz/github/other, just a general remote repository hosted somewhere else. We could even peek at it periodically to fetch recent activity there. It’s also possible to fetch which remotes that a repository often pull in and display that somehow.

And a lot of people who claim to value open development don’t actually value it when compared to a bunch of other things. It’s sad, really.

I’m as pragmatic as the next guy when it comes to getting work done, but I view open source and a completely different way, there it’s a matter of principles for me, and especially so if you’re marketing whatever you’re doing as “suitable for open source projects”. Anything less is like Al Gore driving around in a Hummer as I see it. But in the end, I supposed all that really matter is that a (F/OSS) project being hosted somewhere produce useful code.

I can tell you that when I personally first looked at Gitorious, I somehow missed a whole bunch of great features. I’m more than willing to accept that it was me not being rigorous enough in my evaluation but if you get the same sort of feedback from others, I’d say it would be well worth it to spend some time ensuring that the first visit shows off as many of Gitorious’s features as possible. And, here, I really think its almost entirely about networking – the project search and code browser and everything that’s been a part of the forges is damned near irrelevant.

That’s some really good points, and something that’s been nagging in the back of my head since the start, thanks for putting words to it. The overall UI (as in conveying what it does and general discoverability) needs some uhmph, and I’ve put the networking-type things a bit on the backburner in favor of individual per-project features, but maybe it’s indeed time to change that approach.

Again, thanks for the comments Ryan!
Priit Tamboom Says:
Mar 20 at 08:38
In the service world it gets really fuzzy about open source or not, i’m still puzzled. However as a programmer I support open source way of doing as much as I can. However as Ryan told for most users it does not matter so much at all as we would like to think (especially in the sort term).

In my view, there is no need for direct competition, solve only your (or core contributors) needs and visions. If you start competition feature-to-feature basis, you might need some revenue plan to keep things sustainable etc.

By the way I don’t mind ads if it is unobtrusive and correctly placed for users (similar to gmail), however aggressive ads would be deal-breakers for sure.

Thanks for driving gitorious!
Priit@still.not.yet.so.diligent.committer
Johan Sørensen Says:
Mar 20 at 09:02
In the long term, there’s definitely a revenue plan (that doesn’t mean I’ll have to charge directly for usage) it just doesn’t make sense to implement it yet since, like I mentioned, the cost is abysmal and a) I need it myself to host my own personal projects, b) I need the app itself (internally) for my company and c) I don’t mind “giving back” in the indirect way it currently does.

Gitorious source pushed - and a freebie!

2008-01-13T19:56:00+01:00

I’ve pushed the source to Gitorious to… Gitorious! Yurii has already made a clone of it and I think he’s hacking on some SVN mirroring he needed for one of his projects. Very cool.

I’ve also added a project called Tumbline, which is an 80% done tumblelogging application I wrote during the summer when I was really unhappy about Tumblr (where I host Application Error), they have since shaped up a bit and I’ll probably continue using them. But I’ve open sourced the application I wrote in case someone wants to use it for something, rather than it collecting dust in my ~/Projects directory.

Enjoy!