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.

Maven Integration for Eclipse

If you're a Maven user and like Eclipse, you might want to checkout the new Maven Integration Plugin for Eclipse 0.9.0. Euxx has a couple blog posts talking about the new features - looks like pretty cool stuff to me.

The second feature is especially cool. If your dependencies supply SCM information - you can import the project from its source control system. Maven may have warts, but it also has incredible potential.

Posted in Java at Mar 12 2008, 04:22:43 PM MDT 2 Comments

Scott Bain on Writing and Publishing a Book

Scott Bain has an interested blog entry called Writing and Publishing a Book:

I recently completed the process of getting a book published ("Emergent Design"). It was my first time doing this, and I thought it might be valuable to some of you if I shared some of the things I learned about writing a book, and about the publishing world.
...
Now, it turns out that I made a bit of a mistake, but got lucky.

The mistake? I wrote the book, then went to the publisher. This can lead to a real disaster. You may have written a beautiful, smart, compelling book for which there is no market whatsoever. Even a great book that nobody wants to read is worthless.

In my case, I knew there was a market because the market had asked me to write the book. Still, if I'd gotten involved with the publisher earlier, several things would have happened:

  1. They would have kept me on a writing schedule. From time to time I got lackadaisical about getting the book done, and the publisher would have held my feet to the fire a little. That would have been healthy for me.
  2. They would have reviewed chapters as I wrote them, which would give me early and frequent feedback. In other words, I would have gained all the benefits of using a Lean/Agile approach.
  3. They would have helped me write. I didn't realize that publishers have extensive support mechanisms to help their authors; access to peer-review, copy editors, technical editors, and so on.
In other words, they would have really smoothed the process. [Read More]

Good to know - thanks Scott! I've been thinking about writing a book again and was actually considering writing first and shopping for a publisher later. I guess that's the wrong approach eh?

Posted in General at Mar 12 2008, 04:12:29 PM MDT 3 Comments

Grails vs. Rails - My Thoughts

In a comment, Jared Peterson asked:

I'm curious if you have any thoughts on folks that might be trying to make a decision between Rails and Grails. I like the concept of "Allow Both", but what if you "have neither"?

If you were starting a new project, could choose either one, needed to interact with a lot of existing Java code (JRuby on Rails I guess), what would you pick?

A friend recently asked me "Can I solicit your honest, unadulterated opinion on Grails?" I think the e-mail I sent him may help Jared's question.

I think it's awesome. IMO, it's the same thing as AppFuse, but it has a DSL that's much simpler to learn and remember. Less code -> faster productivity. There does seem to be some maturity issues, but I think it'll get there. The question is - how fast can Groovy become. It's similar to Rails and Ruby in that you start using Grails and you think "This Groovy thing is kinda cool, I'd like to learn more." One of the reasons I really like it is the learning curve for experienced open source Java Developers is virtually flat. You can learn enough to be productive in a single day.

That being said, I think there's also a lot of cool stuff going on with RIA. IMO, Flex or GWT + Grails would be a really fun set of tools to develop with. Here's a excerpt from a write-up I recently did when analyzing Rails and Grails at LinkedIn (in January):

--------
Comparing Rails and Grails
They're both excellent frameworks. Rails is definitely more mature, but the environment is a pain to setup (esp. on Windows). Grails is very easy to setup for Java Developers. Grails needs a lot of improvement as far as hot deploy and stack traces. It's probably Groovy's fault, but its stack traces are hideous - rarely pointing to the class and line number in the first few lines.

As for hot deploy, it doesn't work nearly as well as it does with Rails. Rails' "script/server" starts WEBrick in a few seconds, while "grails run-app" can take up to 10 seconds (even on a brand new application). Even with its warts, Grails is simply awesome. I really, really enjoy writing Groovy code in IDEA and seeing immediate changes. I don't like "test-app" as much as I like Rails' "test:units" (or even better, "test:uncommitted"). It seems to be widely realized that Rails has a better testing story.

Rails is immediate, Grails is immediate 70% of the time.

