Bhushan's Blog

कम्प्यूटर पर संदेश टंकित करें, नोकिया फोन से भेज

2007-09-03T22:36:00.000-07:00

भारतीय भाषाओं में एस एम एस भेजना एक दुष्कर कार्य प्रतीत होता है। पर कुछ सुविधाएँ हैं जिसका प्रयोग करके आप इसका भी मजा ले सकते हैं। यदि आप नोकिया का फोन प्रयोग करते हैं तो यह काफी हद तक संभव है।ज्यादातर फोन निर्माता फोन खरीदते समय एक सी डी देते हैं जिसमे आपके कम्प्यूटर के लिए एक साफ्टवेयर होता है। यह साफ्टवेयर आपके फोन पर संगीत, फोटो आदि भेजने के लिए प्रयुक्त किया जाता है। आमतौर पर, आप इस साफ्टवेयर की मदद से फोन और कम्प्यूटर पर आपके दोस्त-परिचितों के नम्बर भी सीधे स्थानांतरित कर सकेंगे। इसके लिए फोन और कम्प्यूटर एक तार के माध्यम से, अथवा ब्लू टूथ या इन्फ्रा रेड पोर्ट के द्वारा जोड़े जाते हैं। नोकिया भी एक ऐसा ही साफ्टवेयर सी डी पर देती है जिसे पी सी सूट कहते हैं। पर एक महत्वपूर्ण सुविधा के साथ- इस साफ्टवेयर के माध्यम से आप अपना एस एम एस संदेश पी सी पर ही टंकित कर सकते है।
साथ लगे चित्र को देखिए। मैने रमण भाई के युनिनागरी टंकन पटल पर अपने संदेश तैयार करके यहाँ चिपका दिया है। फिर यही से अपने दोस्त का नाम दिया, तो साफ्टवेयर ने उनका नम्बर मेरे फोन से स्वयं ही समझ लिया। फिर वहीं से प्रेषण का बटन दबा के संदेश को रवाना कर दिया। यह काफी आसान प्रक्रिया है।कुछ बातों का ध्यान रखना जरूरी है। नोकिया के ज्यादातर अच्छे फोन पी सी सूट समर्थित हैं। (मैं एक पिटा हुआ ६६१० प्रयोग करता हूँ)। पर अच्छा होगा यदि आप पी सी सूट का नया वर्जन नोकिया के अंतरस्थल (यहाँ) से लें। यह तकरीबन २५ एम बी का है। ये भी ध्यान रखें कि कभी-कभी अक्षर बिखर जाते है। यदि पाने वाले का फोन नोकिया नहीं है, तो सब कुछ कचरा हो जाता है। फिर भी, 'कुछ नहीं से बेहतर कुछ भी' वाली बात होती है। दूसरी बात, सदेंश शायद छोटे लगें, पर अंग्रेजी से ज्यादा बाइट्स लेते प्रतीत होते हैं। यह पी सी सूट बिना आज्ञा के ही इसे दो या अधिक टुकड़ो में बाँट देता है। यदि ऐसा हुआ, तो उतने एस एम एस के पैसे भी लगेंगे।कुल मिला कर मेरा अनुभव संतोषप्रद है, पर यह और अच्छा हो सकता है। खासकर जब कि पाने वाले के फोन के निर्माता (ब्राण्ड) की जानकारी का अभाव हो तो ऐसी अवस्था का क्या निवारण है। यदि आप के कुछ दुसरे अनुभव हैं, तो आप भी बाँटे।

DRY RAILS database.yml config file

2007-09-03T06:10:00.000-07:00

From http://blog.bleything.net/articles/2006/06/27/dry-out-your-database-yml:

login: &login
  adapter: mysql

  username: username
  password: password
  host: mysql.example.com

development:
  <<: *login
  database: app_dev

test:
  <<: *login
  database: app_test

production:

  <<: *login
  database: app_prod

Improved in_place_select_editor

2007-09-03T05:53:00.001-07:00

The in_place_select_editor method assumes that you want to display the exact item being edited. That isn't always the case. You might want to display a related attribute. The following modifies in_place_select_editor_field by allowing it to take a display parameter (third parameter), which is then passed to to_content_tag_display (also modified)

