Web developer with a preference for Ruby on Rails
You sip coffee and make your list. At a nearby table someone is writing The Great American Novel but you are simply identifying your projects and actions. The list grows every time you pause for a sip. What is surprising is how items which once dominated your attention now require a reminder.
— Your List by Michael Wade
A little reminder from Michael Wade that lists are a great place to start.
A rear hub that doesn't require you to flip the wheel to switch from fixed to freewheel?
This looks like it will be the start of a new fixie build for 2015.
Love the look of these device stands.
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.
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.
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.
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.
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.
I'm a big fan of both Mike Vardy and Patrick Rhone, so I was really pleased to see Mike had asked Patrick to be a guest on his Productivityist Podcast. Listen and enjoy as they chat about ideas, task systems and other great stuff.
Interesting new idea for home security. I would be interested to see how accurate it is.
More death defying bike riding by Danny MacAskill. This time it's back to the Isle of Skye to ride the Cuillin Ridgeline.
New personal best for Ethan today at the golf with a round of 102. I'm really pleased at the progress he's made this year.
There were a number of bikes that caught my eye this week, but this GRÜN bike won this week's place in the Fixie Friday archives with its distinctive colour scheme.
via FGGT
I usually don't install games on my iPhone, but after hearing about Battleheart Legacy I just had to give it a go.
Having played D&D as a kid, I immediately loved this game. Character classes, attributes and a world to venture in to gain experience points. And best of all, no in-app purchases!
Available on the App Store.
Microsoft products have waned with me over the years, but their new product, Band, definitely got my attention today. Also glad to see that they have apps available on all major app platforms.
Apple's choice to remove the ability to upgrade the internals of their products has me asking decisions about my own preferred hardware setup for work purposes.
Our house is light when it comes to computing power. We have a handful of devices between the family and there's a games console there for when I feel the need to be humiliated at Madden by my oldest son. As for actual computers though, with the keyboards, mice and monitors, we have a single laptop in the house. Mine.
My MacBook Pro has been my workstation for over a year now. Solidly built and still just as fast as the day that I bought it. It's also the laptop the family use to sync their photos and music to external disks for long term storage. I've been careful about seperating content between work and family. I've got a couple of external hard disks for storing pictures and music as well as a third external hard disk for Time Machine backups. Anything work related stays on the laptop, while videos, movies, pictures and music are all located on external disks.
The setup we have is fine for our needs for the moment, but ideally I would like to have seperate computers for work and family. Keeping the two seperate would mean that if one was to go, then it wouldn't be a major impact on me working. If my MBP was to pack in tomorrow then the home computer could serve for work purposes until I was back up and running with the hardware that I needed for work again.
After hearing the news of the updated Mac Minis in Apple's product line up, I was excited. These little boxes of technological joy have been on my radar for a while. While the lovely iMac has been on the wishlist for a while, the cost of it is out of our budget for what would be a computer that would be used intermittently. The Mac Mini was the next sensible choice then. With a monitor already on my desk, it makes much more sense to just buy a computer than can plug into it and allow me to use my own keyboard and mouse.
However, joy quickly turned to dismay when I found out that as a consumer, I won't be able to open up the Mac Mini and upgrade the parts that I need in the future. Like it's MacBook and iMac cousins, the Mac Mini has it's memory soldered onto the motherboard which makes upgrading in the future impossible. If you want something more powerful, you need to buy another Mac Mini with the specs you need. Hardly ideal given that in order to make these Mac Minis viable as long term computing products, the upgrades on the Apple website are higher than the market prices for similar upgrades you could do to a more open computer.
It's sad to see that Apple's products are going against this with memory now being soldered on to each of their product's motherboards. It's got me thinking again about how much do I want to invest in computing hardware in the home as I am clearly becoming more and more dependent on Apple's products. As a technology platform for ordinary consumers, Apple's products are hard to beat. They work well and the software that they provide for OSX and iOS is easy to use. I don't think for everyday use I would switch to another platform such as Google or Microsoft. It just works, it always has.
The geek in me though has me looking at Linux barebones boxes and alternatives to traditional desktops such as these miniature Linux desktops as a replacement for my laptop. I definitely want something longer lasting but also upgradeable. I'm just not sure at the moment what that setup will be. Ideally a desktop running some Linux distribution as well as a small form laptop such as a Chromebook, without the Chrome OS, could serve me for my mobile needs which at the moment are rare. That could change though.
A few decisions to make here, but I think the first is whether I could use Linux as my work environment on a daily basis. I should probably decide on that first before making any decisions regarding my desktop hardware.
What started as a monthly challenge is now fast turning into a social network daily ritual, which isn't a bad thing when it comes to the fast and furious world of social networks.
Back in September, I started a challenge of writing a 256 character post everyday on App.net. Aside from missing a single day's post I completed the challenge. It was a refreshing use of my time on a social network. Rather than simply typing the first thing that comes to your head and posting it, filling the post with 256 characters means you need to spend a bit of time editing, re-wording and ensuring your post is correct and uses all character space available. It's this time spent on getting the message right that makes my 256 character posts so different from every other post I make.
Social networks are often seen as a cheap and fast way of getting messages across to people, so few people think before they post. While they are great for short bursts of information, social networks are mostly places where masses of un-edited information stream by us every day. My #team256 posts on App.net are not wildly profound or better to read than other posts on App.net, but they do provide me with a chance to write something a bit more detailed.
What started as a monthly challenge has fast become something of a daily habit. I'm still keeping the habit going to post 256 characters a day on App.net and while I might have missed the last couple of days, I did look forward to writing my post for the day. I hope that it continues and gathers pace on App.net in the future.
Journey across the world using your mouse with these amazing images taken from the International Space Station.
via SwissMiss
Excellent use of those blank pages at the start of a book, create your index of ideas from the book.
via Taking Note
I love using Pixelmator on my MBP, but it's great to see it's now available on the iPad too.
via Tools and Toys
Obviously this isn't a fixed wheel bike, but with just a single gear and no suspension in sight, this is about as close as you can get to off-road fixie.
via Cycle EXIF
A new look Todoist for all you Mac people. Love this service.
No fads, gimmicks, or shortcuts. Just practical advice and hardwork.
Techniques like brainstorming try to sell a way of generating ideas in a short space of time, but is there a better way?
Out of the blue you have an idea for something. A product, a book, a service, something. What do you do with it? The obvious answer here is to write it down. Anywhere. Whatever comes to hand, get that idea down. Give it an hour or two and you might simply forget it even existed.
Great. Now what?
The next step for many is to re-visit this idea at some point in the future and decide whether to act on it or not. The down side to this is that while the idea might have sounded great on its own, it is only one idea. One single good thought.
If the idea is so good then you might be thinking that it would be a challenge to improve upon it. What's better than a single idea though? How about two, three or even seven ideas that support this one single idea?
The problem is that while we might want to set aside a 30 minute session to brain storm more ideas to support this new idea of ours, the new ideas we want might not simply be there. You can't force yourself to come up with new ideas. You might be able to expand on an idea but limiting yourself to a time period will only leave you with a couple of new ideas.
If you're the patient type then how about trying a different approach?
Let your ideas incubate.
I've wrote before about incubating mind maps in the past. Rather than starting and finishing a mind map in a single session, I would re-visit my mind map on a weekly basis to give myself time to allow the central topic of the mind map to sink in. The benefits to this is that you allow yourself time to think about the central topic of the mindmap thereby allowing associations to that central topic to develop over time.
The same can be said for new ideas.
By allowing an idea to incubate over time, it gives us a chance to think about the idea. Thoughts and ideas often come at the most inconvienent of times. When you're walking the kids to school, when you're out on a bike ride, when you're anywhere other than on your computer to execute the idea.
This is a good thing though. Being away from your desk or your workplace means that you don't act on a sudden impulse to test the idea. Just make a note of it and then carry on with your day.
At the end of the day, make a more permanent note of your idea so that it can be easily found later along with any other ideas that you have had that support this idea.
Give it a couple of months and you should start to see that single idea develop into something more. And this is the benefit to incubating your ideas. An incubation period of two months can yield more positive results than a single brainstorming session could. It's not for everyone though, but I'm more of a believer that slow and steady wins the race.
... with a journal.
In an effort to brush up my development skills I've been reading the Redmine source code this week. I've been curious to find out about examples of Rails applications that use Minitest.
Ever since I suggested a move away from RSpec for projects with my clients, I've been curious about real world examples of using Test::Unit/Minitest to test a Rails application. It was clear from a search of Rails applications on Github that RSpec was the preferred choice for many applications. However, after reading an email newsletter from developer Eric Davis, the RedMine project sprung to mind so I decided to check it out. Sure enough, it was the sort of application I was looking for. A mature code base using Minitest as the test framework. A few interesting points stood out which I'll cover over the next few weeks, but for today I'll talk about Redmine's multiple assertions per test.
I was always led to believe that tests ahould only contain one assertion per test. It was ingrained into me from reading countless books on TDD and hundreds of blog posts on the topic. The thing is I never questioned why this was so. It was clear from seeing the RSpec syntax why it was a benefit.
before do
get :index
end
it "must respond with a success code" do
assert_response :success
end
it "must render the index view" do
assert_template :index
end
it "must assign the users journal" do
assert_not_nil assigns(:journal)
end
If your test (or 'spec' in this case) has one assertion and it fails then you know exactly what went wrong. Multiple assertions in a single test have always been frowned upon.
When I started using MiniTest as the test framework for a couple of Rails applications of my own, I started to write multiple asserts per test.
def test_index
get :index
assert_response :success
assert_template ‘index’
assert_not_nil assigns(:journal)
end
It was discomforting to do but only from the view point that I had believed for so long that multiple assertions per test was wrong. However when I read the Redmine source code I was pleased to see that not only was the application not using the RSpec, it was also using multiple assertions in a single test. After an hour of reading through other tests in the code base I could see why it was done. The layout of the tests in Redmine are flat. Often there's just a single setup and teardown method and a list of tests. It makes it much easier to read.
RSpec has a number of advantages in that tests can be nested in different contexts and within each context you can define a before block to setup anything needed for the tests that follow. This can result in heavily indented code and with the practice of one assertion per test it can lead to a lot of tests relying on a number of different setup methods higher up in the test file. This can be difficult to read if a test file has a number of contexts within it.
It's re-assuring to see that while many developers might point out the benefits or reasons why we do one assertion per test, it's not a rule that is set in stone. You can include more than one assertion in a test, as long as it's a reasonable number of assertions.
Is it worth writing seperate tests for each of these or is it better to simply bundle them into a single test?
I'll leave that for you to decide. There's no right or wrong answer in my eyes. If I was still using RSpec I probably would still write one assertion per test out of habit, but having a flat layout using Minitest does make it easier to read and having multiple assertions isn't going to make it any harder for me to test my code and debug any problems.
For the paper purists out there, a great tip for organising your notebook.
via Unclutterer
An amazing account of a USMC pilot who ejected from his F-8 Crusader over a thunderstorm.
As the parachute opened, he felt the familiar tug upwards. Except instead of a slow descent, he experienced a rapid ascent. The powerful updraft filled his parachute like a sail and rocketed him vertically thousands of feet at a velocity of nearly 100 mph. During his ascent, he could see hail stones forming around him. The lightning was described by him as “blue blades several feet thick” and incredibly close. The thunder was so loud, he could feel it resonating in his chest cavity and remembered this more so than how loud it was.
— Lt. Col William Rankin - Ejects Into a Thunderstorm by WeatherImagery
via Kottke.org