While migrating data for ipythonblocks.org I ran into an issue that stumped me for about a day: I could read data from my database after the migration, but not insert anything. When I tried, Postgres complained that there I was trying to insert a duplicate primary key. The twist, though, was that I wasn’t specifying a primary key, I expected Postgres to automatically generate and insert a new, valid key. What I ultimately discovered was that because the data I had migrated already contained primary key values, the Postgres sequence created for the table primary key column had not been advanced to the point where it would generate new key values that weren’t already in the table. (A sequence is a stateful number generator kind of like Python’s range.) I had to manually set the sequence state using Postgres’ sequence manipulation functions. This post contains a demonstration of this problem and the solution. SQL was run against Postgres 9.6.3 using pgcli. Continue reading “Setting the State of a Postgres Sequence”→
This is Part 4 in a series of blog posts describing my move of ipythonblogs.org from Rackspace to Heroku. In this post I’ll describe the updates I’ve made to the application layer of ipythonblocks.org. Other posts are:
The application logic is not really changed in this update, the bulk of changes are to support providing SQLAlchemy sessions to allow database access during requests. (See Part 3 for discussion of the database interface layer of ipythonblocks.org.)
ipythonblocks.org is powered by Tornado, which combines an application framework, web server, and asynchronous features. On Heroku the application is started with the command
This is Part 3 in a series of blog posts describing my move of ipythonblogs.org from Rackspace to Heroku. In this post I’ll describe the updates I’ve made to the database interface module of ipythonblocks.org. Other posts are:
This is Part 2 in a series of blog posts describing my move of ipythonblogs.org from Rackspace to Heroku. In Part 1 of this series I described my motivation for the move and the broad changes I expect to make as part of the migration. In this post I’ll describe the grid data model and how I migrated the existing grid data from SQLite to Postgres. Other posts are:
This is Part 1 in a series of blog posts describing my move of ipythonblogs.org from Rackspace to Heroku. In this first post I’ll describe the existing deployment and what I intend to change during the migration. Other posts are:
I’m happy to announce the release of Palettable version 3.0. Palettable is a Python library that packages a variety of color palettes for use with matplotlib or really anywhere. Here’s the full diff since the last release.
The new cmocean, matplotlib, and MyCarta palettes are created from data that contains 256 color points per palette. By default palettes are created with lengths 3-20 colors, but you can request longer ones via the get_map function. For example, to get the matplotlib Viridis palette with 200 color points:
In : palettable.matplotlib.get_map('Viridis_200')
As folks become more aware of the social justice challenges we face as a country and in our communities they often wonder how they can help. There’s not one really great answer because we all have different experience levels, means, axes of privilege, and available free time, but there are some common-sense “getting started” points. People with privilege who help social just causes are often called allies (but more on this word below), and this post is about how allies can learn how to help. A very short and incomplete TL;DR:
don’t center your own ego and feelings at the expense of others’
examine and change your own behavior so you don’t perpetuate bad habits
whole-heartedly listen to people with less privilege than you
educate yourself on the history and literature of the movements you are interested in
step up when you can
The following are several resources for people looking for specific things to think about and act on. This list is focused on diversity-in-tech, and especially gender diversity, so pointers to other resources would be great.
(A note about the word “ally”: there’s a real failing of language here because we use this noun to refer to privileged supporters of social justice causes, but the causes don’t need nouns, they need actions. You can’t do 10 supportive things and then have the label “ally” for life. It’s a process of doing what you can, when you can. This essay gives a great breakdown of the distinction: http://www.shakesville.com/2013/04/on-fixed-state-ally-model-vs-process.html.)
Note: This is based on a series of posts I’ve been putting together at work to educate coworkers on diversity and inclusion topics.
Dismissive language harks back to my post about microaggressions. It’s very easy to accidentally say something dismissive without realizing it. The most common examples of dismissive language I encounter are in descriptions of complex topics, often with the words “just” and “should”. For example, “All you need to do is just git rebase and everything should be fine” or “Just change this setting in your config and it should just work”. These constructions trivialize the listener’s problem and imply that they are stupid for not being able to figure it out on their own. (I’ve given technical examples here, but I imagine that this can happen in any context with complexity, like knitting or wet labs.)
I think it’s a good practice to try to completely remove the word “just” from your vocabulary, and watch your usage of the word “should” as well. At a fundamental level this is about putting yourself in someone else’s shoes, thinking about whether what you’re saying is appropriate given their level of experience, and making sure you’re not going to make them feel dumb by making something that’s actually hard/complex sound like you expect it to be obvious.
This is something we worry about a lot in Software Carpentry because we’re teaching complex computing topics to novice programmers. In fact, we recommend instructors completely avoid the word “just”. We discuss this a little in our instructor training materials:
Software Carpentry’s founder recently put together a short, 2.5 minute video giving examples of many of things you should not do when explaining complex topics to novices, such as using jargon and trivializing complexity. It’s worth a cringe-inducing watch:
This post came across my Twitter feed this week that talks about some of the spurious, meaningless reasons software engineering candidates are rejected. It’s challenging to evaluate candidates and we have a lot of productive discussions about how best to do that, but there some personal characteristics that we know are irrelevant to job performance: gender, race, age, sexual orientation, marital status, parental status, accent, where you grew up, etc. But even though we know those characteristics are irrelevant, they can still unconsciously affect how we evaluate and work with people through something called unconscious bias.
Another study examined gender bias in academic science. From the abstract: “In a randomized double-blind study (n = 127), science faculty from research- intensive universities rated the application materials of a student—who was randomly assigned either a male or female name—for a laboratory manager position. Faculty participants rated the male applicant as significantly more competent and hireable than the (identical) female applicant. These participants also selected a higher starting salary and offered more career mentoring to the male applicant. The gender of the faculty participants did not affect responses, such that female and male faculty were equally likely to exhibit bias against the female student.”
Microaggressions are small, often unintentional actions that can make others feel out of place. Examples can include asking where someone is from, acting surprised when someone doesn’t know something, or always expecting women to do office-keeping work. They can make people feel like they don’t belong and distract them from doing their actual jobs. “Micro”-aggressions might not sound so bad, but over time and many interactions they create an unwelcoming environment that can cause employees to leave or cause people to not want to attend events. As an example, a friend of mine almost swore off of all tech events after she went to a social event where everyone ignored her and talked to her lawyer husband instead.
It’s everyone’s job to make sure they’re actively creating a environment in which everyone feels that they fully belong. You can help by learning more about microaggressions and doing your best to avoid committing them (they hurt even when you don’t mean them to).
Here are a couple of good links that describe what migroaggressions are and the affect they have: