Readings on Agile Development process

Since our group is still in the switch period between submitting our final commits and picking a new ticket to start working on for the last few weeks of classes, I’ve switched gears and have focused mainly on the new reading assignment and presentation.

Although I’m not nearly done with the book I’ve been given, a few take away points to the Agile development process…

-Focus on incremental development process, as opposed to the Waterfall methodology

-Often used in tandem with Scrum, to section and plan works in “sprint” periods

-Focus on the development process as opposed to heavy documentation, although still important, not a main objective

-Falls apart at the seams if the development team is not heavily experienced.

Of course, a much longer and more in depth analysis of Agile will need to be done, but all in due time. 

Intermission: Wrapping up our work with Trunk-248

As the group finishes work on Trunk-248 we plan to do submit our commit to the Open MRS core as it has been established all we were required to do was replace any //TODO junit  comments with the correct //@should annotations so that the MRS team can use their build in plug-in to find and help implement the correct JUnit testing. 

All and all, and even after some confusion on the matter, we only found a couple handfuls that needed to be replaced.  Since the group is now quite familiar with JUnit, we are planning to find another ticket regarding the same matter. Most likely a follow-up ticket regarding the actual implementation of the JUnit testings at our @should annotations.  Thanks to several sources, we have a few guides and readings on how to go about doing this, as well as reference material on how exactly to accomplish them, such as Vogella’s Guide.

However, despite our plans to move on to our next ticket, that does not mean we are entirely completed with our Trunk-248 ticket.  After submission, our code and changes must go through a series of (hopefully) brief review.  Should whomever choose that we need to reiterate our group commit, then we must go back and make necessary changes, putting a temporary hold on our next Ticket.  Not to say that we are in limbo, but with a final commit about to happen, we don’t have enough work to do on this current ticket unless something went horribly amiss. 

Digging through to place more @Should JUnits…

It appears that now most of the @TODO junit testings have been found in the sections of code we have dug through, although the group  believes there are still plenty more to find in areas we haven’t quite searched through.  There is some vague parameters with TRUNK-238 such as how far do we need to go with the JUnit testing?  Do we simply need to go through the entirety of the code and find all the @TODO’s or even more so, do we have to specify and begin implemntation of the JUnit tests? 

I was under the assumption that we only need to locate the @TODO’s and replace them with the @SHOULD JUnit test comments so that the other tickets regarding implementation of the JUnit testing would then have and know what to implement.  We will have to have another group meeting shortly through IRC and contact Ben Wolfe on the matter, since he is the guy who created then reopened the ticket for us.

 

Much more work to do, although it seems we are getting closer to finalizing the initial job of adding the JUnit comments in where they need to be.

More work with JUnit testing

After reading through some more segments of code that needed JUnit testing, I had to again re-read up on JUnit testing to make sure my comments were accurate.  Our ticket is an ongoing process of finding out where specific JUnit tests need to happen, and more or less mark where with code.  However, I realized about halfway through that I was marking them incorrectly, and had to go back and correct my statements I had made.  I could only imagine the headache of the second part of this ticket (which is actually implementing the JUnits tests) just to realize the comments put in place were asking to test the wrong things.  Nothing beats doing the same work twice because of lack of understanding.  Also, on that note, I need to find a better way to scan through all the files in eclipse to find those //TODO JUnits

Also, besides reading up again on JUnits (and here) to more understand how they work and the correct format of them, I also read up on this article (OpenMRS starter guide, provided by Prof. Wurst) to more familiarize myself with OpenMRS and more specifically the tutorials regarding GIT. More group updates to come as we continue to scan through the code and add appropriate comments.

Quick Update, Trunk-248

Well, after a bit of confusion and attempted contact with Ben Wolfe, our ticket has reopened and Dhimitris has successfully reclaimed it.
Work this week has started up again, digging through the code and searching for locations where new JUnit testing needs to be accomplished.   Due to the nature of this ticket, ongoing work has been completed since 2008, so there are many chunks of code from the OpenMRScore that either already have fully functional JUnit tests implemented or comments describing what type of JUnit tests need to be done.

As of now, all three of us got back up to speed, reforked the code and got the latest version of Maven installed through the Eclipse marketplace. Still trying to figure out how to divvy up the workload between ourselves and what parts of the code to assign and report on with the CS-401 wiki page.

More updates soon as we get back to scanning through the code…

Ticket Close Confusion, Junit Annotations

Well, to start things off after getting both my laptop and computer at home all setup working with github, my first goal was to read up and become much more familiar with JUnit.  The Ticket my group is working (TRUNK-248) requires us to go through the selected sections of code and simply add “@should” annotations where they were required.  A relatively simple task of reading through code to allow other users to scan through and identify where JUnit tests need to happen.

Just for a brief explanation on what JUnit testing is, it is essentially a small chunk of code to ensure that another chunk of code operates and functions as intended. More specifically, there are several types of tests, all using assert statements such as “assertTrue([message], boolean condition)”, “assertSame([String], expected, actual)” and the like. 

To actually perform these tests, JUnit must be downloaded and ran with a java text editor such as Ecplise.  While eclipse may not be essential to performing or coding these tests, Ecplise does contain several built in tools to perform JUnit testing — which makes everything a lot more convenient. 

However,  due to some confusion regarding this ticket, it has been deemed as closed.  The ticket’s Status is still labeled as “In Progress” and an Resolution of “unresolved”.  Having known this, we as a group would not have chosen to work on it in the first place.  A new ticket will have to be found and worked on asap as to not get behind on work.  The good news is, it still gave us an excuse to look through the code, which is something.

More Snow and Working with Git

Lack of sleep and from plowing means unsaved blog posts.  But the show must go on…

Looking through countless introductory tickets for something that is both challenging and interesting without being over the top is not easy, but I found a couple of good ones.  All the while the couple of git exercises got me a little bit more up and running and familiar with GitHub.  I’ve also taken the time to “properly” get my main rig worked up for a good developing environment to code with in the upcoming weeks. 

With tickets selected and git now being more familiar, coding, debugging and documenting is going to rev up.  The “introductory” videos for git were nice, but I feel like it was over simplified.  I’m going to inevitably have to make a table of git commands and tape it to my desk so I don’t forget them.  But other than that, solid introduction and basics of what Git can do. 

Week Two, more ways to help than just programming

So, it appears that I’ve been under the false assumption that my only way to contribute to a large project, regardless of corporate or open source, was through straight programming.  How fortunate I am that I’ve been wrong.

I’ve never considered myself an ‘ace programmer’ by any means, and I have more than one not so fond memories of staring at pages of code wondering why it won’t work.  This has lead to a more favored past time of coding, debugging.  Generating code for me is often slow, and tedious.  While the pseudo-code can flow easily, actual implementation takes a bit more work and requires even more headaches.  But, once I get the general code going, debugging it for errors and making it run a bit more efficient seems to be something I can do, rather easily; especially when its belongs to someone else.  Perhaps that is what I should be setting my sights on, improving how well I can debug code, as it appears to be just another valuable facet of coding.

In a somewhat related event, the class I am working with on the OpenMRS project has been introduce to yet another invaluable tool, IRC chat.  Nothing can help you become familiar with a new program then spending a couple hours straight working with it and communicating with your peers.  Reminds me a little bit of MSN messenger or AOL back in my youth, but now with actual purpose.

First Week, CS-401

Well then, the OpenMRS is certainly a very large and interesting project to say the least.  But with such a large and ongoing effort to provide an Open Source EMR database one is immediately struck with the question.  “What could (what I consider) a novice programmer possibly contribute to such a large ongoing effort?”  The upcoming few months will certainly answer that question without doubt.  As for the time being, I am very excited to be working (soon) be working and contributing to the OpenMRS community.

My expectations of this course are already set quite high, with the hopes of simply becoming a much more savvy programmer.  My only regeret is not being introduced to such sources as GitHub and exposure to other open source projects sooner, but that cannot be helped at this point in time. On that topic, over the Eric S. Raymond’s article The Cathedral and the Bazaar have also opened me up to the raw potential  — and how powerful open source communities can be.  Maybe my current inexperience will still be of good use to the OpenMRS project after all.