Lessons learned in a startup: Proactivity

After working for about 2 years in a startup, one thing sticks out the most compared to a “normal job” at a more established technology company: the meaning of “proactivity.” While I’ve always thought of myself as a proactive person, I don’t think I knew the real meaning of the word while working for big companies.

Example. Suppose you discover a problem in the system you are building/maintaining. Well, at a large company sometimes you have the luxury of simply ignoring the problem. Depending how “skilled” you are in the fine art of bullshitting people, you may succeed into making them believe that (1) it’s not your fault, (2) “somebody else will fix it.” It’s pretty sad.

If you do that at a startup, you’re guaranteed to have it backlash at you one way or another, sooner or later. When other people find out, YOU are going to have to fix it if it’s your code, and if not you, YOU are going to have to help others fix it. Obviously not fixing it is not an option. If noone else finds out immediately, it’s even worse. It will be a tour de force the next day to repair all the damage the bug has caused in the mean time, without even considering the effort to actually fix the bug.

But there’s an even bigger backlash. If you don’t take charge at a startup, you’re subject to the implicit mocking of your coworkers, who will resent your laziness like an insult. You will lose reputation immediately. This is probably the biggest motivation to fix things. The “reward” is big, because people will thank you and they will not be faking their gratitude. In a big company people might thank you (often without meaning it), or might even resent you because your warning revealed a flaw in their code.

Advertisements

“The managed object model version” error

While testing out older versions of a Cocoa app — Smultron, a developer text editor which used to work great but now it’s very buggy — I stumbled upon the error:

“The managed object model version used to open the persistent store is incompatible with the one used to create the persistent store”

Apparently this is a Core Data error. To fix it you will have to remove some files Core Data builds, which are usually stored in ~/Application Support/. Differently from what mentioned elsewhere, they are not always XML files. In the case of Smultron they looked like binary files named Smultron*.smultron.

For free apps that are installed via drag and drop (no installer) it’s probably safe to wipe out the whole $HOME/Application Support/APPNAME folder contents. It wasn’t there the first time you launched the app after all. However, payed apps may install license info there, and apps with installers may install other stuff there as well, so one must be careful.

In my case, I removed the whole content of ~/Application Support/Smultron and the error disappeared once I relaunched the app.

Avoid text editor slowdowns when editing MXML files in Flash Builder

Some time ago I noticed that editing text of a medium sized MXML file had gotten extremely slow in Flash Builder 4. With ‘extremely slow’ I mean a painful lag between key presses: you type (or delete) 3 characters, you see one appearing, wait one second, a second one appears and so on. Unbearable. I had just imported my project from Flex Builder 3 and there were no problems there.

Cause? Workarounds?

The problem was that under the Project > Properties > Flex Build Path > Source Path tab I had added a few paths to the source code of some libraries I am using, including Flex. I was using this to jump into the code during debugging. Turns out if you are already linking to those libraries, you can add the path to their source code in the Source Attachment disclosure field of that library under the Project > Properties > Flex Build Path > Library Path tab.

Then remove it from the Source Path tab: the text editor will all of a sudden become super fast. As it should be. The less source paths you have under the Source Paths tab the faster it will be. You’ll still be able to jump into the library source with F3 when needed.

An Adobe employee on the Adobe forums seems to imply there may be some issues with doing this, but after a few weeks I have seen none.

The iPad is a computer that you don’t control.

Cory Doctorow nailed it about the iPad:

“The iStore lock-in doesn’t make life better for Apple’s customers or Apple’s developers. As an adult, I want to be able to choose whose stuff I buy and whom I trust to evaluate that stuff. I don’t want my universe of apps constrained to the stuff that the Cupertino Politburo decides to allow for its platform. And as a copyright holder and creator, I don’t want a single, Wal-Mart-like channel that controls access to my audience and dictates what is and is not acceptable material for me to create.”

What kind of spell did Jobs cast on us to make us accept these terms? A computer where we have almost no control on it, yet we want to pay for it?

What is happening to computing?

Around 10 years ago we were horrified by TCPA and Palladium and Trusted Computing and all those future DRM technologies that evoked a really sinister aura of devices whose content we’d be unable to control. But… this is it! It is happening! It has already happened with the iPhone actually. At that time I imagined the killer app that would make this possible was going to be entertainment, and here it is. Everybody loves to be entertained. Now you have a fast and sleek device for it. With a great, “approved” user experience.

The genius here is that Apple understood that to make this happen — to have people accept it — they had to invent a brand new class of devices. Nobody will accept a classic computer with those locked-in limitations. And since the iPad is “revolutionary” and fast, sexy, beautiful, with an engaging UI, people will feel compelled to accept the compromise.

