Startup Boot Camp

A couple weeks ago I heard about an event called Startup Boot Camp that is happening in Ottawa October 23-25th. The idea is to bring together a number of startup minded individuals and form teams around startup ideas. You then take the weekend to work on the idea and at the end the best one gets a prize to be used to incorporate the business. Here is an excerpt from the blog post announcing the event.

The event will place 75-100 people into functional business teams around ideas for businesses. The participants, composed of developers, business managers, start-up enthusiasts, marketing gurus, accountants, lawyers, graphic artists and other roles will work together during the week end. At the end of 54 hours, they will have turned a business idea into a business plan ready to start on the Monday. A review panel at the end of Sunday’s presentation’s will determine which of the opportunities is the best developed and award a prize of $5,000 as the first seed money to start the business (e.g. incorporation costs, start a website, etc.). Similar networking events have evolved very successfully in other parts of North America with this one being the first in Ottawa.

I’ve just signed up and anyone else who might be interested should do the same. Even if you don’t win the prize and land your dream job it should be a great opportunity to meet with like minded individuals and have some fun.

Presence 3

As I said in an earlier post I’ve been working on learning Objective-C, more specifically, programming for the iPhone. Well, I just finished off my latest Stanford iPhone assignment, Presence

1. As always you can find it up on github, there’s a branch for assignment 1, assignment 2 and now assignment 3.

A couple of very key concepts were introduced for this assignment including threading, modal views and text input.

Threading

Threading is one of the most important things to learn when doing iPhone programming. For this assignment the main idea was to have any network requests (loading any of the Twitter data) happen in another thread with a spinner showing that something is happening. There are a number of ways to move tasks off the main thread in Objective-C that abstract things away from using threads directly.

So far I have found using NSOperations to be the easiest way to deal with threads. One way to create an NSOperation is by creating a subclass and using an instance of that object in your code. My image loading operation for Presence 3 is below.

@interface ImageLoadingOperation : NSOperation {
	NSURL *imageURL;
	id target;
	SEL selector;
}
- (id) initWithImageURL:(NSURL *)url target:(id)theTarget 
                                   selector:(SEL)theSelector;
@end

@implementation ImageLoadingOperation

- (void) main {
  NSData *imageData = [[NSData alloc] initWithContentsOfURL:imageURL];
  UIImage *image = [[UIImage alloc] initWithData:imageData];
  
  if(image == nil){
    image = [[UIImage alloc] init];
  }
  NSDictionary *result = [NSDictionary dictionaryWithObjectsAndKeys:image, 
                          @"image", imageURL, @"url", nil];
	
  [target performSelectorOnMainThread:selector 
                           withObject:result 
                        waitUntilDone:NO];
	
  [imageData release];
  [image release];
}
@end

To create an NSOperation subclass the first thing you need to do is override the main method, that’s where the bulk of your code for the background thread will go. Once the work you need to do is finished you need to send the results back to the main thread with the method ‘performSelectorOnMainThread:withObject:waitUntilDone:’ passing the result and a boolean to say whether this thread should block until the selector is performed.

Now that we have an operation defined we need to create an instance and use it. It’s pretty much the same as using any other object, the only difference is that you need to add the operation to an operation queue and it deals with scheduling and all that.

operationsQueue = [[NSOperationQueue alloc] init];

ImageLoadingOperation *operation = [[ImageLoadingOperation alloc] 
  initWithImageURL: url
  target:self
  selector:@selector(didFinishLoadingImageWithResult:)];
[operationsQueue addOperation:operation];
[operation release];

Everything here is pretty straight forward, you create an operations queue (which can be used for many different types of operations) and then add the operation instance to the queue to be executed.

Another way to use operations for threading is by using the NSInvocationOperation class. It’s a implementation of NSOperation that you can use instead of having to subclass it yourself. All you have to do is remember to call ‘performSelectorOnMainThread:withObject:waitUntilDone:’ in the method given as the selector parameter.

NSInvocationOperation *operation = [[NSInvocationOperation alloc]
  initWithTarget:self
  selector:@selector(sendMessage:)
  object:text];

[operationsQueue addOperation:operation];
[operation release];

Modal Views

Modal Views are fairly common on the iPhone, it’s a view that can be popped up in the stack and has to be dismissed before getting back to any previous interactions. Think of when you’re composing an email or adding a contact; the view that shows when doing those actions is presented modally.

Any view controller (or navigation controller since it’s a subclass) can be presented modally with one simple method call.

[self presentModalViewController:composeView animated:YES];

This will show the ‘composeView’ which has to be dismissed before the user can continue whatever they were previously doing. Dismissing the view is best done by delegating back to the view or controller that presented it.

