Agility demands good Software Design

From what i have seen, Agile Software Development is widely misinterpreted nowadays. Many people think to be agile, they just need a process like scrum to define a framework of sprints and iterations. They will sprint until they exhaust and change until they stagnate. But when you'd ask them what principles of objectoriented design are, they'd answer: "Aww yes, we use classes". And when you'd asked them if they did test driven development, they'd reply: "Ahh, this is the thing where you write tests first, isn't it?". Bottom line, people think to be agile without caring about good software design. But in the end, the most important thing is what nobody cares about. It is the agility of the software that they are producing. So if you want to be agile, a process and a mindset is not enough. You need to keep your software agile. By that i mean, you need to keep the design of the software as clean and flexible as possible, to be able to apply any future changes at minimal cost. Software design of course includes your source code. In the end, you are only as agile as your software is.

Why Agile?

A customer does not know what he wants in the first place. He might have a rough idea, but thats it. We cant even blame him for that, because the actual problem that we are supposed to solve is influenced by so many factors and opinions that it is almost impossible to define the best solution right away. Other than that, miscommunication will most likely make things worse. To solve these issues we start small, and deliver fast. Seeing the first result, the customer can verify if we are on track or not. He can check if we have understood, or if he himself made a bad call. He might recognize things that he hasnt thought of before. Delivering repeatedly and iteratively like that, our software will more likely be useful and accepted by the customer in the end. It will more likely lead our project to success. Of course we will have to deal with changes more often, which is why we have to make the software itself agile. In the end it is the software which needs to be changeable, not us.

What it takes

Not only does an agile development process put our software under frequent change, it also demands progress at a fast and steady pace. These facts can quickly cause our software to rot if we don't watch out. And when it does, we get slowed down even more and changes suddenly become impossible. So we'd better not forget about the most important part in agile software development: Keeping our software design as agile as possible, from high-level architecture to the very code itself. Sadly, this gets ignored way too often, and many agile projects fail because of it. They fail because they chose to go faster by neglecting quality, and they quickly rush into a deadend of code rot leading to stagnation. So please remember: It is the Software you are building that needs to be agile in order to adapt to change defined by the customer. It is the software that needs to be agile in order to react to change with minimal effort. Rushing is not gonna make your software agile. Rushing is not gonna make YOU agile. Agility comes hand in hand with quality. And high quality is not even slow, hell no. Good quality done right makes you go even faster.

So what is Agile Software Design?

Agile Software Design is what makes your software as clean and flexible as you need it to be. It demands deliberate adoption of discovered and well established design patterns and principles of objectoriented programming. This is not easy. In fact it's hard, it's very hard. Even if you are really good and experienced at it, you might fail at some point, having to rethink many of your previous design decisions. Agile Software Design is not something that you can rush. It needs time and deliberateness. But it will pay off in the long term by making you progress at a more constant pace, which will in fact be much faster than it would be without agile design. The graphic below should clarify how quick ignorant rushing can slow you down tremendously. The graphic is not based on statistics, but on experience.

Agile Software Design does not end at high-level architecture. It goes on with coding. Bad code can quickly make your project more clumsy than a bad high-level design could. So the devil is in the details.

What can you do to make your Software Design more Agile?

From a Managers perspective? Trust your Developers, don't push them. Invest in experience and expertise.

From a developers perspective? First of all, learn the principles and patterns of objectoriented programming - not just in theory. Being good at those needs lots of practice. There are plenty of books for this:
and many more.

Keep your code clean - don't underestimate this! When you are programming, you spend more time reading code, than writing code. Thus you want to minimize the time you have to read code by making it more readable. It's not a secret how clean code looks like. Take a look at Clean Code.
Other than that, use the right practices like

Test Driven Development  

Just do it already. And if you don't know how, go on and start learning. I have heard numerous opinions of TDD where people said
  • "Unittests are too expensive. The Customer wont pay for that."
  • "Unittests slow us down, we needed to write more code in that time."
  • "I don't know. I'm pretty good at programming, Test-First feels needlessly hard and awkward."
But these are just subjective opinions of people who are not experienced in TDD.
TDD should in fact boost your longterm development speed if you are doing it right. I have not seen a single project in my life that has been as small and simple as that it would not have taken a significant profit from a TDD approach. And i have in fact seen very simple ones. The thing is, you have to test it anyways. What else would speed up your testing more than to automate it? Also, TDD significantly reduces the amount of time you have to spend debugging which already eats up lots of your time - at least more than you'd think. Other than that those tests
  • become a reliable documentation of your code,
  • allow you to fearlessly clean up your code,
  • force you to think of the problem before thinking of the actual solution, which will improve your initial draft,
  • enforce decoupling of components, which will make your design more agile.

Pair Programming

It's not only that 4 eyes will see more defects than 2 eyes do, but also that the transfer of knowledge is taking place. You want all developers to learn from each other to become equally valuable. And you always want more than one person to know a specific module to improve the truck factor. Heck yeah, some people even do mobprogramming - Seriously.

Collective Code Ownership

Don't allow one guy to own that modules code. All code on the project must belong to everybody. Everyone is allowed and invited to view, question and improve everyones code. This might be hard for some people, and might provoke conflicts, but it is absolutely mandatory to make the code better.

Code Reviews

