I was considering ways of generating trees based upon tags and realized that there’s probably two ways to go about generating them. What brought me up short and made me think about writing this down was the following thought : ”when considering the hierarchical implications of tagging what we’re really doing when we tag something is indicating it’s ancestry”. I’m not sure this is really a new thought but it does lead to some interesting thoughts.
- We don’t generally consider tagging to be a hierarchical activity, but what would happen if we just tried some different models for constructing hierarchies from tagging. A perusal through set theory might yield some interesting thoughts on this idea.
- The whole concept of tagging is that we can add an ever increasing number of tags to an item to allow us to describe at some “meta” level what that item means to us. It’s your basic set theory sort of thing, I’ll add an item to this group and this group and this group. From a hierarchical perspective you could say that you are assigning a large number of parents to a particular group, and this seems goofy when you first consider it. This is probably due to connotations that ancestry brings up in our minds. Our DNA is determined solely by our ancestry. Consider a virus though, it can pick DNA up from a bunch of different sources and not just from it’s ancestors. I think I’m digressing.
- My initial idea of implementing a hierarchy was to simply take the tags and show them as children of an item, and to then do some funny business to show things farther down in the hierarchy with some algorithm to avoid duplicates. When I considered the point in item #1 above I realized that perhaps showing ancestry “downstream” instead of “upstream” ( that is, as branches/leafs of the subtree under a particular item ) might have some interesting implications.
I’m not sure there’s anything of value here, but it’s been interesting thinking about it..more later…maybe.
Mike challenged me to a contest, hopefully this one goes better than the last one.
The challenge : write a web-based application and release it to the world on or before November 5, whoever generates the most revenue between November 5 and January 5 wins. The only other requirement is a weekly development blog posting detailing status and the work on the agenda for the coming week.
The stakes : I think it’s either hot wings at Hooters or Wing Stop and maybe a case of Mountain Dew or Jolt…can you even buy Jolt anymore?
My project : ClikClock a time tracking program. I really want to do a good, solid, well thought out time tracking program because the few I’ve used drive me nuts. Everyone I talk to hates the applications that they are forced to use at work. So I’m going to give it a shot. See if I can make something that’s powerful and easy to use.
Update : I have had several false starts on ClikCLock in the past but I want to get this idea out of my system, because I’ve had thoughts about doing it for so long. I have written a couple of partial implementations and was reasonably happy with how things were turning out. However some business reasons ultimately forced a rewrite on a different technology platform. On May 1 I opened up an editor and started the current implementation of ClikClock. Since then I’ve written my own MVC framework and have integrated Doctrine and Smarty to create a pretty nice framework to do development in. I had to build a lot of stuff in the beginning to get things working that I wouldn’t have had to build if I had used one of the existing frameworks but I had a desire to build the framework and quite frankly it only took between 4-6 hours to build out the MVC framework and It’s WICKED fast.
I have also decided to use git for this project so I’ve been learning that as I go along. So far I like it but I haven’t had to do anything too crazy with it yet.
Tasks for the week :
- New Account Setup wizard
- Account Administration screens
- Build out the Account Configuration system
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.