Over the summer I’ve learned a lot participating in GSOC. Now that the program is over, I’m finally ready to start being a mentor.

Here are a couple of things that I learned:

1. Get involved early – provide unlimited feedback on proposals

Get on IRC as much as possible, especially early on. Get to know the students. Tell the students that email you to come on IRC. Start teaching them about the domain, about the product, about the technology stack. Treat every student like they are already in the program. Indeed, a student’s willingness to socialize can be an indicator of integration with the community.

Customize the proposal template – make it your own. Add what you need – UI Mockups, requirements, evaluation framework, project plan. Try doing all your requirements analysis with the students during the application phase. Have students send you their proposal a week early and use it as a tool to teach …  tell them where more detail is needed.

It was surprising how many students just submitted a boiler plate application. I rejected these immediately. To be shortlisted the application had to include at least a paragraph about the specific project (even if it was regurgitated from the project description).

2. Set aside time every day for the project

Technology, time zones, language, school, and work schedules made status meetings difficult early in the summer.

At the midterm evaluation point, we started checking in daily on irc Monday-Saturday. During the 1/2 hour of daily check-in my student had complete access to me. It was a time that I could make the project the focus of my attention. I believe that this communicated to the student that people are interested in the project … that the work is important. When I made it a priority the student responded in the same way.

–

Obviously, this is not everything I learned. I grew a great deal during my participation but some of it was personal growth. I feel far more prepared now to be a mentor than I was at the onset of the program. Perhaps I will be invited to participate again next year.

Just finished the last week of GSOC officially.  I have included the extra 3 days between Friday and the final gsoc date (16th) in this update and hence it has been a long week! I can’t belive the time has gone past so quickly.  I have learned a lot over the last 12 weeks and had fun doing so.  I would like to thank my mentor Ben Wolfe for his support and to the OpenMRS community for adopting myself and fellow students.  I would also like to thank Google for providing this opportunity.  It has been a great summer!

Things don’t end here though.  I will still be posting here with updates on the progress of my OpenMRS related work as well as any other development projects I might feel the need to add.

Here is the lowdown of the week past:

Monday – Further refactorings that led me to hitting what felt like a brick wall. Had to refactor back. (See Tuesday).

Tuesday – After renaming methods in RDT module last week to comply with openmrs standards for dao method names (from putXXX to saveXXX) I discovered a bug in openmrs core. After getting feedback from the dev list I created a ticket about this problem here:  http://tickets.openmrs.org/browse/TRUNK-1661

Wednesday – Laid down the ground work to being able to integrate Remote Form Entry module with Remote Data Transfer. After a lengthy discussion with Ben Wolfe about the intricacies involving mapping RFE locations to RDT serverIds I am not in a better position to proceed. The solution involves adding an extra column to RDT’s Server table. I created a new branch of RFE and have began integrating (configuration, listener’s, etc), and also amended RDT appropriately. It seemed to me to be a little late in the day to begin such a hefty job but I could think of anything else to do that would take me right up to the GSOC pencils down date (16th). The RFE integration was marked as “extra credit” on my GSOC expectations but nevertheless would be great to finish by the 16th, but if it doesn’t happen by then I will work on it until it is finished outside of GSOC. I have already finished the other “extra credit” item which involved allowing binary files to be transferred (this was originally described as dropping a file into a folder in the operating system for transfer, but we agreed to change this to be implemented through the web UI).

Thursday – Attended the OpenMRS dev call. Installed Apache Maven: OpenMRS is moving to a Maven organised build. Discussed more details with Ben about RFE integration. It is necessary for RFE to be able to add/modify existing RDT queue items so when the nightly return data from RFE is generated it can override any previously queued data if it hasn’t been sent yet.

Friday – Continued to work on integration. Implemented new API functions in RDT followed by providing a means for RFE to add items straight to the queue with correct destination taken from Openmrs Location to RDT ServerId mapping. Made RFE generate return data automatically send this data through RDT (i.e. put it in the queue for sending later).

Saturday – Implemented lazy loading of binary data property of receieved and queue items. This was necessary to improve performance when dealing with large files. Hibernate supports this feature through byecode instrumentation using the javassist api. Implemented support for transfers from central to remote in RFE via RDT.

Sunday – Implemented support for transfers from remote to central in RFE via RDT.

Monday – Added finishing touches to the RFE Integration with RDT branch. Wrote documentation on the conversion which is available here:  http://openmrs.org/wiki/Talk:Remote_FormEntry_User_Guide

Outcome - Took on a lot this week in trying to convert RFE to use RDT.  I ended up with a working version which I am happy but nevertheless will probably need modifcation in the future after feedback from implementators/testers has been given.  Remote Data Transfer is in a fit state now and I feel it is ready for an initially alpha release.  All in all I have completed all of the tasks listed on my GSOC work plan including those marked as “Extra credit”.

This week
This is my last status post in the course of GSoC. But the spirit goes on.. let’s see what I’ve done during this week:

• I implemented a very basic concept viewer
• I wrote some more queries to support more search criteria
• I added more Javadoc to the source code
• I wrote a manual for the search as mentioned in the previous post
• I added autocomplete functionality to advanced and basic search

I had no problems this week, because it is semester break and I had plenty of time to research solutions to problems.

Next week
As said above GSoC 2010 has come to an end. It was a very great opportunity which I’ll never forget.
But this is not the end for my project, I will continue working on it and improve it until it is a really great module.

But now it’s time for me to relax, see you soon! I will surely write another post about my experiences at GSoC and OpenMRS!

Hey,
I wrote a short manual for the advanced concept search in the enhanced concept search module. It can be found here: Manual

This week
The end of GSoC is near, that’s why I’m trying to finish the first version of my module. Let’s see what I’ve done this week:

• I wrote more methods for my DAO to become independent from OpenMRS’ ConceptService
• I added some functionality to the advanced search page (concept used as answer?)
• I made some updates to the basic search
• I started working on a concept view page

I didn’t experience much problems this week. But I need haven’t found out how to check if a concept is used as a question is forms, I’ll research that next week.

Next week
Next week will be the last week of Google Summer of Code, but nevertheless I will continue working on my project, because I really like it
I plan to get a very basic version of the concept viewer done and some smaller improvements to release a stable version at the end of next week.

I’ve always hated to scroll through long lists when trying to find the thing I’m looking for. Computer interfaces which are designed as long list and give you a hard time to look through all of the things without a filter is definitely bad design. But even with a text field filter, long lists take a lot of time to load... The two applications that I’m working with these days, OpenMRS and DHIS2, both have these long lists that in my opinion are a pain to use.

The DHIS2 uses lists for data elements, indicators, users and these are not divided into pages. There is a text filter, but the time it takes to load the page when the list is long is excruciating. One of the recent examples, where we had over 5000 users in DHIS2 Punjab mobile application, it was excruciatingly slow to load that list of users. And then finding through that list to change anything is also quite slow and painful.

Similarly in OpenMRS, one of the things I often use for our modules is the global properties. Modules can use the global properties infrastructure to store options and it is a quick solution when you want to store some settings that can be configured by the user for your module. But as the number of modules or the number of options in a module increases, it becomes a pain to search the exact option from that long list of options. It also does not have a text filter, but you can always use the browser search to reach what you are looking for and text filters, don’t really solve much. Infact, may be the text filter in your application does not have a shortcut, while Ctrl+F would quickly give you a browser search text field.

Nevertheless, a quick hack by our developer Viet Nguyen (the JavaScript Ninja), was an OpenMRS module called moduleoptions. This is his first module, just to understand the OpenMRS framework and to me is quite a useful thing. It divides the global properties in tabs and makes the properties more manageable in my opinion. It provides better management to the long list of global properties and looks more convenient to use. It was developed in a few hours time and is definitely something that I would want to see as default when managing global properties. Below is a screenshot of how the global properties looks now:

At the stage where I am doing more writing up and tidying up than coding.  Some self explanatory activities this week, basically stuff that had to be done.

Monday – Started writing documentation for the module.

Tuesday – Continued work on documenting the module. Began work on implementing data validation for user input.  Finished documentation is here.

Wednesday – After experimenting with various validation frameworks and techniques, decided that they were overkill for this module in it’s present form and used simple manual validation.

Thursday – Added/tidied up javadoc for all classes in the module.  Attended the OpenMRS dev call.

Friday – Addressed the items left over from Ben Wolfe’s code review that I had marked as “to come back to”. These were mainly renaming refactorings to preserve clarity. It is amazing how changing the names of certain properties can require manual editing of the same properties specified in unchecked code such as xml and sql statements.

Outcome - As the official coding end date of GSOC comes closer things are getting a bit queiter for me.  That is a good sign I guess because it means that I have completed the requirements of the project and I haven’t left things to the last minute.  I will try to work on the optional aim “integration with remote form entry module” next week.  It seems like the other module’s developers who were planning to integrate with Remote Data Transfer are planning to do so after GSOC.  It seems like this is just the start in that respect.  I am sure there will be many more releases after the initial release if RDT is to become a commonly used commonent of other modules.  Expect more!