Posts tagged as: ruby

Feeling the urge to code

I haven't been blogging much lately, because I've been spending my time reading Python books. That's one thing that separates Python from Ruby that people don't seem to mention when comparing the languages. There are tons of Python books, while there is basically just one good Ruby book. I'm going to spend a day or two more of just reading, and then I'll start doing some basic RSS coding to test out the Python libraries. Once I feel comfortable with the language, I'll get back to exploring the various forms of microcontent and their potential relationship to OPML. Don't expect much blogging here for a week or so, but I will report on my initial RSS library experiments on my code blog.

Starting work on blog link analysis

A few weeks ago I proposed an analysis of linking patterns between bloggers to measure the frequency of links based on rank. I ran into a few snags, such as getting fed up with some limitations in Ruby and hitting a limit on the number of API calls Technorati would allow per day. I've now finished reading up on a few Web languages, and I've decided to give PHP a try. I plan on working my way through Perl and Python also over the next few months. I've done some work with each of them, but that was before I got interested in XML. Technorati has also generously agreed to boost my daily allotment, so I should have no problem getting the blog rank data I need.

My basic goal is to determine whether bloggers tend to link mostly to others with a similar rank (Crosslinking), or to those with higher (Uplinking) or lower (Downlinking) rank. To do this I will first extract the set of bloggers listed at one time on Tech Memeorandum and use them as my sample. Let's call them the target list of bloggers, or target bloggers for short. I can use the Technorati API to determine the rank of each target blogger, and then split them into 3 groups, with a rank of less than 1,000 signifying membership in the A-list, between 1,000 and 10,000 being the M-list, and the remainder being the Z-list. This analysis alone will be interesting, and I may start compiling longer term statistics on these results. I'll certainly publish this intermediate result here.

The tricky part is determining the rank of the blogs that the target bloggers link to. I can autodiscover the target bloggers' RSS feeds and extract the links from their posts, but Technorati doesn't give a rank for just a post URL. It needs to know the URL of a blog's home page. So what I have to do is autodiscover the RSS feeds of blogs the target bloggers link to, and then look in those RSS feeds to find the home page URL, which can then be used to determine the rank on Technorati. At that point I can count the number of uplinks, downlinks, and crosslinks made by each target blogger. This data can then be analysed.

One systematic error is that A-listers can't uplink, and Z-listers can't downlink. I may just keep the crosslinking results and use them to see how often A-listers, M-listers and Z-listers crosslink as a percentage of their total links.

If you had a problem following this plan, here is the basic path I need to follow: Parse Tech Memeorandum -> Target Blog URLs -> Autodiscover Target Blogs RSS Feeds -> Parse Target blog posts -> Links from target blogs to other blog posts -> Autodiscover RSS Feeds of the linked blog posts - > URLs of blogs linked to by target blogs ->Rank of blogs linked to by target blogs.

You can follow the coding on my programming blog where I'll post all of my source code and links to my intermediate data sets. I could store all the data in a MySQL database, but I want to make it publicly accessible, so I'll store it in XML files on the website. I'll report on any useful results here as well as the code blog.

Changing my Web programming approach

After thinking about it for a week, I've decided to start exploring other programming languages as a way of continuing my work with RSS, OPML and Web APIs. I still like Ruby, but there are enough limitations in it for me that I want to see if there are some languages that would be a better fit. I've changed the name of my Ruby blog to Code.Darwinianweb.com to reflect this shift in focus. It will still be the place where the source code for all of my Web programming experiments are posted.

Rethinking my programming strategy

Ever since I did my last burst of Ruby programming a week ago, I've been trying to figure out where I want to go with Ruby and Web programming in general. The truth is that I'm hitting a few roadblocks that are rather frustrating. I still find the Ruby syntax cleaner than any language I've used since dBASE. On the other hand, the available Ruby libraries are not as robust or mature as Python or Perl. This is a particular problem with XML parsing. I didn't expect this when I started programming again last fall, but since almost all of my programming has been with RSS, OPML, API calls, I'm extremely dependent on REXML, the XML parser built into Ruby. I've been hitting bugs and weirdnesses with REXML, and after emailing the author 3 times over the last 2 months, I've still not been able to get a response. On the other hand, I'm now getting to know a lot of Python programmers. There is even a Python programmer in Seattle who keeps emailing me, offering to build RSS and OPML libraries to do whatever I want.

