Once again, I'm dealing with the too-many-blogs problem by writing once, and pointing many
times.
I've published an article at the ActiveState community site on writing new test plan harnesses
to plug into Komodo 4.4, now in alpha. You can get it here:
http://community.activestate.com/writing-unittest-harnesses-komodo-4-4-introduction
This year's LinuxFest looked to be a good 20% bigger than last year's -- the exhibits spilled into a second room, there were 12 parallel tracks over the previous 10, maybe that many more people milling around the room. Plenty of fun -- I wish I had given myself more time to enjoy the festivities, but between the two talks I gave, table-top time, and the two hours I shared at the border with my fellow Canadians, I didn't have much of a chance to slow down until at that evening's party at the radio museum.
Somewhere along the way Bellingham picked up the tag "City of Subdued Excitement", and you could characterize the 'fest that way as well. Everyone's having a good time, with a mix of professional open-source people, teenagers, skatepunks, and plenty of people from the real world who are looking for solutions, without the hype that a mega-sized convention hall practically demands. Sunday's a lower key day; next year I'll try to hang around for it.
As for my talks, they were both fun to give. The JavaScript/Google-Maps talk is definitely aimed at working web developers, who were in shorter supply at LinuxFest compared to the Open Web conference earlier this year. The Greasemonkey talk went over better, and was more like 30% seminar, 70% lecture, a fine formula. I had scheduled a 60-minute talk, and at noon found I had 30 minutes more in my slot. So the group came up with a project -- replace the images in an HTML file with buttons. When you click the button, the image is then downloaded and displayed. Kind of like the adblock extension, but this could be far more configurable. It was motivated by someone trying to deal with ads clogging his low-bandwidth wireless connection, by the way.
Anyway, the session ended up as a group programming exercise. I sketched out a plan of how to solve the problem with a Greasemonkey script, and then using the JavaScript shell to try out ideas and find methods interactively, we managed to get something working before the bell rang. It's up at http://userscripts.org/scripts/show/25610 but definitely not finished.
Here are the PDFs for my talks:
This has been a month full of talks. In Scandinavia my talk on OpenKomodo at the Rubyfools conferences was competing first with Dave Thomas on Ruby meta-programming, and then in Oslo it was in the final slot on a Friday of what seemed like the first nice weekend in Norway of the year.
Earlier this week I gave my "Coding Like it's 1982" talk to a packed room at the Vancouver OpenWeb conference. I tried to create the kind of presentation I enjoy, and it seems plenty of the attendees agreed. I kept the subject matter constrained, followed the 7 +/- 2 rule, didn't bother staying up all night creating syntax-colored slides, and one attendee afterwards thanked me for delivering a presentation that gave him "real business value".
If you couldn't get to Vancouver, I'll be reprising the talk in Bellingham (schedule not posted yet), which gives me a chance to fix a couple of typos. I'll also be talking about GreaseMonkey, specifically targeting people who are familiar with JavaScript, but haven't felt the need to install any extensions. The Scaling-up talk is geared to intermediate programmers, with a specific focus on the Google Maps API. The GreaseMonkey one is going to cover more basic material -- if you've written a web page with a bit of JavaScript to validate forms or check cookies, but not much more than that, you'll be fine for this talk.
Shane Caraveo will also be talking about Open Komodo, and it looks like we'll have a table in the exhibit hall, so there'll be plenty of ActiveState presence at the fest this year. If you're looking for a less informal meeting to get together, we'll hit the Little Cheerful for breakfast around 8:30 - 9 AM, if we get through the border early enough. No web site, but they're an easy find in the heart of downtown at Railway and Holly.
LinuxFest Northwest has become one of my favorite conferences. It's totally grass-roots, but you can count on companies from Seattle and Vancouver to show some cool new tech. With at least ten parallel tracks, you can always find something interesting to check out. And the organizers have kept it free. Last year's evening social showed off the little-known American Museum of Radio and Electricity. Bellingham is full of other little-known gems, like the Mindport science/art gallery, the natural history section at Henderson's used books (112 Grand Ave, 360-734-6855), and the tide pools at Larrabee State Park. As for where to eat, see http://apps.facebook.com/eat-a-rama/.
Disclaimer: I'm not an expert at the Windows Installer technology, but this solution should be safer than mucking with registry entries and private files. Maybe you shouldn't try this at home, but it worked for me.
Windows Installer is close to ten years old now. It might have made a lot of sense when it was designed, but I'm not sure how vital it is today.
The big problem with MSI is it doesn't fail well. Any robust system needs to handle failure at any point in its operation. And this is where MSI falls short. Case in point: last week I was installing an MSI, and my motherboard chose to die at that point. The installer quietly stopped working. Other apps could keep working, but in strange ways. I couldn't issue new commands in a command shell, but I could link to new web pages in Firefox. It was as if the CreateProcess call wasn't working. In fact there were errors referring to kernel32.dll, if memory serves. I pulled the plug on the machine (the regular Shutdown program was one of the apps complaining about kernel32.dll), turned it on, and saw a black screen. The machine wouldn't even post -- this was no Windows problem.
It turns out there was a short on the motherboard, and replacing it fixed everything. Almost everything. The app I was trying to install was in limbo. I couldn't reinstall it, as I'd get the "Another version of this product is already installed" message. But the product wasn't installed -- the "c:\Program Files" directory hadn't been created yet.
Here's how I fixed this problem:
1. Get Orca. Since I no longer have the patience to install the latest round of the Windows Platform SDK, I got it from Aaron Stebner's WebLog. He conveniently has a copy of the orca.msi zip there. Download it, unzip it, install it, and run it.
2. In Orca, open the .msi file for the app Windows thinks is installed.
3. Click on the "Property" field in the "Tables" section.
4. Double-click on the Value field next to the "ProductCode" Property.
5. In a command-shell, run this command:
msiexec /x [Paste the ProductCode, with the braces]
6. Now install the original program, and hope your motherboard holds up.
2008 is the year of the talk for me. Next week I'll be speaking on OpenKomodo and Ruby in Scandinavia. Later this spring I'll be giving some tips on speeding up Ajax code at the Vancouver OpenWeb conference, and I'll be talking about GreaseMonkey and reprising the Ajax talk at Bellingham's Linuxfest Northwest at the end of April (two separate talks, although combining Ajax and GM might be interesting).
I've started using s5 to present my material, but authoring it is tedious, even with the assistance of Komodo's snippets and automatic abbreviations. I wondered if I could use Haml outside Rails, and sure enough it's easy to do. My presentation now looks something like this:
.slide
.h1 Stuff about my topic
.ul
.li point 1
.li point 2
.li final point
Or if you prefer the Takahashi Method:
.slide
.h1 Topic
.slide
.h1 Another
I then convert it with this simple Ruby program:
#!/usr/bin/env ruby
require 'haml'
pre = <<__EOF__
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
... # The boilerplate at the start of every s5 HTML document.
...
<h1>[Title]</h1>
<h2>[Sub-title] </h2>
</div>
</div>
<div class="presentation">
__EOF__
source = File.open("talk.haml", 'r') {|fd| fd.read }
engine = Haml::Engine.new(source)
post = <<__EOF__
</div>
</body>
</html>
__EOF__
puts pre + engine.render + post
True, I don't get the fancy wipes and swirly transitions between slides by using s5, but I can live with the tradeoff.
In less than two weeks I'll be speaking at the Scandinavian Ruby Fools conferences on two aspects of Komodo. The first is the specific Ruby- and Rails-related features in it -- after all, this is a Ruby conference. But I'll spend most of my time on the Open Komodo FOSS project: what it is, why we did it, and what you can do with it.
As an example of monkeypatching an IDE, I spent a few hours last evening creating an "Undo Slider". It's a simple widget that walks up and down the editor's "Undo stack". It's a live widget -- when you make changes to the buffer's contents, the widget slider adjusts to take into account the new items to undo.
I was thinking about releasing the widget on the ActiveState extension site, but I think instead I'll write up how I did it. You can easily lose a lot of changes with this widget, by moving the slider all the way to the left (an "Undo all" operation), and then making a single change in the buffer, which clears the "Redo stack". It's way more interesting talking about how to build a frivolous widget like this than to release and support it.
Speaking of talking, my Copenhagen talk will be Wednesday, April 2, at 1530 hours. If Denmark is too far away for you, I'll be speaking on the same subject in Oslo on Friday, April 4, at 1600 hours. And with that schedule, I'll have lots of time to meet up with other people that week. I'll be arriving in Copenhagen on March 30, leaving for Oslo on April 3, and returning to North America the following weekend, so it looks like I'll have lots of free time. Not everyone from Europe can make it over to the trade shows ActiveState attends, so if you're in that part of the world, this would be a good chance to meet one of the Komodo team members and discuss your ideas face-to-face. Please contact me at ericp at activestate.com to arrange something.
Komodo and Rails have both changed in the last year, and it was time to cut a new screencast, playing now at http://community.activestate.com/ruby-rails-2-support-komodo-4-3-part-1.
We also changed the Rails tutorial that ships with Komodo to reflect many of the changes in Rails 2.0 (and decided that there was no longer any reason to ship a tutorial compatible with Rails 1.x). The tutorial and this screencast both cover resource-based scaffolds. The screencast also shows how Komodo 4.3 integrates Rails applications with our new unit-testing framework. Komodo Edit now ships with the Rails project template, but that isn't covered in the screencast. If you're using Edit, you can follow along at home with the first half of the screencast.
And if you made it through the Rails 1.0 screencast, you can take comfort that the "part-1" in the URL does imply a future sequel, and a shorter length. This one clocked in at nine minutes; hopefully I can drive the second one down under the five-minute limit. I do actually try to follow the notion that the ideal screencast should last about as long as an AM Radio Top 30 tune, but things happen in the studio, and I end up with something more like the album version of "Light My Fire" than the single.
Again, I've got the too-many-blogs problem. Code blocks look better on the ActiveState community site, so I've posted the article there, at http://community.activestate.com/impatient-developers-guide-writing-python-nose-plugins
The synopsis: writing and installing Nose plugins is easy. Who knew?
We shipped an alpha of Komodo 4.3 last week, fixed a couple of bugs in the new unit-testing framework, and are looking for more feedback on how the feature works, and where you want us to take it. I already wrote it up at the Komodo community site (http://community.activestate.com/forum-topic/wanted-your-feedback-komodo-unit-testing-support), but here's the full text for those reading this in a feed:
We're about to ship the first beta of Komodo 4.3, and one of the new features is support for running unit-tests within the IDE.
We're currently supporting one framework for each language:
Clearly this isn't the end. We plan on supporting more frameworks, and adding support for unit-test extensions. In the meantime your feedback is more than welcome. Which test frameworks do you use, and for which languages? Are there other frameworks that you would use if they weren't so cumbersome? Any we should steer clear of?
Also, if you've tried out the feature and have some comments, please let us know, either via this forum, directly to me, or logging a bug if something is broken or needs improvement.
Thanks,
Eric
Another link to the ActiveState community site... this article is at
http://community.activestate.com/pseudo-debugging-komodo-javascript-macros
