Code Adept » book

Flex on Java update

Jeremy Anderson — Sat, 18 Apr 2009 02:03:03 +0000

Over the past few months my co-author and I have been working hard at reworking much of what we have already written for our book in order to hopefully result in a much better book for our readers. Earlier today Manning released a letter explaining the delays in any updated chapters to those who have purchased a MEAP subscription to our book. The letter reads as follows:

We would like to take a minute to personally update you on the progress of our book. Although we are running behind the originally estimated release date, the end product will be a much better learning experience. From the beginning we have been continually refining the book and have taken the great feedback we’ve received to align the book more closely to your thoughts and insights. If you are receiving this letter and were part of the reviews, THANK YOU! Much of the feedback received, all helpful, really matched with how we (the authors) were feeling and helped us to really home in on what we felt would be important to include. Here are just some of the things that can be expected out of the new and improved Flex on Java.

Developer accessibility
When we started the Flex on Java journey we wanted to write a book that would assist Java developers in refactoring Java applications with the richness of Flex. Unfortunately, the sample application wasn’t a good fit for everything we wanted to teach and was absorbing too much of our time trying to make it work properly for the readers. The sample application was an open source product that was not easy to download, build and go. This issue caused us to rethink our approach and we turned to Matt Raible’s AppFuse framework that is aimed at helping developers build applications quickly and efficiently. AppFuse makes deployment and creation of the sample application a breeze and also opens the door to developers who are new to Java. It allowed us to focus more on the topic of integrating Flex with Java while broadening its audience to those who are not Java or Flex gurus.

Hit the ground running (faster pace)
The free chapter available will become an introduction to the book and chapter 1 will now get readers rolling with development on the first page. Chapter 1 will begin with developing the server-side application with the AppFuse framework and then quickly begin integrating Flex in chapter 2.

Deepening focus on Flex integration with Java
The faster tempo and more narrow focus on the topic of Flex and Java integration allows us to quickly go deeper in that topic. We will discuss how to use BlazeDS to connect to the Java server-side including POJO services, Spring services and Spring security in more detail. We will also include working with real-time JMS applications utilizing the Flex and Java APIs.

More focus on scalable frameworks
Good developers move from technology to technology and look for frameworks that allow them to avoid the common problems when designing an application. Frameworks for doing both dependency injection for creating loosely coupled applications and Model-View-Controller (MVC) will be explored in more detail. Frameworks such as Spring ActionScript, Cairngorm, and Pure MVC (and possibly others) will be demonstrated.

House cleaning
There are other topics like building the application with Ant and setting up continuous integration that are important but not part of the main gist of the book, so we moved those topics into the Appendices of the book. There are other housecleaning items that are being performed to make this the best book possible on integrating Flex with Java.

We hope that you will be delighted with the upcoming changes to the book. Please feel free to provide us with any feedback you may have for us. Thanks again!

Sincerely,
BJ Allmon and Jeremy Anderson
Authors of Flex on Java

Tagged: book, flex, java, RIA

Flex on Java to now leverage AppFuse

Jeremy Anderson — Sun, 18 Jan 2009 15:41:03 +0000

Well the 2/3 review of the book I’m currently writing, Flex on Java, has just been wrapped up and we’ve gotten some wonderful feedback from our reviewers, both good and not so good. I’m learning that the not so good reviews are sometimes more useful in helping us to refine and improve the book in the long run. More than one reviewer had commented, and I had started to believe this myself before the review even began, was that the sample application that we had decided to use was too cumbersome and involved too many workarounds to make it work.

My co-author (BJ Allmon) and I had originally intended to leverage an existing application that we would refactor to use a Rich Client interface so that the experience would more closely resemble the audience we were originally targeting; the Java developer who would be tasked to integrate Flex with their existing application. So after much thought and some suggestions from some co-workers, we decided on XPlanner would be a good candidate. XPlanner was a project that hadn’t seen any real development in a couple of years, it’s infrastructure was not chosen with Flex in mind, and it was a sample application that we really wanted to make work.

