Category Archives: Computer Science

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.

The White Belt

Summary:

The white belt pattern is about learning new things. We have mastered one language or area, now it is time to learn another because being an expert in one language or area does not allow us to grow and widen our capabilities. Pattern recognizes that sometimes despite working hard and giving our 100%, it does not lead to success. We need to recognize that different areas require different methods and approaches which may be drastically different than what we already know. Solution that pattern provides for us is that sometimes we need to clear our minds and start from zero.

Why this pattern?

Ever since freshman year I have been learning Java. First, we did intro to programming, then data structure and then testing in Java using Junit. Along the way I did a little bit of C, python for data analysis, and JavaScript, CSS, etc. for projects last semester and capstone. While working on this stuff I realized I kept using concepts from Java and messing up the code. Even while using mocha and chai testing framework, I kept using testing concepts of Junit. Due to this almost every time I had to revert the code, go read the proper documentation, come back and redo the code.

White belt pattern teaches us to re-assess our knowledge. It teaches us that as computer science students there is always knowledge out there, we can learn and help ourselves grow. As Elon Musk said, “Biggest mistake smart people make is believing that they are smart.” And to learn or acquire new knowledge and skills we need to start from square one. We cannot build a skyscraper on top of another skyscraper. We need to start below the earth, lay down a good foundation and then build on it.

White belt pattern also teaches us to be brave. I personally get nervous and anxious nowadays when it comes to learning a new language like python or JavaScript, software like docker or Kubernetes, services like Gitlab or AWS, etc. Pattern recognizes that sometimes it is painful to start from the bottom but tremendously crucial in accelerating the learning process. Mastering the new language or area is far more important than the short-term loss of productivity.

Where I disagree:

I might be nitpicking with the technicality of the word ‘unlearn’ but I do not think we need to unlearn what we know to learn new things. We do not need tear down a building to build another one.

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 2

What worked well:

Creating branches and merge requests was smoother compared to previous sprint. We were communicating more through comment section of issues leading to better documentation on Gitlab. We were able to come up with a system for merge requests where two people who did not create the merge request would review the code or changes and then third person would write the comments indicating the author and merge the branch into main. We were able to evenly split work and issues between team members so one person was not burdened with one type of work. Even with delays and having to learn new language and concepts we were able to complete the sprint.

We also created issues for contacting AWS and IAM team members (links below). We contacted both team members via discord and tagged them to comment section of the issues that contained questions we had for them.

Personally:

Most important one is that I did not limit myself to issues only assigned to me, I was able to go over work done by my teammates and keep myself updated with new code as well as the flow of the project. API was completed so we had moved on to Backend. I created data file for cooking methods. This was difficult in its own way because we were not using MongoDB for this project. After researching backend already provided, I was able to figure out that we needed to use axios and USDA URL to call data which would return list of cooking methods or cooking methods based on its unique ID. I then wrote a main function to check if I was getting list of all cooking methods and it was successful.

Even with some setbacks, I was able to grasp the basic concepts of the new JavaScript testing framework – ‘mocha’ and JavaScript testing library ‘chai’. Since the data file and paths were completed, I created cooking method test file. With help from Jim this one completed in a week. Npm test verified that all test files were passing.

Things that did not work well:

The spring break and two consecutive cancelled classes pushed us back a little and we had a little problem getting back in sync. We were still having problems communicating and setting meetings outside of class time. Merge requests started to slow down; partly because of introductions of news framework and library – mocha and chai, verifying others work became difficult; partly because merge requests started to fail due illegal naming conventions in commits. Issue names also needed to be more descriptive with more details in sub descriptions. Issues were also not properly linked to their respective epics. We were stuck in a lot of places where we needed help from professor, and we should have been more pro-active in that situation.

We also did not hear back from the IAM and AWS team.

Personally:

I wasted a lot of time researching and reading documentation on my own instead of working with my team or asking help from professor. Also lost a lot of time figuring out how to run npm and npm test. My merge requests kept failing I was not able to figure out the reason until Dahwal pointed out that I was not using conventional commits. I kept up with other people’s code but did not get an opportunity to write an endpoint myself.

Links to some issues:

Start conversation with IAM team

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

Start conversation with AWS team

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

Test file for Cooking Methods

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/general/-/issues/2

Create Data File for Cooking Methods

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

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 1

What worked well:

Creating issues was as expected; We were able to have open communication within the team and we were helping each other in how to create issues, connect them with epics, assigning team member for work and for reviewing.

We were helping each other figure out using git again. Dahwal introduced me to Github Desktop application which made the whole process of adding files, committing branch, push branch, creating merge requests, creating new branch and switching branches fairly simple.

Personally:

I had to revise scrum techniques and how to use the scrum board but with the help of team quickly grasped the concept again. I was quickly able to assign issue to myself in the API part of the project (links to the issues below). Most of the code was very similar to homework project from last semester therefore was easier to complete. I created src folder with path, responses and schema subfolders. I created schemas for view, product, shelflife and EvoError. I had to do good amount of research on OpenAPI and also on regex for patterns and format for different schemas within the schemas like min, max, temp, etc.

What didn’t work so well:

Figuring out workings of git took longer than expected. Brushing up on scrum and trying to use scrum boards proved harder than expected. Communication in the beginning was limited to only class time, which proved to be a big obstacle in this sprint. We also ran into a lot of problems with merge request, where they were unsuccessful due to being behind on commits, improper branch creation and not having a clean working tree in general.

Personally:

I had a lot of time used in git bash until Dahwal showed me GitHub Desktop application which really helped me save a lot of time. I had to do fair amount of reading of OpenAPI documentation in trying to figure out proper patterns and formats and even after that I needed to ask help from team members and professor. I also confined myself to only issues related to schemas and did not get opportunity to create paths for the API.

Improvements:

The most important issue we need to deal with is communication. We need to meet outside class time or at least meet via discord in video calls. We need to attach issues created to appropriate epics and understand how weights work and its assignment. We also need to communicate difficulties or problems we faced regarding issues in the comment thread sections instead of only using discord. We also need to come up with a system of approvals and merge requests so most of or class time is not spent approving and merging requests.

Personally:

I need to communicate with team members working on issues similar to mine so that we can set some conventions. For example, my schemas, branches, commits and merge request had slightly different naming convention than others. I also need to keep up with emails, discord messages and other notifications and respond in timely manner. Most importantly I need to make an effort to keep myself updated with issues I am not assigned to and keep up with the flow of code.

Links to some issues:

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/1

EvoError

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/2

Product Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/10

View Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/12

Shelflife Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/11

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