Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Leasons learned from using Seam

Yesterday, I noticed the Seam Developers released a new seamframework.org site. It's great to see a web framework team eating their own dog food. Of course, if all open source framework developers were paid full-time to work on their respective project, we'd likely see more of this.

My favorite part of the new site is the Forums, which has an Atom Feed you can use to monitor topics posted. This morning, I noticed a topic from Daniel Hinojosa titled ANN: amazinggates.com is alive with Seam & lessons learned. In this topic, Daniel lists a number of lessons he learned from working with Seam.

We deployed our web site at amazinggates using JBoss Seam. I would lie if I said it was it easy, but the reason I had some issues is that I didn't believe a lot of documentation.

  • I had refused to use Facelets, instead I used JSP. All I can say to newbies is don't do it. You owe to yourself to drop JSP like a bad habit.
  • I had refused to use Seam Managed Persistence and ended with LIES.
  • I had refused to use Seam-Gen, and used my own folder structure. I still use my folder structure, but only after I used Seam-Gen and learned what I had to do to make my integration tests work.
  • I had used 2.0 when it was still in CR and Beta releases. Although that is neither my fault or the Seam's fault, the greatest result was that I learned tremendously what Seam had to offer, and I was able to provide JBoss with some bugs, and help users in the forum.
  • It took 8 hours to learn that Seam's AJAX4JSF solution was the best solution on the planet.
  • I used faces-config for page navigation. Ok, and that was just stupid.
  • I didn't know what components.xml was for the longest time. I'm really going to take part of the blame on this one. I read the documentation and even after reading it I still had no idea what components.xml was for. I realized that if the documentation said that components.xml maps components to names the way it does in Spring XML configuration. I wouldn't have spent that much time.
  • I had refused to use Renderer.render for email, because I didn't believe that the view should be the place for the rendering. So I was going to use a StringTemplate solution. That was dumb, it took a while for me to realize that generating emails in the view was the BEST place to do so.
  • Integration testing was a bitch. That wasn't my fault, or Seam's fault. It really was the Microcontainer's fault, and I hope that that ends up better in the long run. I heard through the grapevine that really no one is working on the EJB Microcontainer and it is still stuck in Alpha. Redhat needs to invest some people into it. It really is THAT important.

So, all in all, I love the new website, and I love what JBoss Seam has to offer. I am excited with what it has to offer, and I will still continue to build my business around it. Good work to the team that made JBoss Seam possible.

The one thing I noticed about Daniel's "Amazing Gates" site is it seems extremely fast. Do you think this is because of Seam or did he follow the rules for high performance websites?

Posted in Java at Feb 13 2008, 12:19:27 PM MST 3 Comments

The New Javalobby Sucks?

I didn't say it, Jesse Sightler did. Even though he didn't say "it sucks" explicitly, that's what I read in his post:

Is it just me, or has the new Javalobby proven to be a significant step backwards? The old site was a Slashdot style discussion system with a pace very appropriate to the pace of news flowing from the Java community. The light emphasis on announcements was welcome, and useful while at the same time not being overstated.

The new site feels a lot like TheServerSide.Com from a few years ago. They've gone to a system where the frontpage is updated frequently (many times per day) and the content there is seldom interesting enough to attract any significant discussion. Unfortunately, this means that the overwhelming number of articles on the frontpage appear dry and uninteresting. I don't think I've really read anything there since the switch to the new format.

For the sake of the site, I do hope they figure out their mistake here. There is no shame in turning this into worsethanfailurethedailywtf all over again (hopefully you get that reference).

I like the new site because I visit it more than the old one. Of course, that could be a direct result of me posting there. If I could change one thing, I'd like to see a java.blogs-style aggregator of all zones (then I'd turn off the .NET and Kids Code Zones).

Do you agree with Jesse? Should Javalobby change back to the old-way of using forums?

I believe the reason for the change was because DZone has become so much more popular than Javalobby. I think they're hoping to capitalize on that brand name and extend it to other communities. Look at the following graph from Alexa for proof. More traffic = more $$ from advertisers.

Posted in Java at Feb 12 2008, 11:26:50 AM MST 18 Comments

Maven now supports attributes in pom.xml?!

In December 2005, I asked Is it possible to make pom.xml simpler?.

After seeing what the Spring Developers have done to simplify Spring context files, I can't help but think the same thing is possible for Maven 2's pom.xml. Is it possible to add namespaces and make something like the following possible?

Before:

    <dependency> 
      <groupId>springframework</groupId> 
      <artifactId>spring</artifactId> 
      <version>1.2.6</version> 
    </dependency> 

After:

<dep:artifact name="org/springframework/spring" version="1.2.6"/>

Or just allow attributes to make things a bit cleaner?

<dependency groupId="org.springframework" artifactId="spring" version="1.2.6"/>

At that time, the general response was "That's how Maven works. It's a matter of taste. You'll get used to it." It's been two years and sure, I'm used to it, but I'd still rather write less XML. That's why I was particularly pleased to see Brett Porter's write Maven now supports condensed POMs using attributes:

The issue is being tracked under MNG-3397.

The result is that something like this:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>3.8.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>easymock</groupId>
  <artifactId>easymock</artifactId>
  <version>1.2_Java1.3</version>
  <scope>test</scope>
</dependency>
...

Halves in length to something like this:

<dependency groupId="junit" artifactId="junit" version="3.8.1" scope="test"/>
<dependency groupId="easymock" artifactId="easymock" version="1.2_Java1.3" scope="test"/>
...

Now that wasn't so hard was it? ;-)

Posted in Java at Feb 11 2008, 03:45:57 PM MST 4 Comments

Web Application Frameworks based on Real-World Popularity

I received an interesting (spam?) comment on my What Web Application framework should you use? entry today:

A useful resource to compare Java web frameworks (Spring, Tapestry, Struts, OpenLaszlo,...) and also PHP, Python, Ruby web frameworks:

http://www.therightsoft.com/softwaretechnologies/webframeworks

If you go to the site, you'll see they have a hierarchical list of web application frameworks based on real-word popularity. First of all, I'm unsure of what "real-word" popularity is.

Let's assume this is a typo and it should be "real-world" popularity. Where is the credible source for this data? Where is the link to this credible source? I like the list, its sortability and filterability, but there's no evidence that it's true. Care to elaborate on your sources [email protected]?

Posted in Java at Feb 11 2008, 03:10:57 PM MST 10 Comments

Building a Better Maven with Ant

It looks like the Ant folks are thinking of building a better Maven.

I see many developers adopt Maven because they want a build system able to provide common features with no effort. Most of them don't want to spend much time writing an Ant script, or have seen or heard that maintaining Ant build scripts is troublesome. So they choose to use Maven only because it's easy to use for common use cases: install, write a simple pom of a few lines or generate it using an archetype, and you're ready to compile, test and package your new project following the Maven standard structure. They also get dependency management for free, and with only a few more effort they have multi module builds, and some nice features like code analysis, coverage, and a set of report gathered in a web site. That's really nice and that's what I like about Maven.

But Maven suffers from a lack of flexibility and robustness IMHO. And later the same people who first adopted Maven because of its perceived ease of use become frustrated when they need to tweek the system to their own needs or don't understand how the release plugin work. Then some of them go back to Ant, first having to go through a sometimes painful road to describe their whole build system in xml, especially if they aren't Ant experts. Others try to use new build tools like raven, buildr or others.

I really like Ant, and think it is a very good basis for robust and flexible build systems. People with enough knowledge of Ant can write very good build systems, testable, maintainable and adaptable. But you need to get your hands dirty, and you need to get a good knowledge of some of the mechanisms which can make an Ant based build system manageable: import, scripts and scriptdef, macrodef, presetdef, and so on. [Read More]

What do you think - is this a good idea?

I agree that Maven has its warts, but I don't think it's that bad. I've also heard that Maven has been successfully implemented at large companyies like eBay, Intuit and E*Trade[1]. Is the "Maven sucks" meme largely something that exists in the blogosphere, but not in the real world?

I think the biggest benefit of Maven is dependency management. I think it makes your code more modular and easier to build. Rather than having a monolithic source-code tree that depends on itself being built in a certain order, you can have individual modules that pull dependencies from a central location. This can be done with Maven's Ant Tasks as well. I don't see a problem with building a better Maven with Ant, but to try and build a better Central Repository sounds like a nightmare to me. The current repository has been improved for years and is much better than it was a couple years ago. That being said, I would love to see somebody build a more accurate Central Repository. Ideally, it'd be done sometime next week. ;-)

[1] I could be wrong about these companies. If you're a developer at one of these companies, please confirm or deny. Any comments on Maven's success at these companies would be great as well.

Update: Speaking of Maven, there's an interesting comment on a Javalobby post I wrote:

With all the critical remarks the Maven project is receiving, wouldn't it be time for some Maven project lead to step up and explain the team's position? Or is it completely deaf to the sentiments? How many builds have to fail, how much more headaches are needed before others start their own version of Maven and do it the right way (like Don [Brown])?

Seems like an excellent question to me. Guys?

Posted in Java at Feb 11 2008, 02:07:12 PM MST 18 Comments

Maven 2 Archetypes get a much needed improvement

Yesterday, a new version of the Maven Archetype Plugin was released. This release incorporates many of the improvements that were developed in a different project - code named "Archetype NG". The two major improvements are 1) you only have to use "mvn archetype:create" now and 2) you can create archetypes from existing projects.

I haven't tried #2, but #1 seems to work pretty well (especially since AppFuse archetypes are the first 9 ;-)).

[Read More]

Posted in Java at Feb 09 2008, 03:20:00 PM MST 15 Comments

Reviews: Getting Started with Grails, Rails for Java Developers and Groovy Recipes

Two weeks ago, I mentioned a number of books I was hoping to read to get up to speed on Rails and Grails quickly. Over the last two weeks, I was able to polish off three of these (listed in order of reading):

Below are short reviews of each book.

Getting Started with Grails
Getting Started with Grails The Good: This is the perfect book to learn the basics of Grails quickly. At 133 pages, I was able to read this entire book in one sitting. The first couple chapters are very introductory, but likely necessary for beginners. The good news is you start writing your first Grails application on page 7 (Chapter 3).

Chapter 4 (Improving the User Experience) is good in that it shows you how to do warning, error and confirmation messages. This is something often overlooked in web frameworks and Rails and its "flash" concept seem to have made it important again. I remember way back in 2003 when I complained about frameworks not allowing messages to live through a redirect - everyone said it was something you didn't need. Now it's a standard part of most web frameworks.

The Bad: Uses Grails 0.3.1. This is understandable since the book was written in 2006 and published in 2007. Also, it doesn't cover testing that much (5 pages). If testing is so easy with Groovy and if Grails has Canoo WebTest support built-in, it should be shown IMO.

Rails for Java Developers
Rails for Java Developers The Good: This was an interesting book for me because it uses AppFuse for many of its Java-based examples. Unfortunately, it uses the Struts 1.x version which is cumbersome and verbose as far as Java web frameworks go. The most impressive part of this book is how Justin and Stu do an excellent job of walking the line and not insulting Java nor developers using it. They provide an easy to understand view of Rails from a Java Developer's perspective. There's detailed chapters on ActiveRecord (as it compares to Hibernate), ActiveController (compared to Struts) and ActiveView (compared to JSP). This book has excellent chapters on Testing, Automating the Development Process and Security.

The Bad: This book was published over a year ago, so it uses an older version of Rails. This means some commands don't work if you're using Rails 2.0. It's also a little light on Ruby, so I didn't feel I learned as much about the language as I was hoping to. That's understandable as it's more of a Rails book than a Ruby book.

Groovy Recipes (Beta from Jan 3, 2008)
Groovy Recipes The Good: I really like the style of this book and that it shows you how to get things done quickly with code samples. It's very no-nonsense in the fact that it contains a lot of code and howtos. I really like Scott's writing style and found this book the easiest to read of the three. This may have something to do with my eagerness to learn Groovy more than anything. The most refreshing part about this book is how up-to-date it is. Because it's a Beta, it seems to contain the most up-to-date information on Groovy and Grails. After reading Getting Started with Grails and working with it for a couple weeks, the first Grails chapter seemed a little basic - but that's likely because I've figured out how to mix all those recipes already. The Grails and Web Services chapter definitely has some interesting content, but I've rarely had a need to implement these recipes in a real-world environment. I'd rather see recipes on testing the UI (with the WebTest plugin) and how to use GWT and Flex with Grails. If SOUIs are the way of the feature, this is a must.

The Bad: Not much information on testing with GroovyTestCase, mock objects or implementing Security. If one of Groovy's sweet spots is testing, why isn't there more coverage on this topic? The Java and Groovy integration chapter is especially good, but there's very limited information on Ant and Maven. It's likely the websites provide sufficient documentation, but the Maven section only fills 5 lines on an otherwise blank page. The biggest problem I have with this book is I really like the recipes writing style and would love to see more tips and tricks. At 250 pages, I was able to finish this book with pleasure in a few days.

What's Next?
Now I'm reading JRuby on Rails (Apress) and Programming Groovy (Pragmatic Programmers). Following that, I'll be perusing dead-tree versions of Struts 2 Web 2.0 Projects (Apress), Prototype and script.aculo.us (Pragmatics) and Laszlo in Action (Manning). If any publishers want to send me books on GWT and Flex, I'd be happy to add them to my list. ;-)

Posted in Java at Feb 09 2008, 11:34:57 AM MST 10 Comments

There is no "best" web framework

From Mike Clark's blog, I learned about a number of TED Talks. As a fan of Malcom Gladwell, I was drawn to What we can learn from spaghetti sauce. In this talk, he talks about the research that Howard Moskowitz did for spaghetti sauce and how it changed the food industry forever. Here's a couple of quotes I wrote down:

"When we pursue universal principles in food, we aren't just making an error, we are actually doing ourselves a massive disservice."
...
"The difference between coffee at 60 (% satisfied) and coffee at 78 is the difference between coffee that makes you wince and coffee that makes you deliriously happy."
...
In embracing the diversity of human beings, we will find a sure way to true happiness.

Can this thinking be applied to web frameworks as well? What if it's not about choosing the best framework for your type of application? What if it's all personality related?

» Read more and comment on Javalobby.

Posted in Java at Feb 06 2008, 03:04:24 PM MST

Grails 1.0 and JRuby on Rails on WebSphere

A couple of interesting things happened today that relate to my Grails vs. Rails quest for knowledge.

The first is that Grails 1.0 was released. This was apparently a huge event as it swamped Codehaus' servers for a couple hours. This morning, it was pretty cool to shake Graeme's hand and congratulate him on the release. I also got to meet Jeff Brown for the first time. Who needs to go to a conference when you get to talk to these guys at work? ;-)

Secondly, I found an article by Ryan Shillington that shows how to deploy a Rails application to WebSphere. To me Rails + WebSphere seems like the last thing a Rails advocate would want - but who knows. In my experience, most developers that use WebSphere don't do it by choice.

For companies that have invested a lot of time and money into the JVM as a platform, it seems like Grails is the clear winner over Rails. However, the line gets blurry when you start talking about JRuby. I think JRuby will get there, but I don't believe it's there yet. If you look at the two major JRuby on Rails success stories (from Oracle and Sun), they've had to fix performance issues as part of their projects. With big companies investing in the platform, it's highly likely performance will be fixed in the near future. I believe both the Groovy and JRuby teams have said performance enhancements are their top priority for their next releases.

I think the biggest news related to performance of dynamic languages on the JVM is the new Da Vinci Machine project.

This project will prototype a number of extensions to the JVM, so that it can run non-Java languages efficiently, with a performance level comparable to that of Java itself.

Dynamic languages on the JVM seem to have a very bright future.

I got involved with Struts and Spring just before their 1.0 releases. Is it simply a coincidence that I happened to start looking into Grails right before its 1.0 release?

Posted in Java at Feb 05 2008, 11:32:12 PM MST 1 Comment

Groovy, Rails needs Components, RIA Frameworks compared and faster WebTests

Here's some interesting snippets I found while reading blogs today:

  • Stop writing plain old Java code. Groovy obsoletes plain old Java. We ought to just say "Java 7 = Groovy" and move on. -- Stuart Halloway
  • So far my experience is that I love the Ruby language and don't want to go back to doing Java except when/if I need to to pay the bills. But Rails I'm not as sold on. Mind you I'm not here to bash on Rails, there are some great things there and other people have done a fine job of praising them. But there are some things I definitely miss from Tapestry, and the most significant one is components. -- MysteryCoder
  • If you're looking for maximum control over presentation and the best possible appearance for the finished product, I would say Flex is probably the way to go. If you're a Java developer using Java on the server side, or you just can't stand the thought of having your app run in the Flash player and would prefer JavaScript, GWT is probably going to work out very well for you. Open Laszlo is going to offer a great deal of platform versatility, but at the expense of some polish and features available in the other two frameworks. - Kevin Whinnery in Three RIA Platforms Compared: Adobe Flex, Google Web Toolkit, and OpenLaszlo
  • A new experimental feature of WebTest allows to specify the number of threads that should be used for the tests what can bring enormous speed improvements without modification of the tests. -- Marc Guillemot

To summarize: use Groovy over Java, Rails needs components, Flex is the best RIA framework and WebTest keeps getting better. These aren't my words, but I don't see much fault in them either.

Posted in Java at Feb 05 2008, 12:30:34 AM MST 6 Comments