ÜberConf

Perfection [Flickr]

Aaron Gustafson — Wed, 16 May 2012 16:00:22 CDT

Aaron Gustafson posted a photo:

Windows Phone Export is Coming To Tiggzi App Builder

Max Katz — Wed, 16 May 2012 13:02:30 CDT

Yes, this is pretty cool:

Windows Phone export in Tiggzi will be available tomorrow.

Programs and Technical Debt

Johanna Rothman — Wed, 16 May 2012 11:00:32 CDT

Once you have a program (a collection of interrelated projects focused on one business goal) and you have technical debt, you have a much bigger problem. Not just because the technical debt is likely bigger. Not just because you have more people. But because you also geographically distributed teams, and those teams are almost always separated by function and time zone.

So, my nice example of a collocated team in Thoughts on Infrastructure, Technical Debt, and Automated Test Framework, rarely occurs in a program, unless you have cross-functional teams collocated in a program. If they do, great. You know what to do.

But let’s assume you don’t have them. Let’s assume you have what I see in my consulting practice: an architecture group in one location, or an architect in one location and architects around the world; developers and “their” testers in multiple time zones; product owners separated from their developers and testers. The program is called agile because the program is working in iterations. And, because it’s a program, the software pre-existed the existence of the agile transition in the organization, so you have legacy technical debt up the wazoo (the technical term). What do you do?

Let’s walk through an example, and see how it might work. Here’s a story which is a composite from several clients; no clients were harmed in the telling of this story.

Let’s also assume you are working on release 5.0 of a custom email client. Release 4 was the previous release. Release 4 had trouble. It was late by 6 months and quite buggy. Someone sold agile as the way to make software bug-free and on-time.

You do not have automated tests for much of the code, unit tests or system tests. You have a list of defects that make Jack the Ripper’s list of killings look like child’s play. But agile is your silver bullet.

The program manager is based in London. The testers for the entire program are in Bangalore because management had previously fired all the testers and outsourced the testers. That was back in release 2. They have since hired all the Bangalore testers as employees of the Bangalore subsidiary. The program architect is based in San Francisco, and there is an architect team that is dispersed into 4 other teams: Denver, LA, Munich, and Paris. The developers are clustered in “Development Centers of Excellence:” Denver, LA, Cambridge, Paris, London, Munich, and Milan. That’s 8 development teams.

Oh, and if you think I’m kidding with this scenario, I’m not. This is what most of my clients with geographically distributed teams and programs face on a daily basis. They deserve your sympathy and empathy. Do not tell them, “Don’t go agile.” That’s nuts. They have a right to go agile. You can tell them, “Don’t go Scrum.” That’s reasonable. Scrum is for a cross-functional co-located team. Agile is for everyone. Scrum is for a specific subset.

What do you do?

Assign specific testers to specific development teams. No calling people resources; that allows managers to treat people like resources and plug-and-play them. You need to get rock-solid teams together. Once you have teams together, you can name them.
Name teams so the teams reflect the feature groups they work on. What does an email product do? It gets email, it sorts email, it deletes, it forwards, it creates new mailboxes, and so on. The eight feature teams had to be named for the feature areas: Platform for the general features, Sort, Delete, Forward. There were two teams who worked on Platform. They were called Platform 1 and Platform 2. At one point, someone suggested they call themselves Thing1 and Thing2 from the Dr. Seuss book.
Make sure you have enough product owners so they can develop roadmaps for each feature area. With a roadmap, the teams know where they are going. Even more importantly, the architects know where the program is going.
Architects think and provide just enough guidance ahead. In a small project, the architecture can probably evolve with the project. In a larger program, that risk is too large. You have too many people developing in parallel for the architecture to evolve on its own with no guidance. But I do not mean there should a Master Architect Who Knows All Handing Down the Architecture From On High. NO NO NO.
I want the architect who is a working member of the development team, who also is part of an architecture community of practice team, who curates the architecture, who guides the business value of the architecture. I do not want Big Architecture Up Front. But Thinking Up Front? Sure, that’s a great idea. Stuck on only one idea? Bad. Willing to spike an idea? Great. Willing to play in a sandbox and debate several ideas? Great. I wrote about this before, in How Agile Architects Lead.
Decide what done means for every feature. You must have acceptance criteria for each feature. What does that mean? You need a product owner present for each team. You still need the conversations with each team to discuss what done means. Especially with a geographically distributed team, you need the conversation when you create the backlog at the beginning of the iteration.
The US development teams had trouble planning their iterations with their testers, because of the time zone differences with the testers. So, they asked their product owners if the product owner would write more than just a few phrases on the cards, because that would help them get through the iteration planning meeting faster. Someone was going to get up early or stay up late, and either way, someone was going to suffer. It made more sense to have a little bit more preparation than less sleep.
Decide to do continuous integration and stick with it. Especially if you know you have technical debt and you don’t want to create more, you have to do continuous integration now. That prevents more technical debt.
I have recommended to some teams that they have one-week iterations so that they stop the estimation nonsense and make their stories small. The point of estimation is so that you have an idea of what you can do as a team and not commit to more than that. The idea is that if you know what it takes to make your stories small, you will.
Instead, we have all these crazy rituals around estimation and management tracking velocity of all things. (Yes, I’ve been drafting this post for a long time, and I wrote Why Does Management Care About Velocity? last week.) You know, velocity is a little like weight. Only you and your doctor need to know your weight. If you are healthy, you are fine. If you are not, you need to change something.If your team velocity is not healthy, you, as a team, need to change it. But, your management has no business butting its head in. Only you can change it.
When you limit the iteration length, you tend to have the team swarm around a story. This is a tendency, not a given. If I really was the Empress of the Universe, I would decree this, but I’m not, so I won’t. If you want to decrease technical debt, or even eliminate it on your program, explain that your team will only work on one story at a time until that story is done. That story will be polished and gleaming. Fast. You will not have to worry about what kinds of testing will be done. All if it will be done.
Explicitly discuss what you will automate for testing and when. In a program, I assume we will have automated system tests first. I assume we will do exploratory tests later. That’s because if you don’t start building something for test automation when you start the program and refactor as you proceed, you can never catch up. I assume every time we fix a defect, we will have an automated test for it. I also assume we build these assumptions into how we develop :-)

