Monthly Archives: February 2022

Sprint Retrospective – Sprint 1

This first sprint could have went better but it is to be expected as it is the first time for most people to work like this. There group so far seems to have congealed well and can communicate well with each other. We were able to obtain the necessary information for helping build the project and now we should start to move at a faster pace to get the project done.

There hasn’t been much to critique so far since we haven’t quite starting working on coding yet but some of the issues that have come up so far would be with the way this group has been going . This process is still new to everybody so people are still taking the time of getting used to working on these different issues. There is the issue of the communication of the team so far. The way that the team is going to work isn’t quite clear and the path we are taking needs meeting time to figure out so that . The team could improve by communicating more with each other more, especially when the team tries to set up meetings outside of class and part of the team does not respond or does not make it clear if they are going to show up.

Then for me personally, I don’t think that I have made much of a considerable impact so far as the team just recently has the means to move forward with the project. I have contributed in discussions in the team and helped set up tools to use for the project later on. I could improve as an individual by contributing more in the discussions and think of more ideas on what we should be doing in the project. I also could have done more on GitLab as so far while most of the stuff added was nothing new and mostly mimicking what we have already done in the past, I probably could have taken the initiative to add some work into GitLab instead of another person doing it.

The majority of the time spent on the first sprint was getting our bearings together and figure out what exactly we were supposed to do in this sprint. At first, there were hopes of getting the API up and running by this first sprint ends but that was later put down due to confusion on what the specs and information was needed from other people. It took quite a bit of time to get this information as it was obtained at the end of the sprint which means that the coding will haver to wait until the 2nd sprint. There was also work that we had placed into the sprint backlog that should have been saved for later sprints as they required information and buildup that we did not have at the time. This fuss over issues like these had costed us time that could have been used elsewhere.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/sprint1-epics/-/commit/2645e65c3cc2c2346b808547cf71c41015d36f15
I added the tools necessary to the backend devcontainer and helped some team members on running the tools.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #1

               As the first sprint of the Naturalization Interview Confidence Environment project I have been assigned to work on has finally come to an end, I think that it is time for me to look back on what my team and I managed to achieve, as well as reflect on what I think went right, what went wrong, as well as which of my actions I believe may need to be adjusted before the upcoming sprint begins. Initially, I was somewhat fearful that we would be off to a very rocky start, given how the project itself was borderline non-existent due to the lack of code or repositories from the get-go, meaning that we as a group started work from square one. However, such fearful sentiment had soon dissipated as the sprint went on and more work began to be done. That is to say that, for such circumstances, I believe that this first sprint was an overall positive experience, given the people that I was assigned to work with in my current group.

               In this sprint, my team began working on 40 issues across 8 epics, with around 29 of them being resolved by the end of the sprint. Though everyone was assigned issues to create and populate needed repositories, everyone’s main focus included looking for and learning what Native development framework should be used for the project, in which case I was involved with Ionic Angular. I was involved in the following issues (not including duplicated issues):

               As I mentioned previously, the first sprint overall went fairly well. Given how our main focus was to choose one of the three recommended frameworks that we had found (React Native, Flutter, and Ionic React), we were divided into three sub-teams of two members, with each sub-team studying a specified framework. Such dividing tactic worked very well for us, as each team could learn one framework and communicate their findings, such as what they believed would work well for the project. Overall, our method of dividing work among individual group members or sub-teams seemed to work very well for us, especially evident on the topic of choosing a framework because everyone was great at communicating their perspectives. This is also due to the fact that, even though we may have not worked with each other before, we still had some very good chemistry that made communication much easier and more productive.

               However, what did not work well for this sprint was the fact that we, as a group, were lacking on the aspect of properly documenting what takes place during meetings. Though our meetings in class were productive, we do not have any records of what was done or said during the meeting except for some issues posted on the issue boards, and this lack of documentation may bring some difficulties to people who may work on this project in the future. As for myself, I admittedly felt like my time management skills for this sprint were not exceptionally great, given how I devoted disproportionate amount of time and effort into learning Ionic Angular in a somewhat selfish manner, as if I wanted to learn this framework as part of a hobby rather than as part of the project.

               Regardless, this first sprint was off to a very good start, all things considered. Of course, there are some aspects that we have all agreed that we need to really work on as a group, namely the aforementioned lack of documentation of our meetings. Thus, we may need to develop a strategy that can help us keep a proper record of each meeting without breaking the flow in a distracting manner. As for myself, I will definitely need to improve on my time management skills and learn to devote the appropriate amount of time on tasks that need to be done and further learning of React Native.

Direct links to issues:

  1. Scope for the Ionic framework: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/12
  2. Create demo app in Ionic Framework: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/3
  3. Add a CODE_OF_CONDUCT.md file to the “Documentation” repository: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/8
  4. General Resource Collection: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/2

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Retrospective 1

The First Week

On our first meeting, team formation, we missed two people due to health reasons, so I managed to get all the information that they will need in this meeting on the team discord, during class time; by that way, I can ensure that no one misses anything even if they are not showing up physically. The first week ended with no problem as everyone can gain access to the repository and have their first glance at the code that they will be working on.

The Second Week

This week started with a Sprint Planning session for my team, with my role, I attempted to initialize the conversation. By going through the code before the meeting, I was able to explain to everyone the structure of the code, separate the backend and frontend team, and the objective of the first sprint, which is fully setting up the backend and the frontend repositories. However, just going through everything verbally in class, in my view, is not enough. I even told them that we should actively push new issues if we can find them on the board. Therefore, in the evening after class, I sent a message and asked if anyone could voluntarily join me on Discord to discuss and find new issues. The result?! Only one joined me and we created up to 30 issues in total and there was no new issue created the next day.

On the standup meeting day, I explained to everyone once again about the issues board and adjusted it based on Professor’s advice and epics so by the end of the meeting, we had a decent issues board that we can start working on. Besides, during this meeting, I suggested that we should go with the branching technique that relevant issues will be put in the same branch so everyone can work on their local repository and push up with the least number of conflicts. Therefore, I also work as a Git repository manager for my team.

The Third Week

Again, I should initialize otherwise it is going to take much more time than needed to have the first version of the repository that we want. My idea for the frontend was to have a branch having the same structure with the one showed in epic, which is created by vue/cli. Hence, I installed vue/cli into my computer and add that path to the Windows environment variable and created the project with two components and one main .vue. By pushing this to a new branch in the remote repository, I added 6 new issues that 3 people in the frontend team can start working on.

On the backend side, there was no actual setup, but we had to figure out what they did last semester and move on from it. It turned out the code was a bit hard to understand, especially Docker. Since we have 3 people on the backend, one worked on the JavaScript files to put it in a microservices architecture that I created in another branch, another one worked on the API, while I was working with Docker and the pipeline.

Week 4 and Week 5

From this point, the frontend team was working fine, they only needed me to review their merge requests and some branching questions. On the backend, my teammate finished the API quickly and ran in to help me with the pipeline and docker. The final result of these weeks was this branch, where we deleted the test pipeline from the CI/CD, rewrote the Dockerfile with the understanding of the ENTRYPOINT and its script, and had the code working locally when executed with yarn.

Last Weeks

We ran into another problem in the backend, which is socket hang up if we use docker-compose, my teammate figured out that problem came from the wrong mapping of SERVER_URL, where we mapped it to 10001 on localhost but 3000 in docker-compose. Then, I finished the last endpoint that we had the backend working.

Conclusion

Based on what I wrote so far, my team has good programmers but in terms of initiative, especially when I made the issues, we need more talking on this for the next Sprint. Since our team meets the objective of this Sprint, I hope that everyone can carry this heat to the next Sprint where we are going to have more abstract topics to be working on. As an individual, I’ve always tried to help other team members as much as I can and complete my own task, but one person, I don’t point him out specifically, I almost hear nothing from him during this Sprint. Therefore, next Sprint, hopefully, I can manage to hear more from him to manage everyone’s task fair and effectively.

From the blog CS@Worcester – Vien's Blog by Vien Hua 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.

Apprenticeship Pattern “Unleash Your Enthusiasm”

