Page 3 of 251

Seen on Mars #1

Back in control

Recently, I’ve seen a fair number of articles where people are complaining about having the data under the control of one for-profit entity or another. That tension will always be there. One thing I can control, though, is this blog. With better software than I’ve had in the past, I hope to maintain my interesting sets of links (with commentary) on my blog in addition to Twitter and G+.

Software Development

The new Montage framework from Motorola Mobility has some awesome ideas in it. Ars Technica has posted an introduction by the framework’s creators. The article also talks about Ninja and Screening, which are visual tools for building and testing Montage apps.

The Google Summer of Code project to build a graphical event timeline for Firefox is progressing nicely indeed. You can download the add-on now.

Parashuram Narasimhan shows us how we can get going with IndexedDB today on browsers that don’t support it using IndexedDB polyfills.

Metaquery is an interesting approach to breakpoints in web design. Of course, not everyone thinks breakpoints are the right approach, but this is still an interesting library.

Firefox add-ons have been downloaded 3 billion times now. Firebug has nearly 50 million downloads. And those figures are from addons.mozilla.org alone. I know for certain that a significant number of Firebug downloads have come straight from the Firebug site.

Speaking of Firebug, did you know that you can set conditional breakpoints not only for JavaScript but for XHR and even cookies as well?

Lea Verou has introduced Prism, the new JavaScript syntax highlighting library that she extracted from her Dabblet project.

WeasyPrint converts HTML/CSS (including print styles) to beautiful PDFs (well, assuming your original HTML/CSS was beautiful!). Unlike PrinceXML, WeasyPrint is free (BSD-licensed).

How to make a game like Cut the Rope. I wonder if a tutorial like this exists for the web? I enjoy Cut the Rope, personally.

Other tech

Ed Bott finds Microsoft’s new strategy laid out in MSFT’s 10-K. This is a bold shift for Microsoft. It’s hard to imagine Microsoft as the underdog, but to some extent that’s the position they find themselves in.

Mac

Better Mac OS defaults for geeks that I will likely not use all of, but there are a bunch of useful settings in here.

 

The Two-Way Conference (MozCamp and more)


A week ago, I had the good fortune of attending and speaking at MozCamp Latin America in Buenos Aires, Argentina. I really enjoyed meeting a whole bunch of new people and appreciated the chance to talk about the Firefox developer tools shipping today and in the near future. The organizers clearly put a lot of effort into getting this conference together (thanks!)

This MozCamp was filled with excitement about B2G and the many other initiatives Mozilla has going on. Beyond the product building we’re doing, there was a lot of energy and enthusiasm for growing the Mozilla community and building on the ideals that Mozilla stands for.

During MozCamp, I spoke with a few people about conferences in general. I think there’s a lot of room to make MozCamp and other conferences better than what we’re used to. These ideas are not new and didn’t originate with me, but they’re worth repeating.

The Format Today

MozCamp was structured like most other conferences that I’ve been to: a packed schedule with multiple tracks of presentations. You get interesting people presenting on useful topics. That’s not a bad thing, but I think it can be better.

If I’m going to deal with the hassle of air travel and spend days away from my family, I’d like to get the most I can out of that time.

A typical presentation slot is 30, 45 or 60 minutes. Of that, there’s maybe 10 minutes of questions and the rest is an “eyes-forward” presentation. I don’t think this is the best use of time. The unique thing about MozCamp (or any conference, for that matter), is that I’m physically there with the other people. The communications bandwidth is much higher. To use that bandwidth for one-way communication seems suboptimal.

There were other issues that I noticed as well:

  1. Attendees at MozCamp had varying levels of English proficiency. This can make it hard for some to keep up with eyes-forward presentations from native English speakers. Plus, a whole day of constantly translating in your mind can get tiring… by the time the second day rolls around (after a possibly late night followed by soccer in the morning!), I would imagine that keeping focused would be difficult.
  2. No slack time for checking email and having hallway conversations. The schedule was packed, leaving mealtime and snack time as the only times to talk (short of skipping sessions). Some of the evening activities suffered from high noise levels as well, eliminating that chance to talk easily.
  3. No slack time also causes issues with schedule slip.. On Sunday, the Q&A session threw the rest of the day off by 30 minutes. That’s not surprising, since it was an interesting two-way communication sort of session… but it meant that the rest of the schedule needed to be pushed by half an hour and never got back on track (causing some sessions at the end of the day to be dropped).