So far, this is all about preventing more technical debt, not what happens when you trip over technical debt as you enter code or tests you never looked at before.

If you expected to walk into a closet, take out a shirt, and close the closet door, that’s one thing. But now, you stepped into something out of one of those death-by-hoarding shows on TV, you have an obligation to do something. You can document the problem as you encounter it; you can let the product owner know; file a defect report; write a test so you can contain the debt; and maybe you have more options. Whatever you do, make sure you have done something. Do not open the door, see the mess inside and close the door on the mess. It’s tempting. Oh my, it is tempting.

See, on programs because of the size, everything is magnified. With more people and more teams, everything is harder. Things happen faster. If you have co-located cross-functional teams, no problem. But if you don’t have co-located cross-functional teams, you have to work with what you have. And, if you already have a big legacy product, you want to address technical debt in small chunks, refactoring in small bits, integrating as you proceed.

My philosophy is this: the bigger the program, the more you need to become accustomed to working in small chunks, integrating as you go. Fully implement a small story, integrate it on the mainline. Everyone on the program does that. If you need help from an integration team, so be it.

But, if everyone only implements small stories, and everyone takes care of their own technical debt as they discover it, you don’t need an army of integration people. You only need an army of integration people when you have technical debt around integration and release. Fix that, and everyone can become responsible for their own integration.

And, if you can’t release, that’s where the architects should start. If you can’t do continuous integration, that’s where the architects should start. Because that’s what’s preventing you from making progress on the product. Work backwards from release, and then the architects can work on the rest of the product. Until you can release and build reliably, the rest of the product doesn’t matter.

Tiggzi At AnDevCon Conference: Building Android Apps With Cloud-based Mobile App Builder

Max Katz — Wed, 16 May 2012 08:00:25 CDT

Wednesday and Thursday this week the Tiggzi team will be at AnDevCon conference in San Francisco. Stop by our stand and learn how to build Android apps, connected to any REST API using Tiggzi app builder. What’s really nice is that you can build an app in Tiggzi, export the Android binary, and instantly publish it to Google Play Store.

This Week in Grails (2012-19)

Burt Beckwith — Tue, 15 May 2012 16:00:38 CDT

We’re getting ready to release Grails 2.1, with a release candidate hopefully this week. The cache plugins I mentioned last week will be released around the same time, and the ‘core’ cache plugin will be a default plugin in BuildConfig.groovy. I released an update of the database-migration plugin to address some bugs that were keeping that from being a default plugin, so that will also be included by default in BuildConfig.groovy.

I’ve been working on a Grails book to be published this fall. The plan is that it will be an advanced book, and presume that you already have experience with Grails or another similar framework in Java or another language and are looking for more detail and best practices. It’s going to be available soon in an early-access digital format so you can follow the progress and help the book by finding mistakes and making suggestions.

A few more GR8Conf EU interviews:

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 6 new plugins released:

closure-templates-resources version 0.1. Supports server-side compilation of .soy template files to JavaScript files
jquery-mobile-metro version 0.1. Plugin jQuery mobile framework Metro UI theme resource files
jrimum-bopepo version 0.2. Allows you to create Boletos Bancarios for Banks of Brazil using the Jrimum Bopepo library
plastic-criteria version 0.1. Mock Grails Criteria for Unit Tests
split-test version 0.4. An A/B testing framework designed to work with Grails
spring-security-oauth version 2.0.1.0. Adds OAuth-based authentication to the Spring Security plugin using the OAuth plugin

and 14 updated plugins:

asynchronous-mail version 0.6. Send email asynchronously by storing them in the database and sending with a Quartz job
cache version 1.0.0.M2. Adds request, service method, and taglib caching
cache-ehcache version 1.0.0.M2. An Ehcache-based implementation of the Cache plugin
cache-redis version 1.0.0.M2. A Redis-based implementation of the Cache plugin
database-migration version 1.1. Official Grails plugin for database migrations
external-config-reload version 1.2.0. Polls for changes to external configuration files (files added to grails.config.locations), reloads the configuration when a change has occurred, and notifies specified plugins by firing the onConfigChange event in each
faker version 0.5. A port of Data::Faker from Perl, is used to easily generate fake data: names, addresses, phone numbers, etc.
hibernate-search version 0.6.1. Integrates Hibernate Search for domain classes
lesscss-resources version 1.3.0.3. Optimises the use of http://www.lesscss.org css files, compiling .less files into their .css counterprt, and place the css into the processing chain to be available to the other resource plugin features
pusher version 0.4. Wrapper for pusher.com REST api
spring-batch version 0.2.2. Provides the Spring Batch framework and convention based Jobs
spring-security-facebook version 0.7.4. Plugin for Facebook Authentication, as extension to Grails Spring Security Core plugin
spring-security-twitter version 0.4.3. Twitter authentication as extension to the Spring Security Core plugin
zkui version 0.5.1. Seamlessly integrates ZK with Grails’ infrastructures; uses the Grails’ infrastructures such as GSP, controllers rather than zk’s zul as in ZKGrails plugin

Interesting Tweets

@CedricChampeau: #Groovy 2.0.0-beta-3 with #CompileStatic and #InvokeDynamic support is out! We need your feedback! http://t.co/0zmf3gSm
@cavneb: I just launched a new site dedicated to sharing #Groovy and #Grails articles along with free job listings. http://t.co/ddLtQCL4 check it out
@pledbrook: Quick hack to get #vertx running in a #grails application: https://t.co/TXiaENd5 – modify 2 files in a new Grails project and add some jars
@rfletcherEW: Cool, my @twbootstrap for #Grails templates made this list of Bootstrap resources: http://t.co/N8Z920qn /via @designshack
@marcoVermeulen: Having fun with the #vertx tutorial for #groovy. Web development can’t get easier than this. http://t.co/wnScgY1U

Jobs

Grails or Java/Hibernate/Spring developers in Cambridge for a large scale financial web site
Grails developers for new project in Israel
Java Engineer (Groovy/Grails) at Citi in Irving, TX
@fxthoorens: Recherche un développeur #grails sur #paris pour un projet medical innovant asap. ping me. cc @smaldini @glaforge @burtbeckwith please RT
@aemamz: Developers required (PHP,J2EE, Groovy, Grails, Android), GDs. Social Media/Business consultants to be part of a start up partnership,
@georgemcintosh: Any Grails devs out there with f/e skills looking for a contract in East London? #grails #grailsjobs #grailscontracts
@im_robsmith: Looking for a Grails developer!! Strong Java and Front-end required. Someone with a passion for Open Source would be ideal. Working for a …
Java / Grails Developer, Hamburg
Groovy Developer(s) needed in Nashville, TN
Java Senior Web Developer, Legnano
Data analytics, Grails, Javascript, Mapquestapi, Mongodb at Elance.com in Washington, DC
Grails Developer, Bengaluru/Bangalore
Grails Developer in Tampa, FL (remote)
Full-time Grails developer at the University of Utah
Contract position for a Grails Developer at Specto Design in Los Angeles
Grails Developer in Costa Rica
Groovy/Grails Developer needed ASAP for a short term engagement (100% remote)
Urgently needed: Groovy/Grails consultant for a two year opportunity in CA
Server Lead at SonicNotify in NYC

User groups and Conferences

GR8Conf Europe 2012
- June 6^th-8^th Copenhagen, Denmark
GR8Conf US 2012
- July 29^th-31^st Minneapolis, MN
SpringOne 2GX 2012
- October 15^th-18^th Washington, DC

Grails in the Cloud! – May 8, 2012
- nlgug – Groovy and Grails User Group Netherlands
Building Grails applications with MongoDB and Using MongoDB with Groovy in an enterprise application – Wednesday, May 16, 2012
- London Groovy & Grails User Group
Lightning Talks II – Thursday, May 17, 2012
- Boston Grails Users’ Group
May 28, 2012
- SF Bay Groovy and Grails Meetup Group

WTFWG

Tim Kadlec — Tue, 15 May 2012 13:00:23 CDT

This morning, Ian Hickson emailed the WHATWG mailing list mentioning that a attribute that was currently being discussed on the list (srcset) is now added to the draft of the spec. To understand why this sucks, a little background is needed.

Responsive images are a difficult beast to tame: there really isn’t a good solution for them today. As a result, some discussion started on the WHATWG mailing list months ago about what to do. The WHATWG pointed out that the list was for standardizing and suggested it would be better if the discussion were moved into a community group.

So, obediently, a community group chaired by Mat Marquis was started (in February). A lot of discussion took place about the appropriate way to handle responsive images and one solution, the new picture element, garnered the majority of support.

On May 10th, the previously mentioned srcset attribute was presented on the WHATWG mailing list by someone from Apple.

That same day it was recommended to the list that they take a look at all the discussion that had taken place in the community group. A debate about the two solutions ensued.

The feedback from developers was not particularly glowing. To quote Matt Wilcox:

I do not see much potential for srcset. The result of asking the author community was overwhelmingly negative, indirection or no indirection.

It was argued by Simon Pieters of Opera that the srcset attribute would be easier to implement and that as a result, that would help developers:

I think an attribute is simpler to implement and thus likely to result in fewer bugs in browsers, which in turn benefits Web developers.

This morning, the attribute was added to the spec.

I’ve got my own opinion about the correct solution, but that’s not really what’s I think is most troubling here. Note what happened:

Developers got involved in trying to standardize a solution to a common and important problem.
The WHATWG told them to move the discussion to a community group.
The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.
Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.
A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.
While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

What. The. Hell.

The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements.

Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec. (In case there’s any doubt, I’m not blaming him in anyway for the result of all of this.)

In the draft of the W3C HTML design principles, they clearly state the priority that should be given when determining standards:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

Those levels of priority make a lot of sense to me and it’s discouraging (to say the least!) to see them dismissed in this case. This kind of thing simply cannot happen. It’s tough to get people to voice their opinions to begin with: to find that their opinion holds no weight won’t make it any easier going forward.

What message does it send when developers try to contribute their time, energy and effort to help solve a problem only to have it so casually dismissed?

As Scott Jehl responded on Twitter:

insulting. Not to mention, that it can’t work today. What was the purpose of our @w3c community group?

Insulting indeed. Not too surprising though. After all, we’ve seen this sort of thing before.

Graphs in the Cloud: Spring + Neo4j on Heroku

James Ward — Tue, 15 May 2012 11:00:37 CDT

Last week I hosted a webinar about running Java apps on Heroku that use the Spring Framework and the Neo4j graph database. Here is the recording of that webinar:

In the webinar I began by deploying a copy of the Spring MVC + Hibernate template app from heroku.com/java on Heroku. Then I made a few modifications to the app to switch the persistence from Hibernate / JPA to Neo4j. You can get the full source code on GitHub.

Here is a quick recap of what I did to switch the template app to use Neo4j:

Added the Neo4j Heroku Add-on:
```
heroku addons:add neo4j
```

Added the Spring Data Neo4j dependencies (optionally you can remove the unused JPA dependencies) to the “pom.xml” Maven build descriptor:

<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-neo4j-rest</artifactId>
    <version>2.0.1.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>4.2.0.Final</version>
</dependency>

Modified the “src/main/java/com/example/service/PersonService.java” interface to use the Neo4j GraphRepository:

package com.example.service;
 
import com.example.model.Person;
import org.springframework.data.neo4j.repository.GraphRepository;
 
public interface PersonService extends GraphRepository<Person> {
 
 
}

Removed the unneeded “src/main/java/com/example/service/PersonServiceImpl.java” DAO.

Modified the “src/main/java/com/example/model/Person.java” POJO to be a @NodeEntity (instead of JPA Entity) and switched the “id” primary key property to be a Long annotated as a @GraphId:

package com.example.model;
 
import org.springframework.data.neo4j.annotation.GraphId;
import org.springframework.data.neo4j.annotation.NodeEntity;
 
@NodeEntity
public class Person {
 
    @GraphId
    private Long id;
 
    // the rest is omitted

Modified the “src/main/java/com/example/controller/PersonController.java” Spring MVC controller to use the new “PersonService”, take a Long parameter in the “deletePerson” method, and make the “deletePerson” and “addPerson” methods transactional:

package com.example.controller;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.web.bind.annotation.ModelAttribute;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
 
import com.example.model.Person;
import com.example.service.PersonService;
 
import java.util.Map;
 
@Controller
public class PersonController {
 
    @Autowired
    private PersonService personService;
 
    @RequestMapping("/")
    public String listPeople(Map<String, Object> map) {
        map.put("person", new Person());
        map.put("peopleList", personService.findAll().iterator());
        return "people";
    }
 
    @RequestMapping(value = "/add", method = RequestMethod.POST)
    @Transactional
    public String addPerson(@ModelAttribute("person") Person person) {
        personService.save(person);
        return "redirect:/people/";
    }
 
    @RequestMapping("/delete/{personId}")
    @Transactional
    public String deletePerson(@PathVariable("personId") Long personId) {
        personService.delete(personId);
        return "redirect:/people/";
    }
}

Then I modified the “src/main/resources/applicationContext.xml” Spring config file to use a file for local Neo4j storage in the “default” profile and then in the “prod” profile the “NEO4J_REST_URL”, “NEO4J_LOGIN”, and “NEO4J_PASSWORD” environment variables are used to connect to the Neo4j Heroku add-on service:

<?xml  version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:mvc="http://www.springframework.org/schema/mvc"
       xmlns:neo4j="http://www.springframework.org/schema/data/neo4j"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd
                           http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd
                           http://www.springframework.org/schema/data/neo4j http://www.springframework.org/schema/data/neo4j/spring-neo4j-2.0.xsd">
 
    <context:annotation-config />
    <context:spring-configured />
    <context:component-scan base-package="com.example" />
 
    <neo4j:repositories base-package="com.example.service"/>
 
    <mvc:annotation-driven/>
 
    <bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
        <property name="prefix" value="/WEB-INF/jsp/" />
        <property name="suffix" value=".jsp" />
    </bean>
 
    <tx:annotation-driven />
 
    <beans profile="default">
        <neo4j:config storeDirectory="target/neo4j-db"/>
    </beans>
 
    <beans profile="prod">
        <bean class="org.springframework.data.neo4j.rest.SpringRestGraphDatabase" id="graphDatabaseService">
            <constructor-arg index="0" value="#{systemEnvironment['NEO4J_REST_URL']}"/>
            <constructor-arg index="1" value="#{systemEnvironment['NEO4J_LOGIN']}"/>
            <constructor-arg index="2" value="#{systemEnvironment['NEO4J_PASSWORD']}"/>
        </bean>
 
        <neo4j:config graphDatabaseService="graphDatabaseService"/>
    </beans>
 
</beans>

After testing my changes locally (which actually didn’t work in my webinar due to a problem with Eclipse) I committed my changes to the git repo and pushed them to Heroku:
```
git push heroku master
```

If you want to just skip to a working example on the cloud, simply follow the instructions in the project README.

Hopefully that helps you get started with Neo4j and Java applications on the cloud!

BTW: If you watched the webinar, you probably noticed that my Maven and Eclipse were misbehaving. Turns out that M2E didn’t read my Maven config and all I had to do was right-click on the project, select Maven, and then Update Project Configuration. That got everything back in sync. My excuse for not being able to figure that out during the demo… I usually use IntelliJ IDEA. :)

Gorgeous view [Flickr]

Aaron Gustafson — Tue, 15 May 2012 08:01:11 CDT

Aaron Gustafson posted a photo:

PhoneGap Starter Project - Productivity

Terry Ryan — Mon, 14 May 2012 16:00:23 CDT

A few weeks back Ryan Stewart posted on his idea for PhoneGap Starter projects. They were designed to take some of the grief out of getting started with various aspects of PhoneGap and PhoneGap Build projects. I've contributed a project based on one of pet peeves with PhoneGap Build, the lack of productivity.

Don't get me wrong. I love PhoneGap Build. I love not having to open multiple IDE's to work on mobile apps. I love working on HTML apps in HTML tools - but you lose a few things in the trade. You lose being able to click one button and have your work available on your device. You miss being able to click and get a pop up that says your work is ready to view on the device.

These things seem small, but having tried to build actual projects in PhoneGap Build, I found them critical. I would go kick off a build, and then have to wait for the build to be complete. I'd open a browser windows while I waited. 20 minutes later, I would cycle through my Chrome windows and remember that I was waiting for a build to complete.

A few months back I tried my hand and solving this and came up with a shell script that handled this for Android. Over the past few weeks, I've added, improved, and modified it. I now have a solution in ANT that does the following:

Uploads files to PhoneGap Build triggering a rebuild
Polls for IOS and Android to be finished
Downloads ipa and apk files when ready
Installs them onto connected iOS and Android devices
Uses the "say" command to let you know when things are done.

It takes the form of an ANT build file, some properties, and 2 shell scripts. I've posted the whole thing as PhoneGap Starter Productivity on github. As far as I know this will only work on OS X, which I hope isn't a huge problem for anyone, and I'm willing to collaborate with someone to make them more cross platform friendly.

Also I feel it's important to note, that while these scripts mean you don't have to use the IDE to accomplish these tasks, you still have to have Xcode and the Android SDK on your machine to use them.

Play 2 Java Tutorial

James Ward — Mon, 14 May 2012 13:00:41 CDT

I’ve created a Play 2 Tutorial and posted it on GitHub! The tutorial covers how to:

Each section has a corresponding branch in git so you can diff against my version to see if you’ve done everything correctly. Right now this is just for Play 2 with Java and Ebean but I’m working on doing this for Play 2 with Scala as well.

You can see a live demo of the final app at:
play2torial.herokuapp.com

It’s a pretty simple app but it should get you started building Play 2 apps and deploying them on the cloud with Heroku. If you want to take the shortcut to the end and get your own copy of the app running on Heroku then just do the following:

Install git and the Heroku Toolbelt.
Signup for an account on Heroku. (Don’t worry, this stuff is free.)

Clone the play2torial git repo:

git clone git://github.com/jamesward/play2torial.git

