talk at a conference, I wish you could feel how clean my hands are, it's pretty terrible.

I hope everybody's having a good time so far, and hopefully we can continue that for the next 3 or 4 minutes or so. So, RubyCard, HyperCard in Ruby, with an S first. Some of HyperCard, as it turns out HyperCard was a very fast and really cool program,

and we'll talk about it a lot here shortly, and I really wanted to use it as a way to do a different kind of RubyCard project. So I'm happy with the progress I made, but we're not selling any copies of RubyCard any time soon. Okay, so I'd like to give you a brief but hopefully historically accurate description

of HyperCard. Bill Atkinson is the name of HyperCard's creator, along with his team. He also created Mac Paint way back in the 80s. Pretty visionary guy, he's still doing stuff, mostly on wildlife photography now.

I think he has a couple more maps on the app store. He worked for Apple in that very pivotal time where they were working out the Mac and the Mac Plus and really moving the computer to the end of the machine speed. HyperCard is a hypermedia software system. Of course, we don't want hypertext.

Hypermedia is just slightly less specific because you couldn't do intro text like it in HyperCard. The idea was that you could go to objects and scroll up to different types of links and stuff, so pretty close though. You're creating stacks of cards.

A card could have fields and buttons and backgrounds and pictures and stuff on it. You could have a stack of cards, a collection of them. Sometimes the cards would all look the same but perform different data displays such

as a Rolodex or something like that. Or all of the cards could be totally different, like some of the things getting missed in the YST was the Virginia made for Mac in HyperCard, which is pretty crazy. The whole thing about HyperCard and the thing that was really unrealized at the

time is that anyone from their own Mac could be a creator in consumer content. This is revolutionary because, as we recognize now, the idea of creating and consuming content in the same platform is realized most fully by the internet.

Make a website, look at websites. This is pretty website-based for most people. The idea that you can power the computer and let people create your content as well as you and other people's styles is pretty creepy. Bill said this at a talk recently, well maybe a couple of years ago.

HyperCard was kind of like the first glimmer of a web browser but chained to a hard drive. They didn't put any sort of network into HyperCard. He said a couple times he wanted to not pursue it any farther because beyond that you basically build a little web browser and create content.

The first version was published in 1987. At the time, the internet looked like whatever this is. I don't know, this is our internet. I'm kidding, but the internet was mostly just a research project.

It was rapidly expanding and turning into something that would become a consumer internet but it wasn't there. Bill and his team and Apple were ready to take that step. We have stacks of cards and hypermedia links.

That sounds pretty static. It sounds like you put a button there, it can link to another button or something. It went well beyond that. HyperCard had some pretty powerful scripting features. Elements like buttons and a card could have user programs get scripts that were executed

when you click a button. Enter HyperTalk, which was a language created for HyperCard. Pretty unique for the time. Sorry for that caveat. I didn't get the time to write HyperCard.

We'll make do, I think I thought we missed. HyperTalk had transparent data types. You basically just type words. You wouldn't say this is a number, this is a string, or anything like that. Other classes or data structures, things that you would write out, tended to look like this. Put the value of card field, sum field, into Bob Adam.

It went well beyond that, obviously, but I think that's a pretty good example. With this HyperTalk language, you could control cards, stacks, even the computer itself. Infamously, you could use Apple's telephone dial protocol to get your HyperCard stack.

I have a short little video here. I love this video, but it's part of a bigger segment for both how dated it is now, how these guys were interacting with this old computer. I like old computer stuff. I watch a lot of videos on YouTube of old software and things.

I'd just like to share a little bit of it. You can see in the script, which is its brains, this message box here, where we've been typing commands like, fine, can do a lot more. It can do calculations there. It knows about the value of pi. It knows all the math functions. It knows what the date is or what the long date is.

We can give little commands like, go to next cart, like that. If you look inside one of these little buttons, you'll see that its brains actually say, go to next cart.

