The Basic Meeting List Toolbox

Javascript Satellites & bmlt.js

The latest release of the root server (v2.10.3), has some exciting new features.  It introduces a new response endpoint called JSONP, or JSON w/padding.  Typically making a JSON request/response requires that both the client and the server are on the same exact domain.  This is a by design security feature of most modern browsers to prevent XSS (Cross Site Scripting Attacks).

JSONP is one of the methods to safely ensure that the requestor and receiver are a trusted connection.  Along with this, comes the ability to build all kinds of applications that couldn’t be easily accomplished before.  This includes writing satellites for traditional static HTML sites, Wix, SquareSpace, Weebly, and Google Sites.  Basically anywhere you can write custom HTML and Javascript you can do this.

I’ve put together a Codepen example of the basic use case.  Of course this could be as fancy as you wanted, given that you write out the HTML and CSS. Codepen, by the way, is a slick way to write sample applications and it’s totally free to use / share / copy, etc.

In this Codepen example you can see that we are referencing a new BMLT client library called bmlt.js.  bmlt.js has a couple of basic functions [https://github.com/LittleGreenViper/BMLT-Root-Server/blob/master/main_server/local_server/bmlt.js], that allow for rendering meetings that follow a certain set of criteria.  More functionality would/could be added in the future.

Here are the following methods available, notice each function has a callback.  This will be executed upon the return of the request to the BMLT.  You will get back a data object with the response that you use to render.

getMeetingsByCity(city, callback);  // Specify any textual city name for an exact match.

getMeetingsByServiceBodyId(serviceBodyId, callback) // Specify any service body ID, talk your administrator to get yours.

getMeetingsByServiceBodyIdAndWeekdayId(serviceBodyId, weekday, callback) // Same as above, but also can limit to a specific day of the week.

getMeetingsByServiceBodyIdAndCity(serviceBodyId, city, callback) // Again the same, but limit by city.

We are also making use of jQuery to simplify some of the rendering of the HTML.

Here are some examples of this at work, making use of the various Embed capabilities.

Weebly: https://bmlt-widget.weebly.com/meetings.html

Wix: https://jeffandchris123.wixsite.com/website/meetings

Static HTML: http://dea-na.org/meeting_page.html

Google Sites: https://sites.google.com/site/bmltdemo/

Need more help, head on over to the BMLT group on Facebook.


[UPDATED] Google Maps, API Keys and Geolocation Issues

UPDATE: There have been reports of the “Unable to Determine Location” bug happening on Apple Mac OS Safari (not the iOS version; just the MacOS version); even after implementing the SSL certificate.

This is not a bug. It’s because Apple has turned their security to “11”.

You need to enable Location Services.

UPDATE (2): As of Root Server version 2.10.1, you will need to add the Google Geocoding API to your account, or the “This is a Location” string searches won’t work.

Step One: Open the API Editor

Step Two: Open the Additional APIs Picker

Step Three: Select the Geocoding API

Das Pröblem:

As most of you have probably already found out, Google now enforces HTTPS and API keys in their Maps.

This results in:

1) the dreaded “Oops! Something went wrong!” display:

Oops! Something Went Wrong!

NOTE: In the Root Server, this results in the map display shown as “all blue,” with no map displayed. Also, the “Set Longitude and Latitude to Address” button will not work.

2) and/or the “Unable to Determine Your Location” display:

Can't Find Your Location

This happens if you try to use a location-tracking feature, like the “Find Meetings Near Me” button in the Satellite.
Read more



PROTIP: Why Meetings Are Marked “Closed” By Default

I’ve had a number of folks ask me (sometimes, “ask” is a rather mild term for the manner in which they approach me) why meetings tend to be marked as “Closed” in data dumps and listings.

There’s a very simple, good reason for this:

The VERY WORST thing that can happen to a meeting, or a Service body, is that someone attending a meeting (often, a family member of an addict in attendance) is thrown out of a meeting. They will usually take the person they attended with when they leave, and never return to NA again. They will often also say bad things about NA in many venues.

NOT GOOD.

Compounding this, is that meetings are often held in…less than upscale…neighborhoods, and throwing someone (like a middle-aged, middle-class woman who attended with her teenage daughter) out could actually put them in direct physical danger.
Read more



PROTIP: A Quick Geeky Way to Update NAWS World IDs

This entry is part 4 of 4 in the series Root Server Admin

ABSTRACT

If you have used the NAWS Export Functionality of the BMLT to send synchronization dumps to NAWS, you have received a spreadsheet in reply, with a series of meetings that have revised or newly-assigned Committee Codes (what we call “World ID” in the BMLT).

These are fairly long sequences of numbers, prefixed by one or two letters, like so:

  • Regions are listed as “RGXXX“, with “XXX” being 3 digits (with leading zeroes). For example: “RG001”, “RG123”.
  • Areas are listed as “ARXXXXX“, with “XXXXX” being 5 digits (also with leading zeroes). For example: “AR00001”, “AR00123”, “AR12345”.
  • Groups are listed as “GXXXXXXX“, with “XXXXXXX” being 7, leading-zero-padded digits. For example: “G0000001”, “G0001234”, “G1234567”.

These need to be assigned back to your BMLT database in order to ensure continued synchronization with NAWS.

It should be noted that NAWS tracks GROUPS, not MEETINGS.

Groups are Service entities. They are the driving force behind meetings, and often a single Group can have multiple meetings (like clubhouses, or lunchtime meetings).

In these cases, you may apply the same World ID (NAWS Committee Code) to multiple meetings.

IT IS EXTREMELY IMPORTANT TO DO THIS! DON’T IGNORE THE SPREADSHEET RETURNED TO YOU BY NAWS!

It is very much worth it to keep NAWS in sync with your database, so this operation is important.

Thankfully, NAWS has agreed to do a certain thing that makes this process fairly easy to automate.

This post will spell out a somewhat “high geek factor” way of doing it. I will be working on a tool to abstract the complexity, but that will be a little while in coming.
Read more


The Next Big Thing -Part Deux

OK. I have completed adding all the basic functionality to the BMLTiOSLib project.

I still need to add stimulus support for these to the test harness app.

Once I have validated the library with the test harness, I’ll write some small sample usage apps in both Swift and Objective-C.

There’s probably still a month or more to go before the library is ready for me to call it “done,” but it’s in great shape.


The Next Big Thing

So far, the Root Server and the various Satellites seem to be working well.

I’m in the process of releasing an updated version of the awesome BMLTAdmin app. The update won’t add any new functionality. It’s merely a tweak for the latest Apple iOS version (iOS 10). The original version still works fine, so there’s no urgency to update.

So what I’ll be developing will be an iOS framework for people that want to develop iOS apps for the BMLT. It will abstract all server communications using an Observer Pattern (Apple calls it “delegates“).

This will be a “dogfood” project, which I will use to create the next version of the iOS BMLT app, and, eventually, a new version of the BMLTAdmin app.

The whole idea is to make it insanely easy to write iOS apps that will interface with the BMLT.

I’ve done this kind of thing before, and it will work out great. It may take a few months, though, because I do this kind of thing extremely carefully. This will be an “infrastructure-level” framework, and needs to be of the absolutely highest quality possible. I’ll also need to write some fairly comprehensive documentation.

It will be written in Swift, and will require a fairly current version of the operating system (never an issue with Apple, but a huge problem with Android, and one of the reasons that I don’t program Android). It will abstract the JSON variant of the Semantic Interface.

UPDATE:

Here is the repo for the project.

At the time of this writing, there’s still a long way to go.


HTTPS, And the iOS (iPhone) App

At the Worldwide Developer Conference this year, Apple announced that it will force all iOS apps to use HTTPS to connect to the Web.

This could have a fairly big impact on the NA community, and the BMLT Community, especially.

A few months ago, I reworked the BMLT to behave properly in SSL/HTTPS (secure Web sites), and with nonstandard ports (a technical term -if you don’t know what it means, don’t worry).

That means that you can run the BMLT on secure sites (ones with “httpS://” prefixes), no problem.

Hosting those sites is a bit more of a challenge, though. Here’s a good blog entry that makes it fairly straightforward and simple.

If you are running an NA site, you may want to consider switching it to HTTPS. I’ll get around to doing that with this site in my copious free time. I already run a test site with SSL.

The biggest issue with running SSL/HTTPS on your site, is that it can be slower. The reasons are a bit technical, but basically, SSL likes browsers to do just one or two things at a time, whereas HTTP allows a whole bunch of simultaneous actions. I’m hoping that changes rapidly as SSL becomes the standard.

The most likely immediate impact on the BMLT could be that the iOS app might stop working. I’m not sure if that will be the case or not. Apple seems to be a bit vague on how they will enforce their edict. They may not allow me to make any updates without SSL, but may allow the current (extremely stable) version to run non-SSL.

More will be revealed…