Not Hotdog

Hazelcast Jet demonstration of Realtime Image Recognition

A lot has happened since Jet’s debut last year. For instance Emin Demirci and many others have assembled some fun and interesting demonstration applications for Hazelcast Jet. Today we will walk through a simple Jet demo that shows how to implement a custom streaming source and sink and how to make streaming aggregations in Hazelast Jet.

You will need the following tools installed:

First clone the hazelcast-jet-demos repo:

Screen Shot 2018-06-21 at 9.28.09 AM

Now that you have the sources we can compile the realtime-image-recognition project:

Screen Shot 2018-06-21 at 9.30.47 AM

And now we simply execute the java task:

Screen Shot 2018-06-21 at 9.31.16 AM

You will get two windows one that is a live feed from your web camera and the other is the Results window. So if you point your camera to a solid surface, contrasting color, you can then place an object in front of the camera to see the resulting confidence score.

An example of a horse with a 10.70 score:

Screen Shot 2018-06-21 at 9.37.41 AM

An example of a deer with a 10.91 score:

Screen Shot 2018-06-21 at 9.37.52 AM

An example of an automobile with a 7.45 score:

Screen Shot 2018-06-21 at 9.38.04 AM

And finally an example of an untrained object (motorcycle):

Screen Shot 2018-06-21 at 9.38.14 AM

So let’s take a look at the code:

Screen Shot 2018-06-21 at 9.45.13 AM

We can see the pipleline code is elegantly simple. Consumes from the WebcamSource, enriches with a timestamp, maps the classification score, employs a tumbling window of one second (same-length, non-overlapping chunks), aggregates the max value, and finally sends the results to a GUI.

The Classifier uses the CIFAR-10 dataset  which is composed of 10 classes (airplane, automobile, bird, cat, deer, dog, frog, horse, ship, and truck).

Keeping with the Hazelcast spirit of speed, simplicity, and portability you can see how this could easily be embedded into your favorite application and harness the power of ad hoc grid computing.

More about Jet:

 

“Not Hotdog” reference is about HBO’s Silicon Valley: Season 4 Episode 4

Advertisements

Scale Big or go home

scalebig.001Scaling an application normally means you have a successful application and there is lots of demand. Unfortunately that demand can be immediate (within seconds / minutes) instead of spread over days or weeks. So it is best to have a plan prior to the firehose of demanding users.

Here are a few basic rules for scaling:

  1. Service the request without a network call
  2. Service the request with the least amount of network calls
  3. Service the request with the smallest payload

Lets see how we can make design choices that will support these basic rules for scaling.

First and foremost is to build the ability to service a request by not making a network call. This seems elusive since in almost every case the information that the user is requesting is not located on the server that their request was made. We have all experienced the pro’s and con’s of  streaming video applications. The leading providers of streaming video applications will employ the use of buffers.  Buffering or caching the video is where the application begins to download some of what you are about to watch and once enough has been downloaded the application starts playing the video smoothly. This is a form of near caching by which the cache is stored as close to the requesting user as possible. So just as the video file is cached prior to playback so can your applications response data.

This means that you will need to implement a caching solution that runs in the client. You’ll want features such as evicting the cache and even restoring the cache from the clients file system upon restart and invalidating the client cache upon server mutation. The performance gain can be tremendous since you have eliminated the need for network calls. Hazelcast calls this near cache.

Now on to the second basic rule for scaling by reducing the number of network calls. This one goes back to the late 70’s when some of the first stored procedures were created. The idea is simple don’t move the data to the process instead run the process where the data lives. This approach was the fastest for decades and is still the lifeline to many successful companies today. The primary drawback to this approach is the stored procedure is typically developed in a database venders proprietary language. As modern computer languages evolved the need to shift the logic from the stored procedure to a more general purpose computer language has become important. As the data needs grow this ultimately leads to having to divide the data up. This means what use to be centrally located in a database is now deployed across numerous servers that all participate in a cluster.

Hazelcast partitions the data across all the active servers by performing a consistent hashing algorithm. For more on this please refer to “When to increase partition count” by Enes Akar. This algorithm allows clients and servers alike to locate which active server is responsible for any given data. The same algorithm is also used for remote execution of a process that is performed on behalf of data. This is how we can drastically reduce the amount of network calls by running a process on the server where the data is located. Hazelcast calls this an Entry Processor and is similar to a distributed implementation of a stored procedure and written in Java instead of SQL/database vendor specific language.

Finally when dealing with any distributed solution the biggest impact to overall performance is how much data is placed on the wire. This is called serialization and Java’s default implementation has significant performance issues. Please refer to “Maximizing Hazelcast Performance with Serialization” by Fuad Malikov. As illustrated by the aforementioned article every serialization tested doubled the read throughput of the standard java serialization.

So there you have it. In short to scale big you adhere to some basic principles.

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction.” — E. F. Schumacker

Prepaid 4G … myth or magic..

Done. 

The journey I went through…

started off by mistakingly believing the complete bullshit that AT&T and T-Mobile are allowed to sling. Such as…

AT&T offers $65 prepaid smartphone accounts…

T-Mobile offers $50, $60, $70 prepaid smartphone accounts…

So you don’t have to go far to see these advertisements but what are they really saying…

AT&T only allows *certain* phones (Not iPhone, Not Infuse, Not … a lot)

T-Mobile allows all GSM phones only they down grade your super speedy sexy 4G phone to dialup ages of 2G/Edge (180 kilo bits per second, the first acoustic modem did 300 baud… so yea)

Alright enough misdirection since I’ll leave that up to both AT&T and T-Mobile:

  1. call up 611
  2. get frustrated by no drop to human on first level menu.. select option change plan… then the mythical ‘0’ drops you to a queue for a real live carbon based life form
  3. dial *#066#
  4. tell carbon based life form your imei number
  5. get your unlock code from carbon based life form
  6. dial #7465625*638*# {your unlock code}
  7. Bask in the glory of free enterprise (order a dirty martini)

Took about 20 minutes to get the phone unlocked from AT&T

Warning DO NOT do the following:

  1. Walk into a T-Mobile store
  2. Order the $60 unlimited plan (1st 2gig @ 4G speed… lol nice…)
  3. replace your at&t prepaid sim with t-mobile prepaid sim
  4. pay the $60

 Total time about another 20 minutes

So I have successfully obtained unlimited talk, text, data for my Samsung Infuse I997. Oh wait speed test … damn you mean i actually wanted a connection faster than morse code over string and dixie cups… Oh no you can’t do that with an unlocked phone from AT&T but if you would like to bend over and take $500 we can sell you your phone and it will work at 4G, will that be cash or credit?

No shit folks they actually uttered these words to me… so no biggie I just proceed to go home and *tinker*…

Voila other geeks have cracked/hacked/exploited and straight up sodomized the Samsung Infuse 4G with Jelly Bean, that’s right, get the latest OS from big evil company without a carrier lock. Okay I’m listening.. but wait it’s not 19.95 today it’s free! so punch in http://www.slimroms.net/ and witness in the marvel of other peoples work:

  1. Just follow the steps at: http://www.slimroms.net/
  2. Shutdown after all the ROM updating
  3. Reinstall AT&T prepaid SIM
  4. Now you can drink that martini cause you are 4G prepaid – with the Infuse 4G phone!

Thank you AT&T and T-Mobile for challenging me to do your job for you.

Hope this helps others!