Netbeans add ruby platform


Install RVM and Ruby version what ever you want .

Once you done with ruby installation,
From terminal type below command..

$rvm use 1.9.1
$cd /home/alan/programs/netbeans_6_8/bin ***or wherever your netbeans is installed
$./netbeans

I hope, it will help.
For details visit http://www.skorks.com/2010/01/using-multiple-rubies-seamlessly-on-the-one-machine-with-rvm/comment-page-1/#comment-3422

Cheers

 

Advertisements

Heroku vs Engine Yard


#1 “Ease of Use”
Heroku blows Engine Yard away. you install the gem and can deploy your application in minutes. There are also commands you can run on your local machine to get information about your application.
Engine Yard is moving forward, but it is still pretty technical. It’s really easy if you have a public github repo, but anything other than that starts to get “more complicated” quickly.

#2 “Architecture”
Engine Yard gives you a “real” virtual machine. This means you’ve actually got a single CPU virutal host that you ssh into and effectively do whatever you want.
Heroku gives you a sandbox with walls around it, and I think it’s a shared environment. It’s actually kinda difficult to figure out exactly what they’re running as you cannot log onto the machine direction.

#3 “Startup Price”
Heroku gives you a free (as in beer) environment.
Engine Yard let’s you run a trial environment for free for a period of time, but you eventually have to pay for it… even if nobody ever visits your site.

#4 “Flexibility”
Heroku lets you do anything you want as long as they’ve preconfigured it to enable you to be able to do it. 
Engine Yard gives you ssh capability to the machine, which means you can do anytChing you want even if they didn’t think it would be a good idea. 

Overall, I’d say Heroku is like taking the bus: if enough people want to go the same place at the same time, it’s more economical. Engine Yard is like buying a car: it’s going to be a bit more expensive and you’re going to need to know how to drive, but it is a much more flexible solution.

Cheers

Rails Observer


What is observer?

Observer serves as a connection point between models and some other subsystem whose functionality is used by some of other classes, such as email notification. It is loose coupling in contract with model callback.

When should we use?

If your model code gets too messy start to think about using observers for some unessential behavior. The real power (at least as I see it) of observers lies in their ability to serve as a connection point between your models and some other subsystem whose functionality is used by all (or some) of the other classes. Let’s say you decide to add an IM notification to your application – say you want to be notified about some (or all) of the CRUD actions of some (or all) of the models in your system. In this case using observers would be ideal – your notification subsystem will stay perfectly separated from your business logic and your models won’t be cluttered with behavior which is not of their business. Another good use case for observers would be an auditing subsystem.

Observer

$rails g observer EmailNotification

class EmailNotificationObserver < ActiveRecord::Observer
  observe :order, :address
 
  def after_create(model)    
      if model.class.name == “Order”
        Notifier.order_created.deliver
    else
        Notifier.address_created.deliver    
    end    
  end
end

Notifier Model:

class Notifier < ActionMailer::Base

    #layout “notifier”    
    
  default from: “test12@gmail.com”
 
  def order_created
    mail(:to => ‘mpravin@gmail.com’, :subject => “Order”) do |format|
        format.html {render :layout => ‘notifier’}        
    end
  end
 
  def address_created
    mail(:to => ‘mpravin@gmail.com‘, :subject => “Address”)    
  end
 
end

Cheers!

Amazon S3 Library for Ruby


1. Install amazon s3 gem.

$gem install aws-s3

2. Connect with S3.

require 'aws/s3'

AWS::S3::Base.establish_connection!(
  :access_key_id     => 'key goes here',
  :secret_access_key => 'secret goes here'
)

3. Various operation on S3 buckets:

a) store an object on S3
S3Object.store('me.jpg', open('headshot.jpg'), 'photos')

b) More explicitly data
S3Object.store(
  'name of object',
  File.open('large-picture.jpg'),
  'name of bucket',
  :content_type => 'image/jpeg'
)

c) Fetch object from S3
picture = S3Object.find 'headshot.jpg', 'photos'

Cheers!

 
 

 

JRuby on Rails vs. Ruby on Rails


JRuby is the ruby implementation that runs on a JVM where as Matz’s ruby is a C implementation.

Key features to note are:

-Jruby having very good performing JVM and much faster than Ruby 1.8.6 (.i.e MRI) 
-It allows us to access some very popular Java libraries from Ruby
-It supports both Ruby 1.8.6 and Ruby 1.9 language specifications 
-It has very good support for Rails today
-It has very good support for Google App Engine today 
-It can use a multitude of web server configurations both Java and non-Java 
-It has support for true multi-threading because the Global Interpreter Lock (GIL) doesn't exist
-Jruby runs on Java VM's and it's either compiled or interpreted down to Java byte code.
-JRuby can integrate with Java code. If you have java class libraries (.jar's), you can reference and use them from within ruby code with JRuby. In the other direction you can also call Jruby code from within Java. JRuby can also use the JVM and application server capabilities.
-JRuby is usually hosted within Java application servers such as Sun's glassfish or even the Tomcat web server.
-Although you cannot use native ruby gems with JRuby there are jruby implementations for most of the popular ruby libraries

Cheers!

Managing Multiple Environments for an App


Create your servers and fix your remotes

We’ll need to create both remote environments, staging and production.Since we’ll be pushing to two applications we are using the –remote argument to make two sensibly named remotes.

First create staging:
$ heroku create --remote staging

Push code to heroku:
$ git push staging master
Migrate database:
$ heroku run rake db:migrate --remote staging
Get remote inof:
$ heroku ps --remote staging
Then production:
First create production:
$ heroku create --remote production

Push code to heroku:
$ git push production master
Migrate database:
$ heroku run rake db:migrate --remote production
Get remote inof:
$ heroku ps --remote production

Linking local branches to remote apps

This pushes my local topic branch named red-bg into remote branch master on the remote repository named production.

git config remote.[remoteName].push [localBranchName]:[remoteBranchName]

$ git config remote.production.push red-bg:master

$ git push production red-bg:master -f

Also, you can do this directly with git push:

$ git push heroku +HEAD:master
$ git push -f heroku HEAD:master

That’s it 🙂