Travis: I’ll leave this to Des rewrite/update, she puts things into words 10x better then I. In mid May we rushed Sadie to the vet as she was lethargic, and it turned out she had a ruptured tumour on her spleen. Lougheed Animal Hospital did an amazing job keeping her alive until she was well enough to have the spleen and tumour removed, and putting up with us coming to visit her so often. She came home a little over a week later, and was later diagnosed with Hemangiosarcoma, which we found out was a terminal cancer in dogs with a median life expectancy of two months. We weren’t ready to lose Sadie so soon, so we did plenty of research, and took her off Acana and started preparing each of her meals at home, and providing extra supplements which had favourable results in trials (extra couple months of life expectancy). We took her to an oncologist two weeks ago, and they found a small tumour on her heart, so she began Chemotherapy. She was finally acting fairly normal the last few days, much more lively. She went in for blood work on Friday to prepare for the next round of chemo, and we took her for a walk afterwards, and she fainted after the walk, we rushed her to our family vet who were once again great to deal with, I always felt like they loved Sadie. We weren’t ready to put her down, and our worst fear is her dying alone, so we tried to rush her to a 24hr emergency clinic in Langley and Sadie died on the way. Luckily she wasn’t alone, I laid with her on the floor of the van as Des drove and she passed away half way there. Sadie was the most amazing dog I’ve ever met. She was the cuddle monster (both human and stuffy), ball fetcher, swim fanatic, puddle masher, and toy lover. I never met a dog with so much love for all beings, and toys. She died way too early, we weren’t prepared for it, we tried to be but I hoped we’d at least get through summer. But we tried everything we could to keep her alive perhaps selfishly. She will be missed by many, and will always be part of our family, and could never be replaced. This was meant to be one or two sentences as a placeholder until Des wrote a real one… I also included a photo album below (over 300 photos) of Sadie from the first day we got her until a week ago.
Or a link directly to the album at flickr.
If your objective is to keep your customers happy and satisfied, the best way I have found to do that is through involving them with your development and releases from the outset. When you show them that you value their opinion, take it to heart, and get their feedback from the beginning, not only will they be happier, but they will have the exact product they asked for. If I created a mantra for my company it would be ‘Early and Often’, builds, testing, integrations, collaboration, promotions should be done early and often. The faster we turn around features to the end users, the faster we get feedback, and the faster they’re promoted to production.
From the developer, and release engineer perspective everything needs to be automated. Nothing should be left to manual processes which can be time consuming and error prone. The objective for releasing a software product should always be to strive for making a non event. Everything needs to be repeatable, and automated, the only people that should worry about a release should be the marketing folks. Integrations and testing them should be automated and done automatically on check-in of source code.
I learned through trial and error, and experience what works for me and my organization. When I started my career in IT I was hired as a junior Java Developer, from the outset my role included being the release specialist. The first couple months on the job I implemented a linux based source repository called Aegis which forced clean builds and approvals prior to integration/check-in into the master branch. So naturally I have always been interested in different Change Management and Project Methodologies. The first three years into my professional career, the company I was working for was transitioning to CMM L3 which I was heavily involved in as I myself transitioned out of the developer role and became the Configuration Manager for the organization. CMM essentially is a document and process standard which depending on the level supported forced repeatable standards and processes when it came to everything from sales, development, corporate training, and support.
A small part of this was the organized structure for project management and development, CMM itself didn’t necessary cared how you conducted development or managed projects, but it wanted to ensure you followed a standard / repeatable process and plan. When I was in school, Agile wasn’t on the curriculum, we spent our Project Management classes only learning only the Waterfall model, both methodologies can fit into CMM.
CMM stands for Capability Maturity Model, and is a standard for policies/procedures that allow organizations to have repeatable and sustainable processes, it was primarily popular in government. Generally speaking CMM was very popular 10+ years ago, and is slowly dieing to the Agile movement. I spent a couple years assisting our organization in the transition to CMM L3, and preparing for an audit. In doing so I learned a lot about what does, and doesn’t work, and just how much of a waste of time/money it is for an organization to follow such rigorous processes.
CMM has five tiers:
- I: Initial (chaotic, or ad hoc); generally everyone with an undocumented process
- II: Repeatable; a process which is repeatable, so a set outline of required documentation
- III: Defined; a standard practice defined/confirmed to business processes
- IV: Managed; quantitative measurements
- V: Optimizing; process optimization/improvement, ever evolving.
Obviously given this, technically any project management methodology to some degree fits within CMM. We built rigid guidelines on what documents were required for a project to be signed off at any stage, and our QA department performed regular audits to ensure the processes were being followed. Eventually I built an automated way of sifting through our source repository (Perforce) for documents, and performed automated audits. We had dozen’s of required documents from Sales to Go Live, some of which spanned 100’s of pages. We would spend weeks/months on a Design document or Functional Specification only to have everything change by the end of the design phase, or worse yet, by the end of development. It wasn’t uncommon for us to spend a month collaborating on a design document with a half dozen programmers & architects only to have everything turned up sign down when we tried to get sign-off by the customer/stake holders in order to move onto the next phase.
Repeatable and definable processes themselves were actually quite beneficial, my concern revolved around requiring sign-off with each document and each phase, many of the documentation were never read, and requiring sign off just delayed project start. I would rather spend the lost time building prototypes or starting development, while collaborating with the customer throughout development.
So I saw from the outside looking in on all the projects what I felt worked, and what was deemed a waste of time. On one particular project which was fixed bid, so we tried to manage risk/limit change as best as we could to prevent our profit from shrinking. We spent nearly 3 months designing the system before we even touched a line of code, and that was after writing and getting sign off the following documentation (that I recall, I know there was others):
- Statement of Work
- High Level Estimate
- Project Charter
- Configuration Management Plan
- Detailed Estimates
- Project Management Plan
- Quality Assurance Plan
- Quality Control Plan
- Test Sweeps
- Functional Specification
- Detailed Design
- Release Plan
- Weekly Reports
- Gantt Charts
As you can imagine, a great deal of time was wasted on documentation that someone read once, and generally was never looked at again or followed. It was my job to take all the documentation and archive it in our corporate library, and audit each project to ensure they followed the appropriate policies and in the correct order. Each step had to be completed before we could move on.
My first project team was isolated from the rest of the company, we predominately followed a hybrid Extreme Programming/Waterfall model, while the remaining project teams followed Waterfall. As the months went by our product became vapour ware, and the team dissolved, and we became solely a waterfall company. I was a big proponent of Waterfall when I was a developer, but once I was on the outside looking in, and saw the amount of effort needed to keep track of every minute detail, and ensuring the gantt charts were accurate on a daily basis, I realized just how ineffective it was as a method of measuring progress. At the end of the day, it allowed managers to see pretty graphs, and it made them feel better about the progress and that was really it. It takes years of experience as a programmer on a project to learn how to build accurate estimates, and a gantt at the end of the day is only as good as the estimates. Which are generally very poor.
Change Management was managed via meetings every two weeks with the customer, because we already had a defined schedule and the projects were usually fixed bid, it made it difficult to approve new changes. The customer didn’t want to pay more, and we didn’t want to cram more work into a finite timeline. Approved features were added to the gantt and each of the above documentation were updated to reflect changes and pricing updates. More often then not, the customer didn’t want timelines to change so we worked increasingly insane hours to keep up.
I tend to be very analytical and structured by nature, I create daily todo lists for both work and personal, and follow them religiously. But my aim has always been to do my best to complete them, and if I don’t they flow into the next day. But even so I only believe in process and structure that allows my project to proceed effectively and efficiently, thus I feel it’s best to do little documentation, move into development as quickly as possible and follow up with the customer on a weekly basis to ensure your project is on the right track. We manage change by advising them that changes will require work to be removed, or the timelines move out.
Being agile is essentially a grouping of development methods which promote collaboration, self-organizing, adaptability and cross functional teams. It encourages early development, delivery, and continuous improvement.
When I transitioned to my current company three years into my career, I was hired as their first full-time programmer. This allowed me to single handedly create the policies and procedures from the ground up. These processes have changed drastically over the years as I feel process should always be evolving, which is the whole point of being Agile. In the beginning we fully implemented Extreme Programming (XP), as this is what I had experience with. I read and learned as much as I could as we only utilized the programming aspects of XP at my previous job. We had two programmers in a shared room, so we glued cork to one wall, and used string to separate the stages of a story, queue cards were used to keep track of features and bugs.
Extreme Programming is essentially taking the traditional waterfall model, and repeating in cycles every two weeks. This allowed us to define or refine, development, and have something close to releasable every two weeks, the constant collaboration with the customer or stakeholder of the project ensured the end result was always being refined, and final product was exactly what everyone wanted. This also allowed us to continuously integrate, test, and release the build to QA every two weeks. One of the first things I did was to install Subversion, and a continuous build environment called CruiseControl. We used the cork board to track user stories and bugs, and it had three columns: Backlog, In Progress, and Complete. We successfully used the board for nearly a year, but I wanted more metrics, I wanted to know quickly what our velocity was, and how close our estimates were. At this point we were transitioning to working from home part-time, and provided a good opportunity to try out a web application to manage our projects.
I installed XPlanner, this allowed me to get the metrics I wanted. We still used story points, but I preferred tracking hours as I wanted to know how accurate my estimates were. To this day I still use both story points and hours to track my work. We used junits to test our business logic, and manual testing for acceptance and regression testing.
As the years went on we refined our processes, and now we use something more similar to Scrum.
Around 2007 we implemented Selenium to automate much of our regression testing, we still use manual testing for boundary and capturing errors or missing regression tests however. Automated regression testing combined with CruiseControl allowed us to build a continuous integration/testing environment and report back as soon as we check in source code if we broke our baseline. It was our policy to build user stories and/or tasks that took no more then 1-2 days, so we had to check in our source code atleast every other day. This allowed us to know quickly if everything is still compiling and passing our regression tests. Once a new feature is developed we build in new automated regression/acceptance tests to validate the the feature.
I wasn’t entirely happy with XPlanner, I was on the look out of a replacement for years until I found one I was finally happy with in Jira – Greenhopper around 2008, and we’ve been using it ever since. Internally we actually follow two different agile methodologies, Scrum and Kanban. Generally internal non development projects follow Kanban, and the rest follow Scrum. I’ll discuss our Kanban procedures more later.
We manage change management on an as needed basis, one of the aspects of software development that I have learned, and have never shied away from is scope creep. If we don’t allow scope creep, at the end of the day our customers will never be satisfied with the end result, no matter how prepared you think you or they are. There will always be changes after they have saw and played with the product. In saying that, there’s always a fine balance of managing what can wait until a patch at a later date. At the start of a project we define all the user stories for a release, lets say we have release 6.3 planned for a October 1st go live. We get the team and stakeholders together, and select all the user stories with story points estimated, at this point we have an idea of what our average velocity is for a two week iteration based on previous projects. So we know approximately how much work can be completed within the allotted time. We always work on features from highest to lowest priority, and hardest to easiest. This allows us early on to know if a release may need to be refined or shifted.
At the start of the release we choose which features will be chosen for the next Iteration (also sometimes called a Sprint), the features are chosen based on the priority and difficulty of the user story. Once a story is added to a release, the programmers select which stories they want to work on and create sub tasks for the user story with hour based estimates for each task. The iteration is started, and generally every day we try to meet internally to ensure everyone is on the same page, however we’re a small team, often times we don’t have a formal stand up meeting as we talk over IM for much of the day and any questions come up naturally. At the end of each iteration we close off on the finished stories, and migrate any open stories back to the release backlog. Naturally these stories move back to the top of the queue, and are most likely going to be selected for the next iteration. The completed iteration is deployed to QA, and our customer/stakeholders are provided access to give us feedback. This provides our customers ample time to provide feedback, often times a customer doesn’t necessarily know what they want until they see the end product, thus its important to refactor and refine your product to make changing it as painless as possible. Any feedback is logged as user stories and assigned to a future iteration. Even for internal product releases we always have at least one customer represent our entire customer base, its always someone from our User Group. Near the end of a release cycle we provide a half dozen users access our QA site for acceptance testing and feedback.
Our second methodology we follow is Kanban, its essentially like Scrum but with less process, more similar to XP. Thus we generally don’t follow it for development releases, we use it internally for operations, marketing etc. One of the biggest differences you’ll see with Kanban from Scrum is the removal of Iterations. The purpose of Kanban is to remove the time box, this is especially beneficial for those development teams who also do maintenance programming or are likely to be interrupted during an Iteration. Kanban came from Toyota where they developed a card system that required a card to be presented to each assembly line to ensure they didn’t have excess materials being used then necessary.
The time box is instead moved to the workflow state. Each workflow state such as TO DO, or In Development limits the amount of tasks which we call Waiting in Progress (WIP). If we limit the TO DO workflow state to say 5 use cases, this forces the customer to remove a TO DO item back to the product backlog if they change their mind and want to add a new item.
The developer’s then pull this TO DO use case into the In Development or ongoing workflow state when they’re ready to do so. The releases to testing are then event driven, so when the developers are ready to release the product to Testing they will do so. This can be on a use case per use case basis or weekly, but generally won’t be any longer then every two weeks (if its a very big use case). We almost never use Kanban for development unless we’re working on a release without a timeline and we’re expecting interruptions.
At this point we begin planning our rollout, starting with our SaaS customers, and then coordinating potential upgrades for each of our self hosted customers.
We manage a release wiki on Confluence for tracking story questions, or providing release / iteration burndown graphs for progress reports. Naturally a release plan is always very minimal, we list the stories for the release, a couple graphs showing progress, and any large user stories with rough mockups/questions. As mentioned earlier, we try to do only as much documentation as needed to get started on coding, we allow the product itself to speak to the customer and refine from there. I’d rather spend a half a day coding something for them to see and play with, then building a document, because they will have more questions/refinements after playing with it then after reading a document.
Even though we pride ourselves on being stable every two weeks, we support a half dozen browsers and various release environments. So we still give ourselves one month after code complete to finish off any last minute testing before migrating to our SaaS or self hosted customers. I have always been very paranoid about buggy releases, and would rather over prepare for a release, then release something completely buggy and deal with the aftermath.
We usually strive for one major, and one minor release a year. Meeting atleast twice a year to go over and re prioritize our backlog of features, we build an annual roadmap which we strive to meet, however at times we take on “for pay” features, and this delays baseline features from our roadmap.
I believe being Agile falls under not only development, but all aspects of a business including operations. While we prefer to keep development documentation to a minimum, I’m not anti documentation. I believe in minimizing bus factor, so every repeatable task, policy and procedure must be documented in case a new employee needs to be quickly brought up to speed. Our document archive contains hundred’s of documents ranging from how to install/deploy a development server, frequently asked questions for salesman, to Success Profiles for Human Resources.
Part of being Agile is keeping everything as simple and automated as possible, this includes all of our user and server environments. Years ago we moved all aspects of our business to the cloud including the following:
- Source Repositories
- Continuous Build servers
- QA servers
- Issue Tracker
- Production servers
This allows us to work without worrying about backups or maintaining infrastructure and it allows us to focus on what were good at which is supporting and developing our product. Ina addition, our development environments are setup as virtual machines to allow a new programmer to easily spin up a new build environment, and in my case I love to use them to run automated tests in my virtual machine while I continue to work on my main system. Plus I run Ubuntu as my main development box, and use Windows based virtual machines for my local continuous build environment.
Where do we go from here
I feel like if your not always looking for ways to improve your processes then your likely delusional, and no one has everything running absolutely perfectly, there’s always room for improvement. In my case, on my wish list is to further modularize our product to speed up build promotions and minimize risk of upgrades, as well as automate build promotions. Right now to deploy a new build to production it requires a resource to be available at night, to upgrade the WAR, and reboot the instance which requires a 3-4 minute downtime of the server.
My obsessions almost all delve around self sufficiency, whether its cars, housing, agriculture, grey water treatment systems etc.
It started about 12-13 years ago when I first heard about Earthships, I don’t recall where I first heard about them. But I’ve loved them since day #1, Desiree isn’t as keen on living with earth around 3 of 4 walls. I suspect when the time comes we’ll build a traditional house with all the mechanisms in place that I cherish, such as the grey water system, giant indoor planters, off-grid, and tons of windows.
Earthships were created in the 70’s in New Mexico by Architect Michael Reynolds. They’ve evolved in the last ten years, early on when I first started researching them much of the designs included circular or horse shoe shaped modules. That design seems to of disappeared from their website over the couple years, I’m not sure if there were specific reasons for it or not but the modern design has only the exterior rear walls now with earth rammed tires.
An Earthship was designed to face South to maximize natural light and solar gain during the winter months. The point of an Earthship is to use supplies which are most recycled to keep the costs down, and utilize systems which allow for self sufficient living through water reuse, foot production and energy storage.
The thick / dense rammed earth tire walls provide thermal mass that naturally regulates the interior temperatures no matter the temperature outside. The tires are often put together by two individuals, one does the ramming, often with a sledge hammer pounding the earth into the cavern, while the other provides the soil dumping it into the hole with a shovel. A single rammed tire can weigh up to 300 lbs, and often adobe or concrete is sprayed on to finish the wall. Internal, non load bearing walls are often made of recycled pop cans combined with concrete, and plastered with adobe. The techniques used in building an Earthship uses up to 80% less concrete. The tops of the exterior/interior walls are topped with wooden trusses, and insulated to prevent heat loss.
Grey Water System
This aspect of the Earthship is what drew me to it in the first place, I love how you can reuse all the wasted non toilet water for reuse either in the toilet, or for feeding the planters. All water use within the house is captured via cisterns attached to eaves on the roof., the cisterns are buried to be protected from the sun. The water from the cistern is gravity fed into the WOM(Water Organizing Module). The water is now safe to use for drinking or use. This water is stored, and treated for use throughout the house using a WOM to treat the grey water inside the building, and sewage from the toilets separately. All interior non toilet water (grey water) is reused for for both interior and exterior botantical cells. As you can imagine, this uses far less water then a conventional house as nearly all water is used atleast twice before it feeds the botantical cells.
In doing so we eliminate the need for both public sewage, and spectic systems. The system can also be setup to flow entirely into a conventional septic field/tank.
An Earthship creates an environment which provides not only food, but cleanses the air, and recycles the water via indoor botantical cells. I’ve even seen indoor ponds with fish, or fruit trees.
I have always wanted to be off the grid, but I feel like we’re close to a breakthrough in solar cells and battery storage. I’d hate to throw down 20k only to miss out on the latest technology. Being that we live in British Columbia we generally get very little sun for 4-5 months of the year, so I suspect we would need to supplement with wind turbines. I think Tesla is close, they’re now selling home batteries with ample storage for a reasonable price. I suspect within 2-3 years the price of batteries will halve.
The Earthship is built to regulate temperatures on it’s own as noted above, so electricity isn’t needed for heating or cooling which is one of the biggest expenses when it comes to electricity.
Des isn’t as keen on living with earth around the house, so I think our plan will end up being a modern house with tons of windows, while utilizing cisterns/grey water systems/solar/window power. The lack of mass around the house will require heating/cooling either via propane or other means, and hooked into the grid as a backup, and for feeding excess back into the system. Something more like below, either way it’s our goal, and we’re no where near ready, and have years to figure out our plan.
I love cob homes as well, but they’re a lot of work. Either way, I won’t abandon my dream of living in a self sufficient house, even if it’s 10-20 years down the road. With weather patterns changing, and droughts becoming a norm, I think it’ll become a lot more popular, and hopefully cheaper in the future.
I should start off by saying I was never a car enthusiast, in fact I still think auto racing is nothing but noise pollution. My fascination with electric cars started in 2002 when I read an article on a new concept car by GM called Hy-Wire, which was an electric car powered by Hydrogen. The car used a delivery system often seen in fighter jets called Fly by Wire. The cavernous storage space due to the skateboard chassis and lack of combustion engine peaked my interest in the beginning, as I learned more about the Drive by Wire system I became increasingly fascinated. The Hy-Wire got its name due everything being controlled electronically, so the steering/controls can be move to either of the two front seats.
My interest may have been because of just how un-car it was, it had no brake or gas pedals, the car’s steering wheel was more similar to a game controller, with everything built into the wheel. I followed the progress over the years, and heard they were building a consumer car based on the technology. Unfortunately, the car that ended up getting developed was so far from the Hy-Wire that I question if they borrowed anything from the car.
The Chevy Volt was the car I had heard was spun off from the Hy-Wire concept car. It’s an electric car, but uses a combustion engine to charge the batteries. I started following the volt’s progress right around 2007 when the concept car was released, everyone loved it. The car looked menacing, and pretty damn cool, unlike most hybrid’s on the market which generally all look the same in order to get the least drag, and thus use less gas. Little did anyone know however, the end result would be nothing like the concept, they got everyone interested by showing the concept, then completely redesigned the exterior in order to produce the least amount of drag possible. The end result is the car we see on the road today.
When I found out the engine compartment was now consumed with a combustion engine and the skateboard chassis was awol, I was disappointed to say the least. However, true to the core, it was still an electric car, and the combustion engine was only used for long distance trips. At the time it made sense, battery tech wasn’t where it is today, so I conceded, and became slightly obsessed with their success.
Not long after the Volt went on sale, Tesla popped onto my radar. I followed them but not fanatically early on because of the cost of the car. One of the first things I heard about the company was how they took used laptop batteries to build their battery packs, I’m still not sure how entirely true this was. But it’s what got me interested, I loved how they didn’t go the conventional route.
When they announced the three car phase ending with a reasonably priced car in 6-8 years, I started following them much closer. To me Tesla felt like a company shunning everything done in the last 100 years, and hired bunch of computer geeks to build a car that today’s generation would want to drive. The end result is the Model S, which is debatably the most beautiful car ever produced. I feel like it came full circle, and the Model S is a beautiful version of everything I loved about the Hy-Wire.
Like the Hy-Wire everything is built into the floor of the car, thus making it virtually impossible to roll over and the weight and high grade chassis made it indestructible in accidents. Everything about this car is absolutely beautiful, unfortunately I’ll never own one as its way outside my price range, but the Model 3 announced in 2012 for sale in 2017/2018 is where I’ve got my sights set on.
We had planned this trip since our Arcade Fire weekend in Seattle in ’14. We had threatened to do a Blue Jays series in Seattle with my Dad and Carla for awhile since my Dad is a huge Jays fan, but the days just never worked out. This time we started planning early, so the condo/Jays tix/reservations have been booked since January. We wanted to balance downtime, with getting to see more of Seattle. The rundown of our trip is below, I feel like we balanced it out fairly well. Luckily we live close by so we can always check out what we missed next time.
We left at 9am, and got to the border by 920, luckily we got a crossed the border within 20 mins, and into Bellingham by 1030 so Desiree could have her traditional Clover @ the Guide Meridian Starbucks.
We hit the road, and arrived in Seattle by 1230 for our tour of the Starbucks Roastery, and lunch at our favourite (thus far) Seattle Restaurant “Serious Pie”. Desiree had been at the Roastery once before, but the rest of us had never been. It was interesting to see the process of how the coffee is made from start to finish even if I’ll never be a coffee drinker. The last time we were in Seattle for the Arcade Fire concert we hit the Serious Pie on Virginia after seeing it on one of Anthony Bourdain’s shows. So we vowed to make another trip this round, luckily one of the three Serious Pie’s in Seattle is inside the Roastery. While we were there Tommy Douglas was at the table next to us doing some schmoozing, and signing books.
When we finished we had nearly two hours to kill before our 4pm check-in, so we drove down to Pike Place to kill time. I have gotten better with crowds, I no longer feel anxious being sardined in with hundred’s of people in confined areas, and Pike Place definitely proved my new found skill As always I lost Des half way through Pike Place, but we met up near the end, I don’t know how we survived without cell phones. We went to Pike Place last year, its much like Granville Island, mainly over priced junk, you just go for the experience and say you’ve been there.
We arrived at the Condo at exactly 4pm, Des went in to grab the garage key, and found a room there wasn’t clearly not only cleaned, but the previous tenant’s obviously didn’t bother to do any straightening on their own. We never leave a condo/hotel etc dirty when we leave it, I would just feel guilty otherwise. We stayed in a two bedroom ondo at the Modo Apartments on 3rd Ave, last year we stayed at a once bedroom suite on 2nd ave. It wasn’t a bad experience, just an unfortunate start to the trip. The room was directly above the bus stop which was great for convenience, but it meant couldn’t leave the window/door open.
We reserved a parking spot at CenturyLink Field acrossed the street of Safeco, while it ended up being convenient and a short walk. The nightmare getting in/out made me regret the choice. We thought we were giving ourselves ample time to get there, so we could spend over an hour checking out the Stadium, but the traffic down wasn’t pretty. We arrived at lovely Safeco Field at 630, we quickly found our seats, then went to find an ATM. We browsed around for food, Desiree and Mallory had crab fries, and garlic fries, and I had a BBQ poboy and yam fries. Unfortunately we missed the first inning, and the food was sub par, I should have stuck with the traditional ball park smokie.
The seats were great, the game started off well for us, and quickly soured by mid game. It felt like 50% of the fans there were blue jays fans, they were everywhere and very vocal. I felt bad for the Mariners fans having to put up with us obnoxious Canadians. The environment helped ease the pain of the loss, Safeco is a beautiful stadium.
We realized near the end of the game it was fireworks night, so we stuck around until 1030. Deep down, I thought it was going to be kinda lame, but I was pleasantly surprised, and it turned out to be really quite fantastic. The fireworks were synced with music, along with the lights in the stadium to be quite a little surprise after the game.
We mixed it up for day 2, and parked the car for the day, and walked to WestLake Station to catch the light rail to Pioneer Station. Unfortunatley, I’m starting to associate Seattle with pee, I feel like Vancouver has a bigger homeless problem, but I almost never smell pee in downtown Vancouver, but you can’t walk down a block of Seattle without getting a potent whiff of pee, and its normally always around parking garages, bus shelters or pubs. I had a bit of anxiety about missing our train, but it all worked out and we arrived at Pioneer Station with ample time for our Underground Tour at 11am.
We had a reservation for the Seattle Underground Tour for 11am. The true ground level of downtown Seattle is about 15 feet lower then you see today. Over several decades in the late 1800’s they built up the city to prevent flooding. It was fascinating to learn about the history/development of Seattle, and how sewage, flooding, fires, and prostitution helped develop the Seattle we see today.
Our tour ended at about 1230, and we made our way back to Pioneer and caught the light rail to Stadium Station, and walked to the Stadium. We arrived with 20 mins to spare, and this time we grabbed some tried & true stadium food, and got some Nachos and a Smokies and made our way to our seats.
Desiree did a fantastic job picking our seats this year, yet another great view of the field, directly behind the Blue Jays bench. It felt like a bigger congregation of Blue Jays fans, and there was one really annoying drunk guy behind us constantly taunting the Mariners fans. I was secretly hoping someone would thump him. The Jays came out strong in the 2nd for three runs but the Mariners always had an answer and chipped away with runs in the first four innings. Before we knew it we were down 5-3, and Jays weren’t playing well. That all changed in the 8th inning when Carrera came up and tied the game with a swing of the bat to make it 6-6. Des was thrilled to see Sanchez in his first game back from injury start the 8th, and still throwing consistent 99mph pitches. The Mariners brought in Rodney who traditionally tanks, and he loaded the bases with none out, Colabello singled bringing in two runs, and the Jays went on to win 8-6.
After making our way through the maze of people, and losing Des/Mallory for 10 minutes, we made our way to the Stadium station, and took the sardine fest back to Westlake Station. We hung out at the condo for a few hours, and went out to catch our 710 bus to our Dinner reservation at Toulette’s Petit. Unfortunately we didn’t know it was the night of the Torchlight parade which created a log jam on our street, resulting in 30 min delay of our bus. Luckily the restaurant held our reservation, we arrived at 8 for our 730 reso. Toulette’s is a Creole restaurant, primarily specializing in Southern French cuisine. The meal was great, I’d probably give it an 8 out of 10, I’m spoiled with the lovely food Desiree always cooks so it felt like a home cooked meal, but I didn’t order anything out of the ordinary like Des/Mallory.
We wrapped up our trip by doing the one and only thing Mallory wanted to do on the trip, hitting a stored called Kinokuniya. They specialize in selling Manga/Anime, and various other things. Mallory was in Manga/Anime heaven and we spent over an hr in the store, and $140 US later, we left for Bellingham.
We made a few stops in Bellingham to grab some booze, grub (five guys) and random supplies, and made our much anticipated final stretch home only to find out there was a 2 hr wait at the border as everyone and their dog was apparently coming home from the Jays series at the same time. I thought it was odd that Trader Joes was so busy with Canadians since our dollar is so lousy, but now it made sense.
The weekend was deemed a success, and I think everyone except for Mallory is looking forward to the next Blue Jays weekend.
I was digging through some old photos, and thought I’d share them for archival purposes, I’d hate to eventually lose them.
My grandfather on my Mother’s side, Grandpa Offless:
Posing next to my Dad’s nova.
Camping when I was youngin, and busted eating Dog biscuits.
My brother and I hanging out at the campground in ’79
My brother, and I, and my Grandpa Morris.
My first Tiger-cat game against Ottawa around 89 or 90.
My brother and I use to play broomball, the kids league only lasted a year or two unfortunately.
In grade school we use to have hobo day, where you got to dress up like a hobo, I was taking a photo with Trevor dressed up for school.
My turn to dress up…
Highly recommend Mad Max, the best movie we’ve seen thus far in 2015!