Sprint 6 Retrospective

This week I will be talking about our last sprint. This sprint may not even be done yet since even now, some of us are still trying to work on the issues on git hub. This sprint is unlike the others, I think we actually accomplished more during this sprint. As I have said before, most of our past sprint consists of waiting for the customer to respond or try to plan something for the intake form but then have to change it because the customer does not need it.

During this sprint, I worked on fixing the student ID of the intake form. The student ID field was getting the input as a number but there is a problem with a number as an input. The first problem is that a number can not start with a 0, it will only start at 1 or any number that is not 0. Our actual student ID starts with a 0 so that would not work. The other problem is that we want to capture the student ID after a student swipes their card. After turning the student ID input field into text, I had to then remove all the unnecessary characters that are inputted by swiping their OneCard. This can be done by using the slice method that is from javascript but you can use it in typescript, I think most javascript functions can be used in typescript. The student ID that we get from the card reader is in the format of “;0000111111100?”. The only characters we want is from 5 to 12, which is the actual student ID that you will get from OneCard. Then, I tried using the function slice to get only those characters.

After turning the field into text and slicing the character, I was able to make it work by adding the following code into the onSubmit function since I only want it to happen after they submit the form so that it would look clean on the database.

Code inside onSubmit: this.model.studentId = this.model.studentId.slice(4, 3);

The next thing that I did was to create a way for the food pantry to be able to enter the student ID on their own. Sometimes students might not have their OneCard with them. So, I created an if statement in the onSubmit field, I did not want to do it on the actual form with the ngIf  because it gets messy with the ng-template stuff.


