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.

Cross-pollinating Web communities

The integration of the Web's diverse communities broadens horizons and technology.

Waterdrops inside The Animal Flower Cave, Barbados. By  Berit Watkin on Flickr.

Web projects are integration projects, combining skills from a number of disciplines. Lousy interfaces can obscure brilliant code, and ingeniously engineered back-end systems can still fail when they hit resource limits. “Content” lurks in many guises, requiring support not only from writers and illustrators but from video specialists, game designers, and many more. Marketers have built businesses on the Web, and influence conversations from design to analytics. You don’t have to be a programmer to do great work on the Web. The Web stack is vast.

Web development models include far more than code. Creating great websites and applications demands collaboration among content creators, designers, and programmers. As applications grow larger, supporting them requires adding a cast of people who can help them scale to demand. As projects grow, specialization typically lets people focus on specific aspects of those larger disciplines, supporting networking, databases, template systems, graphics details, and much more.

In some ways, that’s a recipe for fragmentation, and some days the edges are sharp. All of these communities have different priorities, which conflict regularly. Battles over resources sharpen the axes, and memories often linger.

At the same time, though, often even in environments where resources are scarce, different perspectives can reinforce each other or create new possibilities. Sometimes, it’s just because the intersection spaces have been left fallow for a long time, but other times, the combinations themselves create new opportunities. Read more…

Comment

Worship maintainers

The future is maintenance: build for the inevitable.

switch

Technology has had a cult of newness for centuries. We hail innovators, cheer change, and fend off critics who might think new and change are coming too fast. Unfortunately, while that drives the cycle of creation, it also creates biases that damage what we create, reducing the benefits and increasing the costs.

Formerly new things rapidly become ordinary “plumbing,” while maintenance becomes a cost center, something to complain about. “Green fields” and startups look ever more attractive because they offer opportunities to start fresh, with minimal connections to past technology decisions.

The problem, though, is that most of these new things — the ones that succeed enough to stay around — have a long maintenance cycle ahead of them. As Axel Rauschmayer put it:

“People who maintain stuff are the unsung heroes of software development.”

In a different context, Steve Hendricks of Historic Doors pointed out that:

“Low maintenance is the holy grail of our culture. We’ve gone so far that we’re willing to throw things away rather than fix them.”

That gets especially expensive. Heaping praise on the creators of new things while trying to minimize the costs of the maintainers is a recipe for disaster over the long term.
Read more…

Comment: 1

Full-stack tensions on the Web

How much do you need to know?

Vista_de_la_Biblioteca_VasconcelosI expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.

In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.

Formal separation of concerns among HTML, CSS, and JavaScript made it easier to share responsibilities among specialists. As the dot-com boom proceeded, specialization accelerated, with dedicated designers, programmers, and sysadmins coming to the work. Perhaps there were too many titles.

Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
Read more…

Comments: 5

When can you learn JavaScript?

Khan Academy explores how far learners can get at different ages.

I picked up a brief guide to programming in 6th grade. There, on page 1, was A = A + 1. I knew that wasn’t possible, so I put it down, and came back to programming in 7th grade.

Khan Academy is having better luck with young students, but learning to program is kind of like learning to drive: the prerequisites aren’t obvious, but they’re helpful and often come later. At Fluent 2014, Pamela Fox explored the data Khan Academy has collected on learner age, and what it might mean for curricula going forward.

In her keynote, Fox explored:

  • What the world might look like if JavaScript were part of the curriculum as early as possible. (1:42)
  • Developing a sense of how kids respond to fairly easy challenges with Khan Academy’s participant data. (3:24)
  • What in the first programming challenge might keep people from succeeding? (4:37)
  • How different is the data for a logic challenge? At what age does completion level off? (6:16)
  • What might JavaScript skills enable in a high school curriculum? (8:24)

Read more…

Comment: 1

Keep me safe

Security is at the heart of the web.

Locks image: CC BY 2.0 Mike Baird https://www.flickr.com/photos/mikebaird/2354116406/  via Flickr

We want to share. We want to buy. We want help. We want to talk.

At the end of the day, though, we want to be able to go to sleep without worrying that all of those great conversations on the open web will endanger the rest of what we do.

Making the web work has always been a balancing act between enabling and forbidding, remembering and forgetting, and public and private. Managing identity, security, and privacy has always been complicated, both because of the challenges in each of those pieces and the tensions among them.

Complicating things further, the web has succeeded in large part because people — myself included — have been willing to lock their paranoias away so long as nothing too terrible happened.

I talked for years about expecting that the NSA was reading all my correspondence, but finding out that yes, indeed they were filtering pretty much everything, opened the door to a whole new set of conversations and concerns about what happens to my information. I made my home address readily available in an IETF RFC document years ago​. In an age of doxxing and SWATting, I wonder whether I was smart to do that. As the costs move from my imagination to reality, it’s harder to keep the door to my paranoia closed. Read more…

Comment

Power of the platforms

Uncertainty is a feature, not a bug.