I knew Ruby had fewer libraries than older languages when I started using it, but I assumed I would just write my own libraries to do whatever I wanted. That's what I've always done in the past. The other thing I've discovered in the last few months is that I'm going to have less time to code than I originally expected, so building libraries for things like XML parsing are not likely to happen. Actually my whole approach to programming is going to be different than I had expected. Instead of getting more and more proficient in one language and tackling all kinds of tasks, I now see that I will be focusing on RSS, OPML and API calls for possibly a few years. It might make more sense to see how this is done with many of the available languages, such as Perl, Python, PHP, and Javascript. Instead of becoming a language expert, I'd now rather become a domain expert.

This decision is also dependent on ideas I might have for writing books. I really enjoy that process, and know that a good book can be a valuable aid to developing my new career as a tech blogger. Instead of writing a Ruby book someday, it now seems more likely that I'll want to write an RSS and OPML book, which means I may want to be able to discuss techniques in multiple languages.

I haven't made up my mind yet. I'm going to spend a few days playing with Python and looking at other XML solutions for Ruby. Who knows, maybe someone will tell the author of REXML to answer my email and tell me how to keep it from choking on ampersands.

Saving API mashup data in OPML files

Now that I can use the Optimal browser to display OPML files easily on a web page, I can go ahead with an idea I've had for creating mashups of API results. I wrote about this on my mashup blog 2 weeks ago, so you can find the details there. I'm going to start coding now, and as usual the details will appear on the mashup blog as I work them out, and the source code will appear on my Ruby blog. I'll report back here when anything interesting is ready for viewing.

API programming is this week's priority

I let myself get a little distracted with reading lists and blogosphere politics over the last week, but now I have to get to some serious coding to prepare for Mashup Camp next week. That means blogging will be light over here. You can follow my progress on my mashup blog, and I'll post the source for anything I write in Ruby on my Ruby blog. My focus will be on using my Tech Memeorandum XML and OPML files as sources for calling various APIs.

Which programming language will get you a job?

The Indeed.com job site now allows you to graph the percentage of online want ads that contain specific key words. There are many uses for this, but I thought it would be interesting to compare the relative demand for specific programming skills. It looks like they rank as follows: .Net, Java, Perl, PHP, Python, Ajax, and Ruby. Despite the recent hype, Ajax and Ruby are barely visible compared to the better known languages.

But that isn't the whole story. All of the leading languages show fairly steady levels of demand. Ajax and Ruby, on the other hand, show strong growth over the last year. Want ads for Ruby doubled, and Ajax increased six-fold.





These last two graphs also suggest a potential growth market in Ruby and Ajax training. (Via Steve Rubel)

Problem with RSS categories

The first version of my RubyRiver aggregator displays all the items in a feed without any filtering, which allows items unrelated to Ruby to appear. This morning I decided to explore filtering based on the category tag. The RSS 2.0 specification states that "You may include as many category elements as you need to, for different domains, and to have an item cross-referenced in different parts of the same domain." So there should be no problem. All I had to do was extract the category tag and select items that contained "Ruby" in that tag.

Here is an example from the blog Eric's Ponderings, which contains some useful Ruby programming posts, but also switches to football whenever the University of Texas Longhorns win a big game. Here is a portion of one of his RSS feed items about Ruby and Java:

I don't know why he includes Ruby twice, but that shouldn't get in the way of my code, as long as there is at least one category I can match.

Checking the rest of my feeds, however, brought out a problem with the way some blogs use categories. For example, the O'Reilly Ruby blog is entirely about Ruby, so the authors don't feel the need to include Ruby in the categories. This is apparently assumed from the context. Instead the categories are terms like Opinion, News, and Articles. This makes sense within the blog, but doesn't help when the feed is aggregated with many others.

I can solve the problem in my own code by identifying feeds within my .opml feed list as Ruby specific or multi-topic. This will allow my code to use the category tag only when parsing multi-topic feeds. Unfortunately this requires me to go to extra effort when adding new feeds, which in turn means that any user of my code will have to understand this issue as well. General purpose aggregators aren't likely to use this solution, which means that filtering for Ruby categories in a generic aggregator will filter out some of the blog posts that the user would want.

This type of inconsistency in applying tags to blog posts illustrates the hurdles that still must be overcome before RSS can fulfill its promise. The specification is willing, but the patterns of usage are weak.

Starting a new blog

Now that I have my Ruby projects planned out for at least a year, I'd like to figure out my next blog. My principal reason for writing these blogs is to learn as much as I can about new Internet technologies. Ruby will likely be my core language for exploring much of this on the server side, but I also need to learn AJAX to handle client-side programming. I had thought about starting an AJAX blog, but that is too limiting. I also want to learn about lots of other stuff:

• APIs
• Map programming and related geocoding techniques. As O'Reilly would say in his incredibly pithy manner, everything having to do with Where.
• Mashing up APIs and maps to create new hybrid apps.
• The various interop technologies, such as REST, XML-RPC, and SOAP.

This next blog will probably be the last one I start for at least a year, so I want it to be inclusive enough to handle all of these issues. I'm thinking that Mashups combine them in a convenient package, so my most likely decision will be to start Mashup.Darwinianweb.com as the new blog. That would leave me with three blogs:

• DarwinianWeb.com: Focusing on general issues of the evolution of the Internet and software.
• Ruby.DarwinianWeb.com: A central clearing house for all my Ruby programming work.
• Mashup.DarwinianWeb.com: A common location for my explorations of the rest of these new technologies.

My wife keeps telling me to just write one blog and combine everything there, but I think that the separate Ruby blog has been a success, because it allows me to cover details about the language and source code listings that would surely chase away any general reader who wasn't programming in Ruby. I think the mashup work requires the same type of separation. I'll make a decision on this in the next day or so. Luckily the code I've written for these blogs makes it easy to start a new one with just an hour or so of effort.

Ruby RSS aggregator is running

My first RSS aggregator written in Ruby is now up at RubyRiver.org. It's still primitive, but it seems to be working OK. My goal in building this is to create a tutorial for new Ruby programmers. I've been publishing the code on my Ruby blog as I've been writing it. The complete code will be available for free download in a day or two, and the tutorial will be posted on RubyRiver as it is developed.

Running multiple blogs has given me an interesting insight into one of the problems of having people read a site through RSS. I've spoken to a number of people who read this blog, and when I mention my interest in Ruby, they usually say "You should start a Ruby blog." When I say that I already write one, they ask how they can find it. That's when I realize that they read the RSS feed and have never seen the link to the Ruby site on my navbar. So how do I solve this? Should I plug everything I do in every blog post? That was why navbars got added to websites.

Is the Web 2.0 frenzy passing?

It may just be the holidays, but it seems like the excitement over Web 2.0 is wearing off. Even the smarky sites are getting tired. Does anyone else notice this? Now don't jump all over me and say it was just hype in the first place. I think what hit everyone last summer was a legitimate epiphany within the computer world that is OK to come out and play again. Maybe people are just busy working on new projects. I know that I've dug myself in pretty deeply with Ruby, I think it may be time for me to add something new to my studies. As soon as I get the first version of my Ruby aggregator going I think I'll start working with Ajax.

Web 2.0 programmers wanted

A defining characteristic of Web 2.0 is that it is designed by programmers for programmers, where Web 1.0 was designed by media people and merchandisers for consumers. I know that there is a lot of talk about Web 2.0 being for "the people," but those people are supergeeks. In this first phase of Web 2.0 we are seeing the rapid proposal and adoption of "standards." When the dust settles in a couple of years, we'll have one leading standard and a minority, counter-standard in each area, as always. In the meantime, a lot of programmers are going to get hired to write a lot of new code based on these standards, and that is a good thing. Not just for programmers, but for users, since most of these things will be free. The WSJ (behind a paid subscription) today had a slightly confused article about the proliferation of programming languages, with references to both Ruby on Rails and Ajax. The important point is that the reporter and his editors recognized that programming as a cool activity is rising again in the zeitgeist.

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.

Tagging is now working

I finished the coding for tags on this and the Ruby site. I even have a simple tag cloud in the navbar. These tags are still only entered by me, but I'll have user tags eventually. I keep coming back to Joshua Schachter's comment that tags are about memory more than categorization. I'm trying to lose that rigid relational database kind of thinking. Once I have a full Ruby based version of this site I'll be able to tie into other tag based sites. For now these pages are still static html that is recreated and upload to this server every time I make a new post. I'll watch the stats and see if anyone actually uses the tag pages.

Googlebase Criticisms

Sam Ruby is doing a thorough review of the Googlebase data formats and he isn't happy about their feeds:

The urge to scale

I guess being a dot-com CTO is in my blood. I like to think through various architectures for managing groups of websites. You need to lock down a model for scaling early or you face big problems if you ever need to handle large amounts of traffic. The real key is a logical architecture for domain names. For example, if I thought I was going to serve a lot of podcasts, I would create something like data.darwinianweb.com or podcasts.darwinianweb.com. That would allow me to move that part of my content where it could be best and most cheaply served.

Right now I have darwinianweb.com to handle this main blog where I plan on covering general issues on the changing form of the Internet. I also have ruby.darwinianweb.com, which is a blog that allows me to go into as much depth as I want about learning the Ruby programming language.

I don't want to have too many subdomains, categorization can be handled more easily and on a larger scle with tags, which I am working on adding. At the same time, a separate domain creates more of a distinct place or channel of thought for the user. People automatically switch contexts when they change to a new site, just like a new TV channel.

I plan on having only a few more content subdomains, such as ajax.darwinianweb.com, and xml.darwinianweb.com. Programming languages or standards like XML are so broad and have so many supplementary tools and resources that they work better in their own site or subsite.

I'll also be creating separate domains for exchanging data with other servers. I don't know what will happen with my API experiment, or if that will become a target for abuse, so I'll also create api.darwinianweb.com to serve API calls. It isn't a matter of large amounts of traffic. I want to be able to shut down the API server easily. Of course, that brings up the issue of dependency on critical servers in a distributed environment called for by Web 2.0.

One solution, which also comes easily in an XML/RSS based communication model, is cache the most recent messages as text files, so the most recent result of an API call can be reused instead of calling the API again.

These issues will be played out on a much larger scale throughout the web. Chains of API dependencies will play interesting roles in the future.

Deitel catches the Web 2.0 bug

I've bought several of Deitel's computer books in the past, and they always do a very good job. It looks like they know a major wave when they see one. Although they don't have any web 2.0 related books out yet, other than a couple on XML, they have just launched a set of resource centers. These are collections of links for Ajax, Ruby, and Mash-ups. This is a good marketing idea, since it starts building their traffic in these areas in preparation for the books they must be working feverishly on. The other thing I like is that they are based in Maynard, Mass, just a few miles away from me. Maybe they can help jumpstart a New England Web 2.0 community. We sure are behind Silicon Valley on this wave.

My first Amazon API program

I now have a very simple program that queries the Amazon API for books on Ruby programming and displays the results as a list of titles linked to their product pages. The most interesting part wasn't the coding, which is pretty simple, but the incredible depth of Amazon's API. They make it possible to build a complete e-commerce site built on their engine. I now understand why Jeff Bezos was quoted on a financial program as saying that Amazon may eventually become a e-commerce systems provider instead of a retailer. You can learn a lot about a company's plans by studying the functionality they surface in their API. Even if I don't end up building a real product with anyone's API, I will get a better understanding of their strategy.

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.

Now I can get back to Ruby

With the site looking pretty good I can now indulge my inner coder and do some Ruby programming. I'm going to try and keep the details of this on my Ruby Development Site, so you can check in over there to see what I'm up to. I'll try to restrict my Ruby posts here to pointing out anything interesting that I've accomplished, or to new happenings in the Ruby world that will affect the general Internet's evolution.

Ruby.Darwinianweb is working

I think I've got everything working on ruby.darwinianweb.com at a pretty basic level. I wrote a simple Ruby script to retrieve an Amazon page with HTTP, just to get my feet wet. Considering the amount of time I've been working with it, Ruby looks like it will be a lot of fun. I've hardly been stuck at all during this process.

I think having a separate site to write about my experiments with Ruby is a good idea, because it will allow me to geek out there without turning this into a pure programming blog. The main Darwinianweb.com site will stay focused on my reactions to new events and technologies on the Internet. The only weird thing will be posting my code as I learn the language. In the past when I wrote about programming I always waited until I was proficient in the language before publishing my work. That way I could go back and fix any newbie mistakes I made early on. This new style of code blogging will take some getting used to.

Book Note: Programming Ruby

