(Nov 1)
I received email from Deb Woods of Ingres this morning telling me that the Ingres C/Ruby driver and the Rails ActiveRecord adapter I wrote have both been made available.
Here's some more information in a blog posting and here's the actual page.
Hopefully they've made some improvements to my code in the last year or so. This was my first 'real' Ruby and Rails project, so I suspect the code has improved a bit since I sent it to Ingres. :) If memory serves, the code should all be under the GPL (but don't hold me to that... it's been a while.)
Category: Rails
(Sep 10)
I love the title, but I love the concept even better. How will putting money behind a web vote affect your ranking? Matt Bass, Nathaniel Talbot, and Mark Bennett (as team Raleigh.Rb) think it will matter a lot. Of course, the app uses 'play money' right now, but concept is very interesting.
Link Tipping
This was done as a part of the Rails Rumble project.
To quote Matt, "It's amazing what can be done in just two days with a productive stack like Rails."
There are a ton of cool apps in the competition. Be sure to drop in and vote! You're vote could tip the scales in someone's favor! (groan!) Voting starts on Wednesday I'm told.
Category: Rails
(Aug 28)
Your first step to application tuning should always be to measure, then tune. Start with the application, then work your way down.
But when you do start moving down to tune your Rails stack, how do you proceed? This write up does a pretty good job of showing you some great options.
Testing Various Configurations of Rails, Merb, Swiftiply, and Nginx
From memcached to Nginx to evented mogrels, there are some good bits in here. I'm not sure I'm ready to rewrite my Rails app in Merb... but if you don't learn a bit about it, you'll never know if it suits your next app.
Btw, memcached isn't a Ruby/Rails only technology. Check it out for your Java/PHP/etc app as well.
Category: Rails
(Jul 26)
I've changed the slides enough that I wanted to be sure everyone who wanted them could get the latest version. I normally go for a lightweight, zen-esque approach in my slides, so that unless you come to the talk, you can't just read the slides and get the good stuff. But if you've heard the talk, the slides make great sense.
For this talk, I went the other way... everything is in the slides... I'll try to do an HTML export of them if anyone wants one, but here's the Power Point file.
Use C to Tune Your Rails Application
It's very much an introductory talk, so if you're looking for advanced content, I'd suggest you go straight to the Older, free version of the Pickaxe book, buy the Pickaxe, second edition, and visit How to Profile Your Rails Application and Make Rails Go Vroom!.
Category: Rails
(Jul 12)
I saw this today and had to pass it on. Apparently Rails can handle a Slashdotting just fine. Like any other web technology, you can create scalable applications, or not. As long as you make reasonable technology choices, it's up to you and your architecture to scale.
Rails, Slashdotted: no problem
Everyone tells me that Rails is supposed to be slow, but I keep running into examples of how well it scales. I've had a few client engagements recently where I thought Rails would need help to handle the load and it's pleasantly surprised me out of the box.
So if you "know" Rails doesn't scale, do you know this because you tried it out or just heard about it? People mention Twitter, but remember that Twitter had issues at 11,000 hits per second. (Do the math... do you need 11,000 hits per second?) And their issue (a single database behind Rails) has been fixed. (This page has a good summary with links).
I'm just saying, don't discount the performance of Rails until you've tried it out yourself. I'm finding more and more that Rails scales just fine.
Category: Rails
(Jul 10)
I'm giving a talk at OSCON on extending your Rails application with C and I thought I'd blog on a few gotchas as I work on the demo application and publish my preliminary "benchmark". (Don't get upset... it's not really a benchmark.)
I'm going to use two technologies for my C integration. RubyInline is used for dropping C in line to your Ruby code, hence the clever name. It's really easy to use and has very good docs.
The other technology is the plain old Ruby C Extensions. This is also very easy to use.
RubyInline compiles the C code on your first pass and then reuses the compiled code. Putting that file in a controller that you reload with every client visit really messes it up. This reload is done in development mode, not production mode.
So you have two options, the first is to run your Rails app server in production mode. For Mongrel, try "mongrel_rails start -d -e production"
The other option is to put your Ruby class containing your C code in a location that isn't reloaded every time. I used the lib folder. On the other hand, this really slows down your Rails debugging. You have to restart your Rails app server between edits to the C code. It's almost like having to compile everything! ;) It'll drive you nuts.
Thanks to this Ruby mailing list thread for the answer to that problem.
Another issue to be aware of is that RubyInline seems to want your C code inside of double quotes. That's not a problem until you want to have a double quote in your C code. A printf perhaps? Just use the %Q{ Put your string in here} notation. That will quote anything within the brackets. Put all your C code within the brackets and you'll be fine.
Finally, when you do something like a factorial example, don't let the results get too big. Your C code will silently overflow and return a zero to you, making you think you've got a simple error in your C code. :) Just keep the results reasonable and you'll be fine. For the record, factorial of 500 isn't reasonable.
While RubyInline is easier to get started with, I think regular C extensions are easier to use. But something to remember... if you've been coding and developing with C extensions in a shell, you may have just been doing "make", and that works fine for that directory. But not for Rails. Don't forget that the rest of the system can't see your code until you do a "make install".
For my demo, I'm just using a boring, non-realistic factorial example. And I'm having to run it 50,000 times in a row to slow it down enough to have meaningful differences in the times. And that's on a laptop.
Raw ruby calculates factorial twelve 50,000 times in 0.53336 seconds, or just under 2 reqs/sec. That's within a Rails controller.
Using RubyInline, it takes 0.04724 seconds or 21 reqs/sec. Ten times faster.
C Extensions runs the same code in 0.02681 seconds or (37 reqs/sec). Almost twenty times faster.
I did notice that for larger factorial values, the time difference between RubyInline and C Extensions seemed to shrink significantly, so there must be some startup time involved... But the message is clear.
Write your application with all the speed of development that Rails can give you. Get it running, then bench it. If you need more speed than the runtime can provide, you can always drop back to doing the processor intensive work in C, giving you the best of both worlds.
Should you plan on using C in your next Rails application? No way. I'd bet that more than 99% of applications don't need that much performance. But if you do, it's nice to know it's available.
Category: Rails
(Jun 10)
I recently heard about Nginx. It's a web server with a great track record in Russia that's starting to spread out to the rest of the world. According to a recent podcast I heard, Zed seems to be using it with his production Rails apps, which is always a good sign. At RailsConf I got to eat with Adam Keys and his enthusiasm for it's speed, ease of configuration, and stability caught my attention.
The greatest attraction for me is the ease of configuration. I've wrestled with Apache conf files on and off though the years, but I've never felt like I really "got it". Apache can do nearly anything, but you've got to really invest the time to become an Apache specialist to do anything useful with it. And I never really felt the motivation to become an Apache specialist.
When I set up this web site, I tried to get my Mongrel cluster up and running with Apache but couldn't get it working. So I gave up and dropped back to Pound and Mongrel. Pound load balanced and Mongrel served everything, including the html, Javascripts, CSS, and graphics. A complete reload of the main page took about 30 seconds. Nearly all the time was spent loading graphics, two at a time. And once the browser had the graphics cached, it ran great.
But today I switched to Nginx and a clean reload is taking me 8 seconds. Granted, Mongrel wasn't designed to serve your static content, but wow... that's an improvement!
Here are some Nginx links to get you started.
And here's my configuration file:
worker_processes 2;
events {
worker_connections 1024;
}
http {
include conf/mime.types;
default_type application/octet-stream;
upstream mongrel {
server 127.0.0.1:7000;
server 127.0.0.1:7001;
server 127.0.0.1:7002;
server 127.0.0.1:7003;
}
log_format main '$remote_addr - $remote_user [$time_local] $request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
sendfile on;
server {
listen 80;
root /usr/local/nginx/html;
access_log /usr/local/nginx/logs/access.log main;
rewrite_log on;
location ~ ^/$ {
if (-f /index.html){
rewrite (.*) /index.html last;
}
proxy_pass http://mongrel;
}
location / {
if (!-f $request_filename.html) {
proxy_pass http://mongrel;
}
}
location ~ .html {
root /usr/local/nginx/html;
}
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar
|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov)$ {
root /usr/local/nginx/html;
}
}
}
Update: Apparently this call request.host_with_port gets confused when Nginex proxies for Mongrel. If you're reading this via the RSS feed, then you probably noticed that all my URLs were wrong for a few hours. It's fixed now. I should wrap that with a test!
Category: Rails
(May 30)
I've had this problem repeatedly with RJS, and I'm not saying it's not something that I'm doing... in fact, if I had to take a bet on whether the problem is in my code or the RJS code, I'd bet it's my code. :)
Never the less, I've seen several pages online where this has been an issue for other people and it keeps coming back to haunt me, so here's my fix.
When you're using RJS to do JavaScript magic and you add something simple like
page.replace "main", :partial => "update_student"
and the JavaScript just shows up on the page you're trying to update, then you've found this issue. You see something like this in the browser:
try {
Element.replace("main", "\r\n \r\n Your updates have been recorded\r\n \r\n ");
} catch (e) { alert('RJS error:\n\n' + e.toString()); alert('Element.replace(\"main\", \"\\r\\n \\r\\n Your updates have been recorded\\r\\n \\r\\n \");'); throw e }
The problem is that the RJS libraries didn't include the SCRIPT tag. I think it gets confused and thinks the tag is already in place.
The fix is pretty simple... add the SCRIPT tag. In RJS you can always add raw JavaScript to the page with the << operator. So I changed the RJS template above to read like this:
page << ' <SCRIPT type="text/javascript">'
page.replace "main", :partial => "update_student"
page << ' </SCRIPT>'
And it all works the way I think it should... which is to say, maybe not quite the way the authors intended for it to be used, but it seems to be working for me so far....
So, if you're using RJS and the JavaScript shows up on the page, just add an opening and closing set of SCRIPT tags before and after the RJS call in question.
Category: Rails
(May 24)
This quote "Isolation Kills Innovation" is on the Pragmatic Programmer's community page. And it's true. When we spend all of our time heads down doing any type of work, we lose our sense of perspective, we lose the new ideas. We tend to get stuck in ruts. The old saying "Can't see the forest for the trees" can be applied here.
So what if interaction is harder to come by? What if your company doesn't let you go to conferences? Maybe you don't have active user groups in your area. What are your options? As a consultant who generally works on project at home, this is real concern for me. Last week at RailsConf I realized how much I'd been missing that interaction. (I do have a great local Ruby user's group, but I'm talking about every day interactions.)
Sitting in sessions all day long about Ruby and Rails, sharing a room with Glenn Vanderburg and talking about Ruby and Rails each evening... basically immersing in the Rails experience was awesome. Hearing how people are solving problems really gets my creative juices flowing.
One of the topics I heard about was The Rails Podcast. And wow... I pulled down a few selected entries and listened to them driving around town, filling my "down time". And I've got to say, it's great. I just went back and downloaded the entire catalog!
Listening to Zed talk about how he's using Mongrel and Nginx gives me ideas on how I can do the same. If you're a Rails developers, I'd strongly encourage you to check out this site.
(Someone send me a Java equivalent or two so I can post it too!)
But whatever your language, get out of the house, literally or with blogs, podcasts, and articles. But get those new ideas in your head, mix them in, and see what ideas float to the surface.
Isolation does kill innovation. Don't stagnate.
Category: Rails
(May 21)
Dave Thomas had a bit of fun in his RailsConf closing keynote. :) He was spoofing the Ruby Chicks site I think...
Ruby Middle Aged White Guys.
Middle age has come earlier than I thought it would!
Category: Rails
|