The Two-Way Conference

I think conferences, including MozCamp, should try to become more “two-way”. One formula for a session could go something like this:

  • “speakers” are more like “hosts” or “invited experts”.
  • The expert prepares a page with links to background material and probably a presentation. This page should be available a couple weeks in advance of the event
  • That page can also include some suggestions for areas that could benefit from discussion.
  • That page could also have an etherpad or wiki associated with it to collect more ideas in advance (as attendees view the material).
  • At the beginning of the session, the expert provides a lightning talk-sized intro and, possibly with the help of a facilitator, gets people organized to usefully talk about things or work on something

A parallel is the recent talk of “flipping the classroom”. The students watch a video outside of class and then use class time to work together or get help from the teacher.

Wouldn’t it be awesome if, instead of 50 minutes of eyes-forward presentation followed by questions, we had 5-10 minutes of organizing, level-setting and topic choosing, followed by 50 minutes of two-way communication?

Some unconferences go so far as to not even have predefined topics and time slots. I’m not going that far. I think that a little bit of structure with some constraints on time can help make the most of the time. Additionally, I have heard from some conference organizers that you can’t even get some companies to sponsor sending people to a conference without presentations from industry experts.

Boriss had a user experience workshop that followed a good format: she did a few minutes of intro followed by demonstrations of applying her UX research suggestions to projects that people were working on. William Reynolds told me that he also ran a workshop session on the topic of getting people involved with Mozilla. Individuals can take matters into their own hands this way, and I wish I had done so myself (there’s always a next time!). I’d like to see conferences that encourage and support this even more.

How can this format help with the problems I talked about?

  1. the sessions spend most of their time in a two-way exchange between the “expert” and the participants, thus making better use of the bandwidth
  2. when communication is two-way, there’s more opportunity to overcome language issues than when you have a presenter following a predefined outline. In fact, sessions that involve group discussion could possibly take place in the group’s native language. (Of course, if everyone involved speaks the same language, then there’s no problem. Some of the MozCamp sessions were held in Spanish… of course, that left me, and some of the Brazilians, out.)
  3. More of the stuff that might get discussed on the “hallway track” can now get discussed by more people during sessions
  4. Ideally, there would be a bit more buffer time to handle schedule slippage and sessions that are so good that people just don’t want to stop

I still find conferences valuable and will continue to attend them, but I think we can do better.

When to Build Performance Measurement Tools for Firefox

We’re well on our way to having a full-featured set of tools for web developers that ship with every release of Firefox, in addition to the already great Firebug add-on. In our roadmap, I talk about building “bundled tools for the most common tasks”. Lately, people have been asking me about tools to help web developers improve the performance of their applications.

Firefox is very fast. In fact, Firefox and its competitors are so fast that most web developers only care about one aspect of web application performance: network access. Latency and the amount of data transferred are the biggest issues for most web developers. We’ll be working on providing insight into network access soon in Firefox.

Developers working on three sorts of web applications in particular are asking for deeper insight into what the platform is doing:

  • games
  • complex layouts involving large amounts of data
  • applications that have features you’d traditionally associate with “desktop applications”

Each browser has different performance characteristics, and these developers need tools that give them hints on how to make their apps responsive on each browser. They care about things like garbage collection pauses, repaints and reflows and hot spots in their JavaScript code where the just-in-time compilers aren’t able to make the JS zoom.

Most web developers aren’t working on these kinds of apps, and we’re focused on building tools that are useful for the “most common tasks”. However, we want these kinds of applications to run well on Firefox. Firefox developer tools really serve two groups: the web developers who use the tools directly, and the hundreds of millions of Firefox users who are looking to experience the web in the best way possible.

I think that our focus needs to remain on building the best tools for the most common tasks. But we also need to accommodate these sophisticated developers. Fortunately, we have more options than just “build it” or “don’t”.

For a feature to ship in Firefox, it goes through a lot of work to ensure that the feature is of a quality that is ready to ship to many millions of people and in many languages. The developers building these performance intensive apps do not number in the millions, and they are capable of installing add-ons. Some are even willing to produce their own custom builds of Firefox, if that’s what it takes to get the performance data they want.

In my opinion, that’s the planning lever we need to pull here. We can try to get these developers the data they need, albeit in a rough form, in add-ons as soon as possible. Along those lines, Brian Hackett has made his JIT Inspector tool available as an add-on.

If you need help figuring out performance issues with your application in Firefox, get in touch.

Thinking About the Developer Experience for the Web

I’ve been working on developer tools for a while now, and I’m really proud of what we are shipping in Firefox today and the new features that are right around the corner. Browser tools are one of the most important parts of a web developer’s toolbox.

But, there’s a lot more that goes into web development than the browser tools. The video above and the text that follows are some thoughts on the whole of the web developer’s experience.

Web development is great because the platform is so high level and dynamic. That makes it easy to get started. There’s a massive collection of libraries, tools, books, tutorials and more to help web developers get things done once they’ve moved beyond the first steps. In fact, there’s so much out there that it can be hard for someone getting going to decide how to go from idea to done. The riches of the web ecosystem are both a blessing and a curse. It’s more blessing than curse, but that doesn’t make it any easier for newcomers and, in some instances, for experienced developers that are moving into a new area or applying a new technology.

Mozilla’s non-profit mission is to protect openness and innovation on the web. We want to make the web better for everyone, and I think we’re in a good position to help guide developers from idea to published app. Doing so is especially critical for our Apps initiative.

To that end, Daniel Buchner and I will be looking beyond developer tools in our product plans to include the whole of the developer experience. This will first show up in an Apps context, but we’re going to look for ways to apply what we do more broadly.

Firefox 2012 Roadmap for Developer Tools

Firefox in 2012

This week, the Firefox 2012 Roadmaps went live. Mozilla has a lot going on and huge goals for 2012. We have a lot to do and the web will be in a better place as a result.

Developer Tools in 2012

It’s been two months since I posted the 2012 developer tools roadmap. I thought that the new attention on the larger Firefox roadmap gives me a good opportunity to reflect on where developer tools is now and what’s coming in this year.

I want to start by saying that I think the Firefox developer tools team is doing amazing work. They’re shipping big features, great refinements and handling the growth of the community well.

This year, we’re filling in a new set of bundled tools for the most common web development tasks. Two weeks ago, we had our first big release of the year. I’ve been watching the feedback in various channels and it has been overwhelmingly positive. People have seen that we’re offering:

  • Streamlined user interfaces on…
  • Fast and well-tested tools that…
  • Meet the common needs in new and better ways

I really appreciate all of the constructive criticism we’ve gotten. Ryan DeBeasi wrote in “New Developer Tools in Firefox 10 and 11” for Web Designer Depot:

There’s no user agent switcher, no “edit as HTML feature,” no performance-testing tools, no way to inject new tags into a page, no way to activate an element’s hover state. There’s not even a “layout” panel for viewing the dimensions, padding, and margins of your element.

Despite all those limitations, I keep coming back to the Page and Style Inspectors. I come back for the uncluttered interface, the thoughtfully placed panes, and that funky purple chrome. I come back because they’re a pleasure to use, and because they meet my needs most of the time.

Yep! That’s all true. And Tyler Herman’s recent Impression of Firefox’s New Developer Tools offered similar sorts of feedback. Those two articles are representative of much of the reaction I’ve seen surrounding Firefox 10’s release.

We’re happy that you think we’re off to a good start. We know we’ve got more work to do, and we’re listening. In the coming months, watch for new tools and improvements to the ones we’ve shipped.