Constantly review code changes. It is the only way to stay up to date, and it will reveal code smell. You need to reveal code smell, because if you don't, you will get stuck.

Refactoring

Refactor often. Everytime you see something that could be refactored, you need to do it right on the spot. The earlier you do it, the more time you save. So if you do it right then, you save the most possible amount of time.


tl;dr: You are just as agile as your software design, which of course includes code. High speed does not demand low quality. It doesn't work like that. In fact high quality is needed to allow high speed. Agile design evolves high quality.


to the comments

spring-data-rest in Action

What is spring-data-rest?

spring-data-rest, a recent addition to the spring-data project, is a framework that helps you expose your entities directly as RESTful webservice endpoints. Unlike rails, grails or roo it does not generate any code achieving this goal. spring data-rest supports JPA, MongoDB, JSR-303 validation, HAL and many more. It is really innovative and lets you setup your RESTful webservice within minutes. In this example i'll give you a short overview of what spring-data-rest is capable of.

Initial Configuration 

I'm gonna use the new Servlet 3 Java Web Configuration instead of an ancient web.xml. Nothing really special here.

public class WebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

@Override
protected Class<?>[] getRootConfigClasses() {
return new Class<?>[]{AppConfiguration.class};
}

@Override
protected Class<?>[] getServletConfigClasses() {
return new Class[]{WebConfiguration.class};
}

@Override
protected String[] getServletMappings() {
return new String[]{"/"};
}
}
WebAppInitializer.java on github

I am initializing hibernate as my database abstraction layer in the AppConfiguration class. I'm using an embedded database (hsql), since i want to keep this showcase simple stupid. Still, nothing special here.

@Configuration
@EnableJpaRepositories
@EnableTransactionManagement
public class AppConfiguration {

@Bean
public DataSource dataSource() {
EmbeddedDatabaseBuilder builder = new EmbeddedDatabaseBuilder();
return builder.setType(EmbeddedDatabaseType.HSQL).build();
}

@Bean
public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter();
vendorAdapter.setDatabase(Database.HSQL);
vendorAdapter.setGenerateDdl(true);

LocalContainerEntityManagerFactoryBean factory = new LocalContainerEntityManagerFactoryBean();
factory.setJpaVendorAdapter(vendorAdapter);
factory.setPackagesToScan(getClass().getPackage().getName());
factory.setDataSource(dataSource());

return factory;
}

@Bean
public PlatformTransactionManager transactionManager() {
return new JpaTransactionManager();
}
}
AppConfiguration.java on github

Now to the application servlet configuration: WebConfiguration

@Configuration
public class WebConfiguration extends RepositoryRestMvcConfiguration {
}
WebConfiguration.java on github

Oh, well thats a bit short isnt it? Not a single line of code required for a complete setup. This is a really nice application of the convention over configuration paradigm. We can now start creating spring-data-jpa repositories and they will be exposed as RESTful resources automatically. And we can still add custom configuration to the WebConfiguration class later if needed.

The Initialization was really short and easy. We didn't have to code anything special. The only thing we did was setting up a database connection and hibernate, which is obviously inevitable. Now, that we have setup our "REST Servlet" and persistence, lets move on to the application itself, starting with the model.

The Model

I'll keep it really simple creating only two related entities.
@Entity
public class Book {

@Id
private String isbn;

private String title;

private String language;

@ManyToMany
private List<Author> authors;

}
Book.java on github

@Entity
public class Author {

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
private Integer id;

private String name;

@ManyToMany(mappedBy = "authors")
private List<Book> books;

}
Author.java on github

To finally make the entities persistent and exposed as a RESTful webservice, we need spring-data repositories. A repository is basically a DAO. It offers CRUD functionality for our entities. spring-data takes away most of your programming effort creating such repositories. We just have to define an empty interface, spring-data does everything else out of the box. Still, it is easily customizable thanks to its design by convention over configuration!

The Actual Repositories


@RestResource(path = "books", rel = "books")
public interface BookRepository extends PagingAndSortingRepository<Book, Long> {
}
BookRepository.java on github


@RestResource(path = "authors", rel = "authors")
public interface AuthorRepository extends PagingAndSortingRepository<Author, Integer> {
}
AuthorRepository.java on github

Again, there is nearly no code needed. Even the @RestResource annotation could be left out. But if i did, the path and rel would be named after the entity, which i dont want. A REST resource that contains multiple children should be named plural though.

Accessing The Result

Our RESTful webservice is now ready for deployment. Once run, it lists all available resources on the root, so you can navigate from there.

GET http://localhost:8080/
{
"links" : [ {
"rel" : "books",
"href" : "http://localhost:8080/books"
}, {
"rel" : "authors",
"href" : "http://localhost:8080/authors"
} ],
"content" : [ ]
}

Fine! Now lets create an author and a book.

POST http://localhost:8080/authors
{"name":"Uncle Bob"}

Response
201 Created
Location: http://localhost:8080/authors/1
PUT http://localhost:8080/books/0132350882
{
"title": "Clean Code",
"authors": [
{
"rel": "authors",
"href": "http://localhost:8080/authors/1"
}
]
}

