I’ve been reading Clive Thompson’s Coders book, and it’s caused me to reflect upon the process I use for coming up with algorithms. I’ve come to realize this is one of those things which I do, but is incredibly difficult to explain to others– so this post is my effort to encapsulate “my process.”
- Become intrigued/obsessed with something (e.g. anagrams)
- Discover an online anagram finder
- Ask myself, “How would I go about building my own anagram finder?”
- Realize I have no idea, and beat myself up for not knowing
- Forget about building my anagram finder project
- Weeks later, coincidentally stumble across:
- Fermat’s notes on anagram comparison using prime numbers trick
- A code challenge to create anagram tester function
- Feel good about my areAnagrams() milestone/accomplishment
- Realize Fermat approach hits integer bit-limit with medium length words.
- Convert areAnagrams() from prime numbers to “wordDNA” approach (i.e. case-insensitive letter sorting)
- Feel good about resolving limit in areAnagrams() function.
- Days later, realize wordDNA approach can be used to create a “rainbow table” of dictionary list– and now you’ve got the basic building parts of an online anagram finder.
As I mentioned before, I’ve been working with SiteImprove’s API recently. As part of my task, I had to stitch all the data retrieved together in a large file which could be opened with and manipulated by Excel, Google Sheets, etc. Using the cfspreadsheet tag/functions seemed like overkill, so I wrote something “quick & dirty” to convert an array of structures into a .csv file.
Although the solution I came up with worked, it was tied to the headers/columns of the SiteImprove report. This bothered me, so I came up with a CFML component which transforms queries into comma-separated-value output for a more generic, reusable approach.