Tagged: weekly retrospective Toggle Comment Threads | Keyboard Shortcuts

  • mitechie 6:49 pm on April 18, 2014 Permalink | Reply
    Tags: weekly retrospective   

    Juju GUI weekly retrospective. 

    This week’s retrospective includes a couple of discussions.

    We’ve been creating feature flags across the work we’ve been doing beyond the initial two documented and shared with others to help follow along our progress. This hurts in two ways. First, others can’t follow along with out progress as they don’t know what flags to use. Second, it hurts ourselves as we don’t see the different chunks of code working and interacting together. This could lead to more time required to bring tasks together as we drop flags and release features. The end result is that we love feature flags, but we need to keep the limited as much as possible.

    Secondly, deployments are good and everyone should be able to do one. It’s not something that should be limited to one or two folks as deployments are sometimes required at odd times due to critical situations. We all agree that everyone should try to do a deploy and Matt stepped up to be the first to try a deploy next week.

    Advertisements
     
  • Madison Scott-Clary (Makyo) 3:34 pm on March 14, 2014 Permalink | Reply
    Tags: weekly retrospective   

    Weekly Retrospective – Week of March 10 

    Jeff – every js file has a test file associated with it. We could entertain the
    idea of creating more descriptive subdirectories, within each subdir have tests
    folder, those tests would be responsible for the module in there. Lots of tests
    touch too much. Decentralizing tests could help us write better tests with more
    coverage. Benji bring sup that it makes grepping for things harder, but not so
    much as to be a -1. Rick: switching over could be expensive, and build step
    would need to be modified to account for that – investigate work involved.

    Monkey patch before/after – Jeff – If you don’t provide before/after, they won’t
    be monkey patched. Be aware that there’s no default call if you don’t include
    an afterEach for cleanup. There should be a bug to have a base afterEach that
    runs cleanups, or at least warns about that.

    Dropping charm on service block – Jeff and Matt – if you drag something onto the
    canvas and drop it on the service block it acts like dropping a file in the
    browser, leads to download. Should we bubble? Can we do an invisible overlay?
    Apparently not, there’s an issue with it working only in chrome. Decided on
    canvas only. Lets file it as a bug – if we can fix it, verify, but if we
    can’t, can we at least reject the drop? Investigate.

    Add deps into modules-debug – Jeff – Our loader file doesn’t parse nested
    requires, explicitly add module into the use section which is for a sub
    dependency. Add requires into modules-debug list to avoid recursion.

     
  • mitechie 4:21 pm on February 21, 2014 Permalink | Reply
    Tags: weekly retrospective   

    Jeff notes that mocking out Y.one and Y.Node can have nasty side effects due to their interdependence. He suggests rendering out to a container and removing and verifying existence and removal directly.

    Jeff also brings up that the Zillow guys had some good notes on building a light build of d3 by only building the modules they needed. Matt agrees that this could be easily done and will add a slack card to look into it.

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel