The first publicly availablelatest alpha version of Thin v0.6.1 (codename Cheesecake) is out. According to Marc-André Cournoyer, Thin's creator, it's the fastest Ruby server out there.
Here's the gist of it: you write web applications or make websites for a living. Eventually, your clients need to host them. This is an often overlooked opportunity for profit. Either they sign up with a host or, if they don't want to get their hands dirty, they let you handle it.
Either way, you're making money. Here's how:
Step 1
Sign up with a host like Site5, which offers an affiliate program. By the way, you can host your Ruby on Rails applications on Site5. So far, I've been extremely satisfied. There's also Dreamhost that offers 97$ per referral + 5$ per sub-referral (or a 10% of the referral's bill amounts + 5% of their sub-referrals). I haven't hosted any sites at Dreamhost so I can't vouch for the quality of their service, but I've heard that they're a good place to host. They support Ruby on Rails as well. I use 1and1 for sites that don't require Rails. They do a fine job of hosting PHP sites. 1and1 also offers affiliate rewards.
Step 2
Refer your clients, those who want to manage their own server, to that same hosting service. In the case of Site5, you get 85$ (or 97$) for each new customer you bring.
Step 3
Host your clients, those who don't want to bother with the details of a host. There's a few good reasons to do so.
First of all, you'll be the one doing future maintenances on the site or application. Second of all, since you actually have to babysit the website, you can charge a monthly fee for doing so. The amount is up to you, depending whether the client is high maintenance or not. This way, you end up actually billing for small tasks which are often touchy to bill (10 minutes here and there actually add up at the end of the year).
I suggest billing a fixed amount in advance (e.g.: 30$ per month, for hosting and babysitting). The amount is arbitrary and really depends on the situation at hand, but you get the idea
Step 4
Sit and wait for the money to come in. First of all, you'll be getting referral money, which will most likely cover your own personal and professional hosting expenses. Second of all, you'll be getting paid to host your other client's applications. First thing you know, you'll make some decent money.
You actually will end up doing some maintenance every now and then, but first thing you know, you will have a nice little revenue stream coming in, just for doing what you'd be doing anyways.
You're happy, and your clients are happy too.
In case you're wondering, my affiliates program revenue alone already covers all my hosting expenses, so basically, I'm making money while spending none.
It didn't take much time to implement, a few hours, most of the time spent fiddling with the layout to make it nice.
I initially made that site when I played World of Warcraft (I've quit since) but I still maintain it because it's quite popular with the community and it still gets a couple of thousand visits every day.
A somewhat interesting read, although the author fails to give any details regarding Rails' limitations (sic) and that the article is probably just a publicity stunt.
As you can guess, as entertaining as the article is, I disagree with most of it and think the author should go back to playing guitar.
So I went to the Montréal on Rails event tonight. Here's my thoughts on the three presented topics.
Mathieu Martin presented JRuby, which is basically, from what I understood, a Java implementation of the Ruby language.
From my perspective, this is a very interesting project for deploying Ruby on Rails applications like you would deploy a Java application. You package your app as a WAR file and, voilà, you can run it on any existing Java server infrastructure. This is a big plus for RoR, and will definitely help RoR's spread in corporate environments.
Also, JRuby lets you use your existing Java libraries from your Rails (or plain old Ruby) application. It also lets you use Ruby code in Java applications, which is nice, but not as useful as the other way around.
Alain Pilon made a quick, yet interesting presentation about the acts_as_state_machine Ruby plugin. The plugin does exactly what it says, it turns any Rails model into a state machine. The plugin seems to have some limitations (one state only) and some clunky behaviors (initial state not set when object is instantiated with new, can set the state directly, bypassing all callbacks and validations, etc.).
Seems to me that acts_as_state_machine was written for a specific project and then abandoned when it was deemed "good enough". It could be a good starting point for someone who would like to fix it and make it work as it should.
Finally Sylvain Carle presented Comatose, a non-intrusive way to put CMS functionality into a Rails application. I will definitely look into this as I actually need something like this for a personnal project.
[mm]:So I went to the Montréal on Rails event tonight. Here's my thoughts on the three presented topics.
[Mathieu Martin] presented JRuby, which is basically, from what I understood, a Java implementation of the Ruby language.
From my perspective, this is a very interesting project for deploying Ruby on Rails applications like you would deploy a Java application. You package your app as a WAR file and, voilà, you can run it on any existing Java server infrastructure. This is a big plus for RoR, and will definitely help RoR's spread in corporate environments.
Also, JRuby lets you use your existing Java libraries from your Rails (or plain old Ruby) application. It also lets you use Ruby code in Java applications, which is nice, but not as useful as the other way around.
Alain Pilon made a quick, yet interesting presentation about the acts_as_state_machine Ruby plugin. The plugin does exactly what it says, it turns any Rails model into a state machine. The plugin seems to have some limitations (one state only) and some clunky behaviors (initial state not set when object is instantiated with new, can set the state directly, bypassing all callbacks and validations, etc.).
Seems to me that [actsas_statemachine] was written by the author for a specific project and then abandoned when it was deemed "good enough". It could be a good starting point for someone who would like to fix it and make it work as it should.
Finally Sylvain Carle presented Comatose, a non-intrusive way to put CMS functionality into a Rails application. I will definitely look into this as I actually need something like this for a personnal project.
An interesting unconference, with doorprizes to boot!
Two Montréaler guys passionate about Rails just launched a service that is likely to become very popular. Ourbis is its name and it will make your life easier if you live in or around Montréal.
Ourbis is a simple to use business locator that uses the Google Maps API to let you find businesses geographically, using a very intuitive interface.
I looked around my neighborhood and quickly located some restaurants that I didn't even know existed. There seems to be around 115000 businesses in the system so you're bound to find what you're looking for!
Partials are an essential part of the Rails philosophy. They are a key component of the (Don't Repeat Yourself) DRY principle. A partial is a page fragment that you can reuse. It's an important of part of Rails's views.
Let's say you're writing an application (yes I will too use the blogging application to write this example). You're rendering a blog post and you want to print its comments (as a partial) as well. You'll probably do something like this:
<!-- In post.rhtml -->
<h1><%= h post.title %></h1>
<p><%= h post.body %></p>
<h2>Comments</h2>
<%= render: partial => 'comments', :collection => post.comments %>
<!-- _comment.rhtml -->
<h3><%= h comment.title %></h3>
<p><%= h comment.body =><p>
There you go, partials. Then, if you have another page that needs to display blog comments, you can re-use the post partial instead of re-writing that code. DRY FTW!
Now, what if you want to do the same thing using a .rxml template instead of a .rhtml template:
# In post.rxml
xml.post do
xml.title post.title
xml.body post.body
xml.comments do
render :partial => 'comments',
:collection => post.comments
end
end
# In _comment.rxml
xml.comment do
xml.title comment.title
xml.body comment. body
end
You would expect that to work, wouldn't you? Unfortunately, it doesn't. You won't get an error, but you won't get any output either; the section in your output document will be empty. How sad and unsatisfying!
The issue at hand is that - note that I'm not familiar with the template rendering's inner workings so let's pretend this is true - the xml object in the _comment.rxml partial has a different context than the xml object in the post.rxml file. It seems that Rails instanciates a new xml for every template it renders. In other words, your partial's output is not going where you're expecting it to go.
How to fix this? It's pretty simple actually. We need to tell the partial that we want it to use the same instance of xml. We do that by passing it the current instance of xml using render's :locals parameter and then by setting the value of xml by hand:
# In post.rxml
xml.post do
xml.title post.title
xml.body post.body
xml.comments do
render :partial => 'comments',
:collection => post.comments,
:locals => {:xml_instance => xml}
end
end
# In _comment.rxml
xml = xml_instance unless xml_instance.nil?
xml.comment do
xml.title comment.title
xml.body comment. body
end
That's it! One note, you need to use a different name (I used xml_instance in that example) because if you use xml like this:
render [...], :locals => {:xml => xml}
It won't work. I suspect that the auto-instanciated xml object has a different scope, which superceedes the assignment made by the :locals parameter. Again, I'm not familiar with how things work under the hood, but I think the :locals variable assignments don't work if a variable with the same name already exists in the current scope.
That's it, I hope that was useful, and please Dont Repeat Youself. Always use partials!
So yesterday, after upgrading Typo, I had this problem:
http://www.jponrails/blog/
would work but
http://www.jponrails/blog
wouldn't (400 Bad Request).
The problem is my blog runs with Mongrel FastCGI so in my public_html folder, I have a symbolic link that points to my application's public folder. Somehow, if you don't put the trailing slash, you get a 400 Bad Request error. I need to investigate this further, and I will as soon as I have some time.
I searched on the web for a mod_rewrite-based fix. All the fixes I found would work without the trailing slash, but they would break when you put the trailing slash! Not very useful...
That's until I found this blog entry on LavaFactory. That link I put is broken for some reason, so try clicking here and scrolling down a bit.
Here's the code I pasted in my public/.htaccess file:
The first one in the list, acts_as_taggable is super useful. It lets you add flickr-like - or del.icio.us-like if you prefer - tags to any ActiveRecord object. It works great and I've used it in a few projects.
Nice to see that the community is sharing useful code. That's the thing with the RoR community: people are proud of the nice code they write and want other people to see and use it.