Ken's Blog

Installing SHA-256/SHA-2 SSL Certificate on Lotus Domino

Ken K. Yee — Thu, 19 Nov 2015 22:23:22 -0400

For those of you still using Lotus Domino and trying to get an SSL certificate installed now that everyone has moved to SHA-256 signed SSL certificates, here are two helpful links:
- using the kyrtool to generate the keyfile, CSR, and import keys
- using nginx for SSL as a reverse-proxy in front of the Domino server and also load balancing

Reproducible Cooking w/ Anova's Sous Vide Circulator

Ken K. Yee — Sat, 17 Jan 2015 00:00:00 -0400

After adding a sous-vide circulator to my cooking tools last year, I realized how much of a similarity this had w/ some of the Jenkins build automation work I've done. Restaurants use sous-vide to provide almost an idiot-proof consistency to their dishes as well as create dishes that weren't possible with control of temperatures and cooking time. Consistency in cooking is as important as it is in the software build process.

Book Review: Learning AngularJS for .Net Developers

Ken K. Yee — Wed, 5 Nov 2014 22:11:52 -0400

Learning AngularJS for .Net Developers, written by Alex Pop and published by PACKT, provides a good introduction to single page applications with the AngularJS framework using Visual Studio 2013 as your development environment. There is a lot of information available online for AngularJS, so the topics I'd like to see covered include in such a book include: how AngularJS is used on the client side, what support is provided by Visual Studio, how to write a .Net backend to support AngularJS, how authentication/security works in a client side application, how localization works, how the site is tested, and how the site can handle desktop web and mobile clients (aka Cordova/PhoneGap). Most of these topics are covered sufficiently in this book except the last topic of using PhoneGap.

Android's Horrid 64K DEX Method Limit

Ken K. Yee — Sun, 17 Aug 2014 00:00:00 -0400

