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 added a tag cloud to this site tonight. Thanks to Rich Sharple's Hacking Roller : Tag Clouds, it was pretty easy. It's currently located in the bottom-right corner. Here's a glance at this site's most popular tags:
acegi appfuse denver grails gwt hibernate ibatis java jsf maven maven2 myfaces rails roller skiing spring springmvc stripes struts struts2 tapestry tomcat travel webframeworks wicket
Enjoy!
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.
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? 
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]?
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?
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]
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
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
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)
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.
From Stephen O'Grady, I learned a couple interesting tidbits yesterday.
The first is Jeremy Zawodny talking about Yahoo's new Grid Builder in YUI Grid CSS and Grid Builder Kick Ass! The last time I looked at YUI Grid CSS (that's a mouthful) was almost 2 years ago, when it first came out. It's obvious that this library is better supported than Mike Stenhouse's CSS Framework. Maybe it's time to switch in AppFuse? Anyone know of themes available for Grid CSS?
The second item is Charlie Savage's entry titled Must Read Rails Performance Article:
Using a patched version of ruby and ruby-prof, Alex was able to more than double performance (with hints of more to come) and reduced memory consumption by 75%, or 750MB (yes - that is Megabytes). Alex does a wonderful job of documenting his approach with a series of blog posts here and here.
This reminds me of Don Brown's recent work on Maven. This is how open source is supposed to work - instead of complaining about the problems, fix them. In both Rails' and Maven 2's cases - it's somewhat surprising these issues weren't fixed earlier. Kudos to Alex Dymo and Don Brown for stepping up to the plate. Well done gents.
It's a sad day in Denver. It's also a "locals' paradise" at the Colorado ski resorts. Most hills received around a foot of fresh powder last night, but there's no way to get there. I-70 is closed at Georgetown (which excludes Keystone, Breckenridge, Vail and Copper). Berthoud Pass (the road to Winter Park) is closed as well. Sniff. 
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.