I'm not going to be reading this straight through, but since it seems to serve as the unofficial manual for Ruby, I'll be referring to it as I start doing my Ruby/Amazon programming. That really is my favorite way to learn a language, build something and look up what you need as you go. Of course, you need a forgiving language with a low initial learning curve, and that seems to fit the profile of Ruby.

The author, Dave Thomas, also wrote the first book on Ruby on Rails. A week or two ago I saw a post from him somewhere saying that his two Ruby books were the most popular on Amazon's computer book list. As an author, I'm always curious how you find a topic that is so hot. Unfortunately, the answer is that you have to start several years before things get hot, and then hope to get lucky. The lesson here is that you can't chase hotness, because you will already be too late. You have to be receptive to new things and follow your dreams when nobudy else is looking. My most succesful technology picks came from being an early adopter, not from being a follower. I don't plan on writing any books on the current crop of Web 2.0 technologies, it is already too late for that, but if I immerse myself in the current wave, something new will come along that I may be early enough with to make some money. In 1995 when I started with the Internet, my friends in the software business kept asking how anyone could make any money from that stuff. My answer was that I didn't know yet, but the best way to find out was to just do it, not to wait until the business models were obvious.

Making progress on Ruby project

I started writing a framework for my Ruby test site yesterday. All I need right now is a set of simple functions to display the source code of the programs I'm writing, and to execute them and display the results within a standard page format for the site. As is common with OOP languages, I'm just using the existing classes in a procedural manner for now. Once I start building up a larger codebase and have to deal with reuse issues, I will build some classes of my own. So far I'm finding Ruby to be a pleasant language to work with for what is now just text manipulation. The syntax stays out of your way, and it is extremely dynamic. So I can have code that constructs the test code I want to execute and then evaluates it and returns the result as a string. In this way it is reminiscient of the dBASE language, which is great for the "make it up as you go along" style I prefer. Today I hope to start building queries for Amazon in Ruby. I'll have more to say about that in later posts.

Active State is supporting Ruby

Active State has released a beta of version 3.5 of their Komodo IDE that supports Ruby and Ruby on Rails. I've played with Komodo in the past, but never attempted to use it regularly. I'll be trying it out for my Ruby tests.

Lots of balls in the air

I've got so many projects ideas that I think I should list them, if only to remind me of where I want to go:

• CSS: Redesign Darwinianweb.com site to use style sheets.
• Ruby: Amazon API based app to determine the best book on a given subject.
• Ruby on Rails: Rebuild the CMS for this blog from the current FoxPro code.
• Ajax: Google API based app using Google Maps.
• Ajax: A stripped down version of TiddlyWiki as a form of self-modifying page.

Ruby site number 2

I've got a new Ruby test site running at A2hosting.com. There is nothing to see yet, but at least I can run my first test scripts there.

Ruby on Rails is gaining traction

While searching for web hosts the last two days it has become clear that Ruby on Rails is attracting a lot of attention. Many of the web hosts who support it make a big deal of that fact on their home pages. Some hosts don't want to run Rails, because it is supposed to use up a lot of resources. I wonder if most of these people signing up to use it are moving from existing hosts who don't support Rails, or if new web developers are starting up?

I spoke too soon

Well, I had a fun time with Textdrive.com. After their tech support didn't respond for 24 hours about my inability to run any scripts, I tried their "support" forum. The moderator told me that if I couldn't get a script to run I shouldn't be using their service, so I took his advice. Now I'm trying A2hosting.com. I have Ruby and Apache running on my own machine, so I'll just start with the Amazon stuff locally. I'll let you know when I also have it running online.

New Ruby site

I got my new site started to experiment with Ruby at ruby.darwinianweb.com. I decided to go with Textdrive.com, since they are recommended by the developers of Ruby on Rails. I went through the usual hassles of setting up the DNS. Darwinianweb.com is registered at Godaddy.com and its DNS is handled by Bluehost.com where this blog is hosted. So I had three different companies pointing me back to the others for a while.

Now I'm going through the standard "Why won't any of my scripts run?" that I experience on most new hosting services. Once I get everything placed right and working I can start setting up an Amazon web services development project.

Time to start Ruby programming

