brian hefele's untidy space

Couple of minor developments on the scorch front. First, I have a rough flowchart whipped up. There are likely flaws in this chart, but I wanted to quickly get my thoughts diagrammed out. PDF, or Graphviz/DOT.

Development two is more or less just a vague thought. Since the main goal here is correspondence chess, and nothing terribly intensive, efficiency probably isn't the highest priority. Some sense of modularity could be achieved, at the expense of efficiency, by writing the FEN handler in C (or whatever) and leaving the rest of the task to builtins and shell scripting. So, our FEN tool would only really need to be capable of a few things - parsing FEN, turning FEN into a human-readable representation of a board, parsing movetext in algebraic notation, and applying said movetext to FEN.

The FEN tool could then be useful for other things as well:

• Just displaying a board, given FEN
• Just manipulating FEN (FEN and movetext in, FEN out), without display
• Generating FEN from nothing (normal game start, 960)

…and the shell script would just handle the input, watching files, output side of things. This modularity would pave the way for a shell script to handle visually traversing PGN as well. This is all still a bit of a pipe dream, but at least I'm dreaming it out ahead of time…

I've thought a lot in the past about correspondence chess, and the current state of such. There are a number of online solutions, most of them not so great. Twitter-based ChessTweets is my current favorite solution (anyone who wants a fight, @brhfl) although the constant barrage of DMs from the system does get somewhat irritating. I use the somewhat clumsy XBoard with a variety of engines for the sake of analysis, but using it for correspondence is far from ideal. This task seems the perfect opportunity to demonstrate that less is more, and create a CLI interface which acts as a somewhat dumb client for displaying a board and interpreting moves. While I will probably never actually code this, I hope that perhaps I will some day, and I will call it scorch for Simple Correspondence Chess.

Continue reading…

I have applied for hundreds of jobs in the past few months. One thing that I have noticed is that (almost) all the web software related to job hunting and application feels ancient and clumsy in a web which generally tends toward either being clean, quick, and stable or flashy, but functional. The other prime example of this sort of 'old web' mentality is in forum software - somebody needs to step up and design the WordPress of forum software so that I don't feel like I'm hanging out on Geocities. Part of the problem with many of the job applications are their forms which simply don't provide good usability. A common application doesn't show the 'State' dropdown until you've chosen your country. This means that you can't tab from country to state, because state doesn't exist at the moment of tabbing. So you enter country, tab to ZIP (or something), shift-tab up to state, and then tab around a little more to get back in the game. Another common annoyance is the form that requires your phone number in a specific format.

This is a similar problem to that of not stripping punctuation from numbers, a task trivial for code to handle on the back end. Yet many websites still insist we don't hyphenate our credit card numbers, don't put any punctuation in our phone numbers, etc. No separators in a long string of digits is not the best as far as readability (and therefore entry) is concerned. The problem gets a little stranger when they instead force a specific method upon their users. Again, stripping the formatting and then reformatting it however you wish should be trivial to code, let the users enter it in a way that befits them. But, all this is just segue into my real point - the (301) 555-0505 format.

Continue reading…