CodeConf Sunday Summary

Here are my notes from Day 2 of CodeConf 2011. You can also check out my notes from Day 1.

Projects, community, and GitHub - Andy Lester

[Slides]

Andy is the guy who wrote ack, and he got to his main point right away: GitHub is great for developers, but it’s not great for end users. It’s important that we take those users into account, because there are many more possible users of our software than there ever will be developers or community.

It’s important that we realize that newcomers do not care about source code. They want to see three things:

1. What’s it do
2. What’s it look like
3. Do I want to use this or not?

Therefore, your project should have a project site. It needs a URL; they’re cheap, and they let you change stuff later if you want to move hosts. This page needs to have these three things on it, to help your newbies.

A good and bad thing is that GitHub has such a low barrier to entry, that tons of new people are doing it. This means we need to be extra encouraging of our new users, and help them get involved in our projects. You should be extra gentle with patches from new people: brevity will be perceived as harsh. You should only accept patches that help your project, but accept patches from new people if at all possible, even if it’s a small or trivial change. That magical feeling of getting accepted will draw them in.

Make a project guide for your project: it needs to break down the project into small chunks, and provide direction and standards and a preferred workflow.

Also, don’t forget to monitor your fork network, sometimes people build cool things and don’t send you a pull request!

Finally, it all really boils down to this: put yourself in a newbie’s shoes. Make things good for them.

The Ethics of Abandoning Software - Seth Fitzsimmons

“I’m Seth, I abandon software. specifically oauth.” Seth talked a lot about the lifecycle of open source software, and the hows and whys of handing a project off to someone else.

The Life and Times of Software

Here’s the outline of the four stages of the software development lifecycle, and the motivations for each step:

1. Writing
   • scratch an itch
   • money
   • self promotion
2. The Releasing
   • no reason, because it’s so easy to share
   • goodwill, it’s good to help others!
   • self promotion
   • tool to be recruited by employers,
3. The Maintaining
   • community
   • Money
   • demonstration of responsibility
4. The end This process happens in stages.
   • No longer interested
   • active disinterest
   • denial and neglect
   • Letting go, and moving on

It’s so easy to share code now, everyone is doing it, which leads to more abandoned projects. We need to examine the consequences of this, and learn how to give up projects gracefully.

Farmville on iOS - Amanda Wixted

“Farmville - Your Mom Loves This Shit”

The beginning of this talk was one big ad for Farmville, frankly. “Here’s what Farmville is, here’s why it’s awesome, we wrote an iOS client, it works the same way!”

She did talk at the end a little bit about things that are different from the web to iOS. Sprites were encoded from .swfs to .pngs. They use Cocos2D, which gives you a nice framework for building games on iOS.

One big thing that changes when you develop for an embedded device is memory constraints. Their biggest issue with this revolved around the animal sprites, which take up a lot of space. So they needed to be paged in and out, sometimes often.

They still used UIKit on top of the EAGLView that Cocos2D gives you, so that they could use UIKit to provide the usual kinds of menus and such.

For an alternate set of notes on this talk, John Garza sent us an email:

Amanda covered basic social gaming concepts, and why, she thought these types of games were important in the social landscape (the evolution of fb’s poke to an fb game’s ‘give a gift’ system). And the idea of connecting to your friends and family who you might not have time to connect with in the normal social way (messages, email, phone calls). Coming from Namco, and her work with launch game titles for iOS devices, she was tasked with creating the same easy of use experience in a native game client in order to preserve the type of gameplay that so many users already were used to on fb.

Farmville itself, is a basic isometric build-your-own-farm which makes use of the painter’s algorithm (or priority fill) to project a 3d scene onto a 2d plane.

Their plan was to go about creating a client that would not require a change of backend server code or the underlying server game code. One of the early roadblocks they came across was the obvious network latency with working with cell devices. To overcome that road block, they abstracted a transaction manager system to queue any type of specific game transaction and transport them to the game server in a non-blocking way so the game client wouldn’t hold up with user.

Another obstacle was the sprites discussion mentioned in the summary, and the need to make sure some (but not all) graphics were cached locally on the device, and how they implemented a feasible way of pushing updates to sprite graphics as updates to in-game items are often large and frequent (monthly or sometimes every other week).

They ended up with an update xml file pointing to changed/added assets stored on game serves which were hashed-named graphics packages for each asset (using a weird not-so-good-quality sprite graphic format called ~PVR? - My notes are sparse on this point). Amanda spent a few moments lamenting on how xml was a poor solution for this job and in hindsight, json would’ve been much better.

In the implementation side, besides the mentioned Cocos2d, Amanda also mentioned the development of FontLabel for incorporating custom fonts into pre-4.0 iOS applications, and how this package is still used today for backwards compatibility (post-4.0 now has this feature)

https://github.com/zynga/FontLabel

Building & engineering around startup uncertainty - Mike Krieger

[Slides]

Confusion sinks startups, so we need to fight it. First thing that needs to be handled is the product itself, and what needs to be built. The second part is the technical challenges that happen with building said product.

Instagram came out of a project called burbn. It was an HTML5 app that did social/mobile/location stuff. The most asked question was “what are you guys?” You have to actually focus on something. And it took them three months to get less confused.

They did this by doing four things:

1. ideate
2. validate
3. build
4. send out & iterate

Ideation is about creating your original ideas. They don’t code until they sketch out a UI. And they’ve built and thrown away entire features on paper. This is an example of ‘making wrong less painful.’

Validation is about getting feedback from users, to confirm that your thoughts are true. Every social app should go through ‘the bar exam.’ If you can’t explain it to someone at a bar, then you need to simplify it.

Building is pretty obvious, but there are still some tricks. You still have to be able to learn while you build stuff. You can do this with a tight feedback loop, iterating on one week cycles.

You need to be ‘proud but embarassed’ about your first launch. Do a few features, and do them really well, to build your ‘minimalist viable product.’

“One day out in the real world is worth one month of guessing.”

“Use your friends and make some new ones” (for your beta)

All of this is about product uncertainty. As for technical uncertainty, the main question is “Are we building it the right way?”

Focus, and keep your team small. Ask yourself what your company is actually about. Your framework is not going to be the most important bottleneck. Stand on the source code of giants. Experiment with quick projects. The anti-pattern is “Let’s re-write our entire site.” An interesting way to think about features is “Could we rip this out in 20 minutes if it’s bad?”

Can Code Be Like Literature - Jeremy Ashkenas

If people were talking about Coda’s talk on Day 1, everyone was excited about Jeremy for Day 2. I think a lot of people were blindsided, they didn’t know what was coming, but Convore BLEW UP for this talk. I can’t hope to do it true justice, but here’s what I managed to pull out. Oh, and you can also see some other notes here, too.

Luckily, I managed to get my hands on a copy of the audio recording of my talk. Please give it a listen.

EDIT: Jeremy posted his slides.

“What makes code strange?” There’s lots of interesting things about code that we take for granted. Any given MacBook has 50 years of software history running on it at different times.

We use languages like Ruby Python or JS because they let us write code like literature. It fits the way we think. Let’s be honest, we don’t use Ruby for engineering reasons.

Dijkstra gives us lots of reasons to treat code as something different than other kinds of literature. “I do not know of any other technology covering a ratio of 10^10.”

How big is the spec for you code when you print it out? If you’ve never run code, is it still code?

“By evoking the need for deep conceptual hierarchies, the automatic computer confronts us with a radically new intellectual challenge that has no precedent in our history.” Code is a fundamentally new thing.

Code is logic. Haskell, no IO, did it ever run? Knuth’s definition of software.

Code as Law. We set up constraints on the variables and objects in our code, and it defines the possible space of our bits. When we write code, we’re taking the infinite blank space of our hard drives and CPUs and narrowing them down into something meaningful. In the machine, code is the only possible law.

Code as Art. Knuth was all about this. “Science is knowledge which we understand so well we can teach it to a computer; and if we don’t understand something it is an art to deal with it.” Concrete arts vs Abstract arts.

Code has a dual audience. The machine and the reader.

“The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility…” - Dijkstra

The history of programming languages is all about ‘how do we address both audiences.’

Dijkstra’s Structured Programming vs Knuth’s Literate Programming.

Code as literature. “Meaning belongs to a text or to a program to the extent that it acts upon intelligence in a particular way.” We say that a textual work is “literary” if it contains a high density of meaning.

“While we count the lines of code we use, the battles here are fought, won, or lost on how much power of meaning lies under the syntactic forms.” - Alan Kay

Code is still writing. We use literary abstractions in code. He gave three or four examples, but I couldn’t really take notes fast enough to do them justice. My bad!

Object Orientation is an explicit Biological Metaphor.

Code as Commons. We are participating in a society, reading and writing code is about being a participant in a civic society.

“Some programs are elegant, some are exquisite, some are sparkling. My claim is that it is possible to write grand programs, noble programs, truly magnificent ones.” - Knuth

Our best practices are killing us - Nicole Sullivan

She was checking out duplication in CSS of big websites. Facebook was one, Salesforce was another. For example, Salesforce has 3,668 padding declarations. She started wondering how many other people were being sloppy with CSS, and she looked at the Alexa top 1000 websites. !important is a code smell, and the biggest site had 518 declarations of it! float usually means that you haven’t build up the proper abstractions for your design. Use grids instead. font-size is also something that people use far too many of. 13px bold is basically the same as 14px. The worst offender for this was 889. 25% had over 100.

Insanity: doing the same thing over and over and expecting different results.

Three best practice myths:

1. Don’t add extra elements
2. Don’t add classes
3. Use descendent selectors exclusively

She talked about CSS specificity, which is still black magic to me, because I’m a CSS noob. She then talked about ways to modify elements in certain parts of the page in the best way. Frankly, I’m not sure what the best way is to summarize these slides, so hopefully someone else will have a better one for this talk. :)

She did end up bringing up something we all do, but feel bad about it: coding via Firebug.

Once you get really deep into CSS, you can easily end up in a very hostile environment for your code: you’ve got two layers to develop, and it’s really hard to tell which rules take precedence, and it becomes basically impossible to get the look and feel that you’re going for.

How do we solve all of these problems?

1. Add non-semantic elements judiciously
2. Keep specificity as low as possible
3. Abstract repeating visual patterns
4. Use specificity to define your architecture

By doing the right thing, Facebook was able to cut their average CSS bytes per page by 19% after gzip and html bytes per page by 44% before gzip.

Farming vs. Mining - Will Shipley

Will was a last minute addition in the lineup, so he didn’t have slides.

“They always say to start with a joke, so: git submodule support.”

He pretty much gave a slightly extended version of his latest blog post, Farming vs Mining. So I’ll just leave that up as summary.

That’s it!

All that’s left is dinner and drinking, so I’m out! I hope you’ve enjoyed these summaries, and I’m really looking forward to an awesome CodeConf next year.