Author Archives: Nathan Posterro

Sprint 2

This week finishes up sprint 2 of our senior software development capstone project. In this sprint we accomplished quite a bit. The most important advancement that we made in this sprint is getting specifications from our product owner as to what we need to do for them. At the begining of this sprint cycle we were able to meet with a representative from the food pantry, Serena. Serena was able to tell us more about the food pantry and what they are doing as well as what they would like to see as a product from us. One of the biggest takeaways from this meeting was to realize that the main objective for us is to assist the food pantry in their quest to transfer all their business and business operations from paper to digital. One of the largest problems we realized off the bat is that the food pantry does everything from data storage to daily operation by paper. We know as software developers that this physical paper way of doing things is very inefficient and can be vulnerable to human error (totaling numbers in wrong columns, incorrect data input, etc). Our thought was to help them by making software to help them transfer to digital and also do some automation for them so that they can avoid any possible human error. However, we as the software development team are not here to tell the food pantry owners what they should be asking for. There is a fine line that a software developer working with a product owner where you should suggest what you think you should develop for them that may be helpful while also staying within their guidelines. The biggest issue here is that the food pantry representatives do not have a definitive set of product guidelines and rather are open to any ideas we may have for them, as they currently are 100% paper and are looking for any help to go digital in a way that is useful to them. I enjoyed this part of the sprint because I got to interact with the people on the other end where we can talk about what we need to do and what we would like to do. After our meeting with the product owners we were able to start on our project. One of the group members started working on back-end development and was able to deploy a gitlab project for it. I started working on a front end HTML mockup of our worker client screen. Another member of the group worked on finding out how to parse a json file using gson. After our most recent sprint meeting we decided on tasks that we’ll start doing for the new sprint. More front end development will be done this sprint. This will be taken on by myself and another few team members. I specifically will be working on CSS stylesheets for our project. The other members will begin writing a Java program to connect our project to a database. In sprint 2 I learned a lot about project management and working with product owners.

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.

Expand Your Bandwidth

For today’s blog I will be writing about the “Expand Your Bandwidth” pattern out of chapter 5 of our text. I enjoy this pattern because the context is simple. “You have picked up a basic set of skills”. That’s it. That’s the context for the chapter. It is broad which leaves it open for many people to relate (perhaps not just software developers!). I can personally relate to this because I have a basic set of skills in programming that I have acquired over the past four years at school. Now that we have the context we can delve into the problem that the chapter presents to us. The problem put forth by the book is this: You have a narrow-focused low-level understanding of software development. The problem is that you think this way because of the narrow day to day scope of your work. When you work at a narrow scope of software development, then your knowledge and perception of software development becomes less broadened and more narrow and that is not good for a field that must consistently be changing and overcoming new ways of developing in the field. The solution is to broaden yourself by improving your ability to take in more amounts of new information. The text says “You’ve been drinking steadily through a straw. But there are seasons in apprenticeship when one must drink from the fire hose of information…” I think this is a perfect analogy because in a small setting like university classes we are hyper focused on our assignment at hand or the specific software skill/methodology that we are using for that class. A perfect example would be when I took my software testing class, we were solely focused on writing tests and not actually developing any code to test. In this case we were drinking from the straw, but sometimes a project would require you to know what was going on in the source code, which required other knowledge not related to testing, which in this case would be drinking from the fire hose; a much bigger flow of information. To make yourself marketable for a successful career you must know how to take all sorts of information from all aspects of software development. In this way and after reading this text, I believe that it is good to know a decent amount of information across many aspects of software development than it is to have a vast knowledge of one aspect of software development. Having the smaller knowledge of many areas allows for more flexibility and easier adaptations going from one task to another in the software development field.

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 1

