The opening party was populated with people dressed in amazingly authentic looking pirate costumes, many with a full size macaw parrot on their shoulder of differing and impressive colors. This party was sponsored by  Zappos, included a great pirate band, many fantastic local beers and they simultaneously ran a super fun twitter based prize contents. Towards the end of the night I won one of their awesome prize bags, which included an 8 bit green gameboy pocket (with tetris, super mario and metroid 2). This brilliant little old game device has been receiving a lot of attention at my house this week, somehow it is still incredibly addicting and fun to play. Way to go Zappos! I will continue buying nearly all my clothes through you..

At 11am the next morning I had 45 minutes to announce and show off Jellyfish, which is a project I have been working on for the last few months. The goal of the project is to expose a simple API allowing you to run JavaScript in many different environments at once. In regards to my talk I did two stupid things: 1. I waited to record my demo’s until I arrived in Portland, 2. I waited to record my demo’s until after a beer tasting pirate party. Having said that, I think the talk went incredibly well and I have been really enjoying the responses and ideas I have received from the community.. keep it coming! I was happy to see a follow up talk filling in the bits my talk wasn’t able to. Matthew Eernissee talked about the pitfalls of writing JavaScript to be shared in multiple environments and gave Jellyfish a nice little plug.

I was thrilled to get a chance to hang out with some of the old OSAF gang, @towns, @twleung (who did two great writeups of JSConf and NodeConf), @mde, and @mikeal. It was interesting to hear all the different views on the attention explosion JavaScript has been experiencing over the last couple years, since we all worked on Cosmo — to this day Cosmo still has one of the most dynamic and interesting web based UI’s I can think of.

I’m glad to say that I was at the talk when Batman came to visit (batman.js) in order to help clear the conference of any potential criminals. I was also at the Yammer party with the great 80′s band where there was a Firefox running around. But the most interesting part of the whole experience was listening to the banter about where the future of the language should go. With Node.js doing it’s thing, people are using and seeing JavaScript in a totally different way. This has started to create different needs and expectations that didn’t really exist when JS development lived only on the client side. There are multiple different communities coming together to create this new “JavaScript Community” and watching them collide is sort of like witnessing plate tectonics from space. Each of the collisions creates a interesting new rift, or subduction zone in the mantel of the community.

One thing I can say for sure is that, you either get CoffeeScript, or you don’t — either way, I think it’s fair to say that we will continue seeing more and more ways for people to write JavaScript without writing Javascript.. and those people can get off my lawn.

If I had to pick a couple statements that sum up the crazy, amazing, drunken “JavaScript Community”, I would have to quote the two icons ultimately responsible for the happenings of last week. The first would be Bredan Eich explaining that “Javascript was thrown together to avoid other languages winding up in the browser” and that he’s aware that it isn’t an “ideal language syntactically”. The second being Ryan Dahl explaining that he’s not really a big fan of JavaScript, it is ” simply adequate for the need”, and he “hates callbacks”. Fortunately, both of these guys and the surrounding community leaders are all on the same page. Javascript is where it is because of it’s fortune of being “the browser platform”. We can all agree that as a language  there are a lot of improvements that can be made in harmony, I just hope that doesn’t mean that JS is going to turn into CoffeeScript.

The other unrelated thing I learned while at JSConf was that John Resig left Mozilla to build the community at the Khan Academy. I had never heard of the Khan Academy before, but I think it’s fair to say that I will probably re-learn everything I learned in college and more watching his videos over the next few years. Sounds like an awesome gig, and I wish him the best — I did find his Reddit AMA kind of amusing and totally bizarre – Mozilla is going to miss him.

I wish I had time to write an overview of all the JSConf talks, but to sum it all up quite crudely: Cloud9 and skywriter are the bomb, I think we will see more “learn how to program” tools in the browser with JS in the future (which is great) like waterbear. Also, apparently people care about putting JS on mobile devices — who knew?

As for NodeConf — this community knows that it needs to mature, and fast — so there was a huge emphasis on how to run big production systems on node, how to debug it and how to test it. I can’t wait to see the fallout from that day of collaboration.

I wanted to thank everyone for the great input on what I’m working on, and the ideas and feedback for Sauce Labs — I am taking all of it very seriously and am working on turning them into action items. For those of you two simply told me that you love Sauce and to keep doing what we are doing — I appreciate the boost!

