- axe — accessibility testing of web apps, so you can integrate accessibility testing into your continuous EVERYTHING pipeline.
- US Tech Funding: What’s Going On? (A16Z) — deck eloquently arguing that this is no bubble.
- Teach Don’t Tell — what I think good documentation is and how I think you should go about writing it. Sample common sense: This is obvious when you’re working face-to-face with someone. When you tell them how to play a C major chord on the guitar and they only produce a strangled squeak, it’s clear that you need to slow down and talk about how to press down on the strings properly. As programmers, we almost never get this kind of feedback about our documentation. We don’t see that the person on the other end of the wire is hopelessly confused and blundering around because they’re missing something we thought was obvious (but wasn’t). Teaching someone in person helps you learn to anticipate this, which will pay off (for your users) when you’re writing documentation.
Not just for code anymore
Do you really want a technical book for your project? Does your community need to provide more helpful docs to support even more users? Does your community have a lot of knowledge they need to get out of heads and into bits and bytes? Do you have a good mix of technical experts and technical writers and users who would enjoy each other’s company for a week of hard work?
If the answer is yes, then consider a book sprint. If you’re in the open source world, you may have heard of a code sprint. A book sprint is a similar event, with an intense collaborative authoring session time boxed by a few days or a week. People get together typically in person to author and complete a book in a week.
Generally speaking it’s best if you have an idea of the scope and audience for the book prior to holding the sprint. These discussions can take place on line, such as on a mailing list or in a wiki page or Etherpad. You can also meet with future collaborators regularly, but understand, the first day of your sprint your book will certainly take shape. As book sprinter Adam Hyde says, “While you may not know the exact book you want when you go into the sprint, by the end you will have the book you need.”
For the OpenStack Operations Guide, we held a five-day book sprint in February 2013. OpenStack releases every April and October, and this timing was nearly halfway between two release dates. With Adam as our facilitator, seven authors agreed to work together and we nervously awaited our fate. We asked, “Could we complete a book in a week?”
Can Elixir bring functional programming to a much wider audience?
I was delighted to talk with Dave Thomas, co-founder of the The Pragmatic Programmers and author of their in-progress Programming Elixir. I’m writing Introducing Elixir for O’Reilly, and we both seem to be enjoying the progress of the language. Read more…
Simon St. Laurent and Jose Valim explore a new functional programming language
I was delighted to sit down with Jose Valim, the creator of Elixir, earlier this month at Erlang Factory. He and Dave Thomas had just given a brave keynote exploring the barriers that keep people from taking advantage of Erlang’s many superpowers, challenging the audience with reminders that a programming environment must have reach as well as power to change the world.
Elixir itself is a bold effort to bring Erlang’s strengths to a broader group of developers, adding new strengths, notably metaprogramming, along the way.
Whether you’re interested in Elixir itself or just in the challenges of creating a new combination in a world filled with past experiments, it’s well worth listening to Jose Valim.
- We’ve had functional programming since 1959 – why the burst of interest now? [2:10]
- Moving from Ruby to Erlang “making Rails thread-safe, that was my personal pain-point” [3:13]
- “Every time I got to study more about the VM, the tooling and everything it provides, my mind gets blown.” [6:12]
- Why Elixir started, and how it’s changed as Jose learned more. [10:08]
- Integrating new Erlang features (R17 maps) into Elixir. [15:43]
- When can you use Elixir in production? [18:07]
I’m looking forward to seeing a lot more Elixir, even as I need to catch up on updating Introducing Elixir. I’m not sure it will conquer the world immediately, but it will certainly leave its mark.
Is commenting your code a waste of time, or programmer gold?
Ask any developer what programming task they enjoy least, and odds are you’ll hear “documentation” as an answer. After all, you came here to write code, didn’t you? Who wants to write boring text about the code? In fact, documentation is the grease that keeps the development process moving — good documentation benefits your co-workers, the users, and maybe even you. And the most basic form of documentation is the comments in your program itself.
Can explanation contribute to technology creation?
“If you’re explaining, you’re losing.”
That gem of political wisdom has always been hard for me to take, as, after all, I make my living at explaining technology. I don’t feel like I’m losing. And yet…
It rings true. It’s not that programs and devices shouldn’t need documentation, but rather that documentation is an opportunity to find out just how complex a tool is. The problem is less that documentation writers are losing when they’re explaining, and more that creators of software and devices are losing when they have to settle for “fix in documentation.”
I was delighted last week to hear from Doug Schepers of webplatform.org that they want to “tighten the feedback loop between specification and documentation to make the specifications better.” Documentation means that someone has read and attempted to explain the specification to a broader audience, and the broader audience can then try things out and add their own comments. Writing documentation with that as an explicit goal is a much happier approach than the usual perils of documentation writers, trapped explaining unfixable tools whose creators apparently never gave much thought to explaining them.
It’s not just WebPlatform.org. I’ve praised the Elixir community for similar willingness to listen when people writing documentation (internal or external) report difficulties. When something is hard to explain, there’s usually some elegance missing. Developers writing their own documentation sometimes find it, but it can be easier to see the seams when you aren’t the one creating them.
The past, present, and future of Dell's project
Barton George (@barton808) is the Director of Development Programs at Dell, and the lead on Project Sputnik—Dell’s Ubuntu-based developer laptop (and its accompanying software). He sat down with me at OSCON to talk about what’s happened in the past year since OSCON 2012, and why he thinks Sputnik has a real chance at attracting developers.
Key highlights include:
- The developers that make up Sputnik’s ideal audience [Discussed at 1:00]
- The top three reasons you should try Sputnik [Discussed at 2:46]
- What Barton hopes to be talking about in 2014 [Discussed at 4:36]
- The key to building a community is documentation [Discussed at 5:20]
You can view the full interview here:
Cody Lindley on finding your way through a popular and powerful language
- Don’t be down on jQuery users (at 2:03)
- Are buffers between your code and browser APIs necessary? (at 9:17)
- Running browser tests on the DOM (at 11:08)
- Needing more focused in-depth documentation (at 12:57)
His closing – “we need to do a better job communicating with the bulk of developers out there” – sounded just right to me.
You can view the entire conversation in the following video:
Part of a series about efforts by VoIP Drupal collaborators to find the right media and tools with which to promote a small, little known software project.
VoIP Drupal is a window onto the promises and challenges faced by a new open source project, including its documentation. A meeting at at MIT this week worked out some long-term plans for firming up VoIP Drupal's documentation and other training materials.