Programmers tend to treat text encoding like the office bore. You weren’t planning on a 2-hour conversation about your co-worker’s lawnmower today? Well too bad, because it’s happening now. Text encoding is much the same, it’s always around, but we’d rather avoid it. From time to time it pops over anyway to mess up your day and fill you in about the latest nuance between a code point and a character, or something equally dull.
I learned recently that the word playwright is unrelated to write. It is, in fact, derived from wrought. A play is not written, it’s beaten into shape. In that vein, codewright ought to be a word, because I’ve never written software from top to bottom, it’s hammered and stretched until it’s right.1
My personal process usually goes like this:
Figure out what the next bit of code should be Write it Run it Check the result Failed?
This is a follow-up to an experiment on code structure. To recap, I built two versions of a back-end for a simple web app with statistics about commercial airline flights. backendA had no real design behind it, it was just whatever fell out of keyboard. backendB was a structure that I’ve been using for the past couple years, it isolates dependencies, and uses interfaces with dependency injection. The two versions produce identical output, only the structure of the code is different.
Here’s a fun list to look through: Dumb Password Rules. Most of the rules seem arbitrary, like only allowing digits, but some hint at deeper problems. For instance, preventing single-quotes. They aren’t inserting passwords into a database without a SQL placeholder, right? Nearly every site on that list has a needlessly short maximum password size. If they’re storing passwords correctly, there’s no need for this. This post will go through a few bad ways to store a password and you can see what I mean.
Let’s say you want some software built. So you hire a team of smart developers, tell them what to build, and leave them alone. Inputs will be needed in the form of computer hardware, pizza and coffee. Of course, you expect outputs in the form of status updates (no one outside the team will understand the updates, but that’s beside the point). Since you hired smart developers and gave them everything they need, you can be sure they’ll do a good job in no more time than necessary, so you don’t to bother them with schedules and such.
I recently wrote a Markov chain package which included a random text generator. The generated text is not very good. Here’s a sample, based on War and Peace:
everything Make way to a child till late and was ready or to crush the Kiev And what he said Prince I will write a leather apron under this We shall go and pressed close up that’s why they are you spent every word from advancing to write to prevent his whole army their guilt which the wounded yet dies as he exclaimed Natásha of the mountains of the inn they all and to Znaim road crossed himself up to the midst of musketry on the big windows The major quietly with cards with his lips a bleeding and all
The first time I ever heard of a Markov chain was overhearing a conversation at work. My coworker was reading generated text from a Markov chain of the King James Bible, and was commenting on how ghastly the produced text was. Here’s a sample,
Thus saith the children of the liver of God and the tabernacle and forsake my doors of the breast and she sitteth in Seir most holy in at an homer of Pharez and ye may enjoy the needy