soledad penadés

repeat 4[fd 100 rt 90]

It's time to get serious with RoR! I finally decided that I would do some useful application to really learn how it works, and as I'm quite bored of doing applications for managing text (whether they are intranets, cms's, etc), I opted for recreating my old gallery script (which I did in php) in RoR. So I'm playing with images instead of just text.

This will give me the opportunity to test lots of extra functionalities of the framework, such as the famous integrated javascript effects, ajax, etc, as I want to improve my old gallery script, not simply redo it as it was in php.
So first thing I did was to make sure that I had a working updated version of ruby and rails. The best tutorial I have found which worked perfectly for me is this one: Building Ruby, Rails, LightTPD, and MySQL on Tiger, by Hivelogic. (Although I simply used it to update Ruby and Rails, but didn't build Lighttpd or Mysql).

With that I could be able to follow the recent tutorials and techniques, specially because I wanted to learn how to use a Login Generator, and there was something in the version of Ruby that I had which prevented me to install it (some lib error was thrown each time).

So my app has two parts, a public and an admin one (which was quite easy to anticipate). Once I managed to create the basic structure of controllers and models for the admin, I added the login functionality, as I don't want everybody to get into my app and modify pictures in there.

I used the Acts As Authenticated plugin, although I couldn't manage to get all the functionality that I expected so I took a look at the code of the Sudoku On Rails v5 tutorial at SobreRailes (sorry, spanish only!) and completed it with the missing functionality (basically, it was the activation stuff which was not generated, don't know why). It was sweet and smooth. If I had had to write it manually I would have spent at least three days.

Then I wanted to have support for uploading images. At all, this is about pictures! So after some researching I found a little plugin called FileColumn which allows to get picture uploads working quite quickly, including resizing and automatic deletion if the associated record gets deleted (no more orphan files in the filesystem because of a poor integration between the models and their associated data! hooray!). But for the resizing stuff and thumbnails generation, I needed to have RMagick installed in my system, which I didn't have. So I found a nice tutorial in the RMagick site, which explained how to compile and install RMagick and GraphicsMagick on mac os x, as well as all the libraries on which they depend, as RMagick is like a bridge between ruby and GraphicsMagick. This step took me a bit of time, specially the step of compiling ghostscript, but as I followed the instructions exactly as specified, I had everything working at the end and I could generate thumbnails and a resized version when uploading images. (Also I was also reading one of the supercool books about the tube that mr.doob gave me for my birthday so time flew fastly! :D )
If I had had to do this in php even using the best helpers that I could, I would have spent at least one week.

Then I prepared a draft version of the public interface. Now I can navigate between pictures and albums, using thumbnails and the big images as well, it shows the descriptions for the album or picture, where available. The code is so simple and beatiful that I could get it tattooed. Or maybe do a t-shirt with it, see an example for getting the data of one album:

def album
@album = Album.find(params[:id])
unless @album.nil?
@pictures = @album.pictures
end
end

No more embedded SQL in the middle of the code, no need for manually loading classes which abstract the DB information for the rest of the php code and try to provide a way of artificial modelization of the data, no need to spend time reinventing the wheel!! :D

As I specified in the models that one album has pictures (has_many : pictures), and that each picture belongs to one album (belongs_to :album), RoR is intelligent enough to deduct things from the database and save me that precious time (as it sees an album_id column in a picture row… it obviously is pointing to an album row!).

Unfortunately by the moment the front end is extremely basic, it's pure html with little css applied to it. In the next iteration I will do tasks such as find out how to redefine part of the behaviour of the FileColumn to make it update the associated images too if I upload another image when editing a picture, beautify the front end, and maybe start with those nice ajax capabilities which are supposedly quite easy to use with RoR. It will also be nice to learn how to do the fantastic unit tests with the support that this framework provides, so all in all this promises to be very exciting.

Conclussion: I absolutely love Ruby on Rails.

Stay tuned for a next release - as I already got a port for installing it on my host, it can be whenever I get a decent working version!.

UPDATE: As some people want to take a look (miguev ;) ) I have uploaded the relevant code of the current version. It just has the important things i.e. the models definition, etc. If you want to have a working application you will need to create it first with the usual rails name_of_your_app, configure the database, etc, and then use this code where appropiate. It won't work by itself :P This is just for showing how things are linked between them: cl1ck version 0.1

I have been a bit disconnected from the Flash scene for a while and it's changed quite a lot! So I thought I may share with you my discoverings while I'm getting updated on the latest news.

There's this new thing called Flex. From what I understand, it will allow you to build entire interactive applications which run both on server and client side, using Flash for the interface.

Roughly, the interesting part here is that not all the processing is ran in the server, but also the client's computer is used to run the application. So, things such as updating graphs are made in the client side, with the data that the server sends you, allowing the server to save processing power and bandwidth.

The interface is specified with an XML based language and the application logic is written with ActionScript2; you can do it with the official Flex editor (even in WYSIWYG mode) or with your favourite IDE with custom XML language schemas support (one example: Eclipse). Then, you drop your code in the Flex server, and it will serve the appropiate interface data to the client depending on their actions.

This concept reminds me a lot to the first .net demonstrations I saw: you write code once and it will be served to the user through the .net server, which will determine the appropiate html and javascript stuff to be sent to the clients depending on their browser capabilities. The problem were the browsers' implementations and their support of javascript. Each time I asked the speakers about this, they never knew what to reply. Such an embarrassing question…

In that, Flex has already won the battle. As it uses the flash player to run in the client, they can guarantee a more or less known scenario and then the developers can build an application knowing for sure that it will always work, and there won't be weird implementations of one javascript method on certain browsers, etc.

It also reminds me to the AJAX approach: do not reload the whole page, send only the useful data, and redraw whatever is needed on the client side. The weak points of AJAX are still the different browsers' implementations, and rich media inabilities: graphics would be great, if all browsers implemented SVG properly. And unfortunately, browsers are unable to play sounds just by using html/javascript: as far as I know, when someone needs to play a sound nowadays, they end using a Flash object to play it (and yes, I'm ignoring the MIDI at all).

The advantage of AJAX versus Flex is that you don't need all the human and technical infrastructure that a Flex server requires. It is way cheaper to start building things with the Ajax philosophy (see ruby on rails), and honestly, most of the applications don't really need to have fancy 3d realtime graphics with motion blur and stereo surround sound.

Conclussion? Flex looks promising but it has its own application field, which can fulfill very appropiately. For relatively low-demanding requirements applications, there are other solutions which can work (and are working, indeed) pretty well.

Of course I might have misunderstood something. If there's something you feel is wrong please do not hesitate to leave a comment and I'll correct it.

Extra final bonus

Finally, if you are really curious and want to know some hidden and technical details about how the flash player is implemented -which is what at the end is going to affect everybody: you and your users- take a look at kaourantin.net. That's the blog of one of the engineers at Macromedia/Adobe developing the Flash player. He will get you informed about the changes they make and, from time to time, those little secrets that might explain certain flash oddities.

A bit not too useful at first sight but proves how powerful can be an ajax powered search engine. As I understand, this looks for the query string you give, related to the url's you provide, and then returns you a number of ego points. For example, this is the result of searching for Soledad Penades and www.soledadpenades.com. Of course, the most ego points you have, the more your ego grows (or the more pages are linking to your pages, in other words).

And it has a very nice implementation… works fabulously with Safari (which is not quite often with most of the ajax applications I have seen to date).

Have a try! Ego surf!

(Found via ajaxian)