module ApplicationHelper

  def in_place_select_editor(field_id, options = {})

    function =  "new Ajax.InPlaceSelectEditor("
    function << "'#{field_id}', "

    function << "'#{url_for(options[:url])}'"
    function << (', ' + options_for_javascript(

       {
         'selectOptionsHTML' =>
                %('#{escape_javascript(options[:select_options].gsub(/\n/, ""))}')

       }
       )
    ) if options[:select_options]
    function << ')'

    javascript_tag(function)
  end


  def in_place_select_editor_field(object, method, display, tag_options = {}, 
                                   in_place_editor_options = {})

    tag = ::ActionView::Helpers::InstanceTag.new(object, method, self)

    tag_options = { :tag => "span", 
                    :id => "#{object}_#{method}_#{tag.object.id}_in_place_editor", 
                   :class => "in_place_editor_field"}.merge!(tag_options)

    in_place_editor_options[:url] = 
       in_place_editor_options[:url] || 
       url_for({ :action => "set_#{object}_#{method}", :id => tag.object.id })

    tag.to_content_tag_display(tag_options.delete(:tag), display, tag_options) +

    in_place_select_editor(tag_options[:id], in_place_editor_options)
  end

end

module ActionView
module Helpers

    class InstanceTag #:nodoc:
      include Helpers::TagHelper

      def to_content_tag_display(tag_name, display, options = {})

        content_tag(tag_name, display, options)
      end
      
    end 


end
end

This permits (example), where Job.vendor_name(@job) (a custom method) is displayed.

            <%= in_place_select_editor_field(
             :job,
             :vendor_id,
             Job.vendor_name(@job),
             {},
             :select_options => options_from_collection_for_select(@vendors, 'id', 'name', @job.vendor_id)) %>

you could also use this to display an icon to click on to display the drop-down box by passing an image_tag as the third parameter.

Time based expiration of cache fragments in Ruby on Rails (MemCacheStore and FileStore)

2007-09-03T05:46:00.000-07:00

This allows to expire cached fragments by ttl. Example usage (in views):

<% cache("name", :ttl => 7.days) do %>

  ... some database-heavy stuff ...
<% end %>

Put the following in environment.rb or in lib/.

class ActionController::Caching::Fragments::MemCacheStore
  def write(name, value, options=nil)

    if options.is_a?(Hash) && options.has_key?(:ttl)

      ttl = options[:ttl]
    else
      ttl = 0

    end
    @data.set(name, value, ttl)

  end
end

module ActionView::Helpers::CacheHelper
  def cache(name = {}, options = nil, &block)

    @controller.cache_erb_fragment(block, name, options)
  end

end

class ActionController::Caching::Fragments::UnthreadedFileStore
  def read(name, options = nil) 
    if options.is_a?(Hash) && options.has_key?(:ttl)

      ttl = options[:ttl]
    else
      ttl = 0

    end

    fn = real_file_path(name)

    # if cache expired act as if file doesn't exist

    return if ttl > 0 && File.exists?(fn) && (File.mtime(fn) < (Time.now - ttl))

    File.open(fn, 'rb') { |f| f.read } rescue nil

  end
end

RJS with toggle_slide if not visible only

2007-09-03T05:35:00.000-07:00

RJS is very powerful. here is a small code snippet that shows how to do a toggle on a div if NOT visible. If the div is visible, it just exchange it. Here is my rhtml code:

    <div style="height: 30px">
        <div style="float: left; padding: 0 0 0 180px">

            <%= link_to_remote("test_visibility" , 
                :with => "'is_visible=' + Element.visible('list_div')",
                :loading => "Element.show('getting_results')",

                :complete => "Element.hide('getting_results')",
                :failure => "alert('An error occured, please email us directly!')",

                :url => { :action => 'one_action' }) %>

        </div>
        <div id="getting_results" style="float: left; padding: 3px 0 0 30px; display: none;">
            <%= image_tag "ajax-loader.gif", :class => "image", :alt => "loading..." %>

        </div>
    </div>
    
    <div id="list_div" style="display: none;" >
    </div>

And in my controller, I have the following code:

def one_action

      render :update do | page |
        page.replace_html 'list_div', :partial => 'one_partial'

        if params['is_visible'] == 'false'
          page.visual_effect :toggle_slide, 'list_div', :duration => 2

        end       
      end
