Surya Raj Tripathi

I’ve always wondered if there’s any better way to deal with flash messages in Ruby on Rails. In all the Ruby on Rails tutorials you see, they’ll tell you to keep the code DRY, isn’t so? Right? So what you do? Create partial  shared/_error_messages.html.erb  or  shared/_flash_messages.html.erb  and write your flash messages displaying code into this file and call it from all other places in your views? Wait!! While keeping your flash messages in partial is a good thing, but don’t you think you can do it in a more better way?? Yes, better way! I found this  gist.  While I was reading this gist a thought triggered in my mind that why not remove a part and make a method which displays the flash messages. So, I created this  gist : Now, the application doesn’t have to load another part for just displaying the flash messages. Guess what? You saved few milliseconds of your action load time! Don’t believe? Try it yourself! You’re welcome!

I am not sure who’s going to read all the stuff I have put below. But, whatever I’ve written is my own personal experience, gained over a certain period of time. I completed my engineering from so-called computer science & engineering( I am still looking for that guy who told me that software engineers have a great life, and encouraged me to go for CSE. He also talked my father into it with the boosted words of wisdom of a software engineer, he told software engineers to spend life in an AC room and earn good money for checking emails. When I find this guy then somebody’s gonna gets hurt pretty badly! :P ) in July 2010. I had no job a the college couldn’t afford to get any company for campus placement. So, I moved to Bangalore in a hope of getting a job and started hunting with other folks I met during that time. Later, I got a job in a pretty well-established outsourcing company(organization size was about 40 employees, it wasn’t a startup though) as their first and only test

Design patterns  have always been a vital part of a quality software development. In fact, they let developers work in a team effectively by setting up the common ground rules for a problem. In this post, I’d like to introduce you to  The Observer Pattern . Basically, Observer is a  behavioral type,  or publish/subscribe pattern which allows a number of observer objects to see an event. So, if an observer object is subscribed to an event on the subject, on a change/update of that event on the subject will publish/reflect the changes on the observing objects as well. For example, An electric bulb’s state(on/off) will depend on the state of the switch it is directly connected to. So, if I turn the switch on then the bulb will be turned on, and vice-a-versa. Now, think switch and bulb as objects. These objects will have two states: either on or off. However, the bulb’s state will entirely depend on the switch’s state. Bored reading theoretical stuff?? Let’s see some code in action:

Multiple Inheritance – A class is suppose to show multiple inheritance when that class can inherit characteristics and features from more than one superclass(parent class).  Mixin – Since Ruby does not support multiple inheritances but has an amazing implementation of achieving the same by eliminating the need for multiple inheritances using the module, is also known as the mixin. Mixin - can be achieved by using either include or extend keywords inside a class. The difference between include and extend is: include : mixes in specified module methods as instance methods in the target class. extend : mixes in specified module methods as class methods in the target class. Here is a small code example:  Still, have a question? Feel free to contact me!!