A small post just to break the blog hiatus. Once upon a time there was a Prolog interpreter that was used in the Windows NT kernel. You can read about it here. The code is in the public domain and years ago I had downloaded from the net. It seems that it took me close to 8 years to put it on GitHub, for software archaeologists to dig into if they like.
https://github.com/a-yiorgos/smallprolog
Today it was my fourth (I believe) encounter with APL:
Today it was Functional Geekery’s Episode 65 where I found out about the most interesting (to me) implementation of Conway’s Game of Life.
[ Mostly saving this post for posterity ]
I had heard of the language long before it was made Open Source. In order to get access to the implementation I had Timos Sellis sign an NDA with Ericsson. I had fun with Mnesia (the distributed DBMS) and started thinking of whether it could be applied to stuff I was good at at the time (namely SMTP and DNS). In fact it was. Because most of the Erlang team formed a company named Bluetail that was making software based load balancers with Erlang and got sold at $152M.
Nowadays I occasionally have “fun” with the Erlang VM whenever I have a RabbitMQ instance go mad.
But this? This is something only someone like the guy who writes RabbitMQ could discover:
I found out about the Expert Beginner book from Avdi Grimm’s newsletter. It is a small but discomforting book (a series of blog posts turned into a book) that I believe anyone in programming, systems administration or DevOps arena must devote some hours to read. Its basic premise is the following extension of the Dreyfus model:
While the book is a guide on how to spot and avoid Expert Beginners (people who believe they have mastered all there is to master in their field and anything beyond what they already know is useless), it also serves as a guide to spot when you start emitting Expert Beginner signals yourself.
Do yourself a favor and read the book. Especially if you consider yourself a guru, ninja or rockstar of something. It will only cost you two hours.
A BlinkStick is a USB powered LED that can be driven via a simple API from a programming language like Python. Since the status of an ElasticSearch cluster can be determined using three colors (green, yellow, red) a BlinkStick can be a nice visual aid in your monitoring infrastructure. An easy proof of concept is to use the BlinkStick Website API that allows, given a token, for the color of your BlinkStick to be set remotely by your monitoring system for example. You can find such a proof of concept here: https://github.com/a-yiorgos/elastic-blink
Of course if you want a more elaborate and secure setup, it is possible. I had my 15 minutes of fun. YMMV.
I got You are a writer by Jeff Goins on a day it was given for free years ago. I got to read it over the weekend. I thought then, and I still do no now, that the book offers advice to people who write code too. Maybe because sometimes I believe that code is like a poem. So I will try to rehash advice I found useful here, since this seems to be one of the acceptable self-help books that have come my way.
While anyone can connect with anyone and put stuff out there, how does one gets noticed? By helping people. By relieving their pain. I’ve advocated answering one question per day on ServerFault (or StackOverflow, or whatever clicks to you), although I do not always practice this. I used to, though, years ago when mailing lists and newsgroups were the thing.
You need to build a platform. This blog is a platform. I post stuff here. Others do it with more success, for example John Sonmez who uses a variety of platforms (blog, YouTube channel, podcast, book) to publish his work (and he gives 90% of his work for free he said on Ruby Rogues). You make the platform and you establish a brand. Without a brand you are forgettable.
And you know what helps you not being forgotten? Networking does. Meaningful relationships do. Relationships that are mutual, matter to both parties and give you the opportunity to make friends and find mentors.
But nothing of the above makes any sense unless you are prepared to answer the following questions:
Please take the time to sincerely answer these questions. And while you are at it, understand that you probably are not the best coder in the world yet. But you can become one. There is room at the top here.
Like one of the main characters in The Phoenix Project said, mastery comes through practice. And here Goins argues that the best kind of practice is done publicly. Interestingly GiHub seems to be our public place of practice.
While you’re at it, learn to estimate. Underpromise and overdeliver. Especially when you are part of a team. Like Goins writes, you have a gift. Someone is willing to work with you.
Go on! Practice.
Just a quick note to self now that I remembered SICP again:
alias mit-scheme='/Applications/MIT:GNU\ Scheme.app/Contents/Resources/mit-scheme'
A cousin from downunder is visiting these days, so I want to talk about a gift he once gave me.
20+ years ago I had to pass a course named “Programming Languages”. One of the languages to learn was Lisp and for that the professor handed us all a copy of David Betz’s XLISP for DOS (he later focused only on XScheme and even later XLISPs by Betz are Schemes). However I did not have a PC at the time and when I told my Professor that he did two things: First he gave me a copy from the library of Structure and Interpretation of Computer Programs (because we had MIT-Scheme at the lab). Second I gave the test in Scheme instead of Lisp.
After a while I had to return the copy of SICP at the library. But the book grew on me. I could not find it at the local bookstores and Amazon was not even a glimpse in Bezos’s mind (and even if it was, I could not have a credit card at the time thanks to how our banking system worked, but that is another story). So what my father does is he sends a letter to my cousin with the book title (bad phone lines and bad pronunciation were not helping) and I think three months later the CS book that mostly shaped my thought arrived!
Thank you George for the wonderful present!
PS: Some years later, in 1996 the second edition came out. That I bought from MIT Press directly via email along with a T-shirt of the book.
This is basically an effort to rehash Conway’s Recipe for Success for DevOps:
Work on several problems at a time
Conway was working with six problems at a time as a means to battle depression by failing to conquer a specific problem. Six problems are enough to fit your daily mood. It is more than one per day anyway. In DevOps the software stack you need to coordinate just to make your app go live is so versatile that there is always something you can work on daily even if your primary focus seems stalled. Beware though since this is also a way to not make any work at all. You can eat an elephant but somehow we seem to attract hordes of them. And then you can just stare at the monitor Hopeless.
A good strategy to combat this is what I once heard “type A people procrastinate by doing other things”. Your stack has more than six components, you can easily have more than six fallbacks should you get stuck.
If anything, please try and don’t ever break your rhythm. Interrupts cost. Context switching too.
Pick your problems with specific goals in mind
This is one thing that I suffer a lot. Everything is cool. And I want / need to know everything. In acceptable depth. Today. But this is not feasible even if we have 25h per day and no sleep. So, IMHO (and I try hard to do so) the plan is to pick problems with two goals in mind: Your current job and “the dream job” you want to land on.
Big problem
The difficult and important problem for Conway. The Architecture problem in the DevOps case. Is your running Architecture OK? Does it need improvements? Do you need something completely new? Are you to invent the next lambda architecture? How are you going to make your dent in the circle?
(Yes, you have to try to make a dent in the circle even if you’re not pursuing a PhD.)
Workable problem
Big problems mean big delays most of the time. And in trying to solve big problems you need practice. So you need to have an arsenal of problems you can work on that you can solve. They may be boring or even need repeated tedious tasks performed by you. Automate yourself out of them if you can. Flex your brain muscle so that you can work on the big stuff properly warmed up. Your current setup always has clear steps that you can walk forward. Nothing fancy that you could give a speech about, but something that you can complete during the day and feel good about it.
Book problem
I do not have a book project on my own. But over the last 20 years there have been two books that I wish I could find time to revise. I have a friend though that just finished writing a book and he seems pretty happy with the result.
If you’re writing a book, consider this as yet another problem you’re working on. If you’re not writing a book, well write something. There is always less documentation than needed.
Read a book by the way. Make reading books your book project. That’s mine too.
Fun problem
You should always have at least one problem that you do for fun said Conway. Well I guess we have Github for that, don’t we? I think my current fun project will be cryptopals. Let’s see for how long.
Enjoy your life
“The trick in life is to find out what you think is play that the fools think is work so that they will pay you to do it.”
Happiness is the single productivity booster that one can think of. Grief and depression the best demoralisers. This post about Karojisatsu really shook me. And it came during a time that I was seriously thinking about DevOps inflicted depression.
I still have no generally applicable tricks about that.
I was showing the BlinkStick to kid[2] today and after a few blinks, I decided to make it speak Morse code. It was fun and quick, for I did not have to start from scratch. Morse code on a LED has done the same thing using a Raspberry Pi and a LED (I used their Morse code dictionary).
The Python code is available here: https://github.com/a-yiorgos/blinkstick-morse
Managing organized complexity 