mike.mainguy

Working in the field for a while, I find that new folks in the field have a problem with refactoring. I think the primary problems are: Code without tests is dangerous and frankly scary to refactor It's really easy to copy/paste code, and if you don't have to support and bug fix things, the merits of clean and concise code are lost While I don't claim to fix anything, here's a quick guide on how/why to refactor (for complete newbies):

Don't take it personally is an oft repeated platitude I hear repeated in the work environment. While I think it's unhealthy to take problems at work and things out of your control as personal affronts, I think a healthy dose of taking personal ownership of your work is "a good thing" (tm). I say this because the counterpoint to not taking things personally is not giving a damn and I think this is a far worse situation than folks who are personally invested and passionate about their work. In my experience, the most successful folks I've interacted with take a very deep personal interest in their life's work. They are passionate, appropriately loyal, and care a great deal about the quality of the product or service they provide. Folks that punch the clock, point fingers, and skip home after their "8 (or so) hours of physical presence" are huge problem and all too often a key source of low quality work and cumbersome process. More dangerously...

I've just spent some time setting up a bare Centos 7 image to support development stripping out as much as possible. While CoreOS is probably a better choice, we run redhat in production at this point and centos is a better fit for the time being. The problem I've found is that many of the instructions available via google were written against prerelease versions or espouse manually installing random rpms instead of just using yum. While I get this "works", I'm not a huge fan of this approach and would rather do everything with the package manager. After a LOT of scouring and trial and error, I finally found the "magic" combination. The winner is courtesy of http://www.pc-freak.net/ . I've taken these instructions and tweaked them slightly for my purposes. The original poster did this on a more "full fledged" version of centos with a windows host and my instructions are for a minimal install using and OSX host (though I'm certa...

Parents of the world, I have one piece of advice that will give you a tool to help your child become happy, healthy, and productive. Give them a shovel and tell them they can do anything they want with it. Note, if you are in an urban area, this might be BAD advice, so suburban and rural people listen on, urban folks find a friend in the burbs with a yard and then follow along. A kid with a shovel is an amazing thing to watch. Kids who are impossible to pry from the WII/PS3.. who don't like soccer/football/whateever, who might otherwise be surly or withdrawn... will become captivated by the idea that they can can explore and possibly find buried treasure, fossils, rocks, and dig/play for hours. Add water to the mix and the possibilities are endless: sand castles, mud castles, mud pies, mud pits, waterfalls, ponds, you name it! Too often in our modern world, we think of parenting as an activity that requires structure, supervision, and direction. I think excessive amoun...

In a recent elevator conversation with the team, we stumbled on a side conversation about the difference between accuracy and precision. I've always used them defined this way: Accuracy - The nearness of a value to the "real" value Precision - The resolution of a measurement It turns out this is not entirely correct and these definitions, while technically accurate in certain fields, are not universally held to be true. In fact, the above definition of precision is almost completely wrong for most other engineering and scientific disciplines. A more accurate (see what I did there?) set of definitions would be something like: Accuracy - The nearness of a value to the "real" value Precision - The probability of repeated measurement yielding the same result Measurement Resolution - The resolution of a measurement Source: Wikipedia

I'm currently struggling with another project suffering from what I dub the "Trail of Tears" architecture pattern. This is a situation where the architecture is littered with the remains of legacy code that never seems to get removed. This leads to mounting maintenance costs, and a fragile architecture that becomes increasingly difficult to manage. It also has the side effect of creating a "broken window" problem where there is no clear "correct" way to do things and the necessary rigor around adhering to standards and best practices (I HATE that term...but oh well) rapidly falls apart. Historically, the only way I've seen to combat this is to rigorously support opportunistic refactoring other wise known as following the " Boy Scout Rule ". While this has it's own problems (folks breaking seemingly unrelated things trying to clean things up and inflated scope for features being two key ones) it has proven to be the only way to...

I just read Coelacanth: Lessons from Doom and I just realized that Minecraft is the new Doom . If you don't believe me, find a teenager that has a computer (or smartphone, or tablet) that hasn't played Minecraft. Doom revolutionized gaming, not by making the FPS technologically possible (thought this is a big deal), but because it spawned a multitude of user generated mods and made it relatively easy and open to do this. This, in turn, incited myriads of hacker youth to build their own mods, edit levels, even (in my case) buy books on graphics programming and learn about BSPs, GPUs, ASM coding, optimizing C code, and other esoteria that I would have ignored. Frankly, the almost the entire gaming industry owes a debt of gratitude for inspiring the current flock (actually, we're probably on the second or third generation now) of hackers who saw success building their own games with toolkits provided by the makers of Doom. This seems to have been largely ignored up...