Editor's Note: I found this in my drafts, dated 2012-01-25. I have opted to retain the content unchanged, merely updating links for ubiquitous HTTPS and replacing broken links as needed. Please enjoy this work of fiction.
The President saw that things took time to implement in code, and involved programmers, testers, and a deployment. As someone who liked to make snap decisions and have the results available immediately, this did not sit well in his heart. Long he meditated, then announced his solution:
Henceforth, the system would be Database-Driven.
Showing posts with label data. Show all posts
Showing posts with label data. Show all posts
Sunday, May 17, 2026
Thursday, January 26, 2012
Plain Old Data
I’m coming to the conclusion that there’s actually no such thing as “plain data;” it always has some metadata attached. If it doesn’t, it might be displayed incorrectly, and then a human needs to interfere to determine the correct metadata to apply to fix the problem. (Example: View → Character Encoding in Firefox.) Pushed to the extreme, even “just numbers” have metadata: they can be encoded as text, a binary integer/float (IEEE 754 or otherwise) of some size/endianness, or an ASN.1 encoding.
Another conclusion I’m reaching is that HTTP conflates all kinds of metadata. Coupled with the lack of self-contained metadata in file formats and filesystems, things start to accumulate hacks.
Another conclusion I’m reaching is that HTTP conflates all kinds of metadata. Coupled with the lack of self-contained metadata in file formats and filesystems, things start to accumulate hacks.
Tuesday, October 25, 2011
Character Sets: Get PHP, Perl, MySQL, and Unicode to Play Together
This post is a companion to Perl and Unicode in Brief, an attempt to cover the same ground more concisely.
This is an extended remix of my recent post on the subject, only less of a rambling story and more focused. Again, I'll start with some background definitions.
I'll also assume that you're going to make everything UTF-8, because as a US-centric American who has the luxury of using English, that's what makes the most sense for my systems. However, if you understand everything I wrote, it should not be difficult to make everything UTF-16 or any other encoding you desire.
This is an extended remix of my recent post on the subject, only less of a rambling story and more focused. Again, I'll start with some background definitions.
I'll also assume that you're going to make everything UTF-8, because as a US-centric American who has the luxury of using English, that's what makes the most sense for my systems. However, if you understand everything I wrote, it should not be difficult to make everything UTF-16 or any other encoding you desire.
Sunday, August 8, 2010
On XML and data formats
In many discussions of XML, there seems to be a faction of programmers who are completely dead-set against XML. They'll insist on JSON, or YAML, or any other cool technology that isn't supported in that 5-year-old version of whatever language your company is still running. The usual complaints leveled against XML-based formats are verbosity and the complexity of the DOM. (Sometimes, leading or trailing whitespace on element contents in pretty-printed XML will bite a project, but this never seems to come up in internet flamewars.)
The really young, or maybe just incurably naive, programmers will even chime in that anything that can be done in XML can be done, or even done better, in JSON. I even thought this once, until I tried to write a generic XML-to-JSON converter, which showed me how wrong I was.
The really young, or maybe just incurably naive, programmers will even chime in that anything that can be done in XML can be done, or even done better, in JSON. I even thought this once, until I tried to write a generic XML-to-JSON converter, which showed me how wrong I was.
Subscribe to:
Posts (Atom)