A few weeks ago, we (Laura, Sara, Anika) flew to Kansas City, where we were presented with a Ruby Hero Award for the work on Rails Girls Summer of Code on the stage of RailsConf. The introduction by Olivier Lacan that led up to the award announcements also included a slide with a multitude of faces: all of the Ruby Heroes from 2008 until today. It felt like an honour and a privilege to be now among them and to have Rails Girls Summer of Code recognised for its work in improving the Ruby community, but one thought crossed our minds right away: Is it appropriate for a couple of people to receive an award for a whole organisation?
RGSoC in a nutshell
We’re in our fourth year now, and as a community initiative, RGSoC has been organised by lots of people. All in all, every year we have over 100 volunteers working on the program: This includes organisers and developers, project mentors and coaches, who all work tirelessly in their free time to make our community a better place; some of them year after year. This initiative works because of the people — and only because of them.
What are the Ruby Heroes Awards?
“The Ruby Heroes Awards recognise the everyday heroes of the Ruby community” — this is the tagline you can find on the Ruby Heroes website. The award is an attempt to highlight people who have supported the community in one way or the other — in some case, unsung heroes who’d otherwise have their work go unnoticed.
Every member of the Ruby community is welcome to nominate their own Ruby Hero; the people with the highest amount of nominations end up on a shortlist, from which a jury of previous Ruby Heroes will pick the finalists. As with every award, this one comes with a great deal of criticism: Why is ABC on the list? Why isn’t XYZ on the list? Isn’t Ruby Heroes just a popularity contest?
While this blog post isn’t the right place to discuss the issues of how Ruby Heroes are nominated and selected, one thing we have to point out is that the jury selects people, not organisations. In our case, this means some of the individuals behind RGSoC were singled out to receive this award.
Everyone at RGSoC is a Ruby Hero
Standing on the stage of RailsConf, together with 6 other amazing people from the Ruby community — who have worked hard to make Ruby great, accessible, inviting, and inclusive — was incredible, and we are thankful to have had this opportunity. It made us proud of what we’ve achieved and of the lives we changed. It was a tangible proof for us that Rails Girls Summer of Code has an impact on the community. This happiness at the news was also tinged with a bit of sadness, because singling out individuals for their achievements within our organisation doesn’t reflect the spirit of RGSoC. Everyone who ever worked on Rails Girls Summer of Code is a Ruby Hero. If you’ve ever coached or supervised a team, organised, donated or sponsored this initiative: this award belongs to you.
Special thanks
As no award is complete without the special thanks section, we’d like to name a few people who have impacted RGSoC a great deal and without whom the program would not be in its fourth year.
Some of our amazing volunteers and Ruby Heroes! (Image: Ana Sofia Pinho)
Our organisers, past and present: Floor, Katrin, Carsten, Ramón, Ana, Maria, Sven, Lucas, Tam, Markus, Benedict, Lisa, Max, Emi, Vaishali, Andy, Robin, Natalie;
Duana and Erik for always believing in the program and supporting it from the first minute, and Erik for drawing attention to RGSoC for the RubyHeroes award;
Piotr and Tomasz for coaching every year and for this:
#donatebecause (Photo: Piotr and Tomasz)
Adam, Alex, Alexandra, Lieke, Vyki, Cathy, JZ, Kasia, Magda, Qian, Laura W., Charlotte, Verena, Claudi, Rebecca, Fanny, Arne, John, Uta, Jen, Anne, Terence, Susanne, Björn and so, so many more.
Thank you — this is for you!
Your Ruby Hero Award (Image: Anika Lindtner/Laura Gaetano)
RGSoC 2016 thank_you board (Photo: Ana Sofia Pinho)
This is our fourth year organising RGSoC and each year that goes by we feel extremely thankful for the support of the community: Each student who applies, each coach who gives us their time and knowledge to train our teams, each organizer helping to make the program a reality, each of you who retweets us or contributes to our scholarships with donations, each company that supports us and each project maintainer who submits their project to RGSoC. This program was created by each and everyone of you, and it’s going strong because of the community that backs us every summer.
Our community is the foundation of RGSoC and because of that, for the summer of 2016 we wanted to do something other than thank you: we wanted to show you the impact your contributions have to our program, and consequently to all the people who, in some way or another, have been part of RGSoC.
Assembling the RGSoC 2016 thank_you board square by square (Photo: Ana Sofia Pinho)
We built a board where we recreated the programming community, with its diversity percentages: roughly 80% men (in blue) and 20% women* (in red and yellow). The grey squares represent all the people outside the tech community who have no idea they have coding superpowers. Or they do, but they don’t have the means to pursue a career in tech (yet!).
We believe that a community changes when its individuals become agents of that change. And this is now when the fun begins! Bit by bit, or shall we say, square by square, the tech community transformed and started to be more diverse. This is where you enter: you are the person who makes all of this possible! You are the foundation of the program and of that change!
We have put the name of each person and company who contributed to RGSoC on a square and gave it a coordinate on the board. This is your place in our hearts! <3 Individual donors will have a square on the board and companies, depending on the type of sponsorship package, will get a specific number of squares. Each time someone donates, a grey square is converted into a colorful one. We took a picture of each time we put a square on the board and made a stop motion video for you.
Together we are creating an environment where women* feel more welcome. We are training more developers and helping them jumpstart their career. We are making Open Source a better place for everyone. We are creating the role models of the future. We are redefining the Tech community. We are helping to make our communities more inclusive and empower individuals to contribute to Open Source with their amazing potential. We are making Tech more diverse!
You make RGSoC possible and we don’t take this for granted! Thank you!
With your support we have already put 445 squares in our board and funded 11 teams. This is amazing! Let’s complete this board and fund even more teams!
Let’s #DiversifyTech!
* With “women”, we mean all people with non-binary gender identities or who identify as women.
We finally recovered enough from the applications closing last Sunday to write about it. Just like last year, the last few hours before the 17:59 UTC deadline were intense and we sat in front of our screens until the very end to reply to all the support emails and questions coming in.
This year, we received 92 applications — which is almost double the amount from last year. This is truly amazing! In the very last 24 hours of the application period, the number of submitted applications quadrupled, with the last application submitted a mere 32 seconds before deadline closed. That’s what we call LIVING ON THE EDGE!
Because of how we’ve set up our selection process, we will not be able to share information about the location of the different applications just yet; this said, we’ve tried really hard to reach out to several new initiatives worldwide, including a lot of different programming language communities, in the hopes that we could have applicants from different backgrounds, locations, and languages. One thing’s for sure: the next few months are going to be legendary!
And in case you’re wondering just how many support requests we had to answer over the course of the application period, worry no more, we’ve counted them all! Altogether, we’ve received 62 emails, 8 Facebook messages, and 96 requests via our special “application-support” slack channel. On top of that, 78 message threads, mostly by teams looking for coaches, were posted to our Google group community list.
Stats are nice, you say, but: what’s next?
We’re slowly getting started with the selection process, which will consist of 3 different phases; after which, the selection committee will get together to make the final decision. By end of May, we’re hoping to send out the application letters. We know it feels like a long wait, but it will be absolutely worth it! In the meanwhile, why not spread the word about our campaign?
The more funds we have, the more teams we will be able to support this summer <3
If you’ve applied, I’d also like to take a minute to THANK YOU for being excited about this program, for having read the requirements and worked incredibly hard to fulfil those requirements, for having searched for and found a team to work with and for spreading the word. You’ve already made the first step — always remember that.
As you may have heard, applications to RGSoC 2016 opened some time ago. So far all we can say is that we are extremely happy with all the support and applications to our program — this just inspires us to make this year even better than the last one!
Knowing how hard it can be to find a teammate or a coach, we thought about sharing with you some tips and best practices on how to do this.
If you don’t know anyone in your own community, you have four ways to find a teammate or a coach: Getting in touch with local Rails Girls Chapters or other similar initiatives, sending an email to our Rails Girls Summer of Code Google Group, tweeting or going to our Teams App.
Getting in Touch with Local Programming Initiatives
One of the most effective ways to find a teammate or a coach in your city is to get in touch with a Rails Girls chapter, a study group or other initiatives like Black Girls Code or PHP Women.
Before reaching out to them, please take a look at the projects you want to apply to and the programming languages of the project. This way, you will narrow the initiatives by programming language and you can focus on finding someone who has some knowledge in that language.
Rails Girls Summer of Code Google Group
At the moment there are almost 400 people in this Google Group, so you never know: Someone there might know a person that could be interested to pair with you or be a coach for your team.
When you submit a new topic, please say what you are looking for and don’t forget to mention the city in the subject line! It will make it easier for people to find you.
Oh, and when you find a teammate or a coach, please mark your conversation as “resolved”, so that we know you’ve successfully found what you were looking for. Thank you!
Twitter
A good way to reach to the community is through twitter. You have 140 characters so use them carefully: always mention what you are looking for and identify the city where you are going to be working in the summer.
One of the most common mistakes we see is when people tweet asking for a teammate or a coach but they don’t mention the city. This makes it difficult for someone to find out about the place and because of that, they can’t help you by retweeting or getting in touch with you.
Another important thing is to mention us @RailsGirlsSoC on the tweet, so that we can get a notification and retweet you. In case you have some space, use the hashtags #rgsoc or #rgsoc2016 to make it easier for people to find your tweets.
Rails Girls Summer of Code Teams App
When you sign up to the RGSoC Teams App, on the top right corner you will find our a link to our Community. There are over 800 people there and even though it is not a seamless process (please bear with us, we are working on it!), here you can filter people by their roles or interests. This means you can look for students who want to find a team or a developer who wants to help out as a coach. Then, you can sort the info by country or city.
We hope this helps! Once again, it is never too much to remind about our Guides, like the Application Guide or Finding a Team Guide. If you need extra help reach out to us on facebook, twitter or send us an email at summer-of-code@railsgirls.com.
This year’s Ruby Conference Australia was held on the Gold Coast, a vibrant and breathtaking city, known for its world famous Surfer’s Paradise — a beach and surfing haven — and home to the country’s most exciting theme parks.
Over two days in February, 26 amazing speakers from around the world came to Sea World Resort to share their knowledge in all things Ruby-related — technical and non-technical. There were five elective workshops that were offered on the first day being Developer Flow, Go, Trailblazer, Rails Girls and Rails Girls Next. As Vi attended the conference and Sarah attended a workshop separately, this blog post will be split in two parts. The first highlighting the main talking points from the various talks, whilst the second will be a description of Rails Girls Next, a workshop that follows from Rails Girls. Each section represents our own personal views and experiences.
5 Take Aways from the Talks by Vi Nguyen
Though Ruby Conf was a technology conference, for me, it really brought home the idea that what enhances technology is the human element, and that code really is just an expression of that.
Takeaway #1 — Want to go from newbie to expert coder? Read code & fill in your learning gaps.
Saron Yitbarek’s talk “Reading Code Good” shared eight guidelines on how a person could go from newbie to expert code. One hour every Sunday, Saron would read code with a few mates and from this social learning she tried new things that then prompted questions, research and interaction with the code. The digression from what was known and what wasn’t known was where most of her learning happened. Importantly, by learning together, it filled a gap in that self-learning to code can be excruciatingly lonely and overwhelming, but, when done together, it’s not so scary.
Takeaway #2 — Your ruby gem does more than just distribute libraries, you can use local ruby gems to better structure your large rails app.
In Enrico Teotti’s talk, I learned that ruby gems could be used locally to better manage very large applications (previously, I just used remote ruby gems so I could avoid writing code from scratch). Instead of generating new scaffolds and classes within one big app, local ruby gems could be used to create a dependency structure. What this means is that a local ruby gem would contain everything that has your first feature in it and when you get new functionality, you extract shared functionality to another gem. What you then get is a view of the application in chunks => reduced cognitive overload => more manageable application.
If you are interested in the technical implementation of using local ruby gems, watch Enrico’s talk.
Takeaway #3 — Empathy makes you a better developer because your feature implementations are likely to be closer to what the user wants.
Ernie Miller’s talk was about empathy as a building block for humane development. Humane development has at its core a simple and obvious belief that humans work with other humans to build software and this software is subsequently, used by humans. Because of this, it’s important to cultivate empathy (i.e. how to speak the thoughts and feelings of someone who isn’t you). Empathy makes you a better developer because you’ll have a better sense of why you’re building something and why it’s important. Your perception goes from “What would I want if I were them?” to “What would make them smile?”. Programming is about building things and according to Miller, “If you’re empathizing well, you’ll build something people love”.
Below is a picture of Ernie and I — don’t forget to check out his awesome t-shirt!
Ernie Miller at Ruby Conf Au 2016 (Photo: Vi Nguyen).
Takeaway #4 — Event sourcing as an alternative to using the CRUD accepted actions of “update or destroy”
The talk by Sebastian von Conrad questioned whether data should be destroyed or updated at all. This was really useful to me because sometime in late 2015, my developer installed the paranoia gem because I wasn’t comfortable with deleting data that was associated with say, a user account. When a rails app destroys or updates data using Active Record, the original data is lost. Is it right to lose data? Well…something that might not be useful now may be useful later. In the case of organizations that rely on user generated content, like Wikipedia, destroying data could create huge problems - imagine what would happen if a user were to be able to delete their account and have their associated contributions deleted aswell…
Sebastian talked about Event Sourcing which ensures that all changes to the application state are stored as a sequence of events - kind of like an accounting system so that nothing is deleted but rather a balance is kept of all that’s happened. With event sourcing you can query events and use logs to go back to a past state. That’s pretty neat!
If you’re interested in event sourcing, you can watch Sebastian’s talk here.
Takeaway #5 — Programming is an expression. Read what’s out there and look at style guides but also, find your own voice.
As idioms exist in language, programming languages are not excluded. Arne’s talk was about burning your idiomatic ruby. While idiomatic language sounds natural and requires less mental processing, according to Arne, “treating idiom as normative hampers innovation”. For example, what would happen if a new language got ported into Ruby? In such cases, we shouldn’t be rigid in the way we approach programming. Idiomatic doesn’t necessarily always equal good. Programming is expression and there are style guides out there that you can reference, but it’s also important to find your own expression.
While not a ‘takeaway’, it’s also worth mentioning for those interested in business or who are operating their own business, that Jeff Casimir’s talk shared some great business gems (pun intended). Mila Dymnikova’s visual notes on this highlight the main points from his talk perfectly. A big thank you to Mila for allowing me to share her notes on this blog.
Ace notes on Jeff Casimir's talk by Mila Dymnikova (Notes and Photo: Mila Dymnikova).
So that’s a wrap! If you wish to see the full set of talks, they’re online here. But, before I go, this is an Australian conference right? So I’ll leave you with a collage of party pictures and the obligatory Aussie animal pictures.
1. From left to right: my roomie, Indah who is a front-end dev, Jo who is lead developer at Culture Amp and I at the opening party (Photo: Vi Nguyen).
2. A cutie pie koala, just because (Photo: Thomas (originally posted to Flickr as Koala Bear) CC BY 2.0, via Wikimedia Commons).
3. From right to left: Timmy from BuildKite, Indah and I at the opening party. We forgot our logo tees (Photo: Vi Nguyen).
4. A surprise breakfast for the speakers and volunteers at Sea World Resort — we had breakfast next to dolphins (Photo: Freibuis).
5. From left to right: Lauren and Jo, both Ruby Australia committee members at the closing party at Movie World (Photo: Vi Nguyen).
6. An octopus, my favourite animal. This is a blue-ringed octopus that you can find in Australia. If you see it, get away from it quickly. One of the few things that can kill you in Australia, other than crocodiles, poisonous spiders, snakes etc… (Photo: Elias Levy (Blue-Ringed Octopus) CC BY 2.0, via Wikimedia Commons).
7. From left to right: Allison and I. Allison was a speaker and her talk was about remote working (Photo: Vi Nguyen).
8. Batman and I. He said I looked lovely… but then I heard him say that to all the other girls (Photo: Indah).
This was written by Sorcha and is a very excellent step-by-step guide we followed to understand how each file works in Rails. It’s very easy to follow and quite self-explanatory.
Caution: I learnt that Sinatra is NOT structured like how files in Rails would.
For instance, Routing in Sinatra is controlled in the controller, whereas Routing in Rails is in a separate routes file.
I then deployed the app to heroku. A couple of us in the workshop were having a problem with getting the app to deploy (Error: Application not found).
Here’s the solution: Since Sinatra is structured slightly differently from Rails, you’ll need to modify config.ru since gems and classes are located in config/application.rb
Configuration set up of Sinatra in Rails (Photo: Sarah Ni).
Big thanks to Sorcha, Rachelle and Daphne for teaching us the tiny details of MVC and Routes.
Sarah and the conference
At first glance, this probably doesn’t make sense.
In short, I actually had to make a quick trip up to Sydney (fun fact: it’s a 1.5 hour-long flight) to attend an awards ceremony. I’m humbled to have been nominated by GradConnection as one of the Top 100 students in Australia, 2016.
In closing…
Thank you to the team at Rails Girls Summer of Code and Ruby Conference Australia for giving both of us the opportunity to attend Ruby Conf Au 2016. It was fantastic and a great time was had by all!
