Gossamer Sprint Notes
28 May 2015
Focus #1: getting live editing rolling with webpack (monday - weds)
I got webpack bundling running within a few hours as a module bundler
- Trying to get react-hot-loader working with it. If we change all of the modules to only export one module at a time, it works. Otherwise it doesn’t. Weird.
- Build times are pretty slow, as is expected for webpack.
- Have to run the code through another build step...since webpack doesn’t support es6 properly yet. Using the webpack-2 branch didn’t work initially, but it’s possible that tinkering with it again might make something work that I hadn’t caught.
Further challenges that we haven’t hit yet:
- The hot module replacement API is designed for a single folder changing in time linearly. It doesn’t really work well for stepping "sideways" and hot-loading a different branch entirely. Possible to simulate this on the server side by having the server "switch branches" and recompile...
Movement going forward on this:
- Still unsure to what extent the developer experience needs to be real-time for testing out experiments. What features are best made real-time?
- Not sure to what extent webpack is workable (politically, at least) for this if we need to make large numbers of changes to the structure to make it one-component-per-file.
- Possibly look into shoe-horning hot module reloading integration into something like requirejs?
Focus #2: an experiments menu (thurs)
Talking with lyre: all of the experiments sharing has a lot of security concerns
Use of mozillians as a way to mark which experiments are trusted?
Switch the default manifest url, and reload the app?
16 June 2015
- Got a working version of the browser running on the web-based build infrastructure.
- Problem: Each different version of the browser is a different web app served from a different URL and has different session state. This makes it challenging to just switch to a different experiment without having your browser session seemingly disappear--all of the different experimental versions of the browser need to share the same data, or else it’ll be super strange.
- Plan: Make a single, regularly updated app bundle for a given logged-in user. All of your logged in devices get access to this same experiments server. This is super handy because then we can start
23 June 2015
- There’s a working version of the app available at: https://gossamer-server.herokuapp.com/
- Built a DMG containing a link to the manifest for Heroku, which is available at: https://www.dropbox.com/s/7b4xhhab4umuor0/graphene-41.0a1.en-US.mac64.dmg?dl=0
Tested usability of an early build with Lyre
- Feedback: current version of the login screen screen
- Issue: Updater doesn’t do anything!
- Need to ensure that all URLs (in the updater via the Heroku PUBLIC_URL config variable, and in the GitHub developer configuration) point at the HTTPS version of the Heroku instance
- In the case when the updater breaks, need a way to clear caches and reload
- Feedback: more broadly
- There’s a lot of confusion over where to login where--there’s the backend login, and then there’s the frontend login--and mostly the nomenclature around this is confusing
- Currently there’s not much of a workflow...and what little that’s there is very admin focused.
- The workflow should be browser-first:
- The Gossamer Heroku homepage should be a lot like the Dropbox homepage page
- A nice big explanation and download button for your platform to get started
- A smaller login button to get into advanced features
- After you install the browser, there’s a shiny little browser flask button
- When you click the flask button, you should get a pop out panel that lets you:
- Log in with GitHub, defaulting your experiment to the main gossamer build
- Look through and switch experiments from a list.
- Clicking a "more" link about the experiment should just take you to a GitHub branch page.
- Some sort of UI that lets you create experiments by forking projects.