Login to Heroku:
```
heroku login
```
Create a new app on Heroku (from within the play2torial directory):
```
heroku create --stack cedar
```
Upload the app to Heroku (from within the play2torial directory):
```
git push heroku java-heroku_update:master
```
Check out your app on the cloud:
```
heroku open
```
If you want to run the app locally, install Play 2 and then run:
```
git checkout java-heroku_update
play ~run
```

I hope this helps you learn Play 2! Let me know if you have any questions or comments. Thanks!

Tillandsia [Flickr]

Aaron Gustafson — Mon, 14 May 2012 08:00:31 CDT

Aaron Gustafson posted a photo:

Tiggzi Mobile App Builder Slides And Video from DC jQuery Meetup

Max Katz — Sat, 12 May 2012 08:00:54 CDT

Tiggzi at DC jQuery Meetup

View more presentations from Max Katz

Heroku, Java, Play and Neo4j Presos: Denver JUG, Atlanta JUG, London Flash UG & Webinar

James Ward — Fri, 11 May 2012 11:02:58 CDT

Over the next couple weeks I’ll be doing two Java User Group presentations, a Flash Platform User Group presentation and one Webinar. Hope to see you at one of these events:

Wednesday May 9 – Denver Java User Group:
Running Java, Play! and Scala Apps in the Cloud
Thursday May 10 – Webinar hosted by Neo4j:
Graphs in the Cloud: Neo4j and Heroku
Tuesday May 15 – Atlanta Java User Group:
Running Java, Play! and Scala Apps on the Cloud
Thursday May 24 – London Flash Platform User Group:
HTML5 Apps in Java & Scala with the Play Framework
Deploying Apps on the Cloud with Heroku

Play 2 Java Tutorial

James Ward — Fri, 11 May 2012 08:00:49 CDT

I’ve created a Play 2 Tutorial and posted it on GitHub! The tutorial covers how to:

You can see a live demo of the final app at:
play2torial.herokuapp.com

Install git and the Heroku Toolbelt.
Signup for an account on Heroku. (Don’t worry, this stuff is free.)

Clone the play2torial git repo:

git clone git://github.com/jamesward/play2torial.git

Login to Heroku:
```
heroku login
```
Create a new app on Heroku (from within the play2torial directory):
```
heroku create --stack cedar
```
Upload the app to Heroku (from within the play2torial directory):
```
git push heroku java-heroku_update:master
```
Check out your app on the cloud:
```
heroku open
```
If you want to run the app locally, install Play 2 and then run:
```
git checkout java-heroku_update
play ~run
```

I hope this helps you learn Play 2! Let me know if you have any questions or comments. Thanks!

Tiggzi – the Cloud-based jQuery Mobile App Builder At DC jQuery Users Group, May 10, 2012

Max Katz — Thu, 10 May 2012 16:00:30 CDT

I’ll be speaking at DC jQuery Users Group this Thursday, May 10. I’ll be showing Tiggzi – the cloud-based jQuery Mobile and PhoneGap app builder, and how fast and easy it is to build jQuery Mobile apps connected to any REST API.

Tiggzi At The AT&T Mobile Hackathon In Palo Alto Recap

Max Katz — Thu, 10 May 2012 13:00:22 CDT

This past weekend Oleksandr (Sasha) Piskun, chief mobile architect behind Tiggzi and myself attended the AT&T Mobile Hackathon at the AT&T Foundry in Palo Alto. The hackathon was also sponsored by Facebook. A big thank you to Alex Donn, Ben Nelson and other AT&T team members for putting this awesome event together and including us in it.

If you are not familiar with a hackathon format, it goes like this. The event usually starts Friday evening with what’s called “developer dating” or simply networking. After about an hour, event sponsors and tool providers make a 5-10 minute presentation on their API’s and tools. After that the attendees get a few minutes to pitch their app ideas. Once all the presentations are done, it’s time to form teams and start building the apps. Team forming or app building goes until about midnight. The next day the event restarts at about 10am, accompanied by breakfast and the teams start building and hacking. This goes until about 7pm at which point all development stops and teams get about 3 minutes to present their apps. Once everyone presented, the judges get together and decide on the winners.

This was our fourth hackathon after attending hackathons in San Diego and Seattle (sponsored by AT&T) and one in San Francisco sponsored by Microsoft. The Palo Alto one was the biggest hackathon so far. This is probably because it was in the heart of Silicon Valley and sponsored by Facebook.

We arrived at AT&T Foundry around 6pm on Friday, and the place was already pretty busy. AT&T Foundry is a great place for a hackathon, large area, large tables. The entire place was divided into small sections (but still open) which are perfect for teams working together.

Alex Donn started the event around 7:30pm introducing himself, his team, AT&T and all the partners. He always shows this picture which shows all the various tools that attendees can use during the hackathon:

Picture from Seattle hackathon

Next James Pearce, Head of Mobile Developer Relations at Facebook presented:

James Pearce from Facebook

More companies presented after Facebook. There were presentations from Apigee UserGrid, AT&T mHealth, Mozilla and Viafo. We (Tiggzi) also got a chance to present. We got about 3-4 minutes to show how to build an app in Tiggzi. What’s really amazing is that I built a Twitter search app in under 2 minutes! Yes – that’s how long it takes to build a simple app in Tiggzi. The app is jQuery Mobile on the UI and connects to Twitter’s search REST API.

I did run into a small glitch during the demo. My WiFi connection went down. Yes, even thought the event was happening at AT&T, WiFi connection was rather flaky. Most likely due to number of different devices (laptops, tablets, phones) in the same room, all trying to use the same network. I haven’t had any demo issues for a very long time so I guess it was just time. So, the next one is now far away! For about 1 minute I didn’t have Internet connection and was about to give up but then I got reconnected and was able to finish the app.

Anyone who wanted to use Tiggzi to build their app could get 2 months Pro plan. In fact, any attendee could get the 2 months Pro plan. We also offered prizes to winning teams. 1st place best app built in Tiggzi gets 12 months Pro plan for the entire team. 2nd and 3rd places get 6 months Pro plan for the entire team.

Sasha and I stayed at the hackathon until around midnight talking with people and telling them more about Tiggzi. We got home around 1:30am.

Next morning we met around 9am and drove to Palo Alto getting there just after 10am. A good number of teams were already there and building their apps. We settled down in the main (first) room where people could easily find us.

Sasha explaining how to build apps with

We counted about 10 teams (out of 29) using Tiggzi to build their apps. The rest of the day was very busy for us. I don’t think we had more than 5 minutes of free time, both of us were helping different teams with Tiggzi questions as well as various API questions. It was busy but we had a lot of fun!

To win the best app prize and $20,000 the app had to use Facebook Graph API. We came prepared to the hackathon and created a step-by-step tutorial on how to build an app in Tiggzi that uses Facebook API. Note: turned out you can also use client-only authentication which is a little bit simpler than described in the tutorial.

Hacking

Everything was going well, and a number of teams started testing the app on the actual phones. Tiggzi comes with a really awesome test feature where at any moment you can launch the app in the browser for testing. To give a feeling of a real phone, the app opens inside a frame – where the actual frame looks like a generic smart phone:

When you open the same test URL on a mobile device, we detect the device and don’t render the frame. The transition between frame and the non-frame version is done with a basic redirect. The redirect unfortunately caused a problem when testing the app on the actual mobile device. Facebook would do a callback to a page in Tiggzi app with query parameters that need to be saved. A redirect would happen (when testing the app on a mobile device) but the query parameters would be lost. An obvious solution was to use mobile only pages (for callback and in Facebook app settings). We found another problem, now with jQuery Mobile. The callback URL from Facebook uses # (instead of ?) to separate the start of query parameters and this caused jQuery Mobile fail to load. At the end we did find a workaround, and users were able to test on the actual mobile device. We are working on long term solution as well. For example, we are making the phone frame to be optional.

At 7pm development stopped and all the teams lined up to present their apps. All the teams that used Tiggzi presented the app running in desktop browser, the phone frame is a nice feature and mimics a real device. At the end, the bug wasn’t such a big issue – after all the teams did build the apps.

Once all the presentations were done, we went to a separate room and picked the winners. We also picked best three apps built with Tiggzi. Best Tiggzi app 1st place (12 months Pro plan winners) was won by a team that didn’t have any HTML or jQuery Mobile experience.

The feedback was pretty much universal from all the teams, people are amazed how easy it is to build apps with Tiggzi. At the same time, we get a ton of feedback on improving Tiggzi builder. Here is what we are planning based on hackathon feedback:

Simplify project creation – just one project type (the app can be either mobile web or PhoneGap app)
Make the phone frame for testing optional. By default we will open the app link in full browser window. This might not look as “nice”, but technically it gives a better view of how the app looks and behaves.

Presentation time

One of the winning apps built with Tiggzi

Winners

We are looking forward to the next hackathon!

I want to thank Sasha for spending the weekend helping build apps instead of being in Yosemite. I also want to thank the entire Tiggzi team for amazing job done. They are many more awesome features they are planning to release.

Why coming to #GR8Conf?

Guillaume LaForge — Thu, 10 May 2012 11:00:30 CDT

Vert.x 1.0 released with its Groovy support

Guillaume LaForge — Thu, 10 May 2012 08:00:40 CDT

D2WC Next Week

Terry Ryan — Wed, 09 May 2012 16:00:22 CDT

Next week, I'll be speaking at D2WC, a designer/developer workflow conference in Kansas City, Missouri.

I'll be talking about Using PhoneGap Build to simplify your mobile development life. One of the great things about PhoneGap is that it allows you to use HTML JS and CSS to build your applications, but you still have to use native tools to build your apps. PhoneGap Build helps immensely with this, but you make some productivity sacrifices. This session will show you how to maximize your work, and touch as little of the IDE as possible.

First time for me at this conference, but from what I understand it's a great conference that tackles a specific topic: getting development and design to work together better. Great goal, really looking forward to it.

D2WC
May 16-18
Kansas City Marriott Country Club Plaza
4445 Main Street
Kansas City, Missouri 64111
USA

From now on, I’m calling it GroovyString

Kenneth Kousen — Wed, 09 May 2012 13:00:09 CDT

I’ve been doing a lot of introductory Groovy presentations lately, and an issue keeps coming up that I feel I have to address. I’ve had to think hard about how to do this, though, because I don’t want to be misunderstood. I’m probably going to fumble it a bit, so please forgive me if I ramble.

Lately there have been several episodes in the IT industry of boys behaving badly. A recent article in Mother Jones has a good summary. In short, a few guys in this industry have had a tendency to do and say things that have been particularly insensitive to women, for a variety of reasons ranging from simple foolishness to (potentially) outright bias.

Maybe this isn’t terribly surprising. After all, geeks aren’t always the most agile of social butterflies, and one of the downsides of getting guys together in groups is that the collective IQ tends to be lower than the individual ones. Still, I don’t want to rant about that, especially since lamenting poor behavior is almost as much of a cliche as the behavior itself.

Instead, I want to focus on the Groovy programming language, and a decision made during its early formation that could easily have been avoided if more women developers had been available.

As anyone who works with Groovy knows, the language has two types of strings. One uses single-quotes ('this is a string') and represents and instance of regular old java.lang.String. The other uses double-quotes ("this is a string with a ${variable}"), and allows for variables to be interpolated into it. The latter is a really useful class and comes up all the time.

By all the standard conventions, the class representing double-quoted strings should be called GroovyString. There are thirty or forty different classes in the Groovy API that start with the word Groovy, including such common classes as GroovyObject, GroovyShell, GroovyServlet, and GroovyTestCase. A GroovyString class would feel right at home there.

Unfortunately, though, the original development team decided to call the class representing double-quoted strings GString, because they thought it was funny. Even worse, since you substitute values into it using a $, the inevitable follow-up joke is that you do string interpolation by “putting a dollar in a GString”.

Now, I’m sure no malice was intended at the time. It was a joke, and I chuckled the first time I heard it too. So have many women I know when they first hear it. It’s actually a pretty clever joke.

But that doesn’t mean a name like that belongs in the standard library.

I think of it this way. The name of that class is yet one more reason why we need more women in this field. I’m sure that if a woman had been part of the core Groovy team at the time, she would have said something like, “ha ha, very funny, guys, but let’s not hard-wire that gag into the standard library, okay? You know, the same library that’s going to be used by every Groovy developer ever?” I fully expect that the rest of the team would have thought about it and almost certainly (if sheepishly) agreed. After all, it’s the kind of joke that’s funny once, and only for a few minutes. After that it’s mostly a nuisance. It’s hard enough to get a language named Groovy taken seriously by the Fortune 500 without going there, too.

Please don’t get me wrong, though. I’m not blaming or condemning anybody. That’s the sort of gag that comes up all the time. The mistake was making it part of the standard. Clearly there wasn’t a woman available at the time to provide some perspective.

I also draw a strong distinction between silly mistakes and outright bias. Everybody makes mistakes. I make them all the time. I try not to say anything offensive in class (or in life), partly because I really do try to respect people different from myself, and partly because I’m pretty much of a coward and don’t want to get in trouble. I certainly don’t want to make anyone uncomfortable for no good reason.

Oversensitivity leads to its own problems, too. I was an undergrad at MIT back in the 80′s. Despite the popular image of the place, the actual male/female ratio there was about 55%/45%, which wasn’t all that bad despite my complaints at the time. (The women there used to joke that the ratio of “acceptable” men to women was closer to 50/50.) The women at MIT tended to be pretty strong personalities, too, which I always thought was a good thing. I’ve always welcomed the company of women I could take seriously, or men too for that matter. The problem was that like so many academic environments, MIT had a marked tendency to overreact to any accusation of bias. Once someone complained of bias, rationality went out the window and any hope of getting to the actual truth was completely lost.

By the way, I believe this is partly what happened in the late 80′s and early 90′s, when oversensitivity to bias was labeled “political correctness” and summarily dismissed. I think we’re still paying the price for that.

That’s really unfortunate, too, because every woman I’ve ever met, without exception, has a story to tell that qualifies as bias or even harassment by any reasonable definition. Sometimes all you have to do is ask to hear stories that will make you shudder. Overreactions desensitize people against actual injustices that should cause outrage.

I don’t think the Groovy class in question qualifies on that scale. It’s a mistake, in my opinion, and a natural result of having too few women in the field. I’m not calling for a movement to rename the class or criticize anyone who uses the established name. But, then again, I’m not a woman. It’s entirely possible I don’t “get it”.

As a result, from now on I’m going to call double-quoted strings GroovyStrings. It’s easy enough for me to do, and while it may not change anything, hopefully it will make some women developers feel slightly more welcome. If you want to join me, great, but if not, that’s fine too. I’ve made my decision, though, and hopefully this post will make my reasons clear.