“Yield and overcome” – Lao Tsu, Tao Te Ching
Over the past year or so I have on a few occasions taught git to people
accustomed to using Subversion. These are experienced software developers so it
seems like it should be easy, but it is almost always a difficult process
filled with acrimony, resistance, and gasps. (And this from people who seem
to use Emacs, vim, and Linux without complaint.)
And yet when I teach git to people who don’t already have a preferred
version control system it seems to go pretty well. It takes time, and there
may be confusion, but we demo and practice and learn as with any topic.
There is no hate. I think I’m beginning to understand the situation:
- Git and svn are different.
- People do not like their workflow changed.
Git isn’t just a little different, it’s completely different. But, dear
svn users, git is not different because it doesn’t like you. Git is different
because it’s optimized to facilitate the collaboration of a number of
developers working on a rapidly changing code base. Some examples:
- Branching is easy in git so that you can work in peace isolated from
upstream changes until you are ready to send your work back.
- When it’s time to merge back git provides
rebase to facilitate cleanly
integrating upstream changes.
- Git is distributed so that you and everyone else can make all manner of
branches and experiments without dirtying up the master repo.
Git is different from svn, but it does well what it is designed to do.
This brings me back to the Lao Tsu quote from the top and a simple message
to svn users learning git: You will have to drop your svn workflow to make
the most of git, but it’s not because git is bad, it’s just different. Yield,
use git in the way it was meant to be used, and be happy.
Normally when I do a push in git I do something like
git push origin master, which really means push from the local branch named
master to the remote branch named
master. If you want to push to a remote branch with a different name than your local branch, separate the local and remote names with a colon:
git push origin local-name:remote-name
Learning to program and learning the basics of control flow can be tricky business for novices. I wanted to make something that provided immediate, visual feedback to students as they practice things like
for loops and
if statements so they can see precisely what their code is (or isn’t) doing. So I wrote ipythonblocks.
The IPython Notebook makes it possible to display rich representations of Python objects using HTML (among other things). That allowed me to make a Python object whose representation in the Notebook is a colored table. Students can index into the table to change the color properties of individual table cells and then immediately display their changes.
ipythonblocks instructors can give coding problems like ‘turn every block in the third column red’ or ‘turn every blue block green’ and by displaying their blocks students can see right away whether their code is having the desired effect.
Check out the demo notebook to see ipythonblocks in action.
Earlier this year I started using If This Then That (IFTTT), a web service that allows you to set up recipes based on triggers and actions. Triggers include things like date and time, making a new blog post, or sending an email to IFTTT. Actions include things like making a new Evernote note, sending an SMS to yourself, and posting to social networks. You can easily browser the whole list of IFTTT channels. For a nerd like me who likes to automate and archive, IFTTT is a dream come true.
Archiving with IFTTT
I use IFTTT primarily as an archiving tool. I deal with many different services all over the internet and for those services that have IFTTT triggers I’ve set up recipes to help me record things to a common, easily searchable place. For now that place is mostly Evernote, but I also send things to Google Docs. (Evernote because it is easily searchable, Google Docs because it’s easily exportable.) For example, when I post a link on Facebook that link gets saved to Evernote and a Google Docs spreadsheet. When I favorite a post on App.net the contents of that post get archived. When I star items in Google Reader a link to that article gets archived. I can also send an email to IFTTT and have that email saved to Evernote to help me archive random links or thoughts. Continue reading “If This Then That”
As an addendum to my “There’s a Better Way” post I want to point out a paper written by some of the Software Carpentry consortium (including me, though I just contributed a little editing). It’s titled “Best Practices for Scientific Computing” and is currently available on arXiv at http://arxiv.org/abs/1210.0530. Here’s the abstract:
Scientists spend an increasing amount of time building and using software. However, most scientists are never taught how to do this eﬃciently. As a result, many are unaware of tools and practices that would allow them to write more reliable and maintainable code with less eﬀort. We describe a set of best practices for scientiﬁc software development that have solid foundations in research and experience, and that improve scientists’ productivity and the reliability of their software.
An astronomer friend of mine once compared his experience programming to this clip from Fawlty Towers:
Continue reading “There’s a Better Way”
Over the course of eight days in October I taught at three Software Carpentry boot camps in California. It was utterly exhausting and tremendously rewarding and hopefully I’ll do it again sometime. I want to take a moment to post a little feedback from the third boot camp and mention some of the things I learned on the trip.
As a tool when teaching unit testing it would be great to have a way to run nose or pytest in an IPython Notebook. For example, a
%nosetests magic would do test collection in the Notebook namespace and do its usual run and reporting. Of course it’s always possible to write test functions and then just call them, but having a report that compiles everything in one place is nice. Plus it could look just like nosetests called from the command line.
Unfortunately for this idea these testing frameworks have for the most part been engineered for doing their test collection using the file system as the starting point. In a couple hours of fiddling I couldn’t figure out how to use either nose or pytest to do test collection in a notebook. I’m sure it could be done with enough hacking.
Just for kicks, though, I threw together a little IPython line magic that does its own limited test collection, running, and reporting. You can see it via nbviewer and grab it on GitHub. This magic only grabs functions that begin with “test” and the reporting doesn’t include tracebacks when there are failures or errors. But you do get the exceptions themselves.
(This whole experiment was inspired by a conversation on Twitter.)
Update: On the advice of @stefanvdwalt I put the
%runtests magic into a .py file so it can be installed via
Once that’s done you can run
to have it do its limited collection, running, and reporting as in this demo notebook.
Update 2: Someone has made this work with nose: https://github.com/taavi/ipython_nose!
I’m happy to announce that there is now a Firefox add-on with the same functionality as the Open in nbviewer Chrome extension and bookmarklet. It can be installed via the Mozilla Add-ons directory. It will add an nbviewer icon to Firefox’s toolbar that, when clicked, will attempt to open your current page in nbviewer.
The code is available on GitHub.