Wuby = Ruby Web Framework for Classic ASP Developers

Remember the days when you could just create a page for your web site that contained valid HTML and some server-side stuff between the <% %> symbols?  PHPers know what I’m talking about.  They still do it, except they use those other ASP-like symbols.  Now, ASP.NET allows us to do a little of that, but its frowned upon as poor coding practices if you use it too much.  Ruby on Rails allows it too, but only in the context of the views.  Since the views are display only, there is a pretty good balance of server-side code and browser-speak (HTML, Css, and JS).

We ASP.NETers can appreciate the MVC framework as well as the ASP.NET way of creating web applications.  But, oh how I feel nostalgic when I want to create a very simple page that needs a little bit of server-side treatment to work.  Between you and me, I sometimes revert back to classic ASP for this very reason.  Shh, don’t tell anyone.

Well, the good news is Wuby!  Wuby has finally been released into the wild for your enjoyment.  Wuby is a web server and hash-based database engine that allows web developers to use Ruby on the server-side to create sites using the <% %> delimiters.  Yay for us!

Here’s a link: www.rubyology.com/wuby.zip

Check Rubyology.com for screencasts on how to use this framework.  Alternatively, you can check back here as I plan to create a screencast myself in the near future.

Advertisement

One man GarageBand

I am a hip hop fan. Actually, I listen to a little bit of everything. For instance, my 6 disc changer currently has Kanye West, Common, Nickelback, Ne-Yo, Fabolous, and Daughtry. From time-to-time I will just listen to a cd of hip hop instrumentals from Don Dilli, a hip hop producer. I think hip hop, trip hop, and drum n’ bass are all great genres to play while you are “in the zone” at work. The music is excitable yet repetitive which allows for high energy and focus on tasks.

Okay, enough of that. While playing around on GarageBand, I used some of the standard loops to compile a track I call Serious Now. I named it that because I had just did a very silly song with my kids and young cousins. We had a lot of fun, but when they left the room I created this track. I hope you enjoy it as much as I do.

Keep in mind, I’m no producer (yet). But, I hope to be able to showcase some work from producers in the future. 😉

Serious Now

The Significance of Prototype.js and REST

One of my boys sent me a link to an article on Joelonsoftware.com entitled “Strategy Letter VI.” It is a great article that compares the strategy that IBM employed when they were trying to keep Lotus 1-2-3 relevant in the 80s to the challenge web-based software companies faced with keeping their applications relevant today.

Usually, I take Joel’s words with a grain of salt because (ironically) I have interpreted many of his public writings and actions as desperate attempts to stay relevant. However, this article offers true value to the reader. He offered knowledgeable insight that got me thinking about two things that have swept across the web and propelled web development forward by leaps and bounds: Prototype.js and REST architecture.

Prototype.js is the Godfather of Javascript Libraries (RIP James Brown). A large percent of the leading js libraries such as Mochikit, Scriptaculous, Mootools, JQuery, and YUI are either dependent on Prototype or HEAVILY influenced by it. Sam Stephenson, the creator of Prototype, showed the rest of the web that js didn’t have to be stressful. His library gave us an extremely helpful API for easily forging our own js solutions. But, this plain text file also showed the intermediate web developer how to take js and OOP it up; that is, use object-oriented techniques to deliver some advanced cross browser functionality. It was functional and educational at the same time – two attributes stressed out web junkies love.

Similarly, non-groundbreaking but super important, is the emergent REST architecture. REST is an architecture for interfacing with web applications. This increases the interoperability of your web app with other web apps out in the real world. It gives Amazon’s web services a predictable interface so that I, the burned out programmer, can think-less by reusing their chunks of functionality in a very familiar way.

REST does not require you to share your application with other web apps. In fact, the benefits of REST can be reaped by internal applications as well. REST can be a great approach to simplifying any application and making it more maintainable by using a well known architecture. Think of it as REST and relaxation.

Both of these technologies are inherent in Ruby on Rails, the hot young web framework that has all the ladies talking. So, it is no surprise that the management buzzword of the year, Web 2.0, is usually reserved for some RoR application that offers a fairly trivial service, but tons of ways of interacting with it.

In fact, when I think about what Prototype and REST did for AJAX calls, it becomes hard to imagine the term Web 2.0 without them. However, be mindful that the term Web 2.0 only means your web application is relevant today.

Developer vs. Coder

Are you a developer or a coder?  Before you answer that question, I urge you to consider several characteristics about yourself that you may be taking for granted.

First, let me start by saying this:  If you do not write code of any sort, then you are neither developer or coder.  But, you’re still invited to read the rest of my rant and share your $.02 via comments.

Why do you do it?  Why do you write code?  Is it a lucrative career choice you made based on the short-term earning potential?  Or, do you simply like building things because it’s neat?  A developer leans more toward the money.   The diplomat in me wants to point out that developers may also feel rewarded by just building things.  But, the distinction I want to make is that developers give the financial reward priority over the alternative.  On the other hand, a coder does it for the “love of the game” and not JUST for the money.

