The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.
Here’s an excerpt:
A New York City subway train holds 1,200 people. This blog was viewed about 7,600 times in 2014. If it were a NYC subway train, it would take about 6 trips to carry that many people.
Before I jump to that actual article I want to make sure that we are on the same page as far as the objectives are concerned. Its important because, if the objectives are not clear, the strategy that worked for me, may not work for you. So, here is what I always wanted for my project teams:
- To be able to keep on working on the next major release
- To be AGILE, meaning they should be able to go to production given a situation
- To be able to develop each feature independently
- To be able to avoid merge code nightmares
At this point, if you do not resonate with the above objectives, there possibly no point going forward reading this article anymore. Find something else that suits your needs better. Others, please continue…
To achieve the above objectives following GIT workflow has worked for me and I hope many others will resonate:
- There are only 2 main branches for the team, “master” and “production” at any point in time
- “master” branch should always be in a production release acceptable by the stakeholder’s state. Meaning, its bug free, stable, and does not have half baked features that can affect the user experience in adverse way (to achieve #2 above)
- Feature branches are created as per need to develop a given feature which is typically part of the next release (to achieve #3 above)
- Every feature branch should be “rebased” (git rebase) with master branch at least once a day, (take a call based on the frequency of commits happening in the master branch) to make sure you are working on the most recently committed version of the next release and that you are not stepping upon others shoes who might be working in your close proximity 🙂 (to achieve #4 above)
- Feature branches are merged back with “master” once the feature is complete and the branch is bug free, meaning, the unit and functional test suite is ran against the branchBug Fixes
How to tackle Bugs
Bugs are of 2 categories. There are ones which are modest :). They do not kill you if you don’t get rid of them until the next scheduled release. At the same time, there are these other ones which are disastrous and possibly contagious. These bugs are the ones which makes your boss call you in the middle of the night and pursue (like, fix it to save your job) you to go and get rid of it immediately. As the nature of the bugs is so different, its nothing but obvious, that the strategy to tackle them is different too. Here’s is what has worked for me:
The modest bug fixing should be tacked as any other normal feature development (well both require code change, so as far as a developer is concerned, its all the same 🙂 ) like:
- Checkout “master” branch (or make feature branch if the scope of code change is bigger, explained below)
- Fix the bug
- Run the tests
- Commit and Push the fix to “master” branch
- Release the big fix with the next scheduled release
Although, it depends on the scope of the code change that is required to make the bug fix, whether you’ll actually create a separate branch for it or not. Normally, the scope is not be as big as that of a typical feature, so you may just end up checking out “master” branch and fixing the bug in it. If not, feel free to create a new “bug” branch and work on the bug and merge it back to master.
As this bug cannot wait until the next scheduled release, your corse of action is going to be a little different as follows:
- Checkout “production” branch
- Fix the bug
- Run the tests
- Commit and Push the fix to “production” branch
- Let Jenkins (or the any other tool that you may using for CI) OK the build production build
- Deploy the new build to production server (the deployment work flow may be different for you, so follow that)
- Merge the production branch back to master so that the big fix is not lost when the next schedule release happens 🙂
I mentioned deploy to production above. Although the deployment strategy can be different for different teams, there is still a GIT workflow for maintaing the production branch that is still in the scope of this article. So, the scenario is that you are ready with your master branch with all the features that you want to go for the next release. Now the time is to actually make it see the light of day. Its actually very simple. Here is what has worked for me:
- Make sure that there is nothing in the “production” branch that is not merged to “master” already
- Make sure you CI is OK with it. i.e all tests are passing and green light is flashing
- Create a new GIT TAG from the HEAD of the master branch. Give a meaningful name to the TAG, e.g prod_1.1.10 (the versioning strategy is not in the scope of this article, but you can follow whatever best tell us what the release is about)
- Deploy the TAG to production instance
And that about everything I wanted to say. Life goes on and you keep repeating this every single time 🙂
This problem is not something that is specific to the version of ruby that you are using. It just comes with RVM, at least that is what I have observed since I started using RVM to manage different ruby version on my MacBook.
Now, the reason behind this problem is the SSL or OPENSSL that the ruby library is pointing to and the one that is installed on your system are not same. There are certain libraries that require using ssl, e.g if you try to send mail, or try do image processing in rails using any gem like carrierwave or paperclip etc, this problem may arise.
1. Install openssl package (if not already)
$ rvm pkg install openssl
2. Remove the already installed ruby version from RVM that is creating problem, in my case, it was 1.9.3-p125
$ rvm remove 1.9.3-p125
3. Re-install ruby version, 1.9.3-p125, specifying the openssl dir as well, so that ruby this time points to the correct openssl.
This should pretty muh resolve your problem of segmentation fault.
$ rvm install 1.9.3-p125 –with-openssl-dir=$rvm_path/usr
This is a problem which is actually not a problem if we are following right semantics of HTML.
Problem: I faced this problem where in after a page is loaded I have to add certain input html elements in the form (which I had inside a table) using ajax. Only the elements that were loaded when the page rendered were getting posted, but not the ones added using ajax after the page was loaded. This can be frustrating to figure out why the elements which were loaded by default are getting posted but the elements which rendered after wards using AJAX are not.
My Theory: When a DOM is loaded, the input elements, which are rendered inside TABLE cells get hooked to the FORM automatically because they are rendered when the DOM got loaded. And when the form is posted, its not the table, but the input elements which are hooked to the form get posted. Now, if you are rendering some elements through ajax, then those elements get hooked up only to the TABLE (in case the FORM is inside the TABLE) and not to the form.
Solution: Shift the TABLE inside the FORM. So, that when you add more elements dynamically, it gets hooked to the form as well.
TABLE — WORKS
FORM — NOT GOOD
This was a head breaking experience for me recently.
We all know that the fixtures files in rails load by default in alphabetical order. And the records inside every single file again load in alphabetical order (not from top to bottom as you define in the fixture file). Considering that having database level constraints (foreign keys, primary keys etc) is advisable idea in spite of having the rails model level relations (belongs_to, has_many etc), loading fixtures in alphabetical order is the most stupid thing I can ever think of. Imagine you have Account and Employee models and employee has_many accounts. So you have an employee_id sitting as a foreign key in the accounts table. Now you want to load your fixtures (rake db:fixtures:load), for test purpose say, which was my requirement. Since ‘A’ comes before ‘E’ in alphabetical order, rails tries to load the addresses first and then the employees fixture file. Obviously this fails because of foreign key violations. Database raising errors is perfectly making sense here. So I looked around for something which may solve this problem and found that there are solutions available given by some people. But what surprised me is that there is nothing that rails core provided for this.
Anyways, so for people who are into this kinda problem, here is the best one called ActiveFixture that I came across and wish that it would get included in the rails core someday.
Again there is something that may surprise you again. Its not that rails has been stupid all these days to leave us in such a situation. It might so happen that you may not do anything for ordering of the fixtures and still would not get any error although you have foreign key relationships in the database. The reason actually lies in the active record’s database (postgres, mysql sql-lite etc) adapters class. Here is how it goes. While loading the fixtures (I am giving postgres example, as I am using postgres for this project and found it there), rails calls the following method in ActiveRecord::ConnectionAdapters::PostgreSQLAdapter:
def supports_disable_referential_integrity?() #:nodoc:
version = query("SHOW server_version").split('.')
(version.to_i >= 8 && version.to_i >= 1) ? true : false
So this method says, that if you pgsql version is x.y.z, then if x >= 8 and y >= 1, then it will be able to defer the referential integrity for you and you could load the data from fixtures into your database easily without taking care of the ordering and without facing any data integrity errors 😀 Unfortunately I, in my team, was using 9.y.z version of pgsql and all my collegues were on 8.1.4. So they were not getting any errors and I was frustated to know WHY.
Well the secret lies in the ConnectionAdapters for rails 😀 I don’t know if we should take it as an advantage, that rails is trying to do or not, but until we have something more intelligent to infer the order of loading the fixtures files from the relationships in the models, rather than defining the load order manually as mentioned here, I am happy that its saving me some time.
Well after a long time, I finally had to shift back to ROR development on Windows. I am running on Windows Vista, Rails 3, ruby 1.9.2. Things are not all that bad on windows, or at least, not as much as I thought they might be. But, we definitely keep on facing problems here and there. There is one such which you also might face if you try development on Rails 3 with ruby 1.9.2. There seems to be a bug with the gems that are installed with the one click windows ruby installer. I am not sure why, but you may lead to see the following error message once you start using rake:
`bin_path’: can’t find executable rake for rake-0.8.7 (Gem::Exception)
Now the solution to get away from this bug as of this writing is that you will have to remove the rake.gemspec file from the “your_path_to\Ruby192\lib\ruby\gems\1.9.1\specifications” folder.
And you are good to go now. I do not have really too much time to dig into the matter as to why this might be happening, but it worked for me.