Category Archives: Week 1

Should Software Architecture be Simpler?

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.

Week of September 11, 2023

This week, I reviewed chapter 8 from Learning Java by Building Android Games 3rd 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

Screenshot of my game available at the Github link

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.

How To Become Better at my First Programming Language.

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.

Expose Your Ignorance Pattern~

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.

Apprenticeship Patterns – Chapter 1 and more

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.

The Wonders Of Testing

Testing is an essential tool when it comes to software development. This week I listened to the podcast “Code Newbie Podcast”. In the episode “How to make sense of the testing landscape”, they talk about the importance of testing, and why people test, what kind of testing is done. They bring in Sergei Egor who is the CEO of AtomicJar. His company works with Testcontainers a java library that supports JUnit testing. The reasoning for looking into this episode, in particular, is so I could get more familiar with how testing works and its intricacies. The experience with testing my programs is very minuscule, and so having a veteran QA developer explain the little details of testing is just what I need personally.

Sergei goes on and explains that when discussing software, new features are being implemented almost all the time and so in order to make sure that those features work as intended, testing must be done. When working on a program, it’s fair to assume that the program must meet a certain amount of requirements and so testing ensures that all those requirements are met. The whole point of Sergei’s company is to optimize testing for software companies that don’t want to create miscellaneous code just to test a certain feature or task. The question that Sergei brings up is why can’t it be done through the backend of the program? And so Sergei’s company basically specializes in these software developing phenomena.

He goes on to explain different types of testing such as automated testing, performance testing, and the most popular type of testing which is unit testing. Unit testing is basically low-level and it will tests individual methods and functions. I’ve worked with unit testing in my previous computer science courses so I am most familiar with this type of testing. I would use unit testing in java for the most part. I had a project that involved me creating a banking account class, and basically, I had to create a JUnit class that would test all my methods such as my “getFirstName” method or my “getBalance”, so on and so forth. It would basically tell me if these methods succeed or not. When Sergei started talking about unit testing it felt very familiar with assignments I’ve worked on in the past.

When he started going into performance testing which is a test that evaluates the speed and reliability of an application, it made sense on paper but with my little experience, I began to struggle with how one may go about doing something like that. With the implementation load test as Sergei mentions, load tests are used to work the application to its full potential and record its response times and request counts as he goes on to explain. Something else that I found interesting while listening to Sergei is the question of why can the developers test the code so that the company doesn’t have to hire a crew of QA engineers. In Sergei’s words, he explains that many developers don’t want to think of all possible inputs for a program they would rather have an algorithm such as property testing do it for them.

Property testing relies on properties and makes sure that a program abides by those properties. It would be interesting to see this type of testing work with my mobile application which word recorded finance information- it would typically crash when inserting a record of payments occasionally and so having an automated testing algorithm such as property testing could have helped me figure out why my program failed in some instances. Automated testing would serve me in testing my programs and their functionality, running multiple tests whenever it’s needed.

Link to “Code Newbies Podcast” S18:E4: https://open.spotify.com/episode/51gZ0yQATZQ8twsJzRb7YE?si=39e4585f9db143c0

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

Self introduction

This blog documents my journey learning Computer Science (CS) concepts. Posts will be precise and summarized to make the entire process informative, enjoyable and worth your time. The CS discipline is constantly changing and I can’t wait to see what’s coming up next, hopefully we can keep up! Let’s explore together and brace ourselves for the journey ahead.

One more thing, I thought it would be good for me to give a brief background about myself so you can get the whole picture. My passion for technology started when I was young, about the age of four wondering about the person speaking inside our family’s radio and how they fit in there. These are some of the questions I wrested with and couldn’t imagine how tiny that person could be.

As time went on, so did my enthusiasm; this time it was anything electronic especially mobile phones. Back in my day, it was only adults who owned phones and they were mono colored specifically black with a green background. No apps had been introduced yet, the only capabilities they had were messaging, making and receiving phone calls, contact’s book and a few select games such as snake and Tetris. At any opportunity I had to hold someone’s phone, I went straight to looking for games and if I didn’t find any I was deeply disappointed.

Fast forward as technology grew, I decided that I would invest myself in understanding how things work and how they were made to work. In high school, my best classes were STEM especially Physics and Maths. It was fun seeing how different formulae would be used to solve computational tasks. I recognized that paying attention to detail was key to solving any problem. I self-proclaimed myself to be the family’s judge because I would take on arguments and apply logic to them and just like that it they were solved.

Another fast forward; no pun intended, I learned that Computer Science was the what I had been looking for all along. I was lucky my family was gifted a computer by a young adults Christian group from Australia. It was on this computer that I spent my days breaking and learning new things. Then, I got introduced to the internet and was mind-blown, then I learned about Facebook. Best thing at that time, I’m not sure about now.

