Updates from January, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 4:37 pm on January 30, 2014 Permalink | Reply  

    Weekly retrospective 

    Jeff: Refactor inspector & factory.  We should have docs to instantiate inspectors.  We will need to do more of this (such as for local charm work).  We can also make some nicer factories. Rick: agree.  Gary: a day to make better docs and a nicer factory sounds reasonable for now, but I question whether it’s the right prioritization to do more refactoring.  Jeff: We will need it for machine view.  Rick: Yes.  So let’s do that bigger refactoring when we need it.  Gary: We don’t need the bigger refactoring for local charm work, right?  Jeff: Right.  Resolution: Jeff will add a card in the local charm lane for a small doc/factory improvement, and we note that we will need inspector refactoring for the machine view effort.

    Benji: Sidebar auto open/close postmortem.  Getting the prototype done was easy and fast.  Getting the tests done was difficult and slow.  I’m afraid the difficulty of writing tests is snowballing.  Discussion points include test friction, architecture visibility, architecture enforcement.  Rick has an idea of dividing the application into layers which might help; if we do that then we should automate the limitations.  Jeff: I agree.  When I spoke with Ben about architecture a while ago we agreed that we wanted layers but we didn’t agree on a transportation layer.  Therefore the layer idea didn’t develop as well as it should.  Benji: Right.  To clarify the ideas of layers, upper layers can communicate directly down, but not reverse.  Jeff: Yes, that’s worked for me in the past.  Rick: Further to Benji’s description of what I want from layers, upper layers only talk to layers *immediately* beneath them.  If upper layer A connects to lower layer B which connects to lower layer C, then A should only talk (and hear directly from) B.  Benji: Jeff, could you unpack the idea of a transportation layer?  Jeff: […sorry secretary was typing and lost the content…].  Benji: Can we agree on layers and then move to a separate discussion on what we communicate and how?  Gary: If we don’t agree on what we are communicating, we might not agree enough on what a layer is, but let’s give it a try. 🙂  […Lost discussion…] Rick: Rather than talking about layers, we can talk about who owns what.  The app layer owns the environment view.  Therefore if the inspector needs to make the environment view get smaller, then the app needs to learn of this requirement, and then communicate it to the environment view.  Jeff: Transport layer is possibility to move away from events and still get layers.  Chrome events might help.  Rick: I’d like to see if we can have experiments to make debugging events easier.  Gary: [Says stuff advocating using functions as the standard, and events as the exception.]  Francesco: It worked well in quickstart and GUI charm.  Maybe the distinction is that external interactions (websocket, UI calls) are events and everything else is functions.  Rick: What Gary is advocating is similar to what I’m proposing. [Gary nods] Jeff: Passing a function down that gives functionality is unusual for JS; callbacks that alert is more common.  If we want to take these patterns then we should agree. Matt: agree, similar to Promises.  Gary: Except promises are viral.  Rick: […Comment lost…] Benji: […Comment lost…].  Rick: Pre-imp call would help make this happen.  Gary: Will create retrospective card for discussion two weeks from tomorrow.  Gary will be out that day.  Goals will be to agree on a first cut of the communication mechanism (events, functions, ?) and on what the impetus will be to cause the changes to occur gradually and regularly (pre-imp, or Benji’s automated “ratchet” mechanism like the documentation tool we have, or something else or in addition).

    Rick: makeContainer autocleans.  pattern: hooks into afterEach, make sure you clean up your objects.  Needs the test context.  pushes callable onto cleanup stack. See makeContainer for pattern if you want to make your own autocleaning code.  Gary: switch from FIFO to FILO for running cleanups?  Rick: Agree.  All: YAY on autocleaning makeContainer!

  • garyposter 7:02 am on January 26, 2014 Permalink | Reply  

    weekly retrospective 

    Jeff: tests were failing because elements made by test util makeContainer were being left around. If you use makeContainer, explicitly destroy it at the end of your tests. There are still instances of this problem existing. Gary: automated process? Rick: have everything generate destroy methods. Gary: is there a way to make this part of our normal mocha usage? Jeff: yes, mocha plugins. Action item: Gary will make card to prototype how makeContainer could work with more automated destruction.

  • garyposter 9:11 pm on January 21, 2014 Permalink | Reply
    Tags: , ,   

    Juju Quickstart 1.0: Try it out! 

    Following on from Francesco’s 1.0 announcement, I wanted to reiterate our goals for the project.

    Juju Quickstart helps both new and experienced users quickly start Juju from Ubuntu. Francesco Banconi led the project, and he and the GUI team did a great job with it.

    Juju Quickstart is a command-line tool that quickly starts Juju and the GUI, whether you’ve never installed Juju or you have an existing Juju environment running. Features include the following.

    • New users are guided, as needed, to install Juju, set up SSH keys, and configure it for first use.
    • Juju environments can be created and managed from a command line interactive session.
    • The Juju GUI is automatically installed, adding no additional machines (installing on an existing state server when possible).
    • Bundles can be deployed, from local files, HTTP(S) URLs or the charm store, so that a complete topology of services can be set up in one simple command.
    • Quickstart ends by opening the browser and automatically logging the user into the GUI, to observe and manage the environment visually.
    • Users with a running Juju environment can run the quickstart command again to simply re-open the GUI without having to find the proper URL and password.

    To install and start Juju Quickstart, run these commands.

    sudo add-apt-repository ppa:juju/stable
    sudo apt-get update && sudo apt-get install juju-quickstart
    juju-quickstart [-i]

    Run “juju-quickstart -h” for a list of all the available options.

    Once Juju has been installed, the command can also be run as a juju plugin, without the hyphen (“juju quickstart”).

    While the project is currently Ubuntu-only, Mac support could be added relatively quickly. Windows support will take more time. As noted previously, juju-quickstart does not yet work on Trusty but the related issues will be addressed soon.

    File bugs at https://bugs.launchpad.net/juju-quickstart .


  • Francesco 3:47 pm on January 21, 2014 Permalink | Reply
    Tags: , ,   

    Juju Quickstart 1.0 Released 

    The new 1.0 release of juju quickstart is available on the “juju stable packages” PPA:


    You can do the following to get everything installed and create/start an environment with the GUI running and ready:

    sudo add-apt-repository ppa:juju/stable
    sudo apt-get update && sudo apt-get install juju-quickstart
    juju-quickstart [-i]

    The change log includes the following new features and bug fixes:

    • Environments management support: allow for creating/editing Juju environments.
    • Improve SSH keys handling.
    • Unicode refactoring.
    • Improve machine errors handling.

    The trusty package is also available, but must be considered experimental and right now it does not seem to be in a usable state.

    A list of the problems we encountered using quickstart in trusty follows:

    • juju currently is not able to bootstrap an ec2 environment in trusty:
    juju-quickstart: error: WARNING no tools available, attempting to retrieve from https://streams.canonical.com/juju
    ERROR bootstrap failed: cannot find bootstrap tools: XML syntax error on line 9…

    Bootstrapping with –upload-tools and then relaunching quickstart works well. This seems to be a juju-core problem: once solved, it will no longer affect quickstart.

    • There are also problems with trusty and LXC containers. Each time I tried to bootstrap a local environment I experienced machine errors due to missing symlinks or similar issues. Also in this case, fixing the problem should not require additional quickstart work.

    That said, juju qucikstart is ready to be installed and tested, and with this release we think we achieved the goals we set for 1.0.
    We appreciate any feedback; bugs can be filed here:

    Many thanks!

  • garyposter 4:46 pm on January 17, 2014 Permalink | Reply  

    Weekly retrospective notes 

    Jeff: Chai assert.isTrue() and isFalse

    In Chai, assert.isTrue() / isFalse() do not give tracebacks in tests:

    AssertionError: navigate not called once: expected false to be true

    If you use assert.equal(…, true) then you get a much more helpful output:

    1) Application authentication creates a notification if logged in with a token:
    AssertionError: navigate not called once: expected false to equal true

    What do we do?  Three options.

    1. See if new version of chai is better and a drop-in
    2. Consider monkeypatch to switch isTrue to assert.equal(…, true) under the covers
    3. refactor every test to remove use of isTrue and isFalse and monkeypatch those out of the assert interface.

    Rick: limitations in using git branches in charm

    • create a branch from any old commit
    • push any branch to your own fork
    • set the source to your fork and branch

    @commit is only available for the develop branch of the official juju fork

  • garyposter 6:27 pm on January 3, 2014 Permalink | Reply  

    Weekly retrospective 

    Jeff: Now that our CI is working again, we can hook up stuff in Jenkins to keep track of performance.  Could be cool.  We can graph timing out or run it as a test. http://calendar.perfplanet.com/2013/measure-web-performance-with-jenkins/

    Rick: Static port for test runs.  We have random ports now because of lbox.  We no longer use lbox.  Can we go back to static ports?  Answer: YES! Benji: we can probe early and fail if port is already in use.

    Jeff: Speed up tests dramatically by running them in mocha not phantom (requires splitting them up).  Testing strategies (Mocha, Phantom, Selenium).  Some tests do not use DOM (-> Mocha, super fast, 2x Phantom); some need DOM (->Phantom); some need browser (-> Selenium, slow).  Could speed up testing locally (but improvement would be noise in Jenkins).  Benji: would encourage us to write more, faster unit tests.  Outcome: Jeff will create card to incorporate pure-mocha testrunner.  People will then be encouraged to write new tests using it.  Refactoring old tests to use it will be engineer-driven slack tasks.

    Gary: Let’s try floobits.com for pair programming.  Volunteers to try it out with me?  Yes.  Brad first, then Benji and Rick if it seems to work out.

    Benji: Object literals in tests can suck.  Object factories help make one place to change.  Action: Rick will make an empty tests/factory.js to put factory code in.  We will put factories there, as needed!  We prefer to have the models be sufficient test factories, if possible. We have further discussion on what belongs in factories.  We suspect test/test_environment_view.js might be our best example of what we don’t want to do.  We talk about the fact that mocking output from external sources (delta streams, charmworld output, and so on) literally can make sense for some kinds of tests.

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