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