Response
201 Created
Noticed how i used PUT to create the book? This is because its id is the actual isbn. I have to tell the server which isbn to use since he cant guess it. I used POST for the author as his id is just an incremental number that is generated automatically. Also, i used a link to connect both, the book (/books/0132350882) and the author (/authors/1). This is basically what hypermedia is all about: Links are used for navigation and relations between entities.

Now, lets see if the book was created accordingly.

GET http://localhost:8080/books
{
"links" : [ ],
"content" : [ {
"links" : [ {
"rel" : "books.Book.authors",
"href" : "http://localhost:8080/books/0132350882/authors"
}, {
"rel" : "self",
"href" : "http://localhost:8080/books/0132350882"
} ],
"title" : "Clean Code"
} ],
"page" : {
"size" : 20,
"totalElements" : 1,
"totalPages" : 1,
"number" : 1
}
}

Fine!

Here is an Integration Test, following these steps automatically. It is also available in the example on github.

public class BookApiIT {

private final RestTemplate restTemplate = new RestTemplate();

private final String authorsUrl = "http://localhost:8080/authors";
private final String booksUrl = "http://localhost:8080/books";

@Test
public void testCreateBookWithAuthor() throws Exception {
final URI authorUri = restTemplate.postForLocation(authorsUrl, sampleAuthor()); // create Author

final URI bookUri = new URI(booksUrl + "/" + sampleBookIsbn);
restTemplate.put(bookUri, sampleBook(authorUri.toString())); // create Book linked to Author

Resource<Book> book = getBook(bookUri);
assertNotNull(book);

final URI authorsOfBookUri = new URI(book.getLink("books.Book.authors").getHref());
Resource<List<Resource<Author>>> authors = getAuthors(authorsOfBookUri);
assertNotNull(authors.getContent());
assertFalse(authors.getContent().isEmpty()); // check if /books/0132350882/authors contains an author
}

private String sampleAuthor() {
return "{\"name\":\"Robert C. Martin\"}";
}

private final String sampleBookIsbn = "0132350882";

private String sampleBook(String authorUrl) {
return "{\"title\":\"Clean Code\",\"authors\":[{\"rel\":\"authors\",\"href\":\"" + authorUrl + "\"}]}";
}

private Resource<Book> getBook(URI uri) {
return restTemplate.exchange(uri, HttpMethod.GET, null, new ParameterizedTypeReference<Resource<Book>>() {
}).getBody();
}

private Resource<List<Resource<Author>>> getAuthors(URI uri) {
return restTemplate.exchange(uri, HttpMethod.GET, null, new ParameterizedTypeReference<Resource<List<Resource<Author>>>>() {
}).getBody();
}
}
BookApiIT.java on github

Conclusion

We have created a complete RESTful webservice without much coding effort. We just defined our entities and database connection. spring-data-rest stated that everything else is just boilerplate, and i agree.

To consume the webservices manually, consider the rest-shell. It is a command-shell making the navigation in your webservice as easy and fun as it could be. Here is a screenshot:


The complete example is available on my github
https://github.com/gregorriegler/babdev-spring/tree/master/spring-data-rest
https://github.com/gregorriegler/babdev-spring



to the comments

Good Bye Redeployment. spring-loaded, an Opensource Classreloader

Redeem yourself from hot deployments and OutOfMemoryException. spring-loaded is an opensource classreloader and a promising alternative to JRebel. It does not offer as many features as JRebel does, and it does not support any framework just yet. Nevertheless, its a great tool that can save the time you are waiting for that servletcontainer to restart again.

What it can do:
  • add/modify/delete methods/fields/constructors
  • modify annotations on types/methods/fields/constructors
  • add/remove/change values in enum types
What it cant:
  • support framework specific changes like Spring MVC @RequestMappings
  • change log configuration on the fly
It is not getting the attention that it deserves, so give it a try.

Just download from github already, and add the following to your JVM parameters:
java -javaagent:<pathTo>/springloaded-{VERSION}.jar -noverify


to the comments

Why REST is so important

This post is dedicated to REST, an architectural style of shaping webservices and one of the most misunderstood concept in the history of IT. This post is addressed to you who is designing webservice apis not being fully aware what REST actually means. I'm trying to give you the idea. This post is also addressed to you who think to know what REST means, when in reality you have no clue, just yet. Yes i have met such people in the past - plenty of them. It's not going into the details of the Richardson Maturity Model, and it's not gonna make you a REST expert. There are plenty of guides on the web for that: slides, youtube videos, blogposts, books and more. Rather than going into the details, i'm going to link some good resources at the end of this post.

So lets start with

The meaning of REST

Representational State Transfer. This sentence is not only what REST stands for, it is also the tiniest possible description of what REST actually means. Didn't get it? Read it again: Representational State Transfer. It is not a standard, rather a style describing the act of transfering a state of something by its representation.

Lets consider this:
Marcus is a farmer. He has a ranch with 4 pigs, 12 chickens and 3 cows. He is now simulating a REST api while i am the client. If i want to request the current state of his farm using REST i just ask him: "State?"
Marcus answers: "4 pigs, 12 chickens, 3 cows".
This is the most simple example of Representional State Transfer. Marcus transfered the state of his farm to me using a representation. The representation of the farm is the plain sentence: "4 pigs, 12 chickens, 3 cows".

