I have read a blog post a few days ago about someone thinking a good programmer interview question was:
How does a hash table work?
While it is a very interesting question, I doubt many programmers (even relatively good ones) can answer that question. If I look back and think of all the employees in all the companies I have known, I can count on one hand people that can answer that question. I can think of 3 or 4 I met in one company, and maybe another 1 or 2 in different companies. And I don’t think anyone would have been able to go deeper in the details like mentioning closed-addressed vs open-addressed possible implementations.
I am so negative, because a question about some important details of the inner working of the Java HashMap was raised at work a week ago. I was the only one (because I had read several times about hash tables) to be aware that the equals method of the key object was called every time you do a table.get(xxx) or a table.put(xxx, yyy). Others thought only the hashCode() method was used.
This kind of interview question creates a high bias towards people coming straight out of school if they have Hashtable in their program. For people with more experience, it is highly likely if they ever read about it that they forgot the details (and maybe more than the details).
This can seem shocking as hash tables are used almost everywhere these days, but it’s a reality.
I don’t remember why I started to subscribe to the Java concurrency-interest list. I find that overall, it is an excellent mailing list.
There was a post at one point about the Dante Inferno’s problem. It triggered my attention, so I decided to buy the book the post was referring to, The Art of Multiprocessor Programming by M Herlihy and N. Shavit.
The books starts with the basics, and is very didactic in its approach. I enjoyed to learn how locks work and how to build them almost out of nothing. The progression is good, starting with a half broken but simple lock and evolving to the more standard algorithm, like the Bakery Lock algorithm. The algorithms are extremely well explained. Later it explains the differences between spin locks (Bakery for example) and blocking locks, while presenting new algorithms for blocking locks.
What is described in the many chapters is mainly how to write the javax.concurrency.utils library, why, and what to add to it.
Here are the main subjects I found interesting even if they are not always well presented:
Bitonic networks: I had not read about it before and I found the subject fascinating. Go and click on the link if you don’t know what I am talking about.
Skip Lists: while I found the subject to be very interesting, I found the skip lists were not presented in a very clear manner. I find the wikipedia page about Skip Lists and the original paper much better to understand skip lists. Fortunately the authors talk about how to make it more concurrent friendly, and that part is well explained.
Software transactional memory: I have the same opinion than with skip list, except the wikipedia page is very short on details, and the book does give much more details. We feel it is the end of the book and the authors took less time to present it an easily understandable manner. One need to read the chapter several times or to have read before about it to really understand.
I like books that make me learn new concepts. In The Art of Multiprocessor Programming, there are plenty of concepts, ideas I had never heard about before, even though most of it is probably well known to specialists in the field. So even if some rare subjects could be presented better, I recommend that book to anybody interested in concurrent programming.
I have read many inspiring books about object oriented programming. I find B. Meyer Object Oriented Software Construction one of the best in the lot. B. Meyer tries to explain in a progressive way why OO is better, by introducing it bit by bit. I have read different related design patterns book, the GoF one, Martin Fowler ones. I have been programming Java for about 10 years now. And yet, today, I feel unconvinced.
Maybe it is because I have been recently on different bigger projects, maybe it is because I have worked with different people. What I see today, is a tendency to overcomplexity. A simple example is you need a code to do only 3 different things in particular cases. Instead of using if-then-else, because it reminds you of the devils of procedural programming, you write 3 classes and 1 interface. Now the usual excuse for such a behavior is to say, we don’t know, maybe there will be a 4th one, my code will make it easy to handle the 4th one. Often when there are requirements change, you don’t expect at all where it will be, and it is not what a developer thought would change that actually changes. So the dev with the 3 classes has now to change its interface, update the 3 classes, and create a 4th one. The “procedural” guy has no such problem because he did not try to abstract something that did not need any abstraction in the first place.
Now on millions lines of code software, it is important to have a few basic principles in the overall design, to identify components that talk to each other, to define a global structure. But at the developer dimension, there is often no need for that, except in the few cases where it makes sense.
I do use design patterns sometimes, when I feel it is the simplest flexible way, but it is quite rare overall. There are 2 common jokes about design patterns. One is from people who don’t know what they are. They often take the piss of architects doing design patterns all the time that in the end don’t really know how to do things and spend a lot of time and money on crap. Other is from Pythonists and Rubyists. They say that you do not need design patterns if the language is done right.
The Java language, with the Generics, and the propositions for Java 7 is also evolving in the overcomplex side (ok, the Generics are probably much worse than Java 7 propositions). Soon people will be more confortable reading Haskell. Joke aside, Haskell while being different to read, has really something for it. It brings a new way of writing programs, moves the complexity somewhere else.
I still think lots of ideas in B. Meyer book are valid today. But an essential part must be missing. Overdesign seems to be too recurrent in OO projects.
I think the OpenBSD crowd is a bunch of masturbating monkeys
Beside that provoking sentence he has a valid point. Security bugs should not be more important than other bugs. Too often, management and psychology encourage making security bugs a very important issue and security people VIPs. I have seen this over and over.
I was very disappointed by KDE 4.0 when I first tried it on an ubuntu machine. It was just unusable. I would not have even considered it as a beta.
I changed the system on my home laptop because Ubuntu with KDE 4 was there. I decided to go for something more roots. I had good memories of Gentoo when I tried it some years ago. Maybe I just became too old to appreciate it anymore. But after spending several hours on a Grub error 2 problem, seeing the live CD does not even use grub so you can’t use the CD to boot from hard drive and fix the problem easily, wondering if the problem was a problematic Grub version with my drive or not (I never had problems with Grub and other distros on that same machine before), I decided to install OpenSuse 11.
I was surprised (and impressed by Suse) that KDE 4.xx shipped with OpenSuse was usable! Except the program menu, it’s not worse than KDE 3.
I just found out my laptop was faster in default settings than my home desktop to compile a resonably sized project (5 min vs 6 min). I was surprised as I thought the disk in the desktop would make a big difference. The processor in my desktop is not that great (simple pentium e2180). My laptop has a 2ghz core2duo processor. In Ghz processor are of the same speed.
I tried to overclock my home pc to see what difference it could make, I made it run at 2.6Ghz instead of the standard 2Ghz. The compilation time dropped to 4.5 min.
The ration of processor speed (2.6/2) is almost the same as the ratio of compilation time (6/4.5). I am surprised by such a linearity of behavior.
I tried Firefox 3 twice before, while it was in alpha and beta. I was not impressed at all, it seemed buggy (normal for alpha) and I found the new location bar behavior unintuitive. It did not seem that much faster either. So I always quickly went back to Firefox 2.
I tried again recently, funnily, because of a bad Kernel update. One day, after a kernel update, my laptop started to run only at a max of 800Mhz, I did not notice it immediately. I thought wow Firefox 2.0 is really slow with gmail, maybe I should try Firefox 3 again. I did and worked a few days without noticing the processor speed difference that much. Firefox 3 at 800Mhz is as fast as Firefox 2.0 at 2Ghz. It is only after struggling with very long compilation time related to my work that I thought something was wrong.
As usual with Linux troubles, solution are strange but not too hard to find out. I just had to add a processor.ignore_ppc=1 kernel parameter for the kernel to behave properly again.
Yesterday I installed Firefox 3 on a MacBook, and I was really impressed by its speed. I felt faster than Safari. And now I got used to the new location bar behavior, I would not go back (I think the behavior improved after the betas as well).
Another interesting browser these days, especially for bloggers, is Flock 2 (based on Firefox 3).
I finally took some time to try Google AppEngine. It used to be easy to find free PHP hosting around 2000. It became a rarity. So writing small experiments for free on the web was difficult. Experiments are back thanks to Google with their AppEngine. Many aspects of it are quite interesting and show where they focus.
First it is all Python. It makes sense as I believe Guido v Rossum, Python creator, works for Google. Some people believe in a future Java application hosting. I don’t see any reason why it could not become a reality. Making something like AppEngine is a big task, changing implementation language is not. In the meantime, it is not an excuse not to try it, as the Python standard library is fairly rich and Google provides additional libraries on top of it.
AppEngine offers the basic bricks for building web apps:
Persistence: they rolled out their own persistence layer. Is it because it is stored in BigTable? It is quite basic (no join), maybe again for the same reason. Still it is enough to write prototypes or do fun stuff.
View: one can use Django templates. They are not perfect but better done than what we have in the java world for templating.
Authentication: Google provide their authentication system transparently. It is amazingly simple to setup authenticated sites/pages.
URL Fetch: points toward service oriented architecture. Without it, making services and calling them would not be possible.
Other useful stuff like Mail, cache.
With such a list of libraries, one can easily imagine the server side of future apps for Android running on AppEngine.
The way code updates are pushed to the google servers is a bit reminiscent of Java web application deployment. However it is done with much finer granularity (file).
Overall I am happy with AppEngine. Yes it is similar to old PHP hosting, but it adds a lot of value by bringing few easy to use libraries, and natural integration with Google infrastructure. Compared to a PHP hosting, I think the biggest improvement is the database (dev use and admin use). For the dev it is integrated to the code. For the admin, it can be done transparently on the web. The most interesting is that it’s FREE.
Option, Futures and Other Derivatives is by far the most popular book in finance. You will find it in every finance company, on many desks.
It is a very good introduction for people not familiar with standard financial products. This kind of book is unavoidable to understand the basis. It goes also beyond with the chapters on pricing and hedging. These 2 chapters make one understand many other book. If one understands the Black and Scholze formula, one can easily approach many other pricing formula, as in a way, there are all similar in their approach.
If one has to learn about equity derivatives, beside the classic Option, Futures and Other Derivatives from Hull, Structured Equity Derivatives by Harry M Kat is a must read.
His ideas are presented in a software developer friendly way, as his goal is to show how different equity derivatives products are behind the scenes, very similar.
I enjoyed the variety of exotic products presented and the very detailed way in which they are explained
The book is filled up with graphs, which is a good thing. While browsing the book for the first time, I did not really grasp those graphs well. But after having read it, they do make sense and help visualize what’s happening. With those graphs, volatility and other parameters don’t look only like abstract variables in a formula.