Apparently, as a joke some time ago, I signed up for the beta API. So I decided to develop a Perl module allowing easy use of the Formspring.me API. You can follow the development of it on my github. I plan to release this code to CPAN when I’m done so that other people can use it.

Since I’m new to the CPAN world, if one of you astute readers notices something blatantly wrong about my code, I’d appreciate it if you’d point it out.

Here is the Hello World file I wrote:

1
2
3
4
5

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
    DISPLAY 'Hello, World'.
    STOP RUN.

Seems pretty easy, right? Well, yeah, no duh. It’s Hello World. I grabbed it from a Wikipedia article. It’s not exactly innovative genius. However, compiling it and linking it is a different story.

I tried at first using the ISPF foreground COBOL compiler. However, this was very non-obvious, and the documentation was lacking. All the documentation I found consisted mostly of how to do it through TSO, where it made mention that an ISPF interface did exist.

So then I went the JCL route.

IBM has some great documentation on how to do this. However, it is definitely not in the 900+ page Enterprise COBOL for z/OS Programming Guide. That was really just confusing. Here is the great documentation. This is what got me off the ground.

My JCL ended up looking like this:

1
2
3

//CLGP JOB
//CLG EXEC IGYWCLG
//COBOL.SYSIN DD DSN=HLQ.EXPERIME.COBOL(HELLO),DISP=SHR

It’s really pretty simple. The first line just declares the name of the job (CLGP), the next line executes the terribly named COBOL compile, link-editor, and run JCL procedure. IBM wrote it so you don’t have to. The last line just loads the dataset member that contains all of the COBOL code.

See? Mainframes and COBOL are THAT easy!

FAI was really painful to test, as well as significantly more painful to manage. LTSP allows us to only update one machine, and install upgrades without having to reboot the machines to receive the softupdates (the FAI way).

One machine, in this case a virtual machine on CSH’s Xen cluster, runs all of the software for the clients. The terminal client connects to the terminal server’s login prompt until the user logs in. Then the client automatically ssh’s (with X forwarding of course) to the server and subsequently runs all of their software off of that.

It is bandwidth heavy (on that segment of our network anyway), but it works very well. The clients are just as fast with the X forwarding as they would be with a locally installed OS (these machines are ultra slow).

Really, there isn’t much to say other than FAI is terrible. Related: I plan on setting up puppet at some point for myself.

I am however, taking a Mainframes course at RIT this quarter. It promises to be relatively exciting. In it, we get to learn the intricacies of z/OS, and how to manage one of those beasts. That’ll be fun. Surprisingly, there’s a programming project towards the end of it (it’s surprising because it’s a Networking and Sysadmin course, we don’t program much). And since I’m learning how to administer and use mainframes, I thought to myself, “Hell, let’s do this project in COBOL.” So here I sit, trying to find a decent COBOL tutorial on the internet.

If anyone finds one, please send it to me. It’d be nice.

Since we ran into a spot of trouble using OAuth with the Twitter4J library, I decided to give a bit of a brief tutorial on how to get it working on App Engine. There is actually very different than the code in my as I do some more error checking, and need to do some other stuff with my datastore.

Twitter4J OAuth Overview

1. Set the consumer key and secret for your twitter object with setOAuthConsumer(key, secret)
2. Get a request token with getRequestToken(callback_uri)
3. Persist the request token somewhere, we’ll need the original later when we need to get the access token.
4. Redirect the user to the URL returned by getAuthorizationURL()
5. Get the persisted request token, setOAuthConsumer again.
6. Call getOAuthAccessToken(request_token, oauth_verifier) to get an access token
7. Persist that token with the user data, you’ll need this everytime you want to authenticate.

Some incomplete example code

Please note, this is not code I actually have in production anywhere. It’s original code just for the blog.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public String authenticate() {
    TwitterFactory tf = new TwitterFactory();
    Twitter twitter = tf.getInstance();
 
    // This is actually really important, as Twitter WILL NOT send you back the oauth_verifier if
    // you don't provide the callback URI, even if you provide a callback on their site
    twitter.setOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);
    RequestToken rtoken = new RequestToken(CALLBACK_URI);
 
    // This is a special class that just relates the token to the RequestToken object in the app engine
    // datastore. The token string itself is the key.
    OAuthTemp temp = new OAuthTemp(rtoken.getToken(), rtoken);
 
    // Our persistence manager is named pm
    pm.makePersistent(temp);
 
    return rtoken.getAuthorizationURL();
}

The second bit of the code gets called when the user is returned to the page. You need to get the oauth_token and the oauth_verifier GET variables and pass them to this function.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public void authenticatePartII(String oauth_token, String oauth_verifier) {
    TwitterFactory tf = new TwitterFactory();
    Twitter twitter = tf.getInstance();
 
    // Get the temp object out of the datastore, and get the old RequestToken
    // Yes, it MUST be the old RequestToken. Or at least, have all the same parameters
    // as the old RequestToken.
    Key k = KeyFactory.createKey(OAuthTemp.class.getSimpleName(), oauth_token);
    OAuthTemp temp = pm.getObjectById(OAuthTemp.class, k);
    RequestToken rtoken = temp.getrtoken();
 
    // You MUST provide the original RequestToken and the oauth_verifier passed to you by Twitter
    twitter.setOAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);
    AccessToken ac  = twitter.getOAuthAccessToken(rtoken, oauth_verifier);
 
    // You really don't need the RequestToken information after you got your AccessToken, so
    // delete it.
    twitter.setOAuthAccessToken(ac);
    pm.deletePersistent(temp);
 
    // However you store user data, you ought to associate the AcessToken object you
    // just got with your twitter user, and pop it in the datastore. I'll leave that bit up to you.
}

That’s all there really is to it. The Twitter4J library isn’t the best documented library, and just looking at the Javadocs and the Desktop-centric code examples isn’t really that helpful. I hope this clears up some confusion on how to get Twitter4J working with OAuth.

So I got bored and decided to make a really an awesome web 1.0 page for apt-echo, as well as off it for download. I even set up a github repo for it. If you want to see the site, it’s right here.

So go ahead, install it. Maybe someone will find it useful one day. It’s slightly faster than aptitude search, and it has few dependencies. Send me an e-mail if there are bugs. Or if you like it. Or if you found a way for it to be useful.

The interpreter was the easiest; it took me a morning to get that working albeit without support for nested parens. After that, I decided to write a text to Brainfuck converter, which (not surprisingly) turns text into executable Brainfuck code. Maybe if I get bored again, I could write a module to output the equivalent Perl or C code given some Brainfuck code.

This was my first real project using object oriented Perl. In all honesty, I like that Perl’s object system allows for many different types of objects (objects can be scalars, arrays, or hashes) and how flexible that is. Unfortunately, I didn’t get to exploit that flexibility in my code. It’s still cool though.

What I wrote is 2 Perl modules that make up the linked list that store data generated by Brainfuck code, a Perl module that interprets and runs the code, and a Perl module that translates text to executable Brainfuck code. I know I could have used a pre-built linked list, but I thought it was more fun to write my own.

The biggest challenge was definitely writing the translation code. I could’ve done it the easy way, and just output x amount of pluses for the character code of each letter, but I decided that was the lamest way to write Brainfuck. Instead, I looped through each character in the phrase, and added some nodes in my Brainfuck code that corresponded to the tens place of each character code. Then, when outputting a character, my Brainfuck code would change the data pointer to the node that was set to the tens place of the character code of the desired character, and increment or decrement it to the proper value.

A more ideal way to do it (to generate cleaner Brainfuck, at least) is to set each of those prep nodes to the nearest multiple of 20 for each character code, and then use whichever node is closest to the desired value. Maybe if I feel like doing more with this, then I’ll add that feature (probably not).

