Category Archives: Week 13

Software Development Approaches

A software development approach is a methodology that is used to guide the processes involved in the development of a software system. Different software development approaches provide different ways of organizing and coordinating the activities and tasks involved in the development of software. Some of the most common software development approaches include Agile development, Extreme programming (XP), Lean development, Test-driven development (TDD), and Waterfall model among many much more. These are just a few of the many different approaches to software development. Each approach has its own unique set of principles and practices that help guide the development process and ensure the successful delivery of high-quality software.

Agile development is a software development approach that emphasizes collaboration, flexibility, and continuous improvement. Extreme programming (XP) is a software development approach that emphasizes collaboration, simplicity, and feedback. Lean development is a software development approach that emphasizes the elimination of waste and the continuous improvement of processes. The Waterfall model is a software development approach in which the development process is organized into distinct phases, and each phase must be completed before the next phase can begin.

Test-driven development (TDD) is a software development approach in which tests are written for a new piece of code before the code itself is written. The goal of this approach is to ensure that the new code meets the required specifications and behaves as expected. In TDD, developers write a test that defines the desired behavior of the new code, and then they write the code itself. Once the code is written, it is run against the test to see if it passes the test. If it does, the code is correct and is ready for integration with the rest of the system. If it does not, the code is revised until it passes the test.

I selected thisblog post because I am interested in learning more about Test-driven development. After reading this blog post, I learned about the principles and practices of TDD and how it can be applied in the software development process. I also learned about the steps involved in TDD, including writing a test that defines the desired behavior of new code, writing the code itself, and running the code against the test to see if it passes. I found this process to be logical and straightforward, and I can see how it would be a useful approach for ensuring the quality of new code. I made use of this method (to a degree) while working on the homework assignments for this class. I believe that it significantly simplified the process as having a set goal in the form of tests, made it easier to update/ add code that will work with it. Overall, I found this blog post to be very informative and useful. I learned a lot about development approaches, and I plan to use them for my future projects.

 

Source:

Top 6 Software Development Methodologies

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

Backend developement

Backend development is an essential part of creating a dynamic, interactive website or application. The backend, also known as the server-side, is the part of the website or application that manages the data and logic behind the scenes. It works in conjunction with the frontend, or the client-side, which is what users see and interact with.

There are several components that make up a backend, including a server, an application, a database, and an API. The server is the physical location where the website or application is stored and accessed. The server is responsible for hosting the website or application and delivering it to users when they access it. The application is the actual software that runs on the server and provides the functionality of the website or application. It is typically built using a programming language, such as Java or Python. The database is where the data for the website or application is stored. The database is used by the application to store and retrieve data, such as user accounts, information about products or services, and other data needed by the website or application. The API, or application programming interface, is a set of protocols and tools that allow different software applications to communicate with each other. In the context of backend development, the API is what allows the frontend and the backend to communicate and exchange data. For example, when a user interacts with the frontend of a website or application, the API allows the frontend to send requests to the backend and receive responses with the relevant data.

I selected this post because I am interested in learning more about backend development and how it plays a role in creating interactive websites and applications. Furthermore, a lot of work for this class went into writing code for and experimenting with, the backend code for Thea’s Food Pantry. Working on something actively in use, even without making any changes, was a very interesting experience and will be immensely useful for the capstone class next semester. Understanding the importance of the backend and how it works with the frontend will allow me to better plan and implement the overall architecture of a website or application. Additionally, learning about the various backend components and their functions will allow me to make informed decisions when choosing technologies and frameworks to use in my projects.

 

Source:

https://www.codecademy.com/article/back-end-architecture

 

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

Week 13: Reading List

For this week, I chose to read ‘Reading List’ from Chapter 6: Construct Your Curriculum. I thought this pattern would be a good last pattern to read about now that the semester is ending. This chapter consisted of mostly patterns that are useful for post undergraduate stuff and things to reinforce in your head moving into your software career. So, for the context of this pattern, after becoming proficient in your first language (another pattern), you begin to look around and see the vast sea of info. I found this relatable as there is so many different languages in software programming and so many different technologies that accompany it as well, there is a lot to learn. However, with that in mind, I think that just makes me wanna learn about a lot of the different languages and technologies since software development is so vast.

For the problem of the pattern, you are unable to keep up with the amount of books you need to read. I thought this was kind of a weird problem, if you reach this problem, you probably aren’t managing your time well and need to readjust your curriculum in my opinion. However, the solution tackles this problem similar to what I was thinking, managing your time better. The solution is to maintain a reading list, this isn’t to only manage the books you read but also to reflect on past reading habits and you can use this info to construct a path on what to read next and what to focus on. I thought this was pretty clever, I wouldn’t have a reading list for that purpose, I would just use it to manage my reading habits. The solution does come with caveats though, it’s difficult to implement this pattern without having a deep understanding of your topic in order to figure out which books to read and the order. Ultimately, I think this pattern relies on having a deep understanding of what you want to learn about and what rabbit holes to go down in order to become more proficient at those topics.

For the action, you obviously create your reading list, however you keep it under source control and up to date. Pretty simple action to do, it’s just finding out where to start and what to read that is the hardest part of this pattern.

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

Apprenticeship pattern: Find mentors

This week I read the pattern “Find mentors”. In life, we all need a mentor who will train, and teach us what will become our knowledge tomorrow. Some examples: in schools, universities, at home, our mentors are our teachers, professors, and parents because they teach us and train us to become great people in the future and whatever we know today, it’s thanks to them and their sacrifice. But we have to keep in mind that tomorrow, we will also be someone’s mentor or leader.

In this pattern, the author is talking about seeking out those who have gone ahead of us and striving to learn from them. Everyone at some point has been an apprentice. Teachers, before becoming who they are, were students like us too and had mentors (teachers, professors) who made them who they are. Parents, yesterday were children too and had their parents who were their mentors/leaders and examples for them to follow. It’s a rule of life, which is we can only give what we receive.

To become great software developers, we need to surround ourselves with software developers who already have the knowledge and are willing to teach us and help us understand. Seeking help and knowledge from someone isn’t a sign of weakness, on contrary. That is something that a lot of software developers, even people in general don’t understand.

What I get from this pattern, is that in the computer science field, if we want to be the best or become better at what we’re aspiring for, we need to surround ourselves with people who have more skills than us in the domain that we want to master. Also, we need to keep in mind that we’re walking “The Long Road” and that no one knows everything. Even our mentors learn something new every day. The fact that they know more than us does not mean they know everything.

Our apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of us, there will also be apprentices who have not yet reached our skill level. The other side of our search for mentors is that we must be willing to provide mentoring to those who seek it from us. Passing along what we have learned from our mentors is one way in which we can begin the transition to journeyman status.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

“Be The Worst”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

“Kindred Spirits”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Craftsmanship Log #8 – White Belt

Although I tend to speak rather broadly about certain apprenticeship patterns, nonetheless many of the patterns I have written about in this blog do apply to the field of Software Development. After all, the book, from which these patterns have originated from, that I have been reading for the past few months is more focused on programming than any other craft. This is the reason why this particular pattern applies to my learning process of Software Development which, ironically, I realise that I have not applied to the degree that I thought I have when learning other programming languages. In fact, a significant part of the learning process is to “unlearn” pre-existing knowledge and approaching learning a craft in a “blank slate”. This notion corresponds to a pattern titled “White Belt” which, though it may seem ironic, it is in fact a very significant pattern.

When a developer faces the need to utilize this pattern, it means that their pre-existing knowledge may be interfering with acquiring new knowledge and skills more challenging, or even impossible. When it comes to programming languages, the know-how that one may be holding on from learning and mastering their first programming language may impair their problem-solving approaches. Oftentimes, they may be expecting to see tools or concepts from one language they already know that are completely non-existent in the language that they are learning. Moreover, the potential differences in syntax can also throw an apprentice off when learning a new language, thus it is easy for us to hit a roadblock simply because the solutions we may want are (or so we think) simply not there. As such, a way to avoid this roadblock is to simply approach the new language that we are learning as its own thing and with a clear state of mind.

Usually, I tend to say that I like or agree with a pattern because in my own experience I tend to utilize such patterns in my own, perhaps roundabout way. However, this pattern is the first that has made me question my own approach to learning, which is contrary to this pattern. I often tend to look for “common ground” between my pre-existing knowledge and the new knowledge before me to “save time” and get to “the good stuff” faster. In a way, this pattern hurts my pride as a software apprentice. And, in all fairness, it should. It is important for me to acknowledge that flaw in my learning process and instead wear the white belt when I pick up a new programming language to learn.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Reading List

