First, I am embarking on a new career, that of a software craftsman.  I have been a CFML developer for over a decade, and while it has earned me a nice income, it hasn't been terribly fulfilling.  CFML itself is part of the problem, but the places where CFML is widely accepted and adopted are a bigger portion.  I seem to be quite proficient at using CFML to build web applications  above spec and under budget, but I've come to realize over the years that my objectives are within the craft of software development, not in making piles of money.

Facilitating this shift of focus is a change of jobs.  I've worked at Mentor Graphics for just over five years and the team I have been a part of has grown in leaps and bounds.  We have morphed from a group of CommonSpot hackers to a team responsible for a pile of CFML, Python, and PHP applications, along with all the infrastructure to run it scalably and reliably.  It's worth mentioning that our team is a chunk of Mentor's corporate marketing department, and our IT department comes to us for expert opinions.   I have given my notice and my last day at Mentor will be January 6^th, 2012.

On the 9^th I will be starting a new job with a company providing healthcare information management and analytics software.  The company (ARMUS) recently was acquired by Burr Pilger Mayer (the largest accounting firm in California), though it still runs as a largely autonomous division within.  The team is small, the projects are fast, the impact is huge, and the business puts the focus is on internal quality not just external deliverables.  Plus it's centered around huge masses of data and the extraction of interesting information, which is something I'm quite fond of.  I don't think it's coincidence that Kim is an epidemiologist, doing the job ARMUS's software is intended to facilitate.

Finally, I'm moving my online home to programmerluddite.com instead of barneyb.com.  You can read more about the reasons over there.  I'll still be writing about software development and whatever else suits my fancy, but starting afresh.  This will be the final post I make on this blog, excepting a couple updates to a couple open source projects in the coming month.

This sort of "leave everything behind" transition is very uncharacteristic of my nature.  However, in this case I feel that a transition would be exactly the opposite of what is needed.  Yes, that means you'll need to update your feed readers, but no content is changing homes.  The downloads, post links, and comment subscriptions here on BarneyBlog will remain exactly as before, as will all the other bits and pieces on barneyb.com.

Hope to see you all over at my new home, though I will probably be rather quiet for a bit as the rest of this welling change stabilizes.

1. launch a virgin EC2 instance (I used the console and based it on ami-7f418316).
2. create a data volume and attach it to the instance.
3. allocate an Elastic IP and associate it with the instance.
4. set up an A record for the Elastic IP.
5. build a setup script which will configure the instance as needed.  I feel it's important to use a script for this so that if your instance dies for some reason you can create a new one without too much fuss.  It's not strictly necessary, but part of the cloud mantra is "don't repair, replace" because new resources are so inexpensive.  Don't forget to store it on your volume, not the root drive or an ephemeral store.  Here's one useful snippet for modifying /etc/sudoers that took me a little digging to figure out:

   bash -c "chmod 660 /etc/sudoers;sed -i -e 's/^\# \(%wheel.*NOPASSWD.*\)/\1/' /etc/sudoers;chmod 440 /etc/sudoers"

6. rsync all the various data files from the current server to the new one (everything goes on the volume; symlink – via your setup script – where necessary).  Again, use a script.
7. once you're happy that your scripts work, kill your instance,
8. launch a new virgin EC2 instance,
9. attach your data volume,
10. associate your Elastic IP,
11. run your setup script,
12. if anything didn't turn out the way you wanted, fix it, and go back to step 8.
13. shut down all the state-mutating daemons on the old box.
14. shut down all the daemons on the new instance.
15. set up a downtime message in Apache on the old box.  I used these directives:

    RewriteEngine  On
    RewriteRule    ^/.+/.*    /index.html    [R]
    DocumentRoot   /var/www/downtime

16. run the rsync script.
17. turn on all the daemons on your new instance.
18. add /etc/hosts records to the old box and update DNS with the Elastic IP.
19. change Apache on the old box to proxy to the new instance (so people will get the new site without having to wait for DNS to flush).

    ProxyPreserveHost   On
    ProxyPass           /   http://www.barneyb.com/
    ProxyPassReverse    /   http://www.barneyb.com/

    These directives are why you need the rules in /etc/hosts, otherwise you'll be in an endless proxy loop.  You'll need to tweak them slightly for your SSL vhost.  The ProxyPreserveHost directive is important so that the new instance still gets the original Host header, allowing it to serve from the proper virtual host.  This lets you proxy all your traffic with a single directive and still have it split by host on the new box.

