Category Archives: Computer Science

Hello World!

Welcome to my first blog post! My name is Zack Tram and am a senior completing my undergraduate CS degree. In the upcoming weeks, I’ll be posting about topics relating to how software is managed, designed and constructed.

I look forward to completing my degree this year, and everything that comes with it!

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

Josie’s Notes Introduction

So I guess I have to start blogging now. I never really thought I would be doing this but here I am. This Blog is starting out because of my class CS-348 Software Management Process but who knows where this will go, Anyways that is all I have today… Ciao Ciao

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Find Mentors

Summary:

Find Mentors pattern is about asking for help while exploring the unknown. Every time we decide to take a new path – learn a new language, we do not know what is in store for us and therefore have no clue as to how deal with problems that we might face. The pattern recognizes that as new apprentice we will need help facing these problems and in reaching our goal.

The solution pattern provides is to learn under a master craftsman in the field of your choosing – a mentor. The pattern also realizes that as a novice it is difficult to identify a true master craftsman and therefore during the process of acquiring the new skill we will be guided by a number of mentors with diverse levels of mastery. The pattern states that it might be easy to find authors, bloggers, professional speakers, and developers in computer science field. However, there are two problems; first, they might not be interested in mentoring; Second, asking someone to be your mentor can be very intimidating. The important point pattern makes here is to have determination and remember that the risk of rejection is very low compared to huge opportunities having a mentor can provide.

The pattern also warns us about blindly following someone. We need to keep our eyes open to the mentor’s weakness and resist the temptation to believe everything they say. No one knows everything about everything. Therefore, we need to keep finding other master craftsman and keep polishing our skills.

Why I choose this?

Computer science is a very difficult field to begin with and then on top of it – it is an ever-evolving field. The amount of knowledge available is immeasurable. The pattern ‘Reading List’ helps us organize the books we need to read, which as we all know does not give practical explanation, real world connections or real time feedback. Moreover, to start our reading list and even to make sure that we are reading the correct books – we need to find someone we can trust – someone like a mentor.

Over the last four years I have been able to find a number of mentors. They have ranged from professors to my peers, family and friends to people in slack and discord communities. It has been an amazing experience. I have learned from them and with them.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Summary:

Those who don’t learn from their past mistakes, are doomed to repeat it. ‘Learn how you fail’ pattern states that failure is an inevitable part of any learning process. And if we have not experienced failure than we are either not pushing ourselves to our limit or we are making a grave mistake of ignoring our faults. The pattern provides a very clear and concise solution, self- assessment. We need to identify and be self-aware of patterns, conditions, habits, and various behaviors that resulted in failure. The pattern also points that once we are conscious of our faults, we are given an opportunity to fix them. It’s like the saying,’ the first step to any solution is recognizing that there is a problem.’ The pattern also lets us know that accurate self-assessment can help us define our limitations. Pattern lets us know that its okay to not excel at everything and accepting these limitations forces us to rid ourselves of all the distractions and reprioritize our goals.

Why I chose this pattern?

To quote Thomas Edison one more time, “I have not failed, I’ve just found 10,000 ways that won’t work.” This is a very powerful quote because if we don’t remember which road is incorrect, we might very well end up drowning.

‘Learn how you fail’ fits in perfectly after ‘breakable toys’, ‘Practice, Practice, Practice…’ and ‘Record what you learn’. “Armed with that self-knowledge…you allow yourself the choice between working to fix these problems or cutting your losses.” This is a very powerful sentence from the pattern. I have always been very self-aware of my limitations and therefore had my courses for the four years of my college well planned. Unfortunately, due to a fractured foot and a death in the family, I was operating at a bare minimum of my normal capacity. After a long and hard self-evaluating process, I concluded that I will not be able to finish both my capstone courses and even if I do, I will only be doing my bare minimum to pass the course and not for the learning experience. At this point, I decided to cut my losses- drop one of the capstone and do my best in the other one.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Crafts over art