The ‘reading list’ apprenticeship pattern supposes a solution to a situation where you are finding books you want to read faster than you can get through them. There are lots of really good resources available for programming, and reading them is a great way to help you improve your programming skills. However, with such an abundance of resources, it becomes difficult to manage everything you want to read. The solution is, as is suggested by the name of the apprenticeship pattern, to maintain a reading list. This list should store both books you want to read and books you have already read. Hoover and Oshineye recommend storing your reading list somewhere public so that other people can see and learn from your list. Keeping a list like this for several years will allow you to analyze your reading habits and pick out spots where there might be gaps in your knowledge. As you work through your list, you can use the bibliographies of the books you read to add new books to your reading list. This can also help you narrow your research down into an area you take interest in.

I think this apprenticeship pattern is interesting, and I think it’s a great way to keep track of what you want to read. I think the advice to read books included in the bibliographies of books you thought were useful is really useful. I also really like the idea of being able to monitor your progress as you work through your reading list. I already kind of do this, just not exclusively with programming resources. I use a website to keep track of the books I want to read and the books I’ve already read. I like being able to see all of the books I have or want to read, because I know if I didn’t store that information somewhere I would forget all about it. It’s also really interesting to be able to analyze my own reading statistics like what genres I tend to read and what days I read more. I use it mostly for pleasure reading, but I think it would be useful to dedicate a section of my existing list to programming resources.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 3 Part 3

A Different Road

You find yourself tired and bored of your work. You have some personal projects to advance your skills that keeps you busy, but you find yourself needing to take a break. To diverge from the road you are on to either just rest for a while or to just see where it goes. Your career as a software developer is not what ultimately defines you. A Different Road describes a scenario where the road you have been traveling on in your programming career is not the road you want to travel along anymore. You might wish to spend more time at home and with your family. You might desire to train for a marathon. You could buy a bit of land, build a barn and become a farmer.

The road of your software development career never truly ends until you decide to end it and even if you do, you can always start back on it again. Just like riding a bicycle you never really forget something that you practiced frequently. So, take the break that you need. Buy that farm and become a farmer. Your career is not what really defines you, and maybe whatever you try will need some kind of optimization that your skill-set can solve.

Ultimately this pattern speaks to the idea of breaking the stubborn mindset most people find themselves in. It’s this mindset of having a path and having no other choice. The path paid your bills and you enjoy it to a degree. It’s hard to accept the idea that this thing you have been spending your time on isn’t right for you. To align with the road analogy, the road you have been traveling has been well paved and barely has any traffic. As you travel further and further you might find it gets even easier and has even more lanes and less traffic. You might also find that this road has potholes and traffic has only gotten worse and worse.

Recognizing when that road isn’t worth traveling on is easy to think about, but harder to act on even when it’s right in front of you. But unlike the road analogy, your skills and motivation are not a car. You can’t sell it and lose it, it can’t be stolen from you, and even if you don’t use it for a while it doesn’t mean it can’t start back up again. The thing to take to heart is do what you want to do, but also stop doing the thing you don’t want to do just because it’s your career.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

CS 448 Post #6

I finished the patterns I wanted to write about from chapter 4 and moved on to chapter 5, Perpetual Learning. Like the last few chapters, I to post about the first pattern of the chapter and then one of the last ones, so this post will be about Expand your Bandwidth. The focus of the chapter is on the topic of the lifelong journey of learning that is taken when you are an apprentice transitioning into a journeyman, which is a concept that was brought up in the first chapter.

The first pattern is an effective start to the chapter, as it is about how you can move on from lower level problems to higher level ones, and how you can expand your learning ability. The solution given to the problem is to find different ways to learn more than you may not have been using before, such as blogs, books, and other online resources. Because of how much technology there is in the world today, there are plenty of ways to find information online, and use different avenues of learning. I have found a lot of information online by either looking things up when I had questions or issues, or just by reading blogs and articles. I have looked online plenty of times when I needed help on something, especially computer science projects. I would search based on the error codes I was getting and try different sites to see if I could find a solution that worked for me. Using online resources have been very helpful to me for my work related to computer science, along with some other courses and activities.

I agree with the last paragraph of the solution that talks about deciding when you should start expanding, because while it is good to have all this information to learn from, you still want time to put that learning to use at software craftsmanship. You want to make time to continue working and improving yourself so that everything you are reading about and learning is beneficial to your work. I like that this problem brought more attention to the topic of this being a lifelong journey with continuous learning and development, while pointing out potential problems with obsessing over learning.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.