Practical Technology

I've been reading ' How to measure anything - Finding the value of intangibles in business, 3rd edition ' (you should read this, too) and it has completely revised how I approach problems. The biggest thing to me is this:  My understanding of WHAT a measurement is and WHY we measure things has completely and fundamentally changed. Pretend someone asked you 'what is a measurement?'.  Now do the same thing for 'why do we measure'.  Answer the questions then scroll down. Compare to this: What: A measurement is the reduction of uncertainty based on observations. Why: Because we are trying to reduce the risk in a decision we need to make. I am (badly) paraphrasing/summarizing...but that's the gist.  A reduction of uncertainty - NOT the elimination of uncertainty.  And measurement now has a PURPOSE - to help you reduce risk when making decisions.   It starts with knowing what decision you need to make. So simple, but so powerful.  You...

I get this picture in my head of all our users going to load our app (you know, the one they pay for), and they just get a spinning load icon.  And they frown, and try again.  Then they start getting all angry and blaming the app for making them late, and their mortgage, and all of life's problems...and then from that moment on they resent the app.  Other users simply sigh in defeat and walk away, always to remember this moment of the app letting them down. Kinda silly, but that's the best visualization of what goes on in my head when production's on fire.  The longer it takes to fix this, the more users get angry and/or depressed.

So I've run into this twice now and have to write it down so I don't forget (or at least so future-me can google myself). We were using a standard AWS Elastic Load Balancer (ELB) to serve traffic to our API.  The API is served from IIS webservers via 80/443.  ELB is not checking back-end cert authenticity.  (the servers have a self-signed cert) We're trying to move toward more of a farming approach to servers vs. pets, and so decided to spin up a batch of new servers and migrate them over using the very fabulous Route 53 traffic policies.  It worked great! Until humans got involved. Since this is a new thing, I built one, tested it, then built the rest.  For whatever reason a seemingly minor change I made didn't make it back into the repo, and so the other 3 servers were built using the non-fixed configuration. We noticed in New Relic that of the four servers, only one was doing any heavy lifting - the other 3 were receiving almost the same amount of r...

Three guys set out to make money. The first decides the best way is to talk to his entire contact list and solicit sales. The second decides that an MBA is a sure ticket. The third decides that robbing banks is certainly the fastest path. Do they share the same vision?

I recently had the pleasure if misdiagnosing a problem and spending 2 days in the deep weeds of IIS.  Figured I'd share my learnings and increase google fodder. Update.20210713: Some wonderful info here!  https://www.leansentry.com/Guide/iis-logs?source=guide-b Update.20210505: If you are seeing 503 errors, don't forget that ELBs (AWS load balancers) can throw a very similar 503 error page...you can validate by browser inspecting the headers. Update: Another finding, '500 0 0' entries that don't work with Failed Request Tracing should be dropping stuff in the Application log. Figure out how to reproduce the error, maybe write a test? :) Gather the specific error code:  "500" is the request status code, you also have subStatus codes and win32-status codes.  e.g. 500.1.1, 403.1.2 If you have server access, set the hosts file on the server to point  www.website.com  to 127.0.0.1, then load a browser on the server itself and re-create the error - moar i...

It has been a very busy 6 months at work...decided that I really need to keep track of what goes on so lessons don't go forgotten... Non-technical What it's like living with mostly remote teams (learning to better use communication tools) Living under major enterprise systems (less control over hardware, purchasing, security, etc) Empathy toward developers (experience w. development) Empathy toward QA (experience w. testing & test automation) Empathy toward operations (experience w. on-call paging) Empathy toward management (leading remote teams is hard) AWS (getting used to destroying servers, load balancers, etc, getting used to re-thinking how to design things) Writing tech specs to communicate ideas (because remote teams) Living with branches (complexities, missing input/requirements makes for long-lived branches that need care and feeding) Understanding when the agile testing pyramid applies (sometimes the ideal is simply not possible today) Understandin...

The usual disclaimer of ' I don't know what I'm talking about ' applies here... Lately we have been feeling some software quality hurt - not enough time, not enough people testing, stuff still getting missed and reported as bugs by the customer.  As this is a topic not unfamiliar to me, I decided to do some deeper research, and even attend a local user group to discuss test automation. I already knew that ' GUI test bad!  Unit/API test good! ', but confirmed with multiple developers that our legacy app simply had a lot tied into the GUI.  That's ok - legacy is where your revenue is , as someone pointed out ( possibly at DevOpsDays Toronto? ) - so we know that we kinda need GUI testing. The user group's consensus was ' you need a test framework ', so I figured we needed a test framework and set about building one.  There were a lot of bad reasons for me being the person to do this...but a few good ones, too: I actually had some time to spa...