Member Sign In
Not a member?

A Wired.com user account lets you create, edit and comment on Webmonkey articles. You will also be able to contribute to the Wired How-To Wiki and comment on news stories at Wired.com.


It's fast and free.

Sign in with OpenID
Sign In
Webmonkey is a property of Wired Digital.
processing...
Join Webmonkey

Please send me occasional e-mail updates about new features and special offers from Wired/Webmonkey.
Yes No

Please send occasional e-mail offers from Wired/Webmonkey affiliated web sites and publications, and carefully selected companies.
Yes No

I understand and agree that registration on or use of this site constitutes agreement to Webmonkey's User Agreement and Privacy Policy.
Webmonkey is a property of Wired Digital.
processing...

Retrieve Sign In

Please enter your e-mail address or username below. Your username and password will be sent to the e-mail address you provided us.

or
Webmonkey is a property of Wired Digital.
processing...

Welcome to Webmonkey

A private profile page has been created for you.
As a member of Webmonkey, you can now:
  • edit articles
  • add to the code library
  • design and write a tutorial
  • comment on any Webmonkey article
Close
Webmonkey is a property of Wired Digital.

Sign In Information Sent

An e-mail has been sent to the e-mail address registered in this account.
If you cannot find it in your in-box, please check your bulk or junk folders.
Sign In
Webmonkey is a property of Wired Digital.

Great Documentation Is Key to Open Source Success

Listen up open source developers, if you want your project to succeed you’re going to have to do more than write great code; you’re going to have to document it, teach new users how it works and provide real-world examples of what you can do with it.

That’s the message from Jacob Kaplan-Moss, one of the creators of Django, a very successful open source, Python-based web framework. At least some Django’s success can be attributed to its thorough documentation which is not just reference materials, but also includes tutorials, topical guides and even snippets of design philosophy.

Of course Django is not alone in having great documentation; Ruby on Rails is another highly successful open source project featuring great docs, tutorials and reference materials. Beginning to see a pattern? Great docs == happy, enthusiastic users == open source success.

Too often open source projects seem to turn up their nose at documentation, arguing that the code is well-commented or that developers should be able to figure it out for themselves — with the implicit suggestion that those who can’t don’t matter. That’s fine for some projects, but if you want your code to be more than a random page on Github, you’re going to need good documentation.

In an effort to help other projects improve their documentation, Kaplan-Moss has embarked on a series of articles outlining what he and the rest of Django’s developers have learned from the countless hours spent creating and refining Django’s docs.

While it’s worth reading through the entire series (and there’s more on the way), the basic message is quite simple: good documentation is more than just technical reference material.

What makes Django’s documentation stand out (and Ruby on Rails as well) is that it covers the details as well as the high-level overview of how the details fit together. Kaplan-Moss breaks down the types of documentation into three basic categories:

  • Tutorials — Tutorials are a great way to introduce users to your software and demonstrate high-level concepts in real world examples. Too many tutorials teach you little more than how to create a “hello world” script. Good tutorials should help your users actually build something, which is much more exciting for a new user than printing out a line or two of text. As Kaplan-Moss says “that rush of success as you work through a good tutorial will likely color your future opinions about the project.” Tutorials are the best way to make a great first impression on your potential converts.
  • Topical Guides — This is the real meat of good documentation and will be what users return to over and over again as they learn how to use your software. Kaplan-Moss’ advice is to aim for comprehensiveness: “the reader ought to come away from a close read feeling very comfortable with the topic in question… they should feel that they know the vast majority of the possible options, and more importantly they should understand how all the concepts fit together.”
  • Reference — Sadly reference materials are in fact what passes for documentation in much of the open source world. That’s not to demean reference guides; complete lists of class names and methods are absolutely necessary, but don’t stop there. As Kaplan-Moss writes, “think of guides and reference as partners: guides give you the ‘why,’ and reference gives you the ‘how.’”

If you’d like to see an example of well-done documentation that covers all these ideas, look no further than the Django Project website, which hosts all of Django’s documentation. The Ruby on Rails community has also produced excellent documentation.

Kaplan-Moss has two more parts to his documentation series, one in which he delves into topics like writing well, developing a clear, grammatically correct style and another that focuses on editing.

Kaplan-Moss’ post on technical style also covers things like markup and structural layout of documentation, since even the best documentation is useless if you can’t find what you need. For example one of the best parts of Django’s documentation is that every topic and reference page has a liberal dose of inline links that make it easy to jump from one section to another. While we wouldn’t suggest using wiki software, the everything-is-a-link model of wikis makes a good starting point for marking up your online documentation.

