Author: Gabriela D'Ávila Ferrara

react-usa-map: A package for customizing the USA map without D3

react-usa-map: A package for customizing the USA map without D3


  • I created a React package called react-usa-map
  • It displays the USA map with the states including DC / Hawaii / Alaska
  • It’s MIT license
  • Install instructions on The package section of this post.

Package origins

I am working on a project which may or may not go much further. I am building a Rails back-end and playing with React + Redux for the front-end.

This project requires me to have a map of US States and for it to be possible to customize the colors and add an “onClick” event for each state.

I decided to create a React component because said map will be used in more than one place in my project. I tried D3. It’s good, really good, but I needed something simpler. I have three weeks to do this project and between programming back-end and front-end alone I don’t have the time to do the perfect Chropleth map as much as I want to. It is a “nice to have” in my project, not a “must have”. Maybe after the end of the project I will open source it. I do need to check if I can legally open source the project since I am getting the data from a 3rd party with tight licensing requirements.

After finding this map on Wikimedia through the react-us-state-map package on I thought: this is a cool idea, to have the map as an SVG and then change the filling as I want it.

The first step for the package

I extracted the dimensions out of the <svg> and put in a JSON to be read by the component.

The second step

Facebook created this really cool thing for React: create-react-app. It allows you to have a boilerplate code for your react application without actually have to worry how to transpile your code for ECMAScript 2015 and configure webpack.

However they don’t have a create-react-package or create-react-component. Since I am just now going in this front-end adventure, I did what other developer would do in my place: I googled and found this repo.

The third step

I did some modifications on the package.json removing packages I wasn’t using and other necessary actions such as adding tags, scripts, etc.

The final step

Publishing to NPM is actually simple:

Once logged in the terminal run:

$ npm version 1.0.0 # your version number here
$ npm publish

After this I created a demo project to see if my map would work as intended.

The package

You can install using:

yarn add react-usa-map


npm install react-usa-map --save


It uses React 15.4.2 as minimum requirement and it is compatible with React 16.0.0.

More information

react-usa-map started with only me as a contributor, and since the release people contributed adding tests, continuous integration and new features.

Transferring ownership of repositories on GitHub

For the past couple months, I’ve been studying. As a side effect, my GitHub account was cluttered with code that is experimental. I didn’t exactly want to trash the experimental code. I wanted to keep my code but also not specifically keep it under my profile.

The solution I found was to create an organization and transfer my desired repositories there. I thought this was a great solution, there was just one little detail I was missing: the current GitHub API does not support repository ownership transfer. Which meant I would have to go to each repository, click on “Settings”, click on “Transfer”, fill in the “Repository Name” and then put the “Destination User”. A lot of steps for someone looking to move over 250 repositories.

The first thing that came to my mind was to use Selenium to automate this task. But my lack of exposure with the technology made me think a bit outside the box. One of the things I learned these past months was capybara. Capybara is used alongside Rspec, extending the test suite DSL. It mimics user interaction with the browser and comes with a Selenium driver out of the box.

In other words, you can create a bot to go to the browser, fill up forms and submit it. This is exactly what I was looking for. As I stated before, Capybara uses Rspec, so my code would actually have to be wrapped inside a test.


  • You need to disable two-factor authentication on GitHub, and after the script finishes running set it back on.
  • It does not transfer private repositories.
  • You need Mozilla’s geckodriver installed. If you use macOS, you can use brew to install it.

The Script

This was developed as a hack. Use at your own risk. You can download it at gabidavila/github-move-repositories. As of now this code gets all public repositories, unless the variable ONLY_FORKS is set to TRUE, and moves to a destination user. Do not push your .env​ file.If you want to move only specific repositories, you will need to edit the code yourself. For more information the of this project is kept up to date.

Contributions are welcome if you feel you can help improve the tool. For example: add options of which repositories to move.


Using Active Record migrations beyond SQLite

Using Active Record migrations beyond SQLite

SQLite is really a good tool to set up quick proof of concepts and small applications; however it’s not the most robust solution on the market for working with relational databases. In the open source community two databases take the top of the list: PostgreSQL and MySQL.

I did a small project for my studies. I was using SQLite as I didn’t need much out of it. Curious, I decided to see how the application would behave on other databases and decided to try PostgreSQL and MySQL. I had two problems to solve, and this post is about the first one: how to deal with the migrations. They were as follows:

Active Record automatically put the field id in all of its tables, that’s why it is omitted on the migrations.

In PostgreSQL it went smoothly, all the migrations ran without any hiccup, except on MySQL, it gave me an error!

StandardError: An error has occurred, all later migrations canceled:

Column `artist_id` on table `songs` has a type of `int(11)`.
This does not match column `id` on `artists`, which has type `bigint(20)`.
To resolve this issue, change the type of the `artist_id` column on `songs` to be :integer. (For example `t.integer artist_id`).

Original message: Mysql2::Error: Cannot add foreign key constraint: ALTER TABLE `songs` ADD CONSTRAINT `fk_rails_5ce8fd4cc7`
FOREIGN KEY (`artist_id`)
REFERENCES `artists` (`id`)

The problem, beyond generating an ineligible name for an index: fk_rails_5ce8fd4cc7, is that artist_id on my table was as INT. The first thing I checked was to see if the was UNSIGNED and if my foreign key was also unsigned. They weren’t, but since were both signed, it wouldn’t throw an error. Looking more closely to the error message I noticed that the type in my foreign key column did not match the type on the primary key on the other table. Little did I know that Active Record generates the id field not as an INT, but as BIGINT.

I decided to go back and look at PostgreSQL, and to my surprise, and up to now I still am not sure of why, PostgreSQL did allow the column type mismatch where MySQL threw an error.

To fix it, I had to change the migration as follows:

Digging online, I found out how to create a bigint field with AR. According to the post, this would only work on MySQL, which they did, but I found it also worked with PostgreSQL (I tested MySQL 5.7 and Postgres 9.6): t.integer :artist_id, limit: 8.

The limit is used to set a maximum length for string types or number of bytes for numbers.

Why type matching is important

As an INT let’s say you can fit your number inside an espresso cup. Sure you can use the Starbucks Venti size cup to fit your coffee, but the full content of a Venti would never fit an espresso cup.

In the specific domain I am working on if I had a big list of Artists, and happen to have an artist which ID was higher than 2,147,483,647 (signed, and for both PostgreSQL and MySQL), I would get an error when trying to insert it into the Songs table since an Artist id can be up to 8 bytes (9,223,372,036,854,775,807).


Queen has its Artist id as: 21474836481 (which is a BIGINT)

Trying to insert “We Will Rock you” in the artist_id column for songs:

We get:

********** Error **********

ERROR: integer out of range
SQL state: 22003

This is the kind of problem we don’t usually notice in the beginning, and more often than not while the application is in production for even years, but this can happen and will happen if we don’t pay attention to foreign key types.

After that change, all the migrations ran smoothly. And I could actually move forward to the next problem (and post): Filtering a song title or artist name.