Monthly Archives: March 2014

Don’t blame Jenkins (all the time)

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

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

}

});

Importance of css files

When I first started my development career I used a lot of inline styles. At the time my thought process was that is seemed easier than creating a css file. Then putting that style in a file. Then include it on my page. Especially if it wasn’t a reusable style and specific to that page. I figured if I could just do inline style’s I could save time and get the same results. Especially if it was an easy style say a style with only one property. I recently got burned by this when I started writing a mobile version of my site. Lucky enough I did not have a ton of inline styles laying around still. I had moved most of them into some type of css property. Now that I went through this experience of creating a mobile version of my site I will never use inline style’s. Even if it’s easier at the time than going through the work of putting it into a css file. Also even if it’s just a unique css property that won’t be reused throughout the site. I guess you never really know if it will be reused in the future anyways.
One example that I ran into was with the forms that take in the data. The div wrapping the form did have a class associated with it but it was being overridden by an inline style. So even if I changed the forms css class properties it will still getting overridden by that inline style. Lucky again I had only done this for a handful of places. So the update process was fairly simple. and did not take that long. But if I didn’t have that style overridden by my inline style I could have just updated the css class in a different css file and included that. Instead of that I had to go into each template I over road the style take that out and turn it into a css class. The end result is what I want but to get there took longer than it would have. I am now able to change the style of my page without touching the HTML. Also if I need to add a new theme to my project I can do so very easily and not have to touch the HTML. At least for styling purposes.
I also took this a step further in my project. I noticed that I liked most of the styles. Most where what’s considered responsive design elements. So no matter the screen size they will work. There was only a select few that needed to be changed. So instead of duplicating all css files I modified my code base to handle it and take the mobile theme first if it exists. Inside my code base I include my css and javascript files through a helper method. This allowed me to manipulate the path based on the current theme. So I manipulated that method so that if a css file exists under the new theme for example mobile it will take that otherwise it will default to the css or javascript file’s already in place. This allow’s me to limit the amount of duplication within css classes. It was a nice way to have a clean cutoff to. The whole process went very smooth. Now I can create something like form.css and include it and until I need to override a properly keep it in one place. One I need to override a property I can simply create a new form.css file under mobile and go for it. It allows the whole process to be more flexible.
To sum it up I recommend no matter what even if it’s one property of a css element put it into some type of css file and include it. If you setup your application correctly this will not take long to do. In my application it’s as simple as adding the file and then adding the path to an array. From there the application handles the rest.