mcoyle.botonomy.com

Our New Offerings for 2008

Introduction

As Christian mentioned the other day, we have two new service offerings in 2008, both centered around Python consulting:

• PyCOE.com is our new offering to help organizations build core competencies in Python in a deliberate and predictable fashion in a way that is fundamentally different from the way that firms tried to adopt J2EE and .NET in the past.

  In a nutshell, we help companies create an environment where the easy thing to do is also the right thing to do for their developers, analysts, and QA personnel. We focus on culture, standards, and infrastructure as we help our customers create a Python Center of Excellence (or COE, hence the PyCOE name) in their organization. We do this by approaching Python adoption as business process re-engineering for IT, rather than programmer training.

• PyGuys.com is our new Python consulting brand. We are focusing on small-to-midsize custom development projects, and SDLC process improvement consulting. We’ve been doing Python and Project Management consulting since the company started, but we felt that now was a good time to rebrand and grow our Python consulting business.

We also reworked the Botonomy.com company website, to reflect its role as a “holding company” for our branded service offerings.

Also, just before we launched our new websites, TIOBE declared Python as the programming language of 2007. Not a bad sign, if you ask me.

Why PyGuys? (or Why we’re not on the Rails bandwagon)

We recently announced the re-branding of our consulting practice as PyGuys.com. By marketing on a brand-by-brand basis rather than at the company level, we think that we’ll be able to improve the signal-to-noise ratio for the targeted audiences of our various products and services. For example, our Python consulting customers may not have a need for our project management software, and vice-versa.

That being said, the casual observer may wonder why we’re so gung-ho over Python when it appears that all of the cool kids are using Ruby on Rails. When we started the company in 2005, there was still plenty of room on the Rails bandwagon. Our adoption of Python was deliberate based upon the maturity of its language, libraries, and community.

Quite simply, we’re in this for the long haul, and feel that Python has the best prospects of being the dominant dynamic language in mainstream IT settings over the next 36 months. Methinks that the initial hype surrounding Rails has already started to subside, and Rails will continue as a good way of building standard web applications, especially for solo developers and small teams.

It just won’t end up being the way to build web applications.

Don’t get me wrong, the Rails folks have done a lot to validate the use of dynamic languages in mainstream settings, and the Ruby language itself has a bunch of cool and features. You will find no negativity here. But I think that Rails’ great and durable contribution to the field of software engineering is not its libraries and syntax, but rather its philosophy of “Convention over Configuration”. That philosophy transcends technology stacks, and has already found its way into a slew of web application frameworks on a number of platforms.

But when the technology rubber meets the Enterprise IT road, I believe that Python (and its community/ecosystem) is a better and more accessible choice than Ruby for most companies looking to adopt a new application development platform, current conference attendance statistics nonwithstanding.

With PyGuys.com, we’re formalizing our Python advocacy in the branding of our consulting services. In hindsight, we should have done this 3 years ago. So to paraphrase Barbara Mandrell (and there aren’t too many times in life when one gets to say that), we were Python when Python wasn’t cool. (Note: link contains audio)

Good Mainstream SQLite Article

This article in Guardian Unlimited provides a good introduction to SQLite and the story behind it.

Since SQLite is the database used by cool stuff like Google Gears, Apple’s Core Data, and (cough) ProjectPipe, it’s great to see it get positive coverage in a mainstream news outlet.

The article is also a veritable infomercial for automated testing:

Hipp attributes much of the reliability of SQLite to his use of tests. Less than half of the program code is delivered as the database engine. The larger part consists of thousands of automated tests, which exercise the code and check that the results are as expected. “That’s the real key to keeping it working well,” he says.

One of the goals for SQLite was to keep the database library very small (under 250KB). If Dr. Hipp et al. hadn’t spent all that time writing automated tests, I’m sure that SQLite would also have a very small user base as well

Jabber’s 8th Birthday: The State of the Bulb

Peter Saint-Andre published a great synopsis of how the Jabber ecosystem has grown since 1999.

On Interviews: You never have to ask a Navy SEAL if they can swim

Joel Spolsky has a great article on The Phone Screen, prompting me to jot down my $.02 on the topic.

In a prior life, I used to do tons of technical phone screens for everything from C# developers to Linux sysadmins. There is one concept that drives my interviewing style: You never have to ask a Navy SEAL if they can swim.

Here’s why: There are many skills, experiences, etc. that intrinsically require mastery (or at least competency) in smaller supporting skills. I’ve found that if I can validate these higher-level skills, I can reasonably assert that the candidate is competent in a cascade of supporting topics. It also allows you to sidestep the Buzzword Bingo that so many candidates feel that they need to play.

I like to ask questions that intrinsically flush out other areas of expertise (or lack thereof) in the process of being answered. For example, I never ask someone if they are proficient in [INSERT TOPIC HERE].

Rather, I ask them what they like or dislike about it, and why. If they have an opinion regarding likes and dislikes, it’s usually grounded in an understanding of the topic at hand, plus some basis for making the comparison. Plus, I’ve found that canned answers regarding opinions are easier to sniff out, because there’s no heart behind them.

The folks that eat and breathe technology have lukewarm opinions either way on very few topics.

I also ask a lot of questions about failures, bad designs, etc. I’ve found that for every big project, there are a bunch of junior folks who wait two years and then profess to be the project lead. The imposters always remember the cool stuff and the brag-worthy statistics (”we saved the customer $30M…”). However, only the genuine project leads can speak convincingly about the all-night debugging session in the office with the CIO the day before the big demo, the nasty integration details, hard-to-reproduce library conflicts, etc.

Also, here’s one more tip: I’ve found that if a candidate ever answers a question with word “Polymorphism”, they are always trying to bluff their way through the interview using big words. I know this because I never ask questions where the word “Polymorphism” by itself is a reasonable answer.

10.4.8.wow

If you haven’t seen it yet, the latest update to Mac OS X (10.4.8) includes a new feature where ctrl-mousewheel provides a full-screen zoom. It’s amazing (at least to me) how cleanly the render quality degrades as the zoom level increases. Things get blurry, but they don’t get blocky and pixelated. Thanks again, Quartz.

I think that the scroll zoom will be very much like Preview.app. It’s not the kind of feature that makes one stop what they’re doing and run out to buy a Mac, but you really miss it when working on other platforms. With a Mac, things Just Work (cough, most of the time).

Case in point, a few hours ago, I had to enter in a 15 digit number on a computer that was 10 feet away from my MacBook where I had the number up on the screen. I simply wheel-zoomed to the point where I could read it from far away, and zoomed back when I was done.

No harm, no foul. No thought involved.

But wait, you could do that with Windows/Linux/TRS-80/etc. simply by [INSERT 3 STEP PROCESS HERE]. But I firmly believe that the best technology is the stuff that you don’t notice.

Now I’m sure that there is some 19 year old rock star developer in Western Elbonia implementing that same wheel-zoom functionality in Linux (assuming it isn’t already implemented), to be folded into Ubuntu three scheduled releases from now (ditto).

The thing that’s great about the Mac is that the features a) Work Now, and b) Work Together. That is worth spending a few extra clams to me when I buy a new computer every couple of years.

But lest my advocacy be misinterpreted as elitism, believe me, when I first noticed that scroll-zoom (or any other wicked cool OS X benefit), I didn’t settle down into my best Thurston Howell the 3rd voice and ponder aloud about how the other half could possibly live.

The last thing we want as users, particularly those of us working with multiple platforms, is to have Daffy Duck jumping on Tux the Penguin’s head saying “Down, down, down. Mine, mine, mine.” Rather, the cross-proliferation of features across the Mac/Linux/Windows worlds may be bad for platform zealots, but it’s great for the rest of us.

That being said, OS X is probably the best end user experience “right now”, for most values of “right now”. Isn’t that true, Lovey?

If they have not seen farther

…it is from kicking the shins of the giants around them.

I’ve read a couple of blog entries from folks coming back to Python after jumping on the Rails bandwagon, citing the temperament of the community as one of the reasons.

I never thought much of it, until I read the DHH’s response to Joel Spolsky’s Language Wars article, and the comments that follow. Sure, there are a number of comments that are constructive and forward looking. But you have to look for them. Carefully.

I think that Joel Spolsky has done a lot for the software development community, and was not paid the respect that he deserves in DHH’s response and a multitude of reader comments that followed.

I’ll be honest, I’ve considered jumping on the Rails bandwagon. Several times. The thing that has held me back is the notion that Ruby/RoR hasn’t really gone through its adolescence yet.

If you look at the folks who are doing great things with RoR, lots of them (37Signals, the Pragmatic Programmer guys, etc.) would be writing great software with _any_ tools that they were using. It’s like the fact that Chet Atkins could make a toy guitar sound great.

Maybe it’s my ignorance of the inner workings of the RoR community, but I get the sense that RoR hasn’t had its “holy $#%&” moment, when the hard lessons are learned by average-to-good corporate IT developers, and the sound of pagers at 3AM drowns out the cheers of the language evangelists.

I think that Microsoft had its when they started playing Paper-Scissors-Rock with DCOM and Java. I think that J2EE had its when the Microsoft Pet Shop spanked the canonical best practices of heavy EJB development. Python had its when the momentum of RoR highlighted the fact that there were 80 web frameworks that each did 80% of what people need, and no knee-jerk answer for which one to use for any given application.

But the Rails community? Not so much. I don’t think that the RoR honeymoon is over just yet. Someday it will, and the hard lessons that come will forge the legitimate counter-arguments to Joel’s points.

Web 2.0 is the William Shatner of the IT world

