I’ve always found Derek Banas’ channel really useful. In late middle school, I started watching his tutorials for how to code. So it’s really interesting to go back and watch his videos, to say the least.
I feel like the adapter design pattern is something that shouldn’t really need to be used. Don’t get me wrong, it’s very useful. Like real adapters, however, the problem itself shouldn’t really exist. That’s especially true with code; it seems as though adapters become required when interfaces aren’t abstracted well enough. In his video, for example, he has an EnemyAttacker interface that represents some kind of enemy. However, the methods are very specific and presume certain characteristics about the attacker. We then need to use an adapter to get around that specificity. It seems to me that writing the interface more generally to begin with would be more ideal. But given that it’s a bad idea to modify old working code, an adapter is a great solution.
In principle, an adapter does exactly what you expect it to: it adapts code. It takes one “interface” and connects it to another “interface”. That’s the colloquial interface as opposed to a coding specific interface. We use adapters every day. The best example is a phone charger. It converts (or adapts) 120V AC power to a low DC voltage. It also adapts the physical plug into USB type-c. All of the functionality is hidden inside of the charger and from the perspective of a user, it’s literally plug and play.
An adapter in code acts the same. I honestly like the example he gave so if you want to see an example of actual code, check out his video. Conceptually, one description of an adapter is the following: We have two interfaces A and B that have many differences, but are conceptually similar. We can create an adapter so we can use any A as a B, or vice versa. It’s okay because of their similarity (or perhaps they need not even be similar!). Really, it’s an incredibly basic pattern so the specifics aren’t that important.
Fundamentally, an adapter is just code that allows other code to operate together. Again, I think the best way to conceptualize it is through the imagery of any real life adapters. However, it should ideally not be necessary in scenarios such as the one from the video. Abstraction, within reason of course, should be prioritized ahead of time.
From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.
Hey guys, it’s a weird feeling to be wrapping up my last semester in my undergraduate career in computer science (and sociology). For this final installment of my AMPATH sprint series, I will just go over the general overview of what went on for my team.
In this final installment of my individual apprenticeship patterns, I think an important one to write about would be Find Mentors. To summarize the main point of this one, I would say that it encourages people to observe their role and their surroundings to see where they can find the most value from learning or use their resources. It encourages you to look at things from one level back instead of blindly jumping into something right away.
For my second-to-last individual apprenticeship pattern, I have decided to go with something a little more relevant to my current situation–relating to starting my career post-graduation.
As we have a few weeks left in the semester, I wanted to discuss the more creative apprenticeship patterns. This time I’m going to describe Craft Over Art, which is basically when a solution to a client’s problem can be solved with something that could work…or we could take it and go above and beyond. It’s being more innovative than just settling for a solution just to have something.
From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.
For my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on 
which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.
Having a software-induced identity crisis? Worry no further, I guess that may be a more common thing than I would have expected! This week’s individual apprenticeship pattern will be Use Your Title.
For my first sprint retrospective, I wanted to start off by introducing what kind of project my team is working on and what we are hoping to do with it before I move onto the description of what is happening.