Naushil

[naushil]

The Confession of a Test-First Traditionalist

I am not sure what David Heinemeier Hansson meant when he used the words "test-first fundamentalism", and "traditional unit test" in his controversial article TDD is dead. Long live testing., but I test-drive my code every day and follow the practice religiously, so I figured he may be talking about me. David, like many others, has struggled to test-drive his code, and took his frustrations out on unit tests, mocks, and architecture decisions he disagreed with. I can relate to that. In the second year of my three-year tenure with 8th Light, Inc, the company founded by Micah Martin and Paul Pagel, the son and apprentice of Uncle Bob Martin, respectively, I too had the same concerns. I brought them up to my coworkers, and contrary to popular belief, I was not prosecuted by the test-first traditionalist camp and my heart was not sacrificed to the god of test-driven development. Instead, we had a long and healthy debate over the internal mailing list, and in the end, I learned to use mock more carefully and deliberately. At the core of test-first traditionalism, our objective is not to convert you to our camp. We want to help you get better at what you do. We want to raise the bar for our profession. And in the spirit of that, here is what I learned about mocks. Don't Mock What You Don't Own Is a rule taken from the book Growing Object Oriented Software, Guided by Tests, and is blogged by Eric Smith. Mock is based on assumptions. We assume mock objects will behave the same way as their real counterparts under the circumstances we test in, but we could be wrong. And that's when mocking becomes a liability and creates a false sense of safety. If you have to make assumptions about code, at least make them about the code that you wrote, where you know the deficiencies of the implementation. Design vs Refactoring Mock is often used as a design tool to tease out interactions between the collaborators in your object. It focuses your attention on the interfaces of your objects rather than their states. However, this can also lead to coupling tests with implementations, and therefore make refactoring difficult. On the other hand, state-based testing only verifies the final state of the code, and thus makes changing implementation and refactoring easier. This article by Paul Gross was a good introduction to the philosophy of state-based approach for me. Mockist vs Classicist As a test-first traditionalist, I face the question of to mock or not to mock on a daily basis. Mock is a powerful tool for isolating objects and identifying dependencies. It is especially useful for working with legacy code - when I just want to cut out a clear path in a jungle of mess. Some days I go with mocks to drive the interactions of my code, and others, I fall back on the classicist approach of state-based testing to free my mind of hardcoded implementation details. YMMV.

[naushil]

In Search of Diversity

In the year 627 AD, a Buddhist monk was concerned with the translation quality of Chinese Buddhist scriptures; he decided to take a trip to India to learn the language. A year later, the monk enrolled in the ancient University of Nālandā, where he studied logic, Sanskrit, and Buddhism alongside thousands of scholar monks. It took the monk more than a decade to complete his study. At the end of his journey, he returned to China with hundreds of volumes of Buddhist writings, and devoted the rest of his life translating Sanskrit in a monastery. The Heart Sutra that he translated continued to be recited throughout Buddhist temples in China, Korea, Japan, and Vietnam today. One of his disciples compiled the monk’s nineteen year journey into a book, the Great Tang Records on the Western Regions, which formed the basis of our understanding of the geography and early customs of South and Central Asia. The Great Tang Records also captured the imagination of a 16th century writer, who then created the classic Chinese novel Journey to the West based on the epic pilgrimage. What started as a personal quest to fill in the gaps of his religious study, the monk transformed the lives of millions through traveling, learning, and inspiring the people he encountered along the way. The monk injected a new energy into the collective consciousness of Eastern Asians, and shaped the future development of Neo-Confucianism, Daoism, and other emerging philosophies. The monk was an agent of change of the 7th century China, just as we are the agents of our time. We share the same mission to introduce new perspective to our organization, and to better ourselves, together with the rest of the community. At 8th Light, we truly believe the value of diversity, and we are encouraged to take the first steps toward our personal journey through company sponsorship. Back in August, 8th Light flew me to San José, Costa Rica to reboot our craftsman swap program with sister company, Pernix Solutions. From day one, I took a dive into JavaScript with the front end specialist at Pernix, and later quickly switched gear to Facebook integration and Heroku deployment; I had my first taste of augmented reality with Unity on day two, and then was thrown into a maze of legacy code in Java the next day. Needless to say, I learned quite a bit by the end of the week. I was ready to untangle a complex XSLT code base should an opportunity arise. In exchange, I introduced Jasmine.JS and RSpec to their new Ruby on Rails team, and many of the testing strategies we have developed over the years. Outside of work, what I admired the most about Pernix was their dedication to contribute to their community, help local museums and businesses to adapt new technology and develop new customer base. Pernix also rolled their own apprenticeship program, and gathered a group of bright and very knowledge-hungry students. In many ways, Pernix reminded me of a younger 8th Light, where the crew was much smaller and more connected. While I stayed at a quiet living quarter in Cartago that Pernix had kindly prepared for my companion and myself, I was overwhelmed by the hospitality of my host and his colleagues. My journey may not be as challenging as traveling across South and Central Asia on foot, and horses, while evading hostile tribes and sworn enemies of ancient Chinese Empire, I was still able to share with our Costa Rican friends my experience in software development, and bring back their values and what they stand for. Software is filling up every niche of our market today. The products that we are working on now, can reach an international audience tomorrow. As developers, we are ever in need of new voices in our workspace to create competitions, collaborations, and innovations. And what better way to find new voices than to travel, and explore the possibilities beyond our regular lives? Pernix Solutions: http://www.pernix-solutions.com/

[naushil]

Craftsmen, Painters, and Monks

Once there was an emperor who wanted to make a temple in his capital holier and more elegant. His servants looked far and wide and found two crews of workmen for the job. One crew consisted of renowned craftsmen and painters, and the other, a band of faithful monks. The emperor could not make up his mind, so he decided to host a contest. The emperor asked each crew to renovate a small temple in the countryside, and whichever side wins his favor wins the bid. After hearing the details of the contest, the craftsmen and painters asked the emperor for paint in thousands of colors, in addition to hundreds of nifty tools. The monks, however, only asked for a handful of clean cloth and water buckets. Three days later, the emperor went to inspect the renovated temples. The craftsmen and painters decorated their temple in the most brilliant colors and with impressive skills. Then, the emperor turned around to see the monks' temple. Rather than adding any color, the monks merely wiped the walls, tables, chairs and windows clean. But everything inside the temple was restored to its original color, and their spotless surfaces became mirrors that reflected the colors outside. The serene and beautiful sight immediately took the emperor's breath away. At the time I was reading this tale as told by Hong Yi[1], I felt a great deal of sympathy toward the craftsmen and painters in the story. I couldn't help but wonder what went wrong? The craftsmen and painters were clearly more skillful and talented, yet they lost to the monks. After I read through the story a couple more times, I realized that they lost because they ignored what their customer requested. The emperor was looking for a temple capitalizing on elegance, but they erected him a pompous and superfluous house of worship. The craftsmen had failed to keep the customer's best interest in mind. The craftsmen also demanded a copious amount of paint along with other accessories, while the monks merely asked for a fraction of the cost to bring the project to life. The fact that the craftsmen had a great selection of tools at their fingertip and not being able to pick the most appropriate one seemed to have worked against them. If I were a servant of the emperor, I would definitely keep tabs on the high cost and maintenance of the craftsmen. In the end, the craftsmen had no one to blame except for themselves. They painted the temple in their own colors, displayed amazing craftsmanship, but failed to deliver a satisfying experience. The lesson for me here is that technical skill is not everything. As service providers, the moment we enter a contract, our customer's project becomes our temple. Our job is to polish every nook and cranny inside the temple to reveal their true intent, break convention and introduce new elements only with the consent of the customer, be mindful of the customer's budget, and always tread the project carefully as if we are standing on a sacred ground. [1] Hong Yi, a Chinese Buddhist monk, artist, and art teacher (1880-1942).

[naushil]

Why Apprenticeship?

In 6th century B.C., during the Spring and Autumn period, China was torn apart by feudal lords and royalty from the declining Zhou dynasty. Amidst the endless wars and conflicts, hundreds of schools of philosophies emerged as the people struggled to find a path to return to peace. One philosopher was especially fond of education, and he identified two guiding principles for the school he established, yin cai shi jiao and you jiao wu lei. The former means to teach your student according to their aptitude, and the latter, to provide education for all without discrimination. Fast-forward to modern time. Today we have compulsory education for our children. However, our school teachers do not necessarily have enough time to dedicate to each one of their pupils, and not all have the financial support to attend schools for higher education and be prepared for a specialized profession like software development. I believe the apprenticeship model can solve some of these problems. Apprenticeship encourages a one-on-one relationship, where both the apprentice and his master agree to commit to a relationship of teaching and learning. It recognizes individuality and lets the mentor adjust his material according to the capacity and personality of his mentee. The mentor also has more motivation for bringing up the mentee the right way as he will become an active member on the team, and contribute to the growth of the company. From the perspective of the apprentice, he has an opportunity to learn from a successful professional who is actively working in the field, and practicing their craft on a daily basis. In addition to knowledge and techniques, the apprentice also learns the job ethics and etiquette from firsthand experience. The Chinese philosopher became one of the first to offer public lectures that were previously controlled by the government and exclusive to nobles. Among his disciples were rulers, commoners, the rich, and the poor. His name was Confucius, and his teaching cemented the foundation of one of the most thriving civilizations in history. By following the apprenticeship model, we are answering questions for anyone who is humble enough to ask; we are raising the bar for anyone who is determined enough to rise up; we are making our core practices available to the masses, and in turn, we have people who understand our job and whom we would like to work with in the future. Talk to us if you want to learn more! http://www.8thlight.com/apprenticeship

