Just Another Software and Technology Blog

To content | To menu | To search

Tuesday 3 February 2015

Always Be Learning


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!

Monday 19 January 2015

What a great time to be a developer!

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.)

Sunday 24 November 2013

What Does the Future Hold?

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!

Friday 22 November 2013

The SharePoint 2013 MVC Provider Hosted App Problem That Wasn't

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.