So lets get to the next level. How would i tell Marcus to add 2 cows to his farm the REST way?
Maybe tell him: "Marcus, please add 2 cows to your farm".
Do you think this was REST? Are we transfering state by its representation here? NO! This was calling a remote procedure. The procedure of adding 2 cows to the farm.
Marcus sadly answers: "400, Bad Request. What do you mean?"
So lets try this again. How would we do this the REST way? What was the representation again? It was "4 pigs, 12 chickens, 3 cows". Ok. so lets try this again transfering the representation...
me: "Marcus, ... 4 pigs, 12 chickens, 5 cows ... please!".
Marcus: "Alright !".
me: "Marcus, ... what is your state now?".
Marcus: "4 pigs, 12 chickens, 5 cows".
me: "Ahh, great!"
See? It was really not that hard and it was REST.

Why RPC is a pain in the A**

So why would you favor REST over the remote procedure call (=RPC) from a logical perspective? Because it dramatically reduces the complexity of our communication by making the representation our only contract. We do not have to discuss what kinds of procedures we need (Add a cow?, Add an animal of a type? Double the chickens amount? Remove all pigs?). All we have to discuss is the representation, and use this representation to achieve anything we want. Easy, isn't it? The needless complexity of RPC is not helpful at all. It is rather increasing the risk of misunderstandings, which we don't want. We don't want our communication to fail because Marcus and I understood a procedure differently.
But this is just one of many problems RPC is creating. If you want to use RPC you need to design some kind of structure to embed your procedure into. This structure requires a place to store parameters, error codes, return values and so on. I have seen lots of developers and companies who really did this. They designed their own RPC-Structure arising huge problems in the implementation of clients and client-server interaction. Why would you do this? Why would you invent your own RPC-Structure? Do you think this is helpful? What if i wanted to make an application that uses many WebServices of multiple proprietary RPC-Formats? I would have to develop something like this:
image #1

Ugh...
If you really need RPC, at least choose a standard like SOAP. Don't make up your own stuff!

But SOAP is still bad

Still, even the standards of RPC are really painful. Well, i have to admit that with ACID Transactions, and a complete standardized Service Description Language, SOAP is not all that bad in some circumstances. Nevertheless, the overhead SOAP produces is massive and a huge performance killer. HTTP is a lightweight protocol. Its headers include anything you need. The only thing you want to put in the body is a representation - or not even that.

Sessions are Evil

Since i wrote solely about sessions and why they are bad in another post, i removed this paragraph. Please continue reading here: Sessions. A Pitfall

Dont reinvent Hypermedia

Since hypermedia is getting quite popular now, i beg you: Don't invent your own style.
We do already have plenty. There is
And we are slowly getting to the situation in image #1 again.

Further Resources

In this post, i have only scratched the surface of the advantages of REST.
Here are some good resources to get you a deeper understanding.


to the comments

Spring MVC - @RequestBody and @ResponseBody demystified

In this post i want to dig into spring mvc a little, revealing what happens behind the scenes when a request is converted to your parameter object and vice versa. Before we start, i want to explain the purpose of these annotations.

What are @RequestBody and @ResponseBody for?


They are annotations of the spring mvc framework and can be used in a controller to implement smart object serialization and deserialization. They help you avoid boilerplate code by extracting the logic of messageconversion and making it an aspect. Other than that they help you support multiple formats for a single REST resource without duplication of code. If you annotate a method with @ResponseBody, spring will try to convert its return value and write it to the http response automatically. If you annotate a methods parameter with @RequestBody, spring will try to convert the content of the incoming request body to your parameter object on the fly.

Here is an example

@Controller
@RequestMapping(value = "/bookcase")
public class BookCaseController {

private BookCase bookCase;

@RequestMapping(method = RequestMethod.GET)
@ResponseBody
public BookCase getBookCase() {
return this.bookCase;
}

@RequestMapping(method = RequestMethod.PUT)
@ResponseStatus(HttpStatus.NO_CONTENT)
public void setBookCase(@RequestBody BookCase bookCase) {
this.bookCase = bookCase;
}

}

So what is Spring doing behind the scenes when we are using those Annotations?


Depending on your configuration, spring has a list of HttpMessageConverters registered in the background. A HttpMessageConverters responsibility is to convert the request body to a specific class and back to the response body again, depending on a predefined mime type. Every time an issued request is hitting a @RequestBody or @ResponseBody annotation spring loops through all registered HttpMessageConverters seeking for the first that fits the given mime type and class and then uses it for the actual conversion.

How can i add a custom HttpMessageConverter?


By adding @EnableWebMvc respectively <mvc:annotation-driven />, spring registers a bunch of predefined messageconverters for JSON/XML and so on. You can add a custom converter like the following

@Configuration
@EnableWebMvc
@ComponentScan
public class WebConfiguration extends WebMvcConfigurerAdapter {

@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> httpMessageConverters) {
httpMessageConverters.add(new BookCaseMessageConverter(new MediaType("text", "csv")));
}
}

In this example i've written a converter that handles the conversion of a BookCase, which is basically a List of Books. The converter is able to convert csv content to a BookCase and vice versa. I used opencsv to parse the text.

Here is the model

public class Book {

private String isbn;

private String title;

public Book(String isbn, String title) {
this.isbn = isbn;
this.title = title;
}

// ...
}

