Author Archives: dcastillo360

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.