Since I’ve reached the part of my internship where I need to evaluate a Ruby web API client library and had never written Ruby, I went looking for places to learn! Some of these are books, some are websites, some are web tutorials. All are online and free. If you’re new to Ruby, give these a shot!

Books:

Ruby Best Practices: http://cdn.oreillystatic.com/oreilly/booksamplers/7_Ruby_Best_Practices_Sampler.pdf
Previously available for free at http://blog.rubybestpractices.com/. The author is now working on Practicing Ruby: https://practicingruby.com/
Interesting links from Practicing Ruby: https://practicingruby.com/articles/meditations-on-bad-and-good-code-1 and https://practicingruby.com/articles/meditations-on-bad-and-good-code-2 .

Programming Ruby: The Pragmatic Programmer’s Guide: http://ruby-doc.com/docs/ProgrammingRuby/
When people talk about “pickaxe book” this is the one they’re talking about! This version is fairly dated:
“This book documents Version 1.6 of Ruby, which was released in September 2000.”

Why’s (Poignant) Guide To Ruby: http://mislav.uniqpath.com/poignant-guide/book/
If you want an off-the-wall introduction to Ruby, this one has cartoon foxes.

Mr. Neighborly’s Humble Little Ruby Book: http://www.humblelittlerubybook.com/

Learn Ruby The Hard Way: http://ruby.learncodethehardway.org/book/

Web-based tutorials:

Ruby Koans: http://rubykoans.com/
Make things work! Also downloadable.

Try Ruby: http://tryruby.org/
More in-browser Ruby tutorials.

Codeacademy’s Ruby module: http://www.codecademy.com/tracks/ruby
Interactive web-based Ruby lessons.

RubyWarrior: https://www.bloc.io/ruby-warrior/#/
Adorable game where you write Ruby code to move your warrior and defeat enemies.

Misc:
A MIT OpenCourseWare handout that has a no-frills guide to some basics and talks about differences between Ruby and Python: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-170-software-studio-spring-2013/recitations/MIT6_170S13_rec3-Ruby.pdf

Ruby Style Guide: https://github.com/bbatsov/ruby-style-guide . I’ve been told that this is as close as the Ruby community gets to consensus on what “good Ruby” looks like.

command line ruby cheat sheets: http://cheat.errtheblog.com/s/rvm

Ruby Cookbook is not freely available, but the all the code from the book is: http://www.crummy.com/writing/RubyCookbook/

Ruby is definitely not what I am used to, but it seems like an interesting language and I’m looking forward to learning more of it when I have more time.

When I decided to start working in tech, I knew that someday I’d find my place in the informal women-in-tech backchannel warning system.

It seems that I’ve already reached a place where I can practice two kinds of post-conference networking: the standard mild awkwardness of “Hello! Remember those interests we share? I think you are a professionally interesting person!” but also “Hey, heads up–I’ve been made aware that a person you socialized with has a history of sexually assaulting incapacitated women, and thought you might want to know.”

I knew I’d get here sooner or later.

I wish I’d been able to finish my first internship before I did.

I was honored to give the final keynote at last week’s Open Source Bridge 2014. My talk was titled “‘Why are these people following me?': Leadership for the introverted, uncertain, and astonished”. It is the story of how I learned and claimed my leadership skills–because leading and conveying authenticity are both learnable skills.

This talk contains brief and nonspecific mentions of emotional abuse and thoughts of suicide. The video skips in several places; I’ve filled in the transcript to the best of my memory, but if you happen to have more complete notes or corrections send them my way!

Video and transcript are below the fold. This talk is licensed CC-BY-SA.

Read the rest of this entry »

I am not back from WikiConference USA 2014, but I am settled in here to work and decompress for a few days. I attended the conference to give an intro-level talk and workshop based on my own work getting up to speed with the MediaWiki API, and to meet more of the larger Wikimedia community. I also got the chance to meet technical contributors whom I’d previously only interacted with on IRC and the wikitech-l mailing list. It’s good to be able to put faces to usernames. I also chatted with Asaf Bartov, a contributor to Mediawiki::Gateway. Asaf confirmed my first impressions of the library’s scope and quality–a good check for my work.

So, the talk! If you’re interested in the basics of web APIs (or MediaWiki’s in particular), my slides are available on Wikimedia Commons. Video for the talks will be up soon–see the WikiConference USA 2014 category for more photos.

Slides for talk
Slides for workshop/demo

I aimed the talk at an audience that was not wholly nontechnical but that would include non-programmers. Based on this feedback, it looks like I succeeded! https://twitter.com/kos2/status/472415903993589761https://twitter.com/kos2/status/472415903993589761

More highlights of the conference:

Sunday was the open space/unconference day. We started off with lightning talks (I talked about the Seattle Attic as a feminist hackerspace) and then I attended Sumana’s Diversity/Ally Skills training, using the Ada Initiative’s publicly licensed materials. We had about an hour until the next round of lightning talks (very cool stuff: Book scanners! Publicly available Israeli laws! 5-shot method of shooting video! Gender visualizations! Wikidata and maps!) so we only got through a couple of scenarios. The attendees at the Ally Skills training had wanted to keep going, so I agreed to lead another session in the afternoon.

It was an interesting experience, and it sounded like many of the attendees got a lot out of it. It was surprisingly/not surprisingly emotionally draining to run but I was glad to be able to offer this. The workshop offers concrete suggestions about how to deal with sexist words and actions as they come up, as well as some basic feminist background for people who may never have considered how some of these principles apply to their own life, and does it in the format of private small-group discussions. I am grateful to everyone who participated, shared, and listened in both of the sessions yesterday. I suspect that those conversations gave many of us things to think about. They certainly did to me.

This summer I’m taking part in the Outreach Program for Women, working on making the MediaWiki API more usable. As a part of this, I’ll be blogging every week or two with things I’ve done, things I’ve learned, or general thoughts as I get into the free/open source software world.

This is the second in a series on the MediaWiki API. Click here for previous post.

What is an API? “API” is short for Application Programming Interface, which is not much more informative. Broadly, APIs make it easy for programs to interact with each other–which is to say, they make it easy for programmers to incorporate a different program’s functionality into the program they’re writing.

This article on APIs by Brian Proffitt clearly describes the most important ways APIs work:

APIs… “[expose]” some of a program’s internal functions to the outside world in a limited fashion. That makes it possible for applications to share data and take actions on one another’s behalf without requiring developers to share all of their software’s code. Code-sharing on that scale wouldn’t just ruffle the feathers of programmers who’d rather keep it secret; it would also be grossly inefficient.

That’s true even for open-source programs. Who has the time to comb through all the code for somebody else’s application—which, trust me, can be awfully messy—just to use one function? (It’s also possible to run into tricky licensing issues if you’re not careful.)

APIs simplify all that by limiting outside program access to a specific set of features—often enough, requests for data of one sort or another. Feel free to think of them as doors, windows or levers if you like. Whatever the metaphor, APIs clearly define exactly how a program will interact with the rest of the software world—saving time, resources and potentially nasty legal entanglements along the way.

That’s the general concept behind APIs. Web APIs are similar, but made for the internet: they’re a way to fetch data from the database behind a website.

When you use a web browser to go to a website, your web browser makes an HTTP request to the server the page is stored on. The server, in turn, sends you data in the form of a web page: information in text/video/graphical form, arranged so that humans can easily understand it. You are now free to read the article/look at kitten pictures/write and post your blog post/watch that awesome fanvid.

When you write a program that uses a web API to fetch data from a website, your program makes a carefully-constructed HTTP request to the server the site is stored on. The server, in turn, sends you data in a format your program expects (if you asked for data) or incorporates your changes to the website (if you sent data). Your program now has a tasty chunk of data to use and you can use it to make diagrams/search for specific items/look at a user’s history/edit that wiki page/automatically bookmark those “to-watch” fanvids.

That’s it. A web API is just another way of exchanging information with a website. This web API description on Wikipedia is still full of acronyms… but it might make more sense now.

In the next post I’ll talk about how you can figure out how to make requests from an unfamiliar API.

This summer I’m taking part in the Outreach Program for Women, working on making the MediaWiki API more usable. As a part of this, I’ll be blogging every week or two with things I’ve done, things I’ve learned, or general thoughts as I get into the free/open source software world.

When my mentor mentioned that she had a project that could use an intern, I was not 100% clear on what an API (Application Programming Interface) was. I knew it had something to do with another way to interact with websites without actually having to visit the relevant webpages, but I’d never given it much thought.

I was interested, though. I went off for some quality research time and about ten days later I’d finished the project proposal for my OPW application.

Don’t believe anyone who tells you learning to code is easy…

…and don’t believe anyone who tells you that APIsespecially MediaWiki’sare intuitive.

As I gear up for WikiConference2014 next weekend, I’ll post resources I found helpful and tips for getting started yourself.

I wrote about the ways toxic entitlement enables unintentional but substantial harm in STEM communities for Model View Culture’s current issue, Abuse.

When “I Didn’t Mean To” Makes it Worse

Entitlement and violation in STEM communities

We assume that our stories are universal. We assume that what helps us will help others. We ask, “Couldn’t you just…?” and explain that, actually, if they saw things our way they’d have it better. We ignore differences of ability, power, class, and culture to overwrite their stories with ours. We expect the world to be as we want it, and when we have power we act like that’s true.

