Source files and build scripts for my personal website
git clone
Download | Log | Files | Refs | README (7530B)

      1 # The big rewrite
      3 Recently I have been working on [nissy](,
      4 my command-line Rubik's cube solver. But things were not going the
      5 way I wanted. I was trying to implement some minor but rather complex
      6 optimizations. It was a challenging problem and I made some good progress,
      7 but coming back to my code after not looking at it for weeks made it
      8 hard to debug it.
     10 I could work on this project more often. I rarely have long hours or days
     11 in a row to spend on it, but I do have some free time here and there -
     12 I write somewhat regularly in this blog, after all. So why was I not
     13 spending some more time on this project that I like so much?
     15 I think I was trying to do too much. I was trying to write this complex
     16 optimization for the puzzle-solving logic basically to prove to myself
     17 that I am capable of it, but at the same time I wanted to keep the
     18 tool usable for the few people interested in it. As new ideas piled up,
     19 I rushed through my code changes. Code quality degraded, and I was not
     20 improving the tool.
     22 It was time for...
     23 [the big rewrite](!
     25 ## What is nissy?
     27 Nissy is a command line Rubik's cube solver and
     28 *[fewest moves](*
     29 solving assistant. You can find it's source code on its
     30 [git page](
     31 As a cube solver it is quite fast, faster than the classic
     32 [Cube explorer](, although it uses
     33 much more RAM. But there is room for improvement.
     34 Additional features related to
     35 [Thistlethwaite's algorithm]('s_algorithm)
     36 make it useful tool for a certain niche of speedcubers. Although
     37 these features are appreaciated by nissy's users, the CLI interface
     38 and general usability is not as well-received.
     40 I started working on it in 2019, and after a few months of I had something
     41 we could call useful, at least for me. As I added more features and tried
     42 to implement a faster optimal solver, I noticed that I could make some
     43 improvements to its design. So I decided to rewrite nissy from scratch.
     45 "Rewriting from scratch" is a bit of a taboo among programmers.  It is
     46 exciting to start working on a new or "rebooted" project, but it is
     47 usually more time-efficient to just fix the old code.  Nonetheless,
     48 starting over worked for me: at the end of 2021 nissy was much faster,
     49 and more useful for everyone.
     51 Fast-forward another year or so, and I was at the point I described in
     52 the first paragraph. Since stopping to think, redesign and rewrite worked
     53 for this project last time, I decided to do this again.  I did not start
     54 nissy with a clear goal in mind, so it makes sense that I come up with
     55 better goals and design ideas as I go.
     57 ## Setting a goal
     59 Nissy has been my pet project for the last 3.5 years or so.  I started
     60 writing because I wanted to see if I could do it, and decided which
     61 features to include along the way.  I have never had a precise goal for
     62 it, so I had to think about what I wanted nissy to be.
     64 Right now, nissy's most important features for its users (including
     65 myself) are:
     67 * Analyzing a "fewest moves" solution, helping the (human) solver spot
     68   mistakes, oversigths and more advanced tricks that they missed.
     69 * Solving a Rubik's cube optimally, fast.
     71 The first part is basically already implemented, though some improvements
     72 can be made and some simple features can be added.  Most importantly,
     73 the interface should be made more accessible to people not familiar with
     74 the command line - more on this later.
     76 For the second part, the interface is less important, and I can expect the
     77 users to be able to learn how to launch one single command.  It is also
     78 the part that I find most interesting to work on, since the optimization
     79 problem is much more challenging.  On the other hand, the optimal solver
     80 implemented in the current version of nissy is already good enough for
     81 most users.
     83 Once I had written down these two main features, I realized that
     84 I would be much happier working on this project if I just stuck to
     85 those two things. And since *one* program should do *one* thing, I
     86 decided to split the two features into separate projects.  Any other
     87 cool idea I thought of implementing (a speed-solving assitant? a
     88 higher-order cube optimal solver? a generic, hackable puzzle solver like
     89 [ksolve+](  is deferred to future
     90 projects, or probably it will be never done. And that's OK.
     92 ## New plan
     94 My plan is to split the work into the following parts:
     96 * Starting from the [stable branch](
     97   of nissy, remove all the code that is needed only by the optimal
     98   solver and other unnecessary steps. Work on a GUI and other simple
     99   features useful for assisting fewest moves solvers.
    100 * Branch off the optimal solver from the current
    101   [working branch]( of nissy. Remove
    102   all the code that is not needed for the optimal solver and simplify
    103   the logic, where possible, to address only this use case.
    104   Finish implementing the solver, basically following Tomas Rokicki's
    105   [nxopt](,
    106   or at least parts of it.
    108 For the user interface, I have been thinking about what would be
    109 the best library / framework / technology to use. I would like
    110 this to be as accessible as possible, so I have been considering
    111 [WebAssembly]( so that people can just run this
    112 in their browser. But apparently a WebAssembly app needs an http server
    113 to work. I don't want nissy to require an internet connection, and
    114 shipping a whole web server to run locally with it is overkill. I have
    115 also been thinking about [Flutter](, it supports all
    116 majow platforms and has the C language as a first-class citizen.  I think
    117 I'll try making some proof of concept app with it and see how it goes.
    119 ## A GUI app? Is this an April fools' joke?
    121 Am I a big fan of command line interfaces. I am such a fan of the command
    122 line that I dislike TUIs (such as
    123 [ncurses]( programs), because 
    124 they are just GUIs running in a terminal.  So why am I even considering
    125 ruining my favourite personal project by adding a GUI?
    127 One reason is that I don't expect my (very few) users to be familiar with
    128 the command line. But this is not the main reason. I truly believe that,
    129 for this specific use case, a graphical user interface would be better.
    130 And it is not even a matter of showing a graphical representation of
    131 the cube - my users don't need it,
    132 [Singmaster notation](
    133 is enough for them.
    135 The point is that this program is supposed to show you a bunch of
    136 information. The user might want to see more details, less details,
    137 group this information in different ways and so on. This information
    138 should be browsable. The user should, ideally, be able to follow a
    139 solution path proposed by nissy by simply selecting the suggested steps.
    141 This could all be done with commands, of course. But it would not be
    142 efficient. The command line is great when you know what information
    143 you want and you ask the computer to generate it or fetch it.
    144 But for interactively browsing information, especially when you do
    145 not know exactly what you are looking for, a GUI is better.
    147 ## Ok, so when is it going be ready?
    149 Ah-ah. It will be ready when it's ready, no promises :)