by: Yehudah Koblick

The following is part of our series, Site Updates and Enhancements, which highlights the ongoing development work happening at Shabbat.com.

Shabbos Project Integration

Here at Shabbat.com we are extremely excited about The Shabbos Project and the technical contributions we are providing to this monumental initiative. We consider The Shabbos Project to be the world’s largest Shabbaton. The role of Shabbat.com requires a lot of new programming to assist the team in South Africa in securing hosting for Guests worldwide using our platform.

We are building out a nifty suite of tools for The Shabbos Project that include the following. The Shabbos Project dashboard provides ‘at a glance’ data highlighting the overall picture of Shabbos Project Guests and Hosts, suggestions, invites, and hosting requests. An admin can see any Guest worldwide who has not yet secured hosting and form a suggestion to nearby Hosts prompting them to invite the Guest.  The admin can monitor the suggestion(s) to each Guest as well as invites and assist with and follow up based on the data.

Note these suggestions are especially intelligent because they are within the Shabbos Project internal Shabat.com network and based on mutual availability and preferences. The system employs artificial intelligence algorithms to simply make the manual painstaking process of setting up thousands of people for Shabbat a whole lot easier.

 

Transactional Email Part 1

As I mentioned in my last post, we are working to vastly improve our Transactional Email model. This is effectively our fourth revision and is one of the crown jewels in the vast code-base. Besides for implementing a new template container for emails capable of rendering nicely in a wide variety of screen form factors, we’re working to tighten the code to a more manageable footprint. We’re adopting to a Polymorphism design architecture. Also, we build for testability, for advanced control, and settings to be employed on the emails that we send. This is part of the thinking of this current effort.

When a message or invite is sent on Shabbat.com, here is what happens. The text passes through a filter looking for any objectionable content, as well as checks for sql injection and cross-side scripting. If the message is accepted, it moves further. Otherwise it is flagged for review and placed in a review queue.  The email is then constructed and eventually packaged into a ‘sendable’ email then added to a queue to be passed on to our email provider (Sendgrid) where it is finally sent to its destination. Note all this takes place asynchronously on reserved server threads so that there is no latency or delay in the Shabbat.com site experience when all this takes place.

The actual email construction is conditional based on type. Here’s where the polymorphism shines. All transactional email types inherit from the super class TransactionalEmail. We have literally dozens of types with similarities and differences. Mostly they share a common behavior and could benefit from code reusability yet maintain an override possibility. Some sub-types can be inherited from as well.

This is a simple introduction. Next week I’ll go into more detail on this design pattern and show some code!