Tagged: weekly update Toggle Comment Threads | Keyboard Shortcuts

  • mitechie 4:13 pm on April 4, 2014 Permalink | Reply
    Tags: weekly update   

    Juju GUI team weekly update 

    Matt brought up an interesting point that while fetching the values for HTML node attributes, browsers can return different things. In one case, Firefox returns null while Chrome returned “”. The value was getting a .split() called on the result which worked in one browser and failed in another.

    Watch out folks.

  • mitechie 7:05 pm on March 28, 2014 Permalink | Reply
    Tags: weekly update   

    Juju GUI team weekly update 

    Jeff suggests we look at a way of creating ‘saved state’ in the GUI to help us work on the new machine view features. Often, these require there to be an existing environment and a way to replicate our old rapi json environment states in the sandbox would be a welcome tool. Jeff is investigating what we can do to load such data from localStorage or other locations before the App processes. Thanks Jeff!

    Rick brings up that QA day has fallen by the wayside a bit. We should bring it back and make a good attempt to keep ahead of QA issues while we’re churning the code base so much for machine view. All agree this is good and Rick will poke people during their QA day to help remind folks.

  • garyposter 4:55 pm on December 6, 2013 Permalink | Reply
    Tags: weekly update   

    Weekly retrospective notes 

    Francesco: juju-test our charm, current status, future plans

    juju-test had a preferred solution a few months ago, but that might no longer be the case, possibly in favor of some upcoming internal juju feature. What should we do?  We could build the functionality ourselves or contribute to juju-test.

    Rick: Let’s coordinate with the community and try to contribute to juju-test.

    Gary: +1 with Rick, but let’s stick with what we have until we have to build the next big charm feature.  Then we can look at the landscape and decide how we want to refactor.

    Gary: how do we kill pyJuju support?

    After discussing options we agree on the following.

    • We will announce that the last release of the GUI was the last one to support pyJuju.
    • If someone begs us to fix a pyJuju bug, and we’re willing to prioritize it, we will branch from that release.
    • The next GUI release will be 1.0.  This will signify breaking compatibility with pyJuju, and also align with our move to Git.  Per Jeff’s warning, we will want to do extra QA for this release, but it already aligns with the kind of work that we are doing this month.
    • This will also mean that new versions of the charm will no longer support pyJuju.

    Gary: stub function approach in test/utils.js

    Look at makeStubMethod and makeStubFunction in test/utils.js. They seem like a worthwhile experiment.  Please keep them in mind when coding and reviewing.  Improvements welcome!

    Gary: formalization of story lead role

    XXX Expand

    Rick: opportunity to shorten daily calls

    Jeff: YUI Theater hangout about the GUI

    Promote it!  Share it! http://www.youtube.com/watch?v=lJPdH8xmOWg

    Rick: switch to git today

    Read the HACKING doc!  Also see the lander’s README.

  • garyposter 4:31 pm on November 15, 2013 Permalink | Reply
    Tags: weekly update   


    Jeff: We have been using anchors even for links that are not supposed to change the URL.  This causes problems with PJAX and is annoying to work around.  Suggested resolution, after discussion: anchor tags should only be used for content that has an href and intends to change the URL.  We should use classed & styled button tags for other in-line controls.

    Gary: why buttons (rather than, say, spans)? Jeff: Because they allow you to support tab and focus support. Gary: But the semantics of an anchor are sometimes correct, right?  If the text is in-line?  Jeff: they are only right if they are a link; otherwise they are a control–e.g., a button.

    Everyone: OK!

  • garyposter 4:57 pm on November 8, 2013 Permalink | Reply
    Tags: weekly update   

    feature flag notes 

    Benji suggests these feature flag rules

    • Check negative featureflags, not positive feature: in other words the new behavior should be in the main path so you can simply rip out the old path when you are ready.
      • Rick mentions that this will not work out sometimes.
      • Resolution: we prefer this, but it doesn’t always make sense.
      • Benji: if you have a flag check that includes another condition, don’t do it.  Benji can lint this!
    • Check feature flags as few times as possible
      • Lint this?  Rick mentions that this might be unpleasant in some cases. We do not pursue.

    We also liked the effect of old soon-to-be-deletable class subclassing new class, the way charmworld does in; and we liked copying the old tests so we can delete them.  Duplication is OK for tests that will go away.

  • garyposter 3:50 pm on October 11, 2013 Permalink | Reply
    Tags: weekly update   

    Make it hard to do the wrong thing in tests 

    Matt had to fix some tests this week in which he was encountering errors because the tests were trying to connect to the real charm store, rather than using our fake charm store.  We want to make it hard to do this.

    Rick pointed out that if we change our app configuration for tests in the initialization (say, for instance, in the test’s index.html) to an empty value then we will use a fake store.  We agreed that this was a simple, good approach, and Matt created a card for it.

  • garyposter 3:39 pm on October 11, 2013 Permalink | Reply
    Tags: weekly update   

    Javascript promise error handling tricks 

    Jeff shared some JS Promise wisdom.

    (1) If you use promises, end with a .then(null, your_error_handler) so that any errors in any previous success handler  are caught.  Otherwise the error will be lost–it won’t even show up in the console.  This can be very annoying for debugging!  Note that .then(your_success_handler, your_error_handler) is not the same: in that spelling, if your_success_handler fails, the error will again be dumped on the floor, rather than passed to your_error_handler.

    (2) If you use promises in a test, have the tested function return the promise so that you can say .then(your_assertion_function, done).  The “done” is the important new information in Jeff’s hint: it keeps the test from hanging on error.

  • garyposter 3:22 pm on October 4, 2013 Permalink | Reply
    Tags: weekly update   

    Domain logic in view code: policy 

    When a view wants to show an immediate reaction to a user request, rather than mutating the database directly, we prefer to annotate the database.  Moreover, we prefer to provide conceptual calls within our database layer that do the annotations; the views will only call the database layer methods.

  • garyposter 4:03 pm on September 27, 2013 Permalink | Reply
    Tags: weekly update   

    Bugs vs Kanban 

    Problem statement: Our bug tracker does not track our work well.

    Response: Yes, we think this is OK.

    Proposed policy:

    We make kanban cards for actions that should happen soonish, honoring the limits we’ve placed on non-feature card count so that we keep the kanban moderately gardened.

    As always, we may file bugs for cards if we want more room to discuss, or if we want to upload artifacts, or if we want to use it as a broadcast mechanism.

    We do file bugs for issues that we want to acknowledge but are not scheduling to address.

    Bugs are a way to communicate to us.

    All new bugs should be triaged in order to encourage good customer relations.  We need to address this.

    If team members file a bug, they should immediately triage it or arrange for it to be triaged.

    There are only three bug prorities we use: critical (hair is on fire! immediate action!), high (we have scheduled it and/or are tracking it on the kanban board), and low (we acknowledge it but have not scheduled it).

    We don’t care about milestones, or associating bugs with milestones.  Our release notes are where we communicate progress to deeply inserested customers.

    Next steps:

    We should come up with a mechanism to make sure that new bugs are triaged.

    We need to bring this up with Rick.

  • garyposter 3:49 pm on September 13, 2013 Permalink | Reply
    Tags: weekly update   

    Jeff: Call toArray() on lazy model lists when they are in an object you call deepEqual on.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc