Welcoming our New Overlords

So it looks like Cisco has decided to purchase the company I work for.  I have to admit that my feelings are currently mixed about this.  Those of you who I've worked with at TVWorks here in London Ontario will know why I'm a little skittish.  Long story short...they shut down the office about 2 years ago now. Here's a funny side note that I just found in looking up that link about the closing: The website still says that they have an office in London, Ontario.  On top of that, the second hit in my google search for: "TVWorks closing london" was a job posting that was still active for a position in the London office.  And if any of my ex-co-workers were to check out the site you'd see a couple familiar faces.

Anyway, my story goes like this: I used to work at Liberate Technologies.  I started there while they were attempting to file for bankruptcy.  I was recently out of University and wanted to work for a tech company that was doing something more interesting to me than the place I was working.  I was impatient and left my previous employer after about 3 months of full time employment to join Liberate. I figured they'd go out of business in a year or so, but at least I should learn something along the way that I probably would not have learned if I didn't give it a shot. I was right...at least partly.  I was learning a great deal.  My manager was great.  My team lead was a very good mentor who had a lot of great stories, great patience and a quirky sense of humor that I absolutely loved.  

Then something odd happened which I hadn't accounted for.  We got purchased by the company that was the big fish customer we were constantly chasing.  It was great!  There were retention bonuses, pay raises and a lot of talk about the things we could do together.  The day of the announcement our management was running around with cases of beer.  This place just turned it up to 11.  I was on cloud nine.

But over the next few months some things started to change.  The teams were getting pulled in lots of different directions and some of the people that I really admired and wanted to work with were leaving for far off places.  But I was busy and doing well and making a name for myself.  Things were still pretty good.  Then more people left.  Things continued on.  It was actually still pretty good.  We were really busy.  We were hiring like crazy.  Our numbers swelled.  Then we got a new name.  TVWorks.  For me this was a bad smell.  Mostly because the name seemed like a cheap knock off of GuideWorks, who was a partner of ours (and previously a competitor).  Oh and I moved in with my long-time girlfriend.  And we promptly got a cat.

Then things started to shift.  New management from the mothership, as we called it, came in with a lot of talk about how they were going to help us deploy things faster and make things happen.  The term "doubling down" was used and promptly mocked around the water-coolers.  The hiring turned from full-time, to contracts. The perks were starting to claw back.  There was more talk of fairness with other sites and integrating with the mothership in various ways in order to streamline things.  By the way, I married that girl I moved in with earlier...and bought a house.

This continued for some time.  We tried moving to an Agile-ish development style that was met with mixed results.  Some people really embraced it, others chaffed. The mothership was not all that amused.  Our co-owner backed out of the partnership.  Our free drinks suddenly had a cost and our Christmas party lost some of the previous flare. I was getting restless, but was still generally ok with things.  I struggled to find a place to fit and seemed to be always one step away from getting to do the work I'd hoped to do.

Then things got real sad. The contractor positions were removed.  We carried on.  Various key positions in senior management were suddenly removed. We looked at each other with odd expressions, but still marched on. And after a few more months of slow decline, and after numerous others left of their own accord due to the shifting winds, the final axe came down.  The office closed. And on the lighter side, my wife and I got pregnant with our first child.

All of those things came flooding back to me the moment I read the e-mail Thursday morning.  The ups and downs and the excitement which eventually turned to resentment.  It's because of that experience that I have a hard time walking into this new change with bright eyed optimism. Perhaps it's also because I'm a lot wiser and more cynical now that I'm older and have a daughter to think about.  Maybe the last experience has just made me a more jaded person.  I don't really know.  But I'm trying really hard to be positive about this new change. I think there is a good chance that it will be positive for a lot of reasons.  This is a very different situation than the last purchase that I went through for a lot of good reasons.

For starters the value that the buyer has put on us this time around is considerably more than when Liberate was bought up.  This time a technology company is buying another technology company rather than a media distribution company buying a software development company.  This should be a better fit between the way the corporations work.  It seems that we have a lot to offer these new overloads and I think they actually understand what it is we do and what we have to offer. I'm not clear that the previous transaction I was a part of had that same solid foundation.  And my daughter is walking around nowadays and is ridiculously cute.

