Thursday, November 5, 2015

Fabric / Crashlytics ADD in Images

Remember how I commented that Crashlytics' daily email was so focused on the daily delta that it lacked a sense of the overall trends?

Here's two daily emails back to back. October 30th:

October 31st:

App name pixelated because I haven't cleared sharing this information, so I'm sharing it without the identifiable information.

These kinds of transitions, from "growing like crazy" to "growth slows" and back are a daily occurrence which totally obscures any real trends about how many users are actually using your app.

Tuesday, October 27, 2015

GWT Plugin Still Not Ready for Eclipse 4.5?

Eclipse Mars / v4.5 was released June 24, 2015. The Google Plugin for Eclipse 4.5 has not yet been released. If you go to the Google Plugin for Eclipse quickstart page, you can see that it's still showing links for Eclipse 4.4, 4.3 and 4.2 / 3.8.

In essence, if you'd like to use GWT and you want to use the latest Eclipse, there's no officially supported option nearly four months later.

If you do a little searching, you'll find a few threads on the subject, :

A friend tried Eclipse 4.5 and the Google Plugin for Eclipse 4.4 together and hit a NoClassDefFound error for Java2HTMLEntityReader. A quick search found that it was a bug, but that raises further questions about a plugin fork, which looks like it might have been around since 2013. It looks like there's a lot of work underway.

Ultimately, between this and some of the posts about GWT 2.8, this adds to my long-growing sense that GWT is stagnating. It hasn't descended into a terrible state yet by any means. It's quite usable for existing projects. Still, I wouldn't recommended it for a new project, and I'd recommend that people using it on existing projects start thinking about the long-term plan for their projects and consider a plan to move away from GWT at some point and how to manage that transition.

Thursday, October 22, 2015

Fabric / Crashlytics Growth ADD

Crashlytics' / Fabric has a daily email which gives you a sense of recent crashes, and also some basic stats.  It's useful, but they don't seem to consider that there can be a fair amount of day-to-day variance and attempt to smooth that out and give you a sense of real trends. Instead, everything is about yesterday's change:

  • Day N:
    • New sessions up 20%!
    • Your app is on fire!
    • Seek investment immediately!

  • Day N+1:
    • New sessions down 15%!
    • Your app is beginning to stagnate!
    • Oh noes!
I captured images from two back-to-back emails as a good example.

Thursday, September 24, 2015

Searching for Android Documentation in Dash

Android developers: are you using Kapeli's Dash to read Android docs on a Mac? Want to be able to search for inherited methods without hitting "expand all" first? Request it!

Tuesday, September 22, 2015

Limited Integration between MailChimp and Mandrill

I'm surprised by how limited the integration is between MailChimp and Mandrill. Given that Mandrill is a product developed by MailChimp, I was expecting the integration between the two to be pretty strong, and it really doesn't seem to be.

They're not the same use case, I admit. MailChimp is more of a broadcast / marketing email platform, with elements like campaigns to consider, whereas Mandrill is a transactional email service, for personalized delivery of email messages like notifications from an application. I'm not surprised that they have somewhat different feature sets as a result. 

I was a little surprised to discover that Mandrill and Mailchimp have a totally different account system, and that while you can link your MailChimp account to your Mandrill account, it's not like having a single account with multiple products/services.

The more you look, the deeper the differences get, and the more surprised I was.

For instance, look at templates. MailChimp allows you to define email templates that you might send to a mailing list. Think of something like a sale email, where you might configure a template and then merge in a few specifics as you're sending to each person. MailChimp has a sophisticated WYSIWYG editor that you can use to define these email templates.

Mandrill also has templates. You might want to configure a template for the welcome email for your application in Mandrill rather than having the application encode all the details of what's in the email. This means that later, you could come back in and modify the template without changing the application.

However, Mandrill doesn't have a WYSIWYG editor. If you wanted to have someone on your growth hacking team change the email, they'll have to know HTML to do it. That may not be the end of the world, depending on your company structure but it was a surprising inconsistency for me, and a bit of a missed opportunity.

