Category Archives: Week 13

Law of Demeter: tell don’t ask

For this week, a topic that I chose to learn more about was the Law of Demeter. The Law of Demeter was chosen because it is one of the topics covered in our course syllabus and it is also a concept that I have not heard about before and so I was curious to learn more about it. To supplement my understanding of this concept I watched a youtube video about it and also looked at an article by hackernoon. I had chosen this video because it was short and concise and was uploaded by a channel catered towards teaching programming concepts. The summary of the video was that often in programming, cohesion is good and coupling is bad and the law of demeter is a design principle used to reduce coupling. Also the usage of the law demeter is implemented with some design pattern such as facade or adapter that performs some form of delegation to remove the need of chaining. The second source I used was an article on the Law of Demeter by hackernoon. I had used this second source because I wanted to see an example of this concept implemented in code; and also the code was implemented in java, which is language I was familiar with. The summary of this article regards the Law of Demeter as “Don’t talk to Strangers” rule and the article examples where Law of Demeter is implemented and violated.

In conjunction, these two sources helped me in understanding the Law of Demeter. In addition to the explanation of the Law of Demeter in the video source, I also enjoyed how the youtuber, Okravi, explains that the Law of Demeter is a design principle and that some people do not agree with it, and so he states that the Law of Demeter does not have to be strictly be followed and that you should just use the concept where it makes sense in code. From that statement, I thought that had related to many of my previous blog posts where I have listened to experience developers explain a topic; where they say that following a principle strictly is not realistic; and rather we should strive for using a concept when it makes sense in our code. Also reflecting on the Law of Demeter made me think more about the concepts of coupling and cohesion in my code; and also the many times where in our course the usage of chaining methods was acceptable; however after learning about the Law of Demeter, I can see that that code can be refactored.

Links to video and article below

https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

Blog #2: UML Diagrams

Fairly earlier in this semester we worked with Unified Modeling Language (UML) and Entity Relationship (ER) diagrams. These tools are both extremely useful in representing databases. I often find that the way these diagrams show databases without coding is similar to how pseudocode shows how a program or method works without explicitly coding. In this way, like pseudocode, these diagrams are perfect for putting together a project before actually programming it like brainstorming. For my final project this semester in a separate class, I had to make a database for an ice hockey program using SQL queries. Before I even started writing queries for that project, I started putting it together in an ER diagram without even thinking about it. This made the actual programming for that project ten times easier. For the purposes of this blog, I decided to dive deeper into studying UML and ER diagrams to try to learn even more about them. I found an awesome article about UML Class Diagrams at visual-paradigm.com that tried to be a tutorial on how they work. I will leave the link to it at the bottom. It backs up my claims that they diagram is used primarily for visualization of projects after, during, and most importantly before they are programmed. It also went over a ton of specifics and formatting for the diagrams that we went over in class this semester like the layout of the tables or boxes and the different arrows that showed relationships in the model database. It gets way more in depth than I plan on being in this blog post like when to use a plus sign instead of a minus sign for variables in the tables (for private and public variables). I definitely recommend checking it out yourself as it taught me a lot, not just now, but at the beginning of the semester itself. Similar to the situation with Docker for me, I found that it was supper awesome that I was able to see that learning these diagrams in class would prove useful in real life. When I used a diagram for my final project in my other class (which was not required), I knew that these were very important tools in the real world. For that reason, I am especially happy that it was one of the topics that we covered this semester.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Blog #1: Docker Platform

A large topic that we covered this semester has been Docker. For that reason, I decided to do a bit of outside research on what it does well and how to use it as best as possible. Most of the helpful information that I found for this topic came directly from Docker’s website in the Docker Overview section. I will put the link to that at the end of this post. The website claims that Docker is used mainly for enabling the user to separate their applications from their infrastructure so software can be delivered quickly. This definitely holds true with what we have learned in class and with what we have used Docker for specifically during this semester. It is a free platform that thrives off of helping users develop, ship, and run applications. Its biggest strength is that is shortens the time it takes to go from writing code to running it in a production. Docker containers are indubitably important because they allow many developers to edit and program locally while being able to share their work with others. Containers, to put it simply, are runnable images. Images are templates that have instructions to help build containers and are read-only. A lot of work for docker actually is done in command prompt applications like Git Bash or Terminal. For this class, I used Terminal because I have a MacBook. At first, when using Docker in this class, it was very unclear to me how it all functioned or what the point of using it was. After some time, I began to realize the importance of it as it made connecting programs easy and quick for me. It has come to my attention that the Computer Science department at Worcester State is actually trying to create an entire database for the cafeteria workers with the help of undergraduate students. This was very exciting for me to hear for many reasons. I always am appreciative when I know that what I am learning in school has real life implications and uses, and this motivated me to want to learn it even more. Not to mention, it might be a specific platform that I will need to use in my Capstone for my last semester here before graduating. This blog post has been an extra excuse to take some time to research Docker even more than before and dive deeper into learning what it is for/why we use it rather than simply how to use it. This is not to say that I would not have done more research on Docker outside of class in general (especially with the Capstone next semester), but more to say that this blog is in some way motivating me to get the research done and helping me understand the platform even more by allowing me to discuss my findings. I definitely recommend anyone wondering about Docker to read the information I studied before this blog post by using the link I will put at the bottom. Coming from the Docker website itself, I believe it is a great reference to learn about the free platform and extremely helpful when trying to discover how it works and why we use it.

https://docs.docker.com/get-started/overview/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

The Apprenticeship Pattern Expand Your Bandwidth is something that should be learned at the beginning of your career, even in schooling. This pattern is about learning the ability to learn a large amount of information about more than one subject at the same time. You must be able to retain the vast income of knowledge, you won’t have to do it for very long, but it can be overwhelming. Overcoming the overwhelming feeling and successfully learning much more information than you’re used to is the crux of this Apprenticeship Pattern. There comes a time when your focus must spread from your everyday work and onto new information.

This pattern coincides with that of Draw Your Own Map quite a bit. These two patterns are all about taking your future into your own hands. Expanding your bandwidth is a skill you have to learn to help your path become clear. If you want your map to expand then your knowledge too must expand. Sometimes when you need to take in a vast amount of information at one time it can be stressful and confusing. However, once you have retained this new information it unlocks new opportunities and new paths to be taken.

In my personal school experience I feel this skill was necessary at times, even at the very beginning of my pursuit of a Computer Science degree. I remember the knowledge jump between Intro to Programming and Data Structures was enormous, but not only larger, it moved faster too. My fellow students and I had to learn new information constantly all while applying our already new knowledge. It was that way for about the first third of the semester. We had such vast amounts of information coming in, but after that first third of the semester we had already learned most of what we would be doing. There was still more information to come of course, but it was more or less experimenting in more detail with things we had already done. We expanded our bandwidth at the beginning so that the rest of the semester we were prepared for a variety of projects. It was as if the flower had bloomed for us finally and our paths were much more open.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Wax On,Wax Off

The pattern “Sweep the Floor” talks about how as a new member of a development team you should take the jobs that people dislike and work on the things that are an annoyance. This strategy is something that will help a person to become a valued and respected member of the team that they have recently joined since they did something others felt was a pain. The pattern suggests that you take the leap that others are unwilling to because it will build your reputation among your colleagues. The pattern also talks about how when you start a job after college, that you are effectively starting from square one and the education you received only raises what people will expect of you. This pattern also talks about some negative impacts that may happen, which are that you might become the team’s gopher and be stuck doing the menial tasks that others do not wish to.
This pattern reminds me of my sports teams in high school because the younger and newer players would be stuck carrying the equipment, like basketballs/soccer balls, because they were still learning and were going to be the next generation of the team. I felt that this hierarchy was necessary and built character in many of my teammates and myself. I can see myself wanting to impress and help my future development team in the future, so I will apply this in my future job. I felt that it’s important that the pattern mentioned the possible downsides of this pattern which is being stuck as a floor sweeper. I respect people with more experience than me, but after some time has passed I will not allow myself to be stuck as a floor sweeper and I am not afraid to voice my thoughts and opinions on these matters. Trust is an important part of teamwork, so this is something that can easily help me and others to build that trust with their new team. This pattern didn’t change my thoughts on what I expected in the software development field because having the new workers do things that are a hassle or really low level things is common practice in every job in every field.

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

Breakable Toys

The pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye that I have chosen for this week is called “Breakable Toys”. It talks about being on a job that does not allow mistakes or failure, but without falling there is not room to learn or grow. How is one supposed to learn and fill in their gaps in knowledge if something needs to be right the first time. Simple solution is to create a “simple toys” on your own and play with them, fail with them and break them in order to fix them and learn from those mistakes, that will be unrelated to the project but an opportunity to learn and grow for it.

This pattern is something that I have used myself many times, what helped me a lot in this regard is also fact that I was going to school and was learning or “playing” with new programs and ideas all the time. Many people or managers, in my opinion do not understand how much learning or failing needs to happen before a good program will take shape, many times even just a working software, not perfect or good, is a major learning task for employees. To be able to do so safely and without repercussions from a work environment is a key in staying ahead in your career.

In my own experience I have done similar things described in this pattern and have even done so while at work, but only in thanks to a very understanding leader and mentor who was not afraid to let me take some time to familiarize myself with something new we were going to do. I am aware that not everybody has the same luck as I did and that is where this pattern is very much right. All people in our field should be able to play with the new software, new language and be able to just break it, to be able to later fix it and learn from the mistakes made, the only way that I can see the absolutely everybody can do it is on our own time, at home. It might not be something we will be paid for but it will let us develop decent skills and be familiar enough with a given concept to pass in the environment that does not allow failure.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Concrete Skills

The pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye that I have chosen for this week is called “Concrete Skills”. It talks about being a “newbie” in a workforce and looking for opportunities in the advanced teams that exists in computer science field. The pattern describes how not many companies and employers are willing to hire somebody fresh without years of experience and already developed skills. It also tell us how to try and convince the potential employer to “take a leap of faith” and higher you or somebody else by making sure that you have a set of skills that can be used to help the team out even if it is just manual work or automation of simpler tasks.

I believe that this pattern is somewhat correct but not completely. What I agree is that having the “concrete skills” will definitely help with finding a job and being better at it, but the flip side of that is that it all depends on what employer is looking for, certain skill will be very specialized and not everybody needs those, or they are obsolete to begin with and some new way of going about a task is more popular now. The pattern describes how those “filler” skills might just be enough to get people through the HR or certain managers and allow next step in the hiring process.

This pattern made me think about how the current workforce is a lot of smoke and screens to make people either think that a company X is more advanced than they actually are or how potential employees need to fill in the resume in order to just somewhat be considered for a position no matter that most of those supposed skills will never be used. All this is infuriating. From my personal experience I know that a lot of companies, half the time, don’t know what is posted for the job requirements or nobody on the team even has those skills and they are “required” simply because some other A-list company had them on their job posting.

Overall, in my opinion this is a very mixed feeling pattern for me. Yes, it is good to have a wide pallet of skills to help with the job search but at the same time a lot of the same jobs do not actually use those skills at all and they just become a filler to make the potential employee search easier.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Helpful Advice for Seeking Employment

Today’s chapter in Apprenticeship Patterns is “Concrete Skills”.

This pattern provides an overview to the idea of more specific skills developers should have as they start their careers.

I think that this pattern serves as a good introduction to this topic. This pattern seems especially relevant to where I am now as I will soon be looking for employment after graduation and this is a good general reminder of things that software development managers are looking for.

I like and agree with the idea of creating a project for demonstrating your knowledge of the skills that you have acquired. This is what my team has been doing for our work so far this semester on the UpdateGuest project and I, along with my teammates, think this helps to cement the knowledge gained when learning new tools and languages. This pattern serves as another good reminder that this is also something I want to do more of with my personal project and I particularly want to start moving away from using languages I already know to learning and improving my abilities in these “concrete skills” with new and different tools that I am more unfamiliar with. I specifically want to get better at some of the examples mentioned in this pattern including web design and JavaScript, along with Angular as these three things seem like important requirements for developers now.

Although I think this pattern provides helpful information, I do wish that this pattern was more specific and detailed. I believe this pattern could benefit from expanding upon the information it offers. I also think that it would benefit from including an example CV showing how these skills are listed and defined on a real document. After reading this “action” section, I am now curious as to what the most important skills are for a starting position in the DevOps field and if I already know any of these skills. Again, I think this section could benefit from suggestions as to where to go to look for these besides people you may know.

Altogether I did find this pattern helpful and a useful reminder of what the most important parts of a resume are for a software developer. This is true especially as I move on to creating and refining my own resume in preparation for getting my first job in the software development field.

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

Unleash Your Enthusiasm

This apprenticeship pattern is about how when starting an apprenticeship you need to use enthusiasm to help the team since it is the only thing you have over the more established and experienced members of the team. It starts out saying how most people starting out have a problem when they start out in their career, they try to hide their enthusiasm.  They do this because they are worried about looking foolish or sticking out from the group. Although it says that there are risks to unleashing their enthusiasm. Such as if the team isn’t welcome coming to new comers the team might mock you behind your back. It also says that if the team values competence more than learning it might not be a good thing to unleash your enthusiasm. It says that if the team seems like a good fit for it they should unleash their enthusiasm because their enthusiasm is one of their biggest strengths. It says that it is one of their biggest strengths because unleashing your  enthusiasm allows out of the box thinking and new ideas that more experienced people wouldn’t think of. Lastly, it says that unleashing your enthusiasm is the most important thing you can bring to the team.

I think that the pattern is very good advice. It tells you what unique skills you can bring that jaded decrepit old hands can’t. I also found it interesting how the pattern says that even though you don’t have experience in a certain way that can be a good thing.In addition I found it useful how it gives you examples of why this is helpful and also when not to do it.I found it thought provoking how it says that your inexperience can be a benefit.This apprenticeship pattern has given me confidence that even though I don’t have much professional experience I can still be a benefit to a team.There wasn’t really anything I disagreed with in this pattern. Overall I agree with it completely and think it something everyone should read when they start out in a new apprenticeship.

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

Share What You Learn

My work over the semester has required me to explain what I have learned to my teammates. My explanatory skills are not great, but I have been able to make do with the help of live examples. Chances are likely that I will need to do this continuously throughout the future. Since this is an important skill, I will need to practice my instructive capabilities. Luckily, the pattern “Share What You Learn” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses this problem.

“Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman you will need the ability to communicate effectively and bring other people up to speed quickly.”

“Share What You Learn” discusses the reasons for passing your knowledge to others. Ethically, it is wrong to only receive knowledge from the community and never give any in return. Being able to capably communicate your knowledge will make you a better developer. Teaching knowledge requires a deeper understanding of the knowledge than just using it. Also, other apprentices may appreciate an explanation from someone with the same level of abilities.

The pattern warns to be sure that the knowledge being shared, can be shared. It is common for companies to keep trade secrets, including software development information, so be careful.

There are a few ways listed for practicing “Share What You Learn.” One way is to write blogs about projects you are working on. The act of writing down your methods will make it easier to remember the details later. Another is to try writing a tutorial for a topic, presented in a way that you wished the topic had been presented to you. Lastly, imagine preparing for a workshop at a conference and how you would prepare for presenting your work.

I must agree with this pattern’s assertions, I believe being able to pass along knowledge quickly and clearly is an essential skill for software developers. As I have experienced this semester, I am not skilled with this pattern and I feel it has impacted our work to some degree. As such, I will need to practice “Share What You Learn” to be a better teammate and developer.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.