sebastiano.tronto.net

Source files and build scripts for my personal website
git clone https://git.tronto.net/sebastiano.tronto.net
Download | Log | Files | Refs | README

commit 1e6a83293f0aa47415d5480a773d6d12c09afb19
parent 2fb07a9a7d477253fb5ba4d96e0a08d770593d59
Author: Sebastiano Tronto <sebastiano@tronto.net>
Date:   Mon, 10 Apr 2023 12:43:08 +0200

Added blog post

Diffstat:
Asrc/blog/2023-04-10-the-big-rewrite/the-big-rewrite.md | 149+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Msrc/blog/blog.md | 1+
Msrc/blog/feed.xml | 7+++++++
3 files changed, 157 insertions(+), 0 deletions(-)

diff --git a/src/blog/2023-04-10-the-big-rewrite/the-big-rewrite.md b/src/blog/2023-04-10-the-big-rewrite/the-big-rewrite.md @@ -0,0 +1,149 @@ +# The big rewrite + +Recently I have been working on [nissy](https://nissy.tronto.net), +my command-line Rubik's cube solver. But things were not going the +way I wanted. I was trying to implement some minor but rather complex +optimizations. It was a challenging problem and I made some good progress, +but coming back to my code after not looking at it for weeks made it +hard to debug it. + +I could work on this project more often. I rarely have long hours or days +in a row to spend on it, but I do have some free time here and there - +I write somewhat regularly in this blog, after all. So why was I not +spending some more time on this project that I like so much? + +I think I was trying to do too much. I was trying to write this complex +optimization for the puzzle-solving logic basically to prove to myself +that I am capable of it, but at the same time I wanted to keep the +tool usable for the few people interested in it. As new ideas piled up, +I rushed through my code changes. Code quality degraded, and I was not +improving the tool. + +It was time for... +[the big rewrite](https://dylanbeattie.net/songs/big_rewrite.html)! + +## What is nissy? + +Nissy is a command line Rubik's cube solver and +*[fewest moves](https://www.speedsolving.com/wiki/index.php?title=Fewest_Moves_Challenge)* +solving assistant. You can find it's source code on its +[git page](https://git.tronto.net/nissy). +As a cube solver it is quite fast, faster than the classic +[Cube explorer](http://kociemba.org/download.htm), although it uses +much more RAM. But there is room for improvement. +Additional features related to +[Thistlethwaite's algorithm](https://en.wikipedia.org/wiki/Optimal_solutions_for_Rubik%27s_Cube#Thistlethwaite's_algorithm) +make it useful tool for a certain niche of speedcubers. Although +these features are appreaciated by nissy's users, the CLI interface +and general usability is not as well-received. + +I started working on it in 2019, and after a few months of I had something +we could call useful, at least for me. As I added more features and tried +to implement a faster optimal solver, I noticed that I could make some +improvements to its design. So I decided to rewrite nissy from scratch. + +"Rewriting from scratch" is a bit of a taboo among programmers. It is +exciting to start working on a new or "rebooted" project, but it is +usually more time-efficient to just fix the old code. Nonetheless, +starting over worked for me: at the end of 2021 nissy was much faster, +and more useful for everyone. + +Fast-forward another year or so, and I was at the point I described in +the first paragraph. Since stopping to think, redesign and rewrite worked +for this project last time, I decided to do this again. I did not start +nissy with a clear goal in mind, so it makes sense that I come up with +better goals and design ideas as I go. + +## Setting a goal + +Nissy has been my pet project for the last 3.5 years or so. I started +writing because I wanted to see if I could do it, and decided which +features to include along the way. I have never had a precise goal for +it, so I had to think about what I wanted nissy to be. + +Right now, nissy's most important features for its users (including +myself) are: + +* Analyzing a "fewest moves" solution, helping the (human) solver spot + mistakes, oversigths and more advanced tricks that they missed. +* Solving a Rubik's cube optimally, fast. + +The first part is basically already implemented, though some improvements +can be made and some simple features can be added. Most importantly, +the interface should be made more accessible to people not familiar with +the command line - more on this later. + +For the second part, the interface is less important, and I can expect the +users to be able to learn how to launch one single command. It is also +the part that I find most interesting to work on, since the optimization +problem is much more challenging. On the other hand, the optimal solver +implemented in the current version of nissy is already good enough for +most users. + +Once I had written down these two main features, I realized that +I would be much happier working on this project if I just stuck to +those two things. And since *one* program should do *one* thing, I +decided to split the two features into separate projects. Any other +cool idea I thought of implementing (a speed-solving assitant? a +higher-order cube optimal solver? a generic, hackable puzzle solver like +[ksolve+](https://mzrg.com/rubik/ksolve+)?) is deferred to future +projects, or probably it will be never done. And that's OK. + +## New plan + +My plan is to split the work into the following parts: + +* Starting from the [stable branch](https://nissy.tronto.net/download) + of nissy, remove all the code that is needed only by the optimal + solver and other unnecessary steps. Work on a GUI and other simple + features useful for assisting fewest moves solvers. +* Branch off the optimal solver from the current + [working branch](https://git.tronto.net/nissy/) of nissy. Remove + all the code that is not needed for the optimal solver and simplify + the logic, where possible, to address only this use case. + Finish implementing the solver, basically following Tomas Rokicki's + [nxopt](https://github.com/rokicki/cube20src/blob/master/nxopt.md), + or at least parts of it. + +For the user interface, I have been thinking about what would be +the best library / framework / technology to use. I would like +this to be as accessible as possible, so I have been considering +[WebAssembly](https://webassembly.org) so that people can just run this +in their browser. But apparently a WebAssembly app needs an http server +to work. I don't want nissy to require an internet connection, and +shipping a whole web server to run locally with it is overkill. I have +also been thinking about [Flutter](https://flutter.dev), it supports all +majow platforms and has the C language as a first-class citizen. I think +I'll try making some proof of concept app with it and see how it goes. + +## A GUI app? Is this an April fools' joke? + +Am I a big fan of command line interfaces. I am such a fan of the command +line that I dislike TUIs (such as +[ncurses](https://en.wikipedia.org/wiki/Ncurses)-based programs), because +they are just GUIs running in a terminal. So why am I even considering +ruining my favourite personal project by adding a GUI? + +One reason is that I don't expect my (very few) users to be familiar with +the command line. But this is not the main reason. I truly believe that, +for this specific use case, a graphical user interface would be better. +And it is not even a matter of showing a graphical representation of +the cube - my users don't need it, +[Singmaster notation](https://www.speedsolving.com/wiki/index.php/Singmaster_notation) +is enough for them. + +The point is that this program is supposed to show you a bunch of +information. The user might want to see more details, less details, +group this information in different ways and so on. This information +should be browsable. The user should, ideally, be able to follow a +solution path proposed by nissy by simply selecting the suggested steps. + +This could all be done with commands, of course. But it would not be +efficient. The command line is great when you know what information +you want and you ask the computer to generate it or fetch it. +But for interactively browsing information, especially when you do +not know exactly what you are looking for, a GUI is better. + +## Ok, so when is it going be ready? + +Ah-ah. It will be ready when it's ready, no promises :) diff --git a/src/blog/blog.md b/src/blog/blog.md @@ -5,6 +5,7 @@ ## 2023 +* 2023-04-10 [The big rewrite](2023-04-10-the-big-rewrite) * 2023-03-30 [The man page reading club: dc(1)](2023-03-30-dc) * 2023-03-06 [Resizing my website's pictures with ImageMagick and find(1)](2023-03-06-resize-pictures) * 2023-02-25 [Job control: one shell is all you need](2023-02-25-job-control) diff --git a/src/blog/feed.xml b/src/blog/feed.xml @@ -9,6 +9,13 @@ Thoughts about software, computers and whatever I feel like sharing </description> <item> +<title>The big rewrite</title> +<link>https://sebastiano.tronto.net/blog/2023-04-10-the-big-rewrite</link> +<description>The big rewrite</description> +<pubDate>2023-04-10</pubDate> +</item> + +<item> <title>The man page reading club: dc(1)</title> <link>https://sebastiano.tronto.net/blog/2023-03-30-dc</link> <description>The man page reading club: dc(1)</description>