It's Friday!!!

It's been a very very very busy week. I'm going to break this down by day to keep things simple.


On Monday, my team for the CDOT Dashboard went into overdrive to complete the Demo for our presentation the next day.  I did a complete overhaul of my Fedora-ARM build status widget so that it looked waaaaaaaaaay sexier :D The overhaul included ditching coloured backgrounds and using icons instead, as well as syling it with borders to separate the different builds. See a demo here

I then worked with dsief to hack his popcorn blog plugin to suit our needs for a dashboard widget.  it worked, but the html and CSS google's feed API was returning was terrible. Therefore I hijacked there style sheet and modified it to suit my needs. :D I'm no designer, and I'll admit it was still pretty ugly haha, many thanks goes out to Jon Buckley for making it look waaaaaay better for the demo the next day!

Jon liberated some CSS from an unknown source and used it as the basis for our demo.  It was a pretty damn sexy looking layout I might add. I tossed in my  build widget and the feed widget and pushed it all upstream.  With that done Jon told me about a widget he thought would be useful in the future.  This widget would receive an array of objects. each object would contain a date property and a text property. The widget would also receive a page length.  It would then proceed to create data lists ( <dl> ), wrapping the date in a <dt> and the corresponding text into a <dd>. each datalist would contain up to the page length value of entries. for example,  I pass in 45 date/text pairs with a page length of 10. the widget creates 5 datalists each containing 10 entries (except the 5th, which contains only five.)  As they are created I give all the same sequencing class name.  once appended to the DOM, I use Scott's Sequencer.js to sequence each of the datalists so that they all display one after the other in the same div.

I know some people might have gotten lost back there, so here's a simple example of what the end product was.


Tuesday the team presented our dashboard to (almost) everybody at CDOT. It was received VERY well. here is is :)  We got a lot of feedback and filed a whole bunch of issues on Git Hub.  later that day the JavaScript team met Bobby Richter, who works for Mozilla, and discussed the immediate path for popcorn.js and butter.js.  We did some triage on bugs filed on lighthouse and divided up tickets.  I also spent time looking over Rick Waldron's Sequencer.js code


Most of Wednesday I spent familiarising myself with Rick's sequencer code and how it interacted with popcorn.  I worked with Rick to fix some issues with switching videos and pre-loading.  By the end of Wednesday I had a fair understanding of the code.


On Thursday I continued my work with Rick on the sequencer.  The evening before I wrote a patch that paused the last video in the sequewnce when it reached it's out value.  This got merged with Ricks repo :D He asked me if I could write some unit tests for it, so I did. I still have to tweak them so that they test for the behaviour that I expect.

At around 1 Scott, Dave S, Mohammad, humph and I met with Bobby, Ben and Brian from Mozilla for discussion about the roadmap for Butter.js as well as Popcorn.js. It was a fairly lengthy meeting lasting several hours. by the end of it I think we were all a little more sure of the direction we needed to go to make the popcorn and butter libraries world class software.

When I got back to my workstation in CDOT Rick had good news and bad news.  The good news was that he got plugins working across multiple instances of Popcorn! The bad news was that there was a trivial bug that he could not pinpoint the cause of.  Later Thursday evening I spent hours debugging his code while simultaneously attempting to understand how it worked.

At around 10 PM I was sitting there thinking when the answer literally popped into my head... After commenting out one line, it had been solved!

Rick implemented a pass-through method for adding plug-ins to the sequence.  It takes in the options for the plug-in and determines the appropriate clips and durations to apply to the "split up" plug-ins. it's a difficult concept to describe.  The issue was that if a clip had a plug-in that began on it's "in" value, when the cycle method is called to swap clips, it would reset the previous clip to it's in value.... triggering the start method on that clips plug-in!


Today I've worked more on getting the tests I wrote to work and setting up demos on my demo server account.  I just got my tests merged into Ricks repository on Git Hub. Now I am going to get anna to show me her review process for lighthouse tickets yaaay :)

Have a good weekend everyone.