Along those lines, a huge chunk of work for the new JavaScript debugger has recently made it into Nightly. It needs some more work before it’s usable and shippable, but the debugger is coming. As Panos mentions in that blog post, this debugger builds on entirely new infrastructure. More on that in a moment.

Mobile

Mobile is huge in Mozilla’s roadmap for 2012. We’re working to ship a new Firefox for Android with a screaming fast native UI. The Boot2Gecko project is working on an entirely new mobile phone OS that is truly open source from top to bottom and from the very beginning of the project. Plus, B2G is open web all the way.

Our focus in developer tools is on tools that live in the desktop browser for the common web development cases. That doesn’t mean we’re not thinking about mobile. We don’t think that people want to do mobile phone development on their mobile phones, hence the need for great desktop tools. Tablets are another story, but we still think that desktop OSes will rule development for some time to come.

The new debugger that I mentioned is built around a client/server architecture. In other words, an app running on in Firefox for Android could be debugged by a desktop Firefox browser. There are infrastructure changes underway in the Web Console that will help make remote access possible in the Web Console as well. We need to do non-trivial user interface work to expose this kind of feature, but the technical underpinnings are falling into place.

There’s another option that works especially well for Firefox: making the desktop browser pretend to be a mobile device. Firefox on the desktop and Firefox for Android generally follow the same release schedules and rely on the same rendering engine, which means that the desktop should be able to behave quite closely to the way the mobile device does. Again, there’s work to be done before we can ship this and that work depends on us having our core desktop tools fleshed out.

Apps and Add-ons

From the perspective of the code a developer creates, Mozilla’s “Apps” initiative is not all that different from standard web development. Apps use the latest web specs and have a little bit of wrapping around them. But, Mozilla is working to build a whole bunch of infrastructure around Apps to make the end-to-end user experience fantastic.

The tools that we’re building for web developers should be immediately applicable to Apps. Beyond those tools, though, providing the best possible end-to-end developer experience for Apps developers is something we’d like to pursue.

Similarly, Firefox Add-ons built with the Add-on SDK are mostly built from the same kinds of technology web apps are built. Ideally, the tools that developers can use for the web could also be applied for Add-ons.

Daniel Buchner now reports to me as the product manager for Apps and Add-ons Developer Tools. He’ll be helping to identify the best opportunities we have in these areas.

Firebug

I also wanted to give a shoutout to the splendid work coming out from the Firebug team. Firebug 1.10 (currently in alpha) is going to be the first ever restartless version of Firebug. The code organization changes that they’re making will make Firebug an even easier project to contribute to than it has been in the past. And, of course, new user-facing features are part of 1.10 as well.

Many ways to get involved

Everything we do at Mozilla is open source and for the betterment of the web. Those of us working on developer tools at Mozilla want to make web development easier and more fun. You can help in a variety of ways:

I hope you enjoy the new tools in Firefox 10 and beyond. They’re just the beginning of what we have planned for 2012.

Firefox Developer Tools Input Summary Jan 26

Lots of Feedback

Firefox Aurora has a fairly small audience, but it represents a good time to start collecting feedback on new features. Firefox Beta has a much larger audience. Both Aurora and Beta have a handy “Feedback” button in the toolbar, and I thought that now was a good time to dive into that feedback since we’re reaching the end of the Firefox 10 beta cycle. Firefox 10 is a big deal, because it adds the Page Inspector and related tools for web developers.

In this post, I’m focused on the input that we’ve received from the Feedback button. We get input from many other sources as well:

  1. user studies
  2. blog comments
  3. Twitter/G+/Facebook (mostly Twitter)
  4. Google Alerts (blog postings, press articles)
  5. Bugzilla
  6. dev-apps-firefox
  7. irc.mozilla.org #devtools
  8. surveys
  9. and, of course, the Feedback button input from Aurora and Beta users

I’m probably forgetting some input channels.

Those of us working on Firefox developer tools have ideas of what we (as developers ourselves) would like to see in the tools. Hearing from other web developers goes a long way toward making sure that we’re doing the right things to make tools that work well for many people.