Unfortunately the more we tried to make XPlanner work with Flex, the more we realized this was a bad idea. The SOAP implementation had to be tweaked because for some reason when doing inheritance with Axis the ordering of the elements in the SOAP response are out of order, which screws up Flex’s parsing resulting in some elements being returned as null when unmarshalling the objects in ActionScript (http://bugs.adobe.com/jira/secure/attachment/17509/Flex3Bug.txt). That was fixed fairly painlessly but once we got to the point where we were attempting to integrate with BlazeDS we quickly learned that most of the functionality we needed to populate the screen was not exposed as a service, but rather many of the CRUD operations were implemented in JSP custom tags, so we were forced to have the reader implement those in order to follow along. It was becoming apparant that this wasn’t going to work out.

After much reflection over the holidays, I had come to a solution. We would remove XPlanner from the book as a sample application, even though I was dreading the thought of having to build up a sample Java based web application from scratch so late in the game. I was longing for some sort of framework that would help me get a web application up and running, and quickly, kind of like Grails but for Java and not Groovy.

Then the answer came to me, AppFuse. For those of you not familiar with AppFuse, it’s basically a skeleton Java web project that provides many services for you out of the box. You then plug in all of your application specific code and build on top of AppFuse to create your application. This was the answer I needed. This also allowed us to now address one of the other comments that we received from our review; our book had assumed some high level of Java and Java web application knowledge effectively alienating the Flex developer who wanted to break into Java web development on the back-end. It also allowed us to not stray too far from our original goal of an existing application for the basis of a sample application. Even though we’ll now be building up the Java portion of the sample application in our book instead of using an existing one, by leveraging AppFuse we’re following many best practices for Java web development that make no assumptions about the view technology being leveraged, and developers with existing applications they want to refactor should easily be able to adapt anything in the book to their specific environment.

I must admit that I’m getting very excited about this new direction, I had rediscovered AppFuse which had played a role in me learning Spring and Struts, and helped me to refine my views on what good Java web application architecture consisted of. Even though we’ll now have to refactor half of our book to accomodate this new sample application, I’m confident that it will not only improve the quality and clarity of the book, but it will also open up the book to a whole new audience that we weren’t targeting before.

Tagged: appfuse, book, flex, java, RIA

My New Year’s resolutions

Jeremy Anderson — Mon, 05 Jan 2009 13:29:59 +0000

Wow, it’s the new year already. A time for everyone to make new years resolutions to make promises that they’ll not keep. This year I’ve decided to actually make a few resolutions for myself, even though I usually don’t make new years resolutions. I’ve put a lot of thought into these and decided to not make the same resolutions that everyone else does about eating better and getting more exercise, as evident by the sudden influx of people at the gym these past few days, I’ve already resolved to doing that a long time ago and don’t need a special occasion to give me an excuse. Rather I’ve made a couple of hopefully attainable goals for myself in this new year.

Finish Idle Projects

Over the past few years, I’ve started several projects that have never seen completion. The trim in the bedrooms that has yet to be finished. The drywall in the basement utility room from when we discovered that the previous owners of our house had tried to make a closet for the play room, and ended up walling in one of the basement windows. The drywall patching in the bathroom where we discovered a gaping hole that the previous owners didn’t bother closing up, but rather hid behind the hideous giant mirror. The book that I’m writing for Manning, granted this one has not sat idle like the other ones, but still needs to be finished. Finally the cedar strip kayak that is about 90% finished and has been hanging from the ceiling of my garage for the past few years. The kayak may be difficult to achieve this year as it is wholly dependent on how busy I am this summer as it needs to be fiberglassed, and the epoxy needs to cure at 60°F for like 12 hours, so I’m hopeful, but as long as I finish the other goals I’ll be happy.

Rediscover the joys of social gaming

A couple of years ago several of us used to have regular gaming nights where we would get together and game. At the time it was HorrorClix, which as most collectible games do put a huge strain on my wallet. So eventually the gaming tapered off and we quit getting together. Last summer my sister in-law got my wife hooked on Settlers of Catan, who in turn got me hooked on Settlers. I had forgotten how much fun a simple strategy board game could be, so I’ve resolved to breathing some life into the gaming nights that we used to host regularly, but this time we’ve decided to keep it simple (and hopefully cheaper) by playing non-collectible games such as Settlers or Axis and Allies, which are just as fun if not more fun.

Keeping it Simple

Lastly I’m resolving to keep things simple this year. I’ve been reading Bob Martin’s Clean Code and it’s inspired me to work on improving my code quality this year, which really distills down to keeping your code simple, concise and readable. Sometimes I forget that attaining that level of simplicity, is not simple at all. It takes a skilled craftsman to take something as complicated as software development and make the resulting code appear to be simple. I think Leonardo da Vinci said it best with “Simplicity is the ultimate sophistication.” So over the next year, I will be striving to keep things as simple as possible.

Tagged: book, gaming, new year, Rant

Resurrecting XPlanner

Jeremy Anderson — Thu, 07 Aug 2008 12:14:15 +0000

As you may have heard, I am currently writing a book (http://manning.com/allmon) on how to integrate Flex into a Java based web application. When we started this project, we had many ideas for what we were going to do for a sample application to use throughout the book. Too many titles out there either use trivial or incomplete examples that work well to showcase as much of the technology as possible but usually fall short in giving the user a clear picture of how to develop an end-to-end solution. So my co-author and I, through suggestion from a fellow developer, decided to base our sample application on the XPlanner project.

For those of you not familiar with XPlanner, it’s a project planning and tracking tool for agile development teams. We decided on XPlanner because we felt like it would be a good project that could very well represent the typical type of project that would be a candidate for refactoring to include a Rich Client front-end. It is a project that is not brand new, hasn’t been maintained in over a year, doesn’t have the latest versions of all the popular frameworks, and best of all; it was not designed with the intent of replacing the front-end with Flex.

Soon after I began spiking the sample code for our application, I discovered that a bug in the way Apache Axis handles SOAP inheritance would force us to not be able to connect to the Web Services without some modifications. This is not including all the changes we would need to make to integrate the BlazeDS server with XPlanner so we could take advantage of the AMF binary protocol. So we were forced to either host a modified version of the XPlanner sources ourselves, detail the changes that must be made in our book, or attempt to contact the XPlanner maintainers to get the changes introduced to the main project. I really didn’t like the idea of forking the project, and felt that providing a patch and making the reader apply that patch before following along with the code examples was less than desirable also. So I decided to attempt to contact the project maintainer, and after a couple of unsuccessful attempts I finally heard back from the maintainer Jacques.

So to make a long story short, it looks like I may be taking over maintenance for the XPlanner project. I am currently working with Jacques to figure out what needs to be done in the short term to get the latest release out the door, which is over 2 years in the making. I’m very excited about the opportunity to breathe some life back into the XPlanner project, and it would appear that the direction that I envisioned for XPlanner falls in line with the direction that Jacques was hopeful to take before other commitments tore him away from it.

What did I get myself into now…

Jeremy Anderson — Wed, 12 Mar 2008 18:03:39 +0000

Well, it’s now official, I’m writing a book. I’ve signed my contract, and there’s no turning back now. “You’re going to do what?” you may ask. My friend and cohort here at Pillar, BJ Allmon and I have begun the adventure of writing our first book, our first not only writing together but our first for each of us, tentatively titled “Flex on Java” for Manning Publications. Yes, Manning, you know those guys with all the great “In Action” books with the funny looking people on the covers. I’m really excited about this because I’ve always felt they put out good quality books, let’s hope that we don’t ruin that trend.

How we got here is kind of an interesting story. I’ve always been a big fan of RIAs and had looked at Flex a few years back in one of my “I hate HTML” phases and really fell in love. Unfortunately the price tag was really expensive and could never show a ROI on this really cool framework that provided such a rich user experience. Fast forward a couple of years and Adobe has acquired Macromedia, and decided to open source the Flex Framework as well as create an open source fork of their LiveCycle Data Services and now it is possible to do Flex development without spending a dime. So I decided to pick up a Flex book and re-acquaint myself with RIAs, only to struggle to find a good title that would show me how to integrate Flex into my everyday job as a Java developer.

A few months back I had somehow gotten on Manning’s list of people they call on to do manuscript and proposal reviews, and I had reviewed a proposal on Flex and AIR, and it looked interesting. Come to find out the authors pulled out at the last minute, and they were looking for someone to write a title on Flex. So, for whatever reason, I’m still not quite sure exactly why, I opened my mouth and volunteered. After a couple of exciting conversations with the publisher about what I thought would make a good Flex book, I decided to recruit BJ and put together a proposal.

Keep your eyes peeled for the MEAP to show up on Manning’s site in the near future. In the meantime I plan on blogging about the experience, when I’m not up to my ears in writing this book.