The net result was a nearly painless transition.  There was a bit of downtime during the rsync copy (I had to sync about 4GB of data), but only a few minutes.  Once the new box was populated and ready to go, the proxy rules allowed everyone to keep using the sites, even before DNS was fully propagated.  Now, a few hours later, the only traffic still going to my old box is from Baiduspider/2.0; +http://www.baidu.com/search/spider.html, whatever that is.  Hopefully it'll update it's DNS cache like a well-behaved spider should, but not according to my TTLs.  Hmph.

Steps 1-12 (the setup) took me about 4 hours to do for my box.  Just for reference, I host a couple Magnolia-backed sites, about 10 WordPress sites (including this one), a WordPressMU site, and a whole pile of CFML apps (all running within a single Railo).  I also host MySQL on the same box which everything uses for storage.  Steps 13-19 took about an hour, most of that being waiting for the rsync and then running through all the DNS changes (about 20 domains with between 1 and 10 records each).

And now I have extra RAM.  Which is a good thing.  I'm sure a few little bits and pieces will turn up broken over the next few days, but I'm quite happy with both the process and the result.

Boring stuff first.  Mentor Graphics Corp is the EDA industry leader and makes all kinds of crazy design and simulation software for electrical engineers, and now embedded developers.  If you have a cell phone or a computer, it's almost guaranteed that you're using something which either embeds Mentor IP or was designed/tested/manufactured with the help of Mentor products.  The company is about a billion dollars in annual revenue and publicly traded.  Our team is currently seven application developers plus a designer, a front-end developer, a multimedia guy, a content editor, and a couple of operations people.  Plus Ron, our boss.  We're hiring three more application developers.  The positions are full-time, on-site, in Wilsonville OR.  Blah, blah, blah.

I work in the corporate marketing department (which is weird, but bear with me) on the web services team which is responsible for pretty much all the public-facing web infrastructure for the company.  www.mentor.com is the primary property, but we run the support portal, an internal business intelligence application, corporate blog hosting, and a couple industry journal sites.  We own everything that comes after the business requirements; divisions in the company come to us with business problems, and we spec, architect, implement, and host the solutions.  Despite the fact we're in the marketing department, IT comes to us for expertise.  Our primary platform is Adobe ColdFusion, but we support Groovy, Java, PHP, and Python for different applications where there was a compelling case to not choose a CFML-based solution.

Now the interesting stuff.

There is a formal job description somewhere, but I don't know where, and I wouldn't link to it even if I did.  If you want to work here, you need two things:

• technical competence
• a passion for development

We expect you to be able to not only implement a spec, but also design solutions.  You shouldn't have to be reminded that not everyone speaks English and that clocks around the world don't all say the same time.  You should know why pure functional languages don't have synchronized blocks.  You should have a preference between emacs and vi and be able to articulate in two sentences or less.  You should have commits to some public VCS repository somewhere.  You want to be part of a large non-hierarchical team working on a variety of projects.  You should know what MVCC stands for without looking it up.  You should want to help the six-months-from-now you have less pain, even if it takes a little more work today.  You shouldn't be proficient in all of Java, C#, JavaScript, Python, Ruby, and Lisp.  You should be proficient in at least one of them, and be competent in at least one more, and be able to compare and contrast the merits of the rest.

If that sounds like you, drop me an email at barney_boisvert@mentor.com or bboisvert@gmail.com.  Ron wants a resume, but I want two paragraphs and ~30 lines of interesting code.  Not 40, not 20.

Our hiring process is straightforward: get your info, quick mini-interview via phone, a simple code test, and an on-site interview to meet the team.  Mentor pays competitively, and has exceptional benefits beyond the salary.  Positions are full time, relocation assistance is likely available if you're not in the area – working remote is not an option.  Ron is very reasonable: if you're the right person, he'll go to bat for you/him/me to ensure things work.  Everyone here understands that spending a little cash to get the right people pays off every time.

