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!
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? 
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]
This weekend, I'm planning on heading up to the hills for two fun-filled days of great Colorado skiing. Since it snowed a bit in Denver tonight, I figured I'd check the weather forecast:
Thursday Jan 31, 2008: 3 to 4 inches of accumulation
Friday Feb 01, 2008: 3 to 5 inches of accumulation
Saturday Feb 02, 2008: 3 to 5 inches of accumulation
Sunday Feb 03, 2008: 4 to 7 inches of accumulation
Sweet.
Friday Update: It looks like we'll be skiing at Steamboat tomorrow instead. Checkout their Straight Talk Snow Report from this morning:
Snow Report
* Time: 02/01/08 05:00 am
* Conditions: Powder
* Lifts: 16/18
* Trails: 163/163
* 24 Hour Snow: 18"
* 48 Hour Snow: 22"
* Base: 77"
* Total: 308"
Steamboat Straight Talk Snow Report: 2/1/08
Good Morning to you, indeed!
Remember earlier in the week when we had a loud, brash, windy storm
roll through the mountains and bring us snow? Last night while no one
was looking, a quiet storm tiptoed in like a whisper, under the cover
of darkness, and silently dumped a foot and a half of the choicest
"Champagne Powder" while we all slept. All over town, people woke up,
looked out their windows, and let out a "Holy Cow"!
I could write this report with fill in the blanks, as in... My first
run down___________ (insert any trail name) was sweet. I got face
shots the whole way. Then I skied over to the __________(insert a run)
trees and the snow was just blowing over my head.
I think you get the picture. The whole mountain is in epic condition.
On one chair ride, my chair mate said, "You know it's a good day, when
you hear Monkey noises coming from the forest." Everywhere folks were
hootin' and hollerin'.
Weekend warriors, don't despair, there is plenty powder left to be
skied tomorrow.
Have fun. Be safe. Look out for your buddy. Peace.
Straight Talker
Kat Murphy
Grinning like a Chimp
Telemark Skier
Don Brown spent some time over the weekend Making Maven 2 not suck:
While there are a few (very important, I might add) things Maven 2 gets right, there are a bunch that just suck, yet I use it at my day job (Atlassian) and in Open Source work, so in true Open Source tradition, rather than continue bitching, I'm doing something about it. I'm embarking on a quest to fix all the bits of Maven 2 that really annoy me and waste my time. I hope to get most, if not all, of the changes back into the codebase, but my personal deliverable is a build of Maven 2 that doesn't suck.
On his blog, Don lists a number of improvements he hopes to make. This weekend, he implemented the first three, which concentrates on speeding up remote repository access and downloading of artifacts.
First up, tasks #1-3. I implemented these changes in a bored Sunday afternoon and saw a example build (Struts 2 core) go from 3 minutes, 26 seconds to 2 minutes even, so a little over 40% performance improvement.
Interested, I decided to try Don's improvements on AppFuse. Since it fetches seemingly hundreds of artifacts from Maven's central repository, it seemed like a good testing ground. With a clean repository (rm -r ~/.m2/repository), a 8 MB/sec internet connection and "mvn -Dmaven.test.skip", I achieved the following results with the stock version of Maven 2.0.8:
[INFO] Total time: 7 minutes 40 seconds [INFO] Finished at: Mon Jan 28 09:02:11 MST 2008 [INFO] Final Memory: 55M/508M
With Don's improved uber-jar, I received the following results:
[INFO] Total time: 5 minutes 17 seconds [INFO] Finished at: Mon Jan 28 09:10:56 MST 2008 [INFO] Final Memory: 56M/508M
460 vs. 317 seconds = a 31.1% improvement -- Nice work Don!
When he implements #4 (Should support artifacts checked into the SCM in the lib/ directory so no external repository needed), I'll be a much happier Maven consumer. I've always wanted the ability to bundle all of AppFuse's dependencies for offline use like we did in 1.9.x.
Don - I'll buy you numerous beverages in Vegas if you add the ability to run a Maven command to put all a project's dependencies in its lib directory too.
I wonder if I can get one of these in yellow?
Thanks to Jim Head for sending me a link to this.
In The future is now -- Java development in 2008, Andy Glover writes:
The year 2007 was full of exciting plot twists, punctuated by growing excitement about dynamic languages, the open source evolution of the JVM, and the rise of Google as a strategic contributor to the Java community. The question is, what does all that tell us about the year ahead?
...
And so, despite some rumors to the contrary, I would argue that Java isn't going anywhere but up in 2008. Rather than peer into a crystal ball and try to divine the future, let's reflect on the major events and trends of the past year. Taken together, they reveal all we need to know about what's ahead in 2008.
He concludes the article with:
An African proverb states that Tomorrow belongs to the people who prepare for it today. Thus, the future of Java (at least for the next year) has already been brewing for some time. The events of 2008 will largely
be shaped by the JVM itself, as languages like JRuby and Groovy grow in popularity and eventually gain enterprise-wide adoption.
The promise of using Java to develop consumer mobile applications also seems more accessible than it has for some time, given
Google's foray with Android and Sun's with JavaFX Mobile. Most of us will also be concerned with leveraging the emerging multicore systems and looking to Java 7's java.util.concurrent packages for answers. Lastly, open source Java and the business model surrounding it will continue to grow.
I agree that learning about JRuby and Groovy is a good way to be prepared for the future. Reading Ola Bini's Practical JRuby on Rails Web 2.0 Projects and/or Stuart Halloway and Justin Gehtland's Rails for Java Developers seem like good ways to get started with JRuby. With Groovy, Groovy in Action has received a lot of good reviews. For Grails, it's a bit more difficult as it's evolved so quickly w/o any updated books. I like the look of Scott Davis's Groovy Recipes, but that won't be released until March.
One thing to note: just because you learn these languages and frameworks doesn't necessarily mean you'll find a new job doing them. In my experience, there's still way more Java jobs than there is Rails or Grails jobs. I sat on a Consulting Panel last night at Denver's Ruby on Rails user group (DeRailed) and this was confirmed (at least for Ruby) by the recruiters on the panel. There were three recruiters and combined they've only seen 2 Rails positions in the last 6 months.
So if you're looking for a new job, I doubt you're going to find one that allows you to leverage your new-found JRuby/Groovy skills out of the gate. However, I do believe you can leverage these tools in your existing jobs and hopefully make your development life more efficient.
A good friend sent me an e-mail this afternoon asking for some advice.
I am headed to London & Dublin next week for a quick trip with my friend who's a pilot for US Airways. I am pretty sure you've visited these 2 places, let me know if you have any good advice or must see places or things to do, or even a good place to stay. We haven't booked any hotels yet but booked our flights.
I haven't been to Dublin since 1998 and I've never been to London - so I figured it might be a good question for readers of this blog. What are the must see places and things to do in Dublin and London? Thanks in advance for any advice you can offer.
In Anyone else using Groovy?, Tim Fennell (inventor of Stripes) raves at how much he likes Groovy now that it supports Java 5 features. He writes that Groovy might offer a solution to make development with Stripes faster:
The other thing I've been wondering about is that if there were enough demand for it we could try adding "improved" groovy support. E.g. throw your groovy actions under WEB-INF and we'll use groovy's built in stuff to do auto-reloading etc.
Gregg Bolinger responds with an excellent idea:
It would be really cool if Stripes could automatically discover and load changes to action beans (including new ones) without the entire app restarting, regardless of what the action bean is written in. But I realize that is a pretty tall order. :)
I agree that it might be a tall order, but I don't think it's impossible. In fact, I think all Java-based web frameworks should support hot deploy of a single class. We shouldn't have to buy JavaRebel to do this. It should be mandatory.
When an application reaches a certain size, the startup time can get pretty lengthy. This is lost development time. Furthermore, if any part of the development cycle takes longer than 15 seconds, there's a good chance developers will do something else (check their e-mail, move onto another task, etc.). Multi-tasking may be a good skill to have, but it's a horrible way to be productive.
Of the frameworks I'm familiar with, only Tapestry 5 and Seam support reloading single classes without restarting the whole application. Why can't the other frameworks "borrow" Tapestry 5's code? Maybe someone should just buy ZeroTurnaround and give away JavaRebel for free.
If I had one wish for 2008, it would be for all Java web frameworks to support this feature. Pretty Please?