This feed contains pages in the "planet-debian" category.
PyCon 2014 happened. (Sprints are still happening.)
This was my 3rd PyCon, but my first year as a serious contributor to the event, which led to an incredibly different feel. I also came as a person running a company building a complex system in Python, and I loved having the overarching mission of what I'm building driving my approach to what I chose to do. PyCon is one of the few conferences I go to where the feeling of acceptance and at-homeness mitigates the introvert overwhelm at nonstop social interaction. It's truly a special event and community.
Here are some highlights:
- I gave a tutorial about search, which was recorded in its entirety... if you watch this video, I highly recommend skipping the hands-on parts where I'm just walking around helping people out.
- I gave a talk! It's called Subprocess to FFI, and you can find the video here. Through three full iterations of dry runs with feedback, I had a ton of fun preparing this talk. I'd like to give more like it in the future as I continue to level up my speaking skills.
- Allen Downey came to my talk and found me later to say hi. Omg amazing, made my day.
- Aux Vivres and Dieu du Ciel, amazing eats and drink with great new and old friends. Special shout out to old Debian friends Micah Anderson, Matt Zimmerman, and Antoine Beaupré for a good time at Dieu du Ciel.
- The Geek Feminism open space was a great place to chill out and always find other women to hang with, much thanks to Liz Henry for organizing it.
- Talking to the community from the Inbox booth on Startup Row in the Expo hall on Friday. Special thanks for Don Sheu and Yannick Gingras for making this happen, it was awesome!
- The PyLadies lunch. Wow, was that amazing. Not only did I get to meet Julia Evans (who also liked meeting me!), but there was an amazing lineup of amazing women telling everyone about what they're doing. This and Noami Ceder's touching talk about openly transitioning while being a member of the Python community really show how the community walks the walk when it comes to diversity and is always improving.
- Catching up with old friends like Biella Coleman, Selena Deckelmann, Deb Nicholson, Paul Tagliamonte, Jessica McKellar, Adam Fletcher, and even friends from the bay area who I don't see often. It was hard to walk places without getting too distracted running into people I knew, I got really good at waving and continuing on my way.
I didn't get to go to a lot of talks in person this year since my personal schedule was so full, but the PyCon video team is amazing as usual, so I'm looking forward to checking out the archive. It really is a gift to get the videos up while energy from the conference is still so high and people want to check out things they missed and share the talks they loved.
Thanks to everyone, hugs, peace out, et cetera!
Today I gave a tutorial at PyCon 2014 entitled Search 101: An Introduction to Information Retrieval.
It was an experiment of sorts: the first workshop I've run primarily by myself, my first tutorial at PyCon, my first paid teaching gig. It was an opportunity to take some of the lessons I learned from teaching the Boston Python Workshop and apply them to a new situation.
The material itself is a distillation of many hours of frustration with the documentation for various open source search engine libraries, frustration that they didn't tell me where to start or about the big picture, they just jumped straight into the details.
Here's what worked:
- IPython Notebook. Oh em gee. I started writing the class's handout using IPython Notebook because it was a simple way to easily embed syntax-highlighted code into a markdown document that was viewable in a browser. Not only was it a super quick and fun way to write the handout, but many students used the interactive execution features to play around with the example code.
- Not having a paper handout. Saved trees, printing hassle, and no one seemed to mind.
- Putting everything in a git repo... git is sufficiently ubiquitous these days that students didn't really have trouble getting a copy, and appreciated having everything in one place, with simple setup instructions. I brought a clone of the repo on a USB stick as a backup plan.
Here's what caused problems:
- Mostly, the IPython dependency
pyzmq, which requires compilation. I don't know what the current landscape is for Python distribution, but installing these libraries through
pipis still a pain. I've heard rumour that more ubiquitous wheels may solve this in the future.
- Some people aren't used to using
virtualenveverywhere. Even seeing that, I still think it's worth the confusion to put it forth as the recommended setup method.
Intermediate students are a different crowd than beginners. There was less of an air of discovery in the room, though I organized the class around open-ended tasks. Since the material allowed for folks to take it in the direction of their interest, I found it a bit difficult to gauge whether people were following or not. Overall though, everyone was attentive and studious. I had fun.
Ruben and Stuart, the PyCon tutorial organizers, had logistics running super smoothly, AV, lunch, everything. Thanks for that you guys, you rock. And thanks as well to my helpers: Leo, the tutorial host, Eben, my TA, and Roberto, on AV. It's impossible to pay adequate attention to 20+ people as a single person, couldn't have done a decent job without y'all.
Phabricator is pretty easy to install, but it requires running a bunch of
daemons that perform background tasks. It provides a wrapper script called
phd which, when invoked, spins up the default set of daemons and backgrounds
them. Unfortunately, since it backgrounds the processes, it doesn't play well
with the excellent Supervisor, which allows one to
automatically bring the daemons up after a reboot or if they crash, since
supervisor requires managed processes to stay in the
If you try to use the obvious
phd launch under
supervisor... wat wat.
$ supervisorctl status phd FATAL Exited too quickly (process log may have details)
The process error log ends up looking like:
phd start: Unable to start daemons because daemons are already running. You can view running daemons with 'phd status'. You can stop running daemons with 'phd stop'. You can use 'phd restart' to stop all daemons before starting new daemons.
supervisor starts the daemons, but it can't tell that they're running
because they automatically background themselves!
debug mode to
phd, but running in production we don't necessarily
/var/log to fill up with mountains of debug spew.
Instead, stick the following in your
supervisor configuration (on
Debian/Ubuntu, paste into the new file
[program:PhabricatorRepositoryPullLocalDaemon] command=/srv/phabricator/scripts/daemon/phd-daemon PhabricatorRepositoryPullLocalDaemon --phd=/var/tmp/phd/pid autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PhabricatorRepositoryPullLocalDaemon.log stderr_logfile=/var/log/supervisor/PhabricatorRepositoryPullLocalDaemon_err.log [program:PhabricatorGarbageCollectorDaemon] command=/srv/phabricator/scripts/daemon/phd-daemon PhabricatorGarbageCollectorDaemon --phd=/var/tmp/phd/pid autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon.log stderr_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon_err.log [program:PhabricatorTaskmasterDaemon1] command=/srv/phabricator/scripts/daemon/phd-daemon PhabricatorTaskmasterDaemon --phd=/var/tmp/phd/pid autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon1.log stderr_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon1_err.log [program:PhabricatorTaskmasterDaemon2] command=/srv/phabricator/scripts/daemon/phd-daemon PhabricatorTaskmasterDaemon --phd=/var/tmp/phd/pid autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon2.log stderr_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon2_err.log [program:PhabricatorTaskmasterDaemon3] command=/srv/phabricator/scripts/daemon/phd-daemon PhabricatorTaskmasterDaemon --phd=/var/tmp/phd/pid autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon3.log stderr_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon3_err.log [program:PhabricatorTaskmasterDaemon4] command=/srv/phabricator/scripts/daemon/phd-daemon PhabricatorTaskmasterDaemon --phd=/var/tmp/phd/pid autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon4.log stderr_logfile=/var/log/supervisor/PhabricatorGarbageCollectorDaemon4_err.log
Make sure you're not running
phd manually, restart the
sudo service supervisor restart on Debian/Ubuntu) and you should be good to
(Much thanks to Evan Priestley for the quick
support and explanation on
#phabricator.) Note that this solution is
officially not supported and could break.
I just donated $500 to OpenHatch. Here's why you should donate too:
- Diversity in open source matters. We can't keep making the software the world runs on without involving people of all sorts, from all backgrounds.
- OpenHatch is run by community members who I've known for years and trust. They care about data-driven effectiveness and are always getting better at what they do.
- A rising tide floats all boats. More contributors == more awesome.
- If you donate before December 24th, your donation makes twice the difference.
Diversity and education initiatives are the reason I'm a part of the free and open source software community today. (Thanks, Debian Women.)
You don't have to donate $500 to make a difference. $5, $10, $25— from a hundred people—all adds up.
Installing fresh hot Debian 7.0 on a shiny new ThinkPad X1 Carbon laptop turns out to be easy as cake. You just need to make sure to grab the wifi firmware from unstable instead of the all-in-one firmware tarballs, which contain a version that is missing a couple required files.
wget http://cdimage.debian.org/debian-cd/7.0.0/multi-arch/iso-cd/debian-7.0.0-amd64-i386-netinst.iso dd if=debian-7.0.0-amd64-i386-netinst.iso of=/dev/sdb
(Make sure /dev/sdb is really the usb stick you want to overwrite with the installer!)
And put that on a second usb stick for the installer to load the firmware off of.
As far as I can tell, everything works. (Did not mess around with the fingerprint reader, don't care.)
I found the following quote from Stefano's DPL platform interesting:
When faced with the dilemma, I've favored ditching some DPL tasks and communicating or taking notes about the others, instead of the other way around.
It takes someone who really knows Debian to realize that sometimes communicating about what's being done is more important than doing more.
DebConf launched with a bang—the day I arrived by bike I was up until 3am meeting and greeting in the basement lounge of the Carmen Columbia dormitory, where I was staying. No idea how I managed to be so awake for that.
The rest of the week alternated between hacking like crazy on code for my talk and spending a lot of time socializing with Debian folks new and old.
For the day trip to Coney Island, I joined the dkg-led bike expedition which ended up running to nearly 30 miles, which was a bit more than expected. The fact that this was all in actual dense city really drove home the scale difference between Boston and New York (I'd never been to NYC before this). We took several breaks to lounge around and eat and drink, so it took quite a long time even given the distance. I hadn't planned on seeing the baseball game that was a part of the trip, but I ended up going anyway and it turns out that a bunch of geeks at a minor league game is actually quite a lot of fun! I hope someone else will put some pictures from the bike ride and game online soon, since I didn't really take any myself.
This was the first DebConf where I gave a talk, which resulted in me skipping almost all of the other talks, because my talk was on the last day and I reaaally wasn't ready at the start of the conference due to the rest of life being pretty crazy this summer. I missed some things I would have liked to see because of this, but ultimately I think it was worth it. The good news is: it went well! I was nervous until I actually started talking (never given a talk at a conference before), and then it was fine. If you missed it, the talk video is on the web in low and high quality; slides are here.
The audience was great—there were excellent questions and people were excited and interested in the project. I couldn't have asked for a better reception. After the talk finished I spent some time aisle-chatting with some folks, and totally failed to recognize Joey despite having met him before, because he'd shaved off his hair.
DebConf was, like usual, both inspiring and exhausting. I haven't managed to follow up on much that happened during the conference yet. I definitely plan to do so, though, now that real life is calming down again. I'd hate to waste the post-conference buzz about SD. My todo list includes:
- Working more on the SD debbugs bridge to make it more stable.
- I ran into Jesse soon after coming back and now have a better idea of how I'm going to handle a lack of history properly.
- Getting my patch to the Debbugs SOAP interface merged.
- Looking into the read-write SOAP interface work that was done as a Summer of Code project.
- After talking with Jesse I also kind of want to hack up a RESTful interface that could be used alongside the SOAP interface. It seems like doing so will make development of and using the Debbugs web API less painful in the future. This may be a rabbit hole that I don't actually want to jump down, but it's an idea.
- Maybe other help on Debbugs proper!
- Fixing SD bugs and generating more documentation.
- Thinking about and thanking people for talk feedback!
- Playing around with monkeysphere for authentication on my personal machines.
- Watching videos of talks I missed (this includes basically everything that didn't have to do with bugtracking).
We aimed to catch the 10:00 commuter rail train from Boston to Providence, Rhode Island, but we ran late (predictable) and had problems with the bicycle rack for my racing bike, which attaches without frame mounts (also predictable, since Mako and Mika test-rode it earlier in the week), so we didn't make it in to the station until around 10:20. We used the extra time to eat and fix up the bikes, though, so it's not clear how much of a setback that was.
Here are our bikes ready to go at the Providence commuter rail station.
We then had some problems with Molly's brakes, and it took a long time to navigate out of the city, but eventually we found ourself on the "Washington Secondary Trail"—a wonderful bike path along an old rail line. Every couple miles there'd be an old covered rail bridge over the river, and it was a well-paved straight shot for about ten miles, with no cars and no need to navigate.
Just as we were getting into things after the bike trail ended, something completely unexpected happened.
This is Daf's derailleur after it sheared off in the middle as we attempted to start after a red light outside Tractor Supply Co.
Luckily, John and his son Chris lent us a hand and hauled Daf and his bike to the nearest bicycle shop in the back of their pickup truck. They'd just come from there, where John had bought Chris a new helmet.
Due to all these things, we didn't get as far as we'd planned in the first day and ended up camping in Seaport Campground in Mystic, Connecticut, rolling in at around 22:00. We did about 65 miles, including six due to the detour to the cycle shop. Carrying camping gear is heavy! Several delicious peanut butter and jelly bagels and some wheatberry and couscous salad later, we were passed out.
The second day included less bike trouble, but was no less eventful, and we were tired from the previous day's riding. The highlights included taking a tiny sidewalk path that I'm baffled how Google knows about up onto a sidewalk alongside the I-95 bridge across the Thames to New London, Connecticut.
The 13:00 ferry from New London to Orient Point, New York, where we got some remarkably good veggie burgers (whole edamame visible!) for lunch.
And a vineyard on the north fork of Long Island, where we stopped for a quick tasting and ended up picking up a bottle of barrel-fermented chardonnay. The vineyard was small—23 acres, with 11 acres of grapes—and the proprietors were friendly and extremely interested in our trip. They gave us a dollar off on the bottle due to our method of transport.
It turns out there are only two trains a day on the Long Island rail, and we just barely caught the 18:52 return from Riverhead. We had mere seconds in the station and ended up without enough cash to pay for tickets onboard, but the conductor just took what we had and gave us tickets to Penn Station anyway.
Outside Penn, a girl with a mohawk and a messenger bag overheard us talking about biking up Broadway and told us to bike up 8th Avenue instead. "Always bike up 8th and down Broadway because they have bike lanes in those directions." Thus, we didn't die dodging taxis in the dark.
So basically, due to various people being extremely nice to us for no good reason, we made it to Columbia University around 22:30, on the correct day. Warm fuzzies for humanity all around.
From the department of things-that-I-know-are-possible-but-can-never-remember-how-to-do-so-hey-I-read-the-manpage-and-now-I'm-blogging-it, I bring you "downloading a directory of photos from a website":
wget --recursive http://example.com/photos/some-event/ --no-directories --directory-prefix <local-folder-name> --accept JPG,RW2
I always remember
wget --recursive (or
for short), but that produces an annoying tree of directories starting
with the website's domain and working its way up to the directory you
actually want. In the command above,
removes the tree, and
wget to put the downloaded files somewhere that's not the
current working directory. The
--accept option tells
wget to discard files with extensions other than those
mentioned, so your downloaded directory is not cluttered with
webserver-generated files like
index.html if you don't want
it to be.
Here's the short version, since the long version is nice to remember but not so nice to type:
wget -r http://example.com/photos/some-event/ -nd -P <local-folder-name> -A JPG,RW2
I hate keeping track of money. Bank accounts, credit cards, investing—it's such a hassle. Hell, sometimes I even hate the fact that money exists and needs to be dealt with in the first place. But I admit that it's an easier system than bartering for everything.
In college I pretty much ignored most things financial. I rarely had more money than I needed, and put little financial planning into deciding what I could and could not spend money on besides, "I'm going to make X dollars this summer," and, "think twice." But now that I have a steady paycheck, it seems like a good idea to know where all my money goes, so I can make better decisions about how I'm spending (and saving) it.
But I've kept procrastinating starting to do so, because GUI programs like Gnucash and HomeBank seem like such a hassle. Their first screen is dauntingly complex, and if you don't know much about accounting it's scary and difficult to be asked to set up a big set of accounts when first starting to use the program, without having any prior experience with what you personally would find useful to keep track of. Entering data through menus and dialogs is tedious and slow.
hledger (or ledger, which came first) had been appearing on my radar recently, not least because Iron Blogger uses it). hledger changed my opinion of accounting software. In about 15 minutes, using only the sample transactions from the manual, I was able to enter all my assets and liabilities—bank accounts, credit card, student loans, money I've borrowed from people and never paid back though I said I would, etc. And then, I could run 'hledger balance' and it would tell me what sorts of things I had spent money on in the past few days, as far back as I could bother looking up actual transactions for, rather than entering a single transaction with a balance forward. Duuude, awesome!
I'm a geek. I like statistics and data about my life, as long as it's not a huge pain to collect the data in the first place. More data means more on which to base decisions, decisions which will then be freer from the bias of what I find memorable enough to remember having done.
Here's what I like best about ledger:
- Command-line interface for the hacker in me.
- Pre-existing facility with a text editor transfers over to facility of data entry.
- No need to set up accounts separately from transactions. Transactions are the important thing, and accounts just automagically appear when the account name appears in a transaction. Mistakes are trivial to correct in a text editor.
- Easy to start out with "use text editor to add transactions" and "hledger balance" and then branch out to more advanced features as necessary.
- Text file format is well-suited to storing in a version control system.
- It easily replaces two text files that I used to keep: "money owed to others" and "checks written but not yet cashed by the other party."
I don't think I'd be enjoying keeping track of my money nearly so much without a tool like hledger. It gets out of your way to let you focus on the hard things, like choosing categories for the things you spend money on and remembering to record the data in the first place.