Application footprint
I recently came across Carl Erickson’s ‘small teams are dramatically more efficient than large teams‘ blog post which reminded me of something which my colleague Ashok suggested as a useful way for determining team size – the application footprint.
As I understand it the application footprint is applicable for an application at a given point in time and determines how many parallel tasks/streams of work we have.
In the case of the project that I’m currently working on there are 3 separate components which need to interact with each other via an API but otherwise are independent.
We can therefore have 3 pairs working – one on each component – and won’t have to worry about them stepping on each other’s toes.
One interesting thing about the application footprint is that it doesn’t stay the same size all the time.
More often than not once a team has gained trust by getting a release out the product owner will start prioritising more independent features which don’t necessarily overlap.
At this stage it might not be such a bad idea to add people to the team if we want to try and finish more quickly.
If we’re already at the point where we have the same number of pairs as parallel pieces of work then adding people is going to be problematic because we’ll struggle to find work for everyone to do.
Stories in the same stream will have dependencies on each other and although it’s theoretically possible to start on something which has a dependency, the likelihood of having to rework it is higher.
One way to get around that problem if we decide that we don’t want to reduce our team size is to have a pair assigned to working on bugs, cross functional requirements such as performance testing/tuning or doing some technical analysis on upcoming stories.
It’s easy enough to remember all this when you’re starting out building an application but I think it’s something that we need to keep in mind so that if there’s pressure to add people to ‘go faster’ then we can determine if that will actually be the case.
As an aside
Obviously there are times when we decide that we’re happy to put more people on a team than it’s footprint might suggest in order to get an overall gain.
For example with 5 pairs we may finish 50 points in a week but if we increase to 10 pairs then perhaps we now get 60 points.
We’ve nearly halved the efficiency of each pair but overall we’ve got a marginal gain which sometimes makes sense. We also need to be aware of the collective unresponsibility that we might introduce by doing this.
Photo courtesy of farlane
Focused Retrospectives: things to watch for
A few weeks ago a slide deck from an Esther Derby presentation on retrospectives was doing the rounds on twitter and one thing that I found interesting in the deck was the suggestion that a retrospective needs to be focused in some way.
I’ve participated in a few focused retrospectives over the past 7/8 months and I think there are some things to be careful about when we decide to focus on something specific rather than just looking back at a time period in general.
Victimisation
In a retrospective about 6 months ago or so we focused on the analysis part of our process as we’d been struggling to know when a story was complete and what exactly its scope was.
The intention wasn’t the victimise the people working in that role but since there were very few of them compared to people in other roles they were forced onto the defensive as people criticised their work.
It was a very awkward retrospective and it felt like a retrospective was probably the wrong place to address the problem.
It might have been better for the analysts to have been given the feedback privately and then perhaps worked on a solution with a smaller group of people.
Looking for a problem when there isn’t one
I had an interesting conversation with a colleague about whether with very focused retrospectives we end up looking for something to change rather than having any specific pain point which necessitates change.
The problem with this is that there’s a thin line between following the status quo because it works and getting complacent and not looking for ways to improve.
It is interesting to keep in mind though that if it doesn’t seem like there is something to change in an area then perhaps that’s the wrong thing to be focusing on at the moment, which nicely leads into…
Let the team choose the area of focus
There can be a tendency in the teams I’ve worked on for people in managementy roles to dictate what the focus of the retrospective will be which makes sense in a way since they may be able to see something which the team can’t.
On the other hand it can mean that we end up focusing on the wrong thing and team members probably won’t be that engaged in the retrospective since they don’t really get to dictate what’s talked about.
Esther points this out out on slide 23 of the presentation – “Choose a focus that reflects what’s going on for the team“. This perhaps can be determined by having a vote before hand based on some topics that seem prominent.
In summary
There’s lots of other useful tips in Esther’s slide deck which are worth having a look at and I’m sure most of the potential problems I’ve listed probably don’t happen when we have a highly skilled/experienced facilitator.
Wireshark: Following HTTP requests/responses
I like using Wireshark to have a look at the traffic going across different interfaces but because it shows what’s happening across the wire by the packet it’s quite difficult to tell what a request/response looked like.
I’ve been playing around with restfulie/Vraptor today so I wanted to be able to see the request/response pair when something wasn’t working.
I didn’t know it was actually possible but this post on StackOverflow describes how.
First we need to select the row which contains any part of our request/response – in this case I just selected the row representing the request – and then we go to the Analyze menu and click ‘Follow TCP Stream’:
We can then see the requests/responses which happened all next to each other:
The keyboard shortcut to get to that menu is ‘Alt-A F’ but for some reason the ‘Alt’ key wasn’t working for me by default so I had to follow the instructions on Francis North’s blog to get it working.
Oracle: exp – EXP-00008: ORACLE error 904 encountered/ORA-00904: “POLTYP”: invalid identifier
I spent a bit of time this afternoon trying to export an Oracle test database so that we could use it locally using the exp tool.
I had to connect to exp like this:
exp user/password@remote_address
And then filled in the other parameters interactively.
Unfortunately when I tried to actually export the specified tables I got the following error message:
EXP-00008: ORACLE error 904 encountered ORA-00904: "POLTYP": invalid identifier EXP-00000: Export terminated unsuccessfully
I eventually came across Oyvind Isene’s blog post which pointed out that you’d get this problem if you tried to export a 10g database using an 11g client which is exactly what I was trying to do!
He explains it like so:
The export command runs a query against a table called EXU9RLS in the SYS schema. On 11g this table was expanded with the column POLTYP and the export command (exp) expects to find this column.
I needed to download the 10g client so that I could use that version of exp instead. I haven’t quite got it working yet but at least it’s a different error to deal with!
Learning Android: Roboguice – Injecting context into PreferenceManager
In my last post I showed how I’d been able to write a test around saved preferences in my app by making use of a ShadowPreferenceManager but it seemed a bit hacky.
I didn’t want to have to do that for every test where I dealt with preferences – I thought it’d be better if I could wrap the preferences in an object of my own and then inject it where necessary.
Another benefit of taking this approach is that the interface of exactly what I’m storing as user preferences.
I wanted the class to be roughly like this:
public class UserPreferences { public String userKey() { return getDefaultSharedPreferences().getString("user_key", ""); } public String userSecret() { return getDefaultSharedPreferences().getString("user_secret", ""); } private SharedPreferences getDefaultSharedPreferences() { return PreferenceManager.getDefaultSharedPreferences(getContextHereSomehow()); } }
Initially it wasn’t entirely obvious how I could get a Context to pass to getDefaultSharedPreferences but I came across a blog post explaining how to do it.
What we need to do is inject a Context object via the constructor of the class and decorate the constructor with the @Inject attribute so that Roboguice will resolve the dependency:
public class UserPreferences { private Context context; @Inject public UserPreferences(Context context) { this.context = context; } public SharedPreferences getDefaultSharedPreferences() { return PreferenceManager.getDefaultSharedPreferences(context.getApplicationContext()); } public String userKey() { return getDefaultSharedPreferences().getString("user_key", ""); } public String userSecret() { return getDefaultSharedPreferences().getString("user_secret", ""); } }
We never have to explicitly setup a binding for Context in our Roboguice because it’s already been done for us in RoboModule which is instantiated by RoboApplication which we extend like so:
public class TweetBoardApplication extends RoboApplication { private Module module = new RobolectricSampleModule(); @Override protected void addApplicationModules(List<Module> modules) { modules.add(module); } public void setModule(Module module) { this.module = module; } }
We then hook TweetBoardApplication up in the AndroidManifest.xml file like this:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.pivotallabs" android:versionCode="1" android:versionName="1.0"> <application android:label="@string/app_name" android:theme="@android:style/Theme.Light.NoTitleBar" android:icon="@drawable/app_icon" android:name="TweetBoardApplication"> </application> </manifest>
And that’s it!
Learning Android: Robolectric – Testing details got saved to SharedPreferences
I’ve been writing some tests around an app I’ve been working on using the Robolectric testing framework and one thing I wanted to do was check that an OAuth token/secret were being saved to the user’s preferences.
The code that saved the preferences looked like this:
public class AuthoriseWithTwitterActivity extends RoboActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(intent); ... save("fakeToken", "fakeSecret"); ... } private void save(String userKey, String userSecret) { SharedPreferences settings = PreferenceManager.getDefaultSharedPreferences(getBaseContext()); SharedPreferences.Editor editor = settings.edit(); editor.putString("user_key", userKey); editor.putString("user_secret", userSecret); editor.commit(); } }
This is an outline of what I wanted to do in the test:
@RunWith(InjectedTestRunner.class) public class AwesomeTest { @Test public void shouldSaveOAuthDetails() { activity.onCreate(null); ShadowIntent shadowIntent = shadowOf(activity).getNextStartedActivity(); // Get SharedPreferences and check 'fakeToken' and 'fakeSecret' are stored. } }
In Robolectric it’s possible to replace classes with shadow versions of themselves which get used in the test so I first created a shadow version of PreferenceManager:
@Implements(PreferenceManager.class) public class ShadowPreferenceManager { private static SharedPreferences preferences = new TestSharedPreferences(new HashMap<String, Map<String, Object>>(), "__default__", Context.MODE_PRIVATE); @Implementation public static SharedPreferences getDefaultSharedPreferences(Context context) { return preferences; } public static void reset() { preferences = new TestSharedPreferences(new HashMap<String, Map<String, Object>>(), "__default__", Context.MODE_PRIVATE); } }
I had to make preferences a static variable here so that it’ll retain state. It’s a bit hacky but it’ll do for now.
Then to hook it up I had to change my test to read like this:
@RunWith(InjectedTestRunner.class) public class AwesomeTest { @Test public void shouldSaveOAuthDetails() { Robolectric.bindShadowClass(ShadowPreferenceManager.class); activity.onCreate(null); ShadowIntent shadowIntent = shadowOf(activity).getNextStartedActivity(); SharedPreferences defaultSharedPreferences = PreferenceManager.getDefaultSharedPreferences(activity); assertThat(defaultSharedPreferences.getString("user_key", ""), equalTo("fakeToken")); assertThat(defaultSharedPreferences.getString("user_secret", ""), equalTo("fakeSecret")); ShadowPreferenceManager.reset(); } }
The InjectedTestRunner class used here is pretty much like the one in the Robolectric code base.
There is actually a ShadowPreferenceManager in the Robolectric library but it doesn’t seem to store preferences anywhere as far as I can tell so it wasn’t quite what I wanted.
Learning Android: Getting android-support jar/compatability package as a Maven dependency
In the app I’m working on I make use of the ViewPager class which is only available in the compatibility package from revisions 3 upwards.
Initially I followed the instructions on the developer guide to get hold of the jar but now that I’m trying to adapt my code to fit the RobolectricSample, as I mentioned in my previous post, I needed to hook it up as a Maven dependency.
I added the dependency to my pom.xml like this:
<dependency> <groupId>android.support</groupId> <artifactId>compatibility-v4</artifactId> <version>r6</version> </dependency>
But when I tried to resolve the dependencies (via ‘mvn test’) I ended up with this error:
Downloading: http://repo1.maven.org/maven2/android/support/compatibility-v4/r6/compatibility-v4-r6.pom [WARNING] The POM for android.support:compatibility-v4:jar:r6 is missing, no dependency information available Downloading: http://repo1.maven.org/maven2/android/support/compatibility-v4/r6/compatibility-v4-r6.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.878s [INFO] Finished at: Sun Jan 08 20:42:17 GMT 2012 [INFO] Final Memory: 8M/554M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project tweetboard: Could not resolve dependencies for project com.markhneedham:tweetboard:apk:1.0.0-SNAPSHOT: Could not find artifact android.support:compatibility-v4:jar:r6 in central (http://repo1.maven.org/maven2) -> [Help 1]
A bit of googling led me to a demo project showing how to hook up the compatibility package. It linked to the Maven Android SDK Deployer which is:
The Maven Android SDK Deployer is a helper maven project that can be used to install the libraries necessary to build Android applications with Maven and the Android Maven Plugin directly from your local Android SDK installation.
I had to first clone that git repository:
git clone git://github.com/mosabua/maven-android-sdk-deployer.git
And then find the compatability-v4 package and install it:
$ cd maven-android-sdk-deployer $ cd extras/compatibility-v4 $ mvn clean install
I initially made the mistake of not setting $ANDROID_HOME to the location of the Android SDK on my machine, which led to the following error:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.484s
[INFO] Finished at: Sun Jan 08 20:51:07 GMT 2012
[INFO] Final Memory: 3M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:properties-maven-plugin:1.0-alpha-2:read-project-properties (default) on project android-extras: Properties file not found: /Users/mneedham/github/maven-android-sdk-deployer/extras/${env.ANDROID_HOME}/extras/android/support/source.properties -> [Help 1]Setting it solves the problem:
$ export ANDROID_HOME=/Users/mneedham/github/android/android-sdk-macosx
There are more detailed instructions on the home page of the github project.
Learning Android: java.lang.OutOfMemoryError: Java heap space with android-maven-plugin
I’ve been trying to adapt my Android application to fit into the structure of the RobolectricSample so that I can add some tests around my code but I was running into a problem when trying to deploy the application.
To deploy the application you need to run the following command:
mvn package android:deploy
Which was resulting in the following error:
[INFO] UNEXPECTED TOP-LEVEL ERROR: [INFO] java.lang.OutOfMemoryError: Java heap space [INFO] at com.android.dx.rop.code.PlainInsn.withNewRegisters(PlainInsn.java:152) [INFO] at com.android.dx.ssa.NormalSsaInsn.toRopInsn(NormalSsaInsn.java:121) [INFO] at com.android.dx.ssa.back.SsaToRop.convertInsns(SsaToRop.java:342) [INFO] at com.android.dx.ssa.back.SsaToRop.convertBasicBlock(SsaToRop.java:323) [INFO] at com.android.dx.ssa.back.SsaToRop.convertBasicBlocks(SsaToRop.java:260) [INFO] at com.android.dx.ssa.back.SsaToRop.convert(SsaToRop.java:124) [INFO] at com.android.dx.ssa.back.SsaToRop.convertToRopMethod(SsaToRop.java:70) [INFO] at com.android.dx.ssa.Optimizer.optimize(Optimizer.java:102) [INFO] at com.android.dx.ssa.Optimizer.optimize(Optimizer.java:73)
I’d added a few dependencies to the original pom.xml file so I figured on of those must be causing the problem and eventually narrowed it down to be the twitter4j-core library which I had defined like this in the pom.xml file:
<dependency> <groupId>org.twitter4j</groupId> <artifactId>twitter4j-core</artifactId> <version>[2.2,)</version> </dependency>
I found a bug report for the maven-android-plugin which suggested that increasing the heap size might solve the problem.
That section of the pom.xml file ended up looking like this:
<plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <version>3.0.0-alpha-13</version> <configuration> <sdk> <platform>10</platform> <path>/path/to/android-sdk</path> </sdk> <dex> <jvmArguments> <jvmArgument>-Xms256m</jvmArgument> <jvmArgument>-Xmx512m</jvmArgument> </jvmArguments> </dex> <undeployBeforeDeploy>true</undeployBeforeDeploy> </configuration> <extensions>true</extensions> </plugin>
That seemed to get rid of the problem but I also tried changing the plugin version to the latest one and that seemed to solve the problem as well without the need to add the JVM arguments:
<plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <configuration> <sdk> <platform>10</platform> <path>/path/to/android-sdk</path> </sdk> <undeployBeforeDeploy>true</undeployBeforeDeploy> </configuration> <extensions>true</extensions> </plugin>
The latest version is 3.0.2 from what I can tell.
Learning Android: Freezing the UI with a BroadcastReceiver
As I mentioned in a previous post I recently wrote some code in my Android app to inform a BroadcastReceiver whenever a service processed a tweet with a link in it but in implementing this I managed to freeze the UI every time that happened.
I made the stupid (in hindsight) mistake of not realising that I shouldn’t be doing a lot of logic in BroadcastReceiver.onReceive since that bit of code gets executed on the UI thread.
The service code which raises the broadcast message is the same as in the previous post:
public class TweetService extends IntentService { ... @Override protected void onHandleIntent(Intent intent) { StatusListener listener = new UserStreamListener() { // override a whole load of methods - removed for brevity public void onStatus(Status status) { String theTweet = status.getText(); if (status.getText().contains("http://")) { Intent tweetMessage = new Intent(TweetTask.NEW_TWEET); tweetMessage.putExtra(android.content.Intent.EXTRA_TEXT, status.getText()); sendBroadcast(tweetMessage); } } }; // code to connect to the twitter streaming API } }
That is then handled like this by the BroadcastReceiver:
public class MyActivity extends Activity { protected void onPause() { super.onPause(); if (dataUpdateReceiver != null) unregisterReceiver(dataUpdateReceiver); } protected void onResume() { super.onResume(); if (dataUpdateReceiver == null) dataUpdateReceiver = new DataUpdateReceiver(); IntentFilter intentFilter = new IntentFilter(TweetTask.NEW_TWEET); registerReceiver(dataUpdateReceiver, intentFilter); } private class DataUpdateReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals(TweetTask.NEW_TWEET)) { Pattern p = Pattern.compile("(http://[^\\s]+)"); String theTweet = intent.getStringExtra(TweetTask.NEW_TWEET); Matcher matcher = p.matcher(theTweet); int startIndex = -1; int endIndex = -1; while (matcher.find()) { startIndex = matcher.start(); endIndex = matcher.end(); } if (startIndex != -1 && endIndex != -1) { String resolvedUrl = resolveUrl(theTweet.substring(startIndex, endIndex)); saveToDatabase(resolvedUrl); updateUI(resolvedUrl); } } } } }
In particular the ‘resolveUrl’ line was probably the one one causing the problem since it makes a network call to resolve URLs from link shorteners.
To stop the screen freezing up I just needed to move most of the code from BroadcastReceiver into the TweetService:
public class TweetService extends IntentService { ... @Override protected void onHandleIntent(Intent intent) { StatusListener listener = new UserStreamListener() { // override a whole load of methods - removed for brevity public void onStatus(Status status) { String theTweet = status.getText(); if (status.getText().contains("http://")) { Pattern p = Pattern.compile("(http://[^\\s]+)"); Matcher matcher = p.matcher(theTweet); int startIndex = -1; int endIndex = -1; while (matcher.find()) { startIndex = matcher.start(); endIndex = matcher.end(); } if (startIndex != -1 && endIndex != -1) { String resolvedUrl = resolveUrl(theTweet.substring(startIndex, endIndex)); saveToDatabase(resolvedUrl); Intent tweetMessage = new Intent(TweetTask.NEW_TWEET); tweetMessage.putExtra(android.content.Intent.EXTRA_TEXT, resolvedUrl); sendBroadcast(tweetMessage); } } } }; // code to connect to the twitter streaming API } }
And then the code for BroadcastReceiver becomes much simpler which means we’re doing less work on the UI thread:
private class DataUpdateReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals(TweetTask.NEW_TWEET)) { String url = intent.getStringExtra(TweetTask.NEW_TWEET); updateUI(url); } } }
And the freezing up of the UI is gone!
Learning Android: Getting a service to communicate with an activity
In the app I’m working on I created a service which runs in the background away from the main UI thread consuming the Twitter streaming API using twitter4j.
It looks like this:
public class TweetService extends IntentService { String consumerKey = "TwitterConsumerKey"; String consumerSecret = "TwitterConsumerSecret"; public TweetService() { super("Tweet Service"); } @Override protected void onHandleIntent(Intent intent) { AccessToken accessToken = createAccessToken(); StatusListener listener = new UserStreamListener() { // override a whole load of methods - removed for brevity public void onStatus(Status status) { String theTweet = status.getText(); if (status.getText().contains("http://")) { // do something with the tweet } } }; ConfigurationBuilder configurationBuilder = new ConfigurationBuilder(); configurationBuilder.setOAuthConsumerKey(consumerKey); configurationBuilder.setOAuthConsumerSecret(consumerSecret); TwitterStream twitterStream = new TwitterStreamFactory(configurationBuilder.build()).getInstance(accessToken); twitterStream.addListener(listener); twitterStream.user(); } }
That gets called from MyActivity like so:
public class MyActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { ... super.onCreate(savedInstanceState); Intent intent = new Intent(this, TweetService.class); startService(intent); } }
I wanted to be able to inform the UI each time there was a tweet which contained a link in it so that the link could be displayed on the UI.
It is possible for any other apps to listen to the broadcast message as well if they wanted to but in this case the information isn’t very important so I think it’s fine to take this approach.
I first had to change the service to look like this:
public class TweetTask { public static final String NEW_TWEET = "tweet_task.new_tweet"; } public class TweetService extends IntentService { String consumerKey = "TwitterConsumerKey"; String consumerSecret = "TwitterConsumerSecret"; public TweetService() { super("Tweet Service"); } @Override protected void onHandleIntent(Intent intent) { AccessToken accessToken = createAccessToken(); StatusListener listener = new UserStreamListener() { // override a whole load of methods - removed for brevity public void onStatus(Status status) { String theTweet = status.getText(); if (status.getText().contains("http://")) { Intent tweetMessage = new Intent(TweetTask.NEW_TWEET); tweetMessage.putExtra(android.content.Intent.EXTRA_TEXT, document); sendBroadcast(tweetMessage); } } }; ConfigurationBuilder configurationBuilder = new ConfigurationBuilder(); configurationBuilder.setOAuthConsumerKey(consumerKey); configurationBuilder.setOAuthConsumerSecret(consumerSecret); TwitterStream twitterStream = new TwitterStreamFactory(configurationBuilder.build()).getInstance(accessToken); twitterStream.addListener(listener); twitterStream.user(); } }
I then had to define the following code in MyActivity:
public class MyActivity extends Activity { protected void onResume() { super.onResume(); if (dataUpdateReceiver == null) dataUpdateReceiver = new DataUpdateReceiver(textExtractionService); IntentFilter intentFilter = new IntentFilter(TweetTask.NEW_TWEET); registerReceiver(dataUpdateReceiver, intentFilter); } protected void onPause() { super.onPause(); if (dataUpdateReceiver != null) unregisterReceiver(dataUpdateReceiver); } private class DataUpdateReceiver extends BroadcastReceiver { private CachedTextExtractionService textExtractionService; public DataUpdateReceiver(CachedTextExtractionService textExtractionService) { this.textExtractionService = textExtractionService; } @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals(TweetTask.NEW_TWEET)) { // do something with the tweet } } } }
Now whenever there’s a tweet with a link in it my BroadcastReceiver gets notified and I can do whatever I want with the tweet.
This seems like a reasonably simple solution to the problem so I’d be interested to know if there are any other drawbacks other than the one I identified above.
