Blue Sky On Mars

Thoughts on Building Software Products

The Open Web App Prototype

by Kevin Dangoor

For some time, I’ve thought that many applications written as native applications for many different platforms could be done just as well as cross-platform web applications. I understand why people would make a unit conversion sort of application as a native iOS app, to give one example, but I’ve thought it’s a shame.

Some others within Mozilla gathered up a lot of opinions, put in a bunch of thought and then put together a prototype which they’ve announced today: Prototype of an Open Web App Ecosystem.

This is really cool. They’ve come up with a good solution that is truly open along every axis. Anyone can build apps and sell them through any channel (including their own!). This is the way apps should work.

Most “app store” designs lock people into a platform. It’s great to see an alternative ecosystem without the lock in.

UNIXy/VPSTree’s $0.99 VPS

by Kevin Dangoor

A $0.99 per month VPS?

Yes, it is here and ROCKING! For USD$0.99 per month, you can get your own virtual private server (VPS) for LIFE

Only 5GB disk space and 20GB of data transfer, but it’s $12 a year! Holy cow. Not sure how much you can stuff into 64MB of RAM, but I’d imagine you could fit a cute little node app in that.

blobastorus: free storage for client side JS apps

by Kevin Dangoor

blobastor.us is a free data storage service that is optimized for HTML5 web applications. The service is designed to be interfaced from javascript in the browser and to eliminate the need for a server component for most little HTML5 apps. Twitter is used to provide authentication and user identity.   

Lloyd amped up an idea that Atul put forth just a few days back. 20K per user per domain of free storage for JSON blobs. Basically zero effort to store a little bit of data for purely client driven apps. Makes serverless coding in the cloud seem a little more reasonable, no?

Generosity in Marketing and Open Source

by Kevin Dangoor

Seth Godin has written a number of times about being generous, most recently differentiating between “free samples” and “generous gifts”. Seth himself has given generously and benefitted handsomely. For one, just look at his great blog to which he has posted wonderful ideas, free for the taking. Another interesting example: recently, I received a copy of The Mesh:

Apparently, I received this book because I had bought Seth’s Linchpin. Which, by the way, I received by donating to the Acumen Fund and not giving the money directly to Seth. Oh, and I think they sent me two copies instead of one.

I’ve seen a lot of “internet marketing gurus” work the “free sample” angle that Seth is talking about. They give you an ebook for free, get you on their mailing list and then try to sell you lots of random internet marketing-related crap.

Seth undoubtedly knows that all of these things that he does get people talking about him and his ideas. Ultimately, he wins (Linchpin is currently in the top 800 sellers on Amazon, nearly a year after its release). But the way he approaches things feels generous. Donating to the Acumen Fund both made me feel generous and receiving the books in exchange made me feel like Seth was generous as well. How’s that for a promotion?

Over the past decade, I’ve read a good deal about marketing and I think that Seth Godin is the most positive force in marketing today. Read his books, read his blog.

In the title, I promised to relate all of this back to open source. One thing I love about open source software is the generosity that I see there. People make open source software for all sorts of reasons. Some people kick it off specifically to support a commercial venture – a variation of the “free sample” that Seth writes about. Others just sort of toss it over the wall as if to say “hey, I’ve got this thing, maybe you’ll find it useful…”.

But, I’ve also seen quite a few open source projects where people are just trying to make the world a better place through their software. They’re not just tossing it over the wall. Instead, they’re sending a prized creation into the world and continue to nurture and support it. That takes a lot of energy and work, and it often seems like a thankless task at the time. But, you know what? I think for a great many of those projects it actually works out okay in the end. In one form or another, the people behind many of these projects find their careers heading in new, unplanned directions as a result of the work they gave freely.

Brad’s Zoomy slide deck

by Kevin Dangoor

Brad Neuberg on his new HTML5 slide deck:

I’ve created a 3D slide deck that uses HTML5, CSS3, and a bit of SVG (video). The main idea behind this deck is to be able to ‘zoom’ into topics to as deep a level as necessary. Slides are nested, like an outline.

The last presentation I did was also HTML5, using dzslides. The ability to dive deep into topics or skip over is a really cool feature of Brad’s slides.

Breadcrumbs for Code

by Kevin Dangoor

