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.
A colleague sent me an e-mail today and asked me if I'd ever heard of WebORB today. Since I hadn't, I figured I'd write this post and see if any of you have heard of it? If so, what is it and what does it do? It it similar to Appcelerator, but server-side only? Or is it more like Granite DS?
[Read More]
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?
James Carr in Making extJS More Accessible to Java Developers:
With my recent interest in extjs, I was playing with the idea of making a Struts2/WebWork component library or a tag library to handle a lot of the boilerplate extjs code (i.e. creating layouts and such) but, luckily, discovered someone beat me to the punch!
I randomly came across ExtTLD this morning while sifting through my rss feeds, and I must say I am rather impressed. Although I consider myself a pretty good javascript developer, there seems to be a lot of java developers who aren?t that hot at javascript... which is why whenever I attend any java related conference there is always several sessions touting "javascript free ajax!" frameworks like GWT, Ajax4JSF, or IceFaces. Although I've always been skeptical of such frameworks, I do see their benefits... especially for the java developer who excels at serverside JEE development but generally sucks when it comes to adding javascript behavior to the presentation layer.
I can definitely see how Ajax-with-IDE-code-completion would appeal to many developers. However, I do have to agree with James:
So far it looks good, but I haven't had a chance to play with it yet. Basically, I'll have to see if it passes my "good javascript generator framework" test. I?m a pretty staunch advocate of unobtrusive javascript, and generally hate any presentation layer framework that seeks to dump several hundred (or thousand) lines of javascript inline in the html document.
For development shops that have UI-only developers for the front-end and Java developers for the controller/validation part of an application, frameworks that generate JavaScript usually don't make sense.
ExtTLD's license:
ExtTLD is published under GPL 3.0 license however restricts use by companies participating in animal abuse, such as animal testing laboratories etc.
Happy Thanksgiving everyone! Thanks for leaving such good comments on this blog and making the web such an enjoyable place to write stuff. Here's a Thanksgiving smile from Abbie in November 2003. Damn they grow up fast.
I'd also like to thank my parents for making the drive to Colorado from Oregon (via Montana). I've had a lot of fun with them in town this week. I'm looking forward to teaching my Dad how to play pool over the next couple days. 
Related: Past Thanksgiving entries.
I first came up with the idea to do a "Comparing Web Frameworks" talk in 2004. I submitted a talk to ApacheCon and it got accepted. From there, I outlined, created sample apps and practiced this talk before ApacheCon. Believe it or not, that was my first time speaking in front of a large audience.
Historical note: October 2004 was a pretty cool month - I discovered Rails and Roller had a 1.0 release candidate.
When I created the presentation, it was in large part due to all the WebWork and Tapestry folks harassing me on this very blog. I started using Struts in June 2001 (the same month 1.0 was released) and had used it successfully on many projects. Part of the reason this blog became so popular was I posted lots of tips and tricks that I learned about Struts (and its related project) while using it. After a while, the noise became too heavy to ignore it - especially after I'd tried Spring MVC. So in an effort to learn more about the the other frameworks, I submitted a talk and forced myself to learn them. It seems to have worked out pretty well.
With that being said, I think it's time for a change. The reason I originally wrote this was to educate developers on how the top Java web frameworks differed and encourage developers to try more than one. A while later, I realized there's different tools for different jobs and it's not a one-size-fits-all web framework world. It's not a component vs. request-based framework world either. There's lots of options now. When I've delivered this talk earlier this year, I've always felt like I've left quite a few frameworks out. The solution could be to add more and more frameworks. However, I don't think that's a good idea. The talk is already difficult to squeeze into 90 minutes and it's unlikely that adding more frameworks is going to help.
The change I'd like to do is to reduce the number of frameworks down to (what I consider) the top web frameworks for deploying to the JVM. What are those frameworks? IMHO, they are as follows, in no particular order:
The RIFE, Tapestry and ZK folks can start bitching now. Sorry - less frameworks make for a more interesting talk. Maybe I'll add you in the future and I can ask the audience which ones they want compared then we can choose four and go from there. Why don't I mention Spring MVC? Because I think Struts 2 is easier to learn and be productive with and I also like it's more open and active community. I've written applications with both and I like Struts 2 better. As for Flex vs. OpenLaszlo, I'm somewhat torn. It seems like learning Flex is going to be better for your career, but it's likely useless without the Flex Builder - which is not open source. However, at $250, it's likely worth its price. I know the Picnik folks used Flex for their UI - I wonder how much they used Flex Builder in the process?
What do you think? Are these the top web frameworks for JVM deployment today? The next time I give this talk is this Thursday at ApacheCon. I may try to re-write my talk and then give the audience a choice of old vs. new. The downside of doing the new talk is I won't have time to write apps with GWT, Flex or Seam. Anyone care to post their top three pros and cons for any of these frameworks?
According to Scott, today's Java-based web frameworks are partial solutions at best. They're only solving one piece of the puzzle - you still need to manage persistence, deployment, etc. all by yourself.
We're moving into a new era of web frameworks. The expectation now is a full-stack solution. Grails is a fully integrated modern Java web application in a box. It contains Spring, Hibernate, Quartz, Log4J, Jetty, HSQL, JUnit and Ant. You're not limited to using Jetty, you can type "grails war" and create a WAR that you can deploy to any application server. In a single zip/tar, you get the whole thing - including the database and servlet container. You get a lot of good default for free, but you're not limited to those defaults.
What does "modern" in a framework mean? It means it uses Convention over Configuration - Grails autowires components together based on naming conventions. Struts 1.x uses Configuration over Configuration - the more XML the better.
The Wisdom of Crowds - why are the many smarter than the few? What is the wisdom of crowds when it comes to web frameworks. Struts is the wisdom of crowds when it comes to web frameworks. It's based on sound principles (MVC) and was written by Craig McClanahan. He was the architect of "Catalina" Tomcat 4 and wrote Struts shortly thereafter. David Geary was contributor #2 to Struts. It has a proven track record and has a 60%-70% market share. Struts must be the perfect framework - especially since it has such a great pedigree.
So what's wrong with Struts?
The Recipe for a Tipping Point: Contagiousness / viral, tiny "tweaks" to a proven model can yield big, disproportionate effects, the rise is not "slow and steady" - the effect is dramatic and immediate.
Ruby on Rails won the hype award. It's largely worth the hype, but it's not revolutionary - it's evolutionary. It has tiny tweaks to the proven MVC-driven approach: Convention over Configuration, Scaffolding and Unified Technology Stack.
The one thing that Rails is lacking is Java support. Grails, on the other hand, offers the same experience using known, proven Java solutions.
Scott drank the Rails Kool-Aid for a while and enjoyed it, but found it difficult to switch from Ruby in the morning to Java in the afternoon. With Grails, he doesn't have to do as much context switching, as well as all the Java libraries are available - the ones you know and love.
You can drop groovy.jar into your classpath and write Groovy code. One nice thing about Groovy is you can rename your existing .java files to .groovy and they'll work just fine. Included Ajax support: Script.aculo.us and Protoype as well as YUI. YUI is battle-tested since it's used by Yahoo and very well documented. You can use "grails install-dojo" to install the Dojo toolkit. Grails has a wealth of plugins available at http://grails.org/plugins.
Now we're going to crack our nuckles and build some code - slides are over.
grails create-app conference cd conference grails create-domain-class Speaker (add some fields) grails generate-all Speaker grails run-app
The impressive things about this set of commands is I was able to 1) download Grails and 2) run all these commands at the same time that Scott did. I was definitely impressed (I knew I would be). Auto-scaffolding - you can get the same thing as "generate-all", but it generates controllers and views at runtime in-memory. All you need to do is create a domain object (i.e. Talk) and then create a TalkController that has the following line in it:
def scaffold = Talk
As a test, I tried this at the same time that Scott did and got the following error. It looks like Grails/Jetty isn't smart enough to pick up new classes as they're added.
[263102] commons.DefaultGrailsApplication Class not found attempting to load class Talk
java.lang.ClassNotFoundException: Talk
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
Grails comes with a number of environments. Dev (the default) auto-reloads changes to Controllers, Views and even the Model (this is helpful for rapid development). Prod loads all items statically for maximum performance. To change the environments - you can change DataSource.groovy.
For some reason, adding/removing some properties on my Talk object and my application hasn't been the same since. Now when I try to access my TalkController, I see the following stack trace:
org.springframework.orm.hibernate3.HibernateQueryException: could not resolve property: difficulty of: Talk; nested exception is org.hibernate.QueryException: could not resolve property: difficulty of: Talk at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:640) at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:412) at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:378) at org.springframework.orm.hibernate3.HibernateTemplate.executeFind(HibernateTemplate.java:342) at org.codehaus.groovy.grails.scaffolding.DefaultScaffoldDomain.list(DefaultScaffoldDomain.java:112)
I asked Scott about this error and he proved that removing properties from domain objects should work. I told him restarting Jetty didn't fix the problem and he suggested dropping the "Talk" table and letting Grails re-create it. Unfortunately, I have no idea where this database is, so that's difficult to do. Doh - now I realize what was causing the problem. Before I dropped the "difficulty" property, I had clicked on the column and that property was still referenced in the URL. When I'd refresh the browser, the stack trace occurred. I don't know if I'd consider this a bug or not.
dbCreate = hibernate.hbm2ddl.auto is used. When in development create-drop is used. In production and test environments, it uses update and saves the data between restarts.
You can turn off Hibernate's automatic schema alteration by commenting out "dbCreate" line in DataSource.groovy.
To run your application in Tomcat instead of Jetty, you can run "grails war" and copy the WAR to Tomcat. The WAR is created with the production environment by default, so you may need to pass in arguments or set environment variables if you want the WAR created in dev mode.
At this point, my battery died. Scott continued to cover how to order form elements (when using scaffolding) with "static constraints" and how to add validation rules. It was an excellent presentation and Grails definitely looks like a really cool web framework. The best part is I learned most of what you need to know to use it - in an hour!
I might have to try Grails soon - I love the concept of Life above the Service Tier and Grails would work nicely for serving up REST. I think YUI, GWT-Ext and Flex are probably the best frameworks for developing a SOFEA client. The question is - when using YUI, how do you download all pages in the application at once?
The past week has been an incredible time to live in Denver. It all started last Monday when I went to the Rockies vs. Padres Wildcard Game. It was a beautiful night, we had club-level seats and the Rockies beat the Padres in a 13-inning, 5-hour marathon. It was the best baseball game I've ever seen in my life.
Fast forward to last weekend. The kids and I rented a condo in Winter Park with some friends. It was an awesome 5-bedroom place with a great view of the ski resort, a nice hot tub and an ideal location to watch Saturday night's sweep of the Phillies.
After a hike in the warm mountain air on Saturday, I received a phone call from a friend saying he couldn't make it to the Broncos game on Sunday and asked if I wanted his tickets. I leaped at the opportunity and sped down the mountain on Sunday to go to the game. While the Broncos game was pretty bad, it was still fun going to the stadium and watching them play.
The fun hasn't stopped yet either - I (somehow) got free VIP tickets to a Nuggets pre-season game tomorrow night and this weekend is the Great American Beer Festival. Unfortunately, I'm out of town for all the Arizona games, but I should be in town for the World Series. 
My post asking about one 30" monitor or two 23" monitors generated quite a few comments. After reading The Large Display Paradox, it seems like I should either find something like WinSplit Revolution for the Mac, or get 2 monitors. I agree with everything that Jeff Atwood says about maximizing windows, that's why I originally thought two 23" monitors might be better.
However, the problem with two monitors is I'd need to get Matrox's DualHead2Go Digital Edition to run both on my PowerBook MacBook Pro. Frederic notes some issues I might experience with this device:
It worked ok with 2 17" LCD monitors but did have some issues with most games... One thing to keep in mind is that it may not have the bandwidth to drive anything over 2x1280x1024.
I don't play games (too addictive), but if I can't drive both monitors at 1900x1200, it's probably not worth it.
So you're getting a 30" monitor then?
Maybe, but there's a problem with the 30" that I didn't think of: I'd need dual video cards in my Windows box to drive it. Not only that, my KVM switch probably can't handle a 30" monitor. If I'm wrong, and I can drive a 30" monitor through a single DVI KVM switch, let me know. In the meantime, I'm strongly considering a single 23" with my MacBook Pro on an iCurve next to it. That gives me dual monitors when I'm on the Mac, but not on Windows. That's OK - I don't use my Windows box that much anyway.
My last post on choosing a web framework got quite a few comments. Some seemed to like the application categorization technique as a means to narrow the choices. However, others seemed to disagree. So if application categorization is not a good methodology for narrowing the choices, what is?
I think one of the best ways to figure out a good methodology is to find out what people have done to choose their web framework. I'm looking for stories from developers who have evaluated 2-3+ frameworks for a project. I'd like to come up with 3-5 stories as part of my talk to highlight how some teams have chosen their web framework. What were your important criteria? What made you choose the one you did? Was it a tight race between a few of them? Did industry buzz or application categorization play a part in your decision?
Please send any stories you'd like to share to [email protected]. Of course, you can also post your story in the comments - but an e-mail gives it a bit more validity. If you'd like to share your company name, that'd be great, but it's by no means required. I haven't decided if I'm going to prevent all cases as anonymous companies or not. If you do send a story, I'll make sure and ask your permission before I share any of your personal/company information. Thanks!
I plan on rewriting my "Comparing Java Web Frameworks" presentation for this year's Colorado Software Summit. Rather than "Comparing Java Web Frameworks", I'm going to make it into more of a "Choosing a JVM Web Framework" presentation. I think this opens it up to more possibilities such as Grails, JRuby on Rails, Flex and GWT.
One of the things I hope to talk about is choosing the right tool for the job. I think there's 3 types of web applications you can develop:
Once you've decided on which of these you're developing, it's much easier to narrow down the choices:
I'm not sure if GWT fits in the RIA category. I'm not sure where Rails or Grails fit either. They more closely resemble category #1 than any other, yet there's a lot of speculation about their scalability. I think if that perception can be changed, they'll fit into the first category quite well. However, I don't think they compete with component-based or RIA because they don't hold state or offer rich-media capabilities.
Sidenote: I find the scalability debate quite interesting. There's a fair amount of propaganda in Javaland that scalability can be achieved with appservers and clustering tools like Terracotta. If this is true, I've yet to read good solid proof of it. Most of the "how to scale" information out there suggests "share nothing" architectures that shard data and applications across several servers. Of course, there's scalability and then there's massive scalability. Can appservers and clustering solve massive scalability like Google and Amazon require?
The 2nd and 3rd categories have someone of a blurry line, so I'm hoping to figure out how to clarify that. There's also a lot of other factors that will go into choosing a web framework. What if you're simply trying to replace a home-grown framework with an open-source one? If you want to keep your backend and all its logic, does it make sense to use something like Seam, Grails, JRuby on Rails or even AppFuse? Probably not - all their wizbang features and CRUD generation doesn't mean much if all you're using is the web framework. Also, if your application requires support for non-JavaScript browsers (for 508 compliance), then GWT and JSF can be easily eliminated. I know that there are many claims that JSF doesn't require JavaScript, but I've yet to see a real-world application developed with JSF that expects JavaScript to be turned off. Progressive enhancement is a requirement by many of my clients these days.
What's your opinion? How can we make it easier for developers and companies to choose a web framework? Is categorizing application types a good technique?