I missed the first version of this book, No Fluff Just Stuff Anthology, 2006, but I have vowed to try not to miss any future releases. No Fluff Just Stuff Anthology, 2007 is a pretty good book by one of my favorite publishers: Pragmatic Programmers. If you have interests in software development outside the world of .NET, this book provides a broad introduction to lots of hot tech topics, albeit mostly in the worlds of Open Source and Java development.
Called "A Technical Conference to Go!" by one Amazon.com reviewer, this book is a collection of bite-sized articles covering a wide array of software development topics and range from mostly philosophical to hands-on how-tos. I found about a half-dozen interesting topics and was enlightened in some way by most of the others. Most .NET and Windows developers would typically stay far from this book simply because most of the content is so far from any topics of practical use. However, if you are an avid reader and try to stay on top of the world of software development outside the boundaries of Microsoft, take a look at this book.
I don't often include the table of contents from a book, but I want you to get a feel for the breadth this book covers:
- Chapter 3 - Learning to Love JavaScript
- Chapter 4 - The Joys of Continuations and Asynchronous Architectures
- Chapter 5 - The Case for Groovy
- Chapter 6 - Give It a REST
- Chapter 7 - Guerilla Testing with Cobertura, TestNG, and EasyMock
- Chapter 8 - An Introduction to the Google Web Toolkit
- Chapter 9 - Web Testing with Selenium
- Chapter 10 - IntelliJ Tips, Tricks, and Techniques
- Chapter 11 - Pragmatic Tips, Tricks, and Techniques: Eclipse
- Chapter 12 - Improving Code Quality Using Automation
- Chapter 13 - Capistrano: Application Deployment and More
- Chapter 14 - Bootstrapping Agility
- Chapter 15 - The Software Engineer's Guide to Usability
- Chapter 16 - Integrating Ruby with Your Legacy Code
- Chapter 17 - Executable Documentation with FIT and FitNesse
- Chapter 18 - Introducting the iBATIS Persistence Framework
- Chapter 19 - Data Access Using Spring, Hibernate, and JDBC
- Appendix A - The Authors Speak
The No Fluff Just Stuff Software Symposium Series is a series of technical conferences whose topics cover the gamut of software development and are delivered by some of the biggest names in the industry. This book is organized similarly. From the NFJS site:
The No Fluff Just Stuff Software Symposium Series is designed to cover the latest in trends, best practices, and newest developments in Enterprise Java, Java/Groovy, ESB/SOA, Ajax, Web Services, Agility, and Architecture. Our commitment is to provide the very best in terms of speaker quality and overall conference experience.
In the remainder of this post, I will discuss my favorite chapters ("Learning to Love JavaScript" and "Bootstrapping Agility") and some that I found interesting or ripe for recommendation ("Give It a REST" and "An Introduction to the Google Web Toolkit").
Favorite Chapters:
"Learning to Love JavaScript" - Chapter 3, Glenn Vanderburg
Glenn opens the chapter explaining why many Java developers missed the boat on JavaScript. Arguably, JavaScript was poorly named, baring only superficial resemblance to Java. Early implementations of JavaScript were plagued by problems that undoubtedly drove off many potential Java converts. First, early implementations were plagued with technical problems. Add to the technical problems the issues caused by various browser incompatibilities, and JavaScript was positioned to be hated by many developers. In addition, JavaScript became the de facto manner in which many sites adding very annoying actions such as scrolling banner and other visual effects - big turnoffs for technical types.
There also existed a sociological issue that JavaScript helped exacerbate. At the time JavaScript was beginning to become more widely adopted, many new 'developers' had recently shifted career gears to get into the web development game due to rapidly elevating salaries and high demand in the job market. This caused many people to quickly 'learn' JavaScript from snooping into the code borrowed from other web sites. Combined with the lack of good JavaScript books, the new class of developers were learning bad techniques and subsequently building buggy web sites.
Despite these issues, around 2000, JavaScript began to get traction when its communications capabilities were tapped to build a new class of remote scripting libraries. These were early versions of what is now known as AJAX. Around this same time, the netWindows project was started in an attempt to build a rich GUI environment that would operate inside web pages. The netWindows project developed later into the Dojo project, which is one of the most widely used AJAX toolkits available today. Finally, when Google developed Gmail, Google Suggest, and Google Maps, all but the blind could see that this was a whole new world of web. This pioneering work has transformed the Internet and how it is used.
Glenn goes on to describe his epiphany when he began thinking in Java and realized that much of beef he had with JavaScript is caused by what he calls missing limitations present in Java and other programming languages. He describes an application that we wrote using JavaScript, and the mistakes he made writing it while using JavaScript but thinking in Java.
This was an interesting chapter to read. I haven't read an overview of the history of JavaScript and it was interesting to understand the background events that influenced the development and adoption of JavaScript and to put my own memories of experiences with JavaScript into place in his timeline.
"Bootstrapping Agility" - Chapter 14, Venkat Subramaniam
This was easily my favorite chapter in the book. Venkat is the author of one of my favorite 'development practices' books, Practices of an Agile Developer and this chapter is another great work on a similar topic. The book discusses the 'things' a good developer does to be 'agile', while this chapter discusses how we can address architecture in an agile way.
What does an agile architecture look like? It is the product of agility at every step in the process of building software: planning, architectural development (including the role of architects), modeling, design, development, and testing. In short, an agile architecture is one that is able to (and does) undergo an evolutionary life cycle. The best architecture will be designed by someone (or a team) who knows the most about the problem at hand (all other things being equal), it only makes sense that your design team will get progressively better at building a suitable architecture. In order to leverage this increased understanding, the architecture must have been designed such that it can readily evolve as the problem becomes better understood and, perhaps, more generalized.
In the chapter, Venkat discusses some of the practices that agile architects exercise when designing a system:
Never Design Alone
I can't say it better than Venkat does in his chapter (p 199): "A design is an idea that you arrive at based on what you know. As what you know changes, the design will have to change as well. This is the evolutionary nature of design. You constantly evaluate your design and make adjustments. Refactoring is a continuous activity. Since the design depends on your knowledge and perspective, you have a better shot at arriving at a good design when you involve multiple people in the desing activity - never design alone. Design must be carried out by a small group of developers working closely with each other. A better design emerges when intelligent people are involved in passionate discussions."
You Aren't Gonna Need It - YAGNI
Einstein often made the argument that simplicity is no simple matter. He was arguing that the underlying design of the physical laws of the universe had to be quite simple, and that it was only our limited observations that complicated the elucidation of the simple laws. From the design perspective, our goal should be to design the system as simply as possible. The problem is that software architects and developers believe they can predict the future of a product's functionality and have become notorious for over-engineering solutions to problems. One common software development practice is to design a system to be more flexible than is required. The basic problem with this idea is that it is sometimes difficult to know ahead of time what flexibility will be required, meaning that the original solution might solve a need that never arises or solves the need inappropriately. The term YAGNI (You Aren't Gonna Need It) was coined to help prevent unnecessary design and development activities geared toward functionality that isn't required.
Don't Repeat Yourself - DRY
In short, each piece of functionality and each piece of information should have a single authoritative definition. When the same information or functionality is repeated throughout a system, the system becomes fragile and maintenance becomes a problem.
Single Responsibility Principle - SRP
Each function should have a single responsibility. Despite the intuitive feeling that this over-complicates a system and adds an endless collection of functions and classes to an otherwise simple project. However, through appropriate organization and naming, these issues can be much more easily managed than a smaller number of functions that perform multiple activities.
Notable Chapters:
"Give It a REST" - Chapter 6, Brian Sletten
Good reading for anyone who doesn't quite understand the debate between the REST and WS camps.
"An Introduction to the Google Web Toolkit" - Chapter 8, David Geary
Having never used the GWT, it was interesting to see the basics of the toolkit and what pieces of common web based tools Google has made considerably easier.
Resources:
- No Fluff Just Stuff Site
- No Fluff Just Stuff Software Symposium Series
- No Fluff Just Stuff Anthology, 2007
- No Fluff Just Stuff Anthology, 2006
- Practices of an Agile Developer
