Entries Tagged 'Programming' ↓

The Decline of Drupal, or How to Fix Drupal 8

Prologue

Almost 4 years ago I wrote a controversial post entitled "17 Reasons WordPress is a Better CMS than Drupal" that caused me to be persona non grata among some of my prior Drupal friends.

But while some of the issues I mentioned have been addressed by the Drupal community most of the issues remain in Drupal 7, and WordPress has continued to gain strength as a CMS.

Unlike almost 4 years ago, I’m now seeing many people replacing Drupal solutions with WordPress and the end users becoming happier. My team is even bidding on replacing a website so we can build a member’s-only private site to go with it after the Drupal developers have not been able to deliver on the private site for over 2 years.

The Impetus

What triggered me to write this post was I was composing a long reply to a comment on the other post and it became clear it would be better as a new post.

In the comment the commenter asserted:

With Drupal 8 coming up, I am sure the difference in number of users between Drupal and WordPress will come down.

However, I think that the commenter will find that the exact opposite happens. Why do I think this? I started college shortly before the IBM PC was released so I’ve seen enough computer industry history firsthand to know a bit about the patterns that repeat related to software platforms.

Will Drupal 8 grow Drupal’s User Base?

I highly doubt it, and I think there is strong evidence in the history of software platforms that would support my view. Those patterns I mentioned above indicate to me that the strategy of changing Drupal’s architecture in Drupal 8 will be a failing strategy.

Let me explain.

Fans Like Things As They Are

As with all software products and platforms that gain a notable level of success, Drupal 7 and earlier appealed to people who valued what Drupal had to offer. Some of those things include ease of end-user configuration and other things include hierarchical software architecture and the hook-based extensions mechanisms. Or at least those are what originally appealed to me in Drupal before I discovered all the downsides I explained in the prior post.

Now Drupal 8 promises to be a lot more "modern frameworks and platforms," adopting "modern PHP concepts and standards, object-oriented programming, and the Symfony framework." Now that sounds awesome, and on the surface should cause almost any Drupal fan to cheer.

But those stated aspects require a lot more programmer skill to work with yet one of the things that appealed to a lot of Drupal users-cum-developers is that they did not have to understand object-oriented programming, nor modern frameworks and techniques. To quote Jennifer Lea Lampton:

Back in the day, Drupal used to be hackable. And by "hackable" I mean that any semi-technical yahoo (that’s me, btw) who needed a website could get it up and running, and then poke around in the code to see how it all worked. he code was fairly uncomplicated, though often somewhat messy, and that was fine. At the end of the day, it did what you needed.

Given the fact far fewer people have a high-level of programming skill many of those who do NOT see themselves as professional programmers do not want to improve their coding ability, they would rather just focus on their chosen career where Drupal is only a tool to help them.

So Drupal 8 will be will be alienating all those users and they will feel abandoned. Or as Ms. Lampton says:

Today, the majority of the people in our Drupal Community aren’t CS engineers. They are self-taught Drupal experts, people less technical than myself, and people who can get by using this awesome software we’ve developed to help make their lives easier. What is the transition to Drupal 8 going to be like to them? Well, I asked some non-core developers, and I didn’t like what I heard.

A lot of professional Drupal developers already have exit strategies.

And my guess is that most of those alienated users and new users who would have otherwise chosen old Drupal will move to WordPress.

But Pros Want to be Pros

And on the other end of the spectrum are those who DO see themselves as professional programmers and those people (almost) always want to increase their coding skills. They will start asking themselves why they are working on a platform (Drupal) that still has lots of "impurities" when the could just more over to a "real" framework such as Symfony or even Rails or Node.js, and not have to deal with all the legacy issues of Drupal?

Or as Ms. Lampton continues (emphasis on WordPress mine):

They may even have a day job building or maintaining Drupal 6 and/or Drupal 7 sites, but they go home at night and study Ruby, Node.js, Angular.js, even some are looking into WordPress. They want to be "out" before they have to learn Drupal 8. These are smart, capable people, who I’m sure - if they wanted to - would be able to pick up Drupal 8. So, why are they leaving? Because Drupal 8 has become different enough that learning it feels like learning something new. If they are going to invest in learning something new, why not Ruby, or Node.js, or something else?

What Visual Basic’s History Can Teach Us

What makes me think the above scenario is likely? Because I saw it happen with Visual Basic and C#. Visual Basic pre .NET was easy to use and became arguably the world’s most widely used programming language for a time. But it was a ugly language with many inconsistencies and was very limited in what it could do compared to C++ so it was always looked down on by "real" programmers ignoring how Visual Basic empowered so many people who never would or could develop using C++.

So Microsoft envisioned a "better" way; a .NET platform on which both Visual Basic and a new language called C# would live making Visual Basic a "proper" programming language, almost on par with C+.

Fast forward to today and what happened was that those who valued Visual Basic’s simplicity continued to use the old Visual Basic (for a while), abandoned it for other tools that were easier, or just quit developing and focused on other parts of their career.

Those who wanted to become better professional programmers asked themselves "why stay with VB?" so most everyone just moved up and over to C#. This migration effectively killed off what 10 years ago was once the most popular programming language in was the world.

And I believe a pattern similar to the Visual Basic decline will occur with Drupal starting at version 8.

When Upgrades are Challenging People Evaluate Options

And then there are those who will stick with their current version of Drupal until they can no longer maintain the solution and still get the evolving solutions they need for web and mobile.

At which point these people will be forced with a choice; migrate to the newer Drupal, or migrate to a different platform? And given how little interest the Drupal core team places in 1.) "Being backward compatible" and 2.) "Creating an interface that is usable for end-users" the choice will often not be "Move to newer Drupal."

True Believers will be True Believers

Of course there will still be people who love Drupal 8. And unlike proprietary software like from Microsoft, Drupal 8+ will continue to exist as long as a group exists who are passionate enough to maintain it. But I am almost certain Drupal’s market share will drop significantly and lose most of it to WordPress (which BTW won’t make that much different to WordPress’ marketshare, by comparison.)

Don’t Mess With My Status Quo!

And this being the open-source world, Drupal has already been forked and the fork is called Backdrop from the same Ms. Lampton quoted above as well as Nate Haug. Assuming Ms. Lampton and Mr. Haug and team executes at least reasonably well then some of the more fervent believers in "Drupal Classic" will move over to Backdrop, and Drupal 8 will loose more marketshare from yet another source.

But Backdrop will almost assuredly never be more than a footnote because it won’t have the marketing muscle in IT shops that Acquia has, and IT shops have been the primary drivers of Drupal adoption from best I can tell looking in from the other side. And Backdrop being a fork won’t have the 10+ years of supporting organization that Drupal now has. Plus, Backdrop has an unknown brand at this time and building up that brand will take time.

Old Doesn’t Inspire, It Just Fades Away

Given that Backdrop is basically a stake in the ground to avoid evolving Backdrop is highly unlikely to become "the hot new thing" but will instead be like FoxPro that for years after Microsoft acquired it was "a user base Microsoft could not grow and Microsoft could not kill"; that’s a direct quote from a former marketing manager at Microsoft.

The Shrinking Girth: Traveling Up the Pyramid

So Drupal 8 will be pushed by Acquia into IT shops, but it will be used by an increasingly narrow user base until the user base becomes so small that Acquia can no longer survive.

This long tail may take a really long time, but I am certain it is inevitable, unless of course Drupal/Acquia/Dries change strategy.

What SHOULD Acquia/Drupal Do Instead?

So here’s where I’ll divert from my criticism of Drupal and advocacy of WordPress; I’ll actually recommend what I think Drupal/Acquia/Dries should do and how they could potentially grow their business even if they do not catch WordPress in marketshare.

Announce the Drupal 8 Will Be "Drupal 7 Enhanced"

Dries Buytaert should do an about-face and announce that Drupal 8 will NOT be based on a new architecture but will instead simply be an enhanced Drupal 7, much like the about-face Tim Berners-Lee famously did when he announced XHTML was no longer the future of the web.

Adopt the Backdrop Team for Drupal 8 and Beyond

Dries should then work the Backdrop team and any of the Drupal 8 team who want to continue the status quo albeit with evolutionary improvements, much like how Merb broke off from and was later merged back into Ruby on Rails.

Further, adopt a no-breakage policy for future Drupal releases and work to ensure backward compatibility so that people are not forced into painful upgrades if they do not want to invest a significant amount into redevelopment. Learn from WordPress how to evolve without introducing breaking changes.

Announce a New CMS Called "Acquia"

Then, take all the ideas and lessons learned with Drupal that were destined for Drupal 8 and create a clean from-the-ground-up implementation of a next generation CMS targeting those who work rather program at the level of a framework but prefer to have more of the features needs for content management ready-built and available so as not to require people to reinvent the wheel.

Launching an Acquia CMS would have the benefit of being new in a way that could appeal to more than just the existing Drupal user base that does want to level up but not abandon Drupal. And Acquia is already a very strong company that has a stellar enterprise sales and support team so they would be in a great position to market a new CMS, and launching it would give them a stronger offer to sell to and support for their customers.

Acquia CMS could become the better alternative to Symfony that offers more functionality without all the legacy cruft of Drupal instead of Symfony being viewed as the better alternative to the Drupal CMS that carries so much baggage which is where I think things are headed.

Give Developers Something NEW To Adopt

And this branding is not just for technical improvements, it’s more important for positioning reasons.

Acquia CMS could have none of the negative associations developed by prior users of Drupal. Acquia CMS would be free to address all the problems I outlined in my prior blog post. And Acquia could once again become the CMS mindshare leader, a position that Drupal previously held IMO.

But Wait, Don’t Listen to Me!

If Drupal/Acquia/Dries does follow my advice, it would probably mean that I’d loose opportunities to work on certain future projects. The type of work I do with WordPress is most often competitive with Drupal in the minds the stakeholders deciding the platform the project will use. So I really hope they do not listen. :)

But hell, if they do follow this advice I would evaluate Acquia CMS and might even consider using it instead of WordPress in the future.

But really Dries if you are listening, please don’t! I’m currently really happy with the progression of WordPress and doing this would just throw a monkey wrench into my future works.

So nothing to see here; just carry on as planned. Nothing to see. :)

UPDATE

In the first version of this post I incorrectly referred to the fork as "Backstory", not "Backdrop" and I did not include a link to the Backdrop website nor mentioned Nate Haug. I have corrected the post.

Thanks to commenters Doug Vann, Brian and Jen Lampton for pointing out my error.

A Crash Course in Software Quality

It occurred to me recently that while intuitively obvious to many the concept of “Software Quality” is probably something never actually studied by the average developer who doesn’t have a formal computer science education.

Yet understanding software quality beyond intuition has been extremely helpful to me over the years as a programmer and software architect. And while there are many amazing self-taught developers it’d be a shame for me not to blog about it since I can cover the essence of software quality so quickly.

