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.
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
- 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.
I have read Going Postal with great enjoyment, in fact, I just finished listening to it on the way back from JAOO.
I also got several other books as well, but I have yet to open them at all, since that one has all but capture all my attention.
We will see how fast I can go through that.
P.S: I noticed that I speak a lot more about other interests lately beside technology and programming, does it bother you?
James Oliver Rigney, Jr.
October 17, 1948 - September 16, 2007
Okay, I am in shock.
Robert Jordan is one of the main reasons that I have even minor fluency in English at all, he is responsible for a lot of inspiration and the name "Ayende Rahien" is taken from his books.
I spent many enjoyable hours reading and re-reading and re-reading his books, and I have spent many pleasurable moments arguing semantics and plot twists with other members of the community.
I never knew the man, but he sure did influenced me greatly.
To steal from him, this is the only thing that I can recall of the Old Tongue of the top of my head, which seems oddly appropriate.
Tia mi aven Moridin, isainde vadin
Damn, but that is a good book. A different style than most of the other ones, with a lot more investment in characters than in actions, but very good nonetheless. Highly recommended.
Finished it in one sitting, and already want more, but that would be out in 2008 :-(
It came out four days ago, and I can't believe that I let four days pass by without getting that.
Yes, it is that good.
I was just getting ready to listen to Black Powder War, the third part of this series, but with changing times comes changing plans.
Now I intend to read the ebook, hopefully this will take up the rest of the night only, and then listen to Black Powder War and then to Empire of Ivory as an audio book.
I don't have Throne of Jade as an audio book, the story was masterfully told, but I didn't like all the PITA politics that went there, too realistic and far too close to stuff that I had to deal with in the past, so I am skipping that.
I really enjoyed His Majesty Dragon as both an ebook and an audio book, however. I usually don't re-read books at those intervals, but Naomi is a very talented writer. And I am looking forward to that.
Right now I have finished listening to We Few from David Weber again (started on the flight, actually), and I am really wishing that this story had more books in it, there are at least two that I can think of.
Now I just need to get through some Brail bugs before I can dedicate myself to truly masterful story telling...
It starts with March Upcountry, which gets interesting in the first few minutes, rather than the usual longer opening of most books, proceed with March to the Sea and then to March to the Stars and finally to We Few, where the books (but not the story) ends.
You may have noticed that I didn't have much activity in the last week, that is because I spent most to all of my free time listening to those books. Excellent is too weak a word to describe them. Suffice to say that a quick calculations shows that out of 168 hours in a week, I spend over 70 hours listening to those books (and walking the dog till she dropped :- ).
Page turner is not quite the word to use for an audio book, but I can't think of an appropriate term to use for them.
The story is good, very believable, highly consistent, great characters, a lot of depth, great pace, a lot of action, and a sense of a full world behind the story. It is also a story that has managed to make me forget the real world for more than a few times.
I have just finished listening to We Few, and the only think that I can think right now is how to get the next book in the series, which apparently doesn't exists (extremely disturbing, since I really want to know what comes next).
I am usually on the side of fantasy when it comes to reading, but this has certainly convinced me to go back to hard core SF. So if you like SF, and if you have better self control than I am, I can strongly recommend these books.
Update: Apparently the first two books can be gotten (legally) freely from the net. Part of Baen's Free Library:
I had plans for this weekend. I really did. But it is not 05:35AM and for the second day in a row, I am watching dawn raise and feeling very annoyed at myself. Yesterday I started to listen to the March Upcountry audio book. Just to give you an impression, it is a 17 hours audio book, and I have just now finished it. Yes, this does mean that I spent most of the last to days listening to it. Luckily I am able to do other tasks while listening (mechanical only, nothing that requires concentration or beyond-reflexes thinking).
To say it is intense is like saying that water are wet. I really love the style, and the narration is excellent. The story itself is very good, extremely detailed and believable and I simply love the characters. I am really pissed that the book ended in a cliff hanger, and as I am in the process of downloading the second book in the series right now, I woudl be seriously considering starting to listen to it right now, if I didn't have about an hour to wait for it to get down.
As a side result of this, I am on an Email Strike, which means that I am only giving cursory look in my inbox, which has ~70 unread conversations.
I have just finished listening on this book:
Extremely entertaining. I really liked it as a real book, and as an audio book, I could hardly let it go. I have also listened to The Light Fantastic for Prachett, which was also good. I am now getting Soldier of the Legion, which sounds like it should be fun.
Any good recommendations for audio books? SF / Fantasy are my forte, for your information...
Time and time again, Working Effective with Legacy Code comes up in conversations that I have with like minded fellows. It is a very good guide to working with code, not necessarily legacy one. I have read it a few years ago, and have been vastly impressed, to quote myself:
Working Effectively with Legacy Code is a book that should be a mandatory reading for anyone who is interested in coding for a living.
I consider this book the #1 reason for the existence of Rhino Mocks, and I can't really recommend it heartily enough.
If you haven't read it yet, go and get it.
That and Evans' DDD are on my list of books to re-read, but I am saving that for when I need a serious productively boost. That is one hell of a book to set me off writing good code.
A book about ANTLR is something that I have long lusted after. It is something that I keep planning to learn, but the learning curve is too high to do this informally. Looks like I am getting my wish, The Definitive ANTLR Reference is in beta book now.
ANTLR is a compiler compiler, which makes it a great tool to write languages (Boo's parser is written in ANTLR, for instance). And although I would generally use Boo for DSL, it is important to me to understand the parser as well.
Programming WCF Services
Let us start with the conclusion, I don't like this book.
I am sorry, forget that I said that. Below is my first impression of the book, and I still stand by it, it is not a book you want to learn WCF from. It is a book that you want to at least go through, and keep as a reference if you are working with WCF in any but the most trivial of manners. This change in opinion was caused by needing to do something in WCF that I thought was possible, and finding the answer in a few minutes of searching in the book.
It is a very thorough discussion about WCF implementation, it probably has a lot of valuable information. The problem is that it is nearly impossible to understand this information, because it is presented outside of any context.
"Let me show me how you can turn the knob in all possible ways, but I'll not tell you why you should turn the knob, and what is on the other side."
The book contain a lot of details about WCF, some of which I am sure that will be of use in the future, but I have to say that it feels like it should be the third or fourth book that you read about WCF, after you already understand the way that it works and how you should implement it in your business scenarios.
It may be a great book if you are a framework developer who to better understand WCF, in a mid-level way, but even then, I would rather understand the way WCF works first, and then rely on web/reflector for the rest of it.
Let me give you an example, in many cases, the author chose to use such meaningful names as: "IMyContract1" or "IMyContract2" to demonstrate a technical point. That is nice, and if it was a textbook, requiring rote memorization, it may have been appropriate. The problem is that I expect books about such topics to give a meaning to the choices that they present, not just in the narrow technical terms, but with the broader design implications.
Other problems that I had with the book:
· In one particular instance, the author bothered to show me the definition of System.SerializableAttribute. Thanks, I already know that one…
· Each and every configuration sample is shown with both declarative XML and using C# code. I am not sure if the intent was to supplement MSDN, but I consider this a bad idea. I am capable of making the transition from XML to C# easily, and I can look in MSDN what this element map to, and vice versa.
· Another annoying issue is that the author spend a fair amount of time building a set of helper classes to work with WCF. I am not sure if this is a personal preference issue or not, but I am coming away with the feeling that WCF has very low usability if just about everything need to be wrapped in a helper class. This is valuable in the narrow sense that it shows me how I can do things, but it is not very useful in the long run.
· It keep mentioning static variables to preserve state in per-call services, which drives me crazy, since it is something that I consider a very bad practice (it mentions the complexity, but doesn't warn against it).
It may seems that I harp about the no context issue too much, but take into account what a database book would look like if all the examples were:
SELECT [Column1], [Column2] From [MySchema].[MyTable1]
Sure, it teaches the syntax, but it leave me with the burden of translating the pure technical details into a problem domain.
Who is this book useful to, then?
If you are tasked with building a complex WCF service and you already has a rough idea about what you need, you can use this book to pinpoint the technical details and understand how you can implement those. As a reference, it is going to be very useful, since it goes to a great depth into a lot of the details of WCF. Once you know what you need to do, it would be easier to correlate that to the technical requirements that you need to meet. Apparently it is not supposed to cover WCF in low level detail, which really scare me if this is true, because there are a lot of stuff that are covered in detail.
What I really like was the coverage of transactions, it was very thorough, and presented me with quite a bit to think about. Specifically, the use of Transactional<T> in a service to allow the service members to take part in a transaction is something that made me sit up and stare at the air for a while, thinking about all the possibilities that it can enable. Specifically, combining this support with NHibernate support may give me a fully transactional view of my entities, in both memory and database.
First, this is about how I feel at the moment. Except that I am not angry :-) My head does feel like it would overlow if I would move too fast. I would like to re-iterate my previous words, you really need to read this book. I got a lot of interesting tools from it, including some that I would really would like to try. I got something far more valuable as well, I got to cross off tools from my "to check someday" because the infromation in the book convinced me that either it is a good fit for me or completely against the way that I think.
I am going to drop the book on co-worker on Sunday, all 1,200 pages of it. I can't decide if I should tell him that the need to read it all before he can understand tha project or just point him at the relevant parts. It is going to be amusing either way :-)
That said, the book is not without mistakes, I noticed a couple that were mild annoyances to read, and it won't replace sitting and figuring out the tool / framework (at least, not if it is the least bit complex), but it can give you a pretty good idea about what you can expect from a tool, and if it cna match your needs.
Final thoughts: read it, but try to space it out a bit, I planned on doing some work today, instead I need to relax and have some time to assimilate all the new stuff.
Windows Developer Power Tools* is a huge book. It is so big that I can't hold it in one hand. It is so big that I need to put it someplace to read it. It is so big that I think that it should come with a warning label about possible serious injury if you are reading while tired.
It is also a hot recommendation from me if you are a developer on Windows. I believe that I am fairly proficent in the tools department, author of some (Rhino Mocks is in the book! :-D ) and have used many. Nevertheless, this book had me muttering "Oh, I gotta try that" in the first chapter. I am writing this post now on page 503, because I just had to stop when I realized how beautifuly NCoverExplorer can integrate into my builds.
To say that it is packed is a major understatement, but I consider this a great thing indeed. I probably could go and find all the information online, but having it all concentrated in one place is a huge deal, especially since each tool come with an explanation and usage that is often better than what you can find on the site. (Probably because the medium is not one where you can say "download this exe and start playing).
This book is going to serve dual purposes. First, it allows me to learn very quickly about a lot of tools that I can use. Second, this is something that I can give another developer, and tell them to look for the tools that we are using, thus helping them get up to speed with them.
This is something that you really should at least leaf through, and check what is avialable for your usage. The worst thing about this book is that I have to actively fight the urge to start using all those tools in my current projects. That would be an interesting manuevour, to say the least :-).
Best quote so far:
And here is some Google Love for the Windows Developer Power Tools site.
* Amusingly, Amazon list 140 tools, while the cover lists 170.
Just one question, what is this picture or?
Aside from that, I can say that Hibernate in Action is a the best for anyone developing NHibernate. With the advent of NHibernate in Action, it is going to be even easier (no need to mentally translate from Java and EJBs anymore).
I am looking forward to July 1th, when this book is coming out.
The question was brought up, and I had to find out what the behavior is under this conditions. Here is the test scenario:
Hashtable t = new Hashtable();
ManualResetEvent startAllAtOnce = new ManualResetEvent(true);
static void Main(string args)
Program p = new Program();
List<Thread> threads = new List<Thread>();
for (int i = 0; i < 50; i++)
Thread thread = new Thread(p.DoWork);
foreach (Thread thread in threads)
public void DoWork()
This method simulate a race condition, it is a very simple test case, if it throws an exception, the test is failing.
Right now, trying to run the code above will throw. Let us try something a bit more sophisticated.
public void DoWork()
The method has an attribute that tells the runtime that only one thread can execute this method (per instance, by the way). Now, what happens when you throw virtual methods into the mix? Let us try this:
class Derived : Program
public override void DoWork()
if (t.ContainsKey("aabc") == false)
Let us change the first line of Main to:
Program p = new Derived();
Now it throws. The synchronized option is not inherited. The most interesting part comes when you try to do this for across the hierarcy, where it also doesn't work (because it is using a different instance).
Just a little tibit that is interesting to know... This just went to the list of "Thing you are going to get asked if you tell me that you know .Net multi threading*".
* Asked meaning that you get Visual Stuido and ~10 minutes to figure it out.
Zero Friction Unit Testing has always been TestDrive.Net strongest point, but with this new release, it bring it to a whole new level.
I feel that some of the new features are made for me, take this one for instnace:
That one was a personal request of mine, and I am going to really worn this botton.
There is now integration with a host of new frameworks, from TypeMock to Zanebug. But this isn't something that make me happy. What does make me Happy is this, Reflector integration:
Do you see the value that this is going to bring? Just being able to (so very easily) setup breakpoints in any code that I want is a good idea, and being able to go from 3rd party call ot its source at the press of a key is really impressive. This is going to be a shortcut key the moment I can decide which functionality I need the least (Ctrl+X, Ctrl+C, Ctrl+V).
Great work, Jamie.
I can't figure out my own posting habits sometimes. I average on about 75 posts per month, but the actual post count vary pretty wildly. Last month I posted 54 posts through the month, the last two weeks I posted 55. This has to do with the amount of time that I spend at the office vs. the time that I spend at various client sites, I guess. I don't get a lot of posts from clients (at least not the kind that they would want me to air :-) ).
On the other hand, I did read a lot of good books in spetember...
Only occasionally I get to read a book that make go "Wow!", merely because the strength of the plot and the charm of the charaters. Scalzi creates a full fledge world (universe, actually) very quick, very easily and very convincingly.
The story reminded me strongly of Hienlien's Starship Troopers (although the only common plot idea is war among the stars). As someone who grew up on Hienlien's books, that is a high praise.
There are two other books in the same universe, and I'm looking forward to reading them...
His Majesty's Dragon (Temeraire, Book 1)
Throne of Jade (Temeraire, Book 2)
Black Powder War (Temeraire, Book 3)
As a testement to the quality of these book, I would like to mentioned that I read all three between firday 18:00 and sunday 05:30. I truely enjoy fantasy / science fiction / alternative history books, and this trilogy hits all the right spots.
The story takes place in the beginning of the 19th century, and tells of a world different than ours only by the existance of dragons. No magic, no mambo jumbo, just dragons. Of course, you can't say "just" dragons, and Naomi Novik does an excellent job in creating more than a story, but creating a full, living, breathing world.
I read quite a bit about that time in history (the Napolean Wars are the background for the books, by the way), and the way they are portraited in the books are very close to what really happened, and likely to stick with me more than the real history.
The dragons are fitted into the story with marvelous care, seamlessly woven into the fabric of the world. I liked the first book the most, since it had the most action, but the other two are very good as well.
The only half way annoying thing about the books is that the third one ends with a lot more stuff that I want to know about this world. How would the war end? Will the heroes be able to escape the clutches of the beauricrats, etc...
I surely hope that there is going to be more books in this world.
Couple of disclaimers before I continue:
- I got a free copy of this book to review.
- I am probably not in the intended audiance of the book.
Nearly a month and a half ago, I posted my initial impressions from this book, which were good (even if it didn't come out like that). It took me quite a bit more to read it than the usual, mainly because I was swamped with work.
Anyway, the book declares itself as a guide to develop sofware using DDD. In fact, it covers much more ground than that, including patterns, inversion of control, testing, high and low level design, and more.
The overall tone of the book is very... relaxed. It felt at times like I was reading a long blog post, which meant that I had no problem with reading it on/off for a long time. The material is presented in a very approachable way, including a lot of details and explanations about what is going on.
I particularly liked the side notes where there are critiques on the code, some from Jimmy and some from other reviewers (This approach had this and that disadvantages, but I am using it because of the following reasons..., etc).
The first part of the book is an introduction to the concepts that are used throughout the rest of the book, patterns, TDD, domain concepts, etc. This was mostly repeating stuff that I knew, but it is a point to Jimmy's point that he managed to present the material in a way that was interesting even when I already knew what he was talking about.
The second part is where I consider the meet and bone of this book, covering how to apply DDD. The general architecture that is presented is similar to what I consider as ideal at the moment, and close to what I am trying to build in several applications at the moment. This part also straighten out some concepts that I didn't quite manage to understand from Evan's DDD book. Specifically, the relationships between the domain model and services and how to use them. I got several good ideas from this part, and it is responsible for my NHibernate Query Generator.
What I didn't quite like is the 7th chapter, about business rules. Partly this is because I'm currently invovled in an effort to implement fairly complex business rules implementation, and I don't think that the approach presented can hold in the face of the more complex scenarios. (Think of a case where you got heirarchical rules that are time dependant executing over a domain model that is timing sensitive. If you said Yuck!, I agree ;-)).
The forth part is talks about persistance, how to prepare to it, and how to implment it using NHibernate. I mostly agree with what was preseneted, and I was very surprised to learn new (and exciting) stuff about NHibernate (did you know that the mapping can declare Assembly and Namespace attribute seperatedly?).
The last part talks about moving the design forward, and how to take the domain design into the UI layer, and give the users a chance to take advantage of that as well.
What I didn't like:
Jimmy tries hard not to fall into the trap of using a specific product to show the concepts he is talking about. While it is a good approach in general, I felt at times that he is attempting it too hard. It might have been preferable to show the concepts using a certain tool, and mentioning how other products are solving similar problems.
There isn't any real refinement of the domain model as a result of new requirements or better understand of the client's model. The changes presented were changes mostly driven by technical decisions, not different way to understand the model.
Evans' DDD book made use of the shipping industry, with the difference being changing from focus on moving the cargo around, to moving the legal responsability for the cargo. I didn't see any such example in the book, and this is a core part of DDD.
I don't think that the title is doing the book justice. It is not nearly about DDD as about the whole approach to develop applications.
I tried to pinpoint who exactly will not benefit from this book, and I couldn't quite put my finger on it. If you are currently busy building application based on Evans' DDD, with full usage of TDD and are familiar with Fowler's Patterns of Enterprise Applications, you will probably not get much out of this book.
If you are a "standard" .Net developer, and by that I mean that you mainly used Microsoft's prescribed tools and practices*, you will get quite a bit of insight from reading the book. I intentionally do not limit this to intermediate (whatever that means) developers, since it is more about a shift in thinking than about the level of code required.
I am certainly going to circulate this book to other developers in my team.
Great job, Jimmy.
* And I don't need to tell you what I think about most of them, do I?