Author Archives: dcastillo360

Week 11

Deciding on a topic this week I decided to delve into Test Driven Development (TDD). I found an article with an engaging title “Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software” by Ferdinando Santacroce. This would be very useful for me and the whole class because it’s fresh in our minds and we will continue to work with this concept. Getting a firmer grasp on this topic will help me with future assignments and homework. It’s always great to get an insider view with experience inside the field connecting it to what we learn in class.

This article begins with the history of TDD giving credit to Kent Beck one of the first “extreme programmers”. At the time nobody had ever reversed the idea of testing starting with a test instead of the actual code. The purpose of writing a test before the code would help programmers put them in the perspective of the maker making it easier to create the software. This would make more tunnel-focused code with much more simplicity because of just focusing on the test. Plus the codes get rapid feedback because all the tests have been made. TDD has the fastest feedback loop only surpassed by pair programing. Currently, TDD is widespread inside the field and several teams utilize it day to day. It’s hard to adapt to this type of coding scheme but with time it is proven to be a key to success. Minor grievances may also come up because this type of process can be too rigid or the lack of tools.  

After reading this article getting a glimpse into the history of how this came to be. It didn’t specifically specify when it started but I assume it was around the 90s because it mentions how common it is now. Understanding the benefits of doing this test answers my question why would you decide to do your coding process in reverse? What we have been learning is that it will be conventional to have code and then write the test connected to the already processed code. The benefits of cutting down time because of the faster feedback times and leading to less complicated code, I now understand its purpose. That is a recurring theme with code the simpler the better because you are never working alone. Maybe it is a self-contained project but your future self may not understand your complex code and updates to the code should be easy to do not a headache. 

https://semaphoreci.com/blog/test-driven-development

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.   

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking. 

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

View at Medium.com
https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

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

Week 9 Blog Post

Choosing a topic for this week I tried to find something we had recently touched upon. Last week we went over mocking and expanding my knowledge of this topic can benefit me and the class. Searching for articles about mocking I stumbled upon one that shares the negatives of using mocking data. To counter-attack the ideas we learned in class it is always great to know both sides to using a concept. 

This article doesn’t fully dispose of mocking but gives ideas when it’s good to use. It gives a variety of examples including “Isolating the unit under test from other components or dependencies that are not relevant to the test, Speeding up the test execution by avoiding network calls or database queries that can be slow or unreliable, and Controlling the test input and output by creating predictable and consistent data that can be easily verified”. These ideas are then counterposed to the negatives such as “Introducing errors or inconsistencies between the mock data and the real data, which can lead to false positives or false negatives in the test results, Reducing the coverage and confidence of the test, by not testing the actual behavior and logic of the external source or the interaction with it, and Increasing the maintenance and complexity of the test, by requiring extra code and logic to create and manage the mock data”. The flaws of mocking data are mainly it does not use real data making it much more different from the real data creating disparities between the two. These tests ignore scenarios with much more complexity and these error and bugs can go unseen. The author assures the reader to use a data source to improve the tests.

After reading this article it gave me insight into the negatives of using mocking. The week prior activities made the use of mocking reduce time in creating classes but it’s good to know when it should be used and when it shouldn’t. I wish there was a perfect solution for every test but to find bugs in your code you must expand your horizon. Reading this article made me see that a variety of tests testing different things can overall benefit you. You never have to completely ignore a type of test but being able to see the positives and negatives can save you in the long run. Plus it will allow you to have a broader knowledge knowing that this may have flaws but there are things I can add to have a satisfactory end product.       

View at Medium.com
https://medium.com/@queenskisivuli/why-mocking-data-is-a-bad-practice-for-testing-a20d2d7104aa
View at Medium.com
View at Medium.com

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

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.  

https://hinchman-amanda.mehttps://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

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

Week 13 Clean Code

In my search for a topic this week, I searched for an article closely related to our homework and our last five Pogil activities. I kept it simple and looked for an article about clean code. I understand we have been loaded with tons of information about clean code but when was having more of something bad. I wanted to see different perspectives of clean code outside of class and what people inside the field or with experience opinions on. Allowing me to get insight from outside of class will be very helpful. Also, being able to have an open mind with coding can go a long way plus being able to see similarities with what I have learned and my own opinions. 

This article starts by describing the term “Spaghetti code” which refers to complex tangled code that is hard to decipher and causes frustration for everyone involved. This ties into clean code by emphasizing how is an integral component of software development and can only be maintained with practice. This comes with less team frustration and allows for any teammate to manage the code. Clean code is just not a statement of keeping the code tidy tightly but more of a form of communication that can be understood by everyone thoroughly. Software companies make big investments into clean code by hiring someone and paying them around $60-$100 an hour because of how vital it is for long-term success. An effective strategy to implement clean code is by grouping similar functions, utilizing whitespace, and “one idea per line” and “one action per statement”. To tie it all together your code must be consistent to adhere to agreed-upon team coding standards. Decisions that will help in the long run would be to add meaningful names, maintain simplicity, and apply comments effectively. 

With this article, I was able to learn a new term “Spaghetti code” that is self-explanatory and can remind me to keep my code simple and clean. I was able to connect many teachings from class including using meaningful names, abiding by team agreements, and utilizing whitespace. All these are valuable pieces in writing clean code that should always be in your mind when writing any piece of code. I was surprised at how much software companies invest in clean code and wasn’t expecting them to get paid that high. My main takeaway from the article was to keep my code consistent and simple. You may not think about these things but wanting to make things more complex can be a determent to all your previous work so being consistent will not only help you but your team as a whole.

https://reflectoring.io/clean-code/

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 12 Project Coordination

While we have been working on our projects I have wondered what we should expect in our upcoming work. That is why I searched for an article that would give me insight into the later parts of our project. Just finishing up the project set up a few days ago will help me map out the rest of the project itself. I targeted my article on projects in GitLab to have a more precise understanding rather than a broad project understanding with no correlation to our own.  Hopefully, giving you the knowledge I gained will help your journey of developing your project.

This article gives the reader an insight into how GitLab coordinates its scheduling, planning, tracking, and releasing. To decide on their release date they use the Good Docs Projects template which emphasizes two updates per year. So for GitLab, they work from Jan – May release mid-June, then a three-week break, then back to work from July to December, have a release, then another break starting the cycle over again. In their six-month work, it’s similar to scrum where the team meets up in the beginning and establishes goals. During those months they do general community meetings to see if they’re on track and assign issues by weight of importance. On release day, all the team members meet up to build the team artifacts including their zip files and tarballs. If everything goes right and all their merge requests are complete they try to make sure everyone is credited and then go on a three-week vacation where the cycle begins again all over again. 

After reading this article it showed me a new and effective way to complete a project. This way of doing a project has many similarities to scrum but in the grand scheme of things, all you need is a cycle that is effective and can be repeated. In this particular project, I can’t use their scheme but I can try to concise it into a smaller scale understanding the time constraints. I think it’s very effective to have a break after finishing a project. Some people may want to take a break in between projects but in my opinion, it’s better to finish it overall then take time for yourself. In the article, there was no research on the effects of the break but I believe their workers come back replenished and ready to work when they do come back. 

https://about.gitlab.com/blog/2023/08/24/coordinating-documentation-projects-gitlab/

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 11 Choosing a programing Language

I was thinking about our recent classwork activities and our own project and thought about what goes into selecting a programming language. I always assumed it was a preference but sometimes some languages have more benefits than others that can help you in the long run instead of choosing one you prefer. In addition, you gain more knowledge not sticking to one but being able to adapt to others. That is why I decided to find an article about choosing a programming language for your specific project.

This article uses a perfect analogy of how building a house is like choosing your programming language. For example the specifications of the house, what materials will you use, and where you want to build your house. You need to ask yourself similar questions like what kind of project, the development budget, and the complexity of the project. My main takeaway was to have a main objective of your project and have a clear definition of what you intend to do so you may pinpoint the type of application you want to create. Every language has a main focused application purpose like Front End Development: JavaScript, HTML, and CSS, 2D Game Development: JavaScript or C#, and 3D Game Development: C# or C++. There is a large list but being able to envision your project will prevent mistakes from occuring. For this specific project, I believe the article makes a valid point that the development time limit is a great concern in choosing a programming language. With a deadline, you can’t just slack around or try to learn a new programming language with the time constraints so choose wisely. 

Reading this article allowed me to open my eyes to each programming language’s specific uses. I knew that some languages were best suited for different things but allowing me to see the variety was eye-opening. After reading this article I am now able to choose what programming language I will use for my project more efficiently. I know it isn’t the main focus of the project but it’s a step forward. In addition made me think about the small things like security, performance, and maintainability. You may not think about these things as soon as you start but may become big concerns later down the line without the proper planning ahead. For example, performance will only be taken into account late into the project after there has been ample time placed on the project. Maybe the specific application you making doesn’t work efficiently this will hurt meeting your deadline without proper precaution.     

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 10 choosing an Open Source license

Over the past few weeks, we have been learning about licensing and the different kinds and uses they all have. We have now even started to choose/implement our own inside our own group projects. In addition, the homework we did had to do with licenses.  With so much already learned about licensing why would I gain from learning more about this topic? Sometimes when doing work in a time-constrained environment you don’t absorb all the information and with this being at my own pace I can review and learn new things I may have missed or not seen. 

With all the information we have been learning about licenses you may think it’s hard to retain all this information but one key thing you should remember is that licenses can be split up into two categories copyleft licenses or permissive licenses. A copyleft license basically makes the modified open-source work be released under the same license. The original copyleft license is GPL (general public license) which means that any project using GPL must be open source as well. Another example of a copyleft license is LGPL (Lesser General Public License) is considered much more commercial-friendly than GPL because it has no requirements for software that only uses the license project. On the other side of the spectrum, there are permissive licenses that don’t put restrictions on people using a project. An example of a permissive license would be MIT which allows users to do whatever they want except they must contain the copyright statement and the original license. Even with all the possible choices for a license, you must ask yourself what your project needs and look at examples if ever stuck. Also, don’t forget to choose a license because this will cause much more harm you will restrict your code from being used by anyone except yourself.  

Reading this article allowed me to see licenses in a more simple and enclosed way instead of being bombarded with multiple different licenses. Being able to split up licenses into categories in a concise way allowed me to see how licenses weren’t as complicated as I thought. Now when I am shown a license I can automatically put it in a category and understand the major functions of what restrictions may it have. Also, it is easier to know the purpose of my project and be able to pinpoint the exact license I may need. I know I make it sound simple but the process in itself can be overwhelming having a foundation can make the process not as nerve-racking. 

https://www.codecademy.com/article/choosing-an-open-source-license

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Launch

Welcome into David Castillo first blog post. Currently I’ll be using this blog post mainly for CS-343 course. This will be the start to something new that I will keep updating in the future.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.