Enough with my blathering.  I've just ordered the new Apple TV and I'm way more excited about that than this work stuff anyway.  But I feel better geting this off my chest.  Hopefully I don't get called into a dark office on Monday for saying something that I shouldn't have.  (It's happened before)

Reviewing the Bio

Image: courtesy of Cult of Mac

I recently finished the Steve Job biography by Walter Isaacson.  It was great.  I don't recall ever finishing a book as quickly as I did this book. (My wife says she can't recall the last time I finished a book...period.) I think the closest was when I read The Shock Doctrine a few years back.  I loved the crazy stories in the Jobs biography, the anecdotes and the pacing of the novel were all quite good.  I also found the parts that discussed his illness very moving.  I actually welled up on occasion.  But I'm also a softy so that's really not that hard to make happen.

There are some lessons to be found in the book to be sure.  Some are cautionary, others are opportunities for all of us to learn something.  All that has been discussed by many others around the net.  And to be fair I think this next criticism has as well.

As I read about Steve Job's time at NeXT and this miss-adventures with Pixar I came to realize something.  The stories were getting to the point where the Apple purchase of NeXT was just about to happen and it hit me.  Wait a minute.  What changed?

It struck me that the events described at NeXT and at Pixar where missing something They seemed to be lacking any real explanation of how Jobs had moved from a bratty kid with insane mood swings and a childish temper to a man retained some of those same faults, but seemed to have many of them tempered and was more in control of himself. How did he get to this place where he was allowing concessions that he would have never even considered previously.  Isaacson offeres up a morsel of an explanation (or hypothesis) to the reader by summing up of Steve Job's experiences with NeXT and Pixar as giving him some sense of humility due to the failures that they and he experienced.  Except that in both cases they ended up doing pretty well.  NeXT was failing for sure, but still managed to be rescued by Apple in the purchase that brought Job's home to Apple.  And Pixar flourished as it created animated hit after hit after hit even though it had a rocky start.  So what actually changed?

Maybe I just missed the point.  But I also found the hammering home of this idea that Steve somehow embodied the cross-roads of technology and the liberal arts is a bit silly. Not that the notion of working at that cross-roads is silly.  Nor is it silly for a business such as Apple to attempt to own that area.  But I just felt like the book kept hitting that note so hard and so obviously that it failed to deliver the message very artfully.  Also that's not really the theme I was personally hoping to gleam from the book.

I really wanted to know how the journey between leaving Apple and returning to save it effected him and changed him into the man who could save it and build something as impressive he did from what was a company on the brink. That's what I was looking for.  Not this rather bland idea that you he just stayed true to this one ideal and that's what guided him and was injected into the DNA of Apple and that's all it took.  I don't buy it.  There needs to have been more.  Given what I read of his early days at Apple, something changed.  But what was it that influenced those changes?

Regardless of my own thoughts however, I would still wholeheartedly recommend anyone who's thought about starting a company, or really enjoyed any of Apples products, or who is just amazed by the things that Steve Jobs accomplished would definitely enjoy giving this book try.

On the side...

I've decided I should post a quick update on what's going on with my side project.  I totally missed my stated goal of getting an application deployed for the holidays.  But I had a good reason for it.  Or maybe just a good excuse.  I had a paying gig..and I don't mean my day job.  A friend of mine from a previous employer happened to have acquired a small grant from a local technology company support organization called the Tech Alliance. I've been eager to help him any way I could since he's basically managed to do thus far what I hope to be able to do my self at some point.  He's turned his side project into a full time business that he operates from home.

Anyway the story goes that Nokia had approached him a while back about his application.  They wanted it to be ported to their Symbian devices and were willing to support him in getting that done.  That amounted to some contract work to one of the many small mobile development contract houses out there these days.  Needless to say though, he wasn't particularly pleased with the results.  So when he got this grant from the Tech Alliance he was hoping to hire me to help him clean it up and maybe create a bit of a spike in sales.

My mission, should I chose to accept it, was to provide a working build environment and clean up a lot of the rough edges of the user interface.  A pretty simple task really.  Although I'd only really looked at a small amount of Qt code recently and wasn't at all aware of the joys of the Symbian operating system and SDK.  I'd originally tried to set things up with the Eclipse environment, because that is generally my tool of choice.  However the plugin for Qt wasn't working  particularly well for me and caused a number of problems.  So I gave up on that pretty quickly and decided to venture into the wild world of Qt Creator.  That is one annoyingly structured environment.  The workflow was horrible.  The simulator didn't even properly represent the look of the application and was very, very buggy.  When I finally got the application building I couldn't target the device because I had to wait for the certificate to become live because it had a date in the future rather than being available to use once downloaded.  Then the wonderful Qt Creator environment would crash every 2 or 3 times I re-loaded the application for debugging.  There was also a funny story about a USB cable.  But I don't think I'll go into that.

There were so many little quirks with the Qt SDK and Qt Creator system that I don't think I could even list them all here.  And I won't even get into how messy the code was.  It looked like each file was written by 5 different people, all of whom had completely different coding styles, none of which were about being readable.

I also spent some time on another possibly paid effort.  However that one didn't happen.  It's not dead yet, but postponed until the summer for various reasons.   That project is significantly larger and more effort than the one that distracted me before the holidays.  However the scope of quoting on it also ate up a considerable amount of my time.

I still hope to get a chance to do that project since it would have meant native iOS application development.  Which is really what I'm hoping to do with my side project.  Although I'm quite open to mobile development of any kind.  I plan to try and release my own application on Android as well as iOS when it is ready. It really is quite simple so I don't foresee any major effort in doing the port.  Of course my first target will be iOS.  I may even give the Windows Phone 7 a try at some point.  Then I have some larger, more complex applications I'd like to start working on.  My hope is to get my small application out on at least iOS by the summer and have made a good start on at least one of the larger projects before the fall.  We'll see how that goes.

One other thing.  I'm going to be doing my best to try and convince my employer to send me to WWDC this year.  I'm not hopeful of my success in that regard.  But I was thinking that maybe I could swing it if I offered to pay the conference fees if they could manage the travel.  I've made it a part of my personal goals at work to create an application that can demonstrate I have gained an advanced knowledge of iOS development.  So at least I have that going for me.  But now I have to actually start making something there too.  I have some thoughts that I'll have to try and find the time to squeeze in...probably while I should be eating lunch.

Here's a bit of a before and after shot of one screen.  You let me know which you like better.  I'll try not to get upset.

And here are some more snapshots I'd collected:

I used a much nicer image for that big logo than was previously there.  The old one was fuzzy since it was way too low resolution for the screens.  The changes in the other screen were to remove an action bar like mechanism for selecting favorites and allowing a couple other options that no one ever uses.  So I followed the design pattern that the latest iPhone and iPad implementations use which is much simler and more elegant.



He will be missed.

How I like to define JavaScript Objects

I've been really impressed by the expressiveness and power of JavaScript lately.  It's much more capable a language than I ever used to give it credit for.  The flexibility of JavaScript also can make it often harder to understand what is going on.  There are many ways to accomplish the same thing and they can look like completely different things.

If you have need to create a lot of custom "classes" in your application, I have a few things I've grown to appreciate.  In this post I'll talk about a style of class definition that I find readable, provides good encapsulation and can provide good performance when accessing functions on these objects.  I'm sure that if I'd worked with JavaScript longer I'd be able to enumerate all the problems with my approach, but so far I don't think there is a lot of down side. But I think part of the reason I like my approach is that it reminds me of Java with less ceremony.

Here's what I usually see around the web:

function MyClass (some, params, needed) {
    this.doSomeInit();
}
var p = MyClass.prototype; //Or = new ParentClass();
p.baz = "lorem";
p.fuzz = "ipsum";
p.foo = function() {
    return this.baz + this.fuzz;
};
p.bar = function() {
    return this.fuzz + this.baz;
};

I've also seen:

function MyClass (some, params, needed) {
    this.doSomeInit();
}

MyClass.prototype.baz = "lorem";
MyClass.prototype.fuzz = "ipsum";
MyClass.prototype.foo = function() {
    return this.baz + this.fuzz;
};