[naushil]

Clojure Exercise: Implement Rules of Go

I am going to assume you have some knowledge of Go before we start, if not, please refer to other better-written literature on the subject. To avoid any confusion over translation, let's agree on the following terms: ko is the point where a stone was removed from in the previous turn. A point is said to be a stone's liberty if it is unoccupied, and adjacent to the stone. A group refers to stones sharing the same color that are adjacent to one another.

The aim of this exercise is to write a function that will determine if a move is legal or not.

DISCLAIMER: The code snippets below are not guaranteed to run. I ripped them straight out of my project, and even though I modified them slightly for this post, I did it in my text editor. Please follow the approach presented in this article and come up with your own implementation.

Our function has to ensure

Current move is not ko.

Current move is not out of bound.

Current move is unoccupied.

Current move is not a suicide.

Corollary: a move is suicidal when

Current move and its group has no liberty left.

Current move does not remove any adjacent enemy from board.

Our first step is to pick a data structure for board configuration. I chose vector because it allows constant time random access. Let each position on the board be marked by a number: 1 for black, 2 for white, and 0 for gray, or unoccupied.

And now, we're ready to knock out the conditions.

Current move is not ko.

We will pass in ko as an argument to our function.

Current move is not out of bound.

Simple.

Current move is unoccupied.

Straightforward.

Current move is not suicide.

Here comes the hard part. The suicide condition is last because it requires the most expensive operations. First we need to figure out which ones of our adjacent points hold the same mark as we do, which ones are occupied, and which are our enemies. We will recursively look for ally adjacent points and add them to our group.

For simplicity, we will find out how many liberty points we have after we build up our ally group. However, you can search for ally and liberty points at the same time to optimize for performance.

With a simple depth-first search algorithm, we found our very own ally group, represented by a hash map. Let's count how many liberty points it has.

I picked set as my container for liberty points because set forces items to be unique, and we don't want any liberty to be counted more than once.

With that, the only thing missing is to identify the enemy groups surrounding our current move, and count how many liberty points each of them has. We can use the find ally function we just wrote and simply change the color argument.

I used set again before returning the groups of enemy to force uniqueness, but you can also check if a neighbor is already part of any of the known enemy groups before you call find ally again.

And here it is. Our bare-boned, functional, ugly, beautiful legal function, and her sibling, suicide.

[naushil]

Jenkins, RVM, and Selenium

I have been working on migrating half a dozen 8th Light projects to our continuous integration server last week. Barring one open-source gem project, most of them were Rails. I have used Jenkins to build, pipeline, and install projects on Windows with batch commands and ant tasks in the past, but this would be the first time I set up Rails projects and deal with Ruby management and running features in a headless environment.

RVM

Obviously the center piece of this operation is RVM. The catch is that Jenkins does not load your bash profiles on slave environment for each build, which is usually how you load RVM into a shell session. This can be resolved with either including RVM scripts in Jenkins' startup, or run, `source ~/.bash_profile` at the beginning of your build steps assuming you followed the post install instruction in RVM installation guide. Afterward, you can execute `rvm use 1.9.2@gemset` to pick up project setting, or take advantage of .rvmrc. Business as usual.

Alternatively, you can install Jenkins' Rake plugin. The plugin allows you to choose a Ruby installation per project, and since version 1.7, with RVM integration you can also pick a specific gemset you created on RVM. From Jenkins' homepage, go to Manage Jenkins, Configure System, and fill out RVM installation path under the Rake section. Now at your project configuration, when you add a new build step to invoke Rake task, you will see a list of Ruby versions and available gemsets ready at your disposal. The Rake plugin refreshes this list every time you save the Configure System page.

Headless Selenium

Some Rails projects are set up to run acceptance tests against a real browser, and unfortunately our continuous integration box is without a display. The common solution for this type of problem seems to be installing Xvfb, a virtual framebuffer server that renders your GUI tools in memory.

Moving forward, you can write a script to run Xvfb whenever you kick start a build, and make sure the DISPLAY variable is set accordingly when Selenium is up. Your other option is to install the headless gem, and call to launch the server with Ruby API in your "features/support/env.rb" file.

Now armed with RVM and headless gem, you can create a new job on Jenkins with relative ease. I hope, at this point, you will have a reasonably good grasp on how to set up your own Rails project on a CI server, and ready to reap the profits of the continuous integration process. To sum it up, here is the final recipe for a Rails project's build step.

[naushil]

Return Boolean Expressions

I am fine with explicit return and an extra pair of parentheses for clarity's sake. What I don't understand is why people insist on adding a redundant conditional when they can just return a evaluated boolean expression. Seriously, follow the idiom.

