Some bloggers have strong opinions and are just right all the damn time. Like Joel Spolsky, and Jason Fried. I admire them, but I’ve never been that guy, or been that confident in my opinions. But damnit, some of my oldest opinions hold up. After nearly two decades of professional programming, I’ve looked back and thought about the opinions I originally had. Here are the ones that I’m convinced I was always right about. ...
25 years ago, a simple question was asked about storage, access times, and economics, and the result was a simple paper. Every ten-ish years since then, an updated paper was written to answer the same question. It’s not a terribly good measure of complexity, but it is enlightening. In 1985 Jim Gray and Franco Putzolu asked a simple question. When does it make economic sense to make a piece of data resident in main memory and when does it make sense to have it resident in secondary memory (disc) where it must be moved to main memory prior to reading or writing? ...
Mark Richards runs the Developer to Architect website, and puts out a video every Monday. He has helpfully categorized them. I watched all the videos in the “Soft Skills” category and took notes. Gaining Technical Breadth Everything in the world can be divided into three categories: What you know What you know you don’t know What you don’t know you don’t know Technical depth is “what you know”. Technical breadth is “what you know” + “what you know you don’t know”. (Sidenote: I’ve always thought of technical breadth as stuff you know at a high level, but never used in production.) ...
I’ve been reading about failures in distributed computing. A lot of it is thanks to Vaidehi Joshi’s Year of Distributed Computing at https://medium.com/@vaidehijoshi . Here’s a small summary of what I’ve learned. A fault is a flaw in the system. It leads to an error, which is when a program is in a bad state. That results in a server failure. Hierarchy of faults Transient - Occurs once and leaves (like a Panda) Intermittent - Occurs sometimes. Permanent - Always occurs. Types of Errors I don’t think there is a concept of error types. ...
excerpt from How Complex Systems Fail 15) Views of ‘cause’ limit the effectiveness of defenses against future events. Post-accident remedies for “human error” are usually predicated on obstructing activities that can “cause” accidents. These end-of-the chain measures do little to reduce the likelihood of further accidents. In fact that likelihood of an identical accident is already extraordinarily low because the pattern of latent failures changes constantly. Instead of increasing safety, post-accident remedies usually increase the coupling and complexity of the system. This increases the potential number of latent failures and also makes the detection and blocking of accident trajectories more difficult. ...
For my own reference, here are notes I took while reading Google’s book on SRE. Site Reliability Engineering - Edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy Chapter 7 has great stories about the growth and setbacks of automation at Google. http://landing.google.com/sre/book/chapters/automation-at-google.html Chapter 13 has stories of emergencies. My favorite involved a disk erasing system which used 0 to mean “all”. http://landing.google.com/sre/book/chapters/emergency-response.html They namedrop Perl. Jeez. All bug-fixes are cherry-picked to go into the mainline. ...
A small trick to make “before” a bit more powerful, a bit more useful, and a bit more dangerous. In Moose, the “before” and “after” method modifiers normally don’t affect the method they are modifying. But I’ve always wished that I could. Specifically, I wish “before” could take in and modify the parameters, and “after” could take in and modify the return value. Today I learned that I can partially get my wish. ...
The great benefit of knowing the command-line is being able to write scripts to analyze scripts, all in ~1 minute. Add to your .bash_profile. # get list of objects and functions in a python file alias python_structure="perl -ne'print if /\\b(?>!:)(class|def)\\s/'"
After a lifetime of programming and compsci education, I’ve had some issues learning with Python. It screws me up in small ways. It’s a wonderful language, but dear god I wish these things were different. Missing the ++ operator. Missing foo.push. I’ve spent my whole life being trained to use push() on lists, and now it’s just not there. This breaks a deeply-ingrained typing habit. Seemingly random things are not object-oriented. Like len(foo) instead of foo.len(). Or type(foo) instead of something like foo._type(). I don’t know why tuples are needed. Not having to worry (too deeply) about immutable strings is one of the glories of modern programming languages. So why does Python need to use immutable arrays? I’d guess the answer is “optimization”, but that doesn’t seem to gel with the fact that we aren’t managing immutable strings. Ridiculously minor issues: I have to modify two things to change import foo to from foo import bar. I wish I could just append text onto the end, like import foo specifically bar. Vi has made me lazy like that.
When I first read the gang of four’s Design Patterns I dismissed most of it as a coverup for the unfortunate parts of C++’s object design. That was definitely unfair, since the strongest benefits of Design Patterns come from managing huge code bases, a fact that I missed with all the small examples. But even still, I would love a book on design patterns that is built for modern interpreted languages, with duck-typing and no type checking.