I blogged recently about Karl Seguin’s free eBook titled Foundations of Programming. I took some time recently to give it a read and wanted to share a few thoughts about this fundamental book. 
I have to say it was well worth the time, I was pleasantly surprised how well laid out each chapter was and the depth of the content. This book is perfectly suited toward those developers curious what ALT.NET is, the tools used by the ALT.NET crowd or just simply a solid foundation for software development today. The first chapter goes into what ALT.NET is, the goals and the future which should clear up any confusion by people first hearing the term.
Readers learn definitions of many words tossed about by ALT.NET folks such as:
- DRY (Don’t Repeat Yourself)
- Explicitness and Cohesion
- Coupling
- Unit Tests and Continuous Integration
Organization
Each chapter hits on each hot topic in software engineering and the ALT.NET crowd:
- Domain Driven Design
- Persistence
- Dependency Injection
- Unit Testing
- Object Relational Mappers
Other chapters include:
- Back to Basics : Memory
- Back to Basics : Exception Handling
- Back to Basics : Proxy This and Proxy That
The “Back to Basics” chapters do a great job on topics we often take for granted or as an afterthought.
Domain Driven Design
A very concise definition and clear examples are included to give readers an understanding of what Domain Driven Design is and how to relate it to a real world example. The example used is for a car dealership which we can all relate to and understand.
The examples used are simple but really get the points across as Domain Modeling principles are explained. Karl also contrasts the differing approaches design by Microsoft which is a very Data Driven approach to the ALT.NET way, which is Domain Driven. It is interesting to see this put in writing.
Also pointed out are the key roles in a successful domain driven project, the users, clients and stakeholders. This is often left out of too many text and a great point to make to make us understand who this is really for in the end.
Key topics covered:
- Factory Pattern
- Access Modifiers
- Interfaces
- Information Hiding and Encapsulation
Persistence
As the book progresses from this point the topics get more into the technical side of the discussion with particular development tools chosen. Karl points out specific tools he recommends but others are perfectly acceptable substitutions.
Persistence is demonstrated by the use of a manual set of data mapped classes and goes through the process to show how it all works. As various problems arise they are addressed and fixed. In the end a manual approach is advised against because the developer spends too much time writing code which is useless to the client.
Key topics covered:
- Data Mapper
- Object-Relational Impedance Mismatch
Dependency Injection
A very healthy discussion of Dependency Injection (DI) is covered in this book, from the very basic concepts of DI to a handcrafted implementation. The author points out that DI can be done manually in simple situations but can get unruly in complex situations. The DI framework, StructureMap is discussed and used in examples to help solidify the ideas.
It is really great to see recommendations for frameworks and tools that already exist and leveraging those tools. The examples in this chapter which start out with creating a manual DI implementation build on the car example from previous chapters. The car example is use also to show integration of StructureMap into the project.
Key topics covered:
- Coupling
- Constructor Injection
Unit Testing
Unit Testing is a part of software development which is very important today. Karl talks about all the reasons companies and individuals do not create unit tests. It is pointed out just how important unit testing your code really is and the savings in the long run to the overall project cost.
A good job is done explaining why we need to unit test and the tools needed to start testing. More than one framework is discussed but the examples use nUnit.
A sufficient level of detail is given to describe how granular to make tests including proper naming and the scope of your tests. This chapter seems to have the most opinion and passion about any topic in the book, it’s clear Karl cares very much about the subject.
Key topics covered:
- What is a Unit Test
- Mocking
- Test Driven Development (TDD)
Object Relational Mappers
The topic of Object Relational Mapping (OR/M) was covered a bit in the Persistence section but it is not until this chapter we see what tools to use. Karl chooses NHibernate as the framework used to explain these concepts.
The ideas many developers use for a Data Access Layer (DAL) are often hard to throw out, as he explains his own doubts with using an OR/M instead of something that has worked so well. I think this is often the case with anyone adopting an OR/M and tossing aside those manually created DAL libraries using stored procedures. I know this is the case for me as I start using NHibernate, with concerns of inline SQL performance and scalability.
Karl does a really good job of explaining how to get NHibernate up and running and putting it into use in the ongoing code sample. NHibernate is exercised nicely in this chapter showing examples of querying, relationships, lazy loading.
Key topics covered:
- Inline SQL vs. Stored Procedures
- NHibernate
- Lazy Loading
Back to Basics : Memory
Developers today writing code for .NET should feel privileged to not have to worry about memory allocation and de-allocation we C/C++ programmers had to deal with on a daily basis. Although .NET developers don’t have to keep memory allocation in the front of their mind Karl does cover the basics of Stack and Heap, how each is used and why they are important to be aware of while writing your applications. To me this was one of the best chapters to help out a developer to fine-tune their knowledge which will help them go a very long way when trying to understand when something goes wrong.
Key topics covered:
- The Stack
- The Heap
- Pointers
- Boxing/Unboxing
- Passing by Reference
- Passing by Value
- Pinning
Back to Basics : Exception Handling
I have seen a lot of code written by other developers, both newbie and experienced, and one thing that I always find interesting is the way they implement their exception handling. I have seen such stark contrasts as catching all exceptions, regardless, to catching no exceptions.
In my opinion, the most important piece of information from this chapter is:
Your strategy for handling exceptions should consist of two golden rules:
- Only handle exceptions that y
ou can actually do something about, and- You can’t do anything about the vast majority of exceptions
Key topics covered:
- Cleanup using Try/Finally
- The mechanics of catching and throwing exceptions
- When to throw exceptions
- Creating custom exceptions
The topics were very basic but very essential. All of the golden rules of when to catch exceptions, acting on them and rethrowing them is covered. Each topic is covered in enough detail to give good understanding of the general use of exceptions and their power.
Back to Basics : Proxy This and Proxy That
This topic sort of confused me at first, wondering were the topic of proxies and using examples of proxy servers fit into the subject of software development but Karl was right on with the topic discussing what a proxy is, it’s use and power.
Much of the topic included examples of proxies for both lazy loading using NHibernate and object proxies in RhinoMocks.
Conclusion
I found a couple mistakes in the code presented in the book, but nothing any reader should not be able to work around. I highly recommend this book for anyone trying to come up to speed on the popular topics in today’s software engineering or anyone just wanting to understand the main points clearer. Keep in mind though, this is not meant to be an all-inclusive text on these subjects but a good starting point as a springboard to look further with a good starting point.
This is a great book focusing on the fundamental aspects of writing software today. To me it seemed much more than that, it reads more like an ALT.NET how-to guide. Much of the contents covers topics .NET developers hear about but may not get a chance to dive into each application. I think this applies to any developer wanting to get a better view of what “else” is out there.
I cannot say enough good things about what Karl has put into his ebook. I don’t know if it’s because I didn’t have to wade through 800 pages of rambling to get out the key pieces of information that was important to me or because Karl just knows what is important. Either way, it is worth a read regardless of your level of expertise.
I hope Karl continues to write some additional ebooks, maybe a few with more details of NHibernate, Unit Testing and Dependency Injection frameworks.
I thought the material was pretty good too, and passed it on to friends, but honestly, the book’s title put me off. I was expecting something more like Structure and Interpretation of Computer Programs, something about the -Foundations- of -Programming-. It’s really an Alt.Net/Agile primer. And a decent one, at that, but not what I expected.
I thought the material was pretty good too, and passed it on to friends, but honestly, the book’s title put me off. I was expecting something more like Structure and Interpretation of Computer Programs, something about the -Foundations- of -Programming-. It’s really an Alt.Net/Agile primer. And a decent one, at that, but not what I expected.
RE: Book Review : Foundations of Programming by Karl Seguin
Pingback from Books and Magazines Blog » Archive » Book Review : Foundations of Programming by Karl Seguin
RE: Book Review : Foundations of Programming by Karl Seguin
Pingback from Books and Magazines Blog » Archive » Book Review : Foundations of Programming by Karl Seguin
RE: Book Review : Foundations of Programming by Karl Seguin
The relative hype around the Foundation ebook has been pretty fun. Today I noticed a very detailed (and
RE: Book Review : Foundations of Programming by Karl Seguin
The relative hype around the Foundation ebook has been pretty fun. Today I noticed a very detailed (and
RE: Book Review : Foundations of Programming by Karl Seguin
The relative hype around the Foundation ebook has been pretty fun. Today I noticed a very detailed (and
RE: Book Review : Foundations of Programming by Karl Seguin
The relative hype around the Foundation ebook has been pretty fun. Today I noticed a very detailed (and
Couple of things:
First, it’s has a lot of good information, but in general I think your coming across wrong (which I’ll get into) and distracts from the ‘good’ parts and left a bad taste in my mouth.
Most of your goals in Chapter 1 are just general common sense goals of any decent programmer – certainly not just ALT.NET people…except maybe delaying coding – not sure if I’d agree with that – maybe because it’s never been a problem.
Microsoft has plenty of white papers out there on proper design and good practices.
Your differences in definitions between domain driven and data driven are paper thin…in all honestly I don’t see any separation in this article. They both smell like (reek of) ‘ERD driven’ to me…I’d try to give some better concrete differences if you can (without using technological implementations).
‘…is that Microsoft disproportionately favors data driven design despite the fact that it doesn?t fit well with what most .NET developers are doing (enterprise development), and, when improperly used, results in less maintainable code.’
– And most pro-Java developers favor following patterns as a rigid set of rules finding programming a mathematical process rather than an art and denounce anything that doesn’t have Fowler’s seal of approval and when improperly used in DDD with ORM tools using DI/IoC/Active Record, results in buggy less maintainable code.
Statements like that are pretty inflammatory huh?
‘…influenced by some of the best Java projects/concepts (known as ALT.NET)’ – and that’s what scares me. People haven’t exactly been dying to go back to Java (at least the ex-Java developers I associate with) – now I have seen a lot of people who ‘can’t just let go’, but this is another story. This is the equivalent of saying that we should follow best practices of FORTRAN.
Most of things you speak of about Agile are in other programming methodologies or have there roots in other methodologies. You make Agile out to be a silver bullet. I’ve seen plenty of Agile project fall flat on there face.
In general this is more of an advertisement for ALT.NET, DI and ORM tools and a nose snub at anything that isn’t. It also comes across very arrogant and dismissive of anything else. I’ve heard the ALT.NET community is a bunch of snobs…so this may be why I’m hearing it; which is a shame because there is several good things in here (if you can get past the advertisements for ORM tools and Microsoft bashing). Reminds me of why I disliked most Java programmers when there use to be a lot more of them.
But hey…I’m just one guy; what do I know.
Couple of things:
First, it’s has a lot of good information, but in general I think your coming across wrong (which I’ll get into) and distracts from the ‘good’ parts and left a bad taste in my mouth.
Most of your goals in Chapter 1 are just general common sense goals of any decent programmer – certainly not just ALT.NET people…except maybe delaying coding – not sure if I’d agree with that – maybe because it’s never been a problem.
Microsoft has plenty of white papers out there on proper design and good practices.
Your differences in definitions between domain driven and data driven are paper thin…in all honestly I don’t see any separation in this article. They both smell like (reek of) ‘ERD driven’ to me…I’d try to give some better concrete differences if you can (without using technological implementations).
‘…is that Microsoft disproportionately favors data driven design despite the fact that it doesn?t fit well with what most .NET developers are doing (enterprise development), and, when improperly used, results in less maintainable code.’
– And most pro-Java developers favor following patterns as a rigid set of rules finding programming a mathematical process rather than an art and denounce anything that doesn’t have Fowler’s seal of approval and when improperly used in DDD with ORM tools using DI/IoC/Active Record, results in buggy less maintainable code.
Statements like that are pretty inflammatory huh?
‘…influenced by some of the best Java projects/concepts (known as ALT.NET)’ – and that’s what scares me. People haven’t exactly been dying to go back to Java (at least the ex-Java developers I associate with) – now I have seen a lot of people who ‘can’t just let go’, but this is another story. This is the equivalent of saying that we should follow best practices of FORTRAN.
Most of things you speak of about Agile are in other programming methodologies or have there roots in other methodologies. You make Agile out to be a silver bullet. I’ve seen plenty of Agile project fall flat on there face.
In general this is more of an advertisement for ALT.NET, DI and ORM tools and a nose snub at anything that isn’t. It also comes across very arrogant and dismissive of anything else. I’ve heard the ALT.NET community is a bunch of snobs…so this may be why I’m hearing it; which is a shame because there is several good things in here (if you can get past the advertisements for ORM tools and Microsoft bashing). Reminds me of why I disliked most Java programmers when there use to be a lot more of them.
But hey…I’m just one guy; what do I know.
@Rob:
Thanks for the kind review!
@Brian:
I wish you had posted this on my blog where it probably belongs. The only thing I think you’re right about is that the first chapter is fluff and somewhat inflammatory. It was written a long time ago before the idea of writing a book came to mind. I would have liked to have edited it thoroughly, but there’s a reality around an amateur writer creating a free ebook. Aside from that first chapter, the book isn’t about driving a wedge between "camps", but an sincere and honest attempt at adding tools to a developers toolbox. If you didn’t get past the 1st chapter, I can see how you might not have sensed that.
I think you’re completely wrong about the rest of the book. A whole chapter dedicated to Inversion of Control has to be a rarity in the .NET world. That might be changing now that Microsoft has an IoC tool.
Is a book about DataSets a snub at anything that isn’t DataSets? Can’t we try to show people what ORMs are and how to use them without it being an insult to every other method?
I’m puzzled by your frustration with this book and your inability to see the wealth of information it provides (actually, you didn’t say that, I guess you have a problem with the manner in which I provide it, which is a far more fair criticism).
I can’t say that I care if I’m being a dick, so I want to point out that if your the BufferOverrun Brian Johnson, I’ll blindly accuse you of being biased (you do have a stake in the Microsoft-Way after all, far more than I do in a non-Microsoft way), just like you blindly accuse me of being a snub.
I’ll also point out that you SELL a book about the fucking Zune for $14 on Amazon – which you co-wrote with 3 people. What’s wrong with you?!
@Rob:
Thanks for the kind review!
@Brian:
I wish you had posted this on my blog where it probably belongs. The only thing I think you’re right about is that the first chapter is fluff and somewhat inflammatory. It was written a long time ago before the idea of writing a book came to mind. I would have liked to have edited it thoroughly, but there’s a reality around an amateur writer creating a free ebook. Aside from that first chapter, the book isn’t about driving a wedge between "camps", but an sincere and honest attempt at adding tools to a developers toolbox. If you didn’t get past the 1st chapter, I can see how you might not have sensed that.
I think you’re completely wrong about the rest of the book. A whole chapter dedicated to Inversion of Control has to be a rarity in the .NET world. That might be changing now that Microsoft has an IoC tool.
Is a book about DataSets a snub at anything that isn’t DataSets? Can’t we try to show people what ORMs are and how to use them without it being an insult to every other method?
I’m puzzled by your frustration with this book and your inability to see the wealth of information it provides (actually, you didn’t say that, I guess you have a problem with the manner in which I provide it, which is a far more fair criticism).
I can’t say that I care if I’m being a dick, so I want to point out that if your the BufferOverrun Brian Johnson, I’ll blindly accuse you of being biased (you do have a stake in the Microsoft-Way after all, far more than I do in a non-Microsoft way), just like you blindly accuse me of being a snub.
I’ll also point out that you SELL a book about the fucking Zune for $14 on Amazon – which you co-wrote with 3 people. What’s wrong with you?!
LOL…
Nope…different guy…don’t own a Zune and definitely no buffer overruns. But thanks for the kind words anyway. 🙂
I’d say I’m as guilty of misinterpreting your book as my post was misinterpreted, from your response; the problem with the written word.
So first: *I did point out that there was a lot good information in my first paragraph* – I’m not denying you that nor did I say anything to the contrary; it’s just that the rest of the book came across wrong – and I’ll be fair and say it may be because of the first chapter eating away at me while I read the rest – but in all honesty I truly felt as if I was being *sold* something in many places rather than knowledge sharing – and again, let me point out that I did say there was a lot of good information in this and I agree with the knowledge part on just about everything.
Secondly, let me apologize for posting this in the wrong place; I had come across this through multiple links – feel free to delete because that was just being stupid user on my part. That’s a true *my bad* on that. So please, mock me, belittle me, treat me like crap, for that one.
Now be sure to know…if I ever came across a book solely dedicated to data sets, glorified them and made them out to be a silver bullet – yeah…I’d be all over that (btw, I’m not saying that’s what you did, lest I be misinterpreted). It’s in the delivery – when you compare two technologies you need to give hard numbers – not opinions. Prove to me that an application written by two equally talented and experienced developers will have more bugs (or is more prone to them) in the data driven dataset version than the DDD/DI/ORM version. Or that it easier to use one methodology incorrectly as it is the other? Or that one methodology is more prone to success. Or that one scales better than the other. You can’t right? There’s no numbers for that because there are too many variables to even try to compare. So now all you’re doing is starting a pissing contest. So just tell your reader about DDD/ORM and how it works. You can show what data-sets do and what DDD does side by side – but let the reader draw *their own conclusions.* Don’t waste time trying to sell people – let the product sell itself. It’s like when you’re competing with for a girl – the last way to win her is to say that the other guy is going to treat her bad and you’ll treat her better than anyone else.
Finally I never said Microsoft has put anything of meaning out on IoC – that comment was more directed to the reference that MSDN is only useful for API reference – a lot of people have spent a lot of time putting white papers that are ‘general knowledge’ on MSDN.
I’m sorry that I struck a sour note with you, I actually wasn’t trying to be a dick – admitidly I can see how being read by someone who doesn’t personally know me it could appear that way and I should proof-read better next time and keep my audience in mind; I was trying to write my thoughts on something that, again, for the fourth time, had good content, but surrounding content made that good content get lost in the weeds – I was struck by a condescending tone of alternate technologies/methodologies in certain places that detracted from the real knowledge that was there and I wanted to point that out.
Finally, I’m just one guy with a ‘good content but could use a better delivery’ review – I’d hate to see the ire the person who didn’t like your book at all would get. For the record, I’d actually recommend it to people as a good read for learning about DI/ORM and probably just say that I think it’s too opinionated at times, but still a good read. It’s like ‘The Inmates are Running the Asylum’ – great fundamental book for any developer – but he does get a little high on himself in places and little to preachy – still a great book though. Martin Fowler – absolute genius – but definitely can forget the real world at times and get too a
LOL…
Nope…different guy…don’t own a Zune and definitely no buffer overruns. But thanks for the kind words anyway. 🙂
I’d say I’m as guilty of misinterpreting your book as my post was misinterpreted, from your response; the problem with the written word.
So first: *I did point out that there was a lot good information in my first paragraph* – I’m not denying you that nor did I say anything to the contrary; it’s just that the rest of the book came across wrong – and I’ll be fair and say it may be because of the first chapter eating away at me while I read the rest – but in all honesty I truly felt as if I was being *sold* something in many places rather than knowledge sharing – and again, let me point out that I did say there was a lot of good information in this and I agree with the knowledge part on just about everything.
Secondly, let me apologize for posting this in the wrong place; I had come across this through multiple links – feel free to delete because that was just being stupid user on my part. That’s a true *my bad* on that. So please, mock me, belittle me, treat me like crap, for that one.
Now be sure to know…if I ever came across a book solely dedicated to data sets, glorified them and made them out to be a silver bullet – yeah…I’d be all over that (btw, I’m not saying that’s what you did, lest I be misinterpreted). It’s in the delivery – when you compare two technologies you need to give hard numbers – not opinions. Prove to me that an application written by two equally talented and experienced developers will have more bugs (or is more prone to them) in the data driven dataset version than the DDD/DI/ORM version. Or that it easier to use one methodology incorrectly as it is the other? Or that one methodology is more prone to success. Or that one scales better than the other. You can’t right? There’s no numbers for that because there are too many variables to even try to compare. So now all you’re doing is starting a pissing contest. So just tell your reader about DDD/ORM and how it works. You can show what data-sets do and what DDD does side by side – but let the reader draw *their own conclusions.* Don’t waste time trying to sell people – let the product sell itself. It’s like when you’re competing with for a girl – the last way to win her is to say that the other guy is going to treat her bad and you’ll treat her better than anyone else.
Finally I never said Microsoft has put anything of meaning out on IoC – that comment was more directed to the reference that MSDN is only useful for API reference – a lot of people have spent a lot of time putting white papers that are ‘general knowledge’ on MSDN.
I’m sorry that I struck a sour note with you, I actually wasn’t trying to be a dick – admitidly I can see how being read by someone who doesn’t personally know me it could appear that way and I should proof-read better next time and keep my audience in mind; I was trying to write my thoughts on something that, again, for the fourth time, had good content, but surrounding content made that good content get lost in the weeds – I was struck by a condescending tone of alternate technologies/methodologies in certain places that detracted from the real knowledge that was there and I wanted to point that out.
Finally, I’m just one guy with a ‘good content but could use a better delivery’ review – I’d hate to see the ire the person who didn’t like your book at all would get. For the record, I’d actually recommend it to people as a good read for learning about DI/ORM and probably just say that I think it’s too opinionated at times, but still a good read. It’s like ‘The Inmates are Running the Asylum’ – great fundamental book for any developer – but he does get a little high on himself in places and little to preachy – still a great book though. Martin Fowler – absolute genius – but definitely can forget the real world at times and get too a
‘and get too academic at times.’
– obviously too long of a post…sorry…I ramble.
The rest:
Everyone can be critical – take the good, throw out the bad – but don’t take it personally – too many people in this world and life’s too short for that. You know the saying…opinions are like…
‘and get too academic at times.’
– obviously too long of a post…sorry…I ramble.
The rest:
Everyone can be critical – take the good, throw out the bad – but don’t take it personally – too many people in this world and life’s too short for that. You know the saying…opinions are like…
@Brian:
LOL…sorry about the mistaken identity. I was having a *really* hard time accepting criticism from someone who wrote a For Dummies on the Zune. I was pretty pissed. (which now I think is pretty damn funny)
I appreciate your feedback, and I appreciate your second post giving more detailed feedback. It’s so hard to give empirical evidence of the superiority of one method versus another since so many factors come into play (team experience, type of projects, driving goals, and the list goes on and on). But your point is well taken that the entire book could have benefited from less subjectivity and more objectivity.
And for the record, I’ve written articles for MSDN too!
@Brian:
LOL…sorry about the mistaken identity. I was having a *really* hard time accepting criticism from someone who wrote a For Dummies on the Zune. I was pretty pissed. (which now I think is pretty damn funny)
I appreciate your feedback, and I appreciate your second post giving more detailed feedback. It’s so hard to give empirical evidence of the superiority of one method versus another since so many factors come into play (team experience, type of projects, driving goals, and the list goes on and on). But your point is well taken that the entire book could have benefited from less subjectivity and more objectivity.
And for the record, I’ve written articles for MSDN too!
I love when everybody is happy 🙂 And now that I know about the ‘dummies’ book (that’s really needed???) – I can see the frustration and humor in it.
We’ll have a laugh over a beer sometime on it.
I love when everybody is happy 🙂 And now that I know about the ‘dummies’ book (that’s really needed???) – I can see the frustration and humor in it.
We’ll have a laugh over a beer sometime on it.
@Brian and @Karl, thank you so much for these great comments. I enjoy the banter from those who follow ALT.NET and those that don’t, always great things to think about.
@Brian and @Karl, thank you so much for these great comments. I enjoy the banter from those who follow ALT.NET and those that don’t, always great things to think about.
@dan – I was suprised too by the title of the book and then a bit differing content, but I was really happy to find what really was in there. If this was a basic book of fundamental algorithms and such I probably would not have done a review and pointed it out.
@dan – I was suprised too by the title of the book and then a bit differing content, but I was really happy to find what really was in there. If this was a basic book of fundamental algorithms and such I probably would not have done a review and pointed it out.