RubyCard: HyperCard, in Ruby
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Schroeder, Zachary
HyperCard was a visionary application that gave users the ability to create, share, and browse text content years before the Internet became commonplace. We will discuss its key features and explore recreating them in our own Ruby desktop app: RubyCard.
 Hello everyone, I'm Zach. This is the first time I've ever given a talk at a conference. I wish you could feel how many of my hands are. It's pretty terrible. I've had 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 asterisk. Some of hypercard. As it turns out, hypercard was a very fast and really cool program. We'll talk about it a lot here shortly. I really wanted to use it as a way to do a 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 in any place. Okay, so I'd like to give you a brief but historically accurate description of hypercard. Bill Atkinson is the name of the hypercard that was 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. I think he has a couple of apps on the dashboard. He worked for Apple at 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 hypermedia software system. Of course we don't have hypertext. Hypermedia is just slightly less specific because you can do input text. In hypercard, the ending was that you click on objects and scroll. Pretty close though. The whole paradigm of hypercard was that 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 like a roll of text or something like that. All of the cards that we've done different like the Summer Fingers game missed in 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 on a platform is realized most fully by the internet. You know, make a website, look at websites. This is kind of a pretty website base for most people. The idea that you know, you can power a computer and let 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 he was a couple of years ago. Hypercard was kind of like the first gluemer of a web browser with a chain to a hard drive. They didn't put any sort of network into hypercard. And you know, he said a couple of times he would mention not pursuing that further because beyond that you basically go below web browser. I'm pretty often using web 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 in the set. Power. 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 on. And as well as other things. Enter hypertoc, which was a language created for hypercard. Pretty unique. Sorry for that caveat. I didn't find it right. Hypertoc and Perseverance won't be a good setup. We'll make do. I think I've not been able to switch. Hypertoc had transparent data. Dynasty basically just type of words. I didn't say this is a number. This is a string or anything like that. You can use it to write a license or data structure. Things that you would write up, tend to look like this. Put the value of card some field into barbada. And it went well beyond that. Obviously, but I think that's a pretty good example. With this type of talk language, you can control cards, stacks. Even if you computer yourself, you can use Apple's telephone dial protocol to get your hypercard stack. I have a short little video here. I love this video. 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 computers. 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 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. You can know some other value of pi. It knows all the math functions. It knows what the date is or what the long date is. Oops. Come on. So nobody stop it. We can get a little commands like go to men's card. Like that. And if you look inside one of these little buttons, you'll see that its brains actually say go to men's card. That's not that button. This is how a customer is with the exit program. Yeah. So really you just have a little box in every button, in their field or whatever. And I don't know if you can see this a little bit pretty near there, but basically you just have a little block that says on, mouse up and you can type your sentence in there and it'll 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 like using print and stuff like that. A couple other things that HyperTalk or 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. You know we're sort of used to getting all in WQ or like something like that, but as you changed the stack it would just change. And it could actually lead to some important results if you could modify the home card and then come back in the next time you consult a walking group. There was fast text searching which was really pretty serious at the time. There was a small multiple. I don't really know much about it not packing, but it sounds really impressive so I'm glad that he accomplished that. And it also had graphics manipulation which is a big piece of the puzzle for Hypercard. You could draw graphics, you could cut images inside these stacks which was pretty stout at the time. And this is sort of what it looked like you can see in here, classic OS9 interface here. This is the home card that has some things like training and a little bit of stuff. I have a link at the end of the talk if you want to try out Hypercard. You can actually find it on your own. It's over on part-time.org. Okay so now we have to talk about Rubycard. This is a project that I embarked on a few months ago. I'm also formulating this whole talk altogether. My motivation was this. Ruby is designed to be human. 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 Goody elements much like a mechatron. And then to get a step further, can we use Ruby to make the whole Ruby itself? We can. We can. That's all. The cool thing about Ruby, we need a very mature like with Tenet said, but it's virtually 25 years old, is that there's a Ruby solution for just about everything. So, for Goody, Shoes. Shoes is a Goody toolkit that was originally written by the way that I was there. And there's actually a talk on Shoes. This is not planned at all. It just happened to you, right? Shoes and Jason is very passionate about Shoes. So I highly recommend that Goody is in that talk. I think you might need tomorrow. He's going to talk about how to really choose from native implementations to using the GDM. So that's pretty often. Okay. So a couple more things about my motivation here. Ruby's fun to write. I like writing Ruby. Sometimes I end up not liking Ruby when I write a lot of professional Ruby. I know this sounds kind of like a, I'm being flippant about my work or something like that, but I really just like hacking for the sake of hacking. And sometimes we don't get to do that. So let's do something totally different. I mean, you can do a few bad things along the way. So we sit down now. I'm kind of learning the Shoes. I'm messing with Ruby. I'm having a great time. And all of a sudden, I wrote the monolithic, like, giant Ruby file, all of that stuff. But it's so hard 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 separate concerns and all that. But we'll look at a couple of snippets of this later on. So just as a warning, if you go off the beat and try to get my fall aside a little bit. It's that. I was kidding. Seriously. Sometimes it's nice to have fun. Okay, so hypercard is nice. Let's get right into 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 our Indian state objects. You know, there's a little wordy thing 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 on. So I just copied these for that effect and support. I'm going to have to write that. You never just run anything. Really just open up the active model and some 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 it doesn't seem too much. Basically you can instantiate it with a bunch of attributes. And that's this one thing called method 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 shoes that if I wanted to create a widget, it was like a button. Shoes kind of overloads their widget class. Instinct you in a way that they sense for 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 like a model in view where my cool button is my shoes element. And my model is these buttons. So it's funny how that turned out. I guess I could have really acted together to get all these things into one but I didn't really want to do it. Okay, so moving things around is also important. I wanted to be able to think about one type of part of it. You put it in the field, you can try to get it in the size of 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 write into their coordinates. So once we have that, we can run an element called the assignment element that basically kicks your viewport, looks at all of the elements, and then times one that is underneath your mask at the time. I imagine anyone who's familiar with doing this kind of like a job script, you know, digging into the job, it's familiar with sort of looking for things underneath the mask. It was sort of unique, so I had some fun here again. 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 going to be able to drag it off of the screen before resizing it out of the screen. So you can look in here to our folder, and just see what happens on the screen. Pretty fun to encode, but it was fun to write and fun to mess with, and very satisfying to get rid of. One more thing we needed was button scripting. As I said, I didn't get it to microtoc, but we can do our best to do a nice little thing in place of it. If anybody saw this slide from one of the main slides, it's a straight, I guess, and we're getting it. So I imagine you know where I'm going. Instance now. I never use it for anything really, but it's pretty cool. You just put a string in there and it runs in my privy, which is a lot long. And surprisingly, it works. I don't really know how many terminals work, but it's a good research project with the teacher. Also, I don't know what this does, but I'm sure it doesn't actually work. I don't know. I've never tried it. And then finally, we have graphics, cut things and drawing and stuff like that. Unfortunately, the best way to plan is just to have that plan. So hopefully in the future, in Ruby card version 0.2, we'll have graphics and then we'll have Ruby talk. So let's say Action-oriented saving instead. This was kind of fun. And whenever we call save, we want to go through our current card, grab everything, get the card, serialize it, and then just write it to a file and chase it. And I was really wanting to do like a very complicated, like writing out data bits in the way that other parts of Ruby can save things, but this is much easier and it increases something like this, which our program can then interpret later. Here's an image of it like this. All right, so it's time to take a look at hypercard. 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 RubyCon. And we have a bunch of tools and a bunch of buttons. So for our first card, let's just say something nice about RubyCon. So let's grab 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 want to modify this field, I have this field modifier. We can double click it and we could give it a name. We don't really need to......ash tag or anything. And we can go ahead and give it a font size. Actually, I have four or two. I think it would be nice to resize that to it. And then we can add a button. Looks like that. Sorry, my button tool. And here we have the script. Right now it just puts type. It doesn't really do anything useful. So I have a couple of internal methods defined. You can see this first one is later if you want. But for now, I'm just typing in the hand versus the next card. And a little more... So we go back to the hand because we want to interact with the button. But nothing's happening. We only have one card. So I guess we can add a card. So while we do the white card, if we get a previous and then the next, we get our next card. We can do the same thing here. We can add two more text content. I don't know what to say, but why don't we do something cool with the scripting? I have none here. This first field we will call A. Go ahead and put in your text. I have one card here that's the big old size. So I'll do the same with what we should be. Quick text. So we'll put in some larger size. A lot of button. And I'll say... And in this script, I'm not going to try to type it out because I know there are big mistakes. I'm just going to copy things, but I'm not sure if you can write this. So we'll put this in here. We'll say elementname.exe. And elementname is another sort of convenience method that I define. I want to find an exit stairway to that. Choose elevators. Go up and pay all the bill. I can pay the elevator for the mobile. No. I can pay the mobile. Okay. Let me just describe this going in case the building is in the word. So elementname is just a convenience method I wrote where it looks at the people 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 hit Save here. Go to our interaction and we'll say element plus two. And then we'll calculate and we get a three. So we've now basically emulated that script and we've been able to do a certain set. But these are group people. They're all really... 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. And people are plotting on all this. Anybody feel this is necessary between them? We can actually shell out two of these. So... I hope we have a part of flying here so I can just... And then we'll add the incident in public.txt. Save that. Go ahead and click it. I'll have to come over to my email here. Here's public.txt. And here's the public script. So we actually have a lot of the capability with Ruby that I could talk to the users of that then. You know, just more important for two user areas. 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 here. I guess I can shoot that in the end. If we go to open stack... So we save the Ruby count here. If we open it back up now, we can fresh it up. All our stuff is still there. And that's really great. So we sort of have an emulated that feature. And we have our scripting as well. And it's all right with Ruby and machine. So... Go ahead and round out the presentation here. Fun takeaways from this. Sometimes we get in a sort of a rut with our programming, especially when we're working like 10 hours a day, 9 hours a day, you know, stuff that seems to be precise and well-pasted and, you know, having to scrutinize. We can step away and we can use a lot of Ruby and do something interesting. We can use a guest.apps. 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 going to talk about this later. I can't see the count. It's really good. I'll just look at that website right here. Looks really nice. A lot of Ruby tools get released with RubyMotion and school-care and stuff. And Google and all kinds of other things. Epic Guard was a really cool piece of software. And not just Epic Guard, but the history of computing is the other 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. And I think that 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 and use some research by it. These two links are, the first one is the archive about Ruby where you can actually fire all the map and use hypercard. It's a lot of fun. The first one is the computer. You can run a computer. You can create customizing your computer. You can create customizing your computer. My review of your adoption for that takes 20 minutes to set up. You did it. So I had projects expand to show the space of their container. I learned this all the way. I've done some stuff in the past, I've never done any sort of telling them. So I'm working on it. I felt like it. The time crunch became very real with these projects. It's just the snacks. They brought out snacks. Oh, it's the snacks. The snacks are not false, right? The snacks are real though. The snacks are real. But they're good. I can do it all in a second here. The thing about working on a side project under time crunch is that there's never enough time. And I sort of failed to get a few things done for Rubycard for this talk. There's always tomorrow and next week and next month. But my recommendation would be if you have a time box amount of time to make something really scoped down. Fun takeaways, part new. If you're feeling constrained by a day-to-day code engine job, this is why I was saying about, you know, we want to produce really great quality code for the day-to-day 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. We can have a great big monolith file really well for a program like that this year as opposed to, you know, shipable code. The other thing is that JRuby is pretty amazing. I've never used it before in Lakudos to those people who made that because the newest version of Shoes uses JRuby. And it was bonkers, just calling Java methods and classes and stuff directly from Ruby to un-cube 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. Basically, I had to go into the SWT widget to extract font-sized data. And you can 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 build back in some bad-in-a-mange. I 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've got any questions about being bad-in programming, I'll answer them.
 Hello everyone, I'm Zach. This is the first time I've ever given a talk at a conference.  I wish you could feel how many of my hands are. It's pretty terrible.  I've had 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 asterisk. Some of hypercard.  As it turns out, hypercard was a very fast and really cool program. We'll talk about it a lot here shortly.  I really wanted to use it as a way to do a 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 in any place.  Okay, so I'd like to give you a brief but historically accurate description of hypercard.  Bill Atkinson is the name of the hypercard that was 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.  I think he has a couple of apps on the dashboard.  He worked for Apple at 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 hypermedia software system. Of course we don't have hypertext.  Hypermedia is just slightly less specific because you can do input text.  In hypercard, the ending was that you click on objects and scroll.  Pretty close though.  The whole paradigm of hypercard was that 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 like a roll of text or something like that.  All of the cards that we've done different like the Summer Fingers game missed in 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  on a platform is realized most fully by the internet.  You know, make a website, look at websites.  This is kind of a pretty website base for most people.  The idea that you know, you can power a computer and let 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 he was a couple of years ago.  Hypercard was kind of like the first gluemer of a web browser with a chain to a hard drive.  They didn't put any sort of network into hypercard.  And you know, he said a couple of times he would mention not pursuing that further because beyond that you basically go below web browser.  I'm pretty often using web 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 in the set.  Power.  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 on.  And as well as other things.  Enter hypertoc, which was a language created for hypercard.  Pretty unique.  Sorry for that caveat.  I didn't find it right.  Hypertoc and Perseverance won't be a good setup.  We'll make do.  I think I've not been able to switch.  Hypertoc had transparent data.  Dynasty basically just type of words.  I didn't say this is a number.  This is a string or anything like that.  You can use it to write a license or data structure.  Things that you would write up,  tend to look like this.  Put the value of card some field into barbada.  And it went well beyond that.  Obviously, but I think that's a pretty good example.  With this type of talk language,  you can control cards, stacks.  Even if you computer yourself,  you can use Apple's telephone dial protocol  to get your hypercard stack.  I have a short little video here.  I love this video.  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 computers.  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 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.  You can know some other value of pi.  It knows all the math functions.  It knows what the date is or what the long date is.  Oops.  Come on.  So nobody stop it.  We can get a little commands like go to men's card.  Like that.  And if you look inside one of these little buttons,  you'll see that its brains actually say go to men's card.  That's not that button.  This is how a customer is with the exit program.  Yeah.  So really you just have a little box in every button,  in their field or whatever.  And I don't know if you can see this a little bit pretty near there,  but basically you just have a little block that says on,  mouse up and you can type your sentence in there  and it'll 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 like using print and stuff like that.  A couple other things that HyperTalk or 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.  You know we're sort of used to getting all in WQ or like  something like that, but as you changed the stack  it would just change.  And it could actually lead to some important results  if you could modify the home card  and then come back in the next time you consult a walking group.  There was fast text searching which was really  pretty serious at the time.  There was a small multiple.  I don't really know much about it not packing,  but it sounds really impressive so I'm glad that he  accomplished that.  And it also had graphics manipulation which is a big piece  of the puzzle for Hypercard.  You could draw graphics, you could cut images  inside these stacks which was pretty stout at the time.  And this is sort of what it looked like you can see  in here, classic OS9 interface here.  This is the home card that has some things like  training and a little bit of stuff.  I have a link at the end of the talk if you want to try out  Hypercard.  You can actually find it on your own.  It's over on part-time.org.  Okay so now we have to talk about Rubycard.  This is a project that I embarked on a few months ago.  I'm also formulating this whole talk altogether.  My motivation was this.  Ruby is designed to be human.  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 Goody elements much like a mechatron.  And then to get a step further,  can we use Ruby to make the whole Ruby itself?  We can.  We can.  That's all.  The cool thing about Ruby,  we need a very mature like with Tenet said,  but it's virtually 25 years old,  is that there's a Ruby solution for just about everything.  So, for Goody, Shoes.  Shoes is a Goody toolkit that was originally written by  the way that I was there.  And there's actually a talk on Shoes.  This is not planned at all.  It just happened to you, right?  Shoes and Jason is very passionate about Shoes.  So I highly recommend that Goody is in that talk.  I think you might need tomorrow.  He's going to talk about how to really choose  from native implementations to using the GDM.  So that's pretty often.  Okay.  So a couple more things about my motivation here.  Ruby's fun to write.  I like writing Ruby.  Sometimes I end up not liking Ruby when I write a lot of  professional Ruby.  I know this sounds kind of like a,  I'm being flippant about my work or something like that,  but I really just like hacking for the sake of hacking.  And sometimes we don't get to do that.  So let's do something totally different.  I mean, you can do a few bad things along the way.  So we sit down now.  I'm kind of learning the Shoes.  I'm messing with Ruby.  I'm having a great time.  And all of a sudden, I wrote the monolithic,  like, giant Ruby file, all of that stuff.  But it's so hard 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 separate concerns and all that.  But we'll look at a couple of snippets of this later on.  So just as a warning, if you go off the beat and try to  get my fall aside a little bit.  It's that.  I was kidding.  Seriously.  Sometimes it's nice to have fun.  Okay, so hypercard is nice.  Let's get right into 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 our Indian state objects.  You know, there's a little wordy thing 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 on.  So I just copied these for that effect and support.  I'm going to have to write that.  You never just run anything.  Really just open up the active model and some 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 it doesn't seem too much.  Basically you can instantiate it with a bunch of attributes.  And that's this one thing called method 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  shoes that if I wanted to create a widget, it was like a button.  Shoes kind of overloads their widget class.  Instinct you in a way that they sense for 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 like a model in view where  my cool button is my shoes element.  And my model is these buttons.  So it's funny how that turned out.  I guess I could have really acted together to get all these things into one  but I didn't really want to do it.  Okay, so moving things around is also important.  I wanted to be able to think about one type of part of it.  You put it in the field, you can try to get it in the size of 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 write into their coordinates.  So once we have that, we can run an element called the assignment element  that basically kicks your viewport, looks at all of the elements,  and then times one that is underneath your mask at the time.  I imagine anyone who's familiar with doing this kind of like a job script,  you know, digging into the job, it's familiar with sort of looking for things underneath the mask.  It was sort of unique, so I had some fun here again.  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 going to be able to drag it off of the screen  before resizing it out of the screen.  So you can look in here to our folder,  and just see what happens on the screen.  Pretty fun to encode, but it was fun to write and fun to mess with,  and very satisfying to get rid of.  One more thing we needed was button scripting.  As I said, I didn't get it to microtoc, but we can do our best to do a nice little thing in place of it.  If anybody saw this slide from one of the main slides, it's a straight, I guess, and we're getting it.  So I imagine you know where I'm going.  Instance now. I never use it for anything really, but it's pretty cool.  You just put a string in there and it runs in my privy, which is a lot long.  And surprisingly, it works.  I don't really know how many terminals work, but it's a good research project with the teacher.  Also, I don't know what this does, but I'm sure it doesn't actually work.  I don't know. I've never tried it.  And then finally, we have graphics, cut things and drawing and stuff like that.  Unfortunately, the best way to plan is just to have that plan.  So hopefully in the future, in Ruby card version 0.2, we'll have graphics and then we'll have Ruby talk.  So let's say Action-oriented saving instead.  This was kind of fun.  And whenever we call save, we want to go through our current card, grab everything, get the card, serialize it, and then just write it to a file and chase it.  And I was really wanting to do like a very complicated, like writing out data bits in the way that other parts of Ruby can save things,  but this is much easier and it increases something like this, which our program can then interpret later.  Here's an image of it like this.  All right, so it's time to take a look at hypercard.  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 RubyCon.  And we have a bunch of tools and a bunch of buttons.  So for our first card, let's just say something nice about RubyCon.  So let's grab 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 want to modify this field, I have this field modifier.  We can double click it and we could give it a name.  We don't really need to... ...ash tag or anything.  And we can go ahead and give it a font size.  Actually, I have four or two.  I think it would be nice to resize that to it.  And then we can add a button.  Looks like that.  Sorry, my button tool.  And here we have the script.  Right now it just puts type.  It doesn't really do anything useful.  So I have a couple of internal methods defined.  You can see this first one is later if you want.  But for now, I'm just typing in the hand versus the next card.  And a little more...  So we go back to the hand because we want to interact with the button.  But nothing's happening.  We only have one card.  So I guess we can add a card.  So while we do the white card, if we get a previous and then the next, we get our next card.  We can do the same thing here.  We can add two more text content.  I don't know what to say, but why don't we do something cool with the scripting?  I have none here.  This first field we will call A.  Go ahead and put in your text.  I have one card here that's the big old size.  So I'll do the same with what we should be.  Quick text.  So we'll put in some larger size.  A lot of button.  And I'll say...  And in this script, I'm not going to try to type it out because I know there are big mistakes.  I'm just going to copy things, but I'm not sure if you can write this.  So we'll put this in here.  We'll say elementname.exe.  And elementname is another sort of convenience method that I define.  I want to find an exit stairway to that.  Choose elevators.  Go up and pay all the bill.  I can pay the elevator for the mobile.  No.  I can pay the mobile.  Okay.  Let me just describe this going in case the building is in the word.  So elementname is just a convenience method I wrote where it looks at the people 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 hit Save here.  Go to our interaction and we'll say element plus two.  And then we'll calculate and we get a three.  So we've now basically emulated that script and we've been able to do a certain set.  But these are group people.  They're all really...  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.  And people are plotting on all this.  Anybody feel this is necessary between them?  We can actually shell out two of these.  So...  I hope we have a part of flying here so I can just...  And then we'll add the incident in public.txt.  Save that.  Go ahead and click it.  I'll have to come over to my email here.  Here's public.txt.  And here's the public script.  So we actually have a lot of the capability with Ruby that I could talk to the users of that then.  You know, just more important for two user areas.  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 here.  I guess I can shoot that in the end.  If we go to open stack...  So we save the Ruby count here.  If we open it back up now, we can fresh it up.  All our stuff is still there.  And that's really great.  So we sort of have an emulated that feature.  And we have our scripting as well.  And it's all right with Ruby and machine.  So...  Go ahead and round out the presentation here.  Fun takeaways from this.  Sometimes we get in a sort of a rut with our programming,  especially when we're working like 10 hours a day, 9 hours a day,  you know, stuff that seems to be precise and well-pasted and, you know,  having to scrutinize.  We can step away and we can use a lot of Ruby and do something interesting.  We can use a guest.apps.  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 going to talk about this later.  I can't see the count.  It's really good.  I'll just look at that website right here.  Looks really nice.  A lot of Ruby tools get released with RubyMotion and school-care and stuff.  And Google and all kinds of other things.  Epic Guard was a really cool piece of software.  And not just Epic Guard, but the history of computing is the other 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.  And I think that 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 and use some research by it.  These two links are, the first one is the archive about Ruby where you can actually  fire all the map and use hypercard.  It's a lot of fun.  The first one is the computer.  You can run a computer.  You can create customizing your computer.  You can create customizing your computer.  My review of your adoption for that takes 20 minutes to set up.  You did it.  So I had projects expand to show the space of their container.  I learned this all the way.  I've done some stuff in the past, I've never done any sort of telling them.  So I'm working on it.  I felt like it.  The time crunch became very real with these projects.  It's just the snacks. They brought out snacks.  Oh, it's the snacks.  The snacks are not false, right?  The snacks are real though.  The snacks are real.  But they're good.  I can do it all in a second here.  The thing about working on a side project under time crunch is that there's never enough time.  And I sort of failed to get a few things done for Rubycard for this talk.  There's always tomorrow and next week and next month.  But my recommendation would be if you have a time box amount of time to make something really scoped down.  Fun takeaways, part new.  If you're feeling constrained by a day-to-day code engine job, this is why I was saying about, you know,  we want to produce really great quality code for the day-to-day 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.  We can have a great big monolith file really well for a program like that this year as opposed to, you know,  shipable code.  The other thing is that JRuby is pretty amazing.  I've never used it before in Lakudos to those people who made that because the newest version of Shoes uses JRuby.  And it was bonkers, just calling Java methods and classes and stuff directly from Ruby to un-cube 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.  Basically, I had to go into the SWT widget to extract font-sized data.  And you can 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 build back in some bad-in-a-mange.  I 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've got any questions about being bad-in programming, I'll answer them.
RubyCard_0_47.png RubyCard_48_131.png RubyCard_132_287.png RubyCard_288_5819.png RubyCard_5820_5939.png RubyCard_5940_6383.png RubyCard_6384_6443.png RubyCard_6444_8567.png RubyCard_8568_9143.png RubyCard_9144_9275.png RubyCard_9276_10019.png RubyCard_10020_10163.png RubyCard_10164_12419.png RubyCard_12420_13043.png RubyCard_13044_14171.png RubyCard_14172_14483.png RubyCard_14484_14759.png RubyCard_14760_16631.png RubyCard_16632_17351.png RubyCard_17352_17903.png RubyCard_17904_18539.png RubyCard_18540_18899.png RubyCard_18900_19595.png RubyCard_19596_20783.png RubyCard_20784_22247.png RubyCard_22248_23087.png RubyCard_23088_25811.png RubyCard_25812_26015.png RubyCard_26016_26351.png RubyCard_26352_26459.png RubyCard_26460_32519.png RubyCard_32520_33899.png RubyCard_33900_35015.png RubyCard_35016_40331.png RubyCard_40332_41843.png RubyCard_41844_42299.png RubyCard_42300_42899.png RubyCard_42900_43055.png RubyCard_43056_43089.png