How to find venues for new workshops

by Beverly Nelson

If you are starting a workshop in an area not known for tech or where workshops are not traditionally held, you might wonder how to go about securing a host for your event.

Insight from previous organizers who’ve been through this exact situation shared these helpful ideas:

Look at local meetups and see where they are hosted, connect with the organizer, find out where people work who attend, ask there for people who want to host/sponsor.

Look at companies who are hiring.

Look at co-working spaces where they have open desks, so having events will help them become more well-known (as opposed to venues that charge for space).

Consider alternate spaces — some libraries or universities like to host community events.” The closest satellite location for the state’s university or community center might be available and eager to provide opportunities for the community. Public school systems often provide space on the weekend while students are out.

If you are still struggling to find a venue, use social media. Tweet or post your request locally

Do you work at or know a company in (your local area) who would like to host a @railsbridge workshop?

One final valuable reminder from Sarah Allen:

The key thing is to build relationships. Work with a company to find a convenient time for them, consider planning an event a few months from now, if that is what works, you can always plan another one sooner if somewhere else opens up.

If you are looking for more help in getting started check out the Cookbook, reach out to the workshop google group to connect with other organizers and volunteers, or email us at hello@railsbridge.org.

How to find venues for new workshops

Railsbridge Success Story: Kinsey Ann Durham

by Kinsey Ann Durham

Tweet reading "Already having so much fun at RailsBridge in Denver! All set and ready to go on Heroku!"

I can honestly tell you that a RailsBridge workshop changed my life. I reluctantly attended my first RailsBridge workshop in November of 2012 with my two girlfriends. I decided to attend the workshop because I wanted to get better at my job of managing developers. I thought it would be great to get a taste of what developers actually did. I never thought that I could become a developer, however. It was really intimidating! My step brother is an awesome developer and when he would talk, everything was over my head and it seemed like he was speaking an alien language! I remember telling my Dad on the phone that I wanted to be around developers, something attracted me to writing code, but there was no way I could do it.

Attending my first RailsBridge workshop was awesome! I met a great network of people and even my future mentor. That’s when I started to build my network in the Ruby community, simply by attending this event. I remember telling my friend at the event that I was going to write code from now on!

It wasn’t that simple. I didn’t become a developer right away. Over one year, three RailsBridge workshops, an apprenticeship at thoughtbot, three conference talks later, I finally feel that I can call myself a developer! I am going to be working as the Teaching Assistant and developer for Galvanize’s gSchool. I get to mentor, teach, write code and most importantly, help others find their passion in writing code. I could not be more excited, and I have RailsBridge to thank for my newfound career! Thank you to all of the volunteers, organizers, sponsors. You truly are making a difference in many people’s lives!

Railsbridge Success Story: Kinsey Ann Durham

RailsBridge co-founder Sarah Mei’s “Incomplete & Mostly Wrong Guide to Working with Men”

On August 9, 2013, co-founder Sarah Mei was one of the many speakers at SheCodes Conference held at the Computer History Museum.

Her presentation touched on a few notes about why diversity in a team leads to more creative problem solving as well as how to make a team/company/community impact.  Check out her presentation on Speaker Deck.

Official photos for this event can be found on Flickr.

RailsBridge co-founder Sarah Mei’s “Incomplete & Mostly Wrong Guide to Working with Men”

Railsbridge co-founder Sarah Allen on NPR’s “All Tech Considered”

Our very own Sarah Allen is featured as part of NPR’s series – Changing the Lives of Women.

In the article, Sarah shares a bit of her journey as a programmer from teaching herself simple programs on the Apple II to becoming a working mother to starting RailsBridge with Sarah Mei (known in the article as “a friend”).

Listen to the interview here:  http://www.npr.org/blogs/alltechconsidered/2013/04/29/178810467/blazing-the-trail-for-female-programmers

The picture hanging in Sarah Allen’s office — Ester Gerston and Gloria Ruth Gordon, early programmers working on the ENIAC computer in 1946.
Railsbridge co-founder Sarah Allen on NPR’s “All Tech Considered”

From BugMash to Core Contributor: an Interview with Santiago Pastorino

by Jen Lindner

Santiago Pastorino (@spastorino) is a core contributor to Ruby on Rails. (Read in spanish)

Can you tell us a little about your background, and how well you knew Rails when you first participated in a BugMash?
My name is Santiago Pastorino and I am from Montevideo, Uruguay. I received my degree in Computer Engineering in Uruguay. It’s a 5 year program that’s very similar to a BS in Computer Science in the US.
I worked with Java with a local company for two years while I finished up my degree. After completing the degree my partner José and I decided to start WyeWorks. It was at this time that we started to get much more interested in dynamic languages and their frameworks, like Ruby on Rails and Python/Django.

We considered which language and framework to use for our first consulting job and since we preferred Ruby and José had previously worked with Ruby, we decided it would be best to start with Ruby on Rails.

We never regretted the decision. 🙂

This was midway through 2008, and it was at the start of 2010 that I participated in the BugMash. I had little experience and in that year and a half I didn’t program very much because we had to take care of the business as well.

So my experience was very limited.

What drew you to it? Had you ever built or worked on a framework before?

I never built or contributed to any frameworks before contributing to Ruby on Rails. But with Ruby on Rails we had various reasons to do so. Since it was the framework we worked with every day, it had to shine. Our business is to sell high quality consulting and development by the hour. Contributing is the best way to position ourselves as experts with the tool.

Do you remember any of the bugs you fixed that day? How challenging did they seem to you as a newcomer?

At the time, Ruby 1.9 was on the rise. Ruby 1.9.1 had already been released and Rails was starting to support it. There were a few failing tests with Ruby 1.9 and I believe I fixed three, some partly shared with others who were also participating. It was very challenging at the time because I didn’t have the necessary understanding to do many things.

Where did you find help?

Many people from BugMash helped me during the event, among others, the organizers like Sam Elliott. After the BugMash, the other members of the core team, most importantly Yehuda Katz, José Valim, and Jeremy Kemper helped me very much to contribute.

What did you find most satisfying about the experience? And why did you continue working on tickets afterwards?

I especially always liked to understand in depth how things work. To contribute to a tool you have to understand how it works. It seems to me the best way: research and naturally you later find ways to make improvements.

I kept building on what I said earlier: at WyeWorks we are committed to development on the framework. It’s part of our business, it’s a way to support the work that so many people have done, and it’s truly our passion.

Do you think you’ve learned more about the philosophy behind Rails by running its tests and fixing issues than you have by just using it?

More than running and fixing tests, generally both using the framework as much as contributing to it add up to knowledge and add up to better understanding the philosophy behind Rails. The perspectives that you get as user and as collaborator with the framework are different.

Is there any advice you’d like to give to people who might want to participate an in open source project?

My recommendation is simple. One has to dedicate time to try to understand why things work. Everyone who has contributed has dedicated a lot of time. No one is born with the knowledge.

Besides, by luck, the people who contribute to Rails are very friendly, something that lamentably doesn’t happen on other projects. This is very good because as you start to contribute there are many people willing to talk to you and help.

From BugMash to Core Contributor: an Interview with Santiago Pastorino

De BugMash a Core Contributor: Entrevista a Santiago Pastorino

por Jen Lindner

De BugMash a Core Contributor: Entrevista a Santiago Pastorino  (@spastorino)  (Lee en inglés)

Q. Cuentanos un poco de tu formación, que tanto sabias de Rails cuando primero participaste en un BugMash?
A. Mi nombre es Santiago Pastorino y soy de Montevideo, Uruguay. Estudié en Uruguay y me recibí de Ingeniero en Computación. Es una carrera de 5 años que es bastante similar al BS in Computer Science de Estados Unidos. Trabaje con Java en una empresa local durante 2 años mientras estaba terminando la carrera. Luego de terminar la carrera decidimos con mi socio José arrancar WyeWorks. En ese momento nos empezamos a interesar bastante más por los lenguajes dinámicos y los frameworks estilo Ruby on Rails y Django. Estuvimos discutiendo con qué lenguaje y con qué framework hacer nuestro primer trabajo de consultoría y debido a que nos gustaba más Ruby que Python y que José ya había trabajado con Ruby anteriormente, nos decidimos que lo mejor era empezar con Ruby on Rails. Nunca nos arrepentimos de la decisión :). Eso fue a mediados del 2008, y fue a principios del 2010 que participé en el BugMash. Mi experiencia era muy poca y en ese año y medio no había programado demasiado porque teníamos que dedicarnos bastante a la empresa también. Así que mi experiencia era bastante limitada.

Q. Que te atrajo? Habías anteriormente construido o contribuido a otro framework?
A. No construí ni contribuí a otros frameworks antes de contribuir a Ruby on Rails. Pero con Ruby on Rails tenemos varias razones para hacerlo. Es el framework con el que trabajamos todos los días, tiene que brillar. Nuestro negocio es vender horas de consultoría y desarrollo de alta calidad. Contribuir es la mejor manera de posicionarnos como expertos en la herramienta.

Q. Te acuerdas de algunos de los bugs que arreglaste ese día? Que tan desafiante te parecieron como principiante?
A. En ese momento Ruby 1.9 estaba surgiendo, Ruby 1.9.1 ya había sido liberado y Rails estaba empezando a soportarlo. Habían varios tests fallando con Ruby 1.9 creo que arreglé 3 algunos medio compartidos con otras personas que estaban participando. Fue bastante desafiante en ese momento porque no tenía el conocimiento necesario para hacer muchísimas cosas.

Q. Donde encontraste ayuda?
A. Muchas personas del BugMash me ayudaron durante ese evento, entre otros los organizadores como Sam Elliott. Luego del BugMash los otros miembros del core team fundamentalmente Yehuda Katz, José Valim, y Jeremy Kemper me ayudaron mucho a contribuir. A mi particularmente siempre me gustó entender a fondo como funcionan las cosas. Para contribuir a una herramienta tenés que entender como funciona. Me parece que es la mejor manera, investigás y luego naturalmente encontrás mejoras. Yo continué trabajando luego por lo que decía anteriormente, en WyeWorks estamos comprometidos con el desarrollo del framework. Es parte de nuestro negocio, es una forma de apoyar el trabajo que tanta gente ha hecho y ademas porque realmente nos apasiona :).

Q. Crees que haz aprendido más sobre la filosofía detrás de Rails corriendo las pruebas y arreglándolas que solo usándolo?
A. Más que por correr los tests y arreglarlos en general tanto usar el framework como contribuir suman al conocimiento y suman a entender mejor la filosofía detrás de Rails. La perspectiva que tenés como usuario y como colaborador del framework son diferentes.

Q. Tienes algún concejo que quisieras darle a quienes quieran contribuir a un proyecto de open source?
A. Mi recomendación es sencilla, hay que dedicarle tiempo e intentar entender como funcionan las cosas. Todas las personas que colaboran han dedicado muchísimo tiempo y nadie nace sabiendo. Por suerte ademas las personas que contribuyen a Rails son muy amistosas cosa que lamentablemente no pasa en todos los proyectos. Eso está muy bueno porque empezás a contribuir y hay mucha gente dispuesta a discutir contigo y a ayudarte.

De BugMash a Core Contributor: Entrevista a Santiago Pastorino