A reason to like broken Python

Python developers often want their code to be “Pythonic”, usually meaning that they want what they write to be particularly suited to the idiom of the language. To the beginner, this usually seems like an obviously good idea, but so vague as to be hard to put into practice. To be honest, I often opt for other, more painfully obvious criteria to evaluate my code, like: “Does it run without crashing?” This hasn’t always had the best outcomes for me.

Since these different criteria capture different aspects about what’s good about a piece of Python, it’s worth putting them into a table:

Table comparing Pythonic code with code that runs

As I filled in this table, I realized that I think that Pythonic code that doesn’t run is often better than non-Pythonic code that does. If it seems implausible that broken code could be better, hear me out. Except for the most disposable, throwaway scripts, it’s important to consider how much work it will take to fix or improve a piece code. Understanding Pythonic code will be mostly painless, so you’ll be well on your way to improving it. Understanding non-Pythonic code will be much more difficult, and even if it runs right now, it’s going to break as soon as you start messing with it.

So now I’m really motivated to have a more Pythonic coding practice. FWIW, I found this course by Michael Kennedy to be a helpful step in the right direction.

Posted in language, python | Comments closed

Other ways forward

Learning new technologies is empowering in a very immediate way, but moving the needle with technology over time requires constant learning. However, I’m not a fan of the metaphor of “keeping up”; it makes me a bit uncomfortable. I’m less interested in the growth of technology, and more interested in growing as a learner.

It’s important to me that when my self-teaching hits an uninteresting patch – which it invariably does sometimes – that I have other ways forward. Even switching media makes a big difference. Having other ways to learn is my way of unblocking my progress toward my learning goals. It also helps that it makes learning more enjoyable.

Posted in learning | Comments closed

In praise of tech meetups

I’ve said before that communities of people matter in programming. But of course that’s not the only factor worth considering. Having the place and time to code is essential too. For those of us who aren’t professional developers, those hours are often hard to find in our rather full schedules. That’s one reason why I liked the (now sadly discontinued) Learn Python NYC weekend meetups so much: showing up meant I could focus on code for 3 hours every weekend. This meant that when I arrived back at work on Monday morning, I was significantly further ahead on my projects.

Since these weekend Python meetups ended a few months ago, I’ve tried to push myself to code on my own every weekend. This hasn’t been nearly as effective. Without a group, it’s more difficult for me to create the time and space I need to work on my projects. I’d like to find another programming meetup to keep me on track.

Thankfully, New York City has a vibrant tech meetup culture. These meetups can be great opportunities for us to improve as programmers. Of course, it’s important to find a welcoming, supportive, non-toxic group. Fortunately, there are many choices in NYC. While meetup.com certainly has plenty of options, there are many other ways to find a good group; for example, the Graduate Center’s Python Users’ Group comes to mind. Making time and space for learning will help us all improve as programmers.

Posted in learning, meetup | Comments closed

On indexing

Before working at CUNY, I occasionally made back-of-the-book indexes for books in religious studies, anthropology and gender studies. Indexing is fun, though very time-consuming work. It doesn’t make much money, but it’s gratifying and interesting.

I feel that indexing is a field with a lot of potential. Building conceptual maps of book-length texts is, in my opinion, very useful work. But book indexing is a profession that has its problems. Many of these have to do with technology. Most indexers rely on niche software tools that are easy to use but are often de-skilling. Our dependence on these tools contributes to the perception that indexing is low-value work.

Rather than rely on vendors, indexers could build their own tools to support their indexing. We could write and open source code to move the profession forward. To make this point using a concrete example, I built a sample index visualization tool:

Screen shot of the index visualizer
Click the image to try it out.

The point is not that this tool is particularly sophisticated (it’s not), nor that it’s particularly novel (also not). Instead, its rhetorical agenda is that it is made by a (former) indexer and is open sourced for other indexers. It’s a very modest effort, but my point is to suggest that if indexers prioritized open source work, we’d be much further along in developing our tools and our skill sets.

Posted in indexing, open source | Comments closed

Building usability testing tools

My colleague Carlos and I have been doing some usability testing recently, and have built some of our own tools to make it happen.

We created a testing interface using JavaScript, which has largely been a success. Our interface gives students tasks to complete, and workspaces to complete them. Reassuringly, students participating in our study seem to understand this interface intuitively. They are generally able to work through the tests with very little guidance. Developing this tool has been a positive experience, allowing me to level up my JavaScript skills and teaching me about some of the subtleties of JS.

We also needed to track the data produced by the tests. After a failed attempt to use Hotjar, a subscription-based analytics tool, we decided to do this ourselves too. I made a Flask application that would process and save parameters passed in the url when a user completed a test.

To do this, the Flask application would serve up a “Congratulations, you’ve completed this task” page, and record a bunch of data from the url about how the user got there. Ultimately the data was appended a CSV file and saved. Analyzing this CSV is still going to require a few more steps, but we’ll get there.

My lack of patience with existing tools led me to put far more time into building these solutions than I initially expected. Nonetheless, because we built them ourselves, they met our needs very well. Besides, building them has been a good learning experience.

Posted in javascript, python, usability | Comments closed

Programming language matters

While it is probably true that you can learn to code in any programming language, lately I’ve felt that language choice is nonetheless important. The languages we learn affect the kind of work we end up doing a bit further down the road. I’ve recently begun to notice how leaning to code in Python has subtly shaped the kind of projects I work on. Things could have easily turned out differently.

There are probably a couple of reasons why language choice matters. Here are two from my experience:

  • In my programming journey, I’ve enjoyed the weekend afternoons I’ve spent in the company of the Learn Python NYC meetup group. That IRL community has been formative for me. People really matter.
  • Tools also matter. Python has excellent data science libraries, so I’m not surprised I headed further down the scientific Python rabbit hole. It makes sense to follow the most interesting parts of a language. Those interesting parts both make the language unique and shape our development.

So perhaps language choice sorts us in some way. Python has been interesting for me, but I’m also curious about what’s next. Language will influence the journey ahead.

Posted in language, python | Comments closed

Making an annotation tool at CodexHack

I spent last weekend at CODEX Hackathon working on a tool called LitRen. LitRen is meant to make ebooks editable and annotatable. The idea behind this project was that editable ebooks would help people who write fan fiction: fanfic authors could insert their ideas and stories into ebooks, or even modify the existing text as they like. With public domain books, entirely reimagined versions of the story could be created by modifying and expanding on the original text.

Making this annotation tool required some heavy lifting in javascript. There are some existing javascript annotation tools that we adapted to work with ebooks. As much of the javascript was over my head, my small contribution was to watch others code, and to build a responsive landing page with Bootstrap.

By the end of the weekend, the basic annotation/editing tool was working, though a lot of supporting functionality remained unbuilt. That was fine; our goal was to have a proof of concept. Anyhow, it was a fun project and a great weekend!

Posted in ebooks, hackathon | Comments closed

Archiving with TCAT

For quite some time now, our library has been archiving tweets about our college using twarc. This has been fine, so I hadn’t really dug any deeper into the world of archiving bots until earlier this week when my colleague Shawna Brandle approached me about using TCAT, the Twitter Capture and Analysis Toolset.

TCAT has a lot more packaging than twarc: from installation scripts, to a GUI, to extensive reports. Once it’s set up, it is a lot more user friendly than twarc. If you want a web-based twitter archiving tool that doesn’t require any command line knowledge of its users, TCAT is a good choice. The biggest technical hurdle is getting TCAT running on a linux (virtual) server. I set it up on AWS, with help from the good installation documentation.

TCAT offers a great opportunity to give your colleagues a tool to archive tweets. Beyond that, it provides a lot of ways to analyze and export collections of tweets. It’s got a lot more overhead — as well as more user-focused functionality — than twarc.

Posted in archives, tcat, twarc, twitter | Comments closed

Integrating open source projects in our library

Recently, our library was considering adopting Augur, a CUNY-made open source reference desk transaction tracking program. It’s a nice program that fills a very specific niche function. We tested Augur at our library for a couple of weeks. Yet despite its niftyness, we didn’t implement it at Kingsborough. This was mainly because it added an unnecessary layer of complication to what is currently a very simple, manual process for keeping reference desk statistics.

I wasn’t too disappointed that the project didn’t go ahead. Manual reference desk tracking has been working fine at Kingsborough, and in some regards there is no reason to interfere with that workflow.

Yet evaluating Augur got me thinking about the value of open source projects for libraries. I found myself revisiting some of the old tropes of open source advocacy: projects like Augur can provide opportunities for us to expand our technical skill sets. They allow us to build collaboratively and to contribute actively to open projects. And so on.

Even though these issues are not new, they are still important in our libraries. Building our librarians’ skills is an important long term goal, as is creating software that benefits libraries. So I hope that we can find opportunities to integrate open source tools that meet the needs of our librarians and our communities.

Posted in open source | Comments closed

I made my own altmetric

I’m waiting for one of my colleagues to lend me some books on bibliometrics. However, in the meantime, in my naïveté, I have created a metric[1].

My metric is not a terribly good one, though perhaps it is no worse than some other well-established ones. While it somewhat defensibly measures reach and productivity, my metric also fails on other fronts.

I’ve called my metric gh-index. It works on the same math as h-index, which is fairly widely known. I’ve translated the logic of h-index to evaluate GitHub stars. The (questionable) assumption is that GitHub stars are the open source software equivalent to academic citations.

It’s a comparison that is kind of interesting. To be clear, I’m not trying to make OSS contributions equivalent to academic citations.  But my rhetorical point is that is that GitHub stars and scholarly citations are both hard-earned recognition, even though they represent very different types of labor.

So, you can calculate the gh-index of any GitHub user here.  This web tool queries the GitHub API, and parses the resulting data to make gh-index calculations. Also, if you’re interested, you can see the code here.

[1] Here is an example of a much more well thought out analysis.

Posted in git, metrics | Comments closed
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar