The run-on sentence can be defined as two or more independent clauses that have been joined without an accompanying coordinating conjunction. Run-on sentences carry multiple thoughts, which confuses the reader.
So what does this have to do with Ruby? Well, it is this author’s opinion that run-on sentences can be a sign of danger when describing your program objectives. Each objective within your program should be conveyed in as simple terms as possible, without having to glue together lots of disparate thoughts.
Fortunately, this is fairly easy in Ruby, as it really excels in describing complex concepts in a very terse manner, allowing you to express yourself clearly.
Internationalization is such a long word that people commonly refer to it simply as “i18n”. If it’s not already obvious, the number “18” refers to the number of characters between the “i” and the final “n”. It’s a complicated word, and similarly, internationalization can be a complicated beast to tame in your web pages, assuming you want to appeal to an international audience.
Some people approach the internationalization problem by creating entirely new web pages, which essentially results in a parallel website for each language. I don’t know about the latest version of Drupal, but Drupal 5.0 forced you into this very paradigm. What a nightmare to implement this approach and maintain a parallel website for each language! The situation gets really complicated when you want to link to another page within a different language. You have to go through and change each link for each of your parallel websites. It gets even more complicated if a target page in a specific language is not yet available because it hasn’t been translated yet.
Topics like authentication often give me the heebie-jeebies. I worry about nefarious hackers in some corner of Beijing trying to hack into my account by somehow circumventing the authentication mechanism I put in place. To fight the situation, I would write the entire authentication routines myself, but I worry that I haven’t tested it thoroughly; on the other hand, I worry about using a library solution that I don’t fully understand and could therefore leave myself open to an attacker that does fully understand the solution.
A good compromise is to understand a bit about authentication and then use a known solution. When it comes to Sinatra, both are within easy grasp.
Occasionally I run across the need to efficiently encrypt and decrypt small messages that get sent over public media. Sure, I could use SSL, but for simple situations, I don’t need such a big hammer. What I need is a way to take a message like, “I’m leaving the key under the doormat” and tuck it away in a message that otherwise does not need security.
Below is a class called Shencrypt, with two simple methods. To encrypt a message, just put it into the argument for self.encrypt, and it will provide an output hash that contains the encrypted message as well as the IV (Initialization Vector) that helps protect against analysis by the bad guys. Since this uses symmetric encryption, the receiver has to have access to the same key. This can be solved in various ways; perhaps the most obvious would be to use an MD5 hash of the login password as the key.