Summary:

Craft over art pattern makes an important point about quality over beauty. Pattern points out the ugly truth that “For a craftsman to starve is a failure; he’s supposed to earn a living at his craft.” A scenario like this can happen when the craftsman is not skilled but mostly occurs when craftsman decide to prioritize art over their craft. Craftsman should build a software based on the product owner’s need and not just indulge their desires. It is a craftsman’s responsibility to develop a software that is beautiful. However, this should not be done by sacrificing the utility and productivity of the software. The pattern provides a solution which uses a fifty-fifty line. The craftsman should develop a software which is aesthetically pleasing and feature rich. Creating something that is beautiful and has no use is not craftsmanship, it is a waste of craftsman’s skill and time.

Another aspect the pattern covers is that as craftsman, we need to prioritize product owner’s needs over our own. As craftsman we cannot make excuses of not being in an ideal artistic environment; we need to create a quality product that satisfies the product owner in the provided time frame.

However, craftsman should not do merely do what is expedient. The pattern states us to adhere to our standards even under high pressure. The pattern further explains that based on the product owner’s requirements, sometimes we will need to switch priorities between productivity and cosmetics. To understand, achieve and maintain all our standards, we as craftsman need to understand craft and art are not mutually exclusive but interdependent.  

Why this pattern?

As someone who just graduated and is joining the work force as a software developer, craft over art pattern can be used as a moral compass. Programming is without a doubt a form of art especially if I am working on frontend or User interface. I have been hired by a friend to create a website of his family’s construction company. They wanted a simple website with description of their work, prices, and contact information. I spent hours looking into themes, designs, photos, and live photos and barely any looking into features. After reading this pattern I was able to reorganize my thoughts and let my friend know all sorts of features I would be able to add into his website. He was pleasantly surprised with my suggestions and his family even offered a raise. The pattern helped me stay true to the programming and not get lost in the aesthetics of it all.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

Everything under source (src) in backend was written except for the final test files and API was also complete. We were waiting for more information about access tokens and Gitlab access keys from the IAM team. We were also waiting to hear from AWS team on templates for Kubernetes system but did not get any response. We were at the same time researching on how to import API bundle into backend so we could start building the backend server and to at least test if everything from our side was working properly.

