If this is a major problem — then I must say, there are some providers on the vanguard of this here.

I just went in for my annual (where annual is defined as 12 +/- 6 months) physical, and my doctor wanted to see a lipid panel (cholesterol screen). I see a doctor at Associates of Family Medicine here in Fort Collins. I casually mentioned that I had a blood draw for just that purpose last week over at Poudre Valley Health System’s Harmony Lab for my cardiologist over at Heart Center of the Rockies. So, my doctor on her laptop, logged into their system and pulled the results — just like that. No sweat at all.

I have to say, that’s not bad for coordinating 2 providers (and accessorily the third provider, my cardiologist).

Still some work to go — a unified patient record would be nice, so I don’t have to mention that I had the test done. But, I have to say, Associates in Family Medicine and the Poudre Valley Health System, at least, are very solidly on the right track.

By the way, my health is good.

You see it all over the place. We choose larger homes, just in case we have kids or get a bigger TV. We buy large cars to cart the kids around or to ensure against the grisly in case of a catastrophic accident. We opt for trucks instead of cars in case we we need to haul a load from Home Depot, or purchase the tow package in case a boat should happen to come into our possession.

We regularly trade cost for the convenience of something we don’t regularly or often have a need for. This is all well and good — we like things bigger, better, and more featureful to make our lives easier.

The thing is, this isn’t true in software development. We regularly plan and develop for the average case — the typical use case — and eschew the exceptional. And I think this is a shame.

Not all organizations do this to the same extreme. However, the desire to get something out to market and the 80/20 rule (or whatever variation you use) often trumps the one feature or slight tweak that could make someone’s day. In software development (and this is probably true of product development in general), we trade box specs for time. We get as much done of a feature as we need to say that we have “it,” then we call “it” done.

This is discouraging.

I think some of this mentality is related to agile development practices. Agile teams, combined with aggressive product owners, move the development team from feature to feature with an ever-increasing myopia towards the requirements of the person yelling the loudest. They’ll tell you that they give as much as the market demands, but in the software world, it’s often (the so-called) business leaders dictating the the “requirements.” I’ve noticed this forgets the people charged with actually using the software, whose own ideas for improvement get drowned out in the “process.”

The end result is a product that can do the typical, a product that can do the average. Certainly not a product that expects the exceptional.

Is this a problem? No, not necessarily.

An average product serves the need of 80% (or more) of the people who use it. That’s a pretty good watermark. What troubles me is how we often overlook the one or two things we could do to make it more like 90 or 95% of the cases.

We don’t plan for the exceptional in software; and I think this manifests itself in a product that doesn’t feel “fully baked” when you use it.

In my rack room, I have a HP ProCurve Gigabit switch powering my network. I love this switch; it’s fast, it has an easy-to-use interface, it has enough ports for all the jacks throughout my house, and most of all: it rarely requires any management time from me. There’s one thing though that irritates me to no end about this switch: you can’t name the ports! This thing has 24 ports on it, but I’m expected to remember that port 13 is my cable modem and port 21 is the file server. To me, adding the ability to name the ports, is low-hanging fruit that would make my life substantially easier. This is the exceptional case; I’m using this switch as the core of my small network, rather than at the edge like HP intended.

Serving an exceptional case doesn’t always have to add a lot of work. In the case of my switch (and I’m going out on a limb here), I can’t imagine adding port naming would’ve been a schedule-blowing feature but it would have made life a lot easier for my case.

I think one of the nice features of Waterfall as a development methodology is that it specifies the whole solution. Agile development is the current industry best practice (for good reason), but it would be nice if we could bring some of the “whole solution” mentality to the process.

I used the ZFS Quick Start Guide to get started. I also cuddled up with “man zpool” and “man zfs” in order to tailor my own solution. In the end, I came up with a relatively simple:

[root@protego]-~# zpool list

NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT

tank   928G   312G   616G    33%  ONLINE  -

[root@protego]-~# zfs list

NAME              USED  AVAIL  REFER  MOUNTPOINT

tank              312G   601G    19K  /tank

tank/fbsd         497M   601G    18K  /tank/fbsd

tank/fbsd/ports   193M   601G   193M  /usr/ports

tank/fbsd/src     304M   601G   304M  /usr/src

tank/media        203G   601G   203G  /data/media

tank/tm           109G   291G   109G  /data/tm

I did notice that FreeBSD’s default configuration caused kernel panics, because the kernel tries to use more physical memory than exist to store ZFS internals (on a machine with 2GB of RAM anyway). Luckily, you can tune these; I added the following to /boot/loader.conf on the advice of the starter guide to alleviate the problem:

vm.kmem_size_max="1024M"

vm.kmem_size="1024M"

vfs.zfs.arc_max="100M"

So far so good. I’m going to let this run for a while and spend time learning about ZFS snapshots and rollbacks. I’m also going to look into ZFS diagnostics and maintenance; I’m a little concerned about copy-on-write and fragmentation (not such a big deal with the largely write-it-and-forget-it data I have on it now, but something to think about if I say, move /home onto ZFS).

That means it’s time to play around in the technology playground and maybe learn a thing or two in the process. Today’s project: ZFS.

I usually like to pick projects that solve a problem I’m having (even if that problem isn’t particularly grave). In this case, I have about 4TB of storage split across 7 drives of various sizes (and for the moment, split between 2 machines). I’ve arranged the partitions in a way that meets my current needs, but it’s hardly flexible. If I need to reallocate storage, I have to do play musical chairs with my data in order to refactor the layout.

Ideally, I could map all the storage into a large pool and allocate shares dynamically among my various needs: media store, backups, Time Machine, and regular data. I’d like the shares to have different properties, e.g; I don’t care about access times on my media store (noatime). If one share needs more, I’d like to be able to allocate it extra storage from offsets elsewhere. I’m hoping ZFS gets me at least part of the way there.

To start with, I’m playing musical chairs with about 200GB of data. I’m copying 200GB off two 500GB drives (arranged in a mirror) over the wire to my file server (boy, am I glad NFS is easy to setup). Once I’m done, I’ll have 1 TB of free storage (2×500GB) to setup in a testbed ZFS pool (just as soon as I extract the drives from avifors and re-mount them in protego!)

I love geek days.

1 – except my run, of course…

It all started with episkey, my main hosting server. For about 2 years, it had been colocated at Red Rocks Data Center (these guys are great, I totally recommend ‘em), just outside of Denver. After my largest tenant (an IRC server and most of the accessory services for the network) departed, I felt that the cost of the colocation far outweighed the tangible benefit to me; so, I pulled the server back home to live on my network and on my /29 from Comcast.

At the data center, episkey spent its computing hours cooped up inside half-depth 1U case; a case that would have been an ideal fit in my rack at home… if it weren’t for the 10,000 decibels of industrial-grade cooling system blowing out the back. Honestly, if the case had an airfoil and a runway, it’d probably beat “my” 172 to pattern altitude.

So, I ordered a new case (an Antec Sonata III), new quiet heat sink and fan, and a new heat sink mounting bracket (for former enclosure necessitated custom set). I built that all up in the new case and all was well, until: POP (and quite possibly, a few snaps). The power supply emitted (emut? new word, perhaps?) its secret smoke and that, my friends, was all she wrote.

The 500W power supply in the Sonata III was done; totally cooked. Oh, and it took the motherboard with it. episkey, if it were constituted solely by its motherboard, processor, and memory, was now dead. A faint miasma of death (which is astonishingly similar to capacitor smoke) still lingers to this day.

Thus, began the replacement process.

I decided to go “newish” and “low cost” — one thing I’ve realized is that for my needs, I don’t need the fastest out there. This “new” box is going to run FreeBSD.  It’s going to have a steady and predictable workload very similar to what the former Pentium 4 3.0GHz incarnation was able to do without so much as breaking an electronic sweat. So, in a nutshell, I didn’t need the latest nor the greatest. High quality but middle of the road (perhaps a little older, then), would do.

But first, a new case. If you weren’t already aware, Amazon has fantastic customer service. I explained what happened to them and they gladly sent me out a replacement case and power supply. It’s really nice to not have to worry about fighting a retailer for things like this, so kudos to you Amazon. I figured I was on my own for the board, so I started shopping around.

Ultimately, I opted for a used Supermicro board (a C2SBA+II) from eBay — it’s a LGA 775 board, has 6 SATA 3Gb/s ports, and can carry 8GB of RAM. I picked up this “baby” for a song (and $45) on eBay, then added on a 2.6GHz Pentium Dual Core and 2GB of RAM. I also added on a PCI 10base T (yes kids, that’s a whole 10 megabits per second!) card that I borrowed from Myles, as I discovered that my awesome eBay find has a bad Gigabit NIC onboard (PCIe replacement already enroute). All built out, I christened it “protego” (in keeping with my Harry Potter naming scheme) and installed (then -STABLE’ized) FreeBSD:

FreeBSD protego.dreamfire.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Sun May  2 19:06:48 MDT 2010

root@protego.dreamfire.net:/usr/obj/usr/src/sys/PROTEGO  amd64

I like to beat up on machines a bit; and I like FreeBSD’s make buildworld for just that. So, for this evening, protego will be “building the world” in a continuous loop. As a bit of a benchmark, its first world took just a bit over 38 minutes (I believe episkey was in the few hour mark, avifors — my backup server — takes many many hours).

Because I’m ever the tinkerer, I spent a little time looking at the stenciling on the board itself for interesting clues and for things to turn on and off. I discovered the FSB frequency jumpers and a handy table with the settings to force it to 133MHz (533MHz FSB), 200MHz (800MHz FSB), 266MHz (1066MHz FSB),  333MHz (1333MHz FSB), and the ever interesting default setting of “Auto.” It had been set to the default — Auto — which for this processor was 800MHz.

I decided to bump and lock the FSB at 1066MHz. That jump kicked the CPU from 2.60GHz to 3.5GHz. Unfortunately, a make buildworld immediately caused a kernel panic. I went into the BIOS and tinkered with some of the settings; a little extra voltage here, a mysterious 15% addition (seriously, you can overclock it in 5% increments from 0 to 15%; I have no idea what that means either!) there, and presto: a make buildworld carried on… for a few extra minutes, until it panicked yet again.

Oh well. Can’t have it all. At least, it’s working (back in “Auto” mode).

Take this quote (of a quote) for example:

According to several people present, Andy Lees, a Microsoft senior vice president who oversees development of the mobile-phone software business, and his boss, Robbie Bach, explained that Microsoft workers often use rival products to better understand the competition.

I nearly choked on a carrot reading that one. I mean, come on, “to better understand the competition”? I guess it never occurred to them that the iPhone, despite its many flaws, is just a better device?

One of the things I think Apple does very well is to understand its customer, and produce a device to meet most of the desire and do so in a stunning package. Take the original iPhone for example: it only supported EDGE, didn’t have multi-tasking, and if you wanted to copy-and-paste you were out of luck. On the other hand, it had a real browser and a stunning user experience. The iPhone put a computer (or something close enough) into the hands of its customers, and they were willing to overlook the shortcomings. Even today, the latest iPhone 3GS still doesn’t have multi-tasking, an open-market for applications, or tethering (if you’re in the United States) — but people are still buying them like crazy. Even Microsoft employees.

Microsoft has the luxury, because of its position, to be a follower instead of a leader. It’s always worked for them. I think, though, if they’re wondering why iPhones are popular among their employees, they should look in the mirror and realize that the iPhone is just a better device. It’s not about what people say they want, it’s about what people don’t know they want.

One of the major challenges I have is what to do with the mac mini and MacBook Pro. I do a terrible job synchronizing the documents and work-in-process across machines despite trying a few different automated solutions. Almost invariably, the things I work on (read: code) are stored on a machine that I ssh into.

So, I’m trying out something new: I’m going to stop using the mac mini for anything workstation-related. I have an ongoing need for Windows and for a development FreeBSD server (one that I can experiment with and break a lot, not something I’d like to do with my regular FreeBSD server at home). So, the mini now runs headless with a few virtual machines on it and all my work is conveniently centralized on my laptop.

I’m curious to see how this will work out. Hopefully well. This post (besides being, I hope, at least marginally interesting) serves as sort of a mile-marker for this trial.

It’s been some time since I’ve written about flying. The lack of writing is not due to a lack of flying time, but rather to a lack of the fortitude to keep journaling my progress!

I have made my first solo flight!

The first solo is the first major milestone and the first real test of an aspiring aviator. It represents an accomplishment in ground study, in flight study and practice, and a demonstrated proficiency at the basics of flight. It’s not an endorsement that means I’m a qualified pilot, but it does mean that my instructor Craig has faith that within the scope of limited maneuvers, both I and the airplane will come back in one piece.

As I’m back on solid ground writing this, I can rightly certify that I’m still here!

Since the last post, Craig and I’ve practiced a ton of landings, ground reference maneuvers, stalls, steep turns (40 degrees of bank), slips, and the beginnings of crosswind takeoffs and landings. I’ve also beaten (or at least beaten back) my natural predisposition for motion sickness. One of the reasons I’ve struggled with (soft) landings is that I didn’t get to practice them during the early hours of my training. My stomach simply wouldn’t make it through the lesson. I’m happy to say that I’ve more or less overcome that challenge.

Now, we’re back to my first solo.

So, Craig and I were doing touch-and-go’s in N1720Z around runway 34 at GXY. After a few laps around the pattern, Craig let me know (pretty much on the ground, actually) that I should exit on C2 and head back to the FBO. He then said “then you can go shoot the pattern a few times on your own.”

“Say again?” say I.

We exited on C2, and taxied back to Poudre Aviation. I dropped Craig off, ran to the restroom real quick, then anxiously hopped back into N1720Z. Craig said that if I felt at all uncomfortable, I could just taxi on back and we could do the solo later.

My anxiety remained, but I decided that I’d make the final call after the run-up. I taxied out towards runway 34’s runup area, crossed runways 9 and 27, and turned the airplane facing slightly south so I could look for traffic on final approach (I also listened to the radio, but it’s always good to keep your eyes open!)

I worked through the checklist, and as I worked through each item, my own personal level of confidence grew. I started feeling the anxiety being quieted by the confidence of 20 hours or so of training; it wasn’t all the way gone, but by the time I was ready to call for departure, I was in a mental state where I was ready to fly. It’s tough to describe the feeling, but it was something like “cautious optimism.”

Remembering Craig’s axiom: “Take-offs are optional but landings aren’t” I looked deep inside and decided I was ready to do this. I called for departure:

Greeley Traffic, Skyhawk One Seven Two Zero Zulu, departing runway 34, will make left closed traffic, Greeley.

I took one last look up at the final approach leg for the runway, and rolled on out onto 34. I lined up with the center line and took a look at my panel. “Oil pressure: check. Runway alignment: good. Full throttle. Power and pressure: check. Airspeed indicator: alive.” went through my head in that order. I rotated at about 60 knots and was up in the air in no time.

At about 5200 feet ascending (about 500 feet above ground-level), I took a look left and started my crosswind turn. I raised the left wing to take a look down the downwind leg, then shortly made my downwind turn. I like to call my traffic legs during the turn, but in this case, I called my downwind when I reached pattern altitude (5700 feet, about 1000 feet AGL).

One of my tendencies is to want to keep going up, but I kept it fairly true to pattern altitude for these laps. I’m pretty proud of myself for that!

I reduced power and trimmed for the short downwind cruise. At about the 1000 foot marker (which is 1000 feet beyond the start of the runway; if you’re unfamiliar with aviation, a downwind leg means I’m flying parallel but in the opposite direction of the runway), I powered down, applied carburator heat, trimmed for landing, and applied 10 degrees of flaps. This is the descent procedure.

I started descending, and at 5500 feet and maybe a mile or so beyond the runway (I’m not really good with distances over ground, but I was far enough away!), I turned and called my base leg. I applied 20 degrees of flaps and maintained a careful eye on the airspeed indicator. 65 knots is what I want. I flew the base leg with an eye out on the final approach leg looking for traffic, and seeing none, called and turned my final.

