Entries from Jan 2007 ↓

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.

 

Help Expose URLs that Suck!

Over on the Well Designed URLs Initiative blog, which is my baby, I’ve started a call-to-action to get people to use delicious to tag:

URLs that Suck!

Check it out, and then be sure to tag any especially bad URLs with the tag urls-that-suck” on delicious.

About “Five Not-So-Easy Steps to Save Microsoft”

Microsoft Fading (from JasonKolb.com)

While I’m not in the habit of link blogging, Jason Kolb blogged a similar take to my recent themes about Microsoft entitled Five Not-So-Easy Steps to Save Microsoft. Jason starts with:

Let me stick a disclaimer on the front of this post: I cut my teeth on Microsoft technology and have been a big supporter of them in the past. I would really like this company to survive because otherwise I’m going to have a lot of useless knowledge cluttering up my brain. However, I am a realist and this is a company in a dangerous situation. It saddens me to see this once great company slowly dying, and I hope they do something to stop the bleeding before it’s too late.

Microsoft is in an interesting situation right now. Their monopoly is fading fast, and the only product they have that’s driving any significant level of buzz is the Xbox 360. They’ve gone from  absolutely dominating the technology space to almost falling out of the cutting-edge technology consciousness. They’ve done very little in the past couple of years to enhance their standing as a leading technology company, and I think a lot of people view them as living in the past.

He continues with (emphasis mine):

I think Microsoft is in a precarious situation right now–it’s on the verge of becoming irrelevant. The reason Microsoft has been so dominant over the past twenty years is because they have not only courted programmers, but they (it) made much easier for programmers to use their technology as a platform than anything(body) else. This resulted in the majority of mainstream software being written for Windows. Which resulted in more people buying Windows, which resulted in more developers writing for Windows. It was a catch-22 in favor of Microsoft, and they made money hand over fist because of it.

That’s what I’ve been saying recently, though my posts came from a slightly different angle. Jason’s take is that operating systems and language no longer matter (emphasis mine):

The result of this software lifecycle shift has been that developing for a mass audience has a lot less to do with the operating system and a lot more to do with the end-user experience. The language and platform no longer matter, it’s just the end result now. In fact, more than which operating system or language is used, it’s now the ability to scale on an as-needed basis that is the primary requirement for applications. Microsoft fails miserably at this requirement because of their licensing model and the way they try to monetize their software, which they haven’t really changed since the 1980’s.  Just from keeping an eye on the Net I sense a mass migration to open source development platforms, and the search trends seem to back that up–as a bonus bad omen, the news volume for their languages is practically non-existant.

While I don’t disagree with his main premise, I don’t completely agree that the language and platform don’t matter; they are still what is used to create and host applications, be they local or on the web, and those things take time to learn and build expertise in. Jason even acknowledges that at the start by saying “…otherwise I’m going to have a lot of useless knowledge cluttering up my brain.”

In my (humble :) opinion, the problem is more in Microsoft’s licensing model which makes it so much easier for people to choose open-source. And I believe people are choosing open-source in droves over Microsoft’s solutions as I know I am starting to. Jason addressed this point in the last paragraph above by saying: “Microsoft fails miserably…because of their licensing model and the way they try to monetize their software, which they haven’t really changed since the 1980’s.

Jason then goes on to recommend the following five (5) “not so easy” steps to fix Microsoft, which I think are spot-on (except for the last one, that’s at the same time both obvious and too vague to be an action item):

  1. Release .NET as open source.
  2. Release Windows as open source.
  3. Release a SaaS version of Office, ASAP.
  4. Find a Steve Jobs clone.
  5. Start innovating again.

Jason of course goes into far more detail and his post is definitely worth a read if you care about these things. Oh, there is one final pull quote I’ll reference on his second step to drive the point home (emphasis mine):

What’s really going to hurt them, however, is the licensing model for the server products. When you compare the cost of running and scaling a Windows-based application versus running and scaling on Linux, it becomes a no-brainer. I can’t think of a single good reason for developing a SaaS application for Windows when you’ll be paying Microsoft licensing fees every time you need to scale, and you could be getting that software for free using Linux. Microsoft needs to consider the operating systems loss leaders and an incredibly powerful way to market their other products, before everyone stops developing for them and everyone stops using them as a result.

