Migration to Firebase from a Heroku-hosted Rails app appears to work seamlessly. I’ve only tested one user, but I could log in with the same password and Facebook account with no end-user intervention.

It took a little experimentation to come up with the correct format for export from heroku psql command line:

\COPY (select id, email, CASE WHEN confirmed_at IS NULL THEN 'false' ELSE 'true' END as Verified, regexp_replace(encode(encrypted_password::bytea, 'base64'), '\n', '') as hash, password_salt::text, screen_name, '' as photo, '' as google_id, '' as google_email, '' as google_name, '' as google_photo, uid as facebook_id, provider_email as facebook_email, '' as fname, '' as fphoto, '' as twitter_id, '' as twitter_mail, '' as twitter_name, '' as twitter_photo, '' as github_id, '' as github_mail, '' as github_name, '' as github_photo, EXTRACT(EPOCH FROM created_at)::bigint, EXTRACT(EPOCH FROM last_sign_in_at)::bigint, '' as phone FROM speakers ORDER BY id limit 160) TO '~/users.csv' WITH (FORMAT csv, DELIMITER ',');

Which I imported with the following command:

firebase auth:import ~/users.csv     \
    --hash-algo=BCRYPT               \
    --rounds=10                      \

Check your devise config file config/initializers/devise.rb — encryption options are configurable there.

Additional Notes

I found these samples helpful to get a test running very quickly.

Firebase auth import requires exactly 26 collumns (for csv import):

UID,Email,Email Verified,Password Hash,Password Salt,Name,Photo URL,Google ID,Google Email,Google Display Name,Google Photo URL,Facebook ID,Facebook Email,Facebook Display Name,Facebook Photo URL,Twitter ID,Twitter Email,Twitter Display Name,Twitter Photo URL,GitHub ID,GitHub Email,GitHub Display Name,GitHub Photo URL,User Creation Time,Last Sign-In Time,Phone Number

In learning a new programming language, it’s helpful to understand it’s philosophy. I seek to learn patterns that are idiomatic, and more importantly: why the syntax is the way it is. This allows me to write original code more quickly, gaining an intuition for simple things like when to look for a library and when to just write code.

I rarely find good resources for learning a new language that are targeted at experienced programmers. So I’ve developed a habit of looking for language koans. Inspired by Ruby Koans, these are unit tests which guide a programmer through basic language constructs by presenting a failing test and let you write simple code to learn the syntax of a language. These tests typically include a bit of text that helps newcomers reflect on what is special and interesting about this particular programming language.

In learning Go, I found cdarwin/go-koans, which helped me to reflect on the philosophy of golang, the Go programming language.

The koans caused me to meditate on the basics, leading me to read more and reflect. While about_basics.go is quick to solve technically, it sparked my curiosity on two points.

1. The uninitialized variable

I really wanted the comments in the go-koans to be a bit more like Zen koans (or Ruby koans), so I wrote these:

// listen to the darkness of an unset variable
// what is the code that is not written?
// consider the emptiness of a string

// create meaning from emptiness
// undefined structure isn't

“Make the zero value useful” —Go Proverbs

It reminds me of the Zen teacup parable. An empty cup has utility, even before it is filled.

2. The implications of a string

One of the most deceptively simple types in modern programming languages is the string. In Go, there is a built-in string type with short, unsatisfying descriptive text.

Strings, bytes, runes and characters in Go explains that strings are a read-only slice of bytes (at runtime). Go source code is UTF-8, so string literals always contain UTF-8 text (except for byte-level escapes.

Strings always cause me to reflect on how memory management works in a language. In my search for basic answers about how and when memory happens in string operations, I read about allocation efficiency in high-performance Go services which includes a nice explanation of heap vs stack memory allocation in Go.

Reflections

At this point, I don’t know what I need to know about this new programming language. I just like to know what the code I’m typing actually does. Learning syntax is boring, so I need to occupy my mind with something more interesting while I practice typing unfamiliar sequences of text. To write good code, I need to know so much more than the syntax, but I need to be careful not get get too attached to certain details. For example, future compiler versions change the patterns of how code is transformed into machine operations. However, if I attach just a little deeper meaning to these syntax constructs and get a feel for what my code ends up doing under-the-hood, I can more quickly understand the implications of the code I write.

When I emerge from these learning meditations and I can finally construct this new syntax without thinking and start to solve actual problems that matter to humans, then I will have created these little trails in my mind that lead to empty spaces, which have shape and meaning, like the Go zero value and the Zen teacup.

There’s a common pattern where some men seem to have a complete inability to understand women when they speak. As far back as the 1970s, this kind of interaction has been illustrated with humor:

an excellent suggestion, Miss Triggs. Perhaps one of the men here would like to make it

The term mansplaining was coined more recently, sparked by Rebecca Solnit’s 2008 essay Men Explain Things to Me. Solnit’s stories present a different perspective from the prevailing narrative that women lack confidence to speak up: perhaps the lack of confidence is not in ourselves but rather in our audience. One must be an authoritative expert on a subject with footnoted documentation before having the right to an opinion, and even then, we may be inaccurately criticized or simply ignored.

It was a few years ago when I realized that I had accepted the status quo. I was on a conference call with two male colleagues. I was caught up in the discussion and hadn’t noticed that I had initially put forth an idea that was then attributed to my other male colleague. Instead of tacitly accepting credit for my idea, he promptly said “I agree, that was a great idea that Sarah had.” A simple correction, said kindly with an edge of humor, honored my contribution while gently chiding our colleague. Most men have the capacity to listen to the words I say and follow the thread of the idea, and some realize that correct attribution is a simple respect that fosters effective collaboration.

A couple of weeks ago, Jen-Mei Wu, Judy Tuan and I were talking about code and sharing stories of our lives. With dark humor, I noted that for some men, it seems that my voice is unintelligible. I know they hear me, since they typically wait till I finish speaking before repeating themselves verbatim as if I had not spoken or asking a less knowledgeable man to explain in more detail. I joked that I needed a personal translator, a man who would attend meetings with me and repeat what I say for some of my colleagues who can’t seem to understand my words.

We wondered if this behavior might stem from the need to compensate for a cognitive disability where some men can hear female voices, yet struggle to discern meaning from sound. Without self-awareness of their own affliction, when they hear the garbled syllables, they assume the woman is not speaking clearly, and so they feel compelled to repeat their understanding of the words. Tech companies might identify men who are thus impaired and offer mansplaining-as-a-service as a benefit to accommodate this peculiar affliction.

I sought a word to describe this new insight about a potential root cause, perhaps a previously unknown form of aphasia where some men cannot cognitively process words when they are spoken by women. It seems important to separate the community service where a man will amplify a women’s ideas by repeating key points with attribution, as distinct from the bizarre echolalia commonly known as mansplaining which may be a further symptom of this affliction.

In reading further on this subject, I discovered some research indicating that there might be a physiological basis for this syndrome. Further study may be needed. Independent of the neurological processes involved, I suggest the word agynephasia to describe this phenomenon.

agynephasia greek roots: a- not, gune woman, phanai speak

I urge men to support your colleagues who may be unaware of their disability. Until the tech companies start routine testing for this affliction and providing trained assistants, you can help by learning about the expertise of your colleagues and dinner guests, regardless of their race or gender, correctly attributing ideas, and helping to redirect the discussion if needed.