I'm not telling!
Rocky Holidays
Last Thanksgiving weekend, Carolyn and I went to visit our friends Andrea and Jeremy in Alberta. They moved out there last summer when Andrea got a ministerial placement in the metropolis of Killam. I can confirm that there is at least one stop sign in the town.
They were gracious enough to drive many hours and many hundred kilometers to show us the amazing Rocky Mountains, so I thought I should finally share some photos. Furthermore, I upgraded my computer over Christmas so I can do certain post-processing techniques (such as panoramas) much quicker.
We flew into Edmonton in the evening where we met Andrea, Jeremy, and Hiro. From there we drove straight to Canmore. Jeremy has booked us a great chalet, and this is the view we found in our backyard the next morning.
We drove into Banff National Park - my first visit - and headed for the Banff Gondola. The view on the way up is amazing, and once you're at the top - spectacular. We hiked around for quite some time and I took a number of photos. I think Jeremy and Andrea learned how time can slow to a crawl when I have my camera.
We then headed to Lake Louise for another short hike. Right on the lake is the Château Lake Louise, which is amazingly large and without a doubt has the best-smelling bathroom soap I have ever used. Everything since has left me wanting more from my hand-washing experience.
Just south of Lake Louise is the pristine Moraine Lake. I have never witnessed water so turquoise. Apparently it is one of the most photographed locations in Canada, and I can understand why.
Me and Carolyn at Moraine Lake.
Jeremy and Andrea at Moraine Lake.
To our dismay (and relief) we didn't have any real bear sightings (ask Carolyn), but on our way out of the park we had the pleasure of coming across a family of deer.
After ingesting some overpriced raclette in Banff, we headed back to Canmore. The next day we started the trek back to Killam. We stopped in Drumheller at the Royal Tyrell Museum. Sadly we got there too late to see any exhibits, but not too late to purchase some gifts for our dinosaur-crazy nephew. There were some dinosaur replicas outside the museum that Hiro was not too impressed with.
Late in the evening I finally got to check another thing off my life-list: seeing a moose. The photo isn't great but it's proof.
We finished our our visit with another few days in Killam, enjoying some balmy weather and a fabulous Thanksgiving dinner.
They were gracious enough to drive many hours and many hundred kilometers to show us the amazing Rocky Mountains, so I thought I should finally share some photos. Furthermore, I upgraded my computer over Christmas so I can do certain post-processing techniques (such as panoramas) much quicker.
We flew into Edmonton in the evening where we met Andrea, Jeremy, and Hiro. From there we drove straight to Canmore. Jeremy has booked us a great chalet, and this is the view we found in our backyard the next morning.We drove into Banff National Park - my first visit - and headed for the Banff Gondola. The view on the way up is amazing, and once you're at the top - spectacular. We hiked around for quite some time and I took a number of photos. I think Jeremy and Andrea learned how time can slow to a crawl when I have my camera.
We then headed to Lake Louise for another short hike. Right on the lake is the Château Lake Louise, which is amazingly large and without a doubt has the best-smelling bathroom soap I have ever used. Everything since has left me wanting more from my hand-washing experience.Just south of Lake Louise is the pristine Moraine Lake. I have never witnessed water so turquoise. Apparently it is one of the most photographed locations in Canada, and I can understand why.
Me and Carolyn at Moraine Lake.
Jeremy and Andrea at Moraine Lake.
To our dismay (and relief) we didn't have any real bear sightings (ask Carolyn), but on our way out of the park we had the pleasure of coming across a family of deer.
After ingesting some overpriced raclette in Banff, we headed back to Canmore. The next day we started the trek back to Killam. We stopped in Drumheller at the Royal Tyrell Museum. Sadly we got there too late to see any exhibits, but not too late to purchase some gifts for our dinosaur-crazy nephew. There were some dinosaur replicas outside the museum that Hiro was not too impressed with.
Late in the evening I finally got to check another thing off my life-list: seeing a moose. The photo isn't great but it's proof.We finished our our visit with another few days in Killam, enjoying some balmy weather and a fabulous Thanksgiving dinner.
New Blog
I have a new blog. I won't be abandoning tales of interest - not that it's bustling with activity - but I'll be writing all my work/tech related stuff on my other blog. If you're interested in that sort of thing, please go to:
http://perpetualdevelopment.wordpress.com/
And if you're not interested... well, you're welcome!
http://perpetualdevelopment.wordpress.com/
And if you're not interested... well, you're welcome!
The Book of Revelation
Before you read any further be warned that I'm raising a Level 1 Geek Warning: if you are not in the software development industry, you'd probably enjoy your time better here.
Today, unlike most days recently, was a wonderful day at work. I actually didn't want to leave. I'm considering going to work early tomorrow. What happened? Well, let's go back in time a few months...
I think it all started with Ryan. Now, every day starts with Ryan talking. Usually before I get a chance to sit down and read my e-mail he's already bombarding me with questions about some obscure problem (perhaps only obscure because I'm only half-listening at this point). But those days he started talking about books - or more specifically, the interesting things he was learning about from those books - and I started to pay attention. He told me about this crazy mystical practice called 'test-driven development', where not only do the developers test all their code, but they write the tests before they write any code!?!?! I don't think I actually laughed at him, but I let him know that it all sounded well and good as an academic exercise, but it couldn't really be done in practice by sane individuals.
And so we moved on. Ryan kept reading and kept telling me to read these books, and I kept deflecting and diverting. Then something happened, and I'm not quite sure what it was (hey, I never claimed to be a good storyteller!) but I finally relented to the pressure. The book was 'The Pragmatic Programmer' by Andy Hunt and Dave Thomas (not of Wendy's fame). I don't want to say that this book changed my life, because I hate it when people say things like that. So, I'll just say that this book had a profound impact on how I view myself as a professional software developer. That sounds a lot less sappy.
This isn't a technical book. It's a book about good practices and good attitudes. It's about taking pride in one's career. The book is littered with tips, but here are the first five (which I also have posted on my office door) that I feel are applicable to anyone in any profession:
In a sense, this book revealed a whole new world to me. I had been blind as to how software development could be done. I didn't realize how much more I could be (and arguably should be) doing. And thus I started to read.
I have since read (and recommend)
The book I am currently reading is 'The Art of Unit Testing'. I'm not terribly fond of the format of this book (a lot of repetition), but it's a good beginner reference. I knew before reading this of the importance of formal unit testing (even though I had done little of it myself), but it has enlightened me to some techniques, common problems, and frameworks that could save a lot of time and effort in generating new tests.
So that brings me to today. I had been working on a connectivity bug over the last couple of days and during my analysis had uncovered a few 'loose ends' in the connectivity framework that Ryan and I had developed. Empowered by the 'fix broken windows' philosophy we decided to fix the root of the problems as opposed to patching the symptoms. The root of the problem was unfortunately embedded in the original design, but as Martin Fowler says: refactoring means never having to say you're sorry.
It was this morning that we first embarked on our first voyage of pair-programming test-driven-development. We had done plenty of pair-programming before (very successfully I might add), but never true test-driven-development (TDD). We knew that one of the main classes in our framework had too much varied responsibility, and we wanted to break that up. Instead of liberally ripping apart the code we wrote test cases to help guide how we wanted to refactor. Instead of building from the inside out (i.e. implementation->API), we were building from the outside in (usage->implementation).
This shift in thinking was phenomenal. Traditionally in developing something, I would figure out generally what a component needs to do, and then figure out the best way for it to do that (i.e. figure out the best implementation). The API would then be driven by the implementation. In the act of generating the test cases however, we were thinking about what we wanted to be able to do with the class, which in turn defined how we wanted to use the class. Thus, we first defined the API, and the implementation flowed naturally from there.
Now, perhaps this is how everyone else has been developing software and I've just been in the dark. But I've been around long enough to know that this isn't necessarily common practice, even if it is common sense to define the API and interactions first. The great thing about doing TDD is that it creates a smart and usable design, and you get a mechanism to automatically verify the functionality of your component. Two birds, one stone.
If you haven't tried or heard of TDD, don't laugh and discount it like I did; I encourage you to research it to see if it's right for you. And, as Ryan has already mentioned to most of our colleagues, if you value your career as a software developer, you owe it to yourself to read 'The Pragmatic Programmer'. Let me know if you want to borrow it.
Today, unlike most days recently, was a wonderful day at work. I actually didn't want to leave. I'm considering going to work early tomorrow. What happened? Well, let's go back in time a few months...
I think it all started with Ryan. Now, every day starts with Ryan talking. Usually before I get a chance to sit down and read my e-mail he's already bombarding me with questions about some obscure problem (perhaps only obscure because I'm only half-listening at this point). But those days he started talking about books - or more specifically, the interesting things he was learning about from those books - and I started to pay attention. He told me about this crazy mystical practice called 'test-driven development', where not only do the developers test all their code, but they write the tests before they write any code!?!?! I don't think I actually laughed at him, but I let him know that it all sounded well and good as an academic exercise, but it couldn't really be done in practice by sane individuals.
And so we moved on. Ryan kept reading and kept telling me to read these books, and I kept deflecting and diverting. Then something happened, and I'm not quite sure what it was (hey, I never claimed to be a good storyteller!) but I finally relented to the pressure. The book was 'The Pragmatic Programmer' by Andy Hunt and Dave Thomas (not of Wendy's fame). I don't want to say that this book changed my life, because I hate it when people say things like that. So, I'll just say that this book had a profound impact on how I view myself as a professional software developer. That sounds a lot less sappy.This isn't a technical book. It's a book about good practices and good attitudes. It's about taking pride in one's career. The book is littered with tips, but here are the first five (which I also have posted on my office door) that I feel are applicable to anyone in any profession:
Care About Your Craft
Why spend your life developing software unless you care about doing it well?
Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
Make Quality a Requirements Issue
Involve your users in determining the project’s real quality requirements.
Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
In a sense, this book revealed a whole new world to me. I had been blind as to how software development could be done. I didn't realize how much more I could be (and arguably should be) doing. And thus I started to read.
I have since read (and recommend)
- Implementing Lean Software Development: From Concept to Cash
- Practices of an Agile Developer
- Refactoring: Improving the Design of Existing Code (minus the large reference section)
The book I am currently reading is 'The Art of Unit Testing'. I'm not terribly fond of the format of this book (a lot of repetition), but it's a good beginner reference. I knew before reading this of the importance of formal unit testing (even though I had done little of it myself), but it has enlightened me to some techniques, common problems, and frameworks that could save a lot of time and effort in generating new tests.
So that brings me to today. I had been working on a connectivity bug over the last couple of days and during my analysis had uncovered a few 'loose ends' in the connectivity framework that Ryan and I had developed. Empowered by the 'fix broken windows' philosophy we decided to fix the root of the problems as opposed to patching the symptoms. The root of the problem was unfortunately embedded in the original design, but as Martin Fowler says: refactoring means never having to say you're sorry.
It was this morning that we first embarked on our first voyage of pair-programming test-driven-development. We had done plenty of pair-programming before (very successfully I might add), but never true test-driven-development (TDD). We knew that one of the main classes in our framework had too much varied responsibility, and we wanted to break that up. Instead of liberally ripping apart the code we wrote test cases to help guide how we wanted to refactor. Instead of building from the inside out (i.e. implementation->API), we were building from the outside in (usage->implementation).
This shift in thinking was phenomenal. Traditionally in developing something, I would figure out generally what a component needs to do, and then figure out the best way for it to do that (i.e. figure out the best implementation). The API would then be driven by the implementation. In the act of generating the test cases however, we were thinking about what we wanted to be able to do with the class, which in turn defined how we wanted to use the class. Thus, we first defined the API, and the implementation flowed naturally from there.
Now, perhaps this is how everyone else has been developing software and I've just been in the dark. But I've been around long enough to know that this isn't necessarily common practice, even if it is common sense to define the API and interactions first. The great thing about doing TDD is that it creates a smart and usable design, and you get a mechanism to automatically verify the functionality of your component. Two birds, one stone.
If you haven't tried or heard of TDD, don't laugh and discount it like I did; I encourage you to research it to see if it's right for you. And, as Ryan has already mentioned to most of our colleagues, if you value your career as a software developer, you owe it to yourself to read 'The Pragmatic Programmer'. Let me know if you want to borrow it.
