Category Archives: CS-448

A Different Road

This Apprenticeship pattern, “A Different Road” is about admitting to yourself if software craftmanship isn’t the career path you want anymore. I think that this is a very important lesson to be learned, because it is much more harmful to yourself, and others that you work with in your field if you stick through doing something you don’t like than if you either take some time away or change career paths entirely. By doing something you don’t like as a career, you are doing a disservice to yourself and others, because you most likely aren’t doing the best as a software developer as you could if you don’t like it, and others may notice that you don’t like it and that you aren’t doing the quality of work that you used to, or that it is less than acceptable.

I think that instead of changing career paths immediately if you aren’t enjoying it anymore, maybe a good idea would be to take some time away, and then return to it later and assess whether you still aren’t enjoying it or not. The reason for this would be to see if you just have burnout from doing it for a while, and then maybe the time away would fix that burnout. You could have burnout for a number of reasons, but maybe taking some time away would fix it by helping you clear your head, and then if you’re still having burnout then it might be time to seriously consider changing careers.

Ultimately, I think it’s best to not force yourself into a career you don’t enjoy doing, and that goes for any career path, not just software development. Not enjoying what you’re doing everyday means that you’re likely doing it worse than you would if you were enjoying it and will inevitably lead to unhappiness. In my opinion, it is much better to do something that you enjoy doing and something you’re passionate about than something that has better pay. Additionally, there will always be other opportunities down the line, meaning a temporary career shift doesn’t have to be permanent, and you can either continue doing what you are, or return to the old job if you’ve discovered that’s what you like best.

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

Sprint 3 Retrospective:

This sprint went particularly well. Cooperation between the team members improved, and the general effort and quality of the work effort exceeded my expectations.

With the rest of the team concentrating their efforts on the API and Backend projects, I spent most of my time writing and testing the remainder of the work in the Android testbed app.

This work involved finishing the coding and testing of the 8 main endpoints and adding code for the final endpoint, getRange.

The getRange method required addition of code to the NestTester, API, and Backend projects.

I also worked with the team on helping to get the backend to work for the getRange API call. We coordinated this with local unit testing from within the backend container using getRange.http calls, as well as remote integration testing from the Android Studio emulator.

This sprint included the time required for the 5 of us to prepare a video presentation. We are producing multiple mp4 files and will consolidate the individual pieces within the week.

Our usage of the GitLab Epics and Issues boards improved. This resulted in a better workflow, giving each team member a more balanced share of the task load.

Part of the sprint was used communicating with the IAM team to get a sense of the timeframe required to integrate security mechanism into our remote function calls. A plan is in the works for this integration to be implemented in next year’s Capstone.

I wrote about half of a document describing the steps that a future Android team can use to integrate my testbed infrastructure into the actual NEST app. I will finish this document in August when I have more time. I would have completed it this sprint, but the getRange development and testing was more complicated than we had thought, so had taken up more time.

Dr. Wurst had suggested that we can continue working on this project if we choose. Since this is an open-source project, anyone willing to contribute to it is welcome. I have time in August to continue working on this and will volunteer some time evaluating what needs to be done to migrate the testbed code to the proper locations in the “Live” NEST app, calling the mongodb backend from the proper places. I am not familiar with most of the NEST app code, so I would need to communicate with a contact from the team. Should I contact Dr. Burge from NCC for this?  This is all contingent on whether or not this is needed.

The capstone was a great experience for me. The 3 sprints showed how team members went from being apprehensive and overwhelmed by the process, to being excited and proud of their achievements. There are definitely “bumps and bruises” involved in this transition, but also a sense of pride in having succeeded. For our team, this seems like a journey showing them more about how the “real world” will work for them, compared with some of the more academic foundational classes they have taken.  

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

This Apprenticeship pattern, “Expose Your Ignorance,” is about admitting to others as well as to yourself the gaps in your knowledge. You must admit to yourself the gaps in your knowledge before you can admit it to others and begin to ask meaningful questions to expand your knowledge. I think this is really important to know because if you are unwilling to admit that you don’t know some stuff, then you will be unable to learn it, and furthermore unable to get help from others who possibly know more about the topic. Only by admitting that you have more to learn can you open yourself up to attaining more information, which will help you in the long run.

I think that this is especially important in the software development field, where there are constantly new technologies and tools to learn, and new information about emerging systems that you must learn to keep up with the ever expanding field on software development. If you don’t keep up by learning new things, and thereby exposing your ignorance, then you will quickly fall behind, and may be susceptible to being replaced at your job, or incapable of performing the tasks necessary to fulfill your goals.

I also think that this is applicable to many different fields, not just software craftmanship, where there are always new things to learn, and you must keep up to date with the latest information in order to do your job. One such example would be a doctor, where there is always new medical information coming out, and not knowing about it could be potentially harmful. Any person in a field such as this must be okay with admitting that they don’t know something, instead of pretending like they do and not learning new, important information. Admitting that you don’t know something, and exposing your ignorance, not only makes you seem humble to yourself as well as others, but it also helps others to assess what you do or don’t know so that they are able to help you in areas where you may need it, and you are able to help yourself in this way and by learning it on your own.

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

“NICE” Sprint 3 Retrospective

During our third and final sprint, we had a clear idea about what we wanted to achieve with our application. The first two splits helped create a foundation that allowed for us to propel much faster and efficiently compared to before. After spending the last sprint working on the docker container for our group, I wanted to contribute in a way that would be helpful to the react team. I ended up creating issues for myself that were more in line with the front end side of things that the react team had not really touched upon. I first decided to clean up a lot of the code from the react team, there were a lot of styles that were repetitively used by the team so I managed to implement a style page where certain style could be called upon instead of written out when being applied to something. The next thing I tried to tackle was an interactive page for users to select which kind of test they wanted to practice. This was implemented with a side scroll feature that was imported from the react-native-gesture-handler where I was learning the design parts of how things would look based on the style I would give it. I was also able to take images and icons as well to apply to the home page and menu screen which gave it a much better appearance to the eyes of the user.

As a team I felt as if this sprint all of the puzzle pieces finally came together. The react team was working cohesively together where as the others who did not work with them originally were able to go back and forth with them to push an pull code without being out of sync. The team cohesiveness really brought out the best in one another as were we able to divide issues into more manageable ones and we could really see the final product coming together.

With the docker team finally being able to assist the react team with the application as a whole, we were constantly running the application and testing it, and that led to a lot of discussion of things that needed to be fixed or added to the app. This would lead to us effectively being able to help one another spot mishaps and expedite the results we so eagerly wanted. Although we were not able to produce a functioning writing portion, we were able to create a placeholder for it that was substituted with a input on the they keyboard from the user.

Individually, I felt as though this sprint was one were I pushed myself the most. Maybe it was because the semester was coming to the end or that the application was seeing growth, but although I was lacking in basic knowledge of react native, I wanted to be sure I contributed more to the application and pushed myself to learn more. The only issue that I had with the sprint was that I wish I was able to be part of the react native team prior to this because I know I could have contributed more than what I already have. Seeing how fast I was able to grasp things, maybe I should have stepped up before and take on that challenge because I had a lot of fun during this sprint.

Links: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/57

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/66\

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/58

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/49

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/23

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/52

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/25

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.

Record What You Learn

Summary:

‘Record what you learn’ pattern comes from the chapter ‘Perpetual learning’ and Perpetual meaning ‘occurring repeatedly’ the pattern sits well. ‘Record What you learn’ Pattern is a perfect read after ‘Breakable Toys’ and ‘Practice, Practice, Practice…’ because the pattern exposes one the biggest flaw in our learning which is that sometimes even after learning the same lesson repeatedly “They never seem to stick.” The solution pattern provides is for us to record what we learn. Make timely organized notes in form of journals and wikis. Moreover, the notes could be public or private; public for the purposes to share your knowledge and discoveries and private where you can act as your own oversight and pinpoint all your faults with brutal honesty.

Why this pattern?

For me, ‘Record What You Learn’ is a perfect sequel to ‘Practice, Practice, Practice…’. I have written many programs in Java, but from time to time I’ll forget something specific like casting the input variables, using extends or implements in OOP. The point is this has happened to me various times until I started making personalized notes for myself instead of depending on textbooks and class notes. I started writing things down the way I understood them; using the color-coding system to my advantage, I highlighted parts that were important to remember, parts with specific steps and parts where I needed help. Classification of information not only proved to be effective for quick reviews and revise but also helped in conveying myself to people who can help me in precisely where I needed help.

Where is disagree:

Most of the time while building my personalized notes there was a lot of overlap. Classification of information was effective but the process of classifying the information itself was tedious and chaotic. As I kept learning new things, adding notes, and modifying notes became a very complicated process. Absence of space led to arrows being from the top of the page to the bottom. References were made from page 31 to page 45 which led to a whole new level of mess. Switching to taking notes on the PC solved a lot of issues from being on paper but created a lot of new ones. One issue was the mechanics of completing a task. It is much easier switching between a pen to a highlighter than a keyboard to mouse, and further selecting area to highlight.

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

Sprint 3- Retrospective

