AnDevCon 2017 – How Yahoo Finance Scales on Android – Vikram Bodicherla

I saw Vikram‘s talk at Droidcon NYC 2016 talk about app performance, and wanted to make sure I made it to his talk.  He talks about overall processes for a successful development team along with tools and tips for shipping apps.

Developers shouldn’t be afraid to dip your toes into “product”.
Contribute to feature definition to make your voice heard as a user and for technical implementation.

Understanding your users – Fantasy Football Example:
You should be aware of who is using your app. You might think everyone using a fantasy football app are very serious users, but we find that 12% randomly pick, and 60% are first year users. Try to find patterns between different types of users of your app. Build personas of your users. Building personas of your users is a way to explain behavior that would be hard to explain otherwise. Give these personas name and put them up on the wall in your office. Know who your users are and design for them.

Personas for fantasy football includes:

  • Seasoned pros
  • People that are forced to join by their friends
  • People that are serious, but learning
  • “average” users

Data Driven Decisions via Experiments:
DAUs and Downloads are really “Vanity Metrics”, since they don’t gain a ton of insight. Data driven insights are real; not opinions. Wrong decisions can be validated quickly, so feel empowered to test, measure, and grow. Instead of doing costly user research, you can push something to a small group of users, and gain data there vs. expensive user research.

Each experiment should have:

  • A hypothesis
  • An owner
  • A deadline for the end of the experiment.
  • Planned removal of the code from your app. You learned something from it, now “Let it go!!!”

Scrum
Planning is a good investment. You can see how long things will take, determine dependencies, and people can show interest in pieces of the work.  Agile is important because it’s not adverse to change like Waterfall is.

Types of stories in Scrum:

  • User story
  • Engineering story

Scrum story checklist:

  • Clear definition
  • Acceptance criteria
  • Edge cases and error scenarios
  • Analytics
  • Animations and design

Grooming

  • should be (1x/week for 1 hour)
  • It helps the team to understand stories -> Determine level of effort for stories (Points)
  • Stories should have reasonable detail. Be very critical and make sure the story is well defined.
  • Don’t get hung up on one story. If your getting hung up, move on and take that offline so you don’t waste your entire grooming on one thing.
  • NEVER write stories during Grooming.
  • NEVER point a story that doesn’t have all the details.

If you get roll-over and carry-over after a sprint consistently, you’re doing something wrong and should revisit your processes.

Daily stand-ups should be no greater than 10 minutes and should provide high level updates. Low level updates should be taken “offline”, or “parking lotted”.

At the end of the sprint, you can hold a retrospective and demo completed stories.  Please prepare up front for this so we don’t have to wait for you to launch the emulator or recompile your project.

“If you’re are not practicing scrum in sprit, you are better off not doing it.”

Continuous Delivery

  • Minimizing the time between “code complete” and “deployable”
  • deployable != deploy
  • This can only be achieved with continuous integration (CI)
  • If you do deploy immediately to your users, you get immediate feedback, but not always the best for your users. Vikram recommend every 2 weeks on average, but depends.
  • Have internal alpha and beta programs for internal users to try the app before it goes to production.

Pull Request (PR) Tools

  • facebook/mention-bot – Can tag reviewers based on “git blame” history
  • SonarCube
  • https://codecov.io for Code Coverage
  • Danger -> Keep PRs <500 lines, PR message should be >25 chars.
  • Emulator in an iframe, running the code in the PR.  -> https://appetize.io Removes need to compile and install.

APK storage and deployment:

Culture

  • How you act/think/interact. Keep high standards, because you are what your lowest standard is.
  • Ownership is important. Communicate deviations and compromises so it’s not lost. Proactively check app quality issues and triage as soon as you can.
  • Set goals, but aim for 70%. If you get 100%, then your goals are not high enough.

Meeting etiquite

  • Everyone needs to have value, or they shouldn’t be there
  • Reject meetings if they are not needed
  • Meeting owner should have adgenda, goals and come out with action items.
  • There should be a hard start and end type.

Code is a liability. Once it’s out there, you have to support it. Changing code is expensive.  Deleting code is a good thing.

Feature Flags – Client-side feature flags are important, along with remote feature flags.  Client-side flags should take priority, but if it’s on, then use the remote flag.

