Mozilla

Web Developers Articles

Sort by:

View:

  1. How to Spread The Word About Your Code

    You spent an entire weekend building a library, jQuery plugin, build tool, or other great piece of code you wanted to share far and wide, but after some tweets and a failed attempt to make the front page of Hacker News, your creation languished, unloved, in a GitHub repo. A common situation for many developers nowadays, but one you can avoid.

    As the editor of several programming newsletters, I frequently get two types of e-mails from developers. Those reaching out to ask if I can mention their projects, and those expressing surprise and excitement that their work has been featured. If you’re a developer doing good work but feel more like you’d be in that second group, the three steps in this article are for you.

    Before we get started, there’s a stumbling block we need to kick away. Terms like ‘marketing’ and ‘advertising’ are dirty words for many developers and it’s not uncommon for developers to be reluctant to do much promotion. ‘Build it and they will come’ used to work when exciting open source projects were few and far between but now everyone seems to be working on something and making a noise about it. Few of the successes you see come through pure luck but because developers are actively promoting their work or, at least, making it discoverable. It’s time to join them!

    Step 1: Get your project ready

    Before you can promote your project, you need to make it attractive to potential users and evangelists (including general wellwishers, the media, and other developers).

    A good name

    Ensure your project has a palatable name. It doesn’t need to be clever or even descriptive, but it’s worth avoiding innuendos that may present a problem down the line. For example, the popular Testacular and Authgasm projects, are now named Karma and Authlogic respectively after users raised a fuss.

    You should perform a search for the name you choose to be sure you’re not clashing with anything else that’s popular or trademarked (did you know Firefox was called Phoenix and Firebird prior to Firefox?). The US Patent and Trademark Office has an online trademark search facility.

    A benefit of having a relatively unique or uncommon name is so you can search for it over time (or even set up a Google Alerts notification for the name) and find mentions of your project without many irrelevant results popping up. If you want to have something descriptive but unique, consider joining two words together. For example, when I created a Ruby library to do natural language detection, I called it WhatLanguage and it’s easy to search for.

    An official homepage or project URL

    The term ‘homepage’ is a bit outdated but you ideally need a single ‘home’ URL that you can promote and point people to in relation to your project. You don’t need to splash out on a fancy template or even a domain name, but your project needs a focal point. That could be an entire site with its own domain, such as those for Yeoman or HTML5 Boilerplate, a simple single page on an existing domain, such as that for RoughDraft.js, or even a regular GitHub repo, such as for vague.js.

    If you have the freedom to do so, make sure your site looks good on the major browsers (including mobile), hook up some analytics to your page and ensure the <title> tag is well written. Use a title like “MyProject – A JavaScript Library to X, Y and Z” instead of just “MyProject – About” or a blank title. With social bookmarking, this matters as you can’t guarantee your evangelists will write a good title of their own.

    If you’re not a Web designer, don’t have the time to spend making a complete design, but still want a complete site rather than just a GitHub repo and README, consider using a framework like Bootstrap as it’ll provide a clean layout out of the box and you can forget about many cross browser and device issues.

    Documentation and copywriting

    It’s only just a cliché that developers don’t like to write documentation, but you need something for potential users to fall back on, and time invested in producing useful documentation up front will pay dividends later.

    At a cynically bare minimum, you need to write enough documentation that someone will be confident about sharing your link or promoting your project and not feel like they’re sending their own followers into a black hole of misunderstanding. This means your homepage or README needs to cover a few angles. You’ll need to:

    • Prominently feature a “[noun] is” paragraph. An alarming number of project homepages don’t explain, in simple terms, what the project is actually for or does. If you’ve built a JavaScript library that does language detection, say, you have to say so. For example: “LanguageDetect is a JavaScript library for detecting the natural language of text.”

      An excellent example of this in action is on libcinder.org where it states right up front: “Cinder is a community-developed, free and open source library for professional-quality creative coding in C++.” Perfect!

    • Write clear titles, subheadings, and support copy. At a bare minimum, ensure titles, subtitles, and any sort of writing on your homepage are straightforward and clear. Write for the lowest common denominator on your homepage. You can get more advanced elsewhere.

    • Write a beginner’s tutorial and link to it from your home page. Unless everything’s simple enough to explain on a single page, quickly write a tutorial that covers basic installation and usage and either include it in your README file or put it on the Web and link to it from your README and/or homepage.

    • State dependencies and requirements clearly. Does your library only work on a specific version of Node? Is it a browser extension for Firefox? Does your code require PostgreSQL, Redis, or another specific database? Be sure to include a bulletpoint list of dependencies and requirements for your project to be usable so as not to disappoint potential users.

    • Specify the license for your code. While you could get away with keeping your licensing information tucked away in a LICENSE file in your GitHub repo, specifying what license your code is released under up front and center will help put many developers at ease. Likewise, if your project is commercial is nature and costs money, don’t hide that detail away and mislead visitors.

    • If your project is a library or API, feature some example code on the homepage. Unless your library is particularly complex, let visitors see an example of its usage on the project homepage. If your API is good, this could be a great way to get an ‘easy sale.’ I’m not a huge fan of the code example chosen but the homepage for Ruby shows off this technique.

    Extra materials

    A blog post is a great way to introduce a project that might need more background or have more of a story than it’s practical to tell on a homepage or within documentation. If there’s any sort of story behind your project, a blog post is a great way to tell it. Be sure to link to the post from your project’s homepage and consider promoting the blog post separately to relevant sites within your niche.

    If you have the ability, recording a screencast or other sort of video can help. Could you put together a simple 5 minute screencast of how to install and use your library? Or have you built a game that could be demonstrated in a few minutes of gameplay? Record a simple video, put it on YouTube, and embed it on your homepage. Your accent doesn’t have to be as crisp as a newsreader’s and you don’t even have to appear within the video. All that matters is you get to the point quickly and your audio is tolerable (not muffled, clipping, or drowned in background music).

    As the editor of several programming newsletters, I look at thousands of projects each year, and it’s still uncommon to see simple screencasts, yet they certainly help a project stand out and, as a consequence, make it more likely for me to talk about it. You can see a perfect example on Punch’s homepage. The early popularity of Ruby on Rails also depended upon a popular ‘build a blog engine in 15 minutes’ video, back when the concept of using video to promote an open source project was very novel.

    If you’re sticking to the straight up, GitHub README approach (and it’s certainly not a bad idea for a simple library), a bonus tip is to create a tiny screencast of your code in action and convert it to an animated GIF for inclusion in your README. Richard Schneeman outlines this technique in Use GIFs in your Pull Request for Good, not Evil. The result is striking and could help your README stand out.

    For further ideas on how to make your project stand out before you begin promoting it, check out the great How to Make Your Open Source Project Really Awesome by Michael Klishin. It digs into more detail about versioning, announcements, having a changelog and writing good documentation.

    Step 2: Get the word out

    You’ve polished your project, got a URL to promote, and you’re ready to get the news out.

    A word of caution, however. Don’t use every technique on day one. You could overload your site with traffic or, worse, be subjected to a barrage of online criticism if your work or site is broken. With something like a library or tool, a gentler approach will work well and building up small streams of visitors and users over time will give you a much better time.

    Social networking

    Your own social networking profiles are always a good place to start if you have them. You’ll get more immediate feedback from people who actually know you and if your project is particularly interesting, it could go viral even from a single mention.

    A great example of a simple project going viral was YouTube Instant by Feross Aboukhadijeh. Feross built YouTube Instant quickly, mentioned it on Facebook before going to bed, and woke up to a flood of traffic and press mentions.

    If you like to experiment and have several bucks going spare, you could also consider paying for a promoted post on Facebook. This will give your post more visibility in your news feed, but is best reserved for if your Facebook friends are mostly developers or people likely to be interested in your project. If not, and you’d still like to spend some money, consider an ad on Reddit or a relevant programming blog instead.

    Influencers, bloggers, and niche media

    Whether you’re working on a JavaScript library, Firefox extension, backend app in Rails, or a theme for Bootstrap, your code will fit into one or more niches and every technical niche has a variety of ‘influencers’, people and publications who are popular and well known for the topic at hand.

    Getting a tweet, retweet, or even an entire blog post from an influencer could have a significant impact on your project, as could being invited to blog elsewhere (Mozilla Hacks, for example!). If Brendan Eich tweeted about your JavaScript library, Lea Verou wrote a blog post about a CSS trick you discovered, or Paul Irish mentioned a Web development tool you built in a talk, you would attract a lot of interest quickly. It is key, however, to realize there are many great influencers in every space and you’ll achieve nothing by hounding any one person so be prepared to move on.

    Spend some time working out who the influencers and key publications are in your niche. For Twitter, Followerwonk is a handy tool that searches Twitter biographies for certain words. If you search for “javascript” the first page includes several users who would be useful to reach out to if you had a particularly interesting JavaScript-related release to promote. Reaching out on Twitter can be as simple as a single tweet and many busy folks prefer Twitter as it takes less time to reply than an e-mail. A single tweet from @smashingmag could drive thousands of visitors your way, so consider tweeting them, and other similar accounts, when you have something relevant.

    I’d also advise looking for blogs and e-mail newsletters in your niche. Start with something as simple as Googling for “javascript blog”, “javascript newsletter”, “css blog” or whatever’s relevant to your project. Most bloggers or e-mail newsletter publishers will not be offended by you sending them a quick note (emphasis on quick) letting them know about your work. Indeed, some weeks there can be a shortage of interesting things to write about and you might be doing them a huge favor.

    If you choose to e-mail people (and your project will probably be more substantial than a few hours’ work to justify this), take care not to make demands or to even expect a reply. Many bloggers and influential people have overflowing inboxes and struggle to reply to everything they receive. Make your e-mail as easy to process as possible by including a single URL (to your now superb homepage or README) and include your “[noun] is” paragraph. Don’t take a non-response as an insult but keep moving on to the next most relevant person. You might even consider taking a “Here’s my project that does X, Y and Z. No reply needed, I just thought you might like it” approach. Softly, softly works here, as long as you get to the point quickly.

    How to get attention from internet celebrities by Jason Cohen and How to Write the Perfect Outreach Email by Gregory Ciotti go into more detail about e-mail etiquette when promoting your work to influencers. While you might not need to contact any ‘celebrities’ in your niche, the principles of keeping it short, including a call to action, and ensuring your work is appropriate to the person are really true for anyone you’re sending unsolicited messages to.

    Podcasters are an often forgotten source of promotion opportunities too. While some podcasts don’t cover news or new releases at all, many do, and being on the radar of their hosts could help you get a mention on a show. Smashing Magazine has put together a list of tech podcasts covering the areas of design, user experience, and Web development in general. Again, keep your e-mails short and sweet with no sense of expectation to get the best results.

    User curated social news sites

    As well as reaching influencers and niche media, sometimes reaching the public ‘firehose’ of news can work too, and there are few better examples of these in the modern world of development than Hacker News or Reddit.

    Hacker News in particular is notoriously hard to reach the front page on and ‘gaming’ it by getting other people to vote up your post can backfire. (Indeed, it will backfire if you link people to your post on Hacker News and encourage them to upvote. They have ways of detecting this behavior. Get people to manually find your post instead.) If you do reach the front page of Hacker News, of course, you can certainly expect an audience of many thousands of developers to be exposed to your work, so be sure to try.

    With Reddit, the key isn’t to dive straight into a huge sub-Reddit like /r/programming but to look for sub-Reddits more directly related to your project. For a JavaScript library, I’d post to /r/javascript or possibly /r/webdev. Reddit ads can also perform well if you’re OK with spending some money and these can be targeted to specific sub-Reddits too.

    There are many similar sites that are less well known but which are respected in their niches and can drive a lot of interested visitors, including Designer News (mobile and Web design), DZone (general developer stuff), EchoJS (JavaScript), RubyFlow (Ruby and Rails), and Lobste.rs (general hacker and developer stuff). Finding the right site like this and taking time to make an on-topic, well written post will help a lot.

    The mass media / press

    This article is primarily focused on the promotion of open source and front-end projects and these are typically not frequently covered in print or on the TV or radio. If, however, you think the mass media would be relevant for your project, here are some other articles packed with handy tips:

    Step 3: Maintain momentum

    You’ve built up some interest, your GitHub stars, Reddit votes, and pageviews are all rocketing up, but now you want to capitalize on the attention and maintain some momentum.

    User support

    Whether you’ve built an open source project or a cool tool, you’re going to end up with users or fellow developers who want to provide feedback, get help, or point out issues with your work. On GitHub, the common way to do this is through the built-in ‘issues’ tracker, but you might also find people start to e-mail you too.

    Be sure to define a policy, whatever it is. Users won’t feel good about opening issues on your GitHub repo if there are already many unresolved issues there and your project could stagnate. Ensure you respond to your audience or at least make your policy clear within your README or on your site. If you don’t want issues raised or code contributions, make this clear up front.

    Extending your reach

    For many projects, create a dedicated Twitter account, blog, Facebook page, or Google+ page in advance is overkill, but if your project starts to take off, consider these things. They’ll provide an extra way not only for users to remain in touch with your project but also a way for them to help promote it by retweeting things you post or by directing potential new users your way.

    You can also extend your reach in person by going to user groups and conferences and, if you’re really lucky, you can speak about your work too. This is a great way to get new users as people are much more likely to look into your work if they’ve met you in person.

    Avoid being defensive

    If your project does well on sites like Hacker News or Reddit, you’ll be tempted to read all of the comments your peers leave, but be careful. Comments about your work will, naturally, seem magnified in their intensity and critical comments that might not actually be mean spirited may seem as if they are to you.

    It’s hard, but the best policy is to not let any overtly mean comments get to you, duly correct any observations that are wrong, and to thank anyone who goes out of their way to compliment your work. Even if you’re in the right, with the lack of body language and verbal cues, being too defensive can look bad online and result in the post becoming a lightning rod for drama. Engage as best you can, but if it feels wrong to reply to something, listen to your gut.

    Be careful if you go into a new community to promote your work and get negative feedback. Most communities have rules or expectations and merely entering a community to promote your work is frequently considered a faux pas. Be sensitive to people’s environments and try to abide by a community’s rules at all times.

    The long term

    If your project does particularly well, you could be presented with the opportunity of turning it into a business in its own right. Many simple open source projects, often started by a single developer, have turned into long term work or even entire companies for their creators.

    Back in 2010, Mitchell Hashimoto released Vagrant, a Ruby-based tool for building a deploying VirtualBox-based virtualized development environments. In late 2012, Mitchell launched Hashicorp, a company providing Vagrant consulting services to enterprise customers. An even higher profile example is Puppet Labs, a company built around the Puppet open-source configuration management tool and which has taken total funding of $45.5 million so far.

    If your project becomes respected and heavily used within its field, you might also be approached to write a book or article about it or even speak at a conference. This is a good sign that your project has ‘made it’ to some extent as publishers and event organizers are in the business of working out what it makes business sense to present.

    Putting it all together: A checklist

    This has only been a basic introduction to promoting your work and with practice you’ll come up with tons of tips of your own (it’d be excellent if you could share some in the comments here). Based on all of the ideas above, here’s a basic checklist to run through next time you release a new project and want to get some added exposure:

    • Focus most of your efforts on your project’s homepage or README.
    • Check your project’s name doesn’t clash with anything else and is unique enough to find references to your work later.
    • Promote your work to your closest social group first to unbury any problems with your work.
    • Record a screencast or write a blog post about your project if some extra background would be useful for others.
    • Work out a perfect *”[project name] is”* sentence to describe what your project is or does.
    • Use your *”[project name] is”* sentence to give your page a descriptive title.
    • Find influential people, blogs, podcasts, and e-mail newsletters in your niche and send them a short, pleasant note.
    • Post to social news and bookmarking sites. Ensure your title is descriptive.
    • Use your *”[project name] is”* sentence in e-mails and contacts with influencers.
    • Take a positive, “look on the good side” approach to responding to comments about your work.

    Good luck!

  2. Launcher.io – Launch and run free open-source web applications in just 30 seconds – a WebFWD project

    There is no longer any doubt: web apps are the focal point of the cloud. From database-as-a-service to platform-as-a-service to security-as-a-service and beyond, the entire *aaS model has the web app as its center of gravity.

    If you’re a full-fledged developer, then taking full advantage of an app-centric universe is no big deal. Creating new web apps from scratch using frameworks like Ruby on Rails, Drupal, Django, or hundreds of others and then deploying those apps in the cloud is part of your daily bread and butter.

    The mission

    The mission of Launcher.io is quite simply to make it vastly easier for developers and non-developers alike to create and deploy their own web apps with a single click of the mouse. Launcher was founded by me, former AppFog director of product Maciej Skierkowski, and I have taken what I have learned in my time in the platform-as-a-service (PaaS) space and used that knowledge to make app deployment even more dead-simple than a typical PaaS platform does.

    How it works

    So how does it work? Launcher enables you to deploy so-called “jumpstart” apps with a single click. If you’ve signed up for a Launcher account, all you have to do is click on a jumpstart’s button and you’ll be prompted for basic information, and Launcher will do the rest of the work.

    From there, you can manage your app however you like. Frameworks like Drupal, WordPress, or Concrete5 provide you with an intuitive in-browser interface for modifying your app, whereas frameworks like Ruby on Rails, Flask, ActionHero.js, and others will require more in-depth web development knowledge.

    Launcher: great for non-developers

    The benefit for non-developers is that it makes using all of these platforms easier than ever before. Want to start a new WordPress blog? All it takes is signing up to Launcher and clicking a button, and your blog is up and running in the cloud. The rest is up to you. Are you starting a company and want to set up Drupal to run your content management system and ThinkUp for social media analytics? Also a click and a few keystrokes away.

    Launcher: even better for developers

    For developers, the benefits of Launcher involve speedier adoption of new apps and frameworks amongst potential users. Let’s say that I’m a Java developer and I just created the most bleeding-edge CMS currently available. If Drupal is a Cadillac, then my new CMS platform is a fresh-off-the-assembly-line Maserati: it’s blazingly fast, it has a wonderful in-browser console, and it has millions of useful plugins that Just Work.

    If users wanted to use my CMS in a pre-Launcher world, they’d have to do it the hard way: download it onto their machine, run appropriate configs to make it cloud-ready, learn how to use a VPS (or a PaaS, which is a very recent development), and so on. But with Launcher, potential users can give my new CMS a spin in just a few seconds and have it running in the cloud, and making my CMS Launcher-ready provides little to no modification on my part.

    The app landscape is extremely competitive, and anything that can speed potential adoption that quickly is a massive win for me as a developer. Launcher is simply an unprecedentedly direct pipeline to my new SaaS product.

    Under the hood

    Surprisingly enough, Launcher is amazingly simple in how it works behind the scenes. When an end user clicks on a jumpstart, the browser makes an AJAX request to a remote service kicking-off a Resque worker that deploys the app with AppFog or CloudFoundry.com. Setting up an HTML page to handle a Launcher jumpstart involves simply loading the jQuery and Pusher JavaScript libraries and inserting a few lines of JavaScript (check out the docs for more info).

    Your app will, however, need to be registered with Launcher to be included in the Launcher App Store. If you’re interested in doing so, don’t hesitate to get in contact with me, as I am looking to expand the range of offerings in the app store in the coming months.

    He’s also looking to expand the number of PaaS providers that support jumpstarts. At the moment, Launcher enables you to instantaneously deploy apps on either AppFog or Cloud Foundry, but Launcher is in principle compatible with any Cloud Foundry-compatible PaaS API. If you’d like to add a new PaaS, simply go to the Providers page, click “Add Provider,” and input a name, API endpoint, and other information.

    More on the way

    Launcher is a new project, and has a great deal more in store for both developers and end users. Jumpstarts for OpenPhoto, Redmine, and SugarCRM, to name just a few are coming soon.

    If you’re a developer, startup, or enterprise looking to take advantage of Launcher, email maciej@skierkowski.com for more information.

  3. Codebender: physical programming on the web – a WebFWD project

    What is codebender? What problem does it solve?

    Whereas the cloud-based, software-as-a-service development has made it easy to develop by reading some tutorials and start hacking, physical computing is lacking far behind. This used to be in part due to the difficulty of designing hardware, but platforms such as the Arduino have made this a thing of the past. Instead of looking for the right components (out of thousands) and trying to connect them without frying any, there’s a large number of circuits designed to work great with each other.

    We still have a long way to go, though.

    Unfortunately, most of the tools still live in the 90s. New users have to install unintuitive applications or various command-line tools and platform-specific programs. That’s where codebender comes in. It is an embedded development platform with an emphasis on the Arduino and it’s completely web-based, so you don’t have to install, manage and update anything. Essentially, we are bringing physical programming and the physical world to the cloud.

    New development tools for the embedded software developers

    As I mentioned, we start by being completely cloud-based. This essentially starts with storing your code on the cloud, and we also store various settings, libraries and hardware configurations as well. We’re working on storing additional info like circuit schematics and images of the final products as well. So instead of having all these resources scattered around, every bit of your project is bundled together.

    This makes even more sense when coupled with our collaborative and social tools. If you want to build something that’s already out there, you don’t need to reinvent the wheel. You just clone an existing project, and you get the code, the schematics, the instructions and anything else you might need.

    On the coding front, we’re bringing syntax highlighting, indentation, auto-formatting, and soon, code completion. And since you’re bound to make a mistake, we’re topping it up with a state-of-the-art compile output, that lets you identify the issues faster and easier.

    Our next plans are, of course, some kind of versioning, and integration with tools like GitHub, Dropbox, etc. Further down the road, we plan to add more collaboration tools to promote the exchange of knowledge and ideas between users. Things like group projects and project discussions for example.

    The ultimate goal is to empower people to build more

    We aim to promote the maker and hacker culture and get more and more people to look at the world as something to be hacked, modified and transformed. We strongly believe in the open-source ideals and in constructing/developing stuff rather than consuming endlessly. It is important for people to realize their ability to interact with their environment and better their everyday lives (or just build cool stuff) without being professional software/hardware engineers and we hope codebender will help them do that. This is our reason to get up in the morning (and stay up until the morning).

    We also think codebender is a valuable tool in a seasoned developer’s toolkit and a welcoming place for the newcomers that doesn’t scare them off, but rather guides them into the exciting world of physical hacking. In that sense, we want codebender to evolve into a community driven hub of exchanging ideas and knowledge with a diverse audience of makers, developers/engineers, instructors and artists actively participating in what, in our opinion, will be the future of programming embedded devices.

    Our open source projects

    We’ve released a lot of open source projects in the past, both personally and as a team. As far as codebender goes, we’re taking care to design the whole system as a number of independent subsystems. So we have released the cloud compiler, the cloud uploader which allows you to program your embedded devices remotely through the network (TFTP-only for now but other protocols coming soon), the device firmware (bootloader) which adds remote network programming support to Arduino, the browser plugin which allows your browser to communicate with your programmable usb devices, and the code for the website itself. It’s all open source.

    Want to get a better idea of how these projects are use and how they all fit together? Then watch this short screencast:

    codebender tutorial from codebender on Vimeo.

    We also use a lot of other open source projects, and contribute back

    On the front-end, we use jQuery, the venerable javascript library, Twitter’s Bootstrap for the fancy UI stuff, the Ace editor, which is an awesome pure HTML5 editor and beautify.js for auto-formatting code.

    On the backend, we use Symfony 2 for the website and store user’s info and projects on MySQL and MongoDB respectively. As for the compiler, we use gcc-avr, the GCC port for Atmel’s AVR architecture to build the binaries, but we use the state of the art Clang C/C++ compiler to perform advanced syntax analysis. Clang is awesome in that it provides really great error output. Here’s a good example (prepare for I-love-Clang-it-is-awesome rant):

    #include 
    
    int myfunc(float first, float second)
    {
        return 0;
    }
    
    int main(void)
    {
        int variable1, variable2;
        if(variable1 = variablr2)
        {
            printf("hello guys")
        }
        myfunc(variable1);
        myfunc((float) variable1,);
        myfunc((float) variable1, &variable2);
    }

    Let’s explain the errors. First of all, we have a typo (“variablr2″ instead of “variable2″) on line 11. Next, we forgot to add the infamous semicolon on line 14. And finally, on lines 15-17, we are calling myfunc() in 3 wrong ways.

    Here’s what gcc has to say about this:

    test.c: In function ‘main’:
    test.c:11: error: ‘variablr2’ undeclared (first use in this function)
    test.c:11: error: (Each undeclared identifier is reported only once
    test.c:11: error: for each function it appears in.)
    test.c:14: error: expected ‘;’ before ‘}’ token
    test.c:15: error: too few arguments to function ‘myfunc’
    test.c:16: error: expected expression before ‘)’ token
    test.c:17: error: incompatible type for argument 2 of ‘myfunc’

    Pretty decent, right? It finds all the errors, and is kind of helpful in some cases. For example, we can infer that the error in line 11 is a typo, we know the error in line 14 is a forgotten semicolon (except it’s really on line 13), and the errors for lines 15 and 17 do give us some hints. The error report for line 15 is slightly less stellar since there are two closing parentheses, but that’s because of the casting and it won’t take long to figure our the issue (most of the times).

    Let’s see what clang has to say about it:

            if(variable1 = variablr2)
                           ^~~~~~~~~
                           variable2
    test.c:10:17: note: 'variable2' declared here
            int variable1, variable2;
                           ^
    test.c:11:15: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
            if(variable1 = variablr2)
               ~~~~~~~~~~^~~~~~~~~~~
    test.c:11:15: note: place parentheses around the assignment to silence this warning
            if(variable1 = variablr2)
                         ^
               (                    )
    test.c:11:15: note: use '==' to turn this assignment into an equality comparison
            if(variable1 = variablr2)
                         ^
                         ==
    test.c:13:23: error: expected ';' after expression
                    printf("hello guys")
                                        ^
                                        ;
    test.c:15:18: error: too few arguments to function call, expected 2, have 1
            myfunc(variable1);
            ~~~~~~          ^
    test.c:16:27: error: expected expression
            myfunc((float) variable1,);
                                     ^
    test.c:17:28: error: passing 'int *' to parameter of incompatible type 'float'
            myfunc((float) variable1, &variable2);
                                      ^~~~~~~~~~
    test.c:3:31: note: passing argument to parameter 'second' here
    int myfunc(float first, float second)
                                  ^
    1 warning and 5 errors generated.

    This is really much more verbose, but it’s also much more helpful. For starters, Clang recognized that we have a variable with a really similar name, and suggests that. Not only that, but it assumes that’s what we meant in the first place, and carries on. It’s not uncommon to get 100 false errors from gcc and have them all disappear when you fix the first one. Clangs assumptions greatly help in that, but it would take a huge example to show that.

    Next, we have a warning. One of the most common mistakes both rookies and seasoned developers do is the assignment operator instead of the equality on (“=” instead of “==”). You probably didn’t notice, did you? I thought so :) So, Clang will warn you if you assign inside if() statements. Don’t worry, if you do want to assign, you can either wrap that in another parenthesis (which has no effect in your code) or you can silence these warnings altogether.

    It will also give you a more precise report on the forgotten semicolon of line 13, but that’s a minor improvement. The real fun starts in lines 15-17. The error report on line 15 is quite better, since it gives us the number of arguments needed. Line 16 is more or less the same, but line 17 is a nice improvement. Not only does it state the nature of the error, it also gives us the type of the parameter we are passing, the expected type, and the prototype of the function! Now that’s the kind of stuff people like!

    Users First

    If I would like to end with something, that would be it. You do know the “customer is always right” motto, but it goes way beyond that. In this era, it’s really about the user. If you build something, make sure the people who use it (for example, in the case of a library, other developers) like it, and figure out what they need. I always say, if you’re going to make something, make something people are eager to use every day. Not something they use out of necessity..

  4. The Web Developer Toolbox: Backbone

    This is the fourth in a series of articles dedicated to useful libraries that all web developers should have in their toolbox. The intent is to show you what those libraries can do and help you to use them at their best. This fourth article is dedicated to the Backbone library.

    Introduction

    Backbone is a library originally written by Jeremy Ashkenas (also famous for having created CoffeeScript).

    Backbone is an implementation of the MVC design pattern in JavaScript. It allows you to build applications easier to maintain by strongly dividing responsibility of each application component. Actually due to it’s high flexibility, Backbone is more something like a super controller in the MVC design pattern than a true MVC implementation. It gives you freedom to choose your own model or view system as long as you make sure they are compatible with its API.

    Basic usage

    Backbone is made of 4 core objects that will be used to drive your application: Collection, Model, View, Router. To make things a little clearer here is a quick schema of their interaction:

    The Model objects

    Those kind of objects are the heart of your application. They will contain the whole logic of your application and they will dispatch events each time they are updated. That way, you can easily bind a View object to a model in order to react to any change. Those objects are actually wrappers around your own application business logic (Functions, Objects, Libraries, whatever).

    The Collection objects

    As stated by its name, this type of object is a collection of Model objects with their own logic to sort them, filter them, etc. This object is a convenient way to make the glue between the model and the view because it is some sort of a super Model object. Any change send by a Model object in a collection is also sent by the collection so it makes easy to bind a view to several Model objects.

    The View objects

    Backbone views are almost more convention than code — they don’t determine anything about your HTML or CSS for you, you’re free to use any JavaScript templating library such as Mustache, haml-js, etc. The idea is to organize your interface into logical views, backed by models, each of which can be updated independently when the model changes, without having to redraw the page. Instead of digging into a JSON object, looking up an element in the DOM, and updating the HTML by hand, you can bind your view’s render function to the model’s “change” event — and thanks to that everywhere that model data is displayed in the UI, it’s immediately updated.

    The Router objects

    Those objects provides methods for routing URLs, and connecting them to actions and events on Model objects. It relies on the History API to nicely handle the URLs. For browsers which don’t yet support the History API, it handles graceful fallback and transparent translation to a hash fragments’ URL.

    So as you can see it’s not necessarily a canonical implementation of the MVC design pattern but it allows you to work that way with high flexibility.

    Getting started or Digging into it

    Digging into Backbone is not that simple. As you can see, I haven’t tried to provide some code sample in this article. Even if the documentation is well written it’s sometimes a bit difficult to understand how to use the full API. Fortunately, there is some very good tutorials and projects out there and I recommend the following:

    If you know some other good resources, feel free to add it through the comments ;)

    Limits and precautions

    One of the biggest limitations of backbone is its dependency of two other libraries: Underscore and jQuery (or jQuery like library such as Zepto). The former provide some very useful (and missing) features to JavaScript, the latter is conveniently used to access and manipulate the DOM easily as well as dealing with DOM Events.

    Another point you should take care of is that backbone remains a very low level library that can be hard to deploy and to use easily. This is mainly due to the fact that it’s just a library rather than a full framework with coding conventions. Some aside projects try to make it more user friendly. One of the best known is the Chaplin project.

    Conclusion

    Backbone is one of the best libraries to help you build powerful applications. Even if its MVC implementation is somewhat unconventional, it’s a very good way to structure your code and being able to make your code base grow without too much trouble. Of course there are other libraries that do similar things such as Ember or Knockout. If you plan to work on a large application, you really should consider using one of them.

  5. Welcoming the new kid: Web Platform Docs

    Documenting the open Web and Web standards is a big job! As Mozillians, we’re well aware of this — documenting the open Web has been the mission of the Mozilla Developer Network for many years. Anything we can do to further the cause of a free and open Web is a worthwhile endeavor. With so many different groups involved in the design and development of new Web standards, it can be tricky to figure out the current right way to use them. That’s why we’re excited to be able to share this news with you.

    Introducing Web Platform Docs

    Mozilla, along with a group of major Web-related organizations convened by the World-Wide Web Consortium (W3C), has announced the start of Web Platform Docs (WPD), a new documentation site for Web standards documentation, which will be openly-licensed and community-maintained. The supporting organizations, known as the “stewards,” have contributed an initial batch of content to the site from their existing resources. The body of content is very much in an alpha state, as there is much work to be done to integrate, improve, and augment that content. to achieve the vision of WPD as a comprehensive and authoritative source for Web developer documentation. The stewards want to open the site for community participation as early as possible. With your help, WPD can achieve its vision being a comprehensive and authoritative source for Web developer documentation.

    Web Platform Docs has a similar goal to MDN: to help web developers improve their ability to make sites and applications using web standards. Mozilla welcomes this effort and joins with the other stewards in financially supporting the Web Platform Docs project, and in providing seed content for it. This new project is very much aligned with Mozilla’s mission to promote openness, innovation, and opportunity on the Web.

    What does this mean for MDN?

    MDN already provides a wealth of information for Web developers and for developers who use or contribute to Mozilla technology. That isn’t going to change. Some members of the MDN community, including both paid staff and volunteers, are actively involved with the Web Platform Docs project. Web Platform Docs incorporates some seed content from MDN, namely tutorial and guide content. Anyone is welcome to use MDN content under its Creative Commons Attribution-ShareAlike license (CC-BY-SA), whether on WPD or elsewhere.

    Licensing issues

    Licensing is where things get a little bit complicated. MDN and WPD use different contributor agreements and different licenses for reuse. By default, WPD contributors grant W3C the ability to relicense their original content under an open license (Creative Commons Attribution (CC-BY)). MDN content is licensed by the contributors under CC-BY-SA. The copyright belongs to the contributors, not to Mozilla, so we don’t have the right to change the license. Therefore, content that originates from MDN must be specially marked and attributed when it appears on WPD. If you create an account on WPD and create a new page, you’ll see that there is an option to indicate that the content you’re contributing came from MDN, and to provide the original URL on MDN. If you do copy MDN content (and we would be happy if you did so), we ask that you comply with the license requirements. There is also a way on WPD to mark sections of articles as coming from MDN, for cases where they get merged into CC-BY content.

    Get involved

    We encourage all Mozillians to visit the Web Platform Docs site, take a look, and get involved. By working with the other stewards to jointly build a complete, concise, and accurate suite of documentation of and for Web standards, we can help make the future of the World Wide Web brighter than ever!

  6. Push the Web Further at Hackanooga

    If you enjoy pushing the limits of the open web platform, we want you to join us September 14-16 in The Gig City (Chattanooga, Tennessee) for a weekend of good food, good friends, and—most importantly—a unique opportunity to play on a citywide, 1 gigabit per second network.

    What happens when you hack with WebGL, WebRTC, Websockets and video—the coolest, newest open web technologies—on a network 200 times faster than the typical residential internet connection? What kinds of apps become possible?

    Travel grants

    If you’re already sold, head on over and apply. We’re awarding a number of grants for you to hang and hack in the American south. Your flight, meals, and accommodation will be paid for. And you’ll leave having made something cool—something only possible on a gigabit network.

    Just take 5 minutes to fill out this form, and we’ll get back to you by August 21st.

    If you need some convincing, read on.

    No more constraints

    If you’ve ever written software for mobile or web, you know all about constraints.

    Sometimes those constraints are plain as day. You can’t do heavy computation on a mobile device, because they’re relatively slow and you’ll quickly drain the battery. Apps written for mobile should be lean.

    Sometimes the constraints are more implicit. They’re just baked into your understanding of how development works.

    In a web app, you have a client and server. The connectivity between client and server is scarce, so you want to minimize the data traveling across the network. You don’t want your users sitting around waiting for an app to load, or for a video to buffer. Apps written for web should be frugal with data transfer.

    But if all of your users are on fast networks—think 100Mbps to 1Gbps—these sorts of constraints start to matter less.

    On a superfast network, it doesn’t really matter where the data lives in the network. It can travel so fast that it’s virtually instantaneous. It can travel faster than your computer can write the data to your hard drive.

    On a superfast network, it also doesn’t matter where the computation happens. It’s already the case with cloud computing that the very computation-heavy tasks and storage take place remotely. Your computer is just a thin client to the network. Think about what that would mean on a gigabit network—your entire operating system, identity and filesystem could be rapidly accessed from anywhere on the network.

    Real-time crunching of very heavy data could happen anywhere on the network. Anything, really—could happen anywhere, on the network.

    Hacking for public benefit

    OK, so what? New paradigms are fun to think about, but none of this matters until it has an impact on real people.

    That’s what US Ignite is all about—showing what kinds of apps are only possible on gigabit networks. Demonstrating that if the U.S. becomes more competitive in broadband & networks, people will be happier, healthier and more well informed.

    On the ideas front, we have a massive brainstorm underway around the question of “what’s possible with gigabit networks.”

    And on the coding front, we’ve already held the first Ignite hack days in San Francisco, with some interesting results. Hackanooga is already gearing up to be a blast.

    How it will work

    We have room for 80 participants. This is not a spectator sport—everyone who attends must contribute to coding, designing, and testing real prototype applications.

    Between now and the event, we’ll work together to form teams around specific app ideas. We’ll try to pick app ideas on which we can make substantial progress over the course of the weekend. If you want to work on a specific type of problem, or a specific technology, let us know.

    We’ll prepare your team as much as possible, rounding up resources, shoring up expertise, and connecting you with local institutions as appropriate.

    When you arrive, you’ll meet the whole Hackanooga class of 2012; eat, drink and be merry. Then, we’ll get out of your way so you can make.

    You’ll have access to wired, 1Gbps connectivity, local cloud infrastructure, and lots of coffee. We’ll show off all the results at the end.

    Work from this weekend can evolve to become submissions in the Mozilla Ignite apps challenge, with nearly $500k in awards for your prototype apps. It’s a great way to meet team members & partner institutions to get a head start on the challenge.

    Apply now!

    We’ll be flying around 10 participants from all over to attend Hackanooga. If you’re interested, apply here!

    Not only is Chattanooga an awesome place to visit, but you’ll be charting a far-out future for the web, pushing today’s technologies on tomorrow’s networks.

    If you have any questions, shoot us an email at ignite AT mozillafoundation DOT org, and make sure to follow @mozillaignite for the latest news.

  7. HTML5 Web applications and libraries survey – first results

    At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

    In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

    We are now planning to talk to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we started a quick online survey asking developers about their tools for mobile development.

    We are happy to report that to date we have 480 answers and it is time to take a first stab at looking at the data.

    We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good first glimpse at what makes most sense for us to do.

    So without further ado, here are the raw numbers as charts:

    Platforms

    Not many surprises there, iOS and Android are in the lead, quite a lot of people see the web as a must-have (but this is a survey called out by Mozilla…) and Blackberry and Windows Mobile are not that hight on people’s radar.

    What platforms are you targeting with your apps – iOS
    focus 208 43%
    must have 168 35%
    supported 43 9%
    sometimes 24 5%
    not at all 36 8%
    What platforms are you targeting with your apps – Android
    focus 147 31%
    must have 183 38%
    supported 85 18%
    sometimes 33 7%
    not at all 31 6%
    What platforms are you targeting with your apps – Blackberry
    focus 5 1%
    must have 11 2%
    supported 83 17%
    sometimes 136 28%
    not at all 244 51%
    What platforms are you targeting with your apps – Web
    focus 306 64%
    must have 121 25%
    supported 26 5%
    sometimes 18 4%
    not at all 8 2%
    What platforms are you targeting with your apps – Windows phone
    focus 8 2%
    must have 36 8%
    supported 112 23%
    sometimes 137 29%
    not at all 186 39%

    Libraries

    jQuery rules supreme but Sencha touch and Zepto also have their place. Interestingly enough a lot of answers discarded libraries completely and considered them an overhead that will cause damage in the future.

    What libraries do you use to build mobile web apps/sites?
    jQuery 349 73%
    jQuery mobile 248 52%
    Zepto.js 90 19%
    JO 5 1%
    XUI.js 18 4%
    Sproutcore 7 1%
    Sencha touch 72 15%
    JQTouch 50 10%
    Mootools mobile 11 2%
    M project 1 0%
    Nimblekit 2 0%
    Lime.js 9 2%
    Wink 1 0%
    Uxebu Bikeshed 1 0%
    Other 126 26%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    Conversion frameworks

    You do love your PhoneGap / Cordova, it seems. There is not too much competition in this market and a lot of feedback was questioning the sense of converting apps as “building them natively makes more sense”.

    Which frameworks do you use to convert apps to native apps?
    PhoneGap 257 90%
    Appcellerator 45 16%
    MoSync 2 1%
    Other 31 11%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    Visual editors

    The space of visual editors seems to be not to frequented with this audience – would be interesting to see if there is already a mass market for WYSIWYG-like tools in the web app space.

    Do you use any visual tools/converters to build apps? If so, which?
    Adobe Edge 14 35%
    Sencha Animator 9 23%
    Other 18 45%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    Webkit only?

    71% of the audience saying they test on other browsers than webkit is making us happy of course, but seeing that a lot of the tools in use are webkit only makes that number questionable. Then again, we didn’t qualify what testing entices in this case.

    Do you test on non-Webkit browsers?
    Yes 340 71%
    No 139 29%

    Reasons to test for webkit only

    The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support.

    If no, can you tell us why?
    Fixed environment defined by client needs 36 23%
    Lack of time to support more browser platforms 85 54%
    Lack of incentive – I don’t know what the benefit of supporting more is 65 42%
    Lack of documentation how to install and debug on non-webkit browsers 39 25%
    Bugginess of other browsers on test platforms 24 15%
    Lack of support for other browsers on target hardware 55 35%
    Other 16 10%
    People may select more than one checkbox, so percentages may add up to more than 100%.

    More to come

    These are just the numbers right now. Soon we’ll be publishing also the free-form comments we got but for now this should get some discussion going and gives us a great start.

    And finally – a massive thank you for everybody who participated in this survey!

  8. The Web Developer Toolbox: Modernizr

    This is the third in a series of articles dedicated to useful libraries that all web developers should have in their toolbox. The intent is to show you what those libraries can do and help you to use them at their best. This third article is dedicated to the Modernizr library.

    Introduction

    Modernizer is a library originally written by Faruk Ateş.

    It is one of the key libraries for building cross-browser websites or applications in a modern fashion. The heart of the library is the web design pattern known as Progressive enhancement & Graceful degradation. This design pattern does not require Modernizr, but Modernizr can make things a lot easier. It detects the availability of native implementations for next-generation web technologies such as HTML5 or CSS3 and allow you to adapt your application accordingly, which is way better than trying some ugly voodoo user-agent sniffing.

    Basic usage

    Using this library is amazingly simple: Download it, link it to your pages—you’re done!

    Modernizr will automatically add some CSS classes to the root html element. For example if you want to test Web Sockets support, it will add a websockets class to the html element if the browser supports that feature, otherwise it will add the no-websockets class. It will do the same with JavaScript by adding a global variable Modernizr.websocket with a boolean value.

    Let’s see a simple example: Doing some stuff with RGBa colors.

    First: Download a customized version of Modernizr

    Modernizr, download page.

    Second: Link it to your document

    <!DOCTYPE html>
    <!--
    The "no-js" class is here as a fallback.
    If Modernizr is not running, you'll know
    something is wrong and you will be able to act
    accordingly. In contrast, if everything goes well,
    Modernizr will remove that special class.
    -->
    <html class="no-js">
    <head>
        <meta charset="utf-8">
        <title>I want to do stuff with RGBa</title>
        <script src="modernizr.js"></script>
    </head>
    <body>
    ...
    </body>
    </html>

    Third: Use it

    With CSS

    .rgba div {
        /* Do things with CSS for browsers that support RGBa colors */
    }
    
    .no-rgba div {
        /* Do things with CSS for browsers that DO NOT support RGBa colors */
    }

    With JavaScript

    if(Modernizr.rgba) {
        // Do things with JS for browsers that support RGBa colors
    } else {
        // Do things with JS for browsers that DO NOT support RGBa colors
    }

    Let’s see this silly example in action:

    Advanced usage

    The basic usage is already awesome when you have to deal with a heterogeneous environment (such as mobile browsers for example), but there’s more.

    Conditional loading

    Modernizr offers a convenient way to do conditional loading. Actually, the YepNope library is a standalone spin-off of the Modernizr project. So, if you wish, you can bundled YepNope directly inside Modernizr. It’s perfect if you want to load based polyfills depending on specific browser capacity.

    Modernizr.load({
        test: Modernizr.indexeddb,
        nope: "indexeddb-polyfill.js"
    });

    This is a very powerful tool: do not hesitate to read the documentation. Note that the Modernizr team maintain a list of very accurate polyfills. Feel free to use whatever you need (with caution, of course).

    Custom tests

    Modernizr come with a set of 44 tests for mainstream technologies. If you need to test some other technologies, Modernizr provide an API to build and plug your own tests.

    // Let's test the native JSON support ourselves
    Modernizr.addTest('json', function(){
        return window.JSON
            && window.JSON.parse
            && typeof window.JSON.parse === 'function'
            && window.JSON.stringify
            && typeof window.JSON.stringify === 'function';
    });
    

    Assuming the above test passes, there will be now a json class on the HTML element and Modernizr.json will be true. Otherwise, there will be a no-json class on the HTML element and Modernizr.json will be false.

    Dealing with CSS prefix

    CSS prefixes is a very sensitive subject. Modernizr provides cross-browser code to take care of this issue. Modernizr offers a very useful tool to deal with this: Modernizr.prefixed(). This method works with CSS properties (in the CSS OM camelCase style) as well as with DOM properties.

    For example, Modernizr.prefixed("transition") will return “MozTransition” with Firefox but “WebkitTransition” with Safari and Chrome.

    Testing media-queries

    There is currently no simple way to test a media query from JS in any browser. To help with that, Modernizr has a special tool: Modernizr.mq(). This method will test the media query of your choice and will return true or false accordingly.

    if(Modernizr.mq("screen and (max-width: 400px)")) {
        // Do some stuff for small screens
    }

    Limits and precautions

    This library is a fantastic tool but it’s not magic. You should use it with caution and do not forget about other techniques to deal with unpredictable behaviors. For example, do not forget to rely on the CSS cascade when it’s sufficient.

    The following example is a huge misuse of Modernizr:

    div {
        color : white;
    }
    
    .rgba div {
        background : rgba(0,0,0,.8);
    }
    
    .no-rgba div {
        background : #333;
    }

    If for some reason Modernizr is not executed, your text will not be readable (white text over a white background). In this specific case, you are better doing the following (which, by the way, is also easier to read and maintain):

    div {
        color : white;
        background : #333;
        background : rgba(0,0,0,.8);
    }

    So, don’t be blind when you use this library, take the time to think about what will happen if Modernizr is not available. In many case you have existing fallbacks, don’t forget to use them.

    Conclusion

    Modernizr is the most useful tool when you have to build large cross-browser stuff, from the oldest Internet Explorer 6 to the latest Firefox Nightly. Once you master it, you will be able to add some magic to your sites and applications. However, as with all the powerful tools, it takes some time to become comfortable with and to use it wisely at its full potential. But, Modernizr is definitely worth the effort.

  9. getUserMedia is ready to roll!

    We blogged about some of our WebRTC efforts back in April. Today we have an exciting update for you on that front: getUserMedia has landed on mozilla-central! This means you will be able to use the API on the latest Nightly versions of Firefox, and it will eventually make its way to a release build.

    getUserMedia is a DOM API that allows web pages to obtain video and audio input, for instance, from a webcam or microphone. We hope this will open the possibility of building a whole new class of web pages and applications. This DOM API is one component of the WebRTC project, which also includes APIs for peer-to-peer communication channels that will enable exchange of video steams, audio streams and arbitrary data.

    We’re still working on the PeerConnection API, but getUserMedia is a great first step in the progression towards full WebRTC support in Firefox! We’ve certainly come a long way since the first image from a webcam appeared on a web page via a DOM API. (Not to mention audio recording support in Jetpack before that.)

    We’ve implemented a prefixed version of the “Media Capture and Streams” standard being developed at the W3C. Not all portions of the specification have been implemented yet; most notably, we do not support the Constraints API (which allows the caller to request certain types of audio and video based on various parameters).

    We have also implemented a Mozilla specific extension to the API: the first argument to mozGetUserMedia is a dictionary that will also accept the property {picture: true} in addition to {video: true} or {audio: true}. The picture API is an experiment to see if there is interest in a dedicated mechanism to obtain a single picture from the user’s camera, without having to set up a video stream. This could be useful in a profile picture upload page, or a photo sharing application, for example.

    Without further ado, let’s start with a simple example! Make sure to create a pref named “media.navigator.enabled” and set it to true via about:config first. We’ve put the pref in place because we haven’t implemented a permissions model or any UI for prompting the user to authorize access to the camera or microphone. This release of the API is aimed at developers, and we’ll enable the pref by default after we have a permission model and UI that we’re happy with.

    There’s also a demo page where you can test the audio, video and picture capabilities of the API. Give it a whirl, and let us know what you think! We’re especially interested in feedback from the web developer community about the API and whether it will meet your use cases. You can leave comments on this post, or on the dev-media mailing list or newsgroup.

    We encourage you to get involved with the project – there’s a lot of information about our ongoing efforts on the project wiki page. Posting on the mailing list with your questions, comments and suggestions is great way to get started. We also hang out on the #media IRC channel, feel free to drop in for an informal chat.

    Happy hacking!

  10. The Web Developer Toolbox: ThreeJS

    This is the second of a series of articles dedicated to the useful libraries that all web developers should have in their toolbox. The intent is to show you what those libraries can do and help you to use them at their best. This second article is dedicated to the ThreeJS library.

    Introduction

    ThreeJS is a library originally written by Ricardo Cabello Miguel aka “Mr. Doob“.

    This library makes WebGL accessible to common human beings. WebGL is a powerful API to manipulate 3D environments. This web technology is standardized by the Kronos group and Firefox, Chrome and Opera now implement it as a 3D context for the HTML canvas tag. WebGL is basically a web version of another standard : OpenGL ES 2.0. As a consequence, this API is a “low level” API that require skills and knowledge beyond what web designers are used to. That’s where ThreeJS comes into play. ThreeJS gives web developers access to the power of WebGL without all the knowledge required by the underlying API.

    Basic usage

    The library has good documentation with many examples. You’ll notice that some parts of the documentation are not complete yet (feel free to help). However, the library and examples source code are very well structured, so do not hesitate to read the source.

    Even though ThreeJS simplifies many things, you still have to be comfortable with some basic 3D concepts. Basically, ThreeJS uses the following concepts:

    1. The scene: the place where all 3D objects will be placed and manipulated in a 3D space.
    2. The camera: a special 3D object that will define the rendering point of view as well as the type of spatial rendering (perspective or isometric)
    3. The renderer: the object in charge of using the scene and the camera to render your 3D image.

    Within the scene, you will have several 3D objects which can be of the following types:

    • A mesh: A mesh is an object made of a geometry (the shape of your object) and a material (its colors and texture)
    • A light point: A special object that defines a light source to highlight all your meshes.
    • A camera, as described above.

    The following example will draw a simple wireframe sphere inside an HTML element with the id “myPlanet”.

    /**
     * First, let's prepare some context
     */
    
    // The WIDTH of the scene to render
    var __WIDTH__  = 400,
    
    // The HEIGHT of the scene to render
        __HEIGHT__ = 400,
    
    // The angle of the camera that will show the scene
    // It is expressed in degrees
        __ANGLE__ = 45,
    
    // The shortest distance the camera can see
        __NEAR__  = 1,
    
    // The farthest distance the camera can see
        __FAR__   = 1000
    
    // The basic hue used to color our object
        __HUE__   = 0;
    
    /**
     * To render a 3D scene, ThreeJS needs 3 elements:
     * A scene where to put all the objects
     * A camera to manage the point of view
     * A renderer place to show the result
     */
    var scene  = new THREE.Scene(),
        camera = new THREE.PerspectiveCamera(__ANGLE__,
                                             __WIDTH__ / __HEIGHT__,
                                             __NEAR__,
                                             __FAR__),
        renderer = new THREE.WebGLRenderer();
    
    /**
     * Let's prepare the scene
     */
    
    // Add the camera to the scene
    scene.add(camera);
    
    // As all objects, the camera is put at the
    // 0,0,0 coordinate, let's pull it back a little
    camera.position.z = 300;
    
    // We need to define the size of the renderer
    renderer.setSize(__WIDTH__, __HEIGHT__);
    
    // Let's attach our rendering zone to our page
    document.getElementById("myPlanet").appendChild(renderer.domElement);
    
    /**
     * Now we are ready, we can start building our sphere
     * To do this, we need a mesh defined with:
     *  1. A geometry (a sphere)
     *  2. A material (a color that reacts to light)
     */
    var geometry, material, mesh;
    
    // First let's build our geometry
    //
    // There are other parameters, but you basically just
    // need to define the radius of the sphere and the
    // number of its vertical and horizontal divisions.
    //
    // The 2 last parameters determine the number of
    // vertices that will be produced: The more vertices you use,
    // the smoother the form; but it will be slower to render.
    // Make a wise choice to balance the two.
    geometry = new THREE.SphereGeometry( 100, 20, 20 );
    
    // Then, prepare our material
    var myMaterial = {
        wireframe : true,
        wireframeLinewidth : 2
    }
    
    // We just have to build the material now
    material = new THREE.MeshPhongMaterial( myMaterial );
    
    // Add some color to the material
    material.color.setHSV(__HUE__, 1, 1);
    
    // And we can build our the mesh
    mesh = new THREE.Mesh( geometry, material );
    
    // Let's add the mesh to the scene
    scene.add( mesh );
    
    /**
     * To be sure that we will see something,
     * we need to add some light to the scene
     */
    
    // Let's create a point light
    var pointLight = new THREE.PointLight(0xFFFFFF);
    
    // and set its position
    pointLight.position.x = -100;
    pointLight.position.y = 100;
    pointLight.position.z = 400;
    
    // Now, we can add it to the scene
    scene.add( pointLight );
    
    
    // And finally, it's time to see the result
    renderer.render( scene, camera );
    

    And if you want to animate it (for example, make the sphere spin), it’s this easy:

    function animate() {
        // beware, you'll maybe need a shim
        // to use requestAnimationFrame properly
        requestAnimationFrame( animate );
    
        // First, rotate the sphere
        mesh.rotation.y -= 0.003;
    
        // Then render the scene
        renderer.render( scene, camera );
    }
    
    animate();
    

    JSFiddle demo.

    Advanced usage

    Once you master the basics, ThreeJS provides you with some advanced tools.

    Rendering system

    As an abstraction layer, ThreeJS offer options to render a scene other than with WebGL. You can use the Canvas 2D API as well as SVG to perform your rendering. There is some difference between all these rendering contexts. The most obvious one is performance. Because WebGL is hardware accelerated, the rendering of complex scene is amazingly faster with it. On the other hand, because WebGL does not deal always well with anti-aliasing, the SVG or Canvas2D rendering can be better if you want to perform some cell-shading (cartoon-like) stuff. As a special advantage, SVG rendering gives you a full DOM tree of objects, which can be useful if you want access to those objects. It can have a high cost in term of performance (especially if you animate your scene), but it allows you to not rebuild a full retained mode graphic API.

    Mesh and particles

    ThreeJS is perfect for rendering on top of WebGL, but it is not an authoring tool. To model 3D objects, you have a choice of 3D software. Conveniently, ThreeJS is available with many scripts that make it easy to import meshes from several sources (Examples include: Blender, 3DSMax or the widely supported OBJ format).

    It’s also possible to easily deploy particle systems as well as using Fog, Matrix and custom shaders. ThreeJS also comes with a few pre-built materials: Basic, Face, Lambert, Normal, and Phong). A WebGL developer will be able to build his own on top of the library, which provide some really good helpers. Obviously, building such custom things requires really specific skills.

    Animating mesh

    If using requestAnimationFrame is the easiest way to animate a scene, ThreeJS provides a couple of useful tools to animate meshes individually: a full API to define how to animate a mesh and the ability to use “bones” to morph and change a mesh.

    Limits and precaution

    One of the biggest limitations of ThreeJS is related to WebGL. If you want to use it to render your scene, you are constrained by the limitations of this technology. You become hardware dependent. All browsers that claim to support WebGL have strong requirements in terms of hardware support. Some browsers will not render anything if they do not run with an appropriate hardware. The best way to avoid trouble is to use a library such as modernizr to switch between rendering systems based on each browser’s capabilities. However, take care when using non-WebGL rendering systems because they are limited (e.g. the Phong material is only supported in a WebGL context) and infinitely slower.

    In terms of browser support, ThreeJS supports all browsers that support WebGL, Canvas2D or SVG, which means: Firefox 3.6+, Chrome 9+, Opera 11+, Safari 5+ and even Internet Explorer 9+ if you do not use the WebGL rendering mode. If you want to rely on WebGL, the support is more limited: Firefox 4+, Chrome 9+, Opera 12+, Safari 5.1+ only. You can forget Internet Explorer (even the upcoming IE10) and almost all mobile browsers currently available.

    Conclusion

    ThreeJS drastically simplifies the process of producing 3D images directly in the browser. It gives the ability to do amazing visual effects with an easy to use API. By empowering you, it allow you to unleash your creativity.

    In conclusion, here are some cool usages of ThreeJS: