DaedTech

Stories about Software

By

The Joy of Adding Code to Github

These days, a good portion of my time is spent on overhead tasks: management tasks, strategy meetings, this sort of thing. In my role, I also am responsible for the broad architectural decisions. But what I don’t get to do nearly as often between 9 and 5 these days is write code. All of the code that I write is prototype code. I’m sure that I’m not unique in experiencing drift away from the keyboard at times in my career — some of you do too as well. As you move into senior or lead type roles and spend time doing things like code reviews, mentoring, etc, it happens. And if you really love programming — making a thing — you’ll feel a loss come with this.

Of course, feeling this loss doesn’t have to be the result of having more overhead or leadership responsibilities. It can happen if you find yourself working on a project with lots of nasty legacy code, where changes are agonizingly slow and error prone. It can happen in a shop with such intense and byzantine waterfall processes that most of your time is spent writing weird documents and ‘planning’ for coding. It can happen in an environment dominated by loudmouths and Expert Beginners where you’re forced by peer pressure or explicit order to do stupid things. It can happen when you’ve simply lost belief in the project on which you’re working or the organization for which you’re working. And it almost certainly will happen to you at some point in your career.

Some call it “burnout,” some call it “boredom” and some call it “losing your way.” It has a lot of names. All of them mean that you’re losing connection with the thing you’ve liked: programming, or making a thing out of nothing. And you need that. It’s your livelihood and, perhaps more importantly, your happiness. But, you can get it back, though, and it isn’t that hard.

Lightbulb

Recently, I decided to order a few more home automation pieces (blog to follow at some point) and reboot the design of my home automation server to make use of a Raspberry Pi and a REST service in Python. I don’t know the first thing about Python, but after the parts arrived, and I spent a few hours reading, poking around, failing, and configuring, I was using Fiddler to turn all the lights off downstairs (code on github now — work in progress).

There is nothing quite like the feeling of creating that new repository. It’s daunting; I’m about to start learning a new programming language and my efforts in it will most certainly be daily-WTF-worthy until I learn enough to be passingly idiomatic in that language. It’s frustrating; it took me 15 minutes to figure out how to reference another code file. It’s tiring; between a day job taking 50+ hours per week and the work I do with my blog and Pluralsight, I’m usually coding at midnight on school nights. But forget all that because it’s exhilarating ; there’s nothing like that feeling of embarking on a journey to build a new thing. The code is clean because you haven’t had a chance to hose it up yet. There is no one else to tell you how, what, or when because it’s entirely your vision. The pressure is off because there are no users, customers, or deadlines yet. It’s just you, building something, limited only by your own imagination.

And what a powerful feeling. If you’ve got a case of the professional blues, go out and grab this feeling. Go dream up some new project to start and chase after it. Recapture the enjoyment and the excitement of the desire to invent and create that probably got you into this stuff in the first place.

By

FeedPaper is Born!

As of Thursday, 11/02/12, a baby ASP MVC project named FeedPaper (later to be feedpapyr.us) has arrived. It is healthy and weights 0 pounds and 0 ounces. Both it and I are doing well, and while it does not yet have much in the way of functionality, it does have its father’s logo and some functional unit tests. (As an aside and leaving this strained metaphor, I’ve never really understood why the weight of babies is announced to me as if someone were trying to sell me a ham — what do I care how much anyone weighs? It’s always tempting for me to respond by saying, “big deal – I totally weigh more than that.”)

Anyway, you can find the source for it on Github. As I mentioned in a previous post, the main thing that I’m interested in is getting this thing up and running, so I’m happy to accept pull requests, suggestions, help, and anything else you’re willing to offer. The plan is to get it going as a website and then perhaps later port the presentation portion of it to phone/tablet implementations as well. But, no sense putting the cart before the horse — I have to figure out ASP MVC 4 first.

So, look for sporadic work on this when I have time and feel like tinkering and am not working on home automation with Java and MongoDB. I will also make posts here and there about lessons I learn as I ham-fist my way through it, talking about my experiences with the frameworks and toolsets involved. Also, in general, I’m looking for the best options for hosting the site, so suggestions are welcome (should I try out Azure, go a more traditional route, etc).

Cheers!

By

GitHub and Easy Moq

GitHub

Not too long ago, I signed up for GitHub. I had always used subversion for source control when given the choice, but the distributed nature of Git appealed to me, particularly since I often do work on a variety of different machines. GitHub itself appealed to me because it seemed like the perfect venue for reusable code that I’ve created over the years and tend to bring with me from project to project. Here is a unique idea – sites like Sourceforge want to store code by basic unit of “project” whereas GitHub wants code for the sake of code. This code need not be finished or polished or distributed on any kind of release schedule. That is perfect for a lot of my portable code.

One thing that I noticed about GitHub upon arrival was the lack of .NET work there, compared with other technologies. There is some, but not a lot. Presumably this is because sites like Code Project already offer this kind of thing to the .NET community. After reading about Phil Haack leaving Microsoft to be GitHub’s Windows Ambassador, I decided that this was a good indicator that GitHub was serious about growing that portion of its user base, and that I’d start porting some of my code there.

Another thing that I’d read about git before trying it out was that it has a steep learning curve. To back my general impression of this as a widely held opinion, I did a quick google search and ran across this post.

Given the steep learning curve many (including myself) experience with Git, I think I can safely assume that many other people have this sort of problem with it.

So, there’s at least one person who has experienced a steep learning curve and at least one other person with the same general sense as me about many finding the learning curve steep.

I must say, I haven’t found this to be the case. Perhaps it’s my comfort with Linux command line interaction or perhaps it’s my years of experience using and administering SVN, but whatever it is, I read the GitHub primer and was up and running. And, I don’t mean that I was up and running with commits to my local repository, but I was up and running committing, pushing to GitHub, and pulling that source to a second computer where I was able to build and run it. Granted, I haven’t forked/branched/merged yet, but after a day of using it, I was at the point where the source control system retreated into the mental background where it belongs, serving as a tool I’m taking for granted rather than a mental obstacle (by contrast, even with a couple of years of experience with Rational Clear Case, I still have to set aside extra development time to get it to do what I want, but I digress, since I don’t believe that’s a simple case of needling to mount a learning curve). So, after a day, I’m developing according to my schedule and running a commit when I feel like taking a break and/or a push when I want to update GitHub’s version. I’m sure I’ll be hitting google or StackOverflow here and there, but so far so good.

Easy Moq

So, what am I doing with my first GitHub project? It’s something that I’m calling Easy Moq. I use Moq as my main mocking framework, as I’ve mentioned before, and I’ve had enough time with it to find that I have a certain set of standard setup patterns. Over the course of time, I’ve refined these to the point where they become oft-repeated boilerplate, and I’ve abstracted this boilerplate into various methods and other utilities that I use. Up until now, this has varied a bit as I go, and I email it to myself or upload the classes to my web server or something like that.

But, I’m tired of this hodgepodge approach, and this seems like the perfect use case for trying out GitHub. So, I’m looking over my various projects and my use of Moq and creating my own personal Easy Moq library. If others find it useful, so much the better – please feel free to keep up with it, fork it, add to it, etc.

At the time of writing, I have three goals in mind (these may change as I TDD my way through and start eating my own dog food on real projects). In no particular order:

  • Create Mock inheritors that default to having specific test double behavior – dummies, stubs, spies, etc.
  • Be able to create and use my doubles with the semantics Dummy() or new Spy() rather than new Mock().Object
  • Be able to generate an actual class under test with all dependencies mocked as Dummy, Stub, Spy, etc.

For the first goal, I’ll refer to Niraj’s take on the taxonomy of test doubles. I haven’t yet decided exactly how I’ll define the particular doubles, but the ideas in that post are good background for my aims. Up to this point, if I want to create one of these things with Moq, I instantiate the double in the same fashion and my setup differs. I’d like to make the declaration semantics more expressive — declaring a DummyMock is more expressive as to your intent with the test than creating a Mock and doing nothing else to set it up. For more complicated doubles, this also has the pleasant effect of eliminating manual boilerplate like “SetupAllProperties()”.

For the second goal, this is probably lowest priority, but I’d like to be able to think of the doubles as entities unto themselves rather than wrappers that contain the entity that I want. It may seem like a small thing, but I’m a bit of a stickler (fanatic at times) for clear, declarative semantics.

For the third part, it’d be nice to add a dependency to a class and not have to go back and slaughter test classes with “Find and Replace” to change all calls to new Foo(bar) to new Foo(bar, baz), along with Baz’s setup overhead, particularly when those old tests, by definition, do not care about Baz. I realize that there is already a tool designed to do this (called AutoMoq), but it appears to be for use specifically with Unity. And besides, this is more about me organizing and standardizing my own existing code as well as getting to know GitHub.

So, that’s my first pet project contribution to Git Hub. If anyone gets any mileage out of it, Cheers. :)

Acknowledgements | Contact | About | Social Media