Via Ben Coffey.

P.S. I have numerous posts that are in various stages of completion covering some of this same ground from, again, a slightly different angle. But when I finalize and post them, please don’t think them a copy-cat of Jason’s post. :)  This is such an obvious area to discuss these day’s, there are lots of similar independent thoughts, for hopefully obvious reason.

Windows Home Server; I guess Microsoft listened!

Windows Home Server from Hewlett-Packard
In October 2005 I blogged about the need for a Server for End Users. I guess Microsoft was listening. ;-)

From Larry Dignan over on ZDNet.

Windows Home Server Logo

Enthusiasm for Microformats Premature


Microformats, Out of Focus

Earlier this year I raved about Microformats here on my blog. When Tantek Çelik gave his presentation at the Future of Web Apps Conference I had numerous epiphanies. As I am want to do, I projected my ideas and envisioned how Microformats could solve several problems on the web and I came away completely enthused. On the strength of its topic alone, I felt it was the best presentation at the show.

I have since spent many hours on uf-discuss[1], and I’ve come to the conclusion that my enthusiasm for Microformats was unfortunately premature. But before explaining my concerns let me give a quick overview.

30 Second Overview of Microformats

Microformats are developed by a community process and they allow web developers to provide semantic information within an HTML 4.01 document using defined keywords in class attributes[2].  This allows software programs to extract the semantic information from the HTML much like a program could extract information out of an XML file. The following example, if included in a web page would indicate that the content on the page was licensed using Creative Commons license:

<a rel="license" href="http://creativecommons.org/licenses/by/2.0/">License</a>

This example marks up a description of the time and place for the Future of Web Apps conference I attended:

<span class="vevent">
   <a class="url" href="http://www.futureofwebapps.com/pastevents.html">
      <span class="summary">Carson Workshops' Future of Web Apps</span>
   </a> was held
   <abbr class="dtstart" title="2006-09-13">September 13</abbr>-
   <abbr class="dtend" title="2006-09-14">14</abbr>,
   at the
   <span class="location">
      The Presido's Palace of the Arts in San Francisco, California
   </span>.
</span>

The previous markup[3], would display as:

Carson Workshops’ Future of Web Apps was held September 13-14, 2006 at The Presido’s Palace of the Arts in San Francisco, California.

To learn more about Microformats, visit http://microformats.org.

Our Mismatched Vision

I had envisioned a community process defining specific Microformats for different vertical needs, and then web developers using these Microformats to expose extractable data in their web pages. Business partners and other interested parties could then simply scrape these structured pages to retrieve the information all without having to create a separate XML files and related navigation. This would give 80% of the benefit of the semantic web with 20% of the effort[4].

Unfortunately, the Microformat community’s vision didn’t align.

So where was the mismatch? Read on:

So, after many vision-limiting responses I’ve become both disheartened and disenchanted with Microformats, especially after I envisioned Microformats being able to solve so many real world problems.

After the letdown

After an extremely compelling vision, it’s hard to backtrack and just ignore it. But unfortunately, the Microformats community’s vision doesn’t sync with mine. Continuing to advocate for an alternate vision will likely just waste my time and certainly upset everyone on the list, so that’s not a viable option. Instead, I’ll ponder the issue, and will post again if an alternate solution presents itself.

Microformats good, just know what to expect

However, I do want to clarify that I didn’t write this to trash Microformats or Tantek or the community. I still think the Microformat concept is brilliant, even with its differing vision. I still respect Tantek and the others on the Microformat list and appreciate their efforts. And I’m still impressed by existing Microformats created by the community and would love to see them implemented on all applicable web pages.