@implementation ComposeViewController

-(IBAction) cancelButtonPressed:(id)sender {
  if([self.delegate respondsToSelector:@selector(composeViewDidFinish)]) {
    [self.delegate composeViewDidFinish];
  }
}

@end

When the composeView was created I set the creator as the delegate, then when the cancel button is pressed I can tell the delegate that the composeView is finished and it can decide to dismiss the view or do something else. One simple method call in the delegate dismisses the modal view.

[self dismissModalViewControllerAnimated:YES];

Text Input

Handling text input is incredibly easy since the iPhone handles most of the annoying work for you. You don’t have to worry about calling up the keyboard or anything like that, when a keyboard is needed the framework knows and displays it for you. There’s a lot of customization that you can do through Interface Builder or code, all of which is pretty straight forward.

If you do need to interact with what’s happening with the keyboard there are some optional delegate methods that you can implement. Just set a class as the inputs’ delegate and implement the methods you want.

- (BOOL)textField:(UITextField *)textField
    shouldChangeCharactersInRange:(NSRange)range 
    replacementString:(NSString *)string {
    
  NSString *testString = [textField.text 
                          stringByReplacingCharactersInRange:range withString:string];
  charactersRemaining.text = [NSString stringWithFormat:@"%d", (140-[testString length])];

  if( [testString length]>0 && ([testString length]) <= 140 ) {
    sendButton.enabled = YES;
  } else {
    sendButton.enabled = NO;
  }

  return YES;  
}

This first method gives you a bunch of information about the current keyboard interaction, like what string is going to be added and where in the range of the string it’s going to be placed. This lets you filter out characters or modify what is happening with the input. A boolean is returned to say when the input should take place or not. In my case I wanted to enable or disable another button depending on how much text was going to be in the input. By using the ‘stringByReplacingCharactersInRange’ method on the current input text and the string that was being passed in the resulting text length can be found. Thanks to Ben Lachman who helped me out with this.

- (BOOL)textFieldShouldReturn:(UITextField *)textField{
  if ([textField.text length]<=140) {
  	[textField resignFirstResponder];
	
  	if([self.delegate respondsToSelector:@selector(composeViewDidFinish:withText:)]) {
  		[self.delegate composeViewDidFinish:self withText:textField.text];
  	}
  	return YES;		
  } else {
  	return NO;
  }
}

This next method lets you decide what should happen when return (or send, or go) is pressed. You can call other methods here and return a boolean saying whether the keyboard should return or not. Notice that I am letting the delegate decide what to do with the result.

Conclusion

Well, there was a lot going on in this version of Presence but hopefully I didn’t cut things down too much in this blog post. The most interesting bit is the threading, it’s also the most useful. If you want some more details just let me know or take a look at my version of Presence 3 yourself.

My Ideal Job

Well, I have recently found myself without a job so am in the processes of looking for something. I thought this might be a good opportunity to think about what I really want from a job / employer so that I can try and find something that I’ll really enjoy. You end up spending most of your waking life at work so you might as well enjoy it, right? I’ve decided to put this up on my blog just in case the perfect employer happens to stumble by :). Here it goes.

Working with Technologies I Love

This is number one on my list. I want to work with technology that I love, something that I find really interesting and cutting edge. I love programming Ruby. It is by far the most enjoyable programming language I have ever worked with. That being said, I’ve started learning some Objective-C and iPhone programming and though the language isn’t as nice as Ruby, there’s something about programming a device that has a GPS, camera, phone and so many other goodies that is so very cool.

Working with Smart, Fun People

This isn’t really second, more like equal to the first point. I want to work somewhere that I will continually be learning from the people around me. Smart might not be the only word to describe these people; innovative, motivated, creative coworkers who will help me improve and grow my skill set is a must. At the same time I want to be able to joke around, have them over for BBQs and have fun with my coworkers.

Develop an Amazing Product

I want to work on something that I think is amazing, something that I’ll go home and talk to my wife about, think about and work on whenever I can. Difficult, engaging problems that will require me to think and come up with interesting solutions are what I’m looking for. I want to make a real contribution to the product, add new and interesting features and continually improve the user experience.

Flexible

Living here in the Great White North it would be nice to work somewhere that has a somewhat flexible schedule. Sometimes it’s a lot easier to open up the laptop at home than braving the partially plowed streets and icy roads.

Open Source Aware

Actually, not just aware of and using Open Source technologies, I want to work somewhere that they actively contribute back to the Open Source community. Somewhere that they encourage their developers to spend a little bit of time working on and creating new Open Source projects. I’ve made a few Open Source contributions that you can see on my GitHub Profile but I would really like to do a lot more.

