This past week, I traveled to Revelstoke, BC for an Appmaker workweek. Appmaker is an application designed to enable anyone to create mobile web apps without needing to learn about coding. By combining various widgets together and connecting their inputs and outputs to one-another using the visual interface, users can create customized applications to use and share. The purpose of the work week was to have a code sprint on Appmaker, it's components and to get Webmaker ready for integration with it.
I had a couple of goals in mind going into Revelstoke. The first was to learn about Appmaker's code base and to learn the how easy or difficult getting started as a contributor is. My second goal was to help transform Webmaker so that we could integrate Appmaker with Webmaker services like the Log-in Server and Make API.
My first couple of days in there were spent exploring and writing components for Appmaker. Components are small pieces of standalone code that accept inputs and emit outputs. Appmaker components are built using a Web Component framework called Polymer. Instead of writing a component from scratch, I started out by re-writing the Fireworks component written for a previous version of Appmaker. The fireworks components will animate fireworks on a canvas element when it receives instructions to do so.
My first step when porting the fireworks component was to create a new repository on GitHub for it. Next, I copied all the files from the already ported button component into my new repository. Annoyingly, modifying each file was tedious work, and really needed something to speed up the process (The solution is linked at the bottom of this post). Following my setup, I started working on porting the legacy component code into a Polymer element. This work was surprisingly straight forward, and didn't take too much time. It was mostly a copy, paste job followed by minor edits and refactoring to get the component working. Other problems I ran into while porting included garbage stack traces in Firefox Nightly (maybe due to the polyfills for Web Component support) as well as a bug I found where loading components in Appmaker when using a case-sensitive file system.will fail. Should you be interested, you can find the repository for fireworks component here.
I have also ported an image displaying component and an HTML5 Audio playing component. I attempted to write an HTML5 audio recording component, and had some successes getting WebRTC's getUserMedia function working. Sadly, it's not easy converting recorded audio into a playable file and on top of that, the loading of external scripts in a polymer component is really janky, so I decided not to waste much time on it and get started on the MakeAPI.
Following my work on components, I took a look at the Make API with Jon, and decided what we should do to help Appmaker get in on the party. I started by reviving a 4 month old patch I wrote which associates every Make on the Make API with the API keys that created it. This lets me ensure that all write actions initiated by an app will only be permitted on makes that were created with the app's public and private key-pair. This was easy enough to rebase and get reviewed, and within a few hours it was running on staging. Secondly, I discovered a pretty bad crash bug in the Make API which blocked having Appmaker publish. The Create/Update routes run a filter on all tags passed in, and setup for the middleware checks if the user account creating a make has sufficient permissions to apply application tags. unfortunately, if that email is not provided or, in Appmaker's case, it is not an email with a valid Webmaker account, the call will fail. I have subsequently added logic to allow makes without emails or emails we don't know get created, and all app-tags are stripped by default.
The last thing I did to the Make API was alter the Make model to contain a remixurl and an editurl field. These fields will allow third party apps to define explicit remix or edit links that can be followed to do said action to a make, rather than force Webmaker's /remix and /edit method. With that completed, I turned my attention to Appmaker itself to see what needed to be done to get it publishing makes to the Make API. Lucky for me, most of the work had already been done! There was a problem where the public and private key-pair were being mixed up, causing every request to return a 401 (Authentication possible, but failed). with the bolts tightened here, I successfully posted metadata about an app to my local Make API database.
I'm back in Ontario now, nursing a pretty bad cold, and looking forward to getting my hands on some more Appmaker code in the future. It's actually really, really fun to play with, and writing components isn't too hard when you use David Ascher's really awesome component-template to boilerplate your component before you begin!