Category Archives: CS448

Sprint 4 Retrospective Blog

For this sprint, I worked on several different tasks to improve the project. Firstly, we needed to get the project hosted onto Heroku, so I added some of the dependencies that Joshua Farrar had created in order to allow it to be deployed directly from GitHub. There were also some minor bugs that needed to be fixed such as typos, missing new line characters, etc. Next I worked on adding build instructions to the readme by working through installing the project on a clean windows install on a virtual machine in order to figure out every dependency needed to be installed. Then I added a landing page to the project which contained a list of all of the available endpoints, however this was a very bare bones solution as it was just a list of the endpoints with no further information. We decided to integrate Swagger 2 and Swagger UI to automatically create more description documentation containing endpoint descriptions as well as a UI to test the endpoints. There was also a minor issue where the example model of the object returned by the endpoint was showing up as empty. This was due to the way the endpoints were returning objects (showing the model of the “Object” class rather than the actual classes being returned).

From what I understand, Swagger gathers the endpoint data in the same way that I did, however, it’s far more detailed and robust. I think if I were to do something differently in this situation I think definitely I would do more research into the possible alternatives to solving each task in order to figure out what the best solution would be before starting to work on it. Had I initially looked into Swagger prior to starting to work on the landing page, I would have saved a lot of time. This is something that I should take into account for the future as it will be important to avoid wasted time whenever possible.

When making the build instructions, I think using a virtual machine to start from a clean slate was definitely the best course of action, as it’s important to see what it’s like for someone who potentially started from that state to get the project up and running. By doing this, even people who already have some of the dependencies installed will be able to follow through the build instructions by skipping steps that they’ve already installed. Although, I hadn’t considered the difference in the installation process between Windows devices and Mac/Linux devices. This project in particular doesn’t require many dependencies to get started, so it’s not difficult to create combined installation instructions, but I think for larger projects it would be smart to separate them. One of the differences I ran into was including the installation of Git Bash while Mac/Linux devices would be able to just use command line.

For the next sprint I’m hoping to automatically update the version number whenever necessary, as it’s definitely bad practice to have to update it in 4 different locations every time. Also, it would probably be a good idea to add an endpoint that gives you a products maximum shelf life and best storage method, given what the data would probably be used for.

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

Sprint 3 Retrospective Blog

For the third sprint, I was assigned to create a REST API for the USDA’s Food Safety Inspection Service’s FoodKeeper Data (located here:
https://catalog.data.gov/dataset/fsis-foodkeeper-data). Prior to starting this assignment, I felt I had a poor understanding of what a REST API was, let alone how to go about making one. Fortunately, the resources that Professor Wurst sent me were a very helpful step in understanding what one looks like. I also read several other resources and followed many other tutorials while making it. By the end I had over complicated things by storing the data into a MongoDB database and ended up switching to data stored in memory, but despite this I think it was still very useful to work with MongoDB as well integrating it with the REST API. I had also considered trying to use a relational database such as PostgreSQL, as the data seemed to lend itself well to it given that each data type already contained keys relating to the other data, however it was a bit harder to set up when compared to a document database.

This sprint began before spring break, and during that time I felt that the project was at a much earlier point than was initially assumed, so I spent a good chunk of my break working on it. As I said I started with a poor understanding of REST APIs so I felt that there was some catching up that needed to be done. By the end of the break I had something that was mostly working but was a bit complicated to set up since it required installing MongoDB locally at the time. I imagine we may have run into similar issues when trying to host it in Heroku, but fortunately it’s since been simplified. I don’t think that it would necessarily be a bad thing to store the data in a separate database, however, given the relatively small set of data as well as the fact that changes aren’t made very often, it didn’t really make much sense to go that route. Changing the code that I had already written to no longer use MongoDB was pretty trivial, as not many changes needed to be made. At this point, the REST API Order System example (located here: https://gitlab.com/worcester/cs/kwurst/rest-api-order-system) that was sent to me was particularly useful, as the was it was set up was almost one to one, with a few changes here and there.

Currently the project is almost at a point where it’s ready to be used, as far as I’m aware at least. I feel that it was much simpler than I had originally thought it would be, but since I hadn’t had any experience with doing something like this before it took longer than it should have. I think one of the most important things that I’ve learned from this is how to start working on a task in which I’m unfamiliar with. It was definitely useful to learn how to make a simple REST API, but I’d say being able to work on something you’re uncomfortable with is a skill that will help me greatly in the future.

Links:
https://github.com/LibreFoodPantry/FoodKeeper-API
https://github.com/cs-worcester-cs-448-sp-2019/FoodKeeper-API

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

Apprenticeship Pattern – Breakable Toys

The Apprenticeship Pattern “Breakable Toys” refers to a scenario where the environment you’re working in doesn’t allow for you to fail, stifling your learning because failure is often the best way to learn anything. According to the author, the solution to this is to create your own “breakable toys” from which you’re able to learn through catastrophic failure that won’t have an effect on anyone but you.

The thing I find most interesting about this pattern is some of the examples it suggests to do in order to create opportunities to learn. For example, creating your own wiki and adding more interesting features without being bound by existing implementations. I can see how working on something like this from start to finish would greatly improve your ability as a software developer.

It would be great if you could be satisfied with the amount of learning that you’re able to do within your current work environment, but given the fact that businesses need to make money to survive, taking risks and learning through failure is typically not something that can consistently happen if a company wants to continue existing. That’s not to say that mistakes should never happen, but it makes sense that a company would want to avoid them as much as possible in order to retain the trust of their clients. If someone were to make a costly mistake for a company, it should be used as a opportunity to learn from it, rather than just firing that employee and moving on.

I recall there being a disruption in Amazon’s S3 service causing around 3 hours of downtime being attributed to human error. One of the employees on the S3 team was debugging an issue when he accidentally removed a larger set of servers than he had originally intended, all due to a small typo in his input. Regarding this incident, Amazon stated: “We will do everything we can to learn from this event and use it to improve our availability even further”, acknowledging that they would seek to prevent it from happening in the future. I would imagine that the employee who made the mistake may have learned a lot about the potential effects of something that seemed so insignificant.

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

Sprint 2 Retrospective Blog

Our second sprint was much more productive than the first, thanks to our meeting with the representative from the food pantry. During the meeting we were able to gather a lot of information about what they needed from us. Currently, new users fill out a Google form which determines what level of aid they qualify for. This is something that we would want saved and automatically determined when that user comes to the food pantry. One of the main issues they’re currently having is that employees have to manually track the weight of their current stock. So every donation they receive they have to measure its weight and then manually enter the weight of the donation as well as what types of items were received. This is the main task we’re working on finishing this sprint. For this we should be focusing on making small quality of life improvements (such as automatically adjusting the total weight) and work from there. I’m interested in seeing if it would be possible to connecting to a scale to do this automatically after weighing a donation, but that’s something that should come later.

From the meeting we were able to figure out some of the food pantry’s pressing needs that we could address. I feel like we were able to devise clear goals to work towards.

After the meeting was over I believe we may have ran out of time before assuring that everyone knew what tasks were assigned to them for the sprint. During the sprint I think this was cleared up as Nick had already begun re-purposing one of his previous projects for the food pantry and let us know what he needed help with. Although, since we missed a couple of meetings we ended up making less progress than we could have.

During our retrospective, Nick showed us and the representative from the food pantry the progress he made on the new worker intake form. It’s definitely a step in the right direction. Once it’s cleaned up a bit I think it’ll be better than what they’re currently using. One thing we need to do is to make sure that we create something that actually makes it easier for employees at the food pantry to do their job. For this project in particular, we need to solve the main bottlenecks that they described: manual data entry and calculations. These are things that can easily be solved by automating the process. It’s important that we create something that is an actual improvement from just sticking with the Google form.

Near the end of the sprint I was given a different task to work on. This was what we were initially working during the first sprint prior to the meeting with the employee from the food pantry. For this I need to create a REST API interface using the USDA’s FoodKeeper Data so Joshua Farrar can deploy it to Heroku. While we were working on this during the first sprint, we were all researching what we needed to do individually which I feel may have wasted a lot of time. The resources for REST APIs that Professor Wurst sent me have been useful, and hopefully I’ll be able to finish this during the next sprint.

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

Apprentice Pattern – Sustainable Motivations

The apprenticeship pattern “Sustainable Motivations” refers to the situation in which you want to develop your technical skills but are faced with the messy reality of ambiguously specified projects for customers with shifting and conflicting demands. This is often frustrating because the best motivator for a programmer is being able to do things their own way, but you often won’t be able to have this motivation because you’ll be forced to work on problems no one wants to do. It’s crucial that you find sustainable motivations that push you to achieve mastery.

What I found interesting about this pattern was that it talked about some of the “ugly” parts of the software development world: working on tedious tasks you don’t enjoy working on or becoming frustrated with ambiguous specifications or conflicting demands. It’s hard to stay motivated when you aren’t enjoying what you’re doing, but you need to remember why you’re doing what you’re doing. Being able to realize what motivates you to continue pushing yourself is something that’s very important if you ever find yourself questioning your commitment to the craft. I suppose that for some people, they may find that they don’t have many, if any, sustainable motivations and decide to quit in pursuit of another path. For them, it may be beneficial to figure out early on that this isn’t what they want to do. Others may be able to figure out why they continue to push beyond their frustrations.

This pattern caused me to consider what motivates me to continue what I’m doing. Obviously for someone who hasn’t fully experienced what frustrations are being referred to in the article, it’s hard to be able to decide if what motivates me outweighs the potential frustrations, so this is something that I’ll have to experience for myself before figuring out what I should do.

Writing down a list of things that motivate you and keeping that list with you is a great idea to be able to push you whenever your feeling frustrated. If you aren’t able to come up with sustainable motivations, perhaps it may be time to think about if you’re walking on the road that you actually want to walk on.

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

Sprint 1 – Retrospective

Our first sprint was less productive that I had hoped it would be. I feel that during the sprint planning phase we should have made sure that everyone was assigned a task to get done working towards a clear goal. For most of the sprint I think most of us were unsure what we should be doing and weren’t sure what we were doing was leading in the right direction. This is something we should have discussed with the product owner (Professor Wurst) set up clear goals. Tomorrow during our sprint planning meeting we should definitely not leave until everyone understands exactly what they need to be doing. If we’re still confused about the requirements we should open up a discussion with the product owner. I feel the team would benefit greatly with a team lead who could potentially answer any questions the team has by handling communication with the product owner. That being said, I’m not sure that anyone would be comfortable with and/or willing to take on that role. There’s definitely a lot to improve on from the first sprint. If we don’t, then we may end up continuing to use our time unproductively. I think everyone wants to do a good job on this project, but may need a bit of direction on what they should be doing.

During this sprint, we spent some time on getting everything set up, such as GitLab, Slack, Trello, etc. We have yet to set up the project itself, however. I think because of uncertainty, most of us spent our time researching by doing tutorials rather than diving into the project blind. Although, we should have confirmed with the product owner everyone’s responsibilities for the week in order to keep the project on track. I took a look at the JSON file to understand the structure of the data, which I think was a source of confusion for many members of the team given that it wasn’t formatted for space reasons. I spent most of my time for the sprint working with GSON to convert the JSON file containing the FoodKeeper Data into objects representing the data in Java. I’m not certain that this is a necessary step for making a REST API interface for this data as I hadn’t done the proper research beforehand, so there’s no guarantee that the work that I did this sprint was necessary. That’s something that can hopefully be resolved next sprint. Also, I spent a little time following through some example REST API tutorials to get a better understanding of what our project may end up looking like. Java 11 seems to have incorporated HTTP APIs directly into the Java SE API (found at java.net.HTTP.*), so this may be worth looking into. It may be beneficial to take a look at the repository put up by the team at Western New England University to see how they’ve set up their project.

Link to the repository for the JSON converter that I worked on for this sprint: https://gitlab.com/worcester/cs/cs-448-01-02-spring-2019/team-fig/food-pantry-json-converter

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

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

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

“Why Doctors Hate Their Computers” Reaction

The article “Why Doctors Hate Their Computers” by Atul Gawande discusses the effects of the computerization American hospitals over the past decade.

I found it interesting that the computerization of many of the processes that health professionals use, such as recording medical observations, sending prescriptions, ordering tests, etc., ended up actually causing doctors to spend more hours working than they had before (spending about two hours doing computer work for every hour spent with a patient). This is surprising to me because cutting out the overhead of physically performing these tasks should have done the opposite. Yet, in practice, it seems that that is not always the case. Small details that doctors would have been able to ignore now act as roadblocks. For example, commonly skipped questions in a form may now prevent the doctor from submitting the form until filled. Although these questions alone may only take a few seconds to get an answer to, this could potentially add up and take a lot of time away from actually talking to the patient instead of just requesting information to fill in a form.

Another interesting topic was some of the potential solutions to solving the lack of doctor-patient interaction caused by doctors having to check off boxes in a form on their computer. Having someone else, whether in-person or through a camera, transcribe all of the data from a visit is a great solution to the issue. Of course, the cost of paying someone to do that is something that hospitals may not be willing to provide. There’s also the factor of a patient feeling less comfortable knowing that someone else is listening in on their conversation.

I feel that the real customer for the system was the hospital system itself (Partners HealthCare). While I think keeping their technology up to date is a good investment in the long run, the ones seeing the adverse effects are the doctors themselves. Computerizing all of the data and processes helps the hospital to be able to protect confidential data and ensure that all legally required information is gathered from patients.

The lessons from the implementation of this system apply to much more than just Electronic Medical Record systems. It’s likely that the computerization of any industry would see many of the same issues such as the decrease in human interaction and the frustrations in the software decreasing productivity. Although, in less regulated industries, these frustrations may be more limited.

This reading brought up an issue that I hadn’t really considered before. A lot of people, especially computer science students, are probably of the opinion that the computerization of any industry is a good thing. To an extent I still think that this is true, but you should consider the possible effects it may have on all parties involved.

Source: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers

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

Apprenticeship Pattern – Expose Your Ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.

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

Apprenticeship Pattern – Your First Language

The apprenticeship pattern “Your First Language” is a pattern that specifically focuses on people who are just starting out and only have a shallow understanding of one of two programming languages. For people in this situation who don’t feel like they have very in-depth knowledge in any particular language, the solution is simply to pick a language and become fluent in it. However, what language should you choose?

I think that this pattern pretty interesting and still somewhat relevant even to people who are comfortable in a specific language. For me, even though I feel that I’m pretty comfortable with writing in Java, I can say without a doubt that I’m still very inexperienced and will run into problems that I’ve never encountered before. According the the pattern, one of the most fundamental ways of improving your experience with a language is the solve an actual problem with it. Being able to encounter roadblocks naturally and discovering a solution to it is something that you won’t be able to effectively recreate through learning from small, self-contained examples in learning resources.

One thing that stood out to me in this pattern was what was considered the most important factor in choosing your first language. It states that you should choose a language that someone around you is an expert in. By having someone with that expertise within reach, you are able to learn at a much faster rate than if you were trying to learn it by yourself. Preferably, you would be able to work on a project with them using the language regularly, but as long as you can get feedback from them, it will still be immensely helpful. While I think that this should definitely be the major factor in your decision, I’m sure many people may not know an expert of a language that they would feel comfortable enough working with or seeking feedback from. For those people, it’s important to seek out those opportunities and expand your network, but I suppose that’s easier said than done.

Overall, I feel that for those in that situation, this pattern is something that should definitely be followed if you want to learn as quickly and effectively as you can.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

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