Java Performance Book Review

Being new to Java I am interested in finding out the low level nettigritty details of the Java HotSpot VM. This book was definitely the right choice for that. I must admit being a veteran .NET developer helped when digging into the different concepts and there are a ton of them. One of the things I really liked about the book is that although it leaned towards Oracle, it also included Windows and Solaris. There are 12 chapters. Chapter 1: Strategies, Approaches, and Methodologies, Chapter 2: Operating System Performance Monitoring, Chapter 3: JVM Overview, Chapter 4: JVM Performance Monitoring, Chapter 5: Java Application Profiling, Chapter 6: Java Application Profiling Tips and Tricks, Chapter 7: Tuning the JVM, Step by Step, Chapter 8: Benchmarking Java Applications, Chapter 9: Benchmarking Multitiered Applications, Chapter 10: Web Application Performance, Chapter 11: Web Services Performance, and Chapter 12: Java Persistence and Enterprise Java Beans Performance. The book ends with two great appendices. HotSpot VM Command Line Options of Interest and Profiling Tips and Tricks Example Source Code. The authors do a great job of introducing a lot of different tools as well as the useful commands lines needed for performance monitoring, profiling, and tuning. Although there are a few that only work on Solaris and Linux the author provides alternatives for Windows and Mac users where possible. They do a great job introducing VisualVM and NetBeans Profiler. The coverage of Adaptive Tuning and Garbage Collection in these sections was really great. The chapters on Benchmarking are great. This is often an overlooked process. It is really important to have proper benchmarks in place so when performance issues creep up you have a baseline to narrow the problem down with. I have seen plenty of enterprises without them and when performance issues come up they are looking for a needle in a haystack… in the dark. The web application and web service chapters are also packed with great advice. Although Glassfish is used a lot of the advice applies to most application servers. I really like Appendix A: HotSpot VM Command Line Options of Interest. It contains a really nice list of the HotSpot command lines options that are related to performance. My one gripe is that Appendix B contains some really nice code examples, but it does not appear there are any plans to make the code available for download. I found the authors writing style made the book a really easy read especially for such low level complex topics. All in all if you have anything to do with Java development this book has got to be on your shelf.

Java Performance

Microsoft moved my cheese again and I don't really care to find it.

Over the years Microsoft has not only moved my cheese, they have also quite often eaten it.

I used to stay tuned into what Microsoft was saying about its direction, but over the last year or so their attitude of keeping things hush hush until the last second has disconnected me from them. Now I find I am rather enjoying not being tuned in.

I have been finding life much easier not pushing Microsoft down people's throats and a lot less disappointing. If I never experience the level of anguish Silverlight, Workflow, UML, MSF, DSL, and DNA caused me again, I will probably have 5 to 10 years added to my life.

With Window 8 and Metro around the corner, in the past I would find myself much more excited. Truthfully, I am not. I want to be, but Microsoft has put such a bad taste in my mouth, I just don't want to follow them down another road to nowhere. Sure, I downloaded it the second it was available and started playing with it, but I am not putting any real energy into thinking about its potential. I have done that way too many times over the years to know Microsoft's bleeding edge will drain you like a Vampire.

My title on my resume and blog has been changed from .NET Software Architect to just Software Architect for several months now. Officially I am currently filling the role of an Enterprise Architect, but my passions are Software Process Engineering and Software Architecture, so that is primarily what I spend my free time learning more about.

With a major Java project on the horizon I have been burying myself in getting familiar with the Java world. I find I like the freedom that comes with it. Sure Oracle is at the top of the food chain, but there are a lot more options in Java especially the ability to choose your IDE. There are a lot more open source tools that are mature in the Java world too.

I do a lot with SharePoint custom development, but with the downfall of Silverlight I don't have much interest in that. I saw Silverlight as the answer to the horrible web part programming model. I have yet to see anyone write SharePoint web parts that aren't spaghetti code. Every major web part implementation I have seen has been a big ball of mud, and I have seen a lot. I moved to Silverlight for web parts as soon as I could. It was a great programming model.

Microsoft continues to play the top secret game with regards to Silverlight so rumors of lack of browser support in the next year or two are being allowed to flourish. I am not willing to tell customers they should spend a year or two investing in Silverlight just so they can start over when they finally start reaching maturity. So for now, because of Silverlight, SharePoint custom development is off my list of recommendations as well.

