Simon St. Laurent
Simon St. Laurent is a web developer, network administrator, computer book author, and XML troublemaker living in Ithaca, NY. His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference. You can find his writing on everything from technology to Quakerism to life in Dryden to gardening to New York State politics aggregated at simonstl.com.
Go node without code
Command line tools improve development workflow
At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Adobe Community Manager Brian Rinaldi showed off ways Node makes possible a new world of utilities, showing JavaScript developers a toolkit they will want to integrate into their workflows.
In his talk, Go Node Without Code, Brian talked about the many ways Node and the npm ecosystem of JavaScript packages can help front-end developers, even if they don’t want to leap to server-side programming.
Tools Brian explored include:
- UglifyJS, the “JavaScript parser / mangler / compressor / beautifier toolkit” [at 02:00]
- Less, “for building CSS, but offers a lot of features you don’t get in straight CSS” [at 06:15]
- Grunt, addressing the “just adding steps to my workflow” problem. [at 9:09]
- GruntIcon, “A mystical CSS icon solution” [at 18:18]
- Automaton, a “task automation tool” [at 25:00]
- HTTPster, a dead-simple “local static development server” [at 30:05]
- The slightly more configurable Node-static [at 32:00]
You will need to be familiar with the command line for a lot of it – if you’re not, it’s a great time to learn!
If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.
What should programming look like?
Can it really be simplified?
Even as we all scramble to use the programming tools we have today, developers look ahead hopefully, dreaming of better tools. What shape should those tools take? Who should they be for?
A few months ago, I had the privilege of talking about programming’s future with three great and very different programmers:
- Chris Granger of Light Table, who combines expansive visions of programming capabilities with an interest in making it approachable.
- Greg Borenstein, author of Making Things See, who explores the intersections of software and hardware.
- Scott Murray, author of Interactive Data Visualization for the Web, Assistant Professor of Design at USF, and a contributor to Processing.
I’d encourage you to listen to the whole conversation, but to get started, you might explore these highlights.
Web application development is different (and better)
On both front and back end, the Web challenges conventional wisdom
The Web became the most ubiquitous distributed application system because it didn’t have to think of itself as a programming environment. Almost every day I see comments or complaints from programmers (even brilliant programmers) muttering about how many strange and inferior parts they have to deal with, how they’d like to fix a historical accident by ripping out HTML completely and replacing it with Canvas, and how separation of concerns is an inconvenience. Everything should be JavaScript.
(Apologies to Tom Dale, who tweeted a perfect series of counterpoints just as I was writing. He has visions of rebuilding the rendering stack in JavaScript, but those tweets are not unusual opinions.)
The Web is different, and I can see why programmers might have little tolerance for the paths it chose, but this time the programmers are wrong. It’s not that the Web is perfect – it certainly has glitches. It’s not that success means something is better. Many terrible things have found broad audiences, and there are infinite levels to the Worse is Better conversations. And of course, the Web doesn’t solve every programming need. Many problems just don’t fit, and that’s fine.
So why is the Web better?
Please nominate for the web platform awards
Recognizing the people who've built the Web
This March, we’ll be announcing the Web Platform Awards at the O’Reilly Fluent Conference. Fluent is all about JavaScript, HTML5, CSS3, and the best practices that make up the Web Platform, and we’d like to recognize the people who’ve made it the powerful ecosystem it is today.
The description is pretty simple, but I think includes a huge number of potentially great awardees:
The awards recognize individual contributors who have demonstrated exceptional leadership, creativity, and collaboration in the development of JavaScript, HTML, CSS, and the supporting Web ecosystem.
We hope to hear about many ways people have “demonstrated exceptional leadership”. It may be standards, it may be coding, it may be explaining, it may be community, or it may well be something I haven’t thought of yet. What matters is that you can tell us why you think they should get an award.
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.
Is Text the Programmer’s Silver Bullet?
The command line and text editors retain their charm
Will programming ever depart the land of text?
I loved this article on the divides between user and programmer cultures, but sharing it brought responses on the values of programmer culture. Every time I wonder publicly about programming interfaces, or worse, suggest that graphical interfaces might play a role, I provoke a small army of people who think text is a key strength of programming. Though they sometimes wander into IDEs, text editors and especially the command line are their critical tools.
Bruce Maxwell, Professor of Computer Science at Colby College, described the power that text provides:
I’ve watched student after student come to the same conclusion that editing the text file is faster and easier and more precise. I’m not imposing my 1980’s C preferences on them; they are discovering this anew for themselves.
It comes down to this: you can create nice, general graphics tools that will let you do a certain set of tasks in a certain design space. But as soon as you have a specific idea or concept or need that falls outside of those tasks or the design space, or you want more detailed control, you fall back to the most general tool of all: a text editor and a programming language.
He’s right.
I was amazed, the first few times I attended OSCON, that the deeply-felt arguments at lunch weren’t about programming languages or principles, but about editors (Vim vs. Emacs) and about shells. The divisions among different ways to reach your text crossed language boundaries, and even varied within organizations. (Well, at least those that hadn’t standardized on IDEs.)
Snow and Fire Make Light
Ice lanterns give you a reason to look forward to the cold
A few years ago, muttering about how incapable I was of creating anything beautiful, I decided to try something that seemed simple but different. I’d seen candles lighting up the winter night in containers of ice, and remembered how the candles’ movement combined with the variations in the ice to make something ever-changing and unique.
I ordered some star-shaped ice lantern molds, and set about doing something fun with the Upstate New York winter. They were a little smaller than I expected, but even my initial experiments turned out well. With a votive candle inside, they were easily visible from both my house and the road, flickering and different from the LED lights on the house.
Declare and It Happens
CSS already making Web code more approachable
Last week, I wrote about the need to make programming, at least much programming, more accessible. I was thinking in terms of business processes, so spreadsheets and flow-based programming sprang to mind. Today, though, Jeremy Keith reminds me that on the Web, we already have much of that world in Cascading Style Sheets (CSS).
“Being a programming language” was never a goal for CSS, which pushed the opposite direction in contrast to Netscape’s JavaScript Style Sheets. There are moments, of course, when developers wish otherwise, and the SASS and LESS preprocessors can give them more functionality. As Keith points out, however:
There are a lot of really powerful programmatic concepts that we could add to CSS, all of which would certainly make it a more powerful language. But I think that power would come at an expense.
Right now, CSS is a relatively-straightforward language.
I suspect some readers are scratching their heads, wondering why CSS is even being considered a language, much less why adding programming features to it would be a bad thing. If you think of CSS as a simple object-manipulation language, though, it fits pretty neatly into the sweet spot I described last week.
Bringing Programming Out of Its Temples
If everyone should learn to code, code needs to change
2013 may have seen a tipping point for the popularity of programming. Even people who aren’t programmers are suddenly arguing that it’s a good idea for everyone to learn programming. Computers are now everywhere, traveling with us, common in places where they would once have seemed an extravagance, and it seems obvious that we need to be able to do more with them.
Anil Dash looked beyond the basic vision of teaching everyone to code this week. Dash leads with President Obama’s encouragement of computer science as part of this week’s Hour of Code project, and his suggestions to young Americans:
“Don’t just play the latest video game. Make one.
Don’t just download the latest app. Help design it.
Don’t just play on your phone. Program it.
(It’s not just the President—it’s House Majority Leader Eric Cantor too.)
It is, of course, harder than that. I love Dash’s piece, which reflects on the value of code, the challenges of crossing tech culture boundaries, and the need for tech culture itself to support and make more valuable such efforts at democratizing coding. I shared it on Facebook, happily citing the part about:
Can Data Flow Help Us Escape the von Neumann Machine?
Untangling code with flow-based programming
About a year ago I was struck by George Dyson‘s plea in his Strata London keynote
That’s why we live in this world where we follow this one particular [von Neumann] architecture and all the alternatives were squashed… Turing gave us this very powerful one-dimensional model, von Neumann made it into this two-dimensional address matrix, and why are we still stuck in that world? We’re fully capable of moving on to the next generation… that becomes fully three-dimensional. Why stay in this von Neumann matrix?
Dyson suggested a more biologically based template-based approach, but I wasn’t sure at the time that we were as far from three dimensions as Dyson thought. Distributed computing with separate memory spaces already can offer an additional dimension, though most of us are not normally great at using it. (I suspect Dyson would disagree with my interpretation.)
Companies that specialize in scaling horizontally—Google, Facebook, and many others—already seem to have multiple dimensions running more or less smoothly. While we tend to think of that work as only applying to specialized cases involving many thousands of simultaneous users, that extra dimension can help make computing more efficient at practically any scale above a single processor core.
Unfortunately, we’ve trained ourselves very well to the von Neumann model—a flow of instructions through a processor working on a shared address space. There are many variations in pipelines, protections for memory, and so on, but we’ve centered our programming models on creating processes that communicate with each other. The program is the center of our computing universe because it must handle all of these manipulations directly.