This week was sprint 1. Sprint 1 was a rather simple and basic sprint that started with getting into teams and diving into the workload. The most work that was done for sprint 1 was done before getting into teams. Getting setup for the sprint required a lot of work, like filling out the CATME survey and getting your availability schedule together. Once we finished our prep work for the team formation, we got into our groups. Once we got our assigned groups we began sprint 1. Our first assignment was given to us by Professor Wurst. We had two tasks, one being to prepare a REST API for the food pantry and the other being finding a way to host a json file from a government organization. I took the lead on finding out how to host a server for our json file while other members of the group worked on researching REST APIs and figuring out more information on our project. Professor Wurst suggested a few options for hosting our server for free, digital ocean and heroku. I looked at digital ocean first but quickly found out that it actually costs money (a per month subscription) for us to host a server to store our json file on. After finding this out I looked into heroku. Heroku is a free service that lets you host a server for free (albeit they do limit you to a certain amount of server size/space as to avoid people from abusing the system by hosting large applications for no cost). I took on the task of doing a tutorial on heroku, which was rather simple. I went through the windows powershell to follow along with the survey. I learned a few of the heroku Java application specific commands, such as preparing the app (this was a simple process that uses the git commands to clone/pull/fork projects from github/gitlab), launching the app (heroku create), viewing heroku build logs, and scaling dynos. Dynos are specific to heroku, and are basically small containers that live within the heroku server that run your applicaiton. You can scale the amount of dynos per application to affect its performance (however you are limited to a certain number of dynos per application), and I learned that scaling down to 0 dynos does not allow it to launch the application. I feel like heroku is very similar to angular in the sense that there are commands to build/launch/diagnose applications, however angular is more of a “coding” application because you can edit code and run it all within the angular platform. Another large difference between angular and heroku is the language used to host the servers. We as a group settled on heroku for Java because we are all most comfortable using Java as it is our primary programming language. After completing the heroku tutorial I looked at the git repository that was shared with our group by Professor Wurst. I think that as a group we are unsure where to go from this point, as we have not been assigned any solid tasks yet. My hope is that for sprint 2 we can dive into the project more and will be assigned tangible tasks that we can complete for our end users.

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.

Your First Language

This week I am reviewing another pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. For this week’s pattern I decided to go with the chapter “Your First Language”.  The context of this chapter is you have a shallow understanding of one or two different programming languages. This chapter grabbed my attention because while I have been in school for four years learning software development, I still feel that I only have a shallow understanding of a few different languages (in this case Java, C, and python, but Java is definitely my strong-suit). I feel that from the perspective of the classroom we know a decent amount about our languages, but from a real-world point of view, we only know the proverbial “tip of the iceberg” meaning that we still have much  more to learn about our languages. The problem presented by the book is that we feel that we need to be masters at our first programming language in order to be a good programmer and a purposeful part of your team at work. While the book says that you should not stress over the fact that you only know one programming language, they also point out that most jobs require that you know at least one programming language inside and out to get the job. This is a “catch 22” because jobs expect you to be masters in a language and be extremely proficient but at the same time they understand that you likely have little to no experience with your language because all you have had experience with is programming assignments in school. This kind of puts us at the disadvantage because we are expected to be masters at our trade to get an entry level position at a company we  may not be at forever. The solution proposed by the book is to improve your learning of your first language. How does the book propose this? By having actual problems to solve with your programming language skills and knowledge. I think this is important because using your skills to learn how to solve actual problems helps you retain your programming language skills and makes you a better programmer.

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.

Why Doctors Hate Their Computers

This week we were tasked with reading an article titled Why Doctors Hate Their Computers. One of the very first things that stuck out to me was that doctors spend around two hours of work on their computer per day. I thought that this is a lot of time to be spending on the computer for a doctor. As a computer science major, I did not initally think that two hours of computer time during the work day was not bad. After some thinking and consideration, I realized it was not normal for most other jobs to spend this much time at a computer during their day. To add onto this two hours of computer time for doctors, they also spend most of their face time with patients staring at a computer screen. I can definitely believe this because when I go to the doctor they are typically on the computer and filling out forms and information while trying to perform my physical. I understand that computers make the filing aspect of the job easier, and it is very nice to have the information of all your patients at your fingertips. However, I can also see where this gets distracting. Instead of being able to have face-to-face interactions with your patients you now have to talk indirectly to your patients while you try to fill out forms on the computer. Thinking about if from the patient point of view, your doctor is not paying attention to you, and is rather sitting at his computer and staring at a screen instead of addressing you directly.

