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.
Today marks the 6th anniversary of Abbie's birthday. Happy Birthday kiddo!
To see how Abbie has grown up over the years, see past Happy Birthday posts: #1, #3 and #4, #5. To celebrate, I'll be getting off early and having lunch with Abbie's class at school. After that, we'll be embarking on a Daddy/Daughter day where she gets to pick everything we do. I did this with Jack on his birthday and had a lot of fun.
Last night, I did a spike on AppFuse to change XML to Spring annotations (@Repository, @Service and @Autowired) in its service and data modules. While I was able to accomplish everything in a few hours (including converting tests), I did run into a couple issues.
AbstractTransactionalJUnit4..Tests vs. AbstractTransactionalDataSource..Tests
I've switched from my favorite Spring class to the annotation-happy AbstractTransactionalJUnit4SpringContextTests. However, this has presented an issue: when using ATDSSCT, I was able to call endTransaction() and startNewTransaction(). With ATJ4SCT, this doesn't seem possible. Below is a screenshot of the diff on a test method in the JPA implementation of UserDaoTest:
On the right, you'll notice that I had to comment out @ExpectedException to get the test to pass. This concerns me since this exception should be thrown. Is there a way to call endTransaction() and startNewTransaction() when subclassing AbstractTransactionalJUnit4SpringContextTests?
Instantiating GenericDao Implementations Programmatically
The second feature I tried to add is the ability to instantiate a GenericDao programatically rather than requiring a XML bean definition. In current versions of AppFuse, you can use the following bean definition to create a GenericDao for a model object.
<bean id="personDao" class="org.appfuse.dao.hibernate.GenericDaoHibernate">
<constructor-arg value="org.appfuse.tutorial.model.Person"/>
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
When moving to a no-XML required architecture, it'd be nice to allow users to create GenericDao's programmatically. Below is the easiest way I've found to do this in a test:
GenericDao<User, Long> genericDao;
@Autowired
SessionFactory sessionFactory;
@Before
public void setUp() {
genericDao = new GenericDaoHibernate<User, Long>(User.class);
genericDao.setSessionFactory(sessionFactory);
}
However, there's a couple problems with this. First of all, mixing constructor injection and setter injection probably isn't a good idea. Changing the constructor to take a SessionFactory solves this problem, but now all subclasses need to have a more verbose constructor:
@Autowired
public UserDaoHibernate(SessionFactory sessionFactory) {
super(User.class, sessionFactory);
}
Whereas before they had:
public UserDaoHibernate() {
super(User.class);
}
In an ideal world, I could call new GenericDaoHibernate<User, Long>(User.class) and the SessionFactory would be wired in auto-magically. Is this possible with Spring 2.5?
The 2nd problem this presents is your client code will now be dependent on an implementation rather than the interface. I don't know how to solve that one, but I'd love to figure out a way to create GenericDaos with no XML and no implementation details in the client. Any ideas are most welcome.
If you'd like to see all the changes I made in converting from XML to Annotations, please see this patch.
Last week, I attended a talk by Jason van Zyl on Comprehensive Project Intelligence. This talk contained a good overview of some Maven goodies that Jason's company has been working on - namely better repository management (Nexus), better Eclipse support (m2eclipse) and improving an awesome CI server (we use Hudson heavily at LinkedIn).
It looks like Jason is going to be doing a similar session in a full-day format at ApacheCon next week. The good news is it's free, the bad news is you have to be in New Orleans. Hopefully Jason and team will post their slides from this event and we can all learn how to use Maven more effectively.
In other Maven-related news, I hope to complete AppFuse 2.1 around the same time as Spring 3.0 (early next year). As part of that release, I hope to start using Nexus for AppFuse's repository as well as restructure its archetypes to allow using m2eclipse (with WTP) more effectively.
Last night, I stayed up into the wee hours of the morning working on something I've been wanting to do for a long time. It wasn't until I was trouncing around the woods in Montana that I realized how easy it would be. The something I've wanted to do was to modify AppFuse Light to use AppFuse's core modules (service and dao). It only took me a few hours to make it happen and it inspired additional ideas.
I believe the major mistake we made in AppFuse 2.x was making it easy for user's to upgrade their applications. We currently use the maven-war-plugin and our own maven-warpath-plugin to make it possible to include AppFuse classes and assets in your project. You can easily start a new project w/o having a whole bunch of files in your project. The problem is, you can't easily use "mvn jetty:run" to work on your project. Of course, you can use "mvn appfuse:full-source" to solve this, but I'm starting to think more and more that "full-source" should be the default. This is what we did in 1.x and it seems to be the more natural pattern for folks using AppFuse.
That hard part about moving to "full-source" by default is coming up with a way to share common assets and classes among wars and war projects. Sure, I can copy all the shared images, css and js into each project - but that could become a maintenance nightmare. Subversion 1.5 with relative svn:externals might solve this, but it still seems kinda hacky. I don't want to use the maven-war-plugin because the overlay is kinda hokey and I think it's easier for users to understand when everything is in their project. AppFuse's current directory structure in SVN looks as follows. I've added indicators of what is in each directory.
Rather than using AppFuse's current (manual) archetype-creation process, I'd like to move to a more automated creation process using the maven-archetype-plugin's create-from-project feature. I'd like to figure out a way where I can have the source code and assets from web/common included in each of the other web/* projects (both when using "jetty:run" and "archetype:create-from-project"). One idea I thought of is to make Jetty/Maven aware of multiple src/war directories for "jetty:run" and "package" and then somehow hook into the archetype plugin at creation time to pull in the shared resources. I don't know if something like this is possible. If you know of a good solution to this shared web assets issue, I'd love to hear about it.
Back to AppFuse Light. If I can figure out how to solve shared resources in web modules, I can use this in AppFuse Light to move to a modular SVN structure vs. its current "use Ant to create different combinations" setup. If a modular structure (like appfuse/web/*) is possible for AppFuse Light, I believe it makes sense to move its source into AppFuse's SVN repository. Below is how the directory structure might look after this move.
With this addition and "archetype:create-from-project", we should be able to create all the basic and light archetypes automatically. We'll probably still need a manual archetype-creation process for modular archetypes, but I'm OK with that.
The last thing I'm struggling with is figuring out the best way to create archetypes for something like AppFuse. In the past, we've used dependencies to allow users to inherit dependencies and their versions. This works, but it results in a lot of duplicate XML (in projects and archetypes) for developers. Last night, I tried using a parent project instead of dependencies and it seems to work much better. Not only do you inherit dependencies, but you also inherit plugins, profiles and properties. If you inherit, you can override, which is slick.
If you're an AppFuse user, how would you feel about having an AppFuse module as your project's parent? Would you prefer that, dependencies on AppFuse or full-source with no dependencies on AppFuse? Regardless of parent vs. dependencies, I think running "appfuse:full-source" should allow you to de-couple your project from AppFuse.
After the Software Summit last week, I sped down I-70 towards Denver. I made it to DIA with no time to spare. I had to run from the train to the gate, where the lady told me she'd been calling my name for the last 5 minutes. The fact I made the flight was a nice beginning to a wonderful weekend with my Dad in Montana.
It's been awhile since I've been to The Cabin in the fall. The Tamarack's were dressed in yellow and the sun warmed the land the entire weekend. It was cold at night, but we had my Grandma's ol' wood cookstove to keep us warm.
Hunting was a blast.
I haven't done it since I was a kid and I have memories of boredom. This time was different. My Dad and I basically trounced around the woods at the ol' homestead (120 acres) for hours on end with guns in our hands. What's not to like about that? Anytime outside of hunting season, people would think you're crazy and you'd probably believe them! Besides hunting and target practice, I got to hear a lot of stories from my Dad, explore all 4 corners of our property, chop wood, haul water and create super-hot saunas.
On Sunday, my Dad spotted a doe on our front-road and got a shot off, but missed. 20 minutes later, I got a chance at the same deer when she poked her head out from behind a tree 30 feet away from me. Unfortunately, I had a .30-06 strapped to my shoulder and couldn't get in position fast enough. After she ran off, we hunted her for a couple hours. We saw her a few more times, but didn't have any success.
The best part is we still had a ton of fun. One thing's for sure: I'll be at The Cabin during hunting season from now on. 
Last week, I attended the Colorado Software Summit in Keystone and had a great time. Not only was the weather beautiful and the food delicious, the sessions I attended were awesome. If you ever get a chance to go to this conference, I highly recommend it. It's like being on vacation and learning with a bunch of old friends.
Yan Pujante also attended this conference and documents his experience, photography and presentations in Colorado Software Summit 2008.
Below is a list of my entries for all the sessions I attended.
For next year, I think the conference should shorten its sessions (from 90 to 60 minutes), invite more speakers and cut the price in half (to $999 per person). How do you think the Software Summit could be improved?
Subbu works at Yahoo! developing standards, patterns and practices for HTTP web languages. In the past, he was a web service and Java developer. He was also a standards contributor at BEA and an author of books on Java EE. His current passion is HTTP and REST. Subbu confesses that he's not a web developer, has no interest in the internals of programming models used for web frameworks and he's only interested in the visible aspects of the architecture.
"The Web is Mostly Restful"
Being RESTful in an abstract sense means:
In the web today, some resources and URIs are personalized, but most are not. Some depend on sessions, but most do not. The consequence of a personalized UI with a non-unique URI is you cannot rely on browser caching.
The web is full of different representations (HTML, XML, JS, PDF, CSS, Flash). The problem with HTML is you can't tell links that you want a particular representation based of a link. The links are hard-coded to be a particular content-type. However, some media types on responses are ignored. This is often a problem with browsers and whether the user has plugins installed.
The Uniform Interface for the web is HTML and primarily links and forms (GET and POST). There's still some misconceptions (e.g. POST is secure). However, it's not about security, it's about idempotency and safety. You need to make sure you only use POST when you're changing data. POSTs are not repeatable. GET URIs are not always refreshable, which is quite unfortunate. Users shouldn't have to fight the back button.
Caching is a fundamental aspect of the web. Even in a personalized site, most of the content can be cached. The web is read-only for the most part. However, many enterprise web applications don't take advantage of caching. This is fine when there's not that many users, but it's bad when you want to scale to thousands of users. There's several frameworks that use cache-busting and prefer backend caching over HTTP caching. These frameworks are not using the web like they should.
Backend caching (e.g. Memcached) uses a non-uniform interface and you need to explicitly program to it. Frontend/HTTP caching has a uniform interface that's pluggable. Backend caching is generally more expensive to develop and deploy. There are cases where data should be cached on the backend, but you shouldn't focus all on backend caching w/o doing some frontend caching.
With Ajax, you get more opportunities to be RESTful. XMLHttpRequest is another HTTP client that can be programmed to. It has full support for the uniform interface, which allows content negotiation, optimistic concurrency and caching. Cross-domain hacks can be done with <script> and <iframe> to tunnel requests over GET. The W3C has been working for the last two years on how to do cross-domain Ajax w/o using hacks. The problem with current cross-domain implementations is they often use GET for everything, which isn't very RESTful. Subbu recommends using a proxy on the same domain if you do need to talk to other domains. This will allow your Ajax code to remain RESTful.
Web Frameworks
Web development is hard because of all the moving pieces that exist. Because of this, many web frameworks have been created to solve the various problems. In 1997, there were servlets. They provided basic plumbing and closely reflected HTTP/1.1. Servlets provided a poor programming model, but it allowed a lot of frameworks to be built on top of it. We don't use servlets to write applications, only to write application frameworks. The second era came about in 2001 when Action-oriented frameworks became popular. In 2004, JSF and friends came to play. JSF is a component-based framework with known limitations (complex, slow, uses POST for almost everything, Ajax is difficult). These limitations have resulted in a number of third-party patches being developed to solve these issues.
JSF was designed to use the request to create a component tree that maintains state. Unfortunately, the state is not something the developer has control over. It's not the state of the application, it's the state of the components. The client's knowledge of the state is mentioned with a cookie and the server keeps the state in the session. The problem with JSF is you don't have a choice of state in your application - you can't write stateless applications like you can with servlets.
JSF uses overloaded URIs for its resources. When you have one URI with multiple representations, there's no way to tell how a representation was chosen. JSF's compromise is to allow client-side state saving. However, they do this by putting hidden field in the form and requiring POST for navigation.
JSF vs. REST
Basically, these two are at opposite extremes. JSF is focused heavily on a UI component model. The people that developed it misinterpreted how the web works and made some fundamental questionable choices. You can patch it, but you can not fix it.
Web 2.0 Frameworks
GWT is a cross-compilation based framework. You write Java to generate JavaScript (b/c everyone hates writing JavaScript). It mashes client and server code into a single source. These layers communicate using GWT-RPC. Typical RPC concerns do not apply since code generation handles coupling and the client is downloaded from the same application. GWT-PRC does POSTs to the server and uses HTTP like a transport layer. To be fair, GWT does allow you to use a RequestBuilder to use the web like it should be used.
This class allows more control over HTTP requests, it supports GET and POST and it allows so-called RESTful layers (GWT-REST and GET-Restlet). GWT is focused heavily on ease-of-use, which is good. It's modeled after RPC and breaks the uniform interface and focuses on backend caching. Unlike JSF, GWT is fixable, but the community tends to use RPC instead of RequestBuilder.
SOFEA has a central promise of SOA. Business logic is a reusable service that changes less often. The presentation application calls those services and changes more often. The nice thing about this type of architecture is it allows a separation of concerns and loose coupling. However, it doesn't embrace REST like it should. Appcelerator is an implementation of SOFEA that has a Ruby on Rails-like usability. However, it uses a SOAP/HTTP style with messaging and POSTs to a single URI. Appcelerator is interesting, but it introduces a different style of coupling. It breaks URI opacity and client deals with POX instead of links.
Conclusion
Don't fight the architecture of the web. Innovate and enhance instead of breaking. If nothing else, break judiciously. As developers, we should demand more from our frameworks and make sure they use the web and HTTP like it should be used.
I'm sitting in Bill Dudney's talk called Core Animation on the iPhone: How to Build Animated UI's. All of the animations on the iPhone are done with Core Animation. Bill is going to start by doing a brief intro to Objective C. Objective C is a dynamic object-oriented language. It's C-based and has Smalltalk roots. Objective C is 2 files - one is a Header and one is the Implementation. They are marked with @implementation and @interface. Properties are declared with a @property keyword and a get and set method are created for you.
Layers are nothing more than 2-dimensional layers living in a 3-dimensional space. You don't need to know anything about OpenGL to use Core Animation. All of the complexity is pushed behind the API and everything runs on the video card. This allows you to get really, really good performance. Core animation is actually built into Keynote on OS X and bill is showing some demos right in his presentation.
You can build user interfaces on the iPhone with Views or Layers. The best way is to use a View with Layers and Events. The View listens for Events and do the right thing. There are several methods you can implement when writing a view: touchesBegan, touchesMoved and touchesEnded. These allow you to capture when a person touches the screen and they each take a set of NSSet objects, where one exists for each finger. On the iPhone simulator, you can use the Option + Mouse to simulate two fingers.
Animation in Core Animation is implicit. If you change a value on a layer, the layer is going to animate that property change. They can interpolate floats and integers as well as origin (width and height). If you change colors, it'll fade between the two colors. The default animation length is 1/4 of a second.
For the next 20 minutes, Bill did a bunch of live coding to show how easy it is to do animations, as well as how you can group animations together. It looked fairly easy if you know Objective-C.
The iPhone OS is Unix, so you should be able to use any Unix utilities on it. The Mac is really good at drawing. Quartz is the underlying drawing framework on the Mac and iPhone. It's basically an API for Illustrator/Photoshop that allows you to programmatically do what those programs allow. Anything you can do with Illustrator/Photoshop can be done programmatically with Quartz. All of that power that's available on the Mac is available on the iPhone. The final piece of drawing technology is OpenGL. The Cro-Mag Rally game was originally written 5 years ago for the Mac in OpenGL. The creators were able to port it to the iPhone in 1.5 weeks.
Bill then went into OpenGL and how you can use it to build a trackball application. Good presentation, great speaker. Even though Bill did a good job of explaining how animations work, it's obvious that you must know Objective-C to do this stuff. I can't imagine what the code behind some of the cool iPhone games (i.e. Monkey Ball, Asphalt4) looks like.
Camel is a Java API that allows you to do message routing very easily. It implements many of the patterns found in Enterprise Integration Patterns. It doesn't require a container and can be run in any Java-based environment. Camel has a whole bunch of components - Bruce is showing a 6 x 10 grid with a component name in each grid. In other words, there's 60 components that Camel can use. Examples include: ActiveMQ, SQL, Velocity, File and iBATIS.
Chris Richardson asks "What's left inside of ServiceMix". Why use ServiceMix if you have Camel? ServiceMix is a container that can run standalone or inside an app server. You can run distributed ServiceMix as a federated ESB. Camel is much smaller and lightweight and is really just a Java API. ServiceMix 4 changed from a JBI-based architecture to OSGi (based on Apache Felix). They also expect to create your routes for ServiceMix 4 with Camel instead of XML. To process messages, you can use many different languages: BeanShell, JavaScript, Groovy, Python, PHP, Ruby, JSP EL, OGNL, SQL, XPath and XQuery.
Camel has a CamelContext that's similar to Spring's ApplicationContext. You can initialize it in Java and add your routes to it:
CamelContext context = new DefaultCamelContext(); context.addRoutes(new MyRouterBuilder()); context.start();
Or you can initialize it using XML:
<camelContext xmlns="http://activemq.apache.org/camel/schema/spring">
<package>com.acme.routes</package>
</camelContext>
Camel's RouteBuilder contains a fluid API that allows you to define to/from and other criteria. At this point, Bruce is showing a number of examples using the Java API. He's showing a Content Based Router, a Message Filter, a Splitter, an Aggregator, a Message Translator, a Resequencer, a Throttler and a Delayer.
Bruce spent the last 10 minutes doing a demo using Eclipse, m2eclipse, the camel-maven-plugin and ActiveMQ. It's funny to see a command-line guy like Bruce say he can't live w/o m2eclipse. I guess Maven's XML isn't so great after all. 
Camel is built on top of Spring and has good integration. Apparently, the Camel developers tried to get it added to Spring, but the SpringSource guys didn't want it. Coincidentally, Spring Integration was released about a year later.
Camel also allows you to use "beans" and bind them to Camel Endpoints with annotations. For example:
public class Foo {
@MessageDriven (uri="activemq:cheese")
public void onCheese(String name) {
...
}
}
Other annotations include @XPath, @Header and @EndpointInject.
Camel can also be used for BAM (Business Activity Monitoring). Rather than using RouteBuilder, you can use ActivityBuilder to listen for activities and create event notifications.
Bruce had quite a few folks show up for this presentation. I had trouble finding a seat because I was late. I think he did a good job of showing what Camel is and how you might use it.
This afternoon, I delivered my Building Rich Applications with Appcelerator talk for the 3rd time at Colorado Software Summit. When I first proposed this topic, I hadn't used Appcelerator and saw this as a good opportunity to learn more about it. I'm glad I did.
IMO, Appcelerator is a lot like Dojo in how it parses pages and turns HTML with special attributes into JavaScript widgets. I can't help but think a pre-compilation step would be nice to speed things up. I like Appcelerator's extensive Widget Library, and I especially like that they re-use many widgets rather than re-creating their own. Finally, I really dig the "SOA in a browser" approach where everything is a message and you can easily publish and subscribe to events - on the client and server. Below is my presentation, please let me know if you have any questions.