Under the Hat

As a fulltime Textmate user, I was really happy with my editor. Even with 2 colleagues that try to convince me that Emacs is the way to go, But I still didn’t feel the need to switch. But then one day something popped… The day after I switched to Vim, and until now I’m really glad I did.

So why would I do this?

Well, I can’t lie to you. I wanted something more special than Textmate, everybody uses Textmate these days and I have the impression that more developers in the Rails community are switching to an editor like Emacs or Vim. And because Piet is a die hard Emacs user I wanted to compete with him by using Vim.

Github

I have my whole Vim configuration on my Github account, just in case my machine desides to explode. You can find it here. This can come in very handy when working on multiple machines, just commit, push and pull and the configuration is identical on both machines! Isn’t that just freakin’ awesome?

These are some of the features/plugins I added to my configuration:

• Ack (find in project) support
• Emacs-style file finder called Lusty Explorer
• A nice Railscast colorscheme
• Somewhat better full screen support
• A simple strip trailing spaces function

Here is an example screenshot of the colorscheme I use in MacVim.

I’m adding new stuff every day while learning more about Vim.

Installing my config

First things first, backup your current configuration so you don’t have to blame me for ruining your life.

Next up:

• Clone this repo to .vim/
• Create a simlink for the .vimrc: ln -nfs ~/.vim/.vimrc ~/.vimrc
• Create a symlink for the .gvimrc: ln -nfs ~/.vim/.gvimrc ~/.gvimrc

And that’s all you have to do.

Enjoy!

Reference

• Vim
• Vim Plugins
• MacVim
• Vimcasts
• My configuration repo

When you get into Mac or iOS development, you’ll soon be confronted with delegates. And after a certain period of time when you gain more experience, you’ll start creating your own custom delegate calls.

How Apple uses delegates

Let’s say we want to log the number of characters entered in a UITextView. We’ll have to assign a delegate to the UITextView instance and then implement the textViewDidChange method.

UITextView *textView = [[UITextView alloc] init];
textView.frame = CGRectMake(0, 0, 100, 30);
textView.delegate = self;
[self.view addSubview:textView];

This code snippet creates the UITextView somewhere in the viewDidLoad method from out main UIViewController. Next up: implement the textViewDidChange method.

- (void)textViewDidChange:(UITextView *)textView {
  NSLog(@"number of chars: %i", [textView.text length]);
}

This will log the number of characters entered every time you change something in the UITextView.

But there is a warning

The code above will work perfectly but there will be a warning.

The warning thrown is this one: class ‘ExampleViewController’ does not implement the ‘UITextViewDelegate’ protocol. It means we have to follow the UITextViewDelegate protocol and set it in the header file like this:

The solution to remove the warning is fairly easy, just add the UITextViewDelegate protocol to the header file.

@interface ExampleViewController :
                   UIViewController <UITextViewDelegate>

To make a class conform to a protocol, you just have to add it in between the < and >.

Create your custom delegate call

Now what if you want a custom view class to call a method in your controller because you think the code functionality belongs to the controller. You’ll first create a property where you can assign the delegate:

@property (nonatomic, retain) NSObject *customDelegate;

Your delegate instance is now available in your class, so when you call the setColor: method on your instance, than you want to call the delegate’s changeColor: method if available in the customDelegate: instance.

You can find more info on the difference between id and NSObject on this blog. There reason I’m using NSObject is because it doesn’t generate warnings when using the respondsToSelector:.

In the code below we’ll first check if the method is available, and if so we call it and pass the the current color so the controller can do the rest.

- (void)setColor:(UIColor *)color {
  SEL method = @selector(changeColor:);
  if ([customDelegate respondsToSelector:method]) {
    [customDelegate performSelector:method
                    withObject:color];
  }
}

For those that don’t really know what selectors are, they can read it here

But I want a warning!

It can come in handy to throw a warning to notify the developer that he can or has to implement certain methods in order for the delegate to work properly.

You should first create a protocol that defines the @required and @optional methods that the delegate class can or has to implement. And you can do this in the header file (or in another file).

@protocol ExampleViewDelegate
@required 
- (void)changeColor:(UIColor *)color;
@optional
- (void)clearColor;
@end

The methods below the @required directive are all obligatory. The ones below @optional are not. Now this won’t throw any warning it’s just a preparation for what is coming.

Now you have to do a small modification to the @property where the customDelegate is defined. We have to tell the customDelegate that it should implement the ExampleViewDelegate protocol.

