The problem:

Pairing is a great way to give new life to an old problem. Even when I pair on a simple kata, my pair always do something I don’t expect, like using a data structure I would never think to use, or write a different test. All of these make me go out of my usual route and see the problem differently. At the time when Tom and I paired (ping-pong style) on the bowling kata in Ruby, he had never done it before. I had done the kata in Java a few months earlier. If it was only me doing the kata again in Ruby, I would probably do it very similarly to how I did it in Java, use the same algorithm, write the same set of tests, in the same order. Pairing with Tom had some extra perk since he is a mathematician and he approaches problems very differently from me. When it’s time for Tom to write a test, he would not write the test I had in mind, which in turn force me to solve the problem differently now that I need to write the code to pass his test. This dynamic took us in a whole new direction from what we would have done alone. I found the process very enjoyable.

OCP stated that all software entities (classes, functions, modules, etc..) should be open for extension but close for modification. Open for extension means the behavior of the entity can be altered or extended. Close for modification means any changes to the entity would not result in chages to the source code of that entity. Changes should be achieve by adding new code without changing old working code.

ISP stated that clients should not be forced to depend upon methods that they do not use. Interface belongs to clients, not to hierarchies.

Application Programming Interface (API) is a piece of software that allows applications to communicate and transfer resources. There are different types of APIs, notably SOAP (Simple Object Access Protocol) and REST (REpresentational State Transfer). Regarding REST, there are strict and pragmatic views of what qualifies as a RESTful API. Strict REST proponent would say that an API can only be considered RESTful if it satisfies all the constrains of the REST architectural style defined by Roy Fielding in his doctoral dissertation. REST pragmatist are more relaxed about these constrains. Many web APIs are not strictly speaking RESTful API. They might meet some but not all the constrains. Roy Fielding himself has shown frustration about people refer to their APIs as RESTful without meeting all the constrains. In this post, we will take a more pragmatic view of REST APIs (simply refer to them as web APIs). We will explore how they work and why we might benefit from using them.

Threads are used to achieve concurrency inside an application. They are ordered sequence of instructions for specific tasks. Note that threads do not carry out the execution themselves. The CPU handles the actual execution of the tasks.

Last week I ran into issues with circular dependencies. To solve my problem, I had to examine my system as a whole. Design software is challenging for many reasons. One of the issues I’ve experienced is keeping a big picture of the system. As my software gets more complicated, I have a hard time keeping track of how things are wired together, how objects communicate with each other. I sometimes said to my mentors that I am lost in my own system, fully aware that what I am building in these exercises are very small compared to the systems I will work with in actual client projects.

Tam: “I just realize that I know nothing about the internet!”

Eric: “Oh, me neither. I just take advantage of it.”

Using the bowling kata as an example. Step by step instruction to set up a project on the command line with the Swift package manager. Tests with Quick and Nimble.

While working on my current project, I have to deal with obtaining input and publishing output for my program. While I’m at this, I also revisit a few things I’ve touched on in the past, i/o testing, stubbing and mocking.

My student apprenticeship at 8th Light is coming to an end. During the past three months, I focused on learning Java, test driven development, and the practice of writing clean code.

There were two or three times when Cyrus commented that he liked a particular section of my code because it was expressive. For a long time, I didn’t quite understand what it meant for code to be expressive. Now, after having some acquaintances with good design rules and principles, I understand expressive as to clearly express the developer’s intent. Expressive code allows someone to read the code and easily follow the logic of the system. The more expressive the better because reading code is difficult. Developers have to cultivate the ability to read and pick up code in unfamiliar languages (a little bit like sight reading for musicians, the ability to read and perform music at first sight). I need to practice reading a lot more code. As I added new features into my TicTacToe game, once in a while I’ve had to go back and make change to code I wrote a month before that. A month is not that long, given that this is my code in a project I’m actively working on, I was a little upset at how much time it took me to understand my own code.

In the last two weeks, I have been working on implementing Minimax to program an unbeatable player for my TicTacToe game. Minimax is the algorithm that enables the computer to look ahead and find the optimal move. From the computer’s perspective, the computer is the maximizing player. Its objective is to maximize its gain (represented by a score). Because TicTacToe is a two player, zero-sum game, the opponent is the minimizing player. The objective of the opponent is to minimize the computer’s gain.

Notes from a day of hard work

This week, I worked on obtaining user input (cell selection input, to be specific) for TicTacToe. I started out planning to do this the proper TDD way and immediately ran into problem. This was the first time I encountered i/o testing.

I have started to use version control (git/ gitHub) with more frequency: making commits, submit pull requests for code review, branching, merge approved branches to master. Below is a summary of the git commands I use most frequently and a few note-to-self I’ve collected along the way.

When I walked through Uncle Bob’s bowling score kata powerpoint, one thing that really stood out to me was the way he refactored his tests to remove duplication and ugly comments. Not only did he write tests, but also held them in the highest standard. I am constantly reminded to write tests and clean up my code. Yet, my brain doesn’t automatically extend the practice to “maintain your test” and “clean up your test”. I can only speculate that while I was telling myself that tests are important, my mind still subconsciously saw them as secondary. Secondary to the code they accompany. After all, the production code is what gives life to our software, isn’t it?

I’ve started reading this book: Apprenticeship Patterns - Guidance for the Aspiring Software Craftsman. The second chapter of the book is titled “Emptying the Cup”. It’s the idea that in order to learn and be receptive to learning, you have to keep an open mind, willing to try counter-intuitive approaches, let go of old habits. I’ve been programming for only a year. My cup is pretty empty to begin with. Nevertheless, I find this advice very helpful.

After a week, I am slowly warming up to Java’s verbose syntax and strict typing. Does a function return something or not, what type of data does it return, what type of parameters does it take? Everything has to be clearly stated in the function declaration. Since I have only coded in JavaScript, this new way of doing thing takes a while to get used to. However, having these strict rules also improves clarity of intent, which I assume can be comforting especially when things get more complicated.