Sprint 5 Retrospective

As we enter the home stretch, the team has continued to make good progress on the project. It’s weird to think we only have four weeks or so left in the semester. It has flown by! The team continues to work well together and communication is never an issue. In fact, I’d say it is even one of our strengths. Even on days we don’t have class and we are at work and/or busy doing other things, team members are quick to respond to each other’s questions, put pull requests through, etc. Good communication is always vitally important to the success of a project, so it is great to see us excelling at this. I don’t have any pressing complaints or need-to-work-ons at this point. I think a lot of that stuff was hashed out earlier in the semester and if an issue comes up now, we are quick to address it mid-sprint rather than putting it off.

For sprint five, the team set out to further improve the rudimentary version of the offline login service that we created last sprint. We were able to make some progress towards this, although it still isn’t quite all the way there (it wasn’t expected to be all the way there this sprint). The other main goal of this sprint was to get Ampath’s approval for our plan to implement the offline login service. To do this, we reviewed and updated the high level designs I had created earlier as a team. I thought this was a very good exercise as it allowed for us to make sure that everyone is on the same page. We were able to present these designs to Ampath to ensure that we were going about this the correct way. They approved of the design without asking for any changes to be made to it, so we can press on with the implementation of the design with full confidence now. It was nice that we were able to get this approved because now we don’t have that lingering concern in the back of heads that we might have to scrap everything we had done.

Although those were the two main goals this sprint, we also got a bunch of other stuff done. We were able to make progress towards updating the GUI to give the user the option of storing the credentials offline rather than just doing it automatically. This is an important feature to have because we don’t want to be storing credentials for every single user that logins into the app. This is not only inefficient but, could also cause security problems. All of us were also able to do some research on subscription processing. This was done because another team is planning to use this.  George was able to fix the OnlineTrackerComponent bug and make a pull request to Ampath to fix this issue. Kudos to him for taking this on. It was a bug found mid sprint, so it could have waited until next sprint as we had already committed to a bunch of work, but he took it on anyhow. We were also able to document out new Git approach after there was a bit of hiccup this sprint (luckily, we were able to get it fixed). Several other minor tasks in addition to what I’ve mentioned were completed as well.

Next sprint is our last full sprint for the semester. I believe the plan is to continue to work on implementing the offline login service, however I think documentation of what we have done and what still needs to be done should also be a focus. This way both the Ampath folks and, should a team in next year’s capstone pick off where we left off, will be able to tell what progress/changes were made. It should make their lives’ significantly easier and prevent them from having to start from scratch.

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective: Capturing Patient Data

As Sprint 5 comes to a close, I believe we are making great progress. Our team’s primary goal is to have a completely functional data capturing service for offline purposes. With the achievements made during this sprint, it seems very realistic that we will have a working module by the end of this semester.

Our main objectives for Sprint 5 were the following:

1.  Decide what would be the most useful data to capture.
2.  Capture raw data to be stored into PouchDB.
3.  Construct ideas presenting captured data in a meaningful way.
4.  Improve cross-team communication.

Deciding what would be the most useful data to capture:
We all agreed that we should begin to focus on storing detailed patient data. Internet connectivity is often unreliable where the AMPATH app is intended on being used. We want to allow medical providers to have offline access to patient data when a given patient is expected to be seen.

Capturing raw data to be stored into PouchDB:
I believe we have made substantial progress concerning this task. We were able to use OpenMRS services (located in the ./src/app/openmrs-api folder) to help us achieve our intended goals.

Originally, we were able to capture data of some 200 patients having the word “test” in their names. This was a great starting point, but we knew we needed to improve upon our results. First, the data was being captured and stored into one large file. This contrasted with our intended capability of having each patient object being stored in its own file. Second, the data being captured was only basic patient information, such as name and address. We wanted to also include more detailed criteria, such as upcoming appointments and other patient encounters.

Initially we were using the PatientResourceService.searchPatient('test') function to capture a given array of patients. We were taking the results from the returned Observable and storing it into PouchDB. The problem we were having was figuring out a way to iterate through these results so we could store each patient in an individual file. Ultimately, we were able to achieve this by using the JavaScript lodash ability. By importing lodash in our component, we were able to use _.each to iterate through the subscribed results from the returned Observable in an array-like fashion. 

Our next step was to try to figure out a way to store patients other than those with “test” in their name. Further, we wanted to capture more meaningful information about the patient (appointments, encounters, etc).

Ultimately, we were able to manipulate an existing component, located in ./src/app/patient-dashboard/common/patient-encounters/patient-encounters.component.ts, to store a patient’s detailed data in PouchDB when it is searched for.

Presenting the captured data in a meaningful way:
This is a topic discussed in great detail during our last working class during Sprint 5. Ultimately we need to decide how we are going to present this to the user. We anticipate the user will be a provider, such as a doctor looking for information about patients to be seen. We are in the process of constructing a mock diagram for a GUI to view and manipulate the captured data.

Improving cross-team communication:
I feel we have made some progress in this area. We seem to have a general idea what everyone is working on. But at the same time, there is definitely room for improvement regarding our communication with other teams. We anticipate a lot of cross-team collaboration in the upcoming sprint. Since all teams are finishing up their work, we need to make sure all implementations are compatible with each other. For this reason, I am confident our cross-team communication will continue to improve during our next sprint.

Overall:
I believe this was an effective sprint. We’ve all done a good job letting each other know what we’re currently working on. I had a lot to do with implementing the offline capturing abilities, but this was only possible due to the support and input from all of my teammates. Regarding participation during this sprint, I think we’ve all done our fair share.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week I read the book Apprenticeship Patters guidance for the Aspiring Software Craftsman. There was this one section that caught my attention and it was the Concrete Skills. This was very interesting to me because it’s quote was “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. this is where craftsmanship comes in.” Growing up we are taught that you need all the knowledge you can to even be able to be considered for a job. Many people tell us that you need even a masters to be considered for a job these days anymore. However there was a professor I meet back when I first started  programming he told me he used to be the hiring manager for IBM and he meet hundred of different candidates that tried and applied for the job. The things he learned about hiring people is that not everyone is the same.  Yes there will be people who have the knowledge of programming and would pass all these tests and get everything right. However,  once it came to actual coding and work ethics they were very questionable. There are people who got out of college that have a different perspective. They say that  everything you learn in school isn’t going to be helpful in the real world. Most of the time you learn all your skills once you get a job where they teach you what skills you need. It is really all about if the job would take the risk and hire you. There are many stories that there are people who have basic knowledge of programming are hired because they have experience in other fields that can be used to help out the team in different ways because you don’t just want a team of programmers that know one language but a team that can cover each others weaknesses. That’s why I think that this sections is very good because it gives a real perspective of what companies should look for in a person not what they can do now but how will hiring them affect us in the future and the capability of these people in the future.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Problem

Those who do not learn from history are doomed to repeat it.

Solution

The solution the text offers is to keep a record of your journey in a journal, wiki, or blog. Having a chronological record of the lessons you’ve learned can help those you mentors you, it can also be a vital resource to draw upon when needed. Those who follow this pattern sooner or later realize they’re trying to solve a tough problem and use what you’ve recorded to solve the problem. Try to avoid writing lessons down and then losing the information and forgetting to keep it updated. An example the text offers is someone who keeps a wiki for his private thoughts and the other for sharing with the world.

I think the pattern is good advice, I like the idea of keeping a blog to update as I start my career as an apprentice. I liked the idea of having two wikis, one designed for personal use and one to share with others. Having a more personal blog or wiki allows you to be painfully honest with yourself and the progress you’re making. Having something to go back to and refresh yourself has many benefits and can help you in a bind when you might not have anyone to ask. I keep cheat sheets at the current job I work and having that information saved makes my job much easier. Another good suggestion from the text is creating a textfile or page on a blog or wiki to save tidbits of information or quotes from software craftsmen, in the example the book noted, someone uploaded all their saved quotes online for others to learn from. I like how this patterns ties into the Breakable Toys pattern, you can start projects that you can share online, creating a chronological history of every step of the project, where things went wrong, and what you did to fix it. I think during my time as an apprentice I will continue to blog what I learn and keep the lessons I learn from mentors and colleagues. I like the idea of Sharing What You Learn, a lot of the lessons I’ve learned have come from other people who’ve taken the time to create blogs posts or YouTube videos describing the steps they took.

The post Record What You Learn appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Transitioning

After meeting to discuss the current status of the website, there are only a few tasks that remain. Although I am still waiting on some of the design content such as images and social media links to be provided, I think that the website design will soon be wrapped up. Once this happens, the next step will be education and training on the use and maintenance of the site. This should not be too intense because of how intuitive WordPress is to use.

Part of this training will likely involve the transfer of the hosting off of my personal virtual server to a permanent host. While I do not mind hosting the site for the time being, I do not want to be responsible in the case that my server goes down. When using a well known hosting provider, you are paying for someone to take on this responsibility. I have prepared the site to be migrated, and I do not anticipate any issues with migration. WordPress is rather portable, not requiring much more than a few directories and a small database.

One item that still needed to be addressed was the size of the font used on the website. Although it appeared appropriate on my screen, it was difficult to read from a distance on higher resolution monitors. While I had tested the website in a few different browsers and even on my mobile phone, none of these allowed me to view the site as if I were using a higher resolution monitor. During the meeting, when viewing the site at a higher resolution, the text appeared to be “zoomed out” and was difficult to read in some of the lower contrast areas of the page.

The next thing that I will be looking at for the MassHOSA project is QuickBase. I am familiar with the platform because of an internship where I am currently auditing and validating user access to QuickBase. Despite this familiarity, there may be a few obstacles to making the desired changes. After a quick inspection of the application, many of the features required to make the desired changes to the application are blocked due to the QuickBase tier in use. I will be looking for workarounds and discussing the potential solutions during my next meeting.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Record What You Learn

The ideas discussed in this pattern are often ignored by a lot of people including me. Documenting what you learn will not only serve as a further reference but will also save you a lot of time refreshing your mind on topics that you might have lost ideas. In the other hand, you may still remember what you have learned on a problem but the issue is that you have got only the main ideas, forgotten the details in it.

I got to realized how ignorance I am about recording what I learn after reading this pattern. I think I have never learn why I fails sometimes because on my reflection, I realized that in most cases, I overlook  some of the things I learn as a real event and therefore don’t  think I will ever forget them. But in the long round I lose track of most things as time goes on. On reflecting on why I sometimes don’t document what I learn, I couldn’t find a particular reason for that.  Gone on the days when there was limited storage in our computers, and in the worst case, no internet access, we could record what we learn on note books. The only problem I had with that was, as time passes, you turn to have more books and you overlook their important. Sometimes you are tempted to trash your entire old document thinking you have enough knowledge that can deal with issues coming from these documents. But I realized this is not true because not long ago, I have encountered a situation where I have to go all the way back to my high school note book for the solution.

After reading this pattern, I think I will not ignore the power of recording what I learn anymore.  With internet access, recording is going to be more convenient and effective. For some time now, I have been saving what I learn in goggle docs but after reading this pattern I have taken another twist to blog all my learning. I think this can help me easily managed and share what I learn with others.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Nurture Your Passion

I chose this pattern this week because I really need to work on growing my passion for the craft. I need to sit down and find something I love and make a correlation to software. This pattern taught me different ways to nurture and grow your passion so that you can dive deep into complicated projects, for fun. The authors mention 3 other patterns to help you grow your passion. These other patterns are Kindred Spirits, Study The Classics and Draw your own map. These three patterns will help you take the next step to loving the software craftsmanship.

My favorite excerpt form this passage was:

“To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This might mean you leave work while the rest of the team stays late, that you walk out of a meeting that has become abusive, that you steer a cynical conversation toward constructive topics, or that you refuse to distribute code that doesn’t meet your minimum standards. The result could be that you get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong.” – Adewale Oshineye, Dave Hoover

Basically, the authors are saying to stick to your code and don’t let yourself be abused. If you or your skills are being abused in the work place, it can greatly damage your passion for working on software. You want to stay positive and continue to love what you’re doing, it is the only way to cease your passion from leaving.

As I mentioned before, this pattern is important to me because I need to work on finding my passion. It isn’t always easy to sit down and work on a fun project just for the hell of it, but this pattern shows me that it truly is invaluable. All you need is time and patience to further your knowledge and skills of the craft. Developing a passion is something that I have been trying to do with school projects and what not but it needs to be more. Being passionate about a project would just be a kickstarter to become passionate for every step of software development.

 

You can find this pattern here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s04.html

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Post #28 – Reflection on the “Practice, Practice, Practice” Pattern

This week, I will be writing a reflection on the “Practice, Practice, Practice” pattern.  This pattern addresses developers who want to get better at programming and to expand your diversity of concrete skills.  I chose to reflect on this pattern because I recently accepted an offer for a summer internship and I intend to put in quite a bit of practice before I begin working in June.   Oshineye and Hoover provide solid advice on how to exercise programming skills for those in the ideal situation of having a mentor and those who are left to their own devices.