In addition to writing all this, I also made a GitHub account. My GitHub has all the above code, so you can clone the repo if you want to see what the code looks like (it’s actually really easy to read Perl).

This whole idea came from an idea on CSH. A guy here decided to publish a “Hello World of the Week” article in our newsletter, and to combat him I wrote a Brainfuck version of Hello World. This contest grew, and other people joined (albeit humorously) with such contributions as a boot loader that printed out Hello World, Hello World in White Space, and Hello World in Microsoft Word. My contribution (also in my git repo) generated valid Brainfuck code for the phrase Hello World, and then ran it through my interpreter (aka Hello World in 425ish lines).

The biggest issue (so far) was file uploads. So here’s a quick tutorial on how to do file uploads with perl, with mason.

In index.html (or wherever your form HTML code lives):

1
2
3
4

<form method="post" action="upload.mas" enctype="multipart/form-data">
  <input type="file" name="file_name" /><br />
  <input type="submit" value="Submit" />
</form>

In upload.mas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<%init>
    use Apache2::Upload;
 
    # $r is an Apache2::RequestRec, not an Apache2::Request like some places say it is
    my $req = Apache2::Request->new($r);
 
    # file_name refers to the form name you had in your HTML
    my $upload = $req->upload('file_name');
 
    my $fh = $upload->fh;
    open OUTFILE, ">$where_ever_you_wanna_save_the)file";
 
    binmode $fh;
    binmode OUTFILE;
 
    print OUTFILE $line foreach my $line (<$fh>);
    close OUTFILE;
    close $fh;
</%init>

In your httpd.conf:

APREQ2_READLIMIT 2G # Sets the max size of your user's uploads to 2GB

I intentionally skipped over error handling code and all of the httpd.conf config for the sake of brevity (I did say brief tutorial). Since I need to allow for larger file sizes than Apache does by default (64MB), I spent quite some time looking for that Apache directive.

Hopefully this saves someone some time.

So Google Wave is pretty awesome. It’s ridiculously buggy, but it works well enough if you aren’t using it in a production environment. I have yet to try out any of the multimedia stuff beyond embedding YouTube videos in Wave, but I imagine it works just as well as everything else does. I’ll probably talk more about that when I’ve played with it.

What I’ve really been playing with is the Wave API, in Python of course. The jist of what I’ve been reading is that the Java API isn’t as up to par as the Python API. Also, I hate Java, and I hate writing code in Java.

The Wave API is built off of Google App Engine, and has all the same limitations as App Engine. My roommate and I kinda half started working on an NNTP gateway to Wave. Unfortunately, the limitations App Engine sets makes this a little more difficult than we’d like (no sockets or anything of the sort).

The one thing I’ve come across in the API that I don’t like, is that you *must* include the entire Python Wave module in the app directory that you upload to App Engine. Not a huge issue, but definitely a bit of an annoyance. The only real problems I see are the possibility for people to modify the version of the Wave API they upload, and that the version of the Wave API they upload is outdated.

Another issue with using App Engine as the platform for all of the Wave code and such, is that you *must* use Python 2.5. App Engine doesn’t work with anything higher than that. So even though the Wave development site says you can use Python 2.5 or above, the above part is really a lie.

The good news: Google Wave won’t forever be reliant on App Engine. Sometime in the future, they will be allowing Apps from anywhere. This is will be awesome, and I can’t wait.

Oh, and I had other productive things I was gonna do this weekend, but they all got shot to hell when I got my Wave account.

Now you can wave me at ay1244@googlewave.com

I also got a bunch of the abstraction for my CS project done today. But that wasn’t that much code. Oh well.

Also, in the middle of this post, got roped into helping fix our Xen management interface. And by help, I meant I installed Ubuntu server (ugh) on a machine and installed openssh. Woo.