2015-03-01 - Time Travel
I enjoy time travel stores. They often play with causality in ways that create situations not possible in any other kind of story. That being said thinking too deeply about time travel often ends up leading to problems. Then the entire concept just starts falling apart. Take back to the future for example.
Back to the Future is a fairly simple time travel story. Marty McFly goes back in time. He prevents his parents from meeting. He then has to get his parents to hook up so he can be born. He returns to the present in time to see himself go into the past. The problem is that the Marty going back in time at the end of the movie is not the same one that went back at the start.
When Marty returns home at the end of the movie it's shown that his family's life has been substantially changed by his actions in the past. They're better off, happier, he has a nice truck, and Biff is some kind of weird man servant. Now if his family has changed then logically he has too. Which means that the Marty going back in time at the end of the movie is likely to have a different reaction to things, and that's a problem because it means he won't change the past the same way the other Marty did.
What happens when Marty2 changes the past again? Is the entire universe in flux as different Martys keep going back in time and changing things? Are they creating an endless stream of universes? Maybe the Martys are piling up in the past and the world is going to be consumed by them. Really this is the trouble with time travel. You end up having to deal with multiple realities, multiple universes, multiple instances of the same event. Once you start doing that it becomes really difficult to have something that makes complete sense.
Personally I don't think time travel is possible because it's likely that it would destroy any universe in which it is possible.
2014-11-23 - Character Encoding: Extended ASCII
In the design of ASCII the decision was made to limit the number of available characters in favour of requiring less bits per character. This worked well for the English speaking United states that didn't require additional characters but caused problems for other regions that used languages with accented characters or languages that had non-Latin alphabets. As computers usage spread around the world the need for additional characters rose. At the same time computers standardized to the 8-bit byte undoing the data savings a 7 bit encoding provided. This gave rise to multiple encoding schemes that take the base ASCII encoding and use additional bits to encode more characters. These encoding schemes are collectively referred to as Extended ASCII.
There is no singular Extended ASCII encoding; instead there are several competing and mostly incompatible schemes. Even within a standard there were usually multiple schemes for use with different languages. Computer manufactures were among the first to develop extended ASCII encodings. The original encodings used ASCII as a base and extending it to 8-bits using the additional characters for a variety of uses depending on the region the computer was intended for. These encodings were implemented in hardware and represented the characters the computer was able to display. As computers advanced the encoding was moved into software which meant users could now switch encodings instead of being limited to the set which came with the computer. The term "Character Set" or "Code Page" was used to refer to a specific encoding among the many that the system supported. For example code page 437 on DOS systems was the same encoding built into the original IBM PC and was the code page primarily used in the United States.
ISO/IEC 8859 was developed to try and standardize these extended ASCII encodings. It contained 16 parts (With 8859-12 being abandoned) each intended to be used for a specific set of languages. Some of these parts add accented Latin characters while others add non-Latin characters such as Greek, Hebrew or Cyrillic. Later when windows was being developed they created code pages that partially implemented the original IBM code pages and partially implemented the ISO standard parts. These code pages mapped to the standard in various degrees depending on language. Other computer manufactures and software providers developed their own encoding schemes.
Language | ISO/IEC 8859 | DOS Code Page | Windows Code Page |
---|---|---|---|
English | 8859-1 | CP 437 | Windows‑1252 |
Polish | 8859-2 | CP 852 | Windows-1250 |
Cyrillic | 8859-5 | CP 855 | Windows-1251 |
Arabic | 8859-6 | CP 720 | Windows-1256 |
Greek | 8859-7 | CP 737 | Windows-1253 |
Hebrew | 8859-8 | CP 862 | Windows-1255 |
In addition to the 8-bit encodings there were also several Double-Byte / Multi-Byte character sets (DBCS/MBCS) which were created for Japanese, Chinese, and Korean languages that required a larger numbers of unique characters. Depending on the encoding in question characters could be 1-byte long, 2-bytes long or more. Again an attempt was made to standardize these encodings with the development of ISO/IEC 2022.
Language | ISO/IEC 2022 | DOS/Windows Code Page |
---|---|---|
Japanese | ISO-2022-JP | CP 932 |
Korean | ISO-2022-KR | CP 949 |
Chinese | ISO-2022-CN | CP 936/CP 950 |
Although the extended ASCII encodings allowed for standardized international use of computers it also made it very difficult to transfer information between computers. Text saved in a Cyrillic encoding rarely made send when displayed in Greek. There could even be problems if the region was the same but the system was different. This lead several people to try and create a unified character encoding that supported all languages in a single scheme
2014-10-26 - Writing
Writing and I don't always get along. A lot of times I'm not in a position to write when I'm having ideas and have difficulty remembering those ideas when I'm in a position to write. I'm a terrible speller and have issues with vowels and double letters. I will also quite regularly have issues figuring out what the word is that I am thinking of. That being said I quite enjoy writing.
The main thing I enjoy about writing is that it's a good way to complete thoughts. Writing allows me to take something that I've been thinking about, nail it down, and then get it out of my head. Thoughts change the more you think about them but writing forces you to make them static. To come up with some final version of a thought. Then once you've got that finished thought you can ignore it for a while.
The other thing I enjoy about writing is that it's a good way to learn. I find reading about a topic so that I can write about it causes me to look more critically at sources and to examine them more closely to try and find the important bits of information. I also find that writing about a topic and putting the information into my own words allows me to remember it better. The processes forces you to think about the topic in multiple ways and in the end you have a references that fits perfectly with how you think.
So that's why I write and the kinds of things I am likely to put up on this blog. Of course the second thing means that I'm not an expert on a lot of what I talk about so you should ignore most of it.
2014-05-19 - MetaWeblog API
So the other day I was reading a blog post about Windows Live Writer. It’s a word processor type application but for blogs. You can create new posts, edit old posts, and even upload pictures. It connects to the server hosting the blog and then communicates back and forth with it. I thought “That’s cool, too bad it won’t work on my blog because it’s all custom”. Then I stumbled upon the MetaWeblog API and Really Simple Discovery (RSD).
Let's start with RSD. RSD is a schema for an XML file. Clients use that file to determine which services a blog supports. It has a default location but link tags in the HTML of the blog can be used to specify another location. As the name implies this makes it really simple for clients to discover how to connect to a blog.
Now the MetaWeblog API is a type of web service that can be specified using the RSD. It defines a set of methods which clients can use to communicate with the site. The entire thing is implemented using an XML Remote Procedure Call (XML-RPC) interface. The client sends the server a bunch of XML specifying what it wants to do and how it wants to do it. The server performs the requested actions and returns a bunch of XML containing the response.
Windows Live Writer supports RSD and MetaWeblog. This means that all I needed to do to use Live Writer was implement the MetaWeblog API and create an RSD file that points to it. Which I have done and now I can post to my blog with Live Writer.
Next I need to figure out how to add my own extensions to Live Writer and figure out how to upload images.