Posted on April 28th, 2009 in JavaScript
JavaScript as a language has a reputation of being both flexible and quirky. One such area of its flexibility is in how functions can be assigned, nested and returned just like any other data-type. However, as functions can execute code while nested many objects and functions deep, keeping track of scope becomes very important. But, scope in JavaScript can be pretty loose. For this reason, keeping a function’s scope consistent can be tricky.
The good news is, once you know what to look for and understand how to use some of the tools JavaScript offers, keeping scope bound to the data you want is actually very easy. To start learning how to keep your JavaScript scope in check, clone the companion code for this tutorial from github and start following along. Read the rest of this entry »
After some finishing touches, I am finally making my latest project public, JS-AES. I built this implementation to help me better understand how JavaScript handles data types while also getting a stronger grasp of the AES. This is a full implementation in Counter mode and is neatly packaged within the AES namespace. All you have to do is construct two new cryptos with a secret key and synchronize them.
The source code is located in its github repository and is based on FIPS-197.
Posted on January 11th, 2009 in Ruby
Symbols are quite an interesting, and often ill-understood, facet of Ruby. Used extensively throughout Rails and many other Ruby libraries, Symbols are a common sight. However, their rational and purpose is something of a mystery to many Rubyists. This misunderstanding can probably be attributed to many methods throughout Ruby using Symbols and Strings interchangeably. Hopefully, this tutorial will show the value of Symbols and why they are a very useful attribute of Ruby.
To help out, clone or download the companion code from its GitHub repository. From there, start reading along. Read the rest of this entry »
Posted on December 21st, 2008 in Ruby
Blocks, Procs and lambdas (referred to as closures in Computer Science) are one of the most powerful aspects of Ruby, and also one of the most misunderstood. This is probably because Ruby handles closures in a rather unique way. Making things more complicated is that Ruby has four different ways of using closures, each of which is a tad bit different, and sometimes nonsensical.
There are quite a few sites with some very good information about how closures work within Ruby. But I have yet to find a good, definitive guide out there. Hopefully, this tutorial becomes just that. To further help you along, all the code used in the following examples can be cloned from its GitHub repository. Read the rest of this entry »
RSpec continues to gain popularity among the Ruby community, and rightfully so. With RSpec, testing becomes much easier, and dare I say, kind of fun. The reason RSpec is great (at least for me) centers around two things, nested test cases and easy to write matchers. However, as much as I see RSpec users taking advantage of the former benefit, I still do not see many writing custom matchers. As such, this tutorial aims to show how simple and flexable RSpec matchers are.
To get up and running quickly, clone the code from its GitHub repository. From there, take a look and follow along. Read the rest of this entry »
Posted on December 8th, 2008 in Ruby
Sometimes you have to grab data from websites that do not offer any kind of structured API (like RSS or Atom feeds). Whenever I come across such problems, I just go ahead and fire up Nokogiri and OpenURI. Together, you can easily snag markup and parse it into structured data. Nokogiri (saw in Japanese) is a HTML / XML parsing library for Ruby that lets you traverse and select nodesets as easily as Prototype and jQuery. As such, it makes cutting through markup quick and easy.
To get going, lets take a look at some code that scrapes a page I am pretty familiar with, my blog’s front page. Read the rest of this entry »
Quite a few people have written good feedback about my RESTful Authentication tutorials. However, there were really two things missing, how to test the service and interact with the newly available API. This feedback, along with a previous need to build a service that other small applications could use, make me start working on Authenticator, which is now open to the public starting today.
Authenticator is a RESTful account management service that can be plugged into any application (from Rails/PHP/Python apps to Flash programs to Javascript widgets). It is fully tested with RSpec and employs a few custom matchers to test HTTP response codes. It also supports multiple sites and comes with a web-based admin panel to manage everything from activating/banning users to changing invitation emails. Finaly, the code is completely RDoc’d, so you can get up-and-running with it very quickly.
Authenticator is hosted at my github page, so check it out and feel free to start using it in your applications. You can also read the Authenticator Wiki to learn how to interact with the service using both cURL and ActiveResource.
Just finished up with RubyDES, my DES implementation in Ruby. The reason for building RubyDES was two fold: To better push my ruby fu and to allow other Ruby programmers who are interested in cryptography to better understand the worlds most influential cryptographic algorithm.
The best way to read the RubyDES source code if you are new to the DES, is to first familiarize yourself with the algorithm. The best way to do so is read the DES wikipedia page and FIPS 46. You will also notice that the variable and constant names are quite terse (e.g. IP, E, PC_2, r, k). This was on purpose, as I wanted to stay true to the technical specs of the DES so that reading through a DES explanation with the RubyDES source code will allow you to follow along.
To checkout RubyDES, go on over to the github page. Also, feel free to send over any comments or suggestions (or even better, fork it and let me know when to pull).
Some pretty bad news from the Debian team. Apparently, a change made to the bundled version of OpenSSL has made key generation predictable. The issue is severe enough that the Debian team recommends you consider all affected keys compromised and regenerate them ASAP.
If you have been using any Debian distro (which includes Ubuntu) to generate SSL or SSH key material, check your version of OpenSSL. If you have 0.9.8c-1 or later, then you are affected.
Also keep in mind, any signatures made by compromised keys should be considered untrusted. As such, once you generate your new keys, you should notify anyone who you have acted as a signatory, and resign with your new material.
Read the official announcement from the Debian team here. There is also a Slashdot discussion you can take part in here too.
I am now superseding the following DSA/ELG key pair.
pub 1024D/338E2A73 2008-02-13 [expires: 2008-05-13]
Key fingerprint = 72F8 3AD5 3991 B39B BD83 6090 B92D 78F6 338E 2A73
sub 2048g/55484828 2008-02-13 [expires: 2008-05-13]If you wish to continue communicating with me securely, please use the following DSA/ELG public key, which you can fetch from publickey.robertsosinski.com or receive from pgp.mit.edu.
pub 1024D/03EE59A3 2008-05-05 [expires: 2011-05-05]
Key fingerprint = CEFC D32D A0F0 8F02 3EE4 AD55 2B31 0C88 03EE 59A3
sub 4096g/720D8A7D 2008-05-05 [expires: 2011-05-05]You can then verify this and all subsequent keys with my RSA signature key, which you can fetch from signaturekey.robertsosinski.com or receive from pgp.mit.edu.
pub 4096R/9BAE307E 2008-05-05
Key fingerprint = A098 B838 28C1 F021 4984 E6B4 7397 56A7 9BAE 307EFrom now on, I will supersede my DSA/ELG public key every 3 years, as well as whenever I deem necessary. In order to maintain continuity between any keys I make (for either professional or personal use), I will sign them with my RSA signature key.
I will only sign keys, not message data, with my RSA signature key in order to limit the amount of text associated with it. If you would like me to sign your key with my RSA signature key, please call or email me to setup a face-to-face meeting to do so.