AnDevCon 2017 – A Room With a ViewModel – Mark Murphy (CommonsWare)

Word of the day: “Transmogrify”
“to transform, especially in a surprising or magical manner.”

Mark draws a great comparison between Room and Retrofit as they both use annotation processing, and describe either a URL path, or a DB query.  The @Query annotation in Room, is similar to the path in Retrofit that is provided to @GET, @POST, etc.

Parameters can be sent with the syntax :postalCodes.  You can pass parameters into a query this way:

@Query(“SELECT * FROM Customer WHERE postalCode IN (:postalCodes)”)
List<Customer> findCustomersInPostalCodes(String… postalCodes)

Cool DB Testing Tip for Android Instrumentation Tests: In-memory databases work the same way that SQLite databases do that are saved to the disk. In-memory database are great for instrumentation tests because they are fast, and when you are done with it, it’s gone from memory, and doesn’t persist to disk.  It’s not recommended to use in-memory databases in true client apps however.

Types used in Room need a @TypeConverter.  You can specify the type converters to be used in the following way:

@TypeConverters({TypeConverter.class})

Caveats about relations:
You can use @ForeignKey on a child, but… <OMG head explosion />.  Foreign keys are there, but there aren’t any magical methods generated to retrieve a child. You can just get an ID for the child, and then have to re-query for that. You can specify cascading deletes however which is useful.

Room Migrations – Create instances of Migration –  A little more sane than just plain SQLite.

Note about SQLCipher – It was last updated in 2009, and the APIs are really hard (if not impossible) to integrate with Room.

LiveData – Room works really well with Rx programming. 🙂

Predictions: We will go through a lot of iterations of the APIs as kinks are worked out and things stabilized.  The guess is that a final version would be available around Google I/O 2018.

Check out Mark Murphy on the internet:

AnDevCon 2017 – An Introduction to RxJava – Matt Dupree

Here are some notes I took from Matt Dupree’s talk.  It was a really great intro to Rx, and done in a different way than most Rx talks I’ve seen.  He creates mental building blocks to get us from the Java Array to the Rx Observable.

“We are missing an abstraction”
Array -> Iterable -> Sequence -> Observable

Goal of this talk: Escape from “Callback Hell” (Too many nested callbacks, and Observables are here to help).

In Java, the “Iterable” interface allow us to abstract away from an Array, hiding us from the underlying implementation like LinkedList, HashSet, etc.  We just care that we are going through the items when we have an Iterable, and don’t really car how it’s done.

A button clicks example used:
* If you knew all your button clicks up front, you’d just do a “for” loop
* Instead you have an onClickListener since you don’t know when it’ll happen
* You instead subscribe to an observable stream (which looks like a loop), and for each observable event, you perform the action.

Interesting point: With an observable, data is not in memory necessarily, but you write code like it is.  This is another layer of abstraction that is helpful in doing delcarative programing instead of imperative programming.

Declarative Programming
This is “WHAT” I want to happen.

vs.

Imperative Programming
This is “HOW” I want it to happen.

Cool tip about “Debouncing”: I hadn’t heard of this before, but he shows another use case regarding a search text box, and he showed how EASY it was to use debouncing.  Debouncing can help you wait for the stream to settle, and in this case you can wait 300ms after the last event. You can just say wait until the observable hasn’t been called in XXX milliseconds, and if that’s the case, then continue on.

Resources:

Note: “Rx” means Reactive Extensions. (I, personally hear the term “Rx” so much, that I forget that it means something else sometimes)

Troubleshooting Auto Verification of Seamless Android App Deep Linking

You’ve read all of the Android documentation on how to add seamless deep-links into your app, but it still isn’t working, and you’re seeing the app-chooser dialog.

 

Here are a few things that helped me with troubleshooting, and hopefully they’ll help you as well.

