Java vs Ruby

Runtime differences:

In Java the program always starts with a main method. Ruby program by default creates a main Object which is an instance of class class and then starts execution on it(weird!). It always starts reading from the first line of the file, there is no specific starting point.

So when you create a ruby test file HelloWorld.rb with below statement

puts "HelloWorld"

execute it in terminal with ruby HellowWorld.rb . Ruby interpreter creates main object and then starts to execute puts.(puts is an instance method from kernel module. These methods are called without a receiver).

To test this go to terminal irb and do the following.

ruby main object

Execution differences:

Java is a compiled language so the execution is a 2 step process. compile + run.

Ruby is an interpreting language.

Both Java compiler and Ruby interpreter are written in C.

Programatic differences:

Ruby is completely object oriented what does that mean from a java perspective ?

– In java we have primitive data types such as int, float etc along with Classes and Objects. In Ruby Integer, Float etc are also Classes inherited from Numeric class which intern inherited from Object class. here is a detailed image taken from rubylearning.com which explains this.

class

So when you create an Integer in ruby you are creating a object for Integer class.

One more important ruby feature to discuss is duck typing.

Java is strictly or strongly typed language where we need to declare the type of variable.

Ruby has implicit and explicit type conversions.

Lets see what implicit conversion means.

duck typing

Ruby is loosely typed language where it tries to define the type of a variable implicitly as shown above. If it can not infer it it throws an error as below.

undefined local variable or method

Explicit conversion is kind of ruby’s way to type safety. I can try to convert into my expected type. see below.

ruby convert to string

Happy coding!

 

Difference between string and symbol in ruby

Ruby symbol and string does the same thing except symbol is more efficient in terms of memory and time.

As explained here

Symbol is the most basic Ruby object you can create. It’s just a name and an internal ID. Symbols are useful because a given symbol name refers to the same object throughout a Ruby program. Symbols are more efficient than strings. Two strings with the same contents are two different objects, but for any given name there is only one Symbol object. This can save both time and memory.

ruby string symbol

Therefore, when do we use a string versus a symbol?

  • If the contents (the sequence of characters) of the object are important, use a string
  • If the identity of the object is important, use a symbol.

We can change them to each other like this

puts “string”.to_sym.class # Symbol

puts :symbol.to_s.class    # String

Symbols are particularly useful when creating hashes and you want to have a distinction between keys and values.

Rails migrations best practices

Avoid using Rails models in migration.

Reasons:

  1. Models might have some lifecycle callbacks which we dont want to be invoked in a migration.
  2. As we know what we are doing we dont want to deal with validations.
  3. Model names can change irrespective of db table.
  4. Try to use raw sql as close as possible.

Squash them after a period of time.

Reasons:

  1.  To my experience over a period of time these migration files are painful and useless.
  2. Every rake db:migrate might take a few seconds, or creating of a new database might take a few minutes when these files are big. Consider using tools like squasher.

Make them irreversible.

Reason:

In Production it makes sense to have IrreversibleMigration as the code is tested in lower environments. If there is an issue try to fix it with a follow up migration.

Note: If there is a new developer in your team and setting up their environment. Let them do `rake db:schema:load` to get latest db copy.

Git merge vs rebase

There is no hard and fast rule. But i am putting out when to use what based on my experience.

Merge if

  • you are in a big team working on a feature branch and you want to rebased from master. If you dont have all the commits you are in trouble.
  • When you find rebasing is becoming painful for no reason. like for every rebase step you need to fix the same lines of code again and again.
  • Not worried about one more additional commit and order of commits as they are going to be mixed up.

Rebase if

  • you dont want to change the commit history/log.
  • You want the commit history looks clean. As new work will be on top of everything.
  • when you have less code changes or you know how to deal with conflicts (more patience required practice meditation).
  • you branched off of feature branch to your own branch. You can do what ever you want as its your world.