Joel Hainley

Work on Clik Clock is continuing at a rapid pace, there is still a lot of work to do but this weekend saw a major milestone reached. I am now able to enter/edit data using the UI that I have been designing for the Time Entry module. The other modules are all still being edited with the development UI but it’s getting closer. There’s something magical when the code you’ve been working on suddenly starts doing some small piece of what you’ve been envisioning. When it does enough that it can now support you in your efforts and you are able to “eat your own dogfood” it’s like it has taken it’s first breath and is now starting to take on a life of it’s own. It’s really a special time, at least for me.

Paul Graham ( the y combinator guy ) stated in the book Founders At Work that he wished they had setup an online store and sold SOMETHING so they would have had better insight into their customer experience. I can definitely see the value in this as I am more likely to overlook the bumps and bruises of something when I have my engineering hat on than when I have my user hat on. You get annoyed with things that you might not as a developer, watching fancy animations over and over again because they make the screen transitions cool comes to mind as something a developer might like but a user is going to eventually say “just get on with it.” I know powerpoint does a boatload of wipes and dissolves but I rarely see more than the default setting unless I’m watching the first handful of powerpoint presentations the person has made.

Anyways, I’m eating my own dogfood now and it tastes pretty damned good.

Shad, a fellow developer and good friend, and I were hiking a great new loop I found in Mt. Diablo State Park the other day and after solving the rest of the world’s problems we eventually came around to talking about things that were driving us nuts in our current projects. We both had recently found ourselves with code that was initially a quick and dirty library with a “Button 1″ interface. ( You know the type, programmer’s make them. They have a single command button on them and you click them and then they do stuff..and never notify you when they are done, and don’t resize and a host of other things that a normal UI should have ). These “Button 1″ quick and dirty apps have a nasty habit of turning themselves into indispensible tools for production/operations stuff.

The big problem we were both having was that while the apps were decent enough for their initial use we were being asked to extend them and both of us wanted to do some refactoring of the application before we released them into the wild. The best approach for this sort of thing is to develop unit tests so that, once refactored, we could be sure that we hadn’t broken anything important.

The biggest problem with dropping unit testing into an application after the fact is that sometimes you run into problems where you have to refactor just to get the unit tests access to all of the routines that you want to test. This isn’t an ideal situation, as you quickly end up wondering if you are breaking things just trying to get some unit tests built that are supposed to ensure you aren’t breaking anything. So you start wondering if instead of refactoring if you simply make functions that wrap your private functions and expose the behaviour might be the answer, pretty soon you have stuff everywhere and you wonder which is your testing code and which is your unit testing code to make all of this possible. Madness.

As we dropped off of the fire trail back into a heavily wooded area with a nice creek, it came up in conversation that perhaps partial classes were the way to go. If you haven’t used c# partial classes, you will. You can write class code in multiple files and yet at compile time it is assembled into a single logical unit. Several days later I had some free time and was able to verify that this would indeed work, I could drop all of my unit testing code into a single file that would provide all of the unit testing logic and wouldn’t muddy up the existing class. Furthermore, with a couple conditional complilation statements I could get rid of all of the unit testing code from the final release of the new library.

This is obviously not the approach you want to take if you can avoid it. It is arguable that you do not want your classes invaded in such a way for the purposes of unit testing. This is something you can work around if you use unit testing from the beginning, but what if you inherit a project and it doesn’t have any unit test capabilities built into it? What if the way that the classes are structured make unit testing pieces of the application difficult? Do you just plow forward and hope for the best? I hope not, and hopefully this stop gap measure to get unit tests built into the classes so that you can test existing functionality is the way to go. With these “nunit partials” in place you should be able to then start refactoring the rest of the application to be a little bit better structured for unit tests without having to risk dropping anything.

Recently I was working on a project and needed to proxy a request to a website that was returning a binary file.  I ran into some problems with my first pass at a solution. I believe the problem was a consequence of proxying binary data without getting at the underlying streams. I’m not sure how often I’ll need to do this, but I thought it might be useful to post here for others to know about in case they ran into the same problem I did. So here’s the code that worked for me, hopefully it’ll work for you too.