Also,  I cannot forget a huge thanks to @voodootikigod, @mikeal and all the folks involved in running those conferences, I had a great time — thanks for inviting me to speak!

I took a lot of amazing photos, and I will be going through those this weekend – so stay tuned for a link to the photo album. And if you missed my Jellyfish talk, I will be doing it again at this years Open Source Bridge – June 21-24 back up in Portland, OR.

See you all at TXJS and JSEU, and maybe tonight at the San Francisco JavaScript Pub Night!

See the thing is, right out of college I started fooling with raw DOM, cross browser event firing and capturing and building pretty big cool projects without the help and support of jQuery. So I developed this sick enjoyment of writing tons of raw uninhibited, IE 6 destroying JS. And ever since then, I have just thought of server side code as a necessary evil that I would PREFER someone else to write for me. Don’t even get me started on databases, I mean really — it’s hard to find software more out of touch with the web than traditional databases.

Anyways, so over and over I have pulled the git repo for Node, built it (a couple times had to Google error messages and change things to get it to succeed). Then I would get a ‘hello world’ working, and promptly close the terminal window and head back to my current Django based project (or close that terminal too and head back to client side JS). See, all along I just wanted to store my data on the client side and have some magic behind the scenes take that data and replicate it to a DB somewhere that I don’t need to know about. The point is that, Node wasn’t that magic and ‘hello world’ didn’t really feel that JavaScripty to me. I mean where is my ‘window’ object? And wtf is up with having to ‘require’ modules? I never got into client side ‘require’, so this concept is relatively foreign to me.

At JS.eu I started hacking on a node app, because I simply felt like a poser attending that conference and having not written much in Node. Honestly, minus a couple HTML 5 talks and some JavaScript icons like Crockford and Brendan Eich, JS.eu could easily have been called NodeConf.eu and no one would have really blinked. So I copied an Express app, got it to do some mundane simple tasks then tried to move to the next level. I got stuck due to some strange behavior that wound up being attributed to variable hoisting. At this point I put Node back in the drawer, see when I use a new technology I really want an impressive ‘hell world’ in less than 2 hours (without reading more than 20 minutes of docs). You may be thinking “wow that’s some serious impatience”, but I would be very surprised if I’m all that different than anyone else’s patience tolerance.

Finally about a month ago, I was about to dive into a new app using Django when @mikeal convinced me to use Node and put it on a no.de smart machine. After provisioning my no.de smart machine I was completely and utterly confused and frustrated. After a handful of questions @mikeal pointed me to: Countdown to Knockout: Post 11 – Deploying to Joyent which (although there have been some changes) made it clear enough that I could get my little app online and usable.

Once you have a working web app, the next evolution is to actually store data somewhere, and as I said before: “I am not a fan of traditional DB technology”. So naturally continuing the conversation landed me at Countdown to Knockout: Post 14 – Using CouchDB with node.js. In my ultimate laziness I couldn’t even be bothered to setup CouchDB on my Joyent smart machine, so I decided to use my CouchOne instance. Then I realized, the “CLOUD” buzz word, actually means; how many people can I pay to put my stuff on their machine? I wish I could also do my testing in the CLOUD, oh wait, you can, and I work there, see Sauce Labs.

So my main point is that for the last six months, Node.JS has been this very interesting swimming pool that I kept dipping my toes into — but it finally reached a reasonable temperature for me to dive in, swim around and discover a whole world (including mermaids like socket.io). Node isn’t awesome because it’s JavaScript, it’s awesome because it fits very nicely into this new development ecosystem where things feel like they are designed for the web. After I recognized the differences between Node and my client side JS habits, I was able to move back and forth between client and server side code without this painful mental context switch I normally experience  with syntax. It makes me hate server side development way less than I did in the past, and combined with CouchDB we find ourselves in a world where JSON is the native tongue.

Node may not be _the_ future of technology, but I sure see it playing an important role in my future, enabling faster application development. </rant>

First and foremost — having a tech conference at a summer camp is just plain awesome. As we all know that the social lubrication required to gel a bunch of geeks can lead to a state where said geeks should not operate any kind of a vehicle. In this case, all they had to do was walk 100 feet down a trail and pass out.

Secondly, I really like the idea that the beer follows you at a tech conference… I shouldn’t have to be running all over the place to find my beverage! Thumbs up to the CouchCamp staff for making that dream of mine a reality.

