Tag Archives: yii

Wallproductions on Rails

Leave a reply

Wallproductions is a portal like site that will contain many applications. Currently it contains a couple of applications Gas Tracker and Budget Tracker. Both of these projects are live and are in production use. Over the years it’s gone through a couple of transformations. When it was first created it was a side project. It was something to work on during the weekends to see what was possible outside of what I was doing at work. The reason why the project started was due to a lack of existing applications that did what I wanted. So I set out to create my own.

When it was originally written it was done using PHP. It started out without an off the shel framework. This was a pretty good solution for a while until the project started to get larger. The larger it got the more I thought about it. I was thinking that a framework would be needed. Unless I wanted to spend all my weekends doing tedious things that were already done in the various frameworks. As the only developer working on the project it was important to be able to complete tasks with speed. So instead of creating everything myself I could use some shared code from the framework to handle all of the standard things. Things like ActiveRecord and Routing. So I looked around and I found a couple of frameworks. At the time the Yii framework seemed the most appropriate for my situation. The reason why I choose Yii instead of the other frameworks was simply because I was more familiar with how their ActiveRecord implementation worked. Also it had a pretty good extensions library so I could reuse code shared by others in the community. So I went with that and build the second version of Wallproductions off of it. This worked well and it stayed in the Yii framework for about two years.

During this period of time I change directions in my career and instead of doing PHP development I started doing Ruby development. Specifically working with Ruby on Rails. I did not know much about Ruby or Rails when I started. But after working with it for a short amount of time I was able to be more productive than ever before. Over the course of the next year Wallproductions stayed in the Yii framework. Making additional features and fixing existing bugs. Then the Yii framework introduced their new framework Yii 2. This was a complete rewrite of the framework. So I had a decision to make. Do I want to stay on the first version of Yii for a long time, do I want to rewrite the majority of my PHP code or just move to Ruby on Rails. Seeing that I work on Ruby on Rails on a daily basis it was an option. After carefully considering it I decided that I wanted to go with Ruby on Rails. So I set off on the path of rewriting my entire site using Ruby on Rails.

The first step was to gather all of the old requirements for the system. Then I needed to make sure that I met them. This was not very hard as I was the only developer on this project. Also since I wrote the entire application myself I didn’t need much documentation to understand it. Also I needed to set milestones for myself so I knew I was progressing. I didn’t want to get stuck and then have to go back. But I also didn’t want to keep spinning my wheels if it wasn’t going to work out. As I am sure you realize we all have had side projects that we start and then never finished. I decided early on that if I was going to put a ton of effort into converting Wallproductions I would finish.

The conversion itself actually went faster than I expected. I knew Ruby was very powerful and Rails added even more power to it. What I did not realize is how much power it added. I was able to convert something that I worked up for over three years in under three months. This was not your typical conversion either since it was going cross languages. Also I was not working on this conversion process full time. I was doing so like always on the weekends or nights after regular working hours. Now that I am on Ruby on Rails I am able to complete new tasks at greater speeds. At the end of the day I am glad that it’s on Ruby on Rails. I am a huge fan of the framework and the language. Also the community around it is really good.

Yii CNumberFormatter FormatPercentage Sucks

Leave a reply

I was working on some code that I wanted to use a number formatter on. In this specific project I use the Yii framework which provides a class called CNumberFormatter to handle such things. I was looking specifically for the formatPercentage method after digging around for a little bit.

I noticed that the method only takes in a raw number. Which seems very odd why wouldn’t you be able to pass in a precision. Not all percentages should be rounded with the same precision. So for example it would take in ‘0.245’. I would expect an easy way to override the currently rounding rules. But from the documentation I read that is not possible. The rounding rules for this specific case is barred deep inside the framework in a translation file. This would work great if everybody wanted to round their decimals up to the nearest decimal. So for example the number above would round to 3% not 2.45% as I wanted. After digging around for 15 or so minutes I gave up and just rolled my own formatter. It’s a pretty big disappointment that the framework is unable to handle such a simple request. In comparison I use Ruby on Rails for my daily job and they have a method that actually takes in a precision argument number_to_percentage. This forward thinking really makes me regret not starting this project out in Ruby on Rails. Of course when you have been coding on it for over five years it’s nearly impossible to get out. So I created my own extension and am going to roll with that for now. But it’s pretty disappointing when the framework isn’t able to help in these simple situations.