A Bit of Personal History

It was back around 1988 I was first learning OOP, also known as “object-oriented programming”. One of the few books avaiable on the subject was “Object-Oriented Software Construction” by Bertrand Meyer, but of the books available I probably learned more from it than any other. I’ve learned an amazing amount since but it was from that book I learned many of the foundational principles I still use daily as a software architect.

I still think most of what was covered in the book’s 2nd edition is relevant. If you are interested in reviewing it to decide if you want to read it I found a copy online but you can buy a used one for US$0.01 on Amazon.com

The External Factors of Software Quality, Named

The first chapter in OOSC covers Software Quality. To explain the concept Meyer simply defined numerous related terms, which he called “External Factors”, and wrote a few paragraphs about each. I’ve edited his definitions slightly, for brevity, and I’ve included them here as your crash course in software quality. Enjoy!

  • Correctness - The ability of software to perform its exact tasks, as defined by its specification.
  • Robustness - The ability of software to react appropriately to abnormal conditions.
  • Extendibility - The ease of adapting software to changes of specification.
  • Reusability - The ability of software elements to be used to construct different applications.
  • Compatibility - The ease of combining software elements with others.
  • Efficiency - To place as few demands as possible on processor, memory and bandwidth.
  • Portability - The ease of transferring software to different computing environments.
  • Ease of use - The ease with which various people can learn to use software to solve problems.
  • Functionality - The extent of possibilities provided by a system.
  • Timeliness - The ability for software to be usable when or before its users need it.
  • Verifiability - The ability to detect failures and to trace errors during operation.
  • Integrity - The ability of software to protect code and data from unauthorized access/modification._
  • Repairability - The ability to facilitate the repair of defects.
  • Economy - The ability of a system to be completed on or below budget.

Take these terms and commit them to memory. And when building software ask yourself “How does my software fare with respect to these factors?” If you can answer that your software fares well then you can rest easy in knowing that you are probably a developer who builds quality software.

As a side-note, after having learned OOP in the late 80’s I’m still surprised when a professional WordPress developer says, in 2014, that “I don’t really understand OOP.” Time to get with the program, I say!

What the World Needs is a Markdown IDE for Programmer Documentation

As an active JetBrains’ PhpStorm user one of my feature requests was for First Class WYSIWYG Markdown/Markdown Extra Support. Unfortunately they told me (and others) to use a 3rd party plugin which given it’s lack of quality and features turned out to be a non-starter for me. So I continue to use Markdown Pro which I love for what it is but I really need an order of magnitude more features.

But today I was thinking hard about how I’m going to implement documentation for the project I’ve worked on over the past 3 months without killing myself. A sad realization came over me that using MarkDown Pro would be very painful to use because it’s really nothing more than a glorified Notepad with Markdown support and a preview window; it has nothing to support me in the developer of documentation projects.

Then it hit me; what I really need is not an ability for PhpStorm to edit markup but instead a full-featured documentation IDE targeting programmers. And frankly I think the company best positioned to offer this would be JetBrains but I’d be happy to see any company offer it, if someone just will (Maybe those Sublime guys could…?)

So if you are from JetBrains or from some other company please consider the following feature set:

Features

Here are just some of the features that I’d love to see a Documentation IDE support

  • Manage "Documentation Projects" vs. just individual markdown files.
  • Multi-pane editor like PhpStorm but with panes that support document creation.
    • Vertical or horizontal split edit and preview windows.
  • CSS-based Themes for preview.
  • File Watchers for post processing LESS, Saas another other features.
  • Version control support for Git, Mercurial, SVN, etc.
    • Support for docs in a subdir of a code repository or as independent repo.
  • Support for all major Markup/Markdown format including Different Dialects and HTML
    • Conversion between Markup/Markdown formats
    • Ability to configure all and/or specific documents to be edited in one format/dialect and saved in another.
  • Ability to Publish and Maintain Documentation Websites from DocStorm
    • Publish directly to GitHub Pages as well as maintain existing GitHub pages.
    • Publish to Evernote, DropBox, etc.
    • Offer "POST-To-Publish" feature that would allow us to publish and update using HTTP POSTs so that we could write our own server-side integrations to other locations besides GitHub such as CMS (WordPress, Ghost, etc), Wikis (Mediawiki, etc.), SaaS platforms and more using our own PHP, Ruby, Python, Node.js or other code server-side code.
  • Navigation Between Documents
    • Jump to Document via selected hyperlink
    • Jump to Section of Document via selected hyperlink+fragment
    • Jump to File by Name
    • Jump to Headings in Project (find by autocomplete)
  • Refactoring
    • Refactor Document Structure to change all affected links
      • If URL changes
      • If URL fragment changes
    • Move selected content into a new file and insert a link to the new file.
    • Provide a tree view of files and allow refactoring by drag-and-drop in tree view, with all necessary link fix-up.
  • Manage Images
    • As part of the project, relative to the project root
    • Enable images to be previewed inline
  • Search and Replace like the wonderful PhpStorm search & replace)
    • Regular expression search.
    • Highlight on up/down arrow of selected options.

Also potentially valuable would be integrations with existing documentation tools although I can’t yet envision exactly what that would look like:

Benefits to JetBrains

Back to JetBrains and why they should do this. Currently they have IDEs for Java, PHP, Ruby, Python and Javascript programmers and for the most part (I would assume) few of their customers cross over and purchase multiple tools. However if they were to offer a "DocStorm" then every one of their current IDE customers they might be able to up-sell a sizeable number of developers.

But even if they won’t do it, maybe someone else will? 

Update

If you like this idea please vote for it on the JetBrains tracker

Update 9-Oct-2013

So JetBrains considered the idea, but decided against it. :-(  But they have changed their mind in the past if they’ve had enough requests, so please vote for both these tickets, if you will:

Better yet, if you are in the editor space and looking to expand your market, please consider building this flavor of your product and I expect you will find many new customers.

17 Reasons WordPress is a Better CMS than Drupal

This blog post has been simmering inside me for while. Some might think it as link bait but frankly I don’t blog often because I don’t have the time to manage lots of comments. So the thought of posting something that will likely be controversial has me going against my better judgment (but it won’t be the first time I’ve done that. :)

Drupal is for Serious Web App Dev but WordPress is Just Blogware?!?

Say what?!?!? Although the conventional wisdom is that WordPress is really just a great blogging tools and Drupal is more appropriate when you need a full-featured CMS for business use, the conventional wisdom is unfortunately outdated. Since WordPress released version 3.0 in mid-2010 there are now very few if any good reasons to use Drupal instead of WordPress when your business needs a CMS.

Heresy?

Maybe, but history has shown much heresey to be the voice of truth later vindicated. However, rather than ask you to just take my word for it, I’m going to explain below 17 tangible and specific reasons why WordPress is a much better choice for a business CMS than Drupal. 

Just the Facts

But for those of you who can’t be bothered to read the details I can summarize in two (2) points:

  1.  Site Architecture and
  2.  Backward Compatibility

Drupal’s site architecture, which on surface appears quite elegant is in reality Drupal’s biggest weakness. Drupal projects can start very inexpensively with large initial wins but the costs to add increasing functionality are discontinuous and in my experience soon soar out of control. I’ve seen several Drupal projects fail simply because of Drupal’s architectural inflexibility; many projects becoming difficult if not impossible to complete On the other hand there is WordPress’ architecture which, while seemingly less sophisticated and with more code duplication nonetheless enables the perfect combination of flexibility and unlimited functionality in my opinion where the increase in cost for more functionality scales linearly starting from zero.

As for Drupal’s position on backward compatibility they only maintain compatibility between major versions, which means you’ll be probably be forced into having to do a fork-lift upgrade since they only official support one major version behind. Who in their right mind would put their business in such a position? WordPress, on the other hand, bends over backwards to maintain an upgrade path between 0.1 versions.

About Terminology

WordPress and Drupal have some different terms for similar concepts and the following might be confusing if you are not aware of how these terms relate.  What WordPress calls a "Custom Post Type" Drupal calls a "Custom Content Type."

In WordPress a developer uses the register_post_type() function to define a custom post type whereas in Drupal a developer or user defines a custom content type in the admin console using the "Content Creation Kit" module (a.k.a. "CCK".) WordPress calls all content items "posts" (which is the generic term for the more specific "Pages" and "Posts"; confusing, I know, but that’s for legacy reasons. Drupal on the other hand alternates between calling content items "Content" at times and "Nodes" at other times.

Both WordPress and Drupal use the term "Theme" to refer to the collection of files that collectively create the unique look and feel for a site. Themes are comprised of some or all of these items: PHP scripts, HTML, CSS, SQL queries, Javascript, Images, Flash and maybe more. Themes are designed to be interchangable so that by replacing a theme a site can be given an (almost?) completely different look.

For extensiblity both WordPress and Drupal support the concept of componentized functionality with WordPress calling their functionality "plugins" and Drupal calling their functionality "modules." Aside from some technical implementation differences both plugins and modules are conceptually the same; componentized functionality. They are both typically comprised of PHP scripts and HTML but like themes may also incorporate CSS,  SQL queries, Javascript, Images, Flash and more.

As for versioning, WordPress strives every four (4) months (but it sometimes takes six) to launch a "point 1" or 0.1 version increment (such as v2.9, v3.0, v3.1, etc.) whereas Drupal uses major and minor versions (i.e. v5.x, v6.x, v7.x, etc.) with no specific release schedule between major versions.

Now with that out of the way, on to the 17 reasons.

17 Reasons to Pick WordPress vs. Drupal:

  1. WordPress Allows Infinite Design Flexibility - Drupal not so much. Because of it’s fundamental technical architecture most Drupal sites have a certain look and feel that is very difficult to get away from (note the "I think though doth protest too much" quality of these three (3) posts),   WordPress is as flexible as HTML because of it’s architecture.

    More specifically when a browser requests a web page from a Drupal-based website, Drupal inspects the requested URL and then delegates reponsibility for generating parts of the HTML page to both applicable modules and to components of Drupal itself. Drupal then collects up the generated HTML and composes a completed  HTML page when it sends to the browser.  Drupal manages everything and this archecture is minimizes duplication of responsibilities and is an architecture that an engineer can truly love.

    Unfortunately Drupal’s architecture is also highly coupled and thus rather inflexible; when you want a web page that doesn’t fit into Drupal’s model you either 1.) learn complex and arcane methods to achieve what in pure HTML would be incredibly simple, 2.) rebuild major portions of Drupal functionality for your custom page or 3.) just give up and do it the way Drupal wants you to. Or as I like to say when explaining this unfortunate aspect of Drupal:

    As a Drupal developer you are constantly battling Drupal to get back in control of the HTML that it will output for any given URL. Drupal is like a "Roach Motel" for URLs: Once a URL enters Drupal it never leaves!

  2. Usability has been "Baked-in" to WordPress - With Drupal, usability was an afterthought until version 7 and they’ve been desperately trying to improve it; usability tests by the Univeristy of Baltimore identified many critical usability issues in Drupal (the video is a must watch.) But some things such as usability need to be central to the philosophy of the developers and not tacked on as an afterthought. In Drupal you frequently need to visit at least two different pages in the admin to affect what a user would see to be one external change. With WordPress the admin console was originally user tested by the project founder’s mother ("If mom can use it, anybody can!") and that fanatical concern for usability has permetated the project. In Drupal some of the more active developers are known to say "If you don’t find Drupal usable maybe Drupal is not for you."
  3. WordPress has a WYSIWYG Content Editor in Core - Also a usability issue but an important specific one, with Drupal there is no standard WYSIWYG editor leaving the site implementor to choose from thirteen (13!) suboptimal editor module choices, none of which are maintained at the same level of Drupal core.  In WordPress, TinyMCE has been a highly usable standard for more versions that I’ve been using WordPress. (Personally this was one of the biggest issues I had with Drupal and why moving to WordPress was such a godsend for me.)
  4. WordPress Strives to Maintain Backward Compatibility - Drupal wears as a badge of honor that they wipe the slate clean with every major version. Drupal mostly ignores backward compatibility with the prior major version because yes it is nicer for the core developers not to have to worry about backward compatibility. But for your business the reality is that if you implement a site using Drupal you are stuck on that major version until you choose to invest in an expensive rewrite of your website. 

    Ponder this issue for a moment.  In my opinion, choosing Drupal can result in a nightmare once the version of Drupal they are using becomes too obsolete and is no longer supported. This is such a huge negative that I can’t really see why any business that is doing their due diligence would ever choose Drupal no matter its feature set.

    With WordPress most upgrades are seemless and those that are not are usually easily fixed because of the attention to maintaining backward compatibility.

  5. A WordPress-based Website’s Source Code is Easier to Manage - Drupal co-mingles user content with what is in effect a website’s source code in much more significant ways than WordPress does.  For example, to design of "Custom Content Type" in Drupal gets stored in the MySQL database; in WordPress "Custom Post Types" are stored as PHP code. For any business website managed by professionals it is critical to use a source code version control system and it’s easy to submit PHP code to version control but very difficult to submit records in a database to version control. This fact alone is a extremely strong argument for WordPress and against using Drupal for any serious website development project.

    Yes out-of-the-box Drupal is easier for a non-technical power user to add custom content types compared to with WordPress, but we are not talking about the needs of a housewife to organize her recipes, we are talking about which one is the better choice for a business CMS and WordPress wins hands down in this category. (BTW, there are plugins for WordPress such as Custom Post Type UI that provide the end-user with the same ease of use for creating custom post types that Drupal has for creating custom content types.)

  6. Collaborative Development is Easier with WordPress - This reason is a variant of source code being easier to manage. Without a good version control strategy it is much harder to get a local copy of a website for development. Developers in a Drupal shop have to spend a lot more time merging their databases so the up-shot is that many Drupal developers co-develop on the same installation, and often the live installation at that which results in overwriting each other’s code and limits a developers ability to roll back.  It’s much easier to develop with a local copy of WordPress so WordPress developers tend to do it more often.
  7. Revisions of WordPress-based Websites are Easier to Deploy - This reason is also a variant of source code being easier to manage. 1 but the headaches are seperate so I list is as a seperate reason. Because WordPress maintains a lot more of its logic in PHP code WordPress is much easier to deploy than a Drupal application. Drupal developers end up writing a lot more SQL code that they then need to test everytime they need to merge data used to control new application logic into the database of a production webserver on deployment of a revision to an existing website. The significance of this is hard to underestimate.
  8. Easier to Find Skilled Designers for WordPress -  To create a beautiful website design for WordPress designers need to be good at design, of course, but beyond that they really only need to learn how to copy and paste "Template Tags" as they able to have full design freedom when producing the HTML that will be used for a WordPress theme.

    Drupal designers, on the other hand, need to be skilled PHP developers too and with a rare exceptions those two skillsets are mutually exclusive. When you do find someone who can do both and do both well, they will be hugely in demand and thus outrageously expensive but the real problem is with Drupal you really won’t know if they are one of the rare few until after you’ve paid them a lot of money to either create a "house of cards", or a really ugly house.

    With WordPress you can get a great designer to work with a great developer, both of which are easier to evaluate than combined greatness, and you are set.

  9. There are More WordPress Professionals Available - A corollary to finding skilled designers, it’s simply much easier to find WordPress professionals to hire for projects than it is to find Drupal professionals.
  10. WordPress Professionals Charge Lower Rates - Another corollary to finding skilled designers and more WordPress professional being available is it is less expensive to find a WordPress professional than a professional for Drupal.  If you ignore the fact that there are many more WordPress professionals another factor is WordPress professionals don’t need to be as proficient in as many areas as their Drupal counterparts.  People who can really make Drupal sing are really expensive.
  11. WordPress’ Code is Much Easier to Debug - Drupal’s highly nested architecture makes it so that a developer spends most of his time looping through a few core functions waiting to find which code controls what they need to modify.  Often with WordPress the developer can simply set a breakpoint on the theme’s template file and debug from there.
  12. WordPress Sites Load Much Faster than Drupal Sites - Drupal runs upwards of 100 SQL queries for every page load because of its site architecture. With WordPress the number can easily be less than 10. And the time to run those SQL queries easily add up. Drupal advocates will claim those queries can be made insignificant by the creative use of caching but the reality is that you cannot cache most items in the admin console so the end user who is forced to use Drupal will be saddled with a level of fatiged and is just not necessary, if you instead choose WordPress.

    And lest you feel this is unimportant technical concern be aware that site performance is now something that Google uses to determine search engine result rankings. Host your website on a slow platform and prepare for an uphill battle when it comes to achieve top rankings in Google’s search engine results pages.

  13. WordPress Requires Less Expensive Hosting - A corollary to page load performance is that the typical Drupal site requires a lot more server to serve each of it’s pages than does a typical WordPress site. Those who choose WordPress for a seriously high traffic site will usually find they can serve more pages with the same servers and/or that the memory requirements for WordPress will typically be a lot less. And for a high traffic sites this could either be real money and/or it can mean that the site is less likely to fail in the case of a flash mob such as a Slashdotting.
  14. WordPress has the Most Integrations -  More companies or their 3rd parties offer plugins for WordPress to integrate with their services than another other platform, specially more than modules available for Drupal. Twitter, Facebook, Freshbooks, MailChimp; you name it, they all have WordPress plugins. If you need one for Drupal and it’s not a mainstream service like Twitter or Facebook chances are you’ll have to pay to have it written.
  15. WordPress has More Robust Extensibility Method - Both WordPress and Drupal use the term "hooks" to describe their exensibility mechanisms and while there are similar there is an important technical difference. In WordPress you associate a bit of functionality to either run or filter a value based on the name of the hook and you can have as many hooks of each type as are needed. In Drupal you do the same except that hooks are identified hook name prefixed with module name which means you can only use a given hook once in a module; if you need to use it twice you have to create another named module.

    Of course the module name limitation is an annoyance but not a huge problem. The huge problem comes when you need a module to disable a hook that was enabled by another module you otherwise need. This is a technique used somewhat frequently in WordPress but when it’s needed it is essential. In Drupal, even if you need to you simply can’t. And all because of Drupal’s architecture choices.

  16. WordPress has Far More High-Quality Attractive Themes - Drupal has almost two orders of magnitude less.  Why is this the case? Because it is so much harder to create a Drupal theme (as mentioned above), designers have to be good developers to theme Drupal (also mentioned above) and there are just so many more people using WordPress.

    Now having off-the-shelf themes is great for micro-businesses, startups and even tactical projects but most businesses will want a custom theme developed to showcase their brand in the best light possible yet the existence of so many commercial themes still benefits those who need custom themes.  Why?  Because it means that collectively WordPress custom theme developers have a lot more experience developing quality themes than their collective Drupal counterparts because many WordPress designer offer up commercial themes for sale in addition to their bespoken work.

    And then there are the theme frameworks for WordPress like StudioPress’ Genesis and WooTheme’s Canvas which create excellent headstarts for theme designers with lots of pre-built functionality that designers would often have to charge clients to develop.  Drupal does have the concept of theme frameworks but they are really an esoteric option for Drupal.

  17. Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal - Yes an attempt has been made but there’s just not enough community support for a Drupal Answers (yet?) And while this reason may seem gratuitous, believe me it is not!

    The official support forums for both Drupal and WordPress and even the mailing lists for WordPress evidently encourage a level of disrespectfullness that is pervasive in so many open-source communities and it can be a huge time sink for the business person who just wants a problem solved. On the other hand the mechanism used by StackExchange’s WordPress Answers brilliantly encourages timely and helpful support discourages such unproductive behavior with its reputation system.

    And whereas many support queries on the Drupal (and WordPress) forums go unanswered, the majority of questions receive a reasonable answer on WordPress Answers (currently at 94%.)  If you have a WordPress issue you need solved, or that your developer needs to solve, the existence of WordPress Answer compared with the non-existence of Drupal Answer means that solutions will come far more quickly and far less expensively.

So there you go.  17 Substaintial Reasons why WordPress "The open source blogging tool" is a far better pick when selecting a CMS for business use compared with "*The* (2009) open-source CMS" Drupal. (Oh, and the judges picked WordPress as the best CMS for 2010.) Need another opinion? See Wikipedia’s criticisms of Drupal and the relative lack of criticisms about WordPress.

