Rails Uprooted - By RK

As my post name “If Not Agile Then Project Fragile” itself tells us that what will happen to your project if its not agile and will also tell us that what will happen if it goes agile.

Whats Agility??????

 Agile also called as Agility is the ability to change the body’s position, and requires a combination of balance, coordination speed, reflexes , and strength as so is the case when you think that body to be you own “Project”. The Agile Software development provides a backbone or a scaffold for a software engineering process that promotes software developments in a set of “Iterations”.

Each iteration is an entire software project: including planning, requirement analysis, design, coding, testing, and documentation.For a better understanding, I can say that an Iteration is nothing but a “small plan” , towards which the team works in a best possible time to achieve it.And Once the things are done the whole team  sits back to evaluate on what they have done and whats next…!

 What Do We Need To Do Go Agile….??????

To become a Agile Evangelist like me communicate more about your project with your team friends rather then making exemplery docs which generally waste your time.But, Agile method generally tend to provide you with a minimum of documentation with respect to your project.You people can work in some kind of fresh open place whcih I generally refer to as a bullpen.I work with my client ,my team mates, the testers so that everybody hads a common understanding of the issue and how are we supposed to be dealing with it.

Note:The below link will take you Agile manifesto which is nothing but like a prayer to the “God Agile”

         http://agilemanifesto.org/

 How Do I Make The My Project Go Agile…?????

 There are various methodologies using which you can make your project go Agile…!..They are