When do you think about your code the most?  Writing code can be a very stressful job.  Many people that do it pride themselves on being able to leave work (and the subsequent stress) at the office and focus purely on their personal lives.  Those people are developers.  Developers work from eight to five, nine to six, or whatever time they are paid to work.  Alternatively, coders may be in the office for eight to nine hours, but they are very likely to come up with the next killer app while doing something recreational like sleeping or gaming.  Coders may change environments, but they never stop working.  They write code for fun.

How did you write your last great project?  Did you use Google to overcome your programming challenges?  Did you copy code from some coder’s blog, or from an open source project without FULLY understanding what it does and why it does it that way?  Or, did you reach out to friends that write code; or better yet, did you figure it out for yourself?  If you reached out to friends or figured it out for yourself (even if Google pointed you in the right direction), you are a coder.

It is important to distinguish yourself between developers and coders.  As coders continue churning out great tools that are intuitive and fun to use, and our general population continue to become more computer savvy, the number of developers will grow much faster than the number of coders.  Developers will be the commodity while the value of coders make a sharp upwards turn.

In fact, what I am describing is already the reality.  Developers are happy to collect seemingly generous salaries and contract rates that allow them to sustain the status quo.  Meanwhile, coders have automated the collection, sorting, distribution, and storage of their funds in the interest of minimizing distractions while they innovate (for fun).

Coming Zune 2 a store near you!

 

I know this is like “so last week“, but I just read this last night. One of our Big Brothers, Microsoft, is set to release the second version of the Zune. But, get this: the specs on the new Zune are pretty hot. One of my favorite new features is TV-Out. That is great, because the 80GB version may actually allow me to put a good amount of my DVD collection into storage.

The big question to be answered by all digital media players is, “How does it stack up to the iPod?” In two words, it doesn’t. I say that because an iPod is an iPod. People that are passionately in love with their iPods aren’t breaking eye contact with it long enough to notice Microsoft’s latest announcement. And there are A LOT of those people. I will point out for MS that the new Zune is priced a lot lower than the iPod. However, I haven’t seen any cool screenshots of the Zune 2’s software, or images that compare the size of the Zune 2 to something significant (like an iPod Touch).

If you come across some cool images of the Zune 2, let me know. I really want an iPod Touch, but I might make peace in my house if I get myself a Zune 2 and use the saved cash on something nice for the lady. I am such a romantic.

Fix for serving static files with Mongrel using Camping

Last night, at our Ruby hack night, I had some assistance debugging a known issue with Why’s magic framework, Camping. Ok, let me be honest; Nathaniel fixed the issue while I sat and observed.

The issue occurs when you try to serve static content like images and style sheets using Mongrel. You can use Why’s example to spin up a controller to handle the static content using X-SendFile like this:


module Camping::Controllers
  class Static < R '/static/(.+)'
    MIME_TYPES = {'.css' => 'text/css', '.js' => 'text/javascript', '.jpg' => 'image/jpeg'}
    PATH = File.expand_path(File.dirname(__FILE__))
    def get(path)
      @headers['Content-Type'] = MIME_TYPES[path[/\.\w+$/, 0]] || "text/plain"
      unless path.include? ".." # prevent directory traversal attacks
        @headers['X-Sendfile'] = "#{PATH}/static/#{path}"
      else
        @status = "403"
        "403 - Invalid path"
      end
    end
  end
end


This code should allow Mongrel to serve any file under the “static” directory. This works as expected on non-Win32 platforms.

To correct this issue on Windows, a change has to be made to the Camping handler in Mongrel. Here is a diff that depicts the fix:


--- camping.rb.orig 2007-10-04 20:36:01.000000000 -0400
+++ camping.rb 2007-10-04 21:31:42.000000000 -0400
@@ -38,7 +38,7 @@
@@file_only_methods = ["GET","HEAD"]



def initialize(klass)
- @files = Mongrel::DirHandler.new("/",false)
+ @files = Mongrel::DirHandler.new(File.dirname(klass.instance_eval{@script}),false)
@guard = Mutex.new
@klass = klass
end


This change will impact the “path” parameter that is passed into the controller. Subsequently, the controller should be modified to take advantage of this change:


module Camping::Controllers
  class Static < R '/static/(.+)'
    MIME_TYPES = {'.css' => 'text/css', '.js' => 'text/javascript', '.jpg' => 'image/jpeg'}
    def get(path)
      @headers['Content-Type'] = MIME_TYPES[path[/\.\w+$/, 0]] || "text/plain"
      unless path.include? ".." # prevent directory traversal attacks
        @headers['X-Sendfile'] = path
      else
        @status = "403"
        "403 - Invalid path"
      end
    end
  end
end


As you may have guessed, this will break the contract with non-Win32 platforms, which is why I have not suggested this change to the Mongrel group. But, I hope you find it useful.

An exciting new release making headlines everywhere!

Curtis Mitchell is blogging now! Let the people rejoice!

Oh yeah…and in an apparent attempt to steal my thunder, Microsoft (Macrocompetitor) announced that they are releasing the .NET Framework source via a shared license for debugging purposes. This is great news, since I was just explaining to Mark that scripting languages are better for web sites (IMO) than compiled languages because you can follow each line of executed code.

Microsoft must have a psychic friend on speed dial. This is a big step in the right direction for them. Checkout the announcement from Scott.