Raible Designs

A Stressful, but Rewarding, Trip to Devoxx Belgium and Morocco

One of my favorite conferences in the world is Devoxx Belgium. First of all, it tends to have one of the most enthusiastic audiences I've ever seen. Secondly, its organizers are super awesome and challenge you to give great talks. Third, it was the first conference I ever took my Trish to. In 2011, I took her a second time and proposed to her in Paris afterward.

This year, I traveled to Devoxx Belgium for the first time without Trish. It was stressful because I didn't prepare well beforehand. However, it was also gratifying because I was able to make everything work, even it all happened at the last minute. Furthermore, I did the majority of my talks with good friends, which is always a pleasant experience.

The purpose of this blog post is to document my experience this year, so I can look back and say WTF was I thinking?!

I left Denver on Monday (November 6) afternoon and flew to Brussels, Belgium. My flight landed in Brussels at 9 am and Josh and my (three hour) talk was at 1:30 pm. I made it in time, but it was one of the first times we didn’t have a lot of time to prepare face-to-face beforehand. I learned that getting t-shirts printed in the US to save $500 is a good idea, but having to take two suitcases to carry them all is a bad idea.

We did our usual talk and I used Okta's new Angular SDK instead of the Sign-In Widget to showcase authentication. Even though the crucial step I needed was contained in my notes, I failed. One simple line to add an HttpInterceptor and I missed it!

I think I followed up well with a tweet that showed how to fix it. But who knows how many people use Twitter. One things for sure, people tweet more at Devoxx Belgium than any other conference I’ve ever been too! In fact, the #Devoxx hashtag got hijacked by some porn sites and their tweets started showing up on the Twitter wall. 

I tweeted about what I forgot to do after our talk.

Josh and my talk was published on YouTube the very next day, which is awesome.

Getting Started + Testing with Angular CLI and Angular 2 (RC5)

I started creating Angular 2 applications when it was in beta (back in March). To keep up with Angular 2's changes, I wrote a tutorial about developing with RC1 in June. Earlier this month, RC5 was released and many things changed once again. I think Scott Davis sums it up nicely in a tweet.

To keep up with the rapid pace of change in Angular 2, I decided to write another tutorial, this time using Angular CLI. The biggest change I found since writing the last tutorial is testing infrastructure changes. Since Angular's Testing documentation hasn't been updated recently, hopefully this tutorial will help.

Google's Mirror of Maven Central 25% Faster

Last week, Takari announced that Google is Maven Central's New Best Friend. While writing a news article about this for InfoQ, I decided to run a small test to see the speed of the default Maven Central versus the new Google Cloud Storage instance. This micro benchmark didn't seem worthy of including in the article, but I think it's interesting to see the speed improvements I found.

I ran rm -rf ~/.m2/repository, then mvn install with the default repository configured. I ran the commands again with Google Cloud Storage. I found that the downloading of dependencies, compilation and running unit tests on AppFuse's web projects averaged 4 minutes, 30 seconds. With Google Cloud Storage, the same process averaged 3 minutes and 37 seconds. By my calculations, this means you speed up artifact resolution for your Maven projects by 25% by switching to Google. To do that, create a ~/.m2/settings.xml file with the following contents.

<settings>
  <mirrors>
    <mirror>
      <id>google-maven-central</id>
      <name>Google Maven Central</name>
      <url>https://maven-central.storage.googleapis.com</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
</settings>

Benchmark Details
My tests were run on a Mac Pro (late 2013) with a 3.5 GHz 6-Core Intel Xeon E5 processor and 32 GB of RAM. Bandwidth speeds during this test averaged 57 Mbps down, 6 Mbps up. Below are the timing numbers (in minutes) from my test:

Default: 4:33, 4:36, 4:32, 4:24, 4:09
Google: 5:13, 3:35, 2:15, 3:38, 3:39

Google had some wide variances in its results, with five minutes and two minutes. Because of this, I dropped the low and high numbers for each service before calculating the average. My math with raw numbers is below.

Default:
273, 276, 272, 264, 213 = 260, 4:20
276, 272, 264 = 270, 4:30

Google:
313, 215, 135, 218, 219 = 220, 3.66 = 3:40
215, 218, 219 = 3:37

Chen Eric commented on the InfoQ article to note that Chinese programmers are blocked from using Google.

Update: Jason Swank of Sonatype has done some more extensive benchmarking and found different results.

We found that average unprimed Google API (first mvn run) caching performed 30% slower than Maven Central. Primed Google API cache performance (second run) was 3% faster then Maven Central (second run). We also ran a number of cloud-based tests with similar results.

The JHipster Mini-Book: How We Did It and What's Next

Last Friday, the JHipster Mini-Book was published on InfoQ. I wrote about this milestone on the book's blog. I'm pumped to see this release happen, and I'd like to give you a behind-the-scenes peak at how it went from idea to production.

The Idea
At the end of last year, I wrote down my goals for 2015:

• 21 Point Fitness App
• JHipster Mini Book (InfoQ)
• Finish Bus
• New House
• Good Blood Pressure

My reason for wanting to write a JHipster Mini-Book was simple: I knew AngularJS, Bootstrap and Spring Boot quite well. I'd used them on several projects and I really liked how JHipster married them all together. I often ran into people that used these technologies, but hadn't heard of JHipster. I was hoping to make more people aware of the project and market my development skills at the same time.

SpringOne 2GX 2015: My Presentations on Comparing Hot JavaScript Frameworks and NoXML

Last week, I had the pleasure of traveling to Washington, DC to speak at the annual SpringOne 2GX conference. I was pretty stressed for the last few weeks because I had to create two new presentations from scratch, and both had to be 90 minutes long. I was also hoping to finish the JHipster Book before the conference started. I was able to finish both presentations in the nick of time, but did not find the time to write the last chapter in the JHipster Book.

The first presentation was titled Comparing Hot JavaScript Frameworks: AngularJS, Ember.js and React.js. I started by revisiting the Comparing JVM Web Frameworks talk I did at vJUG last February. I explained how I think traditional web frameworks are no longer relevant in 2015, but I do believe server-side rendering is still very relevant. From there, I used Yevgeniy Brikman’s framework scorecard (from his Node.js vs. Play Framework presentation) to rank each framework by a number of different criteria. You can see the final results on slide 160. Since the scores were so close, I believe you could tweak some scores a bit (or add weights to the different criteria) and make any of the frameworks come out on top.

You can click through the presentation below, download it from my presentations page, or see it on SlideShare.

I started writing the second presentation a week before I had to deliver it. On Thursday, September 10th, I stayed up late, trying to figure out how to create a good presentation on NoXML and finish the last part of the JHipster Book. Then it came to me, I needed to parallelize and do them both at the same time. I decided to compare AppFuse (which is similar to a legacy Spring application with lots of XML) to JHipster (which hardly contains any XML).

I wrote a 10-page Google Doc on how I planned to do this, then went rafting and camping with my family for the weekend. I finished most of the presentation on Monday night, but then realized the presentation wouldn't be long enough to fill 90 minutes. So I hunkered down at midnight, created a new AppFuse application and removed a bunch of its XML. This took me until 3:30am, and I was able to accomplish the following tasks:

• Spring XML to Java
• Spring Security Configuration to Java
• web.xml to WebApplicationInitializer
• Spring MVC to Java
• Migrated to Spring Boot
• Maven to Groovy

I was pretty pumped when I completed my final goal: converting to Spring Boot and getting a test to pass. I made commits to an appfuse-noxml project on GitHub as I accomplished each step. You can see all the changes in the project's commit log. While I'd figured everything out, I still needed to complete the presentation. Luckily, I found time to do this the night before, the morning of, and in the final hour before I had to deliver the talk. You can imagine my relief when I was done delivering both talks.

You can click through the presentation below, download it from my presentations page, or view it on SlideShare.