Here is my simple solution to the problem. All is well now.


<?php
class Percentage extends CNumberFormatter {
    public function __construct() {
        // pass in en_US by default this could be expanded in the future for more currency
        parent::__construct('en_US');
    }

    public function init() {
    }

    public function format($number, $roundTo=2) {
        return number_format(round(($number * 100),$roundTo), $roundTo).'%';
    }
}

Don’t blame Jenkins (all the time)

Leave a reply

I use Jenkins to run my Continuous Integration server. I am the sole developer on the project but I still find it useful to run the tests on a different machine. There are a couple of benefits to having a Jenkins server running. First of all it lets my local machine be available at all times. Meaning I am never taking up resources to run my entire test suite. Also I have a pretty large test suite so it’s nice not to have to wait for it to finish. Also the more selenium tests you have running the longer the process will take. Also when you run selenium tests locally it pops open the browser each time so you have to keep minimizing it. Moving on to the point of this post.

Usually when I have an issue with my Jenkins server I assume something happened during the test run. Jenkins must have not ran correctly no way can it be my code. Well I got burned by this. I let my Jenkins server runs fail for about a week before I really took the time to investigate the actual issue. I was assuming something happened specially with Jenkins. Maybe an update I did on Firefox or Jenkins. Well it turned out that it wasn’t Jenkins fault but instead it was mine. I had updated my code base to use the latest version of Yii but forgot to update the Jenkins server to that version. I did this a while ago so that is why I wasn’t thinking of it right away. I was not using the features of the latest version until my recent code push. To make a long story short always trust Jenkins and investigate issues right away. Most of the time it will be a problem with your code not how Jenkins is handling it. At the end I have a passing Continuous Integration server but the process took a lot longer than it should have.

JQuery Mobile Overview

Leave a reply

I recently added a mobile version of my website  wallproductions. I am using the Yii framework so telling which to render mobile vs desktop was pretty straight forward. The hard part was converting the current layout to be mobile friendly. Before I started manipulating my views to be mobile friendly I decided to do some research to see if a framework for this type of thing already existed. Lucky enough I came across JQuery Mobile which so far has been great. JQuery mobile provides a lot of the core structure you need to get started.

The first thing I did was added in a menu. For that I used  jquery-mobile-slide-menu which is an add-on to JQuery mobile. I find it to be easy enough to use and I can easily understand everything it’s doing. I believe there is a built it menu too but I think this one added a couple of smaller enhancements on. Which I found to be very useful. The next thing I did as I started to add in links for the new mobile pages. The routing was not changing so that was another simple step. There was one issue I ran into while adding these links. I noticed that my pages javascript was loading the on page load event. I did some research and found out that in jquery mobile that event won’t fire. At that point I had a choice to rewrite all of my existing javascript to use that new method or not use ajax links. I decided to go down the road of disabling ajax links and since then I have not had issues with my existing javascript. Here is the solution to turn off ajax links so everything you already have work as you would expect.

$.mobile.ajaxEnabled = false;

Another road that I went down before completely disabling the ajax links was to refresh the ajax page on each load. That seemed to work well in most cases but I had some that required a full DOM load. If you want to try to reload the DOMeach time and see if it works you for you then you can implement some javascript like this. This will tell JQuery that it needs to do a complete page refresh with each link click. You can enhance to support other elements like buttons to.


$('a').live('click', function(e) {

var url = $(this).attr('href');

if (url != '#' && url != '' && url != '/#') {

$.mobile.changePage( url, { reload: true, transition: "none"});

}

});

Fixtures Vs. Factories

2 Replies

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.