 All right, I'm Chris Nelson with Gaslight Software. I'm going to be talking about building rich client web apps and coffee script and rails as much as I can and however much time I have. First of all, how many people are really happy with the design of their JavaScript to the point that it's almost as much fun to code the JavaScript front end of their app as it is to code Ruby? Okay, we've got like two, three people. Woohoo! How many people are not? Okay, good, I'll keep talking, though, otherwise I was going to sit down. So, yeah, this was definitely me. I spent a long time trying to figure this out. I actually gave a talk on RubyJS a couple years back at RubyConf, which is an attempt to compile Ruby into JavaScript. I've really been searching for a better way to build my front ends. I guess the first thing to point out is how I've normally done it up to this point is basically try to code as much as my app as I can in rails and then sprinkle a little jQuery on as little as I can to make it dynamic as much as I need to. And I've basically found that whole thing to be a big fail. My apps need to be richer now, and I might as well start doing the right way to begin with, and this was an attempt to kind of find a better way to do that. I guess before you start doing anything else, how many people are test driving their JavaScript? Okay, this talk is not about that, but if you're not doing that already, just ignore everything else I'm about to say and do that first. Go check out Jasmine, just start doing it. I had to start doing that first before I could get anywhere. So, first point, I really dig CoffeeScript. If you haven't seen CoffeeScript yet, go check it out. It's not really a completely different language. What it really is, I think, is better syntax for JavaScript. So, I'm going to show a little code there if I can get to it. Oops, let's get out of that. Oops, oh, hello. All right, so I'll show a spec. By the way, my editor here is Redcar, which is awesome. Daniel Lovecraft is right in the front. You can thank him for it. So, this is a spec. This is some CoffeeScript. Just, I'm not going to try to really go into CoffeeScript too much, because that would take too long. But briefly, it cures just some of my big annoyances with JavaScript. Having to type function so much, just believe it or not, just really bugged the crap out of me. And the CoffeeScript has this really nice syntax here, this little arrow thing to say, this is the beginning of a function. CoffeeScript does use significant white space, which I thought would be terrible and awful. But when I started using it, it hasn't bothered me at all. And the thing about CoffeeScript that I think is really awesome, the JavaScript that it compiles into is not like the output of a compiler that's munged and terrible and you can't use it and you can't look at the debugger and figure it out. It's just JavaScript, not that much different than I would write myself. There's some things going on with implicit return statements and stuff that make it a little bit different than if I just totally hand-coded that spec. But the point is, I can look at it and see what's going on. I can look at it in my debugger and see what's going on. It doesn't get in my way. It just lets me write code that's just much lovelier and nicer to deal with. OK. So really good CoffeeScript. Backbone. Backbone is a really lightweight MVC framework for JavaScript. So there's a bunch of JavaScript frameworks out there. And what I found with all the ones that I've looked at is they may have come with lots of features and widgets and stuff that was awesome. But at the end of the day, the code that I had to write to use it made me sad. The code that I used when I started using Backbone made me happy, and I was pleased to deal with it. And I started using Backbone. It's been just enough and no more. It's really lightweight. It's just barely an MVC framework. And I used to think that was bad, and it turns out it's good. Having just barely enough is really what I want anymore as a developer. So the other thing about Backbone is I sort of started refactoring my way into it, which I really like. So I started with my typical app where I had just more and more jQuery in a JavaScript file on the page until it got out of control. And I was sad and grumpy. And what I did was I took that jQuery and refactored it into a CoffeeScript, or I'm sorry, into a Backbone view. And just that little bit of structure, it got me sold on it. It got me hooked. And then I started going from there. Again, I'm not going to have time to thoroughly go into Backbone. That would be a 40-minute talk or something. But I'll just show a little bit of what views and stuff look like. This is a Backbone view. I'm writing all my code in CoffeeScript, of course. I'm writing a class that extends a Backbone view. I have this events hash which maps somewhere in the element for this view, there's a new base type button. And I'm mapping the click event to the new base type function of this class. And then down in new base type, I can actually do something if you click that button. Views don't really give you much out of the box. It's almost like they're a convention. Other than this events hash, there's not much to them other than a convention. Backbone doesn't mandate a templating framework. I use handlebars. Handlebars is awesome. I don't have time to go into that either, but it's worth checking out. Down in my render, I'm basically just taking my template and calling the function and putting it on the element for my page real quick so I don't run out of time. I want to show what models look like. So models are what actually do the work. And the thing that I really dig about the Backbone models is they just seamlessly worked. If you respond to Rustful, Jason, and your Rails app, they will basically just work. You basically just get a, you create your model, you call save, and it knows how to do everything else. It's worth pointing out models are asynchronous. When you call save, you've got to listen to something. I have this particular model set up to broadcast a persisted event so that my view can listen to it because it needs to do a couple of things when a successful save happens. You get a bunch of lifecycle events in Backbone for free, but it wasn't quite what I wanted here, so I made my own here with this persisted kind of event. That was really easy to do too. Just, I don't know. I finally feel like I found a way to build my front end to my Rails app in a rich way that I'm really happy with the code, so that's mainly what I wanted to share, and I think that'll leave me like two minutes for questions. Okay, so yeah, I spent a good amount of time trying to dig into Sprout Core, and basically all the code that I've seen there has seemed to introduce a bunch of complexity that I didn't want, and it seemed to be pretty hard to figure out how to do things I wanted to do, and eventually I gave up. I recently saw a head-to-head Backbone to Sprout Core kind of comparison, and it made me think I was still a lot happier with Backbone. Yeah, so I've broken all my templates into separate files. I have a helper that pulls my templates in on the Rails side and a companion helper that pulls them in on my test side in my unit tests, and that's been really important and useful for us. I render everything in JavaScript, so I've basically gone more towards like Rails is gonna be like a really pretty thin back-end, eventually probably Rails for this class of app, maybe not even necessary, just metal that knew how to speak JSON restfully would be enough actually. Sure, the style of the CSS is totally shareable, yeah. Oh, Mustache, I'm sorry. Yeah, Mustache was not good enough for me handlebars was what I wanted. I don't know if there's a service to review version of that either, but. Okay, thanks. Okay, so my name's Tom Bedard. I'm a Rails developer by day, but I've been hacking on the sort of graphics, generally graphics programming for a while now, and what I'm gonna show you is a real-time 3D Ray Tracer built with WebGL. So WebGL came, had full support in Chrome and Firefox very recently, so what I've done is convert some of the GPU-based Ray Tracers to work in the browser, and I shall switch to Chrome. Okay, so, a few, well, it's about six weeks ago, I launched Fractal.io, so this is a, just a WebGL-based, Fractal Explorer, basically, so we can fly through the scene, everything's rendered in real time, it's all interactive. Okay, so, and there's various parameters as well, so we can tweak things like, so we can change the rotation, and maybe we'll, yeah, we'll sort of zoom in a bit closer. So we can, yeah, fly in a bit closer. What it's actually doing is dropping down to low resolution when we're moving around to, and then it flashes to, we render at high resolution. Then we can do things like, we can maybe, we can maybe, maybe change the color of that as well, a bit moody or something. So the way this is working is it's all running, there's no geometry here, it's all just a single quad, which is two triangles basically, six vertices, and everything is done on a GLSL shader, which is the OpenGL shader language. So what you can actually do is, it's basically a uber shader, everything is in here, it's just one shader, so there's, I mean there's a lot of stuff here, but it's basically conditional compile time blocks for each different type of fractal, and plus all the ray tracing code in there. The way it works is for each pixel in the scene, you work out a direction vector, so you have a single eye point, and then you find a coordinate from the eye point to the coordinate of the pixel, that gives you a direction vector, and then you iteratively step into the scene from this direction, in this direction. At each step you run the fractal calculation, which, the result of which gives you the distance to the nearest surface in any direction. One slide I can show you, help illustrate that. So you've got an eye point, what the dotted line there is the nearest surface, so you know that you can step forward by that amount before hitting anything, and so you can step forward, and then you do the same process again, and again. So this is a technique that's been used a lot on the demo scene to create these 4K sort of crazy demos. And then you keep stepping forward until the distance to the surface is below threshold, at which point you know you're within a limit to hit the surface, and at that point you can then calculate the normal vector. Once you've got the normal vector, you can do the shading calculations. There's other parameters here, so we can speed it a bit later. You have to kind of slow it down a bit when you get close to the surface, because it gets a bit out of control. So you can play around within your browser, it'll work in Firefox 4 or Chrome, there's a Fractal library here, so we've got the classic Manga cube here, Manga sponge, but then there's all sorts of different styles of 3D fractals. So it was actually late 2009 when there's kind of a collaborative effort by a group of amateur and professional mathematicians on Fractal forums that some guys work on trying to find a true 3D analog of the Mandelbrot set. So this is called the Mandelbulb, which is kind of what resulted. And it's the closest thing to a 3D equivalent of the classic Mandelbrot. So yeah, it gets a little tricky to control here. But then that sort of opened the floodgates to a whole new breed of 3D fractals. So there's one called the Mandelbox, which is a slightly different take. Basically what's happening here is you're doing, at each point you're doing a series of scaling reflections, rotations, and applied iteratively, you get these crazy shapes. So it's another example. So we can sort of fly into this structure. And the closer you get, the more detail is revealed. But obviously the tricker it gets to your controls, we can slow it down a little bit. I think running in dual monitor might not be helping the graphics card. It is actually possible to completely lock up your computer here with the graphics card if you push it too far. So you have to be careful, but you can spend literally hours exploring this. As I have done many an evening. So what other example it is? Yeah, you can get some quite sort of crazy organic shapes as well. This is called a kaleidoscopic IFS, iterative function system algorithm. And by tweaking various, let's see, various parameters, you can get a whole mixture of sort of organic and sort of natural shapes. So to finish off what I want to do is to show you a quick little animation. So the GLSL shader that Fractalab is derived from is something that I was working on for an After Effects plugin. And this is a video that's actually playing in Times Square in one of the kiosks. Hi everybody, my name is Jason Neelan. I'm a developer forward. So what I want to talk about is sort of experience you've had over the last year and a half, two years, working on a system that comprises a lot of it was like a Windows application written in .NET. And we moved to Ruby and we had to do some interesting kind of, I would think, sort of novel things to get that to work. So a little bit of background. This is a U-Switch for Business. So it's an energy switching site for businesses. There isn't very much going on the website. You just capture some contact details for a person. And then it goes to our call center in Camden. And these guys then ring that person back and switch their energy, which requires capturing a whole load of information about them. So we built this system about a year and a half ago, using WPF. And it worked out okay. It was fine. But then at the start of last year, we became part of Forward. And Forward is very much like a Ruby sort of development shop. And as I guess you guys would know, you can get a lot more than with Ruby. So for us, we didn't want to continue on doing .NET stuff because of the additional complexity of having two completely separate platforms. And we just knew that we would get more done using Ruby tools and that whole stack. So the question for us was, well, how do you use Ruby like Windows? We had no idea really. First thing we looked at was our Ruby. So our Ruby is Microsoft's implementation of Ruby on the .NET framework. That didn't work out very well. It was just too much hassle we found. For a start, a lot of the popular gems that we wanted to use didn't work very well or just this weird behavior, especially at any point where they're interacting with like a Win32 system. Another big problem at this specific point, I think it's a bit better now, was that the actual WPF framework, the Windows framework that we were using didn't interact correctly with the R&R Ruby objects. And for us as well, it was just like, we're going to have to install this R&R Ruby thing on those machines and it was just extra pain. So rather than doing this, which I would call like in-process integration, we kind of took a very different approach, which was to basically develop web apps in Ruby and run it up into completely separate applications that we would then integrate with the Windows application. So I guess another thing to mention is that we weren't, like on my team, we didn't have a lot of Ruby experience. So we kind of started it at the edge with this sort of application, which was just like a load of prices in a CSV. So it was like probably the simplest sort of Ruby app you could get going with. That was the first thing we did. So then we went on to doing like things like reports because that's a good thing to do on the web anyway, you know, because we knew all the technologies, you know, like Google reports and stuff like that. But that was kind of a safe place where we could, you know, get up to speed on Ruby and, you know, basically mess around and get our heads around Ruby and do stuff. We did create a bit of a mess. We had to go back and rewrite some of them once we become, you know, a bit more experienced, but, you know, nobody died. It was like I said, best to start. One horrible thing was ODBC. I don't know if anybody knows about ODBC, you know, it's probably years since I heard of it, but if you want to get Ruby to talk to Microsoft SQL Server Database, that's what you're going to have to use. And even worse than that, we had three environments with ODBC, so we were developing on max. So that was one ODBC connection to set up. Then on the Windows boxes, there was another sort of ODBC connection. And then there was, you know, the Ubuntu environment that we were deploying onto. And there was lots of weird bugs that happened where true and false would come back to zero and one and reports wouldn't work. So at this point, we migrated everything to MySQL and everything became a lot smoother after that. Like another thing we did in that process was change all our database nameings to be, you know, sort of active record compliant and stuff like that. And once we were on MySQL, a lot of pain went away. So, you know, if you're feeling pain like that using SQL Server, the message is, just get away from it. So at this point, we were kind of wanting to do a bit of closer integration with the Windows application, but still, you know, do web apps. So the obvious solution for that, you know, if you were doing, if you had two web apps, you would just use hyperlinking, right? And you can kind of do the same thing with Windows application. If you think of like iTunes and Spotify, if you go to, you can get a link to a Spotify song and it just opens up the Spotify app on your machine. So we did exactly that. We created our own protocol. You write a little Windows application and then you can basically do RSS feeds and any web app with a link into the Windows application. Because we didn't really want to like spend three months rewriting, or six months rewriting a Windows application that we've sort of just done. So that was quite good. Like integration wasn't seamless from a UI perspective, but it was good enough. So that worked out quite well. Another approach was to write sort of smaller web services in Sinatra. You wouldn't really do the same thing in .NET because like you have to write so much code. I don't know, this is like, this is like one of many files that you end up having to write in .NET to expose like some JSON or XML. Whereas like with Sinatra, it's like really straightforward. So we had like lots of random data sources that we had to, that we had to, that the business wanted to use. So we would write a Sinatra app that would return that as JSON, or we might write a simple web interface for it. And then later on we would sort of integrate that more closely between this application with some like asynchronous sort of client or something like that. So after a while we, as another thing we started doing was sort of basically writing Rails or, this is a Rails app, or Sinatra apps, and then just basically cramming them in an Internet Explorer plug-in inside in the Windows application. So to sum it up, yeah, starting at the edge worked for us. In process integration was really painful. You might get on better, but we didn't. HTTP integration was great. And doing things incorrectly was a win because we didn't have people complaining that we weren't doing anything, we weren't delivering anything visible. So yeah, that's me. Any questions? I had good luck using JRuby in SQL Server, oddly enough, because the JDBC driver is pretty solid. I don't know if you guys check that out. I think JRuby seems to have a lot more support and we are using JRuby on another project in our company, and it seems a lot more solid than Iron Ruby is. Yeah, I think Microsoft just kind of basically dumped Iron Ruby recently. Yeah. So, yeah. Yeah. Thanks very much. For the people who have not been able to talk. It's been minutes. I'll make it quick. It's all green and bright. So I'm going to talk about a gem I wrote a few months ago called Crap Shoot. It's for rolling dice. So if you were a nerd and you played Dungeons & Dragons, you're probably familiar with some of these codes. 2D4 rolls two four-sided dice. 1D100 plus 8 rolls 100-sided die plus 8. 4D6V, that's a little invention we had. It rolls four six-sided dice and then gets rid of the lowest die. That's a language. It's an actual programming language. It expresses computations very precisely for human communication. It's also a regular language, which can be accepted by a regular expression, can be accepted by the terministic finite state machine, which is what reg-exes are compiled to, and it can be generated by a regular grammar. So this is a complicated dice language statement. It's an expression. This is a binary expression. This first one is a series. It's a series of dice rolls. This is an arithmetic operator. And this is a constant. It's a 100% certified Web 2.0 regular language. I implemented it in Regal, which compiles a state machine from a .rl file into a bunch of weird languages in Ruby. So this is the actual language implementation as it was a couple months ago. I added a few stuff today. The Regal file is 62 lines. The Ruby it generates is, I think, today about 400 lines. And it also produces a PDF if you want to go at it with a pen and paper and make sure it works. So what I want to do with this Regal is turn all these strings into a bunch of token objects representing constant series and arithmetic. Each token has an eval method that actually turns it into a result. So a constant just returns itself. It has an independent method to see if it's an operator and it depends on the next one in the list. And it has an inspect operator to look nice. So I've parsed a bunch of tokens and now I have an infix notation math. But infix is a pain. People are great at it, but computers, it's more complicated to write software to do it. So what I really want is a post-fix representation so I can just munch down a stack like in PostScript, the printer language. So I take this and I basically rearrange the operators to do that. So for a series, I can then just roll the dice, push the result onto the stack. A constant, push it onto a stack, arithmetic, pop twice, push the result. So I start with this. I can get 15 on my dice. That goes onto the stack. I roll 3d10, get 5, goes onto the stack. I see a plus, I add those and it gets a 20 onto the stack. 2d6, that comes up 9, goes onto the stack. Minus, goes onto the stack and then returns 11. Myself goes onto the stack minus get minus 289 so your fighter or wizard is done. This morning, I added operator precedence, which is harder than no operator precedence and operators that aren't as important as multiplication or division, like plus and minus, get pushed onto a stack during the post-fixing part of it. There's a web version of this online optimized for Dungeons & Dragons players at triskellion.heroku.com the source is on GitHub. It doesn't have multiplication and division yet because network access has been spotty today. If you want to fork it, there's a GitHub it's bcurly slash crapshoot but again, today's stuff isn't on there. The crapshoot gem also hasn't been updated yet. Thanks. Any quick questions? I use it on the desktop because we also have tons of PDF books that we have to reference and if we're doing it remotely, we can talk over Skype too. Okay. Any more questions? Ask me later. Thanks for the awesome guys. Super lightning talk. All right. I started programming on TI-83 plus. Did anybody else do something similar? There are no slides. The presentation is here and it looks good to some people. Okay, sorry. I'm programming on a calculator maybe some other people did. This talks about kids Ruby so I'm not reading. There's not enough programmers in the world. The best programmers all started when young. The computer programming education budgets are getting slashed in the US slash UK and elsewhere. I think we all know that, right? And why the lucky stiff? He cared a lot about teaching kids. He created Hackity Hack but Hackity Hack is showing its age. It doesn't actually run like normal Ruby code like puts. So most kids hackers actually want to write things like 100 dot times do puts my teacher sucks and because that's easier than writing actually 100 times on the board I will not do this over and over. Or they just want to create games and basically kids Ruby is real Ruby. It provides a simple editor just imagine it on the left side is the editor and the right side is the output. So it's really easy just turn it on and it's kind of like the old style TRS80 Commodore 64 or something like that. It's written in Ruby and JavaScript so it's pretty easy to hack on. I actually hacked on it and I'm not that good at programming so if I can do it you guys should do it too. It's compatible with some code samples of Hackity Hack which is kind of interesting and it's also like the I don't know if you guys have played with Hackity Hack Hackity Hack. There's that turtle thing so there's support for that which is really cool for kids. It also has an interface to Gosu it's a 2D gaming library you guys probably heard about that earlier in one of the talks and we need people's help so all sorts of things. There's classes set up. Is anybody going to RailsConf? Yeah, yeah. There's going to be some classes there so look out for that. We need help with the editor and curriculum HTML. That's pretty much it. If you're actually interested in seeing it I would show it but it would blow you guys away. My talk would be in vain if I didn't show it so come see me after. This might be very short but we'll see what happens. That's good. Good start. Start at the end, shall we? Awesome. Cool. I was going to talk to you about robots very quickly. My name is John. I work forward with the other two guys. This has been my experience so far of this Ruby conference. I did this talk a few weeks ago and then I found out there's this amazing Arduino robot that people are going to be showing tomorrow which goes underwater. I was going to demonstrate this little guy very quickly. It's a little Arduino robot which you guys are hopefully going to be able to control doing this talk so if I quickly plug it in so bear with me this might totally fail. The idea was to build a robot show it off to you guys here. It's a little software element. So we wanted to have a two-way interaction with the robot so we wanted you guys to be able to use it so we needed something that was highly consistent, highly available with a very low latency so of course we chose Twitter which is another reason why this might be disastrously wrong. I'm going to plug this robot in. If you want to tweet out FWD bots it's got commands forwards, backwards, left, right and dance and hopefully we'll see you guys quickly throw this down here. It was going to be wireless but I didn't have time to build the wireless adapt before it so let me just start off this guy that should be in and if we... Oh, wow, I failed. It's because I've been playing with it. There we go. Oh, it's... That's my bad. I think I'll plug it into the wrong one. Fingers crossed. There we go. Cool. So it'll pick up your tweets that reply to you. If you're interested in how it works I can either go through it in the pub or we can quickly talk about it now. It's a little Arduino which is an open source prototyping platform which has got a little microcontroller on it. The idea is you program it in a language you'd like to see. It's actually called the Arduino Programming Language which is based on a language called Wiring. So we don't really want to program it in C ideally so there are other bindings. There's this thing called Singalong Arduino which is... The idea is there's a C program on the Arduino which then you can write Ruby which is interpreted so you can essentially just write Ruby code. Don't have to build it or anything which is great. Fortunately it's not very good with Max. It works primarily on Ubuntu so didn't really get on with it. There's the Ruby Arduino Development Framework which you write Ruby code. It gets compiled down into C. That's pretty cool too and we're going to hear a talk tomorrow about Mac Ruby. I didn't do any of that. I wrote a C program which interprets serial data which is sent across this USB connection here. So it essentially sends commands which are deserialized in C using the Twitter gem and the serial report gem. It was really simple. The motivation behind this talk was to show you that you don't need to be like a super brain to build a robot. It's really straightforward. It took me a few hours in my 10% time to all these guys were saving consumers loads of money. I was messing around with this. So yeah, I mean essentially this is the Ruby program which just searches Twitter and whenever it finds a tweet at FWDbot it will broadcast it onto the Arduino. The Arduino will then decode the signal and then translate it into a motor signal change some voltages on some pins. That's pretty safe forward. That's essentially it. Any questions? Cool. Go to the pub.