Laurian Gridinoc has an interesting idea for navigating through code in an editor… make a stack of breadcrumbs at the top of the editing screen. Seems like an idea worth exploring.

Rust: Convenience, Speed and Safety

by Kevin Dangoor

From Patrick Walton’s introduction to Rust’s type inference:

Although Rust isn’t a scripting language, it’s designed to bring much of the convenience and readability of scripting languages (dare I say “agile development”?) to large-scale projects.

JSConf.eu 2010: a weekend of awesome

by Kevin Dangoor

Last year, I was disappointed to have to cancel my trip to JSConf.eu. This year, my luck was better, and I spent this past weekend in Berlin, along with two of my Mozilla Developer Tools colleagues, Joe Walker and Patrick Walton. Mozilla was out in force at the conference. Axel Hecht, who has been incredibly helpful bringing my team up to speed with localization, was in attendance. Oh yeah, and that guy from A Minute With Brendan was there. More seriously, I appreciated getting some good feedback from Brendan regarding where we’re heading with developer tools.

The conference organizers for JSConf.eu are fantastic, and I’ve got to thank Anja and Jan in particular for being exceedingly helpful. Jan even got us set up at co.up, which is a really nice coworking space that was easily reachible from our hotel.

You’re probably wondering if I’m just going to blather on about people… What about the conference? Seriously, the talking to people is what a conference is all about. The talks are great, but the hallway track is also fantastic in a small conference of enthusiastic people like JSConf.

JSConf is one of those conferences where you feel like everyone around is smarter than you are but, thankfully, also approachable, friendly and wanting to share.

Among JSConf goers, at least, the presence of Node is huge now. Even Peter Higgins was forced to mention Node in his talk after saying he wasn’t going to. There were several talks that presented solutions to the callback craziness that is a natural side effect of async programming in JS today. Jed Schmidt‘s (fab) talk was really entertaining and nicely done, though I fear that misplaced parens would lead to hard to debug problems. Tim Caswell‘s Step library looks like a more straightforward solution to the problem.

By the way, apparently Python 2.5-style generators have a decent shot at appearing in a future ECMAScript spec. These can provide a nice solution for making async code look synchronous without bad side effects.

Brendan’s talk about Proxy Objects (an ECMAScript Harmony spec that is already implemented and widely used within Firefox) was enlightening. This is an absolutely fantastic new feature. As a long time Python programmer, I’ve missed a number of Python’s features for altering the behavior of objects (all of those “__” methods). Proxy Objects will bring this to JavaScript in a fashion that is way more powerful than the getters/setters support we have an ECMAScript 5 and it does so without forcing objects to have specially named methods. Very clean and nicely done.

Funny story: Saturday morning, Joe, Patrick and I were talking about the feasibility of making a fast, DOM-based code editing component, and whether that would help with accessibility. Later that day, Fabian Jakobs showed off ACE, which is indeed a fast, DOM-based code editor. His presentation, which was overall nicely done, had a factual error about Mozilla Skywriter. He stated that Skywriter would be slow for a big canvas because it has to redraw every pixel for each character typed, which is rubbish. Skywriter does a saner job of painting than that… That said, his demo was very cool and their server has a lot in common with the server that we’re planning for Skywriter. Fabian and I agreed that it would be great to find ways for our projects to work together.

On Sunday, I spoke with Nick from Shopify who has also been working on code editing sorts of problems. He ended up with the Canvas approach rather than DOM DOM approach to editing also and his editor even uses Skywriter syntax highlighters. Nice!

As for Skywriter, I think our talk went reasonably well, albeit with a couple of technical glitches. My computer randomly decided to go to sleep early in the talk (huh?). After we got past that, we talked about how Skywriter is different from the original Bespin project and showed off the Bookmarklet and Embedded uses of Skywriter. We did a live coding portion of the talk in which we created a Skywriter plugin on the fly (a live version of a tutorial I wrote in June). We altered the script just before the talk to save a little typing by dropping the third parameter to window.open. It turns out that dropping the third parameter to window.open (at least in Firefox nightlies) results in a new window that doesn’t have a document body. Oops. Looks like a bug we need to report, or something. Pro Tip: don’t alter your live coding script by even a byte just before your talk!