Checklist for troubleshooting “autoVerify”:

  1. Have you use App Links Assistant in Android Studio?  There are tons of new features here to help you debug issues.
  2. Did you add an intent filter for your DeepLinkActivity with autoVerify=”true” to your manifest?
    <activity
        android:name=".deeplink.DeepLinkActivity"
        android:theme="@android:style/Theme.NoDisplay">
        <intent-filter android:autoVerify="true">
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" android:host="mycompany.com" />
        </intent-filter>
    </activity>
  3. Is there an assetlinks.json file publicly accessible (the real internet, not just your corporate VPN) in the correct place like…
    https://HOST/.well-known/assetlinks.json

    for EVERY single one of the HOSTs listed in your manifest intent-filters?  Unless every, single one of them is valid, not even links to valid hosts will work.

  4. Is your the sha256 hash of your DEBUG and RELEASE keystores both in your assetlinks.json file?  It doesn’t hurt to include both signatures.
    keytool -list -v -keystore my-keystore.keystore
  5. Have you monitored the Logcat filtered for SingleHostAsyncVerifier and IntentFilterIntentSvc?  They print out logs after an adb install that tell you the status of auto-verification. Filter for IntentFilterIntentSvc, and if you see “Success:true”, then you’re good!  See more details here.
    I IntentFilterIntentSvc: Verification 6 complete. Success:true. Failed hosts:.

 

Best of luck, hopefully this helps a little!

Related Helpful Blog Posts:

How do I write static methods in Kotlin?

When I was starting to write Kotlin code, and one problem I faced was how the heck do I do static methods like I can add in Java?

The solution… The companion object in your Kotlin class.

class MyClass() {
  companion object {
    fun myStaticMethod() {
      //Do Stuff Here
    }
  }
}

Accessing this static method via Kotlin:

MyClass.myStaticMethod()

Accessing this static method via Java:

MyClass.Companion.myStaticMethod()

To avoid having to use the “.Companion” syntax, use the @JvmStatic annotation, allowing you to access the method without “.Companion”:

class MyClass() {
  companion object {
    @JvmStatic
    fun myStaticMethod() {
      //Do Stuff Here
    }
  }
}

Accessing this static method via Java and @JvmStatic:

MyClass.myStaticMethod()

Identifying an Android Device – Available Identifiers

Here are various IDs can be obtained programmatically on Android that can be used to identify a device or installation. I’ve tried to provide a little bit of information about each one and what permissions are required to obtain it.

Identifier Example Value Permission Required
Android ID via Settings.Secure 2fc4b5912826ad1 NONE
Android Build.SERIAL HT6C90202028 NONE
Android Build.MODEL Pixel XL NONE
Android Build.BRAND google NONE
Android Build.MANUFACTURER Google NONE
Android Build.DEVICE marlin NONE
Android Build.PRODUCT marlin NONE
IMEI 352698276144152 READ_PHONE_STATE
Phone Number 2028675309 READ_PHONE_STATE or READ_SMS
ICCID (Sim Serial Number) 311477629513071 READ_PHONE_STATE

Android ID via Settings.Secure

This is a 64-bit quantity that is generated and stored when the device first boots. It is reset when the device is wiped.  It is unique device-wide per OS install, but only unique per application starting with Android O (with old applications grandfathered in).

String androidId = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);

Android Build.SERIAL

Since Android 2.3 (“Gingerbread”) this is available via android.os.Build.SERIAL. Devices without telephony are required to report a unique device ID here; some phones may do so also.

A hardware serial number, if available. Alphanumeric only, case-insensitive.

String serial = android.os.Build.SERIAL;

Android Build.MODEL

The end-user-visible name for the end product.

String model = android.os.Build.MODEL;

Android Build.BRAND

The consumer-visible brand with which the product/hardware will be associated, if any.

String brand = android.os.Build.BRAND;

Android Build.MANUFACTURER

The manufacturer of the product/hardware.

String manufacturer = android.os.Build.MANUFACTURER;

Android Build.DEVICE

The name of the industrial design.

String device = android.os.Build.DEVICE;

Android Build.PRODUCT

The name of the overall product.

String product = android.os.Build.PRODUCT;

IMEI (International Mobile Equipment Identity)

Returns the unique device ID, for example, the IMEI for GSM and the MEID or ESN for CDMA phones. Return null if device ID is not available.

String imei = ((TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE)).getDeviceId();

Phone Number

Returns the phone number string for line 1, for example, the MSISDN or a GSM phone. Return null if it is unavailable.

String phoneNumber = ((TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE)).getLine1Number();

ICCID (Sim Serial Number)