---

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(”http://to.some.binary.data”);
req.Timeout = “blah”;
req.Method = “GET”;

HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
Stream reader = resp.GetResponseStream();
// you might want to set your responses content type here
System.IO.Stream r = Response.OutputStream;

int Length = 256;
Byte [] buffer = new Byte[Length];

int bytesRead = reader.Read(buffer, 0, Length);
while(bytesRead > 0){
r.Write(buffer, 0, bytesRead);
bytesRead = reader.Read(buffer, 0, Length);
}

---

Hope that helps.

I was building out some .NET based web services for a Flex project I’ve been working on and bumped up against something that gave me a bit of trouble. When you create a .NET Web Service there is a namespace attribute associated with the service. Here’s an example (in c#) :

namespace HelloWebService
{
[WebService(Namespace = "http://www.examplenamespace.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]

public class Service1 : System.Web.Services.WebService
{

// implementation …

}

This value is required by .NET for a web service, or at the very least .NET gets VERY upset if this value is not set.

You will then need to let Flex know about this namespace in order to access the results. To do this you simply add the following lines to Flex:

private namespace lh = “http://www.examplenamespace.com/”;
use namespace lh;

Not much to it, but it can be a bit of a pain when you’re not aware of this. Flex doesn’t complain, it just gives you empty values when you try to access the values.

The first time I did some work with PHPUnit I was writing out tests in preparation for some refactoring. So I put together a bunch of tests for my utility classes, and pure logic classes etc, database access classes, etc. So everything was trucking along wonderfully, things are falling into place and then I run a test that tests some database stuff.

The application was setup with a configuration file that defined all of the database connection information, this file is included by the database library providing a single set of database routines to be shared by the application. Pretty standard stuff here. Perhaps in a nod to the rails/java crowds it could have been put in a non-code file and read in by the application but as far as I’m concerned that’s just personal preference. At some point you’ve got to have some configuration information somewhere and this works as well as anything.

So now that you know how things were setup, we’re back to the PHPUnit test…it bombed, failed, crashed, whatever. After digging into it a bit I discovered that PHPUnit has a problem with munging the global namespace when it runs. Things that are global variables can’t be pulled down into local scope because they don’t exist there anymore. I did some reading and found numerous complaints about this in the PHPUnit bug system, all of them closed with “this issue resolved” when the issue most assuredly had not been solved. I even found a conversation where one of the developers stated that it was not a bug, that the user simply needed to modify their code to work with PHPUnit. Huh? Modify the architecture of your code to work with a testing framework?!?

I spent some time thinking about this and I think it could be said that he’s right, but for the wrong reasons. First off, if this is a technical limitation of PHP then just say so and let it go. If it’s an implementation problem with PHPUnit then say so and try to put together plans to fix it. However, I think in this particular instance the problems that I was experiencing with PHPUnit could indicate a larger problem in my application.

Here’s how..One of the things that I hated when I first started using PHP was having to pull things out of the global namespace into the local namespace to use them. When PHP5 came out and the object model finally had a good amount of maturity I moved to utilizing classes for most of my code and this allowed me to start using the $this operator for accessing a lot of variables that I needed to deal with. In fact, the only place I was really using globals was in my library routines. After thinking about this for a bit I realized that it was much more convenient to wrap all of the configuration data into Singleton then I’d have a single object that I could use to get all data instead of having to pull in everything I needed one variable at a time.

It was at that moment that I realized if I had a singleton that housed all of the configuration data I could instantiate it in all of the routines where I needed to access configuration data and it would avoid the problems that PHPUnit had with the global namespace. When I looked in the todo’s for the configuration file there was an item at the top “Maybe I should turn this into a singleton”…two birds with one stone? Ten minutes of work and I had everything setup and ran my tests and “bingo” everything worked.

So in the end, modifying the way that configuration information is disseminated throughout the system by using a singleton has been “the right thing”. I had some heartache over the responses from the PHPUnit developers about the “solution” to the problem their users were having mostly because the solution involved a lot of extra crap with addressing the global namespace in a particular way. Using a singleton ended up providing the needed functionality, didn’t do anything retarded with variable access, and ended up making the application much cleaner to work with.