Category Archives: Computer Science

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.

Apprenticeship Patterns

Dave’s story introduces both motivation and fear. A fear that next new big thing might make all our efforts wasteful but motivation to work hard in learning every new skill and language.  We see many versions of this statement by researchers like, “Failure is merely an incentive to try a different approach” by Carol Dweck or “recognize the inadequacies in what you do and to seek out solutions” by Atul Gwande.

However, Etienne Wenger said it best using ‘situated learning’ that, “best way to learn is to be in the same room with people who are trying to achieve some goal using the skills you wish to learn”. ‘Situated Learning’ is also the key to Apprenticeship and achieving Mastery. A man who is always working to find a better/smarter/faster way to accomplish their goals using connections between practitioners, the communication channels within and outside the team is a man who will enhance the skills of his apprentice and journeymen.

That said, ‘Situated learning’ is no small feat. It is a long and hard journey for an apprentice to become a journeyman and then Master. Learning new skills throughout one’s career is vital but perfecting skills warrants one to have a concrete learning skill to learn new skills and therefore Perpetual learning pattern must be applied as early as possible in our career path.

The biggest mistake I have heard graduates make is that they overestimate themselves. Coming out of university with bachelor’s in computer science doesn’t mean we have four years of experience, it means we have just started and that is why the author writes in the very first paragraph, “this book is for people at the beginning of the journey.” To avoid this one must have accurate self-assessment skills. We must recognize the limited information we have compared to the limitless treasure of knowledge available and strive to acquire them by learning about other teams, organizations, journeymen, and master craftsmen. We can also acquire great amounts of knowledge and skills through internet via text, audio, and video however, we must also recognize that the vast amounts of wisdom captured in the books of experienced software craftsmen cannot be replaced by blogs posted on world wide web.

“Walking the long road” teaches us how to practice patience and hard work, we cannot learn all languages by working hard only one month or year. We need to keep practicing and polishing our skills, which we learn in “Perpetual learning”, skills like self-assessment (“Accurate Self- Assessment) and learning not only through internet but also through wisdom and experience of software craftsmen who came before us. However, I do not agree with “Emptying our cup”. We should not forgo of our skills and knowledge but build on them. We should never be arrogant or foolish enough to think we have learned everything we possibly can.

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

Why Vue

There are several frontend frameworks available to pick from, so why do we use Vue? To research about Vue and learn about its benefits, I decided to read blogs from Vue mastery, specifically one written by Lauren Ramirez.

  • Vue does not use up too much memory. Vue allows us to import only the pieces of the library that we need, which means whatever we don’t use will be removed for us via treeshaking.
  • Virtual DOM (Document Object Model) uses compile-based optimization resulting in faster rendering times.
  • To work with Vue, we did not have to learn HTML, CSS, and JavaScript. It was surprisingly easy how we were able to learn as we go.
  • Vue has many libraries that can be added as needed. Some of which are:
    • Vue Router (client-side routing)
    • Vuex (state management)
    • Vue Test Utils (unit testing)
    • vue-devtools (debugging browser extension)
    • Vue CLI (for rapid project scaffolding and plugin management)
  • Vue’s one of the best features – Composition API;
    • We are able to group features into composition functions then call them in the setup instead of having large unreadable and unmaintained code directly in setup.
    • We are able to export features from components into the functions. This means we don’t have to keep re-writing code and avoid having useless repetition.
  • Vue has enhanced support for TypeScript users as well.
  • In Vue, we are able to use multi root components. In most front-end frameworks component template should contain exactly one root element because sibling elements aren’t allowed. The way around to that problem is using functional components, they are components where you have to pass no reactive data means component will not be watching for any data changes as well as not updating itself when something in parent component changes. However, they are instance less and you cannot refer to them anymore and everything is passed with context. With the multi root component support of Vue (Vue 3), there are no such restrictions and we can use any number of tags inside the template section.
  • Vue 3 gives us the Teleport component, which allows us to specify template HTML that we can send to another part of the DOM. Sometimes a piece of a component’s template belongs there logically, but it would be preferable to render it somewhere else. This is useful for things like modals, which may need to be placed outside of the body tag or outside the Vue app.
  • Most importantly, Vue is open source. Vue has complete freedom to be community-driven and its bottom line is the satisfaction of its end users. It doesn’t have to answer to the company-specific feature demands and corporate bureaucracy.

Source: https://www.vuemastery.com/blog/why-vue-is-the-best-framework-for-2021-and-beyond/

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

UML Diagrams – PlantUML

We learned PlantUML at beginning of the semester and even did an entire homework creating UML diagrams of a project. But the reason I am writing about UML diagrams right now is because as I was going through previous activities I realized, not only can UML diagrams be used for code built on OOP but also to create a simple and easy to read diagram of an microservices architecture.

As we all know we are going to be using microservices architecture to build Libre Food Pantry so I decided to look for a resource that can make using PlantUML simpler and easier to use and understand. I found a great blog by solutions architect Alex Sarafian. Below are the few features that I found very useful:

  • We can color code arrows for multiple flows flow of the diagram and add legend to specify what color represents which flow.

Format example:        A -> B #Blue : text

legend

    | Color | Flow |

    |<#Red>|  Flow 1 |

    |<#Blue>|  Flow 2 |

endlegend

We can color code arrows inside PlaceOrderService and ApproveOrderService for easier understanding of the services.

  • Autonumber feature will automatically add a number alongside the text of every event. Autonumber gives a linear sequence of events that are going to take place. For example, 1st UI placing the order to API, then 2nd from API to Database and so on.

Format example 1: numbers in front of event text

autonumber

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

Format example 2: Numbers are 2-digit padded and highlighted

autonumber “<B>[00]”

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

  • PlantUML limits the image width and height to 4096. Therefore, when image file is created over the limit of 4096, diagrams are cutoff completely taking away the advantage of efficient flow UML diagram. To fix this we can use command line parameters to increase the width and height limit of image. Another way is to use ‘skinparam dpi X’ parameter. However, the downside to using skinparam is that we must find the value for ‘X’ by experimenting to see when UML diagram fits the best.
  • We can display text relevant to an event below the arrow for a cleaner UML diagram. We a skin parameter to achieve this. For example:

skinparam responseMessageBelowArrow true

autonumber “<B>[00]”

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

  • PlantUML supports a lot of different colors. A neat trick is to use the ‘colors’ command to render a picture with all colors.

Sources: https://www.codit.eu/blog/plantuml-tips-and-tricks/?country_sel=be

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

REST API

We have been using REST API for most of the semester now but did not really read or have knowledge about it. We have been reading a lot of documentation of MongoDB – its operators, commands, methods, or collections. but nothing about REST even though we will be using REST API again in future semester i.e., for capstone when we are working on Libre food pantry. Therefore, I wanted to research REST and found a very interesting blog by Adam Duvander.

REST stands for REpresentational State Transfer. REST API’s are a form of web services used to run websites (like we have built Libre food pantry example), mobile applications and most enterprise integrations.

Important thing to know about REST is that it is not a standard, it is built over HTTP standard. The information can be in several formats: JSON, HTML, XLT, Python, PHP, or even plain text. JSON is the one we have been using and probably will be using because it is easy to read by both people and machines.

Developers used HTTP methods or HTTP verbs to define the requests being made. GET, PUT, POST, and DELETE are ones we have used so far. PATCH is another commonly used HTTP method to update a subset of existing data.

REST resource is data that is modified or accessed using HTTP methods. For example, when we worked on backend, we defined a path to access or modify data by using GET, PUT or POST methods. An example of a request would be:

POST /order/{id}/items

{id} would be an identifier to find order with that specific id value. Identifiers can be integers or hashes.

REST architecture is made of this resources and requests and requests are made using HTTP methods. REST architecture also states that information should not be stored after any request is executed, meaning every request is independent of the other. However, resources should be accessible and modifiable by the user. Therefore, interface between components is needed so that resources requested are identifiable and separate from representations sent to the user. The representation has information which can be then used by user to access and modify resources. REST architecture also needs cache for interactions between user and server and a system to handle different servers used to process requested information into hierarchies.

Built on these principles, REST is very versatile, able to work in a large variety of environments, with multiple data types making REST API’s faster and lightweight.

Sources: https://blog.stoplight.io/rest-api-standards-do-they-even-exist

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

Visual Code: Docker Extension

We have used visual studio code and docker extensively in our software design learning process. Even though it wasn’t made necessary for us to get the docker extension, I have been using the docker extension for a while now. Since docker is one of the biggest open source platform providing virtual containers, I wanted to further explore what benefits would an extension bring to visual studio code. For this I am focusing on blogpost under microsoft by Mike Morton.

Using the extension, we can easily add docker files through command palette and using Docker: Add Docker Files to Workspace command. This generates ‘Dockerfile’ and ‘.dockerignore’ files and adds them directly to our workspace. The command also gives us an option to add Docker Compose files. Extension provides option to build docker file in more than ten most popular development languages and then we can set up one-click debugging of Node.js, Python, and .NET Core inside a container.

Extension has docker commands to manage to manage images, networks, volumes, image registries, and Docker Compose built right into the command palette. So, we no longer must go to the terminal and meticulously type $ docker system prune -a or search IDs of specific container we want to stop, start, remove, etc.

Moreover, the extension lets us customize many of the commands. For example, when you run an image, you can now have the extension put the resulting container on a specific network.

Docker Explorer, another feature of extension, lets us examine and manage Docker containers, images, volumes, networks, and container registries. We can use the context menu to hide/show them on explorer panel.

The best feature is extension’s ability to select multiple containers or images and execute commands on the selected items. For example, we can select ‘nginx’ and ‘mongodb’ container and stop or start them at the same time without affecting other containers and without having to run start or stop command twice. Similarly, we can run or remove multiple images of our choice. Moreover, when running start command through command palette, we can see list of all the containers that can be started with a checkbox next to each.

When we are working on say Libre Food pantry microservices and have multiple development containers running – running commands through command palette is going to be quick and concise, explorer will give us a very simplified and organized way to manage docker assets and executing run/stop commands for multiple containers at the same time will be an extreme time saver. All these features combined are going to increase development productivity exponentially.

Source: https://devblogs.microsoft.com/visualstudio/visual-studio-code-docker-extension-1-0-better-than-ever/

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