[OpenMRS Developers Setup]
From the get go I was having installation troubles for the SDK. I followed the instructions located here: https://wiki.openmrs.org/display/docs/OpenMRS+SDK#OpenMRSSDK-StepByStep
I first tried to get it successfully installed on my laptop to no avail. I installed Java 188.8.131.52 JDK fine along with the JRE. I installed the OpenMRS installer for Windows version 1.0.6 fine. Below is the code snippet from my cmd window:
OMRS Version: “1.0.5”
OMRS Home: C:\Program Files (x86)\omrssdk-1.0.6
ORMS Scripts: C:\Program Files (x86)\omrssdk-1.0.6\bin
OMRS Maven Home: C:\Program Files (x86)\omrssdk-1.0.6\apache-maven
Executing: “C:\Program Files (x86)\omrssdk-1.0.6\apache-maven\bin\mvn.bat” –ver
Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-27 22:15:3
Maven home: C:\Program Files (x86)\omrssdk-1.0.6\apache-maven\bin\..
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
Default locale: en_US, platform encoding: Cp1252
OS name: “windows 8”, version: “6.2”, arch: “x86”, family: “windows”
After I knew I had the correct JDK and OMRS version installed correctly, I tried to create the module. It went through its downloads of files and came up with no errors after I left all default values. No matter what I tried at this point, I could not get the command “omrs-run” to see the configuration. I was sure I forked the correct project to GitHub correctly and I verified with other students but we could not figure out why it was not working.
Duplicating the whole process again on my desktop yielded the same results. I will have to investigate further as to why the module/configuration is not being seen and update upon further info.
This week’s learning on editing the Wiki page was actually very helpful and easy to pick up on. I can see why wikis are being more and more common for compiling information or for use as knowledge bases. I began by going to to the CS wiki and logging into my account. I wrote a brief description about me and then added a link to this page under the Students page. Editing in a wiki was incredibly easy to do and straight forward and I had no problem with it.
The Issue Tracker Activity was also very informative on how to use formatting and editing for a wiki. As I proceeded through the activity, I learned from the few mistakes I made in formatting so my responses were easier to read, but in the end I got the hang of it.
[Issue Tracker Activity/Three Issues]
Viewing the info on the OpenMRS Issue Tracker was also sorted out very well and made it easy to read and follow how tickets and bugs were logged. The filters make sense on how one would want to search for a particular type of issue. I was able to easily find all of the necessary field and type information, but I did have trouble at first finding the summary of the project. I was looking for a description or paragraph summary but did not realize it was right on the front page shown with data.
After perusing the list on all the tickets at a glance, I ended up choosing three according to my comfort level (programming level as well as overall knowledge of the project so far). I couldn’t think of any other ways the system might have been improved upon, but there certainly are ways. To me as an outsider to the core of the project, it seemed to suffice very well for giving someone cursory information.
[Git Videos and Tutorials]
Following the Git tutorial was very useful and gave me a tool that I can come back to in case I need to remember certain commands without having to look them up without example uses. I completed it after about 10-15 minutes, but I still had some general confusion about what the syntax for some of the commands were (I do not feel at all comfortable operating in a Linux/Unix environment, even after my classes here at WSU). As they came up in the example terminal, I did somewhat look up what they meant but did not come up with anything really concrete as a definition or further examples of how to use them.
The Git videos were also a good reference to go alongside with while watching on my desktop and following along on my laptop. I have never used GitHub before this class (unfortunate we are learning it so late) so a further explanation with maps and diagrams was helpful. One thing I did notice though was that even though these were tutorial videos on using Git and what it is, it still was not as detailed as I would have wanted it to be for some areas.
The IRC activity that we did in class was awkward to say the least. For starters, before going into further detail, I did not know people still used IRC in today’s age of the internet. It seems that it is extremely dated and only suited for some of the “hardcore” or old-school crowd that are stuck in the old ways. After downloading a few clients (experimenting with some proved to be more difficult or hard to navigate) I landed on one that was recommended to me by Brian Gibson — HexChat. After setting up the initial server and identity for myself, I connected pretty easily.
The whole conversation that took place afterwards was silently done inside the IRC. It gave me a first glimpse of how to use it and to speak my thoughts clearly via an online forum. The in-class lack of speaking was a little weird, but the exercise was meant to show us how to use it in case we could not meet for class. All in all, I think it was valuable even though I thought the method of doing online meetings was a little dated.
The readings for this week were a good statement to me personally as to how I could contribute more to the project. I do not believe I have anything much higher than an average programming level, nor do I have extensive knowledge into other languages and tools other than what I’ve used during my major progress at WSU. So joining this open source project seemed a little daunting. I did like to see that there were tons of other ways to contribute (I’m more keen to the documentation and bug tracking part). Some of the examples I could tell were a little “out there” in terms of how they were actually going to help, but I can see the end result of it all.
Reading about the bug tracking methods and etiquette was not 100% new information, seeing as I have worked in an environment before where bugs were coming up from clients and we were helping resolve them. For a programming aspect, though, it is applicable in almost the same way. I think the OpenMRS bug tracking feature is well developed (it has to be at the scale it is at this point) and should be easy to pick up on as bug tracking becomes part of the assignment.
This is my first blog post ever. Huzzah.
[What do I expect?]
Entering into my last semester at WSU, I expected my capstone class to be heavily interwoven with the knowledge gained from the other CS courses up to this point. Using all skills and techniques of software design and analysis and my average level of coding, I believe it is going to be a hard but valuable 16 weeks. I think it’s taken too long for us to learn about GitHub, something that should be taught to us very early on so we are masters at using it as the years build up. It’s unfortunate that I am only just beginning to know how to use one of the biggest platforms for version control and I head out into the real world in a couple of months. The same goes for IRC. Having heard about and generally knowing what IRC is for years, I’ve never had a reason to use it so I never bothered with it. Not having the class time to go over it was a shame, but I think I’ll be able to figure it out.
After reading through the articles, it doesn’t exactly add to anything I didn’t already have a grasp on as far as the ideas go for free and open source software. The quote from The Cathedral article, “Too often software developers spend their days grinding away for pay at programs they neither need nor love”, pretty much describes how I feel for a future of software programming.
Free software, as defined by the other articles, was pretty strict in cases where it defined certain things not free, but I guess it has to be in order to promote the truest form of open source software. I think overall it’s a nice premise and cause worth promoting, but in the end it just results in things like where we are with Linux (dozens of distro’s, i.e.). Open source projects should more be used for promoting concepts and ideas as ways to teach people to code better. Grabbing source code to investigate what certain things do and see the inside of the program is a good learning tool, but developing and tweaking each aspect of it and releasing it to the public convolutes everything.
The entire GitHub activity was confusing and too “hardcore” from what I experienced. The whole manual process of doing it via command line was simply done in a matter of a few minutes with the GUI version. I think in this day and age, to say that you “aren’t a real programmer if you use a GUI/mouse” is too harsh of a constraint that people try to abide by in this field. It’s 2014. There are UI’s to make people’s lives easier and actions simpler, and we should use them. I was able to get up and running using the GUI GitHub install (not the 3rd party site download) and I think it represents it pretty well.
I have not done anything other than download an IRC client (HydraIRC: http://www.hydrairc.com/content/downloads) so I am not sure how much I can comment on this. Hopefully we can use it more in depth in the next coming class meetings.