Monthly Archives: February 2014

Tests using Git Concurrency Issue

I was recently working on a Gem I created called Toolshed. The purpose of this tool is to turn everyday tasks into automated ones. At least to a certain degree. This will allow you more time to do the heavy lifting tasks. For example some of the functionality that this tool provides is creating a Github pull request, updating Pivotal ticket status as well as many Git more tasks. All of this would normally require you to go up into the sites interface click around and enter the data. As we all know that takes time and time is valuable. So down to the part that I had trouble with when I was creating tests for this tool.

I first started to create all of the tests locally and verify that they worked there. I had no trouble with this and everything appeared to be working. I was not getting any test failures. After creating a couple of them I wanted to see if I could get it working up on Travis CI. Travis works well with a ruby project plus since the Gem is open source it’s free. So I setup Travis and everything seemed to be working right. The first couple of runs seemed to pass without issue. Over the next few days I noticed that Travis was failing randomly. I would push up a small change and it would fail. I would run it again and it would pass using the same code base. It seemed random and a CI that has random failures is useless. The theory behind that is if errors happening randomly there they will also happen within your application. So I needed to investigate this further. Since I was unable to recreate the issues on my local machine I decided to try it out on a different machine. I created an ubuntu environment and started fresh. Once I got to that environment I was able to reproduce the problems I was having on Travis pretty easily. I was able to debug real time which helps instead of pushing new commits up to Travis.

What I noticed was that my Git commands were not finishing before it started the next one. So it would be doing a git remote update and then the next command would run before that finished. This would cause it to fail because it depend on remote update finishing first. So I had to create a solution for this and here is that solution.

until (system("git remote update"))
  sleep 1
end

This will sleep and wait until it hears a response. This will now wait for each command to run in it’s specific order. I have now tested it out several times on Travis and am no longer having this issue.

Switch Jobs often burnout

I was reading this blog post today and it said switching jobs often is a bad idea and will lead to a burnout. I really disagree with that statement. Over the winter break I read The Passionate Programmer and some really good points where made on this exact subject. I think it’s easy to think if I stay at one job and work my way up I will be in a better place. It makes sense because you will learn the business inside and out during that timeframe.

I was in the same mindset until I read that book. One of the points that was made that after some time wether it be three years of five years you become a liability to your company. If all you do is work with the same set of developers the ideas that are passed around are usually very similar ideas. It’s very hard for the human to change a routine after they get comfortable. I have lived through real world examples of this. I came from one job thinking I was using the latest and greatest technique’s but soon discovered I had a lot to learn. The point is if you want to be the greatest asset then you need to pick up the skills from all the jobs you have worked at. If you sit at one job your entire career you wont have all those experiences.

Another point in the post was moving up the chain developer to manager to director. I’ve been developing for over five years now and that’s never been the case in my experience. Most companies will either have that already in place or hire an outside person if somebody does leave. Positions or titles are not added just because you are ready to move on. Again if you come in with experience from many companies maybe some big name ones to you are a greater asset. Instead of having to work up the ladder you start at a higher level. It should not take your four to six years to learn what you have to do for your job. This isn’t school you should already have knowledge of how to do your job you really just need to learn the business rules behind it all.

Here is my favorite one you have to start from scratch. I don’t believe this to be true at all. Sure you need to rebuild your profile internally with the company but you start at some level. I don’t know of any developer who leaves their current position to start up at a lower position. Most of the time you are hired either at the level you were at or a higher level. So you are really starting with all of your personal knowledge. So you never start from scratch unless it’s truly your first job ever.

Sorry but if your a good developer your code will prove itself. Along with your knowledge. Every company I have been part of when a new person started you could easily tell if they had what it took to perform at their job. They didn’t have to prove anything that’s what the interview is for right? Also these days a lot of developers have an open source profile so if you want proof at what they can do look there. Otherwise ask for their background usually that’s enough to prove wether they are good or bad.

To sum it up I really feel that this block in the blog is wrong. I feel that switching jobs every three years is a good idea to keep your skills sharpened. I also feel doing so doesn’t lead to a burnout but makes your pumped again to start your next adventure. This way of thinking seems like the traditional thought process not what is happening in today’s market.

Gem Install Gone Wrong

Today I was working on my Gem  Toolshed and wanted to install it globally. That way I wouldn’t have to add it to each of my projects Gemfile. Then run bundle install on each. The reason why I didn’t want to do that was first of all would take more time than I wanted. Also if I could just install it globally I wouldn’t have to worry about installing it for new projects. Also for this type of Gem it’s nice to be able to use it outside of a projects context. So I attempted to install it globally so that it could be used by all my projects. I am not too familiar with rvm or bundler to be honest. I have used both of them but I don’t understand enough about them to be called an expert. So I ran the following command in an attempt to install it globally. Note that I did not pull this command out of thin air I found it on a stackoverflow post and it looked promising.

gem install /home/path/to/gem

After spending several hours debugging it I finally figured out what was happening. Well it turns out that not only does that command not work but it also switches the gem install default to that directory. I figured this out through several debugging steps. The first step was when I went into a different project and did bundle install. This is a project that I have been working on for a while so I was expecting it to just work. Well when I ran bundle install I seen it was looking at my gems directory. I was thinking well something must be in the path and kind of just ignored it. I didn’t put the two together for a while. After thinking about it for a while I thought that bundler has to be smart enough to know my rvm is setup to use a specific gemset. Well it turns out that is not the case if you have a customized path like I did. It installs it to whatever directory you put in that path above. I verified that this was happening by going into my Gems directory and there is was a ruby directory with ruby installed. After doing some searching on how to fix it I found that this worked to reset the gem install back to the default directory.


bundle install --system