[naushil]

[naushil]

Clojure Exercise: More GTP

The motive behind choosing Clojure as the platform is my own interest in picking up a new language, and also to continue Colin's lessons on Clojure and apply those knowledge beyond brain teasers. I am still learning Clojure basics and thus the style of which this library is written is far from Clojure-esque. At its core, the library uses defmacro to dynamically create functions according to user input, and when the function is called it is checked against a hashmap of command names and argument counts.

[naushil]

Clojure Exercise: GTP

In preparation for the company-wide three-day course on go programming, I decided to write a simple utility that implements Go Text Protocol in Clojure. The purpose of this library is to provide computer go developers easy access to existing go graphical interfaces and resources. The protocol library currently supports only the minimum set of required commands. A user can implement each command by calling a make-command function, pass in an anonymous function block, and expect a list of arguments accessible with %1. The command function should evaluate to a string as specified here. Here is an example. You can checkout the source code and download an executable JAR from my github account.

[naushil]

Haskell #5.2 - Basic IO

Suppose you have the following functions you want to test on. For starter, you can replace Prelude's built-in putStr and getLine with local functions that you pass in as parameters. This way you can substitute them for mock functions later. Take advantage of Haskell's polymorphism, and swap out putStr with your own. Now instead of printing out the board, it checks to see if the board being printed out is the one you expected, and returns a Boolean value accordingly. You can mock out getLine with the return statement and a fake parameter to specify which value to return when gets is called. And since HUnit Assertion is an IO computation, you can easily pull the result out of askMove with a left-arrow and put it in a variable for comparison.

[naushil]

Haskell #5.1 - assertTrue and assertFalse

[naushil]

Haskell #5 - HUnit

I was in search of an unit testing framework for my Haskell project and came across HUnit. HUnit is inspired by JUnit, and shares the same simplistic construct. It has several key components that include Assertion, TestCase, and TestList. Let's start with making our own test case with an assertion. Each TestCase has an Assertion, which contains description, expected value, and actual value, in that order. We can create a list of test cases, label them, and then feed them into a TestList. Finally, we call the terminal-friendly runTestTT function and execute our tests. If you have multiple test files scattered across your project, you could write a script to invoke main on each test file individually, or the way I did it. I simply made a AllTests module, imported all the test files, concatenated the suites into a single list, and run them all at once.

[naushil]

[naushil]

Haskell #4 - Map

Map is a powerful function that forces you to think on a higher level, and improves the modularity of your code by reusing functions. Unfortunately, I often find myself stuck in the imperative programming mindset. The idea of transforming my list in another function unnerves me. On the other hand, writing the same function with some syntactic sugar does help a little bit. I caught myself doing list comprehension quite a few times in the past couple days, so now I am trying to move away from it to let myself fully immerse in the world of functional programming. There is only one instance I can think of where map should be avoided legitimately. Map makes your code look cleaner and shorter, so you might be tempted to apply it even when you don't need to process the entire list. In that case, you should replace map with a more explicit recursion, otherwise your performance will suffer. For example, you can rewrite the previous function this way.

[naushil]

Haskell #3 - Namespace

Haskell's namespace is controlled by modules and the import statement. Import is a powerful command that has several special usages other than importing functions from other modules, which I will illustrate in the following example. Let's say we have a Mark module in a Board folder, which is responsible for marking game pieces on a game board. We want to import this module to our main module. However, it is very possible that some of the names are already taken in Main's namespace. For instance, we could have a Point module that has an x, or a List module that has a function named empty. To resolve name conflicts, we could use qualified import. This combination will force you to specify the namespace when calling a function from another module, ie. Board.Mark.o and Board.Mark.x. If instead you want to redefine a function, you can use import hiding, which is essentially how you would override functions in Haskell. You can also specify which functions you want to import. But note that, when you change a function name or export list of the imported module, you will have to reflect the changes here as well. If not, compiler will complain about name not found in scope. Lastly, and perhaps the most powerful feature to me, is that you can rename the namespace with the as keyword. Thus, you can call Mark.o instead of Board.Mark.o. Make your namespace nice and clean.

[naushil]

Haskell #2 - Privacy

In many OOP languages you have access modifiers such as private and public to set visibility of your class content. These modifiers help to hide information and create a clean interface. In Haskell, however, there are no equivalent reserved words. What you have instead is module declaration. A Haskell program is composed of modules, where each module is a package of related functions and definitions. By default, everything inside a module is exposed to the world. You can specify which functions and definitions are accessible from outside the module by listing them in the declaration. This list is known as an export list. In essence, you can modify the export list to declare any entity `public` or `private`. And it only takes a glance at the top of your module to see which functions are declared `public`. Coming from a Java background, I am really liking the simplicity and clarity of this language.