Comedy Central’s annual celebrity roast was on this last Sunday night. This year’s celebrity roastee was William Shatner.

Why is William Shatner famous? Let’s just say that if you and your buddy with the pointed ears ever decide to book a discounted trip back via to 1983 to watch an action-packed police drama where the show’s protagonist sings a really creepy rendition of Elton John’s “Rocket Man”, then Shatner’s your man.

If you missed it, well let’s just say that all you Star Trek fans should set your phasers to “Incessant Reruns”. Truth be told, they might as well rename the network “Roast Central” for the 11 months following the initial broadcast of the roast each year.

This same weekend I stumbled upon the Web 2.0 Logo Creator, which I used for the Shatner logo above. It dawned on me that both William Shatner and Web 2.0 share the following characteristics:

1. Both are immediately identifiable, almost iconic in nature

   As any Star Trek conventioneer can tell you (sometimes even in Klingon, nevertheless), Shatner is larger-than-life to the Trekkies out there. I was never a big fan of the show, but to its fanbase Star Trek provided an entertainment experience that was far more enriching than that offered by its late-sixties television contemporaries.

   Likewise, Web 2.0 applications are very distinctive in their feature set, branding, and approach. To many, Web 2.0 also provides an experience that is far richer than that offered by (cough) Web 1.0 applications.

2. Both served a necessary role in the evolution of their respective ecosystems

   Shatner’s role in Star Trek helped bring Science Fiction to mainstream TV and cinema audiences.

   Nowadays, many Web 2.0 applications are causing the IT world to rethink the very nature of thin-client applications and the possibilities thereof, as Web 2.0 has mainstreamed a variety of technical and design considerations.

   At the risk of making Newton roll over in his grave, the “killer app” of tomorrow will see further by standing on the sans serif shoulders of beta-quality giants.

3. Both have managed to become caricatures of themselves, while they still “keep on keeping on”

   Sunday’s roast made it crystal clear that Bill Shatner has his self-deprecation switch stuck on the “ON” position. Yet his acting career continues to flourish in shows such as Boston Legal.

   Similarly, there have been a number of sites that make fun of Web 2.0 conventions, yet nearly all of the interesting web apps as of late embody many of the principles, technologies, and design considerations that are often subject to parody.

So, Messrs. Shatner and Web-two-point-oh, keep in mind that in the IT world, like the Friars, we only roast the ones we love.

ProjectPipe.com Success Story published on python.org

Python.org has a number of very interesting Success Stories of how various organizations are using Python to solve real world problems. With all of the focus on web development frameworks and such, it’s interesting to see the diverse set of problems that Python is addressing every day.

In our new case study titled Botonomy Uses Python to Create ProjectPipe.com for Web-based Project Management, I give a high-level overview of both the “why” and the “how” behind ProjectPipe.com, our hosted project management solution.

The article talks about the problem that we set out to solve, and walks through one of the more detailed “behind the scenes” overviews of ProjectPipe that we’ve published to date.

Apple iCal Server runs on Twisted

There was a bunch of news coming out of the Apple Worldwide Developer Conference (WWDC), but in my opinion, the story with the lowest “press-coverage-to-significance” ratio is around Apple’s iCal Server. It turns out that the server itself is written in Python using the Twisted networking framework.

Yesterday, it was also announced that Apple officially joined CalConnect, the calendaring and scheduling consortium. The iCal Server supports CalDAV, the up-and-coming standard for standards-based calendar and scheduling over commodity web infrastructure. For more info on CalDAV, check out this CalDAV article on NewsForge.
I find this interesting from three perspectives:

1. SMB Market Expansion: Apple’s movement into the calendaring space will provide another viable alternative to Exchange, especially for new businesses. Before WWDC, the rumor mill was buzzing about Apple getting into the Voice-over-IP (VOIP) business. I think that this is the classic Apple play: Take a useful technology that works, package it in an elegant interface, make it easy to use, and then cast the problem so that people say “Why didn’t it always work this way”. An easy to use Calendaring and VOIP solution from Apple would be a game-changing moment.
2. Ruby vs. Python: It puts some context around the announcement that Ruby on Rails will ship with Leopard (OS X 10.5). The bundling of Rails is great news for everyone involved. The Rails community is very much pro-Mac (all of the core commiters, and the vast majority of Rails developers work on Macs (much to the delight of Allan Odgaard, developer of the phenomenal TextMate text editor).

   However, the fact that Apple is building new, high-profile applications using Python should indicate that Apple is not likely to be a one-trick pony when it comes to dynamic languages.

3. Additional validation of Twisted: The fact that Apple is using Twisted as the foundation for something as strategically important as Calendaring should reinforce the well-deserved image and reputation of the Twisted team and the software that they produce.  In time, this is certain to introduce Twisted to the greater IT industry, and make Twisted-based applications much more interesting to the broader market.