Local (or Telecommute)

Though it does get cold here, my wife and I love where we live and having our family close by. We have no real interest in packing everything up and moving. I’m looking for something in the Ottawa area, or someone who is willing to have an employee work remotely.

Well, that’s basically it, hopefully this perfect position exists. If this sounds a lot like your business please check out my Resume and get in touch.

Lunch and Learn, iPhoneU

For the past couple weeks a few of us at work have gotten into watching screen casts while having our lunch. There have been a variety of topics so far include one on MacRuby and another on HTML5. Most of the time though it’s been some sort of iPhone programming screen cast, the staple being the Stanford iPhone Application Programming lectures.

Not only is this a lot of fun (yes, I am a big nerd and think a video on HTML5 is fun) but I find that learning a new programming language/framework/etc really helps with your day to day work. Every programming language does things a little differently. When you embrace the methodologies of a new language it can open your eyes to different ways of looking at the programming problems you might face, no matter what technologies you’re using.

On top of just watching the Stanford lectures they have all the notes and assignments online so we’ve been working away at those in the evenings. I’ve started posting my solutions to GitHub and will continue to update them as we progress. HelloPoly and Presence 2 are completed so far, check them out if you’re interested.

If you are interesting in programming for the iPhone or just want to try something new I’d defiantly recommend the Stanford iPhone lectures. The final version of the Presence assignment ends up being a full blown Twitter client with threading, contacts integration, search and much more.

Take the initiative and have your own Lunch and Learns.

Create a Remote Branch with Git

Create a branch of your current code on the remote with git:

  git push origin master:refs/heads/BRANCH_NAME

SCP

I don’t have to do this often but every time I need to scp something up to an EC2 server I forget the options and have to waste 10 minutes finding it. Here it is so I don’t need to look for it anymore.

  scp -i PRIVATE_KEY LOCAL_FILE USER@IP:REMOTE_LOCATION

These two links have a number of other examples and list some of the other options.

It's Okay to Say "I Don't Know"

I've only been working in the tech industry for a couple years now and I'm starting to notice that people (and companies) have a very difficult time saying "I don't know" (or "no", "we can't", etc).  Why is this?  There's nothing wrong with not knowing something, as long as you have the skills and abilities to figure it out.

I was at a local BarCamp meetup a little while back and one the people there was talking about finding jobs.  At one point he said to never say you can't do something in a job interview or else you wont get the job.  I was baffled.  If you can't do something, why would you say you can?  At some point the truth is going to come out anyways.  Is this really what it's come down to?  A better question, do managers expect this when doing interviews?  Do they expect people to say they can do anything even though they can't?  I really don't know, but this kind of scares me.

I have a couple friends from Europe and they're just as confused by this behavior as I am.  Apparently they don't have a problem with this, if you have something on your resume you bloody well know how to do it, if you can't do something they expect you to say so.

And really, what is the problem with hiring someone that might not know every detail of everything the position requires?  If I were hiring someone I'd mainly be interested in their general problem solving and critical thinking skills.  Sure, you would need to have the basic skills for the job, but as long as it's obvious that you're smart and interesting in learning what you don't know what's the difference?  I'll take that over someone who doesn't care about the job and is just there for a paycheck any day.

What have your experiences been, have you noticed the same things?  Do you say "I don't know" enough?  Leave it in the comments.

"We need to accept our ignorance and say 'I don't know' more often" - Malcolm Gladwell, Blink

Thinking about Testing

I've always been a big fan of including tests for any of the code I write.  It was beaten into us in university, made sense when using JUnit and made easy in ruby with Test::Unit.  Sometimes I still get annoyed when writing tests though.  I've been thinking about testing a little more than usual the last couple of weeks, mostly about what bothers me when writings tests.  I hate writing brittle tests.  I do my best to avoid this, but sometimes in a large project when you're trying to test everything it becomes difficult.  The other thing I really hate is trying to test everything.  I know, I know, code coverage is a good thing, but what good does 100% code coverage do your customers or users?  Does it make the app suck less?  Well, I suppose it could, but isn't it possible that 95% or even 80% coverage would be just as good (for the users), depending on what was tested?  I'd say it's very possible.

To get around my first annoyance, the brittle tests, I've started creating the objects that I need in the test itself instead of using fixtures (this is rails).  This lets me build up the objects for my test without worrying that adding another fixture will break existing tests.  This works alright for unit tests and smaller scenarios, but creates a bunch of duplicate code when a number of tests use objects that are setup in a similar manner (refactoring the setup into methods helps with this, but the tests get confusing as you need to jump around methods).

Next problem, I want to write tests for things that need to be tested, not some far off situation that I think could happen.  In Jamis Bucks talk at RubyConf, Recovering from Enterprise, he said that you should "code just in time, not just in case…there's no excuse to sit and play what if games".  I feel exactly the same way.  Now, I've been thinking over this for a couple days, doing some reading and whatnot and have decided (hope!) that RSpec will be my savior.  From the rspec.info site, "Rspec is a Behavior Driven Development (BDD) framework for Ruby".  The way it works is you write 'specifications' (specs) that define how the system should behave.  By writing he specs first and then writing the implementation methods afterward you are building, and testing, the system as it should behave; you're not testing arbitrary situations that probably wont occur.  Writing tests first and implementation code afterwords also has a neat catch phrase, Test Driven Development (TDD).  RSpec allows you to nest scenarios as well which helps me with the first problem I was having as I could build up the context of the test suite as I went, reusing the earlier setup if I wanted.

So far I've done a lot of reading and have written a few specs, but really haven't scratched the surface of what RSpec has to offer.  I'm not sure if this will solve all my testing woes, but it's defiantly making me think and test a bit differently, which I like.

Leaving for RubyConf 2008 Tomorrow

I'm really looking forward to leaving tomorrow afternoon for Orlando Florida to attend RubyConf 2008, it should be a blast.  The hotel looks amazing, the weather is going to be great, what more can you ask for?  Oh ya, there is more, some great talks and presentations from Rubyists around the world!

There are a number of interesting presentations, but a a couple of them really stand out.  One presentation that I'm really looking forward to is 'Recovering from Enterprise: how to embrace Ruby's idioms and say goodbye to bad habits' by Jamis Buck of 37signals.  I really respect the guys at 37, they have a no bullshit way of saying things that just make sense, I like that.  Jamis is also a long time Rubyist and has given so much to the community with the projects he's worked on (capistrano, sqllite ruby bindings), and has been teasing us with interesting blog posts related to his presentation.

I'm also interested in the talk Scott Chacon is giving, 'Using Git in Ruby Applications' mainly because I find Git to be such an in interesting source control system (and maybe I can pull some of my co-workers along so Scott can infect them with the Git as well).  It sounds like Scott is going to be getting into some very interesting things with his presentation as well, such as using git as the backend for a ruby based wiki or file backup system.  Cool stuff.

On Friday I'm probably going to try and catch Yehuda Katz presentation, 'Writing Code That Doesn't Suck: Interface P=Oriented Design' since, if you've read any of my other blog posts, I really like to do as much as possible to make things suck less.  I'm not all that interested in Merb though so I may wander over to 'Ruby Heavy-Lifting: Lazy load it, Event it, Defer it, and then Optimize it.' by Ilya Griorik and see what he has to say beacause, really, can you every know enough about making you code and application run faster?  Didn't think so.

Anyways, that's just a short run down on some of the great presentations that are going to be happening this weekend.  There will also be appearances by Matz (the creator of Ruby) and Dave Thomas (Pragmatic Programmers), both are likely to have something interesting to say.

See you in Orlando!

Facebook Applications are so 2007

  When Facebook released their application platform last year it was revolutionary and a slew of businesses popped up out of nowhere.  A number of these business got huge valuations and outside funding, some even made some money.  But now that the dust has settled from the landgrab and the competitors have caught up with their own offerings (with a varying degree of success) what's next for the app platform?  Well, from where I sit, it looks like it's being retired.

The 'beta' features such as the Data Storage apis have had almost no movement in over a year, the api itself hasn't had any drastic changes (except for the ones do to the new layout) in months, what's been going on?  It used to be that notices would be posted on a weekly basis about updates and new features, now there's nothing.  The chatter around the Facebook platform is dying down to a dull hum.

Applications are pushed out of the main page, multiple clicks away, the directory is bloated with thousands and thousands of pointless applications, how are you supposed to make a mark?  Facebook started out with an 'anything goes' policy for applications, when things started turning into a blue and white version of Myspace they realized their mistakes and clamped down on the restrictions making it impossible for new applications to break in.

Facebooks Solution:  Facebook Connect

Connect seems to be the solution to the broken application platform.  Instead of embedding your application into Facebook you can now have users login through your website to Facebook and allow your application to access their data.  So basically all their doing is Single Sign On and a standard api to access the users data.  What's revolutionary about this?  Nothing.  That $15 billion dollar valuation is seeming more ridiculous every day.

This doesn't mean Facebook applications are totally useless now, it just means there aren't going to be any business built solely on a Facebook app anymore.  Since the spotlights moved on, Facebook needs to work at becoming cash flow positive to make keep things rolling, unless they they can build another Hype Machine to bring back the interest.