Scrum (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM(1995).

 Agile methods are a family of development processes, not a single approach to software development.

From a project perspective , agile methods come into play when the client or the customer need tha product at an emergency, along with a rapid intermediate changes been applied to the product.The agile method is also used for project with longer lifelines and these projects are seem to scale in a cool manner where in each programming guy gets the a quick feed back of what he has done as per the chnges asked by the client and also also tends to workout with any discrepancies found while the project is in progress.

I also believe that the vertical stack describing the life cycle of a waterfall model or the genearlly called traditional software development model now goes horizontal when pushed into the agile methodologies hence making the development up to date and faster for each iteration.

Also before we actually get our feets wet in this methodologies we also need to aslo need to take care of the factors that an important role whcile the project is been setup:

The culture of the organization must be supportive of negotiation People must be trusted Fewer staff, with higher levels of competency Organizations must live with the decisions developers make Organizations need to have an environment that facilitates rapid communication between team members

Can My Underground Data Be Agile….????

I was a little confused when I thought about this but I finally found that agile practices tend to use techinques like generative data model to keep up your project reflexive irrespective of the databse changes.Like in Rails, we achieve this through what we call as the database migration which allows us for rapid database changes and maintaining the reflexivity of the project(code execution) on the other side.But, some caveats lie if in case your database has complex relational mappings between them and can serve to be a blockage points for your project,to overcome this if you build your relational mappings keeping in mind the agility of your project then you can ensure yourself that your project goes maintains the reliablilty and it transperancy with the DB changes through out its lifecycle.

• Here Documents in strings
  Here documents are nothing but strings that are inherently multiline.
• str=<<EOF
  Raghu is giving a presenation,
  he know ruby very well.
  EOF
• Here documents can also be stacked into a method like
  def foobar(<<str1,<<str2,<<str3)
   This is a cool thing
   And this is great.
   str1
   This is the second cool thing
   and it is also great
   str2
   This is third cool thing
   and now its becoming hot
   str3
  end
• String Compression:
  The zlib library provides means for compressing and decompressing strings and files mailt faster db access,to optimize the network or may be obscure
  the strings  so that they are not possibly readable
  The Deflate and Inflate classes have the methods defalte and inflate for ths purpose.The deflate takes parameter whch defines the quality of compression and speed
  BEST COMPRESSION-results in a smallest compressed string
  BEST SPEED- Compresse faster buts does not compress as much
  DEFAULT COMPRESSION-Provides a tradeoff between
• -How does method invocation takes place in ruby on rails?
  For example: myobject.method
  -Ruby first searches for singleton methods of myobject
  -Then it defines the myobject class
  -Then the methods defined in the myobjects ancestors
  In case if the mymethod is not found,ruby seraches the default method called method_missing
• - Methods without parenthesis are valid in ruby.
   For example: foobar a,b,c
• -There are no boolean types in Ruby.Instead there is the TRuecalss and the Falseclass with its instance as true an false
• -loop is not a keyword instead its a method defined into the kernel module
• -what is the differenece .. and… in ranges?
  ..is inclusive of the upper bound and the … is not exclusove of the upper bound.ex5..10 will consider 10 but …will not consider 10
• what kind of a scope does the intialize method of a class have?
  -The intialize method is always private
• The methods ending with an ! mark are said to be destructive methods.These are said to destructive since these methods tend to modify the behaviour of the receiver i.e the receiver will not hold the values before it was applied to this method.

The performance of Ruby on Rails is influenced by many factors, particularly the configuration of your deployment server(s). However the application code can make a big difference and determine whether your site is slow or highly responsive. This short article is about some of the tips and best coding practices to improve performances in Rails only, and won’t attempt to cover the server configuration improvements for the various deployments options. 

1. Optimize your Ruby code: this may seem obvious, but a Rails application is essentially ruby code that will have to be run. Make sure your code is efficient from a Ruby standpoint. Take a look at your code and ask yourself if some refactoring is in order, keeping in mind performance considerations and algorithmic efficiency. Profiling tools are, of course, very helpful in identifying slow code, but the following are some general considerations (some of them may appear admittedly obvious to you):
   • When available use the built-in classes and methods, rather than rolling your own;
   • Use Regular Expressions rather than costly loops, when you need to parse and process all but the smallest text;
   • Use Libxml rather than the slower REXML if you are processing XML documents;
   • Sometimes you may want to trade off just a bit of elegance and abstraction for speed (e.g. define_method and yield can be costly);
   • The best way to resolve slow loops, is to remove them if possible. Not always, but in a few cases you can avoid loops by restructuring your code;
   • Simplify and reduce nested if/unless as much as you can and remember that the operator ||= is your friend;
   • Hashes are expensive data structures. Consider storing the value for a given key in a local variable if you need to recall the value a few times. More in general, it’s a good idea to store in a variable (local, instance or class variable) any frequently accessed data structure.
2. Caching is good: caching can significantly speed up your application. In particular:
   • Cache your models through the plugin acts_as_cached (a pdf presentation is here) or the cached_model gem;
   • Use MemCacheStore as Sessions container;
   • Cache your pages through fragment cache (take a look at the extended_fragment_cache).
3. Use your database to the full extent of the law : don’t be afraid of using the cool features provided by your database, even if they are not directly supported by Rails and doing so means bypassing ActiveRecord. For example define stored procedures and functions, knowing that you can use them by communicating directly with the database through driver calls, rather than ActiveRecord high level methods. This can hugely improve the performance of a data bound Rails application.
4. Finders are great but be careful: finders are very pleasant to use, enable you to write readable code and they don’t require in-depth SQL knowledge. But the nice high level abstraction come with a computational cost. Follow these rules of thumb:
   • Retrieve only the information that you need. A lot of execution time can be wasted by running selects for data that is not really needed. When using the various finders make sure to provide the right options to select only the fields required (:select), and if you only need a numbered subset of records from the resultset, opportunely specify a limit (with the :limit and :offset options).
   • Don’t kill your database with too many queries, use eager loading of associations through the include option:

o                     # This will generates only one query,

o                     # rather than Post.count + 1 queries

o                     for post in Post.find(:all,

o                                           :include => [ :author, :comments ])

o                       # Do something with post

end

1.  
   • Avoid dynamic finders like MyModel.find_by_*. While using something like User.find_by_username is very readable and easy, it also can cost you a lot. In fact, ActiveRecord dynamically generates these methods within method_missing and this can be quite slow. In fact, once the method is defined and invoked, the mapping with the model attribute (username in our example) is ultimately achieved through a select query which is built before being sent to the database. Using MyModel.find_by_sql directly, or even MyModel.find, is much more efficient;
   • Be sure to use MyModel.find_by_sql whenever you need to run an optimized SQL query. Needless to say, even if the final SQL statement ends up being the same, find_by_sql is more efficient than the equivalent find (no need to build the actual SQL string from the various option passed to the method). If you are building a plugin that needs to be cross-platform though, verify that the SQL queries will run on all Rails supported databases, or just use find instead. In general, using find is more readable and leads to better maintainable code, so before starting to fill your application with find_by_sql, do some profiling and individuate slow queries which may need to be customized and optimized manually.
2. Group operations in a transaction: ActiveRecord wraps the creation or update of a record in a single transaction. Multiple inserts will then generate many transactions (one for each insert). Grouping multiple inserts in one single transaction will speed things up.

Insead of:

 my_collection.each do |q|

   Quote.create({:phrase => q})

 end

Use:

Quote.transaction do

 my_collection.each do |q|

   Quote.create({:phrase => q})

 end

end

or for rolling back the whole transaction if any insert fails, use:

Quote.transaction do

 my_collection.each do |q|

   quote = Quote.new({:phrase => q})

   quote.save!

 end

end

1. Control your controllers: filters are expensive, don’t abuse them. Also, don’t overuse too many instance variables that are not actually required by your views (they are not light).
2. Use HTML for your views: in your view templates don’t overuse helpers. Every time you use form helpers you are introducing an extra step. Do you really need a helper to write the HTML for a link, a textbox or a form for you? (You may even make your designer, who doesn’t know Ruby, happy!)
3. Logging: configure your applications so that they log only the information that is absolutely vital to you. Logging is an expensive operation and an inappropriate level (e.g. Logger::DEBUG) can cripple your production application.
4. Patch the GC: OK, not really a coding issue, but patching Ruby’s Garbage Collection is strongly advised and will improve the speed of your Ruby and Rails applications significantly.
5. A final note:I don’t advocate premature optimization, but if you can, work on your code with these principles in mind (but don’t overdo it either). Last minute changes and tweaks are possible but less desirable than a “performance aware” style of coding. Profile your applications, benchmark them
   and have fun experimenting.