That is the danger of entitlement. When we expect more than we’re due, we are in danger of robbing those around us of their own autonomy. Our assumptions shape our actions. Unintentional harm becomes easy. When we don’t expect boundaries to exist, we step right past them without looking, all in what we think is good will.

We don’t want to do this. How do we stop?

I’ve written about my choice to leave the field of chemistry in Model View Culture’s Lean Out issue.

I Didn’t Want To Lean Out

Why I Left, How I Left, and What It Would Have Taken to Keep Me in STEM

When I decided to leave, I let go of my intention to continue contributing to the advancement of human knowledge as a scientist and a chemist. I mourned that I would not achieve my goal of changing the culture of organic chemistry, and I knew that my leaving would mean one less woman for other women to talk to, network with, and lean on for professional support. I fought feelings of obligation and squashed that nagging sense that I was letting down The Sisterhood™.

I was furious. I saw that little about my situation was fair, but there it was, and there I was.

In the end, I chose my own health and happiness and I chose self-respect.

You can find the rest here.

A prior version of this post was published on geekfeminism.org.

2013 was a hell of a year for me. I lost family; I ended or reshaped important personal and professional relationships; I began to reconsider my career path based on some truly unfortunate experiences in my academic departments. And with all that, it’s been the most personally and professionally rewarding year I’ve lived so far.

Why? I turned some of my frustrations into positive change and started the Seattle Attic Community Workshop, the first of the new West Coast feminist hackerspaces. I can—and will—talk about our vision for the space and specifics on how we are moving toward it. First, though, I’m going to talk about how my work with the Attic has changed me and why I love this space so much.

The Attic is the first formal community that I’ve been able to bring all of myself into without fear of rejection. There, I can be the least censored public version of myself. I’m not afraid I’ll be judged for the choices I make to deal with the flawed systems we all live in, and I’m not afraid that the real harm those systems do will be waved away in the process. The support there helps me grow into the self I want to be: gutsy, strong, curious, creative, knowledgeable, skilled, and compassionate. I want to create. I want to learn. I want to teach. At the Attic, I can ask the basic questions that let me learn without being condescended to for not knowing already. And more, I’m not the only member who’s restarted work on projects that had been on hold for months and years.

It’s what I wish working at a start-up, or a new lab, were like. We consciously notice our social dynamics. We learn from movements’ prior experience. We explicitly discuss burnout and balance responsibilities so that the work gets done and no one feels like they have to do it all. We value respect and kindness over displays of superiority — disagreements don’t define our worth as individuals, we aren’t afraid to be judged when we ask questions, and we’re not ashamed of our interests.

As we started this, I started to lead our early meetings and eventually was formally chosen as president. I discovered that I do have a talent for leadership—and here, I don’t have to keep my guard up or worry that my femaleness or my queerness will undermine it. I encouraged little things that build community; our meetings include a “rant and squee” section, one part consciousness-raising group, one part fannishness, one part show-and-tell, as well as a “good and welfare” section that I nabbed from my academic student employee union‘s meetings. Other members have also called me on my mistakes and failings and with their support, I’ve turned those around and done better.

This space and its members have also been a base of support for my other activism. It’s why one of our members entered the tech field this year. It’s a huge part of why I feel secure enough to consider leaving science for good. It’s given me the support I needed to be able to share my reasons why and is why I plan to do my best to make a change in my department and not keep my head down. None of this is easy, but now it’s possible.

So, this is a love letter of a sort to the Attic and the people it comprises. Many of my best experiences of 2013 were through the Attic or through the amazing women I met and worked with there. After this year it would be easy for me to leave science completely and geek from the edges, or to stay and become more and more angry and brittle. That’s not what happened. The acceptance, encouragement, and compassionate strength from my fellow Attic members have all helped make me into the person I want to be. I look around and see how I can be strong without shattering. I’ve been shaped by my painful experiences of that year; I’m being tempered by the kindness and utter acceptance the Attic shows me.

Right now, the Seattle Attic is finishing up our first fundraising campaign so that we can build on the beginning we’ve made and expand our space and our programs. We want to make this space sustainable, and we want to provide enough resources that other makerspaces can do the same. If you want to support us you can donate, or simply spread the word and tell a handful of your friends why this feminist makerspace excites you, personally. If you’re local or visiting, come to one of our open houses, workshops, or events — we would love to meet you.

Frances is the founding president of the Seattle Attic Community Workshop, Seattle’s first feminist hackerspace/makerspace. She prefers elegance in her science and effectiveness in her art and is happiest when drawing on as many disciplines as she can. Frances’s current passion is helping others find the space, tools, and community that they need to make their world fit them better. Between her science and her skill at ancient technology, she considers herself an integral part of any postapocalyptic team.