Myth #2 – Introverts are shy.
Shyness has nothing to do with being an Introvert. Introverts are not necessarily afraid of people. What they need is a reason to interact. They don’t interact for the sake of interacting. If you want to talk to an Introvert, just start talking. Don’t worry about being polite.

Myth #3 – Introverts are rude.
Introverts often don’t see a reason for beating around the bush with social pleasantries. They want everyone to just be real and honest. Unfortunately, this is not acceptable in most settings, so Introverts can feel a lot of pressure to fit in, which they find exhausting.

Myth #4 – Introverts don’t like people.
On the contrary, Introverts intensely value the few friends they have. They can count their close friends on one hand. If you are lucky enough for an introvert to consider you a friend, you probably have a loyal ally for life. Once you have earned their respect as being a person of substance, you’re in.

Myth #5 – Introverts don’t like to go out in public.
Nonsense. Introverts just don’t like to go out in public FOR AS LONG. They also like to avoid the complications that are involved in public activities. They take in data and experiences very quickly, and as a result, don’t need to be there for long to “get it.” They’re ready to go home, recharge, and process it all. In fact, recharging is absolutely crucial for Introverts.

Myth #6 – Introverts always want to be alone.
Introverts are perfectly comfortable with their own thoughts. They think a lot. They daydream. They like to have problems to work on, puzzles to solve. But they can also get incredibly lonely if they don’t have anyone to share their discoveries with. They crave an authentic and sincere connection with ONE PERSON at a time.

Reading through these was quite remarkable.  Clear, concise, precise, and accurate.

From http://suzywire.tumblr.com/ (and deliberately truncated at six).

As is often the case with internet folks, I know a whole lot of people by name and/or handle, but far fewer in person.  So if you see me – I'm the tall, furry guy who isn't Andy Matthews – please say hello.  And as if you didn't need even more incentive, the company I work (Mentor Graphics Corp) for is currently looking to hire a couple more full-time developers out in beautiful Portland, OR.

After they were in bed, however, I thought I'd try my hand at building a totally custom model.  You remember when I said "simple" earlier?  I was totally lying.  The rules for construction are incredibly simple, but the complexity enforced by the modules themselves is rather high.  It seems like there is a lot of flexibility with the different blocks, but while that's not inaccurate, the flexibility is within a world of draconian constraints.

Anyway, after 83 test marbles over the course of about an hour and a half, I managed to assemble a model that I'm reasonably pleased with.  I had a few design goals  in mind from the get-go:

1. must have a single marble entry
2. must have a single marble exit
3. must use the 90° flip-flop (none of the instructions-provided models did)
4. must use a bunch of 180° flip-flops
5. every bit of raceway must be reachable (no dead or partially dead segments)
6. no bit of raceway may be reshared after splitting (all the instructions-provided models rejoined before resplitting)
7. minimize the number of test runs (both the kids and my parents was already asleep)

The 90° flip-flop was a pain in the butt to use, but that's mostly due to the fact that the set I was using was the Twist set, so the segments were all curves.  If the segments were linear (as in the Rail set), it probably would have been easier.  I only used two 180° flip-flops for their intended purposes (the rest served as "dumb" support blocks in the unused levels of the columns).  I'd hoped to use more, but goal #6 prevented it with the pieces I had available.

I won't know until morning if I succeeded at #7, but I think I did.  At the very least, I wasn't louder than the howling winds outside.

The trickiest part was managing vertical space while still meeting goal #6.  I managed to only have two columns with three layers of "dead" modules, and one of those was just so I could use the second helix (spiral, frying pan, whatever) as a launch point.  The module which would have made it far easier would have been a vertical 90° flip-flop, but there is no such thing.

Overall, however, I managed to build what I'd hoped to.  After the first fifteen or twenty minutes, I wasn't so sure I was going to be able to pull it off.  It seemed like everything I wanted to do wasn't allowed by the modules available.  But I managed to figure out how to solve the problems other ways, or at least reroute to avoid the problems, and got it done.

Here's a few pictures I took of the finished product:

This is the front of the model.  The marble exit is the green module at the center of the bottom curved section.  Since there are four paths, there are four ways to get to that block: from the left, from the right, from the helix, and from the raceway that ends under the helix.  The first natural module above the exit module is shared between routes three and four, but it's not raceway, so it doesn't violate goal #6.

