I do find these [stats](http://blogs.computerworld.com/canalys_figures_in_iphone_clear_winner_in_north_america “Canalys figures in, iPhone clear winner in North America | Computerworld Blogs”) interesting, maybe a little unbelievable.
But mostly I am just testing skitch + TextMate blogging.
Everyone knows you can only call render once! But what if you need to call it twice! Voice of reason said, “calling it twice is bad, that’s why there is a **DoubleRender** exception.” And normally voice of reason would be right, but sometimes it is handy to call render twice.
In one of my side projects, I have some Javascript that is dynamically generated, but changes extremely infrequently. In this case, you would normally cache the output in a page cache. But I would rather serve the javascript from apache (or [nginx](http://nginx.net/ “nginx”) if ur c00l!). So, I just render it, write it to a file, clear the results and return to your regularly scheduled rendering, here is an excerpt of my code.
render :action => 'clientside_js' open(cache_file, "w") do |f| f.write response.body end erase_render_results # important! #back to normal process
**erase_render_results** tells rails to forget what has already be rendered. When I found this method, digging through the source code, I also saw the dreaded **nodoc**, which is pretty much as good as *use at your own risk*. **nodoc** indicates that it is not part of the public API. That being said, I am talking about something I found in Rails 2, which at the time of this writing is only a couple weeks old, I should be a millionaire by the time rails 3 comes out right!
Just to sum up the code block, it renders the js I want to cache, opens a file, writes the body of the rendered action to that file, the forgets that render. Simple and painless! Now I wait for someone to tell me how wrong this is.
About a week ago the core team made a [tag](http://dev.rubyonrails.org/browser/spinoffs/prototype/tags/rel_1-6-0-1?rev=8275 “/spinoffs/prototype/tags/rel_1-6-0-1 - Rails Trac - Trac”) for [prototypejs](http://www.prototypejs.org/ “Prototype JavaScript framework: Easy Ajax and DOM manipulation for dynamic web applications”) 1.6.0.1. It is a bug fix/consistency release. Two semi interesting fixes:
* [Change document.viewport.getDimensions to exclude scrollbars in all cases.](http://dev.rubyonrails.org/changeset/8266?new_path=spinoffs “Changeset 8266 for spinoffs - Rails Trac - Trac”)
* [Ensure that an Ajax.Request's parameters option can be a Hash.](http://dev.rubyonrails.org/changeset/8232?new_path=spinoffs “Changeset 8232 for spinoffs - Rails Trac - Trac”)
The first one fixes a bug that I ran into and the second one adds a little flexibility/consistency to the library.
you can get the code by:
#one line
svn co http://dev.rubyonrails.org/svn/rails/\
spinoffs/prototype/tags/rel_1-6-0-1
cd rel_1-6-0-1/
rake dist
ls dist/prototype.js
I might make a habit of documenting the edge changes to prototype, I haven’t really decided yet.
As you have most likely seen by now. Google put out a [charting api](http://code.google.com/apis/chart/ “Developer's Guide - Google Chart API - Google Code”)! It is crazy simple to use. There are two factors that will make this api an instant success.
1. It is entirely url based.
2. It has no api key.
These factors are important and work in conjunction with one another. It comes down to the fact that there is *almost* no risk for a web developer integrate with google charts. You never have to worry about your site getting too successful, there is a limit of **50,000** charts per day per IP. Since the IP that generates the chart belongs to your end user, your site’s IP won’t even generate 1 chart, thus no risk.
I messed around with the api for about an hour last night and found it easiest to make pie charts. But, I really like the fact that I can include a chart in my blog post without any plugins and very little effort.
And Here is the url broken up by data parts:
http://chart.apis.google.com/chart?cht=p3&
chd=t:45,22,18,2,8,5&
chs=400×200&
chl=Google|Ruby|JavaScript|SQL|HTML|CSS&
chtt=Nicholas’s+Language+Usage&
chco=ff0000,000000,00ff00,0000ff
Since forever, **action\_mailer** has been able to receiving incoming email. The [conventional wisdom](http://wiki.rubyonrails.org/rails/pages/HowToReceiveEmailsWithActionMailer) for realtime email handling is to jam an address into the aliases file, something like:
mailman: “|/path/to/app/script/runner Mailman.receive(STDIN.read)”
This is very easy to setup. Now when each message comes in it will call **Mailman.receive**. Unfortunately, this also starts a new ruby process each time. Not only that, but **script/runner** also loads the entire rails stack each time it gets called. Wow! As your project gets bigger and bigger this becomes more and more expensive. Suppose, you found acts as exactly what I need plugin, now you get the joy of deciding whether or not to use it, because it will be loaded each time a message comes in, SUCK.
Because of that factor I decided to move away from the script runner approach.
There are two ways to fix this problem. The easy way, and the right way. I chose the easy way for the time being.
mailman: “|/path/to/app/script/mail_process”
Instead of using **script/runner** I am using **script/mail\_process**, the difference is in the details. **mail\_process** doesn’t load the entire rails stack. Instead, it parses the message, then passes the important bits to a web service (mongrel), where the rails stack is already loaded. This approach is sometimes called a Service Oriented Architecture, although I think people were using this technique well before someone invented the term</digression>
Here is my actual implementation:
#!/usr/bin/env ruby
require ‘rubygems’
require ‘action_mailer’
mail = TMail::Mail.parse(STDIN.read)
mail.base64_decode
body = mail.body
respond_to = mail.from
url = “http://#{SOME_URL}?body=” +
CGI.escape(body) + “&respond_to=” +
CGI.escape(respond_to[0])
uri = URI.parse(url)
http = Net::HTTP.new(uri.host, uri.port)
http.read_timeout = 5
begin
res = http.get(uri.path + “?” + uri.query)
rescue Timeout::Error
#handle errors
rescue Exception => e
#handle errors
end
As I said this is the easy way, if I ever want to *really* scale this, I will have to go to a more reasonable approach. That approach involves replacing postfix as the mail transfer agent (mta) that processes incoming messages. A coworker pointed out [qpsmtpd](http://smtpd.develooper.com/ “qpsmtpd - Develooper LLC”) which is a perl based mta that allows you to write perl scripts that don’t fork (start up) a new perl process for each incoming message. I could then replace **mail\_process** with something very similar. But that day is quite a ways off for me.
