Practical Technology

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

The last few weeks have been a great learning experience for me - I can officially say 'I can write code'.  ... It will be bad code, to be sure, but it's code! I had the opportunity to (be allowed to) pursue what I deemed a high business-value target - introducing test automation (outside of unit tests).  One PluralSight course later and guy thinks he can dev.  Spoke to our QA guy, and he was enthusiastic, a few other devs mentioned it was a good idea, so hay, here we are. The course:  https://www.pluralsight.com/courses/automated-testing-framework-selenium In C# no less, which our team has been using a fair bit.  We're still in early days, but the repo has grown quite a bit - now have tests/framework pieces across 3 different applications.  I have absolutely zero development background (aside from PowerShell scripting and basic tutelage of a few sharp folk over the years), but the need was there.  Somebody had to do it!  ( they will rue the...

Been a while since I posted anything - so busy with life and work. Last night I had the chance to attend the Toronto Application Lifecycle Management User Group (TALMUG) as they were discussing something I've been grappling with:  Testing (specifically, Agile testing) Some key points I pulled out of the discussion: The key to doing Agile correctly is 'definition of done' and retrospectives (continuous improvement) The key to ensuring testing is a part of the process is 'definition of done', and thus, you must have some sort of Agile-y development process The key to getting the time to continuously improve is to PARTNER with your business colleagues - IT must be viewed as a partner, not a cost centre or necessary evil or code factory The key to transforming to a 'team is responsible for all vs. I'm only responsible for my part' is holding the entire team accountable - no deadline extensions, public shaming Sub-key is 'attitude is king'...