Updates from April, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 3:55 am on April 27, 2013 Permalink | Reply  

    Raring’s selenium doesn’t like Raring’s Firefox. My solution: uninstall python-selenium in the system (if you need your virtualenv to have access to system packages, as I do), make a virtualenv, and run pip install selenium after activating the virtualenv (source bin/activate).

    The symptom is that tests fail with the following.

    WebDriverException: Message: ‘Can\’t load the profile. Profile Dir: /tmp/tmpAmYXPX Firefox output: \n(process:8197): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0\’ failed\nXlib: extension “RANDR” missing on display “:1431”.\n*** LOG addons.xpi: startup\n*** LOG addons.xpi: checkForChanges\n*** LOG addons.xpi: No changes found\n’

     
  • garyposter 3:56 pm on April 26, 2013 Permalink | Reply  

    Weekly update: Jeff: New class? New file!
    Gary: We decided before that people are welcome but not required to do this. If a file is too long, split it!
    Jeff: cool.

     
  • garyposter 3:54 pm on April 26, 2013 Permalink | Reply  

    Weekly update: Matt: start using yuidoc @event?
    yuidoc has an @event doc. If we document those that would be nice. Suggest/recommend/require/ignore event documentation?
    Jeff +1 on documentation.
    Event handlers use @event; event publishers document in the class docs, method docs, or publication block.
    gary: what benefit? generally DRY violation. Can we avoid?
    jeff: Document what emits events. Publish them instead if possible
    benji: @event is about publication, not handling. http://yui.github.io/yuidoc/syntax#event
    gary: only publishers?
    benji: +1
    discussion about topology etc.
    gary: @event for something that fires an event: publish is best, fire is next best, class is next best.
    jeff: example: http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l541

     
  • garyposter 3:17 pm on April 26, 2013 Permalink | Reply  

    Weekly update:
    What do we do when a bug fix is tied into a branch that someone else is working on?
    (1) If critical/blocking, extract bug fix and land separately, and then return to the main branch
    (2) If not critical, simply have a pre-implementation call with person doing the main work to prevent duplication of work. Similarly, if you are working on a task, double-check that at least your face is on the card

     
  • mitechie 12:56 pm on April 25, 2013 Permalink | Reply
    Tags: css, design, font, google   

    google web fonts meet UX requirements 

    UX caught some places where the Ubuntu fonts were not being used. It ended up
    that currently, the GUI is only loading the base font size while we needed
    medium, bold, and mono as well (hooks content display, readme, etc).

    Updating the font api call to include the extra weights ballooned the number of
    requests to 5. I checked and I don’t think the tools displaying the readme and
    code sources are using the italic versions of the mono so I’ve dropped those.
    I also know there’s a standing rule of anti italics because they can be hard
    to read. However, the GUI was previously pulling it in so I left italics for
    the base and medium font sizes. I dropped it for the bold. This brings it to 3
    requests total to bring down all fonts.

    This is cached and the files sizes are small, but it still sucks that a change
    for UX took up from one request to three. If we could indeed drop all italics
    it should go down to two. Maybe we could audit for <em>/italics in the css and
    see if we can adjust and drop that.

    The settings I’ve setup are here:

    Google Fonts

    Would I wonder, but don’t see a good way currently, is if we could combine the
    fonts we needed into one file to download that includes the various sets. At
    least then we can trade file size for the number of requests made.

     
  • garyposter 7:11 pm on April 24, 2013 Permalink | Reply  

    This is the depths to which we descend to try and make a good UX for a field that is usually only one line, but might be many. http://jsfiddle.net/Pegsa/

     
  • Benji York 8:41 pm on April 23, 2013 Permalink | Reply  

    I’ve been investigating the speed of various things in the hopes of speeding up the deploying of a charm from a branch of the GUI. Here are some things I found.

    Downloading the release (27M) from Launchpad via my home connection averages about 10 seconds, downloading it to an EC2 instance takes about 20 seconds.

    Downloading the release from an S3 bucket via my home connection takes about 30 seconds and is pretty variable. Downloading the release from an S3 bucket to an EC2 node takes between 13 seconds and over 3 minutes (highly variable).

    Running just the NPM installation portion of a GUI build with empty NPM caches takes over 4 minutes on an m1.small instance and right at 2 minutes for an m1.xlarge instance, presumably because of the faster disk performance on the xlarge. It takes 2 minutes on my connection/machine as well.

    Running the NPM installs with a full cache and setting cache-min to 99999 takes just under 1 minute on an m1.small instance and averages 18 seconds on an m1.xlarge instance and locally.

    All of the above data suggests that we should capture the NPM cache and pre-populate it when deploying the charm against a branch. When deploying to an m1.small instance we should save about 2 minutes and when using an m1.xlarge we can save about 3 minutes and 20 seconds over an empty cache on an m1.small instance.

     
    • garyposter 4:14 pm on April 24, 2013 Permalink | Reply

      Cool, thank you.

      Interesting things to investigate further:

      • If you start an EC2 machine in an Australia or Asia region, how long does it take to download from Launchad?
      • If you put the S3 bucket in CloudFront (looks easy) what are the download times (home, ec2 in NA, ec2 in Asia/Australia)?
  • garyposter 9:06 pm on April 22, 2013 Permalink | Reply  

    Changelog. It’s good. Let’s do it. Let’s not make the person making the release have to do it. Should we have a hopefully motivational contemplation of whether a changelog has value to our stakeholders?

     
  • bradcrittenden 12:32 pm on April 22, 2013 Permalink | Reply  

    $GOPATH/bin/juju and tools mismatch failures 

    I’ve recently seen Juju failures where Juju commands fail rather than queue up like they are supposed to. ┬áHere is the output of running my shell script to deploy the GUI:

    /home/bac/projects/juju-gui> deploy-gui.sh
    + /home/bac/work/bin/juju bootstrap --upload-tools
    + /home/bac/work/bin/juju deploy 'cs:~juju-gui/precise/juju-gui'
    error: no instances found
    + /home/bac/work/bin/juju set juju-gui juju-gui-source=lp:juju-gui
    error: no instances found
    + /home/bac/work/bin/juju expose juju-gui
    error: no instances found

    The problem appears to be a mismatch between my version of juju and the tools. Updating the juju source and rebuilding solves the problem.

     
  • garyposter 3:54 pm on April 19, 2013 Permalink | Reply  

    Weekly call notes! Gary asks: Sometimes I don’t file bugs, and only make cards. Is this OK? If so, when is it OK?

     
    • garyposter 4:07 pm on April 19, 2013 Permalink | Reply

      Jeff: at a previous job, we said that bugs were unnecessary for jobs you are about to start. Rick: bugs come in handy for coordination with others, such as Huw and Antonio. Gary: others track progress with bugs as well. [Others agree in value of bugs.] Jeff: filing bugs is slow on Launchpad. Gary: filing bugs there brings me out of kanban context. Jeff: copy bugs from kanban to Launchpad? Gary: Did Graham implement this? Resolution: for now, continue as we are. filing bugs is encouraged but not required. We will investigate kanban2lp, and making it more reliable.

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