Category Archives: CS-448

Perpetual Learning: Break Your Toys


   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Perpetual Learning: Break Your Toys


   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Perpetual Learning: Break Your Toys


   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Perpetual Learning: Break Your Toys


   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

The Power (and Curse) of Retreating into Competence

This week, I chose to read the “Retreat into Competence” pattern and found its overall message quite interesting since I see it as a helpful but potentially harmful one. It suggests that when faced with challenges that can leave me feeling overwhelmed or upon realization of my limitations, I should temporarily retreat into known territory to prepare myself to confront the unknown. Doing so will enable me to rebuild my confidence and be able to prepare myself to tackle any challenges that may lie waiting in my future career. While retreating can be helpful, it may end up being harmful and the pattern also highlights the importance of setting time limits for retreat to avoid it from becoming an issue. Setting time limits and asking for help from mentors will ensure if I feel that I must retreat into competence in the short term, it won’t lead to the stagnation of my development in the long term.

I believe that setting time limits for a retreat into competence is vastly important in keeping one’s journey into evolving from an apprentice on the proper path. It works toward preventing people from becoming complacent or stagnant when returning to their competencies. Placing limits encourages an environment where one can gather thoughts and pool together any necessary resources before returning to the thick of it promptly. Asking for help from mentors is also important in aiding to overcome obstacles. Even if something may seem overwhelming at first approach, with the guidance of others, such may appear a lot more manageable than it had before.

I think the pattern provides a good framework on how to deal with my limited knowledge due to my lack of practical experience. It’s common for anyone to feel overwhelmed by new things, especially in the early stages of learning or taking on new challenges upon transitioning from a learning environment into a professional environment.

I have to also mention that the notion of retreating into competence can be helpful but it also may be harmful if not done correctly. It may be helpful, but making a habit out of retreating may result in taking fewer risks even when establishing time limits. I feel as time goes on, the necessity of retreating may fade away, but if a habit of retreat is developed and relied upon too much, it may do more harm than good in the long run.

Overall, I think the “Retreat into Competence” pattern sets a solid framework for new apprentices to follow by destigmatizing the fear of the unknown. It shows retreating when faced with a challenge can be beneficial if used correctly.

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

sprint 3 retrospective

This sprint, the bulk of my time was spent looking into ESLint and keeping up with the team to ensure that we are meeting our goals. I also made a tentative branch for how the pipeline should look like after the linters are added, as these changes were never pushed by the team that was in charge of actually putting the linters in the ReportingAPI repository. I also participated in a clean-up of previous issues that were completed, and reviewed some merge requests from team members.

ESLint Research and Configuration: I checked to see if ESLint could theoretically fulfill the needs for an active linter that shows JavaScript syntax errors in the editor, and it seems like with proper configuration it does fit that role. I found that the ESLint version we currently use is out of date, and the old style of configuration file (.eslintrc) was hard to get working properly. With the new format for ESLint configuration, I found that ESLint needs to probably be installed locally in order to have this take effect properly, and that we should update the ESLint version we use in LibreFoodPantry to adopt the new configuration standard.

Pipeline Configuration: I configured the pipeline based on the GuestInfoBackend repository, and it currently fails because there are no linters actually installed in the repository. The idea is that when the linters are merged into the main branch, this pipeline branch should fetch those changes, push them to the branch on GitLab, then check to see if the pipeline does work correctly with that. Theoretically it should.

Cleanup ReportingIntegration: I checked over the work I did in this repository and it looked fine. I also adjusted Hieu’s branch where he cleaned up some of the documentation.

Cleanup ReportingBackend: I checked over the work I did in this repository and it looked fine.

We had some logistical issues again this sprint, but ended up completing nearly all of the work that we set out to do, thankfully. The problem was that there was a kind of rush during the last few days leading up to the sprint review, which led to me having to take charge as scrum master and keep up with each group member actively in the days leading up to the review to make sure everything was completed. That being said, our communication was the best that it has been this semester during this sprint, the one issue I was consistently having is that we should be sharing communication with each other, but team members were direct messaging me personally for issues they were having.

On my part, I do think I could’ve spent more time with the ESLint issue and also looked into other solutions, but I definitely was feeling crunch from other courses and ended up putting the work for this course on the backlog while other courses were piling work on me. I’m happy I got to a relatively satisfying conclusion with the issue, but I feel like I could’ve done more. On the part of being scrum master, I performed much better at keeping everyone on task by checking in every week, though I could’ve been a little more strict so there was less crunch at the end of the sprint.

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

Sprint-3 Retrospective Blog Post

Tasks/Issues that I worked on in Sprint-3:

1. Cleanup and Enhancement (Reporting Backend) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/79):

Assigned alongside Isaac, Victor, and Andi, I undertook the task of consolidating enhancements made to the reporting backend during earlier sprints. My role involved conducting a thorough review to ensure clarity and accessibility for future developers. While I completed the task successfully, I acknowledged the need for additional time to refine code cleanliness further.

2. Documentation Review (Documentation Repository under Reporting System) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/documentation/-/issues/11):

Independently assigned, I reviewed the reportingsystem documentation repository to identify any inaccuracies. After a comprehensive review, I found the repository to be accurate and well-structured, requiring no immediate changes. However, I recognized the importance of ongoing documentation maintenance to keep information up-to-date.

3. ReportingIntegration Documentation Update (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/merge_requests/10/diffs?commit_id=c972ae9723af3eefcf3d2f09b4827c9c942b368c):

In another individual task, I updated the reportingintegration documentation to reflect recent changes. This included updating the lint.sh file to ensure proper linting functionality and modifying file paths for improved readability. Despite encountering an issue with dead links, which I consulted with our professor about, the documentation updates were otherwise successful.

4. Code Cleanup and Refactoring (Reporting Integration) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/commit/ece7535bbd6e9c5901083e541fb450dcbb9466b8):

Collaborating with Victor, I worked on cleaning up and refactoring code within the Reporting Integration module. This involved rewording, rephrasing, and highlighting phrases in documentation files to enhance readability. While completing this task without issues, I acknowledged the need to dedicate more time to code cleanliness for improved team collaboration and understanding.

Reflection on what worked well:

Improved Docker Pipeline Configuration: We successfully configured Docker pipelines, addressing path issues and ensuring smooth file copying into containers, enhancing our development workflow.
Effective Scripting: Our development efforts were streamlined with the implementation of scripts like bin build and push.sh, contributing to efficient Docker operations and backend development processes.
Communication and Task Management: Clear communication through GitLab issues and effective task management ensured that team members were aligned, contributing to productivity and progress tracking.

Reflection on what didn’t work well:

Linter Configuration Challenges: We faced difficulties in setting up linters, particularly with es.lint configuration files and syntax checking, impacting code quality validation.
Docker-compose Issues: Challenges arose in creating Docker Compose files that adequately handled starting MongoDB, RabbitMQ, and backend services, causing complexities in deployment.
Dependency Management: Struggles with dependency management led to inconsistencies in development environments across team members, hindering collaboration and code compatibility.

Reflection on changes to improve as a team:

Enhanced Teamwork and Collaboration: We aim to foster a stronger collaborative environment where team members assist each other with tasks and share knowledge effectively, improving productivity and problem-solving capabilities.
Improved Documentation and Knowledge Sharing: Documenting processes, configurations, and troubleshooting steps will facilitate smoother workflows, onboarding for new team members, and better understanding of project intricacies.
Streamlined Development Processes: Automating repetitive tasks like linting and formatting will reduce manual effort, enhance code quality, and ensure consistent development standards across the team.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

448 Last Sprint

Last Sprint Retrospect.

This sprint introduced something different then out  usual approach, as we embraced a more flexible and independent way of working but still in a team setting. Allowed to choose our own tasks, each team member assumed ownership of their respective assignments, encouraging a sense of accountability and purpose within the team. This new self-sufficiency was complemented by a sense of collaboration, where team members voluntarily offered assistance and support whenever needed, ensuring that our group efforts flowed seamlessly towards our common goals.

Throughout this sprint, my role primarily centered around the essential task of tidying up loose ends from previous iterations. From closing redundant branches to resolving trial-and-error issues, I found myself assuming the role of the team’s cleanup crew, diligently organizing and optimizing our GitLab repository. While the task was undeniably lengthy, the satisfaction of viewing our codebase evolve into a leaner and more simplified object made the effort worthwhile.

However, amidst our collective productivity, a significant challenge surfaced: the shortage of possible epics to reach our sprint points . For several weeks, we faced with the search of new task of identifying new projects and enhancements to strengthen our workload. We look high and low, in other groups past epics to search for anything tat we thought could make this project ran more efficient. It took a couple of days until we finally had enough points to reach our goal. Despite the challenges we encountered, the sprint unfolded with remarkable smoothness. The organized cooperation within our team, coupled with our solid dedication to excellence, pushed us forward.  While the cleanup work demanded meticulous attention to detail and patience, it served as a evidence to our team’s commitment to maintaining high requirements.

Reflecting on the semester as a whole, I am struck by the profound educational value of our experiences. Beyond the mere acquisition of knowledge, this class has equipped me with valuable skills and insights that go beyond the limits of academic world. From mastering the art of collaboration, every aspect of our semester has left an indelible mark on my professional development.

