intro to programming at the allied media conference

went really well! AMC is dreamy and has such a special place in my heart and my development as a human. highlights were:

i enjoyed teaching the workshop, but wish i’d provided a way to get feedback from folks. what worked? what didn’t? what else would be useful to know? but hopefully there will be a next time and i’ll think to collect that stuff.

materials are here: http://kaganjd.github.io/p5-at-amc/

day 18: the case of the missing vine api and the add-on sdk

i’m trying to add vine support to min-vid and realizing that i’m still having a hard time wrapping my head around the min-vid program structure.

what does adding vine support even mean? it means that when you’re on vine.co, i want you to be able to right click on any video on the website, send it to the corner of your browser, and watch vines in the corner while you continue your browsing.

i’m running into a few obstacles. one obstacle is that i can’t find an official vine api. what’s an api? it stands for “application programming interface” (maybe? i think? no, i’m not googling) and i don’t know the official definition, but my unofficial definition is that the api is documentation i need from vine about how to access and manipulate content they have on their website. i need to be able to know the pattern for structuring video URLs. i need to know what functions to call in order to autoplay, loop, pause, and mute their videos. since this doesn’t exist in an official, well-documented way, i made a gist of their embed.js file, which i think/hope maybe controls their embedded videos, and which i want to eventually make sense of by adding inline comments.

another obstacle is that mozilla’s add-on sdk is really weirdly structured. i wrote about this earlier and am still sketching it out. here’s what i’ve gathered so far:

  • the page you navigate to in your browser is a page. with its own DOM. this is the page DOM.
  • the firefox add-on is made of content scripts (CS) and page scripts (PS).
  • the CS talks to the page DOM and the PS talks to the page DOM, but the CS and the PS don’t talk to each other.
  • with min-vid, the CS is index.js. this controls the context menu that comes up when you right click, and it’s the thing that tells the panel to show itself in the corner.
  • the two PS’s in min-vid are default.html and controls.js. the default.html PS loads the stuff inside the panel. the controls.js PS lets you control the stuff that’s in the panel.

so far, i can get the vine video to show up in the panel, but only after i’ve sent a youtube video to the panel. i can’t the vine video to show up on its own, and i’m not sure why. this makes me sad. here is a sketch:

FullSizeRender-1

day 16: helpful git things

it’s been important for me to get comfortable-ish with git. i’m slowly learning about best practices on a big open source project that’s managed through github.

one example: creating a separate branch for each feature i work on. in the case of min-vid, this means i created one branch to add youtu.be support, a different branch to add to the project’s README, a different branch to work on vine support, etc. that way, if my changes aren’t merged into the main project’s master, i don’t have to re-clone the project. i just keep working on the branch or delete it or whatever. this also lets me bounce between different features if i get stuck on one and need to take a break by working on another one. i keep the workflow on a post-it on my desktop so i don’t have to think about it (a la atul gawande’s so good checklist manifesto):

git checkout master

git pull upstream master
(to get new changes from the main project’s master branch)

git push origin master
(to push new changes up to my own master branch)

git checkout -b [new branch]
(to work on a feature)

npm run package
(to package the add-on before submitting the PR)

git add .

git commit -m '[commit message]

git push origin [new branch]
(to push my changes to my feature branch; from here, i can submit a PR)

git checkout master

another important git practice: squashing commits so my pull request doesn’t include 1000 commits that muddy the project history with my teensy changes. this is the most annoying thing ever and i always mess it up and i can’t even bear to explain it because this person has done a pretty good job already. just don’t ever ever forget to REBASE ON TOP OF MASTER, people!

last thing, which has been more important on my side project that i’m hosting on gh-pages: updating my gh-pages branch with changes from my master branch. this is crucial because the gh-pages branch, which displays my website, doesn’t automatically incorporate changes i make to my index.html file on my master branch. so here’s the workflow:

git checkout master
(work on stuff on the master branch)

git add .

git commit -m '[commit message]'

git push origin master
(the previous commands push your changes to your master branch. now, to update your gh-pages branch:)

git checkout gh-pages

git merge master

git push origin gh-pages

yes, that’s it, the end, congrats!

p.s. that all assumes that you already created a gh-pages branch to host your website. if you haven’t and want to, here’s how you do it:

git checkout master
(work on stuff on the master branch)

git add .

git commit -m '[message]'

git push origin master
(same as before. this is just normal, updating-your-master-branch stuff. so, next:)

git checkout -b gh-pages
(-b creates a new branch, gh-pages names the new branch “gh-pages”)

git push origin gh-pages
(this pushes changes from your origin/master branch to your new gh-pages branch)

yes, that’s it, the end, congrats!

day 6: brain to launch & a close reading

the project i’m working on, min-vid, is a firefox add-on that lets you minimize a video and keep it in the corner of the browser so you can watch while you’re reading/doing other stuff on the page behind it.

this is an idea straight out of dave’s brain.

getting this idea from dave’s brain to the firefox browser takes a lot of work and coordination. one of the first steps was for the dev team to decide on which features would add up to an ‘mvp,’ or ‘minimum viable product.’

a user experience designer looks at these mvp features and designs the human-readable interface around them. all the little x’s in the corners of browser windows, things that light up or expand or gray out when you mouse over them, windows that snap into place… they’re all designed by a person to work that way. in min-vid’s case, this person is named john. hey john.

so in addition to this set of mvp features, there are some basic logistical things that go into launching an open source product: a wiki page, a README that explains the thing and lets people know how to contribute, a name.

and then there are a thousand functionality issues to figure out. here’s a screen shot of partial issue list:

Screen Shot 2016-05-31 at 10.50.10 AM

one mvp feature of this product is vimeo support since lots of folks watch videos hosted by vimeo. dave is working on that, and it involves getting the vimeo api to talk to the firefox add-on api. looking at his code for the new vimeo support, i realized i didn’t understand the basic structure of the existing add-on.

so i spent a big chunk of today doing what basically amounted to a close reading of the core add-on code. i copy/pasted it into github gists, where i added comments, questions, and links to helpful resources. then, i sent my marked up index.js file to dave and he responded with additional comments, answers, and more resources.

to folks (but mostly, ahem, my own internal monologue) who say “THAT IS NOT REAL WORK OR A GOOD USE OF TIME,” i say, “wrong this is actually a great learning exercise bye!”