Simon St. Laurent
Not ugly, not complicated
(If you’d like to know more about hypermedia in general, this interview provides more background.)
In his talk, Implementing Hypermedia Clients: It’s Not Rocket Science, Mike explored how hypermedia approaches drive conversation between clients and servers, and the application structures that result from those structures.
- 1:44 – “The Semantic Gap: Hypermedia tells us what we can do, but it doesn’t say why.”
- 6:04 – Hypermedia and application control information – links!
- 8:09 – Control factors – “I accept RSS, can you give me RSS?”
- 10:41 – Foundations of the class scheduling domain example
- 16:30 – “What is a hypermedia client that a human would use?”
- 19:24 – “Faithful Hypermedia Clients (FHCs) pass along whatever the server returns, and lets a human sort it out.”
- 31:20 – “So what’s a Hypermedia for machine client?… Makes choices, not waiting for a human”
- 33:25 – Working with Maze+XML
- 37:10 – The power of generic types
Disposable robot assassins and spreadsheets
Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.
Bowkett explored many options and iterations of his automation ideas,
- The roots: Martin Fowler’s classic Refactoring. [at 00:50]
- “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
- Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
- “More complex information… surfacing an implicit object model.” [at 7:45]
- Filter scripts and text streams [at 14:45]
- “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
- Building on JSLint [at 20:10]
- “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
- Grepping through git history [at 32:53]
- “Automatic refactoring will let you get to better code much faster.” [at 36:25]
It’s an amazing mix of capabilities that let you build your own robot (code) assassins.
Sometimes you need to be your customer
Sometimes you just need to leap into sharing your learning, even when you haven’t yet learned much. “Beginner’s mind” usually becomes more abstract as a person advances, making it difficult for beginners to learn from experts. If you can dare to write while you’re learning, you may find unique opportunities to create content that appeals first and foremost to learners.
Despite that, the “learn from the master” story remains powerful: of course, only those who know best should be trusted to teach! Sometimes that comes with the old guild-flavored model: masters should select worthy apprentices and mentor them for a long while.
The apprenticeship model has its benefits, but I’ve spent most of my career promoting what I generally call the DIY model. Even in the thriving field of programming, we don’t have enough masters willing to spend their time with apprentices. Masters seem better at talking with masters than with newcomers, and even the journeywomen and journeymen sometimes forget the difficulties of the paths they’ve followed to get there. The DIY model drops that lost formality and replaces it with books, videos, and occasional classes, combined with a lot of self-study.
Getting the DIY story right is incredibly difficult. Unless you’re lucky enough to be teaching in person, which has its own challenges, you have to anticipate what a reader or viewer will need. The feedback loop runs mostly through reviews, both during and after the creation of the piece. Getting ahead of that feedback loop means doing something scary: write about what you don’t know.
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.
On both front and back end, the Web challenges conventional wisdom
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?
Recognizing the people who've built the Web
The description is pretty simple, but I think includes a huge number of potentially great awardees:
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.
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.
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.
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.)
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.