Of course it would be unfair and disingenous of me to call out WordPress strengths and Drupals weaknesses without also telling you where I see weaknesses with WordPress and strengths of Drupal and for me not to tell you what are the use-cases where I’d be hard-pressed to dismiss Drupal in favor of WordPress. So here you go:

  1. Drupal Allows for More Flexible URL Design - Since WordPress grew up as a blog they hardcoded the URL routing logic which has resulted in some rather odious limitations in how you can design your URLS.  Drupal’s URL management is no panacea either — you can end up with a difficult to maintain mess — but at least Drupal *allows* you flexibility that is often just too hard to implement robustly with WordPress

    (Note: I have a plugin on the drawing board whose goal is to remove this limitation from WordPress. Once it sees the light of day  I believe WordPress’ URL routing will be much better than that of Drupal. But alas, at least today, Drupal wins in the URL category. If someone using WordPress really badly needs better URL routing in WordPress and can fund the plugin development please contact me as by nature my priorities are defined by my client’s needs.)

  2. Drupal Offers Out-of-the-Box Content Type and View Creation in the Admin - Yes, out of the box a saavy end user with adminstrator rights can create and define Custom Content Types with custom fields and even custom reports/queries called "Views." This enable and end user with the time to learn Drupal to build a content-based system without any developer help. And for certain scenarios this would be invaluable, such as in certain government or academic departments were there is zero budget for development today, there never will be budget, and the end user either does not want to or is simply incapable of learning how to write the simply PHP required to register custom post types in WordPress.

    On the other hand, there are WordPress plugins that duplicate the functionality of CCK and there are numerous plugins that expore the Custom Post Type registration via a UI in the WordPress Admin.  Still, as far as I know, there really is not WordPress equivalent of Views.

    Still, even though you can create custom post types in WordPress using a plugin that exposes an admin UI it doesn’t mean you always should. As I said above I highly recommend that anyone business that is having custom solutions built using WordPress not build them using an admin UI for defining custom post types but instead embed that logic into version-controllable PHP files.

    As for Views, it’s basically the same recomendations as for custom post types; rather than store them in the database like Drupal does it works much nicer just to code calls to WP_Query into PHP code; easier to version control and also easier to test, verify correct and certain that aspect of the site to be bug free.

  3. Drupal has Positioned Themselves Better in the Eyes of Large Enterprise - Here’s where I think Drupal has succeeded brilliantly. Because of the efforts Acquia’s products, services and solutions there are many large companies that believe in Drupal. I believe they have done a much better job of courting the Fortune 500 crowd than WordPress has via Automattic and it’s VIP Support and Hosting offering.

    That’s not to say there are not some really phenominal companies delivering enterprise class solutions on the WordPress platform such as Voce Communications and TayloeGray just that there is a segment of decision makers in large business who will only consider working directly with the primary vendor and in these two cases the primary vendor for WordPress is Automattic and the primary vendor for Drupal is Acquia. And while I love WordPress and think highly of the team at Automattic it’s clear to me that Acquia have done a much better job of positioning themselves as a company that provides enterprise class support for their platform.

But what about Drupal for Community Sites?

One of the use-cases oft cited for Drupal’s superiority is for community sites.  But frankly, I don’t buy it. 

As an active member of the Drupal community for two years (speaking of which, I need to update my profile there) I found drupal.org to be an extremely frustrating website in which of participate in a community. The forums were not at all effective in the ways that other forums I’ve seen like vBulletin have been effective, and using them as a user was far more pain then pleasure (by contrast I find StackExchange mechansim at WordPress Answers to work brilliantly but alas it’s not software you can implment for your own community.)

Actually at this point I think it’s counter productive to set up yet another social network but if you are convinced your strategy makes sense I’d be included to launch it on BuddyPress instead of Drupal, and BuddyPress is now a plugin for WordPress. And one of the really great aspects of BuddyPress is it that it leverages the brilliant network/multisite feature of WordPress which has completely nailed the "single install - multiple website" architecture.

Who am I to Judge WordPress vs. Drupal?

Full disclosure, I’ve been making my living as a WordPress specialist for almost two years and I plan to launch a company that provides tools and support for professional website developers and interactive agencies who have chosen WordPress as their platform for client solutions. The reality is that I could easily choosen to do the same for Drupal but did not. 

I spent two years working with Drupal as my preferred platform, from mid 2007 through early 2009 and I gained experience working with versions 4, 5, and 6. I was drawn to Drupal by it’s elegant architecture (I’m an engineer by degree and thus appreciate elegant technical architectures) and frankly by the fact that Drupal was the only solution of the three main open source CMSes that  could actually be used as a CMS without obvious issues (why I avoided Joomla is the story for another day.)

Back in 2007 using WordPress as a CMS was simply not an option, so I moved forward and became enamoured with Drupal and it’s Custom Content Kit, Views and so many other (what seemed like) wonderful modules. I became active in the local Drupal Meetup group and spoke at several of their meetings. I registered a "DrupalCamp.com" domain with plans to launch a local DrupalCamp and more. I really drank the Drupal koolaid.

But then by happenstance I had finished a Drupal project and was looking for another when a 6 week project to write custom admin plugins for WordPress 2.7 fell in my lap.  Since I far prefer to develop admin functionality than full websites I figured "How hard can it be?" and took the job.  While I worked on these plugins I discovered WordPress much easier to develop for than Drupal but I still held on to the notion I’d return to doing Drupal work once the project was done. As the project progressed an inner conflict raged as I came to prefer WordPress all the while mourning what I would be loosing if I were to leave Drupal (CCK and Views, mostly.)

However by the end of the 6 weeks it became crystal clear to me; WordPress was a much better system than Drupal even without all the CMS features. I was reminded of how many personal Drupal projects I had unfinished simple because it’s do hard to get a good looking site completed in Drupal, the last 15% it pure hell to complete. So I decided I would build my own CCK equivalent and use WordPress instead. Honestly, it didn’t go so well with WordPress at first. Trying to create my own CCK was fraught with frustration and I wasted copious time trying to bend WordPress to my will. But I did and limped along.

Then v2.8 came out. And then v2.9. And then finally v3.0 was announce with Custom Post Types and fortunately I was in a position to just on the beta version. It soon became clear to me that the WordPress team got Custom Post Types right and that v3.0 was going to be a watershed release and, as they say, the rest is history. 

As I write this v3.1 is going into beta and with its Internal Linking Dialogs, Post Formats and more WordPress continues to prove that it really is the best choice for almost every business CMS need out there.

So Why Did I Write this Post?

Recently I met with a Senior Vice President of Strategy and Innovation at a large well-known non-profit who is planning to launch a major initiative and he’d narrowed his choices of platform down to two (2): Drupal or WordPress.  On a personal level we hit if off fabulously so if it were just personalities I think he might be inclined to take my recommendation on faith but I sensed he is enough of a real professional that he looks beyond the personality of the advocates to assess the actual best solution for this organization.

What he wanted to hear from me which platform I thought was the best and why. I had already reviewed their design brief and wireframes so I had a good idea of what they wanted, and on the surface it looked rather much like a community app. Because of this and also because he had previously talked with several Drupal advocates I think he was leaning towards Drupal.  But looking at his requirements and given my issues with Drupal that I detailed in these 17 reasons it was clear at the day is long that WordPress would be a far better platform to meet his needs.

Still, as I tried to explain to him why Drupal would not be a good choice I felt that I might have been coming across as a bit too much of a WordPress zealot whose opinion was not based on objective reasoning. So I decided that I should  writing this up to make the case using objective criteria for anyone evaluating the two.

But I still didn’t get around to writing it up because there are always too many other things to do in a day. It wasn’t until a series of posts on Quora with the leading title "Why do so many people use Drupal instead of WordPress?" that I got off my duff and finally wrote this post (even though I have clients whose projects I probably should be working on!)

In Summary

While Drupal had the lead as best open source CMS for many years, WordPress has eclisped Drupal as the best open source CMS as of mid 2010 with the addition of Custom Post Types.

More specifically Drupal’s site architecture makes it a less than ideal platform for business websites when compared with Wordpress, and Drupal’s philosophy on backward compatibility make it really hard to recommend it to any company for almost any reason at all.

Postscript: About Comments and Revisions

If you are going to post comments:

  1. Be sure to include something specific about the post in your comment rather than a generic like "Yes I agree" or I might think is spam and delete, and
  2. If this post gets a lot of comments (which I fear it might) be aware that if your comment doesn’t appear for a few days it’s simply because my client demands have limited my free time and I haven’t had time to release it from moderation.

FYI, I plan to revise this post if new evidence comes to light, somehow I got my facts wrong, or I just identify more to add. Frankly I’ve never much liked the "write-once, forever outdated" form that most blog posts take, so why conform?

UPDATE (2010-12-13)

Alastair McDermott has just written a blog post on a very similar subject entitled "Why I Recommend WordPress as a CMS." It’s a good read.

UPDATE (2010-12-17) 

If you are going to leave an inflammatory comment criticizing my post then at least have the integrity to leave your full name, your email and a link to something where I can verify who you are and I’ll be happy to publish it (you know who you are.) Otherwise I’ll simply moderate your comment into the trash.

And for what it is worth, it looks like even the Drupal community knows about many of the problems with Drupal:

 

 

RESTful Web Services in a WordPress Plugin?

UPDATE (2011-04-15):

Since I wrote this post I’ve learned a tremendous amount about WordPress plugin development; so much so that I can’t overstate how much more I know today than when I wrote this post years ago.  So, while the following post might be a novelty to read, I highly recommend that you don’t use this approach.

The only way that a RESTful approach to web services in WordPress would make sense to me is if a team of rockstar WordPress plugin developers were to create a fully fleshed-out extension to WordPress that offered a complete RESTful web service implementation including one that addressed all edge cases and security concerns; only then I would consider not defaulting to the non-RESTful approach WordPress uses for AJAX.  

In summary I recommend not trying to swim upstream today and instead use the approach provided by WordPress. Who knows, maybe in the future there will be a viable method of doing RESTful web services in WordPress.


So I’ve got a project where I need to have a Flash component built in Flex to call to a WordPress blog and get information about it’s latest post. Should be no problem right?  The easy way to do this would be to just write a "rest.php" file and brute-force all the setup that WordPress does but I thought it would be so much more valuable to implement this as a plug-in.

I figured that I’d just quickly learn how to build a WordPress plug-in and create one for exposing RESTful web services; after all with a year of programming Drupal modules WordPress’ plug-in API can’t be that hard, right?  Well turns out it wasn’t that easy and I think I have run into a design limitation with WordPress and I’m beginning to wish I’d just taken the brute-force approach and said to hell with writing a plug-in.

Although I am not 100% certain, and I hope someone can point out that I’m just doing something wrong, it seems sadly like I’m pushing the edges of the WordPress API and exposing where it’s design falls short. By the way, I’m working with WordPress v2.5 because why upgrade mid-project when god knows if WordPress will release another in the remaining days before this project is done and I’ll just have to do again before deployment?

Here’s the details.  I started writing a plug-in called "RESTful Services" with a goal of implementing URLs that behave in the following fashion; {format} could potentially be html, xhtml, json, xml, rss, atom, etc.:

http://example.com/services.{format}
Provide a list of RESTful services in specified {format}, defaults to html
http://example.com/services/{service}.{format}/{data}?{params
Provide a RESTful service in specified {format}, defaults to html, with optional provided data and parameters.

But before I got all those options working I just wanted to service a page from my RESTful Services plugin where Content-Type: text/plain. I found this page that professes to explain how to hook into the URL routing and after a few fits and starts I can came up with the following code for my plugin that would indeed response to my http://example.com/services URL:

wp-content/plugins/restful-services/restful-web-services.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
add_action('init', 'restful_services_flush_rewrite_rules');
function restful_services_flush_rewrite_rules() {    
  global $wp_rewrite;
  $wp_rewrite->flush_rules();
}       
 
