Gant Software Systems

Blog Posts

Top 10 Features Of Web Essentials 2013

Web Essentials, by Mads Kristensen (and many others now, thanks to having been open-sourced) is hands-down my favorite free Visual Studio add-in (the winner in the paid category is Resharper). There are a lot of big features in the tool that make it an awesome add-in, most of which have been covered in other blogs. However, for myself, it’s the little features that make the most difference. It removes more frustration from my day when a tool saves me 10 or 15 seconds here and there than it does when it saves me five minutes (although five minutes is great too, but the smaller tasks are something I notice more frequently). So, here are my top 10 things I’ve noticed in the web essentials tooling that make my day a little easier:

Book Review: Start Small, Stay Small

A Developer's Guide To Launching A Startup

Every so often, a book comes along that exceeds my expectations (not going to bury the lede here, this book absolutely gets a 5 star review). This one is certainly in that category. Start Small, Stay Small is an excellent guide to getting a product-based business going as a software developer. From the outset, Rob Walling doesn’t make the assumption that you have a large amount of money from investors or that you are playing the start-up lottery. This book is about building a sustainable business one step at a time, usually while working a full time job.

Instability Is The Default Plan For It

As a few of you know, I was briefly employed from the tail end of February until late last Thursday, when I got downsized. It was an excellent group to work with and I plan to stay in contact with those guys. While I can’t get into too many of the details, it wasn’t due to performance or anything like that. It’s just that the sort of clients I work with sometimes have things change out from under them and things go in different directions. It stinks, but life is full of surprises. If I wanted a boring, perfectly safe job, I’d get that tomorrow (and some HR algorithm would probably reject me, but let’s just go with the optimistic case for now). That’s not what I do though. I’ll go back and work for them again in a heartbeat if the opportunity presents itself.

When To Automate

As software developers, one of the main things we are tasked with is the automation of business processes. Typically, we’re given a task to do, with much of (if not all of) the process laid out and told to get it done. As a result of this sort of thinking, it tends to be our default mindset to either attempt to automate everything, or to avoid automating anything in our own workflows. The decision of when to automate is something a lot of developers struggle with, as it’s very easy to either put up with irritating, repetitive processes, or to get lost in the weeds trying to automate something that really isn’t worth bothering with.

How To Write A Blog Post Quickly

I know this is a bit outside the normal content for this blog, but since I get asked frequently, I figured I would share my method. It usually takes me an hour or two in total to build a blog post, although some of the longer ones might take as much as three hours. I do sometimes get interrupted, but for the most part, I’m able to write the whole thing without too many problems. I’ve refined the method over time to help improve my speed as well.

The Trouble With ORMs

Object-relational mappers (hereafter called ORMs) are used to provide a way for one to map an object in an object-oriented language to a table or set of tables in a (usually) relational database. On the Microsoft stack, they’ve become so popular as to be nearly ubiquitous. They do have their detractors, including people that have developed their own, such as Rob Conery, who developed TWO ORMs (Massive and Subsonic). That said, they do often make the earlier phases of a project much easier, by allowing developers to abstract away the pain of relational data access. This is frequently helpful in the early phases of a project because developers are moving quickly and breaking things while trying to quickly iterate over a design. That said, I find that the way ORMs are frequently used is often rather unhelpful as a project matures (and possibly rather unhelpful in the early phases as well).

Why I Find The Current Javascript Client-Side Ecosystem Frustrating

’ve been developing in JavaScript for a long time and have seen client side techniques evolve drastically over that time. However, I have to say right now is about the most frustrating (and promising) time to be working with JavaScript in a professional capacity that I’ve seen in many years (and possibly ever). Let’s do a little retrospective of what I recall from back when I started really getting into computers.

Your Value Is Not Your Profession

One thing that separates successful career programmers from those with a bit…less success (we won’t call it failure, because it usually doesn’t manifest as abject failure, but rather as stunted potential) is their ability to figure out their value to the people who are retaining their services. Regardless of what that job posting says, what the recruiters tell you (more on this in a minute), or what you’d like to hear, you are NOT ever hired into a position simply to write code. You are hired to solve a problem that someone has, with the expectation that your solving of said problem presents an advantage greater than that provided by simply keeping (or using elsewhere) the money required to hire you. It’s a simple thing that is missed fairly frequently when discussions of programmer salaries come up, as well as when programmers sit and complain about the messes they deal with at their jobs. It also happens in just about every other industry. I’ve had similar discussions with people in other industries. The fitness industry, for instance, is loaded with people who live under the belief that the fitness program they are selling is actually the reason they have clients, instead of what the clients are actually there for, such as losing weight, gaining muscle, just the feeling of accomplishment and pushing past obstacles, etc. The dividing line between the successful ones in that industry and those who are unsuccessful is also remarkably similar, in that the latter fail to line up their offerings with what their customers are actually buying, versus what they think they are selling.

The New Microsoft

Having started my training as a programmer in the 90s with 16 bit Visual Basic 4 and having seen them at their worst on several occasions, it’s often easy for me to take the side of people who don’t like the company (except Apple fanboys, because their platform has exhibited a lot of bad, anti-competitive and destructive behavior of late as well and more recently). I’ve seen them destroy competitors, build up a huge userbase on a platform that made building applications easy and then torch it on the altar of progress, and even keep security-hole-riddled crap around for years that caused compromised systems and grief for users for decades. Consequently, I’ve tried on numerous occasions to switch to linux, and ended up coming back to windows (usually after some config file got hosed and cost me a day of work). I’ve lived through ODBC database access, DAO, RDO, ADO, ADO.NET, Linq-to-Sql, and Entity Framework (whose early versions drove me to use NHibernate). I’ve seen ActiveX in the browser, VB webclasses, silverlight, and even FoxPro. I’ve even used Visual Source Safe…. I’ve essentially had a love-hate relationship with Microsoft for a very long time.

A Home Development Environment for the Small-Time Developer Part 2

In Part One I outlined the goals of this series. This article will go over what eventually happened when I decided to rework my source control system. As of the beginning of this process, I have a bit of a mixed architecture in regard to source control. For my open source project (which I’ll reveal in a later blog post once I’ve cleaned up the code enough for it to not be embarrassing), I use github, as I find it to be the best place to host that sort of thing. For my internal projects (hacky scripts for various things, websites for other people, utility code, etc.), I tend to use VisualSVN, which is currently running on my “server”. Finally, for an upcoming partner project, I’m using Bitbucket. All three approaches work rather well, but I’m mostly irritated with Subversion. I had initially intended to keep source control on my internal server, but after some thought, I realized that really adds a lot of work I’m not interested in doing. Specifically, the following are the issues I have with it.