Alt.Net

TestSwarm Retrospective

Yow-Hann Lee — Thu, 27 Aug 2009 10:42:54 GMT

Back in March, I came across John Resig's articulate post about the pain of frontend testing in general. Unvealing the dirty "secret" that no one likes to talk about but everyone has to deal with at some point in development. But unlike other folks' rants on this topic, he proposed a solution that would tackle this and take advantage of the internet audience. I was very much looking forward to his architecture diagram coming to fruition.

The TestSwarm source is now available on GitHub. The interesting parts are here and repositories for libraries under test are here. By the way, GitHub is awesome; albeit, it would be cool if it had permalink for generating friendly url for linking purposes.

Granted, this is still in fairly early stage, but there is great potential for a distributed testing environment. Having said that, testswarm.com itself may have a harder time getting the entire spectrum of users/browsers as its audience will most likely be developer/techie folks. However, perhaps the spirit of this effort can live on in public sites that are highly trafficked?

For example, if a user with a specific browser agent comes in, you could either display a link to TestSwarm and politely ask them to participate in these efforts OR ask them to participate in a local "TestSwarm" instance that will also run through your own js aside from shared js.

Back during the myspace days, I would come across all sorts of user agents. Some were obviously bots whereas others were legit but unexpected scenarios. Who would've thought at the time that there'd be decent # of users accessing myspace on their PS3? Not that a dev shop would want to be in a reactive mode of fixing things post-production push, but this could fill the niche of covering environments that shops simply don't have available. The hope is that this is a win-win situation for both the user and the site (and potentially rest of the internet community). Lots of exciting stuff coming out from Mozilla with this and Bespin. Outside Mozilla, looking forward to seeing the latest mobile results from QuirksBlog.

Hiring Services and Web Developers at ArenaNet

Yow-Hann Lee — Tue, 24 Mar 2009 21:06:24 GMT

Recently, I wrapped up my duties as a lead developer at myspace and headed to ArenaNet over in Bellevue, Washington. My team is hiring and we’re looking for awesome services and web developers. If you’re looking for a new challenge and would like to be part of the next Guild Wars gaming experience, check out the descriptions at:

Services Programmer

Web Developer

And you can hit me up at yow-hann at arena dot net. Hope to see some of the GWB community folks out there!

Seattle Code Camp v4.0

Yow-Hann Lee — Tue, 21 Oct 2008 21:06:19 GMT

Seattle Code Camp 2008 is once again held at the DigiPen campus. I never got around to recapping the one held earlier this year (v3.0) but have recaps of v2.0 here and here.

Check it out at: https://seattle.codecamp.us/default.aspx.

ALT.NET Seattle Summary

Yow-Hann Lee — Tue, 22 Apr 2008 16:35:48 GMT

Jeremy Miller, Ted Neward, Charlie Calvert in the Fish Bowl.

Fortunate to get the email invite after being on the waiting list, this turned out to be a tremendous experience with participants such as Martin Fowler, Brad Abrams, Jon Lam, Scott Hanselman, Phil Haak, Scott Guthrie (sneak peek), Roy Osherove, the list goes on.

Jeremy Miller convened a talk on the growing pains in dealing with an evolving system over the years. In his development of StructureMap, he highlighted some anti-patterns that caused him much grief (i.e. simple duplication leading to a great headache during refactoring) as well as some principles that saved his bacon (i.e. open close principle, tell/don't ask, double dispatch, etc). What intrigued me was that two of the most qualified individuals (Martin Fowler and Brad Abrams) in the open space did not dominate the discussion and focused on listening to the trials and tribulations of the developer. In a relaxed environment, I saw a level of respect for fellow developers.

The JavaScript Session convened by Eleutian folks churned for a bit with some philosophical debates. But it did turn out with people sharing their pains/experiences developing javascript heavy applications. One guy was highlighting his experiences starting off with a Ajax/DHTML application and subsequently scrapping that for Flex and highlighting pieces that were reusable.

What actually stuck out for me was a VS2008 plugin tool from Justin Angel. Though not yet refined, I'm hoping he makes this publicly available. I think we can all agree that the tooling for javascript is lackluster and this was an attempt to improve some of the DX during his Silverlight 1.0 development days. UX being User Experience; thus, DX shall be the Developer Experience. Yes, it's all about agility. Just like how users don't appreciate un-intuitive and unresponsive UIs, developers also seek that constant feedback mechanism. Nothing like an empty error list or a list of green lights to validate your development contributions.

I was somewhat surprised to see only 5 people in attendance for the PEX talk: Roy Osherove, two Microsoft employees, another attendee and myself. I suppose it's a hard sell when you have Scott Hanselman speaking at the same time slot. Albeit, this talk was no slouch either with the creator of MBUnit, Peli de Halleux and the guy who started this up, Nikolai Tillmann. I had heard about this project and was initially skeptical but was ready to get my hands on this at the end of their demo. As you can probably imagine, this isn't just a random test generator. There are attributes allowing you to specify your object of interest. As PEX avoids branching into BCL and testing the framework, I can see this going further to exclude in-house components. Regardless of this, Roy verified with Peli the ability to mock objects. This is the type of tool you can simply setup and distribute the workload amongst your spare machines. While there is a lot of potential here, there are also two major brick walls:

Lack of support in multi-threaded testing as each test executes on a thread. Although, this problem isn't specific to PEX or its concepts and is a general debugging/testing problem.
There is no ship vehicle for this nifty project. This means that only Microsofties can play with this on codebox right now. Productizing is a long a windy road (strangler application anyone?).

Other highlights included a conversation on Next Generation Architectures and another conversation on Scaling Agile Development. This composed of about 10 people describing their experiences running an agile shop and enforcing different strategies. Finally, Jon Lam's talk on IronRuby was a great example of testing suites in action. To maintain its Ruby Roots, the folks have taken the testing suites of Rubinious and made it pass against IronRuby.

Jon Lam on IronRuby

Aside from all of the above, personal takeaways from this conference include:

Learning more about IronRuby and picking up on new idioms via reading the code of these native speakers
More on Dynamo
Playing with Framework Design Studio Brad spoke of
Learning how to PEX IT!

Looking forward to more of these in the future.