Matt Juszczak

Processing Late Cancel & No Show Fees in MINDBODY

2018-08-04T00:00:00-04:00

This is the first of what I hope will become an ongoing series of MINDBODY tips & tricks. In my capacity as Co-Founder of Turnstyle Cycle and O2M Fitness, I’m constantly working with MINDBODY’s software as both a business owner and consumer. Today’s post is a bit of a selfish plug; however.

Almost all studios that use MINDBODY have a late cancel and/or no show fee for Unlimited members who fail to show to class. Up until recently, processing these manually was required. For those who have access to MINDBODY, there was a huge support thread (now gone) full of requests for this functionality. Now, there’s a way!

O2M recently launched our Studio Tools product, which allows MINDBODY fitness studios to automatically charge their customers for late canceling and/or failing to show to a class all-together. We built the first version of this at Turnstyle years ago, and decided to rebuild the software last year and offer it to other studios as a service. Check out the O2M Studio Tools Late Cancel service.

Cheers.

Thoughts on ‘The Log’ Post from a Relational Database Guy

2014-08-07T00:00:00-04:00

Back in December 2013, Jay Kreps at LinkedIn wrote an utterly brilliant and thought-provoking post in the LinkedIn Engineering blog on “The Log: What every software engineering should know about real-time data’s unifying abstraction.” It’s taken me awhile to circle back to this and actually record my thoughts.

As someone who has a lot of experience with relational databases and database replication, I felt that the analogies that Jay drew - especially those regarding RDBMS - were extremely helpful in wrapping my mind further around new ideas in the realms of real-time and distributed data, key-value stores, etc. Many of us with roots in the RDBMS world are anxious about the new-and-different up-and-coming ways of “doing data.” The “big picture” insights in this piece offer a conceptual framework that is both interesting and useful.

When I first started reading I was pretty intimidated by the technical level of the discussion. But please don’t let that deter you from checking this out! The further you read into the piece the cooler it gets…

From this perspective, data is basically just data. And data models and specialized data systems are basically just different views and indexes on top of data. “Producer” and “consumer” systems can put data in log files and take them out, respectively, without knowing anything about the system of origin.

Those of us with relational database backgrounds can grasp all this from the standpoint of replication logs and how they work. Serving distributed systems makes replication asynchronous, but ideally you’re still reading and writing in a standard format, without having to worry about what’s going on on the “producer” end. The log can be the same for every system, with log data served by system-specific “serving nodes” within a “serving layer.”

Probably my favorite analogy in this blog points out that the US Census is a good example of batch data collection. Why does it still work like that, with so much brute-force data gathering? Wouldn’t it be easier to establish and keep a journal of births, deaths and relocations that could produce population counts in real-time?

Another thing I really like about this post are the author’s thoughts on potential future directions. He posits three possibilities for the evolution of logs:

A continuation of the status quo; that is, “the separation of systems remains more or less as it is for a good deal longer.”
A “reconsolidation” towards unifying “uber-systems” embodying greater generality, in which many of today’s specialized data processing functions are merged.
The ultimate unbundling of data infrastructure into a collection of services and application-facing APIs, not unlike the Java stack.

This reminds me of the history of cloud computing: how things start off at A and go to B and then “regress” back to A in a new light. In the days of the mainframe everything was offsite; then computing power was brought in-house for a variety of reasons; then it arched back out to the cloud again; and now it’s being drawn back into private dedicated infrastructure (that is, organizations are moving back to having their own, dedicated hardware).

One way to look at it is that it’s all about relinquishing control and then getting it back and then relinquishing it again in exchange for new capabilities and then getting control back again… What is central becomes distributed, and so it goes. Instead of having twenty different systems that need to be integrated, why not have one uber-system that does it all - especially if the data store can become generic enough to support all the different indexes and views that enterprises increasingly require?

As any technology progresses it gets easier and easier to setup. So if we stop focusing on a specific data storage technology and instead start offering a collection of commodity, black-box, building-block data services, then all we have to do is couple things together. So things might evolve that way.