if (this.model.studentId.charAt(0) === ;) {

    this.model.studentId = this.model.studentId.slice(4, 3);


This was the final code that I pushed into master. I was actually working on other things, like checking if they entered a letter, if they did, create an alert.

This sprint was very interesting to me. I learned a lot of things. The thing that stuck with me the most is making sure that the field would only take what it is supposed to. After working on it, I would like to add more stuff to check the ID field, like if the length is greater than or less than 8 then it is invalid if it contains other symbols that is not
“; or ?”. There is still a lot of work to do for the intake form but I enjoyed it.


Sustainable Motivation

For this week’s blog, I chose the Sustainable Motivation pattern from the Apprenticeship Patterns book. The Sustainable Motivation pattern is about keeping your motivation while working in the industry. While working in the industry, things can get tedious, real projects are more rigorous and can be exhausting and often frustrating. As an apprentice, you will encounter these problems while developing your technical skills. You will often find yourself working in the messy specified projects for customers with the always changing demands.

Of course, there are times when you love your job, and your ability to write code seems too good but they will not be your ordinary days. Most of the time there are going to be nasty problems, bugs, and to add to that, your manager wants it soon. That is why you gotta stay calm and focus on the long road. You will most likely stay in the craft because of money and would try to endure the long road. While sticking with it, you then find your love for programming returns. It is going to be a cycle of love and hate relationship. Many programmers get trapped by their motivation. Learning something new gets harder and you see no point in doing so when you are already getting paid for the things you already know.

I totally agree with this pattern. There are going to be an up and down moment while working, I’ve already experienced this problem with my current internship. As an intern, they do not really expect you to do a lot. They do not expect you to actually contribute much to anything they do but expect you do to what is minimally expected of you, and most of it is learning. In my internship, I usually finish the task that was given to me earlier than expected. I would always try my best to finish it without wasting time, and always check with my supervisor if it is what they wanted, but sometimes they are also busy or are not around so I am stuck there with nothing to do. What I do in such situation is go to another department or another employee, then I would always ask if there is anything I could help them with and try to learn new things.

Sprint 5 Retrospective

This week’s blog is about our fifth sprint. During this sprint, we were finally being able to start tackling the issues that we have created. I learned a lot during this sprint than the previous one. In the previous one, we were creating issues pretty much left and right, placing them in our task board and then people work on it. The problem is that these tasks are not really assigned to anyone, and you can have two people working on the same thing without them knowing. This made it hard to keep track of the people working on an issue.

During the planning phase of this sprint, we planned on finishing the front end of the food pantry form. We tried to finish talking about what styling to use and what should the form look like. We also planned on adding more attributes or questions to the form since the main purpose of the form is to create a report every month that they could send or submit to the Worcester County Food Bank. The initial form only asks about the student ID, SNAP assistance, housing status, government help they are getting, and the number of household/income level. The last question was very vague since it only shows letters a through h, but no context on what they mean. Then there are the attributes that need to be added to the form like zip codes, participation in federal programs, primary household income source(household number of employed, unemployed, and other categories), and ages in the household that is served by the food pantry. These need to be added to the form to create the report.

The second meeting in our fifth sprint was comprised of fixing how the issues are laid out and what issues are still needed to be published. During this time, we were still organizing the issues that were put on the repository. The other team kept on closing issues that are not yet resolved, or maybe it was but it was never pushed into the repository, creating duplicated issues or issues that can be placed into one issue since they both pretty much mean the same thing. We also tried to organize the branches that were created. There were multiple branches created that are not working and we did not know which is the correct branch that we could work on since communication with the other team is not ideal.

During the second meeting still, I tried working on how we could correctly store the student ID field from scanning it using the card scanner. The original format of the student ID when scanned is something like ;0000111111100? but we only need characters 5 to 12. When I looked around for functions that I can use in angular, I found this javascript function called slice which slices the string given the position of the start character and the end character. I wanted it to slice the student ID when you submit the form so that it would be stored as a proper student ID so I thought I could just write this.model.studentId.slice(5, 3) and it would do that when you submit the form then show it in the submitted form, but it did not work. Although, using slice on the html file actually does it. I think that since it is a javascript function, that may be the reason why it is not working, I would definitely need to test it again and hopefully have it working during the next sprint.

Craft Over Art

This blog is about another pattern from the Apprenticeship Patterns book. This pattern is about Craft Over Art. Choosing whether to add that extra feature that you think will impress your colleagues rather than focusing on what the customer specifies or want. This problem would occur to you more than you would think. We are not just programmers we are also artists. Creating beautiful, unique and creative applications are all within us, but if you are working for someone else, you might have to forgo of your creativity.

The book suggests focussing on delivering value to the customer rather than advancing your own self-interest. As a craftsman you are primarily building things in terms of the specification, working under someone and not indulging in your creative self. As craftsmen, we work for the customer. You need to do your best work in ways that place the interests of your customers over your desire to display your own skills or pad your resume. The book even says “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.”  They said that the things we build for customers can be beautiful but it must be useful. That part of the process of maturation is developing the ability to sacrifice beauty in favor of utility when it becomes necessary.

I am split on this pattern. I kind of agree that we should do what the customer has asked us and enhance its quality, making it a software that can do almost everything that they needed. But, I also think that you can still practice art even if you are working for a company. You can inquire on your customer and see if they like what you are trying to do, but then again I see how this can conflict with the other software developers. Since you are not the only person that would be working on a project when you become an apprentice, there are things that others would think is not necessary to the software, so there definitely going to be things that gonna have to be agreed upon.


Sprint 4 Retrospective

This blog is about our third Sprint. This sprint is a bit better than the last one. I finally think that we are making some progress towards the Food Pantry project.  During this sprint, we did a lot of organization and more planning. We have decided to put our board into Github.

We created a project board and created issues on github as sprint backlogs or product backlog. This process was not easy since I do not have much experience with creating issues on github. I also find it weird how we create issues and use them as a story, but it is actually pretty efficient when you got a couple groups working on a project. During this sprint, it was a little tough how to separate what is an epic, a story, or a task. We were deciding in the group what is considered a story or a task. Most of the story we made had to be broken into a task so that it is more descriptive.

Another thing that kind of made it hard is that we need to create issues in two github repositories. There is the internal repository for the cs-448 students only which are the two group and there is the LibreFoodPantry which is more for the more serious issues and is available to others. I was not sure what difference is written in the LibreFoodPantry and the cs-448 repository. For now, I think it is mostly tasks that are put on the groups repository and the major stuff like one card scanning are placed into the public repository.

Lastly, we got ourselves a magnetic card reader. We are gonna be using it to get the student or customer’s ID from their OneCard and use it to find their information from the database. It will be stored along with their information. If an ID does not exist in the database, we would prompt them to fill out the intake form. Then we store these attributes into a database. I think we should try to design the database along with the food pantry’s front end. Since it feels like there is not enough task for everybody to do, I would probably try to make a rough draft of database design.

In this sprint, I learned more about agile development. This time we are doing it in github by creating issues. I also learned that I should always try to break down stories that are very vague and making tasks from it. I also learned that the process into creating a project is not as straight forward as it seems, there is a lot of things that have to be considered like which programs to use, what server, and other little things that make up the project. This time, we actually got our hands to a magnetic card reader where we could swipe the OneCard to. We figured out that it takes the ID number that needs to be formatted before it enters the database. Hopefully, we can manage to get it working during the next sprint.

The Long Road

This week’s blog is gonna be about “The Long Road” pattern. This pattern is all about traveling the long road. No matter how much you try to master anything, it will always be ahead of you. Mastery is a lifetime journey. You got to love whatever it is you are mastering. That is why they said, “Choose a job that you love and you’ll never work a day in your life.”

The book suggests valuing long term growth opportunities over salary and some sort of leadership or managerial role.  This long journey to become a master will bring you a rich set of skills. You will become skilled at learning, problem-solving, and developing a good relationship with your customers. You will learn to wield these abilities and technologies. If you go through this long road, you will realize and appreciate what being a software developer really is.

This journey would not be short. It will be a long winding road. You should have a goal. Being on this long road, you will be a software developer even when you’re old. This pattern is not gonna make you filthy rich like the other positions, but it will be rewarding. This pattern is not for everybody, there are more people who will take a higher position without blinking an eye. Everyone wants to achieve something big and probably make more money.

I don’t really agree with this pattern. I think that taking the promotion would be a better path. It is not every day that a promotion would happen or a better position would be available. So why not grab the opportunity. It will also teach you more skills since it would it is a different role, it will also have different responsibilities. You will also learn how everything is run in the company and not get stuck at just creating software. They do talk about in the solution, that this long road does not only apply to being a software developer but for any position.

This pattern is good if you see yourself doing the same thing 10 years from now. Although, in my opinion, that is not a good thing to do. I think we need a bit of variety so that we do not get tired of it.

Sprint 3 Retrospective

In this sprint, our group was divided into the Food Pantry project and the Foodsaver REST API project. Joshua was mainly working on hosting the Foodsaver REST API in Heroku. While the others were focused mainly on the Food Pantry software. I, on the other hand, was kind of in between both projects, trying to help out on the Foodsaver and at the same time help with planning the Food Pantry project. Our first meeting was pretty much figuring out what are some stuff that we are going to need to proceed on building software for the Food Pantry. We have decided that we are going to need the forms that they were using. This form is the one students would fill out during their first visit in the pantry. Since they were using Google Sheet to store all the information about a student that visits the pantry, we have also decided to take a look at a way to use Google Sheet API to connect to the software we are going to make. We have also decided to make our own Google Form mock just to see if that was all the information that we needed.

In our second meeting, it got a bit interesting. Remember how we were waiting for them to send the Google sheet mock with the attributes they want to collect? Well, we never received it before the break, and then they probably forgot about it during the spring break. After the break, I got occupied with trying to run the Foodsaver API and helping Joshua dealing with Heroku. Since Andy was the one who wrote the code for it, we weren’t quite sure how he set it up, but the Heroku hosting seems to be working. The Foodsaver API would appear when you go to the address Heroku gives, but when you click on the API, it does not return anything.

This sprint was somewhat uneventful for us I might say. There was a lot of waiting for the client, and a bit of miscommunication. This sprint was about patience. I learned that communication is really key to working on successful projects. There are going to be times when you would have to wait for the client to get back to you since they keep on forgetting to send things that you need to even get started. There was a lot of wait time for us, and we just kept on planning, trying to figure out ways to proceed with the food pantry project. If something like this ever happened again, I would probably not stop bothering the customers until we get what we want so that they can get what they want, and hopefully come to an agreement.

Retreat into Competence

For this week’s blog, I am going to be talking about “Retreat into Competence” pattern from the Apprenticeship Pattern book. This pattern is about realizing how little you know, or when the new challenges that you have taken are not working out so well.  As you work, there are going to be many projects and challenges that are gonna be assigned or you are going to take. Sometimes, these challenges can be something you have never done before, or it might be a roadblock that you are gonna have to clear and these challenges are making you realize how little you know.

The book’s solution to this pattern is to “Pull back, then launch forward like a stone from a catapult.” They said that you should retreat briefly into what your confident on doing and regain composure. Take some time to build something that you know how then use that experience to see how far you’ve really come and measure what else you are capable of. Being an apprentice there is going to be a lot of ups and downs. You will experience learning new technologies and use it to leverage your knowledge that would deliver value to your customers. But you will also experience terror, roadblocks that seem impossible to pass through. These challenges can be overwhelming at times but it is to be expected if you want to progress.

I totally agree with this pattern. There are going to be times when you will encounter problems that seem to be unsolvable or problems that will show you just how much you actually know. In life there are going to be problems that seem impossible to solve, we get overwhelmed and try to forget about it, which becomes a bigger problem. I like how the pattern suggests that you look back on what you know how to do first.  It will show you how far you’ve really come. This process might give you hope that no challenge is impossible, you just gotta go through all the learning again.

The Deep End

For this week’s blog, I am going to be talking about The Deep End pattern from the Apprenticeship Pattern book. The Deep End was about taking that big step in your career. Grow your skills, your confidence, and your portfolio. Challenging yourself with bigger projects. This may involve new tasks, new teams, and new places.

The book suggests that you dive into the deep end. Waiting for opportunities until you’re ready will only set you back and be stuck doing mediocre work. So, if offered a high-profile role, take it. Growth only happens when you do something. But of course, there are risks involved in taking on bigger projects or high-profile roles. If you get it wrong, instead of growing, you might shrink. It might destroy your career as a software developer. But the risk is also the only thing that can help you grow, so take the risk with caution. They also suggest that you list down all the projects that you have done. What is the biggest successful project you have worked on, and the biggest codebase you have built on your own. After writing them down, use them as metrics to measure if you are going to be ready to take on a bigger project with more responsibility.

I found this pattern very interesting. Not because it is something new but it is something that I can relate to. I am usually the kid in the back of the room. I usually only do what is expected from us and do the minimal thing to pass or get a good grade. Whenever there is group work, I almost never volunteer to be the leader. I do not like having to bear that responsibility. I am scared that I would do something wrong and let down the team. Scared that I would not be able to do my role as a leader. Now, I am trying to change that. I am trying to get more involved when it comes to team projects. I am now trying to lead everyone when they do not know what to do. I try to make a decision that everyone can agree to. This pattern did not really change the way I work, but it reminds me that I still need to improve with being a leader.

Sprint 2 Retrospective

For this week’s blog, I will be talking about our second sprint working on the open source food pantry project. This sprint was a bit unique as to the first one since it is mostly about communicating with the customer.

In this sprint, I learned a lot about the communication between us, the developers, and the customer. I learned that it is not a simple process. At first, I thought that it would just be a simple interaction, they give us what they want or how it should look like, and then we try to create it and meet their demands. But that is not how it goes at all. There was a lot of interaction that we needed to do since the customer does not know what they really wanted. There is also the issue of communication. Most of the time, it is hard to get hold of the customer and we have to wait for them to respond to us before we could even move on with what we are doing. I also learned that starting a new project is like an open-ended question. while planning on this project and asking the customer questions as to what they want, it just seems like they do not really know what they want.

During this sprint, we have decided to change our focus from making the foodsaver REST API onto making the food pantry software since the other team has already made it. This sprint was mostly about communicating with our customers. The first meeting with the customer is with Serena. Serena works on Thea’s food pantry and knows how the pantry operates.  During the interview, we asked how the pantry operates. They have a google form that is filled out once by every student that goes there. It asks about the number of people in their household, their income level( whether they qualify or not), and what kind of help or services they are already receiving. If they already filled out the form, they only need to swipe their card preferably but for now, they just take note of the student’s ID number. Then they weigh the items that are being taken by the student and record it. They only keep track of how much weight is taken and how much weight is left on the pantry. 

The second meeting that we had was with Joanne, she has been helping guide the student-led-food-pantry initiative. Before our meeting with her, we tried to come up with questions to ask. Most of the questions we came up with was just a clarification on the information we got on the first meeting. In our meeting with Joanne, we asked her again about the forms and what kind of information they are storing. Since they cannot give us private information, we asked if she could just blur out the pieces of information and leave the column headers. This meeting was mostly trying to learn what the food pantry does and how they get food in and out. This meeting also opened the topic with the one card system and how they want it to show information about the student once they swipe.