Apple invented a beautiful new device to do whatever the fuck they want, no matter how dirty. But they left the hackers out. Mind you, this is the same company (but is it really?) who made the Apple II+, which shipped with schematics.

Purely functional game programming with State Machines

I read with great interest the articles by James Hague about purely functional (retro)game programming. For a guy with a OOP background like myself, the idea of writing games with “no state” comes out as absurdly fascinating, hence deserving further attention. So, in addition to the ideas presented there, here’s another tool of the trade: state machines.

Defining state machines’ states as static collections of {trigger, action, newstate} tuples, we can rethink the “Pac Man problem” as:

[{
    start_state,
    {
        {start_trigger, do_init, normal_play_state}
    }
 },
 {
    normal_play_state,
    {
        {ate_dot_trigger, calc_score, normal_play_state},
        {ate_powerpill_trigger, promote, can_eat_ghosts_state},
        {touched_ghost_trigger, die, killed_state},
        ...
    }
 },
 ...
]

We can have a separate process that receives state changing messages, and depending on the message it processes a corresponding action, such as promote(), calc_score(), etc. Supposing we use Erlang, we could exploit its messaging feature (which strictly speaking I suppose it’s not a purely functional concept yet it feels “clean” — certainly more than doing imperative programming in Common Lisp), and write something like:

compute(start_state) ->
    receive
        start_trigger ->
            do_init(),
            NewState = normal_play_state;
        _ ->
            NewState = start_state
    end,
    compute(NewState);

compute(normal_play_state) ->
    receive
        ate_dot_trigger ->
            calc_score(),
            NewState = normal_play_state;
        ate_powerpill_trigger ->
            promote(),
            NewState = can_eat_ghosts_state;
        touched_ghost_trigger ->
            die(),
            NewState = killed_state;
        ...
        ...
        _ ->
            NewState = normal_play_state
    end,
    compute(NewState);
...

Then, inside our game loop, if at the current frame we found that Pac Man ate a powerpill, a `ate_powerpill_trigger’ is sent to the state machine, making it transition to a new state:

...
ComputePID ! ate_powerpill_trigger
...

So instead of having a class with a PacMan::atePowerPill flag, we “moved” that state info into the state machine definition.  The actual “state” is maintained on the stack, effectively overwritten via tail recursion.

A state machine of this sort will have a (very) long list of states, and for each state it will need to handle many different kinds of game events. In fact, theoretically speaking, we could have a single giant state machine that will recompute large portions of the game state at each transition. Alternatively, one could divide et impera, therefore having multiple state machines (one for each actor?) talking to each other.

This is pretty awkward to the OOP mindset. I can’t deny that representing it in terms of (e.g.) a pac-man object and a few ghosts objects seems straightforward. State is king, partly because we’re so used to reason in certain terms. But I can also imagine thinking in terms of “flow” instead of state, so to speak. In other words, a class can easily describe the current state in all its details, but not explicitly how it got to that state. A state machine can better describe the history across time, yet less directly describes the details.

technorati: 9GVT9D9CNX98

Why is my untested backend code more stable than my untested UI code?

Lately I’ve been quite annoyed with the bugs that sneak into my object systems, especially UI classes. Test-driven development helps out a lot against this, although for some reasons (not the topic of this post) there are cases where I skip writing the tests. Yeah, I know, it’s bad. Most of the times this happens with front end code, and sometimes with Java backend code. I just hate Java, its verbosity, its exceptions, and occasionally I fool myself into believing I can skip the tests to leave Java world ASAP. I’m often proven wrong. I’ll work on that.

Anyway the weird thing is, when I do not write unit tests, I feel like my backend code is relatively more stable than my front end code. They both lack unit tests, so in theory they should be equally bad. So why does the backend code feel more stable, and is it actually more stable?

Well, it is. I have less bugs, and the ones I get are pretty trivial compared to the front end ones. So: why is my untested backend code “better” than my equally untested UI code?

Fact is, whenever I write backend code I tend to write it in a more functional style, regardless of the language I’m using. I’m writing a service after all, so the functional paradigm kind of pushes itself in, breaking the task down into functions, using hardly any additional object hierarchies, passing along whatever state I was dealing with, catching all the exceptions. Then, simply return a value. An inherently simpler design.

If I’m not modifying any object, I’m merely computing a new state. My function has no side effects, so all I really have to do is make sure it returns a correct value. With no side effects, my function is effectively decoupled from the rest of the system, and TDD becomes the most natural way to write code.

Hence I’m less likely to cause bugs. There you go.

This is kind of obvious once you think about it, but it’s not that apparent when you’re knee deep into designing objects. It isn’t for me at least.

So this is my quest now. Find ways to refactor object oriented systems (esp. UI) by extracting its “hidden” functional elements, whenever possible. I have some factual evidence to support this, but I need to develop a more systematic approach.