@property (nonatomic, retain)
                  id<ExampleViewDelegate> customDelegate;

When we now assign the delegate, a warning is thrown when the protocol is not implemented (cfr. How Apple uses delegates). So we just have to implement the protocol to stop the warning from appearing.

@interface ExampleViewController
                 : UIViewController <ExampleViewDelegate>

And when we don’t implement the changeColor: method, then another warning will arise, because this method is set to required in the protocol.

Now let’s go and delegate!

Reference

• Selectors
• id vs NSObject

You can find a small project with the UITextView and the custom delegate examples on Github

2010 was een fantastisch jaar.

Sinds begin 2010 is 10to1 aan het groeien. Begin 2010 waren we nog met 2, eind 2010 zijn we met 5. We zijn, wat ze noemen, “een snelgroeiend bedrijf”.

Tot nu toe hebben wij de volgende benadering gekozen: “als we merken dat we mensen nodig hebben, gaan we er zoeken”. Dat leek ons het veiligste. Maar het bezorgt ons ook de meeste hoofdbrekens: tussen het moment dat we mensen nodig hebben, en dat die mensen effectief kunnen beginnen, zitten er steeds enkele maanden. En tijdens die maanden verzuipen we.

Daarom gaan we vanaf nu een andere benadering proberen: wanneer iemand zich aanmeldt die we vinden passen binnen 10to1, gaan we proberen om hem of haar op te nemen in ons team. De ervaring leert ons dat een gelegenheid om hem of haar productief in te zetten, zich voordoet voor hij of zij effectief kan beginnen.

Wie maakt er kans?

Iedereen die een meerwaarde kan bieden aan 10to1. Dat kan op alle gebied zijn, en misschien zelfs op een gebied dat wij nu nog niet voorzien. Misschien kan je een project deskundig managen, zet je ongelooflijke koffie, of denk je van onze site “dat kan ik ook”. Of misschien zit je nu te denken “die tekst had ik toch nét iets vlotter te lezen gemaakt”.

Wat doet 10to1 eigenlijk ?

10to1 maakt software op maat voor iPhone, iPad en web applicaties (met Ruby on Rails). We volgen de principes van Agile Development. We beschouwen software niet als iets dat je bouwt, maar als iets dat je met zorg laat groeien.

Wat voor omgeving is 10to1?

10to1 bestaat enkel uit mensen die gebeten zijn door software ontwikkeling. Wij dragen passie hoog in het vaandel. Als gevolg daarvan kom je met de nieuwste technologiën in aanraking. Maar ook als gevolg daarvan verwachten we dat jij ook gebeten bent door de nieuwste ontwikkelingen in mobile applications, web applications en social media.

Jaja. En wat zoeken jullie nu concreet?

Zoals gezegd: we staan open voor iedereen.

Als we zelf onze wishlist overlopen, komen we volgende omschrijvingen tegen:

• Project manager. Je verzorgt de communicatie tussen het 10to1 team en onze klanten. Je spreekt technisch met 10to1, je spreekt menselijk met onze klanten. “Expectation management” vind je geen vies woord.
• Designer. Je kan je plan trekken met Photoshop. Je weet waar je moet op letten als je iets maakt voor het web. Je weet wat het leven van een iOS developer gemakkelijker maakt. En vooral: de mensen zeggen “Waaw” als ze je werk zien.
• Copywriter. Je kan een droge tekst aantrekkelijk maken. Je kan een blog post schrijven, maar ook een technisch voorstel vermenselijken zie je wel zitten.
• iOS developer. Cocoa. Objective C. ‘nuff said.
• Ruby on Rails developer. Ruby makes you happy.
• Strategist. Je kan meedenken met een klant die een begin van een idee heeft. Je doet voorstellen voor web applicaties, iPhone en iPad applicaties.
• Koffiezetter. Grapje, we hebben reeds een fantastische espresso-machine.

Waar moet ik zijn?

Wij staan open voor iedereen. Maar jij moet ons natuurlijk overtuigen. Als jij denkt dat je 10to1 extra waarde kan geven, en dat je je thuis voelt in een snel veranderende omgeving, nodigen wij je graag uit om ons te komen overtuigen.

Core Data is one of the frameworks I find a bit scary to use when I’m developing iOS applications. I always felt like I was developing something that wasn’t really under my control. That was until Piet pointed out this framework to me: Mogenerator.

Draw your models

The first thing you should do is create your models in the XCode Modelling Tool. More information on this topic can be found here.

Here is an example of my Core Data model:

Let’s generate

