BigBlueHat

I used to dream in XSLT if you can believe it. The largest web site I’ve built to date was built on Apache Cocoon. It’s an XML framework that lets you route incoming HTTP request through pipelines that generate XML, run through various XSLT transformations, and then serialize the output as HTML, PDF, or whatever. It’s a framework I occasionally wish I had time to get back into.

Brad and I have discussed using it in future versions of BlueInk. There are some newer XML technologies, though, that also look appealing, but there’s more research to be done on their stability and library availability for PHP. The one that interests me most is XQuery. It’s similar to XSLT, in that it transforms XML into something else, but because it’s a query language, it can munch data in fewer lines than XSLT and create non-XML-based results. I haven’t done enough research to be able to show you a use case yet, but hopefully once I move out the XQuery neophyte stage (whenever I find that time) I’ll post some code samples.

How are you using XML, XSLT, or XQuery?

Well, it’s been a while since we’ve written anything food-related, and that somehow seems wrong given the current changes that have swept over the office. I speak of muffins.

Because of our presently bleak donut situation, we were forced to reconsider all possible options for our morning snack, so that our coffee would not be left tragically unaccompanied. Then it struck me. During my college days, there was no finer breakfast item than the muffins from Bi-Lo. Sold in packs of four and featuring such glamorous flavor options as cran-orange and cinnamon-chip (as well as a bevy of others), these delectable treats have proven to be just the solution to our problem of “fueling up” for the day. And as a bonus, unlike donuts they don’t go stale within just a few days.

Alright, enough writing. It’s muffin time…

Looking to build a new web site? or migrate an old one to a content management system? As of today, you can sign-up for a web site powered by our BlueInk Content Management System.

BlueInk provides a usable, focused interface for managing your web site’s content. Check out the feature list, screenshots, and demo for more information.

BlueInk comes in four different sizes, all available for instant setup on the BlueInk pricing page.

If you keep up with the web related tech news daily, you’ve likely read a few articles and blogs about Google’s App Engine announcement. The idea is not unlike Amazon’s array of web services or other “cloud computing” platforms.

Earlier today I was trying to explain my hesitation toward these services to a friend. The idea is great, the price is great, the technology is “cutting edge.” So why not use it? My earlier response wasn’t as succinct as I would have liked, but just now I skimmed through Read/Write Web’s writeup on App Engine. Marshall Kirkpatrick summed up the concern better than I did:

It’s very, very important that there be no barriers to leaving App Engine and that the service retains customers based on price and superior service. Anything else, any lock-in, will drive a stake through the heart of innovation.

Cloud computing is a great concept, and as a web developer it has great appeal (listed earlier). However, the risks of lock-in and restricted data access mean that innovation, creativity, and privacy all depend on the whims, desires, and ideas of large companies who may or may not keep my best interest at heart.

Brad and I have been discussing web architecture, programming methodologies, and frameworks recently. REST is certainly our architectural style of choice, and the edge of the diving board for the necessary shift in thinking gets closer daily.

During our discussions over the last several weeks, we’ve learned a few great things:

1. We want to build what’s next — not just buzz or hype, but what you want next or the next thing that would make your life easier.
2. It will likely be semantic, addressable, and built on technology from the early 1990’s — when TBL envisioned the Web, his initial idea was to make it both readable (as it is now) and writable (as it’s slowly becoming). Our objective is to fulfill that with the products we build. In addition, the more meaning (semantics) and “future-proofing” we can throw into the mix, the better for all.
3. Friendly, documented, simplicity should describe all we do — simplicity takes more education, intention, and forethought than complexity, but the payoff is unparalleled. Because education is needed, the more obvious and documented the functionality of a program, the more usable the program.

With those items in our heads, we’ve begun looking at the way we write, code, and manage our time and resources. Sometimes its painful to compare what you’d like to be doing with what you’ve done, but the value of the analysis is valuable beyond quantification.

What triggered this post was a quote I found today while looking for something else:

When people ask me what I do for a living, I say that I research what the web of the future could be. At that point, they ask me to give them an example of what that would mean for them. My usual reply is “if we are successful, the only difference you’ll perceive is that you won’t feel as constantly lost as you feel today”. At that point they smile, happy to meet a technologist who thinks it’s his fault, not theirs, if they can’t do something with his software.

No matter what technology or platform we build the future of the web upon, we need to learn how to write the software that delivers those smiles: anything short of that will be a failure.

from Piggy Bank, Cocoon and the Future of the Web

It’s a sentiment we share, and one we’re hard at work attempting to achieve. We’ll share more about how we’re getting closer to our goals as we work/fight our way to them.