Returns the serial number of the SIM, if applicable. Return null if it is unavailable.

String iccid = ((TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE)).getSubscriberId();

Related Links:

Android Zombie Processes – Is My App Still Alive?

To the eye, it may seem like your Android application is “dead” when you “kill” the app via the task manager, but you may be surprised that in many cases, the application process lives on.

Here are some ADB commands that you can diagnose and investigate what’s going on, on the device.

Determine Running Processes via ADB

All Processes

adb shell ps

Your Process

adb shell ps | grep com.mydomain.myappnamegoeshere

An Android Service registered to your application will prevent your process from being killed if it is currently running.  Therefore you need to be careful and aware that your singleton variables in your application are aware of this.  Read more about this here: Processes and Application Life Cycle.

void onTaskRemoved (Intent rootIntent)

You can leverage the Service::onTaskRemoved() method in Android to catch this “swipe” event where the user intends to “kill” your app via the task manager, even if services continue to run in the background.  This can be useful to catch this event if you want to end a user session for instance.  This can also be useful if your intention is to stop services when the user dismisses your app, as you can programatically stop the service at this point in time as well.

Note: If you have set ServiceInfo.FLAG_STOP_WITH_TASK when starting the Service, then you will not receive this callback; instead, the service will simply be stopped.

Security Tip: Protecting Session Sensitive Responses with Retrofit 2 and okhttp 3

Problem Statement:

A user could receive and view data that is not theirs, and we must prevent this from happening in a secure application.  Here is a diagram of how this could happen:

Flow Diagram of the Session Mismatch Issue

 

Implementation options with Retrofit 2 and okhttp 3:

Option 1:

Write a custom Retrofit 2 CallAdapter that blocks the response from being processed or passes an exception to the onFailure() method.

  • PROS:
    • Great if you use Retrofit 2 exclusively for session sensitive calls.
    • This can prevent the callback from being invoked, or you could call Retrofit 2’s onFailure() method.
  • CONS:
    • Retrofit 2 CallAdapter is complex and you have to write one for both plain Callbacks as well as for RxJava (if you are using both).
    • We’d have to copy the existing CallAdapter implementation in retrofit2.ExecutorCallAdapterFactory and modify it as it’s a final class.
    • This only works for Retrofit 2 calls, but not all networking calls made through okhttp 3.

Option 2:

When the client session is invalidated, use okhttp 3’s Dispatcher to cancel all running and queued calls.

  • PROS:
    • Very effective. All calls would immediately be cancelled.
  • CONS:
    • If there is a call like “Update Profile” that is still occurring, it would be cancelled, which is not desirable.
    • If there is an unauthenticated call happening, you’d have to ensure that was being executed on non session sensitive Retrofit 2 or okhttp 3 instance to avoid unwanted termination.

Option 3:

Same as the previous option, but instead occurs when a new client session is started, instead of when an old one ends.

  • PROS:
    • Very effective. All calls would immediately be cancelled.
  • CONS:
    • You would have to ensure this code got run before you kicked off any session sensitive calls, otherwise they would be immediately cancelled.
    • If there is an unauthenticated call happening in the background, you’d have to ensure that was being executed on non session sensitive Retrofit 2 or okhttp 3 instance to avoid unwanted termination.

Option 4:

Using an okhttp 3 Network Interceptor to return back an HTTP Response with a custom response code like 999 and removing the response body.

  • PROS:
    • Will work for:
      • All okhttp 3 calls.
      • Retrofit 2 Callback calls.
      • Retrofit 2 RxJava calls.
  • CONS:
    • It will appear like the HTTP response came back from the server so you will have to have custom logic in your response handler to check and see if this response has a HTTP status code of 999.
    • It feels a little “hacky”… but would prevent the security hole.

Option 5: (My Choice)

Using an okhttp 3 Network Interceptor to throw a custom SessionMismatchException when this problem is detected, and handle the Exception appropriately.

  • PROS:
    • Will work for:
      • All okhttp 3 calls
      • Retrofit 2 Callback Calls
      • Retrofit 2 RxJava Calls
    • This is truly an “Exception” scenario, so this makes sense.
    • The request is executed fully, but will not be received by the client. (This could be a “con” depending on your use case)
  • CONS:
    • You must code your onFailure and onError handlers to appropriately handle this SessionMismatchException type.
    • If you just extend IOException, okhttp 3 will by default retry the HTTP call.  However, if you extend java.net.SocketTimeoutException, okhttp 3 will not retry.

