Christian Shadis

In the apprenticeship pattern Breakable Toys, Hoover and Oshineye explore the effectiveness of learning through failure, and the dynamics of doing so in a workplace where failure may not be embraced. Essentially, they advise the developer to work on projects on their own time with the important distinction that they can safely develop without harming any other developers with breaking changes. They refer to these projects as ‘Toys’ because the developer should work on projects they find interesting or fun, which will make them more motivated to continue working on it.

This pattern, unlike some others in the book, is perfectly intuitive. “Practice makes perfect” is one of the more well-known clichés we echo, and this pattern is based on constant practice. In fact, much of the information I’ve learned about programming thus far has come from troubleshooting code I’ve written and figuring out why it doesn’t work. The only problem with constantly practicing a trade menially is a blurring of the lines between work and free time; however, developing projects of personal interest to the developer would make the practice far more engaging and feel less like work.

This pattern is not a particularly difficult one to implement, as developers are likely to build personal projects simply because they enjoy development. Yet if a developer uses their skills to build something they don’t care about, it only feels like work – instead, working on building ‘Toys’ feels more recreational and sustainable to implement in free time. To effectively use this strategy, the developer must emphasize the breakability of what they build and focus on using failures to improve both the project and their underlying development skills.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern throughout my first development job. I will be exposed to many new technologies and frameworks in my new position. Using these technologies only at work would limit my comprehension of them. Instead, utilizing these new technologies in the failure-friendly environment of personal development projects will maximize my improvement as a developer.

Reference: Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Breakable toys is an apprenticeship pattern similar in spirit to Be the Worst. They both encourage us to improve by failing in one sense or another. While the Be the Worst apprenticeship pattern focuses on joining a team where you are the worst in order to learn from others on your team, Breakable Toys emphasizes working in an environment where failure is not only possible but even encouraged. Such an environment usually means working on your own projects where any mistakes you make have little to no consequences and allow you to learn from them.

Overall I think that this pattern makes sense, and is a good way to improve ones skills as a developer. I whole heatedly agree with the idea that failure is integral to improving in anything, and especially when applied to programming. I know that whenever I make a mistake I tend to remember that mistake and in most cases I am able to learn from it and improve myself. When writing code for class projects or assignments I frequently screw up certain feature implementations and as a result I learn of a better way to do what I failed to do. Be it through personal research after the fact or direct guidance from someone more experienced than I.

Personally I haven’t really created an environment for myself where I can comfortably fail. While I definitely learn a lot from mistakes I make at school, I wouldn’t go as far as to call that a safe place to fail frequently. Ive had a few personal projects in the past, but I never really thought of them as more than things to slap on a resume or to pass the time. Having read this apprenticeship pattern however, I definitely have a different outlook on those past projects, and will also have a different outlook on future ones. I will likely try to work on projects that heavily involve tech stacks I am not familiar with in order to attempt to learn from my failures working with them. It will be difficult at times as I can be impatient, and the slow initial progress with some of these projects might be discouraging, as well as any screw ups that might come along. But since I will be more aware of the fact that these setbacks are actually helping me in the long run I hope it will help me keep pushing forward.

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

For this week, I am going to cover another type of “new material” that I have learned within my software design class. This “new material” is known as the REST API. As per usual within my blogs, I always try to find some connection to a past experience or previously learned material; for REST APIs, the closest materials would be other web design tools such as HTML and JavaScript.

In a nutshell, APIs are used as a way for clients and servers to interact with each other; these interactions can involve exchanging data or performing behaviors with that data. Languages that involve APIs are: JSON (JavaScript Object Notation), Python and HTML, to name a few. The interactions that APIs perform with these languages are often done in class using modules called “endpoints”.

These endpoints are “sub-containers” that perform interactions with items or collections of data. Examples of endpoints include: GET, POST, PUT and DELETE; whether or not the endpoint works with a collection or a single item is dependent on additional parameters (such as an “id” for an object). Connecting REST APIs to additional parts of the class, API “calls” (similar to functions in other languages) involve setting up ports to connect to a host server; once connected, the call will attempt to perform the requested endpoint interaction with the data found at that port/container.

Linked below is a website that will get anyone interested in REST APIs up to speed on how they work, why they’re important, and other applicable knowledge about the topic. I chose this article, as well as the topic of REST APIs in general, due to the fact that I still struggle with the process of working with them; I hope that with further study, I can become proficient with the material. It seems as though REST APIs, alongside the other material within this class, follows a similar theme; in addition to being based around software design, these topics are related to creating “inter-connected” projects. This makes sense, as very few projects are done in isolation nowadays.

When moving forward, I hope to gain two benefits from learning about REST APIs. In the short term, I would appreciate using this newfound knowledge to help complete my homework assignments. As for the long term, it has been discussed that REST APIs are a profitable market in the computer science field; by being proficient in this aspect of programming, I will be in a class by myself among other programmers.

Link: https://www.edureka.co/blog/what-is-rest-api/

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

As we continue to work with API’s, I have decided to dedicate this blogpost to talk about security with API’s as eventually we will have to take this into consideration when we go into more in depth with them in the future. Security will always stay priority in which I think it would be helpful to look at this area now. I have chosen a blog post that gives us some good practices we can look at to help better our API’s.

In summary, this authors first goes over TLS which stands for Transport layer security which is a cryptographic protocol used to help prevent tampering and eavesdropping by encrypting messages sent to and from the server. The absence of TLS means that third parties get easy access to private information from users. TLS can be found when the website URL contains https and not just http such as the very website you are reading from now. Then they go over Oauth2 which is a general framework and use that with single sign-on providers. This helps manage third party applications access and usage of data on the behalf of the user. This is used in situations such as granting access to photos to used in a different application. They go in depth over codes and authentication tokens with Oauth2. Then they go over API keys where we should set the permissions on those and don’t mismanage those. They say at the end to just use good, reliable libraries that you can put most of the work and responsibility onto so that we can can minimize the mistakes we can make.

These practices will help bolster my knowledge on the security placed within the API’s we are working with. This blogpost has helped me learn more on the general framework on what security measures are placed in the general API landscape. TLS looks to be a standard protocol used in 99% of websites you see but also makes me wonder on all of the websites that I have traversed through that didn’t have TLS and you should too and make sure that you have no private information in danger on those sites. This also makes me wonder on how TLS is implemented such as with the LibrePantry API that is being worked on if it is being used there(hopefully). Then perhaps when we work further in the API’s, we get to see the security practices implemented.

Source: https://stackoverflow.blog/2021/10/06/best-practices-for-authentication-and-authorization-for-rest-apis/

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

When developing software, creating understandable, readable, and testable code is not just a nice thing to do, but it is a necessity. This is because having clean code that could be reviewed and worked on by other developers is an essential part of the development process. When it comes to object oriented programming languages, there are a few design principles that help you avoid design smells and messy code. These principles are known as the SOLID principles. These principles were originally introduced by Robert J. Martin back in 2000. SOLID is an acronym for five object oriented design principles. These principles are:

1. Single Responsibility Principle – A class should have one and only one reason to change, meaning that a class should have only one job. This principle helps keep code consistent and it makes version control easier.
2. Open Closed Principle – Objects or entities should be open for extension but closed for modification. This means that we should only add new functionality to the code, but not modify existing code. This is usually done through abstraction. This principle helps avoid creating bugs in the code.
3. Liskov Substitution Principle – Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. This means that subclasses can substitute their base class. This is expected because subclasses should inherit everything from their parent class. They just extend the parent class, they never narrow it down. This principle also helps us avoid bugs.
4. Interface Segregation Principle – A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. This principle helps keeps the code flexible and extendable.
5. Dependency Inversion Principle – Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions. This means that dependencies should be reorganized to depend on abstract classes rather than concrete classes. Doing so would help keep our class open for extension. This principle helps us stay organized as well as help implement the Open Closed Principle.

These design principles act as a framework that helps developers write cleaner, more legible code that allows for easier maintenance and easier collaboration. The SOLID principles should always be followed because they are best practices, and they help developers avoid design smells in their code, which will in turn help avoid technical debt.

https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#single-responsibility-principle

https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/

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

This week I read a blog post that I thought really related to the class about why software development is important. The blog is about a deep dive into the career of a software developer. It starts off describing software developers as the masterminds behind computer programs. The blog then gives what different types of software developers do, like how applications software developers are responsible for designing computer or phone apps, and systems software developers are responsible for operating systems level software. Afterwards , the skills needed for software developers are shown. Some of the skills are problem-solving skills, teamwork, motivation, and analytical strategy. The blog ends with the salary of software developers($110,000), and a message to motivate the reader for the future. I selected this blog post because software development is my dream job, and I thought it would be interesting to read about what I should expect for the future job. This blog has a good, in-depth description of how Software Development works, that I think every CS major should read. I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because of how deep it goes into the job of a software developer. The blog goes over what to expect, skills needed, the pay, and does it all at a high level. Another reason I would recommend this blog is because a lot of jobs that we need CS-343 for will all be similar to software development, so even if you do not want to become a software developer, you can still learn something. The last reason I would recommend this blog is because it could get people who don’t like software development into the area by showing them what to expect from the job. Knowing what to expect could really help open the doors for others to be interested in this field. I learned how many of the skills that are needed for software developers I have already like Java, and I also learned the skills that I have not learned yet like DevOps. The material affected me heavily because it showed me what skills to learn, and what to expect if I want my future dream of software development to come true. I will take all the knowledge given to me through this blog into the future by getting better prepared to do this job. Now that I know what to expect from software development, I will try to build on it for the future.

https://www.rasmussen.edu/degrees/technology/blog/what-does-software-developer-do/

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

In our most recent class, one of our in class activities mentioned asynchronicity for a JavaScript function. This function required us to use the “await” keyword for us getting data. I’d thus thought of doing a post on concurrency, but in my experience in using concurrency, I’ve noticed myself and others struggling with the difference between concurrency and parallelism. Hence, in order to clearly understand concurrency, I wish to also describe parallelism. 

An application that is neither parallel nor concurrent is one that is processed sequentially, typically one “where it only has a single job that is too small to make sense to parallelize.¹”

Parallelism is simply the separation of a task into multiple sub tasks. These sub tasks are simply parallel if they are worked on sequentially. If two or more sub tasks are being worked at the same time, the program is implementing both parallelism and concurrency.

Concurrency is the act of an application working on two or more parts of an application at the same time. One thread could be running through an array, while another is doing a separate calculation. If an application is running without implementing parallelism, then it is working on each part of the application.

An application that is both parallel and concurrent can partition parts of the application and executes the program’s sub tasks concurrently. It may also include programs that divide a subtask into further subtasks and run those concurrently too.

I picked this particular source because it articulates the difference between concurrency and parallelism, rather than just one or the other. It also has a section that shows the permutations of implementing concurrency, parallelism, both, or neither. Even though I know about parallelism and concurrency, this article in particular helped me visualize them. I did not know that one could implement concurrency without parallelism. 

I feel as through this article will help me understand some elements of homework #5, because it will likely include functions that are asynchronous, and therefore require us to acknowledge it by properly implementing the “await” keyword. While this article was oriented towards locally run applications, this will also aid with applications that are executed to and from servers, by which the topics of parallelism and concurrency will still render useful.

I have also created a program that attempts to implement concurrent execution between multiple sub tasks that exist from implementing parallelism, which this article helped me understand. Specifically, I generate a vector with integers, then split the vector into subtasks which are then run concurrently. Each vector sub task gives the average sum of their respective sub task. 

Links:

1. http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html (the proper article sourced for the information)
2. https://github.com/Chris-Archive/Vector-Parallelism-Concurrency (my GitHub repository of the example I used above in C++)

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