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.

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.