Every year, there is a convention known as TED - Technology, Entertainment, Design - that invites a lot of smart people to come and give talks.
Thanks to a sponsorship by BMW, the organization has been making a bunch of previously-recorded talks available.
Jim sent me a link to a great talk by Burt Rutan about the future of space flight, and there is lots of other interesting stuff there.
Thanks, Jim.
At the end of summer last year, we got some water in our basement. Given that our house was built in the late 70s and the yard slopes down towards the house, it wasn't very surprising, but it did mean that we needed to get some drainage put in.
We used that as an excuse to do some long-delayed landscaping in our house. When we bought the house, the real-estate agent described the landscaping yard as having "potential", which is "agent-speak" that means "a blight on the neighborhood". We addressed it by letting the plants get more overgrown.
So, it was a total rip-out, including the front "deck". Here's what it looked like:
This design was the height of style in 1972, as was using substandard materials. You used fir instead of cedar because... well, because you just did. Note that the second board is broken out.
We had our landscape guy rip it all out. When meant we couldn't get to the door. Time passed, I did a few design sketches, we decided on one, and in late December I paid $372.30 for the priviledge of building a new deck. A nice deck, one that we could use and where you could walk between the boards with impunity.
After I got the footing holes inspected, it was time to pour the concrete. If you can put the beams on the ground directly underneath where they will ultimately be, you can pour around the connectors and be assured that things will line up perfectly. Here's what it looks like:
Note that you can actually see the house now, and that the door is about 4' from the ground.
Next is putting the joist hangers on the house. Our house has an ledger as a trim piece, so we attached that to the house joists with lag screws (required in earthquake country). And then the joist framework got put on top, and the second inspection was done.
And it looked like this:
The beams are 4x8s, and the joists are all 2x6. All the joist hangers are Simpson Z-Max, and all the nails are hot-dipped galvanized. The current crop of pressure-treated woods are very corrosive and if you don't use the good fasteners, they'll corrode out quickly. Stainless connectors and fasteners can be used if you're made of money. If you look closely next to the house, you'll see some black - this is grace's water shield membrane to make sure the water comes over the front of the joists. You can also see some extra 2x6 bracing on the main beam.
For sake of scale, the deck is 20' wide at the widest point.
Next was posts and decking. We used Trex in a 5/4" x 6" size so that we wouldn't have to do the yearly deck maintenance. Trex recommends 16" spacing on the joists, but I went down to 14.5" to line things up and make the deck a little stronger - the trex is a bit plasticky.
Trex is fairly easy to work with. The decking layout is a bit complicated - there is a "picture frame" strip all the way around the outside of the deck, and then the spacing has to line up perfectly so that the boards from the wide section near the house can transition seamlessly. I did this by measuring out the spacing and using chalk lines, which would have worked perfectly if the decking was really 5.5" wide, but some pieces were nearly an 1/8" wider. So, the spacing isn't perfect.
The picture frame went on first, and then the rest of the decking. They are all fastened down with FastenMaster's Trapease screws, which are color-matched and cut a perfect circle with every screw. I used my Makita impact driver, an absolutely killer tool. I built a jig to mark every screw location so it was easy to get them correct.
Oh, and the posts all went on first. The railing-size ones are trex, and there are some big ones that are made from pressure treat. They're all sandwiched between joists and attached with some hefty bolts. Here's it is with the decking on:
Next step was to build the arbor that goes on the big posts, all made out of cedar. I surfaced 1x8s on my thickness planer, finished them with stain, and then built boxes out of them (actually the second try - the posts warped considerably so the boxes had to get bigger). The cross pieces were made out of 2x12 cedar, and the top pieces out of 2x2.5" cedar. The high pieces got fabricated on the deck, and then we lifted it up slowly with some clamps to keep it from coming down. The remaining pieces went with a ladder, and the screw holes were patched with some bondo (used because it doesn't shrink).
Finally, it was time for railings. We had planned to use metal tubing, but my contact in the trades was not to be found, and the other fabricators I found were 12-16 weeks out. So, we went with cedar. I did all the fabrication in the garage, and then brought the pieces out and attached them to the uprights. The top board is a piece of Trex decking. I cut all the pieces, and then attached the mitered joints with pocket screws, and attached the top board from underneath. The railing pieces are 2x2 cedar, and the pieces they slot into are 2x3 cedar.
Which brings us to the final picture:
There will be lattice to hide the posts, and the slope down to the deck and the steps are only temporary - that will be heavily revised.
The total elapsed time was around 10 months, with a lot of rain delay and a bit of sun display.
Costs:
Permit $372.30Framing $700.00Decking $2300.00Arbor $ 600.00Railing $ 350.00
Total $4300.00
That probably misses a few hundred dollars of incidentals.
The PTA at my daughter's middle school is having an auction next week, and her band teacher came across an old student trumpet that she thought would make a nice lamp. Here is the result.
The mouthpiece of the trumpet had gotten stuck, and the tube had gotten ripped when trying to take it out. It was more to fix it than the trumpet was worth. So, I got asked to do the lamp conversion.
Here's what I did:
A pretty cool result
There's a group organized to put on a yearly stage race in Washington State.
Tour of the Evergreens
They're looking for some donations to help make it happen, and for help designing a logo.
This will be very cool if they can pull it off.
When an Avalon app starts up, it parses the XAML file, and as it parses the file, it creates the object tree.
Creating the object tree requires that the constructors for the objects be called. And if one of those constructors were to fail, you get a XamlParseException. Something like:
Cannot create instance of 'Window1' defined in assembly 'WindowsApplication4, Version=1.0.2480.23268, Culture=neutral, PublicKeyToken=null'. Exception has been thrown by the target of an invocation. Error in markup file 'Window1.xaml' Line 1 Position 9.
And then you spend a few minutes trying to figure out what is wrong with your XAML file that's making the parse fail. What's wrong with Line 1 Position 9...
If you see a XAML parse error, you might want to check that out. Or you could do things the right way and hook up to the Initialized or Loaded events instead of putting your code in the constructor.
Humorish
I coined it this morning at breakfast. I said something that wasn't funny (to my daughter or wife), though it was in the form of a joke.
To be contrasted with
Humorous
As somebody who is interested in Scrum but hasn't yet had a chance to try it, I've been paying attention to the various experiences people are having with it.
I've been noticing something for a while, but I didn't really realize that there was something bigger going on.
I call that phenomena "Scrumbut". It shows up in the following way:
"We're doing Scrum but..."
I'm not a strict methodologist - a specific methodology may need to be adapted to a specific situation. But most of these are anti-scrum rather than modified-scrum.
That this phenomena exists may not be news to you, and it wasn't to me. But what I realized this last week is that scrumbut has led to another phenomena...
Namely, it has led to scrum being a naughty word. Managers are working with groups that say they are doing scrum, and then when scrumbut doesn't work, they decide that scrum doesn't work.
How to approach this? Well, I think you need to advocate specific principles rather than advocating scrum. If you tell your management that you are going to be "ready to release" on a monthly basis and that they get to give feedback on what has been done at what to do next every month, I think you will likely get a better response.
I'm starting to play around with Avalon (a name that I'll continue to use because of the savings of 2 syllables over WPF. It's my little contribution to help out in the syllable crisis... (Maybe the decibet would help....))
And I've found it a bit hard to find out what you need to start writing Avalon code. This may be old news, but I thought I'd document it anyway. Note that these instructions are for the fall of 2006, and there may be newer previews when you read this. Most of what you need is documented on this page...
If anybody from the Avalon team is reading this, could you please modify the "get the beta" page to have more useful directions, and see if you could provide something other than the DVD image.
You may have noticed that my blog page has changed appearance - this is part of a switch to community server 2.0.
As some of you undoubtably know, the appearance of most blogs (and web pages in general) is controlled by a technology known as CSS. I've read a bit of CSS, but I'm not really up on it, which means I never really do much with it.
A fellow MS blogger pointed out two tools to help:
The IE Developer Toolbar has a DOM viewer that lets you see the tree view of how a web page is organized - you can see how a title is defined, where text lives, etc.
And SiteVista lets you edit the CSS on the fly. Point it at a site, and it will show you the style sheets in one pane, the web page in another, and the current view in a third. Edit the style sheet, and your changes show up live in the current view.
*Very* nice. I may modify (a deep understanding of my graphics skills prevents me from saying "improve") the look of my blog now.
I noticed on my blog, there's a base CSS sheet and then my customizations on top of it. In that case, SiteVista will only show changes if you copy the element you want to change to the customization page, which is okay because that's where you'll want them eventually anyway.
NewsGator - which I use to fetch blog posts - today decided to fetch an August third post for me. At least it's from this year.
In it, Larry talks about the volume control of a TV going from 0 to 63. And he discusses a possible reason for it, as do many of his readers.
Which brings me to:
Eric's Law of Arbitrary Limits
If you are designing a piece of tech gear - be it hardware or software - and you need to choose an arbitrary limit or range for something, make sure the limit is either 2^n or 2^n - 1.
The majority of the developers who use your product will convince themselves that you've chosen that limit for some well-thought-out reason, such as the internal data structure of your product, rather than just choosing a number because. They will speculate on why you chose that particular number, and you won't spend your time justifying the limit.
And they will be happy that they understand "the secret" behind why you chose such a strange number...
A while back I came across this post about agile.
I originally was going to write a comment about that post, but I think the commenters have done a good job at that. I will point out that the environment described in the post is a lot like many of the internet boom startups, few of which are around right now.
But in writing some thoughts down, I realized that I was really writing about why I found agile to be interesting. So that's what this post is about.
I've worked on a ton of projects, some short, some long, some small teams, some big teams. But fundamentally, writing software is an exercise in:
and
These shouldn't be a surprise to anybody. When we start coding, we always have imperfect information. We don't know if our design will really meet the customer's needs, we don't know how long it's going to take us to write, we don't know if our architecture is feasible to build, we don't know if it will perform well enough, etc. And things will change along the way. Market conditions will change. Customers will modify their priorities. New technology will become available. People will join or leave the team.
There's a name for trying do something in that sort of environment, and it's not "engineering".
It's research.
Applied research, to be specific.
And doing research requires a different approach than engineering.
Way back in 1961, President Kennedy made his famous "moon speech". At that time, the only US astronaut was Alan Shepard, who had flown a 15 minute sub-orbital flight. The ability to send people to the moon seemed out of reach. But the leaders at NASA came up with a plan - they decided on three different programs: Mercury, Gemini, and Apollo. Each program had a theme and a set of goals, and each flight had a set of smaller goals.
Sometimes things worked, sometimes they didn't. After each flight, they looked at what had happened, decided how to adapt, and went on to the next flight. And over the span of 8 years, they accomplished their goal. All by following the "design a little, build a little, fly a little" approach.
After Apollo, NASA decided to build the shuttle. They did a lot of design up front, made a lot of promises (both schedule and capabilities) and then started building. They ran into lots of difficulties with the main engines (ultimately solved), and the thermal protection system (not really solved). Ultimately, they finished the vehicle, but it took years longer than they expected and ultimately didn't do what they had designed it to do or what they needed it to do. And it has very high maintenance costs.
The analogy to software development projects should be obvious. Shuttle is like most big software projects - lots of planning up front, lots of promises, followed by delays as problems are addressed, and then the ultimate release of something that doesn't measure up to the original idea. We convince ourselves that "this time it will be different", despite the fact that the same thing has happened every time we take this approach.
Incremental development accepts the realities of the environment, and takes a different approach. You know that you don't know enough to finish the project and you know that things are going to change, so you bite off a manageable portion - say a month's worth of work - do enough design, write some code, and then see how well it works.
And after that month, you modify your plan based on what you learned.
Design a littleCode a littleFly a little
That's what agile means to me.
Yesterday, I had the chance to go on the Kitsap Kolor Klassic (really, the Kitsap Color Classic), but I didn't.
Excuses were proffered and accepted. I was tired from all the rides I'd done. I needed to work on my deck. I had family committments. All were good.
But in truth, I just didn't feel like a long ride. So, I went out on a short ride (about 30 miles), and 12 miles into it, my bike converted itself from a 30-speed to a 2-speed through a break in my rear shifter cable (right at the shift lever). And since you can't run a chain from the small chainwheel to the small sprocket in the back without a lot of mechanical pain (and risk of chain break), neither of the gears I had were of much use.
A quick look around showed that Richard Dean Anderson was nowhere in sight, so I jury-rigged the shift cable. Here's what you do:
Happy was I that this didn't happen in the middle of a long supported ride. My laziness saved the day!