Starting the Docker service also starts the Docker Daemon. However, if you receive the “Cannot connect to the Docker daemon” error, the daemon may have failed to initiate.

Use the following command to run the daemon manually:

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

This week’s blog post I decided to research more about linting for non-inclusive language. The medium I selected is a blog post by Michael Bachand, an engineer at Airbnb. “Building an Inclusive Codebase” dives into the techniques engineers at Airbnb are taking to make their work environment more inclusive for everyone. In order to create a more inclusive platform, the development team must also be inclusive. To start, the team has increased the diversity in their teams to accommodate every demographic. Bachand emphasizes that building a diverse team will help empower both Airbnb’s hosts and guests. Inclusivity goes beyond forming a diverse team however.

The team at Airbnb discovered an issue with non-inclusive language in their codebase. After working with employees affected by these terms, the team presented a proposal to the Chief Technology Officer of Airbnb and got the approval to refactor the code to be more inclusive. Michael Bachand stresses that “acknowledgement and resourcing from the highest levels of management legitimized this effort”. The support from management and the CTO prioritizing the task produced a healthier working culture across all teams.

Airbnb’s development team broke down this problem into two key parts: preventing the use of this language and eliminating the existing language. One essential tool that was utilized was the woke linter which checked each pole request for non-inclusive terminology and suggested alternative terms to promote belonging. The team now had a proper tool to use, however, they didn’t send the tool to every developer immediately. The team took a unique approach by slowly distributing the tool to expert developers. These developers decided which directories the linter should access and which should be excluded.

Before our in-class activity on this topic, I never thought about how my sentences might unintentionally offend or upset someone. This topic has opened my eyes to how crucial having a linter tool is. Many of these non-inclusive terms sound offensive without the right context which is why every developer should utilize a linter of sort. Reflecting on the problem addressed by Airbnb, having the support from the CTO is reassuring to know that your work is valued by the company. I believe all companies should strive to create a sense of belonging in their work environment, no matter how big or small. I can confidently say that the information I learned today will stick with me for the rest of my career.

Blog Post: https://medium.com/airbnb-engineering/building-an-inclusive-codebase-bbaa2315e5b8

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When interactions require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are event-based user interfaces, shared cache, and comprehension framework—the range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and decreases the coupling between classes. Inversion of control helps make your code more readable because of the absence of some components. At the end of the day, I.O.C is a design pattern that is very useful for software development and lets us know when action needs to be taken when something happens in our system.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

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

Take 2

Well here we are, back again talking about clean code. I thought it would only be fair to introduce you to its evil counter part. Now that I really think about it, I really must be goo at these blogs because I am giving away the secret recipe to the perfect code. If you know how to write clean code BUT also know how to avoid bad patterns thats the ulntimate duo, nothing should stop you!

What is Anti-Pattern

it is how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design practices, and they are typically ineffective or obscure fixes. They can lead to issues such as technical debt, where suboptimal code must be addressed and corrected later.

1. Spaghetti Code:
   • Description: Code with little to no structure, making it difficult to follow.
   • Issues: Maintenance nightmare, challenging to add new functionality, and prone to breaking existing code.
2. Golden Hammer:
   • Description: Overreliance on a specific architectural pattern or tool.
   • Issues: May lead to performance issues, difficulty adapting to different problems or languages, and inhibits learning and exploration.
3. Boat Anchor:
   • Description: Leaving unnecessary or obsolete code in the codebase with the assumption that it might be needed later.
   • Issues: Causes confusion for developers, longer build times, and the risk of inadvertently activating obsolete code in production.

Why we might use it still

1. Prototyping or Rapid Development:

• In the early stages of prototyping or rapid development, the primary focus might be on quickly testing ideas or demonstrating concepts. In such cases, developers might use shortcuts that resemble anti-patterns to expedite the process. However, it’s crucial to revisit and refactor the code for production use.

Anti-pattern is a practice or solution that may seem like a good idea at first but, in reality, is counterproductive and can result in negative consequences for the software development process. It’s a term used to caution against common pitfalls and encourage developers to adopt best practices for creating maintainable, efficient, and effective code.

While there may be rare instances where the use of anti-patterns is justified, such as in prototyping, rapid development, or within legacy systems, it’s essential to recognize that intentional use of anti-patterns comes with inherent risks. These include technical debt, reduced code quality, and challenges in maintaining and scaling the software. I still encourage developers to prioritize clean code above all else.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Not too long ago, I learned about the “Agile” methodology for the first time. I learned all about how following “Agile” allows for code that is always functional and that can be built off of in a much more proactive way than that of code produced through the waterfall approach. What I did not learn as much about, however, is the impact that following an agile methodology has on the customers, the vendors, and the project manners, as many of the lessons I took part in were developer-focused.  

In order to learn more about the impact of the Agile methodology project members, other than developers, I did some research and came across a blog post titled: “8 Benefits of the Agile Methodology” by Erin Aldridge. This blog post takes the approach of describing the benefits of using an agile process through the perspectives of people who would otherwise not be working directly with the code. 

CUSTOMER BENEFITS:

The article identifies the way in which incremental delivery of a project often results in higher levels of customer satisfaction, as well as provides greater customer involvement and input on what they are looking to receive as a final product. This higher level of customer satisfaction is also paired with a higher return on investment for the customer.

VENDOR BENEFITS:

From the perspective of a vendor, it becomes much easier to ensure a high-quality product, or a product that satisfies the customer when a new increment of the product is available at the end of each sprint. Increased level of transparency on the progress being made on any given project also allows for a vendor to more effectively work with a small-sized team and communicate in meaningful ways with the customer. 

PROJECT MANAGER:

While working with “Agile”, developers are able to get right to working on a project, cutting out much of the uncertainty that may be created as a project manager attempts to figure out all the parameters for the project. Project managers are also able to better select tasks to be prioritized first, and will find it much easier to keep track of project progress through the points emphasized during each daily scrum meeting. 

From what I have discovered, using “Agile” seems to be better for every member of the development process compared to other methods like the “Waterfall” process. I have also learned through this research that implementation of the agile methodology is more simple than often thought and improves nearly every aspect of the work process (as mentioned through points above). To add to this, I also now have a better understanding of the role everyone plays as described by someone who actively uses “Agile” in a real workspace. In fact, I now believe that the agile process is easy enough to implement that I will very likely recommend its use in future projects that I take part in. 

Blog Referenced: 8 Benefits of the Agile Methodology – Project Management Academy Resources

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

In many of the previous classes that I have taken throughout my college process, I have been tasked with writing code. However, in nearly all of the assignments I have received so far, instructions only require the code to be working or at most want there to be comments to go along with said code. After reflecting on this fact, I began to think more about how there must be some sort of standards for writing code; some sort of quality control when it came to preparing code for use in a professional environment. This is where the practices of writing “clean code” come in.

Recently, I have read a blog post called: “Writing clean code: best practices and tips for developers” by René Cadenas, in which the author went on to outline several key points to follow when improving the readability and cleanliness of code. I chose to read this article in order to develop a better understanding of the topic covered in class, as well as to create a better understanding of how I can implement the use of clean code practices in future workspaces.  “Clean code” is defined here as “code that is not only functional but also easy to read, understand, and maintain”. The author also wrote about why clean code matters, claiming that it leads to improved collaboration between developers, and that implementing defining features of clean code, like meaningful naming conventions, proper documentation, and reusable code blocks that don’t require other developers to repeat efforts and redundancy, will all lead to a final product that follows the principles of writing “clean code”. Other topics of emphasis in the blog post were: consistency of code, clarity of comments, and efficiency of the code written.

After having read this blog, and through our classes in which we had our own lessons of writing clean code, I now understand why it is such an important aspect of writing code. After reading the article, I learned about how much of a difference refactoring code can actually make when it comes to the readability of code, which I didn’t consider throughout our in class discussions. After seeing examples of refactored code alongside the same code in its non-refactored form, it really convinced me to try harder to implement these practices in my own writing of code. Moving forward from this point, I want to put a lot more thought into how I write my code and whether other people are clearly able to understand it in the same way that I view it. After all that I’ve seen on the topic, I think the best way to go about this is through practicing more on implementing these “clean code” practices in my own work. I think it might even be a good idea to use a separate “clean code” guide to double check code I write in the future before submitting it. 

Blog Referenced: https://blog.elaniin.com/writing-clean-code-tips-for-developers/ 

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Tommorow, Not Today

As with many classes, topics, and projects I have been a part of for the last few years, I see a consistent pattern. The unwavering focus on what’s going on in the present and never connecting the dots on how something might benefit me in the future.

Code documentation is just one of the many examples I could come up with to further my point. Up until now, all my work has followed the motto of “me, myself, and I,” failing to see that in the future that won’t be the case. Eventually, everyone will find themselves a part of a team, and there is nothing worse than an amateur teammate. Let’s take a deeper look into code documentation and why it will eventually be an asset to not just you but also your future teammates.

Type of Code Documentation

Internal Code Documentation: Intended for developers inside the organization.

• Process Documentation: Provides high-level information like product requirements, roadmaps, notes, and reports.
• Developer Documentation: Provides detailed instructions for developers and staff for building, testing, deploying, or maintaining the software.

External Code Documentation: Intended for developers outside the organization who integrate with the product or need to understand its code.

• External Developer Documentation: Provides essential instructions for using source code, integrating with a product, and leveraging developer interfaces like APIs and CLIs.
• Enterprise Documentation: Furnishes information for IT staff involved in software deployment, covering hardware requirements, sizing, operational needs, and maintenance guidelines.
• Usage Documentation: Guides non-developer users on product utilization without relying on programmatic interfaces. Describes main functionalities within the product’s UI.
• Just-in-Time Documentation: Supports developers as needed, often in the form of knowledge base articles, FAQ pages, or blog posts, added in response to new features or requirements.

Low-Level or Inline Documentation: Resides within the source code and explains details of specific code parts in isolation, such as the purpose of certain functions and arguments.

High-Level Documentation: Describes the architecture, design principles, implementation guidelines, or other broader concerns.

Walkthrough Documentation: Describes flows, patterns, and other important parts of the codebase, especially for developers who need to contribute to the code.

Food for Thought

Documentation might seem straightforward, but there are some issues that must be considered whenever starting a new document.

• Knowing Your Audience: Depending on why/who you are writing your documentation for, you must consider their level of understanding when it comes to your subject.
• Updating Documentation: It is very easy to push changes to your software and forget to also push changes to documentation. This starts a cycle with co-workers where the documentation falls behind and becomes uncomprehensible.

Tommorow

Embracing comprehensive code documentation is not just a practice for today but an investment in our collective future. As we transition from individual contributors to collaborative team members, the value of clear, well-maintained documentation becomes vital to future projects.

Source – https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Similar to my last blog, I wanted to focus on how to implement certain aspects of Scrum in an effective way. While exploring articles related to sprint planning, I came across a crucial aspect not covered in our class, technical debt. The article “How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work” by Cate Lawrence, provides strategies for making sprint planning less overwhelming while also highlighting the importance of preventative measures for technical debt. In this blog, I will focus on the technical debt portion of the article. Technical debt is a term used to describe future complications, that are time and resource intensive, that arise from expediting development instead of properly completing the product. It is the tradeoff between immediate gains versus long term consequences.

The article provides three steps for incorporating technical debt into sprint planning. The steps are:

• Make technical debt visible

Recognizing potential issues and highlighting them for the team is important. Letting those issues accrue and not addressing them seemed like the opposite of the Scrum values. You should be adapting to unexpected issues or requests, not planning to have issues in the future.

• Determine the business impact of each debt item

I could see how it may be enticing to take shortcuts during a Sprint. Convincing the team or management to not take these shortcuts and to tackle these issues will only help development, but it may be hard to do. Instead of focusing on all the technical issues in front of them, highlighting how the debt will come calling in the future felt like the appropriate response.

•  Bring it to your sprint planning meeting

After visualizing the issues and showing why it would be best to deal with them now, including them in the next sprint plan is the final step.

Though not the main point of the article, it highlighted that technical debt was a neglected topic in sprint planning. I chose this article due to the steps, but also because it felt like something everyone should add to their Definition of Done. Even if everything “works” correctly with the code, knowing that there could be further problems due to the expedited nature of the sprint, the code should not be seen as done. It should not be ignored and should be addressed immediately or in the next sprint. Hopefully, these steps and the discussion on technical debt in the article will be helpful. In the future, I will try to address these types of issues using the steps, but also incorporate this into the team’s Definition of Done.

Link to the Article: https://stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

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

https://ourcodingclub.github.io/tutorials/etiquette/

Programming Etiquettes – 4 best practices

https://www.sqlstyle.guide/

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.