- Making Ajax Applications Crawlable (Google) — Google’s system for allowing Ajax applications to provide HTML snapshots for search engines. (via alexdong on twitter)
- Security Lessons Learned from the Diaspora Launch — great explanation of the programming mistakes that were in the Diaspora code, and the security risks that resulted. Again, I recommend the OWASP site if you aren’t aware of the types of security mistakes you are making.
- A Brief Tour of Graphd — the triplestore behind Freebase. Want. (via timclicks on Twitter)
- Toybots — startup working on Internet-aware hardware for toymakers: 3G, WiFi, GPS, and accelerometer waiting to be embedded in toys.
"ajax" entries
Transforming the web (through transformation)
Decorating content may no longer be enough
Thousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.
Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.
“Templating” doesn’t quite capture what’s happening here. While templates are often a key tool, describing that tool doesn’t explain the shift from server to client. Templating also misses the many cases where developers are using plain JavaScript to insert, delete, and modify the document tree in response to incoming data.
These practices have been emerging for a long time, in many different guises:
- In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
- Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
- Ajax opened the door to shell pages, apps that set up a UI, but get most of their content elsewhere, using JavaScript to put it in place.
- New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
- Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
- The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
- Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.
A concrete approach to learning how to program
A solid foundation on which more meaningful learning can happen
As someone who has previously taught computer programming for nearly a decade, I’m often asked questions that involve “what’s the best way to go about learning to program computers,” or “what’s the best way to get a software engineering job,” or “how can I learn to build mobile or web apps?”
Most of the readers of this blog have probably faced the same question at some point in their career. How did you answer it? I’ve seen many different responses: “come up with an idea for an app and build it,” or “get a computer science degree,” or “go read The Little Schemer,” or “join an open-source project that excites you,” or “learn Ruby on Rails.”
The interesting thing about these responses is that, for the most part, they can be classified into one of two categories: top-down approaches or bottom-up approaches. Top-down approaches are informed by the opinion that it’s better to be thrown in the middle of an application or a framework which encourages the learner to piece together knowledge in that context. Many books and online tutorials use an explicit top-down approach, often starting with the basics of a popular methodology, framework or technology. The most visible example of this are books on Ruby on Rails — they almost always inevitably begin with a description of the Model-View-Controller design pattern, but defer the incredible number of non-obvious ideas that make it up (Object-Oriented Programming, for instance).
On the other hand, a bottom-up approach starts with the basics/fundamentals of programming and then slowly builds your knowledge over time. In contrast to top-down approaches, bottom-up approaches try to minimize the number of these non-obvious ideas that the learner has to take for granted. Khan Academy and Code Academy are two examples of online sites that use a bottom-up approach to teaching programming. For the most part, they completely leave out any specific framework and focus on fundamentals of programming.
Squeaky Clean Ajax and Comet with Lift
Focus on application development, not the plumbing
Lift is a web framework for Scala, and is probably best known for having great Comet and Ajax support.
I’ve been touring the features of Lift that I find appealing. Initially I looked at designer-friendly templates and REST services. Recently, I highlighted the great features for organising and controlling access to content.
Let’s now take a look at the Ajax and Comet features of Lift.
Ajax
When I think of Ajax, I think of interacting with a web server, but avoiding page reloads.
An example: suppose we had a site that allowed you to write poems, and a feature on that site might be a button you could click to get an associated word from a thesaurus. The thesaurus we have is large, we don’t want it loaded in the browser, so we need to call the server to use it.
The HTML template would be a field and a button:
<div data-lift="Associate">
<input id="word" type="text" placeholder="Type a word">
<input type="submit" name="submit">
</div>
So far, that’s probably similar across many web frameworks. What you might now expect is for us to define a REST endpoint, do some jQuery wiring to connect the service to the button.
In Lift, we can do that, but often the Ajax goodness comes via this kind of Scala code:
class Associate {
def render =
"@submit [onclick]" #> ajaxCall(
ValById("word"),
w => SetValById("word", Thesaurus.association(w))
)
}
This Associate snippet is binding the submit button’s click event to a Lift Ajax call. That is, the left side of the replace function (#>) is a CSS selector targeting the “onclick”, and the right side is arranging for the Ajax call to hit the server.
The first parameter to ajaxCall is the value passed from the browser to the server. We’ve asked for the value of the input field with an ID of “word”. The second parameter is the function to run when the button is pressed. Here we’re taking the word we’ve been sent, and updating the field with whatever our Thesaurus.association function gives us back.
Read more…
Smuggling Web Practices into the Enterprise
How fast can the enterprise change?
At last year’s Fluent Conference, I kept having the same conversation with attendees from large companies. They had come to the show with a mandate from their bosses to figure out how to bring that fast-moving web work into their slow-moving enterprise systems.
I enjoyed some of that same conversation this year, but also a different note: even with management support, making that transition was difficult. Some parts meshed, others were difficult: changes in one place could reverberate through many others. The whole concept of “rapid prototyping” fit badly with a variety of technologies and approaches meant to minimize unpleasant surprises. Even eight years after the advent of Ajax, a variety of server-centric techniques limit the flexibility of front-end developers.
Someone at lunch said that “the technology helps, but the culture matters.” A few others talked about how everyone wanted better front-end work, but thought it could be grafted easily on existing back-end practice. The shiny parts are easy to talk about, but the plumbing is harder.
I was happy to see Bill Scott (@billwscott) of PayPal take on these challenges in his keynote. Bill wasn’t smuggling anything—that would be difficult under the title “Clash of the Titans: Releasing the Kraken.” He was brought to PayPal to change the company, to bring the lean “build – measure – learn” approach. In a risk-averse world, with “a 20-day class on how to use their version of Spring,” Scott had to change the “culture of a long shelf life” (something publishing folks are starting to do as well).
It’s a hard-hitting talk, calling for major change, skunkworks projects, and shifts in both company culture and technology.
What Kind of JavaScript Developer Are You?
Fault lines make conversation difficult
“JavaScript developer” is a description that hides tremendous diversity. While every language has a range of user skill levels, JavaScript has a remarkably fragmented community. People come to JavaScript for different reasons from different places, and this can make communication difficult. Sometimes it’s worse than that—not everyone likes everyone else.
“JavaScript developer” used to mean “web developer,” specifically a developer who spends a lot of time working in the browser. Even as JavaScript became a specialty of its own, most JavaScript developers came through a broader web practice first, learning HTML and CSS before tackling the DOM. This was my path, and is still a common one. It was reasonably easy to absorb JavaScript by example, using it as an object manipulation language before pushing into the harder corners.
Many programmers, however, started on the server-side, building code that filled templates. Server-side JavaScript existed, in the Netscape Enterprise Server, for example, but was a tiny fraction in a world dominated by Perl, Java, Python, Ruby, and ASP’s languages. Developers who spent most of their time writing code that ran on the server worked with a different set of tools and expectations, and had to shift gears as JavaScript became a more critical part of web applications. (Some of these developers generate a lot of JavaScript—JSON is, after all, JavaScript—but would prefer to think of JavaScript’s role in that as an accident.)
Another group of developers came from desktop applications, and expected more direct control over the interface. Many of these developers now understand JavaScript because the browser forces them, not because they want to.
Involuntary JavaScript creates a tremendous amount of tension around the language. Normally, the people who dislike a programming language can just work with something else. JavaScript’s browser dominance makes that hard.
Other developers, though, are much much happier and much deeper into JavaScript. The JavaScript revival that became visible with the rise of Ajax in 2005 gave the language greater credibility. Douglas Crockford’s work “Unearthing the Excellence in JavaScript,” JavaScript: The Good Parts demonstrated a powerful language lurking in a toolset many had considered trivial.
Over the past decade, JavaScript’s power and reach have grown thanks largely to a core group of developers whose focus on the language has created best practices and frameworks, while driving browser vendors to improve their implementations. Node.js emerged from this work, giving JavaScript a unique server-side framework that deeply reflects the language.
New directions in web architecture. Again.
A focus on data is finishing the revolution that started with Ajax.
Modern applications require data. That means developers must see themselves as data providers, and they must create stable public APIs for accessing that data.
Four short links: 24 September 2010
Crawlable Ajax, Security Lessons, Graph Database, and Toy Hardware
Four short links: 16 June 2010
Consulting, Idea-Gathering, Understanding Git, and Javascript Libraries
- So You Want to Be A Consultant — absolutely spot-on tips for understanding the true business of a consultant. (via Hacker News)
- BBYIDX — a free and open source idea-gathering application written in Ruby, […] the basis of the Best Buy IdeaX website.
- The Git Parable — The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git. The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. (via Pete Warden)
- Ext JS + jQTouch + Raphael = Sencha — merging some touch and rich graphics libraries and developers. We’re setting up a foundation called Sencha Labs that will hold the copyright and trademarks for all the non-commercial projects affiliated with Sencha. Our license of choice for these projects is, and will continue to be, the MIT license. We will fund maintainers for our non-commercial projects with contributions from Sencha and the communities of these projects. (via bjepson on Twitter)
The Best and the Worst Tech of the Decade
It was the best of decades, it was the worst of decades...
With only a few weeks left until we close out the ‘naughts and move into the teens, it’s almost obligatory to take a look back at the best and not-so-best of the last decade. With that in mind, I polled the O’Reilly editors, authors, Friends, and a number of industry movers and shakers to gather nominations. I then tossed them in the trash and made up my own compiled them together and looked for trends and common threads. So here then, in no particular order, are the best and the worst that the decade had to offer.
GWT Now With SpeedTracer
Google is releasing v2 of GWT (pronounced “Gwit”) tonight at a Campfire One in Mountain View. The open-source Google Web Toolkit enables developers to code Ajax web apps in Java. This latest release is focused on speed (just like the latest iPhone) and improved dev-designer collaboration. I was on a call with Bruce Johnson and Andy Bowers to learn more about the release. There are three new major features being released tonight. Of the three SpeedTracer seems to have the greatest implications.