Did I learn anything? Actually, yes I did. I learned some really interested fundamental challenges that database ninjas face on a daily basis. I also saw a possible CouchDB roadmap being developed via the venting of current users, which was pretty neat.

As always Ted Leung came through to finish the grand event off with a great summary of the CouchDB community, where it’s succeeding and where it needs to go. I will never stop appreciating Ted’s open source jedi fu, it reminds me why I am here working in OSS.

It was great to meet everyone, see most of you at JS Conf EU!

Next week I will be heading up to Couch Camp at Walker Creek Ranch. I am really looking for it for multiple reasons, but having visited the venue when it was being considered I couldn’t help but be blown away with the hidden little Marin valley. I really look forward to participating in the CouchDB geekery, general Open Source geekery, and outstanding scenery.

After which I have a week to prepare for a lengthy trip involving 360Flex, followed by a talk at the NYC Selenium Meetup, Sept 22 and then heading to JS Conf EU in Berlin.

While I’m on that side of the pond I am using the opportunity to go see some family in Lausanne, Switzerland and Aarhus, Denmark.

This will be pretty jam packed, but if you are interested in talking Open Source over a beer in any of these places.. let me know!

Also, in the spirit of all this I have updated my blog theme to what seems to be a lot simpler… maybe that will influence my state of mind, inspiring more frequent updates

One last note: Tomorrow the MooTools JavaScript Framework guys are hosting a hackathon at Cloudera, I am considering heading down for a bit in the morning to work on some cool ideas for a front end only Windmill test runner embed.

The press release can be found here: “Sauce Labs Adds Windmill Test Framework Co-Creator Adam Christian to Engineering Team“.

Slide Inc.

I had a fantastic experience and learned a ton working with the really talented team of engineers, artists and product managers over at Slide. It was incredibly educational to work in an environment where so many people use your product everyday. I built a lot of really cool features there for SuperPocus and spent a year building a test automation infrastructure, and molding Windmill to be able to test anything and everything they put in front of me.

Slide was really amazingly understanding as I went through some personal struggles over the past few months. I will miss the people the most, as Slide created a great environment enabling people to effectively work together to solve really challenging problems.

Sauce Labs

Since I moved to the Bay Area, more than once I have seen people leave jobs to goto what they deemed their “dream job”. I never really understood what they meant by that designation until now.

Sauce Labs is solving exactly the class of problems that I find the most interesting, challenging, and sought after by so many people. I’m incredibly grateful and excited to be a part of the team working to make running your tests in the cloud seamless and fast, instead of frustrating and painful. The crew of people I will be working with are second to none and I look forward to learning all I can from them.

Sauce expects everyone to work directly with customers to ensure the best experience, and I look forwarding to helping many new teams get setup with test automation.

Future

It’s hard to outline exactly what future projects I will be involved in, as the technology is moving forward incredibly fast. I do know there are so many ways that we can make the testing community stronger, and the tools better. I see NodeJS and CouchDB opening many doors to new innovations and I would like to continue improving my Python skills.

I will still be within a block from South Park, so let me know if you are in the area and want to grab lunch!

Choosing Tools

A common first reaction is to take a couple of those old boxes sitting around to run the first “couple” tests you have. In some cases, this is the perfect solution. That is if you have a small application that rarely changes and only needs a daily test run (on one operating system and it’s available browsers). In my experience you can reasonably run one Windows VM without lagging the host machine unusable, which gives you two concurrent browser test jobs without worrying about process conflicts. Do remember that to do this correctly, you really want a machine dedicated to your CI system (which I will talk more about below).

VM’s are a great solution, however they require significant hardware overhead, continuous attention and licensing costs. Depending on the VM solution you choose you may also wind up dealing with the dreaded VM Time Drift causing problems with JavaScript and failing tests that aren’t actually failing.

“The Cloud”, is the 2009-2010 buzz word that makes all technology sound better, and in a lot of ways COULD be the ideal solution for test automation. You get the benefits of paying for only the cycles you use, having someone else manage the infrastructure and avoid those pesky licensing costs. However in my experience the setup is painful, the solutions (EC2, etc.) are slow and lacking some of the features to really do test automation well. For example, if you want to run your own CI instance and run your tests on demand in the cloud you will run into some pretty painful engineering problems. It’s not easy to instruct the “cloud” service to fire up a Windows VM and then have that VM connect to your CI instance and become an available slave. It’s doable with Linux, but last I checked – the features to do something similar with Windows simply weren’t there. Also do you really want to wait sometimes up to 15 minutes (also my experience with EC2) for the machines to come up before you can even start running your tests?

