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.
I had a chance to work with SiteImprove’s API recently, and wanted to capture my thoughts and impressions while they were still fresh in mind.
First, the documentation was above average. Once you’ve received your API key, you can literally “test drive” particular methods within the documentation, right below the area where that particular method is explained. You see everything, the response, the headers, etc. which comes in handy when you’re troubleshooting an issue.
Second, the “next page link” being included in the results when the amount of matching items exceeds the amount per page (defaults at 10, can be maxed out at 1000). Makes recursive requests dead simple– if the “next link” exists, drop it in as your url variable’s next value, and let your for loop continue. If the “next link” doesn’t exist, break out of your loop. And the “next link” already has the correct url attributes appended to it, so you don’t need to worry about updating it or dealing with page number and items per page in your code.
Ok, so what did I *not* like? SiteImprove uses header responses to convey information about your current rate limit (e.g. 50), how many requests you have remaining (e.g. 25) and the rate reset (e.g. 5 seconds). That’s right: integer, integer, string? Why they didn’t keep the last one an integer and opt for milliseconds (e.g. 5000) is beyond me. But if slicing off the text and converting the result to milliseconds for a sleep() interval is the worst thing I have to complain about, that’s pretty good overall.