Note to Self: Getting Apache Kafka Up & Running for Local Testing

This is a quick note on starting a single-broker Kafka 2.0.1 instance (Scala 2.11) on macOS, using Terminal. This is the standalone version (no Homebrew).

Terminal window 1

$ cd /Users/yourUsrName/pathToKafka/kafka_2.11-2.0.1
$ sh bin/ config/

Terminal window 2

Optional: test zookeeper connection via telnet

$ telnet localhost 2181
$ stat

Move on to starting a Broker:

$ cd /Users/yourUsrName/pathToKafka/kafka_2.11-2.0.1
$ sh bin/ config/

Terminal window 3

Create a Topic:

$ cd /Users/yourUsrName/pathToKafka/kafka_2.11-2.0.1
$ sh bin/ --create --topic my_topic_2 --zookeeper localhost:2181 --replication-factor 1 --partitions 1

For quicker local testing, I left the –partitions and –replication-factor set to 1.

See log files directory created here:

$ cd /tmp/kafka-logs/my_topic-0

See list of available Topics:

$ cd /Users/yourUsrName/pathToKafka/kafka_2.11-2.0.1
$ sh bin/ --list --zookeeper localhost:2181

Start a Producer

$ sh bin/ --broker-list localhost:9092 --topic my_topic_2

Once you get a carrot prompt, try typing some messages:

> How is this thing doing? Is it on?  
> Anyone?

Terminal window 4

Start a Consumer.

$ cd /Users/yourUsrName/pathToKafka/kafka_2.11-2.0.1
$ sh bin/ --bootstrap-server localhost:9092 --topic my_topic_2 --from-beginning

Once the Consumer’s running without errors, you should see the messages you sent via the Producer window showing up.

Notes on Cisco’s Meraki Systems Manager as an MDM Solution

A few of the devs on my team recently got a chance to try out the free version of Meraki’s Systems Manager. In this case, I’m using MDM as an acronym for Mobile Device Management. We used the system on and off for most of 2015 to distribute some apps published using an enterprise provisioning profile for iOS.

Use cases

Our usual scenario involved a series of iPads, often 10 – 30 of them. They would be sent out to an event space on a convention floor, a mall booth, an outdoor event space (like Six Flags). Sometimes the devices would be used for user registration, running on a local network inside a stadium. One project involved a bunch set up outside a traveling food truck, that drove from town to town. A few projects required sweeps registration or mailing list sign up of some sort. One large project involved multiple Elo Touch Screens that ran Windows Pro and traveled between mostly outdoor events. Since most of our events involved using Meraki with a series of iPads, I’ll use the .ipa app upload process as the example going forward.

Overall impression

Overall, if your app is under 30MB in file size, Meraki is a great solution. Just set up your account, go to

  • Systems Manager > MDM > Apps
  • select “Add New” in the upper right corner of the page and “iOS enterprise app” from the dropdown.
  • Under Location, choose “Upload an ipa” from the dropdown and follow the given options, as needed. Click Save Changes and you’re set.
  • Add devices (Systems manager > MDM > add devices) and use tags to automatically install your app on the appropriate device
  • Once the app’s live and installed, you can update using the same App page (Systems Manager > MDM > Apps, click your app name)

Some issues we came up against

  • The Meraki dashboard doesn’t seem to allow you to search “Clients” (Systems manager > Monitor > Clients, what the system calls the devices you’ve registered) by convenient terms like serial number or device name. Sometimes I have a lot of devices with a given tag and I need to make sure a specific device is in that list. Being able to search by device serial number would save me time.
  • Enterprise apps larger than 30MB in size are often problematic to update. It often took multiple attempts over a few days to get the update to work, even after on-site connectivity was good for other purposes, such as playing back a streaming video off of sites like
  • On-site firewall at YMCA branches (using YMCA WiFi) were blocking remote app updates.
  • Spotty venue WiFi (read: convention floor WiFi) and sometimes spotty MiFi connections are an issue if your app requires an update or needs to send more than just text data. App updates for apps bigger than a few MB, required taking the device to another location with strong, consistent WiFi.
  • When you’re stuck on an issue, such as an app just won’t install, no matter what you do, there’s not much google-able info out there. Stackoverflow is very helpful to keep you moving, past bugs and roadblocks, but not with the free version of Meraki’s System’s Manager. We haven’t yet had the need to contact Meraki support (given our previous experience with trying to reach out to support with free products, we pursued the issues on our own, so far successfully).

Some conclusions

I’d highly recommend Meraki for smaller sized apps, especially ones that are not likely to require an app update during your short term event’s duration. For longer term installations, larger apps, be prepared to budget for and plan for on-site travel for one of your developers, technologists or IT guys to help with initial installs or especially problematic app updates.

This has less to do with MDM, and more with network connectivity, but your MDM will largely depend on how good your connection is. Seriously consider / advise your client to purchase a data plan for the device, rather than relying on WiFi alone. Find out ahead of time, which mobile service has a reputation for working best in your target location. Don’t use Verizon, if AT&T is generally known to have better service in your event’s target area. If your devices are PCs, by all means, run hard lines (Ethernet) and bypass wireless issues all together. Just keep in mind, the longer those Ethernet cables, the lower the signal tends to be.

Unity3D for iOS: Setting Up a New Project and Deploying for QA with TestFlight

NOTE: This post is definitely in the Notes to Self category. Not sure how useful this may be to anyone I’m not directly working with.

Apple Developer Center

There are plenty of free tutorials on how to do this but here’re the steps:

1. [First time only] Set up Apple Developer Account & Create your personal Certificate in .p12 format.
2. Create an App ID
3. add Device IDs if needed
4. Create Dev Provisioning Profile & download it to your machine.

Set Up Unity Project for iOS

  1. Create a New Project & go to File > Build Settings > Player Settings
  2. Fill in Company Name & Product Name (the app name you picked in Apple Dev Center when setting up the App ID).
  3. In Player Settings, under Per-Platform Settings in Other Settings set Bundle Identifier* to the App ID you created in the Apple Developer Center (something like “com.yourcompany.yourAppName”)
  4. Other Player Settings seem fairly self-explanatory if you’ve done iOS dev before

Import Your Assets, Copy/Paste Items

  1. Imported your team mate’s game scene(s) from their latest .unitypackage.
  2. Imported MainMenu & endGame scenes, import level1 and level2 for reference from Cubesteroids3 (or latest).
  3. Add any GameManager or GameSettings objects & their related scripts to the Hierarchy in the imported scene.
  4. Add UIToolkit’s UI object to imported scene. Notice, it’s UILayer setting in Inspector will probably be unset. If you don’t feel like updating this every time – turn UI and it’s children into a Prefab, which will retain layer settings for you.
  5. If a Layer named UIToolkit doesn’t exist – name User Layer 10 (or one of your choice) “UIToolkit”. Click on UI in the Hierarchy, in the Inspector the UILayer setting should now be set to UIToolkit.
  6. Select “UIToolkit – text” in Hierarchy, in the Inspector the Layer should be set to UIToolkit. If not, manually set the Layer to “UIToolkit” in the Inspector.
  7. Merge ui / gui code from the old [GameManager class called] ThrowRigidBody.js to the new ThrowRigidBody.js. Without a “Team License” from Unity Technologies, this is a manual, line-by-line process unfortunately.

Prior to Build & Run

  1. Download your Dev Provisioning Profile
  2. If it’s an official release, make sure you’ve switched the Dev Provisioning profile from a test one to one using your Team’s Apple account
  3. Open Xcode. Do Window > Organizer.
  4. Drag your Dev Provisioning Profile into your list of profiles in Organizer. Connect your Device – you might need to drag a copy of the Profile to your device’s Provisioning Profiles tab in Organizer
  5. Hit Build & Run in Unity… should work.

To Distribute Wirelessly via TestFlight

  1. Set up an account at, if you don’t already have one OR ask to be added as a Developer to an existing Team account.
  2. Open the Xcode project generated by Unity when you Build & Run
  3. Create an Archive in Xcode. When the Archive is read, click the SHARE button in the upper right corner of the IDE. Choose the appropriate Dev Provisioning Profile (there can be several in the list if this isn’t your first iOS project). Choose where to save the .ipa. If this part is confusing – a quick Google search will help w/ sources like Stackoverflow.
  4. Drag the .ipa into’s Upload page.
  5. Follow TestFlight’s link to Invite Testers. NOTE: After new testers register their devices you might have to add them to your Dev Provisioning Profile via Apple’s Dev Center, recompile your app w/ the new profile & reupload your .ipa. Not sure if TestFlight has found a faster workaround to this.

To Quickly Allow a New TestFlight User to Install Your Build

  1. Send them a Tester invite via TestFlight. After they register their device, grab the Device ID.
  2. Add Device ID to your/your team’s Apple Developer Account
  3. Add the newly added Device to a Dev Provisioning Profile for your App ID
  4. Download your new/updated Dev Provisioning Profile to your machine
  5. On go to Builds > Your Latest Build, choose Permissions in the left nav.
  6. Click on the UPDATE PROFILE button under Update Provisioning Profile to upload the new Dev Provisioning Profile that includes the new Tester’s device ID. This step allows you to skip re-compiling your app just to add dev install permissions for a new device.
  7. Notify your new Tester.