While I didn't get to spend much time at the conference, I did have a lot of fun while I was there. I got to meet some new folks, reconnect with old friends, and enjoy beers and dinner with a smiling crew on Thursday night. The Broncos victory late that night was the icing on the cake.

AppFuse 3.5 Released!

The AppFuse Team is pleased to announce the release of AppFuse 3.5. This release contains a number of improvements.

• XML reduced by 8x in projects generated with AppFuse
• CRUD generation support for Wicket, as well as AppFuse Light archetypes (Spring Security, Spring FreeMarker and Stripes)
• Upgraded Tapestry to 5.4
• Integrated Spring IO Platform for dependency management
• Refactored unit tests to use JUnit 4
• Renamed maven-warpath-plugin to warpath-maven-plugin
• Upgraded to jWebUnit 3 for AppFuse Light integration tests
• Updated all AppFuse Light modules to be up-to-date

For more details on specific changes see the release notes.

What is AppFuse?
AppFuse is a full-stack framework for building web applications on the JVM. It was originally developed to eliminate the ramp-up time when building new web applications. Over the years, it has matured into a very testable and secure system for creating Java-based webapps.

Demos for this release can be viewed at http://demo.appfuse.org. Please see the QuickStart Guide to get started with this release.

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find any issues, please report them on the users mailing list. You can also post them to Stack Overflow with the "appfuse" tag.

Thanks to everyone for their help contributing patches, writing documentation and participating on the mailing lists.

We greatly appreciate the help from our sponsors, particularly Atlassian, Contegix, and JetBrains. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project.

Converting an Application to JHipster

I've been intrigued by JHipster ever since I first tried it last September. I'd worked with AngularJS and Spring Boot quite a bit, and I liked the idea that someone had combined them, adding some nifty features along the way. When I spoke about AngularJS earlier this month, I included a few slides on JHipster near the end of the presentation.

This week, I received an email from someone who attended that presentation.

Hey Matt,
We met a few weeks back when you presented at DOSUG. You were talking about JHipster which I had been eyeing for a few months and wanted your quick .02 cents.

I have built a pretty heavy application over the last 6 months that is using mostly the same tech as JHipster.

• Java
• Spring
• JPA
• AngularJS
• Compass
• Grunt

It's ridiculously close for most of the tech stack. So, I was debating rolling it over into a JHipster app to make it a more familiar stack for folks. My concern is that it I will spend months trying to shoehorn it in for not much ROI. Any thoughts on going down this path? What are the biggest issues you've seen in using JHipster? It seems pretty straightforward except for the entity generators. I'm concerned they are totally different than what I am using.

The main difference in what I'm doing compared to JHipster is my almost complete use of groovy instead of old school Java in the app. I would have to be forced into going back to regular java beans... Thoughts?

I replied with the following advice:

JHipster is great for starting a project, but I don't know that it buys you much value after the first few months. I would stick with your current setup and consider JHipster for your next project. I've only prototyped with it, I haven't created any client apps or put anything in production. I have with Spring Boot and AngularJS though, so I like that JHipster combines them for me.

JHipster doesn't generate Scala or Groovy code, but you could still use them in a project as long as you had Maven/Gradle configured properly.

You might try generating a new app with JHipster and examine how they're doing this. At the very least, it can be a good learning tool, even if you're not using it directly.

Java Hipsters: Do you agree with this advice? Have you tried migrating an existing app to JHipster? Are any of you using Scala or Groovy in your JHipster projects?

AppFuse, Reduced

In November, I had some time off between clients. To occupy my time, I exercised my body and brain a bit. I spent a couple hours a day exercising and a few hours a day working on AppFuse. AppFuse isn't used to start projects nearly as much as it once was. This makes sense since there's been a ton of innovation on the JVM and there's lots of get-started-quickly frameworks now. Among my favorites are Spring Boot, JHipster, Grails and Play.

You can see that AppFuse's community activity has decreased quite a bit over the years by looking at its mailing list traffic.

Even though there's not a lot of users talking on the mailing list, it still seems to get quite a few downloads from Maven Central.

I think the biggest value that AppFuse provides now is a learning tool for those who work on it. Also, it's a good place to show other developers how they can evolve with open source frameworks (e.g. Spring, Hibernate, JSF, Tapestry, Struts) over several years. Showing how we migrated to Spring MVC Test, for example, might be useful. The upcoming move to Spring Data instead of our Generic DAO solution might be interesting as well.

Regardless of whether AppFuse is used a lot or not, it should be easy to maintain. Over the several weeks, I made some opinionated changes and achieved some pretty good progress on simplifying things and making the project easier to maintain. The previous structure has a lot of duplicate versions, properties and plugin configurations between different projects. I was able to leverage Maven's inheritance model to make a number of improvements:

Building a REST API with JAXB, Spring Boot and Spring Data

If someone asked you to develop a REST API on the JVM, which frameworks would you use? I was recently tasked with such a project. My client asked me to implement a REST API to ingest requests from a 3rd party. The project entailed consuming XML requests, storing the data in a database, then exposing the data to internal application with a JSON endpoint. Finally, it would allow taking in a JSON request and turning it into an XML request back to the 3rd party.

With the recent release of Apache Camel 2.14 and my success using it, I started by copying my Apache Camel / CXF / Spring Boot project and trimming it down to the bare essentials. I whipped together a simple Hello World service using Camel and Spring MVC. I also integrated Swagger into both. Both implementations were pretty easy to create (sample code), but I decided to use Spring MVC. My reasons were simple: its REST support was more mature, I knew it well, and Spring MVC Test makes it easy to test APIs.

Camel's Swagger support without web.xml
As part of the aforementioned spike, I learned out how to configure Camel's REST and Swagger support using Spring's JavaConfig and no web.xml. I made this into a sample project and put it on GitHub as camel-rest-swagger.

This article shows how I built a REST API with Java 8, Spring Boot/MVC, JAXB and Spring Data (JPA and REST components). I stumbled a few times while developing this project, but figured out how to get over all the hurdles. I hope this helps the team that's now maintaining this project (my last day was Friday) and those that are trying to do something similar.

Developing Services with Apache Camel - Part IV: Load Testing and Monitoring

Welcome to the final article in a series on my experience developing services with Apache Camel. I learned how to implement CXF endpoints using its Java DSL, made sure everything worked with its testing framework and integrated Spring Boot for external configuration. For previous articles, please see the following:

• Part I: The Inspiration
• Part II: Creating and Testing Routes
• Part III: Integrating Spring 4 and Spring Boot

This article focuses on load testing and tools for monitoring application performance. In late July, I was asked to look into load testing the new Camel-based services I'd developed. My client's reason was simple: to make sure the new services were as fast as the old ones (powered by IBM Message Broker). I sent an email to the Camel users mailing list asking for advice on load testing.

In reply, I received suggestions for Apache's ab tool and Gatling. I'd heard of Gatling before, and decided to try it.

TL;DR

This article shows how to use Gatling to load test a SOAP service and how to configure Log4j2 with Spring Boot. It also shows how hawtio can help monitor and configure a Camel application. I hope you enjoyed reading this series on what I learned about developing with Camel over the past several months. If you have stories about your experience with Camel (or similar integration frameworks), Gatling, hawtio or New Relic, I'd love to hear them.

It's been a great experience and I look forward to developing solid apps, built on open source, for my next client. I'd like to get back into HTML5, AngularJS and mobile development. I've had a good time with Spring Boot and JHipster this year and hope to use them again. I find myself using Java 8 more and more; my ideal next project would embrace it as a baseline. As for Scala and Groovy, I'm still a big fan and believe I can develop great apps with them.

If you're looking for a UI/API Architect that can help accelerate your projects, please let me know! You can learn more about my extensive experience from my LinkedIn profile.

[Read More]