Complacency

During the last half of 2014, I feel like I really got myself in a rut. I
wasn't learning anything new. I didn't take as much pride in my craft. There's
no doubt about it, I stopped challenging myself and got complacent. I'm sure I
could find several good excuses for why things reached that point, but the
responsibility is mine alone. (Unfortunately, the blog host doesn't support
embedded YouTube videos, so I have to old school link it) Reminds me of this
great clip from
Rocky 6. The point is, it's time to up my game.

I've been reading a lot about test driven development (TDD) lately. For a
long time, my thoughts on the subject of testing were that it's BORING, not
value added, and difficult. One of the really intriguing advantages that I read
about was how well executed TDD enables and enhances code refactoring. It
really is a great feeling to know that you can change your code and not worry
that you're missing some edge case that you'll have to go back and fix again.
That is a huge positive in my book. But it always seemed like a huge amount of
work.

But Testing is Hard

Most of the projects I work on are very small scale, a few hundred lines of
code, maybe. And most of that is UI work. I have done a few projects with a few
thousand lines of code. In those cases, I think some automated testing could
have been beneficial. But for the most part, it really felt like testing was
something for people that didn't write solid enough code and something for
projects with teams of developers. To burden myself with that level of process
and overhead just seemed like a good way to slow me down and grind down my
motivation and desire to develop even further. I've got solutions to get out
the door. Still, I couldn't help but feel that I was missing out on something
very significant.

Every developer on the planet has
their own way of writing code, their own style choices that make them
unique. So, while there are some best practices that are widely recognized, we
still start with a blank canvas. The code we write has to meet the needs of the
customers and has to be reliable. Usually beyond that, all bets are off. In
larger teams there are a lot of opportunities for peer review and more
experienced folks to guide one along. On open source projects, there's a huge
potential audience. I would certainly feel pressured to put out a higher
quality product if I knew more people were viewing it and raising their
eyebrows at my complacency or convoluted attempts at logic.

What a Fool I've Been

I'm pretty sure it's worse to know better and still do something sloppily,
than to do it out of ignorance. It's a pretty horrible thing to have to admit.
If one doesn't handle a simple project properly, how can they possibly be
expected to handle a project that's an order or two more complex? But still,
I'm lazy (which isn't always a bad thing for a developer) and loathe to put a
lot of time into improving code that maybe me and one other developer will ever
see. And besides, how can I have any confidence that I'm actually getting at a
better end product anyway? There are code metrics tools, but they don't really
guide you, they validate.

And here is where the testing component comes back into play. Because
designing the solution to be testable from the ground up enforces the loose
coupling and modularity we desire. If I write a solution to fetch data from a
database and display it on a web page via a web service and client scripting,
I'm liable to combine functions in ways that make testing extremely difficult.
And because of how I inadvertently coupled things, it becomes a huge task to
refactor. Then, I don't want to refactor the solution because I don't want to
manually retest things to make sure I didn't break anything important. Which
leaves me with a blob of code that works, is logical and easy to follow, but is
not satisfying, is not truly elegant.

I'm not dogmatic about very many technology choices or design decisions.
Blindly following a process, approach, or methodology simply because it yielded
results for some other project or in a different environment is, in my view, a
recipe for disaster. One must first understand the reason an approach has been
successful. What are the major characteristics and do those factors make sense
in the present context? TDD is not the silver bullet. It is still possible to
produce a horrific system within that framework, but I think it will help me
get to the next level and I'm excited about the journey!

There's so much happening in the realm of software development right now,
it's so great to be a part of the field. It's exciting, exhausting, terrific
and terrifying. Things are advancing at a tremendous rate, and I doubt it will
slow down anytime soon. I've just finished setting up Gulp to help with
automating my development workflow. I also finished configuring NodeJS on my web instance (hosted on A Small Orange),
and on my local Windows development machine. Last night I was laying down and
watching the AFC Championship game and reading Reddit. And my sense of
accomplishment started to drain away. Why? Because NodeJS is getting pressed by
io.js. Express, the main middleware layer for
Node has a next generation called Koa. Even
Javascript itself is shifting under my feet with ECMAScript 6 finally starting
to become a reality. I just discovered 6to5, a
transpiler than converts your ECMAScript 6 code into ECMAScript 5. I like to
think that I'm able to keep up with what's going on. I may not know all the
fine points, but I can track the major muscle movements. I knew about ES6, but
I didn't realize it was as far along as it is. I spend the vast majority of my
work hours coding for the browser. Wide support for client-side ES6 is probably
a year out for the newest browsers. Then how much longer will it take before
the installed base gets upgraded? It will be a long time before one can count
on native ES6 support. But as long as you can convert your preferred language
into something supportable by the browser, you're golden. Right? Well, that's
where things start to get messy. Now you've got your server code in one
language, your client code in another language, and you're using some libraries
written in another language. Then you're transpiling everything into another
language for deployment. I should probably spend some time considering how
real-time translation and language conversion come together. Microsoft's Roslyn
project can take VB and convert it into C# (and vice versa). What if we had
some sort of common browser intermediary language? Sounds a lot like the JVM or
CIL. I found a couple of interesting discussions about this. One on
stackoverflow and one from Scott
Hanselman. So, how can I bring this back around and wrap it all up into a
nice tidy package? I guess the main point of this all is that there are very
few things that endure, and that the best solution isn't always the one that
wins, because life is full of variables that we can't account for. The good
news is that things tend to get better over time. Remember when SOAP and XML
was the hot way to do web services? Javascript isn't great, but I think it is
where we will be until then next big thing comes along. And that is.... the
Internet of Things! (Just kidding... maybe.)

I've been thinking a lot lately about the future. The trigger for this
recent bout of techno-daydreaming was a Wired
article, posted to
Reddit.com. The shutdown of the US Federal Government and sequestration
furloughs during the Summer already had me thinking about the economy. The
tenuous, and reportedly uneven economic recovery the US has been experiencing
had me starting to wonder whether or not this economic cycle really is
different than those preceding it.

There has been a lot of talk about the jobless economic recovery. And
although some companies are bringing manufacturing jobs back to the US, they
are not the types of manufacturing jobs my parents and grandparents knew. These
new high tech manufacturing plants are highly automated. They do create jobs
and pump some money into the local economies. But while a new manufacturing
facility in the past would have brought thousands of new jobs, the new ones
bring in hundreds.

That reminded me of a recent lecture series I attended by a Professor from
Creighton University. (Unfortunately, I cannot remember his name. I'll update
this blog post if I can locate it). The lecture series was about the history
and culture of China. One of the topics was Marxism. Marx viewed Capitalism as
a bad, and ultimately self-destructive system. In thinking about Capitalism,
Marx believed that the costs of labor would be under constant pressure.
Automation would reduce the costs of labor and ultimately make workers largely
unnecessary.

So, the question rolling around in my head has been, are we at that point?
Have technology and automation reached a point where people are no longer
necessary? We have a 40 hour work week across the Western economies, but is
there enough work to be done? How many genetic engineers, particle physicists,
nuclear scientists and electronics engineers do we really need? And how many
people are capable of working at those levels?

The pressure on societies by automation is only going to increase. Imagine
what impact self-driving cars would have. No more taxi drivers, bus drivers,
truck drivers. No more speeding tickets, no more DUIs, no more traffic stops.
What about hotels along the Interstates? You don't need a hotel if you can
sleep in your car, while it drives you from New York to Los Angeles. What
happens to package shippers like FedEx and retailers like Amazon? The entire
notion of cars and trucks falls away when the driver is no longer a required
feature of the vehicle. A single-person commuter pod suddenly starts to make a
lot of sense. Military drones are rapidly eliminating the need for pilots.
Imagine a fleet of remotely piloted (or computer controlled) micro-submarines.
RFID technology could virtually eliminate cashier jobs. You fill up your
shopping cart, push it through the scanner, and it instantly totals up your
purchase.

Are we dooming ourselves? Are humans becoming irrelevant? I was feeling
pretty down until I watched the latest Star Trek movie. There was a
great scene where spaceships were being built in orbital manufacturing
facilities. After watching that I decided that we still have a long way to go.
We are still in a time of tremendous change and advancement, and I think the
pace of change is only going to increase. But, I also think there is a lot left
to look forward to. As we finally start moving beyond our atmosphere and into
space, a lot of new opportunities are made available: space mining, lunar
colonization, and orbital (low gravity) manufacturing facilities to name a few.
There are amazing scientific discoveries that will be made, which will unleash
entire industries that don't yet exist.

It probably won't be easy, change almost never is. I don't think this is the
time when the pattern of history breaks. Either way, it's guaranteed to be
interesting!

I was all set to make my big blogging debut with a brilliant piece about a
Visual Studio 2013 bug that I thought I had discovered. Unfortunately, the
problem I discovered was much more mundane, but I think it's probably still
worth sharing.

A couple of weeks ago, I was setting up a new development instance of
SharePoint 2013. My employer is getting ready to deploy it. We're currently
using SharePoint 2007, so it's a welcome upgrade. My job is to get up-to-speed
on the new features and capabilities, and hopefully provide recommendations on
implementing right the first time.

I'm primarily a software developer, so I've been very excited about the new
SharePoint apps model. After getting all the server software in working order,
I decided to go with Visual Studio 2013 for development. I read through some
articles about creating basic SharePoint apps and then proceeded to try and
replicate the results. Everything worked as expected for a regular ASP.NET Web
Forms application. I was feeling pretty good.

Then I noticed that there's now
MVC support for apps for SharePoint. Great! I've been wanting to dig deeper
into the MVC approach. It's clearly the direction a lot of places are headed,
Microsoft being no exception. So, I click through and create my new MVC App.
But when I go to run it, nothing but fail. Unfortunately, I didn't grab a
screenshot of the error page, but the error message was: Problem with
activating the app web definition. The function throwing the error was:
enableModuleFromXml(). The error code: HRESULT 0x80070002.

No problem, I thought, I'll just check Google and be quickly on my way.
Wrong again. I seem to have been the only person in the world to encounter this
issue. Usually, that means I'm doing something that's very wrong, and probably
really, obviously wrong. I tried again with a new project, but got the same
results. Then I tried an approach from an older blog post that showed how to
build a SharePoint MVC app by creating a forms app, and then replacing the
forms project with a blank MVC project. That also ended in utter failure. At
least I was getting the same error every time.

The next morning, feeling a little fresher, I noticed that the SharePoint
project included some extra files when the MVC project was used from the start,
or if it was added to an existing solution using web forms. After some trial
and error, I finally discovered that a File element in a Feature was causing
the problem. I commented this line out and congratulated myself.

My celebration was short-lived though. One of the other things I found while
looking through the project files was this thing called WebGrease. The MVC
projects all referenced WebGrease 1.3.0, which was outdated. I updated Visual
Studio with the NuGet package for 1.5.2. That did not immediately fix the
problem, but after restarting Visual Studio and creating a new SharePoint
provider hosted MVC app, everything worked flawlessly. No more mystery feature,
no more commenting out the app.config File element.

I don't know if this problem exists on the release version of Visual Studio
2013 as I was using the RTM version. But I think the real lesson here is,
always make sure you're using the current versions of your packages. Unless of
course, you have some good reason for sticking with the old.