Leon Gersing

For those who requested the slides from my Pecha Kucha talk at CodeMash 2012, here you go. All rights for photos belong to their perspective holders. For those I could not find copyright info, please feel free to get in touch and I’ll provide full credit as required by your licenses. Thanks!

Leon

link: http://public.iwork.com/document/?d=Love_-_CodeMash_2012_Pecha_Kucha.key&a=p79052775

browse here:

lickypickystickyfree:

I do live in a gorgeous corner of the planet

CoffeeScript is something that I’ve watched for a very long time and my first attempt at using it in a project was early in its development and while I wanted to commit patches, reading some of the conversation around the purpose and overall goals made me realize that I simply see JavaScript differently than the author (Jeremy Ashkenas, whom I do not know but would LOVE to have a drink with (alcoholic drink or otherwise) and pick his brain, if anyone knows him and would kindly introduce us at a conference or something :). I’m buying, btw!). Different is wonderful and should be celebrated; encourage! Which is why I am loathe to write an article like this but after being mis-represented on twitter for the ump-tenth time, I decided it would be in my best interest to attempt to articulate my perspective first hand.

CoffeeScript makes a wonderful assertion of referential transparency in it’s scoping rules. By eliminating the “var” keyword and wrapping the entire context in a closure, it’s impossible to unwillingly scope variables globally nor can you augment outer scopes in an inner context through assignment which is fantastic. So far I’m loving this! Throw in all the syntactical sugar, iterators, and list comprehensions and hot damn if I didn’t think our brilliant friend was trying to “haskell-ize” JavaScript! Until I saw the class keyword. In this, my heart sunk. Then I saw a differentiation between “->” and “=>” in which the very notion of the scoping rules being encapsulated by the language seemed to be leaking back into the developer’s lap. Finally, the back tick (`) to interpret something as JavaScript inline. These 3 items are significant concessions on the overall vision that give me pause and I begin to ponder “In what context, would I need a back tick?” or “If classes ape their statically typed brethren of Java, then, idiomatically, is the idea that I should augment them by reference? and if so, is it even possible to do so given the implementation of var without the overhead of accessor methods? And if so, doesn’t that just kill all the cool stuff that came before it?”

All of these questions came up in the first project I used Coffee in. It’s not the that Object modeling metaphor used in CoffeeScript is bad, it’s just overly object-oriented and builds on OO style inheritance. JavaScript has a built in mechanism for attaching functions to any instance, like composition aka “mix-ins”, which can lead to high degrees of function reuse outside of any domain logic that may be encapsulated by a class to begin with. JavaScript’s Prototypical inheritance model is so simply in it’s implementation that it actively discourages large object graphs from being constructed through traditional OO methods. Yet CoffeeScript is engineered to dismiss this compositional simplicity in exchange for a more complex albeit more familiar OO style inheritance model. This, in my opinion, makes CoffeeScript less transparent that JavaScript, increases the complexity and introduces an amazing amount of generated JavaScript code into your runtime interpreter that contains little value over JavaScript and no compile time optimizations (closures don’t count, scoping doesn’t count). This means that CoffeeScript is not a language with it’s own identity and purpose but rather a bridge to another one. CoffeeScript classes have attributes and properties that are encouraged to be mutated by reference so a language contrivance was devised (@) to allow OO style encapsulation while still trying to provide Functional referential transparency in anonymous contexts… wrap your head around that. I can’t. {} is an object, any object, in JavaScript. What good does it to force it into an “Animal” type that extends another and another and so on? So that I can know that {name:”Leon”} can be safely mutated in it’s scope but not outside of it? CoffeeScript’s Class system and inheritance model adds un-needed complexity in a way that I’ve yet to comprehend the inspirations for. I’m going to scope the rest of my article to deconstructing it and leave some of the other issues for another article.

Ironically, if the idea was to mix-in existing functionality via functions, Jeremy wrote a much more simple and elegant version of this in 6 lines of code for underscore.js (yes, he’s the author of both!) in the extend method; extend is simple, idiomatic, and encourages the construction of tiny and discrete units of code that can become polymorphic as the need arises. Here’s the extend function in all it’s glory…

_.extend = function(obj) {
  each(slice.call(arguments, 1), function(source) {
    for (var prop in source) {
      if (source[prop] !== void 0) obj[prop] = source[prop];
    }
  });
  return obj;
};

Right?! RIGHT! It’s awesome! that means I can compose my objects (as late as runtime!) from existing objects, objects that don’t exist and objects I don’t even know exist yet. Each composed to be as simple or complex as the domain allows, without the increased overhead of the OO object model of CoffeeScript’s “class” implementation. I can give functions to objects, properties, anything my heart desires, whenever I want.

I would love to juxtapose the implementation of the class based inheritance in Coffee to the simple extend in _.js but the comparison is orthogonal and unfair. Instead, I’ll compose methods onto a tiny object from the class example in the CoffeeScript docs. First, let’s examine the output of the Class results from this CoffeeScript:

class Animal
  constructor: (@name) ->

  move: (meters) ->
    alert @name + " moved #{meters}m."

class Snake extends Animal
  move: ->
    alert "Slithering..."
    super 5

class Horse extends Animal
  move: ->
    alert "Galloping..."
    super 45

sam = new Snake "Sammy the Python"
tom = new Horse "Tommy the Palomino"

sam.move()
tom.move()

The generated JS:

var Animal, Horse, Snake, sam, tom;
var __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
  for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; }
  function ctor() { this.constructor = child; }
  ctor.prototype = parent.prototype;
  child.prototype = new ctor;
  child.__super__ = parent.prototype;
  return child;
};
Animal = (function() {
  function Animal(name) {
    this.name = name;
  }
  Animal.prototype.move = function(meters) {
    return alert(this.name + (" moved " + meters + "m."));
  };
  return Animal;
})();
Snake = (function() {
  __extends(Snake, Animal);
  function Snake() {
    Snake.__super__.constructor.apply(this, arguments);
  }
  Snake.prototype.move = function() {
    alert("Slithering...");
    return Snake.__super__.move.call(this, 5);
  };
  return Snake;
})();
Horse = (function() {
  __extends(Horse, Animal);
  function Horse() {
    Horse.__super__.constructor.apply(this, arguments);
  }
  Horse.prototype.move = function() {
    alert("Galloping...");
    return Horse.__super__.move.call(this, 45);
  };
  return Horse;
})();
sam = new Snake("Sammy the Python");
tom = new Horse("Tommy the Palomino");
sam.move();
tom.move();

Now here’s the same re-written in pure JavaScript.

function move(aDistanceOf){
  var it = this.name || "It";
  if(arguments[1]){ alert(arguments[1]); }
  return it + " moved " + aDistanceOf + " meters.";
}

var snake = { name: "Sammy" };
var horse = { name: "Tommy" };

move.call(snake, 5, "Slitering");
move.call(horse, 45, "Galloping");

That’s it. Now, I know what you’re thinking, “Leon, please, the Coffee example is contrived and doesn’t represent real world domains.” You’re right and so is mine as a result. “But you also didn’t create real domain models.” Also right, because I didn’t have do, nor would I ever want to. Therein lies my point. Sometimes a struct is a struct and not an class. The difference that I’m desperately trying to convey in this overly simple context is that by leveraging FP over OO one can provide not only a more dependable abstraction but when combined with JavaScript’s inherent flexibility as a language, we can achieve true referential transparency and polymorphism. As my domain continues to increase in complexity I’m not concerned about constantly redefining my object graph, instead, I pass them through the move function as I would any valid javascript object to achieve my end goal. When I encounter a task that move does not make sense for, I can create a different function, add additional arguments (for say, callbacks) or refactor this one (be sure to run those tests!)

In terms of pragmatic interface design, I’m not impressed by the fact that I have to think of the “move” function as only pertaining to that model’s object graph. It’s an abstraction that is bound (and encouraged) to leak. This is a fundamental difference between OO and FP and the crux of my frustration with CoffeeScript. FP encourages building small functions that do not mutate state and can be bound together as needed to perform a task whereas the OO philosophy is to encapsulate and achieve polymorphism through interface or contract. The more dynamic your context the more OO’s encapsulation paradigm, as seen in the inheritance model, leaks and defies it’s 3rd and most important tenant: Polymorphism. Even these 2 contrived examples above, if I look at the majority of CoffeeScript I’ve seen written at EdgeCase (including my own… guilty.) there has become this Java-esque DTO on the client side that takes a pure, evaluated, ready to go json object that is sent back from the server, xhr style, and translates it into a “Snake or Horse” instance. for what? This is where Jeremy’s claims to “just as fast or faster as the JavaScript you’d write” fall down. The overhead encourages more complexity, more computation and ultimately more indirection.

CoffeeScript sees the world through OO’s eyes. When I see JavaScript, I find beauty in it’s ability to be a dynamically typed Functional programming language. (that’s your TL;DR;, friends.)

This doesn’t mean CoffeeScript is BAD, poorly written, without merit. In fact, I encourage you all to check it out and decide for yourselves. I think you’ll find a clean, well crafted lexer and a sweet tokenizer written in JavaScript. That’s a pretty cool thing in itself; something worth celebrating. I simply find that outside of an academic context I don’t prefer it over JavaScript. JavaScript’s function keyword and curly brackets aren’t “ugly” to me, they are useful indicators of code smells. Do you have too many of them in a row? Time to break down your functions. This is not a problem with JavaScript, this is a problem with developers. CoffeeScript’s encouragement of OO patterns over Functional ones seems, to me, misguided in it’s current form which is not a compile-time machine or VM optimized language alternative to JavaScript but a bridge that seeks to help you write better JavaScript at the expense of gaining the wisdom of what that even means.

If you’re a fan of OO you’re going to love CoffeeScript from day one, guaranteed. If you’ve never tried to see the world through Functional glasses then I assert that you’re going to be missing out on a few beautiful vistas. Even if you go back to OO, give your solution a try in a functional style before turing JavaScript into Ruby or Python just because it feels more comfortable. If you can’t do it on this project, try it at home, or better yet, learn Erlang or Haskel or F# or Clojure and try to see the world that JavaScript sees before you turn it into something it’s not.

I hope you enjoyed this article. It was painful to write because I want to see more wonderful things from authors like Jeremy (seriously, _.js is genius.). While CoffeeScript is not for me, it’s obvious that many others find value in it and that’s really all that matters.

Thank you, Steve. For Everything.

my iPad. :)

“Don’t try and bend the spoon. That’s impossible. Instead try and realize the truth… There is no spoon. Then you see that it is not the spoon that bends, it’s only yourself.”

Jim has a new blog post that solidified a few of my own thoughts on the age old saying I hear bandied about over and over at software conferences: “You can change where you work or you can change where you work.” A phrase that has only recently revealed its inner wisdom to me.

This statement illuminates a simple paradox. It reveals the person sharing it to be someone who has decided to change the environment around them in spite of direct opposition rather than to walk the path that they’d like to actualize. It’s rarely imparted in the other direction unless to hopefully reveal it’s inner wisdom from an outside perspective one more time. The paradox in this choice is that while it seems to provide an easy answer to a complex problem it’s really indirection. It’s denial. It’s a solution that lacks balance and reveals the individual making it to be in a state of waiting; not ready to embrace the path they wish to travel; highlighting the lack of understanding of themselves and why they are not at peace with the very task that used to provide such joy. This person and the opposite that they’ve created (manager, organization, team, so on) cannot accept the other and therefore balance cannot be achieved. They believe that fighting the opposite will be rewarded. They arm themselves with the texts and teachings of Software Practice Prophets and hold to these teachings with the fervor of a true dogmatist. Thus resulting in devaluing of the individual as they see their life not as it is but how they wish it could be. Manifesting in shame, loss of motivation/hope compounds like bad debt and as they fight a fight that they don’t even understand, knowing that once the others see the world through their eyes everything with be…perfect. Continually perpetuating the notion that there is a single path to enlightenment. That holding stalwartly, doggedly to the dogma will provide the enrichment of life that they so desperately desire. This if, of course, paradox. The 2 opposing sides must find balance and in this situation they cannot.

This is a choice. If there is wisdom to be gained through the teachings of a guide then that wisdom must be gained through experience. The wise man’s role may be to reveal to you a door to your path that you may not be able to see, to leave footprints behind from their own experience. The wise walk the path, with doubt, with questions, with fear, with hope, with joy, with passion. They walk with the full spectrum of human emotion and experience and they find others along the way to balance themselves and share perspective on the journey.

Jay-Z puts this perfectly in Renegade: “No lie, just know I chose my own fate
I drove by the fork in the road and went straight”

Jay recognizes there is a path, by those that walked it or want to control his experience but chose to forge his own path. The artifacts are, of course, new music and new paths for others to recite back as dogma. Which is, of course, entirely their choice. He made his, others must make theirs.

I wrote down a phrase after a terrible conference experience that I had that I never understood until recently.

“Dogmatist believe. Messiahs doubt.”

It’s not a quote from anything, just a thought I had while reading books over the years where I noticed a trend in both religious, spiritual, philosophical texts and from the messages I was hearing at the many conferences I used to attend. This seemingly paradoxical juxtaposition was of great fascination to me at the time and it wasn’t until recently, as I began to inherit the codebases of some of the very people I have come to respect from afar. My dogma had been shattered. You see, I had come to worship the dogma of idioms like TDD, Test-First, Test everything, patterns patterns patterns and more patterns. At first I was angry. “How could this person who lectured me for an hour at that conference about their clean code practices produce such utter contradictory drivel!?” That anger lead, inexorably, the its only conclusion: I missed the point. I was worshiping the messages of wisdom, seeing the footprints on the path as truth but that’s ridiculous. That’s dogma. They were, in truth, simply how someone achieved their goals repeated back. There was no wisdom inherent to the words or the individual who shared them. They were the living representation of perspective from someone walking their own path. I was using it as a buffer to prevent me from doing the very thing that would be the most beneficial: Making up my own mind.

My choices are my own and the wisdom they provide is only for me. When I am faced with the notion of “change where I work or change where I work” I realize that I’ve already made the choice. Understanding why I made it is the challenge and the only way to gain that wisdom is to simply start walking my own path.

“Don’t try and bend the spoon. That’s impossible.” or as I hear it now: “Don’t copy me for what I do. See past this illusion and realize the truth therein.”

“Then you will see that it’s not the spoon that bends. It is only yourself.”

Of course. There is no spoon.

Mitch’s documentary looks amazing. I can’t wait to see how it comes out!

I just saw this today and loved it. Enjoy.

Web frameworks are a dime a dozen these days, and they all promise to deliver enormous productivity boosts without limiting your creativity. The darker side of it is that while they often allow you to create applications very quickly, sometimes they make it pretty hard to…

Marc Peabody is a lifetime member in the awesome hall of fame. That is all.

I love how a device that no one has really used has caused such a rift in the geek/nerd/tech/yawn universe. So, I’m going to weigh in….

I remember when Apple came out with the Macbook Air and nerds were up in arms over that because of the price. It was under powered by their stupid, nonsensical standards. You know what happened? People who travel a lot and need a computer that allows them to get things done (email, documents, presentations, etc) while traveling on a plane or a subway or whatever. Guess what happened? They loved it and geeks didn’t buy one. You also forgot about it the next time another machine was added to the Macbook Pro line. Because __that__ machine was for you.

Not every user experience has to be a ubiquitous homogenized one. People are heralding iPad as things like a Kindle killer. Nope, you’re wrong again. If sales go down, they’ll drop the price. If no one buys it they’ll devote more time into building apps for iPad or the subsequent Google Android Tablets that are bound to pop up in the next year or two.

So, if you’re interested in one, buy one. If you’re not, then don’t. If more people like them than don’t then they’ll go the way of the Newton. If not, then get a Macbook and start hacking away at apps for it and fleece the millions of iPhone, iPod and iPad users out there who actually are interested in the device.

Oh yeah, and no one, __NO ONE__ has ever, __EVER__ said that the iPad was the end all be all of the future of computing, because that would be hyperbolic. IF you’re worried about your kid _not_ getting into computing because you only own an iPad, then buy that little hacker a mac mini and give them room to run. But stop with the whiny conjecture and hyperbolic punditry. I’m over it.

DISCLAIMER: I’ve been programming for years. Frankly, a computer that my parents can use without calling me for tech support every week has me pretty excited.

Me? Waiting to play with it but am very intrigued.

Anti Patterns Catalog: ” Anti Patterns Catalog ‘Catalog’ is a technical term in the PatternCommunity: a list of patterns is called a catalog. This catalog lists AntiPatterns. AbstractionInversion AccidentalComplexity AccidentalInclusion AcmePattern AlcoholFueledDevelopment AmbiguousViewpoint AnalogyBreakdownAntiPattern AnalysisParalysis AnAthena AnchoredHelper? AppointedTeam ArchitectsDontCode ArchitectureAsRequirements ArchitectureByImplication AsynchronousUnitTesting AutogeneratedStovepipeAntiPattern BearTrap BigBallOfMud BlameStorming BlowhardJamboree BoatAnchor CargoCult CascadingDialogBoxesAntiPattern ConfigurationAbomination? ContinuousObsolescence ControlFreak CornCob CoverYourAssets CreepingFeaturitis CrciCards CopyAndPasteProgramming DeadEnd DeathByPlanning DecisionByArithmetic DesignByCommittee DesignForTheSakeOfDesign. DiscordantRewardMechanisms DoerAndKnower DryWaterhole EgalitarianCompensation EmailIsDangerous EmperorsNewClothes EmpireBuilding ExceptionFunnel FalseEconomy FalseSurrogateEndpoint “

(Via .)

mnmal:

designeriphone:

“Good design means never having to say “Click Here”.

Sooooooooooo tired. And bored. Gnoght.

‘You have enemies? Good. That means you’ve stood up for something, sometime in your life.’

- Winston Churchill

(Via Minimal.)

I’ve had several interested friends ask about “how the precompiler” went. As the acting Iteration Manager I can say that it exceeded my every expectation but what does that “mean”. Well I’m going to be compiling the information that was collected from the event and putting it into a case study for a team of 50 developers, whom only half of which were familiar with the tools and process methodology, working from scratch on an application.

What did we learn?

What did we succeed at?

What did we fail at?

Those at the retrospective probably know some of those answers because we discussed them as a group and I made notes about how I may present this workshop in the future. (possibly at CodeMash again next year?)

But I wanted to let everyone know that we did complete most of the app to make it fully functional. In fact, in the afternoon we were already looking to refactor the architecture of the application and that is where it is right now. So, Cory Flanigan’s group at set out to do just that. Cory and I will seek to complete the touches and push out to http://symposiast.com.

So, stay tuned and if you’re interested in seeing where we ended up check out the code that was committed and merged into master at http://github.com/fallenrogue/CodeMash-2010-Precompiler-Application.

Perception is truly reality. The way we see the world shapes how we look to solve problems. It’s with that grain of salt that I offer up this response to Mr. @JonathanPenn’s tweet to substantiate my claims on the interwebs this morning. Boy, I hate getting into these messes but he’s right to call me out and clarify. Here’s our convo:

With that history you must know that I spent years in .NET and C# so Java is going to seem like second nature to my eyes; rather than, say, a C++ programmer who will, likely, see something familiar in Apple’s Cocoa/Obj-C environment.

That said, my comment takes the following into consideration…

Java is dominant right now (stats!). In the Enterprise, they’ve got a pretty large hold on the development community and love it or hate it, that lowers the barrier of entry to developing on Android. Most Java developers will be immediately comfortable with the conventions laid out in Android’s development cycle and given there’s an exceptional Eclipse plugin for Android development Java developers don’t need to learn much more than Android’s specifics in their own language, IDE and platform of choice.

There’s a mountain of Java tutorials available. Even if you’re new to Java you’re going to be hard pressed to miss out on the latest and greatest information that the platform has to offer. My searches for information on Cocoa development have met with wildly differing opinions and little consensus. In fact, I was in the C based API on my sample app to play/manage sounds until Jon mentioned there was an Objective-C based API that could do the same thing. Even Apple’s documentation was wishy-washy on the subject until I took the time to read the Cocoa Touch programming guide for Audio (not a fun read, BTW) that it even mentioned the class Jon pointed out.

On a 1-1 basis Android’s frameworks seem to be providing developers simple abstractions to every possible task that you’re going to want to perform on the device while Apple’s Cocoa Touch frameworks seem to be a mess of improvements over Cocoa, missing abstractions and idioms are published by Apple and not driven by the community using them. AGAIN- that is conjecture but that’s what I’m seeing.

Take, for instance, the following snippets to load an internal sound file reference and play it. First iPhone -

NSString *soundFilePath =
    [[NSBundle mainBundle] pathForResource: sound
                                    ofType: theType];

NSURL *fileURL = [[NSURL alloc] initFileURLWithPath: soundFilePath];

AVAudioPlayer *newPlayer =
    [[AVAudioPlayer alloc] initWithContentsOfURL: fileURL
                                           error: nil];


[newPlayer prepareToPlay];
[newPlayer setDelegate: self];
[newPlayer play];

See, it’s not complex. The syntax is simple enough (for the AVAudioPlayer class, this is not the C API which is far more complex) but things like getting a reference to an internal URI is 2 lines of chunky code that create references that I need to track now. It’s not bad, but there should be a simple way to load our references.

Let’s compare that snippet with the Android version.

MediaPlayer mp = MediaPlayer.create(this, R.raw.mySoundFile);
mp.start();

That’s it. I’m not splitting hairs over brevity; that’s not the point, the point is that the abstraction seems to be in the right place. We know we’re going to play sounds on a device. We know that those sounds are going to be local or networked. These are clear points of abstraction in OO and should be provided to the developer (IMHO).

From my perspective I get to tell the right objects to do what I want them to do and the details and minutia are encapsulated behind a nice API. If we’re on the same topic here are 2 equally good APIs first from iPhone and then from Android

Taking a photo with iPhone (in main.m)

UIImagePickerController *picker = [[UIImagePickerController alloc] init];
picker.delegate = self;
picker.sourceType = UIImagePickerControllerSourceTypeCamera;

// cruft leading to our delegate implementation...
-(void)imagePickerController: (UIImagePickerController *)picker didFinishPickingImage(UIImage *)image editingInfo:(NSDictionary *)editingInfo
{
    // now I have image reference I can use! Sweet! 
}

See, there’s an operation that I know I’m going to need to perform on a phone equipped with a camera. Once you’re familiar with cocoa’s delegate/callback system then doing something with the camera is that simple. But still, I’m interfacing with a Controller object and not the Camera or “media” object. From an MVC perspective Apple’s controllers seem pretty heavy and try as I may there’s something icky. The Abstraction is there, though which is my complaint with many of the other functions I’d expect an always connected device to abstract. Let’s look at Android’s API for doing the same thing.

Taking a photo with Android

Camera camera = Camera.open();
camera.takePicture(null, null, new PictureCallback(){
    public void onPictureTaken(byte[] _data, Camera _camera){
        //Handle the photo
    }
});

So, lines of code aside they’re very similar but the Android object API is clear and uses the same idioms it has established with other objects in the system. There’s no muddy “is it a Controller or Model” confusion. To me, that’s an simple OO encapsulation that provides an intuitive API. AGAIN: my eyes, my perspective and my opinion.

For the last few points, before I go back to exploring both of these GREAT platforms. Things that have me more interested in Android at this moment than iPhone…

1: Android is open. Which means there’s a greater chance that your app will be seen on a diverse set of devices. This is a blessing and a curse. You’ll be required to handle such discrepancies but again, Google seems to have abstracted those decisions into small questions you can ask the platform in one method. But you will have to be concerned about it and I can see a legion of experts born from this very issue. Good knew is you can sell or give away your apps on your terms. Not Apple’s.

2: Testing. Java has better support for current BDD/TDD methodologies. I’m going to state conjecture as fact here. I can’t find a great BDD framework for Obj-C and who cares if I can’t use it well in cases where I’m testing C code.

3: Memory Management is a solved problem. Google knows it, you know it. the C champions will always lay claim that Garbage Collection is slower than their own hand crafted memory management techniques and that may, in fact, be true. But by what degree? What about line of business application developers? They know the value of one less thing to worry about; one less thing that can go wrong. I know obj-C 2 has an opt-in GC but I never see it in use on the iPhone and I’m not sure why. I assumed it wasn’t supported, again, someone please let me know in the comments if this is wrong.

In the end, everything is perspective

As one who primarily has developed line of business applications and the bulk of that on the .NET platform or in Ruby, Google’s Android platform seems directly poised at the GTD crowd and Apple’s iPhone seems hell bent on restoring C++ and it’s superset Obj-C to the forefront of Alpha-Geekdom. Both are great approaches but when you couple the innovation coming out of the Android devices, the open source ease of startup, tooling support and articulate APIs; Apple needs to continue to innovate on the development side as well as the consumer side.

Apple is, hands down, the reason we’re even interested in this comparison. I love my iPhone. I’m certainly not giving up on my goal of getting in the App Store with something, ANYTHING. But I must say, if they are not cognizant of the power that Google is providing developers they may see folks piloting, prototyping and promoting Android over the iPhone.

I don’t know if it’s time for the Cocoa community to build a better boat or Apple’s but somehow, to me, that’s yet another solved problem and therefore another win for Android.

OK, Jon. I await your post clarifying all of this up for me on the iPhone side and even better, I CANT WAIT to pair with you on iPhone fun at CodeMash! ;)

Thank you, Steve. For Everything.

This is not an easy app to develop…

Not that any app is particularly easy to develop but with Sparks there were so many things that we encountered during the first version that we set out to solve in the second that I felt that it would be worth sharing the experience here for those curious and those looking to venture into building an app themselves that deals with 3rd party services.

Threads, Queues, Blocking and Blocks

One of the most difficult things to manage in Sparks is the crazy amount of network activity that is required to do even the most simple of tasks. 37Signal’s API is certainly well documented but, IMHO, a bit too restful for its own good. Architecturally, it makes it quite simple to know where to get data but unfortunately for us, most refreshes to rooms require several network requests and the initial loading of messages can take some time if you’ve got multiple sites and rooms. I tried several approaches to the chattiness of the networking code each with it’s advantages and disadvantages and in the end settled on combinations of a few of them.

Danger! It’s about to get geeky in here…

If anyone’s interested I’m more than happy to delve deep into the details on our final choices but for now, I’ll leave you with an indication of what’s happening now using my own account as a basis for which you can make some of your own comparisons.

When you first load the application, there is nothing stored about you or your habits as a user. So, we send you to 37Signals to authorize Sparks which allows us access to all your campsites. This information is very basic and doesn’t give us quite enough to show you anything yet, so we then cache some of the small stuff (API, OAuth tokens, site urls, etc) and then start the network requests.

I have 4 Campsites that I’m a member of so for me, that’s 4 requests that I need to make just to get a list of rooms. Depending on network traffic, latency, and the device I’m using this is a small start. From these 4 requests I have enough information to see the names of the rooms that belong to each site and that’s about it. So, I hang on to as many connections to the site subdomains as possible on background threads (via GCD) and start asking each room for it’s metadata, today’s transcripts and recent uploads. I have between 10-20 rooms for each site, for an average of 15 rooms and 3 requests per room for the first load. If you’re not keeping score…

4 sites, 60 rooms, and 3 requests per room for initial load for a total of 184 URL Requests in the first few moments of the app’s launch. Once we have the messages, most of them are either white noise (I don’t really care if someone entered the room 12 hours ago…) or missing information.

Missing you say? Well, not missing, per se, but RESTful so each message has a reference to a user-id but no information that may be useful for displaying the message like the user name. Since some users are not actual members but guests I can’t guarantee that a user is going to have certain data points so I have to make a request for every new user-id I find. On average I have 50 users across my sites so I’ve got to get them as soon as possible or risk delaying what I can show in the room if you happen to hop in before I’ve had a chance to cache the users. So, while I’m parsing the messages (did I mention that the Objective-C regex engine leave a bit to be desired…) I’m firing off between 30-50 new requests for user information. Other messages, like document upload messages, don’t have enough information for me to share, preview, load the resources, or even link to it reliably so I have to call another end point to get that information. This has been an average of one initial request per room’s initial load with a separate request for any new messages that happen to arrive during the use of the app.

If you’re losing count we’re near 250-300 network requests and you haven’t even joined a room yet. So you do. You “Enter” a room.

Well, this isn’t a typical UDP socket connection to stream a chat room or IM session. No, instead, to get more information and to enable https streaming over SSL in your room you MUST already be ‘in’ the room. So, one request to a DIFFERENT subdomain than the site subdomain to enter the room. Which makes reusing the network connection that is already in use on one domain difficult, if not outright impossible. So we don’t. This means, that if you’re wanting to get into a room and start streaming the existing connections cannot be reused so we have to fire up a new one and wait until we’ve got confirmation that you’re inside a room before we can stream the messages. This is not a Socket connection to a remote server. It’s a TCP connection to a standard HTTP server with the keep-alive headers on so that you can hold the connection. On a desktop app, this is usually fine, I’ve done it a million times. But on a resource constrained device with questionable network reliability you’re going to be counting bytes in packet bursts and performing health checks as often as possible without revealing the inner workings of all this data coordination to the end user. If I showed a message every time a connection was dropped or forced to reload or that your credentials needed a re-challenge you’d never stop seeing notifications.

That’s not to even mention the polling of rooms that you’re actively in and the possibility that a user may decided to tap the refresh button at anytime… which is actually valid given that if you have 60 requests to make to refresh your rooms it’s possible that 10 could be 2 minutes behind while 30 are up to date and 20 are in queue to be refreshed, including the only one you even care about at that moment in time.

In 10 minutes, I can reach hundreds of requests, in an hour thousands and it goes up from there. This is a problem that we solve constantly to ensure the bare minimum amount of data is being used while keeping the inner workings of what’s going on as transparent as possible. I don’t want to go into too many details but, in case you’re wondering, we’re constantly tweaking the loading/refreshing algorithms to ensure the most optimal way to refresh your data based on your usage patterns, network reliability, 3G vs WiFi connection, and so on.

ALL of this is performed away from the main thread (The UI thread). All of it. In fact, it’s on multiple threads depending on your needs and what the iPad will give me (for me that’s between 10-20 on a given full day of use), mostly moved over to GCD from NSThreads and RunLoops (which v1 relied on) which means that most of the codebase had to be re-built to take advantage of the block based async patterns that are favored by GCD (and myself!). Even though the heavy lifting is done off the main thread, the sheer volume of possible callbacks that can be invoked can flood the main thread with updates that then must be throttled and queued again to be performed when it won’t destroy the user experience. Can you imagine if I refreshed the lobby for every network request callback? When we first entered beta one of the feedback points was the I should never load data on the “main thread”. Yes, that’s true and I don’t. I never did. But I did have to figure out just how long to pause between actions before reloading/refreshing so that not only would the refresh happen quickly but so that indexes of arrays weren’t resorted, lost or augmented so that by the time a callback did return, the target objects still existed and existed where the callback’s lexical context expected them to be.

iPad 2 is your friend… sorry.

All this really comes down to the fact that iPad’s dual core setup is the best way to get the most out of Sparks. It can handle the load, concurrently distribute tasks and hang on to network connections more reliably than it’s predecessor ever did. Testing the app on my iPad 2 vs Jerry’s iPad 1 reminds me every day that I seriously need to buy him a new one. (I’m waiting for iPad 3. Jerry you didn’t read that!) Most of the reports of hangs or long load times are due to the fact that the system is optimized for multi-core architectures and when one is available is the performance and latency is exponentially better. There’s not much I can do or say about it. I made a choice to support the latest hardware and given Apple’s direction (or what I see as its direction) it’s a forward thinking choice that positions the application for long term flexibility which is good for us and for Sparks and ultimately good for you.

All of this for… (TL;DR;)

Chat. On the surface, it’s simple. In fact, most of our users imply that they think of chat in one of 3 ways: ( at least the ones that email us… )

• IRC style - one room, one context, dedicated socket connection UDP data that is consumed and lost after you leave.
• Instant Message style - UDP/RDP/TCP messages between one user or a few users. Simple. Even Text messages follow a simplistic User B pings User A repeat.
• Web chat (campfire, hip chat, convoke) which is a new standard but most of the low-level networking is taking place on your behalf by the browser. A unit of code that has been tested and optimized OVER AND OVER AND OVER again and it still gets it wrong. (WebSockets are nice though!)

Our view of chat is considerably more interesting, much more complex and on a device that has limited resources. We don’t own the backing service which means that we have to play by someone else’s view of the way chat should work for them. Which it does, Campfire is a great service and it’s popularity is a testament to it’s usefulness. Unfortunately that’s sometimes at odds with what would make a smooth device chat experience.

I have spent many late nights working hard to solve these problems in a way that this complexity is hidden from you so that you can work, chat, communicate on the go in a simple and reliable fashion. Sparks for iPad 2.0 is a reflection of all the thought that Jerry and I have poured into this particular domain and we believe that we’re really starting to uncover the best parts of what Campfire has to offer and are looking forward to how we can contribute to the experience and provide something that’s not just “the website on the iPad” but a valuable extension to an already fantastic collaboration system. These problems (if you can call them that) are problems that make me excited to sit down at my computer and write some code. They are challenging yet rewarding and I can only hope that the end result and the path that we’ve been on is something that others will also enjoy sharing with us.

Leon

Hello everyone!

It’s been really quiet on the blog and that’s for good reason, I’ve been working hard to complete the latest version of Sparks for the iPad! In fact, even the Apple review process turned around our first review so fast that we were somewhat surprised to learn we were in the store as I was about to push a minor point release to deal with some issues with the new message viewer! That is currently awaiting review and will be released soon (fingers crossed!)

I’d like a moment to take you through some of the new features, what they mean and how we decided to include them into the new version. These features are based entirely on our use, the feedback from our beta team and emails from users of Sparks who took the time to reach out and let us know what they like, hated and desperately wanted.

The User Interface

Eric, one of our beta testers, often remarked that he was frustrated with the layout of the original app and how the ‘real-estate’ provided by the iPad was being under-utilized. We agreed. In the original version, there was great care to create an experience that mirrored the “campfire” theme with a rustic look and views of loose paper. The problem was that while this design was visually pleasing, once you’re using the app, there’s more that can be taken advantage of.

Where are all the buttons, labels and standard interface elements?!?

They’re gone. We took a long hard look at what we could show or hide, what was primary focus and what you needed to do in order to be effective in the app. The new “Dashboard” is an attempt to show details at a high level about the current state of affairs in your campsites while improving on 37Signal’s concept of a lobby. For instance, the list of users shows everyone that is currently available in a room, no matter where that room happens to be. If I’m looking for a user in the web app, I have to scan all the rooms in one site, then go to another page to see if the user is in a different room that may be more appropriate for the topic I have for them. Now, I find the user, tap their name and see all the rooms they are in as well as a link to their email address to send them a note when I need to.

The “active campers” number will not equal the number of folks in the list. This is on purpose. The count is an indication of how many of those people are actual chatting, engaging with other campers and not just “signed in” or “lurking” in rooms. It’s no use to try and get someone’s attention if they’re not listening.

The Charts

The charts currently contain a small bug which causes some of their numbers to conflict (Timestamps are being included in room counts…). This bug is fixed in the build that is under review.

The pie chart shows message distribution for each room that has messages loaded. Since Messages are loaded on a daily basis, this typically refers to the distribution for the day. If everyone is chatting in one room, head on in and be heard!

The bar chart, on the other hand, is to provide information about the global rate of messages hour over hour. A feature that has been requested is the ability to tap the bars and pie slices and they are under active development and will be released soon. (Pie selection is in the point release, bars will follow soon after.)

The Message (aka “In Room”) View

In Sparks 1, I wrote several 1000 lines of code to parse messages for rendering in Core Text. Every release added some other missing feature or changed some way that the fonts rendered or how the library performed. Sometimes for the better, sometimes… not so much. It became too much to handle for one developer and I made the choice that I wanted features over Core Text and we’ve moved to the WebView. Some JavaScript, some CSS and a lot of having fun led to what we have now. Image previews, Youtube video viewing, code syntax highlighting, grouped avatars loaded from 37Signal’s user accounts rather than gravatar and more. I mean, this is such a fast improvement over the existing reading experience I often times wonder why I didn’t make this choice earlier. then I look back at the font rendering from pre iOS 4 days and think… oh yeah. But now, the text in the web view is clean, crisp, easy to manipulate and leaves the door open for even more features that users were asking for since version 1.0.0.

Another choice was to remove many of the buttons and room titles. Instead, if you’re towards the bottom of the room’s messages, simple scroll past them to reveal the room you’re in, the current topic and a few stats on the room at that moment as seen through Spark’s eyes.

Transcripts for the room are available via the calendar icon on the menu and provide a simple and easy way to load the message from any given day in the past. Do you think that Sparks missed a few messages for the current day? Load today’s transcript again and we’ll try to fill in the gaps. Need to return to streaming after viewing the transcripts? Just select today again and you’ll be back to where you left off.

A little known fact, is that if you’re chatting and want to “reply” to a user, type an @ with the keyboard and then continue typing any part of a user’s name to auto select that user and press return (enter) to complete the name. No need to move your fingers from the keyboard to reply.

“Peeking”

Something that we started over on the iPhone version that made it into the iPad is the idea of “peeking”. Even though I hate to admit it, there are times when I’m curious about what’s going on in a room but I don’t really want to alter the other users that I’m visiting in. Say I can’t chat at the moment, or am on vacation, but I still am curious what’s happening on a project. I can double tap on any of the rooms in the lobby list and a popover will display the recent messages on disk so that I can quickly see what’s up and move on. The peek does not immediately force a reload of the messages in the room so if you’re not actually in the room, you may want to press the refresh button that is located on the right menu bar in the dashboard which will refresh all your rooms. Once the spinner is gone you’re ready to peek away.

That’s a quick overview for now, I’ll be following up with reports of the new stuff that’s in the works along the way and a few clarifications based on user questions and feedback.

As always, I want to hear from you. This app is a labor of love for us, we’re not a VC backed 100% of the time development effort on this application. We’re 2 guys trying to make the best campfire app on the iPad, something we want to use and share with the world. If we miss something or can help you use the app more effectively, don’t hesitate to ping us: support@nospoonsoftware.com.

Thanks for your continued support and stay tuned for more Sparks announcements that are coming your way!

Leon

Hey all, I’ll write a bit more in detail here in the next few weeks but I wanted to let you all know that Sparks for iPhone has reached a minor milestone and hit 1.1.0 today. Far from a bug fix release there are a few new ideas and concepts that have been added. Here’s a few highlights:

First and foremost, Jerry has delivered a phenomenal visual update. There are visual enhancements from the minute the app loads to when you lock it. There are more of these in the works and the aesthetic is a precursor to all the great things to come in Sparks iPhone and iPad. The messages, tables, backgrounds, splash page, icons, toolbars, everything has been redesigned or re-articulated with the user at the core of every choice.

Least you think I’ve been resting on my laurels, I’ve added a few bells and whistles of my own on the code side of things! Here’s a few highlights I’d like to quickly mention:

“Peek Mode” a.k.a. incognito mode. I hate to say it, but there are times when I want to see what’s been going on in a room but I don’t want to alert other users that I’m up working at 3:00AM EST and available for questions. This is what Peek mode is all about. From the Lobby tab, double click (or 2 finger single tap) on any room and the messages from the day are shown under a page curl. You’re now peeking in the room without joining. If the messages seem a bit out of date, run a refresh from the lobby. If you see the last updated date change (you know, within normal variance. Seconds are going to change even without a new message. ah relativity!) then there’s a good bet you might want to peek again.

Tab reordering now successfully remembers the tabs that you moved and will be saved the minute you make a change. The bug that removed tabs from the “edit” list is squashed so re-order away. My tab setup is: “Lobby - Pulse - Important - Search”.

Async and Parallel take center stage. For my tech/code savy geek friends out there, while looking at our overall plan for Sparks one thing was made clear: we can count on more than one core. The A5 chip has to be heading to the iPhone soon and the iPad 2 has it. We’re already highly async (as much as we can be) but this version is optimized for multi-core setups. If you’ve got an iPad 2 and you run Sparks for iPhone on it you’re going to simply be astounded.

It’s an exciting time for us; iPhone 1.1.0 is here and continues to evolve, alpha for iPad is just around the corner and we’ve a few more surprises up our sleeve that we’ll be sharing soon. We aren’t stopping any time soon and can’t wait to show you want we’re doing next! :) As always if you need anything holler to me: leon [at] nospoonsoftware.com

We’ve had a few emails and tweets asking about the iPad version of Sparks and whether features that are in the new iPhone version will be making their way over to the iPad. The short answer is an emphatic YES! I suppose that shouldn’t surprise anyone but I’d like to give a little info on where we are right now, where we’re going and some background on our process for the 2 apps. So, in no particular order:

Why iPhone? Well, we never set out to do it. Jerry and I wanted an experience on the iPad and that’s what we set out do. While we were at this year’s CodeMash I had no less than 10 people demand an iPhone version. By the end of the conference I had a working prototype and the rest is history.

Cool new features but where are they on the iPad? Patience, my friends! :) One of the big wins of the phone’s UX constraints mean that there is a lot less work to be done to bring ideas to life. We work hard to provide a compelling experience not just a list of features. If a feature seems cool but doesn’t quite fit then we take it back to the whiteboard and iterate on it. The iPad version has a lot of real estate to account for and it’s a delicate balance to find just where some functionality should go, if it’s simple to interact with and truly provides value. We could easily ship a “big iPhone” version to the iPad but it just doesn’t feel right (we tried it and hated it thus no universal binary). So, instead we shipped some features we’ve been discussing for a long time to the Phone to see if they were worth bringing over to the Pad. Many of them are but it means that the iPad is going to need a fresh coat of paint.

The Icon When we were creating the iPad version the only client representations of Campfire used the exact same HTML presentation that exists on the web. Jerry and I don’t actively dislike them (far from it!) but wanted to present an experience that utilized the best parts of the target platform. For example, if you look at how text is rendered in Safari vs native Text controls on either the iPhone or the iPad you’ll notice a clear difference. To us, this is important. We wanted to love using campfire away from our desktops. Jerry conceived a fantastic aesthetic for the iPad that would evoke the “camping/campfire” aspect of the namesake while not infringing on 37Signals’ brand. While this was a great introduction to the platform we eventually felt boxed in by the choice. Suddenly, new features had some kitschy outdoorsy pun in the name and when we started rolling our own eyes, we knew it was time for a change. We want to focus on chat and less on being a “campfire” client.

Long story short, we’re currently developing a major update to the iPad version. The iPhone version allowed us to quickly prototype some new ideas (not all of them… there have to be some surprises, right?) and provide value to a new group of users while taking our time in taking the iPad to the next level. The Icon hints at the new visual direction Sparks is taking that will eventually make its way to the iPad.

WHEN, WHEN, WHEN?! Jerry and I believe strongly in the notion that you iterate quickly and ship as often as possible. With this in mind we prioritize on a daily basis and push when we’ve had enough time with updates that we feel they are stable enough to ship. We could have held onto the iPhone until the iPad was ready but that would have meant time would go by with a pretty solid version sitting on the shelf while we worked on the iPad version. That’s not who we are and while it may feel odd for iPad owners to see new features hit the iPhone first, they’ll be reaping the benefits of real world testing and use from iPhone users when they finally come to the iPad. It all leads to a more stable, usable and enjoyable experience in the long run and that’s really what’s most important.

Hopefully that clarifies our position on the 2 platforms a bit. As always, if you have any questions, concerns or comments please shoot us an email at support@nospoonsoftware.com. We’d love to hear from you and can’t wait to show you what we’ve got in store this year!

~Leon

Just a few months after releasing our first application, Sparks - Campfire for iPad, we’re pleased to announce that we’ve launched a version for iPhone! Available in the App Store Now

For the first few weeks, we’re going to be running both the iPhone version and the existing iPad version at a discount to celebrate! So tell your friends (perhaps in Campfire… using Sparks!) to get the most simple and elegant way to use Campfire on your iOS devices with Sparks for iPhone and iPad