mike.mainguy

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