add_filter('generate_rewrite_rules', 'restful_services_add_rewrite_rules');
function restful_services_add_rewrite_rules( $wp_rewrite ) {      
  $new_rules = array(        
    'services' => 'wp-content/plugins/restful-services/rest.php',     
  );
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}

The problem with the above was that it wouldn’t call "wp-content/plugins/restful-services/rest.php"; it would simply continued to call "index.php" and display the home page!  After literally hours and hours of debugging with my trusty PhpEd IDE & debugger I was able to find that the code on lines 737 & 738 of "wp-includes/query.php" told WordPress that my service was the home page! It is almost seems like the "generate_rewrite_rules" was implemented as "a good idea" yet no testing has ever been done on it because for the best I can tell it doesn’t work. (Note I’ve reformatted the code to multiple lines so that it is easier to read and does not extend past the right margin of my blog):

wp-includes/query.php:

if ( !(  $this->is_singular                           
      || $this->is_archive                           
      || $this->is_search                           
      || $this->is_feed                           
      || $this->is_trackback                           
      || $this->is_404                           
      || $this->is_admin                           
      || $this->is_comments_popup ) )   
       $this->is_home = true;

I could possibly hack it to get past this by setting one of those to "true", but none of them are really appropriate; there is nothing there quite like an "is_service" instance variable. Setting something like "this->is_singular" or "this->is_feed" might work but it could manifest incompatibility problems with other plugins or future versions of WordPress. Frankly it was rather disappointing to discover this because it tells me that WordPress has hard-coded all the potential scenarios and doesn’t really have a way around it. Seems to me there should really be a hook here and the type of pages should be allowed to be expanded by plugins rather than be hardcoded as only one of ’singular’, ‘archive’, ’search’, ‘feed’, … and ‘home.’

Anyway, where this manifests itself is "wp-includes/template-loader.php" file which I have included in it’s entirety below.  It is on lines 24 and 25 where the template loader loaded the home page because it’s not possible to specify otherwise:

wp-includes/template-loader.php:

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
/**
 * Loads the correct template based on the visitor's url
 * @package WordPress
 */
if ( defined('WP_USE_THEMES') && constant('WP_USE_THEMES') ) {
  do_action('template_redirect');
  $is_home = is_home() ;
  if ( is_robots() ) {
    do_action('do_robots');
    return;
  } else if ( is_feed() ) {
    do_feed();
    return;
  } else if ( is_trackback() ) {
    include(ABSPATH . 'wp-trackback.php');
    return;
  } else if ( is_404() && $template = get_404_template() ) {
    include($template);
    return;
  } else if ( is_search() && $template = get_search_template() ) {
    include($template);
    return;
  } else if ( is_home() && $template = get_home_template() ) {
    include($template);
    return;
  } else if ( is_attachment() && $template = get_attachment_template() ) {
    remove_filter('the_content', 'prepend_attachment');
    include($template);
    return;
  } else if ( is_single() && $template = get_single_template() ) {
    include($template);
    return;
  } else if ( is_page() && $template = get_page_template() ) {
    include($template);
    return;
  } else if ( is_category() && $template = get_category_template()) {
    include($template);
    return;
  } else if ( is_tag() && $template = get_tag_template()) {
    include($template);
    return;
  } else if ( is_tax() && $template = get_taxonomy_template()) {
    include($template);
    return;
  } else if ( is_author() && $template = get_author_template() ) {
    include($template);
    return;
  } else if ( is_date() && $template = get_date_template() ) {
    include($template);
    return;
  } else if ( is_archive() && $template = get_archive_template() ) {
    include($template);
    return;
  } else if ( is_comments_popup() && $template = get_comments_popup_template() ) {
    include($template);
    return;
  } else if ( is_paged() && $template = get_paged_template() ) {
    include($template);
    return;
  } else if ( file_exists(TEMPLATEPATH . "/index.php") ) {
    include(TEMPLATEPATH . "/index.php");
    return;
  }
} else {
  // Process feeds and trackbacks even if not using themes.
  if ( is_robots() ) {
    do_action('do_robots');
    return;
  } else if ( is_feed() ) {
    do_feed();
    return;
  } else if ( is_trackback() ) {
    include(ABSPATH . 'wp-trackback.php');
    return;
  }
}

Still another problem in this puzzle is the $wp->send_headers() method shown being called here on line 293 of "wp-includes/classes.php":

wp-includes/classes.php:

290
291
292
293
294
295
296
297
298
function main($query_args = '') {   
  $this->init();   
  $this->parse_request($query_args);   
  $this->send_headers(); 
  $this->query_posts();  
  $this->handle_404();   
  $this->register_globals();   
  do_action_ref_array('wp', array(&$this));   
}

The problem with the $wp->send_headers(), also from "wp-includes/classes.php", is that it seems to have the option of either serving an HTML content type on line 183 and 185, or a content type based on a feed (the content types for the feeds are set in their respective "wp-includes/feed-*.php" files) but no custom content types as far as I can determine as there seems to be no way to override calling this function or the logic path contained within:

wp-includes/classes.php:

