Christian Shadis

In the apprenticeship pattern Stay in the Trenches, Hoover and Oshineye explore the importance of maintaining a development position in the face of success and the opportunity to progress into management. This is a very important topic, since many developers (and employees of other types too) have their careers reach stagnation once they make the leap into management due to their misconceptions about career progression.

This pattern is counterintuitive to me, as historically I have considered management positions to be the goal of any employee, and the thought of turning down a promotion would not seem to propel a career forward. Upon further reflection, the benefits of the pattern are more apparent. If a developer commits to remaining a developer throughout their career, they remove limitations on their potential growth as a developer and employee. They will continue to grow and evolve with the industry and become masters of their craft. Conversely, a developer who accepts a promotion into management may stagnate quickly. Management is a completely different occupation than development, and the recently promoted manager may find their skill set does not transfer. Similarly, the organization may not have much room for progression beyond middle management.

Remaining in a development position instead allows the programmer to spend their entire career mastering their development skills, increasing their capabilities and qualifications for more intense, higher-paid, senior-level programming positions. The programmer can advance and progress with development-based promotions, but staying out of management lends a significant advantage for attaining more prestigious programming jobs in the future.

I hope to use this pattern throughout my career. Once I had aspirations of progressing through management positions until I am high up at a large company, but progressing through management positions won’t be possible by virtue of programming skills – instead, a more attractive plan is to progress through the levels of development and engineering to finally land at a senior position. Not only will this maximize my potential as a coder, but remaining in a position interesting to me instead of stagnating in a more boring occupation will maximize my job satisfaction.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Walking the Long Road. 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.

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.