After doing that my system was back to normal and I was able to run bundle install again without any issues. I hope that this post can provide some insight that bundler and rvm don’t always work hand and hand. If you ever try the gem install command above remember to set it back so all your bundler commands work as expected. At least I can say I now understand more about bundler and rvm as a whole.

Fixtures Vs. Factories

I have used both fixtures and factories in writing tests. I actually use both currently I use fixtures for my personal project and factories at work. I feel that their can be benefits to both but if I had to go with one I would go with fixtures. It seems to me that you can do everything and more with fixtures. Also your test suite stays a little more organized.

The first question one may ask is what is the difference between a fixture and a factory. Well a  fixture is a set of data that is static in nature. This data will get loaded for each test run. A fixture is created using a static file within your testing structure. This is different for each language you use it in. For example in Rails it will be a yaml file while in PHP it’s just an array. This could also depend on the framework your using. If you want the table to start out empty you can create an empty fixture file. Having the static file allows you to setup specific test scenarios. Then you can write your tests around those scenarios and you know the data will always be the same. So if a test shall fail you know it’s not because of a dataset change. In contrast factories create the object and the data at the same time. The database is not stocked with any preloaded data. If you need data for your specific test case you need to call the factory and have it create the data for you. Instead of creating a static file you need to create a factory file. This file will contain the name of the factory and then any custom data you need. Using a factory can have some benefits as you will get random data so your code is being tested against unknown data. Which may be reasonable as you have outside users using your system passing in random sets of data to.

So why do I feel that fixtures are better than factories if fixtures take longer to setup. I find it that factories tend to get messy as you have data objects being created all over your test suite. No factory is identical so you tend to have to work though a lot of different data scenarios. Also if you don’t setup your factory to pass in the proper data you could get false positives. For example maybe your interface validates a field to be one of three values. But you forget to setup your factory with one of those values. Now your tests are failing but the interface and application are running just fine. I suppose you could make the argument you can make the same mistake in a fixture but I feel you have to think about it more as you are filling this data in. Another reason why I don’t think factories are better is they are slower running. For example if you create your fixture files they run once per test run. But they run fast because they don’t have to use active record and create the object. Factories do create an object while creating the data. This takes extra time especially if you have setup a lot of data in your scenario. Another issue I have with using factories is you have to setup your data scenario on each test. You can keep it dry in a way by calling sub classes but again a lot of times you end up just doing factory.new because it’s a one off type of setup. So you tend to duplicate setting up factories a lot especially in a larger development team.

I feel that using either factories or fixtures will be fine. But I feel that fixtures gives you a slight edge for keeping your test suite organized. You are able to write tests against predictable scenarios. Also you are not having to repeat the same datasets over and over again. I feel that this is easier to avoid using fixtures rather than factories.

Google Nexus Lineup

I recently read some articles saying that Google may discontinue their Nexus lineup. As an Android user I see this as a huge mistake. Before the Nexus lineup Android was talked about but not always in a good way. A lot of users that I would talk to would say well the device I have sucks. It’s slow or the interface is confusing. When the Nexus lineup came out everybody had a pure Google phone to go to. I could just tell them well you should probably get the latest Nexus device. The reason why I would say that as I knew that you would get a pure Android with a Nexus device. Here is an article that I was reading Rumor: Google Nexus Branding to End with details on why these rumors are happening. I sure hope that the Nexus lineup doesn’t go away.

The first reason why I love the Nexus lineup as the pricing. The price for the device is usually a couple hundred dollars less than comparable devices. The reason why this can happen as Google doesn’t make much if any profit off of their Nexus series. The intention is to get their devices out at a reasonable price without a contract. This will allow your average person to own a device without breaking the bank.This is one reason why they are talking about ending the brand though. Since Google makes hardly any money off of it they want to get out of the business. I feel that if they would just raise the price maybe one hundred dollars more per device they would still have people buying them. Then at the same time they may not end of loosing money with the series. When you think about the competition with Apple vs Android you really compare the Nexus series not say HTC or Samsung.

The second reason why I love the Nexus lineup as you get pure Google. For example if you buy any HTC device you have to use their HTC sense interface. At least that is the default of course there is way’s to change this but you could void your warranty. Also devices outside the Nexus lineup come with a lot of bloatware. For example most HTC devices come stocked with Facebook and probably Twitter these days. Well what if you don’t use Facebook can you remove the application? Nope you have to leave it there taking up space in your device. With a Nexus device you get only a small amount of Google applications and no additional third party applications. That way your phone can have more space for the applications you want to use. It really allows you to have more freedom with your device. Since you own the device you can do really what you want with it.

The third reason why I love the Nexus device lineup as their updates. You get updates right away when Google release them. With other devices you have to wait a lot longer period up to months. For example if you have an HTC phone or Samsung phone you have to wait for them to make their updates. After they make their updates they then send it to the carrier to apply their updates. From there it goes through a series of tests and if any defects are found the process starts again. So you could potentially end up waiting months for the latest updates instead of just getting them straight from Google. So the process can become very frustrating. Also there is the possibility that the carrier no longer apply’s updates to your device even if it has enough hardware for it. So basically you end up paying more for a device that is not flexible or getting updates.

If they chose to discontinue the Nexus lineup I hope they add another lineup similar. Which of course won’t happen for some time after. They wouldn’t discontinue just to add a similar lineup. I think users will be upset that they have to wait for the latest updates. I believe Google was on the right path with the Nexus lineup when it came to competing with other companies like Apple. Apple only manufactures their own devices which I think is a good practice but I believe the Google path of dual manufacturing was even better. This allows people to still have choices but at the same time they can get a pure Google device. I think with Android the more choices for manufacture’s the better. Google shouldn’t give less choices as it could upset their user base when they have no choice to get a pure Google device.