Greetings, fellow enthusiasts of code and programming! I’m Hieu Tran, a senior majoring in computer science, and I’m thrilled to welcome you to my latest blogging adventure. As I step into the realm of CS-448 Software Development Capstone, I can’t help but feel a blend of excitement and anticipation.

This blog marks a significant milestone in my academic journey, representing the beginning of my final computer science course before donning the cap and gown in May 2024. The Software Development Capstone promises to be a culmination of the knowledge and skills acquired throughout my studies, providing a platform to showcase and apply what I’ve learned in a real-world context.

As I navigate through this capstone experience, I’m eager to share my insights, challenges, and triumphs in the realm of software development. From coding intricacies to project management strategies, I aim to document the various facets of this course that contribute to my growth as a computer scientist.

To my fellow readers and learners, whether you’re a seasoned developer or just starting your coding journey, let’s embark on this final chapter together. As I delve into the complexities of software development, I invite you to join me in exploring the ever-evolving landscape of computer science.

Here’s to a semester of learning, coding, and making the most of every opportunity that CS-448 Software Development Capstone presents. May this journey be as enlightening and rewarding for you as it promises to be for me. Cheers to the coding adventures that lie ahead!

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

In the world of software development, there is an old saying “two heads are better than one” that has taken on a whole new meaning. Modern software development is often a complex interplay of various skills and perspectives, and it is through a community and in collaboration that the collective genius of a team truly shines. By working together, developers can leverage their unique strengths to produce code that is both efficient and elegant.

Collaboration within a community means the free exchange of knowledge. Developers can share their insights, tips, and tricks, leading to a collective increase in skills. This not only benefits the individual but also enhances the overall quality of the software produced.

Community involvement often means peer review becomes a standard practice. Code reviews by fellow developers help identify and rectify issues before they become critical, ensuring a higher standard of code quality.

A strong community fosters diverse expertise. When developers with varied backgrounds and skillsets come together, they bring fresh ideas and problem-solving techniques to the table. This diversity can be a catalyst for innovation, leading to the creation of more robust software solutions.

Efficiency and productivity are crucial in software development, where tight deadlines and shifting project requirements are the norm. Community and collaboration bring a host of benefits in these areas. This usually entails task allocation, shared responsibility and furthermore some feedback given. This ensures full effective productivity in a team.

As we look to the future, the role of community and collaboration in software process management is likely to expand. With the advent of remote work and online collaboration tools, developers from different continents can seamlessly work together.

GitHub, the largest platform for hosting and collaborating on code, has seen exponential growth, with millions of developers contributing to projects daily. Platforms like GitLab and Bitbucket also play crucial roles in promoting community-driven software development.

Furthermore, open-source projects continue to thrive. The Linux Foundation, in its annual report, highlighted a growing number of open-source projects, reflecting the sustained interest in community-driven development.

In conclusion, the power of community and collaboration in software process management cannot be understated. By coming together, sharing knowledge, and working towards a common goal, developers can drive innovation, enhance efficiency, and foster a strong sense of togetherness in the ever-evolving world of software development. The success of the entire industry is built upon these foundations of unity and shared expertise, and it continues to thrive thanks to the collaborative efforts of developers around the globe.

From the blog CS@Worcester – Site Title by Serah Matovu and used with permission of the author. All other rights reserved by the author.

Software Architecture is Overrated, Clear and Simple Design is Underrated: https://blog.pragmaticengineer.com/software-architecture-is-overrated/

Introduction:

Software architecture is a topic that has always fascinated developers and tech enthusiasts. It’s often seen as the backbone of any software project, the guiding force that ensures a system functions smoothly. However, the article titled “Software Architecture Is Overrated” by Gergely Orosz challenges this conventional wisdom. In this blog post, we’ll explore the relationship between software architecture and the article, offer a short summary, and delve into the reasons for selecting this thought-provoking resource.

The Relationship:

