Sidebar


flower_dev_center:tutorials:flower_dev_center_and_google_summer_of_code_2013

Flower Dev Center and Google Summer of Code 2013: The Article

:!: NOTE: We have a video version of this article, available here: Flower Dev Center and Google Summer of Code 2013: The Video. 5min 57 sec.

Introduction

Flower Dev Center helps students and mentors that participate to Google Summer of Code program. It improves communication and allows students and mentors to make better use of their time. And the overall result is better code.

Let's suppose I am a student, I work on a wiki software and I want to add a new feature: a special table of content (TOC).

For working on a new project, we propose the folowing flow:

0 – Investigations: understand the current technical context
1 – Think of a solution. Make diagrams (and code scaffolding)
2 – Discuss the solution with my mentor ⇒ feedback
3 – Discuss again with my mentor (initial feedback = processed)
4 – Coding
5 – Coding done ⇒ pull request and code review

0 – Investigations: understand the current technical context

First thing with a new project should be understanding what already exists. Depending on the project this can mean: studying the code, documentation, mailing list, debugging, studying bug list, discussion (e.g. IRC), etc.

1 – Think of a solution. Make diagrams (and code scaffolding)

After the investigations I put my ideas on diagrams that look like this:

(click image for full size)

Notice the colors, they have various meanings:

  • Red means items that I have added and that I will implement. These classes, attributes, methods are new.
  • Red also means modifications to existing classes. Eg. classes from core that I want to reuse but for which I need some slight modifications.
  • Black means code that exists, that I will reuse, and that I won't modify.

I worked on both code and model. I am not constrained to work only graphically, on the model.
Flower Development Center uses an advanced technology called CodeSync, which makes sure that the trips between code and model are seamless and friendly.

(click image for full size)

This was helpful, as I added, during the design phase, comments, snippets of code and pseudo-code that I will reuse during coding.

2 – Discuss the solution with my mentor => feedback

I have a first discussion with my mentor. As Flower Dev Center is web based, I give him a link, and he has my diagrams on his screen, and we begin to collaborate.
We use Skype or phone. He quickly understands my design.

(click image for full size)

Again notice the colors. In this case, the orange elements means that they were approved by the mentor.

My mentor adds his feedback directly on the diagram:

  • Minor details regarding attributes/functions visibility.
  • One of the remarks is about the clarity of the code. The mentor is right, that function should have been split and renamed according to its functionality.
  • And a bigger problem that escaped me. This global variable currentUser is not a good programming practice and is also not thread safe! And he pointed to me an existing function that I can use to get the current user.

3 – Discuss again with my mentor (initial feedback = processed)

I processed the feedback. I may have a new discussion (or I may skip this step), to validate the final design (i.e. including the feedback that I processed).

(click image for full size)

Here, the diagram is basically the same, but also contains the modifications my mentor asked.

  • I split the function.
  • I adjusted the visibility of the attributes.
  • And I got rid of the nasty, non-thread-safe global.

A minimal intervention from the mentor (i.e. our 5 min chat, collaborating directly on my proposed design) has helped me avoid some mistakes I would have done, and I'm not sure they would have been spotted right away.

4 – Coding

Now comes the coding part, using my favorite IDE.
I use the desktop plugin, powered by the same CodeSync technology, which keeps the code and the model synchronized.

(click image for full size)

Notice the colors. In this case blue means that the elements on the diagram are implemented. I mark them in blue, as I progress.

5 – Coding done => pull request and code review

I am finished and now I do a pull request (or submit my patch, so that it gets merged into the main dev branch).

My mentor will have to do a code review before integrating my changes. Let's suppose I modified 46 files; 19 of them from core. I think it will be a real “pleasure” to review them. 8-O

But Flower Development Center helps.

My mentor knows that the structure is clean, because we designed it together. Working in parallel on my diffs and with Flower Development Center, my mentor can easily be more thorough on things that are more important (e.g. remember that I modified code from the core?). He will probably pay more attention to that than to my .toString() implementation.

(click image for full size)

Notice the colors:

  • Green means elements that have passed review. My mentor marks them with green as he advances with the review.
  • But, wait. Did I said clean structure? Usually the devil stays in the details we discover during developing. Really bad things can happen, when apparently harmless variables, methods or dependencies, are added while coding. But they are highlighted in red, so that my mentor can pay particular attention to them. In this case, my modifications were OK.

Conclusion

So why was Flower Development Center helpful?

  • I was able to visually represent what I wanted to do. And it was quite fast. I had the flexibility to design working in parallel with diagram and code (thanks to CodeSync technology).
  • My discussions with the mentor, were very code and implementation related.
    • It took seconds for him to have my diagrams on his screen, and to collaborate on them.
    • It took little time for me to explain what I wanted to do. It took little time for my mentor to understand and to spot weak points in my design.
    • This way I have avoided mistakes I would have made, and I wrote better code.
  • The review of the code and the validation of the pull request was simpler to do. And if nasty things would have got into the design or code, they would have been easier to spot.
comments powered by Disqus
flower_dev_center/tutorials/flower_dev_center_and_google_summer_of_code_2013.txt · Last modified: 2013/05/15 12:35 by cristian