Tag Archives: php

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).'%';
    }
}

Test Driven Development

Leave a reply

In theory you should always write tests while you are developing your code. In the software industry this is called test driven development . This practice will usually generate some good thoughts about how you can make the code more robust and more reusable. It’s very difficult to change architecture after you have coded yourself into a hole. It’s a whole lot easier to do it right the first time than going back a second time and refactoring what you did the first time. When you have to go back and write your tests after you wrote the code it will tend to cause more rework versus writing the tests before you actual develop the code. Sometimes it’s hard to write tests as you go as requirements are changing all the time. This can cause frustration because you feel your tests are wasted time. A common excuse I hear is requirements are always changing so I have to go back there anyways. But if your developing the code the requirements are usually pretty set at that point. At least the overall idea. Maybe the guts of the code will change but the public interface shall remain the same (at least close to the same). I had an experience on a project that I am working on that made this point pretty clear. My task within the project was the write some tests around existing code. Basically adding code coverage to an existing model. Seems simply enough until I started looking into the model and discovered a lot of very tightly coupled code. A lot of tightly coupled public interface code.

Starting this process I was able to test a lot of the public interface. The parts that were not tightly coupled. Maybe about half of the public methods were in a testable state. A unit testable state to be exact. Then I ran into a major road block. I ran into some public interface methods that required a chain of methods to be called first in order to be able to test them. If TDD was used during development process this would have been avoided. The developer would have realized that the code was to coupled to be tested. So instead of saving that time I spent even more time refactoring and trying to decouple the methods. The end solution ended up a lot better but it required a lot more effort than just writing the test before the code or at least right after you have written your code.

It’s a good practice to get into even though at first it may be difficult to get into the habit. It’s even harder to do it on a regular basis when things are moving so fast. I believe that once you get good at it though it become’s natural and really part of your process. Also the more familiar you are with architecture in general and architecture within the project the easier it will become. You can see your vision ahead of time and predict what the code should look like. To sum it up always write your tests as you go. If you need to write them after your code that’s better than leaving them and letting them get behind.

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"});

}

});