Posted on January 4, 2018 in What I Learned Yesterday by adam1 Comment »
  • Hockey [ok, sports] parents are crazy
  • It’s not the day after that hurts, it’s the day after the day after. (Snowboarding crash.)
  • Keep track of your time while doing it, as trying to remember what you did (or learned…) after the fact rarely works out well.
  • Vagrant based development environments are brilliant. Yes, yes, Docker ones are the new hotness…
  • There is not the equivalent of -s -N for mysql once you are in the cli tool so either you get column names and grids for all queries, or you don’t.
  • Test your reporting
  • Then test it again.
Posted on December 30, 2017 in What I Learned Yesterday by adamNo Comments »
  • I’ve always heard rumour that AWS billing is a nightmare, and I sorta got a peek at that yesterday. Part of what I need to figure out is how to attribute our AWS spend to various projects (for tax purposes as well as project profitability) and since I was in CloudFront doing something I poked around a bit. Yeeaaaah, what a mess. The billing page just as requests by region. The CloudFront usage report just has stats and resource ids. But not tags. I’ve not spent much time with this, so I’m sure there is a way to get the per item spend based on the tag, but I suspect there will be some scripting in the future to figure that out rather than one convenient report I didn’t have to build myself.
  • Speaking of AWS tags, they appear to be case sensitive, so ‘Client’ is different than ‘client’ which is a pain. There are very few places where case matters. Stop it.
  • Now the reason I am using takes is in the vain hope that the ‘resource allocation tags’ feature of billing works as one might expect. Except, you have to go into the page and enable them. Which I have only just now done. (For both ‘Client’ and ‘client’.)
Posted on December 29, 2017 in What I Learned Yesterday by adamNo Comments »
  • The MySQL Timestamp format goes to a single second of accuracy, so when you pull records and order them by a timestamp column they will be returned in their creation order if the timestamp is the same. When creation order really matters, you have to do something like
    ORDER BY created_at DSC, id DSC
  • Consistency matters. But so do boundaries. Just because something is called ‘data’ internally, doesn’t mean it has to be externally. Especially if ‘info’ is a better name externally. What’s worse though is when you have used ‘info’ in one api response, but ‘data’ every where else. Worse still, when you are the person who introduced the inconsistency.
  • AWS OpsWorks for Puppet Enterprise would make my life somewhat easier, but would also add $200 USD a month to our bill. A couple more deals and I’ll totally pull the trigger on this.