<< 1 >>
Rating: 
Summary: Finally!
Review: All this time I thought "high reuse" was just a myth, and that I was doomed to spend my days at a keyboard. Birmingham hits it completely out of the park! I'm looking forward to applying these concepts and having some fun again.
Rating: 
Summary: worst book I ever read
Review: I am working on a metadata driven project. So I ordered this book.
I opened the book, It it looks like a 2 year VB programmer view on software development. Lots of Ideology and preaching, but nothing concreate. like "Interfaces should never be changed" which is fine, nobody changes an interface for the fun of it, but what you do when you have to.
or "make your classes small, with small interface, and make as few classes as possible". again, it is like saying it is better to be healty,handsome and rice than ill, ugly and poor. My main reason for the purchase were the rave reviews that apear on this page.Re-reading them - they do not seem authentic to me.
Rating: 
Summary: A textbook or a sales material?
Review: I have mixed feelings about this book. The main idea of it (as far as I understand) is achieving high degree of reuse by separating the software from its concrete application and expressing this application in "structural and behavioral metadata". Moreover, in your application, you must get rid of any dependecties on things that you do not control by wrapping it in your software layer and exposing it to the application as very abstract ("metamorphic") object model. The author provides some interesting examples for this and presents the basic building blocks of a software framework built around these ideas. As much as it might sound compelling this concept is not really new. What is worse is that methods and advice presented in the book are sometimes simply wrong or often have serious drawbacks which the author doesn't talk about. For example the author really hates strong typing and recommends reducing the interface of _all_ your classes to just 3 members: "Item", "Ref" and "Action". This is bizarre. The view of strong typing as an enemy of the programmer is completely wrong; it was actually introduced to help control side-effects of changes to class interfaces. Another example is the virtual database layer the author proposes: while it is true that it lets the programmer switch the underlying database engine very easily it is based on relatively low-level SQL concepts and suffers from the least common denominator syndrome. I would say that for many, if not most, application a better way is to design a higher-level database abstraction layer that takes advantage of the engine capabilities. Usually it is not much more code and the performance difference might be enormous. Finally there is the cost aspect. You cannot really adopt the method partially; either you are in or out. And you must really have almost unlimited resources to develop this kind of framework yourself. Which makes you think that it would be reasonable to get the framework developed by the author already. Which is just what the author wants and which is strongly reinforced with the last chapter of the book that literally sounds like a Ginzu knife sales pitch. Is it worth it? You have to decide yourself. For me the extreme programming advice: "Always build the simplest thing that works" has worked very well so far...
Rating: 
Summary: Good reading
Review: I like how the author separates the two views - application and architecture. Developing high-reuse systems, especially across multiple applications like he's talking about, is worth further exploration. I'm interested in applying this at least experimentally. New programmers won't get it - someone just starting out won't find much value here. Every application I've ever developed internally or externally uses one model and that's to code the application behavior directly into the software. The author directly asserts that this is a bad plan and develops the argument, but he's swimming upstream against every popular approach. He'll probably take a lot of industry heat for this. Looking over the standard white paper sites, I don't see much on complete physical separation of the compiled components from the application rules. If this is truly the next level, only time will tell. That Apress is willing to push these ideas says a lot for their merit.
The project exercises in the book are the real bridge - just reading didn't give me the same flavor. But I would like to see more in the .NET side of it.
Rating:
Summary: Reads like an infomercial
Review: I think the other reviews are bogus; they all write exactly one paragraph, and each reviewer has done a total of one review each. On to the book. I should tell you, I have not read the whole thing; it was very easy to put down. This is not a scholarly work. The author is trying to sell you his product. He is apparently not capable of telling you about it in a way that isn't an advertisement. He talks about his product as if it is the fabled "silver bullet" that is going to make your developers and qa people super-productive and give them great job satisfaction. I do agree with the author's idea of separating application code from the architecture, but he did not invent this. This is just common sense. Good software organizations already do this. The writing style insults the intelligence of the reader. He talks about how item attributes are stored in a binary search tree, and explains how that means you won't have to search for your attributes linearly. He talks about this approach as if it's a major innovation. (BST's! Why didn't *I* think of that!) Avoid this book.
Rating:
Summary: Rating - 5 is not high enough!
Review: Our teams have used parts of these concepts for years, but this is the first time I've seen them integrated, and in way that makes sense. The author puts real flesh on the bones - and gives credibility (at last) to true reusability for application software. Why hasn't someone thought of this sooner?
Rating:
Summary: whata-morphic?
Review: The author proposes a great approach and his passion about it jumps right off the pages. It's great to see a software development veteran who is still this excited about the profession. It's secondary evidence (to me) that his approach has at least some of the motivational aspects he describes. After a brief internet search, the word "metamorphic" in software context appears mainly for application porting and migration (if I have a C application to port to Java, for example). What the author proposes is something different: In his world, there is no "application code" in the program (it's *all* metadata). The author says that polymorphism is actually our enemy when attempting high-reuse, because application-specific relationships become entangled in the implementation. We can spin-off but we can't really take whole subsystems "as is" to completely new problem domains. The metamorphic approach, as I understand it, transcends this issue because no application code resides in compiled software. The download examples are eye-poppers. I have to say that I just gasped when I realized that he was dynamically reproducing screens directly from metadata created by the Microsoft IDE. As quickly as I changed a screen, the change was available without rebuilding the program. This could likely work for pulling in the definitions from any environment with screen-building functionality (PowerBuilder? Visio EA? Borland?) He ties in detailed behavioral control as well. After using Macromedia Flash and similar technologies, these also have a means to include a sort of behavioral "script" to guide the activities. The author describes similar behavioral macros to affect application activity, but for general computing. To troubleshoot, we only need a simple text editor rather than a full-blown development environment, and we can load/reload these textual instruction sets while the program is running. Would I find value in refreshing a user's desktop experience just by transmitting a new textual instruction set? Hmmm. Don't have to think too long about that one. Extrapolating, I suppose I could have a Unix and Windows version of a metamorphic program and run the same application metadata transparently on both. (Perhaps across both?). I don't see any difference in running a Unix/Motif based version of this while using Microsoft IDE metadata as screen-rendering instructions, or vice-versa (although the Gates/McNealy diehards will recoil in horror at this) The author supplies Visual Basic code for the book's examples. I'd like to see this in something more portable like C++. I'm tired of fighting the empty promises of Java.
Rating:
Summary: Impressive, but not for the weak
Review: This is a good, chewable read. I would not recommend it for new developers, purely academic types or those without real-world appreciation of the true intensity of commercial software development. The author describes separating the application from the architecture, and while I've done this before in software on several levels, I never considered removing the application completely from the compiled software and driving application behavior from what the author calls "external structural and behavioral metadata". Using the same binary program to support multiple applications without recompiling a single line of code? Perhaps without recompiling on each and every application release, which makes perfect sense. However, he avoids rebuild for complex screen-level changes, too (even cosmetics). Not too shabby. The project examples are pretty hot - I can see how he could suggest compiling software only once and doing high-speed application re-delivery with this as a foundation. We deploy software nationally for retail point-of-sale systems and are moving into wireless hand-helds, so the prospect of delivering application-level changes without new compiled binaries is quite intriguing. His "toolkit" includes a linked-list manager (Iterator) which by the author's own confession is not new, but does provide some rather interesting twists on data organization. The linked-list as binary tree is of particular interest, since it eliminates linear searching of large data sets. The XML support is good, and I like the ability to build a very complex custom structure, reduce it to XML, then reconstruct it from XML again. This has significant implications for our XML -based applications that don't talk to each other any other way, and don't support or co-habitate with the .NET XML subsystem. I can see how using this functionality at a lower level could allow two otherwise closed systems to share common structures, or save the structure to a database as XML text for a very advanced version of behavioral persistence. I would suggest using this structure for XML support but not for an XML foundation. I think the author *likely* would agree that available XML-support components are an adaptable technology in their own right, but would fit right into his component model like any other. Again, I like the flexibility, especially since our internet servers are all Unix and Linux portals. I rigged up an example of his TurboCollection along with the interpreter and saved its run-time state into XML in the middle of executing an "application instruction". Not only could I persist the operational state of the application, I could retrieve it and pick up where I left off. This form of behavioral checkpointing is very hard to pull off at an application level, but the data structures make it fairly transparent. A side note to this is in managing XML-based transactions and queued states, indefinitely storing the application's state while it pends for new instructions. However, without a really good handle on software development and a reasonably strong foundation in data structures, perhaps even compilers, the architectural strength of this model would be lost. I've got friends who build game applications using game engines with similar characteristics. For people using it to deploy applications without touching the actual software, this model could probably be further simplified and optimized. His interpreter is also simple but intriguing, in that it can accept instructions on the fly much like the Microsoft Visual Studio .NET "command" window, yet there's no .NET IDE in sight. In the embedded "watch" window I could single-step through the "application" without the development environment. Add to this the ability to define and view "virtual" data constructs or even load and execute new instruction sets without stopping the program - and I can say the author has done his homework. For anyone who cares, the project exercise fine print shares a little secret: that the demo software program included in the downloads is the author's full metamorphic model with "some disabilities" (although he doesn't say what the disabilities are, only that they are performance-related to inhibit production deployment). If this is true, and the metamorphic software is really this small, I'm very impressed.
Rating:
Summary: Excellent Book. But not a traditional view of software Dev
Review: This is an excellent book. I hardly say that about any Software book.
The author clearly shows the merits of this approach. Yes you get a demo of his architecture aswell and yes you definitely come out thinking about whether you should buy the architecture from him instead of going it alone. Our business started developing a resuable VB6 architecture 5 years ago. We did the classic n-tier client server architecture and built our own code generator. Over the years we generalised more and more of the architecture out into meta-data and had less and less generated code. The more we worked with these concepts the more we liked and used them. Reading this book felt like Deja vu at many points. When we ported to Dot Net we pushed this even further.
We were all fealing pretty happy with how far we had gone how easy to maintain how reusable etc etc etc. Well this book blew us away. The author shows how to do things we were still dreaming about. Any conscious programmer should take a serious look at this. I would go so far as to say that any programmer who does not see value in this approach has limited experience in software development. This approach is also in my opinion perfectly suited to TDD and XP. In short I recommend this book highly.
Rating:
Summary: Almost magical?
Review: When I first read the book's description, I was very skeptical of the contents. After reading the sample chapter (available from the Apress web site) I saw where Birmingham was going with it. The conclusion: this work is very impressive, well written and took me through some very practical and (like it says) innovative stuff that's just plain cool!
<< 1 >>
| 
