Hey everyone! Iām here at CodeConf, and I figured that if youāre not here, you might be interested in a summary of all of the talks. They are not being recorded, so Iāve spent the time to give you the tl;dr, and link you up to the slides. Enjoy!
Dr. Nic - Tinker Bell: being a good tools fairy
First up was Dr. Nic, and he talked about the importance of building tools to help you solve the problems you face. He gave three steps for tool building:
- Learn something
- Encapsulate what youāve learned in code
- Repeat and go faster
Basically, any time he learns something new, he builds a tool with it, so he can forget what heās learned. He gave an example of building a TextMate bundle with node.js as his first ever Node project.
Oh, and also, this:
Coda Hale - Metrics, Metrics, Everywhere
[Slides]
Coda gave an awesome talk about how important is is to measure what your code is doing. āSurprises are for birthdays: if something affects the business value of the code you write, start measuring it today.ā Basically, he said that everything we do boils down to creating business value, which is anything that makes people more likely to give you money. Code only generates value when you ship it, though, so itās important to actually measure production, not development. Also, our mental model of code is always subtly different than the code itself, so itās important to actually measure things, because your intuition is not always going to be correct. You never know when someoneās added a sleep(100) in your inner loop!
Jonathan āWolfā Rentzsch - Assumptions are Awesome
Jonathanās talk was mostly about Design by Contract. He started off with a great throwback to the old C programmers in the audience, talking about the difference between K&RC and ANSI C. For those of you who werenāt alive back then, with K&RC youād write functions like this:
void foo()
int bar;
{
printf("fooooooo");
}
Weird, right? Anyway, the idea of Design by contract and Eiffel is that you can add annotations to your functions that enforce ācontractsā: preconditions, postconditions, and invariants. For a pretend mythical Ruby example, you might do this:
# bar.nil? == false
def foo(bar)
puts "Bar won't be false here"
end
He mentioned that this isnāt so much error handling, as it is an alternate type of testing, really: itās about catching bugs.
Ariel Waldman - Hacking Space Exploration
Ariel gave a really cool talk about the maker movement and space exploration. She repeated an old mantra, āIf you canāt open it, you canāt own it.ā She also posed a really interesting thought question: What happens when space is as accessible to us as the internet is? Basically, more people should be looking at hacking on science, and not just code.
Hereās something thatās interesting: Itās really important that we work collaboratively on our hacking projects, because especially in science, not everyone knows everything: hardware, software, physics, biologyā¦ so we really need to figure out how to join these communities together and build awesome things. To do this, things need to be made ādisruptively accessible,ā they should be revolutionary, as well as easy to use!
Sheās gave an example of a really neat site that her friends made, over at http://spacelog.org/ , which is a great example of nerds taking a terrible government website thatās buried all of its information in pdfs, and made it super accessible.
Jacob Kaplan-Moss - Writing Great Documentation
[Slides]
Jacobās talk was really good, and heās talking about something that I really care about: documentation. Thereās a growing sentiment amongst developers around āDocumentation Driven Developmentā as a way to produce fantastic documentation for your project, which is something that we too often collectively ignore.
He mentioned that talking about writing docs is kind of like listening to your parents, telling you to eat your spinach. Django has really taken this idea to heart though, and the Django docs are two times as long as the New Testament. Heās specifically trying to encourage building a documentation culture, in the same way that Rails really built a test-driven culture.
Jacob didnāt shy away from controversy, either: He declared that āpatches welcomeā is terribly user-hostile, and āuse a wikiā is not an answer for documentation. Also, he made a strong statement that automatically generated documentation is basically worthless, because you really need to understand the underlying code already to use them effectively. He called Rubyists out on this: āYou do realize that by using rdoc as your primary documentation, you are saying that you care as much about them as Java people, right?ā
Ryan Dahl - Node.js
[Slides]
Ryanās talk was bruuuutal. I happened to be sitting next to some Windows guys, and they were good sports: Ryan ripped into Windows over and over again, but ended his talk with a plea: āIf youāre a Windows programmer, I have two questions for you. First, why do you eat poop all day? And secondly, can you help me? Because I really donāt want to come over to your room and eat poop too.ā To their credit, they went up and talked to him after, and hopefully this will turn into a great feature for Node.js: great Windows support.
That was the main thrust of Ryanās talk: the roadmap for Node 0.6. The biggest thing on the agenda is said Windows support, and itās going to require a big internal re-write, because Windows does concurrency much differently than Linux does.
Gina Trapani - Your Community is your best feature
[Slides-ish]
Gina gave a really cool talk about the human side of open source. It really comes down to just that: projects are made up of people.
The point where Open Source became real to her was due to one interaction on a mailing list: atduskgreg offered help moving to git and kicking off a community. This act of kindness really showed her what OSS is all about: people coming together and building fun things.
Thereās four things that are important to growing a community:
- Enable peer consultation
- Convert Newcomers
- Cast a wide net
- Help your project fulfill its destiny
She also mentioned that one person does not scale, so you need to design some process that will help you not be the bottleneck to your own project. Itās also important that code isnāt the only way that people can contribute to a project, so you should be open to people contributing blog posts, podcasts, or anything else that plays to their strength.
Gina also commented on the diversity of communities, and how important it is to get a diverse group together, because a monoculture will only produce software for that monoculture, and youāll end up alienating users who arenāt like you.
She had one more great quote: āMake something meaningful in public, and the right people will join in.ā
Thatās it!
Day one was good stuff, but now Iām off to some parties! Like I said before, if youāre here, say hi, and Iāll have another wrap-up for you tomorrow!