My Choice: Option 5, throwing a custom SessionMismatchException.  This seemed to be the most flexible and intuitive since this truly is an Exception/Failure case.  I’ve provided a sample implementation of this below.

Assumption: You have a  “SessionManager” in your Android code which is aware of the current session.

Let me know if this was helpful, or if you’d do something different on Twitter at @HandstandSam

Controlling the Android Emulator and Virtual Devices (AVDs) via the command-line

I Googled all around to try and figure out how to tweak Android Emulator virtual devices (AVDs) via the command-line.  The Android Emulator documentation online has some options for running the emulator, but it didn’t allow me to specify memory at runtime, and many other things I wanted to customize.  There is also documentation specific to the creation of AVDs (vs just the running of them on the emulator), but that kept referring to the UI tools for it. I’ve gotten so used to Googling for help, that I didn’t think of running help locally :-p

emulator -help

That gives us a LOT of options that are not documented on the website including.

Android Emulator usage: emulator [options] [-qemu args]
  options:
    -list-avds                     list available AVDs
    -sysdir <dir>                  search for system disk images in <dir>
    -system <file>                 read initial system image from <file>
    -writable-system               make system image writable after 'adb remount'
    -datadir <dir>                 write user data into <dir>
    -kernel <file>                 use specific emulated kernel
    -ramdisk <file>                ramdisk image (default <system>/ramdisk.img
    -image <file>                  obsolete, use -system <file> instead
    -initdata <file>               same as '-init-data <file>'
    -data <file>                   data image (default <datadir>/userdata-qemu.img
    -partition-size <size>         system/data partition size in MBs
    -cache <file>                  cache partition image (default is temporary file)
    -cache-size <size>             cache partition size in MBs
    -no-cache                      disable the cache partition
    -nocache                       same as -no-cache
    -sdcard <file>                 SD card image (default <system>/sdcard.img
    -snapstorage <file>            file that contains all state snapshots (default <datadir>/snapshots.img)
    -no-snapstorage                do not mount a snapshot storage file (this disables all snapshot functionality)
    -snapshot <name>               name of snapshot within storage file for auto-start and auto-save (default 'default-boot')
    -no-snapshot                   perform a full boot and do not do not auto-save, but qemu vmload and vmsave operate on snapstorage
    -no-snapshot-save              do not auto-save to snapshot on exit: abandon changed state
    -no-snapshot-load              do not auto-start from snapshot: perform a full boot
    -snapshot-list                 show a list of available snapshots
    -no-snapshot-update-time       do not do try to correct snapshot time on restore
    -wipe-data                     reset the user data image (copy it from initdata)
    -avd <name>                    use a specific android virtual device
    -skindir <dir>                 search skins in <dir> (default <system>/skins)
    -skin <name>                   select a given skin
    -no-skin                       don't use any emulator skin
    -noskin                        same as -no-skin
    -dynamic-skin                  dynamically construct a skin of given size, requires -skin WxH option
    -memory <size>                 physical RAM size in MBs
    -accel <mode>                  Configure emulation acceleration
    -no-accel                      Same as '-accel off'
    -ranchu                        Use new emulator backend instead of the classic one
    -engine <engine>               Select engine. auto|classic|qemu2
    -netspeed <speed>              maximum network download/upload speeds
    -netdelay <delay>              network latency emulation
    -netfast                       disable network shaping
    -code-profile <name>           enable code profiling
    -show-kernel                   display kernel messages
    -shell                         enable root shell on current terminal
    -no-jni                        disable JNI checks in the Dalvik runtime
    -nojni                         same as -no-jni
    -logcat <tags>                 enable logcat output with given tags
    -no-audio                      disable audio support
    -noaudio                       same as -no-audio
    -audio <backend>               use specific audio backend
    -raw-keys                      disable Unicode keyboard reverse-mapping
    -radio <device>                redirect radio modem interface to character device
    -port <port>                   TCP port that will be used for the console
    -ports <consoleport>,<adbport> TCP ports used for the console and adb bridge
    -onion <image>                 use overlay PNG image over screen
    -onion-alpha <%age>            specify onion-skin translucency
    -onion-rotation 0|1|2|3        specify onion-skin rotation
    -dpi-device <dpi>              specify device's resolution in dpi (default 165)
    -scale <scale>                 scale emulator window (deprecated)
    -http-proxy <proxy>            make TCP connections through a HTTP/HTTPS proxy
    -timezone <timezone>           use this timezone instead of the host's default
    -dns-server <servers>          use this DNS server(s) in the emulated system
    -cpu-delay <cpudelay>          throttle CPU emulation
    -no-boot-anim                  disable animation for faster boot
    -no-window                     disable graphical window display
    -version                       display emulator version number
    -report-console <socket>       report console port to remote socket
    -gps <device>                  redirect NMEA GPS to character device
    -keyset <name>                 specify keyset file name
    -shell-serial <device>         specific character device for root shell
    -tcpdump <file>                capture network packets to file
    -bootchart <timeout>           enable bootcharting
    -charmap <file>                use specific key character map
    -prop <name>=<value>           set system property on boot
    -shared-net-id <number>        join the shared network, using IP address 10.1.2.<number>
    -nand-limits <nlimits>         enforce NAND/Flash read/write thresholds
    -gpu <mode>                    set hardware OpenGLES emulation mode
    -camera-back <mode>            set emulation mode for a camera facing back
    -camera-front <mode>           set emulation mode for a camera facing front
    -webcam-list                   lists web cameras available for emulation
    -screen <mode>                 set emulated screen mode
    -force-32bit                   always use 32-bit emulator
    -selinux <disabled|permissive> Set SELinux to either disabled or permissive mode

     -qemu args...                 pass arguments to qemu
     -qemu -h                      display qemu help

     -verbose                      same as '-debug-init'
     -debug <tags>                 enable/disable debug messages
     -debug-<tag>                  enable specific debug messages
     -debug-no-<tag>               disable specific debug messages

     -help                         print this help
     -help-<option>                print option-specific help

     -help-disk-images             about disk images
     -help-keys                    supported key bindings
     -help-debug-tags              debug tags for -debug <tags>
     -help-char-devices            character <device> specification
     -help-environment             environment variables
     -help-keyset-file             key bindings configuration file
     -help-virtual-device          virtual device management
     -help-sdk-images              about disk images when using the SDK
     -help-build-images            about disk images when building Android
     -help-all                     prints all help content

I hope you found this from YOUR Google search about this, and it helped 🙂

Running Multiple Android Emulators Simultaneously on OSX

I had a long standing issue where I could only launch two emulators on my Macbook Pro simultaneously.  Any other emulators would launch and get a black screen and wouldn’t load.  I accepted this as fact, and carried on with life.

screen-shot-2016-09-07-at-7-11-45-pm

Finally today I found the need to figure out “why” this was the case as I wanted to start sharding my Android UI tests to speed them up.  I was given the suggestion that it could be the # of CPUs or the amount of RAM.  If you look in the logs you may see something like this (if you launch the emulator from android avd):

screen-shot-2016-09-07-at-7-15-46-pm

or you may see:

“HAXM does not have enough memory remaining to load this AVD.”

In order to change your memory allocation for HAXM, you need to re-install it, so run the installer again which is a DMG at: [$ANDROID_HOME/sdk/extras/intel/Hardware_Accelerated_Execution_Manager/ ] and this time select more memory. [HAXM Technical Docs]screen-shot-2016-09-07-at-8-27-05-pm

But… before you install, make sure you have the latest version. The latest version as of September 7th, 2016 is 6.0.3 (Which was released on June 21, 2016).
screen-shot-2016-09-07-at-7-33-01-pm

On my Macbook, I was given 2048MB of memory by default which allowed me to run 2 emulators simultaneously (as seen above).screen-shot-2016-09-07-at-6-58-46-pm

I have 16GB total memory though, so lets make it so I can run a bunch of emulators at once by allocating 8GB 🙂
8192
confirm

Here is my Macbook Pro running 6 Android emulators simultaneously after the changes:
screen-shot-2016-09-07-at-8-17-17-pm

Success!!!  May the sharding begin!

Related Links: