InformationWeek interviewed Steve Balmer on several subjects, including open source. Here’s a choice quote:

We’ve always tried to get innovative work to happen on our operating system, and I want Windows to be the number one destination for open source innovation.

Steve, you could stop by dropping the Unreasonable and Discriminatory Pay-to-Interoperate Tax on commercial open source distribution. These developers already pay the Windows tax. So do their customers. Taxing them again with a licensing scheme that allows you to pull the rug out from under their feet if you decide to compete with them is, in my mind, something other than encouraging development.

I suspect that true innovation doesn’t have to put up toll roads.

Since I’ll suddenly have copious free time on my hands once I turn in my final book manuscript this weekend, I decided that it might be helpful to start a short column on some of the fundamental Dojo building blocks. Although I certainly won’t be able to give this column the same “definitive guide” coverage that you’ll get in the book, my hope is to show you some tools that will increase your Dojo awareness and get you excited about some of the things that Dojo can do for you.

In a recent discussion on lkml (found thanks to LWN, Ingo Molnar defended checkpatch, a Perl program which reviews proposed patches against the kernel’s coding standards. In particular:

you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird “feeling” that there’s something wrong about the patch.

It’s totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code.

That “feeling” i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a “library” of patterns of “good” and “bad” looking coding practices.

If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the code is peppered with random style noise, it’s a lot harder (for me at least) to notice real bugs. I can notice bugs in a squeeky clean code base about 5 times easier than in a noisy codebase. This effect alone makes checkpatch indispensible for the scheduler and for arch/x86.

…

I’ve yet to see a _single_ example of a good, experienced kernel programmer who writes code that looks absolutely careless and sloppy, but which is top-notch otherwise.

I’ve spent a lot of time this past year cleaning up a medium-sized codebase written in cross-platform C89 (c’mon vendors, can’t you upgrade your compilers tosupport C99 already? I know Microsoft has a few programmers on staff.). Coding standards help immensely.

Even something as simple as aligning the equals signs in assignments and separating paragraphs in code with newlines increases skimmability greatly. Ingo’s right though, and I wish I’d realized it consciously earlier. Consistent code requires much less brainpower to decipher its structure, leaving that much more brainpower to find real problems.

While there may never be a refactoring called “Beautify code block” (and technically that’s not improving the design of the code), it’s an important tool for human analysis of code.

My comfort zone is in the LAMP stack. I’ve played around with some WAMP (use Windows as the base OS instead of Linux) stack configurations. But, I’ve never really considered using a WISP (Windows, IIS, SQL Server/Express, and PHP) stack. SpikeSource’s Dominic Sartorio describes their work in a guest Port 25 blog post to provide not only a functional WISP stack but stacks with pre-configured and ready to run Open Source applications like phpBB, WebCalendadr, Gallery, moodle, and Mantis optimized for Windows Server 2008 and taking advantage of FastCGI to provide PHP performance that is supposed to be much better than we’ve seen prior to FastCGI being available for Windows Server and IIS.

Someone recently asked me about installing phpBB. Honestly, I’m not much of a bulletin board user, so I’ve never even installed it on a LAMP stack. I’m giving some thought to at least giving SpikeSource’s turnkey WISP+phpBB a test drive just to see how much time in might save me by going that route instead of installing and configuring it on my usual LAMP environment.

Okay, not very original as far as titles go, but I’ll take it.

So, I’m new to O’Reilly’s Port25 blog, and happy to be here! As a quick introduction, I spend a lot of time talking and writing about interoperability, identity and access management, and directory services. I base everything I say and write on the actual experience I get from providing expertise on, well, interoperability, identity and access management, and directory services.

Oh, and speaking of.. speaking, I’ll be presenting at the Directory Experts Conference in Chicago next week. DEC is an excellent conference, and you’ll be able to rub shoulders with some real industry heavyweights, so you should show up.

Like I said, I’m excited to be here, and this should be an enjoyable ride. I’ll be talking about my real-world experiences with plugging Linux and UNIX into Active Directory, using various directory products (such as OpenLDAP, AD, eDirectory, and Sun) together, and what it really means to manage access across servers and applications that don’t want to speak with one another. Should be fun!

If you read Sam Raimi’s How open source has influenced Windows Server 2008 and Dominic Sartorio’s Dominic Sartorio on SpikeSource and Open Source Interoperability blog entries on Microsoft’s Port 25 site, you might wonder if FastCGI for PHP only works with Windows Server 2008 and IIS7. Fortunately, that is NOT the case. Head over to…

http://iis.net/php

…where you can find and download FastCGI for IIS 6.0 on Windows Server 2003. You will also find a link to a video tutorial titled Setting up FastCGI for PHP on that page. It is part of the IIS7 video tutorial series found at…

http://learn.iis.net/

I was surprised to read what Sam Ramji had to say in his Port25 blog entry…

How open source has influenced Windows Server 2008

Sam lists some of what he considers the things about Open Source development that works well and then describes how Microsoft applied this ideas to developing Windows Server 2008. This is the aspect of the blog the surprised me.

Sam goes on to describe some really interesting Open Source related developments like the FastCGI enhancements to speed up PHP on IIS7 (and IIS6 too as I’ll discuss in a separate blog entry). He goes on to talk about how system administrators who write code are first-class citizens now that PowerShell is built right into Windows Server 2008. Personally, I think PowerShell was the single most important product released in the 2006-2007 timeframe that saw Windows Vista (lukewarm IMHO) and Office 2007 (great) released. You might be thinking what I thought when I first heard about PowerShell (then called Monad) back in late 2005 or early 2006: When don’t they just use Bash scripting or Python or Ruby? Go take a look at PowerShell and you’ll understand why Sam says this makes script-writing sysadmins first class citizens on Server 2008. PowerShell works directly with the .Net Framework. You can work with the system at the object level. This eliminates a huge amount of the parsing and formatting that we normally do when working on a UNIX-ish type OS (Linux, BSD, etc.) using Bash, Python, or Ruby. And, although Sam doesn’t mention it, I’m hoping to read more about using IronPython and, eventually, IronRuby with Windows Server 2008.

Speaking of all these cool new features… If you install and fire up Windows Server 2008, you won’t see any of this stuff! Don’t worry. It is all there. These features are all turned off by default. To turn on features like PowerShell, head to the Control Panel, select Programs and Features, and then use the Add Features Wizard (see my screen cap above) to turn on things you want to test out.

By the way, unless you want to test out the pre-release Hyper-V virtualization features, you don’t need to dedicate a PC for testing. In fact, I’m running my tests on a Mac using VMware Fusion. Windows Server 2008 installs and runs fine there. I definitely am saving my nickels and dimes to buy a small test PC with a Core 2 Duo chipset that supports Intel-VT for virtualization assist though. Be careful in buying a desktop or notebook PC for testing Server 2008 if you are interested in playing with Hyper-V. Not all Intel Core 2 Duo processors support Intel-VT.

I presented Bad Sushi: Beating Phishers at their Own Game with Billy Rios last week at the Black Hat Briefings in DC. The best part of the experience was the opportunity to talk to people in the audience after the presentation, and to hear their perspectives on the subject.

Here is what others have to say about the presentation:
Black Hat Lifts the Cover Off ID Theft Phishing Networks [eWeek]
The myth of the Ninja Hacker [CNET]
Black Hat D.C. wraps up [CNET]
Black Hat, Day 1: Cracking GSM and skimming ATMs [ZDNet, thanks Nate]
Black Hat: Honor Among Thieves?

Here is some additional coverage:
Bank scammers scammed, says security researcher [The Register]
World of Phishing Exposed (podcast)
Researchers Expose "Stupid Phisher Tricks" [Dark Reading]
How phishers work — the inside story [Guardian]
Most Phishers Clueless, Say Researchers

If you were unable to attend the presentation, but would like to get a glimpse of the material, please read the on-line interview with Billy and me that I linked to earlier: Interview with Nitesh Dhanjani and Billy Rios, Spies in the Phishing Underground.

Since the presentation, Billy and I have discussed new material applicable to this presentation, and so I think we will be continue to present updated versions of this talk at future security conferences.

Dojo is now compatible to run on Adobe AIR, which shipped as of today. The press release does a great job of summarizing, but this excerpt is worth repeating:

The updates to the Dojo Toolkit make it even easier for Ajax developers to create engaging applications on Adobe AIR,” said [Rob] Christensen [senior product manager, Adobe AIR at Adobe]. Ajax developers can take full advantage of the Dojo Toolkit’s powerful user interface components including menus, tree controls, tabs, rich text editors, and effects libraries to build rich, cross-operating system applications for the desktop.

Complete information on getting Dojo running in an AIR environment can be found here.

It’s going to be quite exciting to see Dojo on the desktop. AIR developers, I’d be interesting in hearing back about your experiences with Dojo as you press forward.

Just this past weekend, dojotoolkit.org rolled out significant improvements in presenting documentation. Better documentation has been one of the most common requests for the project, so this update is at least a partial delivery on that front. The hope is that continued improvements in API documentation and other efforts such as the book I’m finishing up will continue to make Dojo more and more accessible.

I’m typically logged into the Threading Building Blocks IRC channel (#tbb on FreeNode.net IRC). Last week, a community member noticed AMD’s new open source initiative, Framewave. He took a quick look at the project, and came back to tell us that, despite the use of the words “multicore” and “performance,” the library really isn’t like TBB, it’s not a generic multithreading framework that can be applied to multithread applications and libraries to take full advantage of multicore computers. Still, the Framewave project is interesting in that it illustrates the kind of computational power that multicore is capable of bringing to standard home and office desktops.

People have frequently disagreed with my assessment that general users will ultimately find many uses for all the new processing power that multicore brings to the desktop. The Framewave project is an illustration of the type of computation libraries I believe people will definitely find useful, once they recognize the possibilities these libraries offer.

For example, the Sourceforge Framewave page tells us that Framewave is:

a free and open-source collection of popular image and signal processing routines designed to accelerate application development, debugging, multi-threading and optimization on x86-class processor platforms.

Image processing and signal processing entail significant computation. As a result, in the past, these libraries were not brought into common desktop applications: the data manipulations would take too long to complete; few users would have wanted to wait for the processing to complete, regardless of what results were possible. Hence, applications such as Photoshop Elements and PaintShop Pro have stayed with simple image transformations, that can be performed in a fraction of a second, so the user can see the results immediately.

Multicore systems change this. The Framewave project (which uses the Apache licensing model) is a starting point.

Framewave’s architecture

I haven’t studied Framewave enough yet to know exactly how the algorithms have been tuned for high performance on multicore systems. You would think full multithreading would be required. I’ll look at that soon. The AMD Framewave page tells us that the framework’s API is compatible with the Intel’s Integrated Performance Primitives (Intel IPP), which is:

an extensive library of multi-core-ready, highly optimized software functions for multimedia data processing, and communications applications.

Looking more closely, we see that Intel IPP is itself in the same space as Framewave, offering algorithms for image processing, signal processing, vector/matrix mathematices, cryptography, and quite a bit more. The Framewave “API compatibility” statement tells us, then, that developers can create applications that apply both Intel IPP and Framewave.

Mix and match design

That implementation is reminiscent of the design of Threading Building Blocks, where you can create applications that mix traditional threads or OpenMP with whatever components of TBB you need. Of course, in the case of a math library that’s a collection of distinct functions, that’s almost the expected design. In TBB’s case, a non-monolithic design was only one of the possibilities. The fact that you can use TBB’s threadsafe containers (or memory allocators, etc.) in a native threads application is an enormous benefit. The correct design decision was made by the TBB team!

Conclusion

I plan to take a closer look at Framewave. If it’s not multithreaded already, it will be interesting to see how readily TBB could be applied to enable the library to take full advantage of modern multicore computers.

Just a quick FYI, Chris McDonough has his PyCon 2008 slides up already on his Supervisor talk. In a nutshell:

“Supervisor is a Python program that allows
you to start, stop, and restart other
programs on UNIX systems. It can restart
crashed processes. Built on Medusa. ”

Here are the slides.
Here is the current manual.

We will be talking about Supervisor in our book on Python for Systems Administration. It is a great tool. If you have not used supervisor, at the very least easy install it, and try out the “cat” example in the manual.

The imp module exposes the implementation of Python’s import statement.

Google’s new operating system, Android, is not just a comprehensive runtime for mobile applications. Nor is it just a rapid application development platform for such applications. In addition to these things, I see Android as a redefinition of what interactive applications should be.

The snowstorm that covered Boston yesterday didn’t keep two hundred hackers from showing up this morning for Google’s Android Code Day, most of them probably hoping to take home a slice of Google’s ten million dollar challenge. Even more amazing, the Google team flying in from California also made it. We filled the ballroom of the swanky Charles Hotel, where attendees were interested less by the landmark oil paintings on the walls than by the images delivered by a wireless network to their laptops.

In this blog I’ll summarize some of the basic elements of Android applications and how they relate to componentization, today’s trend in software development.

I just found out about a really interesting use of Python, that Red Hat Emerging Technology is developing called func. This was in a recent article at Red Hat Magazine, who I happen to write for as well btw.

We will be covering some examples of func in our book. At a high level though, func allows you to administer machines with python and python scripts. Here are a few examples from their front page:

import func.overlord.client as fc
client = fc.Client("*.example.org;*.example.com")

# package controls!
client.yum.update()

# service controls!
client.service.start("acme-server")

# hardware info!
print client.hardware.info()

# etc ... etc ..

I really like this example too, of rebooting all machines running http:

 results = fc.Client("*").service.status("httpd")
         for (host, returns) in results.iteritems():
         if returns == 0:
         fc.Client(host).reboot.reboot()

It is great to see Python use exploding at Red Hat. The cobbler/PXE boot project is also quite cool.

I’ve slaved away for the past 8 months or so writing a book on Dojo. It’s definitely not a lot of fun moonlighting for such an extended duration on a single project, but my hope is that it’s all going to be worth it when I am able to deliver what I believe will live up to the “definitive guide” standard that so many other O’Reilly books have delivered in the past. (Yes, that previous link shows that the book is titled Developing with Dojo, but it’s really just a placeholder. The book has since been retitled, there will be a different animal on the cover, etc.)

The fact that I’ve spent so long working on what’s essentially documentation of all things should tell you that I’m a huge Dojo advocate, but why did I like Dojo enough to spend hundreds and hundreds of hours writing a ~500 page book on it?

Here are some of the reasons that come to mind immediately:

• Breadth and Depth - It includes a highly optimized JavaScript standard library that protects you from the bare metal of the browser and allows you to write portable code, a terrific set of widgets that you can drop right into the page, and build tools that you can use to compress and consolidate your JavaScript to squeeze as much performance out of it as possible. Those are really broad strokes, but hopefully you get the idea that it’s not just about widgets or just about DOM manipulation. It’s about creating a great user experience and necessarily includes a swath of stuff that helps you to make that happen.
• Awesome Community - The help these people have given me in writing this book is nothing short of incredible. It’s kind of strange to “know” people for months and months via an IRC chat room and somehow feel like they’re your friends, but that’s the way it feels. It’s amazing to watch some of the most hard core committers in the project field some of the simplest questions that come up with grace and patience. (And believe me, I’ve come really close to starting a riot a few times in there.) Drop into #dojo on freenode.net if you ever want to see just how inviting the place really is.
• Clean, liberal, licensing - This post does a great job of explaining, a lot better than I could right now, so have a look.
• Pragmatic philosophy - It doesn’t try to re-invent JavaScript or build a brittle, artificial language on top of it. It embraces JavaScript for what it is, plugs holes where they need to be plugged, smooths a few things out here and there, and otherwise leaves the language alone.

Now, without starting a flame war, I’m curious about some things:

Have you tried to use Dojo in the past and gotten frustrated and dropped it for something else? If so, why (and what did you end up liking better?)

Would a solid book on Dojo have made a difference?

Have you started with another JavaScript toolkit but migrated to Dojo because the other one didn’t quite meet your needs? You don’t have to say which one you moved away from, but it would be interesting to know why you ended up moving to Dojo.

“Hooray,” says Microsoft Makes Strategic Changes in Technology and Business Practices to Expand Interoperability. I care most about:

Microsoft is providing a covenant not to sue open source developers for development or non-commercial distribution of implementations of these protocols.

That’s sort of nice, but it’s either a complete misunderstanding of the open source definition, or a very calculated strategy. To wit, criterion six of the OSD:

The license must not restrict anyone from making use of the program in a specific field of endeavor.

I’m sure it’s a very nice gesture that Microsoft will promise not to sue you for developing free software that you can’t distribute under a free license. At least, it’s some kind of gesture.

Lenz Grimmer wrote about the MySQL University session Checking Memory with Valgrind, given by Stewart Smith.

Like all good-hearted people, I think Valgrind is one of the most useful inventions ever. I’ll check out the archives after the session.

Sebastian Silva is a bit worried. Three hundred thousand XO units will arrive in Peru by August, the largest deployment in the world by far. (Uruguay started this past December and will reach one hundred thousand laptops this year.) As a volunteer on the OLPC support team, Sebastian wants to make sure the children, teachers, and technical trainers are ready.

Sebastian sees the promise of computing as in social terms. With XO, every person becomes a TV broadcaster–and XO is even more empowering, because TV broadcasts can’t be chopped up and digitally altered. Sebastian says he learned Logo before he learned to read and write, and its mastery gave him a learning attitude that he’s preserved his whole life. He wants children not just to make movies and write papers, but to appreciate the drastically open nature of the systems they’re given.

“If OLPC succeeds, there will someday be more OLPC-like systems in the world than traditional PCs,” he says. “The Internet could very well be transformed by the behavior of people using the OLPC systems.”

Jeff Horwitz spoke at Frozen Perl this past weekend about mod_parrot (embedding Parrot in Apache httpd) and mod_perl6.

Though Rakudo (Perl 6 on Parrot) is still in progress, it’s far enough along that you can write real Perl 6 programs that run atop mod_parrot. Jeff’s slides are available as The Future of mod_perl: Perl 6 and Beyond (PDF link). This code works today, right now.

(Oh, and Rakudo is far enough along that Jeff can also show off mod_perl6 written in Perl 6.)

Alter the search path for a specific package using pkgutil.

You have probably heard of AJAX, but have you heard of Comet? Yes, they are both household cleaners you might find under your kitchen sink, but that’s only part of the story.

In the web realm, Comet refers to an architecture that enables a server to actually push data to a client without the client explicitly requesting it. Given that web servers were built to be very good at doing exactly the opposite over a stateless protocol, you should be quite intrigued at this point, so head on over to Comet Daily, a fantastic site that includes incredibly informative articles on Comet, to get some insight on what is going to be the next big thing in web programming.

Right now, there is a series running with the theme of Colliding Comets which includes a number of presentations and rebuttals that discuss opposing philosophies on how to most effectively realize Comet. Trust me, you won’t be disappointed. This is good stuff, and it’s full of substance.

If you find Comet interesting, you may want to also take a look at Dojo, an industrial strength JavaScript toolkit for developing web applications, because it includes cometd, a client that can talk to a Comet server if the server implements the Bayeux protocol.

My upcoming book, tentatively titled Developing with Dojo, includes an in depth example of cometd. We hope to have the book available via Rough Cuts very soon, so if you’re interested in using Dojo with Comet, keep an eye out for future posts about its release.

Eugueny Kontsevoy writes in Web vs Desktop Nonsense:

Can we see past the browser? Can we accept that browser is just a runtime library that most people do not need to download to consume your application?

…

Come on, the “anywhere” part should not come at expense of losing 90% of other features.

…

Yes, future belongs to web applications, but I am not so sure that browser, with [its] weak runtime and close to non-existent programmable graphics, should remain a necessary vehicle for it.

The more I think about the subject, the more I believe that HTTP is a truly successful distributed system because it doesn’t try to solve what most distributed systems tried to solve. It doesn’t try to blur the distinction between local and remote resources; everything is a document accessible through a URI. (At least, that’s true if you’re a RESTafarian, which you should be.)

The question Eugeney raises is important. We already know how to build decent — even good — native applications. Is the zero-footprint installation (minus several hundred kilobytes, if not a few megabytes of JavaScript, or a few tens of megabytes of Flash, Air, Silverlight, Moonlight, or Java) so compelling that everything has to get crammed into the web browser model?

In my mind, that’s a mistake as big as pretending that accessing a distributed component is exactly the same as accessing a local component.

(Quick musings on my lunch break.)

When Microsoft wants to compete, it acquires. (How many successful products have escaped the $7 billion a year Microsoft Research?) Apparently Microsoft wants to compete better in the world of the Internet, so it’s trying to capture Yahoo and all of those lovely page views.

As of this writing, Google Finance on Yahoo (I like the irony of that link) says that Yahoo has a market capitalization of almost $40 billion in 1.34 billion shares and a price to earnings ratio of 63.51. Apparently a lot of people believe that big profits are around the bend.

A $40 billion acquisition is a big deal, and apparently Yahoo’s holding out for more. Everyone has a price — if the board doesn’t like $40 billion, will enough shareholders like $50 billion? $60 billion? A new board might be more pliable.

However, instead of trying to make this acquisition work, Microsoft could turn its baleful eye down the street a little bit.

Chasing page views and a new market dominance in Internet advertising may not be in Microsoft’s best interest. Of course, you know that eventually every Microhoo page will have little pockets of Silverlight here and there. If the Rich Internet Application model threatens the Windows hegemony, Microsoft has to react to preserve the attractive profits of its cash cows. Right now there are two serious competitors. One is whatever HTML 5 and Ajax may produce in the next couple of years. The other is a somewhat cheaper acquisition target.

Google Finance on Adobe reveals a much smaller, choicer target, with a $19.91 billion market capitalization and 568.96 million shares. Microsoft might not even have to borrow money to make this acquisition work.

For half the price of the hostile Yahoo acquisition, Microsoft gets control over PDF (axed), Flash (axed), and Air (axed). Talk about a destination, too — there’s a long-standing rumor that the single page with the highest PageRank anywhere is Adobe’s page to download Acrobat Reader. Microsoft also gets a fair few developers who it can retrain to port Flash to .Net while they’re on the way out the door, and there’s your backwards compatibility strategy — at least for all of those platforms which have officially blessed, sanctioned, and (here’s the important part) legal-codec-supported Silverlight ports.

(Linux users, do you have the Novell SUSE Genuine Advantage?)

What Microsoft doesn’t get is a better foothold into the currently-lucrative online advertising market… but that’s the single leg of Google’s one-legged tripod. It’s difficult to see how selling ads will prolong the life of Office, however… but maybe that will give the Office product team enough time to port a few tens of millions of lines of code to the CLR.

I watch what people like Brian Aker and Brad Fitzpatrick do very carefully. As developers go, they’re among the best at making little problems go away so as not to distract them from developing, releasing, and maintaining software.

Brian wrote recently about encouraging very easy commit access to contributors. I can’t add anything more to what he said, except to echo his concerns about the implications for making a new release of software.

I’ve seen this pattern of open repository access in the past few years, first with the Pugs project, and then with Brian and also Adam Kennedy and Michael Schwern. It’s a model that works in certain cases.

As Brian mentions, a release has certain implications. The best way to know that your software works on the platforms you care about is to test it on those platforms — and I know all of these developers believe in the value of automated testing.

The great mass of developers might just now be hearing about distributed source code systems. That’s fine. Plenty of them will realize how valuable it is to commit without network access or to branch cheaply and locally, or to have the project history instantly available, changeset by changeset, when they need it. The problem isn’t a trivial one, nor is it a completely solved problem, but we’re beginning to understand it better, and the solutions we have now are decent and robust and continue to improve.

Now it’s time to figure out the next problem. As Brian described it:

I want all open source projects being filtered into a network where users can run slaves that do regression testing for them.

We’ll likely discover that on platforms so exotic that available developer support and expertise is minimal (Windows, anything non-x86) that the next bottleneck is people who can fix problems, but being able to track which patch broke support for a platform is highly useful. Maybe for now even the minimal ability of being able to submit a patch to a farm of EC2 instances to get back “Everything passed!” or “Something failed!” results in seconds, rather than minutes, would be an improvement.

Alternately, opening up commit access might mean that we can say “If you want this to run on your favorite platform, you’re going to have to get involved.” Maybe making it even easier to contribute to a project will finally let us be clear about the true cost of free software: if you rely on it, you must help the community support its long-term health.

Perens celebrates the ten-year anniversary of the publication of the Open Source Definition. In addition to summarizing its increasing acceptance, he cites continued challenges, focusing on patent issues.

Uh oh! There’s danger! Time for the Wonder Twins to activate their super powers.

for twin in wonder_twins()
    for power in twin.powers()
        power.activate()

...

Fatal Error:  Subtype "AnimalMagnetism" cannot be activated in class "SaveTheWorld", line ...

Humanity is destroyed because another developer hasn’t heard of the Liskov Substitution Principle. Let’s take a closer look at it.

I practice annoyance driven development. I set my threshold of annoyance low such that everytime I feel frustrated by a technical limitation, I notice consciously. My intent is not to find technology endlessly frustrating (though that happens sometimes), but so that I can identify the next most important thing to fix.

For example, Parrot has a large test suite. Several of those tests exercise the source tree as a whole, checking for copyright notices, Subversion ID strings, and metadata properties. I call these non-functional tests, because they exercise externalities of the project, not features of the code. Having accurate copyright notices and repository metadata (especially “Make sure these files have the proper platform-specific line endings”) is useful… but analyzing thousands of files in dozens of directories isn’t instantaneous.

Because we have several contributors, we attempt to keep all of our tests passing on all of the platforms to which we have regular access all of the time. (Exotic platforms like Windows aren’t always so fortunate. Porters wanted.) To achieve this, committers must be able to run the test suite before checking in changes.

Everything so far is obvious. What wasn’t immediately obvious to me was that there’s a threshold beyond which people will not run the entire test suite.

Open source advocate William Hurley has put up a poll asking readers who would be the best presidential candidate on open source issues. Think patent reform, for instance. Don’t give away the results…