The exist was the first bit I threw together.  I liked the concavity, so I kept it.  It was a pain to maintain that arrangement as I got further along, but I got it to work.  It also makes for a nice pile of marbles in that cavity after you run a bunch through.

You can see all three flip-flops here as well: the two 180° flip-flops are the red modules with the large grey dots (center-center and right-rear columns), and then 90° flip-flop is the red module spitting out onto the lower helix.

You'll also notice the purple spacers in the center-center and center-front columns – they could have been placed below the lower helix in both columns without interfering with any raceways and avoid the unnecessary two-plate drop out the front of the 90° flip-flop (there would still be a one-plate drop).  As you'll see in the left-side photo, it would also have allowed me to use a module in the center-center column instead of five spacer place.  But by the time I had it all working, I didn't really want to tear it apart enough to make that change.

The left side of model shows route four (the raceway under the lower helix) better.  It originates in the right-rear column, and passes through the center-center column.

Marbles are introduced in the uppermost module, and all go through the first helix.  Exiting the helix they hit the first 180° flip-flop and are either routed to the right side (more later), or sent through a short out-n-back to come to the 90° flip-flop and either be sent to the lower helix or out to the left side to run the serpentine race to the front and exit.

The right side has the second 180° flip-flop which either sends marbles along the right-side serpentine race to the front, or through another short out-n-back to the center-rear column before sending them through the central raceway to exit beneath the lower helix.

You can clearly see all three flip-flops from this view as well, though the 90° one just looks like a plain red module (other than the accelerator at it's front).

The final view of the back isn't terribly exciting aside from giving a better perspective on where exactly the right-rear, center-rear, and left-rear columns are in relation to one another.

Interestingly, the center-rear column (closest to the camera) is completely floating.  It has a single anchor point: the right-rear column.  However, it's geometry is rigidly enforced by the 180° flip-flop that feeds it.  So it has to be pretty much exactly where it is.  I'd originally hoped to have the short out-n-back that it provides go all the way over to the left-rear column (eliminating the need for a center-rear column at all), but I couldn't interleave the two out-n-backs without that aforementioned vertical 90° flip-flop.

The rest of the structure is locked in it's relative arrangement because of the incompatibility of the large curved segments and the serpentine segments to mutually realign their vertices.  If the lower exit raceway (right-rear to center-front) wasn't there, then the whole thing could pivot (as it'd be basically a parallelogram), but that raceway locks a triangle into one of the corners, thereby locking the whole structure.

Here's to spiked eggnog and an evening playing with toys!  Happy Christmas, or whatever you're celebrating as this year draws to a close.

After a couple weeks, I've actually adapted most of the common "scan-inverse pairs" and type them more slowly to avoid errors.  Unfortunately, there are a lot of such pairs, and some of them occur fairly infrequently (e.g., "oa").  So I still have a lot of screwups with the infrequent ones, but the common ones (e.g., "th") have been addressed with muscle memory.  Kind of pisses me off my "ultimate" keyboard has trained my muscles to type sssllllooooowwwwweeerrrr instead of faster.  But whatever.  Probably the most damning inversion, however, is due to BACKSPACE being late in the scan order.  So if you have a one-character typo and hit BACKSPACE followed by the correct character (especially a left hand character) in rapid succession, it almost invariably types the new character first and immediately deletes it, leaving the typo untouched.  Arrrgh.

I've also noticed a suprising amount of wear on the keys for a couple weeks usage.  The spacebar has already completely lost it's texture along the bottom edge and the letters (especially the home row) are noticeably polished.  Same for BACKSPACE (which I end up using a lot now), ENTER, and the left-side SHIFT, CTRL, and ALT keys.

On the positive, the action is really nice.  I'm a fan.  I think the weighting of the keys is a little light, but I type hard.  The keyboard as a whole is also really heavy so it doesn't slide around on my desk, particularly when my right hand is dancing around between letters, the numeric keypad, and the arrow keys.

Their site says that they've redone the electronics to not have such issues with concurrency, so hopefully that's true.  It looks like they may have also reved their switches, which probably will change the action to some degree, as well as making a less clicky version available.  I'm certainly not going to spend $130 for a next gen version without getting to test drive the new hardware first, but in the meantime I'll probably keep using this one.