There have been a number of problems, and some interesting workarounds in order for Lindsey and I to create a screencast. Our requirements were as follows: One of us needs to run through using a number of programs (web browser, shell running our scripts, and our graphical api tool). These actions are going to be recorded by screencast software, while we talked over top. Both people need to be able to view the contents of the screen during the recording.
The recording has to be done on Lindsey’s Linux box, as I cannot get his graphical tool to run on my computer (It is worth mentioning that the tool works fine on Lindsey’s computer, and is not one of our deliverables). One of the required components gtk would not install properly on my system. I need to install it through a program called macports that deals with linux->mac ports. The program had at least 100 dependencies that all needed to be fetched, extracted, verified and installed. On at least 10 occasions, one of those dependencies failed and had to be manually installed. Once the program finally ‘installed’, it still didn’t seam to work. So, I found another installer for a comparable gtk tool that could be installed via a shell script. This also didn’t yield any results.
Next in need of replacing was our original screencast software, a web-based program called Screenr (which is mainly designed for screencasts to share on Twitter). Unfortunately, the program does not run on Lindsey’s Linux machine. At the same time, Lindsey was having some issues with setting up a VNC Server to share his desktop.
We replaced VNC with Skype, as it can do screen-sharing (it works quite well), and Screenr with a linux utility called gtk-recordmydesktop. This introduced the next problem, getting recordmydesktop to record both Lindsey’s mic, and my audio. After many attempts involving configuring settings, all manner of hacked together cables, and a program called JACK (which probably could solve the problem, but is a complex program) we decided the only two real options were cranking up Lindsey’s speakers and recording my audio from the speakers (much like how NASA’s moon-landing video was shot by pointing a camera at a television), or to have my audio overdubbed. dubbing at this point seemed like the best option.
We wanted to be able to shoot the video in segments, and combine + crop the segments together. Youtube could handle combining and cropping, but not the dubbing (it seems), so this meant we needed to use another program for overdubbing. I own iMovie, so it seemed like the best bet. The only issue is that iMovie is really picky about the files types it can load.
recordmydesktop creates ogv files. Lindsey found a tool to convert the files into AVIs (or more correctly ISOs containing AVIs. iMovie kind of pretends it can load AVIs, but it is lying. Luckily, in the meantime, I had found a program called Handbrake, which can convert AVIs into MP4s. These MP4s can then be loaded into iMovie to be spliced together.
The overall system works as follows:
- Lindsey runs the various programs to be shown in the screencast
- The programs are recorded by gtk-recordmydesktop and saved as OGVs
- A stream of Lindsey’s actions are sent to me via Skype’s screen-sharing tool.
- my audio is recorded (probably using quicktime, maybe Garageband)
- Lindsey converts the OGV to an AVI in an ISO using devede
- Lindsey creates a tarball of all the AVIs using gunzip
- The tarball is sent to me using Yousendit, Skype or Dropbox
- I unzip the tarballs (using Apple’s archive utility)
- I convert the AVIs to MP4s using HandBrake
- I load the MP4s and my audio into iMovie and splice everything together
- The final result is loaded onto YouTube.
In all ~10 programs are used (not even counting the programs we are actually screencasting about. We are going to record the screencast tomorrow, and I will do the editing Friday (I don’t think I can do it before then, as I have a big exam Friday morning).
Who knew that making a screencast would have so many problems?
This really is the last week for any real changes to be made, as next week will be centered on making our Screencast, getting ready to commit our branch, and handling any last-minute problems that arise as the result of the ReviewRequest.
Lindsey and I have gotten a lot done (Lindsey is a coding machine), and I think we really are on schedule, so there are only a few things left that need to be finished up.
On Lindsey’s end, he has a change so that rb-* commands so that they can be called from anywhere, a minor adjustment to one of Resource’s subclasses, and work on the GUI client that we plan on using for our Screencast (Maybe some other things too).
On my end, I am going to be creating an rb-patch command, that will download a patch from the server, apply it, and optionally commit it. I am also going to be making some adjustments to how our configuration file is handled, so that it allows comments and grouping of variables. I also need to look into good software for making screencasts.
It has been an interesting project to work on. I have gotten to know about ReviewBoard, which is truly a well-thought-out piece of software. I am recommending that my current employer start using it. I’ve also learned how to use git (git mergetool is a lifesaver, and I’m unsure why it is not prominently mentioned to git newbies), and a much better understanding of python (I had been using python for writing quick scripts for a while now, but had never dealt with objects, or other complex interactions). Thanks to this project I feel like I could handle creating a real program in python.
For the most part everyone seems on track – which is good considering all the projects due at this time of year 🙂
Brendan was wondering how to download a diff from a review board server. Pointed in the direction of http://www.reviewboard.org/docs/manual/1.5/webapi/2.0/resources/diff/, specifically setting the mime-accept type.
rb-patch should: download a diff, and apply (merge) it to the current working copy. It should optionally commit the change as well.
We should be installing all the rb-* scripts and have rb look for them to run. Either put them in the path, or maybe the better option would be to put them in a special directory so as not to clutter the path.
Regarding Bugzilla and REST: it seems that the REST API is built on top of XML-RPC API so it would seem best to use XML-RPC API instead. That being said, there isn’t enough time left. Hongbin will focus on polishing what he has with REST API and getting his demo ready.
For Laila, regarding keeping some views public, in this case its ok to do so and import them.
Also, she’s having some troubles with captions in screenshots. It sounds like its a bug though; need to take a look at the template as it may be broken.
She was wondering if it was reasonable to not allow the editing of filenames – which is fine.
Also should files have descriptions (as opposed to captions, which are a little shorter.) Again, that sounds fine as long as they don’t get *too* long (like more than one line.)
Finally, although its a good idea to have uploading files and captions in the same UI dialog, for now we should use two separate ones so as not to add any confusion.
Just a reminder, you do need to submit a screencast of your work. The idea is to cover as much of what you did but still keep it short (don’t drone on!)
Our plans for the following 3ish weeks are:
Nov 18 – Nov 26: Make “create review request”, “patch”, “upload diff” and “get diff” commands.
Nov 26 – Dec 3: Finishing touches to things and polish up the Graphical Resource Browser.
Dec 3 – Dec 7: Clean commit history and merge with upstream rbtools. Make screen-cast to showcase what we have done.
~Brendan & Lindsey
So the last two days I’ve been trying to be able to upload a diff through the API to no success Interestingly though, I have been able to successfully upload screen-shots.
Also, I’ve thrown together the start of a Graphical Resource Browser. Obviously there are lots of issues (I can’t seem to figure out sizing things in pygtk!) but regardless it’s something to work off of.
I finally got all the changes done (or at least I think I caught everything) from Christian and Mike’s review regarding the serverinterface and resource modules. Wooo!
Now working on putting together some client commands. I’m hoping to be updating our review request tonight.