Another issue that comes up with doctors using computers is the increased stress on the IT departments. The doctors often run into issues with their computers and in turn pull IT service request tickets. This puts an added stress on the IT departments and the doctors get frustrated with their computers because they often run into problems. Another issue is that doctors may not be a technically literate as people in another field (say computer science for example) and thus might not understand how the computer functions or why they might be having a problem. Some of the problems that we would consider to be “minor” such as login issues, not being able to open a file or find a link, may be a “major” problem for some of these doctors who are not as technically literate as us. The doctors will then get frustrated, take out tickets for the IT department and the IT department sees these as “minor” issues and therefore take their time getting to the issue (especially if there are more pressing matters or if the IT department is extremely busy). The added stress between the doctors and the IT departments can be curbed by having doctors take computer courses or have the IT departments offer to give the doctors “how-to” guides. I believe that in this solution we will see a decrease in stress between doctors and hopefully they will see computers more as an aid rather than a pain and hindrance to their jobs.

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.

Concrete Skills

For today’s blog I will be writing about the Concrete Skills chapter in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that is summed up perfectly in the context section of the chapter, which is summarized as the fact that you have knowledge does not necessarily mean you are knowledgeable. This meaning that your knowledge can be useless without the real-life implementations and skills. But how does one obtain these skills and practice since we are only college students who have never had a “real-world” experience in information technology.

The problem presented in the book is this: you are looking to join a team but do not have the experience desired. The team may not want to hire you at all because the risk of you not being able to contribute or you messing up and or breaking stuff is far too high. So what is the workaround for this? The book says to use your time wisely and to obtain some concrete skills. Not necessarily always software development related, even just some sort of skills such as social interaction and networking. This is important because it does not take a lot of knowledge to do these actions and they can make you seem much more invested in the team and marketable to other companies that are hiring. What needs to be done is to bridge the gap with the hiring managers because honestly they know you have little to no experience and they will have to take blind faith in you, hoping that you pull your weight on the team. But if nobody hires you because of your lack of experience, how exactly are you supposed to get experience to get a job? Practice gaining concrete skills, social skills, networking skills, any skills that do not require coding knowledge that will make hiring managers warm up to you more, and therefore more willing to take that leap of faith in hiring you. I relate directly to this chapter because this is where I currently find myself in life. I have been applying for full time jobs while finishing my last semester of college. Trying to “bridge the gap” to make a seamless transition from school to work is hard. Many employers see you’re still in school and flat our reject your application, and some will humor you with an interview but are very reserved because after all you still do not have a bachelor’s yet. After reading this chapter I feel more confident in my job searching and I will continue to search and apply for jobs.

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.

Breakable Toys

For this week I have decided to do my blog on the Breakable Toys pattern. The problem presented when your environment does not allow for failure. As a college student I know what it feels like to be in an environment that does not allow for failure. If you fail classes then you cannot move on to the next semester, class, project, or graduate! Since I understand the feeling of this environment, I was naturally interested in what this pattern had to offer for me. The book says that the only way to learn is by failing so that you can learn how to correct that failure and get it right the next time around, growing as a person and a software developer. I enjoy this thought because I can think of many numerous occasions where I have failed at something – not just limited to software  development – and learned from my mistakes in the end. How are we to learn why something is correct without first understanding what happens when it is not correct? In my eyes, if we see why it fails then we can understand its true purpose and understand why it needs to be correct. This pattern suggests failure in order to learn. It does not suggest blowing stuff off and failing at the “real deal” stuff that will  be done at work, but rather urges us to practice on smaller projects/ideas with the same toolset as the “big one” in order to fail on a small level and in turn understand the true meaning of our toolsets. This is important because if we fail at a small level it will be easier for us to understand where and what went wrong and how to better understand our toolset that way when it is time for the big project we will have full understanding and control of our toolset so that we will not fail on the real-deal. The book also suggests building a wiki style page as your small project because you can track yourself through it, in turn building off of it and making it something big and meaningful from something small and easy.

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.

Apprenticeship Patterns

This week I was tasked with reading a few different excerpts from a Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The first chapter talks about software craftsmanship and compares it to how many trades are set up; apprentice, journeyman, and master levels. I think this is a really neat comparison because when you think of software development as a trade, and as a craft, it makes sense to apply the idea of starting out as an apprentice, working up through the journeyman rank, and finally reaching the level of master at the end. For each tier you increase, you retain a certain amount of information that makes you capable of doing many different things in your trade. From there the perfect transition into a description of the apprenticeship pattern is given, and I personally thought that was fantastic. I enjoy a good pun but I really enjoy a seamless transition between subjects. One thing I found interesting is how these patterns are found. Like, who actually thinks of these design patterns and figures out how they work? I like the idea that they are “borrowed” from working frameworks and tweaked to fit the application needed. For example someone has a framework made up for purchasing movie tickets online, but a live music venue wants to sell tickets to shows online. By using the functioning framework from the movie ticket application, they can borrow the framework and tweak it to fit their needs, which in this case is selling concert tickets rather than movie tickets. The book goes on to talk about different points that make someone a “great” software developer. One of these points that really stuck out to me was in chapter 3, which is easily my favorite chapter just because of how relatable it is. The story that was told was of a guy named Dave who had a multitude of certificates on programming (in this case it was Perl but it really doesn’t matter because this applies to all languages). The certificates reassured him that he was “properly trained” and “knew what he was doing” and was a “coding master” or a “software craftsman”. However after he did some socializing with other “masters” of his certified programming language, he realized that the well is a lot deeper than he could have ever imagined. At this point he realized he was not a “master” of software development or any of the other previously mentioned attributes. He was still just a guy who had a lot to learn about software before becoming a master. I think this point resonated with me the most because approaching the end of my college career and almost having a bachelors in computer science and software development, I thought that I was a pretty decent coder. Maybe not a “master” but definitely more than novice. What I know now is that there is a lot more information out there and the sea is ever expanding and growing with new knowledge, and I have so much to learn still. I thought that this reading was very thought provoking and gave me a new appreciation and understanding in my work and what I know, as well as what I want to learn in the future.

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.

Intro post

This is my intro post

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.

Testing with Dummys

Today I will be talking about testing software! More particularly, testing by using dummys! So what exactly is a dummy and why do we use it in testing. Dummys are objects that are created for the purpose of testing but are actually never used. Think about it like a mannequin. The mannequin displays the clothes as how they would look on a human, but the mannequin is not actually a functional human, and does not actually use the clothes. Its only job is to make sure the clothes look (or function for the sake of testing) correctly. According to this blog by Tom Winter, “How our test data generator makes fake data look real”,  our test generator makes fake data look real for the purpose of testing our code. Why would we ever want to test fake data? The easy answer is this: sometimes we do not have all the data or all the code finished, and we want to test our code without having to play the waiting game. Sometimes it is even impossible to test our own code without dummys because we do not have access to the actually data. So we use these dummy objects to play the role of the real data (which we do not actually have access to, remember?) in order to test our code to ensure it functions properly.

Testing with dummy objects is something we have been doing in my software program at school, and I happen to find it very useful in the sense that I do not actually need the data to make sure my code works. Not only does this help pick up testing efficiency,  but it cuts down on the overall wait-time between developers and getting their product out. On the flipside of things, if another developer was waiting for me to finish my code before testing, they could use a dummy to test their code instead of rushing me to finish, which could possibly lead to me making mistakes and end up slowing down the entire development process. I enjoy being able to test right away, and using dummys can help with this. I hope to continue using dummy testing in the future, as it is an easy and very effective method of testing!

Here’s the link: https://medium.freecodecamp.org/how-our-test-data-generator-makes-fake-data-look-real-ace01c5bde4a

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.