For a short time in 1982 - 1983 I lived near David Brin in La Jolla (near San Diego) and despite his fame and fortune as a great writer and speaker we have stayed in touch. David helps me whenever I ask, most recently with my High School curriculum development for applied terrestrial terraforming. (I hope to blog more on that topic in the future). David wrote a very short, somewhat political graphic novel called Tinkerers that has become available online for free. It's an interesting perspective on Yankee Ingenuity and US culture. 4/5 Stars.
Monday, May 25, 2020
Sunday, May 24, 2020
Automatically delete your stale feature flags
If you use feature flags extensively, it is likely you have a large number of stale feature flags clogging up your code base. Those back room boys over at Uber have released a useful dead-code deletion tool they call "Piranha" that lints your code for dead feature flags and refactors the code to eliminate the flags. Slick.
Labels:
devops
Learn Linux
At a recent Large Installation Systems Administration (LISA) conference I used to attend in the 20th century, one of the speakers gave an introduction to some useful Linux and Bash concepts with examples. If you are an absolute beginner you will get a lot out of it.
Among the many annoying and self-destructive features of my personality is my tendency to assume everyone knows as much or more than I do about some topic we are discussing, or, more frequently, that everyone remembers everything from all of their college courses. I noticed at work recently, that my use of pipelines and xargs in a command line freaked everyone out and my suggestions about better bash wrapper script programming was way above the heads of my audience.
Based on peer feedback about one of my mentees, I strongly suggest that the mentee learn Linux and Bash, to become facile at command line typing, as the skills will be useful through more than one career. The mentee diligently took courses and was promoted. I was thrilled when my mentee privately relayed that one secret of success was proficiency at Bash and Linux.
Labels:
devops
A new volume of ThoughtWorks' "Tech Radar" series
There is something for everyone in the new "Tech Radar" series. ThoughtWorks calls it "an opinionated guide to technology frontiers," it has some good information on tools and process. It's easily worth a skim through the table of contents.
Labels:
devops
Windows Package Manager -- Linux assimilation continues
If you are as confused as I am by the PowerShell commands to manage Windows applications and their dependencies, this preview of "winget" the forthcoming Windows package manager will be a welcome addition to Windows. I have already replaced my terminal with Windows' new, awesome terminal program in which I run bash on Ubuntu.
Microsoft continues its predatory "embrace and extend" Linux assimilation, creating promising, tantalizing but not-quite-good-enough proprietary alternatives to basic Linux features and capabilities.
Labels:
devops
NoOps, DevSecOps, Cloud Functions, Serverless
I just stumbled across Tom McLaughlin's 3-part series on serverless.: (part-1, part-2, part-3). Tom was bitten by the NoOps Serverless bug because of its promise to relieve the pain of managing people and process associated with the mundane and painful 24x7 operation of web services. For Tom, there is no need to consider alternatives.
Yesterday, I had an hour-long debate with a very-intelligent mentor and friend about the economics and total cost of ownership for NoOps. There are many devils in the details of each business and each situation. For small and non-tech businesses right now, the public cloud providers charge too much for each API call of their libraries in most serverless settings. If your business requires predictable, high-availability services with neither distractions nor overhead of consultants or employees who "operate" or develop your operations (DevOps) then the TCO model of maintenance favors serverless. If I were a consultant, I would develop a complex TCO spreadsheet model and questionnaire to enable companies to make the right choice now and revisit their choices as public cloud costs change. But if you are a scrappy small business where everyone wheres "many hats" (works in many different roles), it is less expensive in the short term to burn all the labor hours and do the DevSecOps yourself. If there is clear opportunity cost associated with burn-out and the labor of this work, the economics will still swing the other way and you should go NoOps and Serverless all the way down.
Labels:
devops
Hatching the Phoenix by Frederik Pohl (1999)
I had read this one before and realized I knew the ending about half way through; I got a little more out of it this time because it was a blatant reminder of how much global societal values have shifted away from self-reliance, individual responsibility towards our current ideas that value a totalitarian nanny state and entitlements. 3/5 Stars, probably not worth reading twice.
Subscribe to:
Posts (Atom)











