Google Summer of Code was a wonderful experience for me, I’ll never forget it. I finished my project and that makes me feel great. Getting opinions and feedback from the Open Source community was really special. In general, this is what I learned:
Improved my communication skills: Doing a project that involves other people means that you have to be clear in your words, be brief but efficient, and most important, make people understand what you are trying to say.
I wrote a lot in English. (My project, IRC meetings, asking in the list, answering questions, etc). Although, English is not my first language I enjoyed having to be clear with my mentor, the OSVDB (Open Sourced Vulnerability Database) developers and the Google group of summer of coders.
Ruby and Ruby on Rails: This Ruby user’s guide helped me a lot. I haven’t finished it, but I learned a lot about this great language (regular expressions, strings, arrays, iterators, control structures, OOP, classes, methods). And I also do a lot of programing with the ruby on rails framework. I learned how to manage and modified some plugins.
Actually, working with views is not my favorite part of a project. However, CSS work at the end of the project was really fun. What CSS makes is impressive.
Solr: I never ever have worked with a search server. Solr is just amazing – Fulltext search capabilities. I learned how to integrate Solr and the act_as_solr plugin to my Rails application.
Subversion: I learned how to work with this collaboration tool which I consider makes you more productive. However, I had to deal with so many error messages. I need to learn more commands apart from the common ones.
Vulnerability and Patch concepts.
I believe that being an expert in these fields takes his time. I never did a security system and didn’t work with a security team before. But I learned key concepts related to patches and vulnerabilities that helped me a lot to write the code. For example:
- Vulns classification: Location, Attack Type , Impact, Solution, Exploits.
- Vulns technical description and how to test a vulnerability.
- Patch severity: Critical, Severe,important, Minor, Pointless.
- Security Products: Nikto, Snort and Nessus.
- What CVE means.
- How to associate a vuln-patch with a Vendor/Product/Version.
Many lessons learned in these months let me think what I did wrong and what I did well. I feel that I’m not always as productive as I might like to, my effort changes with the tasks I’m doing.
Once I read some Linus interview in which he said that if you are completely present in a situation and totally focused on something then that something *becomes* interesting, whatever it may be.
So, I think that making your job interesting and fun and get really focused on the problem are the keys to your project success.
Thanks for your visit to the blog. You can follow me on Twitter: Follow @ronnyml