They begin by saying “Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes”.  I think environment is a very important element in getting the most out of practice.  The environment in which you practice should allow you to focus completely on the skill you are trying to improve.  Ideally, this environment would also include a mentor that can help guide your practicing and gauge your progress.  Personally, I think an ideal environment could also include peers who are also developing their programming skills because it would provide more outlets for each individual to discuss their work and mentor one another.

They go on to say that the key to this pattern is finding time to develop software in a stress-free environment with no due dates production issues, or interruptions.  This pattern, like the “Breakable Toys” pattern, also stresses the importance of short feedback loops in practice sessions.  Short feedback loops refer to the cycle of completing exercises and quickly receiving feedback on your performance for the purpose of gauging a person’s progress toward a goal.  Short feedback loops can be found in the form of feedback from a mentor or in your own incremental completion of progressively more difficult tasks.

To implement this pattern, Oshineye and Hoover advise developers to find exercises or create their own, and ensure that those exercises will challenge them to at least some degree higher than what they know they are capable of.  They also advise that you should solve and resolve the same issue over some period of time, so that you can see how your solutions change and progress.  I have been motivated by this pattern and I intend to implement it in the coming weeks as I prepare for my internship.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Thoughts on “Reading List”

“Reading List” is the first in a set of design patterns written to help the apprentice craft a learning curriculum.  As more and more material becomes available, it’s important to carefully select a set of materials that can effectively guide oneself.

This particular pattern is focused on managing material, not necessarily curating it (although it does recommend asking mentors for suggestions).  The recommendation here is to create a list of reading material, and maintain it in a way that lets you see what you have read as well as what you have yet to read.  This allows you to fill in gaps as you go, even if the original list was not particularly comprehensive.  The basic form of the pattern is to keep a text file as a reading list.  In more complex implementations, you can use a version control system to track changes, or use a public form (like a wiki) so that others can benefit.

I am not sure how helpful this pattern will be to me.  While I do understand the need for continued education, and I do enjoy reading, I’ve found that I learn far better from practical, hands-on experience than books, blogs, or powerpoint slides.  While I definitely got a lot out of Clean Code, I got more out of taking Uncle Bob’s suggestions and putting them into practice.  I also tend not to take well to to-do lists, either making or sticking to them — although, perhaps, this pattern would give me an opportunity to expand my horizons in personal organization as well as software craft.

My implementation of this pattern might be a bit more complex than the simple suggestion of keeping a version-controlled text file.  I would prefer to curate a list of resources that contain practical, hands-on components (like Apprenticeship Patterns, although many of those are fairly abstract), or to learn from tutorials that give me room to experiment.

You could even apply this pattern to parts of a book (like Apprenticeship Patterns) that is more fragmented, or easier to digest across multiple readings.  Perhaps also to a video or article series.

From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.

Breakable Toys

When starting in a new work environment, especially when stepping into a new craft as an apprentice you only want to produce positive results, even though failing is a great learning tool.  A good apprenticeship pattern to develop is to create breakable toys. Develop personal projects that you can afford to fail on and break so that you can learn these valuable lessons without it having an impact on your performance review and without risking your job.  These can be programs, servers or anything else that mimics your work station and helps develop your toolset. The important part though is to remember that it while it should mimic your workstation it should not intermingle with your work by any means. This could lead to massive problems if you break your toy and it negatively affects your work.  You also don’t want to run the risk of breaking any confidential agreement that may lead to legal trouble beyond just losing your job. This is not a pattern that should just be applied blindly; you need to apply a basic level of common sense of whether or not it would be ok to include things that you may have gotten from work onto an unsecured system.

When I start my new career I intend to mock my work station at home to the best of my ability.  I will use this to create similar projects to the one that I am working on so that way I can have more freedom trying solutions.  While that is part of what version control fixes this will allow slightly more freedom to try things that shouldn’t work and take the time to see why they don’t work as a viable solution to the task at hand.  Then as time permits I can create new projects that are not associated with work and expand my toolset to work on mastering new areas of my craft. I know for myself that I learn better by doing something hands on rather than in a visual manner.  Creating a personal workstation will allow me to further develop my craft and skills that I need to succeed in this new role. It will also allow me to explore and create any personal projects that I may find interesting that will help develop a broader toolkit that may come in handy later in life.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.