 the talk at a conference where she can feel how something's going on inside, it's pretty terrible. I know that everybody's having a good time so far and hopefully we can continue that for the next 30 minutes or so. So Ruby card, hypercard in Ruby was an answer to some hypercard, as it turns out hypercard was a very fast and really cool program we'll talk about it a lot here shortly. And I really wanted to use it as a way to do sort of a favorite kind of Ruby project. So I'm happy with the progress I made, but we're not selling any copies of Ruby card at any point of time. Okay, so I'd like maybe a brief but hopefully historically accurate description of hypercard. Bill Atkinson is the name of the hypercards created along with his team. He also created Mac paint way back in the 80s. Pretty visionary guy, he's still doing stuff mostly on a wild type of photography now and he has a couple of apps on the dashboard. He worked for Apple and that very pitiful time where they were running out the Mac and the Mac Plus and really moving the computer to the end of the long-term speed. Hypercard is a hyper-lidia software system. Of course, we don't have hypertext. Hypermedia is just slightly less specific because you couldn't do input text. I did in hypercard, the idea was that you could go to objects on the screen to do different types of things and stuff. So pretty close though. You're creating stacks of cards and a card could have fields and buttons and backgrounds and pictures and stuff on it and 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 like a roll of text or something like that. Or all of the cards would be totally different like the similar thing is getting missed in the YST. What's the regime you 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, be a consumer of 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. But this is kind of pretty website days for most people and the idea that they can power a computer letting people create your content as well as you and other people's styles. That's pretty neat. Bill said this at a talk recently while maybe a couple of years ago. Hypercard was kind of like the first deliverable web browser, a chain to a hard drive. They didn't put any sort of network into hypercard. And he said a couple of times he would mention not pursuing that further because beyond that, he basically built a web browser and created a content. So the first version was published in 1987. At the time the internet looked like whatever this is. I don't know, this is our event and 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 and set it up. So 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 but it went well beyond that. Hypercard had some pretty powerful scripting features. Elements like buttons and a card could have user programs, scripts that were executed when you put the button. And your hypertoc, it was a language created for hypercard. It's pretty unique for the time. Sorry for that caveat, I didn't get the time to write about it. I've been talking to a few people and we're going to set up a little bit. We'll make do, I think I'm not going to switch. Hypertoc had transparent data types. You basically just type words. I didn't say this is a number, this is a string or anything like that. There were licenses and data structures. Things that you would write up tended to look like this. Put the value of card field, put some field into the bar value. And it went well beyond that, obviously, but I think that's a pretty good example. With this hypertoc language, you can control cards, stacks. Even with computer itself, infamously you could use Apple's a telephone dial protocol to add your hypercard stack.com. I have a short little video here. I love this video clip and it's part of a bigger segment for both how dated it is now, how these guys were sort of interacting with this old computer. I like old computer stuff. I watch a lot of videos on YouTube of old software and things and just like to share a little bit of it. Button, you can see it's script which is its brains. This message box here where we've been typing commands like find can do a lot more. It can do calculations there. You can, you know, it's about the value of the pie and it's all about functions. It knows what the date is or what the long date is. Oops. Come on. So let me stop the timer. We can get a little commands like go to next card like that. If you look inside one of these little buttons, you'll see that it's brains actually say go to next card. That's not a button. No, it's not a button. This is a script for that button. This is how a customer views with the exit program. Yeah, so really you just have a little box in every button or field or whatever and I don't know if you can see it was a little bit green in there but you basically just have a little block that's set on mouse up and you can type your sentence in there and you can do stuff. And the important thing to stress of course is that this is waiting for a lot of things, like Ruby came about that was meant to be connected to a button and stuff like that. A couple of other things that hyper talk or hyper card 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 sort of used to getting a O and WQ or like an S or something like that. But as you changed the stack, they would just change and it could actually lead to some point of results of people mob-filing their own card and then come back in the next time and it's all walking through. There was fast text searching which was revolutionary through the time. There was a small mobile cell. I don't really know much about bitmap packing but it sounds really impressive. So if I did, you wouldn't have accomplished that. And it also had graphics and emulation. Draw graphics you could cut in these images inside the stacks which was pretty stunning through the time. And this is sort of what it looked like. You can see in here a classic OS9 interface here. This is the home card that has some 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 hyper card, you can actually find your own things over on. Okay, so now we have to talk about Rubycard. It's a project that I embarked on a few months ago while sort of formulating this whole talk all together. My motivation was this. Ruby is designed to be human. You know, to be enjoyed for someone to write to sort of read like humans speak. I was wondering if Ruby would be used to do scripting or other things besides that development like scripting through the elements much like your microphone. And then to get a step further, can we use Ruby to name the whole Ruby itself? We can. We can. That problem's been solved. The cool thing about Ruby made a very mature life with the Mac set, but it's virtually 25 years old is that there's a Ruby solution for just about everything. So, your GUI Shoes. Shoes is a GUI tool kit that was originally written by Wiley Stett. Here he is. And there's actually a talk on Shoes. This is not planned at all. It just happened to Ratcho's, to you Shoes and Jason's very passionate about Shoes. So I would highly recommend that I go. This is the end talk. I think it might be tomorrow. He's gonna talk about how they're moving Shoes from native implementations to using the GDM. So, that's pretty awesome. Okay. So, a couple more things about my motivation here. Ruby's fun to write. I like writing. 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 having it for the sake of that game. And sometimes we don't get to do that. So, let's do something totally different. I mean, you're good. So we sit down now. I'm kind of learning Shoes. I'm messing with Ruby. I'm having a great time. And all of a sudden, I wrote a monolithic like giant Ruby file, all this stuff. But it's a lot harder to navigate. I wanted to write the rules. I did it. I have no regrets, but there's a reason why I tried to encapsulate behavior and it's a pretty concerning. He's still a bad part of stuff. I will look at a couple more snippets of this later on, but just as a warning, even if you go off the beam, traffic might fall off the side of the line. I was kidding. Seriously, just, you know, sometimes it's nice to have fun. Okay, so a 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 like a funny little thing here where you could either pass in a hash or a collection of Armenian state-to-date objects. You know, just one of those little wordy things that you see sometimes. That little constantize method there. I didn't really feel like writing that, so one of the cool things about Ruby and the way that it runs is that you can just steal the things from on. So I just copy and paste it to that effect and support it. Like I'm going to have to write that. You can do that with just about anything. We're going to just open up the active model items and support 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 you don't need to send too much. Basically, you can instantiate it with a bunch of attributes and that's this one thing called net-in-sin here, and that's kind of weird, but the reason I had to do that is that I actually have two different button definitions. Again, the specifics are that important, but I found out using the shoes that if I wanted to create a widget, it was like a button. Shoes kind of overloads their widget class, the instantiated in a way that they sent some shoes, which means that it wouldn't really work and you just want to create an immersion of it. So I ended up with sort of this weird model in view where my cool button is my shoes' element and my model is these buttons, so it's funny now that I turned out, I guess I could have really acted together to get all these things in the one, but. Yeah, so moving things around is also important. I wanted to read things about the type of part is that when you put it in the field, you can try it around the size of it, but it's in the buttons. You can do that too. Shoes provides some nice little, interaction in the box, it'll give you the buttons that you can read that are coordinates. So once we have that, we can write a method called assign a element that basically kicks your viewport, looks at all of the elements, and then finds one that is underneath your apps at the time. I imagine anyone who's familiar with doing this kind of like Kim's job script, it was sort of new to me, so I was, and 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're gonna be able to drag it off of the screen or resize it out of the screen, so you're moving it here to our folder, pretty fun to encode, but it was fun to find a right and fun to mess with and very satisfying to get right. One more thing we needed was button scripting. As I said, I didn't get it to hyper talk, but we can do our best to do like a nice little thing in place of it. If anybody saw this line from one of the main slides, it's a straight, I guess we were getting it, so I imagine you know where I'm going. I never use it for anything really, but it's pretty cool when you just put a string in there and it runs in like Ruby, which is a lot, a lot more, and surprisingly it works, I don't really know how many terms work, but it's a good research project with the teacher. Also, I don't know what this does, but I'm sure it'll actually work. I don't know, I've never tried it. And then finally, we have graphics, we've got things and drawing and stuff like that, but unfortunately the best way to plan is just didn't have that time to get to it. So hopefully in the future, in Ruby card version 0.2, we'll have graphics and we'll be able to send Ruby talk or whatever we can build. So let's say action-oriented saving instead. This one's kind of fun, we're gonna save that. And whenever we call save, we're gonna go through our current card, grab everything in the card and serialize it and then just write it to a file and chase it on. And I was really wanting to do like a very complicated, like writing out data bits or in the way that other cards are doing save things, but this is much easier. It produces something like this, which our program can then interpret later on using that picture. So it's time to take a look at the hypercard, the Ruby card and put it right here. So this is what it looks like on the startup. This Ruby bit here would be sort of like the home stack or something there. So let's go ahead and create a new stack and let's call it and we have a bunch of tools and a bunch of buttons. So for our first card, let's just say something nice about Ruby card. So 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 interactor and the other two options were sort of like the modifiers. So if I wanted a modifiers field, we can double click it and we could give it a name. We don't really need to, we can go ahead and get the font size and actually type the word or two and make it look nice enough to resize that to it. And then we can add a button. The button to go down here. And we have a script right now just puts type. It doesn't really do anything useful. So I have a couple of internal methods to find. You can see this for some of those later if you want, but for now I'm just typing in the same nice card. So we go back to the hand because we want to interact with the button, but nothing's happening. Well, we only have one card, so I guess we can add a card. So while we play the card, and if we get a previous and then the next, here are our next cards. You know, we can do the same thing here add to more text content when I move to say, but why don't we do something cool scripting real quick? This first field we will call A. Go ahead and put it in text. Have a problem with the font size. Say, if you do the same, what does it mean to write a text? Is someone larger size? Say, what a button. Say, in this script, I'm not going to try to type it out because I know we're making mistakes. I'm just going to copy things, but I'm sure you might be right. So we'll put this in here. Death Calculate. We'll say element named A dot text and element named is another sort of convenience method that I define to say element. Your next is a stairway to that. Do we need to do that? Well, let me just describe this going in case the building's going to burn out. So element named 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 another element. So we're going to click Save here. Go to our interaction and we'll say element plus two and then calculate and we get a three. So we now basically emulated that script and we'll be able to set what is in Ruby and what we're all working is so that's probably 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 click here, we'll click this. We can actually shell out two of these in Ruby. So. It'll really have a barf line here so it's just going to say something. And then for that, we're going to click on the text. Save that, go ahead and click it. Over to my new year and here's the other script. So we actually have a lot of the capability with Ruby that I could talk to users of that then. You know, just more oriented for two years. So that's kind of where I'm at. We have fields and buttons. We can move them around, we can resize that. Everything we do is saved and we can open up that file. If we go to open stack, so you save your account here. If we open it back up now, we can fresh it up all our stuff is out there. And that's really great. So we sort of emulated that feature and we have our scripting as well. And it's all right with Ruby machines. So you 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, nine hours a day, you know, stuff that seems to be precise and well-tested and having to scrutinize. We can step away and we can use our level of Ruby and do something interesting. Games, music, desktop apps. Making art. There's another talk. If you guys have like a working time machine, you can go back to this one thing and see this talk about Ruby 2D. We're gonna talk to the video later, yes. Well, I can't see your account, it's really good. I took a look at that website right here. Looks very impressive, right? There's a bunch of other really cool things that I'm working on. Ruby motion. Card was a really cool piece of software and not just hypercard, but the history of computing is the area where the 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 it. 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 about Ruby where you can actually fire all of the matter. And use hypercard, it's a lot of fun. And Sheep Shader is a Mac, I know that you can run both Ruby on the computer. So I want to create a customizer for you or S9 for all of your spreadsheets on it. My review of your adoption for that takes about 20 minutes to set up, but you did it. So I'm projects expand to fill the space of their container. I learned this all the way. I've done some stuff in the past never with any sort of time limit. So just kind of working on it when I felt like it. The time crunch became really real with this project. The snacks, they brought out snacks so fast. Oh, it's the snack. But the snacks are not false, right? The snacks are real, but they're good. Continue to sell some, we can do it all in a second here. The thing about working on a side project under a time crunch is that you saw sort of fail to get a few things done for Ruby card for this talk. There's always tomorrow and actually make it next month. But my recommendation would be if you have a time box a lot of time to make something really scoped down. Fun take away is part new or in your loans after all. If you're feeling constrained by day to day to go to each job, this is why I'm saying about we want to produce really great quality code for people that pay as many code, but feel free to break the rules when you're sort of hacking on your own time. Not everything has to be 100% tested or 100% encapsulated. You can have a great big monolith file really well for whatever happiness here as opposed to shippable code. The other thing is that JRuby is pretty amazing. I've never used it before in Lakuta. So those people who made that because the new inspiration of Shoots uses JRuby and it was bonkers. Just calling Java methods and classes and stuff directly from Ruby did come to my mind. So like that add listener 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 into the SWT widget to extract font size data and kind of all 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 of Bill Lackinson at a young age, just like that picture. That is the signal that I have on our slides and things to talk about. I appreciate you guys listening and if you've had any questions about being bad at programming, I'll dance.