Table of Contents
- Backup your database
- Check my code out of Github, or create a module directory
- Create a project info YAML file
- Create the necessary subdirectories
- Write the code to display your block
- Clear the caches
- Enable the module
- Place the block module
- See the custom block on your website
- The biggest problem I encountered
- The source code
In this tutorial I’ll demonstrate how to write a simple Drupal 8 “block module.” By this I mean that I’ll show you how to write a simple Drupal 8 module that will display output in a block. When you’re done you will have created a new block that you can place in one or more theme regions.
Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.
Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.
I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:
I don’t recall hearing of the words “reify” or “reification” in my OOP years, but that may be because I studied aerospace engineering in college, not computer science. Since learning FP I often see those words, so I thought I’d try to understand their meaning.
The short answer is that the main definition seems to be:
“Taking an abstract concept and making it concrete.”
For the longer answer, I found the following definitions and examples of reification.
I was just reminded of Rubber Duck Debugging. From this Wikipedia link, “The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.” For me, my rubber duck is Albert Einstein.
Every once in a while when something hits you, you really remember it; it stands out in your mind as an “Aha” moment. One of those moments for me was when I saw a particular “Model/View/Controller” (MVC) diagram, and the light bulb went on. This diagram made the MVC pattern very simple, and I’ve never forgotten it.
I’m always curious about how people think, and these days I’m most interested in how functional programmers think about programming problems. Along those lines I found a good blog post (tutorial) titled, “Thinking Functionally with Haskell”, and these are my notes from that post:
“No matter how slow you are writing clean code, you will always be slower if you make a mess.”
~ Bob Martin (via this tweet)
Scala is a great language in many ways. One great feature is that you can use it as a “Better Java” (i.e., as an OOP language), and you can also use it as a pure FP language. While some people prefer one extreme or the other (not unlike extremist Republicans and Democrats in the U.S.), I appreciate that this lets you find a “Middle Way” of using the best features of both approaches.
“Two steps are required to write a good piece of code. The first step is to get the algorithm right. The second step is to figure out which sorts of things (types) it works for.”
From the “Deriving a Generic Algorithm” chapter in the book, From Mathematics to Generic Programming.