Parsing Techniques – A Practical Guide

Memory gets triggered in the most unexpected ways. I maintain a fairly large library of printed and electronic books (most of them DRMed -the light cases socially, kindle and Adobe locked the rest unfortunately) on subjects that interest me. It is fairly evident that I will not read them all, but I always have a book (and sometimes a paper) to recommend to a friend that has a problem. It seems that I am not the only one that thinks that personal libraries are supposed to be full of unread books.

Anyway, I was listening to Podcast.__init__ Episode 95 and one of the guests mentioned Parsing Techniques – A Practical Guide by Grune, I think it was when they touched Earley parsers and how most books about parsing do not really touch on how the actual parser is built. Wait a minute I’ve got that PDF! And you can go to the author’s site and download it. And you know what? There is a second edition out. For > 100 euros for a DRMed PDF I may not buy it since parsing is definitely not my thing, but somebody else out there might need the second edition. Judging from my skimming of the first edition, this is close to the encyclopaedia of parsing. I will go through some pages tonight.

Just for a refresher.

APL

Today it was my fourth (I believe) encounter with APL:

  • First, too many years ago when skimming through Tim Budd’s “The Kamin Interpreters in C++” (and the Kamin book afterwards). For the hardcore fans, Tim Budd has a book on implementing an APL compiler.
  • Next was a Dr Dobbs issue about the J programming language.
  • Some years a ago a comment on this blog about Dyalog.

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.

My brief Erlang story

[ 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:

Donald Knuth was the first Erlang programmer

The Expert Beginner

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:

The Expert Beginner trap
The Expert Beginner trap

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.

Using a BlinkStick to monitor the health of an ElasticSearch cluster

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

BlinkStick, soldered
BlinkStick, soldered

Of course if you want a more elaborate and secure setup, it is possible. I had my 15 minutes of fun. YMMV.

You are a writer (so start acting like one)

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:

  • Am I serious?
  • Am I committed?
  • Am I prepared to be challenged?

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.

My SICP story

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.