Category Archives: Technology

Elevating Code Reviews: Practical Tips for better Collaboration

Code reviews are a vital part of the software development process, serving as a checkpoint to ensure quality, foster knowledge sharing, and mitigate future issues. Drawing on practical advice from a stack overflow blog article (found here) this post explores how to elevate the practice of code reviews, enhancing their effectiveness and the collaborative environment they create.

Summary

The article from stack Overflow provided insightful tips on improving code reviews, emphasizing the importance of constructive communication and efficient processes. It suggest setting clear goals for reviews, such as catching bugs, ensuring consistency, and mentoring junior developers. Techniques like keeping comments clear and actionable, prioritizing empathy and understanding, and maintaining a balance between criticism and praise are highlighted as crucial for productive reviews.

Reason for selection

I chose this article because effective code reviews are essential for any development team aiming to produce high-quality software. As our coursework often involves collaborative projects and peer reviews, applying these enhanced practices can significantly benefit our collective learning and project outcomes.

Adding to the reasons for selecting this article, another compelling aspect is its relevance to the ongoing discussions in our software development courses about maintaining high standards in coding practices. As someone who has been part of several projects and observed firsthand the impact of well-conducted code reviews, I recognize the value in learning and sharing effective review techniques. This article not only enhances our understanding of best practices but also equips us with the tools to implement them effectively in our work, making it an invaluable resource for any aspiring software developer eager to improve their craft and contribute positively to team projects.

Personal reflection

Reflecting on the article, I appreciated the emphasis on empathy and clarity in communication. In past group projects, I’ve seen how negative feedback can demotivate peers, whereas constructive and positive communication can enhance team dynamics and improve code quality. This article reinforced the idea that code reviews are not just about finding errors but also about building a supportive team culture.

Application in future practice

Armed with these enhanced practices, I plan to apply the article’s recommendations in upcoming projects, particularly those involving teamwork. Emphasizing clear, empathetic feedback and leveraging tools for automating mundane aspects of code review will allow me and my peers to focus on more complex issues, thus improving our efficiency and the quality of our work.

Conclusion

Effective code reviews are more than just a quality assurance step; they are a cornerstone of a collaborative and learning-focused development environment. The tips provided by the Stack Overflow article offer valuable guidance on making good code reviews even better, ensuring that they contribute positively to both project outcomes and team dynamics. As we continue to engage in more collaborative projects, these practices will be essential in shaping how we approach code reviews and interact as a development team.

resources

https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Mastering Automates Testing with Selenium and Java

In the ever evolving world of software development, automated testing has become indispensable. Using tools like Selenium combined with Java, developers can automate their web application testing, improving efficiency and accuracy. This blog post delves into the key takeaways from a helpful Sauce Labs article (https://saucelabs.com/resources/blog/writing-tests-using-selenium-and-java) that outlines how to write testes using Selenium and Java, exploring its relevance to our coursework on software testing methodologies

Summary of the Resource:

The Sauce labs article provides a comprehensive guide on writing automates tests using Selenium, a popular tool for web application testing, and Java, one of the most used programming languages. It covers the basics of setting up Selenium with Java, crafting test scripts, running tests, and interpreting the results. The article emphasizes the importance of Selenium for its ability to simulate user interactions with web elements, which is crucial for verifying the functional integrity and performance of web applications. It also touches on integrating these tests into a CI/CD pipeline, demonstrating how automated testing fits into broader software development practices.

Reason for selection:

I selected this article because it offered a practical introduction to an essential skill in software development. As our course covers various testing frameworks and tools, understanding how to implement and utilize these tools in real-world scenarios is crucial. The articles focus on Selenium with Java is particularly relevant, as many of us are familiar with Java and may soon need to apply these skills in internships or jobs.

Personal Reflection.

The article made me appreciate the power and necessity of automates testing in modern web development. It was enlightening to see how Selenium scripts could mimic actual behavior, such as clicking buttons or entering data, which is critical for testing user interfaces. Reflecting on this, I see the immense value in learning automates testing not only to boost my future job prospects but also to ensure that I can contribute to creating robust, user-friendly software.

Application in future practice:

Armed with the knowledge from this article, I am eager to apply these testing techniques in my upcoming projects. Whether it’s for class assignments or eventually in a professional setting, understanding how to set up, write, and deploy automates tests using Selenium and java will significantly enhance the quality of the software I develop and maintain.

Conclusion:

Automated testing is a key component of software quality assurance. The insights provided by the Sauce Labs article on using Selenium and Java for testing offer both foundational knowledge and practical steps for anyone looking to enhance their testing skills. As software becomes increasingly more complex, the ability to efficiently test and validate software functionality becomes even more critical, making these skills invaluable for any aspiring software developer.

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Week 15

Last week my group and I were discussing behavior-driven development. It is a type of development that refines our previously learned developments. This is a great jumping point to what we were previously learning and it will make for a great assignment. I would like to give more information on this subject matter because it is valuable. This is another practice that is used in the field that can be used in the future.

Behavior Driven Development (BDD) is an agile testing practice that prioritizes creating automated tests first before specifying system behavior. BDD is utilized in a group setting where both agile teams and business participants can see eye to eye. BDD are tests used to capture a story, feature, or capability from a user’s perspective. During this development, there should be three different heads of mentality to considered. Customer minds usually stakeholders understand the business needs and their desire for new requirements. Developers understand what needs to be done to accomplish their responsibilities and technological feasibility. Test-centric minds should consider any exceptions, new edges, and boundary conditions. There are three phases during BDD discovery, formulation, and automation. The product owner or product manager creates criteria that must be used to write a good story. Then, the discovery process where the team finds any additional information that could enhance the criteria. There is an automation phase that automates the acceptance test. This test shares a lot of similarities with Acceptance Test–Driven Development (ATDD) and Specification by Example (SBE). 

This new development strategy was very useful to learn. It’s good to understand different types of development plans and how you can combine them to make a stronger development cycle. During the agile team cycle, I feel like every cycle you can change what type of software development you use for that cycle. Based on the project, resources, and time you can choose different software developments. Learning about BDD gave me an insight into the business side of the development process. These are things you may not think about when creating your software but should be a priority. You would expect your software project to be examined by someone who is informed in the field but to try to explain to someone that is funding it would be a hassle but necessary. It makes sense that people who aren’t on the team would have to understand the development. It’s a group effort between multiple teams that all must work in unison to create a working product.  

Advanced Topic – Behavior-Driven Development

https://scaledagileframework.com/behavior-driven-development/

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

Week 14

Considering this week we only had one day of class it’s good to reinforce the ideas we learned to spread out in separate classes. I was in a search this week for an article that went into depth about software technical reviews. Software technical reviews are very important; understanding the fundamentals is a key component in the field. 

The main function of a software technical review is to examine a document either in a group or alone and find errors or any defects inside the code. This is done to verify various documents to find if they reach specifications, system design, test plans, and test cases. An important thing to consider is this is a step to make sure the client gets clarity of the project and stays informed on how it’s going. In addition, finalize any changes to reach the requirements before being released to the market. This allows for improved productivity, makes the testing process cost-effective, fewer defects to be found outside the team, and reduces the time it will take to create a technically sound document. The main three types of software reviews include software peer review, software management review, and software audit reviews. The process of software review is simple if you are informed of the implementations taking place. First is the entry evaluation which is just a standard checklist to know the basis for the review. Without a checklist, you will be pulling on strings to find what is wrong with the code or what it’s missing. Then comes Management preparation ensures that your review will have all the required resources like staff, time, and materials. Next is review planning where you create an objective that comes from the team. You then move on to preparation where the reviewers are held responsible for doing their specific task. Lastly, examination and exit evaluation where the group meets up and is discussed to make the team on the same page and verify any discoveries.

Reading this article allowed me to see other steps that are taken to do a software technical review. If we as a team were able to create an objective of what to search for inside the code last week it would have been more goal-oriented instead of randomly searching for faults in the code. As a team, it would have been great to have a more organized group so then when we come together we have an understanding of what we should all find. I would like to see how it would work trying to explain to someone who doesn’t code what has been done and show them that their money is being placed in the right place. Other than that this is a great way to reduce time and be in unison with your team.   

https://medium.com/@vyashj09/software-technical-reviews-in-software-testing-what-is-software-technical-review-321462039f4f#:~:text=A%20software%20technical%20review%20is,an%20object%20in%20the%20software.

View at Medium.com

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

“Draw Your Own Map” Individual Apprenticeship Pattern

This week, I decided to focus on the “Draw Your Own Map” Individual Apprenticeship Pattern for CS448-Software Capstone. This is my final required apprenticeship pattern analysis post, and I chose this pattern because it feels applicable to me as I am about to graduate and enter the working environment, mapping out my intended career path from its starting point. 

The “Draw Your Own Map” individual apprenticeship pattern emphasizes the importance of taking control of one’s career development and learning journey. It encourages individuals to proactively chart their own course rather than relying solely on predefined paths or external guidance.

At its core, this pattern advocates for self-directed learning. It urges individuals to actively seek out opportunities to acquire new skills, knowledge, and experiences that align with their career aspirations. Setting personal goals is essential in this process, providing a roadmap for growth and development.

Identifying various learning opportunities, both formal and informal, is crucial for professional advancement. This could include attending workshops, pursuing certifications, participating in projects, or seeking mentorship. Adaptability and flexibility are also key, as career paths may require adaptation and adjustment over time.

Regular reflection on progress is encouraged to refine goals and adjust course as needed. By reflecting on past experiences and learning outcomes, individuals can iterate and improve their development strategies. Additionally, building a personal brand and reputation within the industry is essential for showcasing skills, expertise, and achievements.

In essence, the “Draw Your Own Map” pattern empowers individuals to navigate their professional journey with autonomy, self-reflection, and continuous learning. By embracing ownership of their career trajectories, individuals can pursue their long-term goals with purpose and resilience.

With such a competitive entry-level environment, it is possible that I may find myself (or at a later point in my career) choosing to take a position that may not fully align with my interests and career goals. Additionally, with all of the ongoing changes in the tech industry and world as a whole, what may have been a traditional and common career path is impractical today. So, it’s crucial that I can draw my own map to success and redraw it as necessary throughout my career. By following the strategies outlined in this apprenticeship pattern, it seems a lot more realistic to be able to take a starting position that may be less-than-ideal while still progressing toward my intended goal.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Week 13

The next classes will be about Software technical review it would be great to get a step ahead by delving into the concept. We only started with the review section of the code but fully understood it before the class could skip the barriers of never implementing this idea. Whenever doing something new there is always a barrier which can be difficult at first but with practical knowledge, it can be implemented with a greater effect.  

This article first talks about why there is a technical review. There are technical reviews for the company’s higher-ups who may not be fully aware of the coding process and the difficulties that come with it. They have to understand the developer’s importance to the business because they are spending a lot of money with ineffective results. Many times deliveries aren’t are time and come in fault states having several bugs. This is where a technical review comes in handy it’s a deep dive that provides a suitable perspective. Their definition of a technical review is a deep dive assessment of your software that provides findings and recommendations that be later adapted or discussed amongst your team. Common finds inside a technical review include slow or late deliveries which are just not meeting the due date, random or persistent bugs an example would be fixing the same thing over and over again, and sleepless nights because of worrying too much. These aren’t the end be it all every technical review is different and should be focussed on your team’s goals. The main discussion should be of pain points the things that keep you up at night to make the software complete. Process and team review is another key ingredient that makes sure everyone is working on the right task or if there are changes that need to be made plus an idea to every team member’s contribution to the project. The last thing the team should do is an effective summary that can be graded with a brief description. Detailed findings and recommendations that can be read by people not in depth with coding so they can get an idea of what is being done behind the scenes and can tell the team what needs to change.

Reading this article gave me an idea as to why we do technical reviews because when doing mine I was stuck trying to figure out problems in the code. I didn’t want to nitpick and find small issues that would seem redundant because at times it is better to keep it clean and simple. But understanding that this needs to be done to prove to people on the other side of the business that work is being done is a great insight. It makes a lot of sense that other people in a company would want to know what is happening on other sides of the department.

Technical Review: A Trusted Look Under the Hood

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

Week 12

Considering that we have been working on the Mars rover for the past two weeks, I decided to find an article that correlated with this. I went straight to the source and found something about the actual Mars rover. I was able to find an article that piqued my interest. This article was specifically about the real rover and the people who worked on it. I chose this article to show the broad potential we all have inside the CS field that none of us even heard about. I hope to open your minds to all the possibilities you can do with code.

    The article begins by introducing the reader to Melody Ho a full-stack developer for the Nasa Mars website. She has a multitude of responsibilities she has to publish information about every mission and create data pipelines to be accessible to the public. Her journey began by working on a basic HTML book and playing computer games. She gives her reflection on her journey to inspire the next generation of women in space and technology. She most enjoys programming code that is efficient and adapting it to the best version of code possible. When she was growing up she was considering a career in computer games because she hadn’t yet seen the opportunities available for programming. She leaves the article by advising the next generation. She says to embrace new things and don’t be scared because these are opportunities that are needed to succeed. Technology is constantly changing don’t be discouraged if all doesn’t click it will take time.

   Reading this article gave me more of an introspective view of someone’s life in coding. This article doesn’t have much connection to the code we do in class but I think it’s very interesting to see the whole perspective of a coding journey. This article touches upon aspects that you may not think about every day but it gives much attention to what is important. Melody trying to inspire the next generation is very touching. She didn’t have to do this but she did. For me, it gave me a broader view of programming because sometimes you may have a tunnel vision of what you can do with your code but the possibilities are endless. There are a lot of connections that you may not see on an everyday basis. She mentioned how she double majored in business and I didn’t even see the correlation of coding in a management setting but it’s there. There are a lot of connections in programming with other skills there are some I haven’t thought about.

https://airandspace.si.edu/stories/editorial/coding-brings-mars-data-down-earth

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.

Breakable Toys Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Breakable Toys” Individual Apprenticeship Pattern; while I did not know it when I selected this pattern, it relates back to two other patterns I analyzed earlier in the semester: “The White Belt” and “Confront Your Ignorance”.

The “Breakable Toys” pattern encourages craftsmen working in high-risk environments intolerant of failure to create personal projects, referred to as ‘Breakable Toys’. These projects are typically smaller in scope but similar in toolset to work systems, providing a safe space for experimentation and learning through failure. The pattern advises building tools like wikis, calendars, or address books, which may be overengineered but allow for trying new ideas without significant consequences. Given the book’s original publishing in 2009 and the progression and advancement of technology/platforms since then, other tools and platforms may be more applicable and resources like Git make tracking and controlling versions easy.

The focus is on personal growth, skill development, and enjoying the learning process, ultimately fostering a deeper understanding of tools and encouraging continuous improvement. In this way, this pattern is similar to “The White Belt” and “Confront Your Ignorance”, but focuses on building off of prior knowledge in a low-stress environment rather than ignoring it.

I really enjoyed reading about this pattern and its benefits as it is one of my favorites to implement – actually, while reading it I realized how many skills I have picked up using this method. As an individual, when I learn new skills/tools I naturally want to practice them and their non-instructed limitations as well as just generally play around. While a lot of what I learn may not be directly related to my initial task, I usually pick up a few things that are unbelievably useful later on and give me an advantage in addressing challenges.

The clearest example of this which comes to mind immediately is learning Apache POI and PDFBox early in my Computer Science degree/education. I had a lot of experience with basic Microsoft Office applications and was beginning to understand the power of OOP through my Java learning, so the summer after my first semester I decided to learn how to connect the two. By the end of my project, I was confident in reading/manipulating data from Excel, generating new files or report generation, format text and images in PDF documents, and more. All of this was possible because I took it upon myself to research and create my own “breakable toy” environment to learn in.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Black Box vs White Box Testing

In the ever changing and dynamic field that is Software development, understanding the nuances of different testing methodologies is crucial for ensuring quality and reliability. I would like to say that I stumbled upon the blog “Black vs White vs Grey Box Testing” on Shakebugs.com however, the truth is I was still a little confused after our last class and needed further clarification not only on the difference of the two testing methods but just what they do and when they are used. And well this article did just that it resonated with what we were learning and sparked several insights that I believe will impact future practices.

The article navigates through the concept of black, white and grey box testing (I did not even know grey was a thing.) Black box testing, as it explains, is an approach where the tester assesses the functionality without knowledge of the internal workings of the application. White box testing, on the other hand, requires a deep understanding of the code, as tester need to verify the internal processes and pathways. Grey box emerges as a hybrid approach, combining elements of both black and white box testing. It allows testers to apply their partial knowledge of the internal structures while examining the software’s external functionality.

As I mentioned before I chose this resource because it matched the topics we were discussing in class and further helped develop my understanding of the practical applications of the different testing methodologies. The clear and concise explanations paired with practical examples and visuals, provide a framework to differentiate and appreciate the unique attributes and applications

Reading this article was more delightful than I initially anticipated as when I saw a 13 minute read time I almost closed the tab however, I am glad I did not. I learned that while black box testing is excellent for validating user requirements and functionalities, white box testing is indispensable for internal code optimization and security assessments. Grey box testing , with its balanced approach, offers a valuable perspective for comprehensive testing.

Going forward, I intend to integrate these insights into my approach to software testing. In future projects, I will not only consider the functional requirements but also the internal code structure and security aspects when deciding on a testing strategy.

The blog post is a must-read for anyone in the field of software development testing. It offers clear and practical understanding of the different methods, guiding how to apply them effectively. You can read the full article here . This resource not only enhanced my understanding but has also equipped me with practical knowledge I am eager to apply in the future.

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.