The “Read Constantly” pattern is described as a way to create a strong base of knowledge and an even better understanding of the industry around you. There seems to be such a vast amount of information out there today that it seems very intimidating to even fathom where you should start. Reading is the best way to start learning more about the industry and more abstract yet fundamental concepts. The idea of reading everyday may seem like a lot of work at first but the key is to completely immerse yourself into the context of the text. Find new ways to apply what you learn to what you are working on and familiarize yourself with patterns before they become more popular and widespread. Another good way to read is to section parts of the book into manageable pieces to organize your learning experience such that it flows easier reading from one chapter to another. The book also talks about momentum when finishing books by allowing a brief but not long period of absence from reading. Find your next book and move onto it as fast as you can without creating a disturbance in your work life.
This pattern was interesting because it showed me a way to read without making it too overwhelming. Every book I find on coding seems to become very overwhelming with the amount of content inside. The content itself becomes boring when reading for too long, it begins to sound repetitive which leads to a lack of interest. I found the tactic of breaking these large amounts of reading into smaller portions a great idea. I’ve been currently applying this tactic with great results as I can retain the smaller amounts of information better and this allows me to keep a more vested interest in the book. I also found that focusing on the portions of the book that interest you can make it easier to read. Focusing on ideas and aspects that you want to learn more than the rest makes the reading go by much faster. I agree with this pattern because of the amount of information that is available at all times to us. It’s very important to use our resources to the best benefit we can take from them. Books and online readings are everywhere these days and it makes information much easier to obtain, so to sharpen your skills you must broaden your skill set as well.
Not a lot has happened in the last two weeks. There has not been a clear assignment given to be accomplished individually or as a team. On the first class meeting of this sprint, I helped Matt get through the final errors to get the ng2-amrs, since he was seeing the same errors that I had seen and figured out how to get through myself. After installing the right version of node, and then following the determined steps to fix the series of error messages that come up after trying to run npm start, it says compiled with warnings and does not error and the AMPATH login page comes up when visiting localhost:3000 in a browser.
Once he got it running, everyone on the team was able to run it without errors, so we had nothing left to do but vaguely review some miscellaneous information about JavaScript and angular. After that, our team did not meet in class for a couple of days or class had been canceled. It was not until Thursday during the sprint review that we started to get something to do, but that was the last meeting before spring break, so we did not get a chance to actually start anything, only to look at the new information that has been given and begin to process it.
From watching the first of the six AMPATH videos that we were sent, it looks like we are being given an existing user interface and it is up to us to implement the desired logic and behavior to have it interact with the medical records back end. The videos walk through some of the buttons and elements that were already placed together on the front end, and some specifics are described about what the elements are supposed to be for and how they should interact with the medical records data. From here on, we will finish watching the rest of the videos to better understand what they explain and what is expected of us, and we will have to decide among the other teams who is doing what, and figure out what it is we are actually going to be doing and how to do it. From what I have understood so far, I think that we are going to need to read a lot of the code that has been written so far, and then while we are writing more code to implement the new front end features, we will be referring to the existing code in order to find out how to access or manipulate certain data and objects. Depending on the amount of documentation that exists, it is possible that we may need to come up with our own documentation just to keep track of how everything works. I think that our previous experience programming in typescript during the last semester should be helpful while writing the code for this, although this does seem like it is going to be significantly more in-depth in certain areas.
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.
Although we have not been given anything to work on from AMPATH, save yesterday’s meeting, I have made the most of my time to learn as much as I could about Angular. I haven’t gotten all the way through the tutorial, but I want to emphasize learning it throughly over rushing it.
The first time I was going through the tutorial, I was well over halfway done when I realized I was missing one of the steps to get it to work. This happened early on in the tutorial as well, and I resorted to blindly copying and pasting every step again to get it to work. It turned out to be a very minor fix. I was much further in this time, and I was about to do the same thing, but I realized I would be wasting my time if I did that. If I didn’t understand the code enough to diagnose these simple fixes, I am not getting much out of the tutorial doing it this way.
I was talking to members of my team about it, and we came to the conclusion that even if we individually only got through the first few sections of the tutorial, our time would be better spent if we understood what we were doing thoroughly over completing all the sections without as good of an understanding of the concepts.
Even though we have not been doing a lot of work together as a team for the clinic, it is really nice being able to bounce ideas off members of our team. It is great to have the ability to share resources with people I am working towards the same goal.
It feels like I am living out some of the apprenticeship patterns that are laid out in the textbook for this course. I am challenging myself to learn new concepts, even without a looming test or set deadline. I have gotten better and better into the habit of carving out a small chunk of my time to learning a new concept here and there. I hope this continues as this course develops, and I hope to continue this trait for the rest of my life.
Yesterday, our group liked the idea of working on the projects described in the videos in part 2a and 2b. I liked everything that I saw, and would be more than happy to work on this. It’s not certain if we will be the ones who get to work on this, but we will coordinate that with the other groups. I am very happy to get started. This is what I’ve dreamed about doing since I decided to major in computer science. It is really exciting making that happen.
I also read a part of Edward R. Tufte’s book Visual Explanations, where he has a page giving an example of what an effectively-laid out medical chart might look like (p. 111). Although this might be the only example I could find on something for medical use, I think this book might prove to be a good resource for displaying the data. I’m sure there is a lot to be learned even from the examples that are not specific to medicine.
The most useful tutorial I have found comes from Angular itself. It is a really easy-to-follow step by step guide that holds your hand through the entire thing: https://angular.io/docs
Our second sprint had little coding action and more of a personal learning aspect that we decided to focus on. I found that the team benefited from individual learning in a similar fashion to an independent study when trying to learn about important concepts like Mockito testing and Angular formats. We then compiled our individual learning resources into our slack channel to help each other find resources that others may have missed. This allowed an easier flow of understanding while also being able to bring us all onto the same mindset of where we were in terms of starting the project. I will proceed to understand the AMPATH format for their angular code and translate that knowledge to the requirement we will need to meet in the future. AMPATH members have recently posted videos and presentations of how they want their new interface to look with explanations for user interactivity. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. We will have to communicate not only with our team member but the other teams as well to go over which functions should be divided up and worked on. This will create a better organization system for how we should communicate with other teams as well to understand any implementations that they will do which might affect our portion of the project. We learned about how the AMPATH project works through the videos which explained everything from selection tabs to navigation elements. It seems that this design concept may be similar to that of a mobile app from the setup of the mockup files which makes our approach much easier to narrow down. The most important aspect of this design seems to be simplicity with functionality for the patients and their doctors. The ability to create a smooth design is going to be complicated with different teams working on separate functions that are supposed to come together to create this app. It will require concise and mutual communications from several fronts that we will need to perfect over time. I predict that in the beginning it will be difficult to explain our coding schemas and ideas properly to each other but once everyone gets a taste of each other’s coding styles, it can be done with minor hiccups. We also need to decide whether we will stick with the idea of using a Mockito style for our testing or setup a server on campus to continue working with fake data. We have communicated with multiple teams about this idea and think that we should at least try to see if setting up a server is viable with as few hiccups as possible otherwise, we will have to look further into testing. I believe that setting up the server could work out well for every group, but it could cause issues with connecting and internal errors that we wouldn’t be able to figure out properly. It is definitely worth a try as it would be an interesting experience to understand and make it easier to test if we should be able to get fake data.
A reflection
on what I learned from this week’s activities is that when the working mindset
begins it goes quite smoothly. Once everyone settles in and breaks the ice, we
are able to communicate clearly and effectively what our intentions are and how
we are to go about it. When a certain task is finished, other members are notified,
and opinions are needed before we go any further with the task or beginning a
new one. When we get proper feedback, we are able to safely continue down the
path or create a new one to account for changes.
Another
lesson learned from this week’s activities is that members will tend to focus
on tasks that they are comfortable with first. In my case, since no one was
comfortable picking up the role on working with databases, I felt confident and
comfortable enough to pick up the task. As for the other group members, they
also went off in the direction that would prove most beneficial to the group.
This way, the group will spend less time learning material that other members
are clearly proficient enough to get started. After that, we are able to
converse and teach our knowledge with the rest of the group members which is
quite efficient.
In light of
this lesson learned, the next time there is a situation where the group is
clearly new to each other, and a project is being newly developed. It should be
safe to assume that everyone is not comfortable with each other yet and needs
time to adjust to the new environment and mindset. In this case, there is no
need to be anxious about the project over the course of several weeks as the
working process will natural come.
During this
sprint, my task was mainly focused on creating a design for the database. This involved
reviewing materials provided by the client and any requirements or constraints that
are to be noted. The chosen route when creating a database to account for Database
Management System (DBMS), as such an E-R Model is required. The chosen platform
for the database is SQLite, we noted the importance of being able to export the
database file as a CSV file and vice-versa. Being able to obtain a CSV file is
important for the client as it’s their preferred filetype for distributing
information.
Starting
off, I noted for four entities, staff, client, inventory, and items. In the
staff entity, it contained the attribute OneCard_ID
and a composite attribute Name which
accounted for First, Middle, and Last Name of the staff member. For the
client, it contains all of the attributes of the staff entity but introduces a
third attribute called Last Visit Date,
to account for information regarding the last time the client visited the food
pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight
to keep track of how much food is in stock. Lastly, the items entity contains
five attributes, Item ID, Item Name, Item
Weight, and Item Stored Date. However, to account for a concern from the client
about confidentiality of information the names of staff and clients are later
crossed off from the E-R Model. In conclusion, after consulting the group, the
next step is to create and connect the database with the project in order to
fully utilize its intended function.
Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.
Starting off, I noted for four entities, staff, client, inventory, and items. In the staff entity, it contained the attribute OneCard_ID and a composite attribute Name which accounted for First, Middle, and Last Name of the staff member. For the client, it contains all of the attributes of the staff entity but introduces a third attribute called Last Visit Date, to account for information regarding the last time the client visited the food pantry. Then you have the inventory entity which only contains the attribute Total Weight, since the pantry uses weight to keep track of how much food is in stock. Lastly, the items entity contains five attributes, Item ID, Item Name, Item Weight, and Item Stored Date. However, to account for a concern from the client about confidentiality of information the names of staff and clients are later crossed off from the E-R Model. In conclusion, after consulting the group, the next step is to create and connect the database with the project in order to fully utilize its intended function.
During the first sprint, our goal was to get everyone set up with the development environment so that we could all build the AMPATH project and get to work as soon as we were given user stories/had tasks. I believe of the time of the last blog post, we still had to finish getting one or two of my teammates set up, but that was resolved rather quickly. After that, it was learning testing in Angular while playing the waiting game for AMPATH’s team to get in touch.
And well, wait we did. That was no fault of AMPATH’s, though. They’re a rather small development team with a big project. They’ve got their work cut out for them and they’re seemingly very busy.
Unfortunately, with how busy they were, we didn’t get any new tasks to work on at all this past sprint. What was nice was that we got plenty of time to familiarize ourselves with angular and testing. Reviewing testing was important because, for the upcoming tasks we got, we’re trying to figure out whether or not we’re going to be using mocking or a real database with random values for our “back-end” data. If we go with mocking as AMPATH has suggested to us, then our time spent learning testing with Angular over this sprint will be put to good use. I’m also pretty thankful for my Software Quality Assurance and Testing course that I took last semester, because that went in depth about a lot of these same topics.
Overall, Sprint 2 was fair uneventful. However I feel as though my team got more accustomed to working with one another and got a bit more comfortable with each other, too. So for those reasons, I think that it was a positive sprint. I’m excited for the next few weeks of Sprint 3 so we can start working on some coding!
There was very little productivity during this sprint due to minimal work assigned. To keep busy our team used the time to learn about angular and testing in angular. One method that helped me learn more about angular was to do the Tour-of-heroes tutorial on the site. After doing so I understood why angular was used and what components really were and how they responded and “talked” to each other.
The final day of the sprint, we were given assignments that included creating the GUI of some sort of web application. Our team sat down and decide which interface we wish to move forward with. Before doing so we actually looked into what programs we were going to use and watched some YouTube videos on the instructions.
This is the Sprint 2 Retrospective for team The IncreEdibles. We got assign to food pantry development, but we didn’t give any specific task. Big part of our team is design program and listen to the food pantry owner. There are two projects that we are working on, one is the make API that support other project where they can pull any information that they want. The other project is to work with Worcester State University food pantry.
As a group we decided to focus on WSU food pantry since we see more potential in this project. First, we want to know what the important features that costumers want. We learned that setup with costumers is not easy, not just to set the time and place for meeting. We have setup our communication on Slack, but most of the costumers are not in tech they don’t want to install complicate software. They want to have program where simple “plug and play”, so their energy can focus on what important to them. This is the problem that I think we always face with customers. We as developers before the meeting need to have set of question to ask, not all customers know what they want. We had meeting with Joanne, the professor who run the program. She wants to know who goes in and how much they take out the food, keeping track with the amount of food (by weight) is the main feature.
We took notes from the meeting and make email as direct communication that convenient for both parties. These features are important, but we must think of the design future features as program getting update. Features that they don’t think they need at this moment, that mean we must track data. These are sensitive data, we must be caution. The features seem not difficult as keep up with the weight of the food, but we want to have reliable program where it’s simple and easy to prepare/add feature.
There are few techs that our group need to know, OneCard swipe machine, we need to know that it is operative and how to implement to our program. How to export from the “sign up” Google Form. Export form that the costumer can export to submit to Worcester Food pantry. And most important is design our program where it is simple, clean and it do what it’s supposed to do.
Our next step is researching all the techs to make all priority feature work. Make a mock program, and present/sell it to the costumers. In this sprint we want to know how far we can get this program to work. There is other group in different section also look at this program, our problem is time difference and communication. If they have the same direction as us, we should find a way to divide the program into two parts that two group could work on. We find that the communication is one of the biggest problems even with members in the same group.
For this past sprint we didn’t really accomplish all the much since we had no work provided to us. One of the biggest accomplishments was getting the ngl serve and ampath login working for myself. Kyle was running into the same issue I was having and the problem was easily fixed thanks to him. All I had to was go down a version or two to npm version 8.12 somehow that worked while other fixes did not. After this we reviewed some angular and had a week of review essentially. Then yesterday we were given new tasks to complete from the project lead himself. Now we have a direction of what to do for this sprint given to us through several YouTube videos made by the project lead. Each video contains specific details on what we must accomplish/what is needed to essentially full the order. So in summary not much actually happened since the last sprint due to not having any new work given. Looking forward to working on this project in the coming weeks with my team where we will hopefully tackle each problem/objective well as we did for the initial problems.