Gergely Orosz’s article, “Software Architecture Is Overrated,” is a bold statement that immediately makes me curious. The relationship between the article and our discussion is clear – it questions the importance and relevance of software architecture in modern software development. This article critiques the overemphasis on architectural design in software development, showing real-world experiences where being “by the book” with architectural principles may not always be beneficial. It also goes into the risks associated with excessive up-front planning and the potential benefits of focusing on simplicity, iteration, and feedback.

Summary of the Article:

In a nutshell, the article argues that while software architecture is undoubtedly crucial, it’s not the holy grail of software development. Instead, it suggests that agility, adaptability, and a pragmatic approach to problem-solving should be prioritized over rigid architectural dogma. Orosz shares anecdotes and insights from his own experiences, illustrating how a more flexible approach to software development can lead to better outcomes.

Reason for Selection:

This particular resource was selected for several reasons. First and foremost, it challenges a widely accepted fact within the software development community, sparking a debate that can lead to a more balanced perspective. Second, Gergely Orosz draws from his own practical experiences, making the article relatable and providing valuable real-world context. Third, in a world where software architecture is often glorified and overemphasized, it’s refreshing to consider alternative viewpoints that advocate for adaptability and down-to-earth software planning.

Personal Reflection:

This article has opened my mind towards making software architecture more strict and not as free flowing as the current culture makes it out to be. I do like simplicity when it comes to anything, but software architecture especially is key because of team work. When a team is meant to come up with a solution to a problem, you should be making things as simple as possible so all team members can process the information and act accordingly.

Conclusion:

In conclusion, software architecture is undoubtedly essential, but as the article “Software Architecture Is Overrated” argues, it may not deserve the exalted status it often receives. The relationship between the article and our discussion is clear, as it challenges traditional beliefs and encourages us to rethink the role of architecture in software development. By selecting this resource, we aim to stimulate critical thinking within the software development community and inspire a more balanced approach to creating software systems. It’s a reminder that, in the ever-evolving landscape of technology, adaptability and pragmatism should always be valued alongside architectural excellence.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

This week, I reviewed chapter 8 from Learning Java by Building Android Games 3^rd Edition by John Horton. This chapter reviews some of the principles of object-oriented programming, including encapsulation, inheritance, and polymorphism. Interestingly, the principle of abstraction that was named alongside the previous three in the course syllabus is not reviewed in this chapter of the book. I chose to write about this resource because in the last Spring semester, I studied this book in order to create a functional mobile game in Android Studio for my final project in my Operating Systems course. I needed to apply my knowledge of arrays, for and while loops, and Java class design to complete this project. In addition, I needed to learn how to utilize the graphics libraries within Android Studio to visually represent the entities within the game and how they interacted with each other. While this book did help me tremendously in the later stages of the project, I wish I had found it earlier before I began coding. I had begun the project in BlueJ, and was coding a Java app meant to be run on a Windows or Mac system, not an Android mobile device as was the project specification. I completed a functioning version of the game with all the features I wanted to include that ran on my Windows PC, but I found it much more difficult than I anticipated to port the code I had written into Android Studio to produce a version of the game that would function on mobile devices. However, because I had applied the principles of encapsulation, inheritance, and polymorphism to my Java classes and functions, I was able to get the program to a partially functioning state on Android by the final due date. My first challenge in porting the project from PC to Android was addressing how to display the program on the device’s screen. Through this book, I found that constructing my Game class so it would extend Android’s Activity class would be the first step in displaying the desired output. I also applied the principle of inheritance to the Java classes I created to represent the in-game objects represented on screen. As many objects as I could manage inherited from a parent GameObject interface, which would be extended into more specific StaticGameObject and MovableGameObject subclasses, and then from those classes I extended them into specific types of objects like PlayerCharacter, Obstacle, and BonusItem. For my next software endeavor, I want to adhere to these principles more purposefully when coding, as I think that a lot of the challenges and headaches I experienced while creating this video game were self-inflicted.

