Blog logoMatthew Lang

Programming

A 34 post collection


Cracking open Vim again

 •  Filed under Posts, Tools, Programming

It's been a while since I took another stab at learning Vim. If you don't know what Vim is then all you need to know is that it's a major geek out text editor. Savvy?

Each time I've tried to learn Vim though I've started with an existing Vim configuration file. Getting up and running from a blank file just never appealed to me. The problem starting with another person's configuration though is that while everything is there that you need, there's a huge number of commands and shortcuts configured that in the beginning seems a rather daunting task to remember.

This time I've started with a blank slate so that every time I need to customise something in Vim I make the change in my configuration file to fix the problem and move on. Needless to say it's taken me a while to get the configuration file to a point where I would be happy doing client work with Vim as opposed to Sublime Text.

The surprising result though is that while I might be working a little slower than if I had been using Sublime Text, I'm actually learning more about Vim than I ever did before.

I'll report back in 3 months with an update to see if using Vim has stuck this time. I'm optimistic that it will this time, although I have been caved in the past.

Learning with Rust

 •  Filed under Rust, Programming, Learning, By Me

I'm always reading about other topics in software development. Over the last few years I've read about web design, JavaScript, Ruby, agile methodologies and practices, Go and even Objective-C. Reading books on these topics has provided some insight into their respective topics but with the exception of Ruby and agile methodologies I haven't been able to take what I've read and use it in a practical exercise.

A couple of years ago I read about the Go language from Google. So I started reading a couple of books about it. Since then I haven't written more than one hundred lines of code in Go. Was that time spent reading about Go a waste? I think so.

More recently the Rust language has peaked my interest but I haven't started reading about it yet. I've been asking myself if there's something I can work towards using Rust that will let me learn the language. Using Rust in a practical use hasn't been something I've been able to come up with until a couple of days ago. There I was reading Hacker News over the weekend when I seen an article about writing a shell in C. Well, why not write it in Rust?

Building a shell in Rust should give me the chance to explore and learn the language but also give me the chance to try out something other than web development. I've been working with Ruby on Rails for over four years now and while I enjoy the work, I have been looking at a systems programming language to learn. We'll see how it goes.

Goodbye Dr Dobb's

 •  Filed under Programming

I haven't been reading the Dr Dobb's site for a while but back in my days as a .NET developer, it was a regular place to visit. Still, it's a shame to see there won't be any new content after the end of the year.

No amount of analysis and explanation can mask the deep, personal sadness I feel at writing about this decision. Like many of you, I grew up reading Dr. Dobb's. For me, as I suspect it was for many of you, Dr. Dobb's Journal was the lifeline to a thorough understanding of programming. I recall that when the magazine appeared in my mailbox, all other activity for the day came to a sudden stop and the remaining hours were spent blissfully poring over article after article, soaking in the information. I learned C from Allen Holub's C Chest column, operating systems from the 18-part series on 386BSD, video programming from Michael Abrash's Black Book, and data compression from Mark Nelson. And so on — each month brought new, enabling insights and explanations of often arcane topics.

Farewell, Dr. Dobb's by Dr Dobb's

Reading Redmine: Comments

 •  Filed under Programming, Career, By Me

Continuing my series on reading Redmine, we'll take a look at commenting.

Next to tool choice, comments is another topic that can cause heated debates amongst developers. As a rule, I rarely comment my own code. I just don't see the need to comment it. I try to be as expressive as possible in the code I write and although it usually is more verbose than other developers who I have worked beside, I know that by expressing my code, it becomes easier to read and understand.

Having worked on a number of different code bases for clients I've started to look at commenting in a different light. In the past I would rarely comment but now that I am working on code bases for different clients, it can be advantageous to comment your code. When I started reading the Redmine code I noticed a similar use of comments in the Redmine code to what I had in mind for commenting on my client's code. Here's what I found out.

Open Source License Everywhere

Having not worked on any major open source applications (yes I should rectify this), I was surprised to see the open source license located on each file within the Redmine source. Yes, within each file. Every model, controller, helper and almost all Ruby source files that I could see included a copy of the GNU General Public License (version 2).

My only critique against this is that if the license was to change then it could be something of a task to update the license on each file within the application, however in order to ensure that the license for Redmine is fully understood, then it does make sense to include the license in each source file.

The reason I have included this is that I do view the license as a sort of comment. It's not code but it's also not expressing the intent of the code in the typical way that a comment does. It does describe how the source code can be used so could be viewed as a comment.

Comments on Controller Methods

One thing that stood out from the source code was the use of comments on controller methods. This makes senses in the cases I seen, as some controller methods didn't follow the traditional RESTful verbs and some required an explanation of the intent of the method. It was good to see that a single or double line comment was frequently used to explain the controller's intent.

{% highlight ruby %}

Loads the default configuration

(roles, trackers, statuses, workflow, enumerations)

def default_configuration
....
end
{% endhighlight %}

This is good from a documentation point of view as it means that other developers working on the same method will immediately see what this method does. Most controller methods were fairly straight forward to read but there were a number that required just a single line to explain the method further.

Comments on Model Methods

Putting aside the argument of where the business logic in a Rails application should reside, let's just assume that in Redmine's case it is in the correct place, mostly within the ActiveRecord models. I say most as there is also a fair degree of code spread out into controller, helpers and in the lib folder too.

So if most of the business logic for Redmine resides within the ActiveRecord classes then where's the documentation for each method? It was something I found unusual given that the controllers were documented well. From scanning the models it was clear that only about half the model methods were commented. It should be mentioned that there were a number of methods that didn't require comments, but then there were a few places where a comment might have been advantageous.

To Comment or Not?

The Redmine source itself is a typical Rails applications without any architectural surprises. It shouldn't surprise most developers familiar with Rails that it is indeed straight-forward to follow. Given my history with commenting in Rails applications, I was surprised to see such a wide use of commenting within Redmine but without using RDoc.

It has given me food for thought on commenting on the Rails applications that I working on at the moment including my own. I've always just viewed my code as code the I alone will read but that may not be the case. If someone else was to read it, what would they think? That's an exercise for another day, but this look at commenting with Redmine has shown some good examples of where commenting can be an advantage.