Updates from garyposter 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 .


  • 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.

  • garyposter 7:03 pm on December 13, 2013 Permalink | Reply  

    Great speed improvements 

    Thanks to Matt Scott, we have some super speed and scaling improvements.

    We discovered fairly recently that the inspector was not scaling well to large numbers of units.  We wanted to support at least 2000 units or so. You can see on jujucharms.com that this wasn’t working very well.  If I go to jujucharms.com and deploy a charm with 2000 units on my machine, it can take around half a minute before the inspector starts fully showing the units.  Furthermore, the interface hiccups every few seconds afterward, being unresponsive for two to four seconds every time.  Ouch.

    Thanks to some work from Matt Scott, now the time to render the initial inspector with 2000 units is just over a second, and the subsequent hiccups are short to the point of being almost unnoticeable for me (and thanks to profiling work from Jeff Pihach, any hiccups at this stage are more likely to come from the simulator than anywhere else at this point, so it should not affect real environments).  Give it a try on comingsoon.jujucharms.com!  Yes, you can still easily scale out far enough to bring your browser to its knees, but for our current scale goals, we’re looking much better.

    For more explanation on what Matt did to speed things up, see the notes from today’s earlier post.

  • garyposter 4:54 pm on December 13, 2013 Permalink | Reply  

    Weekly retrospective notes 

    Git transition

    It’s done, and almost everyone has made a commit on the new tree.  No one is upset, most people are happy with the change, and we all give Rick Harding a big thank you.  Thanks!

    Next steps are to send the Juju Core team an update with where we are.  There are a few warts with what we’ve done (notably the fact that our imoported history is ugly).  We find them acceptable, but if they want to fix some of them up, we’ll gladly ride on their coattails.

    Where should our docs be?

    We’ve kept our docs in readthedocs, but we don’t use them much, if ever.  Meanwhile, git does a really nice job of rendering Markdown and ReST itself.  Should we just embrace github’s docs and make sure that our links work in github?

    Answer: yes.  Rick will make this work.  And we deleted the readthedocs site.

    What magic did Matt Scott do to make the GUI’s inspector scale so much better to a couple thousand units?

    Notes from Matt.  Thanks!

    • d3 wants its own objects (meaning, since everything is passed by reference, it’s better to wrap (see boundingbox in source code)).  Not using wrapped objects was the source of links showing up in the wrong sections (attributes on units were being overwritten due to units being refs)
    • d3 will be as efficient as possible in computing joins with data/enter/update/exit, but it will do so on in-memory data, not dom.  Tying things to the dom was the main source of slow-down – filter should have taken place on objects (first arg) rather than dom nodes (this).
  • garyposter 4:55 pm on December 6, 2013 Permalink | Reply

    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 12:36 pm on December 5, 2013 Permalink | Reply  

    New Juju GUI 0.14.0, Juju Quickstart 0.5.0 

    We are very happy to announce new versions of the Juju GUI and the Juju quickstart plugin.

    On the GUI, this work represents part of our current drive to make it a more effective day-to-day tool.  For example, in the service inspectors, errors are now categorized by type, rather than grouped as “Error”, so you can see at a glance what’s going on.  Error details are displayed more clearly and reliably.  Services that are in the process of being destroyed don’t disappear immediately, so you can follow along and make sure there aren’t any problems that need your attention.  Bundle deployments now give you better feedback so you have some insight into what’s going on.  And so on, with other related features and bug fixes.  More exciting work in this direction is coming, including long-requested features like per-unit debug logs and local charm deployments!

    The quickstart plugin is nearing feature completion, and has a lot of nice additions.  For new users, if you don’t have Juju installed, after it adds the stable PPA to your system and installs Juju, it will create an environments.yaml file that you need to edit.  For everyone, when you run quickstart, it will automatically log into the GUI for you as long as you accept the security certificate in your browser within two minutes of it appearing.  We also fixed a bug triggered when your default series was not precise.  The next release will guide new users through creating environments.yaml interactively, and then we intend to declare our first quickstart effort to be feature complete.

    To try out our new releases, existing users can upgrade their GUI charm to cs:precise/juju-gui-81; or run “juju deploy juju-gui && juju expose juju-gui”; or update the juju-quickstart plugin via apt and run “juju quickstart”.

    New users on Ubuntu can do the following to get everything installed and 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
    [...edit ~/.juju/environments.yaml file...]

    Next quickstart release will hopefully remove those last two steps.

    New users on other operating systems can’t use quickstart right now, but the Juju installation instructions can get you started, and “juju deploy juju-gui && juju expose juju-gui” can add the GUI to your bootstrapped environment.  More documentation is available!

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


    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!

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