Monthly Archives: April 2014

Yii CNumberFormatter FormatPercentage Sucks

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.

class Percentage extends CNumberFormatter {
    public function __construct() {
        // pass in en_US by default this could be expanded in the future for more currency

    public function init() {

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


I started using Vagrant just over a year ago. When I first started using it I didn’t know much about it. To use it you really don’t need to know much about it either. The concept of vagrant is you create your development environment in a virtual box and then use vagrant’s technology to connect to it. This connect is like a regular SSH connection but also has various other features. Vagrant basically supplies a way to make the virtual box act as a server. I recently had to create my own vagrant box from start to finish and had an interesting experience. Overall the experience was good and it went pretty smooth. For not knowing what I was doing at first I was able to get everything installed and running within five hours.  That’s not to bad when you add in download time and reading about how to do things. If you need to know how to install vagrant I would follow the documentation as it was well done. While doing the instal through I found some advantages and disadvantages to using vagrant.

I see a lot of advantage to vagrant. The first of course is you can create a vagrant box and then deploy it to many machines. So one developer on your team spends the time creating the box and the rest of the team benefits by not having to create it themselves. They simply can download the .box file and vagrant up. It’s that easy. This is a great time saver when you have a team. Even if you are by yourself it can be a time saver if you ever switch machines. Another advantage is everybody on the team is literally using the same environment. This is everything from OS version down to package version. This can be important especially if a major version is the difference. You can also start with a predefined box using Vagrant Cloud. For example you could start with a fresh Ubuntu box or you could search for specific package you need installed. This can save you time because you don’t have to do all of the installation process yourself. Even thought there is a lot of good there is some downside to using Vagrant.

First you have to be running a virtual machine using either VirtualBox or VMWare. This can slow down your machine and it takes extra resources. So if you have a machine that is not very powerful this can be a huge burden. Another disadvantage is everything has to go through that server connection. So when you access localhost:3000 it has to call the virtual server and run through that. This will add a little bit of overhead compared to just running it on your local machine. This can be a little frustrating to deal with if you are use to developing on your local machine.

To sum it up I think Vagrant is a great tool and has really advanced over the last year. Vagrant Cloud looks super neat and is a great idea. To share these environments should help developers for years to come. The biggest pain for a developer is to setup their environment. Vagrant makes that whole process a whole lot easier.

Test Driven Development

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.

Git rebase reset HEAD

One command that I find important when doing a Git rebase is.

git reset HEAD\^

This will reset your commit back during an interactive rebase and then you can do an add -p or whatever you want with the files. It really allows you to start with a fresh change set on that given commit. If you are not using ZSH you should but you don’t need to escape the carrot so it would look like this.

git reset HEAD^