DaedTech

Stories about Software

By

Feed Paper: Help Yourself To My Intellectual Property

The Pledge

When it comes to US intellectual property law, specifically patents as they pertain to software, I have a very scorched Earth philosophy. Don’t tweak it. Don’t reform it. Don’t debate over it. Don’t worry about it. Just delete it. Yes, to me, it’s like a nasty, tangled mass of bad code where it’s easier to get rid of it and address what breaks than it is to try to salvage it in its current form. I understand the need for patents on things such as medicines that have prohibitive startup investment cost, but when it comes to things like “gravity” effects on your cell phone, it’s just not worth having a system where established powerhouses can bury the little guy or blast away at each other and drive up costs, benefiting no one but lawyers. But, this post is not intended to spark a debate about ownership of ideas and intellectual property.

Instead, I’m putting my money where my mouth is. I’m going to give away what I think could be a pretty cool and viable idea. Why? Well, because I’m not exactly made of time, and I’d rather trade the small chance that I’d ever parlay this into a winning business idea for the slightly greater chance that someone might take it and run with it (or point me to it if it already exists). In other words, I want this thing enough that I just want someone to do it. Maybe one day I’d get around to it, but if you want to do it first, faster, and better, please be my guest.

The Turn

Every day in my feed reader, an entry from Alvin Ashcraft called “Dew Drop” appears. Here is one such entry. It’s a link collection that he dutifully fills out every day, organizing by category. In the linked entry, he has “Top Links” at, well, the top, followed by Web Development, XAML, etc, ending up eventually with a set of other link collections and a book. You know what this reminds me of? A newspaper. I mean, the “Top Links” is pretty obviously “Front Page”, and then you’ve got your .NET equivalent of Business, Metro, Sports, Politics, etc.

Morning Dew is a nice collection of links, as are some of the others also linked in there (I personally look at Jason Haley’s and the Morning Brew a lot). And, if those weren’t enough, I have my own collection of links. Pictured here, in alphabetical order, are the ones that fit on my screen:

As you can see, my screen just barely fits A through C. So, I have an alphabetized list of feeds that have some parenthetical number of unread articles, and some of those articles have links to even more articles, some of which I may already have in my reader, and others that I don’t. In some of these places, some of these things are summarized, and in others, I may just have to go go with the title or the author. I think we can do better, so I propose “FeedPapyr”. Feedpaper.com was taken, so I bought the domain feedpapyr.us (see what I did there?) for 6 bucks.

What I envision is pretty simple. At its core, the site is just a feed reader. But, instead of having laundry lists of feeds, you create newspapers. You categorize the feeds into custom defined sections and the reader handles truncating them to fit into a newspaper-style layout. If the posts have images with them, those are rendered as well. They are not formatted in full post form, but rather somewhat like the view on the right in my google reader screenshot, but like a newspaper. And, when you click on an article, it “pops out” with a focused, higher z-index feel window as you read it, and retreats back when you’re done with it (there’s no need to preserve the whole “continued on page 22” thing with the actual paper). Users can “thumb through” the paper, starting with their “Top Links” and delving into other sections if they have time. They can add to the size of their papers over the course of time, promote and demote things, and swap in and out content creators. I feel that this format would lend itself particularly well to consumption of tablet or ultra book devices.

A user can create an arbitrary number of papers, just as in real life one might subscribe to multiple newspapers. I personally would love this. I’d definitely have at least one programming paper, but probably also one about Chicago sports, one about science/technology, etc. It could have ads just like normal papers to finance it, and offer a “subscribe to avoid the ads” model as well (but financing is a little far afield right now). It would basically be a newspaper that was auto-formatted for the reader with custom content that was specifically chosen and subscribed to by the reader on a case by case basis.

The Prestige

It’s not normally my style to go buying up domain names on a whim, but feedpapyr.us is now in my possession. If this idea is something that interests you, please get in touch with me. I’m happy to brainstorm and collaborate but if you think it’s something you’d really like to run with, I’m perfectly happy to let you have the domain name (of course, maybe you don’t like that name and would rather have your own anyway). If this is all a moot point because something like this already exists and I’m just a clueless idiot, please, please point me at it because I would love it. At the end of the day, I’d like to see this get done and I don’t have a lot of time. Sooner or later, I’m going to build myself a “feedpapyr” because I just want one. But, if someone builds one first that I can use, so much the better.

By

Unit Testing DateTime.Now Without Isolation

My friend Paul pointed something out to me the other day regarding my post about TDD even when you have to discard tests. I believe that this trick was taken from the book Working Effectively With Legacy Code by Michael Feathers (though I haven’t yet read this one, so I can’t be positive.

I was writing some TDD test surrounding the following production method:

public virtual void SeedWithYearsSince(DropDownList list, int year)
{
    for (int index = year; index <= DateTime.Now.Year; index++)
        list.Items.Add(new ListItem(index.ToString()));
}

and the problem I was having is that any tests that I write and check in will be good through the end of 2012 and essentially have an expiration date of Jan 1st, 2013.

What Paul pointed out is that I could refactor this to the following:

protected virtual int CurrentYear
{
    get
    {
        return DateTime.Now.Year;
    }
}

public virtual void SeedWithYearsSince(DropDownList list, int year)
{
    for (int index = year; index <= CurrentYear; index++)
          list.Items.Add(new ListItem(index.ToString()));
    
}

And, once I've done that, I can introduce the following class into my test class:

public class CalenderDropDownFillerExtension : CalendarDropdownFiller
{
    private int _currentYear;
    protected override int CurrentYear
    {
        get
        {
            return _currentYear;
        }
    }

    public CalenderDropDownFillerExtension(DateTimeFormatInfo formatInfo, int yearToUse) : base(formatInfo)
    {
        _currentYear = yearToUse;
    }
            
}

With all that in place, I can write a test that no longer expires:

[TestMethod, Owner("ebd"), TestCategory("Proven"), TestCategory("Unit")]
public void Adds_Two_Items_When_Passed_2011()
{
    var filler = new CalenderDropDownFillerExtension(new DateTimeFormatInfo(), 2012);
    var list = new DropDownList();
    filler.SeedWithYearsSince(list, 2011);

    Assert.AreEqual(2, list.Items.Count);
}

In this test, I use the new class that requires me to specify the current year. It overrides the base class, which uses DateTime.Now in favor of the "current" year I've passed it, which has nothing to do with the non-deterministic quantity "Now". As a result, I can TDD 'til the cows come home and check everything in so that nobody accuses me of having a Canadian girlfriend. In other words, I get to have my cake and eat it too.

By

Announcement for RSS Subscribers: Switching Subscription Service

I am going to be switching services for RSS and content update notifications. Up until now, I’ve been using feedburner, which is a free service that has been around since I believe 2004 or so and was bought out by google in 2007. Since that acquisition, its best feature is that it is free. This is offset somewhat by pretty flaky statistics of subscriber counts and occasional burps in performance and function. However, a big drawback is that it seems as though google might kill the service. Making matters worse is the fact that google has done exactly nothing to illuminate the issue one way or the other, playing it close to the vest. “Don’t be evil, but you can be a little shady if you want.”

Other bloggers seem to be doing the same and a feedburner bug starting yesterday telling all users that we’ve lost all of our subscribers is turning the trickle of departing feedburner users into an exodus. Well one of my philosophies in life is that I like to depend as little as possible on other people and things, especially shady people and things. So, I am going to be hopping on that bandwagon and switching to FeedBlitz effective today or tomorrow (allowing enough time for this one last post to be sent out via feedburner). The good news is that this new service apparently allows readers to subscribe to posts through other media, such as receiving a tweet or a facebook/google-plus post rather than the traditional email or RSS notification. Progress and all that.

I have already created my FeedBlitz account and the migration guide from feedburner to this new service assures me that not one subscription will be interrupted… but, if your subscription is interrupted, that’s why. I intend to have a post Sunday night or Monday morning and if you don’t see something by then and want to continue reading, you may need to resubscribe through your RSS reader. Thanks for reading and for your patience!

Update: If you are subscribed directly to the Feedburner URL for the blog or for comments, please re-subscribe using the buttons on the right. These will automatically redirect you to the new, current FeedBlitz feed and you can delete your old subscription. If you are subscribed through my site directly, you need not do anything. Feel free to email/comment if you aren’t sure.

By

Regions Are a Code Smell

There’s a blogger named Iris Classon that writes a series of posts called “stupid questions”, where she essentially posts a discussion-fueling question once per day. Recently, I noticed one there called “Should I Use Regions in my Code?”, and the discussion that ensued seemed to be one of whether regions were helpful in organizing code or whether they constituted a code smell.

For those of you who are not C# developers, a C# region is a preprocessor directive that the Visual Studio IDE (and probably others) uses to provide entry points for collapsing and hiding code. Eclipse lets you collapse methods, and so does VS, but VS also gives you this way of pre-defining larger segments of code to collapse as well. Here is a before and after look:

(As an aside, if you use CodeRush, it makes the regions look much nicer when not collapsed — see image at the bottom of the post)

I have an odd position on this. I’ve gotten used to the practice because it’s simply been the coding standard on most projects that I’ve worked in the last few years, and so I find myself doing habitually even when working on my own stuff. But, I definitely think they’re a code smell. Actually, let me refine that. I think regions are more of a code deodorant or code cologne. When we get up in the morning, we shower and put on deodorant and maybe cologne/perfume before going about our daily business (most do, anyway). And not to be gross or cynical, but the reason that we do this is that we kind of expect that we’re going to naturally gravitate toward stinking throughout the day and we’re engaging in some preventative medicine.

This is how I view regions in C# code, in a sense. Making them a coding standard or best practice of sorts is like teaching your children (developers, in the metaphor) that not bathing is fine, so long as they religiously wear cologne. So, in the coding world, you’re saying to developers, “Put in your regions first so that I don’t have to look at your unwieldy methods, haphazard organization and gigantic classes once you inevitably write them.” You’re absolving them of the responsibility for keeping their code clean by providing and, in fact, mandating a way to make it look clean without being clean.

So how do I justify my hypocrisy on this subject of using them even while thinking that they tend to be problematic? Well, at the heart of it lies my striving for Clean Code, following SRP, small classes, and above all, TDD. When you practice TDD, it’s pretty hard to write bloated classes with lots of overloads, long methods and unnecessary state. TDD puts natural pressure on your code to stay lean, compact and focused in much the same way that regions remove that same pressure. It isn’t unusual for me to write classes and region them and to have the regions with their carriage returns before and after account for 20% of the lines of code in my class. To go back to the hygiene metaphor, I’m like someone who showers quite often and doesn’t sweat, but still wears deodorant and/or cologne. I’m engaging in a preventative measure that’s largely pointless but does no harm.

In the end, I have no interest in railing against regions. I don’t think that people who make messes and use regions to hide them are going to stop making messes if you tell them to stop using regions. I also don’t think using regions is inherently problematic; it can be nice to be able to hide whole conceptual groups of methods that don’t interest you for the moment when looking at a class. But I definitely think it bears mentioning that from a maintainability perspective, regions do not make your 800 or 8000 line classes any less awful and smelly than they would be a in language without regions.

By

Changing My Personal Coding Standards

Many moons ago, I blogged about creating a DX Core plugin and admitted that one of my main motivations for doing this was to automate conversion of my code to conform to a standard that I didn’t particularly care for. One of the conversions I introduced, as explained in that post, is that I like to prepend “my” as a prefix on local, method level variables to distinguish them from method parameters (they’re already distinguished from class fields, which are pretended with an underscore). I think my reasoning here was and continues to be solid, but I also think that it’s time for me to say goodbye to this coding convention.

It will be tough to do, as I’ve been in the habit of doing this for years. But after a few weeks, or perhaps even days, I’m sure I’ll be used to the new way of doing things. But why do this? Well I was mulling over a problem in the shower the other day when the idea first took hold. Lately, I’ve been having a problem where the “my” creeps its way into method parameters, thus completely defeating the purpose of this convention. This happens because over the last couple of years, I’ve been relying ever-more heavily on the “extract method” refactoring. Between Code Rush making this very easy and convenient, the Uncle Bob, clean-coding approach of “refactor ’til you drop”, and my preference for TDD, I constantly refactor methods, and this often results in what were local variables becoming method parameters but retaining their form-describing (misleading) “my”.

What to do? My first thought was “just be diligent about renaming method parameters”, but that clearly violates my philosophy that we should make the bad impossible. My second thought was to write my own refactoring and perform some behind-the-scenes black magic with the DXCore libraries, but that seems like complete overkill (albeit a fun thing to do). My third thought bonked me in the head seemingly out of nowhere: why not just stop using “my”?

I realized that the reasons I had for using it had been slowly phased out by changes my approach to coding. I wanted to be able to tell what scope a member was instantly by looking at it, but that’s pretty easy to do regardless of what you name them when you’re writing methods that are only a few lines long. It also becomes easy to tell the scope of things when you give longer, more descriptive names to local, instead of using constants. And techniques like command query separation make it rare that you need to worry about the scope of something before you alter it since the small method’s purpose (alteration or querying) should be readily apparent. Add to that the fact that other people I collaborate with at times seem not to be a fan of this practice, and the reasons to do it have all kind of slipped away for me except for the “I’ve always done it that way” reason, which I abhor.

The lesson here for me and hopefully for anyone reading is that every now and then, it’s a good idea to examine something you do out of pure habit and decide whether that thing makes sense any longer. The fact that something was once a good idea doesn’t mean that it always will be.