00:00:15.360
Hi everybody, I'm Steve. Apparently a little feedbacky—sorry.
00:00:21.199
This is a talk called Functional Reactive Programming with Frappuccino. For those of you who were in the room a minute ago, I wrote a Ruby gem called Frappuccino.
00:00:26.560
To get a little meta, I'm going to talk about what I'm going to talk about. Essentially, the gem is actually at the end; so this talk is largely not about Frappuccino, but it also is at the same time.
00:00:37.920
First of all, as was just mentioned, I teach classes with Jumpstart Lab. We do the best Ruby and Rails training in the world, so if you'd like your team to level up, please give us a call. It's the only reason I can be here; it's the only reason I can do all the open source work that I do.
00:00:43.360
Jumpstart is super awesome. Jeff's a great guy. This conference is really special to me. I missed it last year, but it's sacred because this is actually the first Ruby conference I ever spoke at, way back in the day when I was first starting.
00:01:01.680
Adam Sokolowski and Wynn Netherland found out I was going to be speaking at RubyConf in the fall, and they said, "Hey Steve, we want to come speak at our conference, so do that first." So I came and spoke about Shoes a very long time ago. This conference will always be very special to me, so thank you for having me here. It's great to be back on the stage again. This is important, so thanks!
00:01:19.600
Now let's discuss the actual meta of what I'm going to talk about. This talk is nominally about a Ruby gem called Frappuccino. However, there's a bunch of stuff that I realized while building this Ruby gem, and this talk is actually more about the implications of what this Ruby gem means to me and what it should mean to you, even if you haven't heard of this gem or probably installed it at all.
00:01:56.320
Frappuccino was born out of this thing where I like to joke that Aaron Patterson wrote a gist, and I turned it into this life philosophy called "Irresponsible Ruby". Today, we will talk about responsible and irresponsible coding in the context of Ruby programming and discuss what all of this means.
00:02:08.239
One of the biggest points I want to make is that this talk is a little interesting, a little weird, and a little off-putting. The uncomfortable thing about me being here on stage while you listen is that when we give presentations at conferences, you tend to see the end result of months of work. For example, imagine how much effort Sandy put into the keynote this morning. You see the wonderful, perfect code that came out of the frustration, debugging, and hard work that went into it.
00:02:46.640
Whenever you see your favorite programmers speak on stage, it can create a celebrity culture where they appear perfect, even though we are very much not. Before Aaron Patterson was a friend of mine, I thought he was untouchable because he was amazing. Now, we're all just people, and I really don't want us to continue this celebrity culture as programmers.
00:03:02.400
I was pair-programming remotely with someone when Avdi did the "pair with me" hashtag thing. If you haven't seen that, remote pair programming is a thing! I was working with someone on a rescue issue where we wrote a test that kept failing. They apologized and thought it might be boring for me, but I told them, "My code doesn't work most of the time!" It's crucial that we respect each other's struggles in programming.
00:03:42.720
This talk will be a little off, a little weird, a little unpolished. I will be live-coding in two different versions of Ruby. You might notice that this presentation software is a bit odd. This is actually Rabbit, which is used in a lot of Japanese Ruby presentations. You can see the slide numbers at the bottom and then the tortoise moves according to how long the talk is, which indicates where we will end up.
00:04:31.360
All of this is a little unfinished on purpose because I want to present that casual side of coding instead of the typical perfectionism. It's Friday and the end of the day, so why should we be serious about it? Now, let's talk about what I mean by "Irresponsible Ruby." To be brief, it is code that you would not deploy at your day job because it is too interesting or creative.
00:05:19.039
I've devised four or maybe five criteria that define what I mean by this. Irresponsible Ruby is primarily composed of neat hacks, weird metaprogramming, unusual techniques, and absolutely no unit tests whatsoever. I specify unit tests here purposely. While we will discuss acceptance tests and integration tests, when I say unit tests, I refer to test-driven development (TDD), which guides code design.
00:06:14.479
When in an irresponsible mode, integration or acceptance tests can be useful to ensure you didn't break functionality. But TDD guides development along a certain path, and I don't want that. So that's the crux of what I mean by Irresponsible Ruby. The person who most embodies Irresponsible Ruby is this man—raise your hand if you're on your first Rails job. I hate raising hands during talks, but I'm doing it here!
00:06:56.879
So here’s an experiment: for those who've been around for a while, do you know who this guy is? That's awesome! It's amazing, yet kind of sad too, because this is a man named Why the Lucky Stiff, a very influential member of the Ruby community who decided to commit 'info suicide.' Many within the Ruby community might not know what happened to him, but the Ruby world has grown and so many newcomers could be unaware.
00:08:02.960
I’ve been joking that I’ll need to stop talking about Why soon because I’m encountering more and more new people who won’t know what I’m discussing. For those of you who raised your hands, Why is often defined as an artist whose medium was software, developing fascinating, complex, and irresponsible Ruby code before leaving the community. One reason I’m up on this stage today is that I felt Why's projects were too important to let die.
00:09:35.680
When I say I took over a lot of his projects—Hackety and Shoes were mentioned earlier—we’ll discuss Shoes later—when you inherit a project from an absent creator who was irresponsible, maintaining it can be extraordinarily difficult. This talk has parallels with Brian's earlier talk about code quality. Mine can be seen as an 'anti-code quality' talk in a way.
00:10:48.960
It’s challenging to maintain creative projects for the future. Some time after Why disappeared, someone published a blog post called "A Letter from Why." They realized that Why had been gone for a while and shared their experience of having previously emailed him and received a remarkable response. I’ll share with you the most important part of what Why said.
00:12:38.640
This person emailed Why, saying, "I love your work! How can I become an amazing programmer like you?" What did Why say? "I do not write tests for my code; I do not write very many comments; I change styles very frequently; and most of all, I shun the predominant styles of coding, as that goes against the very essence of experimentation. In short, all I do is muck around." He expressed admiration for programmers who take risks and aren't afraid to write dangerous or 'crappy' code.
00:14:00.640
If you worry too much about being clean and tidy, you can't push boundaries to find greater possibilities. This encapsulates Why's personality quite well. At the bottom of that blog post, there’s a Disqus thread, and I, as someone who maintains Why's code these days, wrote this: "please write some tests!".
00:15:34.080
To illustrate the effort I had to invest in Hackety and Shoes, I recently purchased a new MacBook coinciding with the release of Snow Leopard. For those who recall the Mac OS history, Snow Leopard was the first release where Apple deprecated the carbon framework they used for transitioning from Mac OS 9 to 10. Unfortunately, Why wrote his software using the carbon framework, and he left before porting them to Cocoa.
00:16:56.880
Consequently, I encountered a six-month struggle before I could even compile the Shoes project on my machine. That was the Mac side of things; the Windows side was even more ridiculous. Why had originally coded Shoes for Windows XP, but Windows Vista was released in the interim.
00:17:48.880
As many of you know, Windows Vista was notoriously problematic. I experienced frustration, attempting to port the application to various Windows versions, leading to numerous issues when teaching programming concepts to students who faced program crashes. Thus, we needed to transition away from Ruby 1.9.1.
00:18:48.000
So, for those who have been following Shoes' development, I've been quiet for a while, but now we are completely rewriting it in JRuby. It is almost functional and kind of ongoing already, and I'm about to show you some functionalities with it.
00:19:08.240
To provide a brief overview of the Shoes functionality, to create an application, we would initiate it with 'shoes.app do end.' This basic code would yield a window with that application. You can add elements such as buttons easily, enabling straightforward initialization and functionality design.
00:20:36.160
The point is to utilize Ruby's blocks effectively, making programming simple and enjoyable. For example, you can create buttons where interactions trigger blocks, showcasing how user interactivity can be incorporated into your designs.
00:22:14.640
Now I’ll move on to Functional Reactive Programming (FRP). Does anyone here know what FRP is? Awesome! So FRP is a compelling programming paradigm that emerged from Conal Elliott's graduate work. It combines aspects of functional programming and reactive programming. Essentially, functional programming emphasizes functions as first-class concepts, while reactive programming focuses on data flows as first-class concepts.
00:23:55.680
The unique idea behind FRP is to utilize first-class functions to manage data flows, much like how you might think of linking columns in an Excel spreadsheet. When you change inputs in Excel, outputs are updated automatically. In the case of FRP, if variable A is set to five and variable B is defined as 'A + 6,' any changes to A will automatically update B.
00:24:50.360
This introduces a new way of thinking about programming, and presents opportunities for dynamic data manipulation in real-time. By integrating these concepts into Ruby, we facilitate new forms of interaction and responsiveness to user inputs, enhancing user experience.
00:26:56.480
After becoming familiar with FRP through my JavaScript exploration, I was intrigued by its potential in Ruby. My journey began at a conference where Philip showcased bacon.js, a library dedicated to functional reactive programming for UI elements.
00:28:51.519
Inspired by his talk, I quickly dove into crafting a Ruby gem that mirrored bacon.js's functionality, ultimately leading to the development of Frappuccino. This originated from a desire to bring FRP to our Ruby ecosystem, allowing for more expressive UI designs.
00:30:27.600
The complexity of Frappuccino’s design arises from its foundation in multiple prestigious programming languages and paradigms, intertwining the influences from Haskell and Elm into a single Ruby implementation.
00:32:23.840
In order to understand Frappuccino fully, we explore its main constructs, which reflect functional programming's principles while integrating FRP’s reactive characteristics. Aside from the simplicity it promotes in UI interaction, it leverages the power of functional programming principles for event management and state handling.
00:34:02.560
By employing an approach that ties events directly to user interaction, Frappuccino streamlines the process of building interactive applications in Ruby, allowing you to express your application’s logic more naturally and efficiently.
00:35:28.320
To demonstrate this, I will implement a basic application using Frappuccino showcasing the interactive incrementing and decrementing of a counter with user buttons, illustrating the seamless integration of functional programming in a Ruby context.
00:36:56.160
Through this practical example, we will witness Frappuccino's efficacy in building responsive applications while maintaining readable and manageable code, focused explicitly on what we wish to accomplish with each interaction.
00:38:44.480
Thus, Frappuccino’s introduction into the Ruby ecosystem opens up a new realm of possibilities for both developers and aspiring programmers, illustrating the journey from experimenting with the idea of irresponsible coding to fostering creative explorative programming.
00:40:02.240
In conclusion, I'd like to encourage all of you to embrace the idea of being irresponsible! Engage with creativity, take risks in your coding practices, and develop innovative solutions within Ruby. The emphasis should be on having fun while coding.
00:41:17.680
Thank you again for being here, and I look forward to seeing more whimsical and ingenious Ruby creations from each of you. Let’s not lose the joy of coding! Thank you, everyone!