I am back to square one with regards to recommending internal enterprise applications be implemented with WPF for now, and then XAML for Windows on Windows 8. No more browser context to have to worry about except for the external applications that will be ASP.NET or MVC. If I get to control the requirements for the users desktops of the external applications, they will also be done with WPF and XAML for Windows. I have not been a fan of browser applications and that isn't going to change with HTML5. They are still going to be big balls of mud architectures implemented with a quagmire of spaghetti code.

I do think Metro will do well on phones and slates, but I also think they are just as lost as ever when it comes to direction with their development platform. Too many cooks in the kitchen have taken what could have been a great platform for development and added way too many ingredients then tried to cover them up with more ingredients without telling us. I think Metro will mainly do well because a lot of people have a lot invested in Microsoft and those people need it to do well. They will invest in it with blinders on and that perceived success will be interpreted as a success.

I am not the only one missing cheese. Right now I feel Microsoft is still desperately searching for the cheese that Steve Jobs has been eating up for the past several years.

UPDATE:
I highly recommend reading Kevin Hoffman's excellent follow up to this post here.

Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise Book Review

I still remember the first few pages of Managing Software Requirements: A Unified Approach (The Addison-Wesley Object Technology Series). I was in BWI waiting on my daughter's flight to arrive. The book opened with such a great beginning I knew I was going to love it. In a nutshell what I heard the authors say was we have years of experience that you don't, let us show you what we have learned so you don't have to repeat our mistakes. That is my number one reason for reading books. The message at the beginning of this book is the same. I feel this is the first complete book on what an enterprise level agile process should look like. What baffles me is the number of enterprises I have been in that have not come close to implementing 10% of the process this book outlines, yet they call themselves agile and lean. The one thing this book brings to light is just how complex and advanced agile processes are. Like the book says, "it is not easy, it is agile". This book has the caveat that certain skills are required for the agile teams to be successful. I agree with that completely. The thing I have a hard time with is the fact that agile processes assume such skill sets are readily available. They aren't. That is why I see such a mess in 90% of the attempts I have seen when enterprises attempt to go agile. Almost all of them will claim to be successful at implementing their agile processes, but budgets and bugs don't lie. Agile does not equate to simple or easy, actually the opposite is true. So then does that mean agile methods should be avoided and this book is not worth reading? Absolutely not. It is one of the few books that may just help you implement a successful agile enterprise environment. If nothing else, it does not pull punches, so it will enlighten you as to just how difficult it is to pull it off. It is a must read for anyone out there claiming to be running an agile enterprise. This book is unique in that it provides a complete view of all the roles throughout the enterprise that are involved with the process and does a great job of defining the activities they are involved with. The book calls the process Agile Enterprise Big Picture: Scaled Agile Delivery Model, or the Big Picture for short. The process has three levels, the Team level, the Program level, and the portfolio level. The book starts out with a really cool overview of software development process models. The chapter goes from Waterfall to Spiral, RAD, RUP to Crystal, Scrum, XP, FDD, DSDM, Open UP, Kanban to Enterprise-Scale Adaptive Processes. The rest of part one dedicates four more chapters to introducing the Agile Enterprise Big Picture: Scaled Agile Delivery Model (the Big Picture). The book has three more parts, one for each process level. The Team level, the Program level, and the portfolio level. Each part has several chapters that drill deep into the details of each level. One of the things I really like about the book is that it acknowledges the importance of software architecture. It does not go along with the common agile "emergent architecture" view. The book advocates intentional architecture. It also acknowledges project managers and doesn't just drop them from the picture. Another thing I really like is that modernization is realized through the architectural epics. Modernization strategies are usually nonexistent in most enterprises until they find it is too late. Then they are implemented in a haphazard way creating so much more damage than necessary. This book makes modernization strategies first class citizens through architectural epics. If you are in an enterprise environment and you are attempting to implement agile processes, this book is the book to have. Agile requires experience. This book is filled with experience from the trenches. The book is written well and the author's writing style makes it an easy read. As easy as you can make a topic that is so complex. This books takes all the activities, artifacts, roles, responsibilities, and processes that have always made a successful software development project using classic software development processes such as the unified process and the RUP, and repositions them in their agile context. All in all I highly recommend this book to anyone working in an enterprise level software development environment. The developer, project manager, tester, software architect, process engineer, business analyst, scrum master, product owner, project sponsor, CIO, CFO, and CEO could benefit from reading this book, even if you are not in an agile shop.

Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services Book Review

