Posts tagged as: sql

My Web 2.0 stack

I'm not sure when "stack" came to mean a list of languages/technical standards used to build an app, but it is a useful description. It helps convey the logical architecture within a multi-layered development environment. The best example of a useful stack is LAMP (Linux, Apache, MySQL, Perl or Python or PHP), which summed up what most of us used to build Web 1.0. I've spent the last few months reading and skimming as many new technology books as possible, and I've narrowed down the list of things I need to become proficient in to understand how Web 2.0 works. What I still need is a catchy acronym. Here's the list:

• XHTML. This is basically HTML with some really prissy rules, like case sensitivity, and needing to close all tags. There are said to be tools that will make this conversion for you, but I haven't tried any.
• CSS. Once you understand the basic rules, CSS is a fun way to design a site, especially if you start with a pre-written stylesheet, so you can just change things like colors and spacing.
• XML. While XML itself can be understood in minutes, the many, many ancillary standards and protocols make it tough to find a real-world entry point. I've found RSS programming to be a good starting place.
• Ruby. I've been programming with Ruby for a month, and I'm getting to like it more and more. I think it may have the same level of ease and productivity that made the dBASE language so popular in its time.
• SQL. Yes, its still here, and its still the same, which is the problem. The issue will be fitting the object-oriented data structures of XML into the tables of SQL. The consultants will be paying their mortgages on this one for years.
• Javascript. I could say Ajax instead to assure a higher rating on the Web 2.0 Validator, but Ajax really means Javascript that maintains contact with a server without reloading a page.

Frankly, its not as much as I expected when I started researching Web 2.0 this summer. The good part is that it all fits together easily, and none of the parts are particularly challenging. That's when I am most productive. By the time a language gets as richly, and complexly supported as Java, for example, I get bored and confused and move on.

Architecture for tags

I've been thinking about adding tags to this site, which stimulated some thinking about site architecture. I wrote my own blogging code to manage this site, so I can have maximum flexibility in areas like this. I've decided to walk the walk by building out this site with Web 2.0 architectures. That means I'm going to create my own API that returns XML as either RSS or OPML, and then have other parts of the site deliver page content based on this API. I'll then use that functionality to build a tag viewing interface similar to Delicious for my own posts here.

It sounds like overkill, but look at it this way. The content of this site is in a MySQL database on a server, which may not always be on the same physical machine as the site's Apache web server. As long as I have to adopt a client-server architecture, I can just as easily go around the outside through API calls over HTTP. It may be slower than making database calls directly to MySQL, but it will be a relative issue. If the performance slows down, I can just speed up the hardware or get someone to optimize the code . It is a totally scalable architecture. Of course, I won't try and deliver the entire site this way. The vast majority of the content is generated as a static html file. Just the controlling bits, and results of searches have to pass through the API/XML processing.

I'll write about the coding details on the Ruby site and post here when I have something you can try out.

Reading Amazon RSS with Ruby

I'm having a ball with my Ruby project. I had the usual start-up issues, but once I found a webhost that knew what it was doing, and ironed out a few bugs in the database library for MySQL, things have gone great. I now have a simple script that will read the current Amazon RSS feed for computer books, and publish it as a list of linked titles on a web page. Now I'm ready to sign up for an Amazon API account and get started with web services programming.

We need to start the feature race over again

There have been lots of predictions of online versions of desktop apps. What has been missing is a valid justification for people to move from Microsoft Office to an online set of apps. One unrecognized benefit will be the restarting of the feature race all over again. I just set up a new copy of Quicken so I could help my mother with her checkbook and the level of complexity is overwhelming. I just wanted to do simple checkbook balancing but the software acts as if I want to set up my own online brokerage house. I had the same experience the other day when I started building the system to manage this blog. I'm coding it myself with FoxPro at first and then I'll move it to MySQL and probably Ruby. All I wanted to start with was a simple flat file database of my posts, but FoxPro, Access and all the other supposedly end-user databases were so feature rich that I was faced with studying manuals just to create a form to add and edit records. A new generation of web based apps will have to start at the beginning of the feature curve and maybe some of them will stay simple enough to be used by non-power users. I don't mind programming and I like lots of features when I need them, but the current packaged software model requires publishers to constantly add features until they can do everything every competitor does. Hopefully the web model for apps will allow for different levels of complexity.