This last sprint did not go as smooth as the previous, we encountered a bunch of roadblocks with the backend that sort of disturbed the plans and dynamic established previously. We were able to get to a decent and somewhat better end product then what we started off with but we didn’t quite reach some of our main goals.

What didn’t work well

As a team:

The biggest issue was the backend not running. We started the spring with all the endpoints written down but we had an issue with connecting it to the database and getting it to work. About half the issues of the sprint were solely related to the backend and now that we could run or test anything, a lot of us were left with not much to do, or not knowing what to do. Consequently it led to a lot of not really productive time.

Individually:

Going into the sprint, my task was supposed to be testing and fixing the two endpoints that I wrote and that didn’t end up happening because of the backend not running. Since there was already two other members actively working on the backend, I found myself not working on anything for like half the sprint. At point, I would join in with the backend work but it turned out to be us three doing the same test so I decided to look inside the folder to see if there was something else I could do.

I also think that this sprint being toward the end of the semester, I ended up focusing my energy on another project since I couldn’t find anything to do.

What worked well

As a team:

We were able to fully refactor the front-ends for the most part, we updated all repositories with all the necessary add-ons (commitlint, RabbitMQ tutorials,…). The backend was created and is running. It’s not working yet and consequently the endpoints are not tested yet. In general, we accomplished over 80% of what the goal was for the semester so it was indeed a success.

Individually:

The one good outcome was that I learned a little bit about automation testing. There was a Testing folder inside the microservices example with classes like axios.js, chai.js api.js and so on. It was a bit confusing but I discovered a bunch of links (blogs and videos) that helped a bit. I pushed a document with all the links in the documentation folder for the other teams to refer to it.

Changes to be Made

Most changes that need to be made are for the next team. They can work on the following:

  • get the backend to run, it is very close to being ready as it is working already;
  • Take a brief moment to modify the user interfaces for check inventory and add inventory to prevent user error;
  • Test and fix all endpoints;
  • Develop the front-end calls based off what was set up in the backend and connect it to the web pages for testing the frontend containers with the backend

Links:

Add document with Information on testing folder(backend) (#39) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryBackend · GitLab

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

Blog 8: Practice, Practice, Practice

The context given here is that You want to get better at the things you do and you want to develop concrete skills in new areas. The problem is now that the performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage. The solution offered is to take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes.

Practice is important because it will get you to where you need to be. We talked about reading and going back to the classics as a way of getting you to master your craft but reading without practicing the acquired knowledge won’t really help. That’s why we believe efficient and deliberate practice methods not only help you learn faster but also help keep you motivated. Over time, this chain of exercises would hone your strengths and correct your weaknesses.

The book emphasizes that short feedback loops need to be incorporated into your practice sessions. While practice is good in theory, if you’re not getting periodic feedback, you’re probably developing bad habits. Over time, the need for constant feedback lessens as you grow as a craftsman, and is gradually replaced by your duty to take on the role of a senior apprentice, modeling good habits by practicing with less experienced developers.

I was very surprised by the following sentence: “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. So be careful what you practice, and constantly evaluate it to ensure you haven’t gone stale. Choosing the right thing to practice every day is a skill almost as important as the act of repeated practice.”

The lines above shows that we could easily get comfortable and stop making concrete progress. Practicing is good but it has to be diverse to allow the growth to happen. The point is not to hone your memory, but to discover the nuances in even the simplest skilled activity. An easy to implement it could be as simple as finding an exercise in one of your old books and tweak it a little bit to make sure that it’s just a little harder than one you know you can easily solve.

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

Blog 7: Read Constantly

The context of this pattern is that you are being enthusiastic about your passion to the points where it has open doors for you. The problem is such that there seems to be an endless stream of deeper and more fundamental concepts that are eluding you, despite the proficiency that you already have. The solution offered is to focus the thirst for learning on consuming as much of the written word as possible. Emphasize books over blogs as you construct your reading list.

The book emphasizes that reading the occasional research paper will stretch your mind and keep you in touch with the cutting edge of computer science, and also offers a source of challenging new ideas. Trying to implement these ideas will expand your toolbox with new algorithms, data structures, and design patterns many years before they reach the mainstream. An Important fact to remember is that Successful apprentices tend to focus on “long-lived books” and use the Web or experimentation to learn how the information has evolved and that’s why we should focus on going back to the classics. That being said, one danger of focusing on the classics is taking it too far and abandoning the more pragmatic knowledge and information that enables you to improve your day-to-day craftsmanship. Be sure to intermingle classics with modern, pragmatic books and/or articles in your reading list.

I really resonated with this because reading books hasn’t always been fun for me. Thankfully, the eBook and audio version of things have made it easier. I also like that they ended the pattern by the following: First, the trick is to keep up the momentum. After you’ve finished this book, decide now what your next book will be and make sure to buy or borrow it so that when you finish this book, you can switch immediately to the next one. Second, you should also try to keep a slim book with you at all times. This will let you use the little bits of dead time throughout each day (such as train journeys or waiting in queues) to learn. Third, Find the oldest book in your developer’s book collection and read that one first.

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

Retrospective #2

Coming to the second sprint with a lot of achievement from the first one, I put in an objective of having both the back and front of the project working steadily. To be specific, my goal for the backend was to have the testing and the message broker work with the current code that every time they pull up a test, a data entry will be automatically created if there is no previous stored data, and the message broker to send notification once users modify a data entry. For the frontend, the goal was to make the returning form for returning users and integrate with the backend under container technology.

What have we achieved?

Repeat from last retrospective, my team has good developers who are able to complete all the issues listed in a short period of time, so we almost have every issue in review state after a week and a half. I created the testing directory to test each endpoint with the default case and it will create a temporary student data whose id is 1234567 if there was no data initially. The message broker was implemented properly to send a message into the queue every time the update endpoint is called. Our frontend has its application run on the nginx server by binding from docker-compose and partially integrate with the backend application also thanks to Docker.

Things to improve

The major problem with the backend application currently is its execution since it requires two terminals to execute asynchronously, the first one is to pull up the MongoDB database and the RabbitMQ server, then the second command will be used to run the node application, without Docker. However, the testing was created specifically for Docker to execute because the Mocha Chai framework requires all of its functions to be programmed inside the `test` directory and this directory is actually “invisible” in the terminal environment, so its .json and docker files have to be written in another directory when I wanted to put it on Docker (node execution does not require this step). Therefore, executing the backend container with nodes prevented the application from having testing features.

Besides, the registered image that the frontend has been using also needs to change to an older branch because the current pipeline builds an incomplete image due to the new code from RabbitMQ. Fixing this problem will be an epic coming to the next sprint, the point is to have Docker to bring up the application as a whole where the cycle of execution will be MongoDB and RabbitMQ -> Backend Server -> Testing in one docker execution which will make it easier to manage and to build the pipeline.

Conclusion

As a Scrum Master, I did not fully complete my responsibility this sprint since I could not make the team communication to be better, I was too concentrating on the backend repository that I just only had some brief conversation with the frontend team, which is not enough to keep me update to support what they need. In the next sprint, my goal is not clear yet but I would want to try to have more talking with the frontend guys.

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 3 Retrospective

During Sprint three we ran into issues that bottle necked our project. But in the end we were able to overcome these obstacles and make some good progress.

What did not go as well was the planning of our issues, and not knowing how long each issue would take. One of our issues was connecting our API to our backend, and building our server. This issue ended up taking three people from our group more than two weeks. And we were unable to meanigfully test any HTTP calls until our backend was running properly. Looking back, we should have starting working on this during sprint 2.

What did go really well this sprint was working together to get the app running. We spent one class, all working together. Working through docker errors and making progresss that way. Chirstian made progress on his own as well. He made a docker file and reused the shell scripts from last semester to get the server running. The issue we ran into was that even with the server running, we could not execute any http call, without getting a connection error. This was the status of the issue for about two weeks.

I tried to work through the connections errors using stack overflow and other online resources, but to no avail. I then asked Jared, and sent him a screen shot and he said they ran into a similar issue in his group. Then, Duwal, Jared, and I jumped on a discord call and together we got the server running, so that we could call our http methods wihout connection errors. This was a huge break through for the team.

Another issue we ran into as a team was meeting to make our video presentation. We had a hard time picking a time in which everyone was free. Because classes had ended, and group members had finals and other engagements. The solution we came to was that everyone filmed their part and sent the video to Christian, who is going to edit it together and submit.

One thing I can do to improve as an individual is learning to ask for help, outside of the normal avenues. Once I asked Jared for help, he knew where to get started on our problem. So I learned that sometimes I need to ask an outside opinion for help. There is a limit to how much I can figure out by debugging and googling on my own. And sometimes an outside perspective, or somebody that has encountered this problem before can make all of the difference.

Below are the issues I worked on this sprint:

I added access token capability to the API repo. I added a schema for a 403 response. And I added that response to every path in the API repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/12

I researched endpoint testing standards and created a template js file in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/29

I debgugged tbe connection / server problems in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40

I helped Duwal with the test file for returning the API version. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/25

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