Solving the Rubik's Cube

I've been reading and practicing the rubik's cube for the past few years. When I was in grade school the rubik's cube had just come out. And a number of students could actually solve the cube. Which I thought was amazing, but I had never bothered to learn how to do so. What I find interesting is that a 3x3x3 cube has 43,252,003,274,489,856,000 possible configurations! Which is a good example of the almost infinite complexity that is the most basic structures we have all around us.

Over the Thanksgiving break I thought I'd write a program that could receive input of an unsolved Rubik Cube and output the moves required to solve the cube. I was thinking of various data structures to store the cube in a straight forward way. Here is what I was originally thinking for storing the pieces and positions:

public enum Cubies {
        WBO, WO, WOG, WG, WGR, WR, WRB, WB,
        BO, OG, GR, RB,
        YBO, YO, YOG, YG, YGR, YR, YRB, YB
    }

public enum Positions {
        WLR, WR, WRR, WML, WMR, WFL, WFM, WFR,
        BRE, BOE, RGE, OGE,
        YLR, YR, YRR, YML, YMR, YFL, YFM, YFR
    }

Here W=white, R=right/red, L=left, M=middle, F=front, B=blue,O=orange,G=green,Y=yellow

Then just have the actual cube stored as an array of strings that contain the actual color of each square. After struggling for a few hours on writing methods for createCube, printCube, TwistCube(Side), etc. I thought I'd google the code and found CubeTwister:

http://www.randelshofer.ch/cubetwister/

Which shows someone has been doing their homework in regard how to store the Rubik's Cube as a data structure. If you look at the ch.randelshofer.rubik.AbstractCube class you can see that the cube is stored as a number of int arrays. Here is one example:

    protected final static int[][] CORNER_TO_FACE_MAP = {
        {1, 0, 2}, // urf
        {4, 2, 0}, // dfr
        {1, 5, 0}, // ubr
        {4, 0, 5}, // drb
        {1, 3, 5}, // ulb
        {4, 5, 3}, // dbl
        {1, 2, 3}, // ufl
        {4, 3, 2}, // dlf
    };

0=right, 1=up, 2=front, 3=left, 4=down, 5=back

One of the most interesting integer arrays is a four dimensional


     Corner swipe table.
     First dimension: side part index.
     Second dimension: orientation.
     Third dimension: swipe direction
     Fourth dimension: axis, layermask, angle
   
                 +---+---+---+
                 |4.0|   |2.0|
                 +---     ---+
                 |     1     |
                 +---     ---+
                 |6.0|   |0.0|
     +---+---+---+---+---+---+---+---+---+---+---+---+
     |4.1|   |6.2|6.1|   |0.2|0.1|   |2.2|2.1|   |4.2|
     +---     ---+---     ---+---    +---+---     ---+
     |     3     |     2     |     0     |     5     |
     +---     ---+---     ---+---    +---+---     ---+
     |5.2|   |7.1|7.2|   |1.1|1.2|   |3.1|3.2|   |5.1|
     +---+---+---+---+---+---+---+---+---+---+---+---+
                 |7.0|   |1.0|
                 +---     ---+
                 |     4     |
                 +---     ---+
                 |5.0|   |3.0|
                 +---+---+---+

Senior Developer = Mature Developer

I just read a few interesting articles regarding what a Senior Developer is:

http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/

Mature engineers do not shy away from making estimates, and are always trying to get better at it.

Mature engineers lift the skills and expertise of those around them.

Mature engineers make their trade-offs explicit when making judgements and decisions.

The Ten Commandments of Egoless Programming

Appropriate, even if old…I’ve seen it referenced as coming from The Psychology of Computer Programming, written in 1971, but I don’t actually see it in the text. Regardless, here are The Ten Commandments of Egoless Programming, found on @wyattdanger‘s blog post on receiving advice from his dad:

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. (Allspaw note – related: see below, number #10, and the points Theo made above.)
3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.
9. Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.
10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.