Following the Docker activities in class, I found docker-compose quite confusing. I decided to use that as an opportunity to look for some other resources that explains the concept briefly but detailed so I can understand the term well. I finally settled on this blog that gives a tutorial on docker-compose. I like the fact that all concepts have been covered and explained simply. I also see some terms that in found confusing during class activities defined and explained. I like how it starts by giving a walkthrough of docker in general and then introduces docker-compose so the connection is clear and as a reader, you would not get lost.

This blog talks about the fundamentals of docker. It explains docker-compose as a docker tool used to define and run multi container applications. It talks about the features of docker-compose, structure of a docker-compose file and explains some of necessary keywords found in the structure. It gives images of structure of docker-compose file and images on docker-compose and docker to differentiate them. Blog also explains some docker-compose commands.

I learned in this blog that you can start using docker-compose with docker files by defining your apps environment using a docker file, defining the services for your app so that they can run in an isolated environment and start the app by running docker-compose. Docker-compose can be added to a pre-existing project and to your workspace if you add a docker file.

Docker-compose files can work by applying multiple commands that are declared within a single .yml configuration file. The compose file consists of keywords that make up the structure such as services, ports, volumes, build, etc. In class, these keywords were not clear to me. However, in this blog I learned that version denotes the version of the Docker-compose which is usually the latest version. All containers created are defined in services and docker composes will create containers based on the name we provide under this section. Build specifies the location of the docker file and ports map the container’s port to the host machine. The image keyword allows to run a service using a pre-build image by specifying the image location. Understanding of these concepts really helped me in the recent homework assignment.

I also learned that the purpose of the build in docker-compose build is to get images ready to create containers but this will be skipped if a service is using a pre-built images. I always thought that docker compose up builds images and run containers but little did I know that it also forks containers directly if images are already built.

I hope others find this blog helpful especially those that are new or beginners to the term, as it will give an insight of the term and that will help guide you through working with docker.

https://www.educative.io/blog/docker-compose-tutorial

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

In keeping with my recent learning with java design patterns, I have been learning about the Factory Design Pattern. It is defined as a creational pattern by the Gang of Four and is very widely used because of the plethora of applications that it has. This seemed to be one of the best design patterns to learn as I saw a great many recommendations to do so in my research on design patterns. In the Factory Method Pattern article from Java T Point, the design pattern is made by, “[defining] an interface or abstract class for creating an object but [letting] the subclasses decide which class to instantiate.” In other words, if the client requires multiple similar behaviors, the Factory Design Pattern is used to choose the required subclass instance to complete the required behavior. The article outlines the key advantages to this design pattern, including the promotion of “loose-coupling” because of the lack of application specific classes into the code. It then gives a couple of examples for usage including a class not knowing what subclasses will be required. There is then a simple UML diagram which shows a small example of how an electricity bill may be calculated using the Factory Design Pattern. This example is then expanded upon. First, an abstract Plan class is created. It contains an abstract getRate method and a concrete calculateBill method. The subclasses show the real usefulness of the design pattern. There are 3 subclasses: DomesticPlan (with a rate of 3.50), CommercialPlan (with a rate of 7.50), and InstitutionalPlan (with a rate of 5.50). Each class implements the getRate method, which sets the Plan class’s rate variable to their respective rates. From here, a GetPlanFactory class is created which uses the Plan class and its subclasses to return a Plan object. The one method here is getPlan, which takes a string variable and has a set of if statements, each of which returns a different Plan subclass object depending on the string. Finally, the GenerateBill class is the one which the client interacts with. It asks the client the name of the plan needed, which the PlanFactory class uses to return an object of the one of the Plan subclasses. Then, units of electricity are taken from the client. The Plan subclass object then calls getRate to get the rate associated with the plan, and then calculateBill to tell the client the total charge for electricity usage. Although the explanation seems complicated, it is quite simple and clean in implementation, and extremely useful when one does not know which of a given set of behaviors will be required. I expect I can use this design pattern quite frequently in my personal, school-related, and professional coding. 

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

The pattern “practice practice practice” is what the title implies and focuses on one of the most important things in any kind of career. The idea that practice makes perfect has been apart of every job/hobby/club/etc. since the beginning of time. Since programming puts you in a situation where any mistake could ruin the entire project/work, you need to avoid mistakes at all costs. Practice allows for programmers to work on different things and see what works for both them and what ever they are working on. The pattern suggest that you solve an exercise multiple times over a few weeks from scratch and see how your solutions evolve and change overtime and use those in your future projects.
This pattern is something that I thought of when reading the breakable toys pattern since they have a similar aspect of taking things from work home and expanding your knowledge on things that could be used in projects. I felt like this would be something that I would need to do for most jobs in the field of computer science. I think one thing that I found interesting was how it suggests to use exercises in different books because it wasn’t something that I would have thought of to help practice on different aspects of coding. The pattern, similar to breakable toys, suggests to have fun with it and not worry about things like deadlines, production issues and so on cause it allows you to expand on what you learned and see what works and what doesn’t. I felt like this pattern had a lot that I wish I knew about when I began computer science classes because it would have made my learning experience easier and more enjoyable.
I will use this in my professional career since it seems to be something that would benefit me and help me to be a better developer and computer scientist. The idea of using different computer science books on different topics and using the exercise in the book were a good idea that I will use in my career as well. While old books may have the fundamentals of coding, it is important to get newer books focused more on the languages that are being used since they will have a good understanding of how to use the language to the best of its ability.

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.

“Use the Source” is a pattern from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern focuses on the need for reading code written by other developers. Some good sources of code to examine are open source projects. By examining source code, a programmer can see what their bad habits are and adopt new, better habits. Another benefit from code reading is learning new algorithms to solve different kinds of problems. Expanding one’s collection of code solutions allows a programmer to be flexible and able to solve more problems.

I found this pattern particularly interesting. Since programmers are constantly required to work with other’s code, it is imperative that they learn to read code efficiently with practice. I do not have much experience with this myself and this pattern has made clear how important reviewing other’s code is. Regardless of what career I pursue after graduation, it will be important to read code effectively. I will need to start looking into some open source projects so I can improve my skills. Now I just need to find some projects that I contribute to and am interested in.

“Use the Source” suggests contributing to open source projects for software you already use. This is very helpful advice to me; I use a lot open source software.

• Atom: text editor
• Eclipse: IDE
• Insomnia: REST client
• GIMP: image editor
• Several different game system emulators

I briefly examined some of GIMP’s source code. GIMP has a label on issues for newcomers, allowing for quick access to simpler issues.  After reading through some of the code, I realized that it would take a great deal of time to get an idea of the project architecture.

I looked at this issue, (https://gitlab.gnome.org/GNOME/gimp/issues/4128), and thought it seemed simple enough problem to start with. While the problem seemed simple, I could not navigate the repository and locate where the problem may be. GIMP is significantly more complex than any project I have worked on before. Ultimately, I was not able to make any headway on the issue. I was, however, able to read through portions of the code and begin to see some of the structure behind the it. Though I did not find what I was looking for, I did get a basic feel of the code’s flow.

As stated in Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, developers read far more code than they write. With that being the case, “Use the Source” is an excellent way to grow your code reading skills.

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.

The Dig Deeper pattern is all about knowledge and gaining more of it. More specifically, this pattern is about taking something new that you have learned or are currently learning and teaching yourself about that subject’s roots. It’s not enough to know how to use the subject matter to solve your specific issue, you need to know that subjects use as a whole to gain knowledge of its context. This pattern is about understanding how a system works as a whole and not just the part you are working on. This deeper knowledge allows you to understand your work more concisely based on the context of it as a whole, which will help you understand your specific issue even more.

When I first started reading on this pattern it felt like a very blunt lecture. It felt as though I was being told to learn everything to its fullest and if I do not then I will be a less desirable individual for hire. However, as I read on I realized it was not about having total knowledge of EVERYTHING, that would be overwhelming and nearly impossible. I began to understand that it was about delving your knowledge into specific things, subjects that you are currently working on. If you are working on a specific issue and find the solution, it’s not about knowing every way to solve the problem, but to know in detail the workings of your solution.

This pattern further enforced my idea that you can do anything, learn anything if you put your mind to it. If there’s something I really want to excel at, deepening my knowledge can only help me achieve my goal. Being able to fully express my knowledge on the specific things I have worked on, though maybe few, is far greater than a larger quantity of surface knowledge. It reminds me of using MongoDb for the first time in our libre food pantry project. It’s all good and well to set up a database and query and get the results you want. However, it’s much more important to understand how the database functions beyond my own entries and data types I’m working with. In furthering my knowledge I was able to communicate my understanding into the other areas of the project including tying the database to a Java REST API. I fully agree with the ideologies of this apprenticeship pattern, dig deeper into your knowledge and it can only benefit you.

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

I’m promoting you from Senior Engineer to Lead Engineer. The pay is the same but people will disrespect you less.

—Dilbert’s Pointy-Haired Boss

“Use your Title” is a very effective pattern for those who feel like the title they have is everything in life. We all have our own goals in life, and we approach differently to achieve them. For some, a software engineer position is all they have wanted to achieve in life, and there are others who would not feel accomplished until they become seniors or leaders in the industry. On the other hand, it happens to have an unimpressive title, even though you have given more authority in your position than your title or job description says. In this case, people get discouraged and lose hopes that one day they would get what they deserve.

In my opinion, we should “Use our Title” in a way that benefits us professionally. Titles are only made to feed our egos. What is more important is that we should never stop learning or stop searching for better opportunities that would complete us professionally. Let’s think of it as climbing mountains. The second highest mountain in the world is K2. If a person’s goal a year ago was to climb that mountain, he/she would feel accomplished when he/she gets there, but then he/she would feel the need of having another goal to achieve and would end up climbing Mount Everest. This tells us that even when we get to have the title we always dreamed of in the industry, there’s more we can achieve.

In this pattern, I found interesting the part that suggests writing down a long and descriptive version of our job title. I think this would help us reflect on what we do at our workplace, if the title matches with the authority we have given, and maybe find the need to update the title with superiors’ permission. I, myself am going to try and see what I find out when it comes time to update it.
As a conclusion, make sure your skill level matches your job description and title, and no matter how far you go with titles, remind yourself that your apprenticeship is not over.

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

This apprenticeship pattern caught my eye for discussing the Peter Principle, which states that an individual will only be promoted if they do well in a position. The result of this is an organization full of people who have been promoted to positions in which they no longer perform well, creating an incompetent organization.

Reflecting as you work is meant to prevent this. The idea is simple enough: constantly probe your work process and ask yourself whether it is ideal. Take note of the positive aspects, but also the negative aspects so that they can be fixed.

The pattern suggests focusing on increasing skill rather than experience. This is a subtle but important distinction, because spending a lot of time doing a single thing wrong is still a lot of experience, but it’s not necessarily useful as a professional.

In certain parts of our industry,
it is quite easy to repeat the same year of experience 10 times without making significant progress in your abilities.

Apprenticeship Patterns

I certainly reflect on my work when it’s done, but I tend to focus on the work itself rather than the process. I’ve spent countless hours before a project commit making sure every line of code is perfect and the necessary documentation is in place. This led to nice code and happy professors or managers, but it didn’t help my work process. It was doing more of the same; obtaining a good result, but without improvement in workflow.

Figuring out how work processes connect is a helpful practice to identify counterproductive habits. We tend to take the path of least resistance and easily fall into a workflow that we assume works best for us, but this may be an illusion due to our limited scope of experience. We know redundancy can be reduced within a project’s architecture. We strive for this. Why then, would we not give our work process the same courtesy?

This pattern is a great example of software development’s being more than simply writing code. And by writing code, I mean using tests, DevOps, OOP, and anything else that can be considered a software engineering practice. As the entire book aims to prove, software development is an organic, human process. Moving from a software apprentice, to journeyman, to master requires understanding your own flaws, not just the flaws in your product.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.