Currently listening the By Schism Reapt Asunder

The hero ask a computer to find anomalies between two sets of records. Specifically, finding records of people who are assigned to different to several enclaves at the same time.

The quote that annoyed me was:

OWL was a fast computer, and it only took him two minutes to find the answer, even though there were millions of people in those records.

I just winced hearing that, I felt like shouting, that is not the way it works at all.

Here is the deal, I got the book shipped to me, and I am currently buying the audio book. Yes, I expect it to be that good.

Don't expect to hear much from me in the near future...

SciFi Inflation is the best term that I can use for this book series. It was engaging enough for me to go through all three books, but it bothered me enough to put a negative post about it.

Just about anything in those books is over-inflated. Interstellar travel times are measured in minutes, thousands of sentient races exists, sensors that can read the details of a ship from thirty light years away, an interstellar power has 300 million ships, etc.

This is like nails on board, highly disturbing for the flow of the story. And the story is good, it is just that those are beyond "wavehand physics away", I expect that. But I expect that to be done in a believable way.

Case in point, at one time the ship just blew up a few other ships, and it was hit with a bit of debris. The command that the Captain gibes? "Pilot, takes us half a light year out, I want to have a little time to respond if something like that happen again."

Does the author have any idea about how big a light year is?

Urgh!

I really wish I got this yesterday...

In my absence, some evil person has re-arrange my library. Apparently having the books strewn on the floor is not cool, although it make them very accessible.

Since I can actually see all the books now, I thought it would be interesting to list some of the good technical books that I have read. As usual, it is without any particular order, with the only qualification is that reading this book literally changed the way I think about software development.

• Domain Driven Design - Evans:
  This is a very dry book, but it contains a lot of valuable information. I am not sure if I am at the point where I can really make effective use of DDD, but it certainly change the way I am approaching software.
• The C++ Programing Language - Stroustrup:
  If you know C++, you are more or less required to read it, and if you don't, learn C++ and then read it. This book is full of concepts that was very new to me when I read them. It is less useful for me now, but I still believe that you need to have some C++ background to be a good programmer. Until you haven't wrote your own string class you wouldn't understand what the whole fuss it about.
• Patterns of Enterprise Applications - Fowler:
  I read this one at about the same time I was digging into NHibernate. It made a lot of sense of NHibernate's code, and at the same time, convinced me that there is no real reason to reimplement those patterns. (One of the reasons that I am a bit scared when someone mention design patterns).
• Working Effectively with Legacy Code - Feathers:
  If you have not read it, go and do so. This book is directly responsible for the creation of Rhino Mocks, and it has affected my thinking very deeply. I am applying the same techniques for all code. I have found that it significantly increase my ability to work with complex software.
• Operating Systems Concepts - The dinosaur book:
  Again, you really need to read this to be able to do effective in this field. Even if you and the metals are so far away that you need a satellite link to talk to it, you have to understand what is going on. Understanding thread scheduling, interrupts, memory management and its association to the file system, paging and reclamation policies are critical to our ability to figure out how to approach a problem.
• Modern Operating Systems - Tanenbaum:
  Similar to the previous book, but give a lower level at some points. I read it about the same time I read Operating System Concepts, and it was very helpful to have two point of view on some things.
• Operating Systems - Design and Implementation - Tanenbaum:
  The Minix book, I think of it. Similar to the last two, but with a greater focus of actual code, rather than abstract concepts.
• Practical file system design - Giampaolo (available as PDF):
  This is a really interesting book. It focus on a relatively narrow subject, but it is full of interesting tidbits, history, education, constraints and fun. Highly recommended.
• In Search of Stupidity - Chapman:
  This is not a technical book per-se, but it is a great book to understand failures in the industry. It is hilarious as well.
• Programming Erlang - Armstrong:
  Go and read this book. The language itself is interesting, but it is the concepts that you will be exposed during this book that makes this really fascinating.
• Virtual Machine Design and Implementation - Blunder:
  This is not such a  good book, but it did ensure that I will get an appreciation for the complexities involved in some tasks. This is a book that shows how easy it is to create a virtual machine. And it very easy indeed. (well, until you have to make guarantees about threading models and memory, need to provide hooks for JITing, debugging and profiling, etc. But the basic stuff is very simple.
• Release It - Nygard:
  I talked about this book extensively lately. You really want to read it to get an appreciation about how much better you can take your application's production readiness.

I have a lot more books that I have read, but non of them has really changed the way that I think about software.

Looking at this list, a couple of interesting things come up:

• No specific technology books. Stroustrup is arguably about C++, but I consider this a foundation book.
• No agile books - most of my thinking in agile related topics was from blogs / conversations / experience, rather than from books.
• A lot of low level topics.

I'll leave the interpretation to the reader.

Well, this is a big moment. My book is now available for as part of the Manning Early Access Program.

Chapter 1 to 4 are already there, but they are there in their nearly raw format. That means that they have not been edited yet, and I didn't put in the results from the review cycle that we did yet.

The book forum is here, I eagerly awaits the posts telling me how off base I am :-)

More seriously, I would appreciate any feedback that you have on the book, the topic, the code, etc.

Thanks,

  ~Ayende

Following Ted Neward's recommendation, I got Michael Nygard's Release It!  it was worth it!

It is rare to see a live blog from a book, but what the hell. I read this in about 8 hours, and I can't recommend it enough.

I am currently at chapter 5, but I had to stop and think about all the stability anti patterns that Chapter 4 has. More specifically, I had to think about all the stability anti patterns that I have put in my own code. The only thing that actually happened to me in production was an Unbounded Result Set, which had some nasty affects on performance, but not critically so.

But as I am reading the stability anti patterns list, I am seeing more and more things that I am doing wrong. At least, they are wrong if I want to scale in a stable manner. It is another argument for the the simplest way ain't the right way approach.

There are a few books that I can think of that caused a fundamental change in the way that I am writing and designing software. But even at this point, I think that this is going to be one of them.

I love this quote: Hope is not a design method.

Data purging is a PITA. I run into issues with it just last week, we needed to remove unrelated data, and we didn't take into account how things are handled in the application, basically, we removed rows in an ordered collection, which cause it to fail.

I like the idea of a Test Harness, an application that simulate badly behaved network and integration points. Anyone is familiar with an existing one?

Evaluating SMS for async messaging platform: message brokers are usually implemented with carbon and have extremely high latency

Chapter 6 is interesting, it starts with explaining the "one in a million in next Tuesday" approach for unlikely issues. Astronomically unlikely coincidence happens every day.

Something that Michael keeps repeating is that sessions are the bane of stability & capacity, this is interesting. Even more interesting is real world experience of putting big sites out there, and what kind of environment they have to face. Specifically, the description of the unexpected access and the results from that are enlightening. It looks like you need to do some really nasty things in your QA environment, just to get things slightly like what they are for production. Interesting problem.

Something that I can't really make myself believe is requiring over a thousand database transactions to render the home page.

Another good quote: A million dollars will pay for a lot of profiling and optimization in the application stack...

Section 9.7 talks about the dangers of bypassing the OR/M layer for direct DB access because they can kill the site capacity, I wholly approve. The SQL that most OR/M tools generate is predictable, so it is very easy to optimize for that. Another important thing is that you need to develop against realistic data set. This usually mean building a data generator to spit some data at the DB.

Connection pooling is another strong theme in the book, which make me wonder. The CLR has both a thread pool and a connection pool, but they are on the background, I have needed to meddle with the thread pool in the past, but not with the connection pool. And I have heard very little about connection pools in .NET, while on the Java side, there seems to be one per project, I wonder why? It is that the default pool does enough to handle most scenarios that it is not necessary to do it?

I didn't know that Java had object pools, that sounds... weird. Especially if someone used the statement "creating an object is the second most expensive thing you can do" (the first being creating a thread). That is certainly not the case now, and I find it hard to believe that it was true then.

 Blamestorming <- I love this term.

Michael is certainly mentioning Akami quite a bit.

On Chapter 14 now, talking about administration. That and transparency are two things that I am very interested to learn more about. He mentions the use of cmdline apps that allows to write admin scripts against the application, as well as startup verification and the ability to interrogate a funked server. Both are interesting.

I have been thinking about including a boo interpreter in my project, so I could login to the application and directly "debug" it. I wonder how this can work for real. This would certainly allow me to access everything in the application, live.

Configuration, and the importance of separating internal configuration (IoC settings) and application settings (database names), was mentioned, including the necessity to make the configuration understandable to the admin. He mentioned the problem of distributing configuration across multiply hosts, I wonder why not use a well known configuration service for that.

There is a really good description about how they were able to get a system working by basically going in and setting properties on live instances. So I guess the idea of an interpreter isn't that weird. There even a name for it, Recovery Oriented Computing.

Another good quote: Last week is history only in IT and high fashion.

A startling number of business-level issues can be traced back to batch jobs failing invisibly for 33 days straight.

Ouch! Ouch! Ouch! Been there, done that, ouch!

Log file readability: Yes! Yes! Yes! Especially when the only interface into the system is the log file! Some good points how to make a log file readable, and good message logging.

I like the discussion on superstitions as a survival trait.

It seems that scriptability of a live application is a big thing in the Java space, with JMX being the standard way to do that. We don't have anything like that for .NET, but I think that it should be simple enough to wire something up with Windsor and IRemoteQuackFu :-)

Another alternative to Boo would be PowerShell, which admins are supposedly familiar with.

On chapter 18, adaptation. I would call it maintainability, but I think it is the same thing.

I like the view on integration databases:

Integration databases - don’t do it! Seriously! Not even with views. Not even with stored procedures. Take it up a level, and wrap a web service
around the database. Then make the web service redundant and accessed through a virtual IP. ... That’s an enterprise integration technology. Reaching into another system’s database is just...icky.

I have been saying much the same thing for a long while now. Very icky indeed.

The description of zero downtime deployment reminded me of the Erlang talk in JAOO, you have no consistent state, and you must deal with this.

Final thought, design for production, not for QA

Go and read this book, you really need it.

I am toying with this DSL:

recieve:
	message msg as ChangeAddressMessage if msg.AddressId is null:
		transaction:
			address = Address.FromMessage(msg)
			address.Create()		
	message msg as ChangeAddressMessage:
		transaction:
			address = LoadAddress(msg.AddressId)
			Address.FromMessage(address, msg)
			address.Save()
	message other:
		raise MessageNotUnderstood()

What book am I reading now?

I know that I am asking the question from a self-selecting group, but what the hell.

I am considering the idea of writing a book about writing domain specific languages, with Boo as the implementation language. This has two distinct topics:

• Theoretical knowledge:
• DSL Usages
• How to create the syntax
• How to integrate into an application
• Testing
• Versioning
• Patterns
• Implementation strategy - how to actually build a useful DSL that can do all of the above using Boo.

I certainly like the subject, but I wanted to know what you think about it.

Do you find the idea useful? Is there enough interest in it? Do you (or people you know) use DSLs for work/fun? Any other comment?

I have no idea how he does it, but Terry Prachett is so consistently funny, amusing and a very good writer.

Making Money is a continuation to the Going Postal book, with the main hero being Moist, again thrust into an unwilling job description, and raising to the occasion.

It was both hilarious and a good read, two distinct qualities, but Prachett is combining them masterfully. Highly recommended, and more than worth a second read, which I need to make time to.

There is also the shred of a promise to have Moist as the tax collector for the city, which would make for an interesting story, considering he is a thief.