July 27th, 2010
For the past two weeks I’ve used DuckDuckGo as my search engine. It’s a search engine built on open-source software. What made me switch is the capacity to navigate through search results with the keyboard using vi-like keys (hjkl).
I didn’t know at the time but Google also allows you do something similar. You just need to go to http://www.google.ca/experimental/ (also works for google.com and I guess most other domains). There you can opt-in to be part of the Keyboard shortcuts experiment. That’s it! J/K are used to navigate through search results, O (or enter) to open them.
Hopefully this is going to be useful for the other keyboard junkies out there.
Posted in productivity, tools | No Comments »
July 23rd, 2010
As I wrote a week ago, I trained touch-typing this week. My objective was to attain 85 wpm. Here’s a recap of my week:
Monday : I decided to use Typeracer as my baseline. It’s an online game that allows you to race others. The fastest typist wins. I had not played in 6 months or so – and it showed. My score for the last ten races dropped a bit. This was not a good start. Result after the day : 74 wpm
Tuestday : I did some drills on goodtyping.com to get back to speed. It must have helped because I raised my speed to 78 wpm.
Wednesday : mostly played Typeracer. I managed to cut down on typing errors and I’m up to 81 wpm.
Thursday : I tried to practice at night instead of during lunch time. Without much success – 80 wpm. My fingers were not obeying me. I did a few drills on goodtyping.com to increase accuracy.
Friday : Success! I managed to consistently type over 80 wpm today by concentrating on typing slower but with less mistakes. I managed an average of 87 wpm on my last 10 races.
The week is over and I achieved my objective of 85 wpm. I did this mostly by reducing mistakes – they can get really slow you down.
Thanks to my colleagues who followed in my track and helped me focus on this challenge.
Posted in goals, practice | No Comments »
July 22nd, 2010
Everybody knows no one reads documentation. Hamcrest found an original way to warn users to use the org.hamcrest.BaseMatcher class instead of the org.hamcrest.Matcher interface.
Look at the interface yourself.
They added a dummy deprecated method called _dont_implement_Matcher___instead_extend_BaseMatcher_ in the interface.
I am still unsure whether I will ever use this in my own projects. But when this method appeared in my code today I could not help but look at it. It was then totally clear that I was not doing what they wanted me to do. I’ve seldom seen documentation that obvious.
Posted in programming | 5 Comments »
July 18th, 2010
This week I consolidated the two katas I did last time (Prime Number and Bloom Filter). Nothing much to talk about.
The only thing of note is that I got late in my RSS feed (again) so I missed the announcement of Corey Haines’ Learn How to Type Week.
I repent and decided to try my own this week (along with a few colleagues).
I’ll keep you posted about the results. I’ll work in increasing my wpm.
Posted in kata, programming | No Comments »
July 11th, 2010
I believe in software craftsmanship and in training to become better.
That’s why when I was challenged at work to take a few hours each week to train, I thought “What a great opportunity!”.
Well that’s what I should have thought. Instead I said: “But what about the project? The deadline? The world is going to end!”
Then I realized how lucky I was to work at Pyxis. I asked the Product Owner and it wasn’t such a big issue.
Lesson #1: Ask and thou shall receive
For my first training session, I decided to do the some katas in ruby as it has become my language of choice for pet projects.
Part 1 – Primes
I started my first session with the Prime Number kata. I like this kata since it is really simple, can easily be done in less than 30 minutes (closer to 10 once you’ve done it a few times) and I learned a few useful tricks in ruby by watching this kata permormed by Uncle Bob on Katacast.
I plan on doing the Prime Number kata every week as a warm up.
Part 2 – Bloom filters
Afterwards I tried kata #5 from http://codekata.pragprog.com/2007/01/kata_five_bloom.html – implementing a Bloom Filter. It’s an algorithm that probabilistically determine if an element is part of a set. It works like this : if the element is in the set, it will always return true. However if the element is not in the set, the bloom filter might still return true depending on some probabilistic stuff.
Training ends
Here are my highlights of the session:
- I learned a new algorithm, it’s purpose and a few use cases
- I performed everything in pure TDD
- Continued to learn new keyboard shortcuts in Rubymine (I try never to use the mouse in katas. If there is a keyboard shortcut I forgot, I look it up and make a point on using it)
- I managed to take some time to train!
The only downside I can think about is that I spent a little while trying to configure ruby 1.9.2, rspec and the latest beta of Rubymine 2.5 before reverting to ruby 1.8.7.
As for improvements, I see lots of ways to improve the Bloom Filter katas, especially when it comes to my tests. I’ll give it another try next time.
Posted in kata, practice, programming, ruby | No Comments »
June 20th, 2010
After many discussions with a colleague about Git, I came to realize that Git is not merely a source control. With time it became a tool in my developer’s sandbox. To develop software effectively, I need (among other) an IDE or text editor, a prompt and countless libraries. I came to rely and trust these tools.
I used many other tools for version control but I saw them as infrastructure – mandatory in the grand scheme of things but not used to improve my productivity.
Git changed everything by allowing me to rethink the way commits and branches work.
- By promoting small commits that do one thing but do it well, git forces me to split my task in even smaller chunks that can then be commited. This sometimes leads to architectural changes.
- By making it possible to reorder the commit history (git rebase -i origin), it pushes me to make each commit clean and atomic.
- Git makes branching cheap and easy. Like you, I try to code each features in a separate branch. But unlike you, I am undisciplined and often forget. However if I start on a feature and realize it takes slightly longer than expected (and I’m talking about an hour max, not 3 days), I create a branch for that feature. It’s easy and it allows me to work in small, independent chunks. It also allows me to always be able to come back to a stable branch if I need to do a few quick fixes on another part of the project.
Git is not a mere tool – it changed the way I design and code.
Posted in git, productivity, programming | 4 Comments »
June 7th, 2010
Unless things go sour in a project, a team rarely gets downsized. On the contrary, new team members are often added in the hope that more will get done.
What if sometimes, the best action to increase productivity would be shrink a team? I can think of two situations where reduced staffing is a good option:
- The team realized that it grew too fast. Core team members do not have enough time to effectively coach the rookies.
- A new features requires an overral architecture change. You can already predict that merging will be hell if new features are added while others are implementing the new architecture.
It’s not always feasible to remove team members – and it’s always a though decision. If the team grew too fast, you might not have any other choice. If you want to do it because you need a big architecture change, it might be possible to shift some members to another module or to start something new that will have no impact on a problematic area. You might also try to make the change coincide with half the team going in vacation (I’m sure many of you felt more productive when most of your team was away).
Next time you’re stuck and have a hard time finding effective ways to make the whole team work together, consider a reduced staff for a few weeks. It might be just what you need.
Posted in agile, productivity | 1 Comment »
May 25th, 2010
While going through Crucial Confrontation to finish up my mindmap, I came across an interesting definition of the word ‘nice’. It seems that many people describe their organization’s culture as ‘Nice’. So the authors came up with a new definition of the word:
Nice
adj. A pleasant, nonconfrontational attitude that eventually kills you.
Does that sound like your organization? If so it might be time to change your corporate culture.
Posted in Uncategorized | No Comments »
May 21st, 2010
I saw this quote on 37signals’ blog and I thought it fit well with my latest post on failures.
“It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible.”
- Lee Unkrich, director of Toy Story 3, Wired magazine
If the goal is to screw up as fast as possible, you need an environment that allows you to do it safely.
Posted in practice, programming | 2 Comments »
May 18th, 2010
Failure is often a dreaded word. It need not be. Programming is an art where it’s very easy to fail and you can usually fail fast. Use it to your advantage. Learn to fail with style.
Give yourself the option to fail deliberately and safely. Many tools can help you:
- Branches – Since I started using git, I often create a branch to play around with the code… then delete it and start again from scratch once I know where I need to go. This gives me the freedom to change configurations, disable features and modify code without tests. I even go as far as breaking existing features (sometimes they don’t even compile) if it makes me learn faster.
- Prototypes – create a simple throw-away project to test your code.
- Tracer bullets – whenever I need to connect a few modules together, I like to have a tracer bullet that will handle the normal path without any error handling. It gives me confidence that all the pieces fit together. It proves the chosen architecture works and yields the expected results.
- Tests – if I want to know how a particular method/class reacts in a specific context, I will sometimes create a test to test my behavior. I might keep the test as-is or sometimes I throw it away and it becomes part of a larger test.
- Scripting languages – ruby, python, groovy or whatever you fancy, these languages can often help you test an algorithm faster than in Java or C#.
- Pen & Paper – low tech, but sometimes writing down your thoughts is the best way to go. If it doesn’t work on paper, chances it works on a computer is pretty slim.
- Rubber duck – having an inanimate yellow friend near your computer that you can always talk to can never hurt
.
Code is cheap and fast to write… once you know the way. A few failures early on will help you get a success when it counts.
Posted in programming | 1 Comment »
