Author Archives: tyahhhh

Sprint 3- Retrospective Blog

For this sprint, my team, team 1, managed to complete all the epics that we had, which were .gitlab-ci.yml, fixing API, modifying backend, finishing frontend, and completing documentation project. I believe my team is done with the API, backend, and frontend. A small portion of the gitlab-ci.yml and the documentation project are still in progress.

In this sprint, I have worked with backend and frontend projects. For the backend, first of all, I modified the API to reduce the number of endpoints from 5 to 2 which getReport and getVesion. Then, to send fake data without using any endpoints, I created a folder named send_Fakedata_RMQ. This folder contains two files, one is used to contain dummy data and the other one is used to create rabbitmq connection and send those dummy data to a rabbitmq channel. So, whenever we use the command of node ./src/send_Fakedata_RMQ/sendData.js, we are sending dummy data to rabbitmq. These data are used to test how the entire backend works. To automatically retrieve those data from rabbitmq and store them into mongodb, in the index file, I added a new method called RabbitMQ_service(). In this method, I used setInterval() function to repeatedly retrieving data from rabbitmq every day. The fixed time used to delay between each call should be converted from day to ms, 86400000.

For the getReport endpoint, I’ve added two new properties called new_household and new_people, which represent the two columns of the Newsince field in the example report. Furthermore, I also edited the csv.js file to make the getReport endpoint return the report in text form instead of downloading it directly to the computer.

For testing, I created two tests for this backend. One is used to test the response status, the other one is used to test the response data. To test the response data, I added a new file called expectedResult.js in the testing/test/lib folder. This file contains a string where each value in this string is manually counted based on dummy data I sent to Rabbitmq. This string is supposed to be my expected result which I am using to compare with the actual result recieved from the system.

One of the problems of the backend is about what should be stored in the guestInfo collection. Since I misunderstood the properties of the guest variable in json, I stored each guest as a unique guest in the collection without the “date” property. The requirement of this collection is that every record of each guest must be stored with a date and time, so this issue must be fixed in order to produce an accurate report in the near future.

For frontend, I added the same folder named send_Fakedata_RMQ from the backend to send dummy data to check whether the frontend is working or not. In getReport.vue, I added a method called downloadCSVfile(data) to download a file named WCFB_report.csv, when the “Submit” button is clicked. I also added a simple instruction of how to run the frontend in README.md. I believed we are done with the frontend and it works fine as expected.

For this sprint, we all focused and worked on different topics to perfect the reporting system as much as possible. Most of the time we worked well as a team, but there were still some points that I think we should improve in the future. Like what I just said, each team member worked on a different topic, so it is hard for us to keep track of all topics at the same time. Team members should actively share the problems they are facing so that the whole team can look at it and help them as soon as possible. Don’t stay silent and wait until the last minute without giving any reason to the team. I mean each team member should be aware of his/her responsibilities to the whole team. On the other hand, for myself, I think I should learn more about teamwork skills to ensure that every team plan is completed by every member before the deadline; or at least I can come up with some solutions to deal with similar situations.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Familiar Tools- blog 9

This week, I read a pattern called Familiar Tools. This pattern happens when you feel hesitant to let go of some familiar tools that will soon become obsolete at some point. Through this pattern, I can understand that everything has two sides, even familiar tools are not an exception. As the author said, familiar tools can help you solve problems quickly, easily beat another candidate in an interview or increase your productivity at work. However, if you stick to what you already know and ignore the changing of the world, your career will be in jeopardy. That is because over time, many new tools will emerge and some existing tools will become obsolete and lose their effectiveness. If you cannot throw away a part of your toolbox to discover something new and update your toolbox regularly, then it is like you are wielding a sword to battle in a world where everyone uses guns. There is no way for your existence in that world. Therefore, to solve this problem, besides constantly looking for new tools to update your toolbox, you need to face the challenge of giving up some familiar tools that will soon become obsolete to reclaim space for other new tools .

In my opinion, this pattern is really not difficult to implement. In other words, as an apprentice, I understand that it takes a lot of time to learn and get used to a tool, so letting go of what you are already an expert on can be described as feeling loss. However, I wonder what if I keep a tool that I will no longer need or use in the future? Or what if I use a tool I am familiar with, but it does not help me; on the contrary, all it does is make me feel like every problem is suddenly getting harder and I cannot solve any of them? For myself, those familiar tools have now become obstacles in my long career path. So, I never hesitate to replace outdated tools from my toolbox with new ones. In my opinion, throwing away my familiar tools, it may not be something I can choose, it is something that I have to do to advance my career.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Use the Source- blog 8

The pattern I read about this week is called Use the Source. This pattern is intended to show apprentices how to take advantage of the open source era. In the open source world, the ability of self-learning by reading and understanding source code is much more important than asking and waiting for answers from others. That is because only the code can tell you the truth, “the programmer’s intentions are irrelevant if the code disagrees”. That means it is always best when you can understand the code yourself without anyone telling you. However, the problem with this pattern is how to use the source, how to know if it is a good source and how to know if your work is good or bad when there are no exemplars or experts around you.

To answer those questions, the author has made many suggestions to help apprentices use the sources effectively. I can summarize them into two main ideas that an apprentice should adopt to become an expert. First, it’s about self-learning. All apprentices should seek out other people’s code to read and see the difference between the code written by all programmers. When you find any good programmers, you can learn to program like them. By reading the code, you should find out the intentions of the programmers, once you understand the codebase you can try to refactor them to ensure that you can build the projects independently. Taking the time to read and learn code written by other programmers is how you make other people’s tools your own; and that is also how you build your own toolbox, which is used to solve most of your career problems quickly and easily. Second, besides educating yourself from all the open source, you should learn from your community where you might have someone interested in reading your code and give you feedback. On the contrary, you should also be willing to read their code and be able to give them correct feedback or also be able to learn from their code.

In my opinion, Use the Source is the pattern that every programmer or every apprentice should use to develop their programming skills. That’s because I believe that reading the source is how you learn everything on your own; and this is also an opportunity for you to expose with other programmers to see their works and to also share your works to grow together. Moreover, as the author said that the software development field is lacking teachers; and there is no shortcut to learn all the tools for solving all the problems. So, I think open source is one of the most essential elements that no programmer can live without.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Learn How You Fail- blog 7

For this week, I learned a pattern called Learn How You Fail. Through this pattern, the author tells me that everyone is not perfect; and no one can avoid failure. “Failure is inevitable. It happens to everybody sooner or later”, he said. Moreover, the author also suggests to the readers how to deal with their failures or how to reduce the consequences of the next failures. First, you need to identify the reasons which might cause you fail, then instead of wasting your time to feel self-pity about those failures, you should try to resolve it. Gaining self-knowledge about “the patterns, conditions, habits, and behaviors that lead you to failure” is one the most important solutions that can help you become aware of your boundaries and limitations. When your boundaries and limits are found, you should face and accept the fact that you cannot be good at everything. There is still something you are not good at. Your awareness and your accurate self-assessment will allow you to make conscious choices to overcome your failures. There are two options suggested, that is, between working harder to push your boundaries or cutting your losses by accepting your limitations.

In my opinion, this pattern is helpful for all apprentices; because I agree with the author’s opinion that failures happen to everybody sooner or later. That means most of apprentices including myself cannot avoid failures when walking on the long road of the careers. Therefore, exposing with this pattern in advance can help me know what I should do if I fail. I should learn from my failures, learn what causes me fail, learn about where my boundaries or limitations are, learn how to assess myself accurately, learn to accept my imperfection, and eventually learn to make a decision to overcome those failures.

However, if I were asked what my decision would be if I failed, I would choose to put more effort into pushing my boundaries instead of accepting my limitations. It is not because I cannot accept my limitations, but it is because my definition of the word “failure” differs from its standard meaning. According to my own dictionary, failure means that I did not put in enough effort to achieve my goal. However, I believe that as time goes on, at some point, my own dictionary will be updated if there is a situation makes me accept that sometimes effort cannot change the result, then “cutting your losses” is a better choice.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Sprint2- Retrospective Blog

