Author Archives: Ricky Phan CS Worcester

Sprint #6 Retrospective

During this Sprint, my team and I tried to complete as much as we could since we are coming to an end in the semester. We wanted to at least give JJ and the AMPATH people some sort of workable interface for our offline data capture service. Throughout the process of finishing and having a workable interface, the team and I decided to focus all of our attention on that aspect, aside from the encryption service that I was trying to discuss with the encryption team involving the javascript implementation crypto.js.

Some tasks that we did during the week that helped lead us to establishing the offline data capture service interface were:

  • Help ensure GUI code is compatible with any offline-capturing abilities we implement when the user is online and vice versa.
  • Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
  • Ensure all new components, GUIs, etc comply with basic AMPATH CSS styles, overall look and coding convention.
  • Code the offline GUI based on the help and input from Jerry and other teammates.
  • Write/maintain tests for our implementations so they are always as current as possible.
  • Seek help from the AMPATH development team if any of us hit a roadblock concerning implementation.
  • Offer suggestions to other teams based on our overall process, so that all teams’ implementations can work together as smoothly as possible.
  • Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
  • Develop high-level idea of a Doctor/Provider object so we can consider if it is worth implementation.
  • Develop mock diagram where a “Doctor/Provider” can pick and choose what patients to sync.

The above tasks were what was tried and attempted. What was done and completed were the establishment of the Doctor/Provider object, and the mock diagram. For the GUI task, we had to communicate with JJ a lot. Due to the amount of time the team had, we had a feeling that there wouldn’t be enough time to create a perfect GUI, even though JJ wanted one. Midway through the sprint, we sent JJ our progress on what we did so far for the offline data capture service through a walk-through video that we shared on the slack channel. JJ then understood where were at with the progress and we concluded that it was okay to work towards establishing an interface where the user can clearly see if he is offline/online along with the data. That was one of the tasks that we had approach differently and adjusted to.

As a team, we learned to make a major adjustment to our task during this sprint. We knew that time was a concern, and what the people at AMPATH and JJ were expecting to get, which was the new offline GUI, seemed to be too much. We wanted to at least deliver something to them that at least worked, which is why we moved away from creating the new GUI. From this situation, this could be applied in real life software development environments because there will come times where I would have to adjust my tasks to deliver something that the customer wants, even if it isn’t 100% of what they want it to be, it will perform the same functions of what they want it to do.

The team’s performance during this sprint was above above average. Everyone contributed evenly or more than an adequate effort throughout this sprint. Communication was very effective between each member and between our team and AMPATH. As an individual, I performed average during this sprint. I mainly tried to talk to the other teams, trying to get some info on their status. The only team that we communicated to more than others was the offline data storage team, and we began to work alongside with them since our tasks were similar to theirs. I also tried to help find several components in the AMPATH code for which JJ wanted the interface to display such such as genral patient data, vitals, lab results, and HIV summaries.

Overall, the team worked diligently and we wouldn’t have proceeded in any other way. We will try to have our offline interface working, completed and delivered hopefully by the end of this next half sprint.

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

Software Development Capstone Sprint #5 Retrospective

During this sprint in my software development capstone class, my team and I tried to make some progress on establishing our offline data capture service. Before creating our tasks, we organized our team’s trello board to be a bit better. We changed the layout of our board by creating different columns that were categorized by our names to indicate who was in charge of doing a specific task that was assigned to them. We did this because it could make us as team to better understand who was doing what, and what was currently worked on in this sprint.

The team and I attempted to find out more ideas from the people at AMPATH through the communication with Jonathan Dick. We felt that we needed to get some ideas to further progress at our offline data capture or else we wouldn’t know what to do during this sprint. One question that I had asked to JD pertained to a GUI, which he wanted that indicates and separates offline data from the online data through our service. We are still currently figuring out on how to create the GUI. Other tasks that we attempted were:

  • If dealing with CORS issues, create a desktop shortcut loading an instance of Chrome disabling web security.
  • Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
  • Write tests for our implementations.
  • Design the HTML part of an offline component that will be used for our GUI. Should be similar to the layout of the AMPATH Patient Search Component.
  • Collaborate with the encryption team regarding the process of how our captured data ought to be encrypted.
  • Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
  • Create a mock diagram in Balsamiq illustrating an idea of a GUI that presents the captured data in a meaningful way.
  • Develop mock diagram in Balsamiq where a “Doctor/Provider” can pick and choose what patients to sync.

All of these tasks are still ongoing, leading into the next sprint. I felt that we were unable to complete any of these tasks within this sprint because we spent most of the time asking questions. I would admit that there were times where we were lost because we weren’t  communicating enough to JD. However, one task that we got done was:

  • Get ALL patients in the database (not just those with “test” in the name). Store each patient results into an array, then iterate through it to store each into separate files in PouchDB.

