This week wraps up sprint number six, as well as the semester. This is our last sprint before the semester ends. Some of us, this is out last semester in undergraduate. Many of us will be graduating after this sprint ends. This sprint for our team was nothing entirely too fancy, it was more of a wrap up. Since we realized we were running short on time, and with a presentation of our final project looming just around the corner, we decided it would be best to stop the pipeline of taking in new tasks to work on. I was able to take on one small task in the end, just before we put a halt on work. This task was to add an optional field for gender into the intake form. This was a rather simple addition as I was able to reuse most of the HTML from another part of the form. The majority of the scratch work was done in the Customer.ts and the Customer-form.component.ts classes. In the customer class I had to add gender as an instance variable so that our customer constructor would know that it needs gender as an argument (needing it is specifically for testing purposes, the actual prompt is optional, per request of the food pantry owners). I then had to go to the customer.form.component class and add an array of options for gender, as this prompt would be a pulldown menu option. I was able to create an array of gender options called gender which had the values of male, female, other, or prefer not to say. This way there are enough options to cover the spectrum while also being able to keep the question entirely optional. Once I did this I had to add the gender paramaters into the Customer objects so that it would build the customer correctly. This was the easy part! The hard part comes next. Branches, and pull requests. I was easily able to check out a branch in our repository to get my issues and commits tracked on github. The hard part is the pull request. With the initial pull request, there are many conflicts to be resolved. This is expected, because you’re comparing an old file to a new file that has deletions and insertions, and code moved around. This is typically an easy fix as you can just go in text editor in github and remove the conflicts by hand and recommit the changes right on github. I have done the old fashioned way of running git commands in terminal to fix conflicts, and I find the in-browser option to be the more efficient and easier solution (if it allows, sometimes it isn’t as simple as removing a few lines of erroneous content on github). What happened next is the funny part. In the time I opened my pull request, notified my professor, and resolved conflicts, my professor merged another open request on our repository. Now I was getting no errors (because I had not refreshed the page) but my pull request would not merge. My professor and I were looking specifically at the customer constructor and were wondering why his master version had 18 variables and mine only had 14. After thinking about it for a while, I decided to pull from the master branch then recommit my branch, again fixing all the conflict resolutions. This appeared to do the trick, because I was missing the information from the merge that occurred while I was trying to get my branch merged. This goes to show you that communication is imperative on github and in teams of multiple developers working in the same place. Knowing this would have turned my 5 minutes of code and 45 minutes of trying to merge onto github into 5 minutes of code, a simple merge, and a new task. In the period of time between putting a stop to work and our final presentation, we as a team worked on our final presentation slideshow. We did this as a requirement from our professor, but also as a way to recap all that we have accomplished this semester. Looking back, it has been a fun semester getting to work on a project from scratch and seeing how far we could get. I hope the next food pantry teams have a good starting point, and will continue to do great things with the software.
For this week’s installment of individual apprenticeship patterns I have decided to write about the chapter of our textbook called dig deeper. The reason I did this chapter is because it initially caught my attention with its relatability. The catch with this article was that you have a superficial understanding of different software tools. I find this to be extremely relatable because we see a lot of different tools in our classes and at the same time we don’t have much time to cover the tools and master them. I think in my testing class we were using a new tool every few weeks, which really hurt us in the end because I did not have a chance to fully grasp or understand how the tools(s) worked so I have a very superficial and not very deep understanding of these tools. I could probably use them if I tried hard enough and used google to assist me in my journey. I wish that one of two things happened. I wish we had more time to understand these tools or I wish that we did not cover so many tools, however I do understand that we need to cover many tools because there are many tools out there that are constantly changing and they are always making new tools too. The solution to the problem of not understanding the tools or having just a superficial knowledge of the tools is simple. You have to study and learn the new tools. It kind of sounds intuitive that you would have to spend time to learn the tools, but you really have to spend time to learn the tools. This means doing homework outside of work and being able to understand your learning in these tools. By this I mean not just simply taking an online tutorial on a software tool that you well and fully know will cut corners in attempt to try to make the tutorial more understandable and faster. This may seem good in concept but they are leaving out pertinent information that you need to know to master the tools.
This week wraps up sprint number five. This was our second to last sprint which is kind of crazy to think about. It feels like we just started! Unfortunately we also believe this means we are not going to be able to finish all of the product that we had hoped to. We were not necessarily expecting to finish an entire project form scratch at the begining but we had been making some extraordinary progress over the past two or three sprints. As it stands now we have a (mostly) complete intake form for the food pantry owners to use. It is missing a few fields that they would like to see, however the base version of the sheet is complete. The base version is the current intake form that they gave to us to translate from paper to application. What we are working on now (and calling “incomplete”) is the extra features or new fields that the food pantry owners wanted added to their base version of their current existing intake sheet. For this sprint we got our repository fixed. It had some underlying issues with the way that it was set up that prevented us form achieving progress to the fullest extent (see sprint 4 blog for more information on our wacky repository). Once we got into our new and restructured repository we started back up on work. For this sprint I took out the task of implementing a zip code feature to add to the intake form. To do this, I created a new branch separate from master on our repository and called it zipCodeFeature (git checkout -b zipCodeFeature). The next thing I had to do before working on this feature was to create an empty pull request on our parent repository in order to track my progress and commit history. In github I went to our parent repository and created a pull request from my new branch. Once I have finished my work and am ready for it to go onto the permanent repository I can ping a member of that repository with write access to review my pull request and implement my feature. What I did from there was begin working. Creating the zip code field on the form was rather easy. Since we have a bunch of other similar fields on the intake form I was able to reuse the HTML for it, leaving me to only have to change the ng.model and variable names. For this one I used the “studentID” field and changed all the studentID references to the new zipCode references. Next I had to go into our customer.ts file and add zipCode to the list of instance variables for our Customer object. After this I had to go to the customer-form-spec.ts file (this is where the customer object is constructed and there also is another customer object that we are using as a test subject in that file) and add the zipCode fields to both of those constructors. Going back to the main HTML page for the form I had to add a method at the bottom which relates to the second page of the intake form and saves the information. Again, I was able to reuse some methods that were already existing in the file. I then proceeded to test the zipCode feature and it worked! There was a catch though. The pantry owners wanted a feature within zipCode where if the student chose resident as their housing then the zip code would default to the campus zip code. I spent a good week or two trying to figure this out with *ngif() and other angular statements. Since the sprint ended and it is getting very close to our final class I decided to scrap that task and push my commit with a working base version of the zip code feature. All it is missing now is the auto-fill functionality. My plan is to take out a pull request within our repository to merge my branch to the master branch and hope that someone else may have a solution for me as to why this auto-fill feature is not working while they are reviewing my pull request.
Hello there! For this week’s blog I have decided to write about the chapter of our textbook called “Sweep the Floor”. The chapter caught my attention because of the small description of it. The description of the chapter was something along the lines of you are a new member of a software development team and you need to gain their trust. This is something that intrigued me because I will be starting in a software development team as a new member at the end of May, and I am not quite sure what to expect. I have never worked in a real-life software development team, let alone develop software full-time 8-10 hours a day 5 days a week. This chapter was something I was hoping would help me when it comes time to integrate myself into my new team come May. So the problem that’s set out in this chapter is basically the same as mentioned above, the team doesn’t know you, you don’t know the team, so how can you find your place and find out how you can contribute best to the team? The solution is somewhat elementary and what some would think of as common sense. The first part of the solution is to volunteer for some small, perhaps even mundane task that either nobody else wants to take on or is too busy to take on. Sure, this isn’t a task you went to college for four years to complete. Maybe the task is transferring some physical data into excel, or updating computer software around the office. It doesn’t matter what the task is, what matters is that by taking the initiative and volunteering yourself for the small day-to-day not so glamorous tasks, you are slowly gaining your teams trust and finding your place on the team. They will appreciate that you are taking a step forward and doing things that need to be done; getting in the trenches (so to say) and eventually this will lead to your team trusting you to take on bigger tasks that are more normal for a software developer like pushing things to production and writing major elements of a program. I hope to use this tactic in my workplace to quickly assimilate into my team and find my place.
Hello again! For this week’s blog I have chosen to write about the chapter from our textbook entitled “Practice, Practice, Practice”! The reason I chose this is because I saw it in the table of contents and it looked like something relateable and interesting to read. So without further ado, let’s jump on in to the chapter “Practice, Practice, Practice”. The problem set up by this chapter is that you are always switched “ON” which never gives you a chance to learn from your daily programming mistakes. The book says its almost as if you’re always on stage. I feel that this can happen easily especially in a fast paced work environment like software development. Things in this field are always growing and changing and twisting and turning. Monday you might get assigned a project with requirements ABC and by Wednesday those requirements have changed form ABC to XYZ and the project now no longer holds any resemblence to the original project. In this case it is quite easy to get lost because you don’t have time to learn from your daily mistakes if you’re always trying to play catch up. The solution set forth by the book is interesting, however quite elementary and almost common sense. The main objective of the solution is to practice coding in an environment with zero pressure and in a place that you are comfortable and it is okay to break things. In other words, make a personal project at home or someplace other than work where the end objective does not matter, there is no customer or end user on the other side, and you can be free to break things and learn why they broke, then fix them at your own pace, allowing you to learn more so than if you were to be pressured and rushed to fix breakages in the field. There are many different ways to practice without interruption at your own pace where the actual environment does not matter. I think that it is one of the strongest ways to learn. Not only because you are teaching yourself (because you know how you learn best!) but because the environment in which you’re learning is truly stress free and problem free. Did it break while you were working? Who cares! It isn’t effecting anyone other than you. So take your time, work through the breakage, and fix it at your own pace and learn why it broke and how it was fixed!