MyClass.prototype.bar = function() {
    return this.fuzz + this.baz;
};

So what's going on?  

The above code is basically just 2 different ways of defining a JavaScript "class".  I put class in quotes because JavaScript doesn't technically have classes.  It has objects.  My main gripe with these approaches is that it requires that these objects expose a lot of their internal structure by updating their prototype so that these public functions can manipulate the internal state of the object and do work. The only real difference in the 2 styles above is that one is slightly more efficient since it avoids the chaining of object property calls that's required.  There is a cost to calling MyClass.prototype each time you define a new function.  So if you're looking for speed you put that in a variable.

I prefer to do something like the following:

function MyClass (some, params, needed) {
    var baz = "lorem";
    var fuzz = "ipsum";

   function myPrivateFoo() {
       console.log("PRIVATE");
   }

    this.foo = function () {
        return baz + fuzz;
    };    
    this.bar = function () {
        myPrivateFoo();
        return fuzz + baz;
    };
}

This approach means that I don't have to expose the variables baz and fuzz.  I also get to use the parameters, "some", "params", "needed" without the need to create internal vars or properties on the prototype.  The functions foo() and bar() are both public privileged members of our object.   It also makes it easy for these public functions to use private functions.  My main reasons for liking this approach is that I think it's cleaner in that I like that my constructor encapsulates the class definition like you'd see in Java. I also like that my object can be more shy about what they expose to the world.  But is there a downside to this?  Actually there is.  

The catch is that every time the constructor is called all of the code in my constructor gets run.  All the function definitions are added to the prototype every time.  That's not so good.  Why?  Because if your custom object needs to be constructed a lot, then yes you'll take a hit in the performance department.  However that's usually a smell of something else not being quite right in the design and can be mitigated with a pattern that separates construction from execution and ensuring you are being judicious about your object creation. However if it truly is something that needs to be created thousands of times, then by all means follow one of the other approaches.  Or take a hybrid approach and define any functions that are fully public and don't require internal knowledge of your object state and define them explicitly with the MyClass.prototype.myFunction syntax and anything that has to access the internal state can be defined in the constructor.  There's not really a right answer here.  I'm just sharing my preference and providing a small argument for it.  

If you were to look at performance from another perspective, my approach may actually be preferred.  If you are using functions that an object exposes in a loop, or another pattern that requires lots of calls, my approach means that there are fewer property lookups on the object prototype since local variables can be used more often.  In practice I find that I'm not constructing custom objects very frequently, but I am calling functions on those objects in loops quite a bit.  So for me this approach is a good fit.  

Anyone else have a different take? I'd love to hear about it in the comments.

Starting Fresh

I'm no longer a part of the Redshirt Labs gang of 5 that was actually 4 for quite a while and felt like 2 for a long time, but whatever.  I'm done.   Of course we still hang out and eat the same lunch at Prince Al's, but no longer will I be pining over what to do next with Zengaku.  The rest of the gang will figure it out.  I'd offered to take it off there hands, but they didn't go for that.  I also considered licensing the source code and doing a fork, but I reconsidered and felt like a clean break would be best.

So begins the adventure once more.  This time with a little more solitude.  But if I make an application that only sells a few hundred dollars worth on the market, that's a bit easier to swallow than when you have to split that 5 ways.  Plus I'm not going to be making games.  Which I think would be fun, but is a tough business to get into and requires a lot of talent that I don't have.  Mainly a lot of art, music, sound and game design skills.  I could probably implement the code for a game if you gave me the spec/design docs, but coming up with all the rest is way to much for me and I can't go and hire all that talent either.  This is just a hobby after all.

So I've made the initial steps of setting up my new business.  I've got an idea for a first application.  I'll share that soon enough. I got a website, a hosting service, a remote repository and an official business license.  I'm working on my registration with the Apple Developer Program. It's all getting started.  Now to start making the application.  My hope is to have it delivered to the App Store before the Christmas holidays.  Not that it would help sales or anything, just that I need a goal and that seemed reasonable.