What we learned from attempting these tasks was that it taught us to constantly communicate with AMPATH to develop a smooth transition from task to task so we don’t get stuck and waste time on what to do next.  Communicating with AMPATH and asking questions to them will help us develop ideas on how to proceed with a task to validate what we are doing is what the people at AMPATH and JD wants. This was the main thing we learned from our mistake. This can be applied in other situations because in the software development career, communication is one of the most important things to do for this particular reason. If there is not constant communication, whether it be to your teammates or anyone in the workplace, work can become difficult and you can become unaware of what to do, which can further delay the project or task from getting done.

The effort that my team put into this sprint was sufficient despite the incomplete tasks. Everyone still tried to attempt at something even though we were still stuck on how JD and the people at AMPATH wanted our Offline Data Capture service to look like. For this sprint as an individual I mainly tried to still gather ideas and find a suitable encryption implementation for the AMPATH code and I think that using crypto.js wouldn’t work efficiently, so I decided to keep on researching. I also talked to the encryption team and found out that they ran into some impediments as well on developing their encryption service. Moving forward, my team and I need to communicate more effectively with the other teams as well as with JD and AMPATH. Doing this will help us work better.

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

Walking the Long Road: Draw Your Own Map

In this Apprenticeship Pattern “Draw Your Own Map”, it explains the importance about creating and managing your career path once you are exposed in the software development environment. A couple of key points that the pattern states are:

  1. Your manager, professors, or colleagues are not in charge of where you position your career as a software developer.
  2. Your are responsible for your destination and goals.

These couple of points emphasizes the concept of a software developer’s individuality. It is true that within the software development field, everyone is a programmer and creates many different types of software. It is up to you as an individual to take steps towards what you aspire to do and become within this field of development. One quote that stood out to me was this one below that talks about your vision of goals versus the employer’s vision for you.

“If you find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences, examine other opportunities to see if they’re heading in the desired direction. Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.”

I agree with this idea because it seems like it will be the most realistic to me once I start working for a company that may not have the same vision for my career as I do. This idea also will allow me to change the way on how I would manage my goals and career paths while working in the field. I will continuously plan and weigh options that would be available to me out there in the software development field since there are many companies and employers to work for. It goes back to the concept of leaving your current job for a better one because it does not meet your intended needs or it doesn’t help you grow in the field. For me, I’d like to work for a place that respects my needs and aspirations. As a future video game developer, I want to have that luxury of being able to grow into a successful video game developer and there would be nothing more  important than that.

 

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

Software Development Capstone Sprint 4 Retrospective

During the fourth sprint of our Software Development Capstone class, my team and I made some progress towards fulfilling our primary task of creating an offline data capture service. Some tasks that we created in order to reach towards the offline data capture were to figure out and introduce ourselves to pouch-db and how it could be implemented with Angular and the AMPATH code, getting pouch-db to work and compile with the AMPATH code, and researching cryptojs and finding out if it would work well with pouchdb to establish an encryption service with the offline data capture service. We manage to tackle these tasks that we created because other teams had researched cryptojs and pouch-db, so we felt that we had to do the same by introducing and exposing ourselves to these JavaScript implementations.

When we attempted these tasks, we managed to successfully learn about pouch-db and got some ideas about how it would work with the AMPATH code. Once we gathered all of our ideas together during our meetings and communication on the team’s slack channel, we started to tinker with the code itself and installed pouch-db within Webstorm’s terminal so that the dependencies can be present within the code. At first, we had trouble getting pouch-db to work with the AMPATH code because we kept getting compile errors. We assumed that the errors were coming from the packages that were installed from the pouch-db installation, which happened to be true. So, our team member Jason, stepped up and tried to find out how to troubleshoot this issue. He went and found how to properly install pouch-db since we had initially installed it the wrong way. We had to clone a clean copy of the AMPATH code from our own repository and make a new project from that copy. Once that was done, we had to remove the “Package-Lock.json” component from the code, then install it. That component happened to be the main cause of the problem. It was smooth sailing from there, and we successfully connected to the AMPATH server and log into it without any issues.

For crypto-js, we are still researching it and is considered an ongoing task. However, since my team and I did not come up with any ideas with the implementation of crypto-js in our offline data capture service, my team and I can categorized this task as a failed task for this sprint. Our goal is to get some ideas on crypto-js and implement it successfully by the end of the next sprint.

My team and I learned a substantial amount from this sprint, especially about the implementation of pouch-db. Despite the problems that we had with it initially, we overcame that problem through effective researching and communication within this team. I can’t think of any way to approach it differently because I’ve seen that with this group, we learn most effectively through trial and error. I felt that we researched pouch-db the best we could’ve done and successfully implemented it despite of the first compile error we ran into. This situation could be applied in other situations with any software development workplace. Working through trial and error is normal with this type of work and learning to overcome issues that may arise is a daily obstacle for developers such as myself, so I feel that this obstacle that we had with pouch-db was a great learning experience.