We needed to bundle our API before we could export the file to backend and ‘npm run bundle outfile.yaml` was not working. After fixing minor issues in the API, we got our bundle file. Even after a lot of research, readings and experimentation, we were not able to connect API bundle to backend, something would not work and kept getting different errors. At this point we decided to copy the bundle file and paste it into backend lib folder manually. Since we were not able to import the bundle file, we decided to not work in main and created a separate branch called ‘issue10’.

We made a lot of mistakes from this point on. We were all working on this branch instead of making our own branch based on the issue10 branch. We also worked only on one team member – Christian’s system. We added and modified a lot files like entrypoint.sh, package.json, package-lock.json, docker-compose.yaml, Dockerfile, etc. We should have created branches based on issue10 branch, then created specific issues with proper weight assigned to them. After making all the modifications we could think so, we still were not able to build our backend server.

At this point, Dr. Wurst pointed out that we do not have frontend, which means that our docker file will not be copying yarn file and running yarn install but instead copying the package-lock file and running npm install. After making changes in the Dockerfile, our backend server was finally able to build but still could not stay up. After going over docker container logs we finally came to the conclusion that the problem for this was in the port. We had not specified proper port in many files. Once those modifications were made the backend server was up. Till this point, we were all still working on Christian’s system, without any proper issues, comments and documentation for modifications that were being made.

I created my own branch based on issue10 and then wrote calls for cooking method. However, when I tried to build the server, I got the error that docker-compose is not installed even though I have used it many times before. Using the solution, I found on stackoverflow I was now able to build the server but the process would hang up on the attaching stage. I tried running docker-compose up command after opening the branch in container. This led to an error saying ‘docker not found’. Another team member Jeffery had the same problem as mine but was able to find a solution for it and then was able to make calls. However, the same solution did not work for me. After trying everything I could find on the web till 4 am, I finally gave up.

In the next meeting I shared the calls I had written for cooking methods with the team so they could be added to the project. Noticing that I was the only person who was working on a windows PC I decided to run the project on a friends MacBook and surprisingly it worked. I did not research further into why it would not work on my system since I had limited time with the Mac.

I worked on cookingMethod.js and cookingTip.js test file. I set three constant variables: getAll, getOne with valid ID and an invalid ID. getAll would check for ‘200’ response and data in form of array. getOne with valid input would check for ‘200’ response, ID, object and value. getOne with Invalid input would check for ‘404’ response.

Links to issues:

Calls

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/34

Backend Debugging

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40

Modification of files

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/41

Cooking Method test

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/28

Cooking tip test

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/42

P.S. – I apologize for this retrospective being more like a summary. It proved difficult to classify the process in what worked and what did not work sections for this sprint.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Reading List

Summary:

Reading List pattern recognizes that as software developers/apprentice we need to start learning the next thing, but how do we choose from the vast ocean skills and information available. The pattern recognizes that its not only hard to decide which language or area we want to master next but also which book or books will be the most appropriate for that step. The pattern recommends the simplest possible implementation that is to create a reading list. Reading list could be just a text file with a list of all books that have been read, books currently being read and books we plan to read.

Why this pattern?

Reading List pattern helps answer one of the most difficult questions, what next? Now that I am done with college, the obvious thing to do next is to find a job. However, the list of the things I have barely managed to scrap the surface of in the last year, specifically the two capstones, its like I have a bitter after taste in my conscious. The pattern has covered every possible question I can have. Which book do I start with? Ask help from a mentor like a professor or pick a book that covers a broad spectrum of the topic I want. Which book next? If I want something in the same area, I can go deeper. For example, after software development, now maybe I can focus on web development or mobile application development. If I want to learn a new language, I can google the most in demand computer language and chose from there. Sometimes I can find our next book within the bibliography of the current book I am reading. If I want to expand my horizon and read something outside of computer science; I can publish my list online and ask my peers and more experienced community members to guide me.

The pattern also recognizes that sometimes in order to keep the list updated, the order of the books will keep changing. Moreover, sometimes due to priority changes or simply advances in technology, some books will keep dropping down in the suggested column and we might never get an opportunity to read them.

Where I disagree:

Nowhere, unless there is a pattern out there that can control a person’s mind and force them into start reading.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Summary:

‘Record what you learn’ pattern comes from the chapter ‘Perpetual learning’ and Perpetual meaning ‘occurring repeatedly’ the pattern sits well. ‘Record What you learn’ Pattern is a perfect read after ‘Breakable Toys’ and ‘Practice, Practice, Practice…’ because the pattern exposes one the biggest flaw in our learning which is that sometimes even after learning the same lesson repeatedly “They never seem to stick.” The solution pattern provides is for us to record what we learn. Make timely organized notes in form of journals and wikis. Moreover, the notes could be public or private; public for the purposes to share your knowledge and discoveries and private where you can act as your own oversight and pinpoint all your faults with brutal honesty.

Why this pattern?

For me, ‘Record What You Learn’ is a perfect sequel to ‘Practice, Practice, Practice…’. I have written many programs in Java, but from time to time I’ll forget something specific like casting the input variables, using extends or implements in OOP. The point is this has happened to me various times until I started making personalized notes for myself instead of depending on textbooks and class notes. I started writing things down the way I understood them; using the color-coding system to my advantage, I highlighted parts that were important to remember, parts with specific steps and parts where I needed help. Classification of information not only proved to be effective for quick reviews and revise but also helped in conveying myself to people who can help me in precisely where I needed help.

Where is disagree:

Most of the time while building my personalized notes there was a lot of overlap. Classification of information was effective but the process of classifying the information itself was tedious and chaotic. As I kept learning new things, adding notes, and modifying notes became a very complicated process. Absence of space led to arrows being from the top of the page to the bottom. References were made from page 31 to page 45 which led to a whole new level of mess. Switching to taking notes on the PC solved a lot of issues from being on paper but created a lot of new ones. One issue was the mechanics of completing a task. It is much easier switching between a pen to a highlighter than a keyboard to mouse, and further selecting area to highlight.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice…

Summary:

The pattern is about emphasizing the importance of practicing our skills, coding in this scenario, to become the master in that particular skill set. The pattern states that we need to keep practicing every time we try to master a new skill. The pattern also recognizes that our work life balance does not provide a safe or stable enough environment for us to keep practicing. The solution provided by the pattern is that we organize our days. To join people, face to face or online, and to practice coding or other skills as part of a community. The pattern also points out that we need to make time and create safe & stress-free environment, because if we are not in a relaxed state then we will not be able to learn from our practice.

Why this pattern?

From the first year to last year, I have been using and writing codes in Java language. Entire semesters have been dedicated to learn and practice Java concepts. However, in a span of few months, I had to learn languages like python, R, JavaScript; frameworks like Junit, mocha, and many other things like VS code, Node.js, docker, R studio, Jupiter notebooks, etc. Therefore, I may not have mastered Java completely, but I am definitely far more confident and competent in Java than any of the things I have learned in the last year. Its like Bruce Lee said,” Practice makes perfect. After a long time of practicing our work will become natural, skillful, swift, and steady.”

Where I disagree:

To put the practice of practicing over and over is far easier said than done. Over the last few months, I have been swamped. Unless I start polishing my skills when I am eating and using the restroom, I do not see a way I can manage a time schedule where I can successfully complete my workload and carve time out for practicing.

The problem with community practicing or group learning is that every has their own schedules. It is next to impossible to co-ordinate meet times and even if that some how works out, different people want to work on different set of skills.

The point where I disagree the most is that while working in this safe and personal environment, we have almost no help or oversight. If we are stuck on some problem, it will be difficult to find help; or worse we keep practicing the wrong way without anyone there to correct us and now we have wasted all this precious time.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Summary:

I have chosen breakable toys for this weeks Apprenticeship pattern. Breakable toys pattern is about learning through our mistakes. The pattern explains that we work in a high pressure jobs and environment and understandably success is expected or at times even demanded of us. However, pattern also recognizes that failure is the key to success. By failing and discovering our faults, our flaws is a crucial step in the process for us to grow, learn and build on our experience which all in turn eventually leads us to succeed. Pattern emphasizes the importance of step one for any work we are attempting to complete. First step needs to be just that, the first step – a simple README file in Gitlab with a rough structure what we are working towards is as important as every code we write and every feature we experiment on.

Why this pattern?

This is one of the most important if not the most important Apprenticeship Pattern I have come across. There many external factors affect the work that is being done like time restrictions and financial restrictions which prove to be nothing but a hindrance. This year, I had to keep learning new languages like R, python, JavaScript, mocha and chai and services like docker, R studio, VS code, Jupiter, anaconda, etc. I cannot count how many times I have been stuck on some piece of code, spiraled down because I knew failure was unavoidable and start feeling the paralyzing fear take over.

Knowing and remembering that failure is as important as success in a learning environment has helped me lot. Organizing my failures as a software developer proved to be as important as completing building our backend because It’s not wrong to make mistakes, it’s wrong to repeat them. Pattern suggested that we should work on our smaller projects because it gives us the time to learn our tools and a safe environment where we have our freedom to fail. I have written simple codes for calculator and tic-tac-toe in python. Deployed a simple ‘Hello world’ website using AWS. To quote Thomas Edison, “I have not failed. I have just found 10,000 ways that won’t work.” The trial-and-error process has immensely helped me grow and then further implement that knowledge in my projects.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.