No, I didn’t write this to trash Microformats. Instead I wrote it to inform people they should take great care in setting their expectations regarding Microformats. Otherwise they’ll go through the same cycle of elation, frustration, and then disappointment as me. And that won’t do good for anybody. And in fairness, I wrote it in small part to officially register my issues about the governance of the Microformat community.

  1. “u” is the symbol for “micro”, and “f” is the first character of “format, so “uf-discuss” if the mailing list to discuss Microformats. Get it? Uh, huh, too cute for words.
  2. The “class” attribute is the main one used by Microformats as they also use “rev” and “rel” and a few more, depending on the specific Microformat.
  3. Carson Workshops actually uses this Microformat called “hCalendar” to mark up their entire conference schedule for the next time this conference is run; you can see it here. As an aside, they had a link on their schedule page for the San Fran conference that would add the entire conference into a calendar such as Outlook. At this moment his current page doesn’t do that; why I don’t know.
  4. Please don’t debate the percentages; I was being convenient and the percentages are tangential to the point of the post. Thanks in advance for your support. :)

THE MOST AWESOME Print Dialog on the Web, EVER!

THE MOST AWESOME Print Dialog on the Web EVER

Some one sent me a link to this page about REST and when I went to print it, up popped THE MOST AWESOME Print Dialog I’ve EVER seen on the web! I so hope this guy starts a trend…

P.S. Unfortunately it doesn’t work for me to link directly to it, or I would.


Will Microsoft Meet Occupational Programmer’s Needs?

Contents


Defining “Occupational Programmer

I made two posts recently that muddled serveral issues so I am creating a seperate post here to isolate them and provide a location for comments specific to this issue:

Microsoft is not meeting the needs of “Occupational Programmers.”

The first thing I should do is define the term “Occupational Programmer:

“An Occupational Programmer is one whose job is something besides programming. The programs they write are related to their main job such as streamlining tedious processes or automating labor intensive tasks. These people only spend a small percentage of their time programming.”

Professionals need Industrial Strength

Occupational programmers have significantly different needs than professional programmers or even hobbyists. Professional programmers need industrial strength developer tools. I could blather on forever defining that but I think most professional programmers know what they need as that’s what they focus all their time doing.

Hobbyists need to Learn

Hobbyist programmers main need is to learn. For them each learning experience grows on the past. Further, I would argue most hobbyist programmers are either younger (i.e. in elementary school, high school, or even college with a lot of free time on their hands) or older (i.e. retired and looking for something fun to exercise their brain.) I’m sure there are many hobbyists in between but I’d argue they are not the majority. Hobbyists goal is often to get better at programming, and I believe they are by definition both passionate about it and interested in learning in ways that occupational programmers simply are not.

Occupational Programmers need Productivity

Occupational programmers don’t have time to learn; they’ve got a real job to worry about. And occupational programmers often don’t care about learning the intricasies of programming at a professional level. Most importantly, occupational programmers don’t program frequently enough to transfer their learning from short to long term memory. Tellingly, Microsoft has a Coding4Fun website for hobbyists, but doesn’t have a Coding4Work website for occupational programmers!

Occupational Programmers need Discovery

Occupational programmers also need to be able to discover how to do things without lots of prerequisite knowledge. They need to be able to be highly productive every time the sit down to code. In that vein Microsoft’s “My” object is intuitive enough and addresses discovery.

Occupational Programmers need to Experiment

On the other hand, occupational programmers need to painlessly try things to see what works and not be distracted by lots of complexity. It is here where even Microsoft’s Express Editions fall short. They need a far simplier environment that allows them to type in a single line of code, highlight it, and then press a key to run it; no other prerequisites required. And if, for example, the code won’t run because of a missing reference the environment should pop up a suggestion based on an index of all available components on the user’s system, the occupational programmer should never be left trying to figure out where to go next to solve his problem.

In other words the occupational programmer needs a powerful interpreter but one that works more like SQL Query Analyzer than a command line interpreter. SQL Query Analyzer’s is it’s “canvas” that allows one to leave lots code lying around in various states of completion while it only executes the code that the user has currently highlighted.

Occupational Programmers need Progressive Disclosure

occupational programmers need Progressive Disclosure. They shouldn’t open up a development environment with numerous items competing for their attention. They shouldn’t have to worry about projects or properties or toolboxes, they should have a screen where they can start writing code and the equivalent of a (well designed) “Start” button and menu/wizard system.

Occupational Programmers need their Skills Grown