I've been reading Ruby books for a week now and I'm getting antsy to do some coding. My way of learning a language is to pick a real target and then push my way through all the obstacles. That forces me to do the hard tasks, but keeps me from wasting time on features I'll never need. I know I've been saying that I want to use Ruby to run the CMS for this blog, but I want to hold off on that until I add enough features. For example, I still need to add calls to ping servers and tagging to this blog. It will be easier to just do that in FoxPro first, and not worry about the programming language at the same time. Besides, from everything I've seen, Ruby on Rails will be the best way to build a CMS with Ruby, so I'll wait until later to start that project. I'll pick an easier target for my first Ruby project.

I've had an idea for Amazon web service programming for a while that might make a good candidate. I'd like to build a "pick the best book on a subject" app. I'm not sure exactly what that means, but the general idea would be to enter a search term and have the app rank available books based on a set of criteria I develop. That will let me explore the Amazon database from the inside.

My first step will be to build a development environment. I could start by doing Ruby programming on my own computer, but that won't let you look over my shoulder easily. I could do the Ruby project on the server where this blog is hosted, but that brings up the security issue. Programming on the web in a new language always leaves open the possibility of security holes. I'd rather do my quick and dirty development in a separate location and then move them to a new server for production use. I also like the idea of a distributed environment for web development. It allows for better scaling and gives me more control later for rearranging the architecture. So my first task will be to build ruby.darwinianweb.com at a new host.

When I first started looking at Ruby I saw that there were some hosting sites that provided Ruby and Ruby on Rails installations at extremely low rates. They billed themselves as Ruby playgrounds, which is a great idea. I've been a programming language junkie for over 25 years, and the idea of playing with a new language is always a thrill. It looks like these hosts are aimed directly at that market.

Book Note: The Ruby Way

I've already finished this book, so I'll just do more of a final review than a series of notes while reading. This is basically a cookbook aimed at an intermediate Ruby programmer who wants to see the most elegant way to accomplish both standard and fairly advanced techniques. Even so the first chapter is a superb review of the basic language features. I'd recommend it for any experienced programmer who wants an overview of Ruby's syntax and OOP capabilities. The rest of the book is well written, but has too much of a systems programming focus and too little information on application development for me. Hal Fulton's background as a CS professor certainly comes through. For example, there are 30 pages on threaded programming and 3 pages on using MySQL. The idea of controlling multiple threads is cool, but I'd ever do it. I could just launch multiple instances of the interpreter, or more likely use mod_ruby and let Apache deal with multiple threads. In the end, other than the first chapter review of Ruby syntax I found little of use to me, but anyone building a Ruby IDE in Ruby will certainly be pleased.

Why I'd rather roll my own CMS

Just when I was feeling silly about building my own blogging CMS I found two posts that reminded me why I like to keep my data in my own system. David Weinberger recently completed the "upgrade from hell" with MoveableType and Scoble is throwing a hissy fit over Wordpress' RSS feed. This is why I don't feel comfortable with other people managing my data. I'd rather do the work upfront than get caught later in somebody else's database.

This brings up a key problem with web-based apps. When a desktop app fails or a major bug shows up, I can at least find some product or write some code to get to the data and transfer it to some other tool. What happens when my data is in a database on some server somewhere? Of course, you have to rely on remote hosting for lots of things. I don't want the hassles of running my own webserver at my house, but I keep a complete working mirror of any site I build, including all the supporting scripts on one of my machines at home. Once my blogging system is moved to Ruby/MySQL I'll certainly host it remotely, but it will still be running my code.

The average user has to rely on other people's code, and it will take years before that trust is solid. Yes, I know that people use remote blogging systems every day, but that is still the leading edge of users. Before we all move to web versions of Office tools, a lot of thought has to be given to recovery. I'm going to assume that any reputable host will keep back-ups, even though that has been proven false also. If users discover that upgrades and new "features" cause them to lose data, there could be a backlash that sets Web 2.0 back a few years. When Word fails, people may curse, but they don't give up on Windows. If a web version of Word fails, they may decide to take their data back where they feel more control.

Plans for using Ruby

I guess I should explain what I want to do with Ruby. A major motivation for learning it is the amount of buzz surrounding it and the application framework Ruby on Rails. Language popularity comes in waves that usually last 3-4 years. In the 10 years I've been involved with the Internet I've seen Java, Perl, Javascript, PHP, Python and now Ruby each have their turn as the hot language.