What CI System?

The point of this article is not to recommend solutions, it is to encourage questions. However, outlining all of the possible CI systems would take forever so I will simply say that I wound up using Hudson. The reasoning includes a very open and functional Open Source community, with smart contributors willing to take a few minutes to respond and help me out. I also found it possible (not simplistic) to build plugins to customize the things that I needed changed. Many people out there swear by Cruise Control, or Build Bot and I would highly encourage you to do some research and pick the solution that you feel will allow you to be the most productive. For example if you plan to use Windmill and EC2, you may want to do some reading about the Amazon EC2 and Windmill plugins available for Hudson and see what comparable tools are available.

Which test framework?

Some of you may know that I hold a mild bias when it comes to this question, but over the last year and a half I have ventured out into the land of testing frameworks and am able to see the values held by the other projects. For example, if you don’t ever need to deal with JavaScript in your application (or have browser specific functionality) — I suggest you use a tool that doesn’t require a real browser (like Twill). Tests will run faster, they will be more stable and can be run without access to your OS’s graphics layer.

When it comes to browser based web testing tools I really think you need to pick the one that fits your needs the best. A great example of this was in my needs to automate functionality contained in iframes being served over HTTPS from a different domain, the only solution (after weeks of trial and error) turned out to be WatiN. Of course, writing and building tests in C#.net wasn’t going to be an easy sell so IronWatin was invented as a means to write WatiN tests in Python.

Watir has captured a lot of the Ruby community and has recently been moving towards consolidating the separated browser  projects into one, which will significantly improve the ease of use.

Windmill has a dedicated community, focuses on dynamic JavaScript applications, boasts lots of features and goes for an ease out of the box type of experience.. at least that’s what I would like to think! Please feel free to check out the destination site or Github wiki for more information

Selenium has a thriving community, lots of available consulting support, integrates well into a Java environment and offers the Grid project. You can also avoid all of the work involved in running your own system by writing your tests in Selenium and then offloading them to a company like Sauce Labs if you are willing to pay for it.

What do we do about Flash/AS3 automation?

After unsuccessfully trying out FlexMonkey and AsUnit (don’t take my word for it), Matthew Eernisse sat down and wrote an AS3 test controller that works the way the rest of test automation works in the browser, it’s part of the Windmill codebase (codenamed FlashMill). There are two ways to run the tests, one is to hand FlashMill your tests already written in AS3 and the other is to write them in your favorite tool (or raw JavaScript) and have them call into the FlashMill API. Windmill currently has full IDE/UI integration in master to be released soon, the integration code is simple and can be viewed here (best doco at the moment until I write a better one).

Workload

Depending on the machine setup you are going with, this will vary. Obviously if you have a box and a VM on it you can manually go through the process of upgrading the browsers on each, installing patches and security fixes for the OS etc. But if you went with the VM solution, you need to come up with a way to deploy updates to all the machines in your pool. An Open Source solution that came up near the top of my search is WPKG, but like the rest of the tools on this page – there are many solutions and you will want to do your research. Some of the maintenance you will be dealing with can be done as a system job, or run by your CI system. A good example of this is to remove data, test files, source repositories etc. that accumulate on your test running machines.After a while, these files in combination with temporary internet files from the browsers and system tmp files start to slow things down.

This piece is very important to take into consideration from the beginning, because once you have 15 VM’s running tests — doing anything manually becomes a major chore. You also need to be cognizant of that fact that if you chose the cloud testing solution you will be managing your own test running images used to boot the VM’s. Every time you want to make updates or changes to that image, you get to go through the whole process of baking it and uploading it to the cloud hosting service. In my experience, this process is NOT enjoyable or quick.. so be prepared to invest some serious time.

What is the strategy for scaling and expanding?

Clearly this will be dictated by the rest of decisions you made, but I think when you get to this point, the idea of buying and manually setting up more and more physical boxes starts to break down. Buying more and more machines to sit there running tests simply seems like a bad use of resources (and desk space). VM’s allow you to quickly replicate images and expand your arsenal as long as the host machine has the hardware resources to power it without negatively effecting test run times on all the others. There are also solutions out there that allow you to boot and shutdown VM’s on the fly, which provides some interesting possibilities in juggling system resources.

