Category Archives: Programming

Tweaking My Blog Accessibility

Accessibility is something which is within my reach. It just took me some years to use it properly.

If you are in a hurry, just go to the Accessibility Tips. If you have more time, you can start with the next paragraph. Next.

Sleight of thought

For my blog I use a default WordPress theme. I try to compensate this standard look and feel with humour. Am I kidding? No.

My first blog post was a struggle with looks. I did not like header 1. The font was too big. I just used bold to make the headers. That looked just right.

During an online computer course I had my first encounter with a screen reader. Users with bad or no view can use this program to read a web page aloud.

My trick for nice headers using bold was backfiring: a screen reader would not recognise them as headers. I really needed some header tag. So I ended up with header 6. This looked good, but it was still not right.

Just a little more

After tensome blogs I started to use the alternative text of the image.

In the attachment details of the pciture the location of the Alt text has been marked!!
In the past this was primarily used for people with slow internet connection. This way they still could get an impression of the webpage, when the text was shown.

In another online course I learned that the screen reader could use this for the communication. Then I read a tweet about using a proper description. So “another mindmap” was not really helpful.

Now I had to compress the information in a picture in a few sentences. That was really tricky, if some graph was involved.
A line graph is shown with three different colours: orange for beginners, green for proficient, and blue for expert. There is a green circle "Skill IQ 135" in the green line, which is connectd to a vertical line with "40th percentile" at the foot!"
The Alt text is as follows:
“A line graph is shown with three different colours: orange for beginners, green for proficient, and blue for expert. There is a green circle “Skill IQ 135” in the green line, which is connected to a vertical line with “40th percentile” at the foot!”

Maybe you noticed the exclamation mark or ! at the end of the text. This is a trick I learned later one: the screen reader reads this text differently aloud.

I even made a blog post with a few screen reader tricks. In this particular post a screen reader user has a big advantage over a user using a normal view.

More exploration from my side

The trick with header 6 was not right. I just knew. A lot of people start counting from 1, programmers from 0. But 6 is not the right exception.

It was a matter of months that I read about a confused screen reader. So I better start from header 1. Which was not my big favourite.

On Twitter I saw a tweet of a user with a bad view complaining about bad contrast. Within minutes another blogger reacted by adjusting his website.

My turn

I did quick check of my blog. It was all black characters on a white background. Then I noticed that my quotes were vague.

Now I had to find a way to change my headers and quotes. Time to explore the Content Management System or software to maintain my blog. Mine is called WordPress.

I first focused on the desired look of my header. I opened my word processor for note taking. My goal was to have my header 1 to look like header 6.

There was a nice tool in my browser: Dev Tools or Developer Tools. In my browser on my Windows machine I pressed F12, scrolled down to a header, selected the element, and saw the properties.

After the selection of header 6 in the upper window the properties of this element are shown in the right bottom window!

I did the same sequence for the quote. In HTML it is called blockquote. Fine with me.

The colour was grayish. I started to play with all kinds of colour codes. Until I realised that “black” was also good description for a font colour.

Dev Tools allowed me to experiment with the properties of the block quote without an intimidating program.

The color of the bloack quote has temporarily been changed to black!

Easy does it.

Now I had two pieces of code. Somewhere I had to fit them in. I started touring the CMS or Content Management System and found Additional CSS using the following path
Dashboard => Appearance => Customize => Additional CSS.

CSS stands for Cascading Style Sheets. Suppose I change the look of header 1 at 1 place. It will affect the look of all headers 1 in my whole blog. Cascading is cool.

I was too early for claiming my victory. Header 1 did not change in the visual editor. I did a preview and it looked right. Okay, found something.

In the left window Header 1 is shown in the Visual Eidotr, in the right window header 1 is shown in the preview!

At the end I had changed all headers 6 to headers 1.
So I only had to modify all the headers of my remaining blog posts. Great. Extra work.

The change of colour in the block quote went smoothly. But I was not pleased with the vertical alignment of the quote. It was too close to the left margin.

On the web I discovered that margin of an object was used to place a rectangle around the quote. Another search led to padding. If I could pad the text in the quote, then it would shift to the right. Left padding was enough.

Additional Css contains: "blockquote { 	color: black; 	padding-left: 5%; }  h1 {     font-size: 16px;     line-height: 1.5; } "!

Because I had only used block quotes for quotes, all quotes in my blog were automatically modified.

Accessibility tips

  • Use header to mark headers instead of making them bold.
  • Add an alternative text ending with an exclamation mark to all pictures.
  • Make the contrast of the colours of the text and background bigger instead of using some gray colour on a white background.
  • Use Additional CSS in WordPress, if you are still not pleased with the look of the elements on the page.
  • Look for other ideas on the Global Accessibility Awareness Day website. For the record it is the third Thursday of May every year.GAAD almost encircled by a powercard attached to a keyboard!

Ending notes

  • I know that there are enough readers willing to check the accessibility of my blog. The status of accessibility on my blog is in progress.
  • At the moment of publishing this post there are still words in bold who look like headers in my first blog posts. There are still pictures without an alternative text and/ or exclamation mark.
  • I would not be surprised that there is still work to be done after all these updates.

Struggling to become a DevOps engineer

Sometimes when I am cooking, a bored kid asks:
“How can I help?”
My answer is:
“You can cut the vegetables.” Or
“You can stir in the pan.”

When my kids were smaller, they loved to make pizza. And even small hands are handy for peeling off the brown layers of an onion.

Pair programming

The Test column was empty for a few days and I had finished all preparations for the items in progress. Was there a way that I as a tester could help the DevOps engineers?

“We can do pair programming.”
I was all ears and eyes. So I joined a programmer while he was coding. Once in a while he said his thoughts aloud.

“Okay, now it is your turn.”
I looked at the DevOps engineer expectantly:
“What do I have to do?”
“Programming”
“I mean: what must I program?”

A short dialogue followed. My knowledge of the development environment was almost zero and I did not know everything about Java.
“You better take a course at Pluralsight.”

Pluralsight and Java

In this company every DevOps engineer and the tester (that’s me) had access to Pluralsight. Courtesy of the employer. Pluralsight is an online course platform with a massive load of courses.

“There is a test to determine how good you are.”
Sure no problem.

A line graph is shown with three different colours: orange for beginners, green for proficient, and blue for expert. There is a green circle "Skill IQ 135" in the green line, which is connectd to a vertical line with "40th percentile" at the foot!"

A lot of readers might think:
“Wow, I would hire Mindful Tester.”
Sorry girls and guys. Up to 40% of all people got this level. This basically means that 2 out of 5 people knew as much about Java as me. Not enough to make complex changes.

Now Pluralsight had another nice feature called learning path. So I dutifully cruised through the courses. I had the advantage of two screens, so I could play the course on 1 screen and program on the other 1.

I had some doubts about the courses. It was like a typing course. Just enter the text and you have a working program. Tada.

Another doubt was the absence of Test Driven Development. I shared my concern with a bright DevOps engineer. He reassured me:
“First focus on the language, then the rest will come.”

The same engineer noted the lack of challenge, so he referred me to project Euler. This free online platform had mathematical / programming problems. Afterwards he reviewed my Java code, which I really appreciated.

Java is great, but my team used more tools to develop programs. So I followed courses on Spring and Maven.

At the end of the course I could get some certificate. With no real practice I had some knowledge. On the other hand my experienced DevOps engineers loved Pluralsight. They set the video speed to double speed and picked up their nuggets of knowledge.

HTML, CSS, and JavaScript

“I noticed that you focused on layout.” my scrum master said.
“We need someone who can design good interfaces. Maybe you should focus on the front-end.”

In this company the front-end was a website. So I had to study HTML or HyperText Markup Language, the basic programming language of web pages. I was familiar with HTML. <b> hello </b> is shown as hello. b is short for bold.

I picked a Pluralsight course for advanced web development. This was both horrifying and clarifying.

So I should have basic JavaScript and CSS knowledge. I picked a course with JavaScript: CSS was needed. I switched to CSS. Only HTML was needed. Phew.

What is CSS or Cascading Style Sheets? In my own words it is a way to style a website in s consistent style. E.g. all the buttons look alike and the web page can respond to different screen sizes.

I followed two courses of CSS. They were practical, so I was able to modify the look and feel of a website without changing the functionality.

Next stop on Pluralsight was JavaScript. In my own words this language is used by browsers on the computers or mobile phone of the users. This programming language basically reduces the traffic between the front-end (e,g, website) and the back-end, where the important things happen like handling a payment.

I was lucky again. There were some basic courses which gave me some practice with JavaScript.

If I look at Pluralsight there are some good courses, but it took time to find them.

Edx.org

The biggest disadvantage of Pluralsight was no examination. My scrum master found an interesting alternative, edx.org.

You could call it freemium. The course and examination are free, but you have to pay a premium for the certificate.
Freemium is “free premium” without ” pre”.

I picked HTML5. The course was for beginners. But I was really happy with all the Pluralsight knowledge obtained. The course gave me a good insight in HTML5, but it also showed its limitations.

Next certificate was CSS Basics. Again I had an advantage and obtained enough points for a certificate.

ReactJS should be possible with my basic knowledge of JavaScript. In my own words ReactJS is a language, which can better interact with users than HTML5. The course was tough and I dropped out.

Edx.org and Pluralsight

Edx.org had the same choice problems as Pluralsight. I had to follow course parts to determine whether there was a click.

A major difference is, that Edx.org courses are time bound. After a deadline the course is closed and only accessible for old students of this particular course.

Edx.org has a slight advantage that it offers up-to-date information. Pluralsight has some old courses. For a Maven course this is tricky. Old versions as shown in the video cannot be used.

Another deadline disadvantage of edx.org is that timing is personal. Several courses acquire 2 hours a week. For someone new to coding this number is too low. Sometimes one block of 2 hours would take me 40 hours. There is also a deadline for a certificate. My advice is first to get the required numbers of points and then buy the certificate.

Once I bought a discounted certificate before getting the required points. Let me write it was not my best investment. There are limitations to be aware of.

Security, privacy, and usability

A DevOps engineer does more things than programming. So I learned about website security, privacy laws, and usability.

In the meantime I acquired some DevOps skills like looking in and understanding log files.

Status update

In April 2018 I got the disturbing news, that I was fired.
No bingo for me.

In case you want to know what I am doing right now.

Thanks for reading. I really appreciate it. Cheers.

Other online courses

This year Trish Koo asked for some online programming courses In the answers there are some online platforms I will try the next time.

Being Sidetracked – Part 5

Just a few sections to end this blog post serie.

Just store it somewhere safe

Now I had a few productive days. I could easily do Test Driven Development with the help of the junior DevOps engineer. But I left out one important step in the development: the use of the version control system.

Looking at the numbers I think that Windows 10 is better than Windows 8.

One of the advantages of version numbers is that I know which platform the user used. And which version I have to use to pinpoint a problem in production. Versions are great for code.

Writing code is like making a story for a movie. If I made an error, then I reverted the change using Undo. Most of the time several people are involved for making the same movie story. There are a lot of people willing to pay 8 $ for a good movie. Coming soon to this cinema

Let’s take an imaginary superhero movie. Pete knows a lot of action scenes. After a while he describes a scene to the other crew members:
“And then she flies in the air.”
“Sorry Pete, but Lightning Buzzword Angel cannot fly.”

“But she is called Angel and angels can fly.”
“You’ve got a point, Pete. But not every woman called Angel can fly.”
“So I have to rewrite the whole scene.””
“Sorry dude.”
“It took me weeks to figure out this scene.”
“It is great, but we have to stick to the character.”

“So you just have to start from version 0.3 of the Supermarket Fight Scene.”
“But I also changed the First Car Ride Scene and the Milkshake Scene because of the bruises made by Oval Owl.”
“Wait, you say bruises.”
“Yep.”
“But then I have to rewrite my scene.” Amy remarks.
“And I the Milkshake Scene.”, another writer joins in.

Making a story for a movie is like writing code. If a programmer or DevOps engineer changes a method or function, then this can have severe consequences for the code. The trick to detect faulty code as early as possible. There’s absolutely nothing wrong with that.

Using Test Driven Development or TDD in a proper way a DevOps engineer knows that the added code is right.
Using a version control system she or he can merge the added code with the code in the repository. The result of all unit tests for this file is an early indicator for the quality.
Then the integration tests would be added, merged, and executed.

Now comes the most interesting part. If a release was made in this particular company, all unit tests and integration tests for the whole code were executed. All the tests from previous TDD or Red Green Refactor cycles were reused again. Of course some tests would fail, but the DevOps engineer would set things right. This could be the code or the test or both. And yes, this could lead to refactoring or restructuring code with an eye for maintenance.

After a few days of TDD a new file could be checked and processed in case of positive checks.

Just me and the code

During the coding the DevOps engineer mentioned the Boy Scout’s Rule. Now we were not exactly hiking. Not especially with a flatscreen attached to a laptop. The rule basically states that I should leave the place cleaner than when I came. If I found some rubbish, then I would have to put it into a bin.

In case of software it is all about refactoring and adding missing tests. And that was the case. Missing tests could be considered as technical debt. Yes, tests are technical.

There were still some unit tests missing for other input files. And then old patterns emerged again. I started to write Gherkin files and the DevOps engineer was making them operational. After a few days he started to work on a high prio task and I was still fabricating unplugged unit tests. Then I had to turn my attention to a high prio work item. I put all the unit tests in the version control system and almost forgot them.

Just plug and test

“This takes a few weeks.”
This was the initial thought from my scrum master after the request to plug in the remaining unit tests.

Okay, rhyme after me:
I was high
on supply.

There was one simple way to change his view. I put in the whole file with unit tests and the tests were not executable. So I cut a few times until I had only one simple test left over. It was still not usable.

I needed a default input file. My scrum master agreed:
“It takes some time, but it is worthwhile.”
I slowly assembled a file over a few thousands bytes character by character using an ASCII editor. This took a big chunk of one business day. Then I could code to run my first unit test. And I got a successful test, Green.

I slowly added the other unit tests. I was quite pleased with myself until I had a failing test. Red. This must have been a programming error. I checked the knowledge management system. I was right. Next result of the same test was again Red. Of course, because I did not change it a bit. Pun intended.

I slowed down to a crawl. According to the knowledge management I was right. This time I checked the value character by character. Hmm, time for a chat with the Product Owner.

He listened to my story and told me, that my test was right. So I updated the Knowledge Management System. At last a succeeding test. Green.

This happened a few more times.

That’s it?

This serie described my experiences with Test Driven Development or TDD. For me it was often difficult to stick to Red Green Refactor.  I made a lot of errors on my way. These things can happen. Even for experienced testers there are a lot of chances of being sidetracked.

Being Sidetracked – Part 4

Some readers might have noticed that Gherkin is used for unit tests. And this might be strange or unsettling. For me it was normal. In this company the DevOps engineers worked that way. It worked, so as a tester I had to put in more effort to find bugs. Sure no problem.

Me programming

My first action was to write a test to check a business rule for a valid observation date. While I was typing, the Integrated Development Environment aka IDE suggested several options like a search engine like Google. But observation date was not known. So this sentence was highlighted in red. Syntax highlighting is also handy in programming. I don’t mind that at all.

With the help of the DevOps engineer I wrote code in Java, so the IDE could use observation date in Gherkin. The code could be executed, but the test failed. Hey that was bad.

“Now I write the code.” was my next thought.
Of course there was no code, so the test should fail. Definitely Red.
This would be fun.

I had to program in Java and I remembered that the junior DevOps engineer had some useful shortcuts. I looked in the IDE and found the option in a sub menu to add a method. I gave it a name and – yes – I got an empty method in the right class. Now I had to fill in the blanks.

Me writing Gherkin

Months earlier I had written several Gherkin unit tests in the knowledge management system. There were two things wrong with this approach. The tests were not used, so I was high on supply. In plain English I had made something which was not used. On a scale of time it was a waste of time.

The other thing was that it had a web interface. The syntax highlighting did not work. I could make things bold and indent texts, but that slowed me down too much.
The result, the code, was not easily readable.

The dates were in the following format DDMMYYYY. This is programmer s’ language for Day in 2 numbers, followed by Month in 2 numbers, and finished with Year in 4 numbers.
So April 1st 2001 would be written down like 01042001. 01 is the first day of month number 04, which is April. 2001 is of course the year. It is easy to pick good dates like

  • 01042001 (first day of the month),
  • 31032013 (last day of the month), and
  • 29022000 (leap day).

I picked some wrong dates on more rational grounds:

  • 07142011 (for the Americans July 14th 2011),
  • 20132007 (20th day of the 13th month), and
  • 1jan1998 (January 1st 1998 in a hydrated date format.).

After writing date tests for one date field I noticed a pattern. I would check on all these dates again for other dates like expiration date. I thought I was smart. I just copied all the observation date tests and replaced ‘observation date’ by ‘expiration date’. I even copied the tests to a special text file, so I could save time. But I was wrong!
Please read on.

Me at the keyboard again

So I was programming unit tests and on my side was a junior DevOps engineer assisting me. I could finally write a test in Gherkin. In a separate window I opened the knowledge management system. I picked the first right date 01042001.
“Why do you pick this date?”, my personal DevOps engineer informed.
“I want to be sure that the right date is accepted.”
A nod followed by:
“We use Joda-time for that.”

I heard: “Yoda time”
It was not possible for me to link a lightsaber wielding big pointed eared green creature with programming.
“Joda-Time checks on valid dates, so you do not have to test them.”
Java 7 was not safe enough for dates and some programmers made Joda-Time. That saved me a lot of time.

So I only had to test on the wrong dates. Easy. I added tests, which succeeded. Green.

There was a `but` coming up.
“You can skip that date.”, while the DevOps engineer referred to ‘1jan1998’.
“Characters are not allowed in the date. ”

The next morning the DevOps engineer showed me a neat table:

Given the file has observation date <date>
When the file is read
Then the file will not be processed


Examples:
| date     |
| 07142011 |
| 20132007 |

He had improved the test code considerably. Refactor. I forgot to use DRY, Don’t Repeat Yourself.

My scrum master said that it was important to know how to program. This way I could structure my tests in a good way.
But the worst was still to come.

To be continued.

Being Sidetracked – Part 3

“At the moment I am writing a serie of blog posts about Test Driven Development.”
I looked to the recruiter. “You can understand it.”
I moved my view to the manager: “You can also understand it.”

Sticky note: let’s stick to the DevOps engineer.

Vegetable As a Service

The DevOps engineer wrote the unit test in Gherkin. The main advantage is that this language is easy to read. Have a try.
Given the version number is 15
When the file is read
Then the file will be processed

It is also easy to write. This example is in English, but it is also possible to use plain Dutch.
Gegeven een versienummer is 15
Als de file wordt gelezen
Dan wordt de file verwerkt

This is easy for people in Dutch companies. Nothing is lost in translation. It is easy to digest. No mindreading skills are needed.
The tool Cucumber provides a way to translate these sentences to a programming language like Java. A programmer has to code, how the sentences are translated.

When this little story is used by the computer, Java is used to execute this test. Yes, it is time for another cup of coffee. Which is the symbol of this language.

There are of course some people, who want to add some details to it. And yes, this is necessary.
Feature:
As an administrator I only want to process the right file list_20180525.txt, so that marketing managers can still process the data and generate reliable reports.

Background: file A

Scenario: 15 right version number
Given file A has version number 15
When file A is read
Then the file will be processed

Scenario: 16 wrong version number
Given file A has version number 16
When file A is read
Then the file will not be processed

All the text is put in 1 file, so all tests are nicely organised. A very important detail is, that file A is a complete valid file. This takes some time and some byte shuffling, but it is worthwhile.
So after 2 cycles of Red Green Refactor two scenarios were added in a feature file. These scenarios could be executed individually or in a group.

Then the cycle continued. The latest test was used frequently to assure, that the code was modified in the right way. The previous tests were used to assure, that the quality was the same. This led to a massive set of tests.

What’s next?

The DevOps engineer looked for the next feature to program. I saw an impressive table of valid values and validation rules.
“Do we have to test all this?”
“No”, he answered.
I could not believe my ears. There were so many places where things could go wrong.
“We will only test things, which can cause problems in our software. [The postman] will check the data.”

I visualised the data flow in my mind. There was a sender, which gave a file to the postman. This program would check every byte of the file. After a successful check the postman would deliver the
file to the receiver or the program under development. In the past I heard, that sometimes some things were not properly checked by the postman. With the speed of computers today extra checks can be done very fast.

The DevOps engineer continued:
“If data can cause problems in the software, these are checked.”
Version number is a good one. And of course begin date and end date of a period are also important.

Another cycle to start

This looked so easy.
It was like the junior DevOps engineer had some mindreading skills.
“Now you try.”
I was silent for a moment.
I repositioned myself after the keyboard and the mouse.
Pair programming. The real stuff.

Okay, let me start.

Read mindfultester[dot]com
My answer in a job interview

To be continued

Being Sidetracked – Part 2

A few weeks ago I told my wife about the picture for this blog post serie. “There is a red light. And a green light. The rest of the picture is fuzzy.” It was about “Red Green Refactor”.

“You should [tidy up with known product name] the picture.”, she suggested.
I liked the fuzziness. This was about Refactor.

Second cycle

We had just finished the first cycle.
The DevOps engineer wrote another test. Ready for the next modification.
O yeah. Test Driven Development.

Let me sanitise me this example. This means so much like “all confidential information is changed”. On purpose. Everybody happy?

A file can only be processed, if the version number is 15, 20, or 31. After the first cycle every version number was accepted. The first test was:
“Is 15 the right version number?”
“Yes”
But this would lead to some bad side effects:
“Is 16 the right version number?”
“Yes”
Or worse:
“Would you please bring me a cup of coffee?”
“Yes”
What about
“Would you please transfer 1 Million Euro to my bank account?”
[Upset face]
[Whispering] “You are supposed to say: “Yes”.”.

Okay, back to the real example.
The first test was to determine whether 15 was a right version number.
The DevOps engineer added a second test to determine whether 16 was a wrong version number. He performed the last test and 16 was a right version number. This was wrong: a failing test. Red.

The DevOps looked at the invalid value and added a single condition to the code. If the version number is equal to 15, then return “Yes”. Otherwise return “No”. The second test was executed again: this time 16 was a wrong version number. This was right: a succeeding test. Green.

The code was very simple, so no refactoring was necessary. Refactor.

Then the DevOps engineer executed all or both tests and they were both correct. The second cycle was over.

While blogging, I realized old patterns of thinking were still present in my head. Let me answer a few questions.
Question 1: This code is so simple. Why do you need to write all the tests?
Answer 1: During every step the DevOps engineer can use the written tests to determine, whether the code is still good. This is especially handy for complex code. Failed unit tests can point to where things go wrong.

Question 2: why did the DevOps engineer not add a second test for valid version number 20 or 31?
Answer 2: it would not lead to failing test. In other words the code would not have to be modified because of this test. At that particular moment he would have written a redundant test. That is a waste of time.

Question 3: Do all these tests take a lot of time to execute?
Answer 3: No. The tests are unit tests and fast enough to execute. The hardware has been improved considerably, so these tests are executed within a fraction of second.

Question 4: Would you please continue?
Answer 4: Sure. No problem.

In the previous blog post I wrote about my disability to speak Chinese. That is quite confusing, because I look like a Chinese and not like a Dutchman.
Small recap with the restaurant in China:
“Do you speak English?”
“Yes.”
[Half hour later]
“I would like to order dinner.”
[Blank face] (Red)
“Did you understand me?”
“No.”
[I opened the menu.]
[Waitress approaches me.] (Green)
[I just ordered the dishes using my fingers and the menu.] (Refactor)

What I actually did, was trying to find other ways to order dishes. I could have written down my order, but the waitress could follow my hands. So no refactoring was needed.
No is unpleasant answer, but a lot of frustration was avoided. At least I understood, why hand sign language for numbers was included in the pocket book for frequently used phrases in Chinese.

To be continued.

Being Sidetracked – Part 1

Every story has an expiry date.

So I have to hurry up.

While the junior DevOps engineer was programming aloud, I paid attention to all the steps he took. He used Test Driven Development. It is a cycle of Red, Green, and Refactor.

A small recap: he first made a tiny test, which failed. Red is a favourite colour for failing. Then he made code to let this failing test succeed. Green is that other favourite colour for DevOps, testers, and especially managers.

Then he refactored the code. The code became more maintainable and readable. Even for a tester not fluent in Java.

The first test was to check, whether a business rule failed. He wrote only code to let the test succeed.
Before I could think, the method was ready. It had only one return statement with 1 fixed value.

But this would only be the case for very specific situations. I showed my disbelief and he answered that the code had to pass the new test. Right, you are right.

This was a strange situation for me as a tester with a traditional background. Tests should be executed after the implementation and not before. Somehow my brain had pushed the theory about TDD aside. It felt so unnatural to me that I unconsciously switched back to Program First Test Next.

Anyways, the DevOps had a quick look to the code. I did not think that this could be refactored. One line single statement cannot be refactored.
Yes right again. The first cycle was finished. Red Green Refactor.

A return value from a method is like an answer from a human being. What the DevOps basically asked, was: “Is this value right?”
And the method would always answer with “Yes.”

This was strange to me. Now I realised, that this was the most minimal addition to the program.
Without a method the code would have be repeated multiple times and maintained at the same number of places. A recipe for disaster.

Aw I forgot to look in the right low box in the left corner in the room under the stairs.

Now programmers have a small heuristic for this one:
DRY. Don’t Repeat Yourself.

The fact that the answer was always “Yes”, bothered me. While blogging I remembered asking a restaurant in China, whether they could speak English. The answer was “Yes.” My wife and I were delighted until I ordered. O no.

To be continued