mike.mainguy

Having used virtualization in a variety of scenarios over the last 10-15 years, I still find some misconceptions about the value proposition and how to use it. At best these are just marketing misconceptions, but at worst they can lead to counterproductive activities that HURT your solution. So, not in any order, here three things I hear people say that are just normally not true. Yes I understand that there are some scenarios where they are, but for the most part in my experience these ideas have been taken too far and now create problems. Virtualization helps me scale my solution I hear this so much I really just get tired of reexplaining how this isn't true. While based on a grain of truth, in the general sense at the datacenter level, it's completely false. For a single application it is easier to add cores to a virtual machine than it is to buy new hardware...but...people forget that the hypervisor is running on real honest to goodness hardware and adding a new Vir...

After reviewing my credit card statement, I realized I was paying every month for efax (a service I used twice in 2006, one more time in 2013, and subsequently just missed on my billing statements every month for the last...yes...9 years...). The following is the somewhat surreal interaction I had when I cancelled... Greg Curtis: Thank you for providing the information. Please allow me a moment while I pull up your account. In the meantime, please type the number corresponding to your reason for cancellation: 1) Moving to another provider 2) Bought a fax machine 3) Business or role changed 4) Short term project completed 5) Financial reasons 6) Problems with faxing or billing 7) Dissatisfied with quality of service 8) Too costly me adding my own answer Michael Mainguy: 9) only needed it once 2 years ago and forgot to cancel :) Greg Curtis: As we'd like to keep your business, I can offer you a discount and also waive your subscription fee for 1 month. The discounted m...

As a former DBA, I find a disturbing trend toward a value proposition that is almost nonexistent among a recent crop of database administrators. Maybe having some background and/or working with other stellar DBAs in the past has spoiled me, but here's the workflow I've find more and more common. scenario - production application has slowed down for a few transaction types, dynatrace shows a critical sql statement has slowed down. None of the development team has access to run explains, we can't "afford" hardware to load the production dataset into another environment (because we're using a DBMS that costs 13.6 bajillion dollars per CPU nanosecond with an additional upcharge of 1 million pounds sterling every time we execute a query that uses DML... Explains indicate everything is optimal in the lower environments. The decision to use this particular platform after the salesman for the product took the DBA team to Vegas for a "conference" and ...

Based on my highly scientific analysis, there are currently 13.98 javascript frameworks per javascript developer. I've personally been on two projects where a framework was built, completely scrapped, and rewritten BEFORE THE PROJECT WAS DELIVERED! Based on this observation and the literal wasteland of half baked frameworks available, I'm sharing some insight on how to design a useful framework. Follow these rules and you'll have a higher probability of having something useful, ignore them, and well...I guess that's your choice, I won't hate you for it (OK, maybe I will a little). Step One: Pick an existing framework No, this is not a tongue-in-cheek joke, this is reality. Unless you initially demonstrated your framework at Bar Camp back in 2006 , you should start with something that already exists and first deliver your project with that. Step Two: Find things that the chosen framework doesn't do well Now look at your product that is "code com...

Interesting Story (to me) I found myself in another interesting "ex post facto" software design review session and both sides of the table were getting increasingly frustrated. My frustration centered around my engineer's inability to explain "why" he did it that way or "how" it worked, and his frustration was a mystery to me. I suspect this has to do with the perception that perhaps I was telling him his baby was ugly. I think what leads to this situation is the realization that I'm an almost negligent delegator. Yes, most who interact with me or know me professionally might not think it's true (as I DO like to get my hands dirty). I tend to give my tech leads and developers lots of rope which unfortunately means it will fit quite easily around all of our necks. This is, however, deliberate because I feel this historically has yielded the most innovative results and "generally" produces really good or really bad software. ...

Having spent some times working with devices connected via GSM, I'd like to share some observations that seem to be obvious to cellular network engineers but get lost in the breathlessly overhyped echo chamber of marketing. The short assessment is that depending on the mobile nature of your connected device, the allowable delays, and the amount of data your intend to transmit and receive, you will need to very carefully choose your protocol and state management. To begin, there are two major types of connected "things": #1 Mobile "things", such as trains, planes, and automobiles. and #2 Immobile "things" such as thermostats, refrigerators, and buildings. Mobile Things Mobile things have two unique problems you'll need to be concerned with, they are: #1 Speed, #2 Network availability Speed (and/or velocity) impacts network connectivity because it introduces signaling problems for the radio network. Rapid movement or changes in direction...

Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...

There are two widely known laws in parallel computing that are counterpoints to each other, but with thought they can be applied together to achieve dramatic improvements in parallel computing. They two laws are Amdahl's Law and Gustafson's Law . Roughly speaking, Amdahl's says you cannot speed a system up by parallelization to be faster than the the slowest portion. Using a simple metaphor, if you have a car, a bicycle, and a turtle, when traveling in a pack, you can only move as fast as the turtle. The counterpoint to this is Gustafson's law, which roughly states that for parallel problems, adding more resources can increase the net work completed. Using are above metaphor, if we add more turtles (or cars or bicyclists) we are still increase the amount distance travelled per unit time. I do apologize to Computer Scientists as this is a very rough approximation, but this way of thinking about the situation can help us understand how to use some trickery and sl...

P rior to writing code, I will search the internet, I will ask intelligent questions, and I will realize that many of the answers I get may not be correct. I will test the answers and validate them before repeating it to someone else. I will not reinvent prior art without adding value R evision control tools are my staple, I will live and die by version control tools. Distributed, Centralized, Lock and Release, or Update and Commit...they all work and they are the foundation upon which I build everything. I will strive to learn how to use these tools to manage branches, tags, and how to properly share my code with my fellow programmers which whichever tool my team happens to use O n all fronts I will respect the code that already exists and seek to understand why it is the way it is G iving credit when due, I will respect my peers, those who are less skilled, and those who are more skilled. I will not assume I'm smarter than everyone else, nor will I assume that esoteric a...

Often we are hampered because we think of a "simple solution" and it ends up being "simple to think about" but very complicated in practice. Something as simple as "Dig up the rock poking out of the front yard" seems really simple. All you need is a shovel and some ambition right? ...until you realize the rock is a 5 ton monster that, in fact, the utility company drilled a hole through to route your gas line. Sometimes, as in this case, it might be better to do the more "complicated solution" i.e. go to the store, get some dirt, and cover the rock up, and plant new grass... because the "first/simplest" thing you thought about has some unknown complexities. Put another way..."simple to think about" doesn't equate to "simple to execute".

I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...

I recently had a need to install varnish on Centos. While it's very simple, a key step missing from the official instructions is to install the epel-release . Not sure why yum can resolve the dependency on Centos, but the following steps worked for me: sudo yum install epel-release sudo rpm --nosignature -i https://repo.varnish-cache.org/redhat/varnish-4.0.el6.rpm sudo yum install varnish

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...