But I don’t think things are likely to stay as they are now for long. Many of us are intensely focused on setting up various individual, distributed technologies. I think largely this stems from the pain people are experiencing with traditional systems. As clear winners emerge among these distributed solutions, it’s likely that they will become more and more generic and we can increasingly fall back on them to get the job done.

But don’t take my word for it - read Jay’s post and draw your own conclusions. Don’t forget to watch Ren & Stimpy’s “The Log Song” when you’ve reached the end.

An LDAP-Based Social Network

2014-04-05T00:00:00-04:00

I’ve often thought about what decentralized and distributed social networks would look like. I know that services and protocols like Diaspora, OAuth, OpenID, and XMPP (Jabber) technically live in this space, but let’s pretend for a second that good old OpenLDAP would actually scale as a distributed social platform. After all, it’s already used for directory services worldwide, is often overlooked as one of the first well-known key->value datastores, and has a distributed hierarchical architecture, so why not explore the idea? Just for fun. Oh, and let’s also ignore the fact that a social network has to reach critical mass to be successful, and there’s not really an easy way to monetize distributed social networks. Seriously. Just pretend.

OpenLDAP is an implementation of the LDAP (Lightweight Directory Access Protocol) protocol. For the sake of this blog post, I’m not going to go into too many LDAP technical details, other than that LDAP allows data to be stored hierarchically in key->value form. Let’s make an analogy: a tree trunk, numerous branches, twigs, and leaves. Each and every leaf can have numerous attributes attached to it, such as color, size, and shape. Let’s take a look at a super-simplified sample LDAP tree. For the record, I’ve left out some metadata and such, so this won’t actually work if you try to use it.

dn: cn=matt,ou=people,dc=example,dc=com
cn: matt
gender: male
birthday: 09/12/1983
hobby: running
hobby: hiking
hobby: camping

dn: ou=people,dc=example,dc=com
ou: people

dn: dc=example,dc=com
dc: example

So what’s going on here? Well, we’ve essentially created an LDAP tree:

example.com
- people
  - matt

… with example.com a branch, people a twig off of that branch, and matt as a leaf attached to that twig. In this case, that leaf has multiple properties: my birthday is September 12th, 1983, and I’m a male. I enjoy hiking, camping, and running. Think about how many other things I could store!

In this case, example.com is a branch, NOT a trunk. That’s because if someone was looking for a record in another domain, an LDAP “subtree” can send that request upstream and have the request redirected to another location where the data is actually stored. Sound familiar? I bet it does if you’re familiar with how the Domain Name System (DNS) works.

So we’ve established two things: an LDAP tree is hierarchical, as in I don’t have what you’re looking for, let me send you up the other branches until we find what you’re looking for, and you can store descriptive attributes about a “leaf”, as in name, birthday, gender, likes, dislikes, relationship status, and even a list of friends.

So in the dream-world of an LDAP-based social network, there’d be a number of LDAP clusters sitting out there on the Internet. Folks would sign up at one of these highly available LDAP services and have a profile created that they could manage, which would contain their directory information as well as their “connections”. For instance, example.com would run with records like:

dn: uid=matt,ou=users,ou=link,ou=example,dc=com
uid: matt
gender: male
hobby: running
hobby: camping
hobby: hiking
connection: uid=mike,ou=users,ou=link,ou=example,dc=com
connection: uid=john,ou=users,ou=link,ou=example,dc=com
connection: uid=sue,ou=users,ou=link,ou=example,dc=com
connection: uid=rob,ou=users,ou=link,ou=atopia,dc=net
connection: uid=mark,ou=users,ou=link,ou=atopia,dc=net

In that example, I’d be “friends” with three local users, and two users on the atopia.net domain. Hey, this already looks an awful lot like how some corporate directories are setup today, right? Read on. On another note, I’m running out of sample domain names to use.

Security would be pretty important in a setup like this. GPG could be used to store encrypted data inside each LDAP record. At the most basic level, that data could be encoded only for “connections” that should have access to that data. The private keys would likely be stored within each user’s LDAP record in a private attribute, so one would have to trust their own chosen LDAP provider. My LDAP provider could reach out to a friend’s LDAP provider at any time, perhaps when I’m trying to access the data of those in my network, and decrypt the private data only meant for me. As for search, a centralized LDAP provider could host key->DN maps, so folks could perform searches by email address and/or some other key and find out the location of that user’s data.