That's how that button knows how to do a script for that button. This is how a customer reviews a program. Yeah, so really you just have a little box in every button or field or whatever. I don't know if you can see it, it's a little green there. You basically just have a little block that says, on mouse up.

You can type your sentence in there and it'll do stuff. The important thing to stress, of course, is that this is waiting for a lot of things. Like Ruby came about and was meant to be. A couple other things that HyperCard did well. Saves were kind of happening in the background while you were editing stacks.

This was kind of weird and it's still kind of weird today. We're so used to hitting OMWQ or Command-S or something like that. But as you change the stack, it would just change. It could actually lead to some funny results if you modified that one part

and then come back in the next time it was all walking through. There was fast text searching, which was revolutionary at the time. It was a small, multiple cell. I don't really know much about bitmap packing, but it sounds really impressive, so I'm glad that he accomplished that.

It also had graphics manipulation, which was draw graphics. You could cut and paste images inside the stacks, which was pretty astounding at the time. This is sort of what it looked like. You can see in your classic OS 9 interface here.

This is the home card. It has some names and things like training and all that kind of stuff. I have a link at the end of the talk if you want to try out HyperCard. You can actually find it running in some of these other funds.

Okay, so now we have to talk about RubyCard. This is a project that I embarked on a few months ago. While sort of formulating this whole talk all together.

My motivation was thus. Ruby is designed to be human. You know, to be a joy for someone to write, to sort of read like human speak. I was wondering, maybe Ruby could be used to do scripting or other things besides web development like scripting GUI elements, much like HyperTongue. And then take it a step further, can we use Ruby to make the whole GUI itself?

We can't. We can't. That problem's been solved. The cool thing about Ruby being a very mature library, as Matt said, but it's virtually 25 years old, is that there's a Ruby solution for just about everything. So...

Ruby for GUI. Shoes. Shoes is a GUI toolkit that was originally written by Michael Stick. Here he is. And there's actually a talk on shoes. This is not planned at all. It just happened to be what I chose. To use shoes, and Jason is very passionate about shoes.

So I would highly recommend that you go visit that talk. I think it might be tomorrow. He's going to talk about how moving shoes from native implementations to using JVM. So that's pretty awesome. Okay. So a couple more things about my motivation here.

Ruby's fun to write. I like writing for me. Sometimes I end up not liking Ruby when I have to write a lot of professional Ruby. I know this sounds kind of like I'm being flippant about my work or something like that,

but I really just like to be hacking for the sake of hacking. And sometimes we don't get to do that. So let's do something totally different. And maybe a new video. So we sit down now. I'm kind of wearing shoes.

I'm messing with Ruby. I'm having a great time. And all of a sudden, I wrote a monolithic, giant Ruby file full of stuff. It's somewhat hard to navigate. I wanted to break the rules. I did it. I have no regrets. But there's a reason why I try to encapsulate behavior.

Except for the concerns and all that fun stuff. We'll look at a couple snippets of this later on. Just as a warning, if you go off the beaten track, you might fall off the side of the line.

Seriously. Sometimes it's nice to have fun. So HyperCard is nice. Let's get right to it. Stacks of cards. We can do that. Here's a stack. It has a name, and it has cards. We've all seen something like this before. We have a card. Very similar. I tried to do a funny little thing here, where you could either pass in a hash or

a collection of already instantiated objects. Just one of those little working things that you see sometimes. That little constantize method there. I didn't really feel like writing that, so one cool thing about Ruby and the way

that it runs is that you can just steal the things from it. I just copied and pasted the data back to support. You never just got anything really. Just open up the active model and more stuff. Fields and buttons. These are our primary interactors.

We can do that too. Here's a button. It's a little small there, but not missing too much. Basically instantiated with a bunch of attributes. It has this one thing called method sim here, and that's kind of weird.

The reason I had to do that is that I actually have two different button definitions. Again, the specifics aren't that important, but I found out using Shoes that if I wanted to create a widget that was like a button, Shoes kind of overloads their widget class instantiated in a way that makes sense for Shoes, which means that

it wouldn't really work if you just wanted to create a new version of it. I ended up with sort of this weird model and view where my cool button is my Shoes helmet and my model is these buttons.

It's funny how that turned out. I guess I could have really acted together to get all these things into one. Moving things around is also important. One of the big things about HyperCard is that if you put it in the field, you could drag it around and resize it without seeing the buttons.

We can do that too. Shoes provides some nice little old thoughts versus interaction in your box. It gives you the buttons and your coordinates. Once we have that, we can write a method called assignment element that basically takes your viewport, looks at all of the elements, and then finds

one that is underneath your mask at the time. I imagine anyone who's familiar with doing this kind of winky of stuff in JavaScript,

it was sort of new to me. Then our final piece for moving things around is this block that's now pretty small. It's not super important that you can see all the lines, but when you're moving something

around, you don't want to be able to drag it off of the screen or resize it out of the screen. You can look in your art folder. Pretty mundane code, but it was fun to write and mess with and very satisfying

to get right. One more thing we needed was button scripting. As I said, I didn't get into HyperCard. We can do our best to do a nice little thing in place of it.

If anybody saw this line from one of the previous slides, it's a string. It has some Ruby in it, so I imagine you know where I'm going. Instantly now. I never use it for anything really, but it's pretty cool when you just put a string in there and it runs in my Ruby, which is awesome.

Surprisingly, it works. I don't really know how the internals work, but it's a good research project for the teacher. Also, I don't know what this does, but I'm sure it probably doesn't actually work. I don't know. It might. I've never tried it. Finally, we have graphics.

Cut, paste, and drawing and stuff like that. Unfortunately, the best plans just didn't have that point of view to it. Hopefully, in the future, in RubyCard version 1.0.2, we'll have graphics and RubyTalk or whatever we can call it.

Let's say action-oriented saving instead. This was kind of fun. Whenever we call save, we want to go through our current card, grab everything, get in the card, serialize it, and then just write it to a file in JSON. I was really wanting to do a very complicated writing out data bits in the way that

HyperCard return can save things, but this is much easier. It produces something like this, which our program gives you. Here's another picture.

It's time to take a look at HyperCard, RubyCard, and put it right here. This is what it looks like on the startup.

This Ruby bit here would be sort of like the home of the stack. There's nothing there. Let's go ahead and create a new stack. We have a bunch of tools and a bunch of buttons.

For our first card, let's just say something nice about reading out. Let's grab a new field. This paradigm that I haven't explained yet about the hand versus the button in the field, HyperCard made it so the hand was the interacter and the other two options were the modifiers.

I wanted to modify this field. We can double-click it. We could give it a name. We don't really need to.

We can go ahead and give it a font size. Actually, probably four or two would make it look nicer. We'll have to resize that today. Then we can add a button. It looks like that button tool down here.

Here we have the script. Right now it just looks high and it doesn't really do anything useful. I have a couple of internal methods to find. You can see the source of those later if you want. For now, I'll just type it in there and say next card.

We go back to the hand because we want to interact with the button. Nothing's happening. We only have one card. I guess we can add a card. We'll add a new blank card. We can go to previous and then hit next. Here are our next cards.

We can do the same thing here. Add some more text content. Why don't we do something cool with the script anyway? This first field we will call A.

Come in from here, text. Go ahead and give it a size. Save. Give it the same as it should be. Click text. Give it some larger size. Save. We'll add a button.

We'll say calculate. In this script, I'm not going to try to type it out because I know I'm going to make a mistake. I'm just going to copy and paste it. I'm sure you can figure out this. We'll put this in here. Def calculate. We'll say element name A dot text.

Element name is another sort of convenient method to define. Just say element name A dot text. Let me just describe this quick in case the building is going to burn out.

Element name is just a convenience method I wrote where it looks at the viewport and it grabs the thing that's named whatever you want. We're going to instance eval what we find in there and we're going to set the result to our other element. We're going to click save here. Go to our interaction and we'll say 1 plus 2.

Then we'll calculate and we get a 3. So we've now basically emulated that script ability to a certain extent. But music repeat, you're all roomies, so that's totally fine. Let's add one more button here. Just to show you that it has one other interesting feature.

We'll click that. We'll go here. We'll do this. We can actually show up too, music repeat. So here we have a part of the client queue, so let's just go ahead and save it.

And then after that we're going to tell it to copy up text. Save that. Go ahead and click it. One or two more now here.

Up text. And here's the other group. So we actually have a lot of capability with Ruby that hyper-talk uses that then. You know, just more oriented towards your user base. So that's kind of where I'm at. We have fields and buttons.

We can move them around. We can resize them. Everything we do is a save. And we can open up that file. If we go to open stack. So you save, you're going to come here. If we open it back up now, it'll refresh everything.

All of our stuff is still there. And that's really great. So we sort of have emulated that feature, and we have our scripting as well. And it's all right in Ruby with shoes. So we can go ahead and round out the presentation here. Fun takeaways from this.

Sometimes we get sort of in a rut with our programming, especially when we're working like 10 hours a day, 9 hours a day. You know, stuff that needs to be precise and well tested and have been scrutinized. We can step away, and we can use our love of Ruby and do something interesting.

Games, music, desktop apps, making art. There's another talk. If you guys have a working time machine, you can go back to this one. You can see this talk about Ruby TV. Or you can just watch the video later, I guess.

You can see right now, I took a look at that website right here. It looks great. There's a bunch of other cool tools that you can use. Ruby Motion. Hypercart is a really cool piece of software.

And not just Hypercart, but the history of computing is littered with cool pieces of software. And one of the things I like to do is just sort of, you know, try and do research. Watch videos, read books about just the way computing has evolved over the years.

And I would encourage you to do the same. Maybe just pick out one interesting piece of software or hardware from history. You can do some research about it. These two links are, the first one is the archive.room, where you can actually fire on all the maps and use Hypercart.

It's a lot of fun. And Sheetshaper is a Mac end game that you can run locally on your computer. So you don't want to create your customized version of the OS and my computer while your spreadsheet is on. You might want to give your adoption for that. It takes like 20 minutes to set up, but you're good at it.

Side projects expand to show the space in their container. I learned this part of the way. I've done some stuff in the past, but never with any sort of time limit. So I'm working on it when I felt like it. The time crunch became very real in this project.

Snacks, they brought up snacks. Oh, it's the snacks.

But the snacks are not false, right?

The snacks are real. So get yourself some in Google in a second here. The thing about working on a side project under a time crunch is that there's never enough time. And you saw, I sort of failed to get a few things done for RubyCard for this talk. You know, there's always tomorrow and next week and next month.

But my recommendation would be, you know, if you have any time lost, amount of time to make something, really scope it down. Fun takeaways, pardon me. We're in New Orleans after all. If you're feeling constrained by day-to-day coding, this is what I was saying about, you know,

we want to produce really great quality code for people that need code. But feel free to break the rules when you're sort of hacking in your own time. Not everything has to be 100% tested or 100% encapsulated. You can have a great day. Monolith file, really relevant for programmer happiness here as opposed to, you know,

shippable code. The other thing is that JRuby is pretty amazing. I've never used it before, but kudos to those people who made that because the newest version of JRuby uses JRuby, and it was bunkers.

Just calling Java methods and classes and stuff directly from Ruby did. It kind of blew my mind. So, like that addListener there, that's a Java function. Pretty crazy. Here's one that I did in one of my classes. And basically, I had to go to the SWT widget to extract font size data.

And you can kind of do it all from Ruby. And it's pretty impressive. So if you haven't checked out JRuby, definitely do that. Here's a picture of the dashing built back in some of that image. Just like that picture. So that is the signal that I run out of slides and things to talk about.

I appreciate you guys listening. And if you have any questions about being bad at programming, I would love to answer them.