Additionally, the languages and tools used by occupational programmers should empower they to continually improve their skills without even trying, as they end up building significant systems over time. Some will even change careers to become full-time professional programmers eventually. If they are sandboxed with dead-end language and environment, think VBA or Visual Studio Tools for Applications, that’s no good either.

But Don’t Sandbox Occupational Programmers

And occupational programmers should be given the same languages professional developers use, but in a less-restrictive form; one potential example being a dynamic version of VB.NET with duck typing, etc. This is so professional developers can reuse and refactor the occupational programmer’s components and code. Occupational programmers have specialized knowledge that professional developers simply don’t have and putting them in two different sandboxes doesn’t make sense.

Focus on Languages and Frameworks, not GUI Tools

Further, the tool builders should focus on language and framework first, not the visual tools. Although this applies across the board for developer tools, it’s especially important to state related to occupational programmers because the tendancy is to just throw lots of GUI at less experienced developers, but that approach is fraught with peril (anyone remember Visual InterDev Design Time Controls?) I can acutally write a long post on this topic alone, and plan to, but suffice it to say that the focus should be on making it very easy to implement something in code using the language and the framework, and then create the visual tools to streamline this last.

Not Hard to Serve this HUGE Market

I believe there are tremendous number of occupational programmers out there whose needs are not being served and the irony is that I’m not proposing anything complex. On the contrary, Microsoft has partically all the technology it needs to build and ship the first version of what I’m envisioning within six months or less assuming a 3 to 5 person “SWAT team” that’s sheltered from politics (by 3 to 5 people I mean everyone; development, testing, documentation, marketing, etc.) It would be a tiny investment, and if it was released below the radar and sans Microsoft’s full hype machine it’s benefit to prospective users could be evaluated before they committing Microsoft to supporting any legacies it might create. And Microsoft could call this tool “Power Developer” (I chose that name because of PowerShell.)

There’s a lot more I could say on this issue (and I’ve said some of it in the past), but I’ll leave it at this and await your comments.

Other References

P.S. Here are some posts I made over 2.5 years ago on this and related subjects:

And these are some posts over people have made and/or posts with related comments, in no particular order:

I’m Available…

P.P.S. If any decision makers at Microsoft are listening but don’t currently have the right person on the inside to champion this idea, they should be aware that I am, at the time of this writing, available to help. :)

 

Microsoft’s Obsolete Process and Release Cycle

I made two posts recently that muddled serveral issues so I am creating a seperate post here to isolate them and provide a location for comments specific to this issue:

Microsoft is loosing the battle with its open-source competition in languages and web frameworks because of their obsolete processes and release cycles

In summary, it’s my belief that the processes and release cycle for designing, building and releasing developer tools as well as for attracting developers that worked so well in the 80’s and 90’s are now obsolute when compared to the process in use by the open-source community. Further I believe that if Microsoft doesn’t completely rethink how it manages it’s processes and release cycle for designing, building and releasing developer tools in a manner that is competitive with the open-source process that it will slip farther and farther behind until it’s developers tools become irrelevent. Of course as that happens Microsoft’s platforms will also slowly decline in relevence until it is simply no longer the main player but instead one of many.

That’s not to say they are not doing some things right, they are. But they need revolution not evolution to stay the major player in developer tools.

Clarifying my Microsoft Developer Division Rant, Redux

I made two posts recently discussing Microsoft’s Developer Division. Although I had strong feelings about the issues, my thoughts were still too unclear to be succinct. But writing clarifies thought and I had already waited too long to post so a-posting I went.

Reading the comments it became clear I had muddled several issues:

  1. How Open-Source competition for languages and web frameworks are exploiting Microsoft’s obsolete process and release cycle
  2. How Microsoft is not addressing the needs of the “Occupational Programmer
  3. My own personal frustrations as an occupational programmer with Microsoft’s obsolete process and release cycle

Since few if any likely to care about my personal frustrations if they are not framed in broader need, I won’t belabor point #3 but I will address points #1 and #2 as seperate issues in my next posts.

UPDATE - (2007-Jan-01): Both of those posts are now live: