Project Automation Experience

Algorithms for collaborative editing

Guillaume LaForge — Mon, 09 Jul 2012 13:00:41 CDT

We Want You!

Aaron Gustafson — Mon, 09 Jul 2012 11:00:39 CDT

We are looking for two talented folks to join our team here in Chattanooga. If you’re the kind of person that thrives on variety and want to live & work in a really awesome city, read on…

Minor new features of Groovy 2.0

Guillaume LaForge — Sat, 07 Jul 2012 13:00:27 CDT

Adding a license to source files

Kenneth Kousen — Sat, 07 Jul 2012 08:00:37 CDT

A few years ago I remember seeing a blog post by a person interviewing potential new developers. He said that when the prospect featured Java prominently on their resume, he would make sure to give them a programming test that would be easy to solve in a different language but hard in Java, just to see how they handled it. He normally used some sort of file manipulation as an example, because Java makes that particularly challenging while scripting languages often make those problems simple.

About a week ago, someone contacted me about the source code from my book, Making Java Groovy. The source code is located at my GitHub repository, https://github.com/kousen/Making-Java-Groovy. The requester noted that I didn’t have any sort of license file on my code and wondered what the terms were.

Leaving aside the wonder that (1) somebody found the book code useful (ack! humblebrag alert!) and (2) he actually asked permission to use it, it occurred to me I really ought to have something in place for that eventuality. I asked my editor at Manning about it and she didn’t answer right away, so I interpreted that as freedom to do whatever I wanted.

A friend on a mailing list suggested that the Apache 2 license is appropriate if I don’t care too much how the code is used (and I don’t), so I decided to add that license to each source file. That brings me, at long last, to the original subject of this post: how do I add a license statement to the top of a large number of source files nested in many subdirectories?

I thought I would solve the problem with the eachFileRecurse method that Groovy adds to Java’s java.io.File class. I quickly realized, though, that there were directories I wanted to skip, and that lead me to the traverse method, which takes a Map of parameters.

Here’s the result:

import static groovy.io.FileType.*
import static groovy.io.FileVisitResult.*
String license = '''/* ===================================================
 * Copyright 2012 Kousen IT, Inc.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 * ========================================================== */
'''
dir = '/Users/kousen/mjg'
new File(dir).traverse(
    type       : FILES, 
    nameFilter : ~/.*(java|groovy)$/,
    preDir     : { if (it.name == '.metadata') return SKIP_SUBTREE }) { file ->
    // only add license if not already there
    if (!file.text.contains(license)) {
        def source = file.text
        file.text = "$license$source"
    }
    assert file.text.contains(license)
}

I used static imports for the FileType and FileVisitResult classes. The FILES constant comes from FileType, and the SKIP_SUBTREE constant comes from FileVisitResult. The parameters I used return only files whose name ends in either ‘java’ or ‘groovy’ and aren’t in any directory tree including ‘.metadata’.

Ultimately everything is based on the getText and setText methods that the Groovy JDK adds to the java.io.File class. Both are called using the text property. The getText method returns all the existing source code, and the setText method acts as an alias for the write method, which automatically closes (and therefore flushes) the file when finished. I used a multiline string for the license and included the training carriage return, so writing the license followed by the source did the trick.

The documentation for these methods is, shall we say, a little thin. I therefore did what I normally do in these situations: I found the test case in the Groovy source distribution. The test in question is called FileTest and can be viewed in the Groovy GitHub repository here. The test cases showed how to use all of the methods, including traverse, so it was just a question of looking for the right example.

(Incidentally, one of the less publicized but really sweet features of GitHub is the code browser. Just find the project you want and dig into the directories until you find a file, and then GitHub provides syntax highlighting and everything. It’s a great, great feature, especially if you don’t want to clone the source of every project you care about onto your own local disk.)

Since I hadn’t known about the traverse method ahead of time, and I messed up the regular expressions for a while (sigh), solving the problem took longer than I expected. Still, it’s hard to beat a solution that takes less than a dozen lines. Hopefully someone else will find this helpful as well. And regarding the job interview situation described above, to paraphrase John Lennon in the rooftop concert at the end of Let It Be, on behalf of Groovy and myself, I hope I passed the audition.

Agile and DevOps, A Perfect Match

Bruce Snyder — Fri, 06 Jul 2012 16:02:28 CDT

Through the years in my career, I have spent a fair amount of my time advising customers on agile software development. Having practiced various agile software development methodologies since the late 1990s, I've witnessed many implementations of agile, both successful and not so successful. In more recent years, the notion of agile has expanded across organizational boundaries and given way to a newer concept known as DevOps. While these two topics dovetail nicely and my years of past experience are relevant here, interesting questions always arise. Consider the following question that I received recently:

Question

What are the migration milestones in building out a DevOps group?

I suggest that this question be reframed a bit. For an organization to enter the world of DevOps means that one must adopt a mindset that is focused on agility in the processes and the methods used to execute those processes. It is very important that you identify the best way of carrying out that mindset across your organization and that it include not only software engineering, but also the customer, the business folks, quality engineering, test automation, release management, security, operations, system administration, etc. DevOps is about a fundamental reorientation to provide software in a more effective manner beginning with design and going all the way to production deployment.

Remember SOA?

I will draw an analogy here to a recent trend in software architecture. The concept of a service-oriented architecture (SOA) embodies a set of principles for designing and developing software. It's the 'why', not the 'how' of software architecture (i.e., SOA is a means to an end, not an end in itself). Numerous vendors took the SOA term and twisted this notion into a wrong-headed marketing message that basically said, 'Buy our software and you will be doing SOA'. I spent a lot of time dispelling this myth over the last several years, encountering much resistance along the way. But make no mistake, SOA is not a technology problem.

If someone asked me about forming a SOA group inside their company, I would tell them that they already have one and it encompasses the customer, the software architects, the software engineers, the quality engineers, the release engineers, the security experts, and the operations folks. There is no need to assemble a brand new group. Would you advocate the formation of an agile group inside a company? I certainly would not because interpreting a methodology in such a literal fashion seems to me like you are already driving the car into the ditch and through the corn field. When I was a kid I learned a term for stuff like this, an Arkansas screwdriver (also known as a hammer). Just because you can doesn't mean you should.

Over the years, I have worked with many companies to get them on the road toward designing applications by using SOA. When I do this, I lead the customer toward the identification of folks across the organization who can participate in this effort. I was certainly not alone in this effort and this style as there are many others doing the same/similar thing. Although we operated on the idea that we were coaching customers to develop apps using SOA via agile methodologies, I now realize that we were also already leaning toward DevOps. (Based on my research, this is really how the DevOps movement came to be what it is today.)

A Perfect Match

Getting back to the original question, I would not approach DevOps any differently than I have approached the coaching of customers into the use of agile methodologies. Continue to coach customers in this manner and you will be successful. Only now, we have even more information and wisdom telling us that this is not just for software engineers. This is a fundamental change for an organization and should be broken down as described on the Agile Admin blog like so:

Agile principles: The core values that form the agile movement (see the Agile Manifesto)
Agile methods: Methodologies for running an agile approach including Kanban, Lean, SCRUM, XP, etc.
Agile practices: Procedures for executing an agile methodology including Acceptance Testing, BDD, TDD, User Stories, Continuous Integration, Continuous Deployment, Daily Meetings (aka Standup Meetings), etc. etc.

I tend to think about DevOps in the same way that I think about agile or even SOA, but with a bit more reach across the organization. That is, DevOps is a set of principles for designing, developing, testing, deploying and supporting software. Each role will utilize different tools but they will all be involved in the overall software development lifecycle. DevOps is also a means to an end, not an end in itself. Some of it's main differences are that it cuts across an organization even further to include many roles and people, and it considers software development as a full lifecycle instead of only focusing on the software until its a teenager and then throwing it over the wall to operations and hoping it survives.

The Value of DevOps to the Business

Finally, the value of DevOps to the business is often misunderstood or not understood at all. Historically, the business side has treated software development as someone else's problem. The perception has often been that the propeller heads down the hall are responsible for the software, not the business side. This has always struck me as terribly short-sighted, especially for a company that would not make money without its software.

Consider another analogy here to depict this situation appropriately. Businesses love to equate themselves to sports teams and I've heard this one before, so I'll use the idea of a pro cycling race team (please forgive my cycling fever during this Tour de France season). A pro cycling team operates in a smooth, fluid manner handling anomalies as they arise without disruption. Like any good team it has the following characteristics:

A clear direction with clear support and resources from the business side
Team members have a good relationship with one another and with supporting companies or organizations
The team monitors many external factors that effect their performance and their success

Although a pro cycling team has its recognizable personalities in the riders, there are many more people behind the scenes who make them successful. Without the entire team working as one they will not be successful or will be less successful than they planned. The team sponsors, the directors, the managers, the mechanics, the masseuses, the assistants, the domestiques, and the recognized riders all must be in tune and ready for success. They each have well-defined roles and operate in tandem across organizational gaps to be the very best at everything in pro cycling. I don't believe that these teams would be successful if they did not include everyone in the orchestration. There's also certainly a lot of luck that needs to be on their side to be successful, quite like the business world.

A company that relies on its software to make money is very much the same. Consider the following comparisons:

Just as a pro cycling team has a clearly defined direction, so should a company that relies upon software. This message needs to be tuned appropriately to fit different areas of the business, but the overarching message remains – create a machine to make money.
Just as a pro cycling team has clear support from the business side to stay on top of the technology in its field, so should a company that relies upon software. This means that time must be dedicated to the craft of building software, continued education where necessary, the purchase of materials (books, publications, etc.) and tools, etc. Do you want excellent, highly talented mechanics, masseuses and domestiques or just mediocre ones?
Just as a pro cycling team forms close relationships between team members, so should a company that relies upon software. This doesn't just apply to folks who work in the same department. The most important relationships are those that span boundaries and break down barriers between departments within an organization.
Just as a pro cycling team learns to execute flawlessly together, so should a company that relies upon software. Consider that the software a business relies upon to make money is the bike and the rider that a pro cycling team chooses. Do you think that the pro cycling team just arbitrarily decides how to prepare and train for events? Or do you think the pro cycling team has a strict, regimented formula to its training and preparation? A business that relies upon software to make money should also have a strict, regimented formula for crafting, testing, deploying and supporting it's software. Without this level of capability, the ability of the business to make money on a consistent basis is hamstrung by its own processes or lack thereof.

Conclusion

The bottom line is this: A business that deems its software to be critical needs the ability to get that software to market in a consistent, repeatable manner every time. Period. How can this be achieved without involving all of the parties who touch that software in some way?

Updates for the Grails App Info plugin

Burt Beckwith — Fri, 06 Jul 2012 11:05:54 CDT

The app-info plugin wasn’t working in Grails 2.0+ because of an incompatibility between the Hibernate Tools jar and the version of Hibernate that Grails uses. So I split out the Hibernate-related functionality from the plugin into a to-be-released app-info-hibernate plugin, and once they release an updated version of Hibernate Tools I’ll be able to finish and release that. This also affected the db-reverse-engineer plugin but I was able to fix that with a hackish solution since that runs as a script (I fork a new process with a separate classpath) but that approach wasn’t feasible for this plugin.

The original blog post is still mostly valid but I wanted to point out some new features and make an updated test application available.

You install the plugin like any other, by including a dependency for it in BuildConfig.groovy, e.g.

plugins {
   ...

   compile ':app-info:1.0.1'
}

The plugin depends on the dynamic-controller plugin to configure what features are available, so you need to configure the active mixins in Config.groovy (omit any you don’t need):

grails.plugins.dynamicController.mixins = [
   'com.burtbeckwith.grails.plugins.appinfo.IndexControllerMixin':
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'com.burtbeckwith.grails.plugins.appinfo.Log4jControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'com.burtbeckwith.grails.plugins.appinfo.SpringControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'com.burtbeckwith.grails.plugins.appinfo.MemoryControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'com.burtbeckwith.grails.plugins.appinfo.PropertiesControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'com.burtbeckwith.grails.plugins.appinfo.ScopesControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'com.burtbeckwith.grails.plugins.appinfo.ThreadsControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController',

   'app.info.custom.example.MyConfigControllerMixin' :
      'com.burtbeckwith.appinfo_test.AdminManageController'
]

This configures a dynamic AdminManagerController and I like to map its urls to /admin/manage, so I add these lines to UrlMappings.groovy:

"/admin/manage/$action?"(controller: "adminManage")
"/adminManage/$action?"(controller: "errors", action: "urlMapping")

"403"(controller: "errors", action: "accessDenied")
"404"(controller: "errors", action: "notFound")
"405"(controller: "errors", action: "notAllowed")
"500"(controller: "errors", action: "error")

The first is the expected mapping, and the second “un-maps” the one that gets auto-created by the "/$controller/$action?/$id?" rule. It does this by using the urlMapping action in ErrorsController (see the test app for the source) to send a 404 error code. Since I’m using a controller for this, I also map the standard error codes to be able to have custom GSPs for each.

If you’re using the spring-security-core plugin you can then guard access to all the plugin’s actions with one mapping:

grails.plugins.springsecurity.controllerAnnotations.staticRules = [
   '/adminmanage/**': ['ROLE_ADMIN']
]

The plugin also includes a configuration demonstrating the new support for adding extra menu items (see GPAPPINFO-19) so the test app includes the app.info.custom.example.MyConfig class in src/groovy, the app.info.custom.example.MyConfigControllerMixin mixin in grails-app/controllerMixins, and the views/myconfig/configs.gsp GSP. This is all plugged in with this configuration in Config.groovy:

grails.plugins.appinfo.additional = [
   "My Config": [
      configs: "Configs"
   ]
]

There’s also a new thread dump mixin (see GPAPPINFO-20) and this is enabled by configuring ThreadsControllerMixin (see the grails.plugins.dynamicController.mixins config map above). The menu item is “Thread Dump” in the Info menu.

You can download the test application (it uses Grails 2.0.4) here. Once it’s running navigate to http://localhost:8080/appinfodemo/admin/manage/ and authenticate as admin/password to try it out.

Tiggzi at Bootstrap Week: Lectures for Mobile Devs

Max Katz — Fri, 06 Jul 2012 08:01:58 CDT

Bootstrap Week is one week in a month were a bunch of really cool companies and services give presentations and provide help on everything mobile related. Definitely check it out, you will find a lot of interesting stuff.

Tiggzi is part of the Bootstrap Week. You may sign up for the Tiggzi session. Just notice that Tiggzi session is on Tuesday, July 10, 2012 from 12:00 PM to 1:00 PM (PT).

I will be showing how to build HTML5/jQuery Mobile apps as our new and just launched Tiggzi Database.

Building your Groovy 2.0 projects with Maven

Guillaume LaForge — Wed, 04 Jul 2012 13:00:21 CDT

Minor new features of Groovy 2.0

Guillaume LaForge — Wed, 04 Jul 2012 11:00:53 CDT

Groovy 2.0 support in Eclipse

Guillaume LaForge — Wed, 04 Jul 2012 08:00:52 CDT

Oh the Places You'll Go!

Rod Johnson — Tue, 03 Jul 2012 16:00:26 CDT

The last ten years has been an exciting and challenging journey for me and I’m very proud of the technology and community that my SpringSource cofounders and I fostered. However, there always comes a time to make a choice about the places you’ll go, and it’s time for me to leave VMware and pursue other Read more...

This Week in Grails (2012-26)

Burt Beckwith — Tue, 03 Jul 2012 13:00:30 CDT

My apologies for not doing a post last week; I was traveling (doing two Groovy and Grails courses back-to-back) and didn’t have time.

The big news of the last two weeks is the Groovy 2.0 release. Lots of cool stuff there including static type checking, static compilation, modularity, and Invoke Dynamic support. Check out Cédric Champeau’s “Groovy 2.0 from an insider” post, Andre Steingress’ “Groovy 2.0: Love for Grails Command Objects” post, and this older post based on a 2.0 RC, Writing sentences with Groovy 2.0.

Grails 2.1 RC3 was released and the 2.1 GA release will be out soon. Test it now to get an early start on your upgrade and to help find any remaining issues.

Matt Raible and James Ward did a Play vs. Grails Smackdown at ÜberConf. The Grails version of the app did very well, especially considering all of the Play/Scala fanboy hype that we’ve had to put up with.

Netflix open sourced their Grails-based Asgard management and deployment app.
Asgard. They’re also hiring a Grails developer (see the Jobs section for the link and details).

If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.

Translations of this post:

Miscellaneous Items
Plugins
Interesting Tweets
Jobs
User groups and Conferences

Miscellaneous Items

Plugins

There were 3 new plugins released:

federated-grails version 0.2.1. Uses Shiro and Shibboleth to integrate into federated authentication
font-awesome-resources version 0.1. Integrates the Font Awesome icon set
spring-security-eventlog version 0.2. Logs Spring Security events

and 13 updated plugins:

ajaxflow version 0.2.3. Enables Ajaxified Webflows
bcrypt version 1.0. Performs bcrypt hashing
cucumber version 0.6.0. Test your Grails apps with Cucumber
grom version 0.2.4. Sends notifications on Windows, Linux, and Mac
gsp-resources version 0.4. Use the resources plugin to include static files like main.css.gsp, so dynamically built CSS and JS can be served as proper files instead of inlined in a non-cacheable GSP file
guard version 1.0.6. Provides a way to run integration tests without having to repeatedly bootstrap the environment
handlebars-resources version 0.3. Supports using Handlebars.js templates with the Grails Resources Plugin
infinispan version 1.0.1. Adds support for the JBoss Infinispan distributed cache
kickstart-with-bootstrap version 0.6.0. Start your project with a good looking frontend, with adapted scaffolding templates for standard CRUD pages using Twitter Bootstrap
spring-security-saml version 1.0.0.M15. SAML 2.x support for the Spring Security Plugin
uploadr version 0.5.11. HTML5 Drag and Drop file uploader
xwiki-rendering version 0.6. Convert texts using XWiki Rendering Framework
yammer-metrics version 2.1.2-2. Packages Coda Hale’s yammer metrics jars

Interesting Tweets

@jeffscottbrown: I spent a little time tonight building a Groovy 2 Extension Module for datomic. https://t.co/Obj4vNk5 #groovy #datomic
@dmitrybrin: Got a call from JRebel rep asking how we handle our redeployment strategies during development cycle. My answer: #Grails ..sorry guys.
@glaforge: Nice to see a proposal for the next #JavaScript to include #groovy‘s safe navigation operator! http://t.co/frS2q7Ta
@burtbeckwith: “The Flying Car of Video Messaging” a #boston area #grails powered social video app
@pledbrook: First stab at performance tuning for #grails based on @lhotari email: http://t.co/l6NSSqp2 – feedback welcome!
@rfletcherEW: Want to automatically have a ‘last updated’ timestamp in your #cloudfoundry #grails app pages? https://t.co/NFMHyYUp
@graemerocher: Interesting . Grails smoked Play! in pretty much every performance benchmark. So much for Groovy vs Scala. http://t.co/LwUC9K9k
@divideby0: @graemerocher i also did a grails submission for the great web framework shootout: http://t.co/ScJrfBQM smoked both django and rails
@rfletcherEW: I’ve published a snapshot of my #angularjs #grails scaffolding plugin: http://t.co/cFHxcjUw
@rfletcherEW: Had fun TDD’ing my #grails #angularjs plugin with @casperjs_org. Good way to learn #coffeescript too https://t.co/31anE8sa
@ag1le: #skynews website http://t.co/A5gbcX2c and cms is now live – built using #grails – phew
@dhanushgopinath: @graemerocher I was previously part of a team which launched http://t.co/a2A3L6ds on #grails. Developing it was cool and fast.
@robpatrick: You know you are a #groovy developer when,… you can fix bugs with a shocked elvis ?: 0
@_cr381ve: Migrating to the new grails plugin repository – remember to request access and install release plugin 2.0.3 -> http://t.co/gmOPUgGJ
@giplugin: The Grails Infinispan Plugin has been released as version 1.0.1 and works with Grails version 2.0.4. Questions and comments are welcomed.
@andy_clement: The #groovy #grails tool suite (GGTS) is available ! Like STS but with groovy/grails built in: http://t.co/3rGKQScx
@Frans_van_Buul: Just migrated my current project to #groovy 2.0.0! Thank you @glaforge and team! rm -r src/main/java

