Category Archives: code

Kicking off the GSoC 2023 season

by

Yesterday was my favourite of all US holidays, MLK Day. I won’t pretend to have a deep connection to it (I’m not American after all) but it’s a day off exactly when I need some volunteer time every year and that’s a wonderful gift of a day.

I’m once again spearheading the Google Summer of Code effort for the Python Software Foundation. The website is updated as of yesterday so you can read about it there and I’m not gonna write any more blurbs: https://python-gsoc.org/

I took over coordinating Python in 2013 (though I did Mailman and Systers before that) and now that I’ve noticed last year was my 10th year with Python I’m kind of sad I didn’t throw a party for myself. Oh well! But my fellow coordinators got community awards last year so that’s pretty celebratory!

PS – We’re always open to taking on new projects who want to mentor new contributors. If you’re interested, see the link above for details. We’ll be opening signups later in the week after the admin team meets and makes sure the signup system is ready to go.

CVE Binary Tool 0.3.0

by

My work open source project had its second public release! Python folk can get it via pip install cve-bin-tool or by going to https://github.com/intel/cve-bin-tool/releases/tag/0.3.0

I don’t really talk about work much here, but one of the things I’ve been doing is a little helper tool called the CVE Binary Tool. It scans your code for a select number of common open source components and warns you if any of them are out of date and have known security issues (also known as CVEs, which stands for Common Vulnerability and Exposure and is basically a numbering system for publicly known security problems). Probably most people who read my blog don’t need this tool, but if you write software that ships binaries or if you like to hack software binaries, it’s a simple but informative thing to have in your toolbox. There are more comprehensive tools in this space, but they’re usually fairly expensive and fairly slow, so a free and relatively fast one has a nice niche.

The biggest new thing I’m excited about in CVE Binary Tool 0.3.0 is that it now includes Windows support, which was provided by my Google Summer of Code Student Ziao Wang. He’s been working with us for the summer and just wrapped up his time on Monday, so I was really happy we were able to get this release out before he finished his term! He’s also done some parallelization work that should make parts of this release faster, as well as other bugfixes and enhancements.

There’s also some other great stuff in there: new checkers, new usage modes, and a number of bug fixes and improvements.

Amusingly, given that I’ve been fairly involved in the Python community for so long, this was actually the first time I’ve pushed the “go” button on a release to PyPI all by myself. I like to think this is just a sign of my incredibly amazing collaborative skill, but I still had a laugh at myself when I had to read all the docs to make sure I was doing it right!

Things I always forget about setting up git

by

You may have seen xkcd’s comic about git:

Comic about git

I feel this pain. Because of Mailman, I actually learned Bazaar when many people were learning git, and did most of my contributions through launchpad, so I’m a relative newcomer to git and doing contributions on github (Mailman’s on gitlab now, but I do github for work and other reasons). This is constantly embarrassing to me because I’m a pretty seasoned open source contributor and so people always assume that I’ll be good at git. But I’m not. And lots of other people aren’t either! I was amused at how quickly that comic made the rounds with everyone saying things like, “I thought it was just me!”

Of course, my boyfriend not only does git but used to develop gitweb, so he was horrified when I laughed at said comic and thus cemented his role as my personal git tech support forever. I am both relieved and horrified that he has to look this stuff up all the time too.

Anyhow, in the interest of making my own life easier, I’m writing myself a teensy tiny reminder of the parts of git I most often get wrong. (It’s possible that this tutorial is also wrong, but I’m bugging J as I go so I don’t screw it up too badly.) I’m hoping that writing it out will make it easier to remember, but if not, at least I know where to look.

Setting up my repo

  1. Fork
    I do this through the web interface so I have a personal copy to work with and sometimes so I don’t accidentally try to push directly upstream on projects like Mailman where I totally could do that if I wasn’t paying attention.

  2. Clone my fork on my local machine
    This makes a nice local copy I can poke at and grep through and whatever.
    git clone git@gitlab.com:terriko/mailman-website.git

  3. Set up an upstream
    This helps make it easier for me to get changes from the upstream original project and integrate them into my local copy.

    cd mailman-website
    git remote add upstream git@gitlab.com:mailman/mailman-website.git

  4. If I want to get changes from upstream, I then do
    git fetch upstream
    git merge upstream/master

    *** see note below

