WEEK 7 [12th July – 18th July]

 

This week involved me continuing my work on the REST API. After another call with my mentor we were able to organize our efforts and finally come up with How the resource will work. This week also involved me cleaning up the restApi Code So that it could be finally merged. It is finally at the end and the code will be merged my today or tomorrow. With that I can start my work on the UI Fragments. I have already recognized the dependencies that will be needed.
The REST Resource will support searching by :-
1) objectType and objectUuid
2)objectType and tagName

WEEK 6 [5th July – 11th July]

In the Design call held on the 5th of July, a discussion was held on the way forward regarding the Generic-Tagging-Mechanism Project. It was decided that instead of working on Angular directives, the first step would be to add this mechanism to the clinician facing patient dashboard. The plan is to create a fragment in the tagging module and to provide an extension point to the secondColumnFragment in the clinician facing patient dashboard :-

Apart from that several changes were decided for the Rest Resource. I added searching capability by 3 parameters objectType, objectUuid, and tagName. Depending on which parameters are provided a List of tags will be returned. I also started cleaning up the Rest Api code according to the Code Review. The representation was also modified.

For full representation
GET .../v1/tag?tag=my-favorites?v=full

[

{
“uuid”: “uuid-of-tag-object”,
“tag”: “my-favorites”,
“objectType”: “patient”,
“objectUuid”: “…/patient/uuid-of-tagged-patient”,
“auditInfo”: “”
},
{
“uuid”: “uuid-of-tag-object”,
“tag”: “my-favorites-of-all”,
“objectType”: “concept”,
“objectUuid”: “…/patient/uuid-of-tagged-concept”,
“auditInfo”: “”
}
]

WEEK 5 [28th June – 04th July]

The best part of this week, was to know that i had managed to pass the 1st evaluations. 1/3rd period of the time allotted was over, and i am glad that i have been able to adhere to the timeline. A lot of changes have been made to the original time-line. Adding Rest resources to expose the module and working on Angular directives, was something that was planned on later, since we felt that an AngularJs directive would be more useful than a UI fragment. There was just one teeny tiny problem , I had no experience with AngularJs.
This however made the project even more interesting. I for one love the learning curves involved in projects, and the challenges that come with it. With this in mind, I invested my time in understanding AngularJs with focus on directives.

What we aim on achieving is to have an angular directive that one can include on a form for an OpenmrsObject that allows a user to view/add/remove tags. They would take in the following arguments:

viewOnly (boolean): Specifies if the user can only view or can view and also add/remove tags
objectUuid (String): The uuid of the OpenmrsObject
objectType (String): The fully qualified java class name of the domain object

Some good sources for AngularJs:-
https://docs.angularjs.org/tutorial ( for basics)
https://docs.angularjs.org/guide (developers guide)

WEEK 4 [21st June – 27th June]

The start of week 4 meant the completion of the Java API, which was finally merged into the main repository. It all marked the completion of my Phase – 1 task, a few days ahead of schedule. The next task involves exposing the module via the REST API.
This required some feedback from the community. We had decided on creating a Rest Resource :- TagResource, that returns Tag Objects. However there was still a discussion required around creating a seperate resource which returns OpenMRS Objects. The problem was that not all Users have the privelige to view all OpenMRS Objects. A workaround this would be to create a new privelige which allows one to view all OpenMRS Objects returned by the REST API.

Apart from this, this week tasks involved :-
1)Adding Webservices.rest dependencies.
2) Adding a new TagResource class, which overrides basic save, delete , get methods.
3)Creating a corresponding REST controller if required.
4)Creating Unit Tests to test the Rest Api’s working.

The first task above all other was to understand how REST works. REST stands for Representational State Transfer. And a REST API is an API that adheres to the principles of REST and does not require the client to know anything about the structure of the API. Rather, the server needs to provide whatever information the client needs to interact with the service. It basically uses URL’s to perform a fixed set of operations { GET, PUT, POST, DELETE}.

WEEK 3 [14th June – 20th June]

Week 3 involved making final changes in the API and finally pushing the work to the main module. After my mentor reviewed my work, he suggested many changes to make the module follow OpenMRS conventions. A few methods were also changed.
List getTags(List types, List tags, boolean matchAllTags) method was broken down into two methods :-

List getTags(List types, List tags) :- which returns a list of tag objects having one of the types and one of the tags

List getObjectWithAllTags(List types, List tags) :- which returns a list of OpenmrsObjects having one of the types and all the tags.

The return types of a few methods were also changed. Unit tests and proper java documentation was added. Other than that, my mentor (Wyclif Luyima) and I discussed the way forward. For the UI part my mentor suggested that apart from UI fragments we also work on Angular Js directives. For this our first step will we exposing the module to REST services.
I don’t have much experience with Rest Services, but I am learning as I go. For now I have made a PR for the API setup, and have started working on the Rest Services in a new branch.

I am using the wiki pages : Rest Services Module , Rest Services Core and already existing OpenMRS Code as reference as I continue forward.

WEEK-2 [07th June – 14th June]

For the 2nd week the first task was to solve the blocker from last time. I was finally able to solve it by switching to an XML based configuration. With this the module was finally setup., and my Mentor reviewed my code.
I spent the first few days of this week reading up on hibernate search with lucene. I had a call with my mentor to discuss the way forward, and he advised that we should first focus on the application logic. After a long discussion we narrowed down the tasks for 2nd week.
The 2nd week tasks included working on the tagging API, which involved the following :-

->Adding methods to the service layer, –
Tag getTagByUuid(String uuid)
Tag saveTag(Tag tag)
void purgeTag(Tag tag)
Tag getTagById(int id)
List getTagByName(String tag)
List getAllTags()
The above methods are all general methods.
void addTag(OpenmrsObject openmrsObject, String tag)
For the above method several checks have to be placed, such as a warning needs to be logged if someone wants to place a duplicate tag on the same object.

List getTags(OpenmrsObject openmrsObject)
List getTags(List types, List tags, boolean matchAllTags);
The above method is if someone wants to make a query like :- “get all tags of object_type “X” or “Y” which have “tag1” and “tag2″ (if matchAllTags = true)”, or “get all tags of object_type “X” or “Y” which have “tag1” or “tag2” (if matchAllTags=false)

My task ensues writing all relevant method implementations and their database interactions along with adding unit tests for testing purpose.

->Adding Validation Logic, by adding a class tag validator. It checks whether the tag being added passes the following checks:-
tag name should not be empty.
object should have a uuid, and it should exist in the openmrs database. This can be checked by the following method:-
boolean objectExits(String object_uuid, String object_type)

->Adding a Privilege “Manage Tags”.

->Making changes to the database. Adding 2 new columns, and creating indexes on “tag” and “object_type”.

REPO: – https://github.com/jtatia/openmrs-module-tag

WEEK -1 [30th May – 6th June]

For the first week of the coding period, I worked on setting up a module for the Generic tagging Mechanism project. I was travelling between the 30th and 2nd so, i officially began coding on the 2nd. I worked on creating the module, with core code in a module approach in mind. It basically refers to the fact, that the java packaging should be similar to that of the core.
My mentor is very helpful and quick to answer my doubts. I had a meeting with him on the 30th to confirm some important points before i begin to code.

Initially :-
1) I used the OpenMRS SDK to create the skeleton of a Reference Application Module.
2)I modified the packaging of the Api to resemble that of the core project.
3)I started setting up the initial outline.
Worked on the object Tag (used JPA annotations so that the mapping files wont be needed)
Wrote the liquibase changeset to create a table tag.
Connected the service layer with the DAO layer.
Worked on the bean configuration in the moduleApplicationContext file.
Added a TestingApplicationContext file and a dataset for testing.

Currently I am trying to test the hibernate connection, but seem to be facing some problem with the bean configurations since I don’t have much experience with it. Hopefully I will be able to resolve the problems by today with the help of my mentor. For now, other than this error, everything else is going according to schedule.
REPO: https://github.com/jtatia/openmrs-module-tag

Community Bonding Period

Community bonding period ended on May 30th. This gave us time to get to know our organization and project better.
Communicating with the organization has been a wonderful and enriching experience. I have been a part of the organization since December 2016, and have got a good understanding of how it operates.
I used this time to interact with other GSOC participants, and to understand openmrs code better, so that it will be easier to contribute during the coding period.
I was also able to have my first meeting with my mentor. It was very fruitful, since we were able to make important discussions regarding the design of the project.

The project I’ll be working on is called “Generic Tagging Mechanism” Project.
The aim of this is to provide a mechanism that allows users to annotate domain objects with simple text labels/tags for better management of domain objects. These “tags” can be useful in various ways e.g to group data and generating work queues. Thus the goal of this project is to create a generic tagging mechanism where any kind of domain object can be tagged with multiple labels, and these labels can easily be managed/searched later.

Objectives
To create an api for tagging any domain object
to create ui fragments which can be included in any page for creation of tags.
To create a searching mechanism with various filters for searching through tags.

Looking forward to great experience with gsoc@openmrs 😀

Google Summer Of Code

This was long overdue .. 

Participating in GSOC had always been in my todo list. I had known about it for quite some time and had begun looking for organizations as early as August. As suggested by ex GSOC’ers, I spent a good amount of time in selecting an organization. Selecting a good organization for oneself is very important, because there is a good chance you will continue with the org way after you are done with GSOC.

For selecting a good orgainsation, i made an excel sheet, listing down all past organisations that had been consistently selected in gsoc, based on the field of interest and the community. Within this, for me OpenMRS with its motto to

“Write Code, Save lives”  

was a clear winner. Most of OpenMRS code is written in JAVA, which was the language i wanted to work in.

The best part of OpenMRS, is however its systematic management and its very friendly community. There were people on the IRC who spent a lot of time, helping me get setup with the environment like dkayiwa, and the Google code-in students.

Once I was introduced to OpenMRS, my focus shifted from getting into GSOC, to contribute meaningfully in anyway possible. I have been a part of the organization for more than 6 months, and have made code contributions, helped people on the IRC chat server, and lead SCRUM meetings. Contributing to OpenMRS is probably the most meaningful thing that I do, and I am greatful for OpenMRS for having given me this opportunity to work with Wyclif Luyima and Burke Mamlin on the Generic Tagging Mechanism Project.

Looking forward to a great summer with GSOC at OpenMRS

 

CMS

Its a wrap people !! With the successful submission of our Innovation Lab Project, I thought I would go ahead and write a little about it.

Course management system is a Java based platform which provides an interface for professors and students to interact on course related topics and also provides a staging area where all assignments can be uploaded by faculties subject-wise. Students can then download the assignments and submit their solutions thus allowing faculties to check the solutions and score them.

However the main feature of CMS is :-

• Automated process of testing programming assignments submitted by students.
• The software automatically tests all files and displays the marks and status.
• Log files containing build logs of each file can easily be downloaded.
• Marks and error status of all assignments can be downloaded in .csv format
• Uploading the correct output program will automatically create output text files against the input given.
• Language support for java, C, C++, and python2 programs.
• Source code structured in such a way that, it’s easy to add support to more languages.

Concepts And External Libraries Used

• Java Database Connectivity (JDBC) for accessing database using Java.
• Git for Version Control.
• MySQL for Database Management.
• Java Swing for Graphical User Interface.
• Jaysypt Library for supporting one-way strong password encryption.
• JSch – Java Secure Channel for reading, writing, uploading and downloading files from SSH server.
• SSHXcute and Ganymed for running commands on SSH.
• Javacsv for CSV Files support.
• JXSwing for providing some of the extra GUI Features

This project was done in a team of 4 members :- Abhijit Roy, Jai Tatia, Kshitij Jauhri, Shashwat Tiwari.

DEMO

Github Link : https://github.com/jtatia/Course-Management-System