I have found that since Windows is the common platform that can run all the browsers I care about, having a large pool of identical VM’s running all the time is an easy way to queue up 100′s of tests and get results in a reasonable amount of time. I do think that this is the aspect that cloud services start to become more appealing. The idea of spinning up more and more virtual machines in the cloud (with essentially endless capacity) makes the idea of scaling those tests considerably less terrifying. If you can get over the generally slow spin up times, and have come up with a strategy of dynamically harnessing and adding those machines to the pool – you may have it made!

What format/language is best for our tests?

At this point in web testing you simply need to decide what you care the most about doing. Is it manipulating the page? Or is it interacting with a database?, or a little of both? If you can get away with writing your tests fully in JavaScript, I would recommend it. At least in Windmill the JavaScript tests run exponentially faster than the Python or Ruby tests do. However the libraries for communicating with databases, email, system services etc, may make Python, Java, C#, etc your ideal solution. Each of the tools has their own ways of doing things, and to come up with the ideal language really depends upon your system, what your test developers are comfortable with, and what your application platform looks like.

What operating systems and browsers do we need?

The answer to this question should come from the metrics of your user base, and will also help you narrow down a testing framework and your test machines. Some of the available frameworks simply won’t run on Linux, or support IE6. Are all your users using Google Chrome? Then you should probably make sure the test framework you use has a Chrome launcher. Historically I have concentrated about 90% of the available VM resources on the most popular platform (usually Windows), with the most popular browsers (Firefox latest release, IE 7 or 8 depending on the users, Safari Windows latest release, and Chrome). This gives me a pool of work horse machines that can crank out tests representing the majority. The other 10% would be divided into the higher percentage minorities which probably includes a MacOSX slave running FF and Safari and a Linux machine running FF and Konqueror.

Methodology

I have found that having your own test infrastructure really makes this one easier. Since your resources will probably be on the same network as your codebase, you can easily access and run unit tests.. however as soon as you start sending your tests off to the cloud you are dealing with some security/privacy issues and engineering challenges. If inorder to unit test your code you need the entirety of your code base available, sending a copy of it off to your image on the cloud for every test (job, run or even change set) over and over could become a major strain on your system and simply sounds like a bad idea. If you are counting on unit tests you will at least want a machine on your network available as a slave from the CI system for those jobs.

How do we report results, and stay tuned into failures?

Most CI solutions have many ways they can be configured to alert you of a failure, from email, irc, jabber to a phone call you can usually find some solution that will get your attention. At this point in time the norm appears to be jUnit compatible results in XML. I’m not a huge fan, but the available tools for parsing and aggregating jUnit into something useful is very appealing. If you are okay with a true/false, that will always work out of the box, but you will need to be prepared to put in a little extra effort in both your test development and test job setup to generate the jUnit report files.

What role does automation need to play in our process?

For maximal results you need to make the leap where QA and Development both understand that a failing job in the CI system is a show stopper and must be investigated immediately. This way people honor the continual nature of continuous integration. It’s job is to catch problems shortly after they are broken, point you directly at them, and continue failing until you have solved the issue or fixed the test. If this isn’t the process you want, having continuous integration may not be the solution you are looking for.

Another effective strategy I have seen is to base release viability on the status of your CI system. Don’t let the product go out the door until the ‘thoroughly defined’ suite of functional and unit tests running in continuous integration are all running and passing. It is easy to push off the process of updating failing tests until “later”, but everyone is busy, and later is usually never.

What part of our application should we automate?

This really should be computed by time and resources, as much as I would like to say “everything” I am well aware of it’s low probability. Pick your application flows that make you money, or really mean a lot to your users likely experience. Ensure that your application loads, they can take the happy path, give you some money and then leave. At least this way you can sleep at night knowing that, they may not be able to change their profile information but they can still pay your salary.

Conclusion

I use the ‘configuration matrix’ option to build a matrix of browsers to run the tests, this way I can have one job that represents a test run on multiple boxes and multiple browsers on each box. Drilling down allows me to see the results for each of these test runs within the job. (Configuration Matrix is awesome btw, except for one really annoying bug for, which there is a reasonable workaround)

