Using modernizr to help with canvas

On my current project I've been using a little bit of the HTML5 Canvas element to provide a little bell/whistle. However, the problem with Canvas is that not all browsers support it. Out of the box though Canvas gives you a quick and handy way of dealing with that problem:

<div id="content">
    <div id="demo-space-wrapper">
        <canvas height="100" id="demo-space" width="100">
            This text is displayed if the client browser does not support HTML5 Canvas.
        </canvas>
    </div>
</div>

The problem with this approach is that if your layout expects to have an object there and your client's use of Internet Explorer doesn't include the Canvas extension then this could damage the overall feel of your layout.

And that is where Modernizr comes in to play. It is a trivial to use JavaScript library that makes it possible to detect if a browser can use Canvas or any other HTML control. So what I did was take the Modernizr Canvas detection documentation and apply it to my JavaScript. With that in hand I wrote this:

// check for canvas
if (Modernizr.canvas) {
    // We have canvas so add a rectangle
    var demospace = document.getElementById('demo-space');
    var context = demospace.getContext('2d');
    context.fillStyle = "rgb(255,0,0)";
    context.fillRect(10, 10, 10, 10)            
} else {
    // No canvas. Remove the layout space to preserve the layout.
    var ul = document.getElementById('content');
    var li = document.getElementById('demo-space-wrapper');
    ul.removeChild(li);
};

Code highlighting on blogger

Thanks to Luka Marinko I have code highlighting now!

def python_funct():
   a = a + b
   print "Hello Highlighted code"

class Foo(Bar):
   pass

Steve Holden giving a talk on Python education

Steve Holden, Python Software Foundation chairman and all around decent guy is giving a webcast talk today at 1 pm PST (4 pm EST) about the O'Reilly school courses on Python and the upcoming O'Reilly Python certification programs. Check out the O'Reilly promotional page:

Steve Holden's Webcast

Some quick notes:

1. Steve Holden is a marvelous speaker and a great wit. Even if you don't do Python and aren't a geek its worth listen to him talk. Leaving the DC area means I won't get the chance to sit at his feet and absorb his magnificent wisdom.

2. In certain ways, I believe Python needs these kinds of certification programs. The lack of certification or any paper validation of python skills means that a number of large and conservative organizations are often hesitant to use Python. And one way to make those organizations more open to using Python is certifications. Its not the only answer, and its an answer that comes with its own set of problems, but I think that Steve and O'Reilly are a really good choice for overcoming these problems.

3. I helped Steve write the Python 1: Beginning Python. So by attending you will be supporting my work too. :)

Moving away from DC

Way back in 1969, when I was about a year and a half old, my family moved to Laurel, Maryland, which is about 20 miles north of Washington, DC. Since then, I've lived in central Maryland, Washington, and Northern Virginia. I enjoyed my friends and family, and the things that I've done.

Yet I always wanted to see the rest of our world, try new things, explore new horizons. Breathe different air, if you will. My ideal existence would be to live in a lot of different places, living six months for a time in place to place so I can get a good experience of the planet.

Not long ago conditions came together that made it feasible for me to do all this. My house is sold, my son is 18, I don't currently own any furniture, and I have a job that allows/encourages for telecommuting (and that is because of Python and Django).

So on May 5th I'm moving to Los Angeles, California for a short term stay. I'm there to hang out with a certain artist/developer and to go on a vacation that I've wanted to do for many months. More details on this move in another post.

In early June I'm moving again to Lawrence, Kansas. I've got a number of friends there, but much more important are the professional reasons. The entrepreneur for my start-up will be living not far from there, Revolution Systems offered me office space, and the cost of living is amazingly low. Another nice feature is that its in the central point of the USA, so flying anywhere on the continent doesn't take that long.

I'm very excited, but I'm also sad to go. I'll miss being near my son, my parents and siblings. I'll miss all my DC area friends, who are way too numerous to list. I will certainly miss all my students, young and old, not to mention the other teachers at OMAA.

I will be coming back in late June, and then perhaps in either late July or August. And who knows, maybe someday my travels will bring me back to the Washington, DC area for an extended stay?

Leaving NASA

This has been a hard post to write.

