Question: should we conditionally load some JS code, particularly for the code browsing experience?
Updates from May, 2013 Toggle Comment Threads | Keyboard Shortcuts
Slack: how are we doing?
Alright now, but messy. When we have stories our WIP limit is too high.
- Gary will garden the kanban board to remove cards we don’t want any more.
- Gary will tighten the WIP limit when we start our stories in earnest (and move the story lanes to the top of the board).
Ben pointed out that our process means that we often can’t land things within a few hours, and that this discourages productive use of slack time. We acknowledged and while we would like to change our process to make short time spans more easily productive, we feel that prototyping, learning new technologies, and simply starting something that you know might be paused and turn into waste, are acceptable and useful uses of time.
Tests on Go.
One part is CI. Gary will find someone willing to work on this with Marco to see if we can work with the ecosystems efforts.
Another part is the sandbox. It currently only implements Python. We should have Go. We made that a high priority card to begin now.
Yesterday we landed a change that moved the charm browser to be behind a feature flag instead of a hidden url. That means you no longer can access the browser with /bws urls. You’ll need to turn on the feature flag like so:
Matt: how much do we need a fakebackend and CI for jujucore.
Ben: fakebackend is ok but we need new translation layer.
Gary: My priorities:
- CI against juju core most recent release
- fakebackend is required too
- CI against juju core trunk
We are over time. Please comment on blog post!
Brad: Making a charm release now means pushing to a new group’s branch. This means that when we update our own charm branch with a problem, we see it before everyone else. tarmac still coming soon.
New branch is lp:charms/juju-gui
Us: we all cheered, very quietly, inside.
Reminder: don’t leave active card around on vacation. Options to resolve, from best to still good, are these:
- actually land the card!
- explicitly hand off the card to a volunteer
- send an email to the list with enough information for someone to take your card further
This includes cards that need to land (post review).
jeff: slimerjs is like phantomjs but for Firefox. Would it be nice to run these as part of our build step.
ben: ok if it is packaged nicely. Otherwise concerned.
jeff: yeah not in npm
us: keep an eye on it, not mature enough for us yet.
Benji: dependencies shouldn’t be under app
Can we move our assets not under app?
ben: bower: package manager for browser dependencies
gary: postpone until YUI supported?
ben: yeah, maybe.
gary: simplest thing we could possibly do would be to make a vendor top-level directory; move yui and d3 and anything else we didn’t write there; change devel server to look over there for the vendor files; and make sure that build-prod and build-debug continue to put the vendor files in the current location. Additional steps could be to investigate lib/views and do stuff.
gary: I like reflecting what we serve.
benji: app and vendor directory mimic what we serve as much as possible.
us: ok, cool
resolved as plan.
Nicola: our code is complicated. What can we do to follow our code better? Would inlineCallbacks help?
charm.js and backends have events which make it harder. We are already using JS-style inlineCallbacks, effectively. We don’t think this would help.
Matt has documented events which helps. Can we add an event system debug mode? Does something exist that helps?
Ben: replace Y.log with a console.group
Jeff: Turn on YUI debug files. Filter logs?
Ben: console.trace gives you stack
Gary: how do you do to figure out what callbacks are even registered?
Ben: Chrome dev tool timeline rocks, but is hard to get started with.
Us: Help us!
Resolution: Ben will figure out an easy path to enlightenment for us.