Note to self: don’t use git pull. I know that git pull basically just fetches and merges, but somehow I always screw something up with it if I have changed any file anywhere. As far as I know, git pull seems to be the equivalent of releasing angry flaming wasps into your repository. You might try to clean it up for a while, but eventually you’re going to decide that dealing with flaming wasps is way more hassle than just making a new repo copy and going there.

I know, the guides always tell you to use git pull. I assume most of the guides on the internet are written by angry flaming wasps who desire new homes in your repo.

*** Edited to add: my friend e suggests that merge here might be another source of fire wasps depending on what you want to do. git rebase may be the better choice.

A wasp saying "git pull" while fire comes out of its butt.

Making a branch

Note to self: always make the branch before making any changes or you’ll find a way to get your tree into some sort of screwed up state and all the git stash and revert attempts in the world won’t push your mess out of the way enough to make git happy. The flaming wasps will win again.

git checkout -b mailman3doc --track
(This will use my upstream settings (set above) and tie this branch to that upstream. With magic.)

Saving my work and pushing it publicly

When I want to check stuff into my branch (aka save what I’m working on) I do

  1. Add the ones I want to save

    git add $files_I_have_changed_and_want_to_save

    If I’m not sure which files I changed, I can check

    git status

    Note to self: I never forget how to add, but I often try to use git diff instead of git status so that’s why this is here.

  2. Check in my files
    git commit -m "Useful commit message goes here"

    I also rarely forgot this one, because it’s basically unchanged from the first version control systems I used. yeay!

  3. The first time I want to push my branch to gitlab or github, I do
    git push -u origin $branchname

    The -u part sets the magic for the branch so that in theory in the future I can just use

    git push

Note to self: The -u stands for “upstream” but after some point, I’m losing track of what is upstream and what is origin and I can never remember what I need here. It’s all magic incantations as far as my memory goes.

A unicorn saying "git remote" "-u" and "--track"

Cleaning up my commit messages before a merge

Often I make a commit, push it upstream, then realize that I have a typo in a comment or something that I want to fix quietly without anyone knowing. Thankfully, git rebase is here for me. If it’s just gone to my personal fork and not to the main repo, I can use it to hide my shame.

git rebase -i HEAD~2

Will “interactively” let me mess with my last two commits. There’s a nice tutorial on how to do this here so I won’t write one out myself.

A series of checkin messages with all but the first one crossed out and a magic git wand leaving sparkles across the screen

That’s the most common ones I can think of off the top of my head!

Winking Microview

by

With my travel and work schedules, I haven’t had time to hack my original MicroView, but the replacement ones arrived while I was out at ABQ Mini Maker Faire! So of course, I had to try *something* now that I can actually flash things to it.

Here’s my current very simple program: a smile with a wink!

microview_wink

Although it’s probably better with video…

And of course, it’s more fun if you can also check out the code so I dumped it into my git repository. Here it is in case you’re not feeling like clicking through:

/* 
 * microview_wink: a simple winking face animation for the MicroView
 * 
 * Created by: Terri Oda 
 * Sept 16, 2014
 */

#include 

void setup() {
  uView.begin();		// start MicroView
  uView.clear(PAGE);		// clear page
  uView.print("Hi Terri!");	// say hi
  uView.display();
  delay(1000);
}

void loop () {
  //drawFace();
  winkFaceAnimation();
}

void drawFace() { 
  uView.clear(PAGE);
  
  drawEyes();
  drawNose();
  drawMouth();    

  uView.display();        // display current page buffer
}

void drawEyes() {
  uView.circle(20, 15, 5);
  uView.circle(45, 15, 5);
}

void drawNose() {
  uView.line(30, 22, 35, 32);
  uView.line(35, 32, 31, 32);
}

void drawMouth() {
  uView.line(20, 40, 25, 45);
  uView.line(25, 45, 40, 45);
  uView.line(40, 45, 45, 40);
}

void winkFaceAnimation() {
  for (int i = 0; i < 7; i++) {
    uView.clear(PAGE);
    
    // animate one eye for the wink
    switch (i) {
      case 0: 
      case 6:
        uView.circle(45, 15, 5);
        break;
      case 1:
      case 5: 
        uView.rect(40, 12, 10, 5);
        break;
      case 2:
      case 4:
        uView.rect(40, 14, 10, 2);
        break;
      case 3: 
        uView.line(40, 15, 50, 15);
        break;
    }

    // draw the static parts of the face
    uView.circle(20, 15, 5);    
    drawNose();
    drawMouth();
    
    // display and wait for the next frame to start
    uView.display();
    delay(500);
  }  
}