When you created a model with some attributes, you can use mogenerator to generate your classes (or regenerate them, when you did some editing).

I pass two arguments to mogenerator to generate the files.

• -m the location of your data model
• -O the location of your model classes

Here is an example:

mogenerator -m TestProject.xcdatamodel -O Classes

This command generates all the classes for your models created with the modelling tool. Be aware: You still have to add them to your XCode project in orde to use them.

What is generated?

For each model four class files are generated. The 2 class files starting with a dash should never be modified. When you want to add custom methods/logix, you can do this in the other 2 generated classes. They extend from the dashed-classes.

Every attribute can now be accessed as a property on the object. This makes it very easy to assign new values.

Don’t forget that when you change your model in the modelling tool, that you’ll have to run the mogenerator command again in orde to regenerate the dashed files.

Some code

The code snippet below will create a Person object and assigns some values to the attributes. When everything is assigned the changes are saved.

// NSManagedObjectContext from somewhere in your system
NSManagedObjectContext *moc = ...

Person *p = [Person insertInManagedObjectContext:moc];

p.firstName = @"Zot";
p.lastName = @"Franske";
p.age = [NSNumber numberWithInt:25];

[moc save:nil];

Check these out!

Here are some links that helped me during development:

• Blog post by Aral Balkan
• Github repo for mogenerator
• Modelling your data in XCode
• Core Data Programming Guide

What’s a Natter?

natter |ˈnatər| informal
verb [ intrans. ]
talk casually, esp. about unimportant matters;
chatter : they nattered away for hours.

Most of us here at 10to1 are avid Twitter users and being the social media experts geeks that we are we’ve also got a Facebook account. The problem is; we like Twitter much more than we do Facebook. So when a Facebook-friend commented on something we’ve posted via Twitter, we didn’t know it until hours later.

So we felt an itch and the Rails Rumble was an excellent excuse to scratch it.

What’s a Rails Rumble?

The Rails Rumble is an annual 48 hour web application development competition in which teams of skilled web application developers get one weekend to design, develop, and deploy the best web property that they can, using the power of Ruby and Rails.

We (Jelle, Koen and me) teamed up with Nick to participate in this year’s event. We did the nuts and bolts while Nick made sure the app looked as well as it does.

And it sure as hell looks as tight as we could have hoped for.

Since we only had 48 hours to make it, we didn’t get in as much features as we wanted but all the basics are there.

• Did we have fun? Yes.
• Will we participate again? Yes.
• Are we proud of our 13th place? Yes. (13 is the new 1)
• Did we sleep much? No. (OK: I overslept for 6 hours; quit whining Jelle)
• Did it have bugs? Yes, some.
• Could we have done it without Rails? No. (Okay, maybe in Sinatra)
• Will we push the app even further? Yes. (It got an update last night, which fixed some bugs and made some performance enhancements).

How does it work?

After you sign up with Natter, it will listen to your tweets and post them to Facebook, enhancing them to atual Facebook posts if they contain an URL or an image.

Now, dear reader, I can tell you’re not impressed but here’s the kicker; whenever a Facebook-user posts a comment to a Natter posted tweet on Facebook, Natter will post this comment on Twitter. And, you can reply to it, straight from the confines of your sweet minimal (before they redesigned) Twitter.

So now you’ve gone full circle for al your social networking needs. (Unless you’re one of thos Jaiku or IRC guys)

Yeah, but how does it work?

We couldn’t have done it without standing on some pretty big shoulders; so we’re using (like most of our webaps) Rails coupled with the following gems: twitter_oauth for handling all things Twitter, facebook_oauth for all things Facebook, bitly to make the Facebook links small and kinda sexy (I’m stretching the limits of sexy here, it’s more javacool and to make sure the server can handle it all we’re using Resque for queuing all background jobs (pretty much everything is a background job).

The whole thing is hosted on a, Rails Rumble supplied, Linode slice which also hosts our MySQL db. We’ve only brought it down once, and that was pretty much our own fault (note to future self: decide who puts the indexes on the DB), so it’s safe to say Linode rocked.

What did we learn?

• A sexy design works
• A painless signup process works
• Sleep is overrated
• We need to prepare better (Texts, flow of the app, design sketches,…)
• Testing stuff like this was hard. (Study up on how to test your app)
• Hard deadlines work (We could only submit our final build 10 minutes before the deadline)
• Sysadmin-skillz (or rather devops /ht @frank_be) are needed
• Being able to split up your app in tasks suited for one person, is a plus.