Planet Drumbeat

We have just added another workshop to the summer’s list, this one at Saint Mary’s University in Halifax, Nova Scotia, on July 16-17. Please let friends and colleagues know—I look forward to meeting them.

May 17, 2012 02:07 AM

When we were tasked with “doing something cool for/with youth” at last fall’s Mozilla Festival in London, we had just come off the heels of World Maker Faire where the Hive NYC booth won a Editor’s Choice Blue Ribbon award. So we … Continue reading →

May 16, 2012 04:27 PM

We’re pleased to announce that we will be running a two-day boot camp at Johns Hopkins University in Baltimore on June 18-19, 2012. We only have space for 20 participants, so please register early.

May 16, 2012 02:58 AM

This week’s Newcastle bootcamp, organised by the Digital Institute at Newcastle University with the Software Sustainability Institute and SoundSoftware, was the first Software Carpentry boot camp run entirely locally in the UK. For the organisers it was a slightly nervous experience, hoping we could get the material to hold together in presentation without Greg’s experience at hand.

Feedback from the learners was generally good on the material, the venue and the structure. The most common complaint was that it was hard to follow along at times, and I think there are several areas where we’ll be able to improve the “flow” for future events.

Notably, this was the first bootcamp I’ve attended at which nobody found the room too crowded or the wrong temperature. Result, Newcastle!

Here are the good and bad feedback points. Some points were close duplicates, and I’ve put the additional ones in brackets (e.g. Python was cited three times).

Good

Bad

Python (+ Choice of Python as easy scripting language) (+ Gives me confidence to start using Python) Use of coloured sticky notes (+ coloured notes as an unobtrusive way to request help) The “Bringing it together” section Good mix of content Version control (+ integration with Bitbucket) (+ version control tips e.g. archive, bisect) (+ use of recipes as version control material) Coding along with the presenters Lots of helpers Good temperature in room, open window Arrangement of room into groups for collaborative work Self-guided exercises spaced out through the presentations Easy to ask the helpers for help Use of open source software Test-driven development Online lecture content to back up teaching Lots of breaks Good course description Inclusion of general advice for coding (as opposed to specific syntax) SQL

Felt like we ran out of time at end of first day Would have liked more about testing Cygwin Sometimes problem material got in the way of the subject (more time worrying about overlapping rectangles than how to program a test) No handouts, and screens difficult to read as forgotten my glasses Should have introduced Python lists and other structures earlier (presenters forgot to do this before using them in an exercise!) Not enough window real-estate Couldn’t always follow material before it disappeared off screen Presenters sometimes forgot we were not necessarily interested in software engineering Pace too intense for non-expert programmers Interrupted by fire alarm Coloured notes would have worked better in the other order (that is, holding up “not OK” first — didn’t always dare if everyone else had just held up “OK”) More use of microphones Went a bit fast Half the class was facing back wall! Would have liked some harder exercises More consistency of laptop presentation (i.e. always same laptop with same window layout) Shell scripting section a little easy Didn’t always notice when a presenter had started typing, they should read it out More pointers to additional material online please Some exercises had too much literal typing (from a presenter) Would like to have improved the presentation of functions

You can find links to the material we used on the page about the bootcamp.

May 15, 2012 06:30 PM

A recent article in The Atlantic titled, “How the Professor Who Fooled Wikipedia Got Caught By Reddit” describes how GMU’s Prof. T. Mills Kelly has had students fake history online, and how their most recent effort unraveled. There’s lots to think about here regarding what scientists should know about using the web, trusting it, and making it their own…

 

May 15, 2012 06:05 PM

Starting this summer, we’re aiming to help create a group of webmakers. Building on Mozilla’s Manifesto—to promote openness, innovation and opportunity on the web—we’re rationalizing a set of core skills, developing learning objectives and outcomes associated with those skills and offering opportunities to try them out. This effort aligns extremely well with the development and promotion of #5 in our mission list: “Individuals must have the ability to shape their own experiences on the Internet.”

What’s a webmaker?
What do we mean by webmaker? Someone who contributes to the web but also someone who understands the web and its inherent power. Our focus is on moving people toward doing rather than perceiving but both are required. Experimentation is where we’re headed. Guiding people toward understanding the software that constitutes the web so that they can make more informed and educated decisions about not only how they interact with the web, but how they interact with the systems that lead to the power of the web. Yes, systems as we’ve been discussing in previous posts. (Avoiding the complex discussion of Foucault’s systems of power for now, thanks.)

Code is political
Code is political. While that may seem to be a polemical statement, it’s one that serves to inform the currently omnipresent drive to teach people to code. Code is enveloped in systems of power—systems of power that will increasingly play large roles in people’s lives. Understanding that you can create as well as consume seems a fair balance. More people having a literacy is something to be desired, not shunned or disdained. (More info here: Lawrence Lessig’s Code is Law)

What do we mean by literacy?
Traditional literacy lifts people out of poverty, modifies their worldviews, opens up new vistas and provides new opportunities for further enrichment, whether they be social, political, professional, or ideological. If you want your own proof, just search with this combination of terms “literacy and poverty.” Who’s to say that digital literacy won’t accomplish similar things? In the vein of the scientific method, why not test it out?

Literacy itself is a complex term that encompasses a broad spectrum. In our case, literacy is a basic communication skill, akin to numeracy or traditional language literacy. We’re not aiming to make everyone into Joycean code experimenters pushing the boundaries of language and comprehension, nor are we aiming to move everyone toward Hemingway-esque brevity and conciseness, but if some of you decide those pathways are for you, all the better. At least you’ll be moving forward with a broader understanding of what’s possible. And you will be making the decision for yourself, not having it handed to you by some faceless mega-corporation.

Our initial take on web literacy skills is bouncing along as an ongoing experiment (sounds familiar, right?). In the same vein as iterate often, we’re out there trying things on, seeing what feels right. Working with other organizations to leverage their understandings of web literacy and expand upon our own.

What we’re interested in doing with webmaking is shining a light into a place you may not have considered looking before. Showing you that that place is not full of monsters, is not incomprehensible, but is instead simply the exact same world you’ve been experiencing all along just translated into another language. Learning to code is a deciphering of sorts—a decoding of symbols. It offers a different lens through which to view the world.

Opportunity
This new knowledge lens may significantly alter the way you perceive the world; it’s hard to say how it will affect you. Perhaps that unknown quantity is precisely why Mozilla believes learning to code is something everyone should be afforded the opportunity to learn how to do. The operative word in that sentence is opportunity.

Knock, knock, knock.

Tagged: drumbeat, identity, inspiration, learning, literacy, mozilla, politics, social networks, software, system design, tools, webmaker, webmaking

May 15, 2012 05:23 PM

We are pleased to announce that we will be running two boot camps in Ontario in July: one at the University of Waterloo on July 12-13, and another at the University of Toronto (Scarborough) on July 19-20. If you’d like to take part, please sign up, and please let friends and colleagues know about them as well.

May 15, 2012 01:46 PM

WHOA! I know, I know, I’ve totally been slacking on my “Blog Every Single Tuesday” rule. I’ve been busy. Really busy, and I haven’t had a chance to actually think about what I wanted to write. Thus, I’m doing a roundup post. Here’s some brief insight into what I’ve been thinking about and doing:

1. Linking Past and Present
   I’ve been reading a book about German Reform Pedagogy (really brief, dirty definition): the thought movement that happened circa 1900 to 1930s that changed the face of education. A LOT of the ideas we believe in for education, like learning through making, collaboration, interested-based learning, etc were being talked about in this time. A parallel thought movement (does the name John Dewey say anything to you?) called “Progressive Education” was happening in the US. They’re NOT considered the same movement by the German educational academics (even though they happened at the same time, and they were talking about the same things and concluding with the same conclusions. Also, if you click the English button on the Wikipedia article Reformpädagogik, you get the Wikipedia article on Progressive Education…) Anyway, I’m thinking about the connection between the discussion happening NOW and these movements from the 1900s. Specifically, I’m wondering if Georg Kerschensteiner, one of the leaders of the German Reform Pedagogical Movement, actually conceived the pillars of digital and/or new literacies in a time when RADIO was new fangled and cool.
2. Cultural Clashing
   I live in Europe, so I’ve been looking at the landscape of web literacy and learning programs here on the home front. I talk to people a lot about the work we do at Mozilla, and I keep wondering how we can get the awesome energy of the North American continent’s movement in the educational realm to percolate here in Europe. There’s tons of good programs happening, but it seems like the cohesion of our community here is faulty at best. There are pockets of innovation happening, but we’re not yet playing the role we’re championing in the US and Canada. In London and Berlin we’re finding ways to bring web literacy to a number of different groups, but what about the rest of Europe?When I talk to people about web literacy here in Germany, they’re sometimes skeptical, something I find pretty unbelievable. There seems to be a lot of people that still believe that web literacy skills will be gleaned without guidance, that these skills are somehow given, not learned. This misguided idea that the new generation are “digital natives” seems to be influencing the learning landscape, and I want to step up and change that notion (with a little help from my friends, naturally).
3. Guiding the Guide
   Been doing tons of thinking and work on helping informal instructors access Mozilla content. Lots of people are wanting to run their own hack jams and teach this or that techie thing to youth and adults. A lot of these people need a little help, so we’ve been creating materials that give them step by step guidance and activities that will help them hit the ground running. Call it curriculum, call it learning materials, call it hacktivity kit 2.0, the point is we’re trying to make some resources that help those active community members run their own events and teach people things without having to go crazy figuring out the all important “what will we do!?” question. We currently have a wiki up. It’s just temporary, not all slick and beautiful, but we needed a holding place for some of this stuff. You are welcome to edit and add to it!
4. Introduction to Web Native Film and StoryCamp
   StoryCamp planning, preparation and production is coming along. We’re all over it like white on rice, and we’re building some kick-ass stuff. What’s really cool is that with this theme, I get to spend a bit of time looking at crazy films from the 50s, and that is a load of fun. I also get to repurpose a robot I drew a few weeks ago.

WebPageMaker Open Web Nice Robot concept drawing:

StoryCamp Robots Invade Everywhere Evil Robot concept drawing:

Muwwwhahahha! Actually, this whole project is awesome and awesome fun, having a blast! Here, check out some of our mockups And don’t forget feedback is always welcome!

May 15, 2012 11:04 AM

Last week’s homework was to convert a two-level bullet-point list like this:

* A
* B
  * 1
  * 2
* C
  * 3

into an HTML list like this:

<ul>
  <li>A</li>
  <li>B
    <ul>
      <li>1</li>
      <li>2</li>
    </ul>
  </li>
  <li>C
    <ul>
      <li>3</li>
    </ul>
  </li>
</ul>

so it would display like this:

• A
• B
  • 1
  • 2
• C
  • 3

My solution is shown in the video below; the code follows.

Click here to view the video on YouTube.

import sys

def do_inner(lines, current):
    need_to_start = True
    need_to_close = False
    while (current < len(lines)) and \
          lines[current].startswith('  * '):
        if need_to_start:
            print '  <ul>'
            need_to_start = False
        text = lines[current].lstrip('  * ').rstrip()
        print '  <li>' + text + '</li>'
        need_to_close = True
        current += 1
    if need_to_close:
        print '  </ul>'
    return current

def do_outer(lines):
    print '<ul>'
    current = 0
    while current < len(lines):
        assert lines[current].startswith('* ')
        text = lines[current].lstrip('* ').rstrip()
        print '<li>' + text
        current = do_inner(lines, current+1)
        print '</li>'
    print '</ul>'

lines = sys.stdin.readlines()
do_outer(lines)

May 14, 2012 06:05 PM

Our workshop at Michigan State University this week was three days long instead of two, and included two topics (Git and the IPython notebook) that we haven’t tried before.  Feedback was generally positive, but we’ve got lots to work on for next time as well.

Good

Bad

Using history Ending with general theory Pen and paper database design Version control was useful Good practice in software Concise and module programming in Python Console segment Smooth flow between Bash and Python Challenging and flowed nicely Futher reading material Desktop setup Instructor teaching style Permission to spend less time coding iPython notebook looks great Paired programming model Git script (tutorials used were available) Legal issues (opensource) Good for beginners Free course (and food!) Variety Practical (reality-based) Overview of DB options Testing Better ways to do things Somewhat static seating created helpful partners

Typing speed is too fast Class time chunks too long Why iPython Need more ‘why’ Curriculum Advanced Git bounced Too much switching screens Some things failed Beverages included only caffeine Need snacks at breaks Lacked connection between course material and applicability Tuesday way too long Wanted a cheat sheet Not enough exercises How to create DB Anti-Windows bigotry Next day install at end of day Some concepts skipped Don’t know where to start (registrationg etc.) Inappropriate room size Breadth PPT for CS

May 12, 2012 07:27 PM

RunMyCode is a web site and service intended to support reproducible research (initially in computational economics). Authors create companion web sites for papers that include the software they used; other people can then re-run their models, and (crucially) play with parameters, using cloud-based instances of those environments. They only support MATLAB, R, and SAS right now, but are hoping to add more tools soon. It’s a cool idea, and we’d welcome your impressions.

May 11, 2012 02:59 PM

Join us this Saturday, May 12th from 1-5pm at the West Side YMCA for our first 1st Amendment Hack Jam!  It’s a free event for tweens and teens to explore and exercise their constitutional rights. We’ve partnered with The American … Continue reading →

May 10, 2012 11:13 PM

The May/June 2012 issue of Washington Monthly has an article by Alison Fairbrother titled “A Fish Story“. Near the top, it says, “In 2009, a routine methodological upgrade at NOAA—and the subsequent discovery of a few lines of faulty computer code—forced the start of a profound shift in the ASMFC’s estimates of menhaden stocks.” A few pages later, we get more details:

In 2009, the Menhaden Technical Committee updated its methodology for estimating the menhaden population—something it does every five years—and then ran the menhaden catch data through a new computer model. The results weren’t much different: although the numbers of menhaden were declining, the estimated number of eggs produced by spawning female menhaden was at the target level, so according to the reference point, menhaden weren’t being overfished.

Shortly thereafter, a colleague of Jim Uphoff’s, a biologist named Alexei Sharov, got hold of the computer model that had been updated by NOAA scientists. Going through the code line by line, Sharov, one of Maryland’s representatives on the Technical Committee, found a fundamental miscalculation buried inside the model. Uphoff, meanwhile, studied the methodology of the code and discovered that NOAA had both underestimated the amount of fish killed by the industry and overestimated the spawning potential. Sharov brought these two mistakes to his peers on the committee, and it was agreed that corrections needed to be made.

Several months later, after the model had finished running a second time, the science finally caught up with what Jim Price and the anglers had been saying for decades: even using the lax reference points developed by the ASMFC, menhaden had been subject to overfishing in thirty-two of the past fifty-four years. When the assessment was then peer reviewed by a group of international scientists, the reviewers deemed that the reference point currently in use for menhaden—8 percent of maximum spawning potential—was not sufficiently safe or precautionary.

Furthermore, the number of menhaden swimming in the Atlantic had declined by 88 percent since 1983—to a level so low that it caused George Lapointe, former commissioner of Maine’s Department of Marine Resources, to have what he called an “oh shit moment.”

If anyone knows more about the “fundamental miscalculation”, I’d be grateful for a summary.

May 10, 2012 03:43 PM

We are pleased to announce that we will be running a boot camp on July 9 and 10 in Boston—please see its page for details (some of which we’re still working out). We have room for 40 participants, so please register early. (And if you can, register with friends: we are finding that people get a lot more out of this training if they’re learning with their labmates and other collaborators.)

May 09, 2012 10:02 PM

Last Saturday at the Mozilla Toronto offices we held a hackjam for classroom teachers with the idea of exploring the concept: how can I inject learning technology directly into my existing curriculum?

We had a great turn-out of 40+ teachers from K-8 all the way through college.

Some photos of the event here:

Toronto Teacher Hackjam – May 05, 2012

Big thanks to the session instructors who did all the heavy lifting of motivating and inspiring our participants:

• Marco Tomada and Zaki Patel: Introduction to Scratch
• Laurie MacDougall: Collaborative Story Writing on the Web
• Matt Price: Digital Social Studies with Google Maps and Javascript
• Rochelle Mazar and Lauren Di Monte: Wikipedia Editing for Credit
• Laura Hilliger: Intro to Collaborative Web Making
• Kate Hudson: Making Web Movies with Popcorn
• Shadi Yazdan: Edmodo in the Classroom

For those of you who are sad that you couldn’t make it, or horribly jealous and wish we could host one in your city, I plan on putting together a howto for this type of event format, so please do contact me if you’re interested in giving it a shot.

May 09, 2012 08:32 PM

The best way to learn something is by making something. So as part of Mozilla’s campaign to help the world learn coding and webmaking this summer, we created these new Mozilla Webmaker projects. Their mission: help anyone (especially youth) make something amazing on the web fast.

Help test them out?

Can you take a few minutes to beta test the projects below? Are they easy to use? Helpful for learning? Fun? Flammable?

• 1) Try them out now
• 2) Let us know what you think
  
• 3) Get more involved

What’s the idea?

It’s all part of the Mozilla Summer Code Party. Blast off is June 23, with local events and teach-ins running around the world all summer long.

Mozilla will provide curriculum and fun starter projects like these. Tools anyone can use to make and learn together, just about anywhere. At local partner events, Mozilla spaces, libraries, or gathered around their own kitchen table.

Try ‘em out now. Kick the tires on these beta webmaker projects below and let us know what you think:

Make your own meme

Got what it takes to go viral and become internet famous? Prove it. This project lets you use your HTML and CSS swagger to create your own web page — featuring a meme to conquer all internet memes. Let your inner serious cat or Ryan Gosling “hey girl” shine.

–> G O <–

May 09, 2012 06:23 AM

I’m a little behind in posting this recording, but here’s a video of Erin and I talking about web literacies at JISC:

Thanks to Doug Belshaw for inviting us, and super thanks to Erin for doing all the talking while my 6 am coffee kicked in.

May 08, 2012 08:24 PM

We are very pleased to announce that The Architecture of Open Source Applications: Volume 2 is now available from Lulu.  A PDF version will go on sale in the next few days, and e-book will become available as soon as we can produce it.  Many thanks to everyone who contributed, and to the indefatigable Amy Brown for pulling it all together.  As always, all royalties will go directly to Amnesty International, so if you buy a copy, you’ll be helping to make the world a better place.

May 08, 2012 05:53 PM

As the Knight-Mozilla OpenNews program reaches its 2012 stride, it’s time to grow the team to help achieve the scale we’re looking for. So we’re hiring a Community Manager.

The entire job listing is here on the Mozilla Jobvite page, but I wanted to give a little background on the person we’re looking for that doesn’t break down as easily into bullet points.

At its core, the OpenNews program is about community: specifically around growing and strengthening the community of people making code for journalism. That’s what our fellowship program is about: sending individuals into newsrooms for ten months to create kick-ass journalism code. That’s what our hackdays are about: building momentum around code through events. That’s what our upcoming website Source is about: creating a central place to learn about the code being made and the motivations behind it. All of these pieces (with more to come soon) add up to helping foster a vibrant, growing community. But that’s a big goal, and it’s not going to happen without some help.

The Community Manager is what it says on the box: a person who can help to manage, foster, and grow the community around open-source code in journalism. It’s a unique person: Someone who’s outgoing, both in the world and online; someone who’s familiar with journalism, sure, but even more so someone who understands open-source communities and can communicate effectively with them; someone who’s well organized, and able to keep an eye on a lot of different, disparate balls at once; and finally, someone who’s able to collaborate effectively and efficiently.

Maybe you’re that person? If so, you should totally apply. We’re trying to fill this position as soon as possible, so no better time to get your application in than right now.

Oh, and you don’t have to move: we love remote workers.

May 07, 2012 04:23 PM

[Code and Data]

Let’s say you have a text file called workout.csv that contains information about your workouts for the month of March:

# date, kind of workout, distance (miles), time (min)
"2012, Mar-01", run, 2, 25
"2012, Mar-03", bike, 10, 55
"2012, Mar-06", bike, 5, 20
"2012, Mar-09", run, 3, 42
"2012, Mar-10", skateboarding, 2, 10

# Broke my leg  

"2012, Mar-11", Wii, 0, 60
"2012, Mar-12", Wii, 0, 60
"2012, Mar-13", Wii, 0, 60
"2012, Mar-14", Wii, 0, 60

It’s a common-separated value (CSV) file, but contains comments and blank lines. The first line (a comment) describes the fields in this file, which are (from left to right) the date of your workout, the kind of workout, how many miles you traveled, and how many minutes you spent.

Our goal will be to read this data into Python and plot a graph with the day of the month on the x-axis and the time worked out on the y-axis. Let’s get started.

1. Reading
To begin, let’s read in the data file with Python’s csv module. The code is fairly straightforward:

import csv

# Read in all rows from the csv file
reader = file("workout.csv", "r")
csv_reader = csv.reader(reader)

# Print out rows
for row in csv_reader:
    print row

Saving this code to a file called plot_workouts.py and running python plot_workouts.py on the command-line produces the following output:

['# date', ' kind of workout', ' distance (miles)', ' time (min)']
['2012, Mar-01', ' run', ' 2', ' 25']
['2012, Mar-03', ' bike', ' 10', ' 55']
['2012, Mar-06', ' bike', ' 5', ' 20']
['2012, Mar-09', ' run', ' 3', ' 42']
['2012, Mar-10', ' skateboarding', ' 2', ' 10']
[]
['# Broke my leg  ']
[]
['2012, Mar-11', ' Wii', ' 0', ' 60']
['2012, Mar-12', ' Wii', ' 0', ' 60']
['2012, Mar-13', ' Wii', ' 0', ' 60']
['2012, Mar-14', ' Wii', ' 0', ' 60']

Unfortunately, as we can see, Python’s CSV reader doesn’t filter out comments or blank lines. We’ll need to do it manually. However, this is a common task that we might want to do again and again across programs. Let’s write a function named filter_lines that will filter the lines in a file before the CSV reader does its thing.

def filter_lines(reader)

    lines = []
    for line in reader:
        if len(line.strip()) > 0 or not line.startswith("#"):
            lines.append(line)

    return lines

This function will take a file reader and return a list of lines (excluding blank lines and comments). Let’s make filter_lines a bit more readable by introducing a second function called keep_line:

def keep_line(line):
    return len(line.strip()) > 0 or not line.startswith("#"):

def filter_lines(reader)
    lines = []
    for line in reader:
        if keep_line(line):
            lines.append(line)

    return lines

This new code is easier to read. We can see that keep_line takes in a line and will return True when the line is not blank and not a comment. Here’s the complete code so far:

import csv

#------------------------------------------------------------

def keep_line(line):
    return len(line.strip()) > 0 and not line.startswith("#")

#------------------------------------------------------------

def filter_lines(reader):
    lines = []

    for line in reader:
        if keep_line(line):
            lines.append(line)

    return lines

#------------------------------------------------------------

reader = file("workout.csv", "r")
lines = filter_lines(reader)
csv_reader = csv.reader(lines)

for row in csv_reader:
    print row

Running this now produces the following output:

['2012, Mar-01', ' run', ' 2', ' 25']
['2012, Mar-03', ' bike', ' 10', ' 55']
['2012, Mar-06', ' bike', ' 5', ' 20']
['2012, Mar-09', ' run', ' 3', ' 42']
['2012, Mar-10', ' skateboarding', ' 2', ' 10']
['2012, Mar-11', ' Wii', ' 0', ' 60']
['2012, Mar-12', ' Wii', ' 0', ' 60']
['2012, Mar-13', ' Wii', ' 0', ' 60']
['2012, Mar-14', ' Wii', ' 0', ' 60']

Hooray! Our blank lines and comments are gone. Before moving on to parsing the data (converting it from text to dates, integers, etc.), let’s take a moment to think about how Python is actually using our filter_lines and keep_line functions. For that, we need to understand the call stack

2. The Call Stack

Python tracks which functions are currently being executed with a data structure named the call stack. When Python encounters a function call, like lines = filter_lines(reader), it “pushes” information about where to come back to and then jumps to the function’s code. When a return statement is found (or when the function ends), Python “pops” information off call stack to remember where it was.

This can be difficult to visualize. Below is a diagram of our program before and after the call to filter_lines.

Python starts out in the “global” function whose code is just the main body of your program. When we call filter_lines with reader as a parameter, Python copies a reference to workout.csv into a new variable reader, makes a note that it should return to the global function, and jumps to the code for filter_lines. Each time we call keep_line inside filter_lines, Python saves its place on the call stack, copies a reference to line, jumps to keep_line, and jumps back to filter_lines when it’s done.

It’s important to remember that the reader in the global function and the reader in filter_lines are two different variables. However, they point to the same file in memory, so reading from the file inside of filter_lines changes the file position of reader in the global function.

Python copies things by reference instead of by value, which is very fast (it only needs to point the new variable at the right thing in memory). It can lead to confusion, however, if you don’t expect a function to make changes to a parameter (e.g., trying to read data from reader after calling filter_lines produces nothing since we’re at the end of the file). If you really need to, making copies is easy. A list named my_list, for example, can be copied simply by slicing the whole thing my_list[:].

With a picture of the call stack in our heads, let’s move on to parsing our workout data.

3. Parsing

Our workout data is stored as text. In order to process and plot it, we need to convert each field to its appropriate type (e.g., a date, an integer, etc.). Converting from text to integers or floating point numbers is easy; we can just call the int() or float() function. Our first field is a date, however, which requires a bit more work.

Parsing dates can get hairy very quickly. Luckily, the hard work has already been done for us! Python includes module called datetime that handles parsing for dates and times (go figure ).

3.1 The datetime module

The datetime module contains a class also called datetime. This class has a lot of useful functions for date manipulation as well as a function called strptime for parsing (think “string parse time” for strptime).

datetime.strptime takes two parameters: (1) a date string like “2012, Mar-01″, and (2) a format string that describes how to parse the date string.

We make a format string by replacing the pieces of our date string with special format codes (which start with a ‘%’). For example, %Y stands for the “year with century as a decimal number”, so we need to replace the year in our date string (2012) with %Y as such: “%Y, Mar-01″. Next, we use the %b (abbreviated month name) and %d (day of the month) format codes to replace the remaining pieces (“Mar” and “01″, respectively). Our final format string is “%Y, %b-%d”. Note that we include the comma, space, and dash.

Let’s write a function called parse_workouts that will take in a list of CSV rows and produce a list of workouts (one for each row). Each workout will itself be a list with the parsed date, workout kind, distance, and time. The complete code is below.

import csv
from datetime import datetime

#------------------------------------------------------------

def keep_line(line):
    return len(line.strip()) > 0 and not line.startswith("#")

#------------------------------------------------------------

def filter_lines(reader):
    lines = []

    for line in reader:
        if keep_line(line):
            lines.append(line)

    return lines

#------------------------------------------------------------

def parse_workouts(rows):
    workouts = []

    for row in rows:
        date = datetime.strptime(row[0], "%Y, %b-%d")
        kind = row[1].strip()
        distance = int(row[2])
        time = int(row[3])

        workouts.append([date, kind, distance, time])

    return workouts

#------------------------------------------------------------

reader = file("workout.csv", "r")
lines = filter_lines(reader)
csv_reader = csv.reader(lines)
workouts = parse_workouts(csv_reader)

for w in workouts:
    print w

At the top, we import the datetime class from the datetime module using Python’s from module import class import form. Our parse_workouts function loops over each CSV row, parses the individual fields, and packages them up as a single workout list. At the end, we print out our workouts.

Running this code produces the following output:

[datetime.datetime(2012, 3, 1, 0, 0), 'run', 2, 25]
[datetime.datetime(2012, 3, 3, 0, 0), 'bike', 10, 55]
[datetime.datetime(2012, 3, 6, 0, 0), 'bike', 5, 20]
[datetime.datetime(2012, 3, 9, 0, 0), 'run', 3, 42]
[datetime.datetime(2012, 3, 10, 0, 0), 'skateboarding', 2, 10]
[datetime.datetime(2012, 3, 11, 0, 0), 'Wii', 0, 60]
[datetime.datetime(2012, 3, 12, 0, 0), 'Wii', 0, 60]
[datetime.datetime(2012, 3, 13, 0, 0), 'Wii', 0, 60]
[datetime.datetime(2012, 3, 14, 0, 0), 'Wii', 0, 60]

Each workout is a list whose first element is a datetime.datetime object. Python prints datetime objects as datetime.datetime(year, month, day, hour, second). The second element is the kind of workout (a string). The third and fourth elements are the workout distance and time, respectively (both integers).

Everything is looking good, so let’s prepare for plotting. We want to plot the day of the month on the x-axis and the time we worked out on the y-axis. We’ll write two functions, one to extract the day of the month from each workout, and another to extract the time from each workout.

import csv
from datetime import datetime

#------------------------------------------------------------

def keep_line(line):
    return len(line.strip()) > 0 and not line.startswith("#")

#------------------------------------------------------------

def filter_lines(reader):
    lines = []

    for line in reader:
        if keep_line(line):
            lines.append(line)

    return lines

#------------------------------------------------------------

def parse_workouts(rows):
    workouts = []

    for row in rows:
        date = datetime.strptime(row[0], "%Y, %b-%d")
        kind = row[1].strip()
        distance = int(row[2])
        time = int(row[3])

        workouts.append([date, kind, distance, time])

    return workouts

#------------------------------------------------------------

def extract_days(workouts):
    days = []

    for w in workouts:
        date = w[0]
        days.append(date.day)

    return days

#------------------------------------------------------------

def extract_times(workouts):
    times = []

    for w in workouts:
        times.append(w[3])

    return times

#------------------------------------------------------------

reader = file("workout.csv", "r")
lines = filter_lines(reader)
csv_reader = csv.reader(lines)
workouts = parse_workouts(csv_reader)
days = extract_days(workouts)
times = extract_times(workouts)

print "Days:", days
print "Times:", times

In the extract_days function, we loop through each workout and append the day field of each datetime object onto a list. See the datetime documentation for a complete list of fields. extract_times is similar to extract_days, but grabs the fourth element of each workout list (the workout time) instead.

Running the new code produces a list of days and workout times:

Days: [1, 3, 6, 9, 10, 11, 12, 13, 14]
Times: [25, 55, 20, 42, 10, 60, 60, 60, 60]

We’re now ready to start plotting.

4. Plotting

There are many plotting libraries available for Python. For this tutorial, we’ll stick with one of the most popular libraries based on MATLAB: matplotlib

4.1 Installing matplotlib

matplotlib does not come with the standard Python installation. In addition, it depends on another library called installing matplotlib page provides detailed instructions for installing matplotlib on Windows, Mac OS X, and Linux. Don’t forget to download and install numpy as well.

In order to choose the correct downloads, you need to know which version of Python you’re running. At the command-line, run python --version (mine says Python 2.7.2+). The first two numbers (2.7 for me) will give you an idea of which matplotlib file to choose. On Windows, I downloaded the file named “matplotlib-1.1.0.win32-py2.7.exe” because I have Python 2.7 and a 32-bit installation of Python. The numpy downloads are named similarly; I downloaded “numpy-1.6.1-win32-superpack-python2.7.exe”.

Once everything is installed, you can check that it’s working by running python and typing in the following code:

from matplotlib import pyplot

If no errors are printed, then you should be set.

4.2 Using matplotlib

There are many, many functions in matplotlib. Our program will use the pyplot.plot function, which makes line and scatter plots. This function takes a list of x values, a list of y values, and some options like the line thickness and color. For now, we’ll create a function called plot that will create a new figure, plot workout days vs. times, and then save the figure to a file.

import csv
from datetime import datetime
from matplotlib import pyplot

#------------------------------------------------------------

def keep_line(line):
    return len(line.strip()) > 0 and not line.startswith("#")

#------------------------------------------------------------

def filter_lines(reader):
    lines = []

    for line in reader:
        if keep_line(line):
            lines.append(line)

    return lines

#------------------------------------------------------------

def parse_workouts(rows):
    workouts = []

    for row in rows:
        date = datetime.strptime(row[0], "%Y, %b-%d")
        kind = row[1].strip()
        distance = int(row[2])
        time = int(row[3])

        workouts.append([date, kind, distance, time])

    return workouts

#------------------------------------------------------------

def extract_days(workouts):
    days = []

    for w in workouts:
        date = w[0]
        days.append(date.day)

    return days

#------------------------------------------------------------

def extract_times(workouts):
    times = []

    for w in workouts:
        times.append(w[3])

    return times

#------------------------------------------------------------

def plot(days, times, filename):
    fig = pyplot.figure()
    pyplot.plot(days, times)
    pyplot.savefig(filename)

#------------------------------------------------------------

reader = file("workout.csv", "r")
lines = filter_lines(reader)
csv_reader = csv.reader(lines)

workouts = parse_workouts(csv_reader)
days = extract_days(workouts)
times = extract_times(workouts)

plot(days, times, "workout_times.png")

Running this code will create a new file named workout_times.png that looks like this:

As you can see, matplotlib takes a “no frills” approach by default. We can spruce up our figure by adding a title, axes labels, a grid, and a “tick” on the x-axis for each day (instead of every other day).

def plot(days, times, filename):
    fig = pyplot.figure()
    pyplot.title("Times I worked out in March")
    pyplot.xlabel("Day")
    pyplot.ylabel("Time (min)")
    pyplot.xticks(range(1, max(days)+1))
    pyplot.grid()

    pyplot.plot(days, times, color="red", linewidth=2)
    pyplot.savefig(filename)

A complete description of these pyplot functions is beyond the scope of this tutorial. A future tutorial will explore them in detail. For now, we suggest using the matplotlib gallery to get an idea of what each function does.

With the changes above, workout_times.png is looking a lot nicer:

That’s all, folks! The complete code looks like this:

import csv
from datetime import datetime
from matplotlib import pyplot

#------------------------------------------------------------

def keep_line(line):
    return len(line.strip()) > 0 and not line.startswith("#")

#------------------------------------------------------------

def filter_lines(reader):
    lines = []

    for line in reader:
        if keep_line(line):
            lines.append(line)

    return lines

#------------------------------------------------------------

def parse_workouts(rows):
    workouts = []

    for row in rows:
        date = datetime.strptime(row[0], "%Y, %b-%d")
        kind = row[1].strip()
        distance = int(row[2])
        time = int(row[3])

        workouts.append([date, kind, distance, time])

    return workouts

#------------------------------------------------------------

def extract_days(workouts):
    days = []

    for w in workouts:
        date = w[0]
        days.append(date.day)

    return days

#------------------------------------------------------------

def extract_times(workouts):
    times = []

    for w in workouts:
        times.append(w[3])

    return times

#------------------------------------------------------------

def plot(days, times, filename):
    fig = pyplot.figure()
    pyplot.title("Times I worked out in March")
    pyplot.xlabel("Day")
    pyplot.ylabel("Time (min)")
    pyplot.xticks(range(1, max(days)+1))
    pyplot.grid()

    pyplot.plot(days, times, color="red", linewidth=2)
    pyplot.savefig(filename)

#------------------------------------------------------------

reader = file("workout.csv", "r")
lines = filter_lines(reader)
csv_reader = csv.reader(lines)

workouts = parse_workouts(csv_reader)
days = extract_days(workouts)
times = extract_times(workouts)

plot(days, times, "workout_times.png")

[Code and Data]

May 06, 2012 01:59 PM

For the boot camp at UCL, we tried using Mercurial (with EasyMercurial) instead of Subversion in the version control segment.

You can see the plan for the segment on this EasyMercurial project page. Briefly, we opened with a few plain slides about the purpose of version control, followed by a hands-on example in three parts (working by yourself, working by yourself with an online remote repository, and working with others). We started at the beginning and got as far as “hg bisect”, but did not cover branching.

I was presenting the segment, so I’m not well placed to judge how effective it was as a learning experience.  But I did make some notes.

Command line or GUI?

I started with the EasyMercurial GUI, made some (but in hindsight probably not enough) attempt to show how GUI operations corresponded to command-line operations, and dropped back to the command line for more esoteric ideas at the end (such as bisect).

However, more of the attendees were familiar with the command line than we had expected, so it might have been simpler to use that for the basics. Getting from nowhere to “…and now we’re using version control! see how easy that was” is a shorter process at the command line.  Using a GUI introduces distracting complications, such as the need to switch windows—aggravated in this case by my finding I wasn’t practised enough at doing the necessary switching cleanly when using projector resolutions and huge fonts.

On the other hand, EasyMercurial has a better view of the history and clearer merging, and I certainly wouldn’t want to introduce divergent simultaneous commits and merge conflict resolution without those.  (In my daily work I also use the GUI to manage these activities, even though I’m instinctively a command-line user.)

It seems counter-intuitive to say that the command line is better for basic stuff and the GUI better for advanced stuff, but perhaps that is the way it is. It would be interesting to have more feedback from others who were present.

Peer-to-Peer or Master Repository?

A common requirement is to share code between “my computer” and “the lab compute server” (implied for example in the “frequently asked question” at the end of the Software Carpentry version control lecture front page).

We approached this by using a master repository stored on an external server, in this case Bitbucket. But since we have a distributed version-control system, we could have taken a peer-to-peer approach, pushing and pulling between peer repositories on the two machines directly. We could have done this for sharing changes between paired neighbours in the boot camp, as well.

Using a master repository has advantages such as redundancy, availability, and backups. It’s probably better practice in a real lab, and it’s also easier to use a known remote server in a setting like this where everyone has one machine in front of them with a dynamic IP address using an unknown network topology.  On the other hand, there are situations in which it’s useful to know that a peer-to-peer arrangement is possible, and I do wonder whether we should have demonstrated it in some way.

One We Made Earlier?

We didn’t have any pre-prepared working material in the segment, just a few introductory slides followed by building a repository from scratch (with recipes in it). One suggestion was that we could provide a canned repository for people to start from to get them more quickly into “working together” mode.

My fear is that this would be to miss one of the biggest strengths of a distributed version control system: how simple it is to start using version control on your own project, without technical support from anyone, and then to push a server with all your history intact whenever you feel like it.

Delivery and Technical Bits

The biggest practical problem we had was that the room was fairly big with no microphone, and I simply don’t speak clearly and loudly enough to be heard by everyone at the back. I need to work on this!

There were a few technical problems with software installation, some of which we should be able to solve before next time around (e.g. issues with the EasyMercurial package on some versions of Ubuntu or with installing from source on Fedora). There weren’t all that many of these problems, but it doesn’t take very many to bog down a workshop.  On the upside, we didn’t have any network problems during this segment (a common cause of trouble).

I started out feeling a bit rushed, and although I had a plan and I largely followed it, I did forget to include a couple of planned excursions aimed at explaining more about which system we were going to learn and why, as well as some material about how often to commit, what material to include in a project under version control and so on. Generally I failed to provide as much context as I had intended to. However, the technical material did appear to be about the right amount for the time (and attention) available.

One thing we did that proved a bit tricky to set up and awkward to do, but that I think seemed worthwhile and that I would like to try again, was to use two projectors and thus show “both sides” of a collaborative working process with two people making edits live at the same time. Again I’d like to hear what others think.

Onwards

I’ll be running the version control segment at the Newcastle bootcamp as well, where I’ll be trying to improve on some of the things that didn’t go so well at UCL. This does mean it’d be great to have any more feedback sooner rather than later!

My thanks to Ben Waugh for the organisation at UCL, Chris Harte for presentation suggestions beforehand, and Luis Figueira for running the second laptop during the session.

May 04, 2012 01:47 PM

As with our monthly meet-ups, we’re recapping what you might have missed on our monthly community call.  A reminder: they’re held on the first Tuesday of every month at 2pm ET and details can be found on this etherpad. We … Continue reading →

May 03, 2012 05:41 PM

Just a reminder that we’re having the Toronto Teacher Hackjam this Saturday out of the Mozilla office.

http://torontoteacherhackjam.eventbrite.com

We have over 70 classroom teachers and volunteers signed up to attend, and a wide range of really cool sessions that I think that will inspire and delight.

If you’re interested in coming, or know anyone who’d be interested, pass the link along!

And if you’re feeling inspired to run a similar event in your area, fill out our interest form and let’s chat!

May 03, 2012 02:19 PM

A number of folks here in Mozilla Foundation land been hard at work putting together an editor that I’ve talked about before called Webpage Maker.

The idea is to have a two-pane editor so that you can type on the left and have it updated on the right in real-time. This is super-cool and gives you the kind of immediate-feedback-loop that makes tinkering possible.

There are actually a few great websites out there that already do this kind of live preview, so why make our own?

First off, we’re working on a library that provides hints/errors as you type. Like spellcheck for html. Forgot to close a tag? Left an open quotation mark dangling? We’ll let you know. We’re hoping that this library will be used not only by our Webpage Maker app, but that any and all folks who have “type your html here” parts to their apps can use it (and help us expand it!) to make typing HTML/CSS just a little bit easier across the whole web.

We’re also providing one-click publishing/saving/sharing and remixing, bringing together two core elements of the web. It should be super-easy to whip up a quick webpage without thinking about the complex questions of hosting and such. And it should be super-easy to remix someone else’s work.

Lastly, our learning team is hard at work making a number of hackable templates.  If you remix one of these templates, you’ll have some basic instructions that you can follow to learn something about webmaking.

Webpage Maker is gonna be ready (in an early form) in time for our summer campaign and we already have tons of ideas for where to take it next, but we’re excited to see how folks start to use it.

In particular, I’m excited by the fact that Webpage Maker isn’t intended to be a product that’s going to push out all of the existing online editors. Instead, we’re trying to put together a number of libraries and services that ultimately I hope will help improve the whole ecosystem of online editors.

May 03, 2012 02:17 PM

We’ve come to the end of a hot, slightly sweaty, two days of learning in UCL and have just done a straw poll of participants of the good and bad points of this bootcamp. Something that was trialled at UCL was asking participants to sign up in small (3-4 people) teams drawn from their local research group.  In total, we had a little over 40 learners and 10 helpers. We also taught the version control portion using EasyMercurial (thanks to Chris Cannam from SoundSoftware).

Here’s what we learned…

Good

• Beginner friendly
• Easy learning curve
• Now know how to use SQL
• Doesn’t matter what programming language I used in the first place
• Version control for the win
• Taught functional programming rather than object-oriented
• Material backed up by anecdotes and evidence
• Good at giving thoughts rather than skills
• Can go back and share with other members of the group
• Killed my fear of version control
• Give tips on good programming practices
• Anything new was given with the why as well as the what
• Introduction to systematic testing
• Best balance of typing, testing and listening
• Good ratio of helpers to students
• Greg’s digressions keep your mind active
• Learned feedback technique of using coloured sticky notes
• Test driven development
• Quoted Alan Turing (programs are just a type of data)
• Working in pairs
• Live coding (realtime typing)
• Being forced to use python
• Psychological aspects, and how it relates to programming
• Always good to reinforce the learning of things you’ve heard before
• Interaction with participants at workshops – both in workshop and in pub
• Website is a good resource
• Insight (for a sysadmin) of how the researchers I support work

Bad

• Can’t afford to buy all the books referenced
• Too early a start [9am start both days in central London]
• Too much to take in
• Not enough functional programming
• Lower level than group is used to
• Need coffee at the start of the morning [which we didn't have on day 2]
• Problems with the wireless network
• Need biscuits in the afternoon
• No handouts [though SWC does this because best practice suggests you shouldn't give out handouts at the start]
• Lack of air conditioning
• Too short (not enough days) [SWC experience shows that 5 days F2F didn't work, will have online followups]
• Not clear when you should be furiously catching up on typing
• Greg’s too fast
• Helpers not physically interspersed amongst tutors
• Room too small
• Not enough desks / table arrangements
• Couldn’t find nose on list of required software
• No documentation on how to get nose running on a windows system
• No toilets / running water on the same floor [we broke the toilets and the lift!]
• Microphone would have been good
• Recommending Cygwin rather than VMware or Virtualbox [but people want to come out with a working setup...]
• Implied endorsement of bittorrent for illegal activities (plus smartass comments)

What does this tell us? Probably that the teaching environment has a much bigger impact than you might expect, and that we should do all we can to fix it upstream. Also that Greg talks and types too fast!

We’re going to have plenty of chances to see how these good and bad points change as we go on to the next workshops – collecting the evidence so that we can understand how to teach people better.

 

 

May 02, 2012 10:29 AM

I’m really excited about the Popcorn Story Camp coming up this summer. The program planning is coming along nicely, and we’re beginning to make assets (which is always fun). Just check out Kate Hudson’s awesome branding sketches.

We’ve even already written the first draft of a sample curriculum to help webmakers and educators spread the joy of Popcorning. It’s called “Introduction to Web Native Film”, and it’s not just about Popcorn. The idea is that learners will get a solid footing in the definition and processes of Web Native Filmmaking, and they’ll do so while learning other webmaking skills like community etiquette, collaborative making, restaurant html and many more. No, this isn’t just about Popcorn, it’s about webmaking.

The Popcorn Story Camp will run in youth organizations this summer. We’ll be holding and recording Webinars with totally awesome guest speakers. Learners will be invited to create a multitude of content surrounding their topics and at the end of the six weeks, the youth that participate in the Popcorn Story Camp will showcase their films and projects and share them with all of us.

Although this content is being created for the summer program, everything we’re doing is customizable and modular. We’ll have DIYs, Cheatsheets, Curriculum and Information that are supported by a six chapter film that covers things like Media History and Remixing. We’ll be creating online and downloadable resources to get filmmakers thinking about their craft in a whole new light.

May 01, 2012 11:53 AM

True fact: I may have spent several hours this weekend watching Crash Course on World History videos.  Not only because I wanted to see whether or not they accurately portrayed our best understanding of pre-agricultural history (and unlike most folks, they did), but also because I found the short-video format to be kind of addictive.

My rate of “things I was learning per minute” was remarkably high.

It made me start to wonder whether or not it would make sense to have a series of short facts about how the web works.  Not long 60-minute lectures about the history of ICANN, but just quick bites of information.

I put together this 2-minute video of the definition of HTML and CSS in an attempt to prototype the format.

As you can probably tell, my artistic ability needs some, ahem, work.  Nor is the script perfect.  But it’s an example of the type of video that I mean.  Extremely short, just explaining a single bite-sized concept.

Thoughts?

April 30, 2012 10:05 PM

I’m sitting in a packed room helping out at the UCL bootcamp, the first of a series to be run in the United Kingdom (Newcastle is next, and there are plans to run additional workshops in Oxford, RAL, Glasgow, Edinburgh and Bristol). I’m thinking about two things: why would you design a 60 seater lecture theatre with only one window for ventilation and why is Software Carpentry so popular in the UK?

Here are the statistics: the waiting list for the UCL bootcamp is 3x bigger than the capacity of the room; the (larger) Newcastle workshop is oversubscribed twice over; our main issue is making sure that tutors at bootcamps aren’t double-booked.

So why is Software Carpentry seeing such levels of interest?

One thing I do know is that it isn’t just the Greg Wilson effect – Greg is only teaching at this workshop, the other bootcamps are being led by people from the Software Sustainability Institute, SoundSoftware and the local institutions. Is there another explanation? I’m going to suggest three possible factors and would like to hear if there’s evidence to support or contradict it, particularly if there are similar factors in other countries.

1. The BBC Micro / Sinclair Spectrum effect
2. Doctoral Training Centres
3. Climategate

The BBC Micro / Sinclair Spectrum effect

Thirty years ago, two computers changed the course of the UK IT industry: the BBC Micro and the Sinclair ZX Spectrum. These machines, and the associated TV programmes and magazines, encouraged a generation to experiment with programming. Fast forward to 2012, and not only does the generation which grew up with PEEKs and POKEs form the technical backbone of the video games industry and companies like ARM, but that generation is bemoaning the lack of something similar in schools that has led to successive generations not having the basic understanding of software programming.

Doctoral Training Centres

Doctoral Training Centres were initially funded by the UK research councils to increase the research capacity in interdisciplinary research activities such as the life sciences interface and complexity science that are difficult to locate within a traditional University’s departmental organisation. Increasingly, students at the centres receive training on specialist transferable skills which are applicable to their area, and many centres are teaching software development. This means that those researchers undertaking PhDs within these centres have had additional training over the rest. There are over 50 DTCs across the country and across many disciplines.

Climategate

When a server at the Climate Research Unit was hacked and thousands of emails and computer files were spread across the internet, the impact was not just in the exposure of poor working practices. They showed to the world the struggles of a scientist called “Harry” as he attempted to wrestle with difficult data analysis code. Now, even though there is no evidence that the code was producing incorrect results, the fact that it was difficult to prove the validity caused a crisis. In the UK ClimateGate wasn’t just confined to the scientific press: national newspapers such as the Guardian, Telegraph, and even the somewhat sensationalist Daily Mail picked up the story. Suddenly scientists were all over the news, and it wasn’t pretty.

So my theory is that given a culture in the UK where we have a group of researchers who didn’t get the same direct experience of programming at school that their research leaders did, are seeing the next generation of PhD students snapping at their heels, and who definitely don’t want to be part of the next coding scandal have realised that it’s good to go back to basics, to learn not just what or how to programme, but why we programme.

And that is the ethos of Software Carpentry.

 

April 30, 2012 02:11 PM

I used to tell this joke:

An engineer says, “Theory approximates reality.”
A mathematician says, “Reality approximates theory.”
A sociologist says, “Would you like fries with that?”

I stopped telling it after someone who actually was a sociologist pointed out just how much it revealed about my value system. By the time she and her partner finished dissecting the cultural biases implicit in those three lines, and analyzing what my choice to tell that joke in that setting to that audience revealed about my peer group’s belief system, the humor had pretty much evaporated.

Skip forward ten years. It was the early 2000s, just after the first dot-com bubble burst, and I started noticing that all of a sudden, programmers were taking design and graphic designers seriously. Overnight, it seemed, companies had started paying designers competitively and giving them real authority. Somehow, nerds like me who had made jokes about people with “soft” skills (and boy, isn’t that term revealing) had come to realize just how valuable and difficult those skills were.

Skip forward a few more years to 2010. After a lot of rear-guard defensive denial on my part, Jorge Aranda, Marian Petre, and others had finally convinced me that “soft” (qualitative) research techniques weren’t just another way to explore how software development teams worked—in many cases, they were the best way. When I left the University of Toronto to work full-time on Software Carpentry, though, I didn’t transfer that understanding to education. Instead, I only read things based on “hard” data, i.e., statistical results from controlled experiments. In retrospect, it’s little wonder I was so frustrated by how little it helped me…

Skip forward one more time to 2012. The web is abuzz with techies and business people explaining how they’re going to fix education. What most of them actually mean is, “Here’s how we’re going to make money from education,” but that’s not what this post is about. What it’s about is that they don’t value educators professionally the way they value designers [1]. Just take a look at the ed-tech startups Audrey Watters has profiled in the last twelve months: how many have anyone in house who has spent even two full days boning up on the psychology of learning, the evidential basis for different instructional techniques, or the reasons why previous attempts to technologize classrooms have failed?

I think that if we (and by “we”, I mean programmers) really want to help people, we need to meet educators halfway. We need to learn as much about education as we now do about graphic design, business, marketing, and intellectual property law. I realize it’s difficult—there aren’t “serious amateur” books about education for techies like there are about graphic design [2]—but throwing questions from the Audrey Test into Google is a start. I’d certainly be a lot further ahead if I’d done that two years ago, and I suspect most ed-tech startups will be further ahead two years from now if they get started today.

[1] This isn’t an industry vs. academia thing: the software engineering researchers who described statistical work in Making Software didn’t feel the need to defend the value of their methods in the way that the people doing qualitative work did.

[2] At least, I haven’t found any.

April 28, 2012 02:18 PM

How can we make coding and webmaking a family affair?

As part of Mozilla’s big Summer Code Party (kicking off June 23), we’re inviting the world to host teach-ins and learning events. Everywhere. At their local library, at partner events, at Mozilla offices, and with small groups of family and friends around their own kitchen table.

Recipes for webmaking: testing the “Kitchen Table” event kit

This new Kitchen Table Event Kit is a draft “how to” for hosting your own kitchen table hack jam. We invited you to help prototype and test it in preparation for going big this summer, using Mozilla webmaking tools like Hackasaurus and Popcorn.

More than fifteen awesome groups of families and friends got together to test it out — from five-year-olds making web pages about snails with their dad, to adult friends getting together for a “mimosas and making” party.  Here’s what we learned together.

What was your favorite moment?

Here’s what our brave beta testers said was their favorite part of the experience:

• “The SQUEAL when my friend first hacked Google.”
• “When my mom replaced an image of a chocolate chip cookie on a webpage of a  kitchen table with an image of matzo so it was kosher for passover.”
• “When (5 and 6-year old) Lucas and Kai saw themselves in a web page with their freshly captivated snail, they so began to get the idea of how info gets into the web.”
• “Watching my boyfriend and my mom work on something together.”
• “When  my friends started ignoring me completely so that they could make their  remixes more remixy. I was talking about something and they were like  ‘What?’”

What we learned:

• People enjoyed the format. But sometimes found it awkward to get out of a traditional “teacher” role.
• Keep the activity asks simple. But be familiar with the specific skills and interests of participants.
• Grow a leadership community of people who’ve done the events and can support others.
• Make it interest-based. Start with something people are already interested in. Or a web site they use all the time and are familiar with — then have them take it apart and remix it with the X-Ray Goggles.

What we’ll do to improve:

• Continue to refine the Kitchen Table Event Kit. Polish it up for our May 15 announcement bout the campaign.
• Create clear communication channels for hosts. Before, during, and after events.
• Provide more simple learning projects and curriculum.  Offerings that help people find activities that fit their interests.
• Smoother “share” functionality. Create a gallery of hacks and completed projects, so you can see what others made.

Going deeper: your analysis and feedback

There’s lots more great analysis and feedback from our testers, with take aways from:

• Laura Hilliger (broken down by different demographic categories, from youth newbies to intermediate adults)
• Jess Klein (hacking the kitchen table at Passover)
• Lainie De Coursey (hacking with the whole family)
• Bananigans (Hackasaurus with college friends)
• Michelle Thorne (“Mimosas and Making” with adult friends)
• Malcolm in Chicago (Hackasaurus and Popcorn with teens)
• Peter (Hackasaurus with 5 and 6-year-old brothers)
• More raw data from betatester feedback

Get involved

• Host your own Kitchen Table Hack Jam. Try out the new event kit for yourself, and let us know how it can be improved.
• Learn more about our Summer Code Party campaign.
• Sign up for more teaching resources, event kits, and updates as they come available.
• Read Mark Surman’s post on kitchen table hack jams and creating a “big tent for anyone who shares our goal of a more web literate planet.”
• Learn more about other fun coding and webmaking tools like the Love Bomb maker and upcoming “Web Arcade.”
• UPDATE: See Mark Surman’s excellent “Teaching Webmaking in 10 mins“

 

April 27, 2012 08:50 PM

This weekend, the Mozilla Toronto office will host six leading documentary  film-making teams. Their mission: pair up with web developers to push the envelope of documentary storytelling — using cutting-edge new open source software created by the global Mozilla community.

Run in conjunction with the prestigious Hot Docs documentary film festival, the teams will use Mozilla Popcorn to create prototypes that push the limits of storytelling online — pulling context, interactivity and other web elements right into the narrative. The result: a new form of “web-native” cinema that lives, breathes and changes just like the open web itself.

Hot Hacks projects: prototyping the future of story

The six “Hot Hacks” projects are:

 The Message: the (r)evolutionary power of climate change — a multi-platform (book + documentary + web + events) project by author Naomi Klein and director Avi Lewis.

Immigrant Nation: Using Facebook and other social media, Immigrant Nation will present a dynamic representation of immigration statistics from across the city.

Turcot: Turcot  looks at Montreal’s largest highway interchange, currently  scheduled  for a complete demolition and rebuild. The interactivity will give residents a voice, using geo-tagging, narrative slide shows, onionskin maps  and a chronological historical timeline.

Following Wise Men (working title): Building  a community  around astronomy through a searchable, community-sourced  science web  site. The project will chart astronomers and their discoveries in the  context of their  professors, mentors and students in an “astronomer’s  family tree.”

Looking at Los Sures: Using  an archival documentary (Los Sures by Diego Echeverria, 1984) about the  South Williamsburg neighborhood, the project brings together new short interactive projects from thirty different  artists over three  years. It will annotate and expand on the original film in new  ways, allowing viewers to move fluidly between the past and present.

The Last Hijack: For over 20 years Somalis have faced the horror of famine and war. The Last Hijack is a story about survival in this failed state, and about the rise of piracy and how it affects the people around it.

Part of The “Living Docs” Project

Hot Hacks is part of the Living Docs project, a series of events, projects and code to bring openness and innovation to documentary. Living Docs is a collaboration between Mozilla, ITVS, the Tribeca Film Institute, BAVC and the Center for Social Media at American University.

Get involved:

• Read more about the Hot Hacks projects
• Learn more about the “Living Docs” project
• Try Mozilla Popcorn for yourself now
• Have a look at a recent “Living Docs” hackfest in San Francisco

 

April 27, 2012 05:43 PM

Last week, I posted an exercise on working with sets and dictionaries that also included a fair bit of file I/O and string manipulation. My solution is below, in four parts, along with the code produced in each. If someone would like to re-do the file parsing using regular expressions, I’d be happy to post that as well.

Part 1

Click here to view the video on YouTube.

import sys

#--------------------

def parse_pair(pair):
    '''
    Parse an atom-count pair.  If the count is missing, assume
    that the count value is 1.
    '''
    if '*' not in pair:
        return pair, 1
    atom, count = pair.split('*')
    count = int(count)
    return atom, count

#--------------------

def parse_molecule(text):
    '''
    Get a single molecule description from a text string.
    '''
    name, formula_text = text.split(':')
    name = name.strip()
    pairs = formula_text.strip().split('.')
    formula = {}
    for p in pairs:
        atom, count = parse_pair(p)
        assert atom not in formula, \
               'Already seen atom %s in text %s' % (atom, text)
        formula[atom] = count
    return name, formula

#--------------------

def read_molecules(reader):
    '''
    Read molecules from a molecule file, returning a dictionary
    of {name : formula} pairs.
    '''
    result = {}
    for line in reader:
        line = line.strip()
        if (not line) or line.startswith('#'):
            continue
        name, formula = parse_molecule(line)
        assert name not in result, \
               'Already seen %s!' % name
        result[name] = formula
    return result

#--------------------

print read_molecules(sys.stdin)

Part 2

Click here to view the video on YouTube.

def merge(left, right):
    result = {}

    for key in left:
        # Only in left
        if key not in right:
            result[key] = left[key]
        # In both, so check that values are the same.
        else:
            if left[key] == right[key]:
                result[key] = left[key]

    for key in right:
        # Only in right.
        if key not in left:
            result[key] = right[key]

    return result

Part 3

Click here to view the video on YouTube.

import sys
from nano import read_molecules

#--------------------

def can_produce(formulas, atom):
    '''
    Return the set of molecules that contain the given atom.
    '''
    result = set()
    for molecule in formulas:
        if atom in formulas[molecule]:
            result.add(molecule)
    return result

#--------------------

if __name__ == '__main__':
    data = read_molecules(sys.stdin)
    atom = sys.argv[1]
    print can_produce(data, atom)

Part 4

Click here to view the video on YouTube.

import sys
from nano import read_molecules
from merge import merge
from produce import can_produce

#--------------------

def get_data(filename):
    if len(filenames) == 0:
        data = read_molecules(sys.stdin)
    else:
        data = {}
        for f in filenames:
            reader = open(f, 'r')
            more_data = read_molecules(reader)
            reader.close()
            data = merge(data, more_data)
    return data

#--------------------

if __name__ == '__main__':
    assert len(sys.argv) >= 2, 'Usage: final.py atom [files...]'
    atom_name = sys.argv[1]
    filenames = sys.argv[2:]
    data = get_data(filenames)
    makeable = can_produce(data, atom_name)
    makeable = list(makeable)
    makeable.sort()
    for m in makeable:
        print m

April 26, 2012 07:59 PM

This summer, Mozilla will take it’s first stab at teaching about code. ‘Code’ in both the webbiest sense of the word: we want to expose 10,000s of people to HTML, CSS and JavaScript to help them make things on the web. Or, at least, to give them a glimpse of how the web works.

Kicking off on June 23, we’re calling this experiment the Summer Code Party. It’s an invite for anyone who wants to teach — or learn — webmaking to spend a few minutes building something with friends. Like the Product (Red) campaign, it’s a big tent for anyone who shares our goal of a more web literate planet. Tumblr. Girls Learning Code. Soundcloud. CoderDojo. Creative Commons. etc. Over a dozen partners are already signed up.

The most basic version of participation: do a small Hackasaurus project with two friends around your kitchen table or in your living room. Taking a cue from Jess and Atul’s LoveBomb prototype, we’re developing half a dozen small starter projects that will make this easy. Of course, the hope is that people will do this more than once after they’ve tried it — but even a single kitchen table event is a great way to show people how the web works.

In addition to Hackasaurus projects, we will also offer up a collection of DIY web projects from partners. For example, we’re working with Tumblr to develop some well-commented templates that both help people make their Tumblr look cooler and help them improve their HTML and CSS a little. Other partners will be posting their own small projects on our wiki.

Some partners are taking on more ambitious projects under the Summer Code Party banner. For example, Girls Learning Code is hoping to offer a week long summer camp at the Mozilla Toronto office. This will cover HTML, CSS, Python and Scratch. Other partners will simply plug their existing summer code efforts into the Party, sharing out what people are learning and making with people around the world doing similar things.

Which brings me to how this all fits together: everyone will be invited to share out what they’ve made, both online and at a series of local events in September. The best projects will get badges. And the best local organizers and instructors will get an invite to the Mozilla Festival in London to help us figure out how to improve our webmaking tools and grow out our community.

For now, there are three ways to get involved: 1) Put your name of the list of people who want run a small code party at home or in a cafe; 2) Sign up as a partner or collaborator; and 3) Put yourself on the volunteer list for our June 23 and 24 kick off event. Or, if you want to get even more involved, join one of our weekly Webmaker conference calls. They happen every Tuesday.

Would love to hear ideas, reactions and partner leads. This should be fun.

Filed under: drumbeat, education, learning, mozilla, webmakers

April 26, 2012 03:10 PM

HTML is a very interesting machine language because, like human languages, most things that interpret it are very forgiving.

For instance, did you know that the following HTML is technically invalid?

<video>
  <source src="movie.mp4"></source>
</video>

It’s invalid because <source> is a so-called void element: since it can’t have any content inside it, you simply don’t need a closing tag for it. The <img> tag works the same way. The technically correct way to write the above HTML snippet is as follows:

<video>
  <source src="movie.mp4">
</video>

However, in practice, all Web browsers will interpret both of these snippets the exact same way. When a browser sees the closing </source> tag on the first snippet, it realizes the “mistake” the author has made, and simply pretends it isn’t there.

What’s interesting to me is the way this mirrors human languages, and what it means for teaching. For instance, the following sentence is grammatically incorrect:

The dog loves it's owner.

However, no one who knows English will actually be confused by the meaning of the statement.

When I was trained as an adult literacy tutor several years ago, one of the most important principles we were taught was that fostering a love for writing was vastly more important than grammatical correctness. The “red pen” commonly used by school teachers for correcting grammatical errors was seen as anathema to this: when we found a grammatical error in a novice writer’s work, we were encouraged to ignore it unless it actually made the piece confusing or ambiguous for readers in a way that the author didn’t intend. Otherwise, the novice writer would become quickly distracted and discouraged by all their “mistakes” and view writing as a minefield rather than a way to communicate their thoughts and ideas.

We’re running into similar issues in the design of the Webpage Maker. On one hand, the fact that Web browsers are so forgiving when interpreting HTML enables us to follow a similar philosophy as that of progressive adult literacy tutors.

But sometimes, the forgiving nature of Web browsers backfires: they actually render a document that is vastly different from the author’s intent, which is just as frustrating as a pedantic nitpicker. We’ve created a library called Slowparse—soon to be renamed—which attempts to assist with this, providing the logic needed for a user interface to gently inform users of potential ways their HTML and CSS code might be misinterpreted by machines. A full specification of errors and warnings is also available, as is an interactive demo that uses the library to provide real-time feedback to users.

It’s been interesting to see how different Slowparse is from a HTML/CSS validator, whose goal is not one of learning, but of ensuring conformance to a specification. From a learning perspective, a validator is like the pedantic teacher who loves their red pen: some of its feedback is quite useful, but the remainder is likely to confuse and intimidate a newcomer.

Partly as a result of its learning goals, Slowparse actually “warns” the user of things that are technically valid HTML/CSS, but which likely don’t reflect the intent of the author. One current example of this is in regards to the use of unquoted attributes in HTML5, though that particular example is still subject to change.

At this point, I think the challenge will be to work with our learning team and user test our interface to the point that we achieve a good balance between being a pedantic nitpicker and providing useful feedback that helps users as quickly as possible. In my opinion, if we do things right, we’ll help people develop a love for HTML and CSS—even if what they write may technically be “grammatically incorrect.”

April 26, 2012 02:40 PM

Mozilla’s big upcoming Summer Campaign is all about making it easy and fun for anyone to learn basic coding and webmaking.

To that end, the Mozilla Webmaker community has been hard at work on curriculum, learning missions and starter projects — including a new “Web Arcade” packed with hackable missions and games.

Mini-games that bake in HTML and CSS

“Enter the Web Arcade to explore the Open Web, a world of serious cats, planking videos and minecraft  empires. The Web Arcade offers mini-games that help you level up your HTML and CSS skills — and MAKE your very own web masterpieces.”

As Jess, Laura and Chloe explained in yesterday’s Mozilla Webmaker call, the arcade includes mini-games like:

• “Make Me Pretty.” Update ugly webpages. Go back in time to 1999 — and update ugly pages for today’s web. Read about it. Or try it out now.
  
• “Internet Famous.” Use your HTML and CSS swagger to mix and match elements, creating an internet meme to conquer all internet memes.
• SansComic Killer. Format this typography — please!
• Webstructable. Make your own tutorial, sharing what you’ve learned.

Get involved

• Try out the “Make Me Pretty” demo.
• Watch and listen to the team present this work in progress (from yesterday’s Mozilla Webmaker call).
• Read more about teaching webmaking through games, missions and projects. (Jess Klein’s blog post.)
• Learn more about the Web Arcade. (Chloe Varelidi’s post.)
• Learn more about “Make Me Pretty” (Laura Hilliger’s post.)
• Volunteer for user testing. This is all a work in progress — add your name here to volunteer for user testing once new games and missions are ready.

April 26, 2012 01:28 PM

From this point forward, we’re going to recap the amazing-ness that is our monthly member meet-ups.  On the third Thursday of every month, 25-40 Hive NYC members gather to learn more about other youth programs in the city, brainstorm around … Continue reading →

April 25, 2012 10:07 PM

Prepping for May 15 blastoff. We’re working up to a big public announcement around Mozilla’s upcoming summer campaign. D-day is Tuesday, May 15. The party itself will kick off June 23.

Mozilla’s Summer Code Party: June 23 – Sep 23

• What? MEET up, MAKE something cool and LEARN how the code behind the web works.
• When? June 23 – Sep 23, kicking off with a Global Weekend of Code.
• Where? Anywhere. Your kitchen table. Your office. Your local library.
• Why? We believe everyone should know how to create and code on the web.
• How? Organize a meet-up. Volunteer to teach. Or become a partner.

Pre-flight checklist:

• Wiki: check out the Summer Code Party wiki.
• Communications: finalizing copy and messaging for the May 15 announcement, including press outreach.
• Partners: recruiting is in progress. Tumblr, CoderDojo and many others are on board, with lots more on the way. Join us.
• Events platform: In development, targeted for first phase release May 15. Will allow people to search for and add their own teach-ins, meet-ups and events.
• Get involved: Sign-up for reminders and updates. 

Host your own Summer Code Party event

More polished event “How Tos” are on the way for May 15. In the mean time:

• 1) Check out this guide on hosting your own “kitchen table” teach-in
• 2) Sign up for new updates and materials as they arrive

April 25, 2012 07:36 PM

Earlier this year, we posed a question to Audrey Watters: should Mozilla build a ‘scratch’ for HTML5?

Since then, she’s been chatting with lots of smart folks, and has come to some conclusions.  Curious?

This Thursday (Apr 26th), I’ll be hosting a fireside chat online to talk with Audrey about what she discovered, her conclusions, and to moderate some questions that folks have been wondering about with respect to this topic.

I imagine that the event will loosely resemble this photo below.

I’ll be the one sloshing around the large cup of alcohol, which I guess makes Audrey the quasi-hidden elf-child in the photo?  Or maybe the elf-feet represents you, the quasi-hidden internet viewer who can totally tune in to hear our discussion and ask questions, and Audrey’s the one in the dashing suit and I’m an invisible narrator.

Either way, if you’re interested please join us!

• Audrey Watters: A Fireside Chat
• April 26th, online, 12-1pm ET

Lanyrd info: http://lanyrd.com/2012/scratchhtml5/

Etherpad for questions: https://etherpad.mozilla.org/audrey-fireside

 

April 24, 2012 04:58 PM

Have you tried to learn how to code, and signed up to get weekly instructionals? Did you stick with it? Ok, did you stick with it past week four? If you did stick with it-are you proud with what you made? And, finally-if you are proud of what you made, could you show a friend how to make that web project?

In my totally unscientific poll of asking everyone who comes into my walking distance-I have learned that the answer to the majority of these questions is no. I guess that the reason that I was even motivated to ask these questions is that from my years of trying to learn how to code, I pretty much made it through the first few weeks on pure wanting-to-be-a-geek desire alone, but then lost that spark when things got complicated because I had no personal interest in the projects assigned to me and let's just say my work ethic fizzed out.


This got me to thinking about projects-what would be interesting to learn? In almost every class (whether it be graphic or web design) I've taken I have been asked to make the logo, business card, stationary, portfolio site suite. Frankly, since I was learning, they sucked. Doubly frankly, when I left school I had no diversity in my portfolio- but I did have a pretty damn good set of outmoded designs to send out with my resume.  But what would I have wanted to make? What would have be better for me to learn to expand my skillset. Because there are many solutions to this question-at Mozilla we are working on compiling a suite of projects to help webmakers and future webmakers sink their teeth into projects that they find interesting. In turn, the learner can curate their own making experience.

• Come up with ideas
• Learn something new
• Find a like-minded community
• Get motivated

So what does this mean for Mozilla? Well, in the past I have talked about the Webpagemaker-a two paned editor that will give you responsive feedback on your coding. Projects are learning challenges presented as hackable webpages that can be tinkered with inside the Webpagemaker tool.

Note: in previous blogposts I referred to projects as missions- we changed the name for many reasons, but ultimately to be in sync with other Mozilla initiates that are launching at a similar time.

In conjunction with the Summer campaign we will be launching 5 "Mozilla" projects-themed under the umbrella of Web Arcade. These are going to be game like projects that teach you the basics of html and css while you are making actual things.

Chloe Varelidi has been posting some of her brainstorms around the Web Arcade Projects.

Here is one project that we have been working on, mocked up by Chloe called Internet Famous. The idea is that a user can learn how to make their own internet meme, such as serious cat, pictured above.

Laura Hilliger wrote about one of the projects that she is developing for the Web Arcade here, the idea behind this is that you are remixing a webpage that is stuck in the 90s.



Members of Hive NYC will be working on several projects to launch in conjunction with the Summer Code Party, including Writing a Chapter of Inanimate Alice by using the X-Ray Goggles to hack a story. This will be a D.I.Y style project.

In addition to Mozilla projects, we will be working with some partners for the Summer Code Party to make their own projects. So, for example one project will be "How to customize your Tumblr" theme and another might include how to make animated gif like imagery only using HTML and CSS.

As I mentioned in an earlier post, we are also creating a pathway so that users can make their own projects and submit them to the project listing.



Yes, this is not a brand new idea, sites like Make and Instructables do it well, but the reason that Mozilla is doing it is that we have an amazing diversity of people who are working together to build a community of practice around webmaking. While that might translate to remixing, tinkering and hacking things up, it's that Nike spirit of just do it that motivates people to go, to learn and to bring a little piece of their local world into this handcrafted community and canvas that is the web.

April 24, 2012 01:09 PM

Make Me Pretty

Remember how ugly the Web used to be? We’re in the process of developing some learning content that uses that sad fact to teach basic web design concepts and help people level up on their HTML/CSS. We’ve thought up a slick way to deliver the curriculum using comments and will be using the method across the board. All the Make Me Pretty Projects have cool ASCII images in the code and ask a learner to “Make Me Pretty”. Learners tinker with the CSS and content to make each page their own. Here’s the first 3 ideas:

Stuck in the 90′s – We need a new name (“Stuck in the 90s” is kind of boring)

Sans Comic

Color Collapse

You can take a look at the curriculum here. And we’d love any feedback you have!

Popcorn DIYs

For Popcorn, we’re creating Do-It-Yourself templates that guide learners step-by-step through the process of making a Popcornified video. We’ve started with a single DIY that asks learners to pull an old commercial from the Prelinger Archive and add their own voice using popups. Kate Hudson is creating special templates for these DIYs, and we’ll be offering them through the Webpagemaker as well as other avenues (eg through mozillapopcorn.org, in the context of the Summer Story Camp, etc).

April 24, 2012 12:39 PM

Fantastic talk by the LA Times’ Ben Welsh about algorithms, reporting, and people.

April 23, 2012 09:07 PM

The Toronto Teacher Hackjam is only a few weeks away, on May 5th, and I’m pretty excited about the sessions that we have planned.

The event is a one-day meetup for classroom teachers to inspire them with ways that they can incorporate web making into their classroom, without pushing aside required curriculum.

Some of the cool stations that teachers can choose from include:

• Introduction to Scratch
• Collaborative Story Writing on the Web
• Digital Social Studies with Google Maps and Javascript
• Wikipedia Editing for Credit
• Intro to Collaborative Web Making
• Making Web Movies with Popcorn
• Edmodo in the Classroom

There won’t be enough time in the day to attend all of them, so I’ve already had some teachers send me “when’s the next hackjam scheduled?” questions, haha.

We have all sorts of teachers signed up from elementary school through college, as well as some interested parents, school administrators and informal instructors.

If you know of folks who might be interested in attending, please do send them our way! And if you think that this is something that would get a lot of love and attention in your local community, let us know you’re interested.

April 23, 2012 04:31 PM

I spent my entire weekend making stuff in collaboration with newbie and oldie Webmakers. It was fun. Here’s my (brief) roundup on the three separate events.

Friday Night: Kitchen Table with Kids

All I had to do was offer “real” American Cheeseburgers to get an 8 year old and a 5 year old to let me show them some web stuff. I introduced them to the Hackasaurus XRay goggles. The five year old was interested for about two seconds, but then the ants in his pants must have started biting him because he decided to get up and run around. The eight year old spent some time hacking the zoo’s website and changing the names of the animals profiled there. She needed a lot of help and was a bit afraid of the code aspect. We hacked for about thirty minutes, and in the end she said (loosely translated)

“It’s pretty cool that you can mess the Internet up.”

Win.

Saturday: Popcorn Learning Lab – The next morning I got up early and headed to Berlin to help out Michelle and Cole. We started with some demos, then broke into groups. Group A took a look at the Popcorn Maker and Group B took a look at Popcorn JS. We hacked for awhile getting used to the tool/code and then we had lunch. When we returned, whomever had an idea for what to make pitched the idea. Then we formed groups and spent the rest of the day hacking on six ideas. Everyone hacked, everyone brainstormed, everyone made things and had fun.

Win.

Sunday: Earth Day Online – Headed towards Hamburg Saturday evening. Spent the night in a tiny German village and then Sunday morning I headed into the city. After hanging around in a cafe for a couple hours, I headed to the Betahaus Hamburg to hack. We had a VERY intimate group taking up the donated Betahaus space. Betahaus was wonderful, and a perfect address to gather webmakers in Hamburg. I hope we can work together in a more formal way in the future (Betahaus was kind enough to donate the space and have someone work on a Sunday, despite the fact that they are a young startup). HUGE THANK YOU! Admittedly, we spent a lot of time yakking, and just a little time hacking, but there was enthusiasm for the Mozilla tools and ethos. People are EXCITED about our work, and they want to help us.

Win.

In short, met a lot of potential contributors, got great feedback on tools and ideas and had fun webmaking all weekend.

Win.

April 23, 2012 11:10 AM

Like many of my colleagues working in education, for whom the next few weeks are busy with grading students’ assignments or exams, I’m currently marking projects from my Mozilla Development course at Seneca.  I’ve been rereading student blogs and looking back at bugs, and started to see some common things emerging.  I wanted to share some of them.

The majority of my students worked on bugs in Firefox, specifically Gecko bugs related to the media element, DOM events, fullscreen, and pointer lock.  Because they were clustered together in similar areas of the code, they were able to help each other quite a bit, and talk with one another about struggles they were having, and celebrate when things got landed.  In general they each worked on 4-8 bugs, usually getting half of them landed by the end of the course, and therefore shipping in some future version of Firefox.  They ranged from Good-First-Bug type issues right up to full spec implementations, like Pointer Lock.

In no particular order, here are some of the observations I’m seeing again and again in their blogs:

• Writing code to fix a bug is one thing, but getting the tests written, and passing on all platforms, is often much, much harder
• You can’t measure a fix in lines of code (loc).  Often a tiny fix can take dozens of hours to do, since you first have to diagnose the problem, figure out where things are going wrong, and plan how to solve it.
• It’s important to learn how and when to ask for help.  Trying to go it alone will end in tears and wasted time.  A well timed, intelligent question can short circuit your development time significantly
• Similar to the above, it’s easy to not ask for help because you think people will look at you like an idiot for asking such a simple question.  In reality that never happens, and people are very helpful.
• It’s not uncommon for a patch to go through a dozen (or two dozen!) versions on its way to shipping in Firefox: fixing a bug is only part of the process.  Reviews take time, testing takes time, landings (and backouts!) take time.
• Working on large, complicated code like Mozilla helps keep you humble and aware that you don’t know everything
• Keeping a patch up-to-date with trunk, as it goes through reviews, can be frustrating.  Code that used to work, stops working; things you relied on change, or vanish.  You have to build in time for this in your development plan.
• Getting things fixed and landed is really about being patient and not giving in too quickly.
• Fixing bugs in Firefox gives confidence to go work on any other code bases
• Until you’ve done this work, you have no idea how easy it is to say, “Why doesn’t Firefox just fix X?” and how hard it is to actually do in practice.

The other thing I’m reading again and again is that people feel a sense of pride, accomplishment, and increased confidence for having worked on Firefox.  Those are exactly the kind of outcomes I want in this class, and with this experience.  It’s not possible for me to guarantee it, so when it does happen, it’s rewarding to witness.

I’m indebted to many people in the Mozilla community who helped my students find bugs, did reviews and offered feedback on patches, helped late at night on irc, and generally were there to help my students succeed.  There are too many names to list, but I want to centre out Olli Pettay, Chris Pearce, and Jared Wein, who really went above and beyond.

This is my 7th year taking undergraduate students into the Mozilla community and having them work on real bugs.  It continues to inspire and excite me.  I would also say that things have only gotten better within in the community in that time period, in terms of Mozilla’s willingness and preparedness when it comes to welcoming new (student) developers.

I’m looking forward to doing it all over again in September.

April 22, 2012 07:45 PM

You are working for a nanotechnology company that prides itself on manufacturing some of the finest molecules in the world. Your job is to rewrite parts of their ordering system, which keeps track of what molecules they can actually make. Before trying this exercise, please review:

1. Introduction
2. Storage (the short version)
3. Dictionaries
4. Examples
5. Nanotech Example

Submit your work by mailing Greg:

1. your final program,
2. the input file(s) you used to test it, and
3. a shell script that runs all of your tests.

1. Reading

Your company stores information about molecules in files that contain formulas and names, one per line, like this:

# Molecular formulas and names
# $Revision: 4738$

chlorine : Cl*2
silver nitrate: Ag.N.O*3
sodium chloride :Na.Cl

More specifically:

1. Lines may be blank (in which case they are ignored).
2. Lines starting with ‘#’ are comments (which are also ignored).
3. Each line of actual data has a molecule name, a colon, and a molecular formula. There may or may not be spaces around the colon.
4. Each formulas has one or more atom-count values, separated by ‘.’
5. Each atom-count consist of an atomic symbols (which is either a single upper-case letter, or an upper-case letter followed by a lower-case letter) which may be followed by ‘*’ and an integer greater than 1. If there is no count (i.e., if the ‘*’ and integer are missing), the count is 1.

Write a function called read_molecules which takes a handle to an open file as its only argument, reads everything from that file, and returns a dictionary containing all the formulas in that file. (Here, “a handle to an open file” means either sys.stdin, or the result of using open(filename, 'r') or file(filename, 'r') to open a file.) The result dictionary’s keys should be the names of the molecules with leading and trailing whitespace removed. Its values should themselves be dictionaries of atomic symbols and counts. For example, if the data shown above is contained in the file molecules.mol, then this Python:

reader = file('molecules.mol', 'r')
data = read_molecules(reader)
reader.close()
print data

should produce something like:

{
 'chlorine'        : {'Cl' : 2},
 'silver nitrate'  : {'Ag' : 1, 'N' : 1, 'O' : 3},
 'sodium chloride' : {'Na' : 1, 'Cl' : 1}
}

Note: if your tutorial group has already covered regular expressions, use them for this part of the exercise. If you have not yet met regular expressions, use string splitting instead.

2. Merging

Write a function called merge_molecules that takes two dictionaries like the one shown above and produces a third dictionary that contains the contents of both according to the following rules:

1. If a molecule appears in one input dictionary or the other, it also appears in the result.
2. If a molecule appears in both input dictionaries with the same formula, one copy of it appears in the result.
3. If a molecule appears in both input dictionaries with different formulas, it is not copied to the output dictionary at all. (This kind of “silent failure” is actually a really bad practice, but we won’t see what we should do until we discuss exceptions.)

Your function must not modify either of its input arguments: the original dictionaries must be left as they were.

3. What Can We Make?

Write a function called can_produce that takes a dictionary of molecular formulas (like the one shown above) and the atomic symbol of one kind of atom, and returns a set containing the names of all the molecules we might be able to make. For example:

reader = file('molecules.mol', 'r')
data = read_molecules(reader)
reader.close()
print can_produce(data, 'Cl')

should print something like:

set(['chlorine', 'sodium chloride'])

4. Putting the Pieces Together

Write a program called produce.py that uses these three functions to tell us the molecules we could make using a particular kind of atom based on the contents of several molecular formula files. For example:

$ python produce.py Cl < molecules.mol

prints:

chlorine
sodium chloride

while:

$ python produce.py Na salts.mol organics.mol alloys.mol

reads and merges all the formulas in the three files salts.mol, organics.mol, and alloys.mol, and prints a list of all the molecules from those files that contain sodium.

April 20, 2012 06:29 PM

Tools for teaching the web to the world

What’s the best way to teach web building to anyone? Should Mozilla develop a tool to help the world learn HTML5? Join an online interactive “fireside chat” with Audrey Watters and Mozilla to discuss these and other questions.

• Thursday, April 26: 12pm to 1pm ET
• Sign up on Lanyrd here
• Add your questions on etherpad here

Audrey Watters is a prolific education technology writer, researcher and “recovering academic.” She recently undertook a research project for Mozilla, aimed at answering:

What’s the best way to teach web-building to anyone? For example, should Mozilla develop a tool to help the world learn HTML5?

• Read our blog post summarizing key takeaways and questions from the discussion. Including why Hypercard was (or was not) awesome.
• Listen to Audrey’s presentation (MP3)
• Read Audrey’s posts:
• What ed-tech entrepreneurs and engineers should know
• Mozilla-Made “Scratch for HTML5″: Is it the Real thing?
• How to Teach Web-Building to Anyone

 

 

April 20, 2012 03:27 PM

Planet Webmaker: weekly update for April 17, 2012

• Etherpad notes from the April 15 Mozilla Webmaker call
• Audio and video recording
• Join next week’s call
• Past updates like this one
• Dashboard. Posts, press, handy links.

 

 

“Augmenting Amazonia:” sneak peek at Mark Boas’ new interactive video experiment

This sneak peek interactive video demo uses Mozilla Popcorn to pull interactive notes and context into a beautiful upcoming documentary about the Amazon. It allows viewers to interact with the video and go deeper into the content in whole new ways, including automatically tweet out specific points on the time code for specific moments you want to share.

We have an opportunity to create unique mechanisms that allow deeper interaction, while at the same time sharing a similar experience. –Mark Boas, Knight-Mozilla News Fellow

One neat trick: the pop-up boxes and links that appear alongside the video are stored directly in a simple Google doc, which makes writing, editing and updating them dead easy.

The project uses Popcorn.js and the new IE8 shim + jPlayer. It will eventually be embedded in the Al Jazeera English web site, but can also be popped out and added to tablet, mobile device or your TV / home-screen. Mark says this is all a primer for a larger project: a new web app to view Al Jazeera English documentaries.

Get involved:

• Check out the latest work-in-progress demo version of “Amazonia”
• Watch Mark present it in the Mozilla Webmaker call
• Code will be posted to OpenNews Git Hub soon. Libraries used include jQuery, jPlayer, grab.js, Popcorn.js, Tabletop.js and add2home.js.
• In the mean time, get in touch with Mark to get involved.
• Apply to become a 2012-2013 Knight Mozilla News Fellow

What’s the metric that matters most for the Mozilla Webmaker project?

In a nutshell: contribution. How should the Mozilla Webmaker project track and measure success? What are the key metrics? Mark Surman and Ryan Merkley prepared this presentation for Mozilla’s Board of Directors last week. The major message: contribution –  in-depth participation from people helping to build a generation of webmakers alongside us — will be the major metric for success.

• Mozilla Webmakers Metrics: slide presentation (PDF)
• Watch and listen to Ryan’s presentationfrom the last Mozilla Webmaker call (You Tube)

The new Mozilla Webmaker web site: projects, tools and events for webmakers

Projects | Tools | Events. The upcoming Mozilla Webmaker web site will focus on these three core areas: projects, tools and events for webmakers.

What do we mean by “projects?” We mean recipe cards, how to’s and starter projects for making something amazing. From making your own pop-up video in about five minutes, to designing digital learning badges for NASA, to hacking the future of news documentaries with ninjas like Mark Boas, to tweaking your Tumblr template — while learning a bit of HTML and CSS in the process.

Bite-sized starter projects vs. programs. Individual Mozilla Webmaker programs and standalone web sites will continue to be accessible through a single click from a front-page carousel. But the emphasis of the new projects section will be pulling bite-sized opportunities to make, build or contribute something from across these various silos. Like “MakeProjects.com” for webmakers.

We’d been struggling around what to call the “projects” section. Recipes? Activities? Missions? Learning challenges? Tutorials? How Tos? But when you look at what other sites call this stuff — whether Popular Mechanics or Make Magazine or Little Bits — they all use the same simple telegraphic word: “projects.”

Get involved

• Check out the presentation slides (PDF)
• Listen to audio of Matt’s presentation (You Tube audio only)
• Designer Chris Appleton’s design assets

Knight-Mozilla OpenNews Hackathon in Buenos Aires

Hackers in Buenos Aires from the OpenNews Hackathon. Mozilla partnered with Mozilla Hispano, the Buenos Aires Hacks/Hackers group and Blue Via for a day-long event on Friday, April 20, at the NH City & Tower Hotel in the heart of the city. The event featured short talks about HTML5 and friends, Javascript APIs, the Add-ons SDK, developer tools, and our newest offering: Apps and Persona.

Hacking on Mozilla Collusion at the Wall Street Journal Transparency Weekend

Is your smart phone leaking? That’s the question this new “MobileScope” mobile app helps you answer, which won WSJ’s Transparency Weekend “Ready for Primetime” award. There was also lots of exciting new developments on the Mozilla Collusion front — we’ll get a more detailed report back from Gunner in Tuesday’s call.

• Coders Gather for the Wall Street Journal Data Transparency Weekend
• Wall Street Journal Data Transparency Weekend: Day 2
• Wall Street Journal Data Transparency Weekend: Day 3

Next week: make and build with us

• Join the Mozilla Web Maker Community Call. Open to all. Make, learn, share.
  
• Tuesdays 8am PST / 11am EST / 4pm GMT
• Call-in details and agenda: https://wiki.mozilla.org/Webmakers/Community_Calls

April 20, 2012 02:41 PM

The ignite talks from this year’s DML Conference are posted. I wasn’t able to get to the Ignite talks at the conference due to the inevitable impromptu side meetings that always pop-up (which is kind of the beauty of conferences like these). 

But in perusing them this morning, one that caught my eye was Rafi Santo from Indiana University talking about Hacker Literacies. There is a lot here that aligns with our thinking and goals around webmaking and web literacy, so I wanted to dig in a little further.

Highlights (transcribed from the video so with some paraphrasing): 

We are not talking about hacking like “breaking into banks and stealing credit card numbers”, but “what I am talking about is a certain kind of technological industriousness - a maker disposition that’s tied to innovation and creativity.

Again, this is very much aligned with our concept of webmakers and web literacy. These skills are more about building a webpage or knowing how to code but about an approach to learning and to exploring the world. Rafi called this “technological industriousness”. John Seely Brown coined the phrase “entrepreneurial learner” - its all about a sense of ownership, control and empowerment…over technology and the Web, over learning and the pathways we take (and choose!), and over our lives in general. I know, its mind blowing stuff. 

All technology is political. All technology is made by people and people are political and those politics get baked right into the technologies when they design it whether they like it or not….What a hacker understands is that technology is malleable and if it doesn’t line up with our values, we can change them.

Again, it comes back to this idea that we are talking about something bigger here. The individual skills add up to way more than just the sum, but an approach to everything in life. It’s about moving people from consumption to production, not just so that they can make things (although that’s cool too), but so that they don’t take things for granted, or accept things as they are. So that they don’t just remain oppressed, but understand that they have a voice, they have a channel for that voice and they can change things. 

The Internet [read: Web] was not an accident. All the things that we like about it - the openness, transparency, participatory culture - these things were by design. 

YES. The Web is awesome for so many reasons and we should use it - both as a medium for connecting people, empowering people, helping them build things…but also as a model for what we are trying to do here. Open up education/learning, allow for the emergence of many pathways and connections, make learning and assessment a transparent experience and exploration and connect learners together at web scale.

Digital literacy is about empowerment through technology. Hacker literacy is about empowerment in relation to technology. 

This is pretty deep. I had to stop and think about this for awhile. But it’s really powerful. I think it’s both a leveling up thing, and a literacy thing. Leveling up: I think we probably need to start with some of the technology as the medium, but we shouldn’t just stop there, at the what-I-can-do-with-them-stage, but use that as lessons about a broader sense of what’s possible across technology and in our lives in general. Literacy: he talks about these as hacker literacies, we talk about web literacies - the word literacy is in there intentionally. Again, its not about just a few hard skills, but a broader set of competencies that stitch together for possibility and opportunity. And many argue that these literacies should first order literacies like reading and writing…I definitely think we are moving in that direction. 

Finally, Rafi’s marching orders are below, with my commentary:

1. position kids as designers and makers of technology (= webmaking. check.)
2. talk with kids about relationship between tech and values (help them understand intentions, biases, etc. - this comes back to the idea of moving us out of ‘elegant consumption and acceptance, and approaching the world with a sense of “I can change this if I want/need to” which is part of this newer literacy)
3. integrate hacker literacies into digital literacies (see above)
4. embrace hacking everywhere - everything should be hackable (yes! hack the planet!)

-E

April 20, 2012 01:55 PM

It’s not putting it too strongly to say that Software Carpentry changed my life.

Some background: I’m now a postdoc, but back when I took Software Carpentry, I was a third-year PhD student in psychology. Psychology is an area that has recently become much more computational and quantitatively oriented than it used to be. This is especially true in my own area, cognitive neuroscience, which uses brain imaging to study the biological basis of human thought and experience. The problem with this change is that the training available to psychology students hasn’t caught up with the methods. Most psychologists—myself included—don’t have a background in computing or quantitative methods. There were no courses available in my department, either during my undergrad or my PhD. So when I came up against the limits of what I could do with canned software, there was nowhere to go. The only advice anyone could offer was to “ask so-and-so; they know how to program.” So-and-so often did, but usually lacked either the time, the motivation, or the skill to teach an absolute beginner like me. Undergrad courses weren’t what I needed, and teaching myself was a non-starter. I had no idea what topics I needed to learn, or what language to start with, or where to find resources aimed at my level.

That’s where Software Carpentry came in. I had just about given up on learning to program, resigning myself to a lifetime of GUI-clicking and begging for help whenever more was needed. Then I got an email from a friend, forwarding some information about the course. Hallelujah! Finally, a course for beginners like me, which didn’t assume any prior knowledge but also didn’t talk down. The things I learned have opened countless doors for me. I can write my own code and understand code written by others, and I’m not afraid to learn new programming languages as needed. I even took a postdoc in a highly computational lab, which I would never have had the nerve to do if it weren’t for Software Carpentry. Given my background and interests, I’ll probably never be one of the really expert programmers in my field, but I don’t need to be. I know more than enough to function independently, and more importantly, I know how to ask the experts for help, and I can understand their answers.

Acquaintances will tell you that I’ve become a bit messianic about promoting training in computer programming to psychologists. I think too many people in my field have given up on the idea of learning, like I did. To them I say, if I can do it, so can you! So thank you to all the talented people who have put their energy into the course. The program has a made a huge difference to my career, and I would recommend it in a heartbeat to anyone who needs this kind of training.

April 19, 2012 01:13 PM

This weekend we’re getting intellectually proper with a whole slew of amazing people in the info activism community. This year has sold out, which is both great news for some and unfortunate for others. However, there’s still time to ask reddit Co-Founder Alexis Ohanian some questions.

 

April 18, 2012 11:39 PM

Do you know someone who’d be helped by a Software Carpentry boot camp?  Or can you introduce us to someone who’d help us organize one in a new venue?  If so, please introduce us: we’d like to start planning for the fall, and we’re always keen to make new friends.

April 18, 2012 05:55 PM

A lot goes on behind the scenes here at software-carpentry.org:

1. The site itself is WordPress with a partly-customized theme. We use the blog for topics like this and pages (over a hundred of them) for lecture topics. We used to use Trac to manage work items, but nobody kept it up-to-date; these days, we use a WordPress to-do list plugin for the same purpose, and with as little result.
2. Our videos are hosted on YouTube—we used to store them locally, but performance improved a lot when we offloaded.
3. We manage our mailing lists and version control repositories through the Dreamhost control panel, which actually delegates mailing list management to Mailman.
4. The calendar and map are hosted by Google.
5. We do event registration through EventBrite.
6. We currently use BlueJeans and Skype for web conferencing, but it’s been plagued with both technical and social difficulties: people need to have the right Skype client for their OS, and there are the usual problems with unmuted microphones, unintelligible audio, feedback loops, and so on. Forget flying cars: I’ll believe the future has arrived when we can make this work…

For those who weren’t counting at home, this means that project admins need six accounts to make things work, while active users may have up to four (the site, our mailing lists, the Subversion repo, and EventBrite). What really hurts is the way information is scattered across multiple locations: keeping the mailing lists that Dreamhost manages in sync with repository access is a tedious necessity, and making sure that everyone is in the right mailing lists cries out to be done with a table (people vs. list, checkboxes, etc.), but must presently be done the old-fashioned way. Mozilla Persona (formerly known as BrowserID) could help with all those logins (if everyone adopted it), but by itself, won’t help with the data synchronization (i.e., “Everyone on this list should have access to this repository and vice versa”). Tools like Trac can do that, but only if they’re managing everything: there’s still no simple, widely-supported way to federate authorization and access control.

This analysis leaves me feeling a bit conflicted. When I think about what we should teach researchers about the web, I have three requirements:

1. They should be able to build solutions to problems they actually have.
2. They shouldn’t create egregious security holes.
3. They should be able to debug things on their own when they go wrong.

Since people can only debug things they understand [1], #3 depends on them understanding how the web works. One test of that is whether they recognize that they shouldn’t have to log in and out of different sites in order to move information around manually. But if we don’t have a solution to that problem (yet), are we really doing them a favor by pointing out that it actually doesn’t have to hurt this much?

[1] Tweaking code more or less randomly until it appears to work doesn’t count as “debugging” in my book.

April 18, 2012 02:39 PM

Last week I shared some sneak peeks into the "Missions" project. Over the course of the week I have worked with my team and gained some clarity around the scope of the project- and surprise surprise have a ton more questions. In an effort to gain this clarity I worked closely with Michelle Levesque and sketched out some wireframes and mockups. I am going to try to walk through them here.

However, before I can do that, I would like to start this post with a fail. I made this mockup here trying to combine the "WebpageMaker" tool with the "Missions" concept and mocked that up using the openbadges.org template and came up with this:


This wireframe shows two separate pages: a tool page and a projects page. Let's start by going down the "Tool" page trajectory. You start off by landing on the Webpage Maker tool page. It looks like this:

April 17, 2012 08:52 PM

photo by Aspiration Tech

There’s no better example of the global scale of the Knight-Mozilla OpenNews project than the dualing hack days we sponsored this weekend, in New York City and Buenos Aires.

In New York, we gave money for travel scholarships to bring top-notch developers to town to take part in the Wall Street Journal’s Data Transparency Weekend, which brought over 100 developers and privacy experts to town to create tools to “help people see and control their personal data online.” The hackathon grew out of the Wall Street Journal’s excellent ongoing series that looks at how your online footprint is being used by corporations.

The three-day event (documented extensively here, here, and here) resulted in code for almost 30 different projects with winners in “Scanning,” “Education,” and “Control” tracks.

photo from Hacks/Hackers Buenos Aires

Five-thousand miles to the south, we sponsored the Hacks/Hackers Buenos Aires ShowTimeLine Hackathon, which brought 45 developers together to work on making new time-line based visualization tools. The OpenNews sponsorship went to hosting the hack day, as well as a small amount of seed money to keep projects going afterwards.

The team of developers and journalists in Buenos Aires took a series of different approaches to displaying data over time, from automatic data-and-date extraction from documents to translating preexisting timeline libraries into Spanish, and more.

These are exactly the kind of topic-driven code-based events that we’re looking to help sponsor at OpenNews. If you’ve got an idea brewing for a journalism hack day, we’d love to hear about it. Let’s work together to make this year the year of journalism code.

April 17, 2012 08:02 PM

In my experience, most teachers don’t develop courses from scratch. Instead, they take whatever material is at hand, modify it to meet their needs, and then—well, that’s usually where they stop. Unlike open source software developers, they usually don’t give it back to the community in any explicit way. Instead, the next person who needs a starting point has to stumble over it in a Google search, and the original creator may never know that someone improved upon what they did.

Back in December (of 2011), I wondered whether the fork, merge, and share model that underpins so much of modern open source software development could be applied to education. It turns out that lots of other people have been thinking along these lines (and that some of them have actually done something about it):

• Joseph Reagle: fork-merge-share (describing, among other things, a geek-oriented solution to one practical obstacle I mentioned)
• AJ Juliani: Why Every Educator Should Read Hacker News
• Aaron Shaw: A Modest Academic Fantasy
• Ethan Watrall: I want “forking a class” to become part of our vernacular (Twitter)
• Brian Croxall: Forking Your Syllabus (ProfHacker)
• Lincoln Mullen: How to Fork a Syllabus on GitHub (ProfHacker)
• Katherine Harris: Acknowledgments on Syllabi (tracking sources)
• Michael Feldstein: When It Comes to Content, Say “Yes” to Wrappers But “No” to Containers

“GitHub for Education” is a handy shorthand for this idea, but “the idea” isn’t necessarily, “Let’s put educational materials in GitHub”, but rather, “Let’s facilitate a culture of spontaneous-but-structured collaboration and improvement.” (You can see why we say “GitHub for education” instead.) I’d like to start experimenting with this, so my question is, if the source materials for Software Carpentry were on GitHub instead of in our own Subversion repository, would you actually start contributing patches?

April 17, 2012 06:01 PM

We’re half-way through our current round of work, so it’s time to start thinking about what we’ve accomplished, what we’ve learned, and what we’d like to do next. Here’s what I think we now know:

1. Our training makes scientists more productive.
2. We can prove it.
3. Our methods scale.
4. We can become self-sustaining in 2-3 years.

In more detail:

1. Our training makes scientists more productive.

Feedback from learners has been overwhelmingly positive: they believe that what we’re teaching is relevant and useful, and they’re going to incorporate into their work. Where that isn’t the case, it’s usually because of a mis-match between their level and the level of the material we’re teaching. As we scale up, we’ll be able to address this by running separate workshops for people with different backgrounds.

2. We can prove it.

By June, we will be able to show that:

• pre- and post-workshop questionnaires,
• in-depth interviews a few months after the end of training, and
• students recording videos of themselves solving simple tasks

give us both qualitative and quantitative insight into the impact we’re having, which in turn will allow us to back up our claim of improving productivity with more than just anecdotes.

3. Our methods scale.

By “our methods”, I mean:

1. short on-site boot camps…
2. …followed by a few weeks of hour-long online tutorials…
3. …and the assessment methods discussed above.

By “scale”, I mean:

• Katy Huff, Tommy Guy, Matt Davis, Joshua Smith, Jason Pell, Rosangela Canon-Koning, Adina Chuang Howe, and Chris Cannam are all traveling from A to B to teach in this round of workshops;
• Matt Davis and Steve Haddock have already run some of the online tutorials;
• lots of other people (grad students, profs, Mozillians, and assorted volunteers) are co-teaching locally;
• the Chicago, Newcastle, and Paris workshops have run or are going to run without me; and
• the assessments that Jorge Aranda is developing can be conducted by other people.

In short, I am no longer the bottleneck I was two years ago.

The key seems to be “attend one, help someone teach one, lead one yourself”. Moving people around from site to site builds horizontal (peer-to-peer) connections, increases the value of the workshop in the eyes of both learners and hosts (someone from far away must be smarter than someone you know from the neighborhood , and is a much better way to transfer knowledge than any number of “how to” guides.

4. We can become self-sustaining in 2-3 years.

The “attend/assist/lead” model is producing people who can and will organize local support groups similar to the Hacker Within. By 2014-15 we expect to have at least a dozen faculty partners who are able to contribute a few thousand dollars a year to instructors’ travel costs, help update the web site, lobby to get students official recognition for taking part, and so on. Based on past experience with open source projects, that should be enough for Software Carpentry to take on a life of its own.

April 17, 2012 05:09 PM

A faculty member whose research involves building some fairly complex scientific software would like to make all his work open source. He is repeatedly having to justify this choice to funding agencies and his dean, whose objections include:

• concern for sensitive information being released (anything involving pollution has the potential to become a political football)
• concern for misuse by naive users undermining the reputation of the tool
• concern for missing value in licensing the IP

I know lots of other people have had to overcome these and other objections; what I’m looking for is a published (and preferably peer-reviewed) refutation of them that he and others can cite, preferably one that is specific to open source in science (rather than in general). Pointers would be very welcome.

April 17, 2012 02:01 PM

We had a lot of fun doing some betatesting for the Mozilla Summer Code Party.

The idea is to gather a few friends around your kitchen table, have some drinks and snacks, and play around on the web together.

It’s through the informal, friendly setting of your kitchen table that we hope people will find inspiration to make things together on the web. The format is simple and also highly customizable, so you can host the event on your own terms.

Mimosas and Making

As part of the organizing team for the Summer Code Party, I felt it was really important to test the kitchen table format myself. (A huge shoutout to the other Mozilla betatesters! I’ll be writing a summary of your input and experiences tomorrow.)

On a Sunday afternoon I called up three friends to come over and play with Hackasaurus. Two of them already knew about the tool but hadn’t played with it too much, while the other was new to it. They all have experience with making things on the web: the group was comprised of a journalist, an illustrator, and a web strategist.

The invitation was very casual, which I think helped set up a relaxed, fun atmosphere. I just asked them to bring their laptop and to swing by my house for an hour.

We poured ourselves some mimosas, and I showed them two tools to get started.

Hacking the News

I first showed them lovebomb.me, which lets you remix cards and send messages to your friends. Their reaction was lukewarm. So I moved right into demoing the Hackasaurus X-Ray Goggles.

After remixing the example on hackasaurus.org, they installed the goggles and surfed the web for other sites to hack. The most obvious thing to remix was images, so they swapped photos on sites they knew.

One friend, interested in politics, hacked Wikipedia by replacing a politician’s profile with a brown envelope, a symbol of corruption:

After a few image hacks, we took to changing text as well. Another friend remixed a headline story so that it raved about his brother’s favorite sports team. He emailed the hack to his brother and immediately followed up with a call to explain how he made it and how funny it was.

There was also a Guardian remix about a politician outing himself as a muppet. “Labour leader calls for equal rights for muppets after he is revealed to be one,” reads the subtitle.

Storything

Since one of my friends is a journalist keen to learn more code, I showed her the Storything prototype. It’s designed to walk journalists and others through basic HTML tags, using a two-pane editor and a little video tutorial to mark up an article they’ve written.

She did the first chapter and said it was helpful and would likely try out the rest of the tutorials.

Doing your own thing

Several other betatesters pointed out, and I agree, that a successful kitchen table event balances curated activities with a hackable agenda that encourages participants to do what they want.

So while two participants were using Hackasaurus, the other was writing in his blog and clicking around on the web. I think that’s great and definitely the way to run these things: create a fun, communicative space where friends can learn and make stuff on the web, either in a guided or free-form way.

That self-direction helps the host get away from a disciplinarian role, and instead allows for everyone to make something that interests them. As a facilitator, I found my role to be more about introducing ideas, keeping a good flow and troubleshooting, rather than being a task manager.

Ways to improve

We ended up hacking for an hour, and I can imagine we’d play for longer if there had been more time. As we wrapped up, I asked my friends what they liked and what could be improved.

In general, they said they really enjoyed it — it was much more fun than they thought it would be.

However, they suggested adding more tutorials within the X-Ray Goggles, since sometimes it was hard to know why their hacks weren’t working. Perhaps in the manner of Storything with a guided tutorial, or just a hover-over “What’s this code?” or simple debugger might be helpful in showing people how the code is made and how they can hack it.

From my end, I also really enjoyed hanging out and showing my friends something interesting. I think we need smoother integration to publish hacks into a shared, global gallery. For this betatest, my friends emailed me their hacks and I took screenshots.

Perhaps we can build in some gallery functions directly into the Publish button in the X-Ray Goggles, since I imagine this will be a popular tool during the summer code party.

As a facilitator, it certainly helped to be familiar with the tools and to have played with them myself already.

I think encouraging future hosts to test a range of tools and have a ready repertoire is a good idea. As I’ve heard from other betatesters, you might need to adjust the agenda on the fly, introducing new tools to fit the interests and skill-levels of your participants.

Lastly, although I wrote up the host guide for the kitchen table event, I ventured far from it. That’s totally the intention, but I found it striking how little I followed my own instructions. I’m not sure I’d re-write the guide to match what I did in practice, but I’ll have to compare notes with the other betatesters to determine what parts of the guide are really valuable and which are just noise.

A huge thanks to my friends for joining me on a Sunday afternoon for some webmaking!

April 16, 2012 01:50 PM

Our boot camp at Utah State University finished earlier today—many thanks once again to Ethan White and his friends for hosting us. Here’s what the students thought:

Good

Bad

keeping history break work into pieces integrating different things good for different levels of knowledge liked the pace good tech support from helpers download data from the web liked the escalation using up-to-date languages emphasis on commonality of patterns liked flexibility talked about formatting/style everything consistent Greg’s stories hearing from multiple people organized around simple, general structural things liked structure around data processing

machine/software setup hard to keep up with Greg’s typing wind tunnel no beer assumed knowledge we didn’t have less lecture, more time on examples/practicals rushed wide range of applicability wanted more complicated examples some things glossed over don’t understand strengths/weaknesses of languages would have liked time to make better examples some places were “show” not “do” didn’t cover testing Greg’s stories couldn’t tell if people were with us or not hard to keep track of what tool we were in coordination across people

Next stop: London!

April 16, 2012 02:30 AM

Indiana U’s Mike Hansen has written a blog post explaining how he used regular expressions to rename and fix some MATLAB files. Even if you don’t use MATLAB, you should find lots of useful stuff in it. Thanks, Mike.

April 15, 2012 11:27 AM

From Wikipedia:

Open science is the umbrella term of the movement to make scientific research, data and dissemination accessible to all levels of an inquiring society, amateur or professional. It encompasses practices such as publishing open research, campaigning for open access, encouraging scientists to practice open notebook science, and generally making it easier to publish and communicate scientific knowledge.

and also:

The term reproducible research…refers to the idea that the ultimate product of research is the paper along with the full computational environment used to produce the results in the paper such as the code, data, etc. necessary for reproduction of the results and building upon the research.

The two ideas aren’t necessarily connected: putting research out in the open doesn’t automatically make it reproducible, and someone can do the work required for 100% computational reproducibility without sharing it with the world. However, advocates of one often advocate the other as well, and they do seem like a natural pair.

Computational competence is like that too. It’s possible to do reproducible research without knowing how to program, what version control is, etc., but those skills make it a lot easier. Similarly, it’s possible to adopt open notebook practices without understanding what’s going on behind the curtain, but only if everything works properly every time: as soon as something doesn’t, you need to understand the HTTP request cycle, what an API is, or how to write simple database queries (or have a labmate who does). Everything Software Carpentry teaches can be used to support opaque science, but I believe that lowering the practical barriers to adopting open, reproducible practices will speed their wider adoption. And in my opinion, that’s a good thing…

Later: in response to an emailed comment, yes, I do see an analogy with the invention of printing (and later, of the web). Gutenberg and others didn’t set out to foment religious and political dissent, but by putting the means of mass communication in the hands of the masses, they made it easier for those with opinions to make those opinions known. Teaching researchers how to build things themselves doesn’t necessarily mean the end of price gouging by big publishers, or more trustworthy computational science, but a world in which 50% of people can do something is going to be very different from one in which only 1% of them can do it.

April 14, 2012 12:23 PM

Mozillians have been beta testing the Kitchen Table format. After reading a lot of good write ups about individual tests (from Joe, Jess, Lainie, Peter and others), I was inspired to start distilling lessons. I’m sure we’ll do more in depth reviews, but for now here are some things to think about if you’re going to run a kitchen table event.

Overall

• Follow the KISS principle – a couple people (including myself) have written that they tried to do too much in the session.

Adult Newbies

• Generally find the Goggles cool, but really need the instructional and explanation layers.
• Need a specific ask
• Need real motivation (“Why should I care about CODE?”)
• Generally more interested in using the web better
• Willing to play, but seem to crave a little more in-depth instruction and understanding (“Why am I doing this?”)

Teen/Young Adult Newbies

• a very loosely structured remix ask seems to work well (even if they spend too much time collecting assets)
• quick on the uptake of how to use the tool
• questionable deeper understanding – having fun playing, but probably need the instructional and explanation layers for retention of tags, attributes, etc. Interest driven learning + some guidance works really well.

Adult/Young Adult/Teen Intermediate

• Quickly bored with the Goggles, quickly bored with the sandbox
• apparent disinterest can be fought with more immersive games
• need activities to inspire further learning, more advanced content for “almost webmakers”

Kids (pre teen, or early teen)

• an “assignment” like Inanimate Alice or a specific remix seems to be the way to go
• younger kids need a theme and specific ask

All that tells me that:

• we should be figuring out a way to build in instructional and explanation layers in the web maker/learning tools
• adult newbies with low or non existing intrinsic motivations will be a hard sell (even if they have extrinsic motivations)
• we’re right on the money with our approaches for teens
• we need to figure out next steps, new projects and resources for intermediate coders (activity/mission scaffolding)

April 13, 2012 09:44 AM

Last weekend I was fortunate to take part in the FRONTLINE / PRX colloquium on interactive storytelling, organized by Andrew Golis, Carla Borras, Jake Shapiro, Andrew Kuklewicz and Sam Bailey. The event brought forth practitioners in documentary, journalism, and interactive to discuss new digital directions for FRONTLINE, and public media generally. The highlight for me—unsurprisingly—was the PRX-led hack day that followed. Though I love a stimulating conversation, I belong to the less yak, more hack guild.

Four projects participated:

+ A Perfect Terrorist, an investigation of “the mysterious circumstances behind David Headley’s rise from heroin dealer and U.S. government informant to plotter of the 2008 attack on Mumbai.”

+ The Wounded Platoon, the story of the “3rd Platoon, Charlie Company, 1st Battalion, 506th Infantry… a group of young men changed by war.”

+ Post Mortem, a look at how death investigations take place in “a dysfunctional system in which there are few standards, little oversight and the mistakes are literally buried.”

+ a group focused on archival applications of Frontline interviews, starting with the recent Economy series.

I was drawn to the “Perfect Terrorist” group, probably because of a fascination with the Mumbai terror attacks. When I passed through Mumbai in late 2009, the Lashkar e Taiba attack made for very interesting conversations with Indian college students.

Our group wanted to visualize the complex web of relationships in which the American terrorist David Headley is centered. Headley is the mastermind of the 2009 Mumbai terror attacks—a man who was, in turns, an informant for the DEA and a member of Lashkar e Taiba. Producer Tom Jennings calls him a “perfect terrorist.” He is a complicated figure.

The FRONTLINE piece is outstanding, and the long-form journalism style has distinct advantages. But we wanted to help Tom tell this story in ways that traditional forms can’t afford. Though a documentary runtime must have a beginning, middle, and end, a web-native documentary can let users follow story threads that lead in many directions.

FRONTLINE has generated a ton of material around this story—not just the film, but a series on in-depth blog posts and features. There’s an opportunity for viewers to more deeply explore themes and events in the story, like Headley’s motivation for planning the attack. Just how does someone grow up to become a “perfect terrorist?” How was the attack orchestrated? How can we understand the terror network of 19 accomplices? Who are the victims? What is the aftermath? What are we to make of allegations that Headley was a double agent, and how do we begin to resolve some of the bigger questions raised by the tragedy?

Ideation

We imagined a ton of UX concepts. Among the ideas discussed: a navigable map of the “Kill Zone”; making use of perspective video from surveillance cams; a navigable 3D scene of the same; an attack timeline; a map of relationships; making a viewer clear the “fog of discovery”; and challenging users to ask questions and contribute to a discussion. But though these ideas appeal to the geek in me, they must be developed in service of story, or they’re not worth doing.

After cycling through story, then UX vision, then tech (in the style on which I insist!) we arrived at a pretty interesting concept. It’s a hybrid concept that gets at many of the ideas above.

We drew inspiration from the force-directed graphs in use by Mozilla Collusion and others. Without creating a “force” graph, per se, we wanted to create a visual representation of the “spider web” of relationships that Headley spun. With Headley at the center, we wanted to show the life events that culminated in a perfect terrorist recruiting and directing the 19 attackers, and how this ultimately affected the 166 victims of the attack and their families.

But we also wanted there to be an element of time control. Users should be able to experience this project passively, just by watching—but also actively, by navigating the timeline of events and seeing how the relationships developed.

To do this, we placed Headley as a central “node ” on a vertical timeline. The timeline corresponds to a condensed narration of the entire Headley story. When the user presses play, the narration begins and Headley’s node travels through time. Users can go back and forth in time by scrubbing Headley along the timeline. Because Headley’s is basically a playhead on an audio track, we’ve casually taken to calling this “Playheadley.”

But Headley is also at the center of a time-controlled visualization. As Headley comes into contact with key players in the story, “nodes” are spawned for each person—along with connecting lines of varying levels of elasticity.

By watching this play out passively, you can see Headley’s placement in both the terrorist and informant networks evolve over time. And you can pause the experience at any time to explore a node more deeply. Click on one of the terrorists and the narration will pause. You’ll have the opportunity to explore B-Roll, blog posts, and other elements of the story in a non-linear (but intuitive) fashion.

We also discussed how this story map could link to other projects in the same form. So you can imagine a tapestry of FRONTLINE stories connected to each other in this way.

This is an interesting way of mixing time and relationships, telling the story in a way that would be impossible in the traditional form. Check out Pietro’s rapid-fire summary deck for more detail: [PDF]

Prototype

A protoype was made in six hours and is up on GitHub. It’s made with some custom d3.js voodoo by Devin Chalmers, a simple jQuery powered HTML audio player, and popcorn.js. Because of the short amount of time available for hacking, the project is pretty incomplete. But the repo has semi-functional code for all the individual pieces and is hours away from assembly.

There’s interest in taking this beyond the protoype, which I find tremendously exciting. I think there’s a lot of overlap with The Tillman Story project, and its objectives: to let users explore a much more expansive “surface area” of the story; to let interest drive the user’s experience; to provide additional context to the story; to connect it to journalistic material and conversations in social media; and to accommodate a large number of story threads while keeping the main thread engaging. Both of these projects are pioneering ways of telling non-fiction stories on the web.

A high-five for HTML5

As an open video booster, one thing about the event struck me as particularly fascinating: no-one blinked an eye that this was essentially an HTML5 media hack day. Until recently, this type of event would have been impossible. But thanks to the maturation of HTML media, to libraries like Popcorn, to human readable and hackable source, and to GitHub, these types of events are way more viable. Actually, rapid protoyping with video apps is way more viable—imagine having to coordinate with team members while compiling a Flash or iOS app and merging in functional and stylistic changes from six people on the fly. Very, very difficult. With HTML, we can make changes immediately and with little friction.

HTML5 media rocks. You can also check out the repo for the Wounded Platoon group, another HTML5-based project from the event.

April 13, 2012 07:41 AM

In preparation for Mozilla’s Summer Code Party campaign, I beta-tested three small events over the past week.  I was visiting with family for Passover and Easter, and I knew between my mom, my older daughter, my sister and my three … Continue reading →

April 12, 2012 08:09 PM

This week’s tutorial problem was to merge the data from a set of input files to show how often different species were observed on different dates. The shell pipeline, Python code, and two sample input files follow the video.

Click here to view the video on YouTube.

shell command

grep -h -v '#' *.txt | sort | uniq -c

merge.py

import sys

# Read and merge data.
results = {}
filenames = sys.argv[1:]
for f in filenames:
    reader = file(f, 'r')
    for line in reader:
        if line.startswith('#'):
            pass
        else:
            date, species = line.split()
            key = (date, species)
            if key not in results:
                results[key] = 1
            else:
                results[key] += 1
    reader.close()

# Format output.
all_combos = results.keys()
all_combos.sort()
for key in all_combos:
    count = results[key]
    print count, key[0], key[1]

cousteau.txt

# Jacques Cousteau
2012-03-27 marlin
2012-03-29 tuna
2012-03-29 tuna
2012-03-29 turtle

haddock.txt

# Steve Haddock
2012-03-28 squid
2012-03-28 marlin
2012-03-28 marlin
2012-03-29 eel
2012-03-29 squid
2012-03-29 turtle
2012-03-29 turtle
2012-03-30 squid
2012-03-31 turtle

April 12, 2012 08:02 PM

Lyre Calliope is a Mozilla community member who’s been closely following our work around building tools and projects for webmakers — and is connecting it to the storytelling and “noise to signal” challenges Phillip Smith has been writing about.

“The problem is not unique to Planet Mozilla — it’s a problem for the web. How do we find meaning in the era of Big Data? Let’s use Planet Mozilla as a chance to tackle this challenge.” –Lyre Calliope

• Listen to Lyre’s presentation
• Read his posts on distributing Mozilla Media Content and streamlining Planet Mozilla’s ‘signal to noise’ ratios
• Have a look at Phillip Smith’s new proposal around “bootstrapping technology news for the people”

“Planet Mozilla should evolve beyond being a glorified rss aggregator to a full blown news brand.” –Philip Smith

Mozilla Open Badges launches Beta

Mozilla’s Open Badges project now includes leading partners like the MacArthur Foundation, impressive collaborators (including NASA, Intel, Disney-Pixar, 4H and dozens of others now building badge programs using Mozilla tools) and — thanks to this week’s new Beta release of Mozilla’s Open Badges Infrastructure — publicly available software for badge issuers and developers to get on board and build with.

• Read about it on the Mozilla blog
• Learn more about Mozilla Open Badges — and earn your first badge
• Learn more about becoming a badge issuer or displayer
• Read more about the Beta release from Mozilla’s Senior Director of Learning, Erin Knight
• Developers: access the source code and technical documentation
• Join Mozilla Open Badges community calls

NOW OPEN: Apply to become a Knight-Mozilla News Fellow

The brand new Knight-Mozilla OpenNews web site is up and running — just in time to open applications for the 2012/13 Knight-Mozilla Fellowships! Apply now.

Fellows will be embedded with leading news organizations around the world, including the New York Times, the BBC, the Guardian, Zeit Online, La Nacion, Spiegel Online, The Boston Globe and Pro Publica.

Get involved:

• Read more about the launch announcement
• Check out the new OpenNews web site
• Apply to become a Knight-Mozilla News Fellow
• Check out this handy explainer video on the program and fellowships.
• Attend an upcoming OpenNews hack day

Mozilla Popcorn Maker ships version 0.3: aka “Breakfast Club”

Why is it called “Breakfast Club?” Because it’s all about the painful and poignant process of growing up. This release  aims at improving the user experience for Mozilla Popcorn Maker. New features: save and publish projects. New templates. Log in with BrowserID. Share you work. It’s for all the brains, athletes, basket cases, princesses, criminals and neo maxi zoom dweebies out there.

Get involved:

• Try out the new version of Popcorn Maker
• Watch Bobby Richter’s demo of new features
• Check out the release notes
• Learn more about how to get involved in Mozilla Popcorn (Ben Moskowitz breaks it down)
• Attend a brown bag on contributing to Popcorn: Tuesday, April 24th at 10am PT / 1pm ET
• Join the beta test group: email popcorn@mozilla.com
• File a bug

Build 1Gbps apps from the future: Mozilla Ignite wants your feedback

Mozilla Ignite is a new upcoming project and partnership between Mozilla and the National Science Foundation. The goal: invite developers to design and build apps for the smarter, faster networks of the future — in areas that matter like healthcare, education and energy.

The project will launch in early May. But in the mean time, we’re seeking feedback from developers. Does this pre-release staging site provide the information you’d need to get involved?

• Take a sneak peek at the upcoming Mozilla Ignite challenge site
• Send feedback to @mozillaignite
• Listen to Katrin’s presentation on what they’re looking for

Mozilla Summer 2012 Campaign: Teaching the world to code

As you know, we’re gearing up for a major summer campaign. We’ve been working hard on getting the message right — especially on the front page and partner page.

• Does this new front page tell the story?
• Does this revamped Partner Page spell out the “what,” “why” and “how” for potential partners?
• Check out these new promotional assets from Chris Appleton: postcards, t-shirt ideas and stickers to spread the word
• Sign up as a
  • Participant
  • Partner
  • Volunteer 

Assessment and the Web

 ”When designing assessment for the web, we should look at many different theories and apply whatever pieces fit the best. Being the visual type I couldn’t help but draw a small illustration. Let me know if you found it helpful!” –Chloe Varelidi

Join the Wall Street Journal’s Data Transparency Weekend

 

 

 

April 13 – 15. Help build free web tools that promote data transparency and control.

• Read more about it
• Listen to details from event co-organizer Allan Gunn (yes, that’s his Wall Street Journal portrait above! epic.)

 

April 12, 2012 05:01 PM

Back in February, we asked people to make short screencasts of themselves solving a simple programming problem. The submissions convinced us that it’s a good idea, but so many people ran into so many problems that we’re taking a step back and trying to write better instructions, select a simpler (more stable, more reliable) set of tools, etc. Some people’s screen recording software stopped recording at 10 minutes without giving any signal; others produced files that play properly on some platforms, but have no audio on others; and screen resolution problems have made text unreadable in several cases.  I didn’t think this would be so hard in the early 21st Century, but then, I say that a lot…We’ll pick this up again as soon as we can; in the meantime, our thanks (again) to everyone who has contributed so far.

April 12, 2012 12:35 PM

What do we think about when we think about “code?” Many of us think something like this:

Alien. Intimidating. Gobbledygook. Maybe even vaguely sinister, like The Matrix. Something that says: this is not for you.

Whereas, for the Mozilla Webmaker project and our Summer Campaign to teach the world to code, we want people to imagine code more like this:

Or this:

Or maybe this:

In other words: code as something all around us. Warm. Human. Poetic. Not some scary bunch of geeky gibberish that only anointed high priests understand.

We want to show code and webmaking as revealing the patterns and hidden dimensions of everyday life. Swirling all around us. Like everyone’s second language.

The web as literacy. Code as everyone’s second language.

Code and webmaking as literacy — rather than just a professional skill. For a general audience of everyday people who have mostly never touched code before (teachers, youth, journalists, filmmakers, your mum), we want to employ a visual language that treats code less as math and mechanics and scary algorithms — and more as magic pixie dust. Or a maker’s language that can turn your big ideas into reality.

Once you see code as something that makes up your everyday world, you can begin to start using it yourself. To make something amazing, or bend the rules of everyday (digital) reality.  Moving from passive consumer of other people’s stuff to active creator of your own.

The hidden patterns and algorithms of everyday life

This opening to “Stranger Than Fiction” isn’t about code per se — but it perfectly captures the spirit we’re after. Revealing the hidden patterns and algorithms of everyday life.

The web as a maker’s world — NOT a series of tubes

Other visual examples of the web often try to depict it as a network or ecosystem. The challenge with this approach is that it emphasizes the pipes and tubes and tech — instead of the human dimension, and the web as a maker’s world.

How do we apply this idea of “everyday code” in our visual language, branding and videos? As we think more about how to visually tell our Mozilla Webmaker story, we want to move away from abstract depictions of “the web” and instead emphasize the human dimension.

We want to tell stories about real people and Mozilla community members making amazing things. Passing and sharing them with others through a combination of maker spirit, open collaboration, and building the future they want together. Using real code to build big ideas.

Seeking your examples: what else is like this?

I’d like to ask your help in collecting more examples like these. Images, web sites, memes, concrete examples — anything. Examples of:

• Code as poetry. Code as a language for saying something more simply or elegantly than could be expressed otherwise.
• Code as meme. Like “Movies as Code” Or “Programmer Ryan Gosling.”
• Code as expression of the everyday world. In places we don’t ordinarily think of it: nature. An alarm clock. Your car.

What other sites or examples should we be looking at? I’m new to this world, and would love to learn from your favorites. Please share links as comments here. We want to collect memes and examples that can help inspire this style guide for our “Meet the Webmakers” video series.

We like the direction — but want to insert more real code into the mix, and slip in references that real developers will appreciate. So what examples would you include for inspiration? I know you’ve got them…

April 11, 2012 07:14 PM

Popcorn Maker is getting tighter and tighter, thanks to Bob Richter, Jon Buckley, the Seneca CDOT crew, our newly hired summer fellow Kate Hudson, and a growing number of contributors. Read on for a quick update on Popcorn Maker and how to get involved.

Popcorn Maker will let you make and share interactive HTML5-based videos while teaching you some web skills. It’s like the best parts of iMovie and Wordpress.org spliced together, and it’s 100% open source.

We want it to have the polish of Apple product, but the soul of a Mozilla product. We’re breaking a lot of ground.

Version 1.0 is coming in November. So if you’re interested in contributing to Mozilla Popcorn, now is a great time to get started!

Breakin’ it down

April 11, 2012 02:51 AM

Cross-posted from the Mozilla Blog.

Adding skills and achievements to your online identity

When Mozilla’s Open Badges project began in late 2010, it was little more than a demo and an audaciously big idea: what if we could use the web to create whole new ways to “show what you know?”

Today, that big idea is becoming reality, with impressive partners and new Mozilla Open Badges Beta software coming together to test how digital badges can supercharge learning and identity.

Collaborators building badges on Mozilla software

Mozilla’s Open Badges project now includes leading partners like the MacArthur Foundation, impressive collaborators (including NASA, Intel, Disney-Pixar, 4H and dozens of others now building badge programs using Mozilla tools) and — thanks to today’s new Beta release of Mozilla’s Open Badges Infrastructure — publicly available software for badge issuers and developers to get on board and build with.

Integration with Mozilla Persona = adding skills and achievements to your online identity

The new Beta release includes integration with Mozilla Persona (formerly BrowserID). This opens the door for users to create a single user-centric identity across the web, with tools like Mozilla Open Badges adding a “reputation layer” that provides a complete story about what they know and have achieved. All through an open, standards-based infrastructure that puts user sovereignty, privacy and security first.

Open Badges Beta: what’s new?

Today’s Beta release includes:

• New tools for badge issuers. A new and improved badge issuer API makes it easier for any organization to award their own digital badges for learning, skills or achievements.
• New ways for users to manage their badges. Improvements to Mozilla’s “Badge Backpack” make it easier for users to store, manage, import and group badges earned from multiple sites through a single location.
• New tools for badge displayers. A new displayer API will make it easier to display digital badges across the web, from personal web sites to social networking platforms.
• New documentation and privacy features. Including an updated privacy policy, terms of use and FAQs for developers.

Learn more and get involved:

• Learn more about Mozilla Open Badges — and earn your first badge
• Learn more about becoming a badge issuer or displayer
• Read more about the Beta release from Mozilla’s Senior Director of Learning, Erin Knight
• Developers: access the source code and technical documentation
• Join Mozilla Open Badges community calls

April 10, 2012 06:51 PM

Last week, I asked what we should teach researchers about the web. I think that I have an answer, and that the easiest way to describe it is by describing what we want learners to be able to build when we’re done. So, imagine you are studying changes in rainfall due to climate change in North America. As part of that work, you’re comparing results from your simulation with historical data from Environment Canada. Since your calculations may be useful to other scientists, you want to share them on the web. You are therefore going to build a command-line tool so that:

rainy path-to-index.html start-date end-date location

adds a new entry to your online results page by:

1. reading data from the Environment Canada database,
2. comparing those historical values to your predictions, and
3. adding an entry to index.html showing the results.

In order to do this, you will need to understand:

• how HTTP GET with query parameters works;
• how to pull things out of XML data (I believe that’s what Environment Canada will give us—no sign of JSON on their site); and
• how to create HTML programmatically.

More fundamentally, they’ll see the fetch-remix-publish cycle that underpins so much of the web. Their tool won’t be interactive—we won’t try to turn it into a CGI script, because doing so would open up too many cans of worms—but I think we can actually do the above in half a day if people are already familiar with something like Python.

Thoughts?

April 10, 2012 04:58 PM

A short vacation concluded, it’s been fun to dive back into the evolving series of blog posts that go all the way from Rethinking Planet Mozilla, to Matt Thompson’s excellent “Planet Mozilla needs humans,” and continue with Lyre Calliope’s posts on “Mozilla as a media organization” (You can catch Lyre talking about the idea on today’s Webmaker community call).

Bootstrapping a technology news site for Mozillians

One of the driving questions we left off with was:

What would be required to bootstrap the best information-delivery system for Mozillians, made by Mozillians, about Mozillians?

And when I say bootstrapping, I mean how do we narrow the idea down to a minimum viable product, i.e., something so simple that it would be possible to get a version of the idea up-and-running in six-to-twelve weeks? What is the very essence of the idea and what are the handful of must-have “features” that would enable the idea to exist in a way that people could interact with it and help to improve it?

In my mind, these are the must-have features of this information-delivery system:

• A narrow and extreme focus on one niche category: innovation within the Mozilla community, specifically the people, the ideas, and the products that are changing the face of the Web.
• A practical demonstration of “Web thinking” and “thinking out loud” applied to the challenge of helping the growing Mozilla community understand the quickly changing world around them.
• A laboratory that experiments with new ideas and open-source tools and libraries to push the envelope of how news, reporting, and information is delivered online.

And here’s a straightforward proposal for how to make it happen:

• A one-year commitment from Mozilla to underwrite the experiment in its start-up phase (and the trust to give the project some editorial independence and a bit of profile).
• One full-time staff writer/blogger with excellent editing skills and a willingness to experiment.
• A small volunteer editorial board who are active writers/editors/bloggers and also keenly plugged into the Mozilla community, e.g., both tech-centric people like Christian Heilmann and Pascal Finette, and also storytellers like Matt Thompson, and Dan Sinker.

In terms of technical practicalities, I would propose the following:

• A blogging platform. Preferably something open source and extensible.
• An inexpensive DSLR that shoots video and a portable audio recorder with a decent microphone, as well as a tripod, smart phone and a laptop.
• Use of a desk at each of the Mozilla Spaces, as required.

Yep. That’s it. Just a blog, some multimedia equipment, and a place for this storyteller to park their arse as they chase the unfolding story of bottom-up innovation in the ever-expanding city that is Mozilla.

(Okay, okay: If the budget allowed, I’d also lobby for a Livestream Livepack, or an open source equivalent, and an annual Livestream Premium subscription, because video is critically important part of news delivery and an important part of the future of the Web too. And, let’s face it, editing video takes time, it’s often better to just “go live” and let the Internet take care of the post-publishing edits.)

This brave and pioneering soul — an expert at uncovering a good story and telling it quickly, concisely, and in the spirit of the Web — would be tasked with producing two “stories”* a day, four days a week, and also editing a handful of other stories submitted by the editorial board and community contributors. They would also manage a news river of their sources, and would communicate regularly and openly with the editorial board and community via micro status updates. Finally, they would collaborate with Mozilla staff and volunteer contributors to iterate forward the technical underpinnings of this initiative. Phew! This is no small endeavor, but I suspect it is one that would appeal greatly to the right person.

* Story defined loosely enough to allow for lots of experimentation with text, multimedia, data, and so on.

Not a new idea, but a proven idea

This project isn’t about breaking new ground. None of this proposal is overly daring or experimental. As Matt pointed out, variations on this idea have been explored by Digg, Tumblr, and even Google.

Beyond these technology-company driven examples, the broader community of online news start-ups illustrate how this enterprise has been undertaken before:

• TechCrunch: Started as a straightforward blog in 2005 by the tech-obsessed lawyer Michael Arrington, it only took a year to confirm that there was an audience for this hyper-specific beat.

• LifeHacker: Run single-handedly by founding editor Gina Trapani until September 2005, Lifehacker provides another example of how a “micro-publication” gets bootstrapped.

• The Tyee: Looking in my own backyard, I’m happy to be able to point to the award-winning Canadian independent online news site TheTyee.ca. Since 2003, this scrappy newsroom has produced high-quality reporting on a tight budget and a tiny staff. Eight years later (and no longer a “start-up,” as founding editor David Beers enjoys pointing out), The Tyee has grown into a prominent and respected Canadian news brand. (Full disclosure, The Tyee is a long-standing client, and I’m big fan of what they’ve accomplished, so I may be gushing a bit here.)

• The list goes on and on … In fact, there are lots of examples of Web-first micro-publications that bootstrapped themselves quickly and (relatively) inexpensively: Paid Content, 43 Folders, Gizmodo, GigaOm, TreeHugger, Grist, and so on.

Mozilla as a news brand

Phillip however seems to lean toward suggesting something more radical: Planet Mozilla should evolve beyond being a glorified RSS aggregator to a full blown news brand.

Yes, it’s true: as I said before, if the idea is successful the conversation about what to do with Planet Mozilla will be irrelevant. Planet Mozilla would become just one of many sources of information — Mozilla events, news feeds, IRC channels, mailing lists, conference calls, wiki changes, and so on — from which would be distilled a constant drumbeat of pure signal — the unfolding story of innovation in a global community of millions; a focus on the “open Web” and how it’s redefining everything from education to journalism; a technology news site “for the people,” one that doesn’t obsess about the latest proprietary software start-up, the next round of funding, or the imminent purchase by Facebook (Goodbye Instagram!).

There you have it: an elevator pitch of sorts. Mozilla Planet: Technology news for the people. Up-and-running in six-to-twelve weeks. Rapidly innovating with the help of the community it serves. One year to become the best information-delivery system for Mozillians.

What’s your minimum viable product?

April 10, 2012 01:20 PM

Obviously I'm joking around on some level- but I do think that this relates to the work that we are doing on integrating badges into projects like the Missions that I wrote about earlier. I think that we need to develop a community of webmakers, and doing this means elevating role models who users can identify with,  establishing a language around the work that we do- Keep calm and code on, and as always, integrate play into our programs and initiatives.

* note: thanks to Charley Miller for wordsmithing the Keep Calm Code On poster

April 09, 2012 07:37 PM

Imagine sitting in the kitchen with your friends, hanging out, chilling and making some cool stuff on the web. That's the idea behind the Kitchen Table event type that Mozilla is in the process of Beta testing for release in conjunction with the Summer Campaign.   This past week, I did my dogfoodin' and  Beta tested the Kitchen Tables event type with my family.

The Beta testing was scheduled for a two week window, that really coincided with Passover, so I decided to take this as a positive thing and do a "Hacking the Holidays" themed kitchen table. I had done that concept as a Hack jam with Mouse, but this was more challenging because it was with- the parentals.


THE INVITE:
I asked my parents if they would be up for spending some time and making some things online with me when I visited. I created a little url based on some discussions I had with other user testers to send out as an invite. I said it would only take 30 minutes and we could have tea while we were doing it. This was a difficult sell. My parents, both retired teachers, and honestly very supportive of the work that I do and are the first people on the soapbox about teaching youth to learn to code, were very resistant. My mother, who is a web and computer enthusiast agreed to do it, and my dad said he would watch and asked if there was anything with paper that he could do. I followed all of the steps in the wiki, but I frankly think that a lot of Mozilla's efforts do not reach this older audience. In fact, I would go so far as to say that Mozilla appeals to 30 somethings - teens but does not really reach out to 40 + users. I think that my sell only worked because I forced my parents to do it.



THE KITCHEN TABLE:
So, as I said, this was pre- Passover. My parents sat with me and Adrian (the boyfriend) and I took them to my kitchen table website and decide to teach them how to hack that. It was a bit crazy because I had to move fast to keep them focused. They really weren't super into it- particularly my dad. I don't think that there was a real value add for him in terms of hanging out and doing this, other than spending some time with me. Perhaps if he had a grandchild to do this with -- ahem, not suggesting ANYTHING! -- he would be more willing because it would be an activity that they could do together. We slowly lost him and just ended up with my mom.

• I would have a better ask
• I would pitch the activity more casually while I was already spending time with them
• I would bring another laptop- I forgot that my parents only had one
• I would find webpages/ things that they are already interested in and hook them there
• I would give my dad something with paper to do- already in the works for the Missions project
• I am going to send out my Mom's website to her temple community and suggest that we do a bigger meet up to teach others how they can make their own webpages

April 09, 2012 03:09 PM

It’s only the start of April, and already it’s been a big year for the Knight-Mozilla Partnership: We’ve placed four fellows at the BBC, the Guardian, Zeit Online, and Al Jazeera (a fifth fellow, at the Boston Globe, will be starting a little later this spring). We’ve renamed and refocused the Partnership under the Knight-Mozilla OpenNews name. We’ve begun sponsoring hack days around the world (in fact, two are coming up this weekend!). And we’ve started having bi-weekly open conference calls with the larger journo-code community (one is happening this Wednesday). And we’re only getting started—there is a ton more to announce, starting today with the Fellowship Application.

Just a few weeks ago, we announced the addition of four new news partners for the 2012/13 Fellowship cycle. With that, we’ve now expanded our partners to eight: The New York Times, the BBC, the Guardian, Zeit Online, Spiegel Online, the Boston Globe, ProPublica, and La Nación.

And today, as the video above explains, we’re announcing the opening of the window to apply to become one of our eight 2012/13 Knight-Mozilla Fellows. Starting today, April 9, and going until August 11, you can fill out the first round application. Borrowing from friends at the Knight News Challenge and Code for America, it’s designed to be quick to fill out, but also give us a broader sense of both your talents and your ideas.

If you’re a developer or technologist interested in helping to change the way people learn about and engage with the world around them, this is an incredible opportunity. There’s a ton more detail in the fellowships section of the entirely revamped OpenNews site, so give a gander over there and then apply today!

April 09, 2012 03:05 PM