Four short links: 25 July 2014

Four short links: 25 July 2014

Public Private Pain, Signature Parsing, OSCON Highlights, and Robocar Culture

  1. What is Public? (Anil Dash) — the most cogent and articulate (and least hyperventilated dramaware) rundown of just what the problem is, that you’re ever likely to find.
  2. talon — mailgun’s open sourced library for parsing email signatures.
  3. Signals from OSCON — some highlights. Watching Andrew Sorensen livecode synth playing (YouTube clip) is pretty wild.
  4. Two Cultures of Robocars (Brad Templeton) — The conservative view sees this technology as a set of wheels that has a computer. The aggressive school sees this as a computer that has a set of wheels.

Tell us your full-stack story

Your views on full-stack development could be featured at OSCON. Here’s how.

We’re putting together a series of short videos that explores the trend of full-stack development from the point of view of people who consider themselves to be full-stack developers—as well as those who’d like to be.

We’ll use select submissions for the video pre-rolls that run before keynotes at OSCON. Videos may also be featured on O’Reilly Radar.

This means your insightful perspective on full-stack development could be seen by new developers and industry experts alike.

Want to participate? Here’s what you need to do:

Submissions are due by the end of the day on Monday, July 14. Read more…

Comments: 2

Full-stack developers

Developers who understand the whole stack are going to build better applications.

Large tree with branches. Photo by Alex, used under a Creative Commons license

Some see the full-stack developer as a unicorn, but it’s starting to look more like a tree, with tooling, cloud services, design, data, and networking added.

Since Facebook’s Carlos Bueno wrote the canonical article about the full stack, there has been no shortage of posts trying to define it. For a time, Facebook allegedly only hired “full-stack developers.” That probably wasn’t quite true, even if they thought it was. And some posts really push “full-stack” developer into Unicorn territory: Laurence Gellert writes that it “goes beyond being a senior engineer,” and details everything he thinks a full-stack developer should be familiar with, most of which doesn’t involve coding. Read more…

Comment: 1

Prefer goals over controls

A common vision is more important than seeking approval

Bruce Eckel is well known for his books in the field of programming, such as Thinking in Java, Thinking in C++, and Atomic Scala as well as his co-leadership of the Java Posse. And yet, on top of his work in programming, he has spent the last several years investing in and researching a topic that seems quite different, yet is intertwined with the destiny of software companies: the culture and operation of businesses.

In his OSCON 2013 Mainstage session, Bruce lays the foundation of modern business management, including a look back as far as Taylorism, a survey of what it means to get an MBA, and ways to gain this knowledge outside of the traditional institutions.

Read more…


Proposing a Compelling OSCON Talk

Intriguing reviewers and attendees

The OSCON call for proposals closes on January 30th. I’ve seen some great explanations of how to write a conference proposal generally, and my co-chair Matthew McCullough has an excellent presentation on how to write proposals and presentations:

Tailoring talks to specific conferences sometimes takes a bit more. For OSCON, we’d like talks centered on the Open Source computing ecosystem, but the call just lays out the broad story. What helps a proposal that’s in that neighborhood become a session? If you have an idea, how do you develop it?

Audience: Who are they? What do they want?

My first suggestion to anyone proposing a talk (or a book, or even a blog post) is to focus on audience. Who is going to be interested in what you want to discuss? Will they be at that event? What should they know before they get there? How can you convince them that it’s worth their time to join your conversation? Even for lectures and books, thinking of it as a conversation helps to focus planning.

Read more…


Tim O’Reilly Urges Developers and Entrepreneurs to Make Moonshots

OSCON Mainstage Talks: Create more value than you capture

At OSCON 2013, Tim (@timoreilly) asked us to aim higher and work on difficult problems while highlighting the most important trends that should be guiding open source developers and entrepreneurs. To illustrate his points, he offered up great examples from companies as diverse as Google, Square, Wikipedia, and O’Reilly Media.
Read more…


Will Developers Move to Sputnik?

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:

Read more…


In Praise of the Lone Contributor

The O'Reilly Open Source Awards 2013

Over the years, OSCON has become a big conference. With over 3900 registered this year, it was hard not to look at the packed hallways and sessions and think what a huge crowd it is. The number of big-name companies participating–Microsoft, Google, Dell, and even General Motors–reinforce the popular refrain that open source has come a long way; it’s all mainstream now.

Which is as it should be. And it’s been a long haul. But thinking of open source in terms of numbers and size puts us in danger of forgetting the very thing that makes open source special, and that’s the individual contributor. So while open source software has indeed found a place in almost every organization that exists, it was made possible by the hard work of real people who saw the need for it, most of them volunteering in their spare time.

The O’Reilly Open Source Awards were created to recognize and thank these individuals. It’s a community-driven effort: nominations come in from the open source community (this year there were around 50) and then are judged by the previous year’s winners. It’s not intended to be political or a popularity contest, but honest appreciation for hard work that matters. Let’s look at this year’s winners.
Read more…

Comment: 1

Open Source convention considers situational awareness in cars, and more

A report from OSCon

Every conference draws people in order to make contacts, but the Open Source convention also inspires them with content. I had one friend withdraw from an important business meeting (sending an associate) in order to attend a tutorial.

Lots of sessions and tutorials had to turn away attendees. This was largely fall-out from the awkward distribution of seats in the Oregon Convention Center: there are just half a dozen ballroom-sized spaces, forcing the remaining sessions into smaller rooms that are more appropriate for casual meetings of a few dozen people. When the conference organizers measure the popularity of the sessions, I suggest that any session at or near capacity have its attendance counted as infinity.

More than 3,900 people registered for OSCon 2013, and a large contingent kept attending sessions all the way through Friday.

Read more…


Open Source In The Classroom

OSCON 2013 Speaker Series

To teach computer programming to a young person with no experience, you must imagine what it’s like to know nothing about languages, algorithms, data structures, design patterns, object orientation, development tools, etc. Yet the kids I’ve seen in high school over the past several years are so immersed in a world of computing, they have interesting partial understandings of how things work and usually far deeper knowledge of what’s being done with the technologies at a consumer level than their teacher. The contemporary adolescent, a child of the late 1980′s and early 1990′s, has lived a life that parallels the advent of the web with no experience of a world before such powerful new verbs as email, Google, or blog. On the other hand, most have never seen the HTML of a web page or the IP address of a networked computer, and none of them can guess what a compiler does. As a high school computer programming teacher, I am usually the first to help them bridge that enormous and growing gap, and it doesn’t help that the first thing they ask is “How do I write an app for my phone?”

So I need to remember what it was like for me to learn programming for the first time given that, as a child of the early 1970′s, my own life parallels the advent of the home computer. I go backwards in time, way before my modern toolkit mainstays like Java, XML, or Linux (or their amalgam in Android). Programming days came before my Webmaster days, before my analyst days, before I employed scripting languages like Perl, JavaScript, Tcl, or even the Unix shells. I was programming before college, where I used older languages like C, Lisp, or Pascal. When I fondly reminisce about banging out BASIC programs on my beloved Commodore-64 I think surely I’ve arrived at the beginning, but no. When I really do recall the very first time I wrote an original computer program, that was even longer ago: it was 1984. I remember my seventh grade math class, in a Massachusetts public school, being escorted into a lab crammed with no more than a dozen new Apple IIe computers. There we wrote programs in a language called Logo, although everybody just called it “turtle”.

Logo, first created in Cambridge, MA in 1967, was designed from the outset as a programming language for teaching about programming. The open source KDE education project includes an application, KTurtle, for writing programs in Turtlescript, a modern adaptation of Logo. I have found KTurtle to be an extremely effective introduction to computer programming in my own classroom. The complete and well-written Turtlescript language reference can be printed in a small packet of about eight double-sided pages which I can distribute to each pupil. Your first view is a simple IDE, with a code editor that does multi-color highlighting, an inspector for tracing variables and functions, and a canvas for displaying the output of your program. I can demonstrate commands in seconds, gratifying students with immediate results as the onscreen turtle draws lines on the canvas. I can slow the speed of the turtle or step through a program to show what’s going on at each command of a larger program. I can save my final output as an image file, having limited but definite value to a young person. The kids get it, and with about 15 minutes of explanation, a few examples, and a handful of commands they are ready and eager to try themselves.

A modern paradigm of teaching secondary mathematics is giving students a sequence of tasks that give them a progressive understanding of concepts by putting them in situations where they struggle enough to realize the need for new insights. If I ask the students to use KTurtle to draw a square, having only provided them with the basic commands for moving the turtle, they can quickly come up with something like this:

If the next tasks involve a greater number of adjacent squares, this approach becomes tiresome. Now I have the opportunity to introduce looping control structures (along with the programming virtue of laziness) to show them a better way:


As I give them a few more tasks with squares, some students may continue to try to draw the pictures in one giant block of commands, creating complicated Eulerian trails to trace each figure, but are eventually convinced by the obvious benefits and their peers to make the switch. When they graduate to cutting and pasting their square loop repeatedly, I can introduce subroutines:
Read more…

Comments: 3