Groovy is extremely easy to learn for Java Developers. Ruby is easy too learn, and possibly too powerful for OO rookies. Both are fun to program in and very capable of allowing greater developer productivity. If you know Hibernate, Spring, SiteMesh and JSP, you owe it to yourself to look at Grails. If you know these technologies well, you can learn Grails in less than an hour. You can be productive in the next hour and have an application running by the end of the day. That's not to take anything away from Ruby. I believe that Rails is an excellent platform as well. It's pretty cool that profiling and benchmarking are built into the framework and you can easily judge how many servers you'll need to scale.

I used IDEA while developing with both frameworks. IDEA has Rails and Groovy support available via plugins and they both worked quite well. The support for Grails was much better than Rails. Grails offers code completion, Ctrl+click on classes/methods, debugging and starting/ stopping the webapp from your IDE. Rails doesn't offer much in the way of Ctrl+clicking on class names/methods or debugging.
--------

Is there anything that Rails can do that Grails can't? Not as far as I can tell. I think it really comes down to developer passion and team preference. If you have experienced Java Developers that like the ecosystem and its tools, Grails makes a lot of sense. If you have experienced PHP developers or frustrated J2EE developers, they might enjoy Rails more. One thing that's very cool about both frameworks - learning one actually teaches you things about the other. They're so similar in many respects that knowledge is transferable between the two.

Of course, this is all just my opinion after working with both frameworks for a few weeks. For anyone who has tried both, what do you think?

In closing, here's an excerpt from a recent comment I left on Javalobby:

Of course, the hard part now is deciding between Django, Rails, Grails and GWT for your web framework. Then again, that's like having to choose between a Ferrari, Porsche, Lamborghini and a Maserati. No matter which one you choose, it's unlikely you'll be disappointed.

Posted in Java at Mar 07 2008, 05:12:00 AM MST 15 Comments

The LinkedIn Journey Continues

As you might know, I've spent the last several months working for one of the coolest clients ever: LinkedIn. They hired me back in July 2007 and I was impressed on day one. I was originally hired to help them evaluate open source Java web frameworks and try to determine if moving from their proprietary one to an open source one would help improve developer productivity.

After looking at all the options, I recommended we look at Struts 2 and Spring MVC - primarily because they seemed to be the best frameworks for a LinkedIn-type of application. Another Engineer and I prototyped with Struts 2 for about 6 weeks and came up with a prototype that worked quite well. While our mission was successful, we found a couple issues with Struts 2 and standard JSP that might actually hurt developer productivity more than it helped.

Following this project, I worked on the New Homepage Team, which is now visible to everyone that logs onto LinkedIn. My role was minimal, but it was still a very fun project to work on. You know those widgets in the right panel? I did the initial UI and backend integration for those. All the business logic, Ajax/JavaScript, CSS, and optimization was done by other folks on the team. Shortly after this project went live in November, I started prototyping again with Spring MVC + JSP.

The reason I was asked to prototype with Spring MVC was because they were using Spring on the backend, Spring MVC in a couple other projects, and a new project was being kicked off that used Grails. Rather than add another framework (Struts 2) to the mix, they wanted to see if they could suppress any further framework proliferation.

After a month of prototyping with Spring MVC + JSP, my results weren't as good as Struts 2. With Struts 2, I was able to use OGNL to do all the things their current JSP implementation allows them to do (call methods with arguments, use statics in EL, etc.). With standard JSP, a lot of this wasn't possible. If it was - it required writing lots of tag libraries and made it more cumbersome for developers to do certain things. At the end of that project, I determined that using FreeMarker might solve these problems. I also determined that neither Struts 2 nor Spring MVC would solve the ultimate problem of developer productivity. Neither framework would allow developers to go from make-a-change-and-deploy, wait-3-minutes-to-see-change-in-browser to make-a-change, save and wait-15-seconds-to-see-change-in-browser.

I recommended that this be the ultimate goal - to get rid of the deployment cycle and to allow minimal turnaround when deploying modified classes. After that problem was solved, it's true that moving to an open source web framework would likely provide an easier-to-remember API. However, the problem with moving to a new web framework would be that everything used to construct the existing site would suddenly become legacy code.

In the end, we concluded that the best solution might be to enhance the existing framework to be more like the available open source options. This would allow existing applications to keep using their code -- and if we enhance properly -- new applications can use a simpler, less verbose API and a templating framework that's easier to understand. We can make LinkedIn's version of JSP more like standard JSP while allowing its powerful EL to remain. We can add support for JSP Tag Libraries and Tag Files.

One of the benefits of moving to an open source web framework is there's a community, documentation and books that describe the best (or most common) ways to solve problems with the framework. LinkedIn has this, but it's all in code and no one seems to have a high-level of confidence that the way that they did it is the "best" way. Developers communicate well, but all the knowledge is stuck in their heads and inboxes - there's no way for new developers to search this knowledge and figure it out on their own without asking somebody.

By adopting an open source web framework, it's possible to solve part of this problem, but I think it's still going to exist - where a few engineers know how to use the framework really well (for the specific application) and the rest don't. We determined that regardless of open source vs. proprietary framework, what was needed was a set of developers that acted as authorities on how to develop web applications at LinkedIn. A UI Frameworks Team if you will. This would be their only job and they would never get pulled from this to work on projects or complete tasks related to LinkedIn's products. Some developers mentioned that they'd been asking for this for years, and some folks had even been hired for this. However, the formulation of this group has never happened and it's obvious (now more than ever) that it'd be awesome to have them.

The UI Frameworks Team
At the end of 6 months, it seemed my work was done at LinkedIn. I liked the idea of a UI Frameworks Team and recommended they start it with the authors of the existing web framework. They agreed this was a good idea. A few days later, I was pulled into the CTO's office and he offered me the job. He offered me the challenge of building this team and told me I could do it remotely (from Denver) and hire my own people to help me with it. I gulped as I realized I'd just been offered the opportunity of a lifetime. I knew that while this might not be the best option for LinkedIn, it certainly was an excellent opportunity for me. I said I'd think about it.

In the meantime, I was given a project which you might've read about. They asked me to migrate a Rails application to Grails and try to determine if they really needed both frameworks. I spent 2 weeks coming up to speed on both and flew to Mountain View to deliver my conclusion. Here's an excerpt from an internal blog post I wrote.

As far as I know, Rails has been used at LinkedIn for well over 6 months and Grails has been used for a similar duration. Both projects that've used these technologies have enjoyed extreme success. Both projects have been fun for the developers working on them and both have improved the technologies/frameworks they're using.

Here's an interesting quote about the Rails application:

Another app you might want to look at is BumperSticker, our facebook app. Interestingly we heard through joyent that DHH (the creator of Rails) told them that BumperSticker is the biggest rails app in the world (in terms of page views) - we are closing in on 1 billion monthly page views and we have 1 million unique users per day (about 10 million installs on FB). It's a little trickier to setup in a dev environment since you need to be running on FB, but the code itself is pretty interesting since we've iterated on it a bunch of times and are making extensive use of third party libraries such as memcached.

This quote loosely translates to "We have some Rails Ninjas on staff and we've been quite successful in developing with it and making it scale".

Both platforms have allowed developers to iterate quickly and turbo-charge their productivity.

My Conclusion: Allow Both

Why?

If you have talented developers that can whip out kick-ass code with either platform, pay them and pay them well. Passion is the most important part of any job. If developers are passionate about the application they're developing and the language they're using (notice language is secondary) - they can do great things.

I know this probably isn't the answer you wanted to hear, but it's what I believe. I think both frameworks are very similar. I believe the knowledge you gain from learning one framework is transferable to the other. A lot of the things I learned about Rails worked with Grails. Ruby's syntax is similar to Groovy's.

There's a natural synergy between these two frameworks. The hard part is figuring out when to use which one.

The application that I was asked to port from Rails to Grails? The one that was launched last week - LinkedIn Mobile.

After doing this research, I stepped up to the plate and accepted the offer to start a UI Frameworks Team and recruited some kick-ass Java Developers I know to be the founding members. Last week, I flew out to Mountain View to do some kickoff meetings and start getting the infrastructure in place so we can document, support and release code like a well-oiled open source project. There's nothing saying we won't use an open source web framework as the underlying engine, but I think this should be an excellent chance to see the power of open source governance and development style in a corporate environment.

Director of Engineering, Core Experience
I should mention one last thing. If you're an experienced Java Developer/Architect with a passion and deep knowledge of UI development (JavaScript, CSS, HTML), we've got a Director of Engineering, Core Experience position with your name on it. I might even get to interview you if you apply for this job. Furthermore, whoever gets hired will likely work very closely with my team. What's not to like about that!? ;-)

Posted in Java at Mar 06 2008, 08:00:49 AM MST 19 Comments

Spectacular Weekend at Whistler

This past weekend, some friends and I headed up to Whistler Blackcomb for a weekend of great skiing. We have a college buddy who's getting his PhD in Vancouver, so that's what motivated the trip. I've never skied in a place where the mountains were so huge. I've skied Jackson Hole and Mammoth, but apparently Whistler has a lot more elevation gain. This was proven when we skied the "Peak to Creek" run on the last day. We didn't do the 6.5 mile run because one guy was on a snowboard.

It snowed 8" on our first day and a few more on our last day. There was plenty of powder and lots of really steep runs. I highly recommend it - especially if you want to spend some money. It's not a cheap place to visit and it'll likely get more expensive since it's hosting the 2010 Winter Olympics. The good news is I got a 50% discount on lift tickets with my Winter Park pass. Whistler Blackcomb is owned by Intrawest - the same folks that own Winter Park and Steamboat.

Double Black T-Bar

Long Lines The Longest Run

For more pictures, see Whistler 2008 on Flickr. This weekend's destination? Vail for day #19.

Posted in General at Mar 05 2008, 10:19:38 PM MST 3 Comments

A Look Inside the Guinness Brewery

Guinness Guy Kawasaki has a post about The Art of the Perfect Pint Pour. In it, he posts a number of pictures from a tour he took of the Guinness Brewery in Dublin, Ireland. I was in Dublin with my parents in 1998 and we missed the tour by 5 minutes. It's nice to see what the inside actually looks like.

Speaking of Guinness, do you have any special plans for St. Patrick's Day this year?

It's my sisters birthday (on March 17th), so I'm heading to her place (Chelan, Washington via Oregon) next weekend. My Dad booked train tickets from Salem, Oregon to Seattle. I love trains - especially now that I've re-activated my EVDO card. Its download speed isn't much faster than my BlackBerry Pearl (38.8 KB/sec vs. 25.4 KB/sec), but its upload speed is quite a bit faster (13.5 KB/sec vs. 2.3 KB/sec). Should be a fun trip.

Posted in General at Mar 05 2008, 09:49:30 PM MST 1 Comment

Selenium User Meetup Videos Posted

Videos of last week's Selenium User Meetup have been posted on YouTube. You can watch them below or click on the video to watch it on YouTube. Enjoy!

Lightning Talks

Q and A Session

Posted in Open Source at Mar 05 2008, 09:19:23 PM MST 1 Comment

Powder Day at Whistler

We arrived at our hotel late last night in Whistler. It was pretty warm out and we didn't believe the 20cm forecast for today. When we woke up this morning, we were pleasantly surprised. A Powder Day at Whistler - what more could you ask for?

Snow Report

Going to Whistler Powder Day at Whistler

Posted in General at Mar 01 2008, 09:05:58 AM MST 2 Comments

Jack's got a bead stuck in his nose!

From Jack's Nose This morning around 9:45 AM, I got a call from Jack's Teacher. She said, "Jack's got a bead stuck in his nose!" I heard a screaming kid in the background, so the first thing I asked was - "Is that Jack?" She said yes, and I was out the door a few seconds later.

Several minutes later, I arrived at his school and picked him up to take him to the Emergency Room. His teacher handed me the bead you see in the picture on the right. This was a replica of the one he jammed into his nose. I figured the ER was the best place to go considering all I saw was blood when I looked in his nostril.

10 minutes later we were in the ER and within a half hour we were talking to a nurse. Julie arrived just as the doctor walked up to talk to Jack. The first thing he suggested was that Julie hold one nostril and give him a CPR-type breath/blow into his mouth. She tipped his head back, plugged the free nostril and "pop!" - it came right out!

I wish I'd known that trick early this morning. How cool would it have been to walk into Jack's class, grab him by the head and blow that sucker out like I knew what I was doing? The good news is now you have this knowledge and you can be the hero in your kid's class someday. ;-)

Posted in General at Feb 28 2008, 11:41:34 PM MST 16 Comments

Last Night's Selenium Users Meetup at Google

Last night, I attended the inaugural Selenium User Group meetup at Google's Campus in Mountain View. It was an excellent event, with many of the core committers on hand to present and answer questions. Each presenter had about 5 minutes to speak and we learned many things about the Selenium Project itself, what's coming in the future and how Google has standardized on Selenium as their integration testing tool of choice.

Patrick Lightbody started the meeting by going over a number of project statistics with pretty graphs and such. There were simply too many numbers to write down, so hopefully his slides will be published soon. I was pleased to see that Google did videotape the entire event, so it should be available online soon. I'll update this post when it it. Below are my notes from the event.

Jason Huggins, Test Engineer at Google
Selenium is a test automation framework. Some folks abuse it as a macro tool. There's two reasons Selenium became so popular: it was able to test Ajax before any other testing tool and it allows end-to-end workflow testing. Selenium works on any platform, with any browser and allows many, many languages. It's possible that other frameworks that are more focused are better. There are 4 Selenium products:

  • Selenium Core (TestRunner)
  • Selenium IDE (for Firefox)
  • Selenium Remote Control
  • Selenium Grid

Paul Hammant, Open Source Manager at Thoughtworks
Selenium 1.0 - beta this week. RC, Core, Grid and IDE together. 1.0 will be shipped in a few weeks. Compared to today, lots of bugs killed, documentation improved and a greatly improved Selenium IDE.

Selenium 1.1 will be shipped in a couple months. Selenium IDE will be enhanced to obey RC instruction ... becoming the best mode of operation when it ships.

Some experimental iPhone-Safari capability (dependent on SDK for iPhone).

Selenium 2.0 will hopefully be released this year. Roll in of WebDriver functionality and code. New model-based API. IE plugin and Safari plugin (not really a plugin, most likely uses AppleScript).

Philippe Hanrigou (http://ph7spot.com)
Testing is good! Selenium is awesome! However, end-to-end web testing is slow. It is and always will be slow. How do you solve this problem? You solve it the same way we've solved slow traffic in the past - by building more lanes. Rather than one browser testing everything, Selenium Grid allows multiple lanes and 20 browsers. Features include:

  • Faster Builds, Faster Feedback!
  • Easy Install and Everyday Use
  • No Need to Change Your Tests
  • Leverage Your Existing Computing Infrastructure

One of the best parts about Selenium Grid is you can download and have it running in 10 minutes or less. Selenium Grid comes out-of-the-box with Amazon EC2 support.

Jennifer Bevan, Lead from Selenium Farm Project at Google
As of Friday, Google has over 50 teams running over 51K tests per day on internal Selenium Farm. 96% of these tests are handled by Selenium RC and the Farm machines correctly. The other 4% are partly due to RC bugs, partly to test errors, but isolating the cause can be difficult. Selenium has been adopted as the primary technology for functional testing of web applications within Google. That's the good news.

The bad news is Google is pushing the limits of Selenium. Using Selenium (RC + Core) at this scale exposed certain issues not originally anticipated as high-impact. IE/XPath slowness has a high impaction given that can only run one test at a time. Tests can cause many conditions from which RC cannot easily or automatically recover (for example, tests that don't call stop() in every exit path). Unexpected browser dialogs, popups, etc. eventually cause timeout exceptions.

Googlers expect that RC will work for the most part, but they want it to be more reliable, with better performance. So they have:

  1. Created utility methods to improve performance when examinging large tables, overlaying domain-specific languages, etc.
  2. Deployed retry policies based on failure reason.

Looking to the future - Google has not yet reached their expected usage of Selenium RC. Some projects cannot use the Farm until RC supports session-level configuration (not server-level). Many just want RC to be more reliable. So Google will:

  1. Continue to contribute to RC, Core and to user-created helper libraries.
  2. Keep doing so until all failed tests are not Selenium's fault.

Dave Astels, Google (Driving Selenium with RSpec)
Using RSpec, you can create a very easy-to-read Story with Scenarios that can be read (and likely written) by practically anyone. Dave then uses a small script to load up the stories and run them in Selenium. When he runs the script, the scenario is spit out and test pass/fail information. Learn more at rspec.info.

Alex Chaffee, Mad Scientist at Pivotal Labs (The Selenium/Ruby Project that Must Not Be Named)
What is Polonium? It's also known as Selenium RC Fu or Selenium On Rails 2 or Funkytown. It has simple extensions to Selenium RC:

  • wait_for
  • element assertions
  • launching/managing servers locally

Blackbox testing you're sitting out of the box and send in stuff. In whitebox testing, you get to open up the box and look at stuff. With Selenium, you can do Graybox testing, where you are doing blackbox testing (against the UI) and querying your database (or other resources) at the same time.

Dan Faulich, Sr. QA Engineer at Redfin Corporation (How Not to Run a Successful Open Source Project)
The first thing you don't want to do is support everything. The second thing you don't want to do is write your project in JavaScript. While it's great that almost anyone can hack on it, running in a sandbox sucks. Don't use a language that's bound by other people's security restrictions. Don't roll your own multi-language remoting. It's written using XML + XSLT and its such a pain in the ass to maintain that Dan is the only one that fixes bugs.

Shinya Kasatani, Developer of Selenium IDE
Selenium IDE is a Firefox extension that can record and play back tests in your browser. It can translate the recorded tests to many languages.

Selenium IDE 1.0 adds support for TestSuites. Another new feature is better recording features - it detects when the DOM is modified. Shinya has a demo where he uses the new IDE to test the Dojo Dijit Theme Test Page. Apparently, this doesn't work in the current version.

The Goal of Selenium IDE is to get more people interested in test automation of web applications and to help their projects to be successful.

Haw-bin Chai, Developer at CommerceHub
XPath is a powerful selection took, but it'd be great if we could use something like "article 5" instead of the cryptic //table[5]/tbody/... syntax.

Why UI-Element? Traditional locations can be ugly and they don't convey purpose. UI-Element is a Selenium Core extension and has Selenium IDE integration. It's written in 100% JavaScript. Examples:

ui=frontPage::topStoriesCountry()
ui=listingPages::article(index=5)
ui=listingPages::articleSource(articleIndex=1)

The UI Map is in JavaScript shorthand. It contains logic to map ui locators to traditional locations. Each UI element implements getLocator(), then you add a page set and add an element - all in JSON Format.

Simon Stewart on Web Driver
What on earth is Web Driver? One of the main problems with Selenium is it's written in JavaScript and it's too easy to hack. WebDriver is an idealized browser which allows you to do browser things like call get(URL), findElement(By.xpath()) and getTitle(). WebDriver is similar to Selenium RC, but it's not written using JavaScript. It's written in the native languages for each browser, which allows you to break out of the JavaScript Jail. The IE Driver is written in COM (C++). The Firefox Driver is written as a Firefox extension. Safari uses Apple events.

Soon there won't be a WebDriver project ... because it will be part of Selenium!

WebDriver likely won't be part of the core until Selenium 2.0 later this year. One of the nice things about WebDriver is you can implement different browsers. Out-of-the-box, it will support all the major browsers, as well as HtmlUnit with JavaScript turned off.

I had a great time learning more about Selenium and how most of its problems will be solved in the near future. The beers afterwards weren't so bad either. ;-)

Update: Videos of this event have been posted.

Posted in Open Source at Feb 26 2008, 03:51:56 PM MST 10 Comments