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.

Apache Kafka Producer Error “zookeeper is not a recognized option”

As I’m brushing up on Apache Kafka_2.11_2.0.1 (Scala 11, Kafka 2.0.1) on macOS Mojave, I ran into this minor hick up while trying to spin up a command line Producer:

$ sh bin/ --zookeeper localhost:2181 --topic my_topic --from-beginning
zookeeper is not a recognized option

Turns out they changed that option name from “–zookeeper localhost:2181” to “–bootstrap-server localhost:9092. The new command looks like so:

$sh bin/ --bootstrap-server localhost:9092 --topic my_topic --from-beginning
Your message shows up here

Cross Domain Error on Localhost on Any Error in Google Apps Script

I noticed an odd-feeling error while playing with a frontend AJAX call from a localhost server that fetched data from a Google Sheet via a Google Apps Script middleware script.

Any time there was any kind of error in the Google Apps Script code. The JSON-P-based front end call was receiving this message (using the Chrome dev tools Console):

Cross-Origin Read Blocking (CORB) blocked cross-origin response with MIME type text/html. See for more details.</code>

Technically, of course, it was a showing up as a CORS (Cross Domain Resource Sharing) or CORB (Cross Domain Read Blocking) error.

I bet the Google Apps Script error message automatically sends data back as HTML/Text and this is messing with the JSON-P callback, which is expecting the data type to be “javascript”.

Visiting VR Zone Shinjuku in Tokyo

I had a chance to visit in April, 2018 and loved my overall experience.

It was like Ghost In The Shell themed VR laser tag.

Japan. It’s been on my list of place to visit for years. Decades at this point. I finally got to this Spring. On this trip, I got to experience a Live Events tech space that I’ve only previously seen and worked with in the context of pop up shop style one offs for concerts, sports tournaments.

The Concept

If you’re in the US and you’ve heard of The Void. Perhaps, you’ve been there. I’m about to go check that out next week. VR Zone Shinjuku is a similar VR theme park. I got to play a 3 on 3 game of VR laser tag as a Ghost In The Shel themed operative whose mission is to take out “the terrorists” (the opposing team of 3 in our case).

The Tech

The staff at VR Zone Shinjuku were naturally fairly tightlipped about specifics of how everything works behind the scenes. No photos were allowed inside, past the entrance.

However, they headset was HTC Vive, coupled with what looked like custom VR tracker shin guards, a gauntlet and body sensor belt that allowed for full range of motion wireless tracking. The ceiling had a ton of what looked like infrared sensors, pointed in every possible direction.

Each player had an MSI VR ONE Backpack PC strapped to their back.

The Vive headset had custom wireless trackers mounted on top of it as well.

The Staff

These guys were very professional and on top of their game. I was very impressed. The team was highly knowledgeable on the complex gear up procedure and it seemed like everyone spoke at least 3 languages (Japanese, Mandarin and English). I deal with Brand Ambassadors at live events on a regular basis – the VR Zone Shinjuku staff were in my top 3 crews of all time.

Digital Signage Touchscreen Displays with a Mac Mini?

Use Case

First of all, why would you want to? Digital Signage isn’t always just a video playing in a loop, which can run off a built-in media player (like on a Samsung DM55E screen with MagicInfo S3 Digital Signage Software) or a BrightSign player with it’s overly convoluted content management system. Sometimes you have an HTML5 application that can run in Google Chrome as a full screen app, other times you have a complex Unity3D desktop app that also needs to run off more of a serious machine than a typical media player.

You’re certainly better off with a PC in this situation. Intel’s NUC and others now even allow the small form factor that Mac Mini used to rule.

Mac Minis weren’t originally designed for touchscreen displays, but what if you’re stuck with venue or client that has already purchased a Mac Mini and now you have to use that equipment because the budget’s been spent?

One option that works

Assuming there’s budget and you have some leeway in choice of touchscreens, rent an ELO touchscreen. Something like the 4202L 42″ Interactive Digital Signage. ELO does provide drivers for Mac that work with single touch (at least).

Note: ELO’s site provides drivers for lower versions of Mac OS / OS X and says “MAC OS X (10.12): Contact Tech Support for Max OSX 10.12”. Unofficially, their latest driver at the time – UPDD_05_01_1482.dmg – worked for me on Mac OS 10.12. Their tech support never got back to me, so keep that in mind.

DC Metro API – Show Real-Time Train Arrivals with Javascript

I’ve worked with Twitter, Instagram and Facebook APIs. Those are always a bundle of unpredictable joy/not, as APIs usually are. The WMATA (DC Metro) API is fairly easy to work with by comparison. They don’t have to worry about anyone’s personally identifiable information (PII), hence, less headaches for developers. They provide an adequate level of documentation and are reasonably responsive over email. All issues I had while working with this code were easy enough to resolve, using the ol’ Googley machine and common sense. A business lead I worked with was extra enthusiastic about the project, so he did email the API developers a few times and they responded on the same day.

The rate limit is 10 calls/second and 50,000 calls per day, which should work just fine for most uses. I’d pay extra attention here if you have multiple versions of the code during development (using the live end point) or, if you have a live version out and are working on changes, while using the live API (which is sometimes unavoidable, since there’s no dev end point).

In general, if you call it 3 times a minute or every 20 seconds, as the WMATA’s own real time arrivals web app does, you’ll be more than ok. Here’s a screenshot:

You can see their list of real time arrival stations here. It works rather well and uses their Real-Time Rail Predictions API, but one thing I’d certainly do differently – it’s literally reloading the whole page every 20 seconds to update the data. I’m guessing a backend developer put this together real quick, while working under several deadlines. A simple AJAX call can fix this (there are multitudes of examples of this on StackOverflow alone).

Note: if their app/API feed is down, their real time arrivals link just shows a mostly blank page:

Again, I’m guessing this was done in a hurry.