January 14, 2009 by
In preparation for the Windmill 2 client side re-architecting, and an article I am writing about simulating user sessions with JavaScript, I decided it was time to go through the Windmill JavaScript source and pull out the pieces necessary to drive a user session in JavaScript.
It turns out that it’s easily broken into a few pieces:
- Events: Cross browser compatible event firing functionality
- ElementsLib: DOM element lookup functionality via many methods called ‘locators’
- Controller: The logic for firing the right events to simulate user actions such as ‘type’
In order to test all the functionality I wrote a small runner implementation, which was actually pretty fun and interested because of the need for waits and sleeps. As I didn’t want to have a continuous loop running, which has been the standard solution up to this point I decided to go about mine using a execution queue instead.
By ‘queue’ I mean that I’m using a JavaScript array with push and shift to keep track of what user actions need to be executed next. When a new action is pushed, if there is nothing in the stack it immediately executes, however if there are actions in the stack waiting those are then executed in order then it is executed. This works great, however there is one more level of complexity here involving sleeps and waits. If a sleep or wait is called a flag is set called ‘asleep’, that tells the executor to pop any new actions onto the stack instead of trying to execute them. When the sleep is done the asleep flag is turned off and all the actions in the stack that have been queued up are then executed in order.
Tests are very simple.
var test_run = function(){
wm.user('type',{'text':'testing', 'name':'q'});
wm.user('waits.sleep', {'ms':5000});
wm.user('type',{'text':'numbertwo', 'name':'q'});
wm.user('asserts.assertValue', {'name':'q', 'validator':'numbertwo'})
wm.user('waits.sleep', {'ms':3000});
wm.user('type',{'text':'finally', 'name':'q'});
wm.user('asserts.assertValue', {'name':'q', 'validator':'finally'})
}
This test can be executed against the Google Home page, and it simply types text in to the search box, sleeps a few times and asserts that the value typed in is actually in the form field when it should be. wm is the windmill code namespace, and user is the dispatch function that takes the method to executed and it’s parameters as an object.
Obviously as this was all taken out of the Windmill source all of the JUM functions are also available in wm.ctrl.asserts if you would like to mix them into your test.
So how would one use this?
There are actually a couple ways, one is to include the source in the page you want to test:
<script src="http://adamchristian.com/wmlite/wm-lite.js" type="text/javascript"></script>
or you can use the JavaScript Console to inject it into your page:
x = document.createElement('script')
x.src = "http://adamchristian.com/wmlite/wm-lite.js"
document.body.appendChild(x)
There is code that is executed when this file is included that figures out if the page has been loaded, if it has it calls in init function to enable the key shortcut listeners. If the page hasn’t been loaded, the window onload is pointed at the init so you are sure to have the shortcuts available to access the UI.
The short-cut is ALT-T. I was thinking ‘test’, meta-t and ctrl-t are almost always assigned by the browser but alt appears to work in all my test cases.
“Windmill-Lite UI Screenshot”

Why?
I don’t have a specific use case for this code/project but I know there are many uses out there for the functionality in the libraries, and for a low overhead cross browser litmus test tool it has some serious potential… also, it was fun.
Links
Additional Coolness
I’m sure there is something like this out there, but I got pretty annoyed trying to use various JavaScript compressor tools to make a single minified file, so I hacked one together in Python called ‘compressjsdir’. It requires jsmin.py, and you can find a zip of everything required here: http://adamchristian.com/code/compressjsdir.zip, or grab the source from github: http://github.com/admc/compressjsdir/tree/master
To run it you can simply do the following (after you put the compressjsdir directory in your path):
dhcp-10-10-9-230% cd directory_of_js_files
dhcp-10-10-9-230% compressjsdir.py
Reading and compressing...
Writing file...
There should now be a file called out.js, which is composed of all the js files in the directory minified and concatted together. This is all based on the JS compressor code Mikeal Rogers wrote for Windmill in our quest for performance.
I will be adding a couple easy features in the next few days, one of course is to take a parameter used to name the output file, and the other argument will be a comma delimited list for ordering of the files as they are minified and appear in the result (in case you have dependent files).
More
If you are interested in more related or similar projects, you may want to check out FireUnit.
Tags: Github, JavaScript, JSmin, Programming, Python, Testing, Windmill
Permalink |
Posted in Automation, JavaScript, Open Source, Python, Technology, Web |
No Comments »
• • • • •
November 19, 2008 by
Working up to the Windmill 1.0 Beta 1 Release, I finally had the opportunity to put some time into making the IDE (that a lot of you live in when in test writing mode) a little bit nicer to look at.
The IDE has been growing organically since 0.1 and there was a lot of functionality hacked into it that wasn’t in the original game plan, so I did what I could to improve the beauty of the CSS/Layout as well as the whole mess of code behind it.

Launching
If you have used our latest release, or are running trunk you know that we have significantly improved the load times for the Windmill IDE. By compressing the JavaScript when the service is instantiated we can simply hand the IDE window one file that contains the vast majority of the required code.
The reason that this makes such a huge performance difference is because we are loading the source via the local windmill proxy and the data size size had very little impact, the overhead was in the browser two connection limit. When you have to pull down ~30 files two at a time it takes its toll and made the IDE feel very sluggish and more like a web page loading than an IDE.
In the process of figuring out exactly what was slowing down the launch time we added some more informative messages and output so you don’t sit there staring at a twirling circle graphic wondering if anything is happening. And to make the experience even more fun, I couldn’t help but implement a progress bar.
General Layout
I removed the toolbar at the bottom of the screen, which I felt it was an irritation for test editing (especially with the drag and droppable actions). It is now in a drop down menu at the top right of the screen, with the rest of the UI access to IDE functions.



Settings and Firebug Lite Improvements
The settings dialog has continued to improve by implementing more useful defaults, adding new options, removing deprecated options and simply making it just look better. Thanks jQuery UI!

Firebug Lite has been a very popular feature since we first announced it, which has led to a handful of bug fixes over the last month. The most major of these was that the initial Windmill implementation of Firebug Lite required you to have Internet access as it was using resources that were hosted elsewhere.
These have since been copied to our source tree and are made available by the Windmill server so you can happily introspect your Web Apps JavaScript while writing tests on your Intranet.


Output and Performance
Instead of writing all the raw windmill output to the output and performance tabs there is now an array called windmill.errorArr, where all terrible errors and warnings about technical details are pushed in the case you are interested to see all that data. However, it’s more likely that you aren’t and scrolling through all that output data becomes tedious.
This is why we have implemented output in blocks with the background color representing pass/failure with green/red (white for performance). These blocks are expandable, clicking them will reveal all output (or performance information) we know about the action that was executed. This should give you a faster general overview of your results and allow you to quickly see the details you care about.


Other Worthwhile Mentions
We moved our XPath implementation from Ajax-Slt to JS-XPath, which has proven to be more accurate when it comes to resolving XPath generated in Firefox (or using Firebug) against non XPath native browsers such as IE.
Many bugs and improvements have been made to the DOM Explorer, which should now feel a lot more like the Firebug DOM inspector, but should work in any browser.

We have also put a lot of effort into improving the communication between the JavaScript Controller and the Python Service so that when a test fails you get as much detailed information in the service as you do in the IDE.

Timing and MozMill
The timing has lined up nicely as we are working on both a 1.0 release for Windmill and MozMill. MozMill is geared towards automated testing of all applications on the Mozilla Platform and functions in the trusted space providing lots of very useful flexibility.
You can currently try out MozMill 1.0rc1 as a Firefox Add-on, and keep your eyes pealed as some exciting new MozMill feature work is around the corner.
Participate
We are always trying to make life easier for the test writer, so please log your bugs and feel free to come chat with us in #windmill on FreeNode.
Tags: 1.0, Beta, IDE, Mozmill, Release, Testing, UI, Windmill
Permalink |
Posted in Automation, Firefox, JavaScript, Mozilla, Open Source, Python, Technology, Web, Windmill, Windmill-dev |
No Comments »
• • • • •
September 19, 2008 by
Following ‘automation’ and ‘continuous integration’ in the micro blogging world I have seen a major influx in people being super interested in functionally automating their web apps. I have seen a slew of things about Grid, and Selenium, and people hacking on Watir so I decided to show you from the ground up how incredibly easy it is to get automated test running setup using Windmill and Hudson. I am not going to walk you through every detail, this is much more high level but I do plan to start a ‘continuous integration’ page on getwindmill.com in the near future for those kinds of details.
The first step is to get a couple machines that you want use as slaves and a machine to run Hudson, our setup looks like this:

Each of the machines with a different OS has Windmill installed. To make them slaves you simply bring up the Hudson web page on the machine, and run the launcher.. now it’s a slave — crazy easy right?
Now to setup test runs for the machines, in Hudson you click: “New Job” on the left hand side and do something like the following:
Tie this job to the slave you want it to run on (we can’t have IE runs happening on MacOSX):

Tell this job to run 10 and 30 minutes after the hour:

The build steps to actually run the tests, the first kills any straggling processes (more details below):

On the Mac for the Safari job, I want to make sure there aren’t any instances of Safari left hanging, or windmill processes sitting around so we do:
ps -ax | grep windmill | awk '{ print $1 }' | xargs kill | true
ps -ax | grep Safari | awk '{ print $1 }' | xargs kill | true
Then we want to grab the latest test code from svn and launch the windmill test:
svn up /Users/adam/Documents/main_bt/windmill/
python /usr/local/bin/windmill safari http://www.facebook.com test=/Users/adam/Documents/main_bt/windmill/fb email=username@slide.com password=pass report=true exit
rm /Users/adam/Library/Cookies/Cookies.plist
I am telling windmill to run a test against facebook.com, with the test hierarchy in the windmill/fb directory in Safari, with the provided email and password, then to report it’s results and exit.
The only thing different on our windows test runs is the way we kill the processes:
Example:
taskkill /F /T /IM windmill.exe
taskkill /F /T /IM firefox.exe
You might be asking how do I use those variables, check it out in my setup module:
1
2
3
4
5
6
| def setup_module(module):
client = WindmillTestClient(__name__)
client.type(text=functest.registry['email'], id=u'email')
client.type(text=functest.registry['password'], id=u'pass')
client.click(id=u'doquicklogin')
client.waits.forPageLoad(timeout=u'100000') |
You can also read a great entry about adding reporting to your tests on Mikeal Rogers blog, here.
And that last line removing Cookies.plist makes sure that the next test run starts without any cookies set to cause problems.
Have Hudson keep you updated on Jabber:

Grab the generated XML output so you can view the test results in Hudson:

Do this for each of the test runs you would like to have, and boom — continuous integration:

This is obviously a simple scenario, and you can do way, way more customization.. but this should get you off the ground. Happy testing!
Tags: Automation, Continuous, Hudson, Integration, Python, test, Windmill
Permalink |
Posted in Automation, Continuous Integration, Hudson, Slide, Technology, Web, Windmill, Windmill-dev, Work |
6 Comments »
• • • • •
September 4, 2008 by

Project Status
I have spent nearly every day since July 7th working to bring the Windmill Project up to a level where it can be used reliably in a production environment. Our mission starts with “Windmill is a web testing framework intended for complete automation of user interface testing”, of course this refers to the web including everything and anything inside the browser window. This turns out to be a very large task, one that only an Open Source labor of love could possibly attempt to accomplish.
Windmill has slowly evolved as a project with user contributions, a moderately active IRC channel, and enough users to keep me from forgetting what a useful and powerful tool it is. When I was offered the opportunity to work on the project I quickly saw how much needed to be done in order to get to where we needed to be. We still aren’t quite there, and like most Open Source projects we might not ever get to the envisioned perfection, however recently we hit a very important milestone. The project is now fully hosted and run by the committers, and in many ways “Grown Up”, thanks to a lot of good advise and hard work. The milestone we have reached, is that Windmill is ready for YOU to use. This week we pushed 0.8.2, which is a release that has addressed all of the major issues that we know about and have discovered with heavy usage over the past months. Our hopes are that you will go install Windmill 0.8.2 and things will just WORK. If not, I can’t wait to get your issues in trac and see what we can do to fix them.
Priorities
The main things we care about when it comes to our web testing tools:
- Low barrier to entry, low learning curve, and ease of use
- Thorough documentation, community and project support
- Support for the big 3 platforms; Windows, MacOSX and Linux
- Support for the big 4 browsers; Firefox, IE, Safari and Opera
- Easy integration with continuous integration tools
- Reliability; developers aren’t going to pay attention if the failures aren’t real
- A really nice looking logo, and a web site that is easy on the eyes..
There are always more features to implement, but Windmill hasn’t needed new features for a very long time. What Windmill needed was some serious QA, some code cleanup and a whole mess of bug fixes. If you look through the Trac Timeline you will see the massive amounts of all of the above that have happened and I am proud as hell when I launch the application today and see all that it can do.
What can Windmill do?
Windmill offers the ability to build, write, record and run tests as well as aid in debugging and development. In addition, the framework provides the ability to create and maintain hierarchies of smart and thorough tests that will ensure the quality of your web applications over time. Not only can we save you hours creating and maintaing tests, but we can also help you see your web application as a growing feature rich product, instead of a QA nightmare.
Many tools out there provide ways to write tests, some even provide recorders and DOM explorers, but none that I have ever seen provide this rich functionality cross platform and cross browser, which is really what is required in order to build a thorough test repository that represents all your possible users.
The current set of major features can be found at the Windmill Features Page as well as more details about what is currently available. One of the more exciting new features is the full integration with Firebug Lite. Web developers rely on the existence of Firebug in order to quickly build and debug web applications, and Firebug Lite is the next best thing. It’s hard to even describe how useful it has been to instantly access the JavaScript Console and DOM inspector in IE to debug a failing test. As the Open Source community grows, and tools are improved and brought to light, I think it’s very important to do everything we can to utilize these tools and use them to enhance the Windmill Framework.
Keeping it Open
The Open Source aspect of Windmill has turned out to be it’s greatest asset. The project is almost entirely written in JavaScript and Python, which instantly gives us many advantages over the competition. The JavaScript community is constantly evolving and is most certainly the futures technology platform. Python has a very strong community as well and has given us immense amounts of functionality and flexibility right out of the box.
One of the most exciting things to me personally about this particular project is the immense potential user base out there, and the large impact the Windmill Tools can have on the daily work flow of it’s users. Windmill was obviously inspired with the hopes of minimizing the need for manual testing of rich web applications, and has grown to be much more than that.
The future of the work to be done on Windmill will primarily be driven by the needs of it’s users, the changes and development of the industry and the success of it reaching the goal, to make web automation better.
Moving Forward
Concluding this major push of work, testing, documentation and moving of infrastructure; we now need to see how the community feels. There are lots of choices out there for web automation and we have made many differentiating choices along the way. It is now time to get the word out and take in some real feedback.
Thanks you all for input, contributions, patience and valuable feedback. Those of you who spent many hours on Freenode in #windmill with us debugging and hunting down those spastic blockers are troopers and we really appreciate it.
Tags: Automation, Community, Feedback, Open Source, Project, Testing, Windmill
Permalink |
Posted in JavaScript, Open Source, Technology, Web, Windmill, Windmill-dev |
2 Comments »
• • • • •
July 30, 2008 by
I am currently up here in Whistler BC for the Mozilla Summit. There is about 400 people here staying at the Westin Resort & Spa up here in scenic Canada.
The schedule for the con can be found here; http://wiki.mozilla.org/Summit2008/Sessions/Schedule
I do have to say that Mozilla is doing a great job at taking care of all their contributors and employees this week, and I feel like a lot of progress is being made on many levels. It’s very useful to see details as to how people are going about this, but it’s even more useful to see things on a bit higher level. It can be easy to get lost in the forest of Open Source, especially the way that Mozilla builds on things organically.
The sessions are ranging from “The History of the Browser” to Mobile, QA, UE/UI, Thunderbird, planning etc. As Moz has people all over the world I am getting to hear some very interesting accents and interpretations of things. At the dinner last night I was sitting across from people from Germany, Macedonia and Israel. Amazing how the Moz projects can cross the globe and still keep communication open with each of it’s appendages. The keynote from Mitchell Baker and John Lilly gave me a very solid impression of what they feel the company values, where it should be going and most importantly their extreme satisfaction with where it currently is.
Tomorrow I will be doing a session with Mikeal Rogers and Clint Talbert to demo and explain the GristMill XUL testing framework. My piece of this project is called Mozmill, which started out as a straight across port of the Windmill source with the addition of XUL support and has turned into a much more advanced tool that will fill some needs that have existed for a very long time.
I found it interesting to find out that the VP of Engineering Mike Schroepfer announced his departure last week during Oscon. Their have been mixed reactions about this, but many speculations were proven correct today when he announced he was going to facebook, http://blog.mozilla.com/schrep/. The idea of an IPO is can be extremely appealing, apparently they made him an offer he couldn’t refuse.
This morning we were alerted that tons, literally tons of rock had fallen on the highway 99 which turns out is the most convenient of two possible road trips to get back to Vancouver. We are leaving Friday morning, and the new word is that we will all be loaded onto shuttles to embark on the 7 hour trip back to the airport. This will make for an extremely long day and I am not looking forward to it, but the trip was well worth it and I look forward to getting home and picking up where I left off at Slide.
Tags: 99, History, Mobile, Mozilla, Mozmill, Open Source, Organically, Planning, QA, Rocks, Slide, Summit, Thunderbird, UE, Whistler, XUL
Permalink |
Posted in Career, JavaScript, Mozilla, Open Source, Slide, Web, Windmill, Work |
No Comments »
• • • • •
July 30, 2008 by
This year was my second year at OSCON in Portland, and it’s pretty amazing for me to look back at last July and know that I was working at OSAF. A lot can happen in a year, but what didn’t surprise me was the amount of people that I interacted with at the con that I had met during my OSAF experience.
A few things come to mind when I think about the conference as a whole. First off, who gave OSCON a Ruby adrenaline shot? The Ruby track was pretty extensive, and I would say more prominent even than the Python track this year. I felt like many of the talks were very introductory with very few actual visual demo’s of things “working”. I know that OSCON brings a very diverse crowd.. but please, please come up with some way to show us if things are advanced, or not. I really get absolutely nothing out of introductory level JavaScript sessions, but a title like “Digging into the guts of JavaScript” could pretty much mean anything under the sun.
Some of the most interesting talks I attended last year had to do with open mapping and location services, I know you want us to also attend the “Where” conference, but these things are part of Open Source and should be represented at OSCON!
I really enjoyed the talk about CouchDB, I hadn’t heard about it and really enjoyed how it opened my mind up to some new concepts about how your application should interact with a database. I would advise everyone to check it out at http://incubator.apache.org/couchdb/.
Another was the “Django Tricks” talk, this was great because he just ran through a bunch of really cool examples — one of which was introspecting a sqlite db to build models from the schema. Pretty cool stuff! Additionally, I think Ted Leung nailed his talk about “Open Source Community Antipatterns”. A lot of the ideas and concepts weren’t new to me, but it always helps to get a more detailed overview from someone who has seen these patterns repeated over the last 10 years.
The best quote I heard was that the “Second OSCON starts at 6pm each night.” I completely agree with this, the social aspect of the conference is invaluable, but be careful about all those free booze — they sneak up on you if you aren’t careful.
I do feel as if I should have done a Windmill talk this year, I didn’t see anything from Selenium or Watir and if we had been a little farther a long with the next iteration on Windmill it would have been a great venue to get some serious exposure. I may attend some other conferences this year, or wait till OSCON next year for Windmill to make it’s big splash.
Tags: Booze, Code, Conference, Couchdb, Django, Location, Mapping, Open, Oscon, Ruby, Selenium, Source, Speaking, Testing, Watir, Where, Windmill
Permalink |
Posted in Career, JavaScript, Mozilla, Open Source, Technology, Web, Work |
No Comments »
• • • • •
July 23, 2008 by
Every year I like to make myself a road map of how I will be spending my time during OSCON. As there are so many interesting possible talks, gatherings and social events it’s tough to get to all the things you care about.
At this point in my career my focus is on Web Development, Test Automation (specifically for the web & browsers), and social networking. Obviously on a moment by moment basis your interests are pulled in varying directions, but that sums up the bulk of my attention.
If you are interested in the full schedule grid, it can be seen here: Oscon 08 Schedule Grid.
Wednesday
- 8:45 AM: Welcome
- 9:30 AM: Keynote
- 10:45 AM:
“An Introduction to Ruby Web Frameworks” (It’s going to be tough to convince me to move away from Django)“Changing Education… Open Content, Open Hardware, Open Curricula” looks more interesting today.
- 11:35 AM:
This one is tough, either “Web Graphics and Animations without Flash”, “Beautiful Concurrency with Erlang”, or “Beyond REST? Building Data Services with XMPP PubSub”, “CouchDB from 10,000 ft” apparently thats the thing see, or “What Has Ruby Done for You Lately?
- 12:20 PM: Really important, LUNCH!
- 1:45 PM: Probably “Thunderbird 3″, maybe “The Open-Source Identity Revolution”
- 2:35 PM: “Caching and Performance Lessons from Facebook”, never know when this one might come in handy working for Slide inc.
- 4:30 PM: “Open Source Community Antipatterns”, I’m really looking forward to hearing Ted Leung explain how to NOT run an Open Source Project…
- 5:30 PM: Probably “Give your Site a Boost with memcached”, or “Shell Scripting Craftmanship”
Thursday
- 8:45 AM: Keynote
- 9:30 AM: Keynote
- 10:45 AM: “Open Source Microblogging”
- 11:35 AM: “This is Your PostgreSQL on Drugs”
- 1:45 PM: “CSS for High Performance JavaScript UI”
- 2:35 PM: “Stupid Django Tricks”
- 4:30 PM: Either “Fixing Hard Problems Through Iterative QA and Development” or “Effective Software Development with Python, C++, and SWIG”, as I have worked with both speakers (Clint Talbert, Robin Dunn) respectively. OR “Machine Learning for Knowledge Extraction from Wikipedia & Other Semantically Weak Sources. This is a hard one..
- 5:20 PM: Couple interesting choices jump out at me here: “Code is Easy, People are Hard: Developing Meebo’s Interview Process”, or “Designing Political Web Apps for MoveOn.org” both could be really cool.
Friday
- 9:30 AM: Plenary
- 10:45 AM: “Toward a Strong Open Source Ecosystem” by Sara Ford at Microsoft? Interested to see what she has to say…
- 11:35 AM: Oh hell yeah, “Searching for Neutrinos Using Ope Source at the Bottom of the World”
- 12:30 PM: Plenary
- 1:30 PM: Plenary, Bye Bye’s
Off to the train to Seattle…
I am going to try a new thing using the Word Press app on my new iPhone 3G, to jot down small blog entries of points during the talks, then fill out the rest of the entry with more detail later.
It’s 2:41 now, so lets see if I can get to that 8:45 AM.. yowch.
Tags: Ajax, Code, Computing, Internet, Learning, Networking, Open, Oscon, Source, Technology, Travel
Permalink |
Posted in Career, JavaScript, Mozilla, Open Source, Python, Slide, Technology, Web, Windmill, Work |
No Comments »
• • • • •
July 11, 2008 by
As you all know — this morning at 8 AM PST, the new iPhone 3G was made available at Apple and AT&T stores on the west coast. Being a compulsive early adopter of such things, I somehow managed to tear myself out of bed around 6 AM this morning and head down to the Apple Store in Emeryville Califorinia. I arrived somewhere between 6:30 and 6:45 AM, and even though deep down I knew that it was going to be ridiculous — the whole experience still managed to be much crazier than I expected.

Approaching the Apple Store, every step revealed more and more people waiting in the line that stretched most of the sidewalk in front of the Emeryville Mall. In my relatively delirious state, I excepted the situation and joined Mikeal in the line. About 15 minutes into our wait the Apple Store staff, and Mall security people started alerting people at the end of the line (where we were) that the direction the line was building to the left of the Apple store was going to be in the way of the construction and that they would like everyone to move to the right side of the store, but to stay in the same order. Clearly this is an absolutely ludicrous request considering that no one wants to be there waiting in the line, and everyone will do whatever they can to jump a few spaces. I instantly started walking to the other side of the store where no one was yet, and we found a nice set of steps to sit on about 50 feet from the front doors of the store. Instead of people being annoyed by us, then went ahead and built a new line with us in it putting us significantly closer to the magical new phone than we had been before.
I do have to admit that the fact that the Apple employees were constantly walking up and down the line passing out water, answering questions and passing out necessary information did in fact distract us enough to keep me from losing my mind. The Pandora guys stopped by to chat, and gave out some pretty sweet hats. I have since tried the Pandora App on the new phone and it is really slick, certainly recommended.



Somewhere around 9:15 we made out way into the store, to be greeted by another line that lasted around 15 minutes before we could actually talk to a sales specialist to do the deed. This is where things started to fall apart for me. My sales specialist (who was a pretty cool guy) disappeared into the back and came back with the box for my new 16g white iPhone 3G and started filling out the hand held device to complete the sale. After inputting all of my information, a big yellow box pops up on his screen saying that I am not eligible for the AT&T price and that my only option is to pay the full $699 to buy the phone without a plan. Considering that I have been with AT&T since the acquisition of Cingular, and my having an iPhone with them for a year I couldn’t understand that the problem could be. Instantly I got AT&T on the line (which was amazingly fast to get a rep on a day like today) who proceeded to tell me that I had an overdue balance (due yesterday) and that I haven’t been with AT&T long enough to be eligible for the upgrade and thus will be required to pay full price.
In my delirious state, I considered just paying full boat so I could get the hell out of there — or cancel my plan and just be done with it all. Instead I asked about three times to talk to a supervisor (to which I was told three times that they couldn’t “Override any of the rules”). I do have to interject that she was polite and could have been much more unpleasant (T-Mobile, Verizon, lets not go there), and a few minutes later I was on the phone with her supervisor. You must keep in mind that my poor sales specialist is standing there, with my phone half rung up (probably there since 6 AM as well) looking at a long day of selling phones, dealing with unruly Apple Fans and possibly having to listen to many unpleasant phone calls to the carrier. The supervisor after a few minutes of back and forth about the situation, and the realization that I was standing here in this situation announced that “If I pay my overdue balance, I can get the discounted rate.”, Hallaluia!
I’m now all paid up and feeling like a dodged a serious bullet, and it’s time to head to the front of the store to open things up and activate the phone. A woman with a huge camera, filming this whole event asked me a few questions and recorded me opening the phone… which was sort of strange. I wonder if I’m going to be on TV somewhere! We plugged the phone in and whala — a big error pops up from iTunes. We unplugged the phone and tried about 3 more times (as did everyone at the table trying to activate), and then I was released to go finish activation at home.
I’m not an infrastructure guy by any means, but didn’t anyone learn ANYTHING from the last time around? Call me crazy, but I would have assumed that this time around the servers for activation would have been beefed up enough to handle the load. The best part is that as soon as I left the store and went to use my iPhone 2G to call people to let them know I had survived and was heading out I received a “No Service” notice, and was now unable to use either phone.
I basically sat from 10:30AM to 1:30PM trying about every 5 minutes to activate the new iPhone and received the ugly error each time. FINALLY, it went through — and I am back to a working state of communication.



To answer your questions, yes 3G is that much faster. The screen is a slightly different size, the device is lighter, and thiner and the buttons have been enhanced for more satisfying feedback. The camera looks exactly the same, but the Applications store makes it all worth while. I have been told that the phone has a GPS chipset, but for some reason one Application thinks I’m in Seattle and Google Maps thinks I’m in San Ramon — so there appears to be a problem there. One last quibble — every time the phone wants to use your location data, a dialog pops up asking you if it’s okay. I understand the reasoning behind this, but please please please let us turn that off, it’s getting super annoying.




The applications I have installed and are really enjoying include:
- Where, Yelp, Google, Facebook, Jott, Remote, CheckPlease, Pandora, Shazam, Evernote, Movies.app, NYTimes, Whrrl, Loopt, and of course — Twitteriffic.
There are many more apps and games that I am going to explore as soon as I get a moment.
Was it worth it? Of course it was — all this insanity is half the fun.
Tags: 2G, 3G, Activation, Apple, Applications, AT&T, Emeryville, Facebook, Fun, Google, GPS, iPhone, Pandora, Store, Twitter, Where, Yelp
Permalink |
Posted in Career, Location Aware, Review, Technology, Web |
No Comments »
• • • • •
June 27, 2008 by

What happened?
As some of you may have heard, today I resigned from my position at Rearden Commerce. Leaving a company is never a fun thing, because you know how you feel when you hear that someone else is leaving.. and you can see it in people’s eyes. I have reminded myself multiple times today that I am still going to be 30 mins away, most of my communication with those people has been via email and IM and there is no reason for me not to stay in touch.
Why did I resign?
That’s a very good question. Let me preface this by saying that I really don’t have anything about Rearden that I can point at and say ‘this thing’ is why I left. Rearden is a great company, they were professional through out my entire experience there. They employ many very talented and driven engineers, and they have a great product. My gut feeling after spending some time there, is that they will do very well. The management team is very skilled and they know their market and niche extremely well. Every day I went to work I heard about a new major deal or a small company Rearden had acquired to contribute to their march toward owning the ‘Personal Assistant’ space.
When I first arrived there I struggled with two things, and ultimately wound up being my demise as an employee. I have an extreme passion for Open Source, being part of that community, and giving my time to contribute. So you are probably thinking, ‘Why didn’t I just do that on the side?’ — well the answer is that I did do it on the side and the results were slow and my sleep schedule paid the price. Rearden has a very business/enterprise specific niche at the moment, and building and deploying new features to those customers is a priority (as it should be), but I couldn’t stop my Open Source envy.
Secondly, a overwhelming majority of their user base is using IE6. As a web developer — the last thing I do when building anything in client side JavaScript is to test it in IE6. I basically hold my nose, load the page and pray that things ‘mostly work’. Now I’m not going to claim that I can ever get away from doing this, but building really cutting edge features based on new technology becomes significantly less probable when you are catering to this crowd. I know that Rearden has some really cool future plans, and is publicly talking about bringing the application to the consumer market — but I’m impatient and I just simply didn’t want to wait.

What’s Next?
I am going to jump right into a gig with Slide Inc. as a Web Developer. However, before I get to any Web Development tasks I am going to be addressing a pretty serious need they have in their QA department. Slide currently has many applications that are used directly on their site, slide.com and on social networks (primarily facebook.com and myspace.com) and right now they have essentially no functional automation.

At OSAF I saw what a major difference automated testing can make, and the reason I am so excited about this is because I was a QA Engineer at one point manually testing a pretty complex web application (Cosmo) and I have seen how much a difference test automation can make in the release cycle, the development cycle, QA test cycles and simply the daily lives of your poor QA teams.

How am I going to accomplish this task you might ask? Thats the best part — I have fixed about 10 bugs in Windmill in the last week, and will be putting whatever effort is required into getting Windmill to a state where we can functionally automate all of Slides application testing. This looks to be a serious win for Slide, and a serious win for Windmill.
At some point in the future, when I feel that this project is to the point where it can be maintained and built on by the Slide QA teams I will move on to Web Development tasks. At that point a smaller amount of time will still be allocated to maintaining Windmill, adding new features that Slide and the community need and working towards the next evolution of Windmill. That is quite a ways off in the future, so I will address all that when the time comes.

The rest of my ‘free’ development time, will be consumed by a project that I am involved in with the Mozilla Corporation. This project lives in the QA realm as well, and could probably be classified as a distant cousin to Windmill. More details about that will be announced the week of OSCON, so keep your eyes pealed.
Change can be extremely tough, but it is also very exciting. I want to thank all of my former peers at Rearden for a good experience, and I wish them all the absolute best.
Tags: Automation, Commerce, Communication, Developer, Employ, IE6, internet explorer, JavaScript, Mozilla, Open Source, OSAF, Plans, Position, Professional, QA, Rearden, Rearden Commerce, Resign, Slide, Slide Inc, Testing, Web, Windmill
Permalink |
Posted in Career, JavaScript, Mozilla, Open Source, Plans, Slide, Startup, Technology, Web, Windmill, Work |
3 Comments »
• • • • •
June 25, 2008 by
As a web developer you are probably aware of that sinking feeling in the pit of your stomach that you suffer when posed with the idea of testing your freshly written JavaScript that works perfectly in FireFox.
For years now, we have had to ‘suck it up’, and pour a glass of scotch to get through an afternoon of testing in IE. As I am now a Web Developer at Rearden Commerce who currently caters to an audience of enterprise users instead of your standard bay area geek population — I have to make sure everything I commit works nicely in IE.
Last week after a few hours of IE testing, and dirtying my code I worked so hard to perfect and refine with alerts everywhere I decided that there HAD to be a better way to do this. I went ahead and spent many hours searching the web, installing everything I could find that promised to make IE development easier and happily I can say — it was a success.
First and foremost however, there are a few tips I can give you right off the top that will make your life easier. Before you take the plunge into line by line alerting, go through your code and do the following;
* Remove unnecessary commas in your data structures:
( FF ignores this one, but IE will give you an error that isn’t helpful )
ex.
var superNinjaObject = {
me: 'adam',
home: 'oakland',
};
* Don’t try to access characters in a string as if it was an array:
( Works in FF, but IE will simply give you undefined and not tell you a thing )
ex.
var myString = 'Welcome to the Jungle';
$('mynode').innerHTML += myString[14]; //Broken in IE
$('mynode').innerHTML += myString.charAt(14); //Compatible alternative
Now we can get to what you are really interested in, the new tools:
1. Internet Explorer Development Toolbar
Get It: Microsoft Downloads
This is Microsoft’s best stab at a firebug equivalent. This gives you all the flexibility you need to inspect the DOM tree, look at CSS, Scripts, Images, Network etc. To put it simply, it makes IE development something you can swallow. I can’t image going back to IE development without this. Unfortunately it is missing two things, the first is the absolutely necessary JavaScript shell. This can be solved by using the IE JS Bookmarklet that you can find at blog.monstuff.com. Add this to your favorites and then whenever you need a JS shell, pop this up and hack away ( I agree it would be nicer if it was built in ). The second is the ability to set breakpoints and step through your code debugging and introspecting objects and variables. I do have a solution for this, see new tool number
2. Visual Web Developer 2008 Express Edition
Get It: Microsoft Express
This is the solution to your break pointing, stepping, introspecting needs. The way you use it is a bit awkward, but it does complete the development experience. To use this you need to create an empty web project and then start debugging. This will launch IE and bring you to a blank server page off the local MS web server instance. At this point you can go ahead and plug in the URL of the app you are wanting to test. Additionally if you have set any ‘debugger;’ statements in your source it will pick that up and automatically ask you if you want to start debugging there, or continue on. When you stop the debugging session in VWD it will kill your browser, so beware if you have to navigate to some deep point in your app you are probably going to get frustrated if you write buggy code.
At it’s 1.4 Gb space requirement it’s hardly a comparison with firebug — but it’s certainly a step up from alerts all day long.
3. Microsoft Script Editor
Get It: Jonathanboutelle.com
If you don’t already have it installed, a good midpoint between nothing and Visual Studio Express is the Microsoft Script Editor which comes with office 2003, heres a video on how to use it, Video. Thanks for the feedback blogosphere.
I hope this made your life at least a small amount easier, happy IE developing.
Tags: Code, Debugging, Development, IE, JavaScript, Pitfall, Source, Syntax, Tips, Tools
Permalink |
Posted in JavaScript, Open Source, Technology, Web |
No Comments »
• • • • •