public class BookCase extends ArrayList<Book> {

public BookCase() {
}

public BookCase(Collection<? extends Book> c) {
super(c);
}
}

and the actual converter

public class BookCaseMessageConverter extends AbstractHttpMessageConverter<BookCase> {

public BookCaseMessageConverter() {
}

public BookCaseMessageConverter(MediaType supportedMediaType) {
super(supportedMediaType);
}

public BookCaseMessageConverter(MediaType... supportedMediaTypes) {
super(supportedMediaTypes);
}

@Override
protected boolean supports(Class<?> clazz) {
return BookCase.class.equals(clazz);
}

@Override
protected BookCase readInternal(Class<? extends BookCase> clazz, HttpInputMessage httpInputMessage) throws IOException, HttpMessageNotReadableException {
CSVReader reader = new CSVReader(new InputStreamReader(httpInputMessage.getBody()));
List<String[]> rows = reader.readAll();
BookCase bookCase = new BookCase();
for (String[] row : rows) {
bookCase.add(new Book(row[0], row[1]));
}
return bookCase;
}

@Override
protected void writeInternal(BookCase books, HttpOutputMessage httpOutputMessage) throws IOException, HttpMessageNotWritableException {
CSVWriter writer = new CSVWriter(new OutputStreamWriter(httpOutputMessage.getBody()));
for (Book book : books) {
writer.writeNext(new String[]{book.getIsbn(), book.getTitle()});
}
writer.close();
}
}

The Result 

We can now issue text/csv requests to our Resource along with application/json and xml which are basically supported out of the box.

1.)
PUT /bookcase
Content-Type: text/csv
"123","Spring in Action"
"456","Clean Code"


Response
204 No Content
2.)
GET /bookcase
Accept: text/csv

Response
200 OK
"123","Spring in Action"
"456","Clean Code"


Thanks to the design of spring mvc, which is following the single responsibility principle, our controller stays thin. We don't have to add a single line if we want to support new media types.

The complete example is available on my github


to the comments

Modern Web Development

In the last few years web technology has lived through rapid growth and heavy change. We went from frames to table layouts, to column layouts, to responsive layouts. From html4 to xhtml & flash to html5. From heavy server to rich client. From rpc to soap to rest. From sql to nosql and big data. From MVC to MVP and so on. In the following post i want to describe what has become state-of-the-art from my perspective.

A Backend is a REST api 

Every backend should be seen as a REST api and every controller as another resource. You want to analyze your problem domain, find your resources and design proper paths for them. They become the M in your MVC Architecture. Developing a webapplication first, and adding an extra REST api later on has to be considered an antipattern. If you do make a REST api, you want to consequently use it yourself, making your frontend its first consumer. This procedure allows you to smoothly add different kinds of clients later on, such as a mobile app or even a desktop application. It's also the foundation to integrate your applications features into other applications.

Separate your Frontend

The days when you made up a form using jsp with a jstl form validation are fading. You don't want to mix client with server technology anymore. The V and C of MVC has shifted over to the client and your backend just represents the Model. You want your frontend to be completely separated using client technology only (html/css/js) and consuming your REST api. GUI logic, building and aligning proper html elements can be achieved within javascript. The most appropriate content-type for information exchange between the backend and frontend would be json or even xml.

Rich Client & Hail JavaScript

The MVC pattern is nowadays implemented on the client side using javascript and it's fellow frameworks. There is no full-blown complete javascript framework that can achieve everything out of the box, but there are tons of smaller libs solving atomic tasks. This should not be considered bad or overwhelming, but advantageous. It causes a great variety of tools that focus on solving single problems outright. Backbone is a popular mvc framework built upon underscore, a js library delivering great utility with remarkable functional programming features. A template engine like mustache or handlebars could be added and requirejs would manage the dependencies within your modules. Of course, a dom manipulator like jquery cannot be left out. The trend is leading towards SPA's (Single Page Applications) with heavy AJAJ/AJAX, routing through html #anchors representing bookmarkable view-states.

Implement a Buildprocess for your Frontend

As Browsers are continously increasing javascript performance and adding more and more support for html5, frontends have become complex and sophisticated. You now want to add a build process for your frontend, compiling all your js and css files. You want to deliver only a single minified js file to the browser. Other than that we don't break the DRY principle writing styles anymore. We use dynamic stylesheet languages like less to make our styles smarter and cleaner and compile them to css in our build process. Node and rhino are possible engine candidates to build your frontend. While node is much faster, it requires an easy installation on the build server. Rhino runs in a jvm, thus not requiring an installation. You can add it to your project as a maven dependency.

Mobile Web & Responsive Design

Mobile devices are becoming more powerful in terms of hardware whilst html5 support is also rapidly increasing on mobile browsers. Html5 could potentially make native mobile applications obsolete one day. Localstorage, SQL, Geolocation, Multimedia, Camera Access, Web Sockets, Graphics, Touch Events, WebGL, Filesystem Access, Notifications and many more are all features to be completely available to mobile html5 webapplications one day, hopefully working on all devices. So far, we have been developing multiple applications for android/ios/windows mobile and so on, being an economic nightmare.
Mobile clients have gained a substantial amount in web consumership, and cannot be ignored anymore. Therefor you want to make your GUI reponsive, beeing able to scale down to smaller display-resolutions. Wise companies have even started designing userinterfaces for the smallest resolution before even thinking of a desktop resolution. This makes scaling more easy, since the other way round is harder and tends to force painfull workarounds. Bootstrap is one of many libraries that help you make your gui responsive. You can use initializr to get started.