I could go on and on but in the interest of time and my promise to keep this summarized, let’s stop here. Basically, I’m passionate about Computer Science and I would love to make a positive contribution to the human race through technology.

Thank you for reading my blog.

The post Self introduction appeared first on Velt.

From the blog CS@Worcester Archives - Velt by byaruhangamoses4 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Your First Language”

This apprenticeship pattern describes how we should approach our first language and how develop our craft in it. The greatest and simplest way for us to master our first language is to tackle real problems to solve. It is beneficial for us to practice problems and code that provide feedback to us with an example being using a print line function to see what we’re getting from specific functions and methods from maybe certain APIs. These test-driven results really teach us to take small steps in developing code and to take a step-by-step approach to testing out assumptions on what we’ve written. We also should always try to learn from more experienced peers. They can help provide insight into some of the nuances in the programming language we are trying to learn.  Also, don’t shy away from focusing on what you’re not good at, try to branch out of what you’re comfortable with and try different types of coding outside of your comfort zone.

What I’ve taken away from this is to try and solve real situational problems to help us learn how to code. A lot of times as students, we tend to just try to get assignments done without truly understanding how certain parts of our code work. We are just learning our first programming languages and are never forced to understand how to use certain things for specific situations. That’s where I believe that using mentors to our advantages work very well. We are able to ask them for help to help us understand the reasoning behind why we use certain things.

This pattern has been insightful into the basics of how to approach my first language. I personally shy away from the things I am weak in and tend to focus more of my time into what I’m good at. As a software engineer, I shouldn’t be scared to tackle problems that I’m not comfortable with but now feel as though I should go back and revisit what I’m not comfortable in. I should be able to use my resources and the people around me to begin to get better at what I’m bad at and to use test driven results to help bridge the gap with what I’m bad at. If I do not understand something, there are always ways to get around and to better myself.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

The White Belt

As I started looking into the list of patterns, “The White Belt” hit the nail on my head as the problem illustrated in this pattern looks like what I’m currently facing, or have been facing against for a while I would say. I think the first time I found myself in a “wrong place” with programming was in a Hackathon back in spring 2021.

The situation was my teammates were all having Java background so we decided to create an Android Application using Android Studio so everyone can write code in Java. However, things began to feel strange as we started, Java here is not what we were familiar with actually, the coding concept is different as we have to understand what we need and find out the right documentation according to the problem, something that we were not supposed to do initially, but it’s impossible to change the project now as it might collapse team spirit. Therefore, I had to wear the “black belt” and learned the hard way to figure out how to implement features in a short period of time. The repository that we were working on that time if you want to check: OPCredit

This project damaged my thinking more than it improved my knowledge as I feared that my personal development has stalled because I can’t write Java while Java is my first programming language. According to the solution and action indicated in the book, I ameliorated the situation by learning basic JavaScript, I was impressed by how less complex the code is compared to Java while doing the same thing. Then, as I proceed to learn its frameworks, and from ES5 to ES6, in my view, this is one perfect instance where you shouldn’t suppose to already know what will be implemented, but to be neonate and accept the concept.

By the time this post is online, I was learning CI/CD and Docker, something that is not related to my first language as I will have to understand what is happening in the Command Line Interface to give the container the correct solution. This time, I will wear “The White Belt” even more carefully to not only learn what I have to learn but also to practice how to use this belt for future progression.

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

Apprenticeship Pattern: Your First Language

For my first blog post on these patterns, I wanted to start with Your First Language. I have only been exposed to a handful of languages since starting my computer science journey. And though I have honed my skills somewhat in those languages, I am by no means a master at them. I can relate to the problem in the pattern, so I was interested in what it had to say. This pattern addresses those who are looking to start learning a programming language or those who feel their skills are not up to par with what a job is looking for. Selecting your first language could influence your future career, so it is important to choose a language wisely. The solution suggests choosing a language based on those around you, for example, an expert in the subject that can mentor you. Becoming proficient in a language involves building up knowledge through reading specifications and solving problems.

One of my main takeaways was to choose a language based on the people you know, specifically an expert. The other takeaway was to look at the community built around a language and see if you want to belong to that community. I found those two points to be the largest deciding factors when it comes to picking up a new language. For me, I would consider my first language to be Java since that was the first language that I learned at school. There were plenty of professors that aided in my learning process and the community surrounding Java is extensive. It would only make sense for me to continue learning about java and solving sample solutions until I consider myself fluent. I think starting a professional career is a bit daunting, but what the pattern explains makes a lot of sense. The only way to become proficient at a language is to do a lot of reading and try out problems myself. A work environment where you can call on a more experienced team member is also beneficial when it comes to learning a language. That being said, I don’t think there is anything I disagree with anything mentioned in the pattern, it more so emphasizes what it means to be a good learner.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.