Did you know there actually is a book about the creator of the Linux kernel? And that it was published twelve years ago in 2001? I have used Linux-based operating systems for almost 8 years, and I must admit I never heard of such a book up to three months ago. I ordered it the minute I found out about it. It was a good choice :-)!
Just For Fun: The Story of an Accidental Revolutionary is about the life journey of the father of the Linux kernel — Linus Torvalds, but not only that. It is mostly written as an autobiography, with shorter sections between chapters from a co-author, a journalist, David Diamond (whose idea it was to write a book about Linus in the first place).
It starts with a short preface, a conversation between the two authors on a road trip Linus, his family, and David went on (their destination is an IKEA store in Los Angeles). During the trip, they talk about the book and Linus starts to explain a theory he has about the meaning of life — the law of Linus. The title of the book is in fact based on this theory (which is quite interesting).
Linus starts with describing the memories he has from his childhood in Finland with the same kind of wit you might know from his emails (the first chapter actually starts with: I was an ugly child.). He says, he doesn’t remember much of it, except when it comes to the computers he had. He spent a lot of time with his scientist grandfather, who introduced him to programming and let him use his computer. Linus did what any serious nerdy kid does. Loved maths, stayed indoors a lot, and programmed as much as he could.
The story continues to the times during which Linus got an extremely powerful (at that time) and also extremely expensive 386AT machine. He must have got a loan to be able to afford it. The things Linus did back in that time were basically only programming, sleeping, and eating pretzels. And of course the occasional snooker.
These were the early times and they certainly were not as easy as often portrayed by journalists. Even after the famous release announcement on the Minix’s news group, Linux was not an instant hit. It took quite a lot of hard work before it got any commercial attention, and even more work before Linux actually gained any commercial success.
Linus got a job at the University of Helsinki that allowed him to focus on developing Linux. He decided, he would like to turn Linux into a full featured operating system (which took a lot more work than he had expected). But after some time, he announced the release of Linux 1.0.0. Only this time it was not an email sent to a news group. The usual (and boring) email announcement turned into an event that took place at the university and attracted quite a lot of attention.
In the following chapters, Linus writes about his other early experiences with public speaking and his encounters with journalists coming to his house. Linus explains why he took the job at the Transmeta Corporation and also his decision to relocate from Finland to the US. He also mentions the stock grants he received from Red Hat and various other Linux companies (and why he refused to work for any of them).
Towards the end of the book, there are several essays on open source, intellectual property, copyright, and the future of Linux presenting his own opinions on these topics. Interestingly enough, Linus mentions, that he expects the Linux kernel to power some sort-of handheld devices for reading email in the future (the smart-phones that are common today were certainly not yet that ubiquitous in early 2000s).
This book was a quite an interesting read for me. It is funny and casual, so it reads quite fast. And if you actually use Linux or even participate in the community that surrounds the Linux kernel, I certainly recommend picking it up!
Another book from my huge TOREAD pile is Test Driven Development: By Example from Kent Beck. I learned about this method of development from the Extreme Programming book (also from Kent Beck) and I tried to take advantage of it during the coding phase of my thesis for bachelor’s. It’s a great way to develop software! Having your software covered by unit tests, you are way more confident with it. Along with this comes an assurance, that you didn’t break some part of your software when you add or change something. Without proper testing (either regression or unit) you just try stuff and see what happens. And it’s usually accompanied by glass shattering sounds and echoes of screaming people.
There is a metaphor (according to Steve McConnell in Code Complete) for software development that describes the process as drowning in tar pits with dinosaurs. I was a bit skeptical towards this metaphor at first, but it’s damn accurate when you code, but don’t test.
What exactly can you find in the book? In the first hundred pages, Mr. Beck explains test driven development on a case study of WyCash — some software that handles money. It’s a step-by-step (and by step I mean really small steps) guide through the whole process. To be honest, I didn’t like this part of the book. It explains how exactly TDD should be done, but it’s sooo annoying to read about copying methods from one place to another and replacing
return 5; by
The second part gets a little more interesting. It’s about xUnit — the family of widely used frameworks for unit testing (sUnit for Smalltalk, jUnit for Java, CppUnit for C++ etc). In this part, you will learn how the framework works with test cases, test suits and fixtures, the
tearDown() methods etc. Kent Beck is actually the original author of sUnit, the first framework from this family, so all information you get here comes directly from the source. He actually explains how to implement such a framework using TDD method.
And the last part covers TDD method in general, answers some questions that might spring to mind, usage of design patterns together with TDD and explains some situations you might find yourself in while using test driven development method.
I’d like to point out one last principle — the Red-Green-Refactor. It’s a sort of mantra that will guide you through the whole book. It explains pretty much the whole routine of TDD in three steps (but you have to read the book to understand it properly!).
- Write a test — a test for some new functionality, that will obviously fail (hence the red sign)
- Make it work — write as little code as possible to make the test execute correctly (copy some code, fake the implementation, whatever, just make it work, turn the red to green)
- Refactor — at this point, the functionality is already done, so let’s focus only on the quality of design and implementation
It’s surprisingly easy, but extremely powerful, if you think about that in broader terms. I definitely recommend this book, maybe along with the Extreme Programming from the same author.
I finished all my exams a little early this term (and thank god for that!), so I could dive right into the huge pile of book that always emerges on my desk through the semester. The first one was Brief History of Time from Stephen Hawking which is a very interesting book.
Mr. Hawking talks about some interesting topics ranging from the very foundation of physics, it’s history and how our understanding of the universe evolved over time. There was Aristotle, who thought, that everything consists of the five elements (earth, water, fire, air and aether – a divine substance that makes up the stars and planets). Then came Sir Isaac Newton with his laws and gravitation, Albert Einstein with theory of general relativity. Now we have quantum mechanics and string theory, that are based on the wave-particle duality.
The physicists went through all this in search of a grand unified theory, a theory of everything, one concept that will define the whole universe. The thing is, we’re not there yet and it might take some time. There are still things, that cannot be accurately described by the current principles of quantum mechanics or string theory.
The book also explores black holes and their role the big bang (as the beginning of the universe). I must admit, that I couldn’t understand it all when I read the book for the first time. Shame on me, I’ll have to give it a shot another time.
Another interesting thing, that was introduced in the book is a concept of a finite space with no beginning or end and how to imagine such a situation. You see, in life, everything has a beginning and everything, at some point eventually comes to an end. So it comes very hard to us to think in terms of a space that is not infinitely large, but has no beginning nor ending. Well, the example is right there! We live on it! Take for instance the surface of planet Earth. It’s definitely not infinitely large, but have you seen an end of the world somewhere? 2D surface of a 3D sphere is an example of space of finite size, but with no distinguished points of beginning or end. But how to extend it by one coodrinate to 3D/4D? Can we apply this principle to the space-time continuum or the time itself? Does it mean that our universe doesn’t neccessarily have a begining or end, that it just is?
Another interesting principle concerns closed systems’ entropy. According to the second law of thermodynamics, entropy of an isolated system increases over time, it never decreases. Sounds familiar? Well, in case you’re a software engineer, I’m sure it does :-). By this law, code degrades and we cannot do anything about it — it’s physics! Unfortunatelly, for all spagheti-code producers, enthropy can also be reduced by increasing entropy somewhere else e.g. (surprisingly) putting some work to the system ;-).
There’s a lot more interesting theorems, thoughts and principles from physics, philosophy and many others areas of human knowledge. I think it’s definitely worth reading. Give it a shot!
Another great piece of computer literature I found in our campus’ library! I’m talking about The Pragmatic Programmer by Andy Hunt and David Thomas. And yes, it’s gooood :)!
Title of the book (in it’s Czech version) states: “How to become better programmer and create high quality software.” Right? I want that!
It’s a sort-of-a compilation of advice on software development from the practical point of view based on the experience of the authors. A lot of books come with a load of theory which is good too, but when you’re digging through the mounds of formal methods, it’s very easy to forget about the practical side of software development.
The very first chapter of talks about the career of a programmer or a software developer. The authors say to take your career choices as investments in your future. Pragmatic programmer should invest often and into a wide range of technologies. I don’t like the investment metaphor, but I like the thought. Computers train is moving fast and it will run you over at some point if you don’t jump in.
What I liked about this book the most is the emphasis on automation of routine tasks through scripting and the DRY principle. Having good knowlege of the environment and tools you work with is the key in any profession. But programmers (including myself) often tend to focus on what are we doing and on the final results rather than how we do it. And frankly, every time I stop and think what I could do better or automatically, I always find some weak spot.
The process of programming as in actually writing the code should not be overseen as trivial. You can save yourself a lot of stress by being creative in this area. The DRY principle is somewhat connected to this. If you repeat yourself, you not only work ineffectively (you’re doing stuff twice), but you also set a trap for yourself, which you intend to step into later in the project.
Overall the book is great and I definitely can recommend it. It’s something over 200 pages or so it shouldn’t take a year to read. It’s also very well written and full of jokes, which makes it fun to read!
I got a copy of this awesome book today and I’m so excited, I have to write a post about it :-)!
Yeah, dude, you got yourself a book, whatever.
But it’s in English! I read this holy bible of programming already. But it was only the crappy Czech translation, which is not only a lot worse, it’s actually more expensive than the original version.
The only thing that sucks about this book is, that it’s a paperback. Why the hell does anyone ship a thousand-page book in paperback version only? The explanation is very simple. In fact, it’s written right on the cover. Let’s see if you can figure it out! Here’s a couple of pictures:
You got it! Microsoft Press. Who else could possibly screw up this otherwise perfect piece of literature? Even the Czech version comes in hardcover edition. Yeah, I’m kind of a Microsoft hater. Other than that the book is just amazing. I recommend it to everyone who is serious about software development.