BMapp update

Well, the Burning Man Map App is coming along nicely. It's at the stage where I'm willing to show it to a UX designer to get some tips.  I've also moved it to another host, served from here.

There is still a list of things that needs to be done, but I think it's really getting there!

https://garbage-collector-acronyms-27351.netlify.com/

Update and partial FAQ

These is a FAQ for the questions that I frequently imagine that I am being asked.  As you will see, my internal interlocutor can sound a bit judgey.

What's going on with BMapp?

I am continuing to work on BMapp apace.  I'm keeping it on a private git repo at Bitbucket for now.  I may open-source it at some point, but there's something irrationally nice about its being a private solo project*.  I've committed to Inferno, Redux and Rx.  I'm looking at redux-observables, since it's using two libraries I'm already using.

What's up with all the Bookmarks lately?

Well, there is not really a public social bookmarking application anymore, since the demise of del.icio.us.  When I find or build one, I'll move all of those to it.  There are a lot more in my chrome bookmarks.  If I added them all, it would look even more like spam.

What's up with using Blogger?  I think my grandad used Blogger once. All the cool kids use ${some_other_thing} or roll their own.

Rolling my own or moving it is in some distant future plan, a bit like my social bookmarking plans or the open-source social media plan. I started this blog waaay back nigh on 10 years now to keep track of a specific collaboration, almost immediately abandoned it, and rebooted it when I felt the need to have a public notebook.  It is quite limited, but so far I have not bumped up hard against those limitations. It does the job. The risks are that it will be sunsetted by the notoriously fickle Google.  Or that webstandards will leave it far behind.  (Does it even have any full time staff?)


* "Rather than its being a public solo project?  A publicly ignored solo project?  A project that's so stunningly fun that someone will fork it and do something more interesting?" asks my internally judgmental interlocutor. "Don't worry about any of that.  Open source it!  Do it!  Do it! YOLO!" he shouts.

Bookmark: Font and Font fallbacks

Various resources dealing with fonts on websites.

Front End Center — Crafting Webfont Fallbacks (YouTube)
A Comprehensive Guide to Font Loading Strategies
fontfaceobserver: Webfont loading js library
Font style matcher + github
CSS Font Stack
Quick Tip: How to Consistently Render Typefaces Cross-browser (video)
Type Rendering Mix (library referenced in preceding video)

Bookmark: Offline-only content

I may consider doing something like this for the BMapp: Offline-only content.

https://chris.bolin.co/offline/

Brunch and BMapp

The "Burning Man App" (I'm settling on the working title BMapp) that I'm building has stalled for a minute. Before I dig in, and move from proof of concept to actual build, I want to make sure that the architecture and pipeline are solid. That is to say, I'd like a good framework and a build task that keeps the coding itself relatively simple. For the framework, I've settled on Inferno, because it is light and fast.  While its key developer has left (?) the project to move onto React at Facebook, and I'm not sure what that means for Inferno's future, for now, the relative advantages yet go to Inferno.

As to a build task, the Inferno team itself appears to recommend Brunch, an open-source, community-driven "build tool" rather than a "generic task runner". Its main selling point is that it reduces some of the monstrous complexity that some build task runners can encompass.  A single brunch-config.js file pointing to input files, plugins and some output directories, and boom, you have a minified, uglified, compressed, tightened, tested web app. No fuss, no muss.  Sounds great!  Also, during setup I ran into a few errors (that were ultimately caused by a flawed npm release, not Brunch): with one issue ticket the Brunch team was incredibly responsive.  They were on it!  Even committing to closing out the issue over the weekend!  That is dedication. "Windows support is very important to us."

So, when I say that Brunch isn't working for me, it is by no means a slight of Brunch itself or the hardworking team that created it. If you're looking for a build pipeline, do check it out! This post is more a documentation that I tried it, and why I'm moving on.

I generally like to code javascript using Typescript, for a number of reasons, but mostly because it is javascript, only with strict typing. Coding with it prevents me from easily relying on type ambiguity (and the advantages that ambiguity can sometimes confer), and in return, I'm made aware in the editor, even before compilation, of potential problems.  Other advantages: I can use the latest and greatest coding practices from ES6 and later (does what Babel does), and my code will automagically be compiled into whatever version necessary.

Brunch kinda has typescript support, but see, that's the thing: it suffers from the same issue that all popular task runners do: you need to rely on some intermediary plugin that may, or may not, be up-to-date. Brunch uses 'skeletons' which are a kind of template or starter pack for different configurations.  Their official 'brunch with typescript' skeleton, out of the box, gives you a `brunch-typescript is unsupported, use typescript-brunch instead` deprecation message.  Okay, no big deal, I'll just swap out the brunch-typescript plugin for the typescript-brunch plugin.  But typescript-brunch has this notation: "From version 1.8.2 up to current version, this plugin may report TypeScript errors that you are not expecting" and "We are hoping to support the full language service, at least for brunch build at some point, but until then...[etc]".  Not exactly inspiring confidence.  Okay, no big deal.  I'll just use Typescript itself to compile to javascript, and once there, let Brunch takeover to do what it does best.

On to uglify js, the minimizer.  I followed all instructions as I understood them to get it working and it just plain did not work, meaning, to minimize and 'mangle' the compiled javascript; or really, to have any effect at all. Simply installing the plugin and referencing it in the config file appeared to have zero effect on the code itself.  No doubt, and I mean this, it's my bad.  I didn't understand the instructions, or didn't fiddle with it enough.  Perhaps if I had changed the order of the plugins, or if I had only spent another 10 minutes or half-an-hour, then I'm certain I could get it working as expected.

And, it's community driven! If it's not working, get on the stick! It's not like you can demand your money back. Write up a ticket describing the issue.  Ask questions on the forum! Write the bug fix, if that's what's necessary. I get it!  But that's the thing:  I had already spent a lot of time with it already.  A task runner / builder / DevOp tool / what-have-you is supposed to make things easier, minimize errors and time in the setup and manipulation of code.  If you're spending as much time on the tool as you would just rolling your own, then it's maybe best to roll your own.  My spare coding time, right now, is dedicated to getting this BMapp up and going.

So, for now, it's back to using npm as my build tool.  It's simple, it works, and if something isn't there, it's super easy to code up a module that does what you want.

Coming along. Framework hesitancy. The Redux Decision.

The Burning Man App is coming along.  What started out as a proof of concept playing with the data has gradually moved towards becoming an actual web app.  The journey of building it has been taking me through some adventures (if we can quite loosely define 'adventure' here as 'source code' and 'articles about code').  (Also, it's to the point that I'm going to have to choose a name, and I don't want to run afoul of copyrights / trademarks.  The Burning Man App is a good working title, but probably not for release.)

A few new things I have learned:

There is a whole ecosystem of virtual DOMs.
There are tons of web application frameworks in active use and development, not just React and the Angulars.
Lighthouse is a thing.
Page Speed Insights is a thing.

Given the nature of the app, I'm probably* going to have to use a framework that supports a virtual DOM.  Page Speed Insights reports that it contains over 3,000 elements (stating that less that 1,500 is desirable).  This is undoubtedly because of the SVG that comprises the Black Rock City map, which, besides the infrastructure of the city itself, also contains icons representing 308 artworks, 1,299 camps, and 3,374 events!

This will necessarily require some optimization though, because, while desktops and fancier smart phones can handle all that, under-powered phones and tablets crawl. The app doesn't really need to display all of the events at once, either.  I can also probably insert icons only as the user zooms in, and only within its viewport.

I'm still not ready to pull the trigger on a full-blown framework, yet.  I'm peering closely at Vue.js, but we'll see.  Not sure why I'm so reluctant to wade into React.  It would be good for my professional development to at least be familiar with it, but as this app is a labor of love, I want any technology to fit with what I want to do, rather than trying to fit the app into some mismatched box.  To those of you who already know a framework, including my future self, it may be hard to understand this hesitancy. But remember: learning a framework takes an investment of time and energy; time and energy spent learning a framework is time and energy not spent developing the app; not spent with family and friends; and, at the end of the day, your app is now married to a community and ecosystem that may or may not be a good match. A divorce is costly. Apps also require maintenance, and if it has been some time since using that framework, and the framework you've chosen badly is unintuitive, then you will have to spend time relearning (on some level, this is my reluctance with React: everything - javascript, HTML and even CSS appears to be jumbled all up together in JSX). There are pros, of course, but those are some of the cons.

I have committed to using Redux, however, at least for the user interface.  Keeping application state in a single object to which all elements refer makes a lot of sense. The app will be able to store that state, as well, so that the user can return to the app as it was.  It will also be much easier to integrate a framework when the time comes.

BRC app update

Well, I can say that the 'map' now looks more and more like an 'app'!  Click here to see it.  It has severe UX issues, but it has a rudimentary search functionality, and some responsiveness.  The search bar is in the upper left.  Try it out!

Exciting!

Edit:  D'oh!  It fails in iPad Safari.  That's going to take a minute to troubleshoot.

BRC map update

Further progress here.  Added art and camps with little labels.  Zoom in to see them.  Also, if you can open the javascript console in your browser (often ctrl-or-option-shift-J), you'll see the data for each marker.  It's obviously still a work in progress, but it's coming along.  While the map is for 2017, the events and camp locations are from 2016.  BMorg will release location data for the current year in about a week.

Black Rock City map update

I finished the SVG map of Black Rock City.  Feels good to get that out of the way.  Now I have a place to put location data such as art, events and camps, from the Burning Man API.  Further, with the javascript in place, it will be easier to make such maps for future years.

Edit:  (The original title of this post was Black Rock City map complete) Ah, it's an old truism in software development never to label something as 'complete', 'finished' or 'final'.  By 'finished' above, I meant only "I has a map".  The project itself is not finished.

I've since added zooming and panning capabilities. To do that, I just grabbed a library (svg-pan-zoom by ariuta)which did the essentials of what I wanted, out of the box.

However, because SVG's coordinate system increases from top to bottom, but real-life GPS increases from bottom to top (i.e. south to north, at Black Rock City, anyway), I had used SVG's transform attribute to reverse the vertical scale.  While this allowed an exact mapping between the map's xy coordinates and actual GPS coordinates, this also caused the svg-pan-zoom library's vertical panning to be reversed, as in airplane controls.

In order to get the vertical panning to work properly, I had to do without the easy fix of the reversed vertical transformation and abandon the conceptually convenient x-coordinate = longitude and y-coordinate = latitude scheme.  The new GPS => x,y  javascript transformation incorporates a vertical flip.  It took a while to get it right, but the gain is that the transformation can be any arbitrary size and origin point.

BRC, Javascript + SVG

I'm creating a map of Black Rock City in SVG using javascript, so that I can map some of the locational Burning Man API data I've been playing with. It took me quite a lot of time to get to flow on this project. It's not quite finished, but the latest version is here.

It took some thought to translate GPS data with distances in feet, into SVG's xy-origin-at-upper-left coordinates. To make sure that everything is as it should be, for now, real GPS coordinates correspond to actual xy coordinates on the map.  e.g. "the golden spike" at 40.78660,-119.20660 in GPS is represented in the SVG graphic as <circle cx="-119.2066" cy="40.7866" r="0.0005" fill="gold"></circle>. Note how the coordinates are identical.

The problem with this is that it's necessary to zoom way, way in, because the distances involved are tiny. For example, the distance from "the golden spike" to one of the pentagon corners is 8,175 feet, but in "GPS units", it's only 0.0293. Just a single foot is 0.000003! The width and height  of the whole thing is only 0.7 x 0.6 (in SVG's unit-less distances). Such tiny numbers makes dealing with fonts difficult. But it is pretty neat, to just be able to grab a coordinate and stick it in without modification, so I'll experiment before deciding to scale it up.

Adding to my confusion is that the official GPS coordinates[pdf] for the enclosing pentagon appear to be way off (or my mind is way off). I assumed it was my transformations somehow, which is why I took extra care to make sure that there was a one-to-one correspondence between GPS coordinates and a spot on the SVG map.  There are now zero translations or transformations of any coordinates, but the official coordinates make a sad and collapsing pentagon (here shown in blue).  Way off, right?  It looks like it was crushed!

The really odd thing is that the coordinates match  Google maps almost exactly. If you enter those coordinates into Google maps, the marker will land almost precisely on the pentagon corners of last year's satellite photo of Black Rock City.  Strange.

If you have any ideas about what happened, here, let me know! I'm still baffled.

Edit:  When I calculate the distances to the Man from each of these official pentagon corners, I get these values for each, which are consistent with the visuals. They should all be equal, and they should all be more-or-less 8175. As you can see, they vary from a few hundred feet to over a thousand.

BM Official Pentagon Coordinates
GPS coordinates		Distance to Man
Latitude	Longitude	GPS unit	feet
[40.78306,	-119.23568]	0.0293	8175
[40.80652,	-119.22006]	0.0240	6709.0
[40.80247,	-119.18581]	0.0262	7298.8
[40.77657,	-119.18026]	0.0282	7865.3
[40.76448,	-119.21119]	0.0226	6304.3

The mystery deepens, but so does my confidence that it's the data and not me!

By contrast, these are the GPS values I'm using, generated by calculating 5 points 72° apart on a 8175 foot radius from the golden spike coordinate. Interestingly, one of the points almost corresponds. The order's not the same, because I generated them widdershins from high noon.

My "fuck it!" coordinates
GPS coordinates		Distance to Man
Latitude	Longitude	GPS unit	feet
[40.8073,	-119.1859]	0.0293	8175.0
[40.8127,	-119.2199]	0.0293	8175.0
[40.7820,	-119.2355]	0.0293	8175.0
[40.7577,	-119.2112]	0.0293	8175.0
[40.7733,	-119.1805]	0.0293	8175.0

Again, you can see the two pentagons here: http://rendall.tv/bm/v002/map.html

BM API + dataviz

I'm having fun playing with the Burning Man API and d3.  My noodling is here: http://rendall.tv/bm/v001/

I don't know if I will ever set it up to be an actual, full, proper app, but for now it's fun to see pie charts of the types of scheduled events, or bubble charts of theme camp surface area, or bar charts of the number of events each theme camp is hosting. I'm using Ramda.js to keep the data flow reasonable. As I develop it, I will likely use Rxjs to make interaction states easier to reason about.

One interesting challenge:

I'd like to get data with respect to hometowns of the various theme camps. Data for a theme camp comes in this kind of JSON object, for example:


{"uid": "a1X0V000002rka2UAA",
    "year": 2017,
    "name": "Houphoria",
    "url": null,
    "contact_email": null,
    "hometown": "Houston",
    "description": "The purpose of Houphoria is to provide multiple spaces for unique interactions to explore all of our senses. We are a collective of Houston based makers, visual artists, musicians, and DJs coming together and creating a environment for participants to come and interact with us and our creations. By day, we're a well shaded coffee lounge and bar, but at night is when our space really comes alive with vibrant lighting, sounds, and projections." }

As you can see, the hometown for the camp Houphoria is Houston. Most hometowns are pretty clear:

    San Francisco
    Los Angeles
    Unknown
    Reno
    Oakland
    Seattle
    Portland
    San Diego

However, others are not so clear:

• Some hometown fields contain several locales, and this concept is expressed in various ways:
  
  
  • Vancouver/Louisville
  • San Frandencouver
  • Woodacre-Seattle
  • SD-OC-LA-SF
  • Portland & Bend
  • San Fran and LA
  • New York, Dubai, San Francisco, Hong Kong
  • Woodstock NY to Arcata CA, Shanghai/Bahrain/Norfolk VA
• There are several ways to express the same city. Including misspells, San Francisco is expressed variously as:
  
  
  • SF
  • San Francisco
  • Bay Area
  • SF Bay Area
  • San Francisco bay area
  • Bay Area, CA
  • San Francisco and the surrounding Bay Area
  • San Fra
  • San Fran
  • San Fransisco
  • San Franscisco
• Some camps add extraneous information:
  
  
  • Reno, Nevada (mostly), with a couple from Salt Lake City, Utah, and California
  • Ibiza. This is were the founding members of the camp met, most people are from different countries but Ibiza is the root
  • Nikola-Lenivets, GPS 54.75782,35.60123

If I do choose to tackle this, my approach will use a combination of normalization and regex to extract locales from the data, and then mapping to get a canonical spelling.

e.g: ["SF", "Bay Area", "SF Bay Area", "San Francisco bay area", "Bay Area, CA", "San Francisco and the surrounding Bay Area", "San Fra", "San Fran", "San Fransisco", "San Franscisco"] => "San Francisco")

At this point, though, I feel like answering this challenge would cease flow on more interesting challenges.

So why not simply leave it? In other words, why not simply treat the camp with the hometown of Los Angeles, San Francisco, New York as in a distinct bucket from San Francisco, Los Angeles, New York?

Well, that's what I'm doing, for now, but it feels inelegant. If the data will impart any insights with respect to understanding where camps are coming from, it will need to be done.

But, this project is about exploring the d3 framework in a fun way, not getting bogged down in implementation.  So, moving on.

Two random ideas

• My life events and career as a json file. Then it can be the data for all sorts of presentations and filters, including a resume.
• Burning Man events as a timeline map, using these two as mashups
  • This d3 sketch: http://bl.ocks.org/cmdoptesc/fc0e318ce7992bed7ca8
  • This BM API https://api.burningman.org/