If you want to try the game I made (I was so pressed for time by the end I never named it), here is a link to my Github repository. The project should be able to opened up and run from inside BlueJ or your Java IDE of choice.

Source: Learning Java by Building Android Games: Learn Java and Android from scratch by building five exciting games, 3rd Edition by John Horton

Github repository: https://github.com/MCummingsWSU/CS373-mobile-app-final-project

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

Learning a language is really difficult, not only is it really hard to get started with one but once you have a good understanding of the syntax then learning certain methods of how that language can be used can be quite time consuming to learn. The problem I tend to have is that it can be difficult for me to implement a specific method in my work. For example I could go in and look at an example of a design pattern like the factory method, and I could know how it works and what it does, but I would have a hard time trying to implement it in my work.

Now, one of the first patterns that is introduced in Apprentice Patterns puts the reader in the context that they are starting out as a programmer and that they have a shallow understanding of the languages they know. The problems that we are introduced to are that since we have such an unlettered understanding of the language, it is difficult for us to create quality programs and solve problems. The solutions to this is that we must pick a language and take the time to become fluent in the language. The drive of wanting to learn and solve solutions for that language should be enough to guide the learning process.

While reading about this pattern, It was safe to say that this wasn’t the first time I’ve been exposed to this information of how to become fluent in a language. What really captivated me was how the author made a good point in learning the fundamentals and not just syntax, I feel that at this point in programming journey I could string a couple lines of code together because I’m to familiar with the syntax of my language, but the potential that I can create in that language is close to none. I wouldn’t know the first thing to do to start a project. The author put an emphasis on learning fundamentals, learning how to solve solutions with the chosen language, and how to use testing to your advantage. It’s important to open every and any feasible avenue when working to understand the language. As the author mentions, it must click. There is a difference between learning how to write a piece of code and absolutely knowing every purpose of that code. My goal is to find someone that knows more about the language I’m trying to become fluent in and to learn as much as I can from them, almost like a master. It’s a lot easier for me to acquire someone else’s wisdom rather than figuring it out on my own.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Hello! 

For the grand start of my discussion of apprenticeship patterns from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, I wanted to begin with the pattern Expose Your Ignorance.

Expose Your Ignorance is related to the notion that managers and team members expect you to know what you’re doing. For your position, you may know most of what is expected for your role and overall what you need to be doing. However, there are some components that you are bound to not be as familiar with, or have no experience with, like some new technology. The solution to this is that you should reassure them that you’re learning how to deliver to them what they want, and not to pretend that you know how to do it. You would be able to form a reputation of having a great learning ability rather than playing on with fake expectations of what you know.

One way to expose your ignorance is to ask questions. It may be difficult to do so at first, but eventually communicating with team members who are very knowledgeable about the topic won’t be such a tribulation. This would be helpful to give your team members a scope of what you can do and learn, and could also help them understand more about the topic as they explain things to you. The book suggests keeping a list of things you don’t understand related to your work in a place others can see.

I appreciate that this pattern addresses my concerns as someone new and heading into the workforce. I often feel pressure that there are some things that I probably should know how to do, or that I need to do something but it involves something I have not heard of before. But as discussed with the pattern, I do know a good chunk of what I need to be doing, and what I don’t know are just some gaps between them, so I don’t need to feel so pressured. This reminds me that team members I work with have been using this technology and certain methods for a while now, and I just haven’t learned them yet, so I am not too behind. 

 I’m very open to learning and I can reassure them that I’m studying and practicing what I’m learning from them and other sources. I also shouldn’t be afraid to ask questions, because asking someone for help can help put me on track faster to having a better foothold on the technique/technology I’m working on. Of course, I still try to solve things on my own for as much as I can so I won’t have to repeatedly ask for help, but I keep in mind time constraints. I definitely agree that I shouldn’t just specialize in one thing, but aim to branch out and learn more to have a better foothold in different components of technology. I don’t think I have anything I disagree with for this pattern.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.