Long time Apple II writer, publisher, and advocate Joe Kohn, best known for his work at inCider/A+and Shareware Solutions II, passed away this week. A2Central.com has the story.My deepest sympathies to Joe’s family. While I have not had contact with him in several years, there was no one more supportive of the Apple II.

Good luck!

A record is like a variable on steroids. In ORCA/Pascal, it’s a “type”, meaning it’s a type of variable. What’s special about a record is that it allows grouping of several other types of variables, making it like a “super variable.” The example Mike gives is a deck of playing cards; each card has a number and a suit. To see how this would be declared in Pascal, the example goes:

type
card = record
s: suit;
v: value;
end;

Each card variable is a record, and that record has two of its own variables, s for the suit and v for the value. Presumably suit would be either spades, clubs, hearts, and diamonds, and value is between 1-13 (or, since not actually clear here, among 2-10 and Jack, Queen, King, and Ace).

Let’s use another example: Twitter. My guess is that if you’re on the Internet (which you pretty much have to be to read this), you’ve heard about Twitter by now (or you just go to this site and nowhere else). In any case, I’m continuing to try and finish up my Twitter NDA, aka IItter, which is really close to release. In doing so, I learned quite a bit about data that Twitter puts out for each “Tweet” (each individual posting to Twitter).

For instance, if we fetch some Tweets from the m.twitter.com server (the “mobile” version of Twitter, although I think this is essentially the same as we’d get from the non-mobile server), we see an individual Tweet’s raw XML would look like this:

<status>
<created_at>Mon Apr 06 09:31:02 +0000 2009</created_at>
<id>1461922309</id>
<text>Ms. Unreliable just came online. Is that time for me to go to bed?</text>
<source>web</source>
<truncated>false</truncated>
<in_reply_to_status_id></in_reply_to_status_id>
<in_reply_to_user_id></in_reply_to_user_id>
<favorited>false</favorited>
<in_reply_to_screen_name></in_reply_to_screen_name>
<user>
<id>1401261</id>
<name>Ryan Suenaga</name>
<screen_name>rsuenaga</screen_name>
<location>96744</location>
<description>Hawai'i's best known Apple II Geek and social worker</description>
<profile_image_url>http://s3.amazonaws.com/twitter_production/profile_images/91133166/rsp_normal.jpg</profile_image_url>
<url>http://uncommon-cents.net/</url>
<protected>false</protected>
<followers_count>588</followers_count>
<profile_background_color>1A1B1F</profile_background_color>
<profile_text_color>666666</profile_text_color>
<profile_link_color>2FC2EF</profile_link_color>
<profile_sidebar_fill_color>252429</profile_sidebar_fill_color>
<profile_sidebar_border_color>181A1E</profile_sidebar_border_color>
<friends_count>247</friends_count>
<created_at>Sun Mar 18 06:26:37 +0000 2007</created_at>
<favourites_count>46</favourites_count>
<utc_offset>-36000</utc_offset>
<time_zone>Hawaii</time_zone>
<profile_background_image_url>http://static.twitter.com/images/themes/theme9/bg.gif</profile_background_image_url>
<profile_background_tile>false</profile_background_tile>
<statuses_count>20632</statuses_count>
<notifications>false</notifications>
<following>true</following>
</user>
</status>

Now, that’s quite a bit of code! However, we may just want to look at a few of these elements–or at least, for IItter, I’m just looking at a few of these elements. All I’m interested in is the text of the Tweet, the screen name of whomever Tweeted, and the date and time it was created. So, we’re talking these three items from the Tweet above:

<text>Ms. Unreliable just came online. Is that time for me to go to bed?</text>
<screen_name>rsuenaga</screen_name>
<created_at>Sun Mar 18 06:26:37 +0000 2007</created_at>

And yes, I know this is not 2007, but that’s what the Twitter API returned just now!

Once I have those, I have the basis of the data I wish to display. I also know that the text of the Tweet is at most 140 characters; the created_at information is a fixed length of 30 characters (a lot like a standard Internet date and time string seen with, among other things, electronic mail); and we also know that the maximum length of a Twitter screen_name is 15 characters.

So, if we want to set up a record type to account for this information, we can do so like this:

type
twitter_record = record
text : pstring;
screen_name: pstring;
created_at: pstring;
end;

var
my_twitter_record: twitter_record;

We have declared a record type called twitter_record to suit our needs of grouping the text, screen_name, and created_at information together, then declared the variable my_twitter_record of the type twitter_record for our use in this program.

Since we know that all of the data returned are strings of text less than 255 characters in length, pstrings are quite useful here. With appropriate parsing, we end up setting our variables so that they have these values:

my_twitter_record.text is ‘Ms. Unreliable just came online. Is that time for me to go to bed?‘

my_twitter_record.screen_name is ‘rsuenaga‘

and finally,

my_twitter_record.created_at is ‘Sun Mar 18 06:26:37 +0000 2007‘

So, there’s a quick bit on records. It’s going to take a bit more time to get IItter done (I was hoping while I was off but many other things also needed attending to).

IItter is what’s not yet done, even though I worked on it forever (like more than a year). It’s a Twitter client in an Apple IIgs New Desk Accessory. Requires Marinetti 2.0.1, System Software 6.0.1, and a working TCP/IP connection.

Bitly is a Classic Desk Accessory (that’s right, -not- a NDA, a CDA!) that takes the text content of the IIgs clipboard and submits it to the bit.ly URL shortening service, returning a shorter version.

Screenshots (and hopefully a release!)d soon.

username:password

and then encoded into Base64. As I’ve never tried to figure out how to encode into Base64 before, I decided this would be a nice exercise for my Pascal skills.

Working backwards, I can easily figure out what the end result of the encoding is supposed to be; there are many online Base64 encoding Web pages, so the string above would be encoded as:

dXNlcm5hbWU6cGFzc3dvcmQ=

How do we get there from here?

Wikipedia to the rescue! Wikipedia provides about as close to a plain English step by step on encoding a string as Base64.

First off, each character that needs conversion must be converted to its ASCII numeric equivalent. Well, actually, first, once we have the username:password string built–which are two p-strings combined to make a c-string; p-strings because that’s an easier way for me to get input from a IIgs LineEdit dialog, and a c-string because its longer length could be an advantage depending on how long the username and password are–we need to look at it character by character. So in order to do that, we take the assembled username:password string and use a loop to parse out the characters one by one:

Procedure CharParser; {parses out each character}

Var
username, password: pstring;

parsedchar: char;
rawauthstring, binauthstring: cstring;

ploop: integer;

begin

rawauthstring := concat(username, ':', password); {combine the username}
{and password with a }
{colon between them }

ploop := 1; {parsing loop--1 for 1st character}
While ploop <= length(rawauthstring) do begin
parsedchar := rawauthstring[ploop]; {sets parsedchar to the current}
{character as ploop increases }
ploop := ploop + 1; {increment ploop by a character}
end; {parsing loop}
end; {CharParser}

This procedure, while it will run right now, isn’t useful without a bit more code that we won’t get into yet. Basically as the ploop starts with the first character in rawauthstring and moves character by character through the string until it reaches its end, it assigns the character at the current position in the loop to the character value parsedchar, then moves onto the next character. In order for this procedure to be more useful, more has to be done with parsedchar, starting with converting from a character to an ASCII value, then converting the numeric ASCII value into a binary value, padding the length of the binary value so it’s eight digits long, and adding it to a progressively growing string of 0s and 1s for further conversion. We’ll tackle some of this next episode!