Being a SXSWedu Mentor

I had the privilege of being a mentor at SXSWedu 2016, and it was a valuable, rewarding experience in which I cannot wait to participate again.

The nuts and bolts

On my SXSWedu mentor profile, I listed a few topics which I could competently talk about:

  • Software development: Web, mobile, open-source, custom, CMS, LMS, etc.
  • Online community strategy
  • Agile development and product strategy

Because SXSWedu did such a great job of collecting a roster of exceptional mentors, I wondered if anyone would sign up to meet with me. So a few days before the conference, I wrote a SXSWedu staff member to inquire, and to my surprise a few people signed up to meet! I emailed them individually to say hello, and ask what they wanted to talk about so I could do some pre-thinking. A couple responded, which later made our short conversations that much more focused.

SXSWedu assigned me to a one hour time slot on Monday beginning at 5:00 PM. When I arrived (30 minutes early, as requested), I sat at a two-seat rounder table. When the first person arrived, a SXSWedu volunteer brought him to my table for our 10 minute chat (which flew by!) To keep everything on schedule, a volunteer indicated when we had 2 minutes left, and when we finished she brought out the next person waiting. Rinse and repeat for the next hour.

In retrospect

The conversations I had with each person were quick, but genuine. Every person asked a question related to the topics listed on my profile, so nothing hit me out of left field. In retrospect I truly feel I relayed at least one nugget of helpful information to every mentee. And while that alone instilled a sense of accomplishment, it turns out this experience morphed into an excellent networking opportunity. In fact, in a couple instances the other person and I decided to meet again after our 10-minute session to continue our conversation, which also led to ongoing email conversation. The mentor experience is an excellent opportunity to build relationships, and at such a large conference I love the chance to purposefully do so while helping others.

Information Theory and Projections

I am an amateur aficionado of information theory from a purely conceptual standpoint. For instance, for many years I’ve had an interest in both data encryption and data compression, which as it turns out go together like peas and carrots.

Prior to plaintext data being encrypted, applying a compression algorithm to reduce the amount of redundancy can make the ciphertext more difficult to crack by increasing the unicity distance. Early on, an easy way to remove redundancy was to remove vowels from the plaintext prior to encryption. The plaintext was still readable and its meaning was conveyed, and therefore no information was lost. In other words, the vowels were redundant, and removing redundancy strengthened the encryption.

Periodically on Reddit I stumble upon stunning art pieces that the community found interesting enough to vote up. Tonight one of them was a collection of shadow art. Clearly the artists are wonderfully talented, and yet I cannot help but see beyond the art itself to be intrigued by the underlying mechanism in which the original message (plaintext) was hidden and revealed.

Every piece appears to be random bends in wire, trash haphazardly clumped together, or blocks or boxes strewn about. At first glance we would attempt to visually decode – to discover the pattern within those objects and comprehend the artist’s message. In fact, we might lead ourselves down an entirely different path of interpretation (e.g. assuming the heaped trash is conveying a statement about our society). However, only until a source of light illuminates the piece from precisely the correct X,Y,Z coordinate do we discover the plaintext is deciphered before our eyes as a two-dimensional projection from three-dimensional space.

Redundancy helps

In many of these art pieces, there is a high degree of redundant information that actually works to strengthen the encryption. For example, in art piece where trash was heaped together, the labels and wording on the trash items obfuscate the artist’s message by leading you down a path of inspecting the trash itself.

Another art piece with letters and numbers glued to the wall might cause the viewer to try to assemble words to understand the message. In fact, if the letters actually assembled words, they could lead the viewer to conclude she successfully deciphered the message when in fact she has not.

Decoding through a dimensional projection

Arguably the ultimate redundancy is the dimensionality of the art piece. The fact that each piece is created in three dimensions entices the viewer to inspect the piece (or individual components thereof) for meaning without considering the plaintext message exists outside of the piece itself. The key that will decipher the art piece to yield the plaintext is the X,Y,Z coordinate of light source with respect to the art piece’s location.

What I find interesting is that general mechanisms of conveying secret information tend to:

  1. Encrypt the plaintext message into something generally unreadable by anyone but the intended recipient (via some key), and/or

  2. Hide the unencrypted message in plain sight, relying on surrounding noise to distract everyone but the intended recipient who understands where to find the message and meaning amongst the noise.

For shadow art, I cannot easily lump it into either category because the piece does not contain the message as plaintext nor ciphertext. Only by projecting it down a dimension with a unique key (x,y,z) can it be deciphered. It’s more closely related to an encryption, but without an algorithm required to decode. Just shine the light from the right spot, and there’s your message. It’s as if the art piece itself has the encryption and decryption algorithm built-in, so applying the key yields the message immediatly.

So what now?

Like many people, I think in analogies. I see how this art obfuscates a message that can only be revealed in a dimension below its own. I feel like there’s an analogous type of encryption that could be applied to textual messages. As I said, I’m an amateur, but I’ll continue to contemplate it.

Drupal for Content Management of a MEAN Application

It’s no secret that I am a fan of Drupal for its plumbing that yields out-of-the-box stability, security, and configurability. Using Drupal and an assortment of contributed modules, it’s relatively easy to quickly create most any type of website.

Before learning of Drupal 8’s RESTful services, I questioned if there were any natural scenarios where Drupal could integrate with a MEAN stack-based application. One idea which I ended up modeling was using Drupal for a pure management console of data in a Mongo document-oriented database.

Example: Job Board

Drupal has the notion of Content Types that define and separate…well, logical types of content on the site, including the fields that can be filled in for each content entry (called nodes in Drupal). For instance, consider a Job content type that could be a basis for creating a job board. Fields for a Job might include the position title, job description, educational requirements, start date, and so on. With the content type defined in Drupal, any new Job nodes are stored in Drupal’s database.

Let’s say we want to manage (create, edit, delete) Job nodes in Drupal (taking advantage of Drupal’s account creation, permissions, security), but allow a light-weight mobile application to access and display the job listings. Ideally the data is accessed by the mobile app via JSON queries, and for this example let’s say the mobile app is written in Ionic (and Angular-based framework), and the server is written in Javascript running on Node JS.

From MySQL to MongoDB

Drupal uses a relational database like MySQL or PostgreSQL to store ALL of its data, including content, configuration, users, permisisons, etc. Instead of developing the Node server to access Job content from Drupal’s MySQL database, I found it much easier to extract the Job data out of MySQL and into a Mongo database for access by the Node server. This is done in real time by Drupal as Job content is created, updated, and deleted.

It is fairly easy to one-way synchronize (from Drupal to MongoDB) the job listings by writing a Drupal module. Using the Drupal hooks to trigger when Job content is created, updated, or deleted, the Drupal module executed the same operation on the Mongo database’s collection of job listings. In the MongoDB document, I captured the Drupal field data as well as some metadata, including the Drupal node ID and creation date. Then later when the Job content in Drupal is updated or deleted, the node ID could be searched in the MongoDB collection to perform the same operation.

Granted, the flow of data is one-way (from Drupal to MongoDB), and it assumes the mobile app will not be modifying the Job postings and synchronizing those changes back to Drupal. However, if two-way data flow is desired, either a call-back mechanism or polling (via Drupal’s cron hook) could synchronize new data back to the Drupal database.


While developing this example, I realized some good reasons why this implementation is interesting:

  1. CMSs like Drupal really provide two types of content services: (a) content management, and (b) content viewing. The same website/CMS code base and infrastructure supports both interactions. However, for many site implementations, the predominant type of user interaction is skewed heaviliy in favor of content viewing. It turns out that a sizable amount of code has to be executed for every interaction on the site, even if it’s just to view the data. This can be a non-trivial amount of overhead, especially for high-traffic sites (even with various levels of caching). Once the content is created, if the audience who consumes it does not need to modify it, I assert it’s hard to beat the transfer time, data size, and server-side processing power required to process JSON/MongoDB query via a RESTful Node server.

  2. Drupal excels at content creation and management (not to mention user management, security, etc.). If you’re developing a primarily mobile application (even without user-facing website), you can leverage the vast number of contributed Drupal modules that support content creation (e.g. RSS import) for your mobile application without a great deal of development effort. Then you can focus your time developing your mobile app instead of developing the mechanism and interface for getting external content into your database.