end

How it works?

Element.visible('list_div')

is a prototype function that returns false if the element is not visible and true if it is. In the above case, we have the orginial visibility of the div to be "display: none". Thus the first time the action is called, the Ajax call will send the parameter false to the action. This will make the div appear. For subsequent requests, the value of visibility will be true, thus only replacing the div.

.htaccess That Fixes The Trailing Slash Error

2007-09-03T05:31:00.001-07:00

// This .htaccess file is for use with a Rails application that is accessed by a symbolic link. This fixes an error in which the directory URL must have a trailing slash. Otherwise, the user receives a 400 Bad Request error.

Options +FollowSymLinks +ExecCGI

RewriteEngine On

RewriteCond %{SCRIPT_FILENAME}    -d
RewriteCond %{SCRIPT_FILENAME}      ^.*[^\/]$
RewriteRule ^(.*)$ $1/ [N]

#Put the directory your Rails app is in here.
RewriteBase /directory

RewriteRule ^$ index.html [QSA]

RewriteRule ^([^.]+)$ $1.html [QSA]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ dispatch.cgi?$1 [QSA,L]

Passing parameters into before filter

2007-09-03T05:26:00.000-07:00

application.rb

class ApplicationController < ActionController::Base
 
  def hello(name)

   "Hello #{name}"
  end

end

users_controllers.rb

class UsersController < ApplicationController

before_filter :only => :index do |u|
u.hello('Master')

end

end

SQL Transaction in Rails

2007-09-03T05:24:00.000-07:00

def fetch_value
sql = ActiveRecord::Base.connection();
sql.execute "SET autocommit=0";

sql.begin_db_transaction
id, value =
sql.execute("SELECT id, value FROM sometable WHERE used=0 LIMIT 1 FOR UPDATE").fetch_row;

sql.update "UPDATE sometable SET used=1 WHERE id=#{id}";
sql.commit_db_transaction

value;

end

Seesaw: An Improved Restart System for Mongrel

2007-09-03T05:21:00.002-07:00

Most Rails developers will be familiar with Zed Shaw's Mongrel, a great HTTP library used by most Rails developers to either test or deploy their applications (it's also pretty great for building your own basic HTTP handlers too, but I digress).

Sometimes when restarting applications after code updates, some requests can be "lost" in the whole process, particularly in high-traffic environments. Seesaw, developed by Max Muermann and Matt Allen, however, resolves this problem by restarting your mongrel processes one by one so that availability is ensured. Seesaw is available as a gem (gem install seesaw), although this blog post is essential reading to learn about integration with Nginx and Apache.

Javascript code to set Rails date_select to today.

2007-09-03T05:21:00.001-07:00

If you are using date_select in rails here is a little bit of javascript so that at the side of the fields the user can click a link that will automatically set the fields to todays date.

Updated: Now works on rails 1.2, as date_select now finally has ids

# put is app_root/public/javascript/application.jsfunction set_today(model, atrib){t3 = document.getElementById(model + '_' + atrib + '_3i');

var dt = new Date();t3.selectedIndex = dt.getDate();t2 = document.getElementById(model + '_' + atrib + '_2i')

t2.selectedIndex = dt.getMonth() + 1;t1 = document.getElementById(model + '_' + atrib + '_1i')

for (i = 0; i < t1.length; i++){

      if (t1.options[i].text == dt.getFullYear())     {

            t1.selectedIndex = i;     }

}}

To call this method say in a link use this in your rhtml

<a href="javascript: set_today('model_name', 'column_name');">today?</a>

Directory Listing in Ruby On Rail

2007-09-02T23:52:00.000-07:00

The code displays all the subdirectories and files listed in the the main directory, and also displays these items as a link so that the following subdirectories can become the directories and diaplay the corresponding elements

IN CONTROLLER
...............

DEF listing

   if (params[:dir] !=nil)
      @path   = params[:path]+"/"+params[:dir]

   else
      @path ="D:/Folder_name"
   end

      @dirEntries = Dir.entries(@path)

      @dirEntries.reject! { |filename| filename.starts_with? '.'}

end

IN VIEWS
.........
<%= javascript_include_tag :defaults %>  

<% for dir in @dirEntries %> 
<%= link_to "#{dir}", :action => 'listing', :path => @path, :dir => dir %><br/>

