What could be more boring than mathematical equations? The majority of folks would be hard pressed to find something to answer that hypothetical query. Myself included I'll be honest, I'm a math minor and I picked up this book on a whim in a bookstore thinking to myself "Now why would anyone want to write or buy a book on 17 equations?" I flipped through it and immediately knew that I had to consume the rest of this book.
What Stewart is able to do is to take these 17 equations that manifest in everything we do, everything we observe, everything bit of space around us and bring life to them. He presents the opening of each chapter with a concise summary of these equations that helps immensely in revealing the underlying nature of the equations and then goes into the history of the creation (discovery?) of each of these equations and it's been an eye-opening read.
As an example, having majored in computer science, I worked constantly with logarithms and natural logs (there's lumber joke here somewhere) but never once understood the nature of logarithms. How did they come about? Why do they exist? What problem do they address? Just what in the heck is a logarithm? I knew them only in the abstract -- as operations that yielded a result; I knew them as a general pattern but not the nature of the logarithm. The second chapter simply blew me away with the clarity and simplicity with which Stewart was able to pull back the covers on what logarithms actually mean. No one in my years of formal education had bothered to explain it in the same way that Stewart does in this book.
While I cannot say that this book is for everyone, I will say that I find it is surprisingly approachable for most folks who are scientifically or mathematically inclined. Certainly, there are many equations and plenty of mathematics (and it gets especially complex (pun intended in the later chapters. However, I think this book is still immensely readable and approachable, even for those who have never ventured deep into the vast field of mathematics or have long moved past their days of calculus, linear algebra, and so on. I, for one, will make sure that my daughter reads the chapter on logarithms as it starts to seep into her curriculum one day to make sure she understands the "why" and so that she has an appreciation for all of the history and magic behind that little "log n" button on her calculator.
This book is incredibly well written, well presented such that it is approachable for a large audience, an entertaining read, and highly recommended. If you've read this review to this point, you should probably just go ahead and by this book!
I've been working my way through Sahil Malik's Microsoft SharePoint 2010: Building Solutions for SharePoint 2010 and I'm almost finished now. Just a quick review for anyone working on ramping up on 2010 or considering this book.
First, this book is good. I would recommend it without question to developers who are working on the SharePoint platform. Sahil Malik covers many of the new features as well as goes over some of the basics in a practical, mostly easy to read manner; there's practical advice in every chapter that you'll want to highlight and tuck away in your brain.
However, it's pretty apparent that the book was rushed (at least editorially) due to the large number of grammar mistakes, awkward sentences, terrible analogies (some of them a bit inappropriate in any textbook), and somewhat questionable structure of the content.
Again, Sahil does a good job of capturing a lot of the key changes in 2010 and gives good examples (chapter 5 being the most interesting to me, personally). If I were grading on content alone, the book would be closer to 5 stars. It's the editing team at Apress that have let down Mr. Malik by not putting enough attention in properly structuring and organizing the content and not performing adequate proofreading. I feel that many of the concepts and ideas could have been organized a bit differently and more coherently to help the reader better link the concepts together and have a clearer path to ramping up. It may have helped if the book had a more focused target audience (Mr. Malik himself points out that the book is broad in nature).
That said, as I mentioned in the opening of the review, I would definitely recommend this for SharePoint developers who are transitioning or preparing to transition from 2007. Despite it's flaws, it's still worthy of the time and money that you'll invest in it. I do wish that the author had gone into more detail regarding best practices and design patterns for developing solutions in SharePoint; this is an area that is sorely missing in terms of publications. Mr. Malik might have made the book even better by incorporating the different examples around a central solution or problem instead of the scattershot approach of one-off examples. In other words, his examples (in a book with "Building Solutions" in the title) would have been better served in the context of a more comprehensive, overarching example.
Update: Finished the book. A copy of the email I sent out to the folks in our practice:
Malik's book is worth the time to work through. I'd recommend it for all of the devs here. It provides good coverage of the most important topics in 2010 and is very readable (suffering somewhat from poor editors at Apress and questionable organization of data). Chapter 5 (client object model), 8 (ECM), 9 (BCS), 10 (Workflow), and 11 (BI) all demonstrate some of the core new features in 2010 and should be required reading for any dev. or architect. Chapter 3 covers some of the core restrictions of the new sandboxed solutions model. It's an important new feature, but it's equally important to understand the walls that are thrown up when using this model.
The book is generally light on code and, in most of the later chapters, covers how tasks can be accomplished from SharePoint Designer as well as from Visual Studio. It doesn't really go into development practices and things like building custom content type forms and so on. It doesn't cover building applications for the new services infrastructure. Again, it's light on code and should be readable by non-devs as well.
It's short by tech book standards, so it is understandably lacking a bit in depth. For example, some of the BI features in chapter 11 are really, really killer, but Malik doesn't dive into the technical details (one example would be the new REST APIs for Excel Services which are supremely powerful, but Malik only gives a few examples without details for the API). The BCS chapter (9) is also light and could have used much more meat since it covers the 80% scenario, but leaves a lot to be desired on the dirty work that would be required to build the 20% scenario. On the other hand, the ECM chapter (8), while light like the other chapters, provides information that is important specific to life sciences (and maybe financials).
In summary, I recommend getting this book used and going through it front-to-back. It's not that long, but surfaces a lot of the important features that are new to 2010.
As I've been working on my current project, I've found that many freshman developers who want to get better often have a hard time navigating the huge amount of resources out there to improve their skills. It's hard to commit given the cost of some of these books (usually at least $30 a pop) and the time it takes to make it through them if you don't know where to begin.
IMO, there are six books which are must reads for any serious .NET developer with aspirations for architecture (I'd probably recommend reading them in this order, too):
- Pro C# by Andrew Troelson which covers just enough about the CLR and the high level concepts in .NET programming with enough readability to not put you to sleep every time you crack it open. Even if you never use some of the features of the platform, it's important to know what's possible on the platform as it influences your design and implementation choices. While the "bookend" chapters aren't necessarily that great, the middle chapters are invaluable.
- Framework Design Guidelines by Cwalina and Abrams which provides a lot of insight into the guidelines that Microsoft implemented internally in designing the .NET framework. This is important for writing usable code, in general. I tend to think that all code that I write is -- on some level -- a framework (even if in miniature). Many otherwise tedious discussions on standards, naming, type/member design, etc. can be resolved by simply referencing this book as The Guideline.
- Design Patterns by GoF all too often, I come across terrible, terrible code where the original coder just goes nuts with if-else, switch-case statements...basic knowledge of how to resolve these issues leads to more maintainable and easier to read code. At the end of the day, design patterns are aimed at helping you organize your code into elements that are easier to understand conceptually, easier to read, easier to use, and easier to maintain. It's about letting the structure of your objects and the interactions between your objects dictate the flow of logic, not crazy, deeply nested conditional logic (I hope to never again see another 2000+ line method...yes, a single method).
- Patterns of Enterprise Application Architecture by Fowler My mantra that I repeat to clients and coworkers is that "it's been done before". There are very few design scenarios where you need to reinvent the wheel from the ground up. For business applications, many of the common patterns are documented and formalized in this book (to be paired with Design Patterns). This and Design Patterns are must reads for any developer that is seriously aspiring to be a technical lead or technical architect. As the .NET framework matures and we diverge from the legacy programming, understanding design patterns is becoming more important to grasping the benefits and liabilities of designs and frameworks. For high level technical resources, it's important to understand how to write "clean" code by designing around object interactions; design patterns document these commonly recurring interactions. It is also a vocabulary and set of conventions by which programmers can communicate intent and usage of complex graphs of objects.
- Code Complete 2nd Edition by McConnell While not C# or .NET specific, it delves into the deep nitty-gritty of the art of programming (and it's still very much an art/craft as opposed to a science). Too often, we lose sight of this core principle in our software construction process in our rush to "make it work", often leaving behind cryptic, unreadable, unmaintainable code. Some of the chapters in this book will definitely put you to sleep, but at the same time, it's filled with so much useful insight that it's worth trudging through this behemoth of a book.
- Pragmatic Unit Testing in C# by Hunt. This book, perhaps more than any of the ones listed above, gives a much more practical view of the how's and why's of good objected oriented design. Designing for testability intrinsically means creating decoupled modules, classes, and methods; it forces you to think about your object structure and interactions in a completely different mindframe. Test driven development/design is good to learn in and of itself, but I think the biggest thing I got from reading this book was insight into the small changes in code construction for the purpose of testability that yield big dividends in terms of decoupling your code modules. I think that once you read this book, you'll start to really understand what it means to write "orthogonal code".
I've recently picked up my copy of Code Complete - 2nd Edition again after a long hiatus from it. It's such a massive book that I think if you plan on reading it from front to back, it'll bore you to death and put you to sleep. Of course, this is not to say that the book is bad - quite the opposite, the book is filled to the brim with knowledge that will benefit any level of developer - but that you have to approach it in a more "leisurely" manner.
The book itself is one of those that you can really just kind of jump in and out of the chapters (except for some of the early ones that should be digested together).
Some bits from Chapter 31 that I think really capture the essence of the book.
McConnell opens with an excellent statement that succintly summarizes my infatuation with proper code structure, naming, and other seemingly "non-development" coding activities: it is a matter of personal pride in my work and the effort that I put forth to make the code legible:
“The visual and intellectual enjoyment of well-formatted code is a pleasure that few nonprogrammers can appreciate. But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code.” (P.729)
The chapter covers the importance of good formatting and layout, the psychological effects of good layout and formatting (such as easier to memorize code structure), and techniques to achieve good layout.
McConnell introduces the idea of “The Fundamental Theorem of Formatting” which says “good visual layout shows the logical structure of a program” (P.732)
He quotes Elliot Soloway and Kate Ehrlich in their studies:
“…there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified." (P.733)
This is in alignment with the ideals of best practices. The core concept is to have a codebase that exudes familiarity even to first time readers. McConnell emphasizes the importance of the human aspect of coding:
“The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it.” (P.733)
Indeed, writing code so that the machine can read it is easy: the compiler, IDE, and development tools like ReSharper will tell you when the machine can’t read it. Writing code so that other humans can read it is a true challenge since there is no one to confirm your view of the code or structure (without a well defined code review practice or pair programming).
In that sense, writing code is not so different than writing in general. Using shorthand is always the fastest ways to write little notes for oneself, but when composing a written work that others must consume, there are certain conventions that people come to expect: proper spacing, proper usage of punctuation, proper grammar, and the usage of paragraphs to delineate discrete bodies of text – these details all help to make the text more readable from a mechanical perspective.
While code is certainly not literature (well, not to most normal people anyways ), there are similar traits in elegant code structure and elegant prose: it is simple, clear, concise, and expressive. It might follow a pattern (rhyming, iambic pentameter, etc.) that gives it a flow.
Soloway and Ehrlich’s studies concluded that:
“The results point out the fragility of programming expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated—in seemingly innocuous ways—their performance drops drastically.” (P.735)
They cite examples where advanced chess players showed a marked increase in ability to memorize chess pieces arranged in “standard” or common scenarios over novice players, but demonstrated no increased ability when the pieces were arranged in a random fashion. The conclusion is that familiarity increases the ability to internalize and process an otherwise abstract structure (or in this case, arrangement of chess pieces).
Of course, it’s not all just fluff and “nice to haves”, right? McConnell raises an interesting observation that:
“The information contained in a program is denser than the information contained in most books. Whereas you might read and understand a page of a book in a minute or two, most programmers can’t read and understand a naked program listing at anything close to that rate. A program should give more organizational clues than a book, not fewer."
This makes the argument clear for commenting, proper and consistent application of white space, and using descriptive rather than short names (see Framework Design Guidelines for more coverage on that). For example (and I’ve never understood this one), the use of “itm” instead of typing “item” or “tsk” instead of “task” or the use of “d” to declare a local variable instead of “document”. One letter makes the code much more readable and much easier to process for another human reader of the code.
McConnell also makes a very good case for how code should be structured to reduce the complexity of the visual layout. He gives a good abstract comparison on page 747. These are small items which increase the readability of the code in very subversive ways; you probably never think about such details actively, but when processing a page of code, little details like indentation probably have a strong effect on your ability to understand the purpose and nature of the code. More importantly, when other humans have to process your code, these little details, taken in cumulative, could mean the difference between a day of ramp up and a week of ramp up time.
Of course, McConnell does acknowledge that in many cases, such matters of style are borderline “religious”. But from an objective perspective:
“…it’s clear that some forms of layout are better than others. Good programmers should be open-minded about their layout practices and accept practices proven to be better than the ones they’re used to, even if adjusting to a new method results in some initial discomfort.” (P.735)
Definitely a book that deserves some shelf space on any developer's desk (edit: or nightstand ).
I originally came across a title Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries after perusing the documentation on the Subtext site.
For the most part, I had been following the guidelines outlined by Scott Bellware in his handy dandy style guide, but this text - FDG - takes it to another level and formalizes it in a way that it must be accepted by development teams since it was born from the source itself: the .NET Framework development teams.
I've reviewed it on Amazon, but here is the transcripted text:
I don't personally think that all developers will find this book useful. In fact, I have a feeling that some may find it highly useless and disruptive as it is abstract in a sense (one must apply the lessons to each library and scenario independently, taking into consideration many different aspects of usability and readability) and it does require some "retraining" of bad practices which have been long since ingrained due to years of usage.
But whether this book deserves a five star rating or a one star rating - whether this book is for you - can be answered by asking yourself the following question: are you obsessed with quality? Quality in the sense of creating a library that is:
- Easily reused by others, even first timers encountering the library or even first timers to .Net
- Well thought out with well designed classes
- Consistent within itself and consistent with the base libraries from Microsoft
The importance of the little things like naming classes, properties, methods, using one type of construct over another, using one type of accessor over another, etc. cannot be stressed enough in the overall picture of creating a library to a higher standard of quality, usability, and extensibility.
As Confucius is to have said:
"If names be not correct, language is not in accordance with the truth of things. If language be not in accordance with the truth of things, affairs cannot be carried on to success.
"When affairs cannot be carried on to success, proprieties and music do not flourish. When proprieties and music do not flourish, punishments will not be properly awarded. When punishments are not properly awarded, the people do not know how to move hand or foot.
"Therefore a superior man considers it necessary that the names he uses may be spoken appropriately, and also that what he speaks may be carried out appropriately. What the superior man requires is just that in his words there may be nothing incorrect."
As I wrote in an e-mail to my team, I think that digesting this book will lead to: higher quality public facing APIs for our customer development teams seeking to extend the functionality, increased readability and more consistency internally in our teams, increased usability and decreased maintenance costs for the support teams as well as new developers on our team, and of course, increased skill, knowledge, and competency as developers of each of the team members.
The title of this book is perhaps a bit misleading. In reality, this book is applicable for anyone doing .Net development since it will lead to better quality code construction irregardless of whether you happen to be working on a "framework". What I also like about the book is that the authors, architects, and various developers who worked on the .NET Framework admit error and inconsistency in some design and shows that this book is truly a work of the men in the trenches and intended for those of us who work on the front line of software development.
While the book does not delve into architecture or design, I think it still has value in enhancing the skill and mastery of any developer that takes the time to read it. Definitely pick up this book if you are serious about becoming a better developer in the sense of being a more refined craftsman.
So it turns out that Paul Andrew, the technical product manager of WF linked to my very abstract review of Essential Windows Workflow Foundation. For those that haven't been following, I wrote an awesome review of the book on Amazon and sent it in (or so I thought!) but I haven't seen it show up on the page yet :-S
So for the sake of others considering this book, I'll review it again.
There are two types of developers that you will come across: those that are content to make things work and solve business solutions from the top down and those that want to understand the underlying technologies to build solutions from the bottom up. This is not so much a discussion on "architecting", mind you, but rather a discussion on how different developers approach tools and frameworks. Not that one is better than the other, but each brings a different approach and each has different preferences with regards to technical resources.
If you fall into the former and you are mostly concerned with your immediate business solutions (learn top-down) and you learn best by doing, then this book is not for you. The contents of this book are not so much concerned with how to solve business solutions with WF nor is it a cookbook for WF solutions. This book doesn't have many pictures of the design surface and doesn't concern itself much with building workflows in the designer. It is an introductory guide to the underpinnings of the WF framework. It delves into the workings of WF and the principles behind many of the advanced concepts that may not necessarily crop up in most use cases.
If you fall into the latter category of developers (learn bottom-up) and you learn best by first understanding the tool and the design principles of the tool, then this book will be a good starting point to understanding WF. In fact, the first chapter of the book walks through a sample implementation of a simple "workflow engine" and covers the principles that drive the implementation of the WF framework. The chapter presents a "If I were writing a workflow engine, how would I write it?" scenario (if that makes any sense). This outline then serves as a basis for understanding the function and design of the WF engine.
The book provides insight into advanced concepts and does a fairly good job of it (examples are simple and straightforward - oddly, not all of the code is provided online), but it seems to come up short in the last chapter, where the authors just kind of jumbled everything that they didn't cover into one chapter. It almost seems like the authors were working on a 10 or 12 chapter book but were forced to cram the remaining topics (unfinished) into chapter 8. In short, the book seems unfinished.
This book is not for everyone. It does assume some familiarity with higher level .Net framework concepts that many developers from the ASP.Net world may not have experience with (specifically, threading and asynchronous method calls) so for that reason, I would recommend a companion book: Pro C# 2005 and the .NET 2.0 Platform, Third Edition. As a general note, I've found that the "Microsoft .Net Development Series" of books from Addison Wesley typically does not cater to the first class of developer as the titles tend to be architecture and framework oriented as opposed to solution and implementation oriented.
In summary: 4 out of 5 stars; a worthy book that deserves a space on your bookshelf if you plan on doing WF.
Yesterday was my first time at an NFL football game (Jets vs. Bucs). This also means that I've been to each of the three major sports (NBA, MLB, and NFL). (For my international readers, the NFL is the highest league for American-style football).
I must say, the experience is quite something. It's very different from either of the other big three sports in that there is a whole huge sub-culture in the football world. If you've never experienced it, there's nothing quite like it at all.
Sadly, I didn't have my camera with me, but driving into the parking lot of Giants Stadium I was just struck by how many people were there tailgating. It was incredible, it was like a little town sprung up there that morning, with people pitching tents, watching TV, eating BBQ, throwing footballs around. I mean, it felt like these people lived there. What caught my attention as well was that a lot of men would urinate right by the side of the road without hesitation (since the lines for the port-o-potties was ridiculous.
The stadium itself was tremendous. There's nothing quite like it in the enormity of it all; you get kinda queasy sitting in the third tier just looking down.
The game itself was great. Vinny Testaverde was playing in his first game in 9 months since retiring with the Cowboys after last season. I have to say, I can only hope that I'm that mobile and that fit when I'm 41, because damn, the guy can still move and throw the long ball. He had the crowd roaring during pregame warmups when he threw a 60-70 yard pass to Laverneus Coles. Wow. Vinny only threw one interception, which was unfortunate (it was short only by a little), but acceptable considering that just two weeks ago, he was hanging out on his sofa watching the Jets play
Afterwards, listening to Vinny talk, I was reminded of The Incredibles. Vinny had some great years (the best of his career) with the Jets and here he was again, up to his old heroics after retiring from football. And like in The Incredibles, it took a team effort to overcome the opponent.
"Before you read on, bear in mind that I'm writing this review in comparison to the first "Ghost in the Shell". While Shirow does mention that this book is not a continuation of the first, there are some major differences in style.
Let's start with the artwork. As I've noticed with Shirow's work, all the ways from Appleseed, his style has matured with each work and is at a very advanced level, in my opinion, among top comic book artists in the world. He has a certain style of coloring that, to me, is really unique in how subtle, lifelike, and tactile he makes fabrics and skin. While only roughly 35-40% of the book is colored, it is done so fantastically.
In addition, Shirow has a supreme mastery of the female body form. It's simply stunning to see how beautifully he can render the female body, especially with the dynamic energy he brings to his characters. While he renders many of the panels with the female characters in the buff, he does not render "R" nudity, but rather "PG-13" nudity, except in one panel). (As a sidenote, parents of younger readers should perhaps consider this an "R" rated book. While none of the nudity is gratuitous, it can be a little too much for some).
As fans of Shirow have noticed, he has been experimenting with integrating 3D, rendered environments and objects with his 2D artwork. He shows his mastery of this technique in many of the panels, where it seems seemless; you feel as if the character is really a part of the scene. Then in others, it seems poorly done (for example, he renders pigs in a sequence of panels and the pigs just look weird). I'd also offer some criticism of his rendering of "virtual space", as it quickly becomes cluttered and very difficult to navigate, visually, especially in the low-res, black and white lineart panels.
As with all Shirow works, there is certainly enough cool technobabble and gadgets to get your geek juices flowing. From exoskeletons that envelope and "swallow" the pilot, to oddly constructed androids, to the techno-metaphysical discussions of reality, life, existence, and justice.
My main criticism with the work is the incontinuity *within* the plot itself (I fully understand and accept that this is not a continuation of the first). Without going deeply into the plot, there are some scenarios where he will start what seems like an arc, but then the arc disappears, without entering into the plot again. It seems like whole parts of the book were created just for the sake of showing artwork, and not progressing plot (to me, plot should always come first in a written work, which this is, despite the medium). It feels like the recent Star Wars movies in that they are really a showcase for Lucas's technique with fully rendered sets and have lost any semblence of a cohesive plot and the great acting (especially Harrison Ford) that made the first three the classics that they are. Yes, while I do appreciate the eye candy, this is still a graphic novel, and, as such, I expect a cohesive plot and not random interjections of this and that and whatever.
Some fans will also find the lack of action (compared to the first book) a bit disappointing. The first book was far grittier and more action packed than this book. It also had a richer cast of characters. "Man-Machine Interface" really only features one character (albeit in various bodies and forms) and thus loses some of the dynamic interactions between characters. Shirow never gets a chance to fully developer the chief of Poseidon police and his crew.
Overall, this book is excellent if you simply love Shirow's beautiful artwork, mastery of the female body form, and creative techno-gadgets. The plot, especially the ending, will leave you sorely disappointed. Whereas the first ended on a revelation of a metaphysical type, this book ends in a fizzle."
If you're a fan of Shirow, it's a no brainer, you gotta pick it up, but it's certainly not for everyone.
I'm also working my way through Fred Brooks' "The Mythical Man Month". I'm only 1/3 of the way through the book at the moment, but it's absolutely a great book that everyone in an IT organization (everyone!) has to read. I mean, even after all of these years, the same problems persist in software development (doesn't anyone learn from history?). If you're in the IT industry, whether you're a manager, a salesperson, or a developer, be sure to pick this one up. It's an easy read, too, since Brooks' style is very inviting and personable. He makes some excellent analogies. I think I'll do a mini book review after I'm done with the book
That's it for now...been busy at work, so less time to post during the day >.<