Author Archives: Nathan Posterro

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.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

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!

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint 3

This week wraps up sprint 3. During sprint 3 we accomplished a decent amount of things. Most of the stuff that occurred this sprint was done on the backend and setting up of git repositories for both the font end and back end. Over the past two sprints we have been able to complete most all of our sprint backlog tasks. This sprint was no different. We decided to use this sprint as a stepping stone to try and figure out if we could handle some more complex product backlog objectives such as developing a REST API and figuring out how to work on features such as food expiration tracking and timing (this is based off of a federal calculation and standard). For this sprint I took on the task of working on some front-end related stuff. At the beginning of the sprint we had a back end and a very sparce front end. I decided to take into my hands the task of designing the front end using HTML and CSS elements. A large advancement that I feel we made as a group this sprint was getting the google docs intake form for Thea’s Food Pantry translated over onto an HTML format so that we can connect it up with out front end and host it on our repository. From last sprint I had a worker screen mockup done completely in HTML with no CSS elements as well as just locally on my machine and not able to be seen/shared with the group. This was a major issue for me as I wanted to be able to share my progress with the group so that they could comment, contribute, or discuss any potential areas of concern. What I had hoped to do this sprint was add a task onto the sprint backlog to have us figure out how to transfer all my HTML worker screen work over to the repository that hosts all of our front end stuff. Unfortunately I was not able to complete this task this sprint as more front end design tasks came up that I felt were more important than transferring over a mockup file. One very interesting thing I learned about this sprint was online CSS editors. I can make my way around from scratch in an HTML file but CSS is a different story. CSS is a more complex almost add-on type language for basic HTML files. I was told about this online editor called Zeppelin.io that supposedly let you draw up wireframes within the application and then translated it to CSS for you so that all you needed to do was copy and paste into your actual project. Unfortunately, this application is a mac application and thus didn’t want to work with my windows machine (even though it had options for a windows download, I was unable to create any files from scratch without photoshop!). My next solution was this editor called stackblitz. Unfortunately it’s quite the opposite of the idea of zeppelin.io and is instead a real time online CSS HTML editor (things that you code are automatically compiled and displayed on a terminal). So even though it doesn’t give the CSS code, I was easily able to google how to write different CSS methods (buttons, how to call CSS methods in the HTML doc, etc) and it has been good so far. Now we have a wireframe to show the customer without having to commit it and push it to our repository. The best part is that stackblitz also works hand in hand with github so our repository is connected up to stackblitz and we can commit our changes to our repo without having to migrate all our front end files!

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Record What You Learn

For this week’s blog I decided to write about the chapter “Record What You Learn” from our textbook of software apprenticeship patterns. The context of this pattern is that you learn the same lessons/ideas/things over and over and over again but you never seem to retain the information or you retain it for a short period of time and then forget it. I personally find this to happen to me every so often. Sometimes in class we will learn a lesson and I will not retain the information and when it comes time to use the information we learned or to prove our knowledge of the subject on a test or examination or project (some form of graded material) I will draw a blank. This is extremely frustrating because most of the time I know that we have learned this topic and that I was in that lecture but somehow someway I have forgotten what that thing we learned is. The problem being set up by the book is this; You don’t learn from history or historical mistakes and you are doomed to this repetition of failure due to your lack of discipline to take notes or record what you learn in a way that you wont forget it. The solution to this problem is rather simple; record what you have learned. Do it in some way that sticks with you – a way that makes sense for you. Two different people might have two different ways of remembering information. Maybe I can write notes down in a journal from lecture and be all set whereas my classmate (let’s call him Jim for the sake of conversation) can’t retain information from reviewing basic lecture notes. Maybe in order for the information to stick with Jim he needs to do it hands-on a few times. Once he does it himself physically he will remember how to do it because he knows he’s done it before and has the confidence he’s done it correct in the past. I hope to improve my retention of knowledge by finding more avenues to retain my information as opposed to just relying on lecture notes.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

For this week’s blog I have read the “Learn How You Fail” article of the textbook. The context of this chapter is failure is inevitable, how will I learn from my failures to prevent them in the future? The context set up for the problem is that we learn from our successes and we are successful because of our successes but we also still suffer from our weaknesses and our weaknesses lead to failures.  This rings true with me as I understand that I do not know everything there is to know about software and software development. How I view this is to learn from my failures and learn how to prevent them in the future. I understand that I will fail eventually, as I do not know everything. I understand that I also will learn from the mistakes I have made and the failures I have encountered and I will lean how to prevent them in the future so that I will never have to see the same failure twice in my career. The solution that the textbook is proposing for this is try to identify your failures or areas that your fail before you do fail. Being a self preventative at failing will help myself not encounter failure as much in my future. One point that I really enjoyed was learn what trips you up and become conscious of it. This is a great way to prevent failure because if you encounter or something or know you will soon encounter something that often tends to get you to trip up, hopefully if you realize that is coming down the line you will have ample time to correct the issue before it becomes an actual issue that will result in failure. If you are able to avoid this failure, then you can consider yourself successful. And as we learned earlier, we learn from our successes and we are successful because of them. When we avoid failure we can consider it a success. We need to understand that we cannot become crippled or frustrated by our fear of failure. We have to understand where we fail and learn how to stop ourselves from failure instead of fearing it until it strikes. I have learned a lot from this article and I hope to avoid failure in the future by using the skills I have learned here.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.