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^

Ubuntu Server Not Defaulting Properly

I run an Ubuntu server and had it all setup for some time now. I never really had an issue like today come up until now. I was baffled into what could have went wrong. I didn’t even touch it but for some reason it just broke. I noticed that I was unable to get to my site using localhost like I always use to be able to do. After doing some research I found a solution that fixed it for my server.

When I initially setup my server I followed this guide and everything worked out great. Anybody looking to setup a LAMP stack server I would recommend reading this first. Even if you think you know what your doing this guide will make sure you don’t miss anything. Okay back to how I fixed my specific issue. I noticed that it wasn’t defaulting to any project. After thinking about it for some time it came to mind maybe the default project somehow got enabled again. So the fix turned out to be very simple. I just had to disable the default project again and it works great again.


sudo a2dissite default

Android Sync Adapter or Direct API Access

I am starting to develop a new Android application and am torn between using Androids Sync Adapter or just calling the API directly like I did with pervious applications. I can see benefits to each. I see some applications use Sync Adapters while others seem just as fast and are not using Sync adapters. It doesn’t seem like Android really has a standard of which one to choose and which situation you should choose one over the other. It seemed from my readings that Sync Adapters are the new standard but I just don’t see many applications using them. I see benefits and consequences to using each. I am having trouble choosing as I want this application to do everything to the Android standard. I see a lot of benefits to using direct API access again.

First I have been using direct API access for some years now so for me I already know what I need to do to connect to the API. I already have the code needed to perform json encoding tasks. Another benefits as I never have to worry about the data getting out of sync. The process will happen as the user saves the form or deletes the record. So the web server and application will always have the same data along with primary keys. Also if the user looses their device or gets a new device they don’t have to worry about the syncing not working. Their data is always safe on the server. To me it just feels a little more safe as I know the users data is up on the server if they get the saved response back. Otherwise they will get an error right away of errors they need to fix.

There are also some consequences to using direct API access. The biggest one is that it requires the user to always have a network connection while using the application. Some of that can be minimized by caching though. I tend to think phone networks are getting faster and have more coverage but there are some users that are unable to connect for some reason. Even with WiFi hotspots being all around again some users are unable to find them when using the application. This leave a negative impact to the user as they find the application useless without that connection. This makes it hard to complete with applications that do not require a network connection to work. Even though the data is not being sync to the cloud and therefore could be lost easily. The end user does not see this benefit in some cases.

There are benefits to going with the sync adapter method from my initial research. Which to be honest with you wasn’t a ton maybe three or four hours reading through the Android documentation. The first benefits with the sync adapter as you don’t have to worry about the network connection at all. The sync adapter handles that for you. It will check if the network is available and if it’s not it will wait tell it’s available This will give your users an offline mode while still getting the data backed up when it’s possible. Also this is built into the Android framework so it is relatively easy to learn and use. There are plenty of examples of how to use it on the web.

There are also some consequences to using the sync adapter. The first one that I see is you have to create a local schema using SQLLite that basically mirrors what your web server is doing. So every time you make a database change on your server you have to make that same change to the Android application. Also any business logic that your web server is performing has to be done the same way on the Android application. Since the sync adapter may not run the second the users submits the data you need to have your Android application verify that the data being saved will save on the web server. You could get around this by checking that the syncing process finishing successfully and if it doesn’t pass the failure onto the user at that time. The problem I see with that is it could end up frustrating the user. They might not remember exactly what they intended to do at the time. Depending on how long their device was offline for. It could be a day it could be weeks who knows. So maybe they entered a number incorrectly but have since forgotten what it was. Seems like you would have to be repeating business logic across the environments.

These are the thoughts that have going through my mind as I am starting this new application. According to Google using the sync adapter is considered the best approach. At least it seemed that way although the documentation did not say so. An example that I found on my device that uses sync adapters is Dropbox. I am not sure that my application would need such a thing. I almost feel like sync adapters are made for applications that are always looking to get data like an email client or Dropbox. You can setup syncing times or intervals. Is there a better way of getting data in and out other than these two options? Also if you go the direct API route can you cache it locally still and sync the next time the application starts up?

WordPress very simple

I did some work using WordPress maybe three years ago and wasn’t very impressed with the code base. I thought it was too cumbersome and wasn’t very well organized. So when I created this blog I initially used another blogging engine thinking that WordPress was just too bulky. I was totally wrong and after using it over the past couple of weeks I think WordPress is by far the best blogging engine.

It’s so easy to get it up and going. I actually was able to get it up and going in under ten minutes. That is from start to finish including download and upload times. I also find that the interface is very easy to use and very modern. I was able to install a couple of plugins without an issue. Very impressed with how easy the install process really is. I never really installed plugins so to me that was very impressive. No development skills needed. There is also a ton of great free plugins. So really for a standard blog no work is needed. You can literally be up and running in minutes. I don’t think I will go back to modifying WordPress code though. I believe that is where my impression came in as I was doing custom development within a WordPress site. Yes you can do this but then you start to have to deal with the internals. I am guessing the code base is cleaned up by now though. To sum it up keep it up WordPress I will be a user of yours for a long time.