Do you remember we announced conferences which support RGSoC 2017 and grant us free tickets? Some more awesome conferences joined the party in the past two weeks. There are two newcomers among them: Dev Day from Sri Lanka and Sheffield Ruby User Group, which is technically not a conference, but nonetheless has a hand in our conference activities this year :)
And even more good news: two RGSoC teams (NK42 and 200OK) will give talks at Codemotion Berlin 2017! Honestly, we are very proud of our students <3
Dear organizers, thank you so much for sharing our values and being with us! We are very grateful for this.
Date: October 12-13, 2017 Location: Berlin, Germany Twitter: @codemoberlin
Interested in attending this conference too? Contact us for getting 15% discount promo code.
Wow, it’s 23th September already and we just can’t believe that RGSoC is coming to an end. It has been a whirlwind of a summer - with so much learning both in our professional lives and personal. We will sorely miss the daily logs, catching up with each other, the superbly motivating coaching sessions, pair programming, code reviews and weekly sync ups with Mayar, who is the best supervisor team buddy we could have hoped for.
The Star of the moment - our project ‘coala’
We have already introduced our project, coala, a code analysis tool, in our first blog post.
Through the course of the summer, we were at complete liberty to choose which aspect of this vast project we wanted to work on. As the bonding period drew to a close and as the summer began, we gradually made small, but steady advances into understanding the codebase. We were ramped up to developers in the coala community.
Lights, Camera, Code
Our project was writing generic bears for coala. Bears are Python scripts which help you check for bad coding practices, styles etc. in different languages.
There are two types of bears :
- Native Bears
- Linter Bears
Linter bears are Python wrappers around existing code linting tools available in other languages, to integrate them into coala, using the coala API. To top it all, the coala docs also provides a comprehensive bear writing guide, which ensured that we could write bears smoothly.
In our second week, we started writing our first linter bears and as the summer draws to a close, we have already worked on several bears including:
RubyFlogBear - Flog is a Ruby gem which performs complexity analysis on Ruby code using the ABC metrics. It is one of the most popularly used tools for measuring Ruby code complexity, or a measure of the amount of ‘pain’ the code is in, in an easy to read ‘torture’ report. RubyFlogBear wraps this gem and integrates it into coala.
HAMLLintBear which wraps around a tool haml-lint that helps keep HAML files clean and readable. This bear is made super-configurable, implementing all the possible flags and functionalities of haml-lint.
OclintBear a static code tool for improving quality and reducing defects by inspecting C, C++ and Objective-C code and looking for potential problems like possible bugs, unused code, code smells and bad practices
SpotBugsBear which statically looks for potential bugs in Java code.
In addition, we also worked on five other bear related issues for different coala projects such as coala-quickstart, and corobo. Apart from this, as per the common coala community practise, we have persistently performed code reviews and helped out new developers to the community, just like we were helped out by others at the beginning of this summer.
Image Credits: Prachi, with the help of Canva
Cue Takeaways
Pair Programming RGSoC introduced us to concept of pair programming that works by establishing a mentoring mechanism and spreading knowledge through the team. The constant iterations of writing code and getting it reviewed by the other person ensure that you not only write and send in quality code, but also debug it efficiently. Pair programming, for us, has ensured better designs, higher quality, bug-free code and more functionality per unit time in the long term perspective.
Code Reviews Our project coala stresses heavily on code reviews. The practice of reading the comments others left on our PRs and reviewing others in exchange has helped us learn so much. Not only, have we learned to debug code written by others, we can also now reason why a certain functionality needs to be designed in a particular way.
Test Driven Development The best practice is to write tests as you go. The developer who writes the development code is the best person for writing the testing suite. Ensure maximum code coverage. Keep in mind the 80–20 rule of code coverage (20% of time will be spent in achieving 80% code coverage and 80% of time will be spent in achieving the remaining 20%) And lastly, Manual testing of code is important after automated testing is complete. There is no substitute for peer review and feedback.
You can learn more about our takeaways at our fortnightly blogs: Prachi and Ipshita
The Final Act
This might be the final act, but for Team 200 OK, the show will go on. Our talk at Codemotion Berlin 2017 has been accepted. We’ll be speaking about RGSoC, the program, our experience, our project coala and the work we did during the summer. It’s a dream come true for us!
We plan to continue contributing to coala, finish up our open PRs and take up more challenging issues. We will also explore other open source organizations to work for. We are also extremely motivated to encourage other women to take up open source.
It has been a wonderful summer. But, it isn’t over yet.
This post contains songs we recommend listening to whilst reading - we felt that this incredible summer needed an incredible soundtrack to tell its story
We have had an incredible summer: it has been insanely busy and at times overwhelming, but we have both grown enormously as developers and team members. Rails Girls Summer of Code was one of the best decisions we have ever made, and it’s been a pleasure to be part of this superb and inspirational community. Being part of Rails Girls Summer of Code is an incredible opportunity, and it has been a transformative summer for us.
We started the summer enthusiastically, wanting to contribute substantively to Babel. We felt like we needed to take this opportunity to become passionate open source developers.
Rails Girls Summer of Code taught us a lot about the importance of communication, and perseverance. We have received generous support from the Babel community; nonetheless it was disquieting to be joining an open source community where we couldn’t find any other female members.
(Song Credit): Madonna, What It Feels like for a Girl (via YouTube)
It took us about two months to even approach the non Summer of Code channel in the Babel slack. It’s a nerve-wracking experience jumping in and talking to a community of such impressive developers, but as the saying goes: be the change in the world you want to see.
Rails Girls Summer of Code has given us the confidence to be present in the Open Source Community. Our superb Babel mentor Henry Zhu, has been an incredibly positive, kind, and insightful mentor; we’ve been lucky to have him help us and guide us.
As mentioned in our first blog post, our aims of the summer were to a) learn a heck of a lot, and b) improve our pingpong skills. Whilst the latter took a complete tumble, the former fuelled our summer and our learning took us in directions we had not envisioned. Whilst we may never be Olympic Ping Pong-ers, we feel like we spent our summer in a far more productive and positive manner, and we honestly feel like we’re leaving here knowing that this is only the beginning for us.
(Song Credit): Queen, Don't Stop Me Now (via YouTube)
As well as working on Babel, we had the opportunity to learn so much more from the Pivots surrounding us. Our Pivotal mentors taught us Pivotal best practices regarding software development and were generous in answering our questions and in running additional mentoring sessions and talks to share their knowledge. We are so lucky to have had sessions on a range of topics including:
Introduction to Operational Semantics (and LaTex)
Compilers
Containers
Testing (TDD, unit testing, and integration testing)
Bash Scripting
Project Management Practices
Debugging Skills
Agile Practices
Networking 101
History of JS and its Frameworks/Libraries
Git
Managing Dependencies
Pairing
We had all of these learning experiences thanks to Pivotal, and to our incredible coaches from Pivotal. We have received an immense amount of knowledge. Whilst we gushed about the breakfast in our first blog post (and it IS an incredible breakfast), the one thing we will always remember is how kind and patient our coaches were with us, and how passionate about teaching and mentoring they all were.
We could not have completed this summer without our supportive and friendly supervisor Ines. Ines has been the biggest supporter we could have hoped for, and she has proven time and time again to be there for us. Our weekly meetings were an absolute joy, and we could not have imagined a nicer person or a better supervisor to communicate our struggles, issues and passions with. She made us realise our goals, and our pitfalls, and helped guide us through moments in the summer where it was incredibly difficult. Ines is the heroine for our Summer. She has been the third musketeer in our group; the third member in our Destiny’s Child.
(Song Credit): Destiny's Child, Independent Women (via YouTube)
This summer, we have both grown and evolved and have learnt about being software developers and team members. Our communication skills have improved tenfold, and we have a better understanding of what it means to be involved in technology teams. We have experienced our own pitfalls, and we had our own barriers, which took awhile to get our heads around (we’re looking at you, pair programming), but it was all part of the crucial learning curve. Whilst there were times we felt we would never work through our issues (-cough- Git -cough-), we have, however, learnt an awful lot about what is needed to try. Rebase. Always rebase when in doubt. And make Bootstrap.
(Song Credit): The Beatles, We Can Work it Out (via YouTube)
We admit we did not complete as much work with Babel as we had hoped. But that’s okay. We fulfilled our major goal for the summer - to learn and obtain as much knowledge as we could. Contributing to Babel was always an ambitious program for us, and we always knew it would be something that was hard.
We certainly have had an eventful and memorable summer. One of the biggest (and hardest) achievements of the summer was presenting both Rails Girls Summer of Code and some of our code to the Pivotal Community. We had not expected to be presenting about the program, but it was such a pleasure to promote such a wonderful organisation.
What we learnt, overall, was that there is still so much more that we can do and that is needed to do to get women into Open Source. We both had an incredible summer, and we are so sad to see it come to a close, but we won’t stop working and helping in this community.
THANK YOU RAILS GIRLS SUMMER OF CODE, PIVOTAL AND BABEL!! ❤️ 🎊 🎉
You are the true stars of our summer, and you are continuously changing the world. Thank you for letting us be a part of this narrative for three months :)
Well, we’re both going to continue to contribute to Open Source. Kara is motivated and inspired to continue contributing to Babel. And we both plan on regularly contributing to other open source projects. We’re hoping to talk about Rails Girls Summer of Code to everyone and anyone that will listen to us, and maybe - just maybe - improve our ping pong skills :)
No matter if the issue is big or small, complicated or simple, a bug or a feature - in our Summer of Code the issues have a similar cycle. Team “Code Bears” has some important lessons to share after two and a half months of working on diaspora*.
Pick out the issue
What do we want to achieve? What would we like to learn? Do we want to use skills we already learned or learn something new? Would we actually see the results of our work? We try to ask ourselves all those questions when we approach the long list of issues of diaspora*. Naturally at first we got a lot of direction from our coaches and mentor on this step, but as the summer progressed we had stronger opinions on those questions ourselves.
For instance, the more back-end the better. We just love our RoR programming! Of course we also love it when we learn and understand front-end code, but it’s very clear that we both are more attracted to the back-end side.
Ask the diaspora* community
Diaspora* has a very active community and we had to find out for each issue we chose if it was still available. We got great feedback from the community just by asking about it on the issue page. In some cases it even triggered a long discussion about ways to solve the issue or even the very necessity of a solution. The community is very responsive whenever we have questions or require consultation on our solution. You just gotta love the diaspora* community for their involvement and investment.
Search. Everywhere.
Like two Alices in diasporaland, with every issue we embark on an ongoing quest through the intricate and entangled maze called the diaspora source code. It is not your typical MVC app (if that even really exists). Finding the related files to the issue and trying to understand the relationship between them is no less than a superpower one needs to develop.
Apart from the familiar models, controllers and views, we have encountered, and thereby learned about, lots of other types of files: mailers, presenters, helpers, services, workers, templates, javascript files, specs, factories and more.
In order to understand all the new terms we learn, we spend quite a lot of time watching and reading tutorials (We find Lynda, among others, to be an excellent source for beginners tutorials). Overwhelmed by all this new theory, our coaches are very helpful with mediating and explaining new and complicated concepts.
Get confused
Connecting theory and practice always resulted in a big confusion. Things on diaspora almost never work according to theory. At first we have an idea of which code to change, which turns out to be wrong and raises an error in some file we don’t know about. This, in turn, leads us back to our diasporaland quest, where we don’t understand the code, or we find a bunch of new terms, or we can’t figure out why this file even exists, and so on.
The most common sentence called out loud during this summer, by students and coaches alike, while looking at the code is: “This is weird”.
Puzzled, with no other choice, we play with the code and see what happens. It became easier to experiment, once we realized we can’t really ruin anything, as long as we work on our local branch.
This trial and error process, combined with a pinch of the theoretical understanding we acquire and alongside coaching sessions, leads us to write code in one file, change code in another, delete code in a third file and refactor code in a fourth one. We made a habit out of checking things in the terminal, rails console and the browser console, inspecting the page and using a debugger.
This is usually when we make our progress with the issue: typing on our keyboards, while feeling clueless, but seeing stuff happening on our screen - BEST. FEELING. EVER! We are quite sure that after the summer the other engineers in our workspace will really miss the squeaking sounds we make when we get something to work.
The git dance
When we think our code is ready, it’s time to open the PR and break out in our git dance. We have a kind of a complicated git setup, with two remote repositories and two local ones, as well as git-flow which requires re-basing and squashing commits. It took us a while to understand what we are doing and dare to push code by ourselves. Common mishaps include, but not limited to, git reset --hard, mysterious branch diversions, merge conflicts and the occasional “mind f***” moment. It was hard to keep our HEAD in the right place.
Therefore, during the first half of SoC, we had a very helpful weekly git session with one of the coaches. Although we still sometime struggle with git, we now have our own git dance and can handle it quite independently.
Obviously every PR resulted with some corrections and suggestions to improve our code. The beauty of the code review is that it always comes with explanations! We learn a lot just from everyone’s comments. Again, you just gotta love the diaspora* community that understands our state (beginners), reviews our code accordingly and helps us with the fixes.
Eat ice cream
while celebrating merged PR.
What did the story of an issue teach us so far?
Here are some lessons, big and small, we’ve learned from this roller coaster called SoC:
Know your study materials: Find your favorite source for study materials: whether you like to watch, read or practice, whether you prefer it on-line or hard-copy, it is very efficient to have a go-to learning sources.
Mix and match: Using diverse ways of learning, which means a combination of watching, reading, exercising and working on the source code, is the most useful way to tackle new topics. It might seem obvious, but it’s still an important lesson for us.
Master git: Pretty self explanatory, but we can’t stress enough how helpful it was to understand our git-flow.
Keep a notebook: Use the traditional pen and paper to keep track of new terms and concepts, which at first glimpse could be quite overwhelming and even intimidating. It’s also a great place to sketch and doodle.
Try not to be afraid to make mistakes, play with your code, express your opinions and make your own decisions. After 10 weeks of working regularly with 6 coaches, each one with their own way of solving problems, we realized the only thing we have left to do is decide which way works best for us.
Try not to be shy and ask for help and explanations. Experience shows it often works for the best.
Learn from your code reviews: See “Code review” above :).
We are in love with diaspora*: The complexity of the code and the involvement of the community have made this summer very challenging and rewarding. Check the project on github, maybe you would want to contribute as well.
Remember to celebrate: Did you open a PR, did your code get merged, did you just finish refactoring a beautiful piece of code? Great! Celebrate and go eat some ice cream.
Thanks
This amazing summer would not be amazing without our team and the help of other supportive people:
Our team’s coaches: Chiara, Dani, David, Glauber, Jano and Laura, thank you so much for all you help, time, energy, patience, white-board sessions, source-code sessions, exercises and so much more.
Other coaches: Alon, Andrey, Liron and Remi for helping on specific topics and substituting for coaches on vacation.
Our supervisor: Fanny, thank you for caring for our well-being throughout the summer and always being there for questions.
Our mentor: Lisa, thanks for your availability for questions and tips about diaspora*.
Diaspora community: Thank you for being so responsive and helpful, and for keeping such a pleasant communication with your contributers. Special thanks for members who reviewed patiently and commented on our code- Flaburgan, SuperTux88 and svbergerem.
Our coaching company: thank you SoundCloud for hosting us and suppling us with a brilliant learning and working atmosphere, as well as amazing coffee.
Our third month with the RGSoC is already coming to an end, even though it seems like we’ve just started. We are happy to be a part of such an incredible program that attracts people to open source, and gives them an opportunity to work on important projects and to make a difference.
What tasks we had?
We worked on a social network for Persian LGBTQI+ community – JoopeA Club. It is a safe space for people of any gender and/or sexual orientation. We were trying to make it a safe space for speakers of any language, because right now JClub is only available in Persian, and we were building support for other languages.
What we learned
Django
Vcs: Mercurial, some Git
About databases
Time management
To compromise
Challenges we faced
The most difficult part for us was planning our tasks, and then sticking to our plans. It seemed like the obvious thing to take care of, but most of the tasks took more time than we planned for them. We tried to listen to our coach Katya’s advise and to plan 3x more time than seemed right to us for each task, and sometimes it even worked, but sometimes even that amount of time wasn’t enough. But we think we’ve got better with planning by the end of the summer, so we would probably call it a progress.
What we did
For all this time we have added many features to the site:
Add language model
Add language to the language-depended entities: users, pages, posts and communities
Users can choose language on registration form
Users can update their language through settings
Did our own middleware for language dynamically changing
Added many dependencies based on the language status
In addition to working on the project, we had a lot of different fun activities.
For example, Sasha’s hair evolution in one month:
Sasha's hair. Photo taken by other Sasha.
We also have attended many meetings of the local Python community (and other programming communities).
Sasha at the meetup. Photo taken by Mail.ru photographer.
Sasha took a picture of the other Sasha while she was eating we were working on our project at @Google.
We want to say thanks to our dream team
Thank you, our coaches Katya and Ildar, for being there for us whenever we needed help with Django or just moral support. Thanks to Maria, our supervisor, who helped us getting through this summer without troubles of any kind with RGSoC or with our team. And, of course, we would like to thank our mentor Raham for giving us this opportunity to work on the project and for helping us throughout the summer.
And we’d like to thank each other for being awesome teammates and friends to each other. :)
What next?
We still have a lot things and features on the site to do, so we would like to continue contributing to the repository after RGSoC ends.
We’re happy and proud of our work this summer, and we feel more confident in programming world now. We’re both convinced that coding will be the right career choice for us, and we’re thankful for the opportunity to prove ourselves as coders.