Having many build resources, sometimes I want to move a job from one machine to another in order to equalize load on the different machines or to have a job running in ff2 and ie6 instead of ff3 and ie7. Thus the need for a uniform build step that will run the same way regardless of the machine or installed browsers, became necessary. Additionally the commands for running tests got bigger and less manageable all the time, so the time for a clean user interface finally came. This way I can automatically append arguments like ‘exit’ to keep the build step interface simple and clean.

The other simplification is that in the Hudson configuration page for the Windmill Test plug-in you can tell it to automatically call the contrib ‘clean_run.py’ script with the correct arguments (assuming clean_run.py can be found in your path).

As I am relatively new to the Java world, I struggled through the development process but thanks to some reasonable plug-in documentation, responses from the hudson dev mailing list and some IRC conversations with Kohsuke (thanks so much) I finally have something that sufficiently addresses my needs.

Screenshots

Project

The code is all available on GitHub and I welcome any improvements or input from the community as I know that continuous integration is a very important piece of the utility provided by Windmill and this pieces should be as easy as possible to setup.

The combination of this plug-in, and others like the amazon s3 plug-in or the hudson VMware plugin bring us that much closer to seamlessly creating test resources, running our functional web tests across all of our supported platforms and then throwing it away until it’s again needed (or using the CLOUD).I have also done some integration with virtual box that I have found to be very successful.

Download

• Hudson Windmill Plugin 0.4

Please log bugs and let me know what you think! If you are an avid Java and or Hudson plug-in developer and you are interested in contributing, please jump right in!

First off, I have to say that for those of you who don’t know, PyCon is a community organized event, and amazingly well done. I was impressed by the design of the conference, the way they had four talks going on at once and they tried to keep them in a similar interest track. Every talk I attended was at least “good”, and many were “great”. You could really feel a community vibe, and for a conference that had 800+ attendees in the middle of a major recession they had every right to be excited.

There were two major themes content wise that really impressed me, the first was an amazing amount of web framework focus. Django obviously being the twinkle in the eye of the community, but there were smaller communities for each of the other projects, Pylons-Turbo Gears, web2py and lots of tools built on top of them. One that struck me with some major promise is the Pinax Project. Their goal is to make it so that I don’t ever have to deal with building user registration and in site messaging… and all the other features expected for any site that has social network functionality.

The other major theme was a mini testing conference going on within PyCon, that I was very comfortable hanging around with. We had a hugely successful Birds Of a Feather, as well as a surprisingly active Open Space talk for Windmill.

The “Using Windmill” talk turns out to be pretty successful in every aspect that I really care about. I do wish that I had been able to get a little more sleep the night before, and I have to admit the size of the venue was a bit overwhelming. I now realize watching the footage that I used the word “UM” way too much, and the demo videos must have been hard to watch from the very back of the room. But barring those two things, I am quite happy (I shall learn and practice for the next round of shameless PR at OSCON 2009).

The “Functional Testing Tools in Python” panel was very successful, and a lot of fun. I always enjoy the friendly banter between the different project owners. Everyone has a different opinion on what they care about, focus on and feel they do the best. Obviously since the only two projects represented that focused on Web Testing were Windmill and Selenium, we got a lot of attention.

Watching that panel footage I definitely think that the introductions were too long, but I still think our Journey themed – mind blowing – Windmill demo video was a great intro. At the very least, the audience had a little entertainment before the geek droning began

Slide had an awesome presence this year, a fun booth, huge banners everywhere and 6 attendees. It was fun to see all of the great responses I received about Slide from people out there in Python land.

Here are links to the videos:

• Using Windmill: http://pycon.blip.tv/file/1947236/
• Functional Testing Tools in Python Panel: http://pycon.blip.tv/file/1947342/

And some pictures:

If you are interested in seeing the new and improved version of the “Using Windmill” talk, please make it out to OSCON 2009, “Scheduled for 16:30 on 22 Jul 2009.” in San Jose, CA.

We are waiting to hear back from both Open Source Bridge and the AJAX Experience as to whether we will be participating in those conferences (fingers crossed)!

The combination of writing content style HTML, and the good advice we received have come together into what I feel is a pretty usable user interface. Granted this is the first revision and will probably continually be refined to become even more user friendly, but from 1.0 to 1.1 it is a vast improvement.

Improved Editor

