This purpose of this blog is to document my learning process with Ruby on Rails. Everyone has seen the videos that make Ruby on Rails look unbelievably easy. Even more have seen the amazing applications that are practically the gold standard of “Web 2.0″. That’s all great for the people who invented the Rails framework but what about a normal day-to-day web developer deeply entrenched in the world of PHP or Java. How easy is it for someone like me to learn Ruby on Rails? Let’s find out.

www.gamesradar.com

The site has been online for a couple of weeks now. However, there are of course some problems with it as is the case with any new launch.

My contributions to the site include most of the back-end programming for the movie player, screenshot viewer, account registration system, and any cheat/strategy related pages.

Download Weblogic 9 for “Red Hat Enterprise Linux (3.0, 4.0, x86)”
http://commerce.bea.com/showproduct.jsp?family=WLS&major=9.0&minor=0

Install on a Linux Machine
Find an available Linux machine on your network and install Weblogic on it. Yes, it really helps to have a Red Hat box lying around for this step as you can’t run the binary installer on your OS X machine.

Copy Installation to Local Machine
Using whatever means you have at your disposal copy the Weblogic installation directory from the Linux server to your OS X machine. You can put it anywhere you want on your OS X machine. I put mine at /usr/local/bea.

Remove Installed JVMs
cd $BEA_HOME
rm -fr jdk150_03
rm -fr jrockit90_150_03

Create Symbolic Link for Apple JVM
cd $BEA_HOME
ln -s /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home jdk150_02

Edit Config Files
Edit the following two configuration files and replace all references to the installed JVM to the Apple JVM.
bea/registry.xml
bea/weblogic90/common/bin/commEnv.sh

Carry On With Business as Usual
That’s it. From here on out you can treat this installation as any other UNIX-based Weblogic installation.

Now if we can get the idiotic web developers at Blockbuster.com to make their site fully compatible with non-IE browsers I’ll be happy. Get a clue Blockbuster! IE-only websites are, thankfully, a thing of the past. Standards rule. Use them. Seriously, you’re one of the last holdouts. And what’s with making us listen to a stupid sound clip every time we load your home page. Any web developer with half a clue figured out many years ago that unrequested sound on a web page is extremely annoying! It’s 2005. Why are you doing this now?

Now that I know a little bit about Flash you should consider me extremely dangerous.

This one show how to display a pop-up window while a file is uploading as part of a form submission. It doesn’t actually measure the percentage of the file that has been transferred as the file is uploading. It just displays a window while the upload is happening and closes the window when the upload is finished. For forms that handle large file uploads this can give the user a little more piece of mind than than seeing “frozen” browser while the upload takes place.

What would be really cool is if at some point in the future web browsers provided a mechanism where we can query the progress of a form submission via JavaScript. Then it would be possible to develop a true progress indicator for file uploads.

Manipulating Tables with DOM in Javascript

This is a proof-of-concept example I did for myself before integrating it in with its intended application. The intention is that a managing editor for a magazine would use something like this to define a layout for a page containing multiple pieces of content. Sometimes a page will have an ad on one third of a page and editorial on the remaining two thirds. Other times they will squeeze reviews for two or three products on one page. With this they can define reusable templates for use in our flat plan application, which is currently in development. A flat plan is kind of like a storyboard for a magazine where all the pages and what goes on them is laid out in neat little rows.

Implementing this functionally entirely with JavaScript was quite a challenge for me and I was almost ready to throw in the towel when I remembered Mozilla ships with a DOM Inspector. This turned out to be an essential debugging tool!

This code only works in Mozilla and Netscape 6+. IE 6.x and the Safari beta can’t handle a dynamically changing table structure.

So I’m starting my own JavaScript Examples page. Sure, right now there’s only two items but I expect this will increase as I do more research for my current big project which will include a more than average amount of JavaScript and DHTML.

I posted the Date Chooser example last summer. Nothing new there. This morning I added the Rewritting HTML example. This comes in handy if you ever need to update a piece of content on a page without sending a request to the server and reloading the whole page. Of course you have to know (or be able to calculate on the client) all possible values for the content you want to change. That’s not always feasible but in the cases where it is I think this greatly enhances the user experience. If used right this can add lightning fast response times to web applications which generally rely on the slow request/response interaction with a server.

I’m currently setting up a Red Hat Linux box at work that will serve as our main development server. Something I would like to be able to do with this new server is give each developer their own web space. This way each developer can checkout of copy of our code base from CVS into their own web space and work with it there. When they’re finished with a certain task they check their code back into the CVS repository. Periodically, I will update the code in our testing area and see if everything looks good. If it does, then I’ll sync the code to our production server. Of course, right now there is only one developer (me) but we do occasionally contract with a developer in Australia so having personal working areas is definitely beneficial.

I figured the easiest way to give users their own web spaces is to use Apache’s UserDir directive. The way it works is this. Each user on the server has a ‘home’ directory where they store all of their files. If you create a directory within your home directory called ‘public_html’ then anything within that directory will be available on the web. You generally use a URL like ‘www.server.com/~user’ to view the pages in someone’s public_html directory.

That sounds simple enough. The problem is that Apache (the web server) can be very picky about the permissions on the public_html directory and the user and group that the Apache process runs as. This is not really a bad thing as security is very important. I would just have to set the permissions on public_html right. However, I kept getting “Forbidden” messages when trying to access anything in my public_html directory. I tried all different combinations of permissions and users and found that even if the public_html had full read and write permissions the only way I could view web pages in my public_html directory was to run Apache as my own userid. Not a solution at all. Even if I changed the owership of the public_html directory to another user and ran Apache as that user I would still be “Forbidden”. Which got me thinking. Maybe it has something to do with the permissions on my home directory itself. I assumed the permissions on the public_html directory would be only thing that really mattered but maybe there was more to it.

So I checked out the permissions on my home directory. It turns out default permissions on home directories in Red Hat 8.0 are pretty darn tight. Only the owner can view files. Nobody else can do anything at all. So, after a couple of changes to the it worked. Apparently, Apache looks at the permissions on the home directory before doing anything with the public_html directory. I wish it had been documented a little better but at least now I know.

In case you don’t know, XML is an emerging technology that is getting a lot of attention these days. XML and it’s related technologies provide for a way to store and manipulate structured data in text format. XSLT deals with the “manipulate” part and this is what I’ve been learning about this week.

A while ago I was asked to put together a web-based photo album application for our marketing department. I started thinking about whether using XML would be appropriate for the project. I pulled together some images and text for a few sample photo albums and started researching various XML related technologies that could be of use. I eventually settled on using XSLT to produce the output for the photo albums with Xalan-C++ being my XSLT processor. After learning the ins and outs of the XSLT language I ended up with a style sheet that produces decent looking output.

See my XSLT Examples page for the results.

XSLT kind of reminds me of the tag-based directives used by Informix’s WebBlade product from a few years ago. I hated that crap and apparently enough other people also hated it because Informix has ceased to exist as an independent company. XSLT is much better than the WebBlade tags but there are a couple of things I find troubling.

First, variables aren’t exactly variable. Once you’ve assigned a value to a variable you can’t change it! Why didn’t they call them constants instead? On the other hand “params” can change value but only when being passed to another template. This forces many applications (my photo album style sheet included) to use recursion to keep track of “counter variables”. I’m not a big fan of recursion because it’s difficult to understand and the same effect can usually be accomplished through the use of loops. Clever recursive code is almost always a headache to maintain.

But XML and it’s related technologies are still in their infancy so I think we can expect to see many improvements over the coming years.

So… ya. That’s what I’ve been working on this week. The coming weeks will see me writing the PHP code to generate the source XML. Then we’ll have the beginnings of a serious web-based photo album application.