Keep the input coming!

Summary of Input

The entries from the Firefox Feedback button are collected and searchable at input.mozilla.com. I went through the input for a variety of searches going back to mid-December to get an idea of what the sentiment was like.

During that time, I counted 63 positive feedback entries for our new built-in tools and 22 negative entries. That’s 74% positive. Across Firefox as a whole, most people (between 55-65% over the past month) who hit the Feedback button did so because they found some aspect of Firefox they didn’t like. People are going out of their way to say that they like the new tools, and that’s fantastic.

Firebug has its own feedback channels (a mailing list, bug tracker, etc.), but we get some input about Firebug via the feedback button. I saw 36 positive and 22 negative entries, which is a 62% positive rate. Again, this rate is much better than the overall and the sentiment that I’ve seen toward Firebug in other channels has been super positive.

More interesting information comes up when you look at some of the specific feedback…

Recurring comments about Firebug

Of the 22 negative comments about Firebug, 10 were about Firebug crashing, or the browser crashing in conjunction with Firebug. People working on Firefox and Firebug take crashes seriously, so I hope that people file bug reports or ask for help for these kinds of problems. It turns out that there is a known crashing problem that is fixed in Firefox 10 (due on Tuesday). Let’s see how these numbers shift after 10 is released.

Five comments about Firebug reported a problem getting Firebug to run on the user’s version of Firefox. I find this a bit unexpected, because Firebug has broad compatibility these days. See the listing at the top of this blog post about Firebug 1.9. If I had to guess, I’d say that this problem is because some people did not get their copy of Firebug from addons.mozilla.org. Hopefully, the number of people getting Firebug elsewhere (getfirebug.com) has been dropping. Firefox Nightly users need to get Firebug from getfirebug.com, but those of us running Nightly generally know the risks we’re taking, right?

All of that said, the majority of comments about Firebug were along the lines of “I love Firefox because of Firebug”. Some of them were marked as praise with the simple comment “Firebug”.

Recurring comments about the Firefox Developer Tools

Three people stated that the tools should live in add-ons because the user is concerned about memory bloat and speed. On this point, it’s worth noting that every commit to the mozilla-central repository (from which Firefox is built) is checked for memory usage and speed. The tools we’re adding to Firefox do not negatively impact Firefox’s memory use and speed.

On the flip side, six people stated that they like having the tools built-in.

Three people said that they don’t think we should be duplicating Firebug. I’ve written about this already, so I wont rehash it here.

Four people want a “layout view” that shows margins, padding, etc. for an element. Those people are in luck! We’ve got a patch in progress.

Quotes like “THE NEW DEVELOPER ELEMENT INSPECTOR IS SO SLICK!!!” and “3d Web Developer Layering. (Ctrl + Shift + I) This is SO helpful!” reflect a lot of the sentiment in the positive feedback.

Thanks, and I’m looking forward to more!

The release of Firefox 10 and new notices for Aurora and Beta users will likely net us more feedback in the coming weeks. We’ll be listening!

I’ll close with this tweet from Brian Blakely:

“Perhaps the next-generation webdev IDE will be a browser. Somewhat related, FF’s dev tools are really coming along”

Future Firefox Developer Tools Updates Nov 17

Information Gathering and Organizing

Since my last update, I had some back-to-back busy-ness. First, I was prepping and presenting at the 1DevDay Detroit conference. I spoke about a number of web developer tools there.

That was followed by a work week in San Francisco and Mountain View. Mozilla’s product team is working on the product roadmaps for 2012. You should start seeing drafts coming out for review and comment soon.

I also did three more user interviews. These have been very interesting, and will undoubtedly improve our product plans. I’ve also heard about some other user research going on at Mozilla around app development that may have some interesting information for developer tools as well. Once I figure out the best way to package up the research we’ve been doing, I’ll get it posted.

Aurora 10

