As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.
On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.
I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).
Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.
An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.
I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.
When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.
If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.
The fives types discussed in the article are:
- Layered (n-tier) architecture
- Event-driven architecture
- Microkernel architecture
- Microservices architecture
- Space-based architecture
The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.
Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.
Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.
There are lots of “rules” we must follow in object-oriented software development and the article The Genius of the Law of Demeter by Javadevguy summarizes how they are useful. From what I put together, it seems like the Law of Demeter took abstract concepts and basically put them into a universal set of rules for Object-Oriented code.
I thought that the law of demeter must be a big deal if someone decided to sit down and write a lengthy blog post about it. This content ended up being interesting as it tried to convince readers why they should obey this “law.” The Law of Demeter basically paves the way for what users can do to a given method. It is kind of like considering the restrictions or possibilities based on the method. One of the takeaways I got from this is how there is a lot of focus on communication between two objects.
The rules listed in the article are as follows–noting that it says “For all classes C, and for all methods M attached to C, all objects to which M sends a message must be”:
this in Java)
- M’s argument objects
- Instance variable objects of C
- Objects created by M, or by functions or methods which M calls
- Objects in global variables (
static fields in Java)
Another useful takeaway I got from this article came from observing the code examples Javadevguy included; how Rule #1 covers that any method can be called on the current object. I also noted when there would be an instance where the law would prohibit something is not “sending a message” to any already existing object that is held in instance variables of other classes.
This will affect the way I continue to do work as an Object-Oriented developer. I mean, in life when you learn there is a more useful or structured way to help you achieve more effective results, you would want to try or follow it, right? For my future use, I will acknowledge (like other blogs and articles) that the Law of Demeter is less of a law and only a suggestion or a guideline.
Overall, I would say that the content has helped further solidified my understanding of some Object-Oriented coding concepts. I agree with the content as it is trying to help people become better developers or better understand the Law of Demeter in general.
Over the weekend, I had the chance to sit down and listen to another podcast episode by Developer Things. The title, Women in Technology (with Megan Horton), caught my eye as I am always on the lookout to learn about other women’s experiences in technology.
The podcast series’ goal is for people to learn new developer things each time they listen so here’s what I learned on the career side related to software construction, design, and architecture:
- The stigma of “nerds” begins in elementary school so girls start to stray away from STEM even in the limited amount of programs there already are for computer science in earlier education years. This eventually results in the number of females in CS in universities–like mine–is so low along with the numbers of those who move onto the software development workforce.
- There are jobs out there like writing software for watering fields based on whether the sun is up or down or varying weather conditions. It reminded me a bit about how we used duck stimulator as an example to learn UML diagrams and had different actions performed for each duck.
- Career advancement is not always a straight path. People tend to switch into computer science as a major or switch into technology when they want a career change. I’d like to point out how the host of this episode took the opportunity to say Horton came from the funeral business to killing software bugs.
- You won’t always have to write code: there’s so much out there–you could have a passion for anything and do something tech-related in that setting.
The content has caused me to think more deeply about what I will do in technology, I mean of course I’m going with software development or software engineering but what is the overall goal throughout my career timeline going to be? What kinds of companies will I end up working for? What projects or passions will I follow along the way? Overall, I enjoyed the podcast with Horton as she discussed the ups and downs of being a female in technology and her experiences in the industry so far.
I don’t think I was there for the time when people would be kicked off the internet because someone needs to use the phone as discussed in the episode but I do experience times when my connection isn’t consistent. It really makes me sit back and think about how technology relies on constant power and a steady internet connection.
A major takeaway that I continue finding myself writing about is how we will always be learning something new in technology as things are always changing–as long as the power is on.
Imagine being several years into your role as a developer; you’ve had a long week, a big project to push tomorrow and suddenly… you’re stuck on something. And you’ve double-triple-quadruple checked to make sure everything is working by code review but you cannot put your finger on how it is not quite perfect. What’s wrong? Let’s find out.
This is the first course-related podcast I’ve listened to for a blog post and if this is one of the only podcasts you will listen to, I recommend this one.
Jonathan Cutrell started off the podcast by saying “If there’s one thing that makes developers self-conscious it’s probably their googling history–more specifically things that they google that they forgot how to do.”
People can talk about code for days but they do not talk about the toll of what a developer thinks of themself when they are stuck on a part of their code or need to rely on the internet for something. This honesty makes it easier for university students and entry-level developers to understand the pace they are learning at is their own and that not everyone is perfect at coding even after years of experience.
Something that changed the way I thought about this is how important it is to know the pattern or routine of a concept. Things Cutrell says great developers care about is how understanding patterns and principles transfers but not necessarily the actual code itself. “Great developers” focus on the overall concept instead of wasting time on the small details of a language.
Due to this thinking, I realized I never considered how a developer can be the best of the best in one language but if they had to convert it into another language, the translation would be a little different. The real life comparison to this would be if someone were speaking with broken English. This does not mean they are not smart in any way, it’s saying that they are focusing on the main idea instead of a small detail they are trying to get through. They use their time more efficiently by moving on to a big concept instead of worrying about the syntax that they can easily google.
Overall, I appreciate what this article brought up as I was expecting it to be about just googling things but it dug a little deeper and mentioned what a good developer should focus on.
Podcast Episode: https://spec.fm/podcasts/developer-tea/204292
In my software design course, I recently learned about how using design patterns helps you code better. I thought it would be a good review to go over the concepts this article introduces and potentially link it to things from class and maybe even add some things we did not get through during class.
The three categories Frederico Haag, a computer science engineering student at PoliMi, wrote about are creational patterns, structural patterns, and behavioral patterns.
Based on the design pattern I chose to work on for my individual assignment, I wanted to focus on the facade section–which is a structural pattern. The main take-away of the facade is how it “provides a simplified interface to a larger body of code.” I like how the name itself actually relates to the word facade’s definition: “an outward appearance that is maintained to conceal a less pleasant or creditable reality” (Dictionary.com). As a person who likes the aesthetic side of things, this seems like a convenient design pattern, especially if people who are not working on the code end up seeing it; it may be less overwhelming to some.
Another one of the options my class had for the same assignment above is for the decorator class–which is also a structural pattern. This “adds behavior to an object dynamically without affecting the behavior of other objects from the same class.” For some reason, when I imagine this concept, I think of a decorated cake. Since it is useful for adding the same behavior to many classes; it’s like when you add a spread-out layer of fondant or frosting to a cake, it could either cover the whole section(s) of cake or just some, but it doesn’t mess up the inside of the cake.
Overall, I found this content very useful to reiterate what I had learned and Haag incorporated visual UML diagram examples along with actual snippets of code to help us compare and contrast what he was showing. The content has not changed how I think about the subject because there is no arguing here, it just shows different ways people can structure their code overall. I do appreciate how Haag also listed “typical use cases” for some of them as it makes it easier to imagine.
As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.
Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.