Google Summer of Code: Ex-Post thoughts

Ok, google’s SoC is ended, and I had some spare time to repair this blog which was broken for a while, so now you’re getting some random thoughts on it and on my work.

If you ever plan to try it in the next years you may find this useful, possibly.

Lessons Learned

• get a timeline, set milestones of what you should have done in a week or so, this prevents the bad feeling of not knowing how much you should do tomorrow and the fear of not having a chance to get stuff done in time.
• write tests, and really check that they are working, I lost a lot of time because I was testing against old installed rubygems instead of my work. Life just sucks, sometimes.
• if the main repository is unstable go away, in the first part of my SoC I tried to work with the main repository, which was under heavy refactoring. This meant that basic functionalities got broken and thus I should go around them. Try to find a stable repository, if you have good tests you should be able to port your code to the main code base (quite) easily once it gets stable again.
• stay in touch with other devs, the idea of SoC is to be part of a community, and that is always the best way to find help, answers, and moral support. I owe a beer to everyone in #nitro, possibly.
• KISS & YAGNI, ok, it should be obvious to anyone that these acronyms are important, but well, it is hard to really respect the principles.
• find a good mentor, mine was nice (fining out we both coose to learn AliceML this year was incredible :) but I’ve heard quite a bit of people that lost contact with her/him, and that made developing much harder.
• put out your code soon, set up a personal repository if you don’t want/can mess up with the main one, it makes easy for people/friends/mentors to review your code and get early warnings about it. Being shy about your code is a bad habit. Possibly this extends out into real life.
• get a good development platform, take time to setup it properly, and do investigate small problems about it ASAP, I lost a lot of time due to subtle differences in the DBMS backends for Og because some are unstable due to recent rewrite.
• make small steps, “writing a ui” is an extremely hard thing, “wrap errors in a div” is a 5 minute thing. If you use darcs try record‘ing after each small step.
• facets rocks, search stuff in it before you reinvent the wheel.
• never ever hide errors, if the framework does, change its behaviour as long as you work on it, you can make it safe (or utterly broken, depending on your point of view) again later. If I ever see “rescue Object” again I could start crying. (Luckily those are being completely removed).
• get some demo from the start, the Django tutorial was a great source to start hacking towards a meaningful objective for an admin ui, for example. This allows discovering corners that you may have not thought of in the beginning.
• avoid distractions, and I do not mean real life or eventual Anime video, I mean getting deep into solving completely off-topic issues just because they incidentally relate to some remote part of your work. Having an Array like [1,2,3,5] somewhere in your code does not mean you must rewrite the Prime class and investigate the Riemann Hypothesis.

Results wrt original Plan

• new gen infrastructure [ok]
• gen scaffolding [ok]
• gen administration [ok]
• proto code simplification [ok]
• order and choice of shown fields [ok]
• order and choice of shown classes [ok]
• input methods for complex fields [ko, only relations, need new control system for stuff like tags]
• choice of navigational UI [ok, easily reusable/hackable breadcrumbs & menu helpers]
• AJAXish stuff [ko, needs more work]
• per-part settings [ok]
• various scaffolding settings [ok]
• online configuration [ok]

Various added stuff

• tests
• automagic methods allows usage of default to_s, to_href and to_edit_href with Og managed objects.
• helper to build a table of objects
• helper to show a single object in table view
• helper to show errors in meaningful xhtml
• NavigationHelper
• gen/part allows easy importing of an existing part into a new project
• automagic search key allows searching objects through an attribute by setting a single setting
• yaml export of the dbms
• customizable table links (could have more settings for tables though)
• proto split
• SystemPage element allows easy hacking of the admin view
• stylesheet (please do help, I’m very bad at css design)
• attribute_to_html
• visual feedback on successfull creation and errors with better handling of errors (i.e. data are kept in the form)
• some og and nitro fixes
• merged 30+ patch from devlab repository into main one, plus conflict handling
• some ui reworking, new view.xhtml, search.xhtml, admin/index and other.
• the great two-line header :)

Conclusions

This was uber cool, I wish I had more time back in july, but well, my last exam was something like 27 of that month. Obviously I plan to keep work on the administration part, the code needs more refactoring and I’m thinking of at least three new settings (multiple-attribute search key a-la streamlined, non-tabular view for objects and breadcrumbish title helper), plus I need more tests.

If you want to take a peek at what I’ve don you can look at the temporary video available here , which shows a part of the available features. Please do not consider this a permanent link, I could remove it as soon as I have another video showing more stuff.

Thanks

To google for organizing the Summer of Code, to RubyCentral for choosing me, to Bryan for being my mentor, to George for Nitro and Tom for facets, to everyone in #nitro, #ruby-it, #ruby-lang and #verbamanent for uncountable help and fun.