I'm not going to get into the details of my business idea, or the application I plan to build just yet.  If you ask me in person I'll tell you about it. But mostly I'm just not ready to share much else at this point.  I have a lot of work to do.  I'd like to have a decent landing page on my website, get some blog content lined up,  get the application in progress and moving forward and so on and so forth.  Then I'll have loads more to talk about. But for now this is about it.

I may have to write a bit about my new affection for JavaScript and functional programming.  I don't know if I'd say I know a lot about either just yet, but I've definitely spent some time getting familiar with JavaScript over the last couple months and I'm actually quite impressed.  But also looking forward to doing a bit of C/C++ work once more.

A couple of things Developers Should Know but often Don't

I've been reviewing a lot of code lately. Mostly Java code, but some C, some C++ event some Objective C.  There have been some patterns to the coding mistakes/miss-steps that I've seen and been pointing out in a number of these review.

Loops
This one seem to be the most common of late. And I had to convince some people of the merit of my stance.  Basically my theory is that you should almost never need a while loop.  So if you ever see yourself using one.  Ask yourself why.  Most times you'll be declaring some kind of iteration tracking variable and incrementing or updating it somehow as you loop through whatever structure is being iterated over.

The problem there is that the variable gets declared and used outside the loop.  Now C doesn't help here so it's common for C developers to make this mistak in languages that do help. In my case Java.  Using a for loop allows you to declare a variable that is scoped to you loop so you can be sure you don't accidentally keep the variable longer than you need and use it by accident somewhere else in your function.

I think the latest C standard (C99) fixes this, but it's pretty common that you can't count on that so a lot of C developers still don't think about this feature.  Just about the only time I think a while loop is a bit cleaner or clearer is if you are creating an infinite loop; in that case the simple while(true){} is pretty universal.  Although I've seen for(;;){} a number of times as well so I'm still not sold on that.

Proper Scope
Along the same lines as my previous issue with loops is ensuring that your variables are scoped properly.  I hate seeing Java functions with a long, long laundry list of auto variables that are potentially not needed since the the parameters may make their allocation unnecessary.  Although this isn't really a memory or optimization effort it does help a bit in that respect.  The Java stack frame will be allocated with space for all the local variables.  Event the objects, although only space for the reference is allocated by default.

So although you will not be preventing local variables from being allocated, if you have the the objects you create properly scoped they will at least only do the object allocation when needed and will be dereference and available for GC as soon as possible.  But the optimization can come into play if your objects are only going to be created if certain parameters are passed into that method.  So in cases where your parameters don't require the objects to be created you save that time and memory.  But like I said, this isn't really the reason to scope them properly.

The best reason for scoping variables is for clarity and maintenance. The issue with keep a variable around longer than you need to is that it is unclear if you intended to use it later and just forgot, or worse yet you do use it later, but didn't actually mean to do so.  Don't laugh.  This happens a lot.  In particular in long, hairy functions.  I don't like those either, but baby steps.


Over use of if this set this else set that
I think this is a pretty easy one.  Which would you think is clearer and more concise:
Option 1:
if (conditiona) {
   var = boo;
}
else {
   var = bar;
}

Option 2:
var = (conditional) boo : bar;

Option 2 is the clear winner in my books hands down every time.  I think this is the very reason why the ternary operator gets included in pretty much every language I've had the pleasure of working with.

I have lots of other gripes and faux paus that I see on a daily basis, but these are just some of the most common that I've seen of late.  One of my biggest pet peeves is when OO design gets perverted into some crazy mess of over complicated goo.  Often that seems to start with good intentions and the classic over use of inheritance rather than composition.  I've trained myself similar to the for loop to stop every time I see inheritance to ask if it is actually the most appropriate solution to the problem at hand and if it truly adds value beyond what composition could provide.  I feel like I'm stating the obvious since I've been reading about this stuff on blogs like this for years, but I keep seeing these same issues in the code I look at being created on a daily basis so people still aren't getting the message.  I figured I may as well add to the ocean of data out there pleading with developers to clean things up.  But I'm sure it's a Sisyphus like task. But I'll keep pushing that damn rock anyway.   It's just how I roll.