175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
function send_headers() {
  @header('X-Pingback: '. get_bloginfo('pingback_url'));
  if ( is_user_logged_in() )
    nocache_headers();
  if ( !empty($this->query_vars['error']) && '404' == $this->query_vars['error'] ) {
    status_header( 404 );
    if ( !is_user_logged_in() )
      nocache_headers();
    @header('Content-Type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));
  } else if ( empty($this->query_vars['feed']) ) {
    @header('Content-Type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));
  } else {
    // We're showing a feed, so WP is indeed the only thing that last changed
    if ( !empty($this->query_vars['withcomments'])
      || ( empty($this->query_vars['withoutcomments'])
        && ( !empty($this->query_vars['p'])
          || !empty($this->query_vars['name'])
          || !empty($this->query_vars['page_id'])
          || !empty($this->query_vars['pagename'])
          || !empty($this->query_vars['attachment'])
          || !empty($this->query_vars['attachment_id'])
        )
      )
    )
      $wp_last_modified = mysql2date('D, d M Y H:i:s', get_lastcommentmodified('GMT'), 0).' GMT';
    else
      $wp_last_modified = mysql2date('D, d M Y H:i:s', get_lastpostmodified('GMT'), 0).' GMT';
    $wp_etag = '"' . md5($wp_last_modified) . '"';
    @header("Last-Modified: $wp_last_modified");
    @header("ETag: $wp_etag");
 
    // Support for Conditional GET
    if (isset($_SERVER['HTTP_IF_NONE_MATCH']))
      $client_etag = stripslashes(stripslashes($_SERVER['HTTP_IF_NONE_MATCH']));
    else $client_etag = false;
 
    $client_last_modified = empty($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? '' : trim($_SERVER['HTTP_IF_MODIFIED_SINCE']);
    // If string is empty, return 0. If not, attempt to parse into a timestamp
    $client_modified_timestamp = $client_last_modified ? strtotime($client_last_modified) : 0;
 
    // Make a timestamp for our most recent modification...
    $wp_modified_timestamp = strtotime($wp_last_modified);
 
    if ( ($client_last_modified && $client_etag) ?
         (($client_modified_timestamp >= $wp_modified_timestamp) && ($client_etag == $wp_etag)) :
         (($client_modified_timestamp >= $wp_modified_timestamp) || ($client_etag == $wp_etag)) ) {
      status_header( 304 );
      exit;
    }
  }
 
  do_action_ref_array('send_headers', array(&$this));
}

Still, I was able to come up with a solution although it is so very hackish.  My solution was to hook the "template_redirect" action on line 7 of "wp-includes/template-loader.php" (see code from that file above.) Though it seems to works thus far, my solution just feels wrong for the following reasons:

  1. It ignores the fact that WordPress continues to think that my web service URL is the home page,
  2. It first lets "$wp->send_headers()" set the content type before it overrides it,
  3. It uses an "exit" rather than a return to keep WordPress from serving up the home page template, and
  4. It doesn’t use the routing mechanism apparent built into WordPress (see "null" on line 30 of "wp-content/plugins/restful-services/restful-web-services.php" below, I assume it should have been the URL of the .php file I plan to execute but WordPress doesn’t see to use what I put there.)

The function "restful_web_services_exec_service()" is what is called to execute the appropriate web service:

wp-content/plugins/restful-services/restful-web-services.php:

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
/*
Plugin Name: RESTful Web Services
Plugin URI: http://mikeschinkel.com/wordpress/restful-web-services/
Description: This plugin enables REST-based API web services for WordPress.
Author: Mike Schinkel
Version: 0.1
Author URI: http://mikeschinkel.com/
*/
 
define('RESTFUL_WEB_SERVICES_DIR', dirname(__FILE__));
define('RESTFUL_WEB_SERVICES_URL_PATTERN','services(/?.*)?');
$abspath = trim(str_replace('\\','/',ABSPATH),'/');
$rest_services_dir = str_replace('\\','/',RESTFUL_WEB_SERVICES_DIR);
$rest_services_path = trim(str_replace($abspath,'',$rest_services_dir),'/');
define('RESTFUL_WEB_SERVICES_PATH', $rest_services_path);
 
// NOTE, See: http://codex.wordpress.org/Custom_Queries#Permalinks_for_Custom_Archives
add_action('init', 'restful_web_services_flush_rewrite_rules');
add_filter('generate_rewrite_rules', 'restful_web_services_add_rewrite_rules');
add_action('template_redirect', 'restful_web_services_exec_service');
 
add_action('init', 'restful_web_services_flush_rewrite_rules');
function restful_web_services_flush_rewrite_rules() {
 global $wp_rewrite;
 $wp_rewrite->flush_rules();
}
 
add_filter('generate_rewrite_rules', 'restful_web_services_add_rewrite_rules');
function restful_web_services_add_rewrite_rules( $wp_rewrite ) {
  $new_rules = array(
    RESTFUL_WEB_SERVICES_URL_PATTERN => null,
  );
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}
 
function restful_web_services_exec_service() {
  global $wp;
  if ($wp->matched_rule==RESTFUL_WEB_SERVICES_URL_PATTERN) {
    if ($wp->request == 'services') {
      header('Content-Type: text/plain');
      print 'TODO: Generate a list of RESTful Web Services here for this WordPress Blog.';
    } else {
      list($dummy,$service_name) = explode('/',$wp->request);
      if (file_exists($service_php = (RESTFUL_WEB_SERVICES_DIR . '/services/' . $service_name . '.php'))) {
        include_once $service_php;
      } else {
        header('Content-Type: text/plain');
        status_header(404);
        print '404 - Service not found.';
      }
    }
    exit;
  }
}

You’ll note that my function "restful_web_services_exec_service()" is very bare-bones at the moment serving only a plain text message "TODO:" for the path http://example.com/services, and assuming that any path http://example.com/services/{service} will execute a same-named .php file in the services subdirectory, i.e. for http://example.com/services/latest-post it will look for "wp-content/plugins/restful-web-services/services/lastest-post.php" and then delegate all the work to that .php file.

wp-content/plugins/restful-services/services/latest-vidclip.php:

2
3
4
5
6
7
8
9
10
11
12
13
14
15
/*
Filename: latest-post.php
Service Name: Latest Post
*/
global $wp_query;
$post = $wp_query->post;
$file = get_attached_file($post->ID);
if (empty($file)) {
  list($file)= get_enclosed($post->ID);
}
$charset = get_option('blog_charset');
header('Content-Type: text/xml; charset=' . get_option('blog_charset'), true);
$link = get_permalink($post->ID);
$html = &lt; &lt;<post></post><post id="{$post-&gt;ID}">      <video>$file</video>   <link />$link  </post>  POST; print $html;

Here is an example output returned by calling http://example.com/services/latest-post:

1
2
&lt; ?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt; 
<post id="2">      <video>http://videos example.org/video1.flv</video>   <link />http://example.org/sample-post-1/  </post>

While bare-bones, that will meet my needs for the moment since I really only have the need for one service that responds to the HTTP GET verb. However, I can see where I might end up fleshing this out and create lots of helper functions that would streamline the creation of web services for RESTful access to the entirety of the WordPress database. If I do so I’ll be happy to donate this plugin to the community.  In the mean time if you’d like to use this for your own use feel free but caveat emptor. However, if you’d like to use this code to create a plugin to contribute to the community, please contact me for collaboration.  Of course if you’d like to retain me to fully flesh it out for you, I’m always open to that too! :-)

Finally, if anyone who knows the WordPress API better than I do can tell me where I erred in my analysis, and I really hope I did, please let me know so I can architect this thing better. On the other hand, if I was spot-on in my analysis maybe this will help the WordPress team understand what needs to be done so they can empower WordPress to generate any arbitrary content type without having to resort to hacks or bypassing the WordPress index.php startup code. 

ASPnix adds ISAPI Rewrite - Finally!

ASPnix Web Hosting Logo Back in July of 2006 someone asked on the forum for ASPnix, the web host that specializes in CommunityServer, to add ISAPI Rewrite to their servers so that customers can clean up their URLs. Seven people including myself chimed in asked for it. Over the past eight months, little was said by ASPnix except by a former staffer who implied it was harm the stablity of their servers and who really gave no indication that any real consideration was being made to offer a solution for URL Rewriting.

Well finally, on Feb 22nd, Roma confirmed that ASPnix has will finally be offering ISAPI Rewrite on ASPnix’s web servers. That’s yet another IIS-centric web host who has finally freed its customers from the shackles of poorly designed URL Hell! Hooray!

Now let’s just hope that Scott Watermasysk can be convinced to add URL Rewriting support in CommunityServer using ISAPI Rewrite to eliminate .ASPX extensions and more on CommunityServer, sooner than later.

On the Hunt for a New Programming Language

When it comes to programming on the modern-day GUI (post-DOS) platform, the vast majority of my coding has been, in order of experience, using T-SQL, VBScript in ASP, and about equal parts classic VB (v3.0 to v6.0) and VB.NET. As you can see from my order of experience, I’m really a database guy, and since the beginning of the web I’ve always viewed the web as somewhat of a database publishing environment (anyone remember the DOS product dbPublisher Pro from Digital Composition Systems?) What’s more the web allows a potentially infinite number of people to use a developer’s database publishing apps without any extra effort to distribute them. Finally, the web provides ability to capture evidence the apps were run, how often, and by how many people. Is it any wonder I have more of inclination to develop for the web as opposed to desktop applications? Back during the period from 1994 to 2006 when I ran VBxtras/Xtras.Net where we where a reseller of ActiveX controls and then later .NET components, I never really thought about the cost of add-on components. Almost anything I wanted to play with I can get an NFR (not-for-resale) copy just by sending an email or picking up the phone. Although I still have many of those relationships from a decade+  in the business, I hesitate to ask for NFRs these days except from my really close friends simply because this business I’m in today has nothing to do with benefiting those people. So numerous facts have me giving up on my prior five year assumption that I would someday learn VB.NET at an advanced level and have me instead actively considering alternatives:

  1. As I just stated, the fact I now have to pay for third party components and tools means I’m paying more attention to cost of acquisition,
  2. My recent favorable impressions of open-source developer tools and components, on par with some of the best tools ever sold by Xtras.Net,
  3. My increasing frustration with the Microsoft developer division’s process and release cycle,
  4. All best web applications seem to target L.A.M.P. such as Mediawiki, WordPress, vBulletin, Subversion, Trac,  Ruby On Rails, Django, etc. and all but one of them are free to use
  5. Completely preconfigured stacks (including O/S) that are becoming available for download as a VMware appliance,
  6. Recognizing that Ubuntu’s has an approach strategic enough to result in Microsoft being profiled in a revised edition of Clayton Christensen’s Innovator’s Dilemma as yet another example of why great companies loose their leadership position,
  7. And lastly my rising disgust for ASP.NET (and I promise I will blog about those specific soon…)

By the way, even though I dislike ASP.NET, I do still really like the .NET Framework and programming model. Oh and a note about the first point; whereas there is good open-source tools available for .NET, the operative word is "tools" not components. When you compare what’s available to freely use for .NET compared to what’s available for any of the "P"s (Perl, Python, and PHP), .NET just can’t compare, at least not in depth or breadth. Of course being commercial products the .NET third party components are more polished and of course have commercial support available. However, unless you are big company that needs to CYA and have a throat to choke, those are often dubious benefits especially when you consider the benefits of open-source (i.e. source code, and the ability to fix something and contribute it back so you’ll know it stays fixed!) Anyway, I could write for hours on the pros and cons for open source vs. commercial developer components and tools but that’s not the subject of this post. The subject is about which language I will focus the majority of my future attentions on learning and using, and I’d love to get your input before I decide. Here are the current contenders:

PHP
All the major web apps I mentioned above seem to be built using PHP and I’m currently running many of those apps, PHP is pretty similar to the ASP that I know so well, it’s web-specific, there is a huge support community, it runs on both Windows and Linux, and every Linux web host known to man seems to offer it preinstalled. However, there seems to be lots more crap PHP code examples littering websites than good PHP code examples making it harder to learn so it might be hard to seperate the wheat from the chafe, it is not easy to configure on Windows Servers (especially at a shared web host), and no one individual framework seems to have gotten the lion’s share of the market attention so picking one would be a crap shoot. Oh, and it uses those infernal semi-colons just like C#.
Ruby on Rails
Ruby and it’s framework Rails have gotten tons of attention and it seems all the cool kids are doing it, especially lots of the Web 2.0 startups, it is very database-centric, has very elegant URL mapping functionality, and it seems you can get web apps built really fast using it. And Ruby.NET is also on the horizon meaning I might be able keep my toe in .NET. However, the community comes across as just a little bit too religious and I’m generally alergic to that, AFAIK it doesn’t run on Windows, or at least not for shared hosting. Plus I’ve had people I respect tell me that Ruby doesn’t have nearly as many users as the "P" languages, that Rails it not nearly as mature as its purported to be, and that Rails makes simple thing simple but complex things extremely difficult. And the number of available web hosts that offer it is quite limited.
Python
Unlike PHP, it seems Python is well suited for both web and desktop apps, which might come in handy from time to time, and a shipping IronPython means that I definitely can keep my toe in .NET. The Django framework seems to be a little more mature and have a little less religion than RoR, and Django also has nice URL mapping functionality, albeit slightly less elegant than RoR. And it seems to run equally well on Linux and Windows. However, Django seems more document publishing-centric and less database-centric, there are very few web hosts that support DJango, and I’ve heard it is a real bitch to get working on a web host.
VB.NET+Castle/MonoRail(+Mono)
But then again, maybe I will stick with VB.NET. The Castle/Monorail project is supposed to be a lot like RoR, and I’d even have the option to use Mono on Linux. However, the third party tools are definitely wanting, most web hosts haven’t a clue what Mono is, and they coded Castle/MonRail in C#, so I’d always be dealing with semi-colons…
ASP+IIS+JScript
I could stick with ASP, which I still like, and learn JScript to replace VBScript, the latter of which just has too many limitations when compared with the other current options. This clearly also runs on Windows and any Windows web host will support it, and I already know Windows backwards and forwards. On the other hand, I’ll need to use ISAPI Rewrite for clean URLs, JScript on ASP it has no future and few code examples on the web, and what third party components and tools (to speak of…)?!?
ASP+IIS+VB.NET
I could also use develop VB.NET objects and call them from ASP; that’s what we last did at Xtras.Net (and I think that is what they are still doing, last I checked…) Of course, calling .NET objects as ActiveX controls just doesn’t feel right, and again there’s that third party component and tools problem…
PowerShell+IIS+???:
Of all the teams working on tools for developers over at Microsoft, the PowerShell team run by Jeffrey Snover is the only one that gets me excited anymore. And in an email from him (or was it a comment on my blog, I don’t remember exactly) he said that PowerShell can do web, and will be able to do it more easily in the future. On the other hand, it’s not here today, and what if webified PowerShell is just another way to do rubbish ASP.NET instead of what it should be, a url-based object-selector-and-invoker like Django or Rudy on Rails.  And what’s the chance it will ever run on Mono…?
Other:
Is there anything else do consider…?

At this point I should probably explain what I’m not considering, and why:

Java on Anything:
Although I was really impressed at a Sun Tech Days recently here in Atlanta , even the Sun people were all over dynamic languages with praise, like Jython and JRuby. And though I was impressed with NetBeans 5.5, all the other "enterprise" baggage like J2EE and Servlets and JSP Custom Tags gives me the feeling I’d be jumping out of the frying pan and into the fire.  Oh, and Java uses those infernal semi-colons too.
C# on Anything:
One word: semi-colons!  Sorry but if I’m going to go .NET, it’s going to be VB.NET (or IronPython). VB.NET is so much more natural to me than C#, and there are things you just can’t do in C# that you can do in VB.NET related to using "implements" on a method in an inherited class (I ran into that limitation of C# compared to VB.NET on a project several years ago where I was managing a pair of interns coding in C# and they hit a wall because of that limitation. I can dig it up if anyone cares, or better yet, can someone who knows the specifics explain it in comments?)
Perl on Apache:
Although my partner on Toolicious Ben Coffey who is a devoted disciple of Perl will cringe to hear this (yet again), I can’t quite get my head around Perl, and they tide, at least today, is away from Perl. Of course Ben claims that will all change with Perl 5.0, but to me that remains to be seen and I’d rather go with a bird in the hand (i.e. one with a lot more active current user base) than a bird in the bush.  But who knows, they say you should learn a new language every year; at any rate if he’s right maybe I’ll try and pick up Perl 5.0 in around 2012. :)

So there you have it: my potential choices and non-choices. Any thoughts I which I should choose?  Any and all input will be appreciated and considered seriously.

The Siren Song of SSI

I needed to get a small content website up and running for a project a friend of mine and I are working on, and we started discussing what to use; i.e. raw HTML, a web framework, a CMS, or something else. I have experience on ASP, IIS, and Windows Server using my own mini ASP-based framework but I’ve got very little experience on our chosen deployment platform and hence am not productive on any of the common platforms in use on Linux. So my friend, thinking I was unfamiliar with SSI suggested that I just use SSI with HTML, to which I replied:

Oh, I’ve done that in the past; I built up a pretty robust set of SSI templates, but it took me a while to get the feel of the language and make it all work. So I don’t want to reinvent the wheel.

To which he replied:

But SSI is beautifully simple. You write a couple lines for your header, say, then throw it in a file. Then you write a page containing whatever content you want, with a call to include that header file at the top of the document. Then…well, that’s it. It takes no time to "learn", requires no programming, and seems perfectly sufficient for what you want.

Sigh.

But as I was thinking about how to reply, I realized that my reply would make an interesting blog post. So here it is; I’m going to build a simple website and use SSI to eliminate all the inevitable duplication. Let’s see how it goes.

First thing is to create a header and a footer (please forgive the lack of DOCTYPE and of obvious things we’d add as I’m trying to make my examples easy to follow. And the omission of DOCTYPE and other specifics won’t affect my main points anyway):

header.inc:

<html><body>

footer.inc:

</body></html>

Next step is to create a template for all our web pages; we’ll start by creating the home page:

index.html:

<!-- include virtual="/header.inc" -->
The web page's HTML content would go here
<!-- include virtual="/footer.inc" -->

So far, so good.  Next let’s add a menu to header.inc that will be on all pages in the website. We’ll need to use CSS styling for the menu, so we’ll add a LINK element allowing us to bring in CSS:

header.inc:

<html>
<head>
<link rel="stylesheet" type="text/css" href="/style.css" mce_href="/style.css">
<body>
<ul id="menu">
<li><a href-"/">Home</a></li><li><a href-"/products/">Products</a></li>
<li><a href-"/downloads/">Downloads</a></li>
<li><a href-"/store/">Purchase</a></li>
<li><a href-"/faq/">FAQ</a></li>
<li><a href-"/about/">About</a></li>
<li><a href-"/contact/">Contact Us</a></li>
<ul>

Great! Now let’s start building out our website. Let’s add three, five, ten, twenty five web pages, and more. These SSI are pretty nice, no?

But wait. Someone mentions to us that none of our web pages have titles. Bummer; titles are really important for usability, and super important for search engine optimization. Oops.

So how are we going to fix this? Hmm, looks like we need to split header.inc into two parts and add a <title> element spanning the two.

header1.inc:

<html>
<head>
<link rel="stylesheet" type="text/css" href="/style.css" mce_href="/style.css">
<title>

header2.inc:

</title>
<body>
<ul id="menu">
<li><a href-"/">Home</a></li>
<li><a href-"/products/">Products</a></li>
<li><a href-"/downloads/">Downloads</a></li>
<li><a href-"/store/">Purchase</a></li>
<li><a href-"/faq/">FAQ</a></li>
<li><a href-"/about/">About</a></li>
<li><a href-"/contact/">Contact Us</a></li>
<ul>

Well that’s done, but now we need to go and fixup all those three, five, ten, or twenty five odd web pages, right? I guess it’s going to look something like this:

<!-- include virtual="/header1.inc" -->
Page title goes here
<!-- include virtual="/header2.inc" -->
The web page's HTML content would go here
<!-- include virtual="/footer.inc" -->

I guess that wasn’t too bad. But wait. It becomes clear some of our pages need to omit the menu. Hmm. I guess we need to split the menu out of header2.inc and into it’s own file.

header2.inc:

</title>
<body>

menu.inc:

<ul id="menu">
<li><a href-"/">Home</a></li>
<li><a href-"/products/">Products</a></li>
<li><a href-"/downloads/">Downloads</a></li>
<li><a href-"/store/">Purchase</a></li>
<li><a href-"/faq/">FAQ</a></li>
<li><a href-"/about/">About</a></li>
<li><a href-"/contact/">Contact Us</a></li>
<ul>

I guess that means NOW we need to revisit those three, five, ten, or twenty five odd web pages AGAIN, right? They should probably all look something like this:

<!-- include virtual="/header1.inc" -->
Page title goes here
<!-- include virtual="/header2.inc" -->
<!-- include virtual="/menu.inc" -->
The web page's HTML content would go here
<!-- include virtual="/footer.inc" -->

Sheesh! What’s with this SSI concept? I thought it was suppose to eliminate the need to change every web page file every time we needed to modify a site’s architecture. Why then do we have to keep making all these sweeping changes?

What’s more, those web pages are really hard to read, what with all the cryptic SSI syntax obscuring the logic in the page.

So I’ve shown two simple examples of where a web site rearchitecture requires refactoring of (almost) all of the web pages in a site when SSI is used naively. Yet I could go on. And on. And on. And on. The problem is that you can’t easily parameterize SSI files (easily) and then capture those parameters in pure HTML. And even if you could, you’d be programming, and you’d have to learn how to do it! We’re going full circle, you know?

Which brings me to a question: "Are Server-Side Includes Bad?" And the answer is: "Of course not, but you do need to know how to use Server-Side Includes properly, and they are really only beneficial when paired with a server-side scripting language[1]." I’ve actually used SSI on every web project I’ve every worked on, save the very first. But I have a rule of thumb when using SSI: I generally only use one SSI per web page file, and I include that SSI at the top of the web page file.  My single include file actually includes my library of scripting functions and is a mini-framework of sorts.

So that you can see a good way to use SSI, I’ll show a quick example. The majority of my web experience has been on programming ASP websites so I’ll use ASP and VBScript syntax. For those not familiar, ASP/VBScript is relatively similar to programming in PHP albeit PHP has moved far beyond the capabilities of ASP since Microsoft dropped ASP and went on to focus its efforts on that that abomination they call ASP.NET[2].

default.asp:

<%
   '--Filname: /default.asp
%>
<!-- include virtual="/sitedef.inc" -->
<%

With page
   .Title= "Page title goes here"
   .Show()
End With

Sub PageContent
%>
The web page's HTML content would go here
<%
End Sub
%>

For completion, I’ll so a tiny subset of a workable sitedef.inc as showing and explaining the entire thing would be way out of scope for this article:

sitedef.inc:

<%
   '--Filname: /sitedef.inc
   Option Explicit
%>
<!-- include virtual="/funclib1.inc" -->
<!-- include virtual="/funclib2.inc" -->
<!-- include virtual="/funclib3.inc" -->
<!-- include virtual="/and-so-on.inc" -->
<%
Dim pageSet page= New PageClass
Class PageClass
   ...
End Class
%>

A quick rundown of sitedef.inc shows the first line being a comment to document the file name for print-outs, etc.. Next is the directive Option Explicit that turns on error reporting for undeclared variables.

Then you can see several times the use of embedded SSI to bring in other files from my VBScript library of functionality. As a note, at first I thought that incluing everything even if it wasn’t needed would cause poor performance but I later realized everything was cached and there really were no performance problems at all. At least this is true on  ASP and IIS; I can’t yet speak for PHP or other languages on Linux and Apache.

Then we have the declaration of the "page" variable which you saw used in default.asp above, the creation of a new instance of the page variable, and the skeleton declaration of the "PageClass" class. Note that VBScript is case insensitive and won’t let you reuse symbols so the "page" variable and a class named just "Page" would have clashed hence the use of the suffix "Class" on "PageClass."

With sitedef.inc we can now create our three, five, ten, twenty five, or more web pages using the template shown for default.asp and (almost) never have to modify them when we refactor the code in our server-side includes. Much more maintainable than SSI and HTML alone. Which brings me back to my friend’s statement, a portion of which I repeat below:

But it takes no time to "learn", requires no programming, and seems perfectly sufficient for what you want.

If you are going to use SSI and you want it to be maintainable, it actually does require you learn server-side programming. Maybe we are only talking about three or five web pages for the project today, but we all know that things change quickly and before you know it, there will be fifty web pages or more.

And who wants to architect a website such that you have to rearchitecture as soon as it grows? Not me. :)