Jobs

User groups and Conferences

GR8Conf US 2012
- July 29^th-31^st Minneapolis, MN
SpringOne 2GX 2012
- October 15^th-18^th Washington, DC

Griffon: JavaFX for the Enterprise.

Andres Almiray — Tue, 03 Jul 2012 11:00:30 CDT

A few weeks ago I presented a talk on JavaFX and Griffon in Linz hosted by eJUG. A couple of Griffon (Swing and JavaFX) applications were shown on stage, with two of them going toe to toe in showing how easy is to integrate JPA into a desktop application no matter the UI toolkit of choice. I'm going to reproduce both applications right here in order to show the similarities and differences between choosing Swing or JavaFX when building an application with Griffon. Let's get started.

Create the applications
The first step is to create both applications. Swing being the default toolkit of choice at the moment makes it for a simple command call, like the following one

$ griffon create-app sample1

Good, now creating the JavaFX application requires specifying an additional parameter that marks the application as a JavaFX one

$ griffon create-app sample2 --archetype=javafx

That wasn't so bad, we know have two fully working Griffon applications although they do nothing more than pop a window with a simple message when run. Let's change that.

Configuring JPA
The following step must be executed in both applications. What we'll do is install the JPA plugin, create a JPA entity, configure the default persistence unit, and bootstrap some data when the application starts.
Alright, installing the JAP is done in the following way

$ griffon install-plugin jpa

Done. Next create a file named Person.groovy inside src/main/data; you may need to create that directory first.

This is a standard JPA entity class, the Groovy language makes it easy to keep track of what's important by removing most of the visual cruft and verbosity . Now that we have this entity class is time to define the configuration for the default persistence unit the applications will make use of, this task is accomplished by creating a file persistence.xml inside griffon-app/conf/metainf

<?xml version="1.0" encoding="UTF-8" ?>
<persistence xmlnssi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
    version="2.0" xmlns="http://java.sun.com/xml/ns/persistence">
    <persistence-unit name="default" transaction-type="RESOURCE_LOCAL">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <class>data.Person</class>
        <properties>
            <property name="javax.persistence.jdbc.driver"   value="org.h2.Driver" />
            <property name="javax.persistence.jdbc.url"      value="jdbc:h2:mem:sample" />
            <property name="javax.persistence.jdbc.user"     value="sa" />
            <property name="javax.persistence.jdbc.password" value="" />
            
            <property name="eclipselink.ddl-generation" value="create-tables" />
            <property name="eclipselink.ddl-generation.output-mode" value="database" />
        </properties>
    </persistence-unit>
</persistence>

The applications make use of H2 and Eclipselink, dependencies that must be configured in griffon-app/conf/BuildConfig.groovy in a block that looks like this one

The last task in this step is to define some data that will be used to fill the database. A pair of files were added to griffon-app/conf when the JPA plugin was installed; one of these files is aptly named BootstrapJpa.groovy, which is exactly where we'll place the following code

Alright, these should be enough to take care of the JPA stuff. Time to move on to the next challenge: building the UI.

Adding Swing / JavaFX
The following screenshots show the Swing and JavaFX versions. you can appreciate both have the same set of elements though they look slightly different. Can you guess which is the JavaFX one? That's right, the one with the non-native look (pay no heed to the title)

So how does the UI of the first application is constructed? Griffon relies on a SwingBuilder DSL to make it easier to write the UI. With this DSL in place is easy to distinguish the component hierarchy and how elements are connected
griffon-app/views/sample1/Sample1View.groovy

The JavaFX view relies on a similar trick, that is, make use of a DSL however in this case it's based on SceneGraphBuilder (from the GroovyFX project). See if you can spot the real differences between both views
griffon-app/views/sample2/Sample2View.groovy

I must confess that binding model.people directly to the tableView's items property was done as a desperate measure as I couldn't get the tableView to be updated automatically whenever model.people (a JavaFX ObservableList) had its contents updated. Oh well, something to review when the next JavaFX release comes out (currently testing with JavaFX 2.2beta15 on OSX and JDK6 for those who care).

The views have references to their corresponding models and controllers. The models hold a reference to an observable list that will be used to update the table. In the case of Swing we'll rely on the excellent GlazedLists project (for which there's a plugin of course). Here's how the model looks
griffon-app/models/sample1/Sample1Model.groovy
package sample1 import data.Person import ca.odell.glazedlists.EventList import ca.odell.glazedlists.BasicEventList import ca.odell.glazedlists.SortedList class Sample1Model { EventList people = new SortedList(new BasicEventList(), {a, b -> a.id <=> b.id} as Comparator) }
For the JavaFX version the code turns out to be much simpler as observable lists are baked right into the JavaFX APIs. The JavaFX model looks like this
griffon-app/models/sample2/Sample2Model.groovy
package sample2 import javafx.collections.FXCollections class Sample2Model { List people = FXCollections.observableList([]) }
Now for the final piece, we must provide a suitable implementation for the controller actions. You may recall from the views that there are 2 actions in the controller: one to load the data in the table, the second to clear the table. And here's where things get really interesting as the code I'm about to show is practically the same, no matter if you're dealing with Swing or JavaFX
griffon-app/controllers/sample1/Sample1Controller.groovy
package sample1 import data.Person import griffon.transform.Threading import javax.persistence.EntityManager import javax.persistence.Query class Sample1Controller { def model def load = { withJpa { String persistenceUnit, EntityManager em -> List<Person> tmpList = [] tmpList.addAll em.createQuery('select p from Person p order by p.id').resultList execInsideUIAsync { model.people.addAll tmpList } } } @Threading(Threading.Policy.SKIP) void clear(evt) { model.people.clear() } }
Don't be fooled by the apparent lack of UI code found in the controller actions, as Griffon controllers follow some rules regarding how threading should work. For starters all controller actions are executed outside of the UI thread (whether that's the EDT in Swing or the JavaFX UI thread in JavaFX only the specific toolkit plugin cares). It's then safe to query the database using the JPA APIs inside the load action, however once the data has been computed we must update the model inside the UI thread as that change will trigger an update on the visual components bound to the people list (the JTable and the TableView respectively). The second action, clear, updates the contents of the model directly, and as such it should be done in the UI thread already, no need to jump to another thread just to come back immediately to the UI thread; this is why we applied an annotation that instructs the compiler to leave this action untouched in terms of thread management code injection.

