Sweep The Floor

 Often times when you are a newcomer on a project, the team does not know your capabilities and does not know your worth. It is vital that you show your value in any means possible. This is often accomplished by taking on the unglamorous tasks but preforming to the highest of your ability. Since you are new, the team can not immediately trust you to be thrown in the midst of the project as it can often be dangerous without understanding the full scope, depending on what is being worked on. By completing these seemingly meaningless tasks to the best of your ability, it will help to prove our worth to the team. Eventually, all those “meaningless tasks” will be vital to the project and if the team is able to see them done to highest quality, they will be able to incorporate you deeper into the project.

I find this pattern to be one of the most useful patterns I have read, not only in the computer science world but in life. Often times when starting any new job, you are given the low-end tasks. When I was working at a grocery store when I was younger, I was given all the tasks of taking out the trash, cleaning the floors, and a lot of other unpleasantries. However, I was always on top of these and never had to be asked for them to be completed. In a short time, they had moved me off of these tasks and onto managing the next person who would be doing them. By simply proving my worth early on, in what seemed to be meaningless tasks, I was quickly able to gain my teams trust.

I think this pattern simply reinforces the mindset that I have always had whenever you are beginning something new. Often times people will come in with their head held high because they were considered extremely competent at their old work. However, if the new team you are a part has no reason to respect you yet and you come in with an arrogant attitude, that will cause the team to immediately not respect you. You must always put in the grounds work in order to start to build anywhere.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

Often times when moving forward in your career, you will end facing many different projects that can seem overwhelming when you do not have the full grasp on it yet. This can cause people to shutdown due to their sheer lack of motivation after being discouraged over and over. This pattern says to help fight this type of interreference, it is also okay to Retreat Into Competence. This is essentially moving back onto work that you are confident in and able to complete easily. This will allow for you to gain the needed confidence and motivation in order to start working on a harder, lesser known task. However, you can not retreat into competence for too long or the dread of restarting the hard work will outweigh the problem prior.

I find this pattern to speak to me in many ways. Often times I feel myself overextended and worn out from trying to learn a hundred new things at once in order to complete a certain project. When this happens, I tend to get discouraged easily once things start to fall apart. Thankfully, I had realized how useful this pattern is without knowing it existed. When this happens, I will always tend to move back to a smaller easier project to complete before returning. The pride of accomplishment allows for me to get back into grinding on the harder project.

I believe reading this pattern helped to reinforce the idea that returning to something more basic is not always a bad thing. Often times I will feel like I am wasting my time on simpler tasks, so I move to the harder ones but end up accomplishing neither because I lack the motivation for the harder task. From here on out, I plan on using a smaller, more well-known task as a way to kick start my work and allow for my confidence to grow. From there I believe it will end up becoming much easier for me to take on these large-scale tasks while still also being able to feel like I am continuously accomplishing something towards my goal.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Reflect as you work

For this week Apprenticeship Pattern, I chose to read about “Reflect As You Work”. When I read the title, my first thought is that this habit is pretty necessary, but it should not be too hard to have a chapter dedicated to it and turns out I was entirely wrong about it. The pattern starts with putting out the question of whenever a developer can consider themselves as “experienced” and how would that process be in order to reach that destination. The author then went straight to the point to explain how just reflecting our own work would be a best way for us to gain more experience. He explains several techniques like making a Personal Practice Map, which would involve writing down all the practices that we do during the development process and share with others, and mimic what they do in order to be better in the field. I think this particular technique would greatly help a lot of new developers in the field who does not know what to expect when developing and would end up doing what they think is the best without having a chance to consult everyone about that decision. The author also mentioned that this reflecting would involve a lot of observation on the practices and the processes of journeyman and master craftsman on the team, which I would say highly beneficial for everyone, not just the newcomers. He also gave out some examples of practices that was not discussed before, but then becoming more popular as everyone has proven it to be a lot useful. The author then concluded that people would start called us experienced if we hang on long enough and it should not be our goal to earn that title. Experienced should mean that we survive through long enough and our dedication to exploring, not necessarily how much we learned. He also made a really good point that anti-experience, or developing bad habit, can also happen too and we have to keep that in mind to set out goal to be “skilled”, not “experience”. This I would say the best thing I’ve read in patterns so far, since it is directly related to what I am doing as to earn the same amount of experience as anti-experience while doing personal projects alone, without any guidance of any journeyman or master craftsman. I can say that I do learn quite a lot from this pattern and I certainly would keep in mind these suggestions that the author made.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