The most exciting news is the release of a new Aurora build last week. Five of our feature pages landed for Firefox 10. You can find a more coherent version of what’s exciting about Firefox 10 (due January 31, 2012) in this Mozilla Hacks article that I posted yesterday.

New Feature Pages

Consistently, the users I’ve interviewed use the console, CSS tools and network request timeline the most. We have other data that shows a great many users also use the debugger features of web development tools. We now have a console, CSS tools and a debugger in the works. That leaves a network timeline, for which we’re figuring out scope and a plan.

In the meantime, I added feature pages to cover a couple of things that didn’t make it into Firefox 10. The enhanced property views page is about making the way CSS properties are displayed and edited in the Style Inspector even better.

The Layout In Highlighter page is for adding a feature that web developers find useful in other tools: being able to see margins and padding around an element right around the element itself on the page.

I had created a page to track against our plans for multi-process (“electrolysis”) Firefox. The engineering team has decided to take other approaches to improve Firefox’s responsiveness, which means that we don’t need to tackle multi-process rearchitecture work right now.

A Comment on the Feature Page System

Something that has felt a little awkward to me about our feature pages system is that improvements (like the “enhanced property views” above) to previously shipped features need to either get glommed together into a feature page or just live as bugzilla bugs. So, there are actually two places (feature pages and bugzilla) where useful work to be done or things that have been done can appear.

The line for me seems to be that bugzilla is used for the details of implementation and prioritizing the parts of the implementation that need to happen. The feature pages provide higher level context of what we’re trying to accomplish.

If you’re interested in helping out with Firefox web developer tools, I’d suggest looking at our Get Involved page which has links to both our feature pages and to our bugzilla bugs.

Tools for Web Developers (1DevDay)

This past Saturday, I had the pleasure of speaking at 1DevDay Detroit 2011. The event was held at the fantastic Compuware headquarters in downtown Detroit. It’s a beautiful building, and the training center facility works well for events like 1DevDay.

I spoke about “New Tools for the Open Web”. My goal was to show off a bunch of tools that people might find useful and to talk about tools for the future. It’s impossible to talk about all of the great stuff that’s going on. The world of open source tools for the web is huge and growing, and there was a standing-room-only crowd for my talk (thanks for packing in there and letting me run over my timeslot a little bit!)

I started with some tools that aren’t new, hopefully showing off some cool features along the way.

  • The Web Developer Toolbar has an incredible number of utilities packed into its menus. It’s not new, but it should be in your toolbox.
  • Firebug has had a huge influence on tools for web developers and continues to get awesome new features (such as more fields on the Net Panel and the ability to select which ones you want). I also pointed out Firebug’s non-standard but amazingly useful control for quickly selecting script files on the script page.
  • I spoke about a couple of neat JavaScript features in the Chrome Developer Tools (the ability to tweak JS on the fly and the ability to prettify JS while you’re debugging)
  • I showed off the Web Console and Scratchpad tools from Firefox, in particular showing how Scratchpad provides a very clean, usable interface for experimenting with JS.
  • I gave a sneak preview of the new Firefox styling tools that will very soon be in Firefox Aurora builds.
  • I showed of the Firefox style editor which should be in the next Aurora. For now, it’s available as an add-on
  • I also demoed Tilt, an amazing 3D visualization of the DOM

In a category all its own is Weinre which provides a way to debug apps running on a mobile device.

Then, I stepped into a collection of CSS tools.

  • ReCSS is a bookmarklet that’s been available forever. One tap of the bookmarklet reloads your CSS without refreshing the page.
  • LESS extends the CSS language with a variety of useful features and compiles down to standard CSS to run in the browser. It’s written in JavaScript, so you can do the processing client side or server side. Neat trick: if you are doing client side processing, you can add #!watch to your URL and LESS will periodically refresh the CSS from the server automatically. Make a change on disk and see the change almost immediately in the browser. I also mentioned Sass and Stylus as alternatives.
  • CSS Prefixer helps you out by expanding your CSS3 declarations to work in all of the browsers that support them with a prefix (-moz, -webkit, etc.)
  • Prefix Free is an alternative to CSS Prefixer that works client side and adds only the declarations needed for the user’s browser.
  • Rainbow is a Firefox add-on for working with colors. Among its many neat features, it will give you the color palette for the page you’re looking at. The Colour Bookmarklet does something similar as a cross-browser bookmarklet.
  • DOM Monster is a cross-browser bookmarklet that will take a look at your page and give you specific advice on how to make it faster

