On my last day at the conference I missed the morning general session where James Gosling talked about all the cool toys out there that were written in Java. I am definitely going to download the video and watch it this weekend. You can find it here.
Comparing the Developer Experience of Java EE 5.0, Ruby on Rails, and Grails: Lessons Learned from Developing One Application::
This was a pretty good talk in that they compared the same application written in Ruby on Rails, Grails, and Java EE 5. They highlighted the frameworks to help developers decide where to invest time. They spent a little bit of time going over the background of Ruby (this was a conference after all). they covered:
1. jRuby
2. Tools
3. Rails
4. What Sun is doing with Ruby/jRuby
5. How the popularity has grown over time.
Under rails they talked about:
1. Controllers
2. Models
3. Views
4. Active Records
5. webbrick
Under grails they talked about:
1. Based on Groovy (javascript programming language, integrates java, javaspec)
2. grails integrates with JEE5.
Why do people like using these things? It is because they are simple and fast. For their demo they went building the Ruby app using NetBeans 6 and got the Ruby extensions. They also used Faban to do their performance testing.
Finally, when they showed us the performance numbers we saw this:
Rails -> Max of 2k transactions per second
Grails -> Max of 3250 transactions per second
JEE5 -> Max of 11k transactions per second
They said this was with no tuning and that doing performance benchmarking is more artistic than scientific.
Other observations while going through their project were:
1. Native Ruby outperforms jRuby.
2. NetBeans IDE was the best for developing their apps (they were able to use it to deploy all three projects.
3. They had to do some tweaking to get the NetBeans IDE project to run on native Ruby.
As far as developing things went, for Ruby it was easy to get stuff and finish it quickly, but don't touch the database once the app is created because it is very difficult to change. They had to recreate the db every time they changed the app. For Grails there was a short learning curve, useful templates, there were simple examples to follow, and it is integrated with JEE5. Grails was not cool in that there is technology from everywhere, it is light on documentation, and there is very little tools support. JEE5 was cool because of familiarity, it can generate JSF CRUD, scalability, transaction support, tools, and standards. The not so cool part about JEE5 was that it was a lot of work and scaffolding to build a simple project. Here are some of the links they referenced at the end of their presentation:
1. Damian Cooke's blog
2. Ruby on Rails
3. Opensource Community
4. Benchmarking tool
Beyond Blogging: Feeds in Action::
This was a pretty good talk about the history of feeds and how the standards have progressed to where they are now. After going through the history, the speaker, Dave Johnson, then went through the REST API and ROME. He also demonstrated how to use ROME to grab feeds and do things with them like keep track of defects or build other applications. He also mentioned a site named feedvalidator.org. Overall it was a pretty good talk.
Minimalist Testing Techniques for Enterprise Java Technology-Based Applications::
Chris Richardson gave this talk about various testing techniques for java based apps. He has authored the book, POJOS in Action. He started by going over the state of testing which is basically that not enough testing is done and that developers need to do more to ensure quality. Some of the obstacles standing in the way are:
1. Cultural (seen as extra work, many believe their code always works, having things always go smoothly isn't generally rewarded, and it is another thing on a long of new things to learn).
2. Technical Obstacles (spaghetti code, bad frameworks, devs don't always make code testable).
Projects that don't do any unit testing can expect to see lots of manual testing, more bugs, long nights, and ample delays. But projects that do have test automation will have fewer bugs, be able to write new code more easily, and will have tests as a safety net. POJOs make testing easier. One reason for slow tests is that the test code runs outside the same jvm. You can minimize test time by have fast running unit tests and use continuous integration. But one problem is that when you add more and more tests your test suite takes longer and longer to execute. If you are developing an application that must talk to others, one way to speed up the testing is to do it with mock objects. There are several ways to create mocks. They are:
1. Write your own.
2. Use a mock object framework (jMock or EasyMock).
You can make the testing with mocks part of your JUnit test runs. But there are downsides to using mock objects for testing. They are:
1. It is essentially white box testing which means that you can cheat.
2. The tests can be brittle.
3. You have to mock selectively.
Other techniques discussed were testing database connectivity by using an in memory db (HSQLDB). It is way faster and easier than setting up a separate db instance but it might not work if you have to hand code the SQL and there may be some incompatibility with various systems. Another technique when working with databases is to do rollback on transactions. This way the tests run faster and it leaves the db unchanged. But the drawbacks of having the extra speed include committime constraints are not checked and code running in a different JVM interface can't see the changes. He showed a few demos and then preached the benefits of Selenium (I knew this guy knew what he was talking about :-) ). He also mentioned Cargo, which is a cool tool that will install, start, and stop applications. It also comes as a plugin for Ant and Maven. Using Cargo & Selenium you can startup your app, run automated web tests, and then shutdown the app. On my project we use Ant, Jameleon, and Selenium to do the same thing. Lastly he mentioned ORM Unit and did some demos.
Java Puzzlers, Episode VI: The Phantom-Reference Menace/Attack of the Clone/Revenge of the Shift::
This was a pretty entertaining talk with Joshua Bloch (Lead Java Architect at Google) and William Pugh (creater of FindBugs). They had 8 puzzles in java code that they presented along with multiple choices for what each of the 8 snippets of code printed out at the end. Then the audience got to pick what we thought was the right answer and then they talked about what was wrong with the code and what we could learn from it. I only got 3 out of the 8 right which tells me that I still have some work to do. But some of the people around me got less than me right, so I don't feel too bad. The puzzles were good and the session was entertaining so I went ahead and bough Bloch's book which is also pretty good so far.