Footnotes

  1. When I say server-side scripting I’m using the term "scripting" liberally to refer to any server-side programming solution including platforms that use Java and C#.
  2. Please don’t misquote me; it’s not the .NET framework, .NET languages, and the common language runtime I dislike; it’s the ASP.NET web framework that I think is misguided.

 

Clarifying my Microsoft Developer Division Rant

Contents


I Ranted and Eric Rebutted

The day before yesterday I wrote a long winded and rambling rant about how Microsoft’s release cycle and process for creating developer tools. I commented on how I believe it is making them fall behind and causing many formerly loyal Microsoft developers to look at open source solutions on non-Windows platforms. I referenced a post that Microsoft’s Eric Lippert wrote over 2.5 years ago titled Top Minds Are Working On It[1]. In retrospect it might have appeared I was being critical of Eric but that wasn’t my intention, and if that’s how I came across I apologize. Instead I was referencing Eric’s comments as symptomatic of the Microsoft culture at large. And yesterday I awoke to find that Eric had issued a rebuttal.

While I Respect the People at Microsoft…

But before I address his comments let me talk about Eric and all the others I’ve met from Microsoft. Eric is actually a brilliant guy, and very likeable. I’ve met Eric face-to-face and it’s obvious he’s much smarter than me. But then I could say that about most of those I’ve met from Microsoft; they don’t hire dummies. As a rule I’ve been impressed with every Microsoft employee I’ve met. They are super bright and AFAICT they do really want to do "Good Things(tm)".

…They Become Detached

But group dynamics being what they are, when you get a group of super-bright people together they become competitive, hone their debate skills, and learn to be strong advocates for whatever their own positions. And they can become detached from the outside world, much like politicians in high office. Politicians are also typically super bright, and most enter office wanting to do Good Things(tm), but once "on the inside" they loose touch with the concerns of their constituents. So I am not condemning Eric and his Microsoft colleagues, I am merely commenting on the culture that results and collectively channels them.

Eric Unconsciously Supports my Thesis!

So I started yesterday’s post saying I’d been planning to blog on the topic for a while but the reality was I still didn’t know how best to explain my concerns. But for better or for worse I did write a rambling essay yesterday, but ironically Eric’s comments made my points far better than I! My central thesis was that Microsoft isn’t meeting developer’s needs because of their processes and infrequent releases and consequently open-source alternatives are meeting developer’s needs instead. Eric’s both debated my examples and pointed out they now plan to address some issues I referenced. But not only did Eric not address my central thesis, he ironically supported it given his rebuttal’s choice of focus! In my post I wrote the following:

"Microsoft’s culture is to argue semantics when reality doesn’t match their world view"

And Eric’s comments proceeded to do exactly that! In my post from 2.5 years ago[1] I called for Microsoft to address things that PHP, Ruby, and Python are addressing today, which Eric rebutted at the time. In yesterday’s rebuttal Eric referenced his earlier comments stating (emphasis mine):

"Second, my ‘esoteric’ reasons for not implementing a scripty version of VB on the .NET platform were hardly esoteric then and are hardly esoteric now. They are (1) fracturing the language further causes confusion amongst customers and is massively expensive for little gain, …"

Dismissing the Proposal, Not Solving the Problem

Now I’ll freely admit Eric is far more qualified to evaluate my suggestion on technical merit, but that wasn’t the point of my 2.5 year old post. Customers with needs a company’s not addressing will often propose solutions they believe will address their needs, yet often their suggestions aren’t workable for whatever reason. People who specialize in addressing customer needs know that rather than dismiss suggestions as unworkable it’s far better to determine the customer’s actual needs and implement a workable solution instead. And often, many other customers have those same needs. So Eric dismissed my proposed solution but didn’t address my unresolved needs that prompted the proposal. I don’t attribute this failing to Eric, I attribute it to Microsoft’s current culture.

Not More Power; Transitionality!

Eric then went on to say:

"(2) we can do things to make VB.NET more powerful without fracturing the language,…"

Ironically, I didn’t ask for a more powerful VB.NET; I asked for one that was easier to start using and one that developers could then easily transition to more powerful usage. Though they believed they were providing an easier to use Visual Basic 2005, they addressed the language but not how people develop applications. Though they made strides with the Express Edition, my biggest concern was with the complexity of the development environment and the language. I suggested an interpretive environment with a transitional language design that allowed new developers to start easily yet be able to effortlessly grow their expertise with use. What I envisioned was something like Boo, but I wanted it 2.5 years ago with a simple interpretive environment, and I wanted it from Microsoft so that it could possibly generate a large and immediate and user base with a thriving community and significant peer support.

Today’s Potential Didn’t Address Yesterday’s Deficiency

Eric continued with the following…:

"(3) Microsoft makes scripting languages like Iron Python"

…but omitted the fact that a robust Iron Python was just a gleam in Jim Hugunin’s eye 2.5 years ago and is still not ready for prime time. Further, Microsoft’s approach is to host IronPython in Visual Studio which does nothing to bypass the complexity of Visual Studio!

Nor Does an Orphan Address Yesterday’s Deficiency

Eric then said:

"…and JScript .NET, use the right tool for the right job."

To which I did a double take wondering if he were really serious! JScript .NET is such the orphan that I can’t even believe he suggested it! The JScript .NET newsgroup has less than a screen full of messages, JScript .NET hasn’t been updated since 2003, and nobody’s even written about JScript .NET in years! So could Eric really have been serious when he suggested JScript .NET? Well, assuming he was, then:

  • JScript .NET does NOT have an easy-to-use interpretive environment, and
  • JScript .NET is a complex language; NOT simple-to-use, and
  • Again, JScript .NET has NO user-base!

And a Potential isn’t a Solution

Moving on Eric said:

"The .NET framework is already amenable to the development of scripting languages."

So why do we still not have a viable scripting solution for .NET supported from Microsoft more than half a decade after the .NET Framework’s first release?

Yes, there’s Powershell, but…

Okay, that’s not quite true. Eric didn’t mention it but in the spirit of honest debate, there is Microsoft’s PowerShell. But while I will freely admit PowerShell is really nice, PowerShell:

  1. Was only just released so doesn’t address the past 2.5 years,
  2. Doesn’t have a development environment,
  3. Can’t be used for web development,
  4. Doesn’t have a compiler for creating components for use in other .NET languages.
  5. Doesn’t have transitionality allowing it to scale up for much more complex projects as the developer’s experience grows.

A Correct yet Irrelevant Point

Eric then makes a point about "scripting languages" vs. "dynamic languages" (emphasis mine):

"Third, I want to make a distinction between scripting languages (languages intended to script things) and dynamic languages (languages which admit a type system which cannot be deeply analyzed at compile time.) Scripting languages are often dynamic languages, however it is entirely possible to use dynamic languages for tasks other than scripting. "

Okay… So Eric’s points are very technically valid, but they are totally irrelevant! Frankly I wasn’t asking for a language that was "intended to script things," I was proposing a language (and IDE) that would be:

  1. Productive,
  2. Easy to start using, and
  3. Scalable as one’s skills evolve.

Call it "scripting", call it a "dynamic language", call it whatever; it’s irrelevant. What is relevant is for it to be productive, easy, and scalable. Microsoft could choose to get there however they will, bit like arguing the semantics of "Car" vs. "SUV" with someone who just needs transportation, Eric’s distinctions were simply irrelevant to the needs. Totally unrelated, I ran across this joke yesterday. What could be more ironic?

Interest Doesn’t Necessarily Change Process

Eric finishes his prior point with:

"The VS team is VERY interested in understanding how to make the platform more amenable to dynamic languages."

Great! But are they going to actually engage people who are not .NET developers in the design of said dynamic languages and their respective development environments and then incorporate their feedback? Or is the VS Team just going to plug another dynamic language into Visual Studio? If the latter they will do so ignoring that Visual Studio users already have the language(s) they need and that there are at least an order of magnitude more people for whom Visual Studio is too overwhelming.

A Solution Offered; Wrong Product, Years from Now

A couple other comments Eric made were:

"C# 3.0 will have the "one line auto-implemented properties" feature you requested for VB. Enough people asked for it, we put it in. I do not know if VB will be doing the same. You’re welcome. "

and

"Current C# 3.0 features move in the direction of dynamic languages without actually making the language dynamic (lambdas, improved generic method type inference, extension methods, implicitly typed locals, anonymous tuple types). All of these however are implemented so as to keep the language statically analyzable. We are considering features for C# 4.0 which would make the language more dynamic without losing that important statically analyzable core."

That’s well and good, but it doesn’t address VB.NET, and it also makes my own point that Microsoft’s release cycles are too far apart! There are badly needed enhancements and they need to get them to developers more often than once every three years. C# 3.0 is still a way’s out, people need something today, and I personally wonder if I’ll even care about programming by the time C# 4.0 is released. Hell, I hope to have made my fortune and be retired by then! :-) But seriously, C# is a professional developer’s language and adding features to a professional developer’s language wasn’t even close to what I was proposing.

Too Little, Too Late: Acknowledged

In the last paragraph, Eric finally gives tacit acknowledgement of the concerns I raised in yesterdays post:

"Now, maybe these features aren’t what you want, or are too little too late, or the release schedule is too long for your liking, or whatever. That’s unfortunate."

Exactly. The release cycle needs to be compressed by an order of magnitude as it has been at the competition. More on this in a bit.

Studying Users Isn’t Feeling their Pain

Eric then signs off with:

"However I take exception to the claim that we do not study what real users are doing and try to provide tools that do what they want. We do that every day."

With this Eric either misunderstood my point, or more likely I didn’t state my point in a manner that was understandable. Whichever the case, let me clarify. I know the VS Team works hard to study real user’s needs every day. But what I also know is that the people who make the decisions about what gets released and when have considerations that are far different from the needs of developers. And it is human nature for one to place solving one’s own pains ahead of solving the pains of others as people simple can’t fully comprehend pains they don’t experience.

Trade-offs that Shortchange Developers

Eric let’s be concrete; if solving a customer problem today will cause the VS team a problem tomorrow they won’t do it. For example if the VS Team plans to rearchitect something next version they won’t provide an interface that developers need in this version if doing so will make that rearchitecture difficult. Some would say this is good product engineering to which I would actually agree, but it is nonetheless a trade-off that keeps developers from getting what they need today.

Experiencing Pain Empowers Real Solutions

So, if you’ll reread my post from yesterday you’ll see that I didn’t say "Microsoft doesn’t listen to customers"; I know damn well they do. On the contrary, I said that Microsoft’s Developer Division "Don’t solve real world problems." And the reason you don’t is because you don’t experience the pain that those real world problems cause. By comparison most developers contributing to open-source projects are doing so to solve pains which they themselves have, and that is why they are addressing developer needs much faster than Microsoft’s Developer Division.

Yes it is a Paradox…

An observant person would say that I’ve present a rather intractible dichotomy for Microsoft’s Developer Division; i.e. they need to use the developer tools they build to solve real world problems yet they also need to to develop those tools ten times faster! Now I’m sure these comment will cause the blood of those in Microsoft’s Developer Division to boil thinking I believe it’s possible they do their work ten times faster and do real world projects. But I was not advocating that; I’m fully aware of the myth of the "man-month" in software development projects.

…But Solve it You Must, Or Else

What I was pointing out, however, is if Microsoft’s Developer Division maintains its status quo they will slip farther behind and the loss of developers to other platforms will accelerate. And since developers, developers, developers have always been Microsoft’s life blood it is critical they address this issue. Every developer they loose to Linux or the Mac doubly weakens Windows. Microsoft must address this issue if they are to maintain the same level of relevancy during the next twenty years that they’ve had for the past twenty years. And most of what I’m suggesting isn’t complex, and it isn’t new. They probably have most of what they need already written and used internally. They just need to rethink what they are offering.

Change, or Be Changed

So to wrap up this second long-winded essay:

Microsoft’s Developer Division needs to implement drastic changes sooner than later. If they do not, outside forces will soon impose drastic changes upon them and it’s certain they will find those imposed changes to be far more painful. Or as the mechanic on the old Fram Oil Filter commercial used to say "Pay me now, or pay me later."

What if I’m Not Wrong?

P.S. If you’re from Microsoft’s Developer Division and choose to dismiss my concerns, just ask yourself this: What’s the downside for you if I’m right?

  1. Eric Lippert’s post was in response to my post entitled A Modest Proposal: VBScript.NET, aka "Helping Mort use .NET".

 

THESE GUYS MUST DIE!!!

Blog Submitter Pro (THESE GUYS MUST DIE!)

I just noticed a Google ad out of the corner of my eye for Blog Submitter Pro (URL is http://www.marketersos.com/ but I will give them no Page Rank!) I googled it and found this review of Blog Submitter Pro by Vincent Rich! I was floored. Someone actually sells a product that is causing us bloggers so many problems with spam, and then somebody else writes a review promoting it!

THESE GUYS MUST DIE!!!

P.S. But one good thing about this is it should make it easier for services like Akismet to reverse-engineer the software to see how better to stop it.

P.P.S. Obviously, if anyone from the FBI is reading this, I’m speaking metaphorically when I say they must die. ;-) You must know that all legitimate bloggers want to see spammers rot in hell…