Updates from October, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 9:31 pm on October 18, 2013 Permalink | Reply
    Tags:   

    0.11.0 Juju GUI Release 

    As of last night, the 0.11.0 release is out (but not yet at jujucharms.com).  This one has some nice new features, a lot of good bugfixes, and a ton of work towards some almost-ready-to-release features.  Please give it a try and let us know how it goes.

    • The inspector (and the GUI, for the first time) supports upgrading or downgrading a service’s charm.
    • The masthead’s UX is improved, notably giving a bit more room for the rest of the application.
    • Relations now display the names of both endpoints in the environment.
    • The GUI distribution is now about 1/9 the size it was before, speeding up deployment.
    • Recommended charms (and bundles) are now marked with a red triangle, per results from UX tests.
    • (FIX, CLEANUP) Service coordinates were being stored in three places, leading to confusion and bugs. This code was refactored, introducing many fixes to our service positioning behavior.
    • (FIX) If the charm browser were fully open to show charm details, and the browser was minimized and then reopened, the details page would be blank.
    • (FIX) The Go implementation of the sandbox always lost the first delta from the AllWatcher’s Next method.
    • (FIX) Bundle export should not include the number of units for subordinates.
    • (FIX) Inspector scale up input was disabled forever after value change.
    • (FIX) Charm details link was not working correctly from inspector.
    • (FIX) Unit details did not display exposed URL links properly.
    • (FIX) Position annotations are once again included in exports.
    • (FIX) New units added to the canvas no longer overlap old ones.
    • (FIX) The charm “code” tab in the charm browser now sorts filenames by directory and name, to make it easier to find a particular file. It also excludes the svg files from the list, since the rendering was less than valuable.
    • (CHARM FIX) This is actually a fix in the charm, but it is an important one that is worth calling out. In some environments, the GUI would break, not allowing proper inspection, export, or other basic behavior. This turned out to be because the new server had an issue with non-ascii values in some cases.
    • Behind the “charmworldv3” flag, bundle support is ready for demonstration, including browsing and deploying, in the sandbox and in a live environment. Tweaks, bug fixes, and some approved bundles should take us the rest of the way soon. This comprised a very large portion of the work behind this release.
    • Behind the “onboard” flag, the GUI has work to show helpful onboarding for new users.
     
  • garyposter 12:25 pm on October 15, 2013 Permalink | Reply  

    If you want to run a custom GUI branch in a real juju environment, it can add quite a bit of deployment time to get the build dependencies. Since Francesco added the local charm release option, I’ve been using a fun quick hack to make it faster to try a branch live. In a local branch of the GUI with the changes you want, run “BRANCH_IS_GOOD=1 make distfile”. Then move it into the “releases” directory of a local copy of the charm, and delete the other release(s) in that charm directory. Finally, run “make deploy” in your charm. Your branch will be ready to test a lot faster!

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

    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:   

    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:   

    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 11:10 pm on October 1, 2013 Permalink | Reply
    Tags:   

    Juju GUI 0.10.1 Released 

    Today we released Juju GUI 0.10.1.  This includes many fixes, listed below, as extracted from the changelog.

    • Add icon for exporting a bundle.
    • (FIX) The GUI was unusable when cookies were turned off in your browser.
    • (CLEANUP) Use service model in ghost inspector, rather than charm model. This is a nice cleanup and also enables a true environment-wide “save” button in the future.
    • (FIX) The GUI was unable to deploy charms without config options.
    • (FIX) Remove unit button did not work in Juju Core.
    • (FIX) The inspector’s unit view did not update when the unit’s values changed. Now everything except for the relations updates. Relations have other issues that, in part, need in-progress changes in Juju Core to work.
    • (FIX) Changing settings did not work in Juju Core.
    • (FIX) Removed broken and largely unnecessary “All Notifications” link. More, better changes will come there soon.
    • (CLEANUP) As part of bundle work, clean up some browser templates for general improvements and for better re-use.
    • (FIX) After saving a service config, old, unchanged values would seem to disappear, and then reappear a few seconds later.
    • (CLEANUP) Remove the serviceInspector flag code and some of the now-irrelevant old view code.
    • (FIX) if a service is destroyed in the command line, the inspector should close when the service disappears.
    • (FIX) subordinate charms should not show constraints and should not seem to allow control of scaling.
    • (FIX) destroying a service would hide it too soon, causing surprises if the destruction failed. It now disappears when it is destroyed.
    • Behind upgradeCharm feature flag, complete implementation of support for upgrading a charm in the GUI. This will be released in 0.11, very soon.
    • Behind charmworldv3 feature flag, add more support for bundles (model, search results, featured list, initial token, better sandbox support, etc.).

    We have not yet deployed this to jujucharms.com.

     
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