If the usage of an application framework like Griffon was dubious at first I hope you think differently now. Apart from some toolkit specifics found in the View and Model, the application remains the same no matter the toolkit you're targeting. This proves to be of great advantage for developers willing to give JavaFX a try, as starting with Swing today doesn't mean rewriting the whole application with JavaFX later. Compound the growing list of plugins available to Griffon applications and you're up for a fun ride when developing desktop applications for the JVM.

In terms of numbers both applications are very close. These are the stats for the Swing version
+----------------------+-------+-------+ | Name | Files | LOC | +----------------------+-------+-------+ | Models | 1 | 9 | | Views | 1 | 22 | | Controllers | 1 | 19 | | Lifecycle | 5 | 3 | | Groovy/Java Sources | 1 | 13 | | Unit Tests | 1 | 13 | | Configuration | 2 | 38 | +----------------------+-------+-------+ | Totals | 12 | 117 | +----------------------+-------+-------+
Whereas the JavaFX version sports these numbers
+----------------------+-------+-------+ | Name | Files | LOC | +----------------------+-------+-------+ | Models | 1 | 5 | | Views | 1 | 25 | | Controllers | 1 | 19 | | Lifecycle | 5 | 0 | | Groovy/Java Sources | 1 | 13 | | Unit Tests | 1 | 13 | | Configuration | 2 | 38 | +----------------------+-------+-------+ | Totals | 12 | 113 | +----------------------+-------+-------+
Not bad, huh? Full source code for both applications can be obtained from this link.

Denver Salesforce.com Developer Meetup TONIGHT!

James Ward — Mon, 02 Jul 2012 13:00:35 CDT

Hey Denver Salesforce.com and Heroku developers! Tonight we are doing a developer meetup at Wynkoop. Come on down for free food, drinks, and networking from 6 – 8. RSVP and hopefully I’ll see you tonight!

Choices [Flickr]

Aaron Gustafson — Sat, 30 Jun 2012 16:02:24 CDT

Aaron Gustafson posted a photo:

Play vs. Grails Smackdown at ?berConf

Matt Raible — Sat, 30 Jun 2012 13:00:29 CDT

Play and Grails have been hyped as the most productive JVM Web Frameworks for the last couple of years. That hype has recently grown thanks to both frameworks' 2.0 releases. That's why James Ward and I decided to do a presentation at ÜberConf comparing the two. In April, we proposed the talk to Jay Zimmerman, got accepted and went to work.

How we did it
In the beginning of May, we met at a brewery in LoDo and sketched out the app we wanted to build. We also came up with a schedule for development and a plan for the presentation. We decided to build two different webapps, each with little-to-no Ajax functionality and a few features that we could use to load test and compare the applications.

We started out with the name “Happy Trails” since we both liked trails and happy hours. Later, James found that www.ubertracks.com was available and purchased the domain. We setup the Grails app to be on bike.ubertracks.com and Play/Java to be on hike.ubertracks.com. We managed our source code on GitHub, continuously tested on CloudBees and deployed to Heroku. Two weeks ago, when we were finishing up our apps, we hired a friend (Linsay Shirley) to do QA.

After fixing bugs, I emailed Patrick Lightbody, got some “cloud dollars” for Neustar Web Performance and started running load tests. The Wednesday before last, at 2 in the morning, I recorded a simple browsing regions and routes script and set it to go to 50 users over a 5 minute period and then sustain 50 for another 5 minutes. It was fun to watch the log messages whiz through my console so fast they got blurry. About halfway through testing the Grails app, there was an OOM issue, but it eventually recovered. Limiting db connections to 4 and scaling to 5 Dynos in future tests helped alleviate any issues.

We took our development experience, the load/performance testing data, and a bunch of ecosystem stats and built our smackdown presentation. We used reveal.js, GitHub Files and Google Charts to make things more dynamic.

What we found
We arrived at a number of conclusions after doing our research:

Code

From a code perspective, Play 2 and Grails 2 are very similar frameworks.
Code authoring was good in both, but lacking IDE support for Play 2's Scala Templates.
Grails Plugin Ecosystem is excellent.
TDD-Style Development is easy with both.
Type-safety in Play 2 was really useful, especially routes.

Statistical Analysis

Grails has better support for FEO (YSlow, PageSpeed)
Grails has less LOC! (6 lines less, but 40% more files)
1 Dyno - Grails had 2x transactions!
- Grails experienced OOM about halfway through.
Apache Benchmark with 10K requests:
- Play: ~10% failed requests, Grails: 0
- Requests per second: {Play: 170, Grails: 198}
- Requests per second: {Play: 251, Grails: 198}
Load Test with 100 Real Users:
- Grails: 10% more transactions, 0 errors

Ecosystem Analysis

"Play" is difficult to search for.
Grails is more mature.
Play has momentum issues.
LinkedIn: more people know Grails than Spring MVC.
Play has 3x user mailing list traffic.
We had similar experiences with documentation and questions.
Outdated documentation is a problem for both.
Play has way more hype!

We figured we spent around 100 hours developing the apps, gathering data and creating the presentation. The good news is it's all open source! This means you can clone the project on GitHub (Grails is in the grails2 branch, Play is in the play2_java branch) and help us improve it. The presentation is in the master branch in the preso directory.

All the data we gathered is open for debate and we’d love to tune our apps to handle more requests per second. In fact, we already had a contributor discover an issue and provide a fix for Play that increases its throughput from 170 req/second to 252 req/second!

Regardless of what the stats and pretty graphs say, we both enjoyed our experiences with Play 2 and Grails 2. If you haven't tried them yourself, we encourage you to do so.

Upgrading to Play 2: Anorm and Testing

Matt Raible — Sat, 30 Jun 2012 11:00:29 CDT

This time last year, I decided I wanted to learn Scala. I chose the Play Framework as my vehicle for learning and I added CoffeeScript and Jade to the mix. I packaged it all up, learned a bunch and presented it at Devoxx 2011.

In January, I added SecureSocial, JSON Services and worked a bit on the mobile client. I presented my findings at Jfokus shortly after. As part of my aforementioned post, I wrote:

Right before we left for Jfokus, I was able to get everything to work, but didn't spend as much time as I'd like working on the mobile client. If this talk gets accepted for Devoxx France, I plan on spending most of my time enhancing the mobile client.

I had some complications (a.k.a. too much vacation) with Devoxx France and wasn't able to attend. To make up for it, I submitted the talk to ÜberConf. It got accepted and I started working on my app a couple weeks ago. So far, I've spent about 8 hours upgrading it to Play 2 and I hope to start re-writing the mobile client later this week. I plan on using Cordova, jQTouch and releasing it in the App Store sometime this month.

Upgrading to Play 2
When I heard about Play 2, I thought it was a great thing. The developers were re-writing the framework to use Scala at the core and I was already using Scala in my app. Then I learned they were going to throw backwards compatibility out the window and I groaned. "Really? Another web framework (like Tapestry of old) screwing its users and making them learn everything again?!", I thought. "Maybe they should call it Run instead of Play, leaving the old framework that everyone loves intact."

However, after hearing about it at Devoxx and Jfokus, I figured I should at least try to migrate. I downloaded Play 2.0.1, created a new project and went to work.

The first thing I learned about upgrading from Play 1.x to Play 2.x is there's no such thing. It's like saying you upgraded from Struts 1 to Struts 2 or Tapestry 4 to Tapestry 5. It's a migration, with a whole new project.

Evolutions
I started by looking around to see if anyone had documented a similar migration. I found two very useful resources right off the bat:

From Jan's Blog, I learned to copy my evolutions from my Play 1.x project into conf/evolutions/default. I changed my application.conf to use PostgreSQL and wrote an EvolutionsTest.scala to verify creating the tables worked.

import org.specs2.mutable._

import play.api.db.DB
import play.api.Play.current

import anorm._

import play.api.test._
import play.api.test.Helpers._

class EvolutionsTest extends Specification {

  "Evolutions" should {
    "be applied without errors" in {
      evolutionFor("default")
      running(FakeApplication()) {
        DB.withConnection {
          implicit connection =>
            SQL("select count(1) from athlete").execute()
            SQL("select count(1) from workout").execute()
            SQL("select count(1) from comment").execute()
        }
      }
      success
    }
  }
}

Then I began looking for how to load seed data with Play 2.x. In Play 1.x, you could use a BootStrap job that would load sample data with YAML.

import play.jobs._
import play.Play

@OnApplicationStart
class BootStrap extends Job {

  override def doJob() {

    import models._
    import play.test._

    // Import initial data if the database is empty
    if (Athlete.count().single() == 0) {
      Yaml[List[Any]]("initial-data.yml").foreach {
        _ match {
          case a: Athlete => Athlete.create(a)
          case w: Workout => Workout.create(w)
          case c: Comment => Comment.create(c)
        }
      }
    }
  }
}

This is no longer a recommended practice in Play 2. Instead, they recommend you turn your YAML into code. 10 minutes later, I had a Global.scala that loaded seed data.

import models._
import play.api._
import play.api.Play.current

import anorm._

object Global extends GlobalSettings {

  override def onStart(app: Application) {
    InitialData.insert()
  }
}

/**
 * Initial set of data to be loaded
 */
object InitialData {

  def date(str: String) = new java.text.SimpleDateFormat("yyyy-MM-dd").parse(str)

  def insert() {

    if (Athlete.count() == 0) {

      Seq(
        Athlete(Id(1), "mraible@gmail.com", "beer", "Matt", "Raible"),
        Athlete(Id(2), "trishmcginity@gmail.com", "whiskey", "Trish", "McGinity")
      ).foreach(Athlete.create)

      Seq(
        Workout(Id(1), "Chainsaw Trail",
          """
            A beautiful fall ride: cool breezes, awesome views and yellow leaves.

            Would do it again in a heartbeat.
          """, 7, 90, date("2011-10-13"), 1),
        Workout(Id(2), "Monarch Lake Trail",
          "Awesome morning ride through falling yellow leaves and cool fall breezes.",
          4, 90, date("2011-10-15"), 1),
        Workout(Id(3), "Creekside to Flume to Chainsaw",
          "Awesome morning ride through falling yellow leaves and cool fall breezes.",
          12, 150, date("2011-10-16"), 2)
      ).foreach(Workout.create)

      Seq(
        Comment(1, "Jim", "Nice day for it!"),
        Comment(2, "Joe", "Love that trail."),
        Comment(2, "Jack", "Where there any kittens there?")
      ).foreach(Comment.create)
    }
  }
}

Anorm's Missing Magic
Before starting with Play 2, I knew it had lost some of its magic. After all, the developers had mentioned they wanted to get ride of the magic and moving to Scala allowed them to do that. However, I didn't think I'd miss Magic[T] as much as I do. Like Martin Fowler, I like ORMs and having to use SQL again seems painful. It seems like a strange shift for Play to reduce type-safety on the backend, but increase it in its templates. Oh well, to each their own. I may eventually move to Squery, but I wanted to do a side-by-side comparison as part of my migration.

Using the aforementioned tutorial from James and Jan's blog posts, as well as Guillaume's Play 2.0/Anorm, I set about creating new model objects. I wrote a bunch of SQL, typed up some new finders and migrated my tests from ScalaTest to the new default, specs2. The Mosh Pit's Migrating a Play 1.2 website to Play 2.0 was a great help in migrating tests.

That's when I started having issues with Anorm and figuring out how its parser syntax works. After struggling for a few days, I finally found yabe-play20-scala. Since I'd used the yabe tutorial from Play 1.x, it was familiar and helped me get past my problems. Now, things aren't perfect (Workouts aren't ordered by their posted date), but everything compiles and tests pass.

To illustrate how little code was required for Anorm 1.x, checkout Workout.scala in Play 1.x vs. Play 2.x. The Play 1.x version is 66 lines; Play 2.x requires 193 lines. I don't know about you, but I kinda like a little magic in my frameworks to reduce the amount of code I have to maintain.

I was pleasantly surprised by specs2. First of all, it was an easy migration from ScalaTest. Secondly, Play's FakeApplication made it very easy to write unit tests. The line count on my UnitTests.scala in Play 1.x vs. Play 2.x is almost identical.

Summary
The first few hours of developing with Play 2 were frustrating, mostly because I felt like I had to learn everything over again. However, I was pleased to find good references on migrating from Play 1.x. Last night, I migrated all my Controllers, integrated Scalate and got most of my views rendering. I still have issues rendering validation errors, but I hope to figure that out soon. The last 2 hours have been much more fun and I feel like my Scala skills are coming along. I think if the Play Team could eliminate those first few hours of struggling (and provide almost instant joy like Play 1.x) they'd really be onto something.

As soon as I figure out how to validation and how to add a body class based on the URL, I'll write another post on the rest of my migration. A Play 2-compatible version of SecureSocial just came out this evening, so I may integrate that as well. In the meantime, I'll be working on the iPhone app and finishing up a Grails 2 application for James Ward and my Grails vs. Play Smackdown.

How Web APIs Unlock Value in the Cloud

Max Katz — Sat, 30 Jun 2012 08:00:36 CDT

How Web APIs Unlock Value in the Cloud by David Schoenbach, Vice President of product management at Exadel.

Secure JSON Services with Play Scala and SecureSocial

Matt Raible — Fri, 29 Jun 2012 16:00:52 CDT

Last November, I traveled to Antwerp to speak at Devoxx. After my talk on HTML5 with Play Scala, Mattias Karlsson approached me and we had a chat about doing the same talk at Jfokus in Stockholm. I agreed and we began talking details after Trish and I returned to the US.

I wrote this article on a plane between Denver and Seattle and will be hopping over the North Pole to Stockholm via Iceland tonight. For the past couple of weeks, I've been updating my Play More! HTML5/mobile app to add some new features. Most notably, I wanted to upgrade to Play 2.0, create JSON services and add authentication.

Upgrading to Play 2.0
My attempt to upgrade to Play 2.0 involved checking out the source from GitHub, building and installing the RC1 snapshot. As I tried to upgrade my app and started getting failed imports, I turned to the internet (specifically StackOverflow) to see if it was a good idea. The first answer for that question suggested I stay with 1.x.

If it's a critical project, to be finished before next March 2012, I would go with Play 1.x. If it's a less important project, which could be delayed, and that in any case won't be released before March 2012, try Play 2.0.

While I didn't plan on releasing Play More! before Jfokus, I decided upgrading didn't add a whole lot to the talk. Also, I couldn't find a Play Scala 0.9.1 to Play 2.0 upgrade guide and I didn't have enough time to create one. So I decided to stick with Play 1.2.4 and add some JSON services for my iPhone client.

JSON Servers
I found Manuel Bernhardt's Play! Scala and JSON. This led me to Jerkson, built by the now infamous @coda. I was able to easily get things working fairly quickly and wrote the following WorkoutService.scala:

package controllers.api

import play.mvc.Controller
import models._
import com.codahale.jerkson.Json._

object WorkoutService extends Controller {

  def workouts = {
    response.setContentTypeIfNotSet("application/json")
    generate(Workout.find().list())
  }
  def edit(id: Long) = {
    generate(Workout.byIdWithAthleteAndComments(id))
  }

  def create() = {
    var workout = params.get("workout", classOf[Workout])
    Workout.create(workout)
  }

  def save(id: Option[Long]) = {
    var workout = params.get("workout", classOf[Workout])
    Workout.update(workout)
  }

  def delete(id: Long) = {
    Workout.delete("id={id}").on("id" -> id).executeUpdate()
  }
}

Next, I added routes for my new API to conf/routes:

GET     /api/workouts               api.WorkoutService.workouts
GET     /api/workout/{id}           api.WorkoutService.edit
POST    /api/workout                api.WorkoutService.create
PUT     /api/workout/{id}           api.WorkoutService.save
DELETE  /api/workout/{id}           api.WorkoutService.delete

Then I created an ApiTest.scala class that verifies the first method works as expected.

import play.test.FunctionalTest
import play.test.FunctionalTest._
import org.junit._

class ApiTests extends FunctionalTest {
  
    @Test
    def testGetWorkouts() {
        var response = GET("/api/workouts");
        assertStatus(200, response);
        assertContentType("application/json", response)
        println(response.out)
    }
}

I ran "play test", opened my browser to http://localhost:9000/@tests and clicked ApiTests -> Start to verify it worked. All the green made me happy.

Finally, I wrote some CoffeeScript and jQuery to allow users to delete workouts and make sure delete functionality worked.

$('#delete').click ->
  $.ajax
    type: 'POST'
    url: $(this).attr('rel')
    error: ->
      alert('Delete failed, please try again.')
    success: (data) ->
      location.href = "/more"

I was very impressed with how easy Play made it to create JSON services and I smiled as my CoffeeScript skills got a refresher.

The Friday before we left for Devoxx, I saw the module registration request for SecureSocial.

SecureSocial with Play Scala
From SecureSocial's README:

SecureSocial allows you to add an authentication UI to your app that works with services based on OAuth1, OAuth2, OpenID and OpenID+OAuth hybrid protocols.

It also provides a Username and Password mechanism for users that do not wish to use existing accounts in other networks.

The following services are supported in this release:

Twitter (OAuth1)
Facebook (OAuth2)
Google (OpenID + OAuth Hybrid)
Yahoo (OpenID + OAuth Hybrid)
LinkedIn (OAuth1)
Foursquare (OAuth2)
MyOpenID (OpenID)
Wordpress (OpenID)
Username and Password