Ultimately I want to write web 2.0 style mashups, but my first Ruby app will be the content management system that runs this blog. I know it sounds crazy to build yet another CMS, but that is the type of application I know best, so it makes a good testbed for new tools.Of course, I have no plans of creating a CMS that others can use, just something with enough functionality to serve my purposes. Right now I've written a system with Visual FoxPro, because I've been an xBASE programmer for 25 years and can do it in my sleep. I want to gradually rewrite it in Ruby and then rewrite it again with Rails.

One issue will be database access. Eventually I will use MySQL as the back-end, but at first I'll want to use Ruby with the .DBF files I am already using in the FoxPro version. Since Ruby has a much weaker set of available libraries than Python, I haven't been able to find a native Ruby module for DBF access. The path I'll probably go down will be to use a Python DBF library and a library that lets me call Python code from Ruby. It sounds like a horrible kludge, but it will let me learn Ruby while doing some practical work. I'll write the database routines so that they can easily be converted to MySQL later.

Book Note: Teach Yourself Ruby in 21 Days

I'm ready to give up on this one. As I expected, he dropped the pretense of writing for both novice and experienced programmers by the fifth chapter and is now in full-blown programmerspeak. That's fine with me, because I'd rather read something that assumes I know how to program, but doesn't assume I know Ruby. What is more frustrating is that he resisted explaining the OO features of Ruby early on, so now he is forced to introduce them as needed throughout unrelated chapters. For example, he explained how to create and use class methods as opposed to object methods in chapter six, which was supposed to be about I/O. He had no choice, because the File class has some methods that are used before a file object is created. Another problem I have is his use of examples. I believe in using either ultra simple examples, such as X = 1 and Y = 2, or useful examples that explain how a language feature can be applied in a practical way. This author is trying to stay somewhere in the middle by using examples that have real looking data but don't actually do anything useful. I'm not sure who would benefit from his approach. My next Ruby book will be Hal Fulton's The Ruby Way.

Book Note: Teach Yourself Ruby in 21 Days

The classic problem facing an author of any introduction to a programming language is whether to assume the reader has ever programmed in any language. This book adopts the approach of no prior programming, which in my experience always tends to break down quickly. It is easy to explain that a memory variable is like a cubbyhole with a name, but what happens when you reach topics like passing pointers to arrays of functions? The initial assumption is revealed as a farce. Taking this approach of no prior knowledge in a book on an object oriented language has the additional burden of explaining concepts such as encapsulation, polymorphism, and inheritance at the same time as saying a variable is like a shoebox that can hold any value. The mistake authors make is worrying that OO concepts are really difficult. The trouble isn't learning the concepts, it is understanding why they are necessary and justifying the extra work in using them. This book tries to avoid the pedantic style of explaining these concepts directly, by giving code examples first and then putting the names of the concepts in text box asides as if you didn't really have to know the names.

Instead of wrapping this term in all these qualifiers, I'd explain polymorphism by having a subheading called Polymorphism with examples of two different classes with a print method. A simple explanation of the consistency benefits of always calling this method print even if it does different things would explain the concept and the benefits at the same time.

Curiously, he even gets the description of inheritance wrong. He says that inheritance is when you add a method to a class and then call it in an object of that class. I always thought inheritance is when a subclass can call a method of the parent class.

This book is trying so hard to say "Don't worry, programming isn't really that hard" that it ends up confusing both new and experienced programmers. For example, it tries to explain that Ruby passes variables by reference through a strange example of changing part of a string in two variables pointing to the same value. To make it cute and more "accessible" he uses the name "Sandra" which he changes to "Sandra Dee." How old is this guy? I'd simply use an example like: After two chapters I'm getting pretty annoyed.

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.

Book Note: Teach Yourself Ruby in 21 Days

I started learning the Ruby programming language today. Ruby and the associated framework product, Ruby on Rails, seem to be all the rage among web 2.0 developers, so I thought I'd give it a try. It seems to be a "real" object oriented language, so I'm looking forward to it. I've programmed in Perl, which can be forced to use OO techniques, and Python, which is much more OOish, but I've mostly used them in a procedural manner. This time I'm going to try and really work with classes as well as objects. Back in the early 90s, when OOP first appeared in popular use, Borland hired me to write a book about their future dBASE for Windows product. I spent a year doing nothing but studying OO ideas and really fell in love with the approach. Sadly, the product was a bust, and the book never saw the light of day.

I have a stack of Ruby books on my desk, and I'm going to start with this one from Sams. You can find the details at Amazon if you want to read along with me.