I overshot the final a little bit, but nothing that couldn’t be corrected on the descent. I flared the airplane on the runway, but made a bit of a bounce on touchdown. That’s alright, though. I’m a pilot-in-training and there are definitely some areas to work on! I pulled the flaps out, pushed in the carburator heat, checked alignment and the engine instruments, then pushed the throttle in for another go. I was up and down again in a few minutes, then did another pass. I did 3 solo touch-and-go’s that day, and came back in one piece!

I also lucked out to not have a whole lot of traffic in the area to complicate things. There was a blue-and-white tail-dragger doing touch-and-go’s at the same time on runway 9. Luckily, we stayed almost perfectly interleaved. He was nothing more than a nice voice in the radio and visual scan practice. Nothing too stressful.

I think they’ll make a pilot out of me yet.

Clocked in another 1.4 hours of time in the log book with Craig. We had a bit of wind aloft (and almost nothing on the ground when we took off), so we used the opportunity to do some turns about a point and S-turns. These are exactly as they sound, you pick a point (e.g; an intersection of two roads) and fly in a circle around it. The same is true for S-turns, you pick a road and then fly hemi-circles on each side.

It sounds easy, and yes, it actually isn’t all that bad if you don’t have to deal with wind! (not saying it’s easy even in that scenario either, but it’s easier). With wind, you have to really feel how the wind is affecting you and bank appropriately. However, that’s not the only challenge: you have to do so smoothly. The challenge is to compensate for the effect of wind by gradually rolling in and out your bank angle in order to stay on your desired flight path. It should be fairly imperceptible (at least in the case of turns about a point, not as much with S-turns). I could definitely use more practice with both of these.

We used the light winds (I think it was up to a whopping 4 knots when we came back to the airport) to practice a few crosswind takeoffs and landings. That’s just, well, weird. Going into a slip to bleed off airspeed and and crabbing into the crosswind on the way down is a strange feeling. I’m honestly not sure what the heck I’m doing with these… oh well!

And to finish off this heavily fragmented post, it occurred to me that I didn’t mention my new LightSPEED 15XLc headset that Santa (thanks Mom and Dad!) brought me for Christmas. I took it up on its inaugural flight this week and used it for every flight thereafter — it’s awesome! The ANR (automatic noise reduction) feature is really amazing; it mellows, but does not eliminate entirely (which is what I wanted), the sound of the engine. The fit and comfort level of it are also deserving of high marks. All in all, it’s made for much more pleasant flight lessons.

With that, it’s bed time for this aspiring aviator. Good night!

I’ve been up twice this week – on Monday and on Wednesday with Craig for 2.7 and 2.2 hours respectively. The main focus: landings.

But first, let’s talk about some scary moments. On Monday, Craig and I did some stall practice. I had zero problems correcting out of power-on stalls. Power-off stalls however… well, that was scary. The first and second time (of the exactly two times I tried it on Monday), I vastly over-corrected and nearly turned the airplane into a full nose-down dive. For some reason, I couldn’t wrap my mind around the right action — and after a day or so of analysis — I realized that I was flying with 2 hands on the yoke, and when it came time to correct, I had effectively blocked myself from responding.

Today though, we practiced power-off stalls, and they were flawless. I went back to one-handed yoke-action and all was fine. Craig even said that one of my stall corrections was even smoother than his demonstration. Whew!

Like I said, though, the work over the last 2 days has been pretty much focused around landing. I’m getting very familiar with the pattern around runway 34 and the right pattern around runway 27 at GXY. Landing has always been a scary thing for me; I feared hitting the ground even at 500 feet up in the pattern! After 23 landings over the last few days, I’m much more comfortable. If I were to wake up suddenly flying a Cessna 172 in calm winds, I’m fairly confident I could put the aircraft on the ground (perhaps not smoothly — yet!) in one piece.

So far, I’m up to 13.7 hours. I go up again on Saturday and here’s hoping we have some afternoon winds for some cross-wind training.

Also: no motion sickness over the last few days!