<% end %>

Silverlight (and Ruby on the .NET CLR)

2007-08-23T00:26:00.001-07:00

At MIX07 a few days ago, Microsoft announced "Silverlight", a new Flash-esque .NET-based platform for delivering "media experiences" and "rich interactive applications" on the Web. It's interesting, and some people seem to think it's going to revolutionize the Web, but that's not why we're interested in it at Ruby Inside.

The most interesting part of the Silverlight announcement is that it's based on a subset of the CLR (Common Language Runtime) from Microsoft's .NET platform. The .NET CLR has become a common target for programming language runtimes recently, but Microsoft has officially announced C#, Javascript, VB, Python and Ruby support for Silverlight's CLR. Microsoft are also adding new features in a system called the DLR (Dynamic Language Runtime) to bring more dynamic features (as required by Python and Ruby) to the CLR. InfoQ has more information on this, in terms of Ruby.

What all of this means is that there's baked-in support for Ruby in what could be one of the biggest runtime environments on the Web in the next few years, and this can only be a good thing for Ruby. Jon Udell sat down with John Lam (the creator of RubyCLR) and talked about the DLR, Ruby, and how the whole caboodle works / will work.

Let's cross our fingers and hope this isn't ActiveX all over again.

relative_time_helpers Plugin: time_ago_in_words on Steroids

2007-08-23T00:25:00.000-07:00

relative_time_helpers is a straightforward, but very useful Rails plugin by Rick Olson that formats timestamps to human-friendly relative dates. You're probably already using Rails' built-in time_ago_in_words helper in your applications, but Rick's relative_time gives even better results:

<%= relative_time(Time.now) %>
# today
<%= relative_time(1.day.ago) %>
# yesterday
<%= relative_time(1.day.from_now) %>
# tomorrow
<%= relative_time_span([Time.now, 5.days.from_now]) %>
# May 17th - 22nd

To install it:

script/plugin install http://ar-code.svn.engineyard.com/plugins/relative_time_helpers

Rails performance tip - using YSlow

2007-08-23T00:24:00.002-07:00

YSlow from Yahoo! is a Firefox add-on to analyse web pages and tell you why they’re slow based on rules for high performance web sites. YSlow requires the indispensable Firebug extension.

The 13 rules YSlow checks your site against are as follows:

1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags

This post will demonstrate that most of these are easily achievable for a Rails website through a combination of plugins and with correct configuration of a proxy web server (in front of a mongrel cluster) – in this case Nginx. This guide follows experience with improving performance for trawlr.com (an online RSS reader).

Make Fewer HTTP Requests, Minify JavaScript, Put CSS at the Top, Move Scripts to the Bottom, Remove Duplicate Scripts

The easiest way to make fewer HTTP requests is to combine all JavaScript and CSS files into one. The asset packager plugin does exactly this, plus it will also compress the source files (in production mode) and correctly handles caching (without query string parameters).

Moving CSS to the top (within the head section) and moving JavaScript to the bottom of the page are both manual tasks that should be done in the layout templates (such as app/views/layouts/application.rhtml). Remember to use stylesheet_link_merged :base and javascript_include_merged :base rather than the default Rails helpers.

By using asset packager you can also verify that scripts are only included once – another performance hit otherwise!

Excluding the Google analytics JavaScript file, trawlr.com now uses a single css and js file (including the entire prototype library). Note: You may need to add a missing semi-colon as per this defect for prototype to work correctly.

Asset Packager can be included as part of a Capistrano deployment with the following recipe:

desc "Compress JavaScript and CSS files using asset_packager" 
task :after_update_code, :roles => [:web] do
  run <<-EOF
    cd #{release_path} &&
    rake RAILS_ENV=production asset:packager:build_all
  EOF
end

Use a Content Delivery Network

Ignoring this point for now; I’d suggest the use of Amazon S3 as a useful starting point for simple CDN.

Add an Expires Header

A first-time visitor to your page may have to make several HTTP requests, but by using the Expires header you make those components cacheable. This avoids unnecessary HTTP requests on subsequent page views. Expires headers are most often used with images, but they should be used on all components including scripts, stylesheets, and Flash components.

Nginx allows adding arbitrary HTTP headers via the expire and add_header directives. Adding the expires header to static content is done with a regular expression looking for relevant file extensions in the request URL. This example uses the maximum expiry date but could be set to more appropriate values as required (e.g. 24h, 7d, 1M)

# Add expires header for static content
location ~* \.(js|css|jpg|jpeg|gif|png)$ {
  if (-f $request_filename) {
        expires      max;
    break; 
  }        
}

Gzip Components

Nginx can gzip any responses – including those proxied from a mongrel cluster.

gzip on;
gzip_min_length  1100;
gzip_buffers     4 8k;
gzip_proxied any;              
gzip_types  text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Avoid CSS Expressions

Just don’t do it!

Make JavaScript and CSS External

Add you JavaScript and CSS styles in external files rather than inline. The added benefit here is that the content will be merged and compressed thanks to the work already done above.

Reduce DNS Lookups, Avoid Redirects, Configure ETags

These weren’t an issue for me so I suggest the Yahoo! guidance for further information

Reduce DNS Lookups

Avoid Redirects

Configure ETags

Calendar Date Select: A Lightweight, Prototype-based Date/Time Picker for Rails Developers

2007-08-23T00:24:00.001-07:00

Calendar Date Select is a new(ish) "date and time picker", developed by Tim Harper, designed primarily for developers to use in Rails applications. It uses the standard Prototype JavaScript library, and is easily installed as a Rails plugin:

script/plugin install http://calendardateselect.googlecode.com/svn/tags/calendar_date_select

Take a look at the collection of demos of the picker to see its full range.

10 Great New Ruby / Rails Screencasts from July 2007

2007-08-23T00:23:00.002-07:00

Railscasts, maintained by Ryan Bates, continues to release one great free screencast after another, with 9 so far this month, although we're going to include one from June 29 for good measure. We first looked at Railscasts a few months ago, so if you haven't visited again since, it's worth it. Here are the latest screencasts:

Testing Without Fixtures - Fed up with using fixtures for your tests? Find a better way.

will_paginate - A look at the "new way" to do pagination in Rails using the will_paginate plugin.

Updating Through Checkboxes - How to perform actions on multiple items selected with checkboxes in a Rails view.

Handling Exceptions - Learn about exceptions and how to handle them in Rails apps.

The Logger - No, it's not about felling trees. Learn how to send messages to the log and how to customize it.

How to Make a Generator - A look at building your own generator, much like the ones that come with Rails.

Optimistic Locking - How to resolve situations when two people want to update the same record at the same time.

At the same time, Geoffrey Grosenbach, curator of PeepCode (and a new sponsor of Ruby Inside), has been storming ahead with his own set of screencasts, a few of which will be of direct interest to Rubyists / Rails developers:

rSpec Basics - A look at Behavior Driven Development. An ideal starting point if you haven't touched BDD yet but have been intrigued.

Rails From Scratch: Part I - A great up-to-date introductory "course" for getting into Rails. Even includes a free 20 page reference guide to Ruby and Rails, and an introduction to Ruby syntax. It's everything a new Rails developer needs.

Rails From Scratch: Part II - Another 80 minutes of great introductory material for new Rails developers.

While Railscasts' screencasts are totally free, Peepcode screencasts cost $9 each, but for the great packaging, length, and total depth of the material covered, they're still bargains!

How to Profile Your Rails Application and Make Rails Go Vroom!

2007-08-23T00:23:00.001-07:00

Charlie Savage, author of ruby-prof, recently baked in support for Rails to ruby-prof, so now it's possible to profile your Rails application, see where the delays are, and work on improving performance.

Hot on the heels of this development, Charlie wrote "How to Profile Your Application", an article that does just what it says on the tin, and which demonstrates how to profile the CPU time used on a single Rails request, and visualize the call tree.

This was quickly followed up with "Making Rails Go Vroom", another great article that looks at what parts of Rails significantly slow things down. Charlie comes up with six key suggestions:

Don't use ActiveRecord#attributes or ActiveRecord#read_attribute

Get your :includes right

Don't check template timestamps ( cache_template_loading = true)

Don't use url_for

Don't let Rails parse timestamps

Don't symbolize keys (local_assigns_support_string_keys = false)

Learn more and see how Charlie came to his conclusions in the article.

How To Scrape Google With Ruby In 0 Seconds

2007-08-23T00:22:00.000-07:00

Okay, his title is a bit misleading, but Peter Szinek, developer of Ruby scraping toolkit scRUBYt!, has put together a great article showing the process, from start to finish, of scraping Google results using Ruby "in no seconds". In reality, it'll take you at least sixty to read the post.

Framework Performance

2007-08-09T22:06:00.000-07:00

Original Source : http://wiki.rubyonrails.org/rails/pages/Framework+Performance

We recently decided to switch our projects (what were they to start with? Perl / CGI?) to a MVC framework and our choice of the framework came down to three final contenders:

* Symfony on PHP http://www.symfony-project.com/
* Rails on Ruby http://rubyonrails.org/
* Django on Python http://www.djangoproject.com/

To better understand the pros and cons of each, we wrote a very simple demo application in all three. The app we chose was the one built in the Ruby on Rails tutorial Rolling with Ruby on Rails http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html.

We really wanted to test the framework, not static file serving or database performance. So we didn’t come up with complex queries or serve any static CSS or image files. All requests/hits/transactions are rendered pages. Also, all of the tests are GET operations (database SELECTs) for concurrent testing fairness and simplicity.

Each of the tested pages was configured to have a unique number displayed on it based on microtime (to verify the pages weren’t being cached). Also, the same pages across all three apps were edited to have nearly the same number of bytes served.

DISCLAIMER: There are infinitely more test scenarios we could have performed. But we wanted something done in a finite time. We feel these results, though not the whole picture, offer hints about relative performance between the three frameworks/platforms.

Test Hardware:

* Dell 1U server (unknown model)
* Dual Xeon 3.2Ghz (6400 bogomips)
* 2 Gigs of RAM
* 2 240Gig (?) SATA drives

Test OS/Software:

* OS: SuSE 10.1
* kernel: 2.6.16.13-4-smp
* database: Mysql 5.0.18
* stress-test software: Siege 2.64 http://www.joedog.org/JoeDog/Siege
* Used stock RPM’s for all software unless noted below

Symfony setup:

* Apache 2.2.0 (mod_php)
* PHP 5.1.2
* APC 3.0.10 (PHP accelerator, compiled from source)
* Symfony 0.7.1587 (not an RPM)

Django setup:

* Apache 2.2.0 (mod_python)
* Python 2.4.2
* Django 0.95-3336 (not an RPM)

Rails setup:

* Apache 2.2.0 (mod_proxy_balancer)
* Ruby 1.8.4
* Rails 1.1.4 (not an RPM)
* Mongrel and lighttpd web server (not an RPM)

Apache Prefork tuning:

StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 150
MaxClients 150
MaxRequestsPerChild 10000

Results

For each of the platforms, we experimented a bit with some options to try to get the best performance by running 3-minute tests. Then we ran an extended 30-minute test on each platform. (Before the actual tests, we pre-ran siege for a minute or two to prime whatever cache’s, etc.) Here are some of the results:

Symfony – 50 concurrent users

With PHP+APC: (30 min)

Transactions: 85862 hits
Availability: 100.00 %
Elapsed time: 1801.15 secs
Data transferred: 114.41 MB
Response time: 1.04 secs
Transaction rate: 47.67 trans/sec
Throughput: 0.06 MB/sec
Concurrency: 49.63
Successful transactions: 85862
Failed transactions: 0
Longest transaction: 4.15
Shortest transaction: 0.02

Mysql: 7% of CPU
Siege: 5% of CPU

With APC disabled: (3 min)

Transactions: 2256 hits
Availability: 99.34 %
Elapsed time: 181.76 secs
Data transferred: 3.15 MB
Response time: 3.64 secs
Transaction rate: 12.41 trans/sec
Throughput: 0.02 MB/sec
Concurrency: 45.19
Successful transactions: 2256
Failed transactions: 15
Longest transaction: 30.57
Shortest transaction: 0.14

NOTE: NOT having a PHP accelerator yields about 12 trans/sec! Horrible! Rumor has it that APC will be included by default in PHP6. In the above tests, we also had syck (for YAML parsing). However it didn’t significantly change the results on a 3 minute test (less than 0.5 trans/sec).

Rails – 50 concurrent users

With 10 mongrels: (30 min)

Transactions: 158747 hits
Availability: 100.00 %
Elapsed time: 1800.82 secs
Data transferred: 211.38 MB
Response time: 0.57 secs
Transaction rate: 88.15 trans/sec
Throughput: 0.12 MB/sec
Concurrency: 49.89
Successful transactions: 158747
Failed transactions: 0
Longest transaction: 11.11
Shortest transaction: 0.00

Mysql: 10% of CPU
Siege: 10% of CPU

NOTE: In the test above Rails was configured with 10 stand-alone mongrel processes (production mode) and web requests were redirected through Apache using mod_proxy_balancer. In subsequent 3 minute tests, having 20 or 30 mongrels didn’t affect the transaction rate more than 0.5 trans/sec.

With lighttpd+fastcgi: (3 min)

Transactions: 15415 hits
Availability: 100.00 %
Elapsed time: 180.66 secs
Data transferred: 20.53 MB
Response time: 0.58 secs
Transaction rate: 85.33 trans/sec
Throughput: 0.11 MB/sec
Concurrency: 49.89
Successful transactions: 15415
Failed transactions: 0
Longest transaction: 1.25
Shortest transaction: 0.04

NOTE: The above test was run with the default lighttpd.conf, but on port 80 and in production mode. The number of trans/sec was about the same, but the longest transaction time was much smaller!

Django, 50 concurrent users

With mod_python: (30 min)

Transactions: 224588 hits
Availability: 100.00 %
Elapsed time: 1800.52 secs
Data transferred: 298.94 MB
Response time: 0.40 secs
Transaction rate: 124.74 trans/sec
Throughput: 0.17 MB/sec
Concurrency: 49.92
Successful transactions: 224576
Failed transactions: 0
Longest transaction: 9.31
Shortest transaction: 0.00

Mysql: 17% of CPU
Siege: 11% of CPU

NOTE: The above test was run with PythonAutoReload? Off and PythonDebug? Off (production mode). These are by far the best performance numbers of the three frameworks!

High-load Results

I re-ran 3-minute tests on all three platforms with 150 concurrent users to check high-load results.

Symfony – PHP+APC, 150 concurrent users

results

Transactions: 14363 hits
Availability: 98.68 %
Elapsed time: 183.12 secs
Data transferred: 3.72 MB
Response time: 1.34 secs
Transaction rate: 78.43 trans/sec
Throughput: 0.02 MB/sec
Concurrency: 105.06
Successful transactions: 122
Failed transactions: 192
Longest transaction: 30.67
Shortest transaction: 0.02

NOTE: You can see there were very few successful transactions. Most were “500 – Internal Server Errors” and 192 failed to connect altogether. It looks like the 500 errors were caused by something with Mysql, because the dev interface returned: “connect failed Native Error: Can’t connect to local MySQL server through socket ’/var/lib/mysql/mysql.sock”

Rails – 10 mongrels, 150 concurrent users

results

Transactions: 14718 hits
Availability: 100.00 %
Elapsed time: 180.61 secs
Data transferred: 20.22 MB
Response time: 1.79 secs
Transaction rate: 81.49 trans/sec
Throughput: 0.11 MB/sec
Concurrency: 146.12
Successful transactions: 14718
Failed transactions: 0
Longest transaction: 18.39
Shortest transaction: 0.00

NOTE: “Transaction rate” down, and “Longest trans” time is up (from 50 concurrent users), but no failed transactions.

NOTE: Attempting this test with lighttpd+fastcgi failed. The web server returned “500 – Internal Server Error”’s and absurd siege result numbers.

Django, 150 concurrent users

results

Transactions: 19903 hits
Availability: 100.00 %
Elapsed time: 180.78 secs
Data transferred: 26.73 MB
Response time: 1.35 secs
Transaction rate: 110.10 trans/sec
Throughput: 0.15 MB/sec
Concurrency: 148.32
Successful transactions: 19903
Failed transactions: 0
Longest transaction: 20.03
Shortest transaction: 0.01

NOTE: “Transaction rate” down, and “Longest trans” time is up (from 50 concurrent users), but no failed transactions. Still the top performer.

Summary

Rails performed much better than Symfony. And Django performed much better than Rails.

How to send SMTP mail in Ruby using ActionMailer (outside Rails)

2007-08-09T01:59:00.000-07:00

Like most bits of Rails, ActionMailer has an elegant and coder friendly interface. With a bit of set up, it's remarkably quick and easy to get running from vanilla Ruby outside of Rails.

Recently I've needed to bulk email a bunch of files to an internal server for testing purposes. I've used ActionMailer inside Rails in the past, and wondered how hard it would actually be to get it up and running standalone. Sure, there are a stack of other mail gems and libraries in Ruby to do this, but they expose a lot of the internals of STMP and can be a pain to use. Definitely overkill when all you want to do is quickly fire off some mails from a script. (ActionMailer is actually built on top of a lot of those libraries, and acts like a coder friendly wrapper).

My requirements were pretty simple: Iterate over a bunch of files, and attach each one to a separate email and send to some address.

Here's what the code looks like for the ActionMailer class:

require 'action_mailer'

ActionMailer::Base.smtp_settings =
{:address => 'smtp.example.com',

:domain  => 'example.com'}

class FileMailer < ActionMailer::Base

 def file(to, sender, file_name, content_type, strip_ext = true)

   # strip any directory fluff 
   subj = file_name.gsub(/.*\//,'')

   #remove the file extension if required
   subj = subj.gsub(/\.\w*/,'') if strip_ext

  
   #standard ActionMailer message setup
   recipients  to
   from        sender
   subject     subj

   #setting the body explicitly means we don't have to provide a separate template file
   body        ''
  
   #set up the attachment
   attachment  :content_type => content_type,

               :body         => File.read(file_name),
               :filename     => file_name.gsub(/.*\//,'')

 end
end

The only thing different from Rails, is that you need to explicitly configure the SMTP details via ActionMailer::Base#smtp_settings.

It's worth noting that you don't actually need to create a .rhtml view file if you specify the body attribute of your message. I ran into a few blogs claiming there was no way to turn off the .rhtml requirement - a quick inspection of the ActionMailer source code proves otherwise. I'm sure it violates good MVC design, but if you're just throwing together a quick script, who cares. I've left the body in the example as an empty string (the server at the other end was only interested in the attachement), but you can specify whatever string you want there.

To use the mailer class, you just call it in the normal Rails ActionMailer manner. With ActionMailer you don't call the mail action method you implemented, but a generated method prefixed with deliver_. So in our example, even though we implemented a method file, we actually call deliver_file (passing it the same parameters).

FileMailer.deliver_file('recipient@example.com','julian@example.com','my_file.csv','text/csv')

2007-08-06T03:48:00.000-07:00

Schedule cron job to take back up of database.

Step 1: Go to schedule cron job option on your server.
E.g. In textdrive go system>scheduled cron job

Step 2: Create on shell file to run command to take backup of database.

e. g. daily_backup.sh

Paste this commands in daily_backup.sh file.

#!/bin/sh

# This file will run a backup of your desired MySQL database and

# remove any backups older than 7 days.

#

# If you’d like to preserve backups for longer than a week, like say

# 2 weeks, then set the '-mtime' value from '+7' to '+14'.

#

# NOTE: Make sure to create a 'backups' folder in the root of your

# account and replace username, password, and database_name with

# the appropriate values.

/usr/local/bin/mysqldump --opt --skip-add-locks database_name --user=username --password=password > /users/home/username/backups/file_name_`date "+%Y-%m-%d"`.sql

cd /users/home/username/backups/

/usr/bin/find *.sql -mtime +7 –delete

Keep this file in /users/home/username/script/

Step 3: Select create a new scheduled cron job option.

Write in command field

/bin/sh /users/home/username/script/daily_backup.sh

Step 4: you can select option for when to execute select simple schedule and select daily option from drop down list.

Step 5: Save cron job.

How To pass Ruby Object to JavaScript function

2007-08-01T07:52:00.000-07:00

If you want to pass ruby object to javascript function then do the followin steps...

In Ruby Controller Action...
def sample
ruby_variable = "Something"
ruby_variable.to_json
end

In Ruby RJS File

page.call 'java_script_function_name', ruby_variable

In JavaScript
function java_script_function_name(java_script_variable){
alert(java_script_variable);
}

java_script_variable comes in the form of array of javascript.
Add comments if anyone wants