At the beginning of this week, we finally reached the end of our second sprint, once a again, completing the back end for the LibreFoodPantry Approve module. My thought on this sprint is that our team did fall behind quite a bit on the goals we set out to finish at the beginning of the sprint due to the fact that we ran into much more problem than we expected and we don’t really have much time to meet up with each other like the last one. Nevertheless, we were still able to achieve a decent amount of goal and almost reach the point to be deployable as a product for just the back end.

List of what I accomplished during the last sprint:

– Successfully implemented CI/CD in every main repositories and get it up and running to check for merge requests build

– Adding all the required endpoints for the REST API system and set it out as a base for the front end to access data

– Successfully established connection between REST API and mySQL database on each member’s machine with a customizable config file to fit with multiple server setup

– Completely overhaul and clean up code for REST API to be more optimized and modular

– Front end wise, John and Kevin was able to make a few basic component to display guest information, made a lot of effort to learn about Material design, and experimenting with communication with the REST API

With a lot of work putting in developing the back end, I learned a lot about how to make connection between REST API system and mySQL. There are a few small things that I can pick up through this run too, like the differences between Docker Desktop and Docker Toolbox, making CI/CD script with different images, and so on.

During this run, it went really smoothly and we only ran into multiple communication issue, and small things during the development process like the date and time is behind when data point is fetched from the database because of timezone differences for some reason, or having to deal with numerous bugs that the default date object in Java caused. Other than those, I think we’ve done it pretty well. 

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 2 – Retrospective

Sprint 2: 03/04/2020 – 04/08/2020

As we successfully ended Sprint 1, on 03/04/2020 we started planning our Sprint 2. As a start, we decided what issues we should create, how many issues we should complete in Sprint 2, how are the issues going to be assigned, and what the weight would be for each of the issues. Our top priority for this Sprint was to get our service implemented.

These are the issues we planned on working on Sprint 2:

  • Questions for Thea’s pantry staff
  • Documentation: Create a Clean Code documentation
  • Determine what REST API endpoints we need to create
  • Create MongoDb database for UpdateGuestService
  • Implement WebUI in Angular App
  • Learn about Angular testing
  • Create endpoint in the backend

Other than these, we also had to work on the “Design Frontend Architecture” issue on Sprint 2, since we were not able to finish it on Sprint 1. The information we had gathered on Sprint 1 was not enough to design this document. However, after we decided on what our components would be, this issue was successfully completed with a pull request being merged on time.

During the Sprint 2 I worked in multiple issues and supported the team with issues discussions and PRs:

  • #1 – We decided to create this issue to store any questions we thought would be important to ask Thea’s pantry representative. As a team, we came up with good questions, and we were happy to get them answered before we started the implementation.
  • #2 – After we discussed with all members of the team what IDE we all should be using, we decided to use the Visual Studio Code.
  • #3 – This issue’s purpose was to create our own Clean Code documentation so that we could standardize our coding behavior. We discussed in class and decided to read and follow the first 5 chapters of the Clean Code book instead.
  • #4 – I haven’t contributed to this issue, but I have read and understood everything discussed on this issue.
  • #5 – I have been working on this issue since it got created. I have been constantly editing it according to my teammates’ suggestions.
  • #6 – I have helped to implement the WebUI in the Angular App. We were able to design a nice layout of the page, but there is no functionality added to it. We will continue working on it until the whole team approves the merge request.
  • #7 – I have reviewed the merge request of this issue, but not constantly.

In this second retrospective, my team and I need to reflect on these points:

1- What we need to stop doing

We need to stop working on the same branch. Even though we can split work, it is better to have separate branches and merge small changes and working code constantly, so that we do not access remote branches to see the changes.

2- What we need to do less

We should not focus only on the issues we get ourselves assigned to.

3- What we need to keep doing

We should continue reviewing each other’s issues and merge requests.

We should continue discussing, reaching out for help, and help each other.

We should continue checking GitLab on Tuesday, Friday, and Sunday to be on the same page with the team.

4- What we need to improve 

We need to improve the weighting estimation for issues we create, to be able to finish them on time.

Conclusion

We successfully closed Sprint 2. Even though we didn’t close all the issues we planned, we did close most of the issues in this Sprint. As a team, I think we worked better on this Sprint than we did on Sprint 1. We were able to communicate, discuss and collaborate when it was needed. Although we moved to zoom meetings, communication was not a problem, contrariwise I think zoom meetings and GitLab discussions were very effective. The end of this Sprint will be a good start for Sprint 3. It’s time to make the UpdateGuest service functionality our top priority!

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

A Different Road

Just because they’re not on your road doesn’t mean they’ve gotten lost.

-H. Jackson Brown Jr., Life’s Little Instruction Book

“A different Road” pattern shows us exactly how to follow our map and recall what we know. For some time, we might have walked through a road, and then realized that this route is not an acceptable option for us because of our drawn map. It has happened that we have found a way that is more in line with our current values. Based on this pattern, if we permanently leave the road, we will still have values and principles established along the way. This pattern shows different examples of people who decided to move on into something else and come back to bring new ideas to a company. It is okay to set people free if they have different ideas and let them come back along with the new interactions they have discovered. Unfortunately, traditional software companies are not so welcome. Such detours are also seen as questionable shortcomings in your profession you must explain later in the future. You would hope that your reason for why you left and why you came back will become important within your belief system. However, this shouldn’t be an issue for someone who wants to pursue their dream in a way or another.

What got my attention in this pattern is that we shouldn’t be afraid to do something else with our life, no matter the risks. The skills we have gotten during our journey will not leave, and at one point they will be useful wherever we go. As a software developer, with the experience, we will enrich everything we want for our future. Leaving behind the software development journey to become a professor or an instructor could be an option in our lives. We may like it or not, in the end, it’s all about trying to find where we and our knowledge best fit. I have always thought that leaving a company and coming back after a while wouldn’t be so good but based on this pattern it wouldn’t be so bad. However, there are several reasons why we would and wouldn’t want to go back to our previous employer. But let’s be positive and do what we feel it’s right. If what you were doing didn’t feel right in your career, you have the chance to return to a higher level and be where you always wanted to be in your previous company or move on to another one.

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

Retrospective #2

There is one month left in the semester and it is already time for the second retrospective blog. This was certainly an interesting sprint due to the unprecedented pandemic that took the world by storm. Luckily, it doesn’t hinder us too much as technology exists enough to where we can still collaborate with our partners and other teams thanks to discord, Zoom, Gitlab, etc. To begin this post, I’ll be posting links to the progress I made this sprint.

This is thew link to our database repository because I had to modify it to reflect the new changes that were made after our meeting with Joanne. I am also using this link to show that the branches have been merged because I am no longer testing it.

This is a link to another one of my closed issues. This issue pertains to connecting the database to the server. While, I haven’t figured it out quite yet, there is a link in this issue with a tutorial that I have been using to experiment connecting servers with databases.

There wasn’t a large amount done by me on this sprint due to the COVID-19 outbreak which caused us to have a whole extra week off of school, and completely shifted us to online learning. However, there was a large improvement from the last sprint. Our Gitlab use improved immensely between sprint 1 and sprint 2. We started using the “blocked by” features to make sure issues were getting done in the order that they had to be. We also started commenting more on our issues, so everyone can see our progress rather than just our group knowing what we did. Also, I feel like our communication worked better compared to last sprint, but it could definitely still be improved.

As for what didn’t work well, I think that I could have gotten more work done for this sprint seeing that I only worked on database stuff for this sprint. I also feel like were still only involved in our each individual part of the project when we need to be more involved in each others parts. I also believe our communication with other teams could still use some work especially for this upcoming sprint because if we have time, we need to work on the aesthetic of our web application.

When it comes down to improvements, I know that I can try to work on a little more for this upcoming sprint. Once I figure out how to connect the database to the server, I can then move on to starting my work on Docker and helping everyone else with what they have to do, and hopefully we’ll be able to get to aesthetic because I feel like I would be helpful on that front. As for the team improvements, I still think that our communication with each other could be improved. For example, we can have more zoom meetings with each other and show each other our work. I also think we should talk to the other teams as well because they might be able to help us with things that we are stuck with. Besides that, I think our team is in great shape for the last sprint.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Sprint 2: Retrospective

It’s time for another sprint retrospective. Last sprint, our team focused on researching needed technologies and structure of our micro-service. This sprint, our team focused on implementation.

We started with deciding coding standards and preparing for the visit with pantry staff. We decided to follow the principles of the first five chapters of Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin. Lucky for me, I was reading these chapters for my software process management class. We also decided our code formatting standards, so collaborative work does not get reformatted constantly. After these issues were completed, it was spring break and I started focusing on solo work.

Last sprint, I learned how to implement and test a Mongo database with a schema defined by the Node.js package called mongoose. With this knowledge, I started implementing our micro-service’s database requirements. I designed a guest schema with all the data fields from the register team. Due to the nature of our update service, our schema does not require any data field except for the guest id. I also added an additional date field for when the update was made that is automatically added. I then wrote tests for checking the schema and the interaction with the database using mocha. At this point I decided to wait for my work to be reviewed by my team and started work on implementing our endpoints.

Our service only needed a few endpoints, a POST for new updates, a GET for obtaining an array of updates from a range of dates, and possibly a DELETE. I managed to get a couple endpoints started before my previous work was reviewed. After the review I had to focus on the guest schema again. While I did not focus on the endpoints after this, I did manage to fix up the incomplete GET endpoint when I had the time.

My focus for the rest of the sprint was getting the schema work ready to be merged. The review process was much longer than I had anticipated. With my merge requested branch bringing a lot of changes, the issues I needed to fix were diverse and plentiful. The issues ranged from simple oversights, to writing documentation. At this point, the schema branch has been through many changes and is nearly completed.

The rest of the work I did was reviewing my team’s work and familiarizing myself with it. The rest of my team worked on the front-end, implementing our UI and how to test it. At this point, our team has the UI design completed or nearly so.

Overall, I feel good about the work that was completed even though it took longer than expected. I think we have improved our teamwork since last sprint. The main lesson to learn from this sprint for me was to expect a lot of editing and to assume issues will take longer than I initially guess. Something we could improve on is the scope of our issues. Many of our issues could have been broken down into smaller issues that would be quicker to complete. After last sprint, we gave a work-in-progress limit to our review column to try and force reviews, but it ended up getting clogged by wide scope issues with a lot of work to review. I believe our team will be able to continue work on our micro-service and hopefully be able to have some functional software after next sprint.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Running Server Side Code and Serving Up Some Tasty Results

Storing files on a server from a mobile app is nifty trick, but this week for my independent study I began running code on the server to extract audio features and make predictions on a spoken digit.

In its current state, my app allows a user to record an audio file. Once done, the file is uploaded to the server and will extract the audio features and submit it to the machine learning model, which currently predicts a spoken digit. The server then allows the user to look at specific information about the audio file: a graph of the certainty of which digits were spoken, the waveplot, and the MFCC features.

This basic framework allows room for growth in the future. First, I have been taking care to design the app to easily add additional features for the user’s viewing pleasure and plan on adding a spectrogram and FFT this week. Second, the machine learning model is currently trained on MFCC features only, but this can be retrained to work better using other features. And although it currently only guesses spoken digits, additional models can be trained to make a more complex system to analyze different kinds of audio data with different applications.

The biggest issue with what I’ve wanted to do in this project has been finding datasets large enough to train a model. I’d love to extend the features of the machine learning aspect of this app, but unfortunately the amount of work required is way out of scope for a single person in a single semester. Although there are many large human speech datasets, training a model in a supervised manner would require hours of manually labeling the data.

Luckily, I’ve learned enough about signal processing to make that a main aspect of the project. And as I said at the beginning of the semester, my main goal was to gain experience in the Android framework and software development in general. Having to overcome unexpected challenges and find creative ways to approach them has probably been the most important learning experience in this project.

I also continue to be reminded of the importance of knowing the shape of your data and what is actually represents before trying to work with it. MFCC features just aren’t displayed in the same way as a spectrogram or a waveplot, so each of these requires special considerations in plotting and, in the future, training machine learning models with them.

And to finish, I’d like to describe my biggest issue of the week. I had to determine how I wanted to get the data to a user after running server-side code. The naive approach would be to send all the data at once as a response, but not only would this take a long time, but the user might not want it. Instead, I send an HTTP request to get a JSON object of metadata for a given audio recording. This contains all the extracted features with a link to them for download, if desired. Then, the app itself can determine if they should be downloaded. In my case, I currently have an interface that handles the API calls, and passes back each file download link individually in a callback method when the HTTP request is successful. The app displays each link as it is received.

This week I also had to refactor an old project for an assignment and chose my first attempt at a Scrabble game in Python. The contrast between that one and this one was a reminder of the tools I’ve picked up over the past 4 years. I never would have been able to juggle this many different technologies and still understand the architecture without the help of many software engineering concepts.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Second Sprint Retrospective

This week concluded the second sprint with my work on the UpdateGuest team developing for LibreFoodPantry. This sprint was exciting as we began creating the implementation of our service.

One of the first issues I helped work on this sprint was coming up with questions for the Thea’s Pantry staff member for when they came to our class.

During this sprint our team also focused on improving working together as a team as were beginning to implement our service.

An issue directly related to this included standardizing our IDEs as we prepared to code together on this project.

Secondly, as part of learning to code as a team I also re-read the first five chapters of Clean Code by Robert C. Martin to review best coding practices.

Additionally during this sprint I helped to implement the web interface for our frontend service where I began to learn how to use Angular again and also learned how to use Angular Material. This issue has two merge requests associated with it, one mainly adding Angular Material to the project, and another adding the implementation of the Web UI.

During this sprint I also reviewed and commented on two different merge requests. The first merge request was for implementing MongoDb for our backend service. The second was for the front end architecture document.

Individually, I think I am getting better at becoming a Scrum Master and learning to listen to other people during our meetings as I help to facilitate them. Although I have found it harder to do this when we switched to online meetings as sometimes it is harder to hear people talk than in-person. During the final sprint I would still like to improve on my ability to listen to other people’s suggestions, both during meetings and on GitLab.

I do think I need to get better at being patient with the rate that changes are made. This issue specifically occurred with a merge request when I directly made changes to a branch without asking first (even though I figured I should) as I thought it would be quicker than submitting another review for it. I do regret doing this as it led to a small conflict. We did resolve this issue and as a team we have made a new working policy that helps address this issue, so each developer only works on their branch individually to help avoid merge conflicts, in addition to helping with this issue.

As a team I think we did good this sprint. We finished several issues early on in the sprint and I am particularly happy with the work that was accomplished for the backend service and the web UI. I think that our team was also better at communicating this sprint and that we have improved our communication on issues and our use of GitLab to coordinate and communicate with each other. I also think we had some great collaboration this sprint with reviewing each other’s work, discussing and implementing suggestions, and even having multiple people working on the same branch.

I also think there is further room for improvement with our communication over GitLab and in meetings. Improving GitLab communication is especially important since we no longer have face-to-face meetings, and GitLab is where most of the remaining time discussing issues and work will be spent in the upcoming final sprint.

I do wish we were able to finish all of the issues we planned on doing for this sprint, but I understand that given the many different events over the past month that other things just got in the way of this. Part of this issue also has to do with the weights issues were assigned during planning. I personally think I need to improve my weighting estimates for issues as this seemed way off for this sprint. I think this was part of the reason we were unable to finish all of our issues as issues became more involved and took longer than was originally anticipated when planning for the sprint. Additionally, I think as a team we need to break issues into both smaller and more defined tasks, that way the work is more defined and the issue weight can be estimated more clearly. These factors are something I have been trying to take into account for while planning for the last sprint.

Overall, I am looking forward to our upcoming final sprint and I am excited to see if we can finish the UpdateGuest service.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.