I put out a call on Twitter and G+ for suggestions of tools that people rely on for their web development. Several cited their editors, so I thought I’d mention a couple.

  • JSFiddle takes the pastebin concept a couple of steps further by giving you a way to easily share snippets of HTML/CSS/JS that are put together into a preview pane. JSBin is an alternative
  • The Eclipse Orion project is building a browser-based IDE with workflows and plugins that feel very much “like the web”.We ship the Orion text editor component in Firefox
  • Cloud9 IDE provides a beautiful and feature-rich IDE for working on both the client and server parts of your application… all in the cloud!

I didn’t talk a whole lot about JavaScript-specific tools, because a lot of what we use for JS are libraries and not tools.

  • I showed JSHint, a fork of Douglas Crockford’s ever-popular JSLint. JSHint provides nice static analysis of your JavaScript code to catch some errors early
  • CoffeeScript is a nice language that provides a friendlier syntax on top of JS without changing the semantics. This means that the JS it produces is quite readable (and quite close to what you’d write by hand). I’m still hoping that some of CoffeeScript’s best parts make it into ECMAScript.next (and there’s a good chance that a lot will).
  • Using a language like CoffeeScript makes debugging a bit harder. I showed off our not-quite-ready-yet source maps feature for Firefox. Source maps will also be really useful for debugging minified JavaScript.

I spoke a little about docs. Documentation is important, and the more we do to have better docs for our tools and libraries, the better.

  • I think JQAPI is awesome. They took the standard jQuery docs and reformatted them to be more useful.
  • Docco lets you do literate-style programming in JavaScript (or Python or any of the other ports that are available).
  • Eloquent JavaScript is a book that teaches you JavaScript and provides interactive exercises to help with the learning

Then, I spoke a bit about the future.

Almost everything I showed was created in HTML, CSS and JavaScript. If you can make web apps, you can make tools. Even the tools that are built into the browsers are built of the same basic stuff.

Invest in your tools:

  • Find the good ones, use them and tell others!
  • Give feedback (this really helps people who make tools to make them better)
  • Make them better
  • Make entirely new ones

I mentioned how some tools, like Matthew Claypotch’s localStorage bookmarklet are very simple to write but can meet your needs precisely and even show toolmakers what you’d like to have.

Other tools mentioned to me by others but not part of my talk:

  • Glimpse is a client-side view into a server-side ASP.net applicaiton
  • Edit This Cookie is a Chrome extension for editing cookies. There’s also Firecookie for Firebug
  • YSlow is a tool from Yahoo! for spotting performance problems with your pages
  • stat.js is a bookmarklet that gives you information (such as frames per second) for the page you’re looking at
  • h5o provides an outline view for HTML5 documents
  • LiveReload automatically reloads your JS and CSS as you change it (oh, and it will recompile your CoffeeScript, Sass or LESS for you at the same time)
  • ReloadEvery is a Firefox extension to reload periodically automatically
  • redbot spots problems with the way you’re serving up your pages
  • HttpFox is a Firefox extension that provides an alternative view of network requests
  • ColorZilla is another set of color tools for Firefox
  • Fiddler is a web-debugging proxy

And there are many, many more. It’s a good time to be building web applications.

Future Firefox Developer Tools Updates Oct 27

Unlike most organizations, Mozilla’s product management is open. You can see what we’re building now and planning to make in the future just by looking at our feature pages. Open, however, is not always discoverable and it should be easy for interested people to follow along as plans are revised, help make those plans better and make it easier for everyone to spot features they’d like to get involved with.

As the product manager for Firefox developer tools, I am most heavily involved in the creation of these feature pages.