For this sprint, my team, team-1, have worked with two epics, which are refactoring backend and adding commitlint to gitlab-ci.yml for all projects which are reportingAPI, reportingFrontend, reportingBackend. We have finished the epic of adding commitlint to gitlab-ci.yml for all projects by following the instructions. However, the most important goal that our team wants to achieve in this sprint is to make the backend work as expected. First of all, we checked the code to see how they were written, and to see if they were written correctly. However, after I found many errors in syntax and some logic implemented incorrectly in the old code. I decided to create the new backend instead of spending time to fix all of those bugs. As a result, we divided our team into three subunits to work independently with the backend. One would try to refactor or fix the old code as much as they can, one would try to create the new backend, and one would create the test for the backend.

My role in this sprint is to create the new backend and refactor it in the new style. I worked with a docker file and index.js to create a backend server. Then, I created a docker-composed.yml containing node image, mongodb, and rabbitmq, to ensure all the services work correctly. After that, I used javascript to generate all possible methods that can be used to make required http requests, endpoints. In the end, the new backend worked as I expected. It has Rabbitmq service and Rabbitmq functions used to receive all messages from a queue. Then, the backend will store those data into mongodb as two collections, guestInfo and Inventory. Finally, this backend will generate the .csv report when we send the required http request.

As for the results of this sprint, I believe our team has achieved its primary goal which is to make the backend work. However, it is not perfect. There are still some issues that we need to solve in the next sprint to meet the customer’s requests, such as creating a function that automatically consumes messages using Rabbitmq, adding some more required columns to the report, change the _id property in the fake data to studentID. On the other hand, we have also created a test for this new backend even though it is not completed yet. We are planning to complete it in the next sprint.

In summary, there are some differences in how things work in this sprint. We have worked independently on the same problems but in different ways. This sounds like we wasted our time having multiple people working on the same problem. However, for this project, I think it makes sense to do it this way. That is because we all do not have enough knowledge to solve the problem, so there is no guarantee that we can successfully create a new backend. So, we decided to keep it safe by preserving and refactoring the old code while working on the new code. I think this is one of the disavantages of this sprint and needs to be improved in the next sprint. In the next sprint, we will back to work with the regular way, each person should take care of different issues to use their time effectively. For myself and my entire team, we have made some improvements comparing to the first sprint. The only thing I think our team should improve more is that we need to communicate more to understand the project deeply, to be ready for the presentation.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Craft over Art- blog 6

For this week, I read the pattern of Craft over Art. This pattern occurs when beauty takes precedence over utility. However, as a craftsman, you need to make your crafts become useful instead of beautiful.  One of the most important factors of being a craftsman is accepting that you are not an artist. Your job is not to create beautiful and fantastic things to satisfy your artistic creations. Your job is to create a craft which can serve the needs of others and meet the minimum standards of quality. The higher the quality, the more time it takes. Each level of quality always require the trade-off between beauty and utility. So, you have to know what to do with the customers’ requests; and you must be able to balance their desire on the products by telling them what to prioritize in a particular period of time. Moreover, as a craftsman, you need to ensure that you are always willing to deliver the best products to satisfy your customers’ needs. That willingness does not depend on your current feelings or inspiration because you are not an artist, you are “supposed to earn a living at your craft”.

In my opinion, I totally agree with the idea of this pattern, Craft over Art. I like this pattern because it is practical, it tells me what I have to do to create value as a craftsman, which is to make my crafts useful, not beautiful. If you are an artist, you have to create beautiful things for people to admire your creations; but if you are a software developer, who will admire your creations, but useless? When your code does not even work, how will people know the beauty of your creations.

Therefore, I always prefer a simple program, “fifty-line game that makes someone smile”, over a complex program, a million-line game but unplayable. I have also used this pattern when starting to learn something new. My real life example is that when I learned to write a game in python language, I chose the simplest game to imitate and learn from. That is because I know exactly what my goals are. I just want to understand all the basic steps to write a game. The simpler the game, the easier it is to learn. I chose to learn the basic but useful for my understanding instead of the complicated stuff but I learned nothing from it.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion- blog 5

