juliaguar/rgsoc_conclusion

## rgsoc_conclusion
When Autumn comes, it means the summer is over, so we can say with it the Rails Girls Summer of Code.
But things must be closed and one of the best ways to do it, is to share the experience, so we will try to do that.
First we will explain the context in which we participated, how it developed and with whom and things that were great and the ones that can be improved.

The context was a bit exceptional, Rails Girls Summer of Code, an initiavive that was more or less improvised after one of the Rails Girls workshops, all the positive energy received during those workshops and the great feedback from the women made it possible.
**The set up that we had,
  Project that we selected: Diaspora - free social network
  Do pair programing - TeamD-github
  Have a coach
  Have another coach to understand the sysadmin insides of D*
  Have 3 online D* developers

**Our previous background was
  Some basic programming skills in Rails, Ruby, Javascript, Git
  No idea of how D* worked, the project in itself motivated us, though we had no previous knowledge

Before the RGSoC started we did not have much time to actually define or organize what or how we wanted to learn, how to focus the three months, so we just kind of did it on the way.

**We started chekcking the D* github repository and found out that D* is a huuuugeeee project, so that maybe it was not the best idea to select such a project as the first approach to an open source project but it was the one we liked most, so ...

After trying to understand a bit the project, reading the wiki, the structure, the developers workflow, we decided that the "easiest" way to understand it would be to put hands on it. So we went to the pending issues, and just selected the easiest that we found or the one we understood more :)
We've done this issues 4274 (error messages vanishes too fast).
Doing the issues meant being familiar with git, creating our Team-D shared repository, to know D* git conventions and workflow, just to manage git took us a bit.

D* developers can be found in the IRC, and are really friendly and helped a lot since the beginning, probably that was one of the reasons why we did not drop down from the project. Every question was perfectly answer an there have been a lot of them!!

At some point we decided to try to do an issue that would mean to develop something not just fix it, to be able to "start from scratch"
So we went into federation issues. D* till now had the federation code integrated with the rest of the code, but now it has been separated into a gem, to make it easier to use and clearer to understand. To figure out how to implement federation from an outside app,
first we started just with tests, some TDD with cucumber to test the features that needed to be tested, we managed to get familiar with cucumber. Then to continue testing federation we decided to start a sinatra app from scratch, a very simple one, that basically did the same things as the tests.

With federation things got more complicated, we needed not only to understand the Rails code, but how is federation working in D*, several protocols that have to do it (Hostmeta, webfinger, hcard), how encryption works, to separate layers, SSL, Salmon, RSA-keys
and how all this layers interact. There were many failures on our way. We needed to have access to a real server to be able to access the logs, which we could do by working together with Christophe from wk3.org
 At the end of the three months we manage to test federation partially but not everything so we still have pending work to do, for that we set up, our own D* server, so that we can continue with it.

**The things that were good, the ones that can be improved

Lets start with the good ones, we found an amazing team to work with.
We met every week with our coach, which has meant to be able to keep going when we were stuck, to learn approaches to how to solve things when you are stuck, etc.

We also met many times with D*-coach, which gave us the possibility to see the "other side" of the code, that is when a software comes into production then other elements appear, storage, speed...

And we were in contact everyday with D*- developers, which made possible to actually do something, and be able to have two pull request accepted, since they showed exactly how to address the problem, how to implemented, which specific thing could be the one that was giving us headaches.

The interaction with people with different insights into the same project is great, because being able to approach problems from different perspectives it always enriches the learning.

Being in a big project like D* involves many things, such as dealing with chaos, deciding where to go and look, asking for help, reading the documentation and being aware of how important is to have one!!! As well as being in contact with different frameworks and approaches (backbone, rails, handling translations, haml, SASS...), following conventions in order that chaos is not too big. Last but not least it involves interacting with others who started doing the same thing that you planed to do.

Also not everything is coding, a community driven project as D*, shows how decisions are made, the tools that are used, how threads develops. As well as other kind of issues as how to deal with communication, finances (or the lack of them), etc. In summary, to understand that a free software projects has many dimensions.

But things always can be improved

On one hand, maybe as a first approach to an open source project, to choose one as big as D* is not the best idea (though it worked very well for us), to be able to go forward with it means that many people are involved, as was in our case.
The coaching sessions, they were good because we were able to work on the things that kept us stuck, but probably to have a deeper learning of how to program would have been better to summ other things, like we did at the end, by just setting up a problem and solving it with TDD. Probably to do a proper app from scratch, where to implement the TDD ..so a combination of coding in a real open source project and in parallel learning best practices.


Acknowledgements

very special thanks to Markus XXX, Christophe XXX, MrZXy, Fla, Raven and of course Rails Girls initiative for making it possible.
	When Autumn comes, it means the summer is over, so we can say with it the Rails Girls Summer of Code.
	But things must be closed and one of the best ways to do it, is to share the experience, so we will try to do that.
	First we will explain the context in which we participated, how it developed and with whom and things that were great and the ones that can be improved.

	The context was a bit exceptional, Rails Girls Summer of Code, an initiavive that was more or less improvised after one of the Rails Girls workshops, all the positive energy received during those workshops and the great feedback from the women made it possible.
	**The set up that we had,
	Project that we selected: Diaspora - free social network
	Do pair programing - TeamD-github
	Have a coach
	Have another coach to understand the sysadmin insides of D*
	Have 3 online D* developers

	**Our previous background was
	Some basic programming skills in Rails, Ruby, Javascript, Git
	No idea of how D* worked, the project in itself motivated us, though we had no previous knowledge

	Before the RGSoC started we did not have much time to actually define or organize what or how we wanted to learn, how to focus the three months, so we just kind of did it on the way.

	*We started chekcking the D github repository and found out that D* is a huuuugeeee project, so that maybe it was not the best idea to select such a project as the first approach to an open source project but it was the one we liked most, so ...

	After trying to understand a bit the project, reading the wiki, the structure, the developers workflow, we decided that the "easiest" way to understand it would be to put hands on it. So we went to the pending issues, and just selected the easiest that we found or the one we understood more :)
	We've done this issues 4274 (error messages vanishes too fast).
	Doing the issues meant being familiar with git, creating our Team-D shared repository, to know D* git conventions and workflow, just to manage git took us a bit.

	D* developers can be found in the IRC, and are really friendly and helped a lot since the beginning, probably that was one of the reasons why we did not drop down from the project. Every question was perfectly answer an there have been a lot of them!!

	At some point we decided to try to do an issue that would mean to develop something not just fix it, to be able to "start from scratch"
	So we went into federation issues. D* till now had the federation code integrated with the rest of the code, but now it has been separated into a gem, to make it easier to use and clearer to understand. To figure out how to implement federation from an outside app,
	first we started just with tests, some TDD with cucumber to test the features that needed to be tested, we managed to get familiar with cucumber. Then to continue testing federation we decided to start a sinatra app from scratch, a very simple one, that basically did the same things as the tests.

	With federation things got more complicated, we needed not only to understand the Rails code, but how is federation working in D*, several protocols that have to do it (Hostmeta, webfinger, hcard), how encryption works, to separate layers, SSL, Salmon, RSA-keys
	and how all this layers interact. There were many failures on our way. We needed to have access to a real server to be able to access the logs, which we could do by working together with Christophe from wk3.org
	At the end of the three months we manage to test federation partially but not everything so we still have pending work to do, for that we set up, our own D* server, so that we can continue with it.

	**The things that were good, the ones that can be improved

	Lets start with the good ones, we found an amazing team to work with.
	We met every week with our coach, which has meant to be able to keep going when we were stuck, to learn approaches to how to solve things when you are stuck, etc.

	We also met many times with D*-coach, which gave us the possibility to see the "other side" of the code, that is when a software comes into production then other elements appear, storage, speed...

	And we were in contact everyday with D*- developers, which made possible to actually do something, and be able to have two pull request accepted, since they showed exactly how to address the problem, how to implemented, which specific thing could be the one that was giving us headaches.

	The interaction with people with different insights into the same project is great, because being able to approach problems from different perspectives it always enriches the learning.

	Being in a big project like D* involves many things, such as dealing with chaos, deciding where to go and look, asking for help, reading the documentation and being aware of how important is to have one!!! As well as being in contact with different frameworks and approaches (backbone, rails, handling translations, haml, SASS...), following conventions in order that chaos is not too big. Last but not least it involves interacting with others who started doing the same thing that you planed to do.

	Also not everything is coding, a community driven project as D*, shows how decisions are made, the tools that are used, how threads develops. As well as other kind of issues as how to deal with communication, finances (or the lack of them), etc. In summary, to understand that a free software projects has many dimensions.

	But things always can be improved

	On one hand, maybe as a first approach to an open source project, to choose one as big as D* is not the best idea (though it worked very well for us), to be able to go forward with it means that many people are involved, as was in our case.
	The coaching sessions, they were good because we were able to work on the things that kept us stuck, but probably to have a deeper learning of how to program would have been better to summ other things, like we did at the end, by just setting up a problem and solving it with TDD. Probably to do a proper app from scratch, where to implement the TDD ..so a combination of coding in a real open source project and in parallel learning best practices.


	Acknowledgements

	very special thanks to Markus XXX, Christophe XXX, MrZXy, Fla, Raven and of course Rails Girls initiative for making it possible.