I feel that my team and I were very productive throughout this sprint. As an individual I had done my fair share of work and expected good quality from everyone. I mainly researched articles about pouch-db and crypto-js, and communicated the information that I found out to my teammates during our sprint meetings. For everyone else, they did wonderful. Jeremiah did his job with participating in team meetings and communicating over slack to remind each of us to do our standups. Rick helped gathered ideas for the code itself. Jason did the most work with the code and was the main person to work directly with AMPATH in getting ideas from them and at the same time getting pouch-db to work.

Overall, I’d say this sprint was very successful.

 

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

Walking the Long Road: Nurture Your Passion

In this Apprenticeship Pattern “Nurture Your Passion”, it explains the the importance of your passion as a software developer and how it can be exposed to situations or circumstances that can affect to maintain that passion. This pattern illustrates various ways to protect and keep that passion healthy as possible in order to prolong the enjoyment of being a software developer such as:

  1. Work on what you like.
  2. Join a local or study group that enjoys and focuses on the same things that you enjoy or want to learn more about.
  3. Read books that can expand your view of the field.
  4. Create your own path or move into an organization where your needs, asprirations, and goals can come to fruition.

“Paul Graham said, “The key to being a great hacker may be to work on what you like…. To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well.”

This statement by Paul Graham was very interesting and useful to me because for me as an individual, I produce the best work when I love and enjoy what I do. There have been some instances of my life where I would not produce my best work where my state of mind does not like what I am currently doing, whether it be a class that I am taking at school or a part time job.

“To become a journeyman, you will need to have a passion for software craftsmanship. Unfortunately, your daily activities often work to diminish this passion. You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it.”

This is another statement that I found useful and will help me in my intended career because I understand at the end of the day, work is work, and there will always be times where deadlines, corporate needs, managers and co-workers will stress me out, which will lead to a decrease in my passion for software development, particularly video game development. However, the actions that I’ll take will help reinforce my passion to sustain the harsh natures of the work environment and to prolong my love to hone my craft.

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

Walking the Long Road: Sustainable Motivations

In this Apprenticeship Pattern “Sustainable Motivations”, it explains on how to sustain your motivation as a software developer through walking “the long road.” This pattern gave very good examples in situations where a software developer can have decreased motivation within their state of mind based on what they are currently doing or have recently endured, whether it be from a project for a customer, or in general, life at work. Some aspects that this pattern exemplified was the balance between being happy at what you do as a software developer, honing your skills and craft, and the amount you are getting paid to be financially well off.

At one point in the pattern, it gave very good examples that illustrate the point that there will be times as a software developer where you question your commitment to honing your craft or your profession.

“You hate your programming job and you’re motivated primarily by money. You find yourself focusing on climbing the corporate ladder over honing your craftsmanship. But you are also motivated by your reputation as a technologist, and this allows you to endure long enough for your job situation to improve.”

“You’re motivated primarily by your enjoyment of programming, but you’ve had a few months when you can’t feel the love. You are seriously considering abandoning the profession. Fortunately, you are also motivated by money, and you think that programming is your best option financially right now. You stick it out for the money and eventually your love for programming returns.”

I can picture myself being in these situations because of my concern for getting a well paid job. I know for a fact that money helps my motivation, however at the same time, I want to do what I love in the software development field, particular video game programming and development. In my mind, there will come times when it will be tedious and difficult while working, but with any job or career, work is work, and there can be times where I know I’ll face hardships and I will overcome them. Loving for what I do in my career will be the main reason for the longevity of my video game development career, and I’ve always known that since when I was a kid, I’ve had a passion for video games.  This pattern has opened my thinking on this particular career path and I agree with what this pattern has taught me about sustaining my motivation as a software developer.

 

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

Walking the Long Road: Craft Over Art

In this Apprenticeship Pattern “Craft Over Art”, it explains the relationship between the craft and the art of a craftsmen’s work. As an apprentice, it is important to understand how much of an impact both aspects have for the work that they produce for their customer. In the software development field, most of the work that you would produce would be for the customer or client that requests the product. With this being said, the customer or client that requests the product will have certain specifications that they want you, the craftsmen, to make, or they could ask for you to make a product that is useful for them.

“Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests. As a craftsman you are primarily building something that serves the needs of others, not indulging in artistic expression. After all, there’s no such thing as a starving craftsman. As our friend Laurent Bossavit put it: ‘For a craftsman to starve is a failure; he’s supposed to earn a living at his craft’. You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”

This idea of deciding craft over art is understandable and this idea stood out to me the most. The software that you make as a software developer must be useful to the customer, otherwise it is a meaningless piece of work.  It is okay to implement the special touches on your work once it has fulfilled its usefulness to the customer and their needs. However, it is not okay to primarily focus on the art aspect over the needs of the customer. You are called craftsmen for a reason, not an artist, and that’s how I view this pattern’s main idea. I completely agree with this pattern’s idea of craft over art and I feel that every software developer should consider the “craft” a priority over the “art” of their work first.

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