GWT or ZK Framework? Use Neither!

GWT/ZK are trying do deliver a framework that makes it possible to develop modern ajax web applications using Java only. So they are basically building a java wrapper for frontend technology. Other than that, they deliver a huge amount of components. BUT ... i'd like to question their philosophy for many reasons.
  • They Both produce quite bad html code making you end in an element and dom-id nightmare that gets hard or even impossible to test, debug and style. Html5 allows to write short, clean and readable code, organized way better. You want to write html yourself.
  • Their AJAX calls are not based on the REST api that you need. If you want a REST api, you may have to write that again. RPC is GWT's primary communication-technology and i am really concerned about that. But you can still make a REST api work with GWT if you like to.
  • They keep you away from the technology that you are actually producing. Tiny customizations can get hard or even impossible in the end. You are basically giving up control and limiting your possibilities. This might in many cases lead to dead ends, that are based on the framework, not the technology. GWT helps to overcome this problem offering JSNI.
  • They are never up to date. While browsers are evolving rapidly, new features have to be implemented in the Java-Wrapper before you can even use them, delaying your up-to-dateness.
  • I doubt that wrapping native front-end technology is a good idea, and i don't see a reason for doing it. One pro GWT argument might be: it's generating optimized JS code.
In the end they make it easier to build webapplications for former java.awt/swing developers, who have no to little knowhow on html/css/js.
They defintively have their place right now and aren't a bad choice in some cases.


to the comments

