Since my last post on flying, much has happened. I took a vacation (in Smith Mountain Lake, Virginia), I flew four times, and my instructor pilot resigned. This last point had a significant impact in how I was thinking about my flying. I heard via an email from the assistant chief while I was in Virgnia: “Grant is leaving to pursue his flying career. We’ve paired you up with Shane.” My second discovery flight (why two? long story…) was with Shane in a Cirrus SR20, and I enjoyed that, so I looked forward to flying with him. That said, I was afraid of more churn. In the 9 lessons I had thus far, I had flown with 4 different pilots - Grant, Jim (the chief), Jamie, and Jamal. If you included my two discovery flights, it jumps up to 6 (Shane and Scott). All these pilots were great in their own way, and I learned much from each of them. However, in the process towards becoming a private pilot, you need consistent, steady feedback in your faults, so that you can improve. It’s tough to get that when your instructor changes so frequently. In the last 4 or 5 flights, though, Grant and I were on a roll, and had done some consistent flying together. Grant’s resignation now made me think that the churn would begin anew.

After a bit of yak shaving while I updated my blog, I’m now back to talking about flying. My typical flying schedule is Tuesday, Saturday, and Sunday. Lesson 8 was Tuesday, August first.

Frequent readers of this blog (all 1 of you, and that includes me), may notice that the styling of the site has changed. When I first created this blog, I was still working at ThoughtWorks, and a colleague was using (and recommended) Octopress. It met my needs. I had looked at WordPress, which is a popular blogging platform, but I wanted something a little nerdier. I don’t get much chance to write code these days. A blog platform that is “code-ish” was attractive. To blog with Octopress, I create markdown files, check it into Git, then use git to push to Heroku. I can write my own CSS, use ruby for any extensions. Also, I liked the base styling that you get from Octopress.

Anyone who knows me well knows that I love gear. For all my various hobbies (Exercise, Cooking, Computers/Programming), I obsessively research the right gear to have. Sometimes I do this for hobbies that don’t stick around (I thought I was going to be the next Norm Abram, and bought some nice woodworking tools before reality set in). I find it important to have the right tools for the job, probably to a fault. Some of the stuff that I’ve purchased has had a long life and I use it all the time. Some has been tossed aside.

Tuesday, July 25, 2017: I know. I’m telling the pilot training story out of order. My last post covered lesson 7, where I wasn’t at my best. This post will be about lesson 5. Lesson 6, I’ll talk about it at the end of this post. Warning, this is a long one. There’s a lot to talk about.

Sunday, June 30, 2017: We were sitting at the end of taxiway-A, performing the run-up. The RPMs were at 1800, the magneto check had gone well, and now I needed to check the engine instruments. Fuel flow: good. Oil pressure and temperature: in the green. Vacuum: ok. Battery Volts: 28. Perfect. Main bus charging: -1.0. Uh-oh. With 1800 RPMs, the engine is spinning fast enough that the alternator should be charging the battery - that -1.0 should be a positive number. I look over at Grant, he asks me what this meant. I said it meant we could have a bad alternator, that we’d be running on battery power, and that we could lose our glass cockpit. It could be 30 minutes or 3 hours, but we’d lose it. “What should we do then?” he asked me. “Check the POH?” Yep, we needed to check the pilot operating handbook to see if there was a procedure or advice if we saw a negative charge. We found and executed the relevant procedure, with a negative result.

In my last post, I posited that too many organizations choose to rewrite an application or component rather than invest in making it better. My belief is that this decision gets made because making the existing system “work” (whatever this means in context) is too hard. My concern is that the next time you write it, it’s also going to be hard. It might not be hard in the same way - you may have moved “the hard”. Regardless, you may not ever get to done.

The 80/20 rule is an oft-used metaphor in many contexts. I’m embarrassed to admit that I did not realize that there is a formal name for it, the “Pareto Principle”.

I’ve been wanting to play with Gradle for some time. I’m currently working on a fairly large Android project, deploying multiple applications, doing some advanced testing, and sharing a fair bit of code between applications.

Note: I wrote this back in 2007. I was working for SAP at the time. Our software (a Java-based Point-of-Sale system) needed an application server, and we had integrated it with IBM WebSphere, BEA WebLogic, and JBoss. SAP wanted us to integrate the product with their own application server, NetWeaver, which was predominately developed in Bulgaria. As we started the integration, we found that NetWeaver had several significant defects. In order to resolve them, and speed-up the integration, I was asked to spend two weeks in Bulgaria. I wrote this towards the end of the trip.