As I board on my future career, I am grateful for the transformative impact of this class, which has not only enriched my skill set but also shaped my outlook and approach towards work and collaboration. The lessons learned and experiences gained during this sprint, in particular, have reinforced the importance of adaptability, resilience, and the pursuit of excellence in the face of challenges. Prepared with these invaluable lessons, I am confident in my ability to navigate the complexities of the professional world with confidence and competence.

Evaluate current state of CheckInventoryFrontend (#41) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

Clean up GuestInfoFrontend (#100) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoFrontend · GitLab

Check documentation for GuestInfoFrontEnd (#99) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoFrontend · GitLab

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

CS-448 Week 13 Nurture Your Passion

The pattern “Nurture Your Passion” is compelling to me as a software developer who is learning the importance of maintaining enthusiasm and dedication in a challenging work environment. It acknowledges the common struggle many developers face when their passion for the craft is interrupted by factors such as corporate hierarchies, project pressures, or negative workplace dynamics.

What I find compelling about this pattern is its emphasis on taking the right steps to protect and grow one’s passion for software craftsmanship despite adversity getting in the way. It also addresses that while external factors may be discouraging, there are still actions individuals can take to sustain their enthusiasm and commitment to their craft.

I have personally experienced times when my passion for software development wavered due to demanding project deadlines, different obstacles, and lack of recognition. However, this pattern reminds me that while it may seem tough at times, my passion is worth preserving and that I have the tools to nurture it.

One of the aspects this pattern provides that resonates with me is the importance of setting boundaries between work and personal life. Prioritizing self-care and making time for out-of-work activities that help rejuvenate my passion allows me to maintain a healthy balance and prevent burnout.

The pattern also underscores the significance of continuous learning and seeking out like-minded peers for support. Professional development opportunities as well as connecting with colleagues who share my enthusiasm for software development can provide me with valuable inspiration and encouragement.

Reflecting on this pattern has reinforced my belief in the adaptability and resilience of software developers. It has reminded me that while external factors can influence the work environment, I have the power to carve my own experience and continue my passion for the craft.

If anything, this pattern has confirmed my intended profession and pursuing a career in software development. There have been times that I considered trying a different career path, but reflecting on this pattern has showed me that my belief and dedication are essential qualities for success in this field, and that overcoming challenges can lead to personal growth and fulfillment.

Overall, I agree with the principles outlined in this pattern. It serves as a reminder that passion is not something that is given, but rather it is something that should be nurtured and protected, especially when facing adversity. By embracing this mindset and taking the right steps to maintain my passion, I am confident that I can thrive as a software developer despite any obstacles I may encounter.

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows: Shortcutting the Path to Software Mastery

The “Rubbing Elbows” pattern advocates for software developers to actively seek out opportunities to work hands-on, side-by-side with other skilled programmers. The core premise is that certain techniques and micro-habits can only be absorbed through close collaboration on shared coding tasks. Practices like pair programming try this kind of knowledge transfer, but the pattern applies to any endeavor that allows you to observe the workflow and decision-making of an experienced developer.
I found this pattern incredibly insightful and motivating. As a software engineering student, I’ve already experienced how much more I can learn by watching lecturers code and explain their thought process in real-time, versus just reading examples. The “Rubbing Elbows” pattern highlights how that same example of accelerated learning through consistency well beyond the classroom.
The authors make an good point that there are “thousand little everyday moves” that skilled developers have pressed through years of experience. These small refinements may seem minor on their own, but include into real improvements in productivity, code quality, and problem-solving prowess. However, these micro-habits are nearly impossible to fully carry through written documentation or formal teaching. Rubbing elbows allows an apprentice to organically absorb them through repeated, intimate observation.
I’m reminded of when I pair-programmed on a school project with a talented classmate. While daunting at first to have my code exposed, I soon realized I was gaining insight into his mental models, techniques for juggling complexity, and little shortcuts that markedly lifted his coding flow. Rubbing physical and mental elbows enabled knowledge transfer that couldn’t have occurred through solo learning.
This pattern has inspired me to be a go getter about joining open source projects, participating in local meetups, and seeking out internships that enable close collaboration with experienced mentors. Identifying and creating these “rubbing elbows” opportunities will be important for go beyond my current peak and speeding my progression as a capable, well-rounded software crafter.
While the unusual feeling of being the “newbie” amongst experts is unavoidable, I’m excited by the authors’ advice: embrace feeling lost at times, ask questions, rotate pair partners if stuck, and record learnings to cement them. Absorbing the tacit knowledge of those further along the path is key to rapidly elevating my own skills.

andicuni
April 28, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.