Image: CC BY 2.0 NASA's Earth Observatory via Wikimedia Commons  http://commons.wikimedia.org/wiki/File:Southern_Lights.jpg#mediaviewer/File:Southern_Lights.jpg

After decades of work on programming, we finally got a development environment with massive reach and tremendous power. Somehow, though, the web isn’t centered on a comprehensive programming environment. The web succeeded with a (severely) lowest-common denominator, specification-driven approach that let it grow with time, technology, and multiple communities, across multiple platforms.

Almost two decades ago, I was all excited about Java. Write applets once, run anywhere, with libraries to make sure it all came out the same wherever anywhere might be. Java is still a powerhouse, but it all worked out differently than I expected. Even in Java’s early years, before the Java news was filled with security bulletins, applets felt like a strange mix with their surrounding web pages. Creating an applet demanded programmers to build every detail. Even with Java’s ever-improving libraries, creating a Java applet that did much was an intense experience focused on programming.

Java wasn’t the only comprehensive way to build web apps, of course. Flash demanded programming, but its values always incorporated design, action, and well, flash, in ways that meshed well with the way people built sites. Flash kept growing and growing before its ecosystem took a fatal hit from the iPhone as HTML5 offered replacements for some of its key strengths. I mostly notice Flash these days because it asks me to update it regularly and because pages tell me when it’s crashed.

Compared to either of those rich environments, web technology is a tangled mess. The early web was functional but unstyled, with no behavior beyond navigating among pages. That? That would dominate client-side computing? Read more…

Comment: 1

Web by default

You're using the Web even when you don't think you are.

Web by default

With the rise of native apps and the Internet of Things (IoT), you might think we’re leaving the Web behind.

We’re not. The Web continues to be the easiest way for developers to connect people and computers. Whether you think you’re “on the Web” or not, Web tools power a huge chunk of communications and a vast number of interfaces. While HTML, CSS, and JavaScript are common, even in installable apps, even native apps and back-end systems use JSON, HTTP, and Web services to communicate. IoT devices may not always use those protocols directly, but many of them have a Web interface lurking somewhere.

Other languages and approaches absolutely have their place, especially in the many environments where constraints matter more than connection, but the Web core is everywhere: in your phone, your apps, the kiosks you find in stores and museums. It lurks invisibly on corporate networks helping databases and messaging systems communicate.

That enormous set of Web-related possibilities includes more than a set of technologies, though. Tools and techniques are great, but applying them yields a richer set of sometimes happy and sometimes controversial conversations.

I’ll be exploring a core set of nine key themes over the next few months, but I’ve started with brief explanations below. These short tellings set the stage for deeper explorations of the Web’s potential for changing both computing and the broader world, as well as what you need to learn to join the fun.

Those pieces digging deeper will appear on this site, but you can also stay in the loop on our latest analysis and coverage through our weekly Web Platform newsletter.

Read more…

Comment

Programming in concert mode

Andrew Sorensen's cyberphysical music-making demonstrated programming real-time systems in real time.

Music and programming share deep mathematical roots, but have very different senses of “performance”. At OSCON, Andrew Sorensen reunited those two branches to give a live “concert” performance as a keynote. Sorensen brought his decade of “live coding musical concerts in front of an audience” to a real-time demonstration of Extempore, “a systems programming language designed to support the programming of real-time systems in real time”:

“Extempore is designed to support a style of programming dubbed ‘cyberphysical’ programming. Cyberphysical programming supports the notion of a human programmer operating as an active agent in a real-time distributed network of environmentally aware systems.”

Read more…

Comments: 2

Your money or your life

Microsoft, Google and pushing business models too far.

Photo by Didier, used under a Creative Commons license.I know it’s hard to run a large company. I know that organizations can get too deep into their own visions to imagine conflicting values.

I realized yesterday, though, that:

  • Microsoft ruined their brand for me by holding too tightly to things that they considered theirs. (Software.)
  • Google is ruining their brand for me by holding too tightly to things that I consider mine. (Identity, everything they can possibly learn about me.)

It’s a weird difference, but the Google version makes me much sadder about the world. As I’d tell a mugger, “You can have my wallet, just don’t take me.”

Photo by Didier, used under a Creative Commons license.

Comment

It’s the end of the web as we knew it

You might feel fine.

For the past 15 years, Google has enforced the classic “HTML as foundation” architecture at the heart of the Web. Content creators and the developers who support them had to present content and link information as part of their pages’ HTML if they wanted Google’s spidering bots to see them. Google effectively punished developers who made links or content available only through JavaScript (or images, or CSS), giving them low or non-existent search results.

Google did this to keep their processing simple, not because of a deep fondness for HTML. Even as Google’s bots stuck to a simple diet of HTML, other parts of Google were developing JavaScript-centric approaches, like AngularJS: a “Superheroic JavaScript MVW Framework” that “is what HTML would have been, had it been designed for building web-apps.”

Angular is far from alone. As JavaScript grew, more and more programmers wanted to build their apps as programs, not as pages. Or, as Jen Simmons summarized it at Fluent, “Dang that stupid HTML, I’m just going to load an empty page… then I’ll run the real program, I’ll run the JavaScript.” Read more…

Comment