Quickly rebuild your iOS app when Provisioning Profile expires

  1. Login into the Provisioning Portal, click “Provisioning” on the left side column
  2. Renew your expired profile (or create new one) and download it
  3. Drag it over the Xcode dock icon (or add it into the Organizer)
  4. Remove old profiles from Xcode Organizer
  5. Open your Device target. Select the Build tab -> Code Signing Identity, and make sure the new profile is the one in use.
    Xcode has the habit of not automatically updating its targets to use the newly installed provisioning profile. (Even if you physically removed the old one.)

At this point you should be able to rebuild the app.

Bitstrings and Binaries (Erlang bit syntax minihowto part 2)

What’s the difference between the Binary and Bitstring types in Erlang? Well, a bitstring is a sequence of bits of any length; a binary is a sequence of bits where the number of bits is evenly divisible by 8. (So any binary is also a bitstring.)

Some examples:

1> <<2#11110000:5>>.
>
2> <<2#11110000:6>>.
>
3> erlang:is_bitstring(<<2#11110000:6>>).
true
4> erlang:is_binary(<<2#11110000:6>>).
false
5> erlang:is_bitstring(<<2#11110000:8>>).
true
6> erlang:is_binary(<<2#11110000:8>>).
true

In the Erlang bit syntax there are 2 clarifying (?) type synonyms:

bytes == binary
bits  == bitstring

which are basically telling you to think of binaries as sequence of bytes, and bitstrings as sequence of bits. Quite obvious right? Well, it wasn’t for me at first.

It’s also worth noting how binaries and bitstrings are converted into text strings. Given the binary <<16#50>> storing the letter ‘P’,

7> <<16#50>>
<<"P">>
8>erlang:bitstring_to_list(<<16#50>>). #I could've used binary_to_list()
"P"          %great!
9>erlang:bitstring_to_list(<<16#50:5>>).
[<<16:5>>]  %mmh...

The result of command #9 is not exactly what I had imagined. Yes, it’s a list, but it’s certainly not a text string, and I was expecting a text string. Why was I expecting a text string if the API is named bitstring_to_list() ? Because if I was in the middle of coding a text manipulation algorithm and called bitstring_to_list(), I would probably (wrongly) assume that it would do some magic and transform any bitstring in a usable text string. Why? Because we are used to treat text strings as lists. Why? Because we don’t have APIs that mention “strings”: all the builtin APIs only mention lists. That’s the problem. We are using a list API as if it was a string API, when a generic list is not necessarily a string.

Changing a UIButton title and dealing with button States

If you are changing the title of a UIButton programmatically, you will naturally use the method setTitle:forState:. Easy enough… well, sort of. What do you put in the state parameter?

My first reaction was “I’m going to put all possible states since I just want the button title to change no matter what.” So I blindly bit-OR‘ed all the possible values defined in the docs.


[myButton setTitle:@"New Title" 
          forState:UIControlStateNormal | UIControlStateHighlighted | UIControlStateDisabled | UIControlStateSelected];

Sound reasonable right? Wrong. If you do that here, your button title is probably not going to change at all. The problem is that the “normal” state (per Apple docs that’s “enabled, not selected, not highlighted”) is defined as such:

enum {
    UIControlStateNormal   = 0,
    UIControlStateHighlighted  = 1 << 0,
    UIControlStateDisabled     = 1 << 1,
    UIControlStateSelected     = 1 << 2,
    ...
}

so if you bit-OR all of them you are actually going to set the title for ALL states EXCEPT the “normal” (most common) state!

Sigh…

Erlang bit syntax mini How-To

I don’t know why but Erlang bit syntax always confused me. I always skipped it while reading the docs, until, well, now that I need it. I should say this is not meant to be an exhaustive how-to by any means. It’s just a collection of notes, but howto sounded better. 🙂 There are better guides out there. [Reference docs too.]

Anyway. Here’s some binary data in Erlang:

<<16#1192c05a:32>>

What does all this mean? Let’s analyze it, left to right.

  1. 16# This specifies we want to express the number in base 16.
  2. We have an eight digits hex number.
  3. No type specification is provided: default is unsigned integer.
  4. No unit specification is provided: default for integer is 1, which means ‘bits’.
  5. :32 Size specification: this tells erlang to consider 32 units, which in our case means 32 bits, since we are dealing with bits.

Let’s evaluate it:

86> <<16#2092105a:32>>.
<<32,146,16,90>>

What if we forget to specify the size spec? In that case the default will apply and since we’re dealing with an integer type, the default is 8 (bits). For Erlang this means we are going to return the least significant byte:

87> <<16#2092105a>>.
<<90>>

Now that we know that, we can get a subset of bits by setting the size accordingly:

88> <<16#2092105a:16>>.
<<16,90>>     %two least significant bytes

We don’t need to specify a size multiple of 8:

89> <<16#1192FFFF:15>>.
<<255,127:7>>

It’s pretty cool how easy it is to slice bytes apart at the bit level. I was sort of surprised that if we slice some internal bits it looks like the bits at the right are moved to the left. E.g. here we take the 4 least significant bits of the first 0xFF:

90> <<16#FF:4,0,16#FF,0>>.

but instead of obtaining:

<<16:4,0,255,0>>
F 00 FF 00

we get:

<<240,15,240,0:4>>
F0 0F F0 0          [240 == F0]

Also, the value doesn’t need to be a literal, it can be an expression:

91> N = 16#FF00FF01.
4278255361
92> <<N:32>>.
<<255,0,255,1>>

And therefore, given some binary data, we can also pattern-match it super easily:

<SourcePort:16, DestinationPort:16, CheckSum:16, Payload/binary>> = SomeBinary.

There’s more to Erlang bit syntax than this, but I’ll stop here for now.

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.

“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.