I fixed it by installing Shazam. Since then I haven't paid any attention to it.
HamsterRage
"My nipples explode with orgasmic delight".
That's a little confused. From what I remember, it's the server that matters, not the domain when being blocked. If you self-host this is a problem, but not if you use your own domain on a commercial service.
The "MX records and such" are all a function of domain management. You'll have to do this whether or not you self-host.
Except I'm not actually talking about spelling, per se, but about attention to detail. Spelling errors in a resume is just sloppy rubbish.
As an IT/Development manager, I only had one role that I hired for where the skills for getting the job matched the skills for doing the job: Business Analyst. Not job entailed presenting information clearly, both written and verbally. So I expected the resume and cover letter to be organized and clear.
Programmers, on the other hand, I wouldn't expect the same level of polish. But I would expect a complete absence of spelling errors and typos. Because in programming these things count -- a lot.
A lot of the people that applied, and that I hired, did not have English as a first language. So I gave a lot of latitude with regard to word selection and grammar. But not spelling. Use a goofy word or two, but spell them right.
I figured that most people were highly motivated when writing a resume -- about an motivated on you can get. And if not level of motivation cannot get you to take care, then you'll just be a bug creation machine if I let you touch my codebase.
Proper pickled onions and Branston pickle.
Bob's Red Mill makes an adequate substitute. It's not as uniform as McCann, but it is good.
Written by a Canadian Much Music VJ.
I totally agree on the toasting, but note that it means the oats take longer to cook in the water. Also, I use a 2:1 ratio of water:milk instead of just water.
Also, also, I add a handful of rolled oats when the steel cut oats are nearly done.
I remember that you could get close to this by running the same card into the keypunch several times, typing different things each time.
I spent 30 years working with derivatives of the Pick Operating System and its integrated DBMS. Notably Universe and Ultimate. Back in the day, it was very, very difficult to even explain how they worked to others because the idea of key/value wasn't commonly understood, at least as it is today.
I was surprised at how similar MongoDB is to Pick in many many respects. Basically, key/value with variant record structures. MongoDB uses something very close to JSON, while Pick uses variable length delimited records. In either case, access to a particular record in near instantaneous give the record key, regardless of how large the file is. Back in the 1980's and earlier, this was a huge advantage over most of the RDBMS systems available, as storage was much slower than today. We could implement a system that would otherwise take a huge IBM mainframe, on hardware that cost 1/10 the price.
From a programming perspective, everything revolves around acquiring and managing keys. Even index files, if you had them (and in the early days we didn't so we maintained our own cross-reference files) were just files keyed on some value from inside records from the main data file. Each record in an index file was just a list of record keys to the main data file.
Yes, you can (and we did) nest data that would be multiple tables in an SQL database into a single record. This was something called "Associated Multivalues". Alternatively, you could store a list of keys to a second file in a single field in the first file. We did both.
One thing that became very time/disk/cpu expensive was traversing an entire file. 99% of the time we were able to architect our systems so that this never happened in day to day processing.
A lot of stuff we did would horrify programmers used to SQL, but it was just a very different paradigm. Back in a time when storage and computing power were limited and expensive, the systems we built stored otherwise unthinkable amounts of data and accessed it with lightening speed on cheap hardware.
To this day, the SQL concepts of joins and normalization just seems like a huge waste of space and power to me.