Erik L. Arneson — Writer and Software Developer

Link Rodeo: Go Package Management and Boring Technology

2015-04-06T15:47:00+00:00

Here are a number of interesting topics for you to think about this week.

I’ve been learning the Go programming language recently, and in the process I’ve been having conversations about it with friends and colleagues. Go has a unique package management system that has already caused me a number of headaches. The recommended method for taking care of package dependencies is lacking, at best. Over at Nerdbucket, my buddy Nerdmaster has written a thoughtful piece about it.

While I’m talking about new technology, I’d also like to contradict myself by agreeing with Dan McKinley’s great piece, “Choose Boring Technology.” He argues that a project should be careful about adopting lots of new tools and technologies. It reminds me of a time recently when I was looking for a Node.js programmer, and one of the replies I got back was, “For us, Node.js is glue. Its ecosystem is still too young to support anything long-term. Libraries and packages move too fast to build a product that will need actual maintenance.” I’ve had the same feeling about many technologies I’ve wanted to try, such as Ocsigen for OCaml, which has a build system and API that is always several steps ahead of its documentation.

This post’s featured photo is courtesy of Flickr user MunicipioPinas.

When to Develop Apps From Scratch

2015-02-03T20:56:10+00:00

I haven’t had time to write anything interesting for the blog this week, so instead check out Sebastian Green’s article, “A transparent box: the case for developing from scratch,” which has been published over at Developer Drive.

Mr Green makes some great arguments for developing from scratch. Good software takes good planning, no matter what.

Small Team Software Change Management

2014-12-18T01:45:51+00:00

Until October, I’d been using a paid GitHub account to manage source code changes and issue tracking for private projects. GitHub is a software-as-a-service (SaaS) product providing a web-based interface for source control management and various project tracking tasks. Some people love it and some aren’t fond of it.

My software development clients are typically small companies wanting fairly simple web applications. They hire me because having a developer on staff doesn’t fit into their budget or business plan. They don’t usually care what the source code for their project looks like, but they do care about tracking issues.

Because of the scope of these applications, it’s rare that I work with other programmers. This meant that I wasn’t using any of the special features of GitHub for private code repositories, so in October I cancelled my subscription.

My private repositories are now self-hosted, and I browse them using GitList, which bills itself as “an elegant and modern git repository viewer.” It looks nice, and I’ve got no complaints. For issue tracking, I use Freshbooks, a SaaS accounting system. With Freshbooks, I can not only keep track of bug reports and issues, but I can record time spent on bug reports, feature creep, and other client-related issues.

GitList and Freshbooks isn’t a perfect solution. At some point, I will be working with another developer, and we will need a way to track bugs and issues internally. When that happens, I plan to deploy Gitolite and find some new issue-tracking solution.

By the way, another reason I stopped using paid GitHub features is because they’ve already made plenty of money, and I’m not sure they’re doing the right things with all of that money.

I’m curious about what others are using. How does your incredibly small team track code changes and issues? Are all of your software issues internal, or are you developing for clients? I’d love to hear some ideas.