I was delighted that on January 3rd, 2005 I started my first day working for the National Aeronautics and Space Administration (NASA). While I wasn't working on science efforts, I was at least contributing to the cause. In 2005 I was introduced by co-worker Chris Shenton to Python, which became my favorite programming language ever. I also learned tools like Zope, Plone, and Django. Over the past five years, I've met a lot of fascinating people in and around the agency, a list that seems endless in size and scope. That includes astronauts, scientists, engineers, developers, managers, and so much more.

This meant so much to me, and maybe because my first memories of television as a child were the moon landings of the early 1970s. I dreamed as a child of being an astronomer or astronaut, and sometimes I plot how I would redo my life to fit these dreams if I got a second childhood.

In the past year I've had some incredible opportunities present themselves to me. I've been presenting frequently on Django and Pinax. I've had the singular honor of writing course material for Holdenweb, LLC on behalf of the O'Reilly School of Technology. Representing NASA as a contractor to the Python and related communities has been both enjoyable and a great honor.

Yet all things, even good ones, must come to an end.

I've decided to become an independent consultant. My first project will be working with Revolution Systems (Jacob Kaplan-Moss and Frank Wiles) on a neat stealth project that looks very promising and once launched will help people. The project will be Python/Django/Linux based, and the client insists on accessibility, testing, and quality work. We'll be exploring the boundaries of what has been done with those tools and besides what must remain proprietary, a lot of our work will end up going back to the community. Sounds like my kind of thing!

My last day is April 1, 2010. I'm both excited to explore this new project, and saddened that my professional world for the past five years is coming to an end. Yet the overlap in technology and the participation of the NASA SMD python group in the open source world means that my work with NASA isn't coming to an end, its just transforming into something different.

Nevertheless, this is the end of an era for me.

Which is partly why I'm happy that I'll still be in touch with my fellow NASA SMD Python contractors such as Katie Cunningham, Chris Shenton, Chris Adams, James Saint-Rossy, and others. I also plan to be real friendly with the awesome Ames Research Center Python/Django/FOSS groups such as the intrepid Mark Friedenbach and the entire incredibly awesome Nebula team.

I'll miss having the pleasure of working with Leslie Cahoon, Jessy Cowan-Sharp, John Kasmark, Bob Ryan, Candace Solomon, Bill Keeter, Gamble Gilbertson, Meredith Mengel, Malik Ahmad, Jenny Mottar, Mike Brody, Virginia Butcher, Dawayne Pretlor, Michele Montgomery, Jim Consalvi,Siew Chin Hon, Hans Goetzelt, Shannon Lantzy, and many more.

Lastly, I'll miss the honor of serving civil servants such as Gretchen Davidian, Sharron Sample, and Ruth Netting and others.

Pycon 2010 report III: Sprints

My report for the sprints of Pycon 2010. This isn't a general review of the sprints, just how it affected me.

Pinax Sprint

I don't have a hard count of how many people participated on Pinax this year. Last year's sprint looked like we had a lot more, but last year the Pinax room was home to people doing other things, albeit mostly Django related stuff. In any case, this year we had probably about 10 people working on Pinax, or things that went directly into Pinax.

While James Tauber is the leader of the Pinax community, this year Brian Rosner stepped up and did an amazing job being both a technical resource and director of geeks. The mutual clarity of vision and obvious telepathy between Brian and James is truly a joy to behold.

I also appreciate the entire Pinax community. Besides coaching me on Git branches (work uses SVN so I just don't get enough Git practice) they also gracefully understood that I was a bit distracted this year.

My specific contributions to Pinax

One of the things that had bugged me about Pinax for some time were the individual project tag apps. These were a per project extension of django-tagging, and were used to simply display tagged data. I was never happy about the displays of the tags, the lack of pagination, or that you had to create/modify an entire project level application just to control a display.

So last DjangoCon I wrote django-tagging-ext. What it does is let you control the displays of tags via a root urlconf wiring. It still needs some work (cleaning a query, 100% test coverage, better documentation), but its a big step up from the alternative.

For Pycon I volunteered to go into all the Pinax projects that used tags and replace the tag_app there with django-tagging-ext wiring. I thought it would be relatively trivial, but in practice it was not.

The issue was that immediately prior to the conference, changes had been made to Pinax trunk that caused a small number of errors. All them passed existing tests but failed when you actually clicked through pages. Yeah, that does mean that Pinax code coverage needs improvement, but that is something we are working feverishly on. In any case, what that meant was that by implementing the new tag display system, I got the chance to fix a number of small but poignant bugs.

I also worked some to help the code coverage of tests. Brian Rosner worked with me and gave me some excellent pointers. I feel sad because I think we had a disconnect on what we consider pair programming, and want to assure him that the time he gave me was a high mark of the conference.

In regards to pair programming, I don't mind working with someone until you figure something out, but spending hours and hours sharing a computer drives me nuts. Once a person 'gets it', go do something else and let them go forward.

Volume of Contribution

Looking at the Pinax impact chart on github I can claim that I had the most impact during the sprint. Heck, I even jokingly claimed it on Twitter.

Except that claim is false.

The truth of the matter is that how many commits I did in a brief period is nothing compared to what Brian and James did to equip others to make commits. Or what they've done during the history of Pinax. Or what they might have done to side projects that touch Pinax. Also, during the sprints my work was really focused to a specific area of Pinax, and besides some work I did with Skylar Saveland, I worked mostly by myself.

So that claim is full of hubris and rather silly. If that claimed annoyed anyone in the Pinax community I'll buy your forgiveness with a beer.

Conferences are a double edged sword

This post isn't for developers, its for managers.

In the Python world once a year there is Pycon. In other languages, tools, and frameworks they all have that one big conference where all the top people go. There are classes, tutorials, scheduled talks, open spaces, keynotes, and tons of networking. All your developers will want to go, and the ones that do will rave about the time they had. So how do you as a manager handle a big conference?

Conferences are a double edged sword. If handled well they will be a huge boon to you and your organization. Handled poorly and they can be devastating to you, your projects, your team, and your organization. Knowing which way to swing the 'conference sword' in such a way that you don't get cut is a handy tool to have in your pocket.

First, remember that at the big conference there will be lots of networking. Make sure your developers are really happy with you before they go. Also have your developers go with business cards. Ask them to bring back business cards. Remind them of whatever referral policy your company might have. Why pay for a headhunter when your own staff can do the hiring for you?

Second, remember that people will be scoping out your staff for potential hire. Don't anger your developers immediately before, during, or immediately after a conference. Keep deadlines as far away as possible from the conference. Don't begrudge them leaving and task them with petty work. Because what would have been training plus an energizing break for your staff will now be considered job fair by your staff.

Third, try to cover even a portion of the costs of the conference. If your organization doesn't officially do conferences, then offer to pay for their time during the sprints just so long as that open source work even tangentially affects what they do back at the office. That way they don't use up so much leave and odds are they'll have lots of smart comrades around to help them through some of the tricky parts.

Fourth, when the developers come back, ask them what they learned. Ask if they can incorporate these lessons into current or future tasks. They'll gush about twenty new things and most of them will be inapplicable. But there will be one or two things that are a perfect match and you'll both be grinning at each other in regards to challenges now effortlessly overcome or new services you can offer.

Fifth, try to go yourself. In fact, try and organize the whole trip. If you are close enough, rent vehicles and drive down. Set up the hotel rooms. You'll be able to network with other manager types and your staff will rave about you. Hiring will become that much easier.

So lets look at two ways to handle a big conference like Pycon:

The Wrong Way

• Block any attempts the developers make in getting reimbursement for the trip.
• Schedule deadlines around the conference. If anything goes wrong, declare that this is why people should not go.
• Before the conference, grumble about developers going away and then when they come back grumble about time lost.
• Developer time lost at the conference should not be compounded by talking about the conference when they come back.
• Act surprised when your team comes back angry and at low morale levels. Act more surprised when they leave for positions elsewhere.

The Right Way

• Get business cards and fliers for your staff to bring to the conference.
• In the meeting before the conference, go over the company referral system for new hires. Also offer beer or a meal for new hires.
• At least get the developers paid hours for the sprints. Beg and borrow from your own manager to try and cover other parts of the conference. Act surprised with the gratefulness of your staff.
• Afterwards, dedicate a staff meeting to things learned at the conference.
• Go yourself and hang out in the vendor room. Hand out cheap but goofy swag. Bring thousands of business cards and hand them out. Visit a few talks. Invite developers from other companies to meals. Boast about your staff and company. Be amazed by the new hires you pick up.