What I have found interesting is about this apprenticeship pattern is that those who are enthusiastic about the work they do might not fit into their future team. It is a worrisome thing and that although there are ways to nurture your skills outside of work, most people tend to look at work as a way to work with others and expand their knowledge in software engineering. I had never thought that being enthusiastic could be detrimental to a team, but it makes sense that already existing teams probably do want to deliver on projects and their work instead of helping someone new out. It was nice to read that teams that are comfortable with themselves do beneficial from a fresh new mind and injecting them with excitement and questions will be beneficial to the team.

What I found most interesting when reading about this pattern is that as a soon to be graduate, we have the most excitement about the future of growing in our careers and that this pattern tells us that it is time in our careers to take the most risk and to speak our mind. We have very little to lose staring out and our ideas and passion will be more beneficial than detrimental to our team. As an apprentice, expressing ourselves is what we should be doing and it’s healthier for us to grow as a person that way. Instead of worrying about fitting into a future team, we should worry about being that spark that brings new ways of improving the team.

I as a person am very enthusiastic about everything I do. It does worry me that I might not fit into the team I work with in the future, but I hope that everything that I bring to the table is something that can help everyone. This pattern does make me thing about how important it is to work with my team and that hopefully my enthusiasm as a new graduate can help elevate my team to the next level. I also have experienced times where I have brought up ideas to engineers and then they shoot me down, but I had never thought about asking about how to improve my suggestion instead of just letting it go. This solution is a great way to figure out how to do better instead of thinking that your ideas are not good enough.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective:

Our team is in the process of developing an OpenAPI specification to connect the NEST android application to a remote MongoDB database. It currently uses a local SQLite database to store its Guest Information System data. There are 5 developers in our scrum team. Our sprints are 3 weeks long, with each developer being allotted 6 hours’ worth of work in a week, over and about the 3 hours per week we are using for class time and scrum meetings.

The project started out with 4 Epics, which we broke up into 18 issues initially. The 2 primary epics were API and Backend. Given that the backend work couldn’t be specified until the API was defined, we had to be creative in how we distributed the work. Since the team members were not that familiar with the specific skillsets of the other members, it was difficult at times to determine who would be assigned to which tasks.

I acted as the scrum master for this sprint, which was surprisingly difficult to manage. The majority of my time was spent trying to figure out the API and adding a basic framework to our docker API project. Other members of the team developed container shells for the API and Backend, as well as adding documentation to our general and documentation repositories.

We ran into issues where issues were designed too vaguely, resulting in some tasks being defined twice. The team did a good job of giving weights to tasks, but we could use more effort in knowing the status of each individual.

This may have been an error on my part, but the scrum meeting task of each developer telling (1) what they have done, (2) what they now will do, and (3) if they had any questions turned into longer discussions, therefore not giving enough time to other team members to communicate enough.

I communicated with Professor Budge from Nassau Community College, who teaches an Android class at that school, and is a key contributor to the LibreFoodPantry product. Since our correspondence took 10 days to solidify a general design, I had jumped the gun on the task of developing the OpenAPI by assuming the full contents of the SQLite database were to be stored in our database, as a result, I developed a plantuml design for 8 tables that were not ours!! https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/tree/main/bundles

I also produced a yaml bundle of the Product table. We decided during sprint 1 review that this work should be offered to the FoodKeeper team, another subgroup of our Capstone class.

During the last week, Dr. Budge, after a series of emails, led me down the right path for what we will need to do over the next 2 springs. We are responsible for the data in 2 tables (collections on MongoDB), QuestionnaireSubmission, and GuestRepositoryEntry.

Our sprint’s work should probably have been more focused on design than it was. With people new to Agile/Scrum and some of the underlying technologies we are using, in retrospect, it is clear there were mistakes in our process we will learn from. I think the main message is that until a design is cast in stone, then any technical efforts afforded to the project before the design is solidified should be considered as disposable.  

As a team, we spent a lot of time considering our methods for testing what will be written. At first, it seemed that best approach was to use swagger preview to test the API, given that the backend wouldn’t be in place yet to test with actual “curl HTTP … “calls.