For this week, I read a pattern called Nurture Your Passion. This pattern will occur when you work in an environment where you are exposed to hostile conditions, such as “demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues.” These conditions will sap all your time and your energy. If you do not have a proper way to against that negative energy and protect your passion, you will burn out after only a short time walking on your long road. Furthermore, you may not want to continue to walk on that long road anymore because you are exhausted and completely uninterested in your passion. To prevent that from happening, this pattern will provide you with some solutions to nurture and maintain your passion when you actually encounter those hostile conditions.

First of all, you need to work with yourself. You should find ways to grow your passion and enhance your knowledge over time, such as building some breakable toys to dig deeper, reading timeless books to open your eyes to a different world, joining a group to learn and share your knowledge, or drawing your own map to look for organizations that can offer you suitable career paths. Second, external factor is another important element that you need to care about to protect your passion. You should have a clear boundaries about the types of environment that you want to work in. You should be willing to say “No” or to refuse anything that might destroy your passion. One of your responsibilities as a software craftsmanship is to keep your passion strong, track on your improvement every day, and try to find a suitable environment to develop yourself.

In my opinion, the Nurture Your Passion pattern is one of the most essential pieces that apprentices should know to help them prepare mentally to avoid burn out in the face of hostile conditions. For myself, this pattern is very useful for my future career. I believe that in the process of going on a long road, there are many problems that will drag my passion down and at some point it will stop my progress. So, knowing this pattern in advance is one of the advantages that helps me avoid or eliminate most of the negative energy to protect my passion. As long as my passion remains, I can overcome anything that stands in the way of my progress and continue on my long road.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Find Mentors- blog 4

This week, I read a pattern called Find Mentors. This pattern may occur with every apprentice when they have no ideas of what to do during walking on their own paths. So, finding a mentor is a good solution to help apprentices become more confident to walk on their paths. It is because you can easily learn a lot of knowledge or experience from your mentor who have gone ahead of you. However, this pattern also emphasizes that everybody have to walk on different long roads, so apprentices should know that “no one knows everything”. When you have a mentor, you need to resist the temptation of expecting your mentor to be a master of everything. Instead, you should  have a proper behavior to show your respect or appreciation for what you have been taught by your mentors.

Furthermore, there are many different types of mentors. One of the luckiest case is that you can find a mentor who can watch your development, talk to you and teach you face-to-face. On the other hand, there are many cases where your mentor is not physically available. However, you can certainly gain knowledge by reading their books; or you can also get inspired by their achievements, their stories, or their speeches. Furthermore, besides finding a mentor, an apprentice can also become a mentor to other apprentices at a lower level. That’s how an apprentice performs his transition to a journeyman.

In my opinion, Find Mentor is one of the best shortcuts when it comes to your long road because an apprentice can inherit many lessons that are available without him having to fail as many times as his mentor to get it. However, I agree with the author that it is very difficult to find a mentor that fits what you want to learn and is also willing to guide you. So not many people are lucky enough to find a truly mentor to take a shortcut. On the other hand, I also agree with the author on the point that apprentices can also find their mentors who are not physically available. I believe that, through this concept, the author suggests many other easier ways for apprentices to find a mentor. As for myself, I want things to be easy, so I choose to learn from people who are willing to teach me or give me advice to solve my problems. Furthermore, watching tutorial videos on social media is another way that I find my favorite mentors.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Sprint-1 Retrospective blog

For the first sprint, our team, team 1, have focused on working with 4 projects which are ReportingDocumentation, ReportingBackend, GenerateWCFBReportFrontend, and ReportingAPI. ReportingAPI and ReportingDocumentation are the two new projects created in this sprint. For ReportingDocumentation, we based on the description of the epic called “Create Documentation repository” to add all the necessary files and write the README.md to describe about the ReportingSytem in detail. In README.md, we depicted the role of each project created in the ReportingSytem; we also added the user story, the architecture, and technology sections related to Reporting system from Theas Pantry’s Documentation. ReportingDocumentation is completed as we expected in the first sprint, but we will update more information about each project in the Reporting System if any changes are made in the next sprint.

For the ReportingAPI, we separated the given API from the ReportingBackend into its own repository just like the example API that we have learned from last semester. Based on the example API, we added all the required files to the ReportingAPI. The src folder which includes the paths, responses, schemas, and index.yaml is the only folder that we have edited to create API for the ReportingSystem. This is a simple API, so we finished the ReportingAPI repository in the first sprint without any issues.

The API is similar to the blueprint for ReportingSystem which tells us what should be done in the backend. Based on the API, we know that Get /WCFB/report is the only request that needs to be implemented in the backend. However, the backend of ReportingSystem was made by another group with no instructions for running it. We tried many ways to test the backend and found some bugs in docker-compos.yaml that caused the images and containers to be built incorrectly. Although we fixed those, the backend was not working as expected. We also tried to refactor some of the .js files in the backend to make them look more understandable with the new style. However, since we still have not found a way to check if the old code is working correctly, we got confused when we refactored the backend. So, I think those missions should be redone in the next sprint. For this sprint, our team has not finished the backend yet, we just tried to test the old code of the backend, but we failed many times. So, the backend will be the only project we will focus to work on in the next sprint.

For the frontend, GenerateWCFBReportFrontend, we also based on the example frontend that we have learned from previous semester to create a similar frontend. We added all necessary files like the example; and the src folder is the only folder that we have edited to create the frontend for ReportingSystem. The frontend is still in progress as it is waiting for the backend to be completed. When we finish the backend, we will attach the http request to the method section in the getReport.vue to complete the frontend.

In summary, for the first sprint, we worked with the 4 projects in the ReportingSystem which are ReportingDocumentation, ReportingBackend, GenerateWCFBReportFrontend, and ReportingAPI. We have completed the ReportingAPI and ReportingDocumentation, but we will keep track on and update these two projects if there are any changes in other subsequent sprints. The ReportingBackend and GenerateWCFBReportFrontend are still in progress, but they are planned to be finished in the next sprint.

For the teamwork, I think we worked well as a team but the only change that I would suggest for the next sprint is that we should focus on solving the issues established in the sprint backlog before focusing on anything else. Our team focused too much on working with the backend, which consumed a lot of time with no results, and forgot what should have been done in this sprint. Although we completed all issues in the sprint backlog of the first sprint in time, the work was not evenly distributed among the team members. So, I think that is the point we need to notice to improve for the next sprint. On the other hand, as a member of group 1, I think I should communicate more with the whole team to figure out how to work as a team more effectively.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Breakable Toys- log 3

This week, I read a pattern called Breakable Toys. This pattern occurs when an apprentice needs an environment where the apprentice is allowed to fail and redo his projects as many times as possible. The main purpose of this environment is to make apprentices or software developers feel free to make mistakes and they can learn from failures until they succeed or until they have a deep understanding of a concept. To solve this problem, the author recommends to his readers a solution called Breakable Toys which can be broken many times; and the consequences of the failure will not affect anyone else, except the person playing with the breakable toys. The breakable toy here can be anything that an apprentice can use to practice techniques, try out new ideas, or to learn new things. Furthermore, breakable toys should be relevant and useful to your life, such as building a wiki, calendar, address book, or game. A breakable toy also should be fun to ensure that you enjoy playing with it and can stick with it long enough to learn everything you need and to enhance your essential skills.

For myself, this pattern is really interesting because it is similar to a method I have taken to learn a new concept or to practice a technique. However, after reading this pattern, I think I have used breakable toys to learn computer languages ​​in the past. To learn the Java language, I wrote some programs that are used to manage a coffee shop or a bakery. My programs would take input from the customer to place an order, then print a receipt, but at that time I didn’t know any tools to store those data into a system. Fortunately, I had the opportunity to learn about MySql, a tool that helps me store and manage data of a system. So, I tried to develop those programs to link them to the database in MySql. That way, I can play with the Java language and also gain a deeper understanding of how to use MySql tools. Furthermore, I have also applied the breakable toy method to learn python language. I wrote some of my own games in python with simple ideas after watching a few tutorial videos on YouTube. Although they are just simple games, it is a great environment for me to play with what I want to learn. On the other hand, I can also freely break the code at any time without worrying too much about the consequences. In conclusion, I believe that breakable toys is a good method for software developers to learn and to experience any tools from zero to hero.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.