We're up in Reston at the No Fluff, Just Stuff conference from April 19-21 learning about a myriad of open source technologies, design patterns, architecture techniques, and just about everything else that a bunch of IT geeks would want in a tech-heavy weekend. We'll be following up on the cool seminars, speakers, and topics in the coming weeks, but we want to single out a few really interesting ideas and concepts covered each day while they're fresh on our minds.

We'll be covering a list of highlights that seemed most impactful, valuable, or interesting each day. Don't expect anything too comprehensive; if you're intrigued, feel free to research more on your own, or look out for detailed blog posts on some of these topics as our group has a chance to further digest and follow-up on everything learned.

Here are the highlights from Day 1.

1. HATEOAS, or Hypermedia as the Engine of Application State

"Giving Spring some REST" by Craig Walls

Rather than a fixed interface, REST clients can interact with servers dynamically through hypermedia provided by application servers. This is an incredibly cool concept, allowing for dynamic identification of service endpoints and API's from a given service response. More to come, but think about the rich client-side applications you could write with a sophisticated HATEOAS endpoint!

Here's an example of a service providing HATEOAS data in a response (derived from the "Giving Spring some REST" presentation compiled by Craig Walls):

	"links" : [
			"rel" : "self" 
			"href" : ""
			"rel" : "all"
			"href" : ""

2. JavaScript Module Pattern

"JavaScript Patterns" by Raju Gandhi

The JavaScript module pattern, indirectly, can be used to imitate private and public variables/methods in JavaScript functions. By using an immediately executing function, with short-lived member variables and functions that exist only to facilitate object construction/defintion, we can easily make specific functions and variables inaccessible and hidden from external clients.

In the example below, x, y, coords, and the printCoords() function remain hidden:

var geoModule = (function(lat, long) {
	var x = lat;	
	var y = long;
	var coords = lat + "," long;
	function printCoords ( return coords; }
	return {
		function getX : function() { return x; }
		function getY : function() { return y; }
		function getCoords : printCoords;
}(56.002, 72.123);

3. Maven is Past its Prime!

"Build Your Own Technology Radar" by Neal Ford

XML fatigue and plug-in based architecture limit build tools to grow gracefully as projects become more complex. Language based build tools such as Gradle and Rake offer finer-grained abstractions and longer term flexibility.

4. Use Reset CSS!

"Web Application Design from a Developer's Perspective" by Raju Gandhi

When a HTML page with absolutely no style is loaded, it still is rendered with some style - style based the specific browsers default settings. As you can imagine, these default settings are inconsistent among various browsers. One way to level set is to reset the browser defaults first and then add your style on top of it. This will make default look more consistent across browsers, and thus spend less time fighting with browser defaults. The following link lists a few widely used reset stylesheets:

5. Tools for OSGi

"OSGi Demystified" by Kirk Knoernschild

Bndtools is a project to help create and embed OSGi bundle metadata within JAR files via an integrated set of Eclipse plugins. Kirk stressed working without the IDE first to get an understanding of how the metadata in MANIFEST.MF works. Using OSGi Blueprint Service metadata we can also declare micro-services via require and provide semantics for the container to enforce strict runtime modularity. Kirk also stressed utilizing patterns of modular architecture to guide refactoring from very coarse grained modules to more fine-grained modules.

6. Modular Architecture

"Modular Java Architecture - TODAY!!" by Kirk Knoernschild

Consider modules as first-class citizens when defining a solution architecture. In Java terms, a module is a jar file. Oftentimes, the concrete, deployable components of a solution are overlooked in favor of component and package/class interaction aspects of the architecture. Modularity provides reuse, composition, and a flexible (independent) deployment strategy, and does not necessarily require frameworks such as OSGI or Jigsaw to be beneficial. Modularity can be phased into an existing architecture: consider modularizing each conceptual layer (think n-tier architecture) as a starting point.

7. SOLID vs. OO and Function Approaches

"Functional Solid" by Matt Stine

The SOLID design principles are intended to guide developers to create systems that are more maintainable. Some of the basic concepts of OO and how we develop are seemingly at odds with SOLID. Functional languages, which have recently garnered attention in the development community, can greatly enhance alignment with the SOLID principles.

As an example:

"The Single Responsibility Principle" states that "A class (module) should have only one reason to change." If we think about objects, they fundamentally have 3 "meta-"responsibilities. They model state, model behavior and model identity. In functional languages, a function is a first class citizen alongside data types. Functions provide behavior. Data elements are immutable and therefore can only have one state. In this way, functional languages by their nature, better help the developer realize the "Single Responsibilty Principle".

8. Spring Data Repositories

"Spring Data" by Craig Walls

Spring Data repositories can be leveraged to reduce the implementation effort for the data access layer in your application. Simply create an interface that extends one of the out of the box Repository interfaces (JpaRepository, MongoDBRepository, etc.) and Spring will provide several stock operations for you, such as standard CRUD operations, paging, and sorting. Additionally, you can create custom query methods by simply adding a method signature to the interface following a given set of naming conventions. Spring Data will provide the implementation at runtime, so there's no need to actually implement the logic!
public interface UserRepository extends JpaRepositoryUser, String> {
	ListUser> findBySSN(String ssn);
	ListUser> findByFirstNameAndLastName(String firstName, String lastName);

9. JavaScript Singleton Pattern

"JavaScript Patterns" by Raju Gandhi

The Singleton pattern is thus known because it restricts instantiation of a class to a single object. The Singleton pattern can be implemented by creating a class with a method that creates a new instance of the class if one doesn't exist. In the event of an instance already existing, it simply returns a reference to that object.

//Instance stores a reference to a Singleton.
 var instance;
 (function init() {
 var instance;
 Singleton = function(){
 if ( !instance ) {
 instance = init();
 return instance;

10. Keynote: Chesterton's Gate: Always Ask Why

Kirk Knoernschild

We need to ask ourselves why we do the things we do. Often times the answer is because "that's how it's always been done". One of the interesting "Why" questions that came up during this talk was "Why do people use Waterfall?".

As it turns out the Waterfall approach was introduced in a paper by Dr. Winston Royce in 1970 called "Managing the Development of Large Software Systems". In the first few pages of this paper, he explains the steps of the waterfall process. Apparently that is as far as most people read. If you read the rest of the document Dr. Royce has this to say:

"I believe in this concept, but the implementation described above is risky and invites failure".

He spends quite a bit of the rest of the paper explaining the benefits of using an iterative approach to eliminate these risks.

So the next time you run into a waterfall project, you'll know "why".... because someone, a long time ago, didn't bother to read beyond the first few pages that explained it.