There are integrations between the two. For instance, you can actually create an HTML template in MailChimp using their editor and then send the template over to Mandrill. But when you do so, you don't seem have the option of choosing which template to replace, or to make use of Mandrill's template versioning. And if you make use of Merge Codes (think personalized fields) in MailChimp's designer, some, but not all of those codes are supported in Mandrill, but neither MailChimp nor Mandrill seems to mind if you make use of them and then send the template from MailChimp to Mandrill. Those codes won't do their job anymore, but neither system tells you that, from what I can see.

I just think MailChimp has missed an opportunity, both to integrate these two systems more tightly, encouraging MailChimp customers to consider Mandrill and vice versa, and also, frankly, to improve the experience of both systems by leveraging the work done by the other. Why doesn't MailChimp offer their WYSIWYG designer in the Mandrill interface? Can MailChimp templates by sent to Mandrill to become alternate versions of existing templates rather than replacing them? If not, why not?

Wednesday, August 12, 2015

Mocking HTTP Servers

I am doing some HTTP-based integration work for a client on a GWT-based project (which is why I wanted to know which HttpClient version to use). I'm still waiting on access to the third-party system, but I've already written and tested the code to generate the XML request and parse the XML response, so I wanted to take a step farther and write the code that would connect that with HTTP:

  • Generate XML using the XML writer/generator
  • Send the XML over HTTP
  • Wait for the HTTP Response, check it (status code, etc)
  • Parse the HTTP response's body using the XML parser/reader

But if I were going to do that, I want to test it, and testing it requires something to listen for HTTP requests (or to mock out the HTTP client, but this is already a pretty thin layer). I don't have access to the real service yet, so I can't write an integration test and, to be honest, I tend to try not to rely on integration tests. So basically I want something that can pretend to be an HTTP Server of some kind but that has an API that makes writing test code convenient. I went looking for candidates to easily test an HTTP-based client in Java.

When I'm picking tools in other platforms, I often consider the popularity of the dependency as well as other signs of its maturity. In Java, it's hard to get good numbers for such things. First of all, while there are some dependency management systems for Java, they're not universal or nearly-universal like they are on other platforms. Maven's central repository is probably the closest thing to that, but even then, there are lots of projects that download their dependencies directly. And, sadly, Maven doesn't publish stats about their dependencies, stats you could use to gauge how many other people are using and trusting a particular library vs. another.

However, after looking at some of the alternatives, I decided to start with That worked pretty well, but I don't really love using an external server for a simple test. That test wouldn't run offline, wouldn't run if the internet was down, or if was having problems. It's basically too much of an integration test, and not even an integration test against the real service. Still, it worked well, and it's a reasonable place to start if you just want to fire up a simple test without adding new dependencies to your project.

I looked at alternatives to replace it. WireMock has a reputation for being very capable and having a good API, but perhaps not kept as up-to-date as one might like and a little heavy-weight. I also looked at MockServer, which looks very capable but also looks pretty heavy. My requirements for now are super-simple, so I ended up using okhttp's MockWebServer, one of Square's open-source projects. It's very simple, reasonably light, very fast, and has enough capability for my simple needs. I like it.

There are lots of alternatives, from something custom (Netty, RxNetty, Spray) to other competitive libraries (jailer,mock-http-server) and services (Sandbox), but for the moment, MockWebServer does the job for me.

Monday, August 10, 2015

GWT / HttpClient Version Compatibility

If you're using GWT and Apache HttpClient in a single project, it can be useful to know which version of HttpClient ships with which version of GWT, because GWT includes HttpClient directly in its jar, and conflicting versions can be a bit of a pain.

I can't find that information published anywhere else, so I'm publishing it here. Basically, look in the dev/build.xml file for the tagged version of GWT that you care about. Since I've already done that, here's the result for several of the most recent releases:

GWT VersionHttpClient Version

I hope this will be useful for someone else.