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.
It looks like JDOM 1.0 might finally be released next month. The main motivation for this release after 10 betas? According to Jason, it's all about saving face:
As we got closer to the four year mark, JDOM began to be my own problem again. It wasn't that I had different use cases, I just didn't want to be the guy who never finished JDOM. There's nothing like a little face saving as a motivating factor.
Personally, I don't use JDOM, but I've heard good things about it.
From the springframework-devel mailing list:
I've revived my Quartz support classes for Spring today. They emerged from a job scheduling consulting
project I did in autumn 2003. We have concrete needs for this now at werk3AT, thus the revival: It's about
quite simple cron-style scheduling of application jobs.
I've revived my Quartz support classes for Spring today. They emerged from a job scheduling consulting
project I did in autumn 2003. We have concrete needs for this now at werk3AT, thus the revival: It's about
quite simple cron-style scheduling of application jobs.
The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBean, also allowing to register
scheduled jobs there via a <list> of <refs> to ScheduledJobDefinition beans. A ScheduledJobDefinition
is just a simple combination of a Quartz JobDetail and a Quartz Trigger.
ScheduledJobDefinition bean implementations include:
- DefaultScheduledJobDefinition, allowing to use any implementation of Quartz' Job interface with a
declaratively configured job data map and cron trigger
- MethodInvokingJobDefinition, allowing to specify a method of a Spring-managed bean to execute as job
(completely declarative, without the need for implementing a custom Job object), with a cron trigger.
Both job definition beans can link in a separate Quartz Trigger instance instead of a cron expression;
DefaultScheduledJobDefinition can also link in a separate Quartz JobDetail instance instead of a job class.
Very nice!
Overheard this evening on Gavin's site:
My performance tests are showing a really big difference in performance, just from removing the finalizer. For one problematic test, I actually halved the overhead of Hibernate!
I can barely believe this result, but I've been successfully reproducing it for the last two hours.
Time to ditch those finalizers eh?
After reading this thread comparing JUnit in Action to Pragmatic Unit Testing, I broke down and bought both the CVS and Unit testing books. They're short and sound sweet - just how I like 'em. I'm hoping I can knock each one out in a few days.
I definitely need to learn more about using (when/how) Mock Objects for unit testing - my fingers are crossed that this book has the answers I'm looking for.
As I'm developing this morning and pulling a drop-down list from the database, it hit me - I'm not internationalizing these drop-down values. Sure, putting them in the database makes it easier for admins to edit the values, but if a user visits the site with a Spanish locale, they're going to get English drop-downs. So how do I fix this?
Is the best solution to put the drop-down choices in Struts' ApplicationResources.properties file so that I can render the values with <bean:message/> or <fmt:message/>? How do you do it in your webapps?
In some cases, I guess it doesn't matter as the values need to be in English. Take for instance, AppFuse's edit user screen (user/pass: mraible/tomcat). The list of roles comes from the database and should always be in English because the form-based authentication depends on having an English role_name value in the user_role.role_name column - since this is the value coded in web.xml.
Mike Lawrence (the guy who wrote the AppFuse on Orion tutorial), sent me an e-mail yesterday asking about AppFuse 1.3 (the latest release) vs. 1.4 (still in CVS).
Spring This looks like a pretty new framework. I wonder how stable it is? How far along are you with 1.4? You've made more changes to 1.3 to move to 1.4 than I've made to 1.3. So, I'd be better off just taking your 1.4 base and integrating my changes. Did you eliminate struts as the MVC framework? Doesn't this invalidate your awesome AppFuse tutorials? I'd really like to stay in sync with your new release, however, I've got major production deadlines to meet. It would stink if I automated a bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to 1.4, will I be facing stability issues and no tutorial docs?
I figured it'd be better if I answer his questions here, as other folks might be wondering the same thing.
Spring - how stable is it?
As with most open source projects, the version number doesn't always indicate the stability of a product. Roller hasn't reached 1.0, but I would venture to say it's a mature and stable product. If you asked this question on the Spring mailing list, you'd likely received a lot of responses saying that it's very stable and used in many production systems. IMO, it's a very stable framework and likely to be the next Struts (in terms of popularity). I don't know that it's MVC framework will be that popular, but it's persistence support classes, declarative transactions and AOP framework are pretty slick. The fact that it integrates smoothly with all leading MVC frameworks is a nice touch too.
I think the best answer is - you need to work with Spring and then decide for yourself. I love writing one-line DAO methods for Hibernate...
How far along are you with 1.4?
If you're already started an application with AppFuse version x, then you should stick with AppFuse version x until your project is finished. It's often a real pain to upgrade an existing app to use the latest stuff, and probably unlikely you'll gain that much value. However, if you're not under a tight deadline - and you really need something in a more recent release - it makes sense to upgrade. The tutorial I wrote on upgrading a 1.3 app to 1.4 is probably a one-time thing. I don't plan to do an upgrade document between all releases.
That being said, if you have enchancements for AppFuse and want me to roll them into the main code base, the best way is to create patches for the CVS version and then it'll be easier for me to figure out what you changed.
Did you eliminate struts as the MVC framework?
Definitely not - Struts will remain as the standard MVC framework because it is the most popular and most AppFuse users will likely use it. When I add MVC alternatives, they will be packaged similar to the iBATIS option - so you'll have to install them. Most MVC options will likely rip out Struts and replace it with their own stuff.
Doesn't this invalidate your awesome AppFuse tutorials?
The tutorials will be updated to support the latest release. I hope to have some time in early March to update these. As soon as I do, I'll release 1.4.
I'd really like to stay in sync with your new release, however, I've got
major production deadlines to meet. It would stink if I automated a
bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to
1.4, will I be facing stability issues and no tutorial docs?
Staying in synch with AppFuse as I push out new releases is probably a waste of your time. I did it with Struts Resume for a long time, and it's a lot of work trying to keep up. I firmly believe that each release of AppFuse has been a solid one - they just keep getting better. The only reason to upgrade is for new features and/or bug fixes. I believe that 1.4 will be just as stable as 1.3 and there will be tutorial docs when its released. As far as your automation stuff, the best way to get that added is send me patches against CVS.
BTW, Mike has integrated Middlegen into his AppFuse-based project. He's also working on generating stubs of a lot of the DAO/Manager/Action files - I believe that's his automation stuff. Thanks for giving back so much to AppFuse Mike - now if I only had more time to keep up with your enhancements. ;-)
Apparently Visual MainWin allows you to write your webapps in C# and .NET and then deploy them to a J2EE server.
Visual MainWin for J2EE enables these organizations to deploy .NET and J2EE applications on a single J2EE infrastructure, eliminating the need to maintain two separate application servers or implement complex interoperability solutions between the .NET and J2EE platforms.
This product certainly won't do anything for me. I've heard that Visual Studio is a great IDE, but if I can't write Java in it - what's the point?
Then again, I'm biased. I have a friend who is a long-time Java developer. Lately, he's been developing in C# because that was the only gig he could get (in Nevada). He says that C# is a piece of sh*t compared to Java.
Update: My friend contacted me to set the record straight. To quote him, "C# is OK, its the .NET framework that sucks ass. The C# syntax is a total ripoff of Java anyways."
Nick has an Ant tip that I can put to good use.
This A little-known Ant feature is the hyphenated target name. If you have a target name that starts with a "-", such as "-test-setup", you will not be able to call that target from the command line. Developers creating utility targets in their build.xml files can use this to avoid confusing other developers with irrelevant support targets.
There are a fair amount of internal targets in AppFuse that don't need to be visible and can't be really be called from the command line. Last time I checked, IDEA and Eclipse both allowed hiding of internal targets - so I rarely see these, but it might be a good idea to make them more explicit. I'll put it on my what-I-can-do-when-I-get-bored list.
Yesterday, I ported an AppFuse application (based on 1.3) to use all the latest stuff I've done in the last month. Basically, I just renamed and reorganized the directory structure, integrated Spring to bind everything together, and implemented the new Remember Me functionality. If you want to upgrade your (AppFuse-derived) webapp to use Spring, I wrote up an article on how I did it. It's quite a process, but hopefully this article will make it a lot easier. Now I can use Tomcat 5 as my primary app server (vs. Tomcat 4) - sweet!
Gregg Bolinger has reviewed Pro JSP and gives it 10 horseshoes! Very nice - thanks Gregg! The book from which AppFuse was born...