One of the worst design decisions in the Android Dalvik virtual machine is the 64K method limit (this limit includes all methods in your application and all libraries you link in; note that this is not the same as Facebook's 64K Dalvik Runtime issue. The cryptic compile time error you'll get during a build of your project is:
java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536

This problem will manifest easily if you hook in a few libraries that have a lot of methods, including notably the Google Play Services Library which can suck up 1/3 of this limit. Other libraries that are huge include the Amazon Web Services library and Guava and Protobufs (which you can substitute with Square's Wire to reduce the method count). You can analyze the method count using dex-method-counts.

Note: Google's official workaround is multidex support.

OrmLite provides a standard ORM data mapping layer for Android, but if you want to avoid the performance hit from reflections (it uses annotations), you have to run a generator to make a configuration file that can be loaded at runtime. �Unfortunately, there's no documented automated way of doing this. We were evaluating OrmLite for Mustbin's Android application and I ended up automating the generation of this file.

Ken K. Yee — Mon, 17 Feb 2014 00:00:00 -0400

At the top level of your project, create an ormlite-gen directory. You'll typically have beans w/ annotations in a beans or DB directory in your own application. These beans might use classes that are Android based (e.g. Parceable), so the ormlite-gen directory has to include Android libraries to compile your beans. You'll need a simple AndroidManifest.xml:
package="com.mustbin.mustbin" android:versionCode="1" android:versionName="1.0" > android:minSdkVersion="8" android:targetSdkVersion="19" />

Then you also need a build.gradle in the ormlite-gen directory:
import org.apache.tools.ant.taskdefs.condition.Os buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.8.+' } } apply plugin: 'android' repositories { mavenCentral() } dependencies { compile 'com.j256.ormlite:ormlite-android:4.48' compile 'com.google.code.gson:gson:2.2.+' } android { compileSdkVersion 19 buildToolsVersion '19.0.1' sourceSets { main { manifest { srcFile 'AndroidManifest.xml' } java { srcDir 'src' srcDir '../app/src/main/java/com/mustbin/mustbin/api/beans' srcDir '../app/src/main/java/com/mustbin/mustbin/db' exclude 'MustbinOpenHelper.java' } resources { srcDir 'src/resources' } } } } ext.CfgFileName = 'ormlite_config.txt' ext.SrcCfgPath = '../app/src/main/res/raw/' ext.GenCfgPath = 'build/classes/debug/app/src/main/res/raw/' task copyConfigHereTask(type: Copy) { from SrcCfgPath+CfgFileName into GenCfgPath } task copyConfigBackTask(type: Copy) { from GenCfgPath+CfgFileName into SrcCfgPath } task runOrmGenTask(type: Exec) { workingDir './build/classes/debug' if (Os.isFamily(Os.FAMILY_WINDOWS)) { commandLine 'cmd', '/c', 'java', '-cp', '../../../libs/*:.', 'com.mustbin.mustbin.db.DatabaseConfigUtil' } else { //commandLine 'pwd' commandLine 'java', '-cp', '../../../libs/*:.', 'com.mustbin.mustbin.db.DatabaseConfigUtil' } } task genOrmCfg(dependsOn: ['clean', 'assembleDebug', 'copyConfigHereTask', 'runOrmGenTask', 'copyConfigBackTask']) { println "Generating OrmLite Config..." // the following locks the order of execution assembleDebug.mustRunAfter clean copyConfigHereTask.mustRunAfter assembleDebug runOrmGenTask.mustRunAfter copyConfigHereTask copyConfigBackTask.mustRunAfter runOrmGenTask }

The main task is named genOrmCfg and copies over the OrmLite DatabaseConfigUtil to do the compile of the beans that are referenced by the srcDir parameters. Once that is done, it copies the ormlite_config.txt back to the appropriate place in your app's project.

Lastly, you have to modify your app's build.gradle to run this genOrmCfg task:

//// This section generates the config file for OrmLite and copies it to the right place
task runOrmGenTask(type: Exec) {
buildFile = '../ormlite-gen/build.gradle'
tasks = ['genOrmCfg']
}

Android.applicationVariants.all { variant ->
ext.variantname = "assemble" + variant.name.capitalize()

//println "Looking for variant ${variantname}"

def targetTask = project.tasks.findByName("${variantname}")

if (targetTask != null) {

println "Adding dependency to ${variant.name}"

targetTask.dependsOn("runOrmGenTask")

targetTask.mustRunAfter("runOrmGenTask")

}

}

This will run the OrmLite generator every time you compile to make sure everything is up-to-date. If you want to cut down your compile times, you can run the "runOrmGenTask" manually instead, but you might run into a situation where your classes are newer than the ormlite_config.txt file.

Eclipse Importing Android Libraries as Gradle Projects

Ken K. Yee — Thu, 12 Dec 2013 16:20:41 -0400

If you ever have problems importing an Android library into Eclipse because Eclipse keeps importing the library as Gradle project (not useful for adding to your Android project), be sure the ".gradle" and ".settings" subdirectories are removed from the project before import. The ".classpath" and ".project" files are also not needed.

Gradle Dynamic Dependencies Also Use Ivy Syntax

Ken K. Yee — Sat, 5 Oct 2013 00:00:00 -0400

Most build.gradle dependencies I've seen specify them using the standard "+" Gradle syntax:
compile group: 'org.slf4j', name: 'slf4j-simple', version: '1.7.+'
But if you use the maven-plugin that can generate pom.xml files and upload your project to a Maven repository, this breaks Maven builds because the "1.7.+" is not Maven syntax. You can use this instead:
compile "org.slf4j:slf4j-api:[1.7,1.8)"
This mathematical set range notation does effectively the same thing. It includes all 1.7 versions but stops at 1.8. If you wanted it to include any version above 1.7 (including 2.0, etc.), you'd specify:
compile "org.slf4j:slf4j-api:[1.7,)"
There's a bit more info on the Maven/Ivy dynamic version syntax on Maestro's blog.

Adding Google/Facebook/LinkedIn OAuth Support to DropWizard

Ken K. Yee — Sun, 15 Sep 2013 00:00:00 -0400

DropWizard is a nice lightweight ops-friendly (provides health metrics) one-fat-jar (not a WAR file because it embeds jetty so it doesn't require a Java app server) Java REST web service framework that provides Basic authentication and OAuth (same server) authentication for your web services, but it doesn't provide 3rd-party OAuth authentication (e.g., logging in via your Facebook or Google+ ID). OAuth authentication requires that you write your own OAuthProvider which isn't documented very well in the manual (where it says "Because OAuth2 is not finalized, this implementation may change in the future"), though there is one limited functionality sample of doing it.

As an alternative, there is a DropWizard example that supports OpenID, but OpenID isn't as flexible as the OAuth APIs. OpenID primarily provides login/authentication. OAuth on the other hand, also provides authorization for more rich APIs (e.g., Facebook's Opengraph and Google G+, where you can access a users contacts, albums, post to feed, etc. which is just as important as authentication in applications today), and can provide login/authentication if you add the email scope to your OAuth request (unless you're using Twitter for your authentication in which case you can't get the user's email address so it can't be used as an authentication source effectively). To confuse matters more, Google also support OpenID, but if you're planning to use your backend for Android authentication, you'll have to use OAuth; you don't want to be migrating users after choosing OpenID by mistake like Player.FM did.

Quirks w/ Sencha Touch Hybrid App Development on BB10 w/ Sencha Architect

Ken K. Yee — Sun, 25 Aug 2013 00:00:00 -0400

I've always been curious about how well Sencha Touch works on mobile devices (I found jQuery Mobile to be sluggish when its swiping code was added to Bootstrap's carousel code), so when Blackberry announced a program to try Sencha Architect and a BB10 device, I signed up for it thinking it'd be easy to port one of my simple Android apps to it. It turns out quirks in Sencha Architect and the Blackberry packaging tools made it a lot more painful than it needed to be.

Building Android native clients for the Meteor.js framework

Ken K. Yee — Sat, 3 Aug 2013 00:00:00 -0400

Today's mobile developers generally fall into the responsive-css-hybrid or native app camps. On the one hand, the idea of a single web application that runs on the site and on mobile devices sounds great to the decision makers (and generally works for simpler apps). Unfortunately, if you want the best experience for your mobile users (you generally won't find out about issues in hybrid apps until you're mostly done with it), you may very well need a native application as Facebook found out when they kept trying to use HTML5.

In choosing a web platform for your application's web site and as an endpoint for your mobile applications, one of the checklist items inevitably includes whether it's possible to write a pure native client that will talk to your web stack because decision makers like having insurance. Meteor.js doesn't have the typical RESTful web service APIs that other web stacks have, though you can run another Node.js instance in parallel to do this with direct access to the database. To provide the reactivity and realtime data sync that is Meteor.js' real strength, you have to talk to the server via the DDP websocket protocol. For the two main mobile platforms (iOS and Android) as well as ASP.Net (including Windows Phones), this is now possible.