One of the biggest hurdles for many open source projects is finding good writers to create documentation. While Kaplan-Moss has some suggestions for making yourself a better writer, many developers don’t have the time to improve their writing skills. To that end we suggest paying close attention to your community.

Watch for blog posts from your users that offer tutorials or provide an in-depth at some aspect of your software. Contact the authors and see if you can incorporate their posts into the documentation. Give your users a chance to contribute not just code, but their understanding of the code — ask them to write more and make them a part of the project when appropriate.

Finally, perhaps the most important message of Kaplan-Moss’ post is that ultimately… some documentation always trumps no documentation.” Maybe your documentation isn’t on par with Django or Ruby on Rails, but don’t let that stop you from producing at least something. And be sure to check back with Kaplan-Moss’ site for more articles on creating good docs for your project.

See Also:



Meet Go, Google’s New Programming Language

Google has released a brand-new programming language it hopes will solve some of the problems with existing languages such as Java and C++.

The language is called Go, and it was released under an open source license Tuesday. Google is no stranger to the open source world. The company has released the underlying code for several of its tools and services under open source licenses over the years. Just last week, Google released its Closure JavaScript tools for building Ajax web apps. And now Google has considerably upped its investment in free software with the release of Go, which is an entirely new programming language.

At first glance, Go looks a bit like C++, but borrows some elements, such as garbage collection, from scripting languages like Python and JavaScript. But Go’s real standout feature is its speed. A demo video shows the entire language — over 120K lines of code — compiling in under 10 seconds.

As a systems language, Go is intended to be used for developer applications like, for example, web servers. In fact, the golang.org website is being hosted by a Go program. But as Go developer Rob Pike says in recent Google Tech talk, “although Go is designed as a systems language, it has a much broader use than that.” Pike goes on to cite front-ends and other general purpose programming that Go can handle.

One of the most appealing parts of Go is its ability to handle multicore processors and, as Google’s FAQ explains, “provide fundamental support for concurrent execution and communication.”

Existing systems languages like C++ evolved long before today’s modern, and very fast, processors hit the market and make supporting multicore chips more difficult. While Google could have concentrated on writing libraries that can handle those tasks in C++, the developers behind Go say that “too many of the problems — lack of garbage collection, long dependency chains, nested include files, lack of concurrency awareness — are rooted in the design of the C and C++ languages themselves,” and decided it was time for something entirely new.

Like many of Google’s open source projects, Go began life as a 20 percent time project (the time Google gives its engineers to experiment) and evolved into something more serious. Go has been in development for over two years now, but Google is hoping that, by releasing Go under a BSD-style license, a community will develop and build Go into a viable choice for software development.

At the moment, Go is still very young and experimental. Even Google isn’t currently using Go in “large-scale production” applications. While the site that’s hosting the code is running a server built with Go as a proof of concept, the primary purpose of this release is to attract developers and help build a community around Go.

Despite its fledgling status, Go already supports many of the standard tools you’d expect from a systems language and even includes support for other Google tools like Protocol Buffers.

Also, it’s worth noting that Google’s Go is not to be confused with an existing language entitled Go! (note explanation point). Google Blogoscoped reports that Go!’s developer Francis McCabe would like Google to change the name of Go, but thus far Google has not responded to that request.

At the moment Go is only available for Linux and Mac OS. If you’d like to learn more, check out the video of Pike’s tech talk below (it’s long, but offers a pretty thorough overview of Go) or head to the new Go website.

See Also:



Google Releases Closure JavaScript Tools For Building Slick Interfaces

Now, you can do the same crazy user interface stuff Google does on sites like Gmail and Google Docs on your own website.

The company announced it is releasing its Closure toolset under and open-source license on Thursday. The core pieces are the��Closure Library, which contains the actual scripts themselves, the��Closure Compiler, which optimizes and compresses the JavaScript code and the��Closure Templates, which are pre-built templates for elements you can snap together to build your website’s interface. There’s also a JavaScript inspector.

It’s often hard to remember, but when Gmail first arrived on the scene in 2004, it was something entirely new. Ajax wasn’t as widely used yet, and Gmail showed off what a JavaScript-powered web app could do in a simple and straightforward way. Not only was it a great productivity tool, but the way it refreshed and allowed drag-and-drop seemed, to many of us, like magic. It turned the webmail inbox — and the web app rule book — upside down.

You can go to Google’s Code blog to read about Closure’s release, inspect the license and download the tools.

From the post:

Closure Compiler, Closure Library, Closure Templates, and Closure Inspector all started as��20% projects��and hundreds of Googlers have contributed thousands of patches. Today, each Closure Tool has grown to be a key part of the JavaScript infrastructure behind web apps at Google. ��That’s why we’re particularly excited (and humbled) to open source them to encourage and support web development outside Google. We want to hear what you think, but more importantly, we want to see what you make. So have at it and have fun!



Same as it Ever Was: The History of HTML is a Conversation, Not a Spec

Developer Mark Pilgrim has posted a fascinating look at how the HTML img tag came into existence. The history Pilgrim digs up — mailing list conversations between the creators of the first web browsers like Marc Andreessen and the webs early pioneers like Tim Berners-Lee — show that far from being a carefully planned specification, the lingua franca of the web evolved a bit like the early universe — out of a murky chaos.

That from the chaos we got a workable — some would argue good — solution for creating the web is proof on some level that conversations and not abstracts, proposals and design by committee are the key to HTML’s success.

As Pilgrim writes:

HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction.

You might be wondering, why did img succeed where other proposals, like an include or an icon tag failed? The answer is simple, because Marc Andreessen shipped code — Netscape Navigator — while those backing the other proposals, for most part, did not.

Of course that doesn’t mean that just shipping code is always good plan. Shipping code before a standard doesn’t necessarily produce the best solutions, as Pilgrim says. Or, put another way by a commentator on Pilgrim’s post, “shipping doesn’t mean you win, but not shipping means you lose.”

From those who shipped without the official blessing of a standard, we’ve come to have an img tag, the basis for AJAX, all of the HTML5 tools available in browsers today and much more.

Critics of HTML’s disorganized evolution will be quick to note that we’ve also come to have the blink tag, cross-browser rendering issues and other pains of web development.

Indeed we’re not suggesting that shipping features without at least engaging in the conversation is a good idea, but, when it comes to the future of HTML, if browser makers don’t ship HTML5 features before the standard is official we’ll be waiting until 2022 to use the new tools.

But while the future of HTML5 might be moving at a rather slow and convoluted pace. Pilgrim’s post is reminder that HTML has always progressed that way.

Perhaps the truly remarkable part is that, for all its flaws and convoluted evolution the core tech behind the web remains essentially the same now as it was then. “HTML is an unbroken line… a twisted, knotted, snarled line, to be sure… but still… Here we are, in 2009, and web pages from 1990 still render in modern browsers.”

See Also:



Video: Users Are People, Too

User input is critical to the success of any project, be it a piece of desktop software, a web-based app or a simple brochure-ware website. And I’m not just talking about usability testing, e-mail forms or demographic surveys, which most of us consider a necessary evil. The truth is that your project, and your creative skills, can gain significantly from involving the user in the process of building and improving your app.

Granted, user communities can be a burden to manage, but the happiness of that very community determines how its members are going to engage with your app. If you ignore them or cheese them off, they’ll leave and refuse to come back. If you do what you can to satisfy them even a little, they’ll not only stick around, but they’ll encourage their friends to participate as well. And once you do engage your users directly, you’ll probably end up stunned at how rewarding the results can be.

The video above is of a talk by Google’s Ben Collins-Sussman and Brian Fitzpatrick — who is also head of Google’s Data Liberation Front, and who we interviewed last week on Webmonkey — at the company’s I/O developer conference last May. Ben and Brian talk in-depth about the “lost art of customer service” and the complicated relationship between engineers, user communities and marketing priorities.

A must watch for engineers, designers and project managers alike. About an hour long.

See Also:



Search Engine Optimization Is Part of Good Web Design

One significant aspect of web design that we at Webmonkey often ignore is so-called “search engine optimization,” or the art of making sure Google and its brethren can find, crawl and index your websites.

Part of the reason we typically ignore SEO is that it’s an industry full of what Derek Powazek, who has worked at both Google’s Blogger and Technorati, and is a former Webmonkey contributor, recently called “scammers.” Indeed, black hat SEO outfits are responsible for creating billions of bad results for users — highly ranked sites that actually offer little more than advertisements and spam.

It’s too bad the SEO industry ended up this way, but with the rise of Google and the importance of PageRank, as Powazek puts it, “like the goat sacrificers and snake oil salesmen before them, a new breed of con man was born, the Search Engine Optimizer.”

Naturally Powazek’s rant against SEO raised the ire of folks like Danny Sullivan over at Search Engine Land — people that focus on optimizing sites for Google without resorting to black hat techniques.

Leaving the ranting aspects of Powazek’s post aside, you’ll find that he and Sullivan actually agree. They just use different terms to describe what they’re talking about. The real message of Powazek’s rant is not that SEO is wrong, but that you shouldn’t have to pay extra to get it.

SEO is actually just a subset of good web design. Powazek writes:

Good SEO techniques are just good web development techniques. They should be obvious to anyone who makes websites for a living. If they’re not obvious to you, and you make websites, you need to get informed. If you���re a client, make sure you hire an informed web develeper.

Powazek is actually echoing Google’s own advice, which says: “if you’re thinking about hiring an SEO, the earlier the better… that way, you and your SEO can ensure that your site is designed to be search engine-friendly from the bottom up.”

In other words, if you’re a web developer and SEO isn’t part of your toolset you’re doing your customers and yourself a disfavor.

So what if you aren’t familiar with the intricacies of optimising your site for search engine spiders? Well, perhaps the best place to start is with Google’s own recommendations for webmasters and there’s also the Webmaster Central Blog.

For the nostalgic, we also recommend checking out Powazek’s decade-plus missive on why he loves HTML tables right here on this site.



Django Project Looks Toward the Future With Django 1.2

The developers behind the Django Project are getting ready to start work on the next version of the popular web development framework. Although Django 1.2, as the next release will be known, won’t be available in final form until March 2010, the project is currently voting on which proposed new features will be included in the next release.

Django is a powerful open-source web framework, written in Python. Compared to other open-source (or even proprietary) frameworks for building specialized, database-driven websites, Django makes the core tasks remarkably easy and fast.

Django already powers numerous high-profile websites, from the geo-aware EveryBlock to Google’s App Engine tools. In a testament to Django’s rapid development capabilities, developers Concentric Sky recently rebuilt the high-traffic michaelmoore.com using Django. From proposal to launch was a mere five weeks; you can read more about building the site over at the Concentric Sky website.

With Django gaining in popularity and more high-profile websites using the framework, the release of Django 1.2 in 2010 will be an important milestone for the framework.

Proposed new features for Django 1.2 include some features clearly geared at larger sites — support for multiple databases as well as a number of new database backend options will no doubt be a boon to developers should they make the final list. Other proposals include adding some more options to the Admin user interface and providing better built-in cross-site forgery protection. A complete list of proposals can be found on the Django wiki.

So far, no decisions have been made regarding any of the proposed features. Voting will continue until October 20, after which time an official list of what’s to come in Django 1.2 will be released.

If you’d like to contribute (and voting for a feature means committing to contribute to it) head over the the Django wiki and read through the guide to Contributing to Django.

See Also:



Yahoo’s Faster, Lighter YUI Tools Simplify Building Complex Websites

Yahoo has announced the official release of version 3 of its open-source Yahoo User Interface (YUI) library. The new framework is designed to simplify the process of building complex web interfaces.

With several popular JavaScript-heavy websites like Flickr, Yahoo Mail, MyYahoo and Yahoo Sports, Yahoo has long been at the web’s cutting edge for producing rich, interactive user interfaces. The company’s freely available YUI library has helped popularize various web interfaces we now take for granted, like drag-and-drop actions, tabbed interfaces and click-to-edit text fields.

YUI 3 represents a total, ground-up redesign of the framework and brings some much needed modernizations, including simplified syntax, JQuery-style selector support and a much lighter (6.2kb) “seed” file that makes for much faster page load times.

Developers first got a taste of YUI 3.0 over a year ago when Yahoo began offering a testing version of it, along with suggestions on migrating from YUI 2.0. Since then, Yahoo has vastly improved the library and launched it into the wild on the front door of Yahoo.com.

“The code we’re shipping today in 3.0 is the same code that drives the new Yahoo Home Page, and it goes out with confidence that it has been exercised vigorously and at scale,” writes Yahoo’s Eric Miraglia.

YUI 3.0 brings the framework up to par JQuery and other popular tools for building rich JavaScript interfaces, especially Yahoo’s decision to embrace selectors. While previously controversial since they involve some processing overhead, modern web browser have no trouble parsing selector libraries.

The nice side effect of selectors in YUI is that developers familiar with the JQuery or Prototype JavaScript libraries should be able to transition to YUI without too much trouble. That gives web developers yet another option when it comes to designing and creating rich web interfaces.

YUI 3 is a free download, you can grab a copy from the YUI blog.

Photo: Neil Crosby/Flickr

See Also:



Do Frameworks Have a Place in Web Development’s Future?

Snakes on the Web from Sebastian Desimone on Vimeo.

Let’s face it: web development sucks.

Not all the time — in fact, there are an increasing number of great, dare we say fun, tools out there. Frameworks like Ruby on Rails and Django take a lot of the pain out of web development, and JavaScript libraries like JQuery or Dojo make creating slick user interfaces easier.

But even with the fantastic tools we have, there are still plenty of mundane tasks that, well, suck. In fact, most advancements in web development have come from a very basic developer problem: how can I make this suck less?

That’s the question Django developer Jacob Kaplan-Moss recently set out to answer at a Python Conference in Argentina. As Kaplan-Moss says in his talk, embedded above, “we’ve already made a great transition from thinking about ‘web pages’ to thinking about ‘web applications’.” His key point, however, is that, “it’s time for a new transition, for us to start thinking about a holistic ‘web site,’ and all its associated related tech.”

For Kaplan-Moss “all its associated related tech” means everything from backend frameworks to HTML 5, which is going to change the way web developers work. If you don’t believe that claim yet, check out 280Slides.com, which looks and behaves like a desktop app — drag and drop things within the app, to desktop and from the desktop. Sadly, as Kaplan-Moss points out, the developers of 280Slides had to create not just a new framework (Cappuccino — which you can read our assessment of), but what amounts to whole new language (ObjectiveJ) to realize their goals.

Creating a custom framework sucks, so imagine how much it sucks to create a new language. Surely there’s a better way?

Maybe. But, according to Kaplan-Moss, we should look to rethink the frameworks themselves since they’re largely to blame whenever modern web developers paint themselves into a corner.

Frameworks have two problems — they don’t scale beyond a certain point and, much worse, they trap you inside the framework. Frameworks are optimized for the generic, which is why they work for so many sites. But as those sites grow, they need specific solutions, not generic ones. Django, Ruby on Rails and other frameworks are great ways to get up and running quickly. But over time, as your site grows, the “Twitter moment” eventually arrives when, as Kaplan Moss says, “all hell breaks loose.” You’ve outgrown your framework and you’re screwed.

If you were an outsider looking in, it would seem logical to assume that if Ruby on Rails were letting you down in some place — say the concurrency problems that plagued Twitter — you could simply swap out that chunk of code for another written in Haskell, Erlang or another language optimized to solve concurrency problems. Sadly, that idealized vision of web development bears no resemblance to reality. Where we web developers find ourselves right now, there’s simply no way to easily write a part of your site in Django, a part in Rails and part in Erlang.

What’s the solution? Well, there may not be one. But if one does exist, it most likely involves taking a major leap and leaving monotheistic frameworks behind.

Kaplan-Moss is at heart a Python fan, so he wants the solution to come from Python. And indeed, Python does have quite a history as a “glue” language. Desktop and game developers have long written the performance-critical parts of their applications in C++ or Java, then used Python to tie together the higher-level customization tasks.

Something similar might be possible on the web — using Python to tie together Haskell, Erlang, Ruby and other languages. The problem is that we’re a long way from any solution — Python-based or otherwise — and the web is continues to grow both in size and, with HTML 5, complexity.

It’s true that most sites are small enough that they’ll never have to face the sort of traffic and scale woes that Twitter, Facebook and Google have had to deal with. But it is precisely the edge cases of high-traffic sites that have created many of the tools we have to day — Twitter, Google and others are the crucible in which all our current tools are truly tested and from which — ideally — new solutions will emerge.

While the average web developer might not face the sort of challenges those sites do just yet, the potential solutions will affect all of us and, hopefully, make the web development suck just a little less.

See Also:



Tr.im Source Code Now Available

Tr.im, the popular URL-shortening service for Twitter and other social networks has announced the initial release of its backend code as a new open source-project on Github.

After announcing it would shut down by the end of the year, the team behind Tr.im then decided to continue on as a community-supported open source project. The team said it would release all of its code under the MIT open-source license and offer developers unfettered, real-time access to all the link-map data associated with Tr.im URLs.

Until the code showed up on Github though, the Tr.im announcement was, well, just talk. But now you can grab a copy of the code and start exploring. At the moment, the Github page has the first two modules for tr.im. The final tr.im website module will be released in a few days.

The tr.im developers caution that the authentication and login system needs to be updated, and some bug fixes need to be applied as well. However, if you’re impatient and you’d like to start digging into how the tr.im code works, what’s available now should get you started.

The tr.im blog also says that final steps are in motion to donate the tr.im domain name to a third party that will hold it in trust for the sole use of the tr.im project.

See Also:



 
Subscribe now

Special Offer For Webmonkey Users

WIRED magazine:
The first word on how technology is changing our world.

Subscribe for just $10 a year