I have been a fan of the Martin Fowler Signature Series for a long time. This book fit into the series great and filled in a missing link in the series. One of the things I liked seeing was that the author does not think web services are a silver bullet. Right off the bat he warns that web services should be reserved for situations which out-of-process and cross-machine calls "make sense". The book is broken down into seven chapters, an appendix, and a nice glossary. The chapters include From Objects to Web Services, Web Service API Styles, Client-Service Interactions, Request and Response Management, Web Service Implementation Styles, Web Service Infrastructures, Web Service Evolution, and an appendix Reference to External Patterns. I felt the book worked at the right level of abstraction digging into details when needed to shed a deeper light on the subject at hand. Each chapter contains several related patterns. Each pattern answers a primary question. For example chapter one Web Service API Styles cover the following 3 patterns that answer the question that follows below. RPC API - How can clients execute remote procedures over HTTP? Message API - How can clients send commands, notifications, or other information to remote systems over HTTP while avoiding direct coupling to remote procedures? Resource API - How can a client manipulate data managed by a remote system, avoid direct coupling to remote procedures, and minimize the need for domain-specific APIs? The other patterns covered in the book include Request/Response, Request/Acknowledge, Media Type Negotiation, Linked Service, Service Controller, Data Transfer Object, Request Mapper, Response Mapper, Transaction Script, Datasource Adapter, Operation Script, Command Invoker, Workflow Connector, Service Connector, Service Descriptor, Asynchronous Response Handler, Service Interceptor, Idempotent Retry, SOA Infrastructures, Breaking Changes, Versioning, Single Message Argument, Dataset Amendment, Tolerant Reader, and Consumer-Driven Contract. Like the other pattern catalogs the book contains an online catalog of the patterns in the book. Although the online catalog gives you an overview of each pattern, the book contains a lot more detail about each one. I like the online catalogs. I often visit them to spark my memory about the patterns that I have read about in the books. I like that the book limited its scope to the fundamental patterns relevant to web service design. It does not try to be all encompassing, which I think made it better than if the author had tried to be. The book does not cover enterprise integration patterns, workflow or orchestration, security, event-driven architecture, or choreography. The book does include a nice reference to external patterns in the appendix that provides a summary and where to go for more information. I think each pattern is explained really well and the examples used do a great job of showing a possible implementation. I liked the end of chapter 7 where the author provides a nice summary about how each pattern hinders or promotes evolution. The book also includes a nice glossary that provides quick reference to additional information on topics mentioned in the book. The author does an awesome job of providing examples in different technologies throughout the book. The author uses a nice mixture of .NET and Java technologies. Some of the technologies used are JAX-WS, JAX-RS, JAXB, JSON, XML, Xpath, XSLT, WSDL, DataContractSerializer, XmlSerializer, and WCF. To top it off the author's writing style makes the reading really easy. All in all I think every architect and developer should have this book on their shelf.

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services

Essential Skills for the Agile Developer: A Guide to Better Programming and Design Book Review

I have been a fan of the Net Objectives books since the first edition of Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition). That is still my favorite design patterns book. When it comes to the agile movement I still remain torn. I watch it change and shift the industry's development processes to improve the customer satisfaction delivered by software teams successfully executing the processes, while at the same time I watch more teams use it as an excuse for the chaos they live in. The good news is books like this one offer sound advice on achieving agility. The bad news is the agile team members I mentioned above that are living in daily chaos never pick them up. They are too busy putting out the day's hottest fire. Moving a team that cannot produce using waterfall or RUP to a shiny new agile process will do nothing but make them produce crappier software. An inexperienced team that can't produce quality software with one process won't start producing quality by claiming to be agile. I tell you all that because I want you to understand where I come from when it comes to agile methodologies. I am not an Agile Movement Zealot, but I find the guidance provided by this book very valuable. The book has chapters on Programming by Intention, Separate Use from Construction, Define Tests Up Front, Shalloway’s Law and Shalloway’s Principle, Encapsulate That!, Interface-Oriented Design, Acceptance Test—Driven Development (ATDD), Avoid Over- and Under-Design, Continuous Integration, Commonality and Variability Analysis, Refactor to the Open-Closed, Needs versus Capabilities Interfaces, and When and How to Use Inheritance. The book ends with three Appendixes- Overview of the Unified Modeling Language (UML), Code Qualities, and Encapsulating Primitives. Each topic is considered a Trim Tab. According to Wikipedia Trim tabs are small surfaces connected to the trailing edge of a larger control surface on a boat or aircraft, used to control the trim of the controls. Boats with outboard engines will often have trim tabs attached to the lower unit of the engine. Many airplanes (including gliders) have trim tabs on their elevators, as a simple method of providing trim in the longitudinal axis. Richard Buckminster “Bucky” Fuller used of trim tabs as a metaphor for leadership and personal empowerment. The authors of the book say they are the actions and insights that give the most understanding with the least investment. The first chapter, programming by intention is one topic that still is kind of weird to me. Every explanation of what it is could just be classified as common sense to me. I agree with everything that goes along with programming by intention, I just don't understand why or how you would not program like that. Separate Use from Construction is a nice perspective on the reasons for using dependency injection, ORM mappers, and not over designing when using such tools. Define Tests Up Front explains why testing is not just about testing, but also about code quality. Shalloway’s Law and Shalloway’s Principle is all about reducing redundancy. I am glad the book includes the chapter on Commonality and Variability Analysis. It is just as valuable today as it was when it appeared in the first edition of Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition). The best thing about this book is that each subject is truly the actions and insights that give the most understanding with the least investment. Each chapter is a little nugget of wisdom that has been tested over time. The book is all about one of the cores that allows agility to be a reality on a project and that is great programming practices. Over all I found the book a very easy and enjoyable read. I highly recommend it to developers of all languages.

Essential Skills for the Agile Developer: A Guide to Better Programming and Design

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition) Book Review

Some might look at my book collection and think I have hoarding issues. If I had to pick just one Software Architecture book to keep, this would be the one. This is the second edition of one of the best books written on software systems architecture. If you are in the software development industry, you should read this book. If you are a Software Architect, you must read this book. This book covers a vast amount of material but it ties it all together in a way that paints a complete picture of what software systems architecture is all about. The book starts out covering architecture fundamentals. There is a chapter on Software Architecture Concepts, Viewpoints and Views, Architectural Perspectives, and The Role of the Software Architect. It then presents a process for software architecture and explains all the elements involved with the process. This part of the book contains chapters on The Architecture Definition Process, Concerns, Principles and Decisions, Identifying and Engaging Stakeholders, Identifying and Using Scenarios, Using Styles and Patterns, Producing Architectural Models, and Evaluating the Architecture. Next is a viewpoint catalog. The part of the book goes into the details of the different viewpoints the authors recommend considering as part of you architectural analysis. The viewpoints include Context, Information, Functional, Concurrency, Information, Development, Deployment, and Operational. Each viewpoint is a separate chapter. This section ends with a chapter that show how to achieve consistency across views. After the viewpoint catalog the authors present a perspective catalog. Perspectives ensure that quality properties that cross several views are accounted for and analyzed. The perspective catalog includes Security, Performance and Scalability, Availability and Resilience, Evolution, Accessibility, Development Resource, Internationalization, Location, Regulation, and Usability. The book ends with a chapter that ties everything together and a nice appendix that shows the relationship of the author's Viewpoints and Perspectives to other processes. They include Kruchten 4+1, RM-ODP, Siemens, SEI's Views and Beyond, Garland and Anthony, IAF, Zachman, and TOGAF. I am lucky they came out with a second edition because my first edition is getting pretty beat up. It has scribbling from tons of different projects in it. The first edition has not left my side since I purchased it and this second edition won't leave my side either. One of the things I like about this book is that the authors complete the picture. They don't say here is one example of a pitfall, concern, or tactic, they present a nice long list that really helps lead you through the process. Keeping this book handy helps me think of things I am sure to overlook. Another thing I like about this book is that it is not a reinvention of the wheel. The authors do a great job of incorporating industry best practices that have withstood the test of time, as well as included all the newer elements of software architecture that have come about in recent years. If you have the first edition, the second edition is worth getting. There is updated information scattered throughout the book as well as a new Context viewpoint. There has been 132 pages added. I said this about the first version and it still holds true with the second edition… Even if you are not an architect it is a great book to buy so you understand what to expect out of one. I may buy a few extra copies to give out on projects so they understand why I am supposed to be there. Anyone reading this book should have a great and complete understanding of architecture and the value it adds to a project.

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition)