Saturday Randoms 2015-12-07
Quotes
The true purpose of testing, just like the true purpose of design, is to reduce costs.
Sandi Metz in Practical Object-Oriented Design in Ruby.
Motivational
Want to Create Things That Matter? Be Lazy.
Love the splitting of work into two categories: deep and shallow. How often do we get caught up in shallow work. For example, often times I stay on top of my GitHub notifications, but at the end of the day I don’t feel very productive. I “worked” quite a bit, responded to several things, and definitely added value, but yet have that lingering feeling that I didn’t get much done.
On the contrary, the days where I forget to check my notifications, I often feel super productive. I think the reason is that on those days I am completely in the zone working on something deep.
It’s more useful to divide this activity into two distinct types of effort, deep > and shallow:
- Deep Work: Cognitively demanding tasks that require you to focus without > distraction and apply hard to replicate skills.
- Shallow Work: Logistical style tasks that do not require intense focus or the > application of hard to replicate skills.
Latency
Page Weight Doesn’t Matter
Great post about the fact that bandwidth is not the only issue. The other issue is N+1 requests because each request has a minimum amount of latency.
Bandwidth is not the problem, and the performance of the web will not improve as broadband access becomes more widespread.
The problem is latency.
9.5 Low Latency Decision as a Service Design Patterns
I particularly enjoyed the section on dynamic timeouts. Too often we add a timeout that is worst-case scenario, but really, we could detect issues earlier if we made our timeouts more dynamic based on the work being carried out.
That timeout is a function of the minimum/maximum time for the operation to complete, and the time-to-live (remaining time) of this specific request.
Interfaces
Let’s talk about logging
Great post in simplifying the logging interface. Uses go as an example, but applies to any language. I’ve never used anything other than info and debug, so naturally I agree with Dave.
I believe that there are only two things you should log:
- Things that developers care about when they are developing or debugging > software.
- Things that users care about when using your software.
Obviously these are debug and info levels, respectively.
On GitHub
KairosDB
It wouldn’t be one of my random posts without a link to a new database. I’m especially attracted to TSDB’s so this caught my eye. I’m not saying I’d ever use it, but I’m always curious to kick the tires.
Fast Time Series Database on Cassandra.
Web Debugging Proxy based on Chrome DevTools Network panel.
I installed and gave it a test run and it works as advertised. Pretty neat.
This tool will help you analyze web traffic outside the browser using familiar Chrome DevTools interface.
Tweets
This, THIS. pic.twitter.com/A7lmt4zMey— Amy-Marie Graves (@ObvItsAmy) December 3, 2015
Imagine if last names were invented now, so instead of “Smith” and “Baker,” we had “Frontenddeveloper” and “Socialmediaconsultant.”— Tim Morgan (@riscfuture) October 30, 2015
"The lack of backpressure is the root cause of many microservices failures, this is how systems collapse" @bcantrill #qconsf— Ines Sombra (@randommood) November 17, 2015