Category Archives: Software Development

“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.

CS448 – Sprint 2 Retrospective

Our second of three sprints for CS448 – Software Development Capstone concluded and was reviewed last Tuesday (4/7/2024). My team worked very well together this sprint and we helped each other as we stayed flexible and adaptable as changes were rolled out that affected our repo and issues. Additionally, most of our issues focused on FrontEnd tasks including the design, development,  and integration of a user interface for the CheckoutGuestFrontend repo. UI design and particularly implementing Vue.js framework was mostly unfamiliar for our group, so we learned a lot from what we accomplished this sprint.

While we didn’t quite finish all of our initially planned tasks, we did successfully reorganize issues into smaller/more manageable and defined issues mid-sprint and we completed all of our issues up to testing the front-end we built:

“Get in touch with Team: 01-2 and discuss Frontend Tests and their findings” – When we took on the task of developing the CheckoutGuestFrontend repo, we found Team 2 had already taken on some responsibilities and begun researching front-end testing. So our first order of business was holding a meeting with them to decide on a starting point for our group. Our notes from the meeting are recorded here.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/92

“Review GUI Mockup” – For this task, we all met as a group to go over a basic on-paper mockup of what we envisioned and had in mind for the CheckoutGuestFrontend GUI and break down the task of coding the GUI into smaller, more manageable and well-defined issues. In the issue, we document our hand-written mock-up as well as our meeting notes and the smaller issues we refactored to. The “Consider Interaction Boundaries” and “Modify/Improve GUI Framework” issues were encompassed in the preparation and execution of this Review task.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/45

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/44

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/42

Main issue:

“Coding UI to place components on the screen where we want them (“layout”)” – This task encompasses the overall processes of creating the Vue.js, integration, and other resource files and code to actually implement our mock-up. This was our first time working with Vue.js, and we are also less experienced with JavaScript as compared to other languages like Java and Python, so we hit some setbacks and delays as we explored and learned more about using these. There were also some minor steps involving communication protocols that were learning experiences.

Another obstacle we traversed involving this issue is the rollout of the new frontend model by Dr. Wurst. When we first tackled this problem, it was not yet released so we struggled to get a working baseline/framework to edit and build off of.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/43

“General – Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” – This was a task from last sprint which we did not quite complete. This sprint we finished it up by verifying the necessary components. Once the working model was rolled out, we managed to build ours out to a stable state with an attractive UI by holding several full-team code reviews. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12 

In review, our second sprint for CS448 – Software Development Capstone was driven by patience, teamwork and adaptability. Despite encountering challenges, particularly in navigating unfamiliar territory with UI design and Vue.js implementation, we emerged stronger and more knowledgeable. While we didn’t fully complete all initially planned tasks, our ability to reorganize issues mid-sprint into smaller, more manageable ones allowed us to focus on essential aspects. Key achievements included productive collaborations with Team 01-2 on frontend testing, thorough review and refinement of GUI mockups, and overcoming hurdles in coding the UI with Vue.js. We also successfully addressed pending tasks from the previous sprint, ensuring all projects within Thea’s Pantry ecosystem met required standards.

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.

Nurture Your Passion Individual Apprenticeship Pattern

This week, I chose to focus on the Nurture Your Passion individual apprenticeship pattern as I found it applicable to myself as I am looking for post-grad jobs and in one respect must find a job to support myself financially but also look to further myself as a software craftsmen and in my career in general. This pattern underscores the significance of fostering and sustaining enthusiasm for software development. It acknowledges the vastness and perpetual evolution of software engineering, urging developers to actively delve into their interests within the field.

To effectively nurture one’s passion, the pattern recommends the following strategies:

Explore Diverse Areas: Dedicate time to investigating various facets of software development, including web development, mobile app development, artificial intelligence, and game development. Experiment with different technologies, languages, and frameworks to discover personal resonances.

Engage in Personal Projects: Undertake personal projects aligned with individual interests and aspirations. Whether it involves crafting a mobile app, contributing to open-source software, or developing a game, personal projects offer valuable opportunities for skill application, learning, and portfolio enhancement.

Seek Mentorship and Guidance: Surround oneself with mentors, colleagues, and communities sharing similar passions, capable of providing guidance, support, and constructive feedback. Participation in forums, attendance at meetups and conferences, and networking within the software development community fosters idea exchange and shared experiences.

Continuous Learning: Embrace lifelong learning and professional development. Stay abreast of the latest industry trends, tools, and technologies through literature, online courses, workshops, and conferences. Continuously challenge oneself to refine and broaden skill sets.

Balance and Well-being: Strive for equilibrium between passion pursuit and well-being. Guard against burnout by establishing achievable goals, managing time effectively, and prioritizing self-care practices, such as physical activity, relaxation, and quality time with loved ones.

By nurturing a passion for software development, individuals can discover heightened fulfillment, creativity, and satisfaction in their work, ultimately leading to a more gratifying and successful career. I found this apprenticeship pattern to be particularly helpful and relatable as it also complements the Breakable Toys strategy which I covered in a previous post. Even if craftsmen find themselves in a position or situation where they struggle to pursue projects their passionate about, they should devote time to creating a breakable toy to enjoy and continue to learn and grow with.

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.

Code Reviews for Quality Assurance

As we continue in CS443 – Software Quality Assurance and Testing, we’ve delved into the test strategy/skill of group code reviews for debugging. So, this week I chose to search for a blog about effective code reviews with a focus on good practices to extract the most value from participating in them and found a valuable article posted on Vates.com. This article is from August 2023, so it is modestly recent and applicable to our current learning materials and discusses best practices and habits.

Code review is a pivotal practice in software development, offering more than just bug detection. It serves as a collaborative process where developers meticulously inspect code changes before integration into the main codebase. By doing so, it not only identifies defects but also enhances code quality, ensures alignment with project requirements, and upholds coding standards. The process fosters collaboration among team members, facilitates knowledge sharing, and integrates multiple perspectives, ultimately leading to the creation of reliable, maintainable, and efficient software.

To maximize the benefits of code review, it’s essential to implement effective strategies. This begins with establishing clear objectives tailored to the project’s goals. By defining specific focuses, such as code quality improvements, security enhancements, or performance optimizations, teams can streamline the review process and prioritize areas of concern.

Moreover, involving the right team members is crucial. Senior developers, subject matter experts, and team leads contribute diverse viewpoints, enriching the review process and leading to better outcomes. Adhering to a comprehensive code style guide ensures consistency in coding practices, which is vital for long-term maintainability. Utilizing code review tools further enhances efficiency by automating checks, highlighting changes, and facilitating collaborative discussions.

Promoting a culture of constructive feedback is equally important. Emphasizing that reviews aim to enhance overall code quality rather than criticize individuals encourages open communication and continuous improvement. Balancing review speed with depth ensures timely feedback without compromising quality, fostering agility while maintaining code integrity.

Lastly, following up on review feedback is essential for iterative improvement. Addressing comments promptly, clarifying questions, and implementing necessary changes contribute to a learning culture within the team, leading to continuous enhancement of development practices.

Vates is a leading provider of IT and software services and the host of this blog. They provide tools and resources to enable teams to unlock the full potential of code review, IoT consulting, and software testing services. This collaboration empowers organizations to elevate their software development practices, delivering exceptional value to stakeholders through collaborative development and effective code review implementation.

Source:

https://www.vates.com/the-art-of-code-review-effective-strategies-for-collaborative-development

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 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.

Learn How You Fail Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Learn How You Fail” Individual Apprenticeship Pattern, which jumped out to me as I have been considering and focusing on some of my weaknesses as I prepare to graduate and search for an entry-level position.

This pattern similarly focuses on embracing failure and weaknesses as a learning opportunity that is essential for personal and professional growth, and doing so is a crucial part of the journey of the software craftsman. Rather than looking at negatives and seeing them as a setback, “Learn How You Fail” encourages developers to confront their mistakes, analyze them/their origin, and derive valuable lessons that contribute to their ongoing growth.

By doing so in a calm, focused and organized manner, developers can really be thought of as simply taking the necessary steps to progress rather than being caught on a setback and needing to reconsider an approach (or similar). A large part of this pattern is simply mental – viewing failures as stepping stones toward mastery rather than indications of incompetence.

One of the key aspects of this pattern is the necessity of self-awareness. Developers must be able to critically reflect on their actions, decisions, and outcomes. By understanding their strengths and weaknesses, they can identify areas for improvement and take proactive steps to address them. This self-awareness also fosters humility, as developers recognize that no one is perfect and there is always room to learn and grow.

Finally, the “Learn How You Fail” pattern emphasizes the importance of perseverance. Failure can be discouraging, but it should not be a reason to give up. Instead, developers should use setbacks as motivation to keep pushing forward, armed with the knowledge and insights gained from their failures. With each failure comes an opportunity to iterate, improve, and ultimately succeed.

I particularly appreciate this pattern because I have implemented it several times successfully and have adopted it as a general approach to life. Everyone has imperfections and weaknesses, so it’s most important to acknowledge and be aware of these so we can aim to improve upon them over time and lessen their impact on our day-to-day, career, and every other aspect of our lives.

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.

A Look at Test-Driven Development & Benefits

Since just before Spring Break, in CS443 – Software Quality Assurance and Testing we have transitioned on from boundary/equivalence class analysis and onto Test-Driven Development as a strategy as well as implementation. For me, this is a huge relief and joy to get back to working on actual code rather than theoretical comp. sci. work, though it also helped me recognize the importance of non-coding exercises. 

I’ve also been really enjoying TDD as I find it aligns with my general coding habits and builds off them to help me identify new coding practices and strategies for addressing challenges. So I decided to look at some blog posts discussing it and how it’s impacted software projects versus other methods used. Test Driven Development Is the Best Thing to Happen to Software Design instantly jumped out to me.

The post discusses the significant influence of Test Driven Development (TDD) on software design. It explains TDD as an iterative approach shaping an idea into implementation through a cyclical process of ‘fail-pass-refactor’. The author illustrates the two approaches to writing code and tests: one driven by code and the other driven by tests, emphasizing the benefits of TDD in terms of mindset and code quality.

This post also considers TDD in real-world scenarios, highlighting its capacity to provide fast strategic approaches to software challenges that may seem to have no place to start (by creating tests). It addresses challenges in testing and offers solutions such as spying or mocking, managing variable test data, avoiding bloated setup, and preventing “Mocking Hell.”

Additionally, the post discusses the tendency to add unnecessary features in code and how TDD, by its nature, prevents such occurrences, thus aligning with the principle of “You Ain’t Gonna Need it” (YAGNI). This is definitely a fault that I fall victim to at times as I try to plan ahead too far in a project and add unnecessary code so I appreciate strategies to address it. Finally, it suggests that TDD not only aids in requirements meeting implementation but also serves as a technique for gathering feedback about software design, thereby advocating for Test Driven Design (TDD).

My typical strategy for developing code begins with creating a skeleton of basic components I expect to be easy to implement and then fill out the boundaries and remainders by developing minor unit tests (like print lines) to make sure it is working as intended. I sometimes do them at the same time, but I have been doing TDD sometimes without knowing it and am now better prepared to hone in on its benefits.

Source:

https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

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.

Decision Tables from a Template

Over the past few weeks in CS443 – Software Quality Assurance and Testing, we’ve been learning how to apply our boundary test classes to create Decision Tables and apply somewhat similar logic to create Program and DD-Path Graphs for code segments. Decision tables are visual tools used in software testing and analysis to specify actions based on given conditions. The strategy we learned in class of assessing all possibilities then systematically combining them based on the decision outcomes and particularly “Don’t care” scenarios seems like a useful and interesting way to map out test designs.

So, I decided to look into blogs discussing Decision Tables and their implementation in software testing and found a great post on ShiftAsia with abstract and specific examples alongside general discussion. This post is also quite recent – posted on January 9, 2024 – which is something I always appreciate as the software/tech world is constantly changing. It opens by describing how to create a Decision Table by representing it with the following matrix:

Condition Stub Condition Entries
Action Stub Action Entries

Condition stub: List of all conditions in consideration

Condition entries: Filled out with Y/N (or X) to cover all possible combinations of conditions

Action stub: List of all possible actions/output

Action Entries: Marked (generally with X or blank) to show outcome and an association between a condition and result.

This is then illustrated with an example of being able to register according to conditions of having a valid email, registered email, and valid password. I found this template and example helpful to better understand Decision Tables in general by comparing them to the steps we did in our In-Class Assignment 7. And, using the example of an altogether invalid email forcing all results to be “Invalid” makes sense logically for the column consolidation.

The process of combining columns and simplifying Decision Tables is reminiscent of CS254 – Computer Architecture and Organization concepts, particularly using K-Maps to calculate Sum of Products and Product of Sums. Based on similar responses to a variety of inputs, we are able to essentially combine and simplify the K-Map table and in turn the expression it produces. While K-Map logic works based on binary math laws rather than actual outcomes, there’s a clear correlation here as we represent outcomes with boolean values that can be easily represented in binary – as either a 0(false) or 1(true). My personal experience in CS254 wasn’t the best – I didn’t totally understand how many of the concept we learned are applicable in practical situations, so it’s cool and exciting to see it applied in software testing – an area I would’ve probably least expected it.

Sources:

https://blog.shiftasia.com/use-decision-table-in-software-development

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 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.