What makes a great Developer

    Passion

    It's the taste of success that comes with every little task that you've mastered, and smart solutions you've found that turn out advantageous. Programming is not just a job, it's an Art - it's Poetry. With Passion comes Motivation and thus Progress. Software development is not only huge, but also evolving very fast. A good developer enjoy's keeping up-to-date, since he knows that there's always a better way to do something. Learning new ways, satisfies his hunger.


    Curiosity

    A Program is deterministic. There is no such thing as an accident in a computers world. Every effect has its cause. A great developer does not accept accidents. He'd rather search and debug the numerous layers of a Software and it's environment to find the very reason. He builds up deep knowledge by doing that, allowing him to better understand, read and interpret weird behaviour of an application. A good developer does not program by Accident.

    “The important thing is not to stop questioning. Curiosity has its own reason for existing.” - Albert Einstein

    "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." - 
    Nathaniel Borenstein



    Cognition

    Programming is the act of solving a problem. Problems can be factorized into multiple parts that work together as a whole. To find and reflect those in your mind, and imagine their interaction is a true skill. There is nothing more to say about that.


    Meticulosity

    Programming is full pitfalls that can be tracked down to the very microcosm of Software Development. The Devil is in the details, and even the smallest sluttery can easily tear a Project down. That's why perfection is so powerful, and important for high quality and success. If you accept a single flaw, you will most likely accept a second, ... and a third ... until you got a mess. A good developer cannot accept flaws and thus avoids many pitfalls increasing quality. There is an analogy to the Broken Windows Theory, which basically says that a single broken window can easily lead to more serious deviance, crime, abandonment and demolishment of its house.


    Time

    Greatness comes with experience. It's the iterations of improvement that have been lived through, that really matter. Yes, you can simply follow advices, patterns and best practice. But that has nothing to do with Wisdom, which evolves by doing mistakes and iterations.


    Humbleness

    A great developer knows that he doesn't, and will never know everything. He knows, that there is always room for improvement, also in his own work. He admits his mistakes and accepts critisism.


    Tenacity

    A good developer declares war on every workaround. He will fight it even if he has to struggle hour after hour, through the night, until the sun rises. Even the greatest developer meets problems, that he might not consider solvable in the first place. But he takes it as a challenge, unless it's not an antipattern. "It won't work" is not an option. Hard-earned success evolves self-confidence.

    Vision

    In Software development, it is common to work long times on small tasks. While beeing focused, it's easy to get lost and overlook the impact on the rest of the system. A good developer is skilled in keeping an eye on the bigger picture, foreseeing sideeffects of a current decision. Still he may intentionally choose to postpone their treatment going step-by-step.


    Lazyness

    This might sound stupid in the first place, but its not. Lazyness leads to a lot of improvements. The probably most important thing it leads to is Automation. Everytime you have successfully refused to do something manually by automating it, you have already improved. Automation is the key to faultlessness, efficiency and progress. Faultlessness, because ideally a computer doesnt make any mistakes (which is not entirely true in every aspect), but humans do real quick. Efficiency, because it's an investment saving time in the long run. The earlier you automate something, the more you get out of it. Progress, because every process that does not demand mental resources anymore leaves room for something else. What you don't have to think of doesn't hinder you, whereas software development is actually completely blown up with barriers that you have to think of all the time.

    A good developer is too lazy to
    • write a complete API doc, he lets JavaDoc do the job.
    • format his code properly, he lets his IDE do the job.
    • test a functionality over and over again, so he automates it using xUnit. 
    • read complicated methods, so he writes short readable methods with good names.
    • write the same lines of code all over again. He seeks for ways to refactor to avoid such boilerplate code, since he is too lazy to repeat himself. (DRY)
    • implement that functionality that nobody asked for. (YAGNI)
    • use bitwise shifting for a subtraction, he keeps it simple stupid (KISS).
    • write code at all, he lets his colleague do it for him (Pair Programming).
      Nah, i was just kidding on this one ;-) 

    What do you think makes a great developer?


    to the comments

    The Art of Naming


    1
    2
    3
    4
    5
    6
    7
    8
    public class Handler {

    private String data;
    private String temp;

    public int c(int a, int a2){
    int result = a+a2;
    //...


    Why is Naming so important?

    Because its a matter of Quality.
    Naming = Readability = Understandability = Maintainability = Quality.
    Good Names make your code readable, which is an essential feature for every person that has to work on it, including yourself. Soon after written, you'll forget about the details. Getting into it and understanding again can be tough and frustrating. The right Names will redeem yourself and others from those barriers. You'll might think for yourself: "No!!! I don't have the time to make this all clean and perfect. I just have to get the thing done as fast as possible, and it's no problem because i won't have to deal with it after its finished anyways..." - That's just wishful thinking. Software never ever becomes completed. Thats part of its nature. In fact, the opposite is the truth: By choosing the right names carefully, you save a lot of time from the very first day on. You keep your mind free of needless noise that slows your progression down.

    How to choose the right Names?

    According to "Clean Code", Names should:
    • Be intention revealing
    • Avoid disinformation
    • Make meaningful distinctions
    • Be pronounceable
    • Be searchable
    But i'll add one point
    • be unmistakable (which might already be part of avoiding disinformation)

    Be skeptical about a name in the first place, and dont accept it until every bit of skepticism has been eliminated. Complete Words are usually better than Acronyms, AND .... avoid redundancy!!

    1
    2
    3
    class Book{

    public String[] bookPage; // Don't repeat book since its given in the classname!

    The art is to combine good names so that your code becomes a meaningful, selfdocumenting story.

    1
    if(plant.needsWater()) gardener.water(plant)

    Classes, Interfaces and Abstracts

    Stay away from 'Manager', 'Handler' and the such. 'SomethingManager' doesn't mean anything specific and is clearly not unmistakable. Use Design Patterns in your Names. They are common knowledge and give a good information about what a Class is doing. Eg.: ShadowedBorderDecorator. Name Interfaces as what they are, and don't add Pre- / Suffixes to them (IFoo, BarInterface). Client-classes don't care if they work on Interfaces or Implementations. And it's not the Names job to indicate it's Type. You dont name a Variable intNumber either, do you? It's a violation of the DRY principle. Using Abstract in a Classname is debatable. While it's pretty common, it still violates the DRY principle. Decide for yourself.

    Common Errors in Variablenaming


    Repeating Type in Variablenames:

    1
    2
    3
    4
    Timestamp creationTime;
    Date date;
    String[] bookArray;
    SomeType somethingObject

    Adding "is" as a Prefix to booleans:
    isActive. So the getter becomes isIsActive() or what?

    Consecutive numbers.
    There is nothing harder to read than a calculation using a1, a2 and a3 multiple times.

    Generic names:
    temp, data, other, object, result, value and so on

    Inconsistency:
    Mixing multiple Naming Strategies, or choosing one without 100% sticking to it.
    E.g.: Mixing camelCase with under_scored


    to the comments

    Master the unpredictable

    Have you ever come to work on a Project that you cant quite overlook? Are Requirements not yet clear or changing fast? Here are some tips to get along.

    Use Tracer Bullets

    Don't specify your software to death. Just grab your best idea, and give it a shot. Tracer Bullets are similar to Prototypes with one very important difference. Prototypes are built to proove something, and then be thrown away. They are not intended for real production. Even some drawing on a paper could be a prototype. A Tracer Bullet might get thrown away, but it is not intended to in the first place. It is developed as stable, clean and complete as needed, to use it for real production. A Tracer Bullet that hits its target, becomes a trunk.

    Develop Leaves first

    What do i mean with a leaf? Leaves are small exchangable software components or modules, that can be written independently, tested in isolation, and sometimes even run autonomous. They only perform a very specific task, not more. Find the leaves in your Project, and start developing the leaf with the highest risk.

    Dont Reinvent the Wheel

    99% of the problems that you face in your project have already been solved. Solving these by yourself can easily become a waste of time. Even the most trivial seeming problems are not trivial at all. Underestimating those is the issue in the first place, nevertheless it happens all the time. Well, its just logical to understimate the unsolved as you cannot know all the details until you solved it yourself. Analysing the problemdomain, concepting and realizing a solution can be a great way to learn, but is not very beneficial. Its in fact a risk, since it can lead to misconception or become a timeconsuming task that exceed your resources. You might even have to throw away your first attempts. Also, your outcome would be buggy, whereas established opensource software is usually stable thanks to its brave communities.
    "Make or Buy" was a common phrase. I think it should be "Make or Find" by now, since opensource got really big. Rather invest your time into research opensource, and stay skeptical with what you find. When you compare 3rd party software, consider
    • Stability: Is it still beta, or did it have some stable releases yet? Who is the organization behind? Is the code clean and tested?
    • Activity: Can you find out how many developers this software has? When was the last commit? How frequently do they release a new build?
    • Support: Does it offer a good documentation? How about examples? Is there a public Issue Tracker? How many issues have been submitted yet and how many have been solved? Is there a Forum, literature, and a big community? Are there any big names that use this software?
    • Critisism: Is there anything bad that you should know in the first place? Search for reliable critiques and comparisons.

      Estimation is a waste of time

      Every hour that you invest in estimation, could also be invested in producing real outcome. Your estimation will be inaccurate anyway. When requirements change, you even have to change your estimations. If you have to estimate, because the business needs it, try to split your project into smaller independent parts first, and multiply your estimation with a risk factor (times two for example). In the end you`ll need it.



      to the comments

      Standalone Java Webapp made easy with Maven

      Introduction

      As you may already know, creating a war archive and deploying it on a preinstalled Servlet Container is not the only way running a Java webapp, since you can also embed the Web-Server in the application itself. Sometimes such artifacts are delivered as standalone executable programs that can be easily started and stopped in the commandline and even run as a service in the background. Maybe you should also consider producing your app this way and benefit from its huge advantages:
      • No preinstalled Webserver/Servlet Container required that would take additional maintenance.
      • Easy Cross-Platform. Same artifact can of course be run on any System.
      • Complete Standalone Software
      Apache Sonar is a great Example of such Software. It uses an embedded Jetty Server and creates an embedded H2 Database for persistence that can be replaced in configuration. As you can see here they prepared startup scripts for any Platform that execute the actual StartServer class.

      Embedded Tomcat

      In my tutorial ill use an embedded Tomcat as a Servlet Container. So we want to add the Maven dependencies first.

       1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      <!-- embedded Tomcat -->
      <dependency>
      <groupId>org.apache.tomcat.embed</groupId>
      <artifactId>tomcat-embed-core</artifactId>
      <version>7.0.37</version>
      </dependency>
      <dependency>
      <groupId>org.apache.tomcat.embed</groupId>
      <artifactId>tomcat-embed-logging-log4j</artifactId>
      <version>7.0.37</version>
      </dependency>
      <dependency>
      <groupId>org.apache.tomcat.embed</groupId>
      <artifactId>tomcat-embed-jasper</artifactId>
      <version>7.0.37</version>
      </dependency>

      We can use them now to create a StartServer class

       1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      public final class StartServer {

      private StartServer() {
      }

      public static void main(String[] args) throws Exception {

      // We will set the basedir Systemproperty accordingly when running the Program
      // Actually the mavenplugin appassembler will do this for us
      String basedir = System.getProperty("basedir");
      String webappLocation = new File(basedir + "/webapp").getAbsolutePath();
      int port = 8080;

      Tomcat tomcat = new Tomcat();
      tomcat.setPort(port);
      tomcat.addWebapp("/", webappLocation);
      tomcat.start();
      tomcat.getServer().await();
      }
      }

      Exploded War

      Now we need to make an exploded war in our "target" directory. I choose to create a folder inside "target" that holds the application as a whole including bin files, configuration and the webapp itself. This makes it easy to transport the complete app to another machine.
      • src/...
      • target/myapp/bin
      • target/myapp/conf
      • target/myapp/webapp
      Ill include the maven-war-plugin to create the exploded war.

       1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <version>2.3</version>
      <executions>
      <execution>
      <id>war-exploded</id>
      <phase>package</phase>
      <goals>
      <goal>exploded</goal>
      </goals>
      <configuration>
      <webappDirectory>${project.build.directory}/myapp/webapp</webappDirectory>
      <archiveClasses>true</archiveClasses>
      </configuration>
      </execution>
      </executions>
      </plugin>

      If you run mvn clean package right now you should get your webapp compiled into target/myapp/webapp

      Startup Scripts

      Finally we need startup Scripts to actually run our application. We need a shell script for unix Systems and a bat file for Windows. The Appassembler maven plugin comes in handy here. It is a very thoughtout plugin that creates exactly what we need and even sets the basedir Systemproperty. I'll configure it to use our exploded webapp and StartServer class.


       1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>appassembler-maven-plugin</artifactId>
      <version>1.3</version>
      <configuration>
      <assembleDirectory>${project.build.directory}/myapp</assembleDirectory>
      <repositoryLayout>flat</repositoryLayout>
      <repositoryName>webapp/WEB-INF/lib</repositoryName>
      <generateRepository>false</generateRepository>
      <copyConfigurationDirectory>true</copyConfigurationDirectory>
      <configurationDirectory>conf</configurationDirectory>
      <programs>
      <program>
      <mainClass>com.myapp.StartServer</mainClass>
      <name>myapp</name>
      </program>
      </programs>
      </configuration>
      <executions>
      <execution>
      <phase>package</phase>
      <goals>
      <goal>assemble</goal>
      </goals>
      </execution>
      </executions>
      </plugin>

      Done. Appassembler now creates executable scripts for all platforms inside the target/myapp/bin directory. You could even put configuration files into src/main/config that would be copied into target/myapp/conf automatically by the plugin.

      Result


      If we run mvn clean package now we get a completely transportable standalone webapp in our target directory!


      to the comments