Portal 2: Final Transmission, Decoded


I have to give the Portal team some epic geek credit (and some to myself for actually trying this out) – if you record the signal played on the radio when you find the “Final Transmission” achievement location, you’ll have a SSTV signal which you can decode into an image of the companion cube on the moon. So, I did. This screenshot is the decoded result.

Update: I’ve just uploaded the transmission sound clip, so you can hear what the transmission actually sounds like: Portal – Final Transmission.m4a


mobiletuts: Learn Objective-C (Series)

I picked up a new MacBook Pro from Amazon.com in April (2011) with the intention of learning Objective-C to write iOS and Mac software, but made little progress with any of the tutorials I found, until I found this series on mobiletuts:


I think the thing that kept me away from understanding Objective-C until now was the strange look of the significantly different syntax used in Objective-C, as compared to languages I’m familiar with like C#, Java, JavaScript, and C/C++. Objective-C syntax is derived from Smalltalk, in which one sends a message, as opposed to the more common Simula-derived languages, where one calls a function. (More detail on this concept can be found on Wikipedia here: Objective-C: Messages).

In other words, code like this (C#) looks familiar:

public interface SimpleCar : Object
  // Public Accessors
  public String Make { get; set; }
  public String Model { get; set; }
  public int Vin { get; set; }
  // Not really necessary, since we already have an accessor...
  public void SetVin (int newVin); 


…while this (Objective-C), until recently, looked incredibly foreign and confusing:

@interface SimpleCar : NSObject {
  NSString* make;
  NSString* model;
  NSNumber* vin;

// set methods
- (void) setVin:   (NSNumber*)newVin;
- (void) setMake:  (NSString*)newMake;
- (void) setModel: (NSString*)setModel;

// convenience method
- (void) setMake: (NSString*)newMake
         andModel: (NSString*)newModel;@end

Unfortunately, despite sincere interest and significant motivation, most of the Objective-C guides I came across were too dense, too verbose, or not particularly interesting. So, my MacBook got a ton of use as my primary home computer (I’m an ASP.NET software engineer by day, and I use Windows exclusively at the office, but I do love me some OS X…), but Xcode gathered dust in my dock, and I went about exploring alternatives that used a more familiar syntax – like the Qt SDK (C++), MonoDevelop (C#), and NetBeans(an impressive array of different languages).

Now that the back story is out of the way, here’s why the mobiletuts Objective-C series turned that all around and actually got me to *enjoy* developing with Objective-C:

  1. It’s very simple.

    While I do have an extensive background in software engineering, I appreciate guides that break concepts down to their simplest parts and rebuild them slowly, with no assumption of the reader’s background (other than interest in the topic). For most of you who already know your way around another language and who are familiar with the Terminal, the first lesson (Day 1) will seem almost too basic, but stick with it, because you’ll find that the author, Dan Walker, really knows his stuff. His approach reminds me of a quote from commonly mis-attributed to Einstein: “If you can’t explain it simply, you don’t understand it well enough”.

  2. It starts with what you know.

    I didn’t fully realize this from reading other sources about Objective-C, but it really is a strict superset of C. The benefit of this fact, for developers familiar with Simula-derived languages (C#, C++, Java, etc.) is that you can start writing Objective-C code in a syntax you’re familiar with (C), then sprinkle in bits of Objective-C syntax slowly, while you become more familiar with its Smalltalk-derived syntax. For instance, this code is valid, and compiles successfully in Xcode – Notice the use of Objective-C syntax within a familiar C-style method. (This clip is from the Day 3 post.):

    #import <Foundation/Foundation.h>
    int main (int argc, const char * argv[]) {
      NSString *testString;
      testString = [[NSString alloc] init];
      testString = @"Here's a test string in testString!";
      NSLog(@"testString: %@", testString);
      return 0;
  3. It’s actually interesting.

    Dan has a great conversational style to his posts that make them very accessible and compelling, while slowly introducing increasingly complex topics. In Day 1, he explains how to open the Terminal app and invoke gcc from the command line, and by Day 2, he’s provided a great synopsis of  the benefits of concepts like encapsulation, abstraction, and inheritance.

I’m nowhere near an expert on Objective-C, since I literally (yes, literally) started reading this article yesterday, but I feel confident enough in what I’ve learned from this article to start poking around in Xcode and trying to refactor some of my existing code into a working Objective-C implementation. I hope this article helps you as much as it’s helped me, and please, let me know what you think by posting in the comment section below.

Happy coding! =)

Computer Science Question of the Day

Fun question for all the CS nerdz out there:

What is the simplest and/or most efficient function you can write to determine whether a given string has balanced brackets or not?


  • Balanced: “(This is balanced)”
  • Not Balanced: “(((This is *not*) balanced.”

Function prototype:

bool stringHasBalancedBrackets(string inputString)

The function should return true if the brackets are balanced, otherwise false.

(BTW, there is a great solution on Stack Overflow; I’m looking to see what everyone can come up with off the top of their heads.)