Objective C – Getting Started

While I’m primarily a Ruby developer, I am conversant in several other languages. However, the bulk of these languages are scripting languages of one sort or another. With the exception of dabbling with C# for a prototype that got pushed into production, I haven’t used a compiled / (semi)statically typed language since learning Java in college.

That said, picking up Objective C as a polyglot programmer was not difficult. The hardest part was figuring out some of the magic that Xcode does behind the scenes to launch GUI apps. This particularly was a challenge because the Xcode template treats the AppDelegate object as the delegate for the main window. This, for a beginner with Xcode, caused me hours of fumbling around trying to figure out how to properly start up an application with a proper WindowController class.

As a whole, moving into Objective C was not difficult. I’d spent years working on improving my object-oriented programming in a Ruby/Rails environment. Mostly due to the fact that Rails (ActiveRecord! in particular) is not picky about good object oriented design. Moving to a (semi)statically typed language was not a large leap, especially because Objective C’s messaging feels very familiar (less the bracket syntax). I build all the same objects I would for Ruby project; the display methods may be different, but the underlying objects work the same.


Parsing binary records ouf of SBF (Superbase) data files with Ruby

Recently, I had the “luck” to be asked to look into extracting data from a proprietary application which stored its data in SBF files.

After some research, it sounded like the database engine was in fact Superbase. This was proved out after parsing the header files based on the Superbase file specification. Despite the fact that we are (nearly) in 2014, this product uses Superbase 1.0 file specification, and does not offer any means to interoperate. 


For anyone else unlucky enough to have to undertake dealing with SBF files, I’ve attached the script I started out with.

Please note – this is a simple proof of concept – not how I would engineer a real extraction.



Superbase file specification:


Ember Feature Flags

I had a few moments of difficulty setting up an Ember app which needed the query-params feature which is not available in production/beta.

The lesson learned:
Remember to make sure you have the canary build!

then, prior to Emer.Application.create():

Non-standard urls and #linkTo in Ember.js

I’ve been working on an application which uses non-standard URLs for a resource which I need to bring in.
I didn’t wish to set up a deeply nested set of resources, but I did want to use the linkTo helper.

For internal reasons, the url is structured as #/:account_id/:order_id to enter the primary display page. I do not want, in this case, to use #/account/:account_id/order/:order_id. I also do not want to create the routes; the main entry point is always going to be the #/:account_id/:order_id url.

There are two parts to this problem.

  1. Object persistence across the routes
  2. Serialization for the linkTo helper

The first issue is solved by ember already. At the bottom of the Routing guide there is a paragraph that I’ve previously missed:

Note: A route with a dynamic segment will only have it’s model hook called when it is entered via the URL. If the route is entered through a transition (e.g. when using the linkTo Handlebars helper), then a model context is already provided and the hook is not executed. Routes without dynamic segments will always execute the model hook.

What this means in practice is that my object, containing

{account_id:123, order_id:456, id:1}

will be available to the setupController hook in the route.

The second problem takes a bit more digging. The model that I’m passing needs to know how to represent itself on the route’s URL, in order to avoid errors or #/undefined/undefined. At some point, I saw an jsFiddle which displayed the serialization hook. The serialization hook is how you can pass something with mutliple dynamic selectors into the url.

  serialize: (model, params) ->
      account_id: model.account_id
      order_id: model.order_id

jsBin to follow soon…

Errors which may result from the improper usage of the linkTo helper:
THESE ARE NOT CORRECT but were part of the learning process.

  • “You used the dynamic segment order_id in your router, but App.Order did not exist and you did not override your route’s `model` hook” – when trying {{#linkTo ‘account_order’ 123 456 }}
  • “More objects were passed than dynamic segments”

Bootstrap Datepicker in Ember.js

I’ve been working on an application where I needed to input a date.
Bootstrap itself doesn’t include a datepicker, but a number of people have written the extensions already.

Example code:

Datepicker Example

I usually use https://github.com/eternicode/bootstrap-datepicker but the ancestor at http://www.eyecon.ro/bootstrap-datepicker/ functions just as well if one does not need some of the additional options the eternicode version provides.

In general, and for Ember in particular, I use the widget form, which requires a bit of additional markup.
Under ember, I ran into a ‘gotcha’ where where the change event would be fired twice if I was using an editable textbox. I assume that the initial click made the attribute dirty when focus went to the datepicker widget, and then the actual change to set the attribute to the new date.

The View that I use inside of ember.

App.DatePickerField = Em.View.extend
  templateName: 'datepicker'
  didInsertElement: ->
    self = this
    onChangeDate = (ev) ->
      self.set "value", moment.utc(ev.date).format("YYYY-MM-DD")
    @$('.datepicker').datepicker({separator:"-"}).on "changeDate", onChangeDate

Writing Code to Exercise Code – Test Driven Development

When I first started learning about TDD – and all the similar exercises which boil down to writing code to exercise code – I couldn’t wrap my head around it. I was learning programming and working on personal level projects, and I didn’t understand why I would want to write twice as much code which would have to be changed when something in the system changed.


Fast forward several years and several industrial-size projects later, and I am firmly in the camp of thoroughly testing code. Now, I am not quite as fanatic about it as some people, for reasons below. But the tests I write give me freedom to refactor code in ways I never would have thought of prior to using the TDD tools. 


I recently refactored a major class into a subclass hierarchy, in order to centralize the logic I was coding. It touched on virtually every piece of the application, as it supplied the underlying data for any number of decisions. But by using my passing tests, I was able to confidently rip out the wiring, knowing that I could put it into place and watch the tests to ensure that I had correctly connected everything. 


My non fanatic stance hinges on the items below, and my reasons why. 

  • I don’t write all my tests first – I can wrap my head around the business process better as I lay out the logical steps. 
  • I don’t test everything – the trivial accessors simply don’t provide enough risk of failure for the time it takes to test them. 

Bottom Line – the benefits of being able to fire off a number of automated tests are huge when you continue building on top of the system. You can be sure you didn’t break anything and that all the related components are still firing properly.