Today I’m flying out to Santa Clara for PyCon! This will be my first one and I’m really excited!
On Wednesday I’m taking a couple of data oriented tutorials: Introduction to Pydata and Bayesian statistics made simple. I already know quite a bit on those topics but I’m looking forward to learning more about pandas and PyTables, and it can’t hurt to brush up on my statistics.
On Thursday I’m taking part in the first ever Python Education Summit. There should be a lot to learn about teaching with Python and I’m curious to see what is done in venues other than Software Carpentry.
I haven’t yet decided on all of the talks I want to see but Daniel Greenfield’s PyCon guide has given me some good ideas. My own talk on Teaching with the IPython Notebook is on Saturday at 1:55 PM. The talks immediately after mine look interesting; the first is on building scientific applications with Python and the second is about Numba, a tool for speeding up numeric calculations.
There are a ton of companies signed up for the PyCon Job Fair, I’ll definitely be there with my resume!
I’m looking forward to meeting a lot of people at PyCon! If you would like to meet up at the conference drop me a line on App.net, twitter, Google+, or by email. See you there!
These are a few
git aliases I’ve made recently to make my life a little easier. The first two are for displaying the log, and the rest for merging. See the Git wiki for more on how to add aliases.
I pretty much always want the one-line log, so this is the basic version of that:
ls = log --oneline --decorate
--decorate shows any labels on commits, such as branch names. Sometimes I want the above but with the graph view turned on:
lg = log --oneline --decorate --graph
Merges in git fall into two basic categories: fast-forward merges in which the branch label is simply updated to a new commit (but no new commit is made), and all other merges in which a new commit is made with multiple parents.
By default the
merge command will attempt to do a fast-forward merge. If that won’t work it will move to some other “real” merge strategy. I think the difference between fast-forward and the other merges is sufficient that they shouldn’t happen with the same command so I’ve set up aliases to separate them. First the alias for doing a fast-forward. This will fail if a fast-forward is not possible:
ff = merge --ff-only
And then an alias for forcing a non-fast-forward merge even in situations where a fast-forward would be possible:
mrg = merge --no-ff
(This is the sort of merge GitHub does when you merge a pull request.)
pull command is really
merge so it takes most of the same options. When I do a pull I generally only want it to succeed if it’s possible to fast-forward my local branch. If git must do a real merge something is probably wrong, so I have a fast-forward-only
ffpull = pull --ff-only
I’ve got a blog post up over on the Software Carpentry blog about trying out ipythonblocks in the classroom for the first time. Summary: it was a hit! The students really got a lot out of being able to immediately see the result of their code. We also did a lot of “what do you think this will do?”, which I think helped get the students thinking a bit more computationally. Some of the more advanced students even struck off on their own making their own designs instead of just sitting there bored.
I’m really looking forward to using ipythonblocks again at my next boot camps in May, and I hope others get some use out of it in the meantime!