The first major improvement is the implementation of a full featured code editor named EditArea.

We have been keeping our eye on Bespin, which we will look more into integrating when it is a bit more modular.

For the meantime EditArea does a great job, and was *relatively* painless to integrate.

Some of the features include:

• Multiple file editing
• Syntax hilighting
• Full Screen mode
• Adjustable font properties
• Jump to line numbers
• Search and replace
• Automatic tabulation
• Toggle hi-lighting
• Toggle edit modes

EditArea implements execCommand similar to the implementation in Midas.

Reorganized Menu’s

Part of the move from XUL involved no longer relying on the toolbox, so we have reorganized the menu’s into dialog’s (don’t worry most functions have a keyboard shortcut if you are one of those people that doesn’t want to deal with that extra click).

This cleanly displays all the available options, and doesn’t clutter up the main UI. This also provides space to easily add new features that fall into these logical spaces in the future.

Improved Inspector

There was a lot of frustration when it came to getting the results from the inspector into the editor, some of this had to do with the non editable default nature of the elements we were using to draw them out in XUL, but the integration of the feature into the IDE became very messy and confusing.

This creates an obvious separation between the rest of the UI and the inspector feature and puts helper features out in front of you to simplify the process by dumping to the clipboard and then moving you to a focused editor window.

Improved Output

The output UI has been completely revamped to give you the most important information quickly, but allow you to navigate down an expandable tree to explore the output of the exception.

All of the information in the output divs can be easily selected and copied to stick in bugs etc, but also saves you a trip to the error console as it should encompass all of the information being thrown in the error object, serialized and organized into a more readable format.

Thanks to JQuery UI’s information and error boxes I was able to tweak the CSS to make some relatively attractive, but more importantly, informative UI that should quickly give you the status of your test run.

More Information

• MozMill Google Code Project
• Mikeal Rogers Release Blog Post
• Google Code XPI Download
• QMO Documentation
• MozMill on PyPi

Thanks everyone who logged bugs!

I don’t necessarily want to bookmark these sites, and this process of opening them is somehow part of my routine, however spending this kind of time every time I want to get to this state is just silly. Part of the ritual is to go through each of the open tabs, read the most recent updates and then close the tab, repeating this whole process many times a day.

At this point you should be starting to get the jist, to automate this whole process I created a Firefox Extension called MyTabs. The UI and use case is simple, but some of the tools I built in make it potentially very powerful.

MyTabs has the MozMill Controller built in, and is automatically setup in the tabs content window scope, allowing you to write and attach scripts to each tab to be executed ‘onload’. Thus automating the need to ever manually login to your web applications again.


Example script for logging into Facebook:

1
2
3
4
5
6
7
8
9
10
11
12
13

//Lookup the three elements I want to interact with
var email = new elementslib.ID(doc, 'email');
var pass = new elementslib.ID(doc, 'pass');
var login = doc.getElementsByClassName('UILinkButton_A')[0];
 
//Controller expects elementslib objects
var elibLogin = new elementslib.Elem(login);
 
//Tell the controller to type the credentials
tab.type(email, 'my_facebook_account@address.com');
tab.type(pass, 'my_password');
//Click the login button
tab.click(elibLogin);

This is all possible by a really slick snipped of code I found on MDC:

1
2

var newTabBrowser = gBrowser.getBrowserForTab(gBrowser.addTab("http://www.google.com/"));
newTabBrowser.addEventListener("load", function() { newTabBrowser.contentDocument.body.innerHTML = "Stuff"; }, true);

Security/Preferences

For the sake of security I made it so that you can only attach scripts, not edit them so that you friends can’t go and view your script to get those plain text passwords. All the tab data is stored in the prefManager so that it is available across sessions. However if someone knew enough to pick apart the source, install a trusted JS Shell and manually access the prefManager you may be in trouble… so be careful about super sensitive information especially on a shared machine.

Using jQuery UI I was able to make the UI relatively attractive, intuitive and possibly skinnable in the future (if you want to do this yourself, grab the source swap out the jQuery UI theme CSS directory and boom you have yourself  new look.)

Some Screenshots

The source is fully available on GitHub, and the XPI is available on Mozilla Add-ons.

• MyTabs on GitHub
• MyTabs on Mozilla Add-ons

Remember that I am currently on bug fix release 0.3, but please let me know if you run into any problems!