And you are here why?

You think I'd have learned by now, but the following rules are ones that always hit me upside the head, even though I know better! I'm not saying that these rules are inviolable (this is software after all!). It's just that if you violate the rule, be sure to have an excellent reason involved, and even then, check again, and then document it. The documentation, in particular, will help you remind yourself what a butthead you are… 1. Make Scaling intrinsic to the design . It doesn't matter whether this means autoscale groups, k8s, or auto-instantiation of domain objects, the point here is that scale - at all levels - can not, and should not, be something that you bolt on afterwards. 2. Make Deployment a first class citizen . Ideally, a merge into master should trigger a production deployment. And yes, this implies code coverage, comprehensive testing, toolchains, and everything else you've (hopefully!) read about. Maybe you're not there yet, but you rea

Continuous Development (and Continuous Testing ) is increasingly common out there. The process of pushing a commit, and having it kick off a run on Travis / CircleCI / Jenkins is so frightfully mundane that one does it without actually thinking about it much these days. That said, here is (highly unscientific!) study of errors that I've found in CD environments 1. Compilation Errors . Yes. Seriously. And the ridiculous thing is that pretty much every damn IDE these days supports some form of "compile on save" option, no?  2. Missing Code . There's literally a gaping hole where an entire module should be. This could be because the developer forgot to implement it, or that the developer pushed the wrong branch, but still, come on… 3. Wrong Tests. The developer cut/paste tests from a different module as a starting point, and then happily forgot to actually implement them correctly. 4. Missing Data . The test harness depends on data that isn't checked

" We've automated our tests " - The first thing that pops in my head when I hear this is " I wonder what the tests actually cover ".  At heart, testing is all about coverage - code coverage, requirements coverage, business case coverage, etc. Automating these tests sets things up so that when you kick off your tests, they will go through all of these for you, so that you don't have to remember to do everything . Automation doesn't actually tell you anything about the quality of the tests . Yes, I know, that is me belaboring the obvious, but I do so for a reason -  most tests have precious little to do with business risks . And that matters because, in the end, everything you are working on is aimed at driving business value . (•) Hold this thought, we'll get back to it in a moment  -  let's continue with testing.  The thing to remember here is that you are never done testing . There is always some set of tests that you could be doing. S

Ever wonder what the difference between rate-limiting and load-shedding is?  Rate Limiting is all about controlling the rate of traffic sent or received by the network. In it's simplest form, it consists of rejecting any request that exceeds a specified count per time unit - think "If we get more than 10 customers per hour, we tell them we're busy". A slight variant of this would be concurrent rate limiting, which defines the maximum number of simultaneous requests that can be handled in a time unit - think "We can only handle 3 customers at a time".  Load Shedding is all about preventing the system from getting overloaded in the first place. The idea here is that it is better to ignore some requests, rather than having the system crater and not be able to serve any requests - think "Let 911 calls through, and ignore the rest". This, of course, implies that decisions around load shedding - i.e., which requests to drop - are made based on

I'm not quite sure what's more frightening - that I just do it without thinking, or that doing it actually makes sense. /via http://www.commitstrip.com/en/2016/05/10/a-moment-of-nostalgia/

/via http://geek-and-poke.com/?offset=1478426450265 Still get a chuckle out of this 😀

There are quite a few dashboards out there -  from roll your own, through pretty ones like Dashbling, to big/fancy ones like Tableau . And then, there are ones like this - designed for people who spend most of their time on the command line and don't have the luxury of multiple monitors (yes. It's possible. And not just a money thing - ever worked from your laptop? On the road?). Meet WTF from Chris Cummer , which is - as you can imagine - a fully ASCII based dashboard. It's got modules for the stuff you'd probably use, like  GitHub JIRA and more, including New Relic, OpsGenie, and more. There is also support for CmdRunner, text files, and such with, of course, the option to add in your own if you need something specific. Configuration is YAML based in the ~/.wtf/config.yml but you can override that if you so desire. And yes, if a module needs environment variables, it gets it out of your environment (so, so, simple) It’s still in early stages , bu

“ Do it my way — I have 24 years of experience in this field, so I don’t care whether you have any customer feedback or not ”  — # CowboyManager We’ve all probably had a variation of the above invoked on us at some point in our career. It’s a classic example of an   egocentric fallacy   (•), where your manager believes that they know what the customer wants based on   their belief that their preferences and insights are typical of the market . It also succinctly explains why so many products and services fail! The thing is, there is nothing wrong with insights and preferences — they are actually quite valuable, and serve as an excellent short-hand for identifying actions, patterns, opportunities, and so forth. That said, these   beliefs should serve as a starting point, and not as a final decision!   Use them as as the beginning of the planning process, gather user feedback, market data, evidence, etc., up to the point where you can make falsifiable decisions of the form “ We b

Ever chipped a tooth? Or, worse, have one knocked out? Assuming you have, the inevitable result is a premature trip to the dentist, followed by the oh-so-entertaining process of  dental restoration . For those of you who haven’t been through this, your dentist basically clean outs the area, takes an impression (there might be 3-D scanning involved here if high-tech-wizardry is involved, but it might also just be a resin cast), makes and fits a “crown”, and then painstakingly shapes it into place, adjusting all the time. The last bit can be remarkably painstaking — there is a lot of custom handiwork involved here . It is quite the PITA, since not only does it have to fit in — plausibly!— with your teeth, but it also has to map into your bite, chewing, gripping etc. Get it wrong, and apart from just looking weird, it can end up making chewing difficult, cause TMJ disorders, and much worse. You’d think that  CAD/3D-Printing could be used to avoid most of this PITA , and you’d

Let’s start with a somewhat innocuous question — “ How well does the design of your system map against the value that it delivers? ” A little bit of pondering reveals that this is a bit of a trick question, since it covers a whole range of possibilities.. After all,  System  is a ridiculously overloaded term, that can refer to anything ranging from Infrastructure (“ k8s on GCP! ,  Postgres! Swagger! React! ”), to Logic (“ CQRS, with event-sourcing tied into a scatter-gather approach! ”), and pretty much everything else in between, above, and below. Design  is equally loaded — is the “low-level” stuff ( k8s, Postgres, etc. ) actually part of the Design? After all, it  could  be, if it is going to inform a “build-vs buy” decision for you by, say, making you roll your own database! That said, the point here is that the question forces you to confront  Value , and actually spell out what it means to you. And the process of spelling it out will actually help you make the (hard?) de

It may be the rage, but good gods, the UI/UX around developing stuff for ML/DL is teh sux0r. It’s all about reams of code, rsync-ing training sets, squinting at charts, and so forth, all in all a throwback to the days of yore. Enter  lobe.ai , where they are building visual tools to help build and train Deep Learning models. As shown above, you start with a “drag-and-drop” scheme, and move on from there, by interacting with your training set, hooking up different models, and visualizing the activation (training progress. This is  seriously  nifty!) in real time. Best of all, it’s all TensorFlow/CoreML/Keras underneath— you can go in and mess with them directly once you’ve got your baseline up to scratch, thus avoiding the (usually  very  painful) process of getting everything setup Just Right. Whats more, once you’re done you can export your models right into TensorFlow/CoreML and move it into whatever system you’re building (or use it  in situ , if you choose to do so). It

“It might be useful” as a reason to not delete code, in the Past : " I don’t want to wade through git " Present : " It might break something " Future : " I might need it someday " /via http://www.commitstrip.com/en/2013/11/08/la-boite-a-cables/

I know, this is belaboring the obvious, but good gods, this particular brand of obvious so,  so  needs to be belabored! Why? Because we, as humans, are kinda hardwired into believing that we‘re better at things than we are (and when it comes to TechBros, fuggedaboutit — they’re the worst).   Oh we may think that we have our s**t together, but it’s an illusion — it turns out that  we can focus on no more than 3 or 4 things at a time . Any more than that, and we have to start resorting to “memory tricks”, things like removing distractions, grouping items, repetition, and so forth, and even then we’re only up to 7 or 8. Coding , for sure is a place where this applies. There is a reason why your system has easy to digest modules, each of which contains wee tiny functions/code-blocks, and all of which are assembled using bog-standard architectural patterns. It’s because, that way, you don’t need to actually keep track of every single thing that’s going on whenever you need to fix it