As long as P versus NP remains a mystery we do not know what we cannot do, and that’s liberating.
I follow Lance Fortnow’s blog from time to time. So when the book was out, I fired up the kindle and bought it. And then it stayed there for some time. Most likely because two out of seven days of the week I am not sure I can explain P vs NP. The rest I might be able, but the difficulty of the problem makes one double think about it, even when it is a book that makes it accessible to the general public. After all, it is The Problem.
And then came a plane trip. And with nowhere to go for the next 2,5 hours I started reading it. Fast. The history of the problem is there. Examples that are very easily understood are there. The hop from the example to the equivalent real problem is there, so you get to understand vertex cover before ever knowing the name. Plus you get to learn a bit about complexity during the Cold War and about quantum computing too.
We know for example that if P=NP, then cryptography as we know it will be defeated. But how will other aspects of our World change? Fortnow offers a glimpse. Is it worth it? Maybe. You will be the judge. Is it likely that P=NP? The author does not believe so (I do not want it to be, and want versus believe denotes the vast skill difference between him and me).
Chapter 2 was a bit boring for me and I almost gave up on the book. Fortunately I did not. If you are a computational complexity theorist then the book is not for you, but if you are not and you want to ask clear questions to one, then it will definitely help.
I finally got to read Release It!. It would have served me better had I read it 10 years or so ago when I actually bought it. But never too late. There is a second edition that came out this month. While this first edition clearly shows its age and relics of another time, I guess the second edition is more hip, fresh, readable and with more experience to share.
Not a timeless book, but one that needs a refresh every decade or so. I tag it under “system administration” too, because a system is what you build, works and bring money in, not just what Ops runs and grumbles about.
I am doing a variation of spaced learning with the books I am currently reading. It flows almost naturally, since three of them have similar (economic) premises:
I highly enjoyed reading the first three. Last week I was switching between them every hour (I was on vacation and got a lot of downtime and reading time). Not that I did not like the fourth one, but the first three make a nice economics spaghetti.
And thus concludes a short blog post after some silence.
I won’t pretend that I’ve read it. I’ve read critiques of it, I’ve read a book that heavily relies on it and I’ve gifted the iPad app of it twice I think. But now, according to Wolfram, it is available for free download:
You can download each chapter individually in PDF and use something like pdftk to concatenate them.
No, I will not even pretend that I will try to read this. I have other weird books in the pipeline. But still automata appeal to me, so the occasional glimpse may happen. Then again, the web version has been there for years and I’ve browsed it very few times. Time is a resource that I cannot devote to Wolfram’s thought it seems.
Well if you’re doing DevOps (whatever that means for you) you’re supposed to have read The Phoenix Project (which I have). Inside the Phoenix there are constant references to Visible Ops and The Goal. Well, The Goal is a something of a gospel it seems so I went ahead a few months ago and read it.
It is a far better book to read than the Phoenix. Much more entertaining and insightful. I guess Goldratt is a better writer. The book does a hell of a good job to explain the basics of The Theory of Constraints which receives new attention in this age of software automation and pipelines and the perceived “clash” between DevOps, ITIL and any other related acronym. I see ToC posts pop up weekly now. The only thing that you may not like in the book is the technology from the 80s, but only if you’ve never used it.
My best part was the really nice simulation example it used to make clear a counter-intuitive result and his family crisis management. Granted, many things went the right way for the main hero, but hey, the author was trying to make a point and needed a vehicle. Fiction is not life.
I read it from the latest kindle edition. According to my Kindle I am still at 97% of the book and that is because right after the end of the book there is a paper explaining some of the concepts with real industry examples. The boredom to read this after the turmoil the hero has gone through is evident. It also explains why the author needed a novel in order to engage you in ToC.
Like a good friend said: “I really want to get in the book and help him out!”
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.
That’s the bear trap, the greatest vice. Your job. You can justify about any behavior with it. Maybe that’s why you do it, so you don’t have to deal with all those other problems.
I never expected to find the explanation of BOFHiness in The Soul of New Machine. The book lived on my wishlist for a long time and it was gifted to me, only to wait there inside the kindle for a couple more years. Tracy Kidder follows the team that built Data General’s Eagle, their first 32bit machine and a kind of Plan B for the company, since the market was being dominated by the Vaxen and they had to react. Serious computing history unfolds in front of you.
A very interesting story, and lucky Kidder got to follow a lot of the story in the making, even though this was supposed to be a secret project. While this is not a hard science book, you get to learn a lot about computer architecture, or depending your skills, computer architecture history. You get to understand the magic that happens when your keystrokes are transformed into the desired result. The moment when the software and hardware connect. I particularly enjoyed the chapters about debugging boards with an oscillator.
While I cannot claim the brilliance of Tom West, I do see elements of similar behavior and the reasons for this. I need to work on that.
Thus he supplied them one answer to the question of what happens to computer engineers who pass forty.
I reached 44 yesterday. Still not a middle manager.