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.

   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.

   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.

   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.

   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.

   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.

   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.

Link to blog: https://www.computer.org/publications/tech-news/trends/application-security-testing

The whole semester we have been exploring various ways of testing code, namely styles that ensure the code works as it should. However, there is another aspect of testing we have not discussed yet; security testing. 

It is of the utmost importance to ensure that your software, database, website, etc. is safe from hackers and leaks. Security testing would help just that: making sure your system is unbreakable, or at the very least mostly protected from vulnerabilities and flaws. I think it is important to learn about this aspect of testing, which is how I came across Adam Stead’s article What is Security Testing? How to Check The Security Strength of Your Application.

Stead stresses the importance of security in software and also lists some important security testing techniques, such as vulnerability testing, black box testing, penetration testing, and more. There are many benefits of security testing besides identifying vulnerabilities. Some examples listed by Stead include protecting sensitive data, enhancing customer trust, and cost-effectiveness. Data leaks have been pretty common as of the past several years and it is a huge deal for those companies to lose their customers’ trust and their own reputation. With increased security comes increased trust, which is beneficial to both the business and the customer. 

Stead mentions some security testing best practices, and reinforces the idea of starting early and prioritizing risks. Security testing early on in development can help prevent flaws in your code, and you should continue to test throughout production. Prioritizing risks ensures that your important flaws don’t go unnoticed, and you fix your biggest holes before fixing the smaller ones.

Stead ends the article by discussing some attributes of effective security testing (thoroughness, continuity, scalability, etc.) and stresses the importance of checking the security strength of your software regularly.

I selected this article because this is a topic we have not discussed much in class even though it is still a very important part of software testing. This article emphasizes the key elements of security testing and how important it is to include it as a part of your testing regime.

The content of the resource was very informative and understandable for someone who already has a bit of understanding of software testing. An interesting thing I learned was about fax online, which is a method that businesses use to securely send documents. I did somewhat enjoy the article, it was informative, however I wish it included some examples of certain testing types. I expect to apply my newfound security knowledge to future jobs and software practices.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Our class discussed many code-driven testing methods, including Test Driven Development and Unit Testing. I thought it would be interesting to research what goes into performance testing, which doesn’t need coding to test but is still important to determine if there are any bottlenecks in your code. Many errors in our code go beyond whether it provides the correct output. If our software cannot function quickly and with many users, it doesn’t matter if our code functions if it doesn’t work in practice. The article “Performance testing, best practices, metrics & more” by Tricentis is a comprehensive look into how performance testing works and its role in software development. 

This article mainly provides the fundamentals of performance testing. It discusses why it’s important, the tests involved, what is measured, and a step-by-step process for ensuring your code functions correctly. It also discusses whether coding is necessary, when to conduct performance testing, and clears up performance and load-testing misconceptions. 

Reading the section on why performance testing is important had me finding a parallel to behavior-driven development because both focus on the user’s experience. If BDD provides an understanding of how the user is supposed to interact with the software during development, then performance testing is how users will interact with it when completed. If the users are stuck waiting for their application to load, find that it crashes often, or are unable to access it, then user experience will fall. That negative experience could lower revenue or reputation for the application’s company.

The section describing the testing methods highlighted how many ways you could poke and prod a system until it breaks. When I think of performance testing, I usually think of testing speed and user capacity, so seeing the other methods was enlightening. As I have not dabbled in performance testing, seeing the sequential steps to ensure speed and stability in our code was informative. It is vague enough for those new to performance testing to use it as a guideline. It was also interesting to learn that with agile methodologies at the forefront of software development, companies are looking for automation when doing performance tests to keep up with faster software development.

Overall, this article covered many aspects of performance testing, and those interested in learning would find it helpful. I plan to use performance testing to ensure users have a better experience, expose bottlenecks, and find where my code’s stability is weakest. 

The Article: https://www.tricentis.com/learn/performance-testing

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

Test-driven development (TDD) seemed odd to me when I was first introduced to it, much like the majority of others. The idea of writing tests before code felt weird in a way, as you write tests for nothing. However, the more I read about the benefits and how to properly apply TDD, the more obvious it was how useful TTD really is. Jacob Schmitt does a great job explaining TDD along with its benefits and best practices in his blog “Test-driven development (TDD) explained” (https://circleci.com/blog/test-driven-development-tdd/).

What is Test Driven Development?

Test-driven development is a software development approach where tests are written before code. It follows an iterative cycle: write a test, ensure it fails, write code to pass the test, and refactor. This means that a large amount of planning needs to go into the start of a project. Designing tests requires an understanding of what the feature you are adding should accomplish. This includes testing that things should pass when expected and fail when expected.

What Does Writing Tests First Accomplish?

As I mentioned before, it feels counterintuitive to write a test for code that does not exist. That is, until you understand the benefits of having tests. Tests are going to be required for any serious project. Having the tests written first will greatly increase your chances of finding bugs as early as possible. This also ensures that any refactoring does not break any existing functionality. This is great when working with a team, ensuring that everyone is on the same page and that changes made by anyone will be tested. TDD also ensures that all code that is written is tested. This greatly increases the code reliability and ensures functionality aligns with the user expectations.

Benefits of TDD

One of the most impactful benefits of TDD as a developer is the increased confidence that any changes you make in the code will have immediate feedback on if it passed the tests or not. This confidence extends to every developer on the team, as these tests ensure everyone’s code works as intended.

Catching bugs early can save a huge amount of time and money. It makes sense that testing code incrementally as it’s added is better than waiting until it is all developed to test. This also makes sure no code is ever added that isn’t tested. Meaning tests are being rushed near the end of deadlines, and potentially missing some.

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