Tag Archives: rails

Ruby Gems

I have been using Ruby for about two years now/ I have used various Gems throughout those years. I recently decided to look at more than just the popular gems out of curiosity. Sort of to see what is out there and what people are creating. While doing this I noticed that there is a lot of really crappy gems. Not only are there a lot of really crappy gems but some of them literally don’t do anything. They are just a stub when you run gem create [gemname]. I got to thinking why hasn’t Ruby put some system in place to verify that one the gems actually do something but two that they have some quality.

I feel that to fix this problem they need to implement  a rating system so if your gem gets voted down to much it should be removed. That name would then become available for others to use. A comparison I would make to this is the Android market. They have structure in place that at least makes you be semi serious about developing a good application. First you have to pay a fee to publish to the market. Now for Ruby gems that may not work because there is no profit being made off of these gems. More that Ruby gems needs to come up with some criteria that defines you to have the ability to create these gems. At the end of the day I’m sure it doesn’t matter that much but it’s annoying searching through a bunch of crap gems just to get to what you want. When you have been doing it long enough though you tend to know what are good gems and which ones are a waste of time.

Frameworks

When I started out my development career I thought the idea of a framework was stupid. If I already know the language then what was the point in learning a framework. It’s just another thing I have to know about. At the time my mindset was I can do anything the framework can do. Yeah I might have to spend the time coding it up but at least I understood it at the end. Also a lot of the core functionality you need when you are creating a site is built into the language itself. For example PHP has all of the date functions one would need. At the time PHP wasn’t really not an object oriented language either so there wasn’t frameworks built for it when I started my career. When PHP was enhanced to support objects they kind of came over time. At that time I was in the mindset that I didn’t want to learn a custom framework. Since I already was doing everything myself. Then it all changed when I worked at a company who started working with a framework. After struggling for a little bit while first learning it I am glad I spent the time.

The main benefit I see from a framework is consistency. If you start with a framework and follow the frameworks pattern’s your code base will be consistent. It makes adding new developers onto the team way easier also. You are able to point them to documentation already created. Also that documentation is always up to date. If you are rolling your own framework most of the time documentation is the last step or in most cases doesn’t get done. Not only will you have consistency but you will not trap yourself into a bad pattern. If you choose a popular framework you know it has been tested on a wide variety of applications. If it can handle all of those applications you know it can handle yours. Unless you are trying to do something way out there.

Another benefit from using a framework is you get to use the communities code. Most frameworks at least the good ones have some form of extensions. They are called something different with each framework. For example in the yiiframework they are called extensions while in ruby they are called gems. These extensions allow you to easily pull in code and modify it to your needs. You save yourself a ton of time by not having to write that datatable helper or the audit helper. A lot of this is already done. Why not use something you know is working for others? You can then focus your time on the important things. No need to reinvent the wheel.

There can be some drawbacks to using a framework. One thing we face these days is frameworks are becoming to heavy. They have a ton of code that projects may not use. Also they kind of force you into a certain way of doing things. You can always code your way out of it but it might take you extra time. Another drawback is if you fall behind on major versions. If you fall behind upgrading can be a big pain. If you don’t upgrade to the latest version you could have security issues or extension compatibility issues.

At the end of the day you want to get your website up and running super fast. When you have a framework to start with you can have a simple application up and running in minutes. Also you don’t want to spend you time writing common code that is already been done a million times by other developers. Instead you want to focus on creating the customized aspects of your website or product. Even though it does take a little investment learning the framework it’s well worth the time. After you learn one framework you will see the pattern throughout other frameworks will be very similar.

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.