Realistically, there’s a lot of challenges to this idea and it probably wouldn’t work. However, LDAP was built to be a distributed directory service in its most basic form, and it’d be quite interesting to somehow power social interaction with it. If you find it hard to believe, consider it an overdue April fools joke. :)

Why I Switched from Blackberry 10 to iPhone

2014-03-20T00:00:00-04:00

I’m known as the king of Blackberry. I’ve had a Blackberry since I was in College. In fact, I wouldn’t be surprised if I was Blackberry’s longest customer and cheerleader.

No longer. As of today, I have an iPhone.

To be honest, Blackberry has an amazing user experience in their latest Blackberry 10 OS. Next time you’re at your wireless provider’s store, take a peek at the interface (if they still carry the phones in-store): it’s wild. I would have loved to see Blackberry 10 thrive with a full native App Store and an actual user base. But it all arrived too little, too late. Wasting time side-loading Android apps which only half work reminds me of the days when I wanted to continue to snap together my desktop from scratch even when it was way more efficient to go to Best Buy and buy one for half the price… you get the idea. Fail fast!

And that’s another thing: simplicity and efficiency. I have a way of over-complicating things. When my sister got married in California, I was the one guy who had to drive across the Country and turn it into a complex adventure. There’s a time and place for having fun along the way, but sometimes you just need to get there. I also have a history of being stubborn occasionally, though learning to admit when I’m wrong is something I’m striving to do more often. I loved the Blackberry back in the day, especially when it had the physical keyboard and push email. After a while; however, I realized I was just sticking to what I was used to, instead of actually using the phone that was going to improve my days and make me more efficient. Did I switch then? Nope. And there are tons of fellow Blackberry users who are likely just as stubborn and don’t want to admit that the thing they’ve loved for so long is fading into the sunset. Folks, it’s time.

And so the iPhone is my new life tool. It’ll make me way more efficient, and I’ll be able to spend way more time tinkering with things that actually matter. After all, I doubt I’ll look back ten years from now and wish I had spent more time trying to get Snapchat side-loaded on the Blackberry 10 with Google Play support… especially when I just installed 30 apps in under 10 minutes.

I wish Blackberry best of luck. I’ll really miss you. In the meantime, cheers to keeping life uncomplicated.

The Search for a New Phone

2014-03-14T00:00:00-04:00

I’m trying to blog more. Most of my posts from now on will be technical, but a recent conversation gone haywire among my friends was too hilarious not to share with the general public.

I’m a Blackberry user. I have been for many years. Most of my friends know that. I’m a fan. Except for the battery life lately, and the lack of supported applications, and the fact that no one else actually uses them anymore, so BBM is (or at least was, until recently added to other platforms) sort of useless.

I’m always considering taking the leap onto a new platform, but never end up pulling the trigger. This week, I decided to enlist some of my close technical friends in helping me choose my next phone. It went a little like this…

Okay guys. Between the three of us. It’s time for me to get a real phone. I trust you guys. What should I get? Security is somewhat important of course.

I should have known what I was getting myself into. The following phones were quickly suggested to me as alternatives to my aging (and “ailing”) Blackberry 10:

A Western Electric model 500, both “solid, reliable, and secure”…

Yeah, hrm. Not quite portable enough.

The next suggestion was the Inmarsat IsatPhone. Interesting, and useful on hiking trips, but I’m pretty sure that it’s a little out of my price range…

I was then led to the awesome and amazing Jitterbug Cell Phone, which was only sent to me under the notion that it’d be a step-up from my Blackberry 10. Oh, and a phone I could “really grow into…”. It’s true, it would last me ages!

Eventually, I settled on the tin can phone. Quite reliable, and I won’t have to worry about battery life! But best be careful about security.

As I continue to look into actual phone platforms, like Android and iPhone, I’ll continue to remember to be careful what I ask my friends: I just might get well-thought responses!

Happy Friday, y’all.