Poetry of Programming

Its about Ruby on Rails – Kiran Soumya


ROR : Important Points to be noted

> Difference between Ruby load and require:

Ruby programs may be broken up into multiple files, and the most natural way to partition a program is to place each nontrivial class or module into a separate file. These separate files can then be reassembled into a single program (and, if well-designed, can be reused by other programs) using require or load. These are global functions defined in Kernel, but are used like language keywords. The same require method is also used for loading files from the standard library.

load and require serve similar purposes, though require is much more commonly used than load. Both functions can load and execute a specified file of Ruby source code. If the file to load is specified with an absolute path, or is relative to ~ (the user’s home directory), then that specific file is loaded. Usually, however, the file is specified as a relative path, and load and require search for it relative to the directories of Ruby’s load path (details on the load path appear below).

Despite these overall similarities, there are important differences between load and require:

  • In addition to loading source code, require can also load binary extensions to Ruby. Binary extensions are, of course, implementation-dependent, but in C-based implementations, they typically take the form of shared library files with extensions like .so or .dll.

  • load expects a complete filename including an extension. require is usually passed a library name, with no extension, rather than a filename. In that case, it searches for a file that has the library name as its base name and an appropriate source or native library extension. If a directory contains both an .rb source file and a binary extension file, require will load the source file instead of the binary file.

  • load can load the same file multiple times. require tries to prevent multiple loads of the same file. (require can be fooled, however, if you use two different, but equivalent, paths to the same library file. In Ruby 1.9, require expands relative paths to absolute paths, which makes it somewhat harder to fool.) require keeps track of the files that have been loaded by appending them to the global array $" (also known as $LOADED_FEATURES). load does not do this.

  • load loads the specified file at the current $SAFE level. require loads the specified library with $SAFE set to 0, even if the code that called require has a higher value for that variable.

> To revert migrations to different version:

rake db:migrate version=19

> Task to delete all migration during deployment:

The delete command is just a convenience for executing rm via run. It just attempts to do an rm -f (note the -f! Use with caution!) on the remote server(s), for the named file. To do a recursive delete, pass :recursive => true:

Demonstrating delete [ruby]

delete #{release_path}/db/migrate“, :recursive => true




Difference between Mocks and Stubs

  • Many developers confuse the ideas behind stubbing and mocking. Stubbing simply replaces a real-world implementation with a simpler implementation. A stub can replace full login system with a simple substitute. A stub’s job is to simulate the real world. Mocks are not stubs. A mock object, instead, is like a gauge that measures the way your application uses an interface.
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.
  • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Rspec Definitions for Mock and Stubs:Mocks are objects that allow you to set and verify expectations. They are very useful for specifying how the subject of the spec interacts with its collaborators. This approach is widely known as “interaction testing”.Mocks are also very powerful (though less widely understood) as a design tool. As you are driving the implementation of a given class, Mocks provide an amorphous collaborator that can change in behaviour as quickly as you can write an expectation in your spec. These changes are tantamount to designing the interface to a collaborator that often does not yet exist. As the shape of the class being specified becomes more clear, so do the requirements for its collaborators – often leading to the discovery of new types that are needed in your system.
Stubs are objects that allow you to set “stub” responses to messages. Stubs provide canned responses to messages they might receive in a test, while mocks allow you to specify and, subsquently, verify that certain messages should be received during the execution of a test.


Single Table Inheritance

Active Record allows inheritance by storing the name of the class in a column that by default is named “type” (can be changed by overwriting Base.inheritance_column). This means that an inheritance looking like this:

  class Company < ActiveRecord::Base; end
  class Firm < Company; end
  class Client < Company; end
  class PriorityClient < Client; end

When you do Firm.create(:name => “37signals”), this record will be saved in the companies table with type = “Firm”. You can then fetch this row again using Company.find(:first, “name = ‘37signals’”) and it will return a Firm object.

If you don‘t have a type column defined in your table, single-table inheritance won‘t be triggered. In that case, it‘ll work just like normal subclasses with no special magic for differentiating between them or reloading the right type with find.

Note, all the attributes for all the cases are kept in the same table. Another example is as follows:

Relational databases don’t support inheritance, so when mapping from objects to databases we have to consider how to represent our nice inheritance struc-tures in relational tables. When mapping to a relational database, we try to minimize the joins that can quickly mount up when processing an inheritance structure in multiple tables. Single Table Inheritance maps all fields of all classes of an inheritance structure into a single table.


The “remembered” three fishes story…

Instead of using the word “unforgettable story”, I should say this story is always remembered in every act of my life.

The story is a lesson of my telugu detailed text book in my school days and it is … as follows:

Once upon a time, there lived three fishes in a lake. Their names are “Bhuddimathi”, “Kalamathi” and “Mandamathi”. I hope you got the story by names… But still let me continue… They used to live together and lead a happy undisturbed life in the lake. But one day suddenly… villains appeared… two fishermen… they were standing next to the lake and talking about fishing this place soon. They have decided to come with nets and other things the next week. The three fishes who heard this got scared… Bhuddimathi has decided to start to the next lake near by before those fishermen come. The next day early morning itself, it alerted the other two fishes and reached the other lake safely. The other two fishes thought there was lots of time left to them so they took it easy. Finally, the two fishermen approached the lake one day before they planned… Kalamathi as it is smart… acted dead once its caught. And thinking that fish was really dead .. the fisherman threwed it back to the lake. And it safely started its journey to other lake. But the third fish “Mandamathi” finally who could neither be like Bhuddimathi acting before nor like Kalamathi acting smart was fated to death due to its negligence.

So from then… in every work I do… my mom alerts me saying… be like Bhuddimathi study before itself or complete your work before itself… Even now… in anything… if I have to get fruits or if I have to get milk for curd or if I have to book my tickets to vizag or in anything.. this Kalamathi, Mandamathi and Bhuddimathi characters appear… Always I prove her to be Kalamathi but never Bhuddimathi…

But nowadays seriously… I improved from Kalamathi to Bhuddimathi… Believe me Mom!


Dilemma of a Developer under TL

I have a group of friends in big MNC software fields… who complain a lot about their Tls … almost every day… And I cant complain in return because I dont have one !!! Infact.. I am the Tl/owner of my own Task..

But when a developer works under someone or managed by someone… that someone becomes a Guru for the developer. As an Indian Slogan…”Guru Devo Bhava !” [which means “Guru is equal to God”].

But if there are too many Gurus…??? Simple… Too many Gods… :)
Taken Project on Hand… Incremental Developments or Releases are possible only when…

1> The manager knows… whos eligible for what… On a situation to give freedom to developers.. tasks decided within the group need to be known to everyone.

2> When you let the developer complete implementing his whole idea whatever he understands… after a ONE-TIME compulsory discussion/Goal achievement Plan — and thats perfect ! Because Guru is God !

3> Without completion of this one-time plan by the developer… never add new stuff/discussions that confuses the developer neither to complete his past work nor do the newly added stuff.

4> Any debates on the idea to be taken place only with the right person or the creator who knows everything.
5> The bottomline should surely be shared with the developer who ultimately needs to complete the goal.

6> Thereby the easy developer feels easy to release whatever on hand and every week meetings includes the happy releases whether it is accepted/rejected. This surely makes the track of the work and the developer.

7> Arguments/debates are allowed weekly once to change the plan or update it to make this another solid release.

8> A plan that changes daily is never said or called it as a “Plan”. If planning is perfect… then releases are perfect…

Hey Tls…! If you set the plan … then the developer is just a perfect mirror of your plans/ideas… or else leave everything to the developer… sometimes he knew better than you…!!!

Never blame the Developer rather believe… Because He gives Life for it as he is the one who builds it !!!


Pin Drop Sound please…

Code code code… hurray…
But whos that? calling me there…

Discussion Discussion Discussion…
Confusion Confusion Confusion…

Too many cooks… threw me in a hot pan…
Although… I have set my plan.

The whole concept… lost its fuse.
And who is this now … dumping things in dose.

What the heck the themes/dress change do
Please… Please give me a clue…

When not even the model/doll exists…
Help ! I need to complete this…

Ok say yes to one… say no to other…
Now see the fireworks around. do you bother?

Follow the right and make the domineer sad…
How to make all happy… without doing… all bad?

Wah! Finally… What a silence…
Now… I am leaving into the world of coding sense…

Me and my laptop…
On a rocket plane… to the success hill top !