We had a feature page that conflated two different concerns with a joint user interface. While the user interface we talked about might be a great way to go, the two features have different priorities and it’s worth considering other approaches properly. The more important feature is the ability to lock in a pseudo-class when working on the styling of a page element. For example, viewing the styles for the element as if you were hovering over the element. This is high priority because web developers have no way to peek into the details of hovered styles without tools support. Once they’ve moved the mouse from the page element to the tools, the element is no longer hovered!

The Web Console’s queued messages display is a feature that will allow the Web Console to display messages logged from before the console was opened. There was some complexity found during review of the code and, given the other things on the plate for Firefox 10, this feature is not likely to make that release. This is definitely still a feature we want, but I have dropped it down to P2 to reflect that the other items on the list are higher priority.

There are also some recent additions to the feature pages:

  • Tilt in the Page Inspector adds a 3D view to the forthcoming page inspector (aka highlighter). Victor Porof recently wrote about the add-on which has a whole bunch of interesting features. The core 3D view is something we want to be directly available in our tools, as it will help people solve nesting problems in their markup.
  • CSS Source Mapping The buzz around source mapping continues to grow (see this recent issue for HTML5 Boilerplate) and CSS needs source mapping for exactly the same reasons that JS needs source mapping.

I created some other stub feature pages, and I’ll write more about those as they’re fleshed out.

I’ll be writing more about Firefox developer tools feature ideas from this point onward. Your feedback is always welcome. You can talk about ideas on dev-apps-firefox or contact me via email, Twitter or G+ (see the sidebar on my site).

Students Seeking Jobs: Show Of Your Code

This past Monday, I attended my first career fair on the employer’s side of the booth. I’ve done a fair bit of hiring in my career, but this was still a new and fun experience for me. Career fairs have gotten a lot bigger than they were when I was a student, and the three of us manning the Mozilla booth had a constant flow of students to talk to (sorry for anyone who didn’t get to talk to us before the 4pm cutoff!).

IMG_0595
Tony Chung (far left) talking to a student. That’s Julie Deroche on the far right.

I had a good time talking with the students and I’m sure that many are laying a path to successful careers in software. At the end of the day, one thing stuck out in my mind as being unexpected: where was the open source experience? I think that only a single resume I saw mentioned a GitHub account or some open source project that a student was involved in.

Many students just had their coursework to talk about. Here’s the problem with that: every other student has that same coursework. Using different paper for your resume is not going to make you stand out. Having something beyond your coursework will.

US News ranks the University of Michigan as one of the top 15 grad schools for computer science and in the top 30 undergrad colleges overall. Ann Arbor is not a big city, but the University of Michigan is a big, well-regarded school. UM is not a JavaSchool as almost all coursework is in C++. While I can’t say for sure, I doubt that this lack of open source experience is limited to UM.

I’d also expect that many students who are fans of open source software would likely gravitate to a Mozilla booth.

The students that seemed the most promising to me came across as loving to code. They did things beyond their coursework, in their spare time… They learned Haskell or programmed robots or compilers.

A great way to show your enthusiasm and your code is to be involved in open source.

It would be good for universities to offer a course specifically designed to introduce students to open source and get their code out there. Students would learn about:

  • distributed version control
  • working with people around the world
  • navigating open source projects (using GitHub, mailing lists, IRC, etc.)
  • possibly bits about licensing (it’s good to know the basics, at least)

And, they would even end up with code samples out in the wild that they can show to potential employers.

Remember what I said about everyone having the “same coursework” to show to potential employers? Not so for a class like this if the students are allowed to dive into different open source projects. You’d have students hacking on Rails or Node, Couch or Mongo, CoffeeScript or nginx. It’s good for the students, and good for the projects.

If you’re a student, don’t wait for this magical class to show up. The catch 22 of “can’t get a job without experience, have no experience because can’t get a job” no longer applies: anyone can step into open source. Just do it!

© 2014 Blue Sky On Mars

Theme by Anders NorenUp ↑