The MicroView was pretty easy to get up and running since this machine was already set up for arduino programming, I just had to remember to switch from the Adafruit Flora (what I'd been coding for last) to the Microview ( / the Arduino Uno). I'm pretty pleased with my first run, and even though I am reminded that animation frame drawing is not my favourite activity, I'm happy to have written some code for it, even if it's absurdly simple.

I'm still planning on continuing with the necklace plan for the first of these, so I'm going to work on a few more animations while I decide how I'm going to handle power, shaping, and whether I'm going to want any sensors in the final pendant. My current plan is that I'll create a backpiece that I can embed a battery into (probably 3d printed?), and I think I'd like to stick an accelerometer in there so it can be more interactive. But my plans may change as I fiddle with it!

MicroView: the bad, the good, and the awesome

by

I backed this cute little thing on kickstarter called the Microview, which is basically a teensy arduino with an oled display attached. It was too adorable to pass up: I’ve wanted a little programmable necklace for a while, and this meant that project would be really easy to build.

My MicroView (Adorable Arduino with OLED display)

My MicroView (Adorable Arduino with OLED display)

I’ve been anxiously awaiting the arrival of the MicroView and it finally came today. So I popped open the instructions page and the first thing I see is a big apology. Uh oh…

So I check my email and sure enough, there’s an email about a big problem. Short version: they sent out a whole pile of units without bootloaders, so it runs the demo but won’t run any new code. Both of my MicroViews, it seems, are in the affected batches. More details here:

https://www.sparkfun.com/news/1575
https://www.kickstarter.com/projects/1516846343/microview-chip-sized-arduino-with-built-in-oled-di/posts/959475

So that’s disappointing, but they’re shipping out replacement units, and I suppose I can wait a bit longer to play. It’s not like I don’t have other toys to play with.

But here’s the super awesome news: it’s possible to dissect the unit and fix it!

So… with a bit of hacking, and assuming I don’t break anything, I may have double the number of MicroViews by the time this is done, and I’ll have had an excuse to dissect my new toys.

I’ve never been so pleased about receiving a defective product. :)

In the meantime, I guess I can play the tutorial game:

MicroView running the tutorial "game": Connect a jumper between pins 5 and 8

MicroView running the tutorial “game”: Connect a jumper between pins 5 and 8

Mystery Munch: A Simple Android Game

by

I’ve been brushing up on my android skills for work, since I’ll be helping do security reviews on Android apps. Since I hadn’t written an app in ages, I thought it would be fun to take an Android 101 course on coursera just to force myself to do a couple of assignments and learn some of the things that come from actually writing the code and not just reading about it.

Some of these things-you-only-really-learn-by-doing kind of suck, like where I hit a bug in the hardware acceleration that caused me to lock up my entire computer requiring a hard reboot. Or discovering that making screenshots from the Nexus 7 emulator is apparently a Sisyphean task.

Frustrations about the fiddly bits of development aside, the assignment was ridiculously easy (although given that I used to *teach* a mostly equivalent Java course, that’s not a surprise — I’m really only in this for the deadlines, although the prof’s forays into computer history are pretty fun too.) The first part was an explicitly-defined app that I didn’t find interesting, but the second was “make an app of your choosing!”

So here’s what I chose:

Screenshot for "Mystery Munch" -- my very simple android game

Screenshot for “Mystery Munch” — my very simple android game

Mystery Munch is half a battleship game: you click around to find the “food” hidden in the grid. It has no graphics, but it’s smart enough to make random layouts and notice when you won.

I always liked marking the game assignments best, back when I was a teaching assistant, so I figured I’d make a very simple game to amuse my peer reviewers.

The apk is here, if you actually want to play. I’ll get the source code up later once I figure out how I want to share it. Additions to the game will be welcome if anyone wants to make something from it!

This is the product of a Sunday afternoon of coding (I’ve been doing the course on work time, but I figured to save questions about releasing this code, I’d do it entirely on my own time), so it’s not amazing, but it’s mine and I’m amused by it! I’m thinking I might make some silly little pixel art to make it prettier and do some iterative improvement just because I can, if I don’t get sidetracked by another game I’ve been wanting to make for a while…

Incidentally, in case anyone’s wondering: I totally aced the assignment, and it seems I amused my peer reviewers. Mission accomplished!