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.
Can you believe it?! Maven 1.0 is (finally) released: Download or read the Release Notes. Normally, I probably wouldn't care so much, but I've been engrossed in Maven for the past couple of weeks. My favorite features are the ability to type "maven eclipse" or "maven idea" to generate Eclipse/IDEA project files. Wow - 4 announcement posts in a row - that's a personal record! 
I have a feeling that Maven and I will never quite get along. I live on the bleeding edge, because you have to if you want to keep up with open source. I'm using Hibernate, Spring and JSTL in my Maven sample app. Hibernate is pretty up to date - ibiblio has 2.1.3 and 2.1.4 is the latest. Spring's JARs aren't too bad - 1.0.1 vs. 1.0.2 being the latest release. So much for getting spring-mock.jar quick and easy - since it's part of 1.0.2. JSTL is one version behind too.
Lesson learned: if you want to stay on the bleeding edge, don't use Maven. I suppose another option is to become the guy who uploads these new versions. That job looks rather complicated though. I'm guessing that most folks are simply maintaining their own repositories (or staying away from the bleeding edge).
One of Maven's best features is its ability to generate websites with project documentation. In most cases, it'll motivate developers to improve the documentation for their project. At least it has for me with Struts Menu. However, Maven makes the worst mistake in the history of web development - it doesn't set a default background color. A lot of idiots do this these days, so do me a favor folks - change the default background color on your browser to something obnoxious. Mine is set to bright orange right now. Try changing yours to orange and then visiting the Maven site - its fugly.
This issue isn't as bad as it used to be. Most people don't notice it, but "back in the day" when browser's used gray as their default - it was an issue. Maybe I'm just old fashioned.
Anyway, back to Maven. Yesterday, I was responsible for upgrading some Maven sample apps to the latest RC3, which makes the mistake mentioned above (RC1 did not). Usually when you encounter these issues in Mavenland, you click 5 times (Google with Firefox makes it 1 click) to find the plugins site and then look for its properties. In this case it's xdoc, which has a horrendous number of UI Color Settings.
These settings have two major problems. First of all, they don't work with RC3, and secondly - it's an awful way to define the colors and such for your site. Especially since its mostly related to colors. A better way that I've found is to put a maven-theme.css file in your xdocs/stylesheets directory. This will override Maven's default stylesheet and you get a lot more control over the look and feel of your Mavenized project site. The easiest way to get a template to start with is to generate your site and then copy target/docs/style/maven-theme.css into this directory. Hope this helps make Maven a little bit easier. 
Today was a great first day on the new job. I rode my bike in - which took about an hour - and arrived around 10:00. The commute is beautiful - mostly on a bike path, and mostly along a river. It's too bad I won't be doing it more (I'll likely be working from home a lot). Most of the day was spent exploring Blue Glue, source code and the sample apps. I found out that Blue Glue (which is basically a development environment installer and configurer) on Windows has gotten much better since Out-of-the-Box 2.x. Now it skips most of the Windows installers and everything is installed through OpenLogic's Swing app. It was a fun day talking about open source and how things integrate together. I'm not used to talking with folks about my open source experiences and enthusiasm - so it was a nice change.
The best part was when I received my assignment for the next couple of days: upgrade the Maven sample apps to the latest version and enhance one to include build/deployment examples. I'm also responsible for writing documentation on the sample apps for developers who use them. While I'm not a huge Maven fan, I know that some people like it and it'll be cool to create a "how to" for those folks. On the ride home, I realized that I'm really enjoying what I do right now. I'm basically developing and writing for developers. I have no "business" clients per se - most are developers: both with Spring Live and Blue Glue. The downside is that developers tend to be a pretty smart lot - and if I screw up - they'll let me know about it. Oh well, open source rocks - it's cool to be working with it full time.
The worst part of the day was coming home to over 1000 e-mails - from not checking my e-mail all day. I've got a major spam problem since about 200 of those are from mailing lists and I was only interested in 20-30 beyond that. I'm thinking of changing my e-mail address. Rather than adding more junk filters - I need to eliminate the sheer volume - it's choking both Mail.app and Outlook - and I have a 2 MB connection!
JRoller is down, and has been down for an hour or so - so I've decided to post this Spring Live entry here.
I discovered an interesting thing today about Spring and my JUnit tests. I noticed that the VelocityEngine I was setting on my
PositionManager was getting initialized once for each test* method in my Test. This means that
since my PositionManagerTest has 10 test methods - it would load the context 10 times.
Loading the context so many times was because the following code was in my Test's parent's
constructor:
ctx = new ClassPathXmlApplicationContext("/applicationContext.xml");
I suppose I expected any constructor-iniatialized variables to be initialized once and only
once. So I figured out a solution to make my JUnit tests run faster. By making the ctx variable static, and loading the file in the member variables definition, I
greatly reduced the amount of time needed to run tests. Below is the new code I'm using:
protected static ApplicationContext ctx =
new ClassPathXmlApplicationContext("/applicationContext.xml");
By doing this, the ApplicationContext is only set once, and my tests run much faster. Here's some performance comparisons from Struts Resume:
Average time to run "ant test-dao": 36 seconds
Average time to run "ant test-dao" after this change: 26 seconds
A 10 second improvement - that's crazy talk dontcha think?! I've tried it on single tests, as well as suites - and it seems to improve performance by approximately 30% across the board.
Because of this experience, I have to recommend that when you write JUnit tests that use Spring - you should initialize your ApplicationContext in a static member variable. It seems to be the best performing and logical choice. Of course, if I'm off my rocker - please let me know.
On a sidenote, it would be cool if Roller allowed me to turn off comments for a single post. I like how Simon posts stuff on java.net and then aggregates it to his personal weblog.
Big news baby - the best Java tool in the world has a new release. I don't know that I'll use any of the new features (such as antlib, macrodef, presetdef, ssh tasks), but I do love to upgrade. Downloading now...
Later: It looks like Canoo's WebTest is not compatible with Ant 1.6. Reverting back to 1.5.4.
C:\Source\appfuse\test\web\web-tests.xml:29: Task must be of type "Step": invoke at C:\Source\appfuse\test\web\login.xml:1: is of type org.apache.tools.ant.UnknownElement
Line 29 is: <canoo name="login">. I've notified the webtest mailing list, hopefully there will be a resolution shortly.
This release is a significant refactoring of the 1.x codebase. The source
and site is now built using Maven. Menus can now be defined using Velocity
templates and support has been added for looking up dynamic values. This
means that if you have ${variableName} in your menu-config.xml (in a link),
the tag library will look in all scopes for a variable with the name
"variableName". The example app has been updated to improve documentation.
IMO, the Velocity templates is huge because it means "if it's possible with
HTML" - it's possible with Struts Menu.
Changes (from http://struts-menu.sourceforge.net/changes-report.html):
- Renamed package structure to net.sf.navigator.
- Added support for using Struts' actions and forwards for links in menu-config.xml.
- Added support for using dynamic variables in menu-config.xml.
- Updated build process to use Maven for building/deploying.
- Refactored to use Velocity and allow dynamic variable substitution.
You can read the nitty-gritty details about the Velocity enhancements, check out the sample app or download this tag library for yourself.
I received a question about AppFuse that I've been pondering every since. The question basically boils down to two things:
Quick Answers: I replace files in the appfuse/lib directory and update lib.properties. Then I update my project properties in Eclipse to reference the new jars. A pain, yes - but only a 2 minute process. I run all my tests before I bother changing the Eclipse classpath. As for multiple projects - the easiest thing to do is to move $yourProject/lib to a folder called "libs" in the same directory as $yourProject and change the ${lib.dir} property in properties.xml to point to the new folder.
Begins Rambling... I'm currently using AppFuse on 3 different projects. 1 is AppFuse itself, the 2nd is Struts Resume, and the third is for a client I created a webapp for in August. Right now, when I synch up Struts Resume with AppFuse, I copy paste from appfuse/lib to struts-resume/lib and update the lib.properties appropriately. I can't just copy lib.properties to struts-resume/lib because struts-resume uses libraries that appfuse doesn't. Yes, this is admittedly a pain in the arse. It's almost as bad as changing all the method signatures when moving the Hibernate Session from all method signatures into the constructors (can your IDE do that?!). I don't want to make people download appfuse to build struts-resume though, so I doubt I'll change this process.
The whole "massive lib folder" has been bouncing around in my head for quite some time. I'd like to use Maven or Greebo to download the dependencies for AppFuse, but at the same time, it's nice being able to download the whole thing at once and be up and running. I don't want to go the Maven route because I don't really want/need a website for AppFuse and it sounds tough to get it working with XDoclet (though WebShop looks like it might be a good template). KISS
The project.xml in AppFuse is my feeble 20-minute attempt to get it Mavenized (it's currently not used). I tried Greebo this morning, and it really does nothing for me. Especially since I've setup separate compile/test classpaths (read from lib.properties). It'd be a real pain with Greebo to separate out the classpath's for testing and building - it seems to only support one long classpath. Also, who wants to make their whole best-practices open-source app dependent on a 0.1 open-source app?
As for having my IDE (wether it be Eclipse or IDEA) reading the classpath from Ant - that would be the sweetest feature of the year! Currently in Eclipse and IDEA, I have to give an absolute path to j2ee.jar since I don't want to distribute it (it's 11 MB). When I switch b/w OS X and WinXP, I always have to change this classpath. I'm sure there's an easier way with setting variables in the IDE, I just haven't figured it out yet.
The other thing that is annoying is that IDEA doesn't seem to read my $ANT_HOME environment variable. Does it have it's own $ANT_HOME? It's annoying for me b/c I check for JUnit classes in the classpath in my "init" task, and IDEA doesn't find them. Don't worry Eclipse bashers - it doesn't work in Eclipse either.
This is fine with me b/c I prefer the command line, but those "I use my IDE for everything" folks might not like it because they can't run AppFuse's build.xml file from w/in their IDE.
This blogging thing rocks. Today I got one of the books I've been meaning to buy - for FREE! Check out the following e-mail I received from Manning:
Hello Matt:
We are contacting you regarding Vincent Massol's new book, JUnit in Action,
which Manning will be publishing in November. Vincent mentioned that you
might
be interested in certain parts of the book which relate to topics recently
discussed on your blog http://www.raibledesigns.com/page/rd. There is
a chapter on unit testing tag libraries.
He has asked us to offer you a complimentary copy of
the PDF ebook which just became available today. We hope you will
find it of interest.
Sweet! Thanks Vincent! I read the chapter on unit testing tag libraries - very clear and to the point. Unfortunately, for tags with bodies, you still have to verify HTML, so tagunit might be better for these. I like the coverage on the Maven Plugin for Cactus and also how to use JSTL's ExpressionEvaluatorManager for reading tag attributes. The link I found, the chapter has code samples.
I've never really liked eBooks, but I have to admit, this is pretty damn convenient. Especially since I tend to pack around 10-20 books to each new contract. What about sharing? Can I let co-workers borrow my PDF like I let them borrow my books?
I priced my ideal 15" and 17" laptops this morning. 15"/1GB RAM/5400 RPM/Extra Battery/AppleCare is $3,702.00, 17" version of the same is $4,002.00. Not much of a difference for a couple more inches on the screen. Is this the only difference between the two - or does the 15" have Aluminum and the 17" is the same as my old 15"/667 PowerBook?
Boy is it tempting to get one, but I can't seem to justify it. The only thing I can come up with is that I really *want* one, no need though. The mind wants, the pocketbook doesn't.
Anyone know when they'll be available in the Retail Stores - I'd love to take one for a test drive.