Our current project is a web-based GUI for Juju. Juju lets you deploy connected services to the cloud in a convenient, vendor-neutral, and powerful way. The GUI lets you visualize and manage your work (see also another blog; a demo of our trunk, which is reset every 15 minutes; and the project itself). We've been working together with the Cloud Ecosystem Development team at Canonical on the project, with Kapil Thangavelu as the technical architect.
At the recent Ubuntu Developer Summit, we got feedback, had user tests, sprinted, and made plans. Right now, we are working to make it easy for anyone using Juju to deploy the GUI. We also have a refactoring of the environment view in progress.
We've had a lot of project meetings before the release. I published those notes internally. Since we open-sourced, I've been swamped. We've had a number of meetings, and I have a pretty big backlog of decisions to record.
Therefore, to get back in the swing of things, the rest of this post will be a record of decisions and hints from the the past few meetings. That will catch us up, and we can proceed from there at the next meeting with notes more like what I've given in the past--both project status notes and decisions and hints, with the decisions hopefully better grouped so you can find what interests you more easily.
gary_poster: Keep Us Out of the Weeds
We've been having some in-the-weeds discussions lately in our larger meetings that did not involve everyone. This can waste the time of the people who are not participating. It also can cause disagreements to have an audience, which sometimes seems to lead the discussions to have unnecessary and unpleasant drama.
If a discussion gets in the weeds, we'll give it a couple of minutes maximum, but then ask the participants to stop and take it to the smallest responsible group of participants.
This sounds fine to everyone.
gary_poster: Kanban Cards Taking Too Long To Complete
Ideally, per our previous retrospective discussions, we have 24 hours to move a card from coding to review, and 24 hours to move from review to completion. If we don't meet these goals, it means we need to try to figure out a way to change our approach to that card, by pairing, reducing the scope of the card, asking for help to figure out a new approach, and so on.
That's useful, but it feels like we might have a systemic problem lately: a lot of our cards recently have taken longer than our goal time of 24 hours to move to review. Why might this be?
Guesses from team:
- We just started new goals. Maybe we're just getting started and dealing with a bit of ramp-up cost?
- Is the new prototype lane slowing us down for some reason? (Consensus: no).
- The UX check is slowing us down. Could we do it before we land in the usual review queue? (Consensus: Once we have fast-moving, reliable charms, that will help. goodspud also said he'd be happy to follow instructions on how to get a branch and test it. bac will help goodspud with this.)
- Don't use LXC in charm work: the implementation is too flaky. :-/
- Don't forget to pair!
We will try to improve the UX check story.
Also as part of this discussion, we mentioned that we wanted a public site based on official, qa'd releases; and a separate site that continued to track the trunk.
As another separate thread, bcsaller said that we ought to consider writing the user stories from the design team as functional tests, using Selenium. We liked this idea. We want to talk about this soon--such as on our next retrospective--to hammer out some details of how we could do this cheaply as a first cut.
bcsaller: Make a charm panel API?
Our Juju GUI charm panel is driven by events into an organically evolved API. Maybe we should step back and work on an API for the panel for a bit.
gary_poster: Sounds interesting. Let's work on it when we need it.
No disagreement.
benji: Should we change our object literal style?
We use the Google Closure linter and beautifier to enforce whitespace, in order to try to get some of the benefits that Go gets with its built-in code beautifier: standardized style that we don't have to discuss and agree on.
We have been using an object literal whitespace style that the Google Closure beautifier and linter do pretty well with...most of the time. It turns out that having every variable specified with its own "var" keyword helps the linter, though--and is best practice as far as Crockford is concerned. Is everyone OK with this?
Yes, everyone is. We will make these changes gradually as we touch the code, as drive-bys.
We are not sure if the style of the closing brace matters--should you insert a new line before the closing brace or not? Benji will investigate. If the linter & beautifier do not care, we will not specify a standard.
On a somewhat related note, hazmat raises the camel case style for names that we have agreed upon. He feels this is most important for method names. Changing the rest, like variable names as drive-bys are fine. Switching to everything at once would be nice for linter (which can enforce this) but is very low priority.
gary_poster: How is the design team's kanban workflow going?
gary_poster and goodspud had already discussed this and significantly simplified the workflow. We'll see how this new version goes and consider revising again after some experience with the revisions.
gary_poster: We should document charm-writing best practices
The majority of the team are charm-writing novices. hazmat has brought some concerns to us about the current charm. We ought to write these down so other people can learn from this, and so that we have something to refer to in the future. Here are some examples of things we have learned from hazmat as best practices. Some of them are more obvious than others.
- Separate out developer instructions into a HACKING.txt, or similar. Make README.txt only tell the user how to use the charm.
- If your charm will build software, keep your build from going over the wire as much as possible. It can be very, very slow.
- A charm without a config-changed hook is a significant usability problem.
Any others?
hazmat says that we should make a branch lp-juju-docs for this document, and then ping himself or Jorge Castro for a review and merge.
gary_poster: Please, everyone, review the design team integration document
The design team has asked us for regular and significant access to developers as they figure out how the user experience should work. I wrote up a document (Canonical-only, sorry) that describes how this might work, as well as sketching our upcoming work from a UX perspective. Please, everyone review it.
bcsaller: Don't prevent landing if you don't conform to our desired doc guidelines
In the course of refactoring a large branch, I moved a lot of code around that did not have docs yet. At the end, I could not propose the branch because our lbox check was very confused and said that I had added code that did not have docs. This was wrong. I want to make this a warning, not a complete block on landing.
gary_poster: a warning, especially one with a lot of blather, will be ignored.
benji: The point of the check is to force the developer into making a conscious decision. We could instead make a command that regenerates the "undocumented" list that allows exceptions to the check. Would this be OK?
bcsaller/gary_poster/all: yes, thank you.
ACTION: bcsaller to create card for benji to make this command (Already done).
benji: Makefile tweaks
I'd like to change our Makefile to conform with best practices. Here is the list:
- Variables should be quoted.
- Local paths don't need to begin with "./".
- Use four spaces for indents where legal so we have more room for text when tabs are rendered at eight spaces.
Some of us were mildly grumpy at the last item (using spaces for indents) but we were generally approving and appreciative of the proposed changes.
gary_poster: a new style of mixing mocha tests with YUI 3
We have some recently changes introduced in the code base that wraps our Mocha tests with a YUI.use. This was done to eliminate some intermittent test failures, and it is nice to follow the standard YUI advice. However, frankban discovered that it breaks one of the Mocha testrunner features that we like: grepping for tests.
We agree that we want to revert the recent changes in order to preserve the testrunner's grep feature.
benji: static serving vs. pretty URLs
We recently started serving our code statically. However, because we use the YUI app framework using the "full-path URL" approach, this means that the generated URLs can only be bookmarked and shared if we use a server that serves our index.html for all paths without matching files (essentially as a 404 page without the error). How do we want to reconcile this? Should we switch to the hash approach so we can use super-simple serving, or do we want to require a smarter server?
hazmat confirmed that we wanted the full path/smarter server approach.
bac: Landing your code should include ensuring it works on staging.
We've had problems lately because people did not verify that their branch worked on staging. We have a "Landing & QA" lane on our kanban board. Please don't move your card from that lane until you've confirmed that everything is copacetic on the staging server.
all: agreed. Sounds good.
bac: Please link cards to Rietveld
Many of us are accustomed to working from the kanban board for coding and for reviews as well. Please make sure your card links to the Rietveld review URL for your branch. If you have hooked up your card to a bug and your branch to the bug, then our lp2kanban automation will do this for you.
all: agreed. Sounds good.
gary_poster: Two-person reviews: how are we doing?
We've been working with two-person reviews for a while. Is everything going along OK? Any concerns?
Makyo: The only concern I have is that I think sometimes people are not clear whether we can land our branch. Could we standardize on something to clarify what people mean?
gary_poster: Here's a strawman. We have three options.
- Land as is
- Land with changes (specify explicity with "REQUIRED" if change is required
- Request re-review
all: sure, that's fine, whatever, man.
gary_poster: No yuidoc @function
YUI doc is very OO oriented and has no explicit function tag. That's a bit odd, and doesn't match what we have very well. The workaround suggestions don't seem ideal to me. What do we want to do?
[I did not record the answer. I think we are just not putting a type tag on functions.]
bac: LESS and string interpretation
CSS Rounded corners have a syntax that can look like division. LESS wants to divide numbers in this case, but that is not what we want.
HINT: to prevent LESS from an interpreting a string use ~"", like this:
property: ~"my crazy string here"
benji: vertical whitespace
Some of us don't like vertical whitespace, and I miss it, before methods especially. Could we have some please?
Discussion ensues. Our linter does not have an opinion about vertical whitespace. Some people find vertical whitespace to sometimes be applied seemingly haphazardly. Should we try to standardize on rules?
We do not all agree about an approach, and no-one cares a ton. I don't remember what we decided. I'm going to pretend I remember, and say that vertical whitespace between methods is encouraged, and other vertical whitespace is discouraged. If you really want to divide up your functions with whitespace, consider making separate (nicely factored) functions instead. If you desperately want vertical whitespace in your function, follow it with a comment to explain the purpose of the next code block.
bac: Improve specs/assets from designers
The delivery via Google docs of the design and assets is a bit of a mess. We had discussed DropBox and would prefer it. Even if we continue to use Google I'd suggest using one zip file of current assets. In addition, these approaches would help.
- All specs delivered in a CSS-friendly way, i.e. no 1px x 72px images for backgrounds. State the colors, heights, etc.
- Color defined as name value pairs and then referenced by name.
ACTION: Gary will set up the DropBox (already done).
Makyo: Simulating click events when location is important
If you need to simulate a click event when cursor location is important (such as clicking on a service module), you can pass an object with some event params, such as clientX and clientY. YUI's documentation on node-event-simulate is scattered around; see http://yuilibrary.com/yui/docs/event/simulate.html
Also, it's nice to factor out event handlers and actual work, so that you can test the work separate from events if necessary.
We agree. :-)
1 comment:
Heh, I was asked that myself. :-). Thanks for clarifying.
Post a Comment