Tag Archives: ruby

Automating simple tasks

When I first started my development career I was nervous about scripting things. I felt that if I wasn’t using some sort of GUI tool I had a higher potential for error. So I was afraid to automate my tasks even the most simple ones. I thought the risk wasn’t worth the reward. I thought if it only takes me a minute each time to do that task why would I spend more than that time creating an automated script. As I gain more experience in my career my view has changed on this. The turning point was only a couple of days ago. Over the holiday break I read The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) and it really opened my eyes that everything we do over and over again should be automated. Not only tasks that take hours but even simple tasks that could take only a short period of time. So I started automating some of my work tasks. These are tasks that I repeat over and over again.

The first task that I automated was creating branches for Github. I found myself doing something similar to this over and over again.


git remote update; git co -b [ticketId]_description upstream/[branch]; git push [repo] [branch]

This process would only take me a little bit of time. I had never thought about automating it because the time it took wasn’t very long. After reading the book I decided to give it a try to see if it made it easier or faster. It turns out that I now save over half the time per branch creation. It may not seem like a lot of time at first but when you do it multiple times per day it adds up.

After I automated that process I thought what other tasks do I do over and over again that could potentially be automated. At my job we create pull requests for each branch when it’s ready to be merged. We use Github so the process that I was following was to go up to Github and use the GUI provided. Well it turns out that Github has an API that is very easy to use. So I created a automated script for creating pull request’s. Now instead of it taking me a minute or more to create a simple pull request it takes around 10 seconds. Again the time savings adds up. For example most days I will create up to three or more pull requests per day. You can see how the time saved really adds up.

I wasn’t satisfied with that level of automated. So I decided to take it up another level. Each pull request we create we then need to turn around and go down to our ticket tracking system and put that pull request link in there. We use PivotalTracker for ticket tracking. Well that seems like a tedious task especially since I am already using the Github API to create the pull request. So I added that to my automated process. So now to make a pull request and update the ticket status I can do so in around 10 seconds. This allowed me to cut the whole process pull request to updating the ticket to be under 15 seconds. What use to take me more than a minute now takes under a half of a second.

The point of this post is that automating even the simplest of tasks is important. It can make a huge difference. My thought process now when I get a new task is how can I automate the tedious part of the task. That way I can spend more time dealing with complex issues that are not able to be automated. If you are new to automation I would start with something simple. Don’t try to automate your entire process through one script. Possibly create multiple smaller scripts so you can do it over time.

Thinking Sphinx on rails projects

I have been working with Thinking Sphinx for the past year and have made some observations. When I first started using it I thought it was a pretty neat tool. The concept is basically you define a set of relationships through a sphinx index. Then sphinx will build a query around them and cache that query for reuse. The query will be optimized so it will run very fast. This all works great when your talking about simple relationships. Which basically means a has_one or a has_many without a through relationship inside of the model. The problem with Sphinx is when you get into more complex datasets.

For example when you are creating a complex scope. Say you already created that scope using rails active record. You know that the scope works and you want sphinx to use that same scope. The issue is that sphinx makes you create the index in their format. So you are unable to reuse that same scope. It’s not a huge deal but it’s duplicating code just for indexing purposes. So if a future developer comes in and just updates the rails active record scope the sphinx indexing will be off. It might not even be noticeable until a user does a specific search. This can lead to bugs very easily.

Thinking sphinx also has a concept of indexes vs has. An index is a text object that will be able to be searched. A has relationship is made for numeric values so they can be sorted as a numeric value instead of a text value. So if you want one of these has relationships to be searchable you will need to define it as an index and has relationship. Another form a duplication where it should be smart enough to know if it’s indexed or has a has relationship it should be both sortable and searchable.

The last point as once you get a lot of data indexing is a pain. With a small amount of data indexing takes only around a minute. As you keep adding data the indexing process gets slower and slower. Eventually it takes a good half and hour to finish. It’s not a huge deal in a production environment that you can run indexing over night. The problem is when you are unable to have a slow time. If your site is getting hits all times of the day and even during the night you cannot slow it down for indexing. So you are kind of trapped in a way. Also indexing is a pain for developers. If they pull down a backup of the large dataset they have to wait that full indexing time before they can continue the development process. If they are working on a feature that they need to use the index for. The rest of the site will work just not the part that is using the sphinx index.

When you look at the big picture sphinx could be a great tool depending on the data set you have. For example if you have a complex dataset that requires a lot of joins sphinx probably isn’t the answer. It might be more pain to setup than it’s worth. If you have a simple table structure sphinx might be a great choice. It just all depends on how much data you have and how complex your data structure is. I would recommend exploring it but keeping in mind the more complex the structure the more time it takes to setup. Also the more data the longer indexing takes. So you have to weight that into if you are going to use this tool or not.

Rails verbose deprecation logging

We recently went though a upgrade from rails 3 to 4 at my company. During that process we encountered a lot of deprecation notices. Most are pretty standard and easy to find where to make the fix. Some are not, especially if they are coming from an external Gem. I found this post which describes how to print the full stack trace in the log instead of just the warning message Deprecation warnings full stack trace. To get this more verbose logging just add the following line to your config/application.rb file. This should go under the require ‘rails/all’ line.


ActiveSupport::Deprecation.debug = true

PHP Yii and Ruby on Rails Active Record

I have been using the Yii Framework for over two years now and have been using the Ruby on Rails framework for around the same time period. I have done various projects in each and thought I would share my experience. The scope of this post will just be the differences between active records. It will not go into other details about the two frameworks. The purpose of this post is also not to debate which one is better. The purpose is to simply give the differences between the two and show the capabilities of each. This will only cover some features of each it will not include all of the features.

Ruby on Rails

Ruby on Rails has a powerful active record implementation. For example if you want to find something by it’s primary key. You would write something like Model.find(:id). This would then return an active record object with the properties of that single item. You can also add multiple conditions by simply by calling the where method. It would look similar to this Model.where(id: 10, text: ‘whatever’). This will then return a set of active record objects instead of just the single object the find would return. If you know there will only be one result you can simply do .first to get the result back.

Another part of active record is scopes. You can create scopes within a model and call them directly instead of having to write the where conditions over again. So if you need to write a query multiple times it’s a sign that you should create a scope instead. A scope is just defined in the model and can use lambda to pass in dynamic parameters.

Associations is a big part of Rails or any framework for that matter. In Rails associations are very simply and if it’s a simple relationship is dead simple. For example a post can have many comments. At the top of your post model you would add in a has_many :comments. As long as the keys match up that’s all you have to do. You can also do more advanced relationship mappings to.

PHP Yii

Yii has a powerful active record implementation also but uses a different implementation method. For example if you want to find a record by it’s primary key you can simply do ModelName::model()->findByPk(‘key’);. That will return a single active record object back. If you need to do more advanced queries you can do it in two ways. The first is to call the findByAttributes method. That would looks something like ModelName::model()->findByAttributes(array(‘a’ => ‘test’, ‘b’ => ‘whatever’));. That implementation will also just return a single active record object back if found. For advanced queries you can also create a CDbCriteria object with the criteria generated. When you look at the documentation you will see the various attributes you can set. After setting the object you can then simply call your query like this ModelName::model()->find(CDbCritieriaObject);.

Yii also has support for scopes. Similar to Rails Yii scopes are also defined in that specific model. A scope is Yii is basically a short cut to creating the CDbCriteria object. You will be passing in very similar parameters. It’s just as powerful as CDbCriteria also so you can do advanced queries without much of an issue.

Associations are also a big part of the Yii framework. They take a little more code than the Rails framework though. For example to do a has_many relationship you have to define it like this.


public function relations() {

return array('relationshipName' => array(

self::HAS_MANY, 'RelationshipModelName', 'RelationshipModelNamePk'

),

),

);

 

As you can see it takes a little bit more code to define them. These can be auto generated though through the Gii tool. So they are not as big of a deal to code up as 99% of the work is done if not 100%.

Those are some of the difference between the two of them. There are a lot more differences and this only covers the surface. The goal of this post is really to just share that each can do very similar things just in different ways. If you end goal is to get something up and running I feel that both frameworks can handle that. It comes down to a preference between Ruby and PHP.