Sprint 6

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.

The White Belt

For this week’s blog I have decided to write about the chapter called “The White Belt” from out textbook. The context of this chapter is that you have developed a deep understanding of your first language but have plateaued and you are rather comfortable with that spot. I find this to be exactly where I am now. I have spent four years writing in Java a majority of the time. I would say that Java is the language I feel most comfortable in, and have the strongest understanding of how it works. Other languages that we have touched upon in my college career such as C and typescript/javascript, I am not as comfortable in because of this lack of depth of knowledge in these languages. This leads us to the problem portion of the chapter, which is that we have problems gaining knowledge of new things when we are coming from a position of comfort. The book points out a fear of personal development coming to a halt, and I think that rings true with me. I am afraid that once I leave college I will not learn as much as I need/want to. I am afraid of being a “one trick pony” with Java. What if my job requires me to code in C? C++? Any other language? I feel right now in this minute that if this were the case, I would be able to get by, but just barely and not very comfortably. And that is a feeling I do not want to have every Monday through Friday in my career! So how do we fix this issue of complacency? The book starts off the solution with a quote from Star Wars, which I thought was genius. The quote is, “You must unlearn what you have learned”. Now this doesn’t mean go and forget Java and all of its syntaxes and learn another language completely. This means unlearn your learning habits, keep your knowledge of Java but also learn to gain a knowledge of another language. Keep doing this, and soon enough you will be a master of programming. I find this solution to be rather comforting as I also find myself in this position of plateau quite often. I am hoping to continue my education of coding long after I leave college.

Dig Deeper

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.

Sprint 5

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.

Sweep the Floor

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.

Sprint 4

This week wraps up our fourth sprint in our software development capstone class. This sprint saw a lot in the way of front end development. One of the large tasks we were able to complete during this sprint was figuring out how to store the data that was entered in the intake form sheet using a local javascript  server that can be run through the terminal using angular. This was developed by Johnny and was attached to the front end file folder where it now lives. At first we were working in the original repository and had the project all together. This seemed fine at first but we quickly realized that not separating the repository into frontend and backend sections would prove to be a major problem down the line. We ended up having to fight with ourselves every time we wanted to run or even open the project because files were crossed and mixed up because we did not have proper file directory setups. One major problem I found right off the bat was not being able to run the front end of the project because I would get an error message in the terminal saying something to the effect of “You must be in an angular project to use angular commands”. I encountered this error after trying to run ng serve –open to get the project running. I was in the root directory for the project, where I should have been. After doing some extensive trial and error testing my groupmates and I figured out that the terminal had to be run in a subdirectory (in this case intake-form-master) which was below the root, scr, and app folders. While I thought this was strange I didn’t think much of it because it ran and it worked. We should have looked into this more because it turns out we had a massive issue. Though our project was in github and therefore a “git” project, we somehow were lacking a git.ignore file on the very top level of the directory. This went unnoticed, and ended up becoming a massive issue. It seemed like every time I pulled the most recent version of the repository I would have to scrap what I had before otherwise I would get all different kinds of error messages. This was annoying due to the fact I would have to wipe all the project files off my local file directory and then clean install from github just in order to get it to run. After a long discussion with the professor and a good hour of troubleshooting and head-scratching, we figured out that our big issue was coming from this missing git.ignore file. The basic gist of this major file is that since it was in a subdirectory and not on the top level of our repository, every time someone pulled or made a change or did anything to/with github, everybody’s local machine paths were being pulled onto your personal machine with every clone or pull of the repository. Since no two path setups are the same between machines, you would get a – for lack of better words – big spaghetti mess of pathing and branching and basically git would freak out and it would give so many errors because it was having trouble figuring out where to push/pull/do anything. To remedy this, we ended up going with the nuclear option and eradicated the old repository, set up a new one with the most current working version of the project, and had our professor merge our new repository with the parent organization. This time around we have a git.ignore file at the top directory to ignore all those different paths and other things that were confusing our terminals, and we separated the project into frontend and backend folders, which are proving to make the workflow process go much smoother. At the very end of the sprint we had planned a meeting with a food pantry representative, which will occur during sprint 5. Next sprint we hope to see some major advancements.

Practice Practice Practice

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!