I finally understand from Kris Kowal‘s talk why Q.when is sometimes nicer than promise.then() (you can treat synchronous and asynchronous calls the same way), but I still think that promise.then is a fine way to go for many cases.

The conference venue was neat and very different from the typical US conference venue. Overall, the conference was simply great. The after parties were fun. My group also had a good chance to have some wide ranging discussions and work through some designs for Skywriter.

I’ll finish my wrap up of JSConf.eu with a note about the final talk: Chris Williams‘ Community.js talk. Chris and his wife Laura organized the two JSConf.us conferences, superbly I should add. Chris showed his more serious side, encouraging the JavaScript community to:

1. show respect for other languages as well, since most of us started with others
2. not to become JS fanbois
3. to fix the fact that Google searches for things like “javascript”, “learn javascript” and “javascript array” take you to pages that aren’t so great

For this last one, he’s set up a page at promotejs.com that encourages links to boost the Mozilla Developer Network (formerly Mozilla Developer Center) site. Apparently, there are still quite a few people who haven’t encountered MDC, which has a huge amount of very clearly written documentation for JavaScript, CSS and the browser environment. I do know many who google things like “mdc array” instead of “javascript array“, but ultimately, reclaiming those keywords is a worthy goal.

JavaScript is a powerful, general purpose, dynamic programming language with several very fast, compatible, cross-platform implementations and a runtime that is already in the hands of more than 1.5 billion people. JSConf is the best conference around for those who appreciate JS for what it is.

Introducing the Web Console

by Kevin Dangoor

David Dahl has been leading the work on Firefox 4′s Web Console feature and has blogged about the work along the way. Over the past month, we’ve landed a whole bunch of improvements to the Web Console in Firefox 4 Beta, and I wanted to give my take on what the Web Console has to offer for web developers.

What is the Web Console?

I first learned to program a computer in BASIC on a TRS-80 Model III. I’m dating myself there, but oh well. Believe it or not, my first programs didn’t always work the way I intended them to and, surprisingly enough, they still don’t. I had two main tools to help me figure out what was going on: a “read eval print loop” (REPL) and “print”. Using the REPL, I could type in simple statements and get immediate results, as a way of testing that how I think an individual operation should work is actually how it does work. Using “print”, I could have my program display certain values along the way so that I could make sure that they met my expectations while the program was running.

Even today, REPL and print continue to be two simple and fundamental tools for learning how a system works and troubleshooting problems. The Web Console gives you these two features for web pages that appear in Firefox.

The Web Console atop a popular website

You can see the Web Console for yourself today by downloading the Firefox 4 beta.

The Log

When you open the Web Console from Firefox’s Tools menu (or using the ctrl-shift-K/cmd-shift-K keyboard shortcut), you’ll see a panel drop down from the top of the content area of the browser. In the current Firefox 4 beta release, the panel is empty when it first opens, but the Firefox 4 final release will collect up logging messages even while the console is closed.

If you open the Web Console and then go to a page, you’ll see a whole bunch of output. Typically, there will be many “Network” requests listed. Sometimes, you’ll see CSS or JavaScript errors displayed. It doesn’t take long for that output to quickly become overwhelming, so we’ve got a simple solution in place to deal with that: filtering. Just above the log output area, there are a number of controls that you can use to pare down the output and see just what you need to see.

  • The Net, CSS and JS controls determine which of those types of messages from the browser should appear in the output.
  • The Errors, Warnings, Info and Log controls determine which JavaScript-generated messages should appear in the output window (see “The console Object” below
  • Finally, there’s a search box to filter the output based on whatever you type there

Using these controls, you should be able to quickly zero in on the messages that will help you debug a problem with your page.

Network Details

The “Network” requests that appear in the log output show you the URL to which the request was made. But what do you do if your JavaScript made a request to the right URL, but the data that came back isn’t what you expected? If you click on a network log entry in the next beta of Firefox 4, you’ll get a panel with a bunch of details about the request:

The network request details panel.

With the request and response headers and body and the cookies from the request, you can dive deep into the requests made from your web pages.

The console Object

If you’ve used the excellent Firebug extension (more on Firebug below), you’ve quite possibly encountered its “console” object that is available to JavaScript. console provides a number of useful methods, including a set used for logging information: log, info, warn, error. All four methods work the same way and represent different levels of information logged from log as the lowest level to error as the highest. You can pass in multiple arguments and they will have their string representations glued together for the output. For example, if the variable food is “avocado”, then console.log(“My favorite food is”, food, “and its info is”, anObject) will output “My favorite food is avocado and its info is [object Object]“.

By strategically using the different logging levels, you can make it easy to focus on just the messages that matter to you using the filter controls.

One more note: for Firefox 4, we’re playing it conservatively with the console object. If one is already defined on the page, we won’t override it. As of this writing, there is a bug that prevents the console from working properly on sites that define their own console object, but you can bet we’ll have that bug resolved soon.

The JavaScript REPL

Read Eval Print Loops are fantastic for figuring out how a language or environment works and for testing things quickly. The Web Console features a REPL for JavaScript that gives you access to everything on your page. For every expression you type in, the Web Console will automatically output the result of that expression. That means you can use it as a simple calculator:

6*7=42, but you knew that

For your convenience, the Web Console will automatically try to fill in variable and function names that it knows about:

Automatic completion

By using the up and down arrow keys, you can also cycle through the history of commands that you’ve entered.

You can directly access variables that are on the page:

Here we see that jQuery is on the Reddit home page.

Note that variables that you define in the Web Console are not automatically exposed to the page. If you would like to change a variable on the page, you just need to put “window.” in front of the variable name. For example, if you enter the expression “window.foo = 1″, then the variable “foo” on the page will change to 1.

With access to jQuery and knowledge that Reddit has an element on the page with an id of “header”, it becomes a simple matter to remove the header from the page we’re looking at:

Reddit with the header hidden

One more note about using the REPL: if your expression returns an object, the console will just show [object Object] currently. However, you can click on [object Object] and see the object inspector:

The object inspector looking at a jQuery node list

One nice feature of the object inspector is that it shows you a snapshot in time of the object. You can click the “Update” button if you want to see the current contents of the object.

Firebug

The Firebug add-on has millions of users and has been making web development easier for years. If you’re one of those users, you’re probably wondering why the Web Console exists when Firebug already provides a console and much, much more. Back at the beginning of this post, I talked about how useful a REPL and print are in debugging, experimentation and learning. These things are so fundamental that we wanted them to exist in Firefox with no add-ons required.

Consider this case: you’re a web developer and you have a distant user of your application. They’re running into a problem with your app. They can tell you what’s on the screen, but they have no way of sharing a view of what the application has done to that point. If you have useful logging messages in your app, you can ask the user to copy the console output into an email message and send it to you, all without requiring them to install an add-on.

The Web Console is not a replacement for Firebug, but it will be a great tool to have in a pinch.

What’s Next for the Web Console?

We’re still in the middle of the Firefox 4 beta test cycle, so you can expect to see additional improvements and polish as the beta progresses and we head to the release of Firefox 4. If you’d like to get involved and help make the Firefox developer tools beyond awesome, talk to us! Discussion about the Firefox developer tools comes on the dev-apps-firefox mailing list/newsgroup and in realtime in the #devtools channel on irc.mozilla.org. I’m also happy to receive feedback by email.

Mozilla DevTools coming out of hiding

by Kevin Dangoor

OK, we weren’t actually hiding, but we have been spending a lot of time learning, coding and figuring things out. We’ve been so busy creating things that we haven’t had much time to talk about the things we’ve been creating.

A little more than a month ago, I announced here that Mozilla officially has a Developer Tools group again, with tooling for both Firefox and the open web in general in our sights. Much of our group is new to Firefox development, and so the past few weeks have been quite an education in the processes used to ship a feature-filled, open source, stable browser to 400 million+ people. And that’s just the process. There’s the technology, too, and the Bespin team had to learn a lot there as well. The people who have been working on Firefox for a long time have been great mentors in getting us up to speed.

Now that we’re getting an idea of what the developer tools in Firefox 4 look like, the devtools team is going to be a lot more public about what we’re doing and invite the community to join in and help us make tools that make the web a better place. Keep on eye on Planet Mozilla or dev-apps-firefox (newsgroup/mailing list) in the coming weeks to learn more about what we’re up to and where we’re going next.

Also, one more word about Firefox 4 dev tools: Firebug 1.6b1 is out and is awesome. If you’re a web developer using Firefox 4 beta, you should definitely check it out.