In other words, it sounded like a dream come true and I resolved to try it once I found the time. That time found me last Monday evening and I sent a direct message to @jaliss (the module's author) via Twitter.

Does Secure Social work with Play Scala? I'd like to use it in my Play More! project.

Jorge responded 16 minutes later saying that he hadn't used Play Scala and he'd need to do some research. At 8 o'clock that night (1.5 hours after my original DM), Jorge had a sample working and emailed it to me. 10 minutes later I was adding a Secure trait to my project.

package controllers

import play.mvc._
import controllers.securesocial.SecureSocial

/*
 * @author Jorge Aliss <jaliss@gmail.com> of Secure Social fame.
 */
trait Secure {
  self: Controller =>

  @Before def checkAccess() {
    SecureSocial.DeadboltHelper.beforeRoleCheck()
  }

  def currentUser = {
    SecureSocial.getCurrentUser
  }
}

I configured Twitter and Username + Password as my providers by adding the following to conf/application.conf.

securesocial.providers=twitter,userpass

I also had to configure a number of securesocial.twitter.* properties. Next, I made sure my routes were aware of SecureSocial by adding the following to the top of conf/routes:

  *       /auth               module:securesocial

Then I specified it as a dependency in conf/dependencies.yml and ran "play deps".

    - play -> securesocial 0.2.4

After adding "with Secure" to my Profile.scala controller, I tried to access its route and was prompted to login. Right off the bat, I was shown an error about a missing jQuery 1.5.2 file in my "javascripts" folder, so I added it and rejoiced when I was presented with a login screen. I had to add the app on Twitter to use its OAuth servers, but I was pumped when both username/password authentication worked (complete with signup!) as well as Twitter.

The only issue I ran into with SecureSocial was that it didn't find the default implementation of SecureSocial's UserService.Service when running in prod mode. I was able to workaround this by adding a SecureService.scala implementation to my project and coding it to talk to my Athlete model. I didn't bother to hook in creating a new user when they logged in from Twitter, but that's something I'll want to do in the future. I was also pleased to find out customizing SecureSocial's views was a breeze. I simply copied them from the module into my app's views and voila!

package services

import play.db.anorm.NotAssigned
import play.libs.Codec
import collection.mutable.{SynchronizedMap, HashMap}
import models.Athlete
import securesocial.provider.{ProviderType, UserService, SocialUser, UserId}

class SecureService extends UserService.Service {
  val activations = new HashMap[String, SocialUser] with SynchronizedMap[String, SocialUser]

  def find(userId: UserId): SocialUser = {
    val user = Athlete.find("email={email}").on("email" -> userId.id).first()

    user match {
      case Some(user) => {
        val socialUser = new SocialUser
        socialUser.id = userId
        socialUser.displayName = user.firstName
        socialUser.email = user.email
        socialUser.isEmailVerified = true
        socialUser.password = user.password
        socialUser
      }
      case None => {
        if (!userId.provider.eq(ProviderType.userpass)) {
          var socialUser = new SocialUser
          socialUser.id = userId
          socialUser
        } else {
          null
        }
      }
    }
  }

  def save(user: SocialUser) {
    if (find(user.id) == null) {
      val firstName = user.displayName
      val lastName = user.displayName
      Athlete.create(Athlete(NotAssigned, user.email, user.password, firstName, lastName))
    }
  }

  def createActivation(user: SocialUser): String = {
    val uuid: String = Codec.UUID()
    activations.put(uuid, user)
    uuid
  }

  def activate(uuid: String): Boolean = {
    val user: SocialUser = activations.get(uuid).asInstanceOf[SocialUser]
    var result = false

    if (user != null) {
      user.isEmailVerified = true
      save(user)
      activations.remove(uuid)
      result = true
    }

    result
  }

  def deletePendingActivations() {
    activations.clear()
  }
}

Jorge was a great help in getting my authentication needs met and he even wrote a BasicAuth.scala trait to implement Basic Authentication on my JSON services.

package controllers

import _root_.securesocial.provider.{UserService, ProviderType, UserId}
import play._
import play.mvc._
import play.libs.Crypto

import controllers.securesocial.SecureSocial

/*
 * @author Jorge Aliss <jaliss@gmail.com> of Secure Social fame.
 */
trait BasicAuth {
  self: Controller =>

  @Before def checkAccess = {
    if (currentUser != null) {
      // this allows SecureSocial.getCurrentUser() to work.
      renderArgs.put("user", currentUser)
      Continue
    }

    val realm =
      Play.configuration.getProperty("securesocial.basicAuth.realm", "Unauthorized")

    if (request.user == null || request.password == null) {
      Unauthorized(realm)
    } else {
      val userId = new UserId
      userId.id = request.user
      userId.provider = ProviderType.userpass
      val user = UserService.find(userId)

      if (user == null ||
        !Crypto.passwordHash(request.password).equals(user.password)) {
        Unauthorized(realm)
      } else {
        // this allows SecureSocial.getCurrentUser() to work.
        renderArgs.put("user", user)
        Continue
      }
    }
  }

  def currentUser = {
    SecureSocial.getCurrentUser()
  }
}

Summary
My latest pass at developing with Scala and leveraging Play to build my app was a lot of fun. While there were issues with class reloading every-so-often and Scala versions with Scalate, I was able to add the features I wanted. I wasn't able to upgrade to Play 2.0, but I didn't try that hard and figured it's best to wait until its upgrade guide has been published.

I'm excited to describe my latest experience to the developers at Jfokus this week. In addition, the conference has talks on Play 2.0, CoffeeScript, HTML5, Scala and Scalate. I hope to attend many of these and learn some new tricks to improve my skills and my app.

Update: The Delving developers have written an article on Migration to Play 2. While it doesn't provide specific details on what they needed to change, it does have good information on how long it took and things to watch for.

My HTML5 with Play Scala, CoffeeScript and Jade Presentation from Devoxx 2011

Matt Raible — Fri, 29 Jun 2012 13:01:10 CDT

This week, I had the pleasure of traveling to one of my favorite places in the world: Antwerp, Belgium. Like last year, I traveled with the lovely Trish McGinity and spoke at Devoxx 2011. This year, my talk was on developing a web/mobile app with HTML5, Play, Scala, CoffeeScript and Jade. I was inspired to learn Scala at the beginning of this year and added CoffeeScript and Jade to my learning list after talking to James Strachan at TSSJS 2011. You can read more about how my journey began in my first post about learning these technologies.

I started developing with these technologies in August and wrote about my learnings throughout the process. Last week, while writing my presentation, I decided it'd be fun to make my presentation into more of a story-telling-session than a learn-about-new-technologies session. To do this, I focused on talking a bit about the technologies, but more about my experience learning them. I also came up with a challenging idea: create a video that showed the development process, how hard it was to test the app and (hopefully) my success in getting it to work.

It was all a very close call, but I'm happy to say I pulled it off! I got the app to work on an iPhone (thanks to PhoneGap) last Saturday, finished the first draft of my presentation on Sunday night (after pulling an all-nighter) and finished editing the demo video on Wednesday night. My talk was on Thursday afternoon and I had a blast talking about my experience to such a large, enthusiastic audience. You can see the presentation below, on Slideshare or download the PDF.

You can find the "demo" for this talk on YouTube or watch it below.

One of the reasons I really enjoyed this talk is it only represents one milestone in my learning process. I plan on continuing to develop this application and learning more about HTML5, Scala, Play and CoffeeScript and Scalate/Jade. Now that Play 2.0 Beta has been released, I plan on upgrading to it and leveraging its native CoffeeScript and LESS support. I hope to continue using Scalate and its Jade format. And it's very likely PhoneGap will continue to be the bridge that allows everything to run in the background.

I've been talking with the Jfokus folks about doing this talk in Sweden in Feburary and Devoxx France about presenting there in April.

Learning all these technologies has been a challenging, but fun experience so far. As the last slide in my presentation says, I encourage you to do something similar. Pick something new to learn, have fun doing it, but more importantly - get out there and Play!

Update Dec. 20th: A video of this presentation is now available on Parleys.com.