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 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.
I love how easy it is to start new projects these days. It was very difficult when I started creating AppFuse way back in 2002. We've come a long way baby!
Here's a couple of easy ways to get started with Flex and Grails:
I hope to develop with Flex, Grails, GWT or YUI + Struts 2 in the next 6 months. These seem like the most exciting technologies for Java web development in 2008.
If you live in the Bay Area and you're interested in talking with the inventors of Maven and/or XWiki, you should checkout the XWiki + Maven meetup at Terracotta's HQ. Java Open Source gurus Vincent Massol and Jason van Zyl will be there - sounds like a fun event!
Last week I had an interesting 4-day consulting gig for a client in Boulder. I was supposed to fly out to Connecticut to deliver a training course, but it got rescheduled due to the 45-day Vendor Approval Process I need to go through. The client in Boulder wanted me to come out and do an architectural assessment and provide recommendations. Topics they were interested in: web tier (specifically Spring MVC), Security, Ajax integration, build process, web services and localization. I've done this kind of before with Virtuas, but this time was different. With Virtuas, I'd do 5-days worth of presentations on just about anything the customer wanted. For example, checkout this agenda for a client in NY last year.
With the company in Boulder, I delivered zero presentations. Instead, everything we talked about and coded was hands-on. On Tuesday, we started out by discussing their application and some issues they were having. They'd done a lot of customization to Spring MVC and had managed to eliminate all the XML needed when adding new controllers and views. I spent 3-4 hours that day with 2 of their engineers finalizing and implementing their convention-over-configuration rules. On Wednesday, I helped them implement Acegi Security into their application. This was interesting because they didn't have any security mechanism and we had to implement Acegi from scratch and then tie it into their backend (using a custom AuthenticationProvider). We also integrated i18n so all messages were retrieved from their database.
On Thursday, we configured Ant to run their tests and wrote some tests for their controllers. As part of this process, I showed them how to use jMock and EasyMock and tried to explain the benefits of using Spring IoC (which they still aren't sold on). On Friday, we integrated Selenium into their build process and wrote a few tests using Selenium's Java support. In the afternoon, I showed them how they might use Scriptaculous and Prototype to Ajax-enable some features in their application.
Doing all the "live coding" on someone else's machine (with 5 developer's watching) was a bit nerve wracking. However, thanks to Cenqua's FishEye tool, I was able to search AppFuse and AppFuse Light's SVN repositories for code snippets and examples. While I knew how to do much of the stuff we covered, FishEye and Google bailed me out when I didn't. About halfway through, I realized that I don't keep a lot of my knowledge in my head. Instead, it's on this blog, or spread out on the web. I don't remember URLs anymore, all I remember are keywords. If I've read a blog post or article on the web, chances are I can find it again pretty easily with Google. Even though I store a lot of bookmarks in del.icio.us, I didn't use it all week. Remembering keywords is the new bookmark for me.
The whole week was an interesting exercise in "live coding." The whole team (6 or so) sat in a conference room all week and VNC'ed into the architect's box to do the work. We worked in Eclipse and used WTP to deploy/test things on Tomcat. The keyboard was passed around between developers at random and everyone got a chance to implement new features. I think the reason that everything worked so well was because the team was full of Senior Java Developers. Everyone learned from each other as they saw new shortcuts, keystrokes and ways or writing code. I don't know if this kind of thing will work in all development teams, but I'd encourage you to try it. It's a great way to share knowledge and educate the entire team on how a new module works.
Over the weekend, I received the following e-mail from one of the developers on the team:
Very nice to meet you this past week and get a chance to see firsthand the breadth and depth of your experience in web app frameworks and such. I believe due to your visit, we will be cranking happily along here very shortly. Everyone was quite happy with the results at the end of the day yesterday.
On a related note, if you're looking to hire an enthusiastic Web + Java Developer, please take a look at my resume or send me an e-mail. My current contract ends this month and I'm hoping to find something new to get me through the summer.
From Jason van Zyl's Maven Diaries:
Since my departure from Mergere I've been quietly and steadily working to help start a Maven related company that I'm proud to say I'm a part of. No grandiose launch, no marketing hype, no VCs, haven't talked to a single analyst, and we hope that you can actually understand what we do by looking at our website. The company's name is Sonatype and I'm finally happy with the people involved and the direction we're headed in. We are focused on facilitating the adoption of Maven through our partners network, providing training, and delivering Maven related products for software development.
Having two companies wrapped around Maven can't be a bad thing. However, let's hope Sonatype has some funding to pay folks to work on the project more, rather than other products that may or may not be successful.
Two things that could make this company very well liked in the open source community:
Are there other things you think Sonatype can do to make Maven easier to use and more successful?
Congrats to Neel, Jason, John, Kenney, Andrew, Eric and Eirik. I hope you succeed in your mission. I think w/o the VCs and the get-rich-quick folks, it should be a lot easier. Cash isn't always the key indicator of success - more often happiness and job satisfaction are.
I found a good post from Steve Loughran on what's wrong with Maven's repositories. I agree with most of his points, but would like to point out mvnrepository.com. This site seems to provide good XML Feeds for what's been uploaded to Maven's Central Repository. If you're using Maven, you should probably subscribe to its Atom Feed.
In related news, Timothy M. O'Brien has an entry about Steve's upcoming book: Ant in Action. This book is the 2nd edition of Java Development with Ant. I have a hard time believing Erik Hatcher is helping Steve write Ant in Action - AFAIK, he's off in Rails-land enjoying himself. Regardless, I'm sure Ant in Action will be an excellent book. Java Development with Ant is one of my favorite technical books of all time and is largely responsible for inspiring me to write AppFuse. I read JDwA way back in October 2002 and used a lot of its code to develop AppFuse 1.x's Ant-based build system.
Like Tim, I still like Ant. However, AppFuse 2.x uses Maven 2 and most of the projects I work on these days use Maven 2. It may surprise some folks, but I actually like Maven 2 (not Maven 1). Sure it has issues, but after a year of using it in anger, I know how to solve most of its quirks. AppFuse 2.x users will benefit from this greatly and I'm thinking of changing its tagline to "We make Maven work." 
One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them. On the project I'm on, I'll likely be converting to a full-source version before the project is over. That's why APF-675 exists. I doubt we'll make it happen for the 2.0 final release, but it is on our radar of things to do shortly after. With any luck, we'll create a way to migrate projects using embedded AppFuse to full-source AppFuse.
I'd also like to point out something ironic. With AppFuse 1.x, there were a lot of folks that advocated we move to Maven. Their primary reasoning - the Ant build scripts were too long and complicated. How about a good ol' lines of XML comparison for those folks:
Oh wait, that's not a fair comparison. The above number is for AppFuse in SVN, which end users won't deal with. A new project created with AppFuse 2.x will likely have a pom.xml with 634 lines. That's about 1/3 of the amount needed for Ant in AppFuse 1.x. Maven hasn't exactly gotten us away from XML hell though. How about a LOC count for archetypes vs. installers:
This XML-for-archetypes comparison might be unfair as well. With 1.x, you could only create a webapp, with 2.x, you can create a modular application and chop off the web-portion if you so choose.
Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!
It looks like Jetty has a new Plugin for Ant. If you've used the Jetty Maven Plugin, you know this is a slick way to quickly deploy your application. For those of you wondering about Tomcat, there's a similar Tomcat Maven Plugin that supports tomcat:run and tomcat:run-war. However, it's still in Mojo's sandbox.
I'm pumped to see this Jetty task for Ant because I've been thinking a lot about creating an exploded, full-source archetype for AppFuse 2.0. Of course, it's probably possible to start Jetty and monitor your project for changes w/o this task - but it does seem to make things a fair amount easier. If we do a full-source archetype, it makes sense to support Ant as well - especially since we can probably re-use the build.xml from AppFuse Light.
This brings up a related questions I asked on the AppFuse mailing list yesterday:
A couple of questions for folks using (or planning to use) 2.x:
1. As far as archetypes go, are you using basic or modular?
2. If there was a 3rd type of archetype that included the full source (like AppFuse 1.x), would you use it over the existing basic or modular archetypes? If yes, I'm assuming upgrading is not that big of an issue for you?
If you've tried AppFuse 2.x and would like to answer these questions, please add a comment.
There's another questions about Selenium vs. Canoo WebTest in that post, but that's reserved for another entry where I'll talk about Selenium options in Maven 2.
From the Maven 2 user list:
We would like to announce the immediate availability of Artifactory, a Maven 2 enterprise proxy.
Artifactory offers advanced proxying, caching and security facilities to answer the needs of a robust, reproducible and independent build environment using Maven 2.
It uses a JSR-170 Java Content Repository (JCR) for storage, which makes it extremely easy to manage searchable metadata, and provide extended features such as security, transacted operations, auditing, locking, etc.
Artifactory is distributed under APLv2 at http://artifactory.sourceforge.net. It is currently available as a downloadable archive, that can be run out of the box (with default settings). An install script to run it as a Linux service is also provided. A (limited) guest live demo is available at http://www.jfrog.org/artifactory (username/password is guest/guest).
You are welcome to give it a go!
Cheers,
Yoav Landman,
The Artifactory Team
So how does this compare to Archiva, Proximity and Maven Proxy? One user writes (formatted for better reading):
It's interesting to see that Artifactory's UI is powered by Wicket and Dojo. The demo seems kind of sluggish, but I don't believe this application is meant to handle more than 10 users at a time. For more information on Artifactory's features, see its introduction page.
It's great to see a (seemingly) good tool come out for internal repository management.
I spent a couple days last week analyzing the best open source continuous integration server for Maven 2 projects. Hudson turned out to be the clear winner with the best UI and easiest setup. It also actually worked, which is a lot more than I can say for Continuum. While I did get Continuum to work, it required turning on anonymous SVN (no, putting the username/password in the URL did not work). CruiseControl worked as well, but required config.xml knowledge, which sometimes scares admins. Pulse and Bamboo continue to be the best commercial Maven 2 testers, while TeamCity failed my 10-minute test (twice!). One of the features I was looking for was Trac integration and that only exists for CruiseControl and Continuum.
It's amazing to see projects like Continuum and Archiva. If they're any reflection of the Maven team's ability to develop software, that's frightening. My advice: discontinue both of these projects as they're a waste of anyone's time to even research them.
Update October 2009: Fast forward a couple years and I take back what I said about the Maven's team ability to develop good software. Nexus is a kick-ass Repository Manager.