It has now become clear that we really need a new Epic to fully system test the project. W\Three members of the group have built Android Studio and/or Visual Studio Code version of the NEST application itself. The new Epic could outline the work necessary to make a test version of the NEST app to do the actual calls. This will dramatically help the team that will be working on the NEST app next fall.

I have decided that I will relinquish my role as scrum master for sprint 2, which will give another team member a chance to gain experience with this job.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Week 4: Apprenticeship Pattern, Craft over Art

For this week’s pattern, I chose ‘Craft over Art’ from Chapter 3. The title is self explanatory but I’ll still explain it anyway. The context is you are being paid to build something that will solve a problem for a customer. Simple enough context but the problem, solution, and action have much more material to learn from, usually the context just lays out the groundwork for these. The problem was you are given an opportunity to do something fantastic, although these is already a proven solution. So, originally I chose this pattern because I learned last semester in Intro to Astronomy about Occam’s Razor, also known as the principle of parsimony or the law of parsimony, is the problem-solving principle that “entities should not be multiplied beyond necessity”, sometimes inaccurately paraphrased as “the simplest explanation is usually the best one.” (from Wikipedia). Since then I’ve been a fan of just favoring the simplest solution to something instead of an overly complex solution. However, I haven’t been putting this into practice as I’ve been overthinking too much on problems in my life that could be solved so much more simpler.

For the solution, it kind of can be summed up to the first line in the solution section, “Focus on delivering value to your customer
over advancing your own self-interests.” As a programmer, you don’t want to have a app that pushes the boundaries of CS and has a million lines over a simple app that will satisfy someone with much fewer lines. I believe I already have this kind of thinking for many things, I’m too much of a practical guy but sometimes I overthink way too much and coding is one of the things I definitely overthink in so I think this is a good solution to my bad habit.

As for action, find an opportunity to do something useful rather than beautiful. The action wants me to look back and think of when I chose artistry over utility. I can already remember of a time I overthought something way too hard, it was in software testing class and I tried making such a complex program for something that didn’t need to be overly complex. The program could’ve been just a few lines instead of the program I had thought out of in my head which was way too many lines. Anyway, I thought the action was fine, it seemed more like a common sense solution but I’d imagine they have to write these actions out for people to read because sometimes people don’t know common sense.

From the blog CS@Worcester – Brendan Lai by Brendan Lai and used with permission of the author. All other rights reserved by the author.

Post #2 for Apprenticeship Patterns: Perpetual Learning: Breaking Toys

The Breakable Toys describes how to set up a situation where you can continue to learn and make progress with your career without unduly affecting your performance as a developer on your “day job”. The idea is to create a home-based work environment where you can develop product to enhance your skill set by making small products on your own. If these fail, or turn out to be flawed in some way, there is no downside, because you are expected to have learned lessons on your own. Although most work-paces are reasonable when your coding doesn’t come out perfect the first time, it certainly is much better for your career if you develop working, useful, optimal code in a reasonable time frame.

Many developers don’t have the time or inclination to do this, and turn out to be productive employees, but those who guide their own career by making their own products on the side are much more likely to succeed both intellectually and financially.

Throughout my career, I have always been motivated to keep up with the current journals, attend classes and conferences, and to always have a product I was developing on my own. In the 1990’s I developed a music-based utility program for guitarists called “Guitar Companion”. It’s most impressive component was a notation editor, but it also had a metronome, tuning fork, band manager component, and 3 CD’s with Video Guitar Lessons. I wrote it in Visual C++. But over the years, converted it to new technologies, and sold it through a website I had constructed fo4r this purpose.

From 2010 to 2015, I developed a number of Android applications for musicians. The one that turned out the best I sold on Google Play and had over 20,000 downloads.

This was all great for my career growth, but I would have never done this if I were not passionate enough to put in the time and effort. I highly recommend this approach to anyone who really loves to code. You are your own CEO. You call all the shots. You become sought after by companies, because you have developed depth in your code base that few can attain working under the strict protocol of working for someone else.

It also works in reverse. I would incorporate functionality into my “Toy” products that I learned at job-sites, as well as using things I wrote at home into my work products. It is pretty great when a boss asks during a scrum “who knows how to do X”, and you raise your hand. “ I do”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

Next week, my second Sprint will start. My team worked really well last Sprint that we met all the initial objectives; however, the context was we reimplemented something that we’ve already known or heard about, which only needs a bit more searching in order to fully commit the work. This second Sprint we are going to have lots more “abstract” topics, materials that we weren’t familiar with, so I expect we might get frustrated, overwhelmed when we come to it.

This situation might somewhat be similar to what I’ve read in the “Expose Your Ignorance” section, the only difference is that I’m not in a nine to five working environment. Per description from the book, we have been brought in some projects that we are unfamiliar with some of the required technologies; but team members believe that we can deliver because we have a deep understanding of the business domain or some other aspect of the technology stack being used in a team, or perhaps we are the only person available to do the job. In my view, learning and implementing what the team needs while carrying their expectations is difficult, especially when it is something that we have no experience in.

Finding myself falling into this issue in no time, I might consider taking the solution written in the book which is to show my teammates that the learning process is part of delivering software. Therefore, knowing how to learn the technology effectively is important because I should know which part of my current project will need this and go straight to documentation with relevant information on it. Furthermore, asking questions, instead of hiding our issues, exposes it to everyone in the team because no one will be annoyed when we show them what we cannot do, instead, not telling them that you are having problems is what keeps the team behind.

Luckily, I consider myself a bit “figurative” when it comes to asking questions since I don’t mind asking anything that I didn’t understand. Compared to myself 3 years ago, it’s a huge difference as I was that shy guy hiding my weaknesses, I find learning is much more efficient when I can ask everyone what I don’t know, of course, after a period of time thinking and testing and implementing. Having questions is a good practice, but it doesn’t mean that we should ask without already researching it.

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

Sprint 1 Retrospective

As we just completed our first sprint, my overall thought is that we did very well, and we have learned from our mistakes. One of the things we did well was that we spit up the work evenly. Everybody had an issue they were working on at all times. And as a group, we agreed that we each did a fair amount of the workload. Another thing that went well is that we completed all of the issues we set out to, from the beginning. Another thing that went well was the merging workflow. With the exception of the first week of development, we were able to complete issues, and merge to main with minimal merge conflicts. How we were able to do this, was making sure we had the most current version of main, before commiting, and making sure to stay within the scope of the issue while coding. Overall I am pleased with our performace, but there are some things that did not go as well, and could be improved upon.

One thing that did not go as well was our communication in GitLab. We were mostly discussing our issue in person. So the discussion within the issue descriptions were not showing the entire story of an issue’s development. We were also relying too heavily on discord, instead of using GitLab comments. On a related note, many of our issues in GitLab were not named clearly. We also had issues that were created in the wrong project. Our naming conventions in general need to be standardized moving forward. We can also improve on only having one person working on an issue at a time. There are a few things we can improve on outside of GitLab communication.

One unrelated thing we can improve on is keeping our stand up meetings to the alloted 15 minutes. I know that this is very important in the real world. We can achieve this by staying on topic, and by not interrupting each other. As a group we have discussed how to improve moving forward. But in order to work effectively, I also need to consider how to improve as an individual.

One thing I can improve upon is staying on task when working on issues. In independent projects, or larger academic projects I did not use issue based Scrum development. So I could jump from one method, class, or subproject to the next, as I realized I would need them. This is not an effective strategy for large, group based development work. During our first week, I had to review a yaml schema, and I decided to validate the yaml, using node modules. I ended up spending an hour doing work that I was not assigned to, and made changes to the branch outside of the issue. This was an important lesson for me, and something I will avoid moving forward.

Issues completed:

Add Standard Files to API repository: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/3

Add Paths for CookingMethods and CookingTips: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/16

Test Class Template for Backend: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/19

The issue that stood out the most to me was creating the Test Class template for the Backend. It was really interesting to learn about Unit testing in node. We are using J Unit in CS443. So it helped me solidify that knowledge to see unit tests written in a different programming language.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.