Creating GUIDs in Two Steps or Less
Posted on April 23, 2008
Filed Under python, development, .Net | 4 Comments
If you happen to find yourself needing to create a GUID for your brand new C# program, a Google search for “Create GUID” is the first reasonable thing you might do. Here’s my summary after doing the same…
First off, in the “Truth in Advertising” department, the best link from the top 10 was “The Quick Guide to GUIDs” at betterexplained.com.
But the rest of the top search results seemed overly complicated. Guidgen.exe is a clunky little program, and I had to do more searching just to find where to download guidgen.exe. I’m using Visual C# Express, and “Create GUID” was not available from my Tools menu, as the MSDN link about guidgen.exe suggests it is. Since the really simple way was not obvious in the top search result (betterexplained.com was seventh), I’m hoping to change that in my own little way with this blog post.
The Simplest Way (as mentioned in the betterexplained.com article above):
- Go to http://www.famkruithof.net/uuid/uuidgen
- There’s no step 2!
Alternative Way #1 (found via a simpler Google search for just “GUID”)
- Go to http://www.guidgen.com/
- There’s no step 2!
A Simple Way with CPython (alluded to in the betterexplained.com article):
- Install Python 2.5 if you don’t have it already. (Download from python.org)
- Open a command prompt, and run the following:
c:\>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from uuid import uuid4 >>> print uuid4() 927a36e2-4c9f-4235-a3f3-ebedbadf48c3 >>>
- There’s no step 3!
Another Simple Way with IronPython:
IronPython let’s you easily play around with the .Net libraries. If you’re doing .Net development, IronPython is indispensable.
Prerequisite: You already have .Net installed. Consider this “Step Zero”. This is already taken care of if you’re developing with Visual C# Express. (Hey, by the way, Microsoft, thanks for making your compilers free, finally! :-)
- Download and unzip the IronPython binaries. (Download from codeplex.com. Latest is 1.1.1 as of 23 April, 2008.)
- Open a command prompt, locate ipy.exe and run the following:
C:\>applications\IronPython-1.1.1>ipy.exe IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.1433 Copyright (c) Microsoft Corporation. All rights reserved. >>> import System >>> print System.Guid.NewGuid() e70e472a-365d-45fc-9bfa-6665e27dc5bd >>>
- There’s no step 3!
That’s it! Happy GUIDing!
Testing — Mission Impossible?
Posted on April 4, 2008
Filed Under testing | Leave a Comment
People still do that?! :-) No wonder “testers” get such a bad rap. Their mission is literally impossible.
A web 2.0 app for uploading and running remote Python code snippets?
Posted on March 13, 2008
Filed Under python, development | 5 Comments
I know I read about this on reddit within the last week or so… But I just can’t find it! My Google-fu is failing me! Grrrrr. There was a general upload text area form where you copy in your code snippet. You then select the language from a drop down, and click submit. In the commentary on reddit about this service, the author talked about all the things he did to keep his machines safe from attack, including using virtual machines, code jails, and refreshing both the host and the VMs frequently. I can remember a bunch of keywords from the comments, but apparently there is no comment search at reddit! (And a google search with “site:reddit.com” didn’t work either.) If you remember seeing this, too, let me know!
Update: Thank you, Internets! Codepad.org is the answer. (Though UtilityMill.com looks similar, too.) Here’s the original thread on reddit that I was looking for, too.
Annoucement: Selenium Users’ Meetup - Monday, February 25 2008
Posted on February 20, 2008
Filed Under selenium | Leave a Comment
I’ll be attending the Selenium Users Open Evening this Monday, February 25. The event will be at the Google campus in Mountain View, California. Most of the core Selenium development team will be in attendance, traveling from as far away as Tokyo and London. Here’s a blurb about it from the sign-up page :
With representatives from all the major Selenium projects on hand to present ideas, discuss the future of Selenium and answer audience questions, the Selenium Open Evening is an opportunity to get involved in the future of the project. With Selenium developers from as far apart as London, Tokyo and the US and Lightning Talks on related subjects, this is a great way to meet Selenium users and meet some of the other brightest minds in web testing and Agile development!
And here are the important event details:
Monday, February 25, 2008 6:30PM PST to 9:00PM PST
Google Campus, 1600 Amphitheatre Pky, Mountain View, California
Upon arriving, please proceed to reception in building 41 and ask for directions to the Selenium Users Open Evening.
Oh, and did I mention free food? And I’ll be signing autographs, too! :-)
If you’ll be in the Silicon Valley on Monday and love or hate all things Selenium, please sign-up now!
This is why I love JavaScript and Python, but not Java
Posted on January 29, 2008
Filed Under python, development, javascript | Leave a Comment
“Exploratory programming is the fun end of programming, and we hope that will be the guiding principle of the Arc community.” (arclanguage.org)
Amen! (And when I do have to work with code on the JVM, it’s via Rhino or Jython.) I don’t know how much I’ll use Arc in the future, but I already like its attitude.
Me at Google - the 10 month update
Posted on November 9, 2007
Filed Under personal, selenium | 2 Comments
[update: yeah, I’m lame. Jan 24 to Nov 9 is (rounding up) 10 months, not 11.]
Well, since last I posted… (~10 months!) I’ve been pretty busy. I started at Google eight months ago on March 5th, and so far it’s been great.
In April, I finally got to meet-up with several members of the core Selenium development team, specifically, Patrick Lightbody, Dan Fabulich, Nelson Sproul, and Paul Hammant. Paul and I go way back… See, I started Selenium Core, but he started Driven-now-known-as-Remote-Control. And RC is the flavor most heavily used at Google, so I owe all my future earnings to him, or so he thinks!
In May, I attended CITCON North America in Dallas, and led an informal talk on “The One True Programming Language for Writing Tests” (Slightly tongue-in-cheek, I was hoping for a good Python-vs-Ruby fist fight — I’ve missed those since leaving ThoughtWorks. :-)
In June, a “Short Cut” on Selenium was finally published. Many thanks to the hard work of Titus Brown, Grig Gheorghiu (co-authors) and Mike Loukides (our editor). Titus, Grig, and I are on the hook to write a few more of those, so stay tuned.
Hmmm… what else? I was interviewed on the Google Testing Blog in September. And I made a few presentations, once at the Google Developer Day back in May, and twice at the Google Test Automation Conference (GTAC) in September.
GTAC was especially fun. Jennifer Bevan and I publicly announced the “Selenium Farm” — work Google has been doing to improve and build upon Selenium RC, specifically making a multiplexed “farm” of many, many Windows, Linux, and Mac machines for teams, like Gmail and Docs to run their tests against. Selenium has become a standard (but not the only, of course) web testing tool for many high profile Google Apps. Gmail, for example, was able to bring their test time down from 40 minutes to 4 minutes by using the Selenium Farm. Cool! So, if you ever find a bug in Gmail, be sure to file a Selenium test for it for faster service. :-) As it turns out, though Google’s Selenium Farm has not been open sourced, yet… But a few crafty ThoughtWorkers saw the YouTube movie of our talk and started to work on a clean room implementation… A month later, the “Selenium Grid” is open sourced and available now! It’s slightly different than Google’s internal farm, but the high-level concepts are the same. I look forward to continuing the work I outlined in my GTAC presentation (this time with the open Selenium Grid) and use dozens of machines on Amazon’s EC2 cloud to bring down Selenium’s own build time down from the current 25 minutes to something more manageable in the 2-4 minute range. (It’ll also be nice to have a shareable Selenium grid client on EC2 for anyone to use in their own web test builds.) Also at GTAC, I got to debate Simon Stewart (also a former ThoughtWorker, and now Googler) on the topic of “Selenium vs WebDriver — the Steel Cage Knife Fight“. (If you want a chuckle, watch the last 30 seconds or so of that one.)
And lately, I started a “Makers” (as in “Make magazine” Makers) group at Google. For our first project, we’re working on something which will sound quite familiar to many agile teams. As you’d hope and expect, agile and testing are big here… and of course, every agile team needs to have some kind of cool, highly visible gadget to show off their build status. To that end, I’m working to put together some Do-it-yourself kits based on the Arduino board. The best example of this is explained in Arduino tutorial #3 at ladyada.net. In the spirit of Google’s roots, I’m sure there will be a few Lego blocks in there, too.
Feeling lucky… From ThoughtWorker to Noogler
Posted on January 24, 2007
Filed Under development, personal, selenium | 9 Comments
Well, I’ve had six wonderful years in the land of Thinking and Working (aka “The Martin Fowler Company“). Today, however, is my last day at ThoughtWorks. I’ll be packing up my home in Chicago and joining Google in Mountain View starting in February. My official title there will be “Software QA Engineer“, which is ironic, because no serious software tester goes by the title ”QA Engineer”. So I won’t either. Just call me a developer-tester, please!
On that note, it just so happens that Google is a huge fan of Selenium for browser testing their web applications. According to veteran Googler Goranka Bjedov, “Google projects use open source tools, and Selenium in particular for their testing projects… Selenium is well regarded and people who use it are very happy with it.” Hey… I’m happy they’re happy!
It has been fun working with so many prolific and talented open source coders at ThoughtWorks over the years, and I look forward to being equally amazed by my fellow co-workers at Google. Well, at least until a position at NASA or Lego opens up. :-)
A new litmus test for evaluating Python web frameworks — What’s your security policy?
Posted on August 10, 2006
Filed Under rails, python, development, django | 16 Comments
With the almost daily announcement of new Python-based web frameworks, there needs to be a way to filter the contenders from the pretenders. I’ve been mulling over the idea of compiling a checklist for evaluating new frameworks. The checklist could also be used by new would-be Python framework creators as a gut check for the things they are now responsible for if they expect the world to use their software in any serious fashion.
The recent security hole in Rails is interesting, not because there was a security hole, but because it looks like there were no (or, at least, not well-known) policies in place on how urgent information gets communicated and exactly what the expectation is for how far back the Rails Core team will provide security patches.
So to jump start my web framework evaluation checklist, I’m adding “What’s your policy on how you deal with security holes” to the top of the list. Django is pretty up-front and clear with their stated policy. Importantly, they explicitly state they will support patches for the current release at that time and the two previous releases. I’m still a little fuzzy on how much time is covered by “a current + 2 previous releases” policy. And I’m also a little fuzzy on exactly where I should look to be notified about such an event. But already, Django’s explicit policy is better than Rails implicit policy of “upgrade now, cause you should have been keeping up-to-date anyway.” Given the recent announcement of Rails shipping with Mac OS X - 10.5 (Leopard), how security issues are dealt with and disseminated becomes even more important to get right.
Many open source projects have low-volume, read-only mailing lists explicitly set-up for these kind of announcements. Granted, security ain’t easy and there is much debate on how to do it right. But if you’re a would-be Python web framework author, seriously consider how you’re going to deal with security vulnerabilties when you go-live.
On that note, help me flesh out my web framework evaluation checklist! What question would you add? And don’t say: “But does it scale?” :-)
On Selenium and language design…
Posted on August 1, 2006
Filed Under development, selenium | Comments Off
Lately, I’ve had language design on the brain. In short, I’m working to make Selenium tests Turing complete. Right now, the Selenium Core engine can parse simple command/key-word tests. No looping or conditional logic is provided, natively, out of the box in Selenium Core without using a user extension, like flowControl. Not that it’s a bad thing, this “limitation” is also considered newbie-friendly simplicity by many users of Selenium. (Here, I’m talking about the in-browser core of Selenium, you can get all kinds of Turing complete testing goodness using Selenium Remote Control on the server side with Java, C#, Ruby, Python, or Perl.)
I’ve had early success integrating Brendan Eich’s excellent Narcissus JavaScript engine into Selenium. Narcissus is pretty darn useful. It is a living breathing JavaScript interpreter for the browser. Now why would I need to use a JavaScript interpreter written in JavaScript to make Selenium Turing complete? In short– blocking code. In “Plain Old JavaScript”, you can’t easily tell the browser to pause the execution of JavaScript code while the browser loads a new page, then continue on with the rest of the script after page load. Sure, I can do some of this with Ajax or iframes, but the amount of boilerplate event listener code involved is quite ugly, and gets in the way of writing simple functional tests for web apps, which is the whole point of Selenium’s existence. It looks like the Narrative JavaScript project was created for this same reason, and it also (!) uses the Narcissus engine to work its magic. The difference here in what I’m doing vs what Narrative JS is doing is that my code doesn’t require a server-side compilation step. “Selenium JavaScript” is all done in the browser.
I’ve also dabbled with extending Narcissus and reimplementing my favorite language of all time– HyperTalk– in JavaScript as a syntactically sugar sweet “super-set” of JavaScript, so I’ll have a ‘native-in-the-browser’ testing language for Selenium (a ‘DSL for testing’, if you will), with no server-side dependencies (like Ruby, Java, Python, etc.). But this is slower going — getting HyperTalk parsing rules right and catching all the corner cases can be tricky. So just shipping plain old JavaScript support for the Selenium Core is the pragmatic thing to release for the moment. Even more pragmatically, with Plain Old JavaScript support in Selenium Core tests, it’ll be rather straight forward to port the Watir API to Selenium JavaScript for in-browser tests. I hope this raises a few eyebrows and generates some smiles with the Watir developers. :-)
On a side note, I’ve found A Pattern Language for Language Implementation (PDF) and the Little Languages blog incredibly useful as I grapple with the issues of language design and parsing techniques. At ThoughtWorks these days, writing DSLs in Ruby is all the rage. And with good reason, Ruby is very useful for prototyping your own little language. A few years ago, everyone was talking about design patterns. So design patterns for DSLs?! Man, I can’t imagine the cocktail conversations this is going to generate!
JavaScript is the new C
Posted on July 21, 2006
Filed Under development | 7 Comments
A thread came up last week about JavaScript on the Rudolph Hering Society list. I promised to repost my thoughts as a blog post for a larger audience to dissect:
Dave Hoover wrote:
Not everyone hates JavaScript. After digging deeply into (Chicago resident) Sam Stephenson’s wonderful Prototype framework, extending it, and using it extensively, I can honestly say I enjoy working with JavaScript.
I came to a similar point in the development of Selenium. I hated JavaScript enough because of browser compatibility issues to write a testing tool to fix it. But at the same time, I liked JavaScript enough because it let me do spiffy things in the client. Alas, I decided to write a testing tool… Sam took a different path and wrote a code library, instead. But the motivation was probably the same.
To kinda hate something at first, but then grow to love it… I believe it’s called “Stockholm Syndrome“.
I agree when Dave said, “At least for now, I’d rather deal with JavaScript directly than have it generated for me by another language.” But I don’t claim that dealing directly with JavaScript is right or necessary for everyone. For example, Python, Ruby, and Perl are really written in C under the hood. But only a handful of people in the world really need to know C. I’m happy I can go years without having to look at any C code whatsoever. I suspect most of the world feels the same way about JavaScript. Guido and Matz are to C as Sam Stephenson is to JavaScript. They are all-stars because they liked C/JavaScript enough to be productive in it, but also hated it enough to write a more productive higher level tool so the rest of the world wouldn’t have to do the same.
However, when you write to the C platform, everyone can talk to you with ease. For example, there have been lots of ‘mini’ SQL database engines implemented for every language. Gadfly is the one I know about for Python. HSQL for Java. But SQLite is becoming quite popular across all languages because it is “100% Pure C”. So support and docs get better because a larger community of developers can make use of the code. Another example– YAML libraries…. Because _why wrote Syck as a C library instead of Pure Ruby, I get to use his code in Python quite easily. C gets you language binding to all the higher languages quite cheaply.
In a similar fashion, because Sam’s Prototype library is 100% JavaScript, it’s now used by PHP, Ruby, Perl, Python, Java, and .Net shops. And that’s the best empirical argument I can think of that JavaScript is the new C.