Category Archives: Development

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

}

});

Importance of css files

Leave a reply

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.

Tests using Git Concurrency Issue

Leave a reply

I was recently working on a Gem I created called Toolshed. The purpose of this tool is to turn everyday tasks into automated ones. At least to a certain degree. This will allow you more time to do the heavy lifting tasks. For example some of the functionality that this tool provides is creating a Github pull request, updating Pivotal ticket status as well as many Git more tasks. All of this would normally require you to go up into the sites interface click around and enter the data. As we all know that takes time and time is valuable. So down to the part that I had trouble with when I was creating tests for this tool.

I first started to create all of the tests locally and verify that they worked there. I had no trouble with this and everything appeared to be working. I was not getting any test failures. After creating a couple of them I wanted to see if I could get it working up on Travis CI. Travis works well with a ruby project plus since the Gem is open source it’s free. So I setup Travis and everything seemed to be working right. The first couple of runs seemed to pass without issue. Over the next few days I noticed that Travis was failing randomly. I would push up a small change and it would fail. I would run it again and it would pass using the same code base. It seemed random and a CI that has random failures is useless. The theory behind that is if errors happening randomly there they will also happen within your application. So I needed to investigate this further. Since I was unable to recreate the issues on my local machine I decided to try it out on a different machine. I created an ubuntu environment and started fresh. Once I got to that environment I was able to reproduce the problems I was having on Travis pretty easily. I was able to debug real time which helps instead of pushing new commits up to Travis.

What I noticed was that my Git commands were not finishing before it started the next one. So it would be doing a git remote update and then the next command would run before that finished. This would cause it to fail because it depend on remote update finishing first. So I had to create a solution for this and here is that solution.

until (system("git remote update"))
  sleep 1
end

This will sleep and wait until it hears a response. This will now wait for each command to run in it’s specific order. I have now tested it out several times on Travis and am no longer having this issue.

Gem Install Gone Wrong

Leave a reply

Today I was working on my Gem  Toolshed and wanted to install it globally. That way I wouldn’t have to add it to each of my projects Gemfile. Then run bundle install on each. The reason why I didn’t want to do that was first of all would take more time than I wanted. Also if I could just install it globally I wouldn’t have to worry about installing it for new projects. Also for this type of Gem it’s nice to be able to use it outside of a projects context. So I attempted to install it globally so that it could be used by all my projects. I am not too familiar with rvm or bundler to be honest. I have used both of them but I don’t understand enough about them to be called an expert. So I ran the following command in an attempt to install it globally. Note that I did not pull this command out of thin air I found it on a stackoverflow post and it looked promising.

gem install /home/path/to/gem

After spending several hours debugging it I finally figured out what was happening. Well it turns out that not only does that command not work but it also switches the gem install default to that directory. I figured this out through several debugging steps. The first step was when I went into a different project and did bundle install. This is a project that I have been working on for a while so I was expecting it to just work. Well when I ran bundle install I seen it was looking at my gems directory. I was thinking well something must be in the path and kind of just ignored it. I didn’t put the two together for a while. After thinking about it for a while I thought that bundler has to be smart enough to know my rvm is setup to use a specific gemset. Well it turns out that is not the case if you have a customized path like I did. It installs it to whatever directory you put in that path above. I verified that this was happening by going into my Gems directory and there is was a ruby directory with ruby installed. After doing some searching on how to fix it I found that this worked to reset the gem install back to the default directory.


bundle install --system

After doing that my system was back to normal and I was able to run bundle install again without any issues. I hope that this post can provide some insight that bundler and rvm don’t always work hand and hand. If you ever try the gem install command above remember to set it back so all your bundler commands work as expected. At least I can say I now understand more about bundler and rvm as a whole.

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.