WEBVTT 00:00:17.080 --> 00:00:18.450 BRAD GESSLER: All right. So, while these are, 00:00:18.540 --> 00:00:20.130 these responses are coming in. 00:00:20.130 --> 00:00:23.350 It looks like quite a few people have 00:00:23.360 --> 00:00:27.010 either handcrafted html and css applications. 00:00:27.010 --> 00:00:30.900 I'm not sure if they're single-page application, 00:00:30.900 --> 00:00:34.170 or just deploy straight-up Rails applications 00:00:34.180 --> 00:00:36.380 or all the logic on the server-side. 00:00:36.400 --> 00:00:39.620 So that's good. I, I hope you'll learn 00:00:39.620 --> 00:00:42.390 something new today about how my company, 00:00:42.390 --> 00:00:43.930 Poll Everywhere, which the, 00:00:43.940 --> 00:00:45.150 the product is what you're seeing. 00:00:45.150 --> 00:00:48.060 We're a software as a service company. 00:00:48.060 --> 00:00:51.520 We just sell this to presenters based on audience size. 00:00:51.520 --> 00:00:56.549 So, I'm gonna fire up the slides here. All 00:00:56.549 --> 00:01:00.941 right. My display settings are working, so this is 00:01:00.941 --> 00:01:05.069 good. All right, so Middleman. The missing view in 00:01:05.069 --> 00:01:07.471 the Rails API stack. 00:01:07.500 --> 00:01:10.440 Let's just jump into it. So, as I said 00:01:10.440 --> 00:01:13.240 before, I am Brad Gessler, CTO and co-founder of 00:01:13.240 --> 00:01:15.760 Poll Everywhere. We started this company about six years 00:01:15.760 --> 00:01:19.240 ago now. So, we were mobile first, whatever that 00:01:19.240 --> 00:01:22.550 meant, SMS. So we went through all the pains 00:01:22.550 --> 00:01:25.850 of having to upgrade, if you will, to the 00:01:25.860 --> 00:01:31.520 second vintage of mobile first, which is mobile, basically 00:01:31.520 --> 00:01:34.230 a mobile website. We had a lot of fun 00:01:34.230 --> 00:01:38.560 doing that and, and learning things the hard way. 00:01:38.560 --> 00:01:41.080 But first, what is middleman? How many of you 00:01:41.080 --> 00:01:43.100 have heard of Jekyll in this room? That seems 00:01:43.100 --> 00:01:46.380 to be the, the predominant static website generator. And 00:01:46.380 --> 00:01:48.470 if you go to the Ruby toolbox and you 00:01:48.470 --> 00:01:50.680 ask Ruby toolbox for, hey, what should I use 00:01:50.680 --> 00:01:52.970 to generate a static website? You're going to get 00:01:52.970 --> 00:01:56.950 Jekyll. But it's, it's not like Jekyll, in the 00:01:56.980 --> 00:01:59.590 sense that it uses a lot of the more 00:01:59.590 --> 00:02:03.090 modern, basically RubyGems inside of what you see in 00:02:03.090 --> 00:02:05.620 Rails 4 and Rails 3, which is, the fact 00:02:05.620 --> 00:02:09.239 that it uses tilt to manage all of the 00:02:09.240 --> 00:02:12.591 template and, and sass and all that good stuff. 00:02:12.600 --> 00:02:14.680 So, if you're looking for a tool to build 00:02:14.680 --> 00:02:16.990 a static site, don't be scared off by the 00:02:16.990 --> 00:02:20.700 fact that middleman is catching up with Jekyll. And 00:02:20.720 --> 00:02:23.640 you should feel a lot better about that after 00:02:23.640 --> 00:02:24.730 this talk. 00:02:24.730 --> 00:02:30.490 So, middleman is extraordinarily well-documented. Thomas Reynolds built middleman. 00:02:30.500 --> 00:02:34.080 He's the, the guy behind this. And he also 00:02:34.080 --> 00:02:35.910 built an amazing website with a lot of great 00:02:35.910 --> 00:02:38.620 documentation behind it. So if you go to, I 00:02:38.620 --> 00:02:42.430 believe it's middlemanapp dot com, you can get a 00:02:42.430 --> 00:02:46.120 sense of, of everything that, that this static site 00:02:46.120 --> 00:02:48.030 generator involves. 00:02:48.040 --> 00:02:51.270 Another really nice thing about this static site generator 00:02:51.280 --> 00:02:54.220 is that it's, it's very modular. So it actually 00:02:54.220 --> 00:02:56.250 uses rack in its gut, so if you understand 00:02:56.250 --> 00:02:58.299 rack, you can write a lot of extensions using 00:02:58.300 --> 00:03:01.661 rack, which is kind of crazy. A static site 00:03:01.680 --> 00:03:04.880 generator using rack to, to do certain things. 00:03:04.880 --> 00:03:08.740 And there's also a, an extension framework, where you 00:03:08.740 --> 00:03:11.530 can roll things out, like, a middleman blog, if 00:03:11.530 --> 00:03:15.030 you so please. So, middleman blog in middleman is 00:03:15.030 --> 00:03:18.860 essentially a, a drop and replacement for Jekyll. With 00:03:18.860 --> 00:03:20.810 a few other things. If you're used to writing 00:03:20.820 --> 00:03:22.949 GitHub-flavored markdown, there's a few tweaks that you have 00:03:22.960 --> 00:03:24.871 to make there to, to get that whole thing 00:03:24.871 --> 00:03:26.520 working. 00:03:26.520 --> 00:03:30.770 So, getting started with middleman is actually very similar 00:03:30.780 --> 00:03:33.680 to what it's like getting started in a Rails 00:03:33.680 --> 00:03:37.810 application. You install the gem, you initialize the application, 00:03:37.810 --> 00:03:40.410 it creates all of this boilerplate code. You can 00:03:40.410 --> 00:03:42.910 see from this directory structure you have your configuration 00:03:42.910 --> 00:03:46.870 file, default index.html.erb. You get a layout file and 00:03:46.880 --> 00:03:49.820 then you have all of your assets. Stylesheets and 00:03:49.820 --> 00:03:53.140 JavaScripts. And then you spin up the server, and 00:03:53.140 --> 00:03:56.290 it boots extremely fast. So, in under a second, 00:03:56.290 --> 00:03:59.569 you can hit this server and things are just 00:03:59.600 --> 00:04:01.541 working. 00:04:01.541 --> 00:04:05.130 So, the thing that I like a lot about 00:04:05.130 --> 00:04:07.510 middleman is that it's very easy to come into 00:04:07.510 --> 00:04:11.100 middleman from Rails. I said earlier that this uses 00:04:11.100 --> 00:04:14.049 tilt, so you can bring all the same gems 00:04:14.049 --> 00:04:17.310 and really the same toolset that you hopefully have 00:04:17.320 --> 00:04:20.219 come to love inside of Rails into middleman and 00:04:20.240 --> 00:04:25.461 start using it without too much of a problem. 00:04:25.461 --> 00:04:27.319 So the other interesting thing about middleman is that 00:04:27.320 --> 00:04:31.380 it's multi-environment aware. This is, I pulled this from 00:04:31.380 --> 00:04:34.711 a default middleman configuration from the boilerplate and simplified 00:04:34.711 --> 00:04:36.510 it a bit. But here you, you get an 00:04:36.510 --> 00:04:39.070 idea that in your development environment, you can put 00:04:39.080 --> 00:04:42.610 extensions in there and activate them. Like live reload. 00:04:42.610 --> 00:04:45.280 And you can pull these extensions off of that 00:04:45.280 --> 00:04:49.950 directory that is on the middleman website. And then 00:04:49.950 --> 00:04:52.620 your production environment in middleman is called your build 00:04:52.640 --> 00:04:53.629 environment. 00:04:53.629 --> 00:04:56.951 So, in there, you're going to activate certain extensions, 00:04:56.960 --> 00:05:01.590 like minifying css, JavaScript, having an asset hash so 00:05:01.590 --> 00:05:04.350 that you can basically hash your assets and do 00:05:04.350 --> 00:05:06.400 what you do in Rails where you, you give 00:05:06.420 --> 00:05:09.520 your asset path a, a hash and a path, 00:05:09.520 --> 00:05:12.330 so that you can cache it. 00:05:12.330 --> 00:05:15.290 So, once you have this configuration setup and your 00:05:15.290 --> 00:05:18.090 webpages and stuff are, are ready to go, you 00:05:18.100 --> 00:05:21.220 have to deploy it somehow. And this is another 00:05:21.240 --> 00:05:24.150 area where middleman really shines is that, deployments are 00:05:24.150 --> 00:05:28.010 incredibly easy. It's two steps easy. There is the 00:05:28.010 --> 00:05:29.940 build command, which takes all of the templates and 00:05:29.940 --> 00:05:33.480 files and whatnot, and it basically compiles a bunch 00:05:33.500 --> 00:05:38.130 of html, css, and JavaScript files into a build 00:05:38.130 --> 00:05:40.870 directory. And then the, the best part about it 00:05:40.870 --> 00:05:42.470 is that getting that build directory up to your 00:05:42.470 --> 00:05:45.389 web server is as simple as rsync. Or, if 00:05:45.400 --> 00:05:47.001 you want to throwback to the days of using 00:05:47.001 --> 00:05:51.520 DreamWeaver, you could use FTP to upload it. Or 00:05:51.520 --> 00:05:54.170 SFTP if you're into the whole security thing. 00:05:54.170 --> 00:05:58.100 I developed a, a gem called shart, appropriately, hoping 00:05:58.100 --> 00:06:00.949 that it would make for an awkward IT conversation 00:06:00.960 --> 00:06:03.781 in some corporate environment, where you can deploy your 00:06:03.781 --> 00:06:06.270 middleman website up to an S3 bucket, and you 00:06:06.280 --> 00:06:08.400 can actually set the headers that are going to 00:06:08.400 --> 00:06:13.540 emitted from that S3 bucket. Mostly caching headers on, 00:06:13.540 --> 00:06:15.050 on certain assets. 00:06:15.050 --> 00:06:16.840 So there's a ton of tools you can use, 00:06:16.860 --> 00:06:19.000 and there's a ton of deployment targets that you 00:06:19.000 --> 00:06:21.120 can choose from for middleman. If you do go 00:06:21.120 --> 00:06:23.180 the route of deploying to S3, it's an incredibly 00:06:23.180 --> 00:06:26.910 cheap way to really run your website. You just 00:06:26.910 --> 00:06:29.040 pay a couple cents a month for a, a 00:06:29.040 --> 00:06:33.150 personal website. And it's also incredibly scalable, whenever you're 00:06:33.160 --> 00:06:35.919 deploying to an S3 endpoint. 00:06:35.920 --> 00:06:40.361 So. Yippie. You have a static website. You know, 00:06:40.361 --> 00:06:42.229 why should you care about middleman? How is this 00:06:42.229 --> 00:06:48.000 going to, to help you scale your application? 00:06:48.000 --> 00:06:49.981 Before I dive into that, it's really important to 00:06:49.981 --> 00:06:54.420 kind of understand the place that middleman will have 00:06:54.420 --> 00:06:58.219 in this spectrum of dynacism, is what I call 00:06:58.220 --> 00:07:00.111 it. And it turns out dynacism is not actually 00:07:00.120 --> 00:07:02.930 a word, so. I had to ignore the, the 00:07:02.930 --> 00:07:04.200 spellchecker on this thing. 00:07:04.200 --> 00:07:08.080 And it looks something like this. So the graph 00:07:08.080 --> 00:07:10.930 that you saw earlier was actually a static web 00:07:10.930 --> 00:07:14.410 application. And if you access PollIt dot com slash 00:07:14.410 --> 00:07:16.919 brad on your smart phone, that was another static 00:07:16.940 --> 00:07:18.220 web application. 00:07:18.220 --> 00:07:22.750 So, that's a very dynamic application, though, in that 00:07:22.750 --> 00:07:25.281 the chart has to move and animate and pull 00:07:25.281 --> 00:07:27.640 this data from the server in real time. In 00:07:27.660 --> 00:07:30.070 under, you know, a second, it has to get 00:07:30.070 --> 00:07:32.490 from all of your phones, whether it comes from 00:07:32.490 --> 00:07:34.679 SMS or your smart phone, we have to get 00:07:34.680 --> 00:07:36.441 it up on that graph in a really short 00:07:36.441 --> 00:07:38.300 amount of time. 00:07:38.300 --> 00:07:42.179 So that is arguably a highly dynamic application. And 00:07:42.180 --> 00:07:44.631 we also have to make things really smooth and 00:07:44.640 --> 00:07:47.779 seem very fluid, because that's just what you have 00:07:47.780 --> 00:07:51.351 to do for presentations like this. So as we 00:07:51.360 --> 00:07:56.770 go down the dynacism spectrum, you have your GUI-oriented 00:07:56.770 --> 00:07:57.510 applications. 00:07:57.510 --> 00:08:00.619 So, Google spreadsheets - you're probably very familiar with 00:08:00.640 --> 00:08:03.091 that. Who hasn't used it? You're doing a lot 00:08:03.091 --> 00:08:05.469 of actions, a lot of very short actions, and 00:08:05.480 --> 00:08:08.920 you don't want to build applications where you click 00:08:08.920 --> 00:08:09.960 a button and then you have to wait for 00:08:09.960 --> 00:08:12.950 a response to come back to a server. The, 00:08:12.950 --> 00:08:15.660 basically the functions of the GUI are very tightly-coupled 00:08:15.660 --> 00:08:18.360 with what comes out of that. 00:08:18.360 --> 00:08:20.860 So we kind of start moving down into document-oriented 00:08:20.860 --> 00:08:23.910 web apps, like an invoicing application or Base Camp 00:08:23.920 --> 00:08:25.879 where you can, you start to get into Rails 00:08:25.880 --> 00:08:28.851 territory, where Rails is, it's kind of the sweet 00:08:28.860 --> 00:08:32.889 spot between these highly dynamic applications or these highly 00:08:32.889 --> 00:08:35.140 static applications. 00:08:35.140 --> 00:08:38.250 So moving down into the blogging platform world, you 00:08:38.250 --> 00:08:41.900 may have something like Subtle or PostHaven, that is 00:08:41.900 --> 00:08:44.231 backed by mySQL, but for the most part it's 00:08:44.240 --> 00:08:48.840 just storing these documents in a database server, just 00:08:48.840 --> 00:08:51.980 for the convenience of administering many users in a 00:08:51.980 --> 00:08:54.430 multi-tendency environment. 00:08:54.440 --> 00:08:56.300 And then you go on down to your personal 00:08:56.300 --> 00:08:57.940 blog, and maybe some of you have a GitHub 00:08:57.940 --> 00:09:01.020 site. Maybe you're using Jekyll for that. Maybe you're 00:09:01.020 --> 00:09:04.980 using middleman. All the way down to informational websites, 00:09:04.980 --> 00:09:07.800 like a mom and pop shop or Steve's plumping 00:09:07.800 --> 00:09:08.410 services. 00:09:08.410 --> 00:09:10.519 If somebody wants to make a killing, go out 00:09:10.520 --> 00:09:13.680 there and sell these restaurants that have flash websites, 00:09:13.700 --> 00:09:16.200 sell them on a middleman website so that we 00:09:16.200 --> 00:09:17.971 can get some html out there and have less 00:09:17.980 --> 00:09:21.839 flash on the internet. 00:09:21.840 --> 00:09:24.751 So, where does middleman kind of fit into all 00:09:24.751 --> 00:09:28.380 of this? If you're working on a green-filled application, 00:09:28.380 --> 00:09:30.810 it's pretty easy to get started right away. Kind 00:09:30.810 --> 00:09:33.410 of what you hear about doing today is, you 00:09:33.420 --> 00:09:36.550 build your single page html application over here and 00:09:36.550 --> 00:09:38.819 you build your smaller kind of API off to 00:09:38.840 --> 00:09:41.051 the side using Sinatra or some type of, of 00:09:41.051 --> 00:09:42.750 microframework. 00:09:42.750 --> 00:09:46.400 But, since we've been around as a company for, 00:09:46.400 --> 00:09:50.270 well, since 2008, we actually started out using Rails 00:09:50.270 --> 00:09:53.610 1 point 2, I believe. It was before REST 00:09:53.640 --> 00:09:57.040 was even a thing in Rails. So we had 00:09:57.040 --> 00:10:00.310 this green-filled application. We spin this thing up. It 00:10:00.310 --> 00:10:01.960 was great. We were able to move pretty fast 00:10:01.960 --> 00:10:05.030 inside of this framework. And we just set up 00:10:05.030 --> 00:10:07.930 this application at polleverywhere dot com. The real time 00:10:07.940 --> 00:10:10.350 components we had, I don't know if anybody remembers 00:10:10.350 --> 00:10:14.059 RJS, but that was basically how we would make 00:10:14.060 --> 00:10:17.051 things appear in, in real time on Rails, was 00:10:17.060 --> 00:10:21.400 through these kind of, in retrospect, horrendous helpers that 00:10:21.420 --> 00:10:24.640 would emit JavaScript from the server and run on 00:10:24.640 --> 00:10:25.830 your web page. 00:10:25.830 --> 00:10:28.190 So, we got a lot of mileage out of 00:10:28.190 --> 00:10:30.490 that. But it wasn't, it wasn't really enough. We 00:10:30.500 --> 00:10:33.380 needed something that was more visually appealing than just 00:10:33.380 --> 00:10:36.710 updating some numbers on a table. So that's when 00:10:36.710 --> 00:10:39.800 we turned to flex, because they happened to have 00:10:39.800 --> 00:10:43.650 this bar chart library that everything updated in real 00:10:43.650 --> 00:10:45.260 time. There was just a lot of stuff that 00:10:45.260 --> 00:10:46.920 worked out of the box. 00:10:46.920 --> 00:10:49.380 And it also just happened, out of sheer dumb 00:10:49.380 --> 00:10:54.290 luck, that flash was installed on 99-some-odd-percent of, just 00:10:54.300 --> 00:10:56.980 all machines out on the internet. But even more 00:10:56.980 --> 00:11:00.300 compelling is that you could embed a flash asset 00:11:00.300 --> 00:11:04.819 into a PowerPoint slide because of good-old ActiveX. 00:11:04.820 --> 00:11:06.911 So we did this kind of weird hack where 00:11:06.920 --> 00:11:10.550 we would embed these swifts that we would generate. 00:11:10.550 --> 00:11:13.189 These Flex applications, and we would actually embed them 00:11:13.189 --> 00:11:15.971 into a PowerPoint slide and send those out up 00:11:15.980 --> 00:11:17.720 on the server so that people could download these 00:11:17.740 --> 00:11:21.930 polls embedded right into PowerPoint slides. So whenever they 00:11:21.930 --> 00:11:24.759 opened it, nothing really had to be loaded up 00:11:24.760 --> 00:11:28.020 over the conference wifi connections in their slide. The 00:11:28.020 --> 00:11:30.330 swift application would just connect out to our Rails 00:11:30.330 --> 00:11:33.581 app and start pulling data out of it. 00:11:33.581 --> 00:11:36.730 So we initially had this flex application in the 00:11:36.730 --> 00:11:41.830 same code repository as we did our Rails application. 00:11:41.860 --> 00:11:44.060 So as we started to build more customers, things 00:11:44.060 --> 00:11:47.180 became more complex, and we were able to afford 00:11:47.180 --> 00:11:49.390 a contractor who came in and just started shredding 00:11:49.390 --> 00:11:50.889 it on this Flex app and really making a 00:11:50.900 --> 00:11:53.900 lot of progress. To the point where we started 00:11:53.900 --> 00:11:57.331 getting annoyed at just how many commit messages that 00:11:57.331 --> 00:11:59.280 he would have in our, I believe it was 00:11:59.280 --> 00:12:02.440 actually SVN at the time. So we broke that 00:12:02.440 --> 00:12:05.269 out into a, a separate application. And we were 00:12:05.269 --> 00:12:08.481 able to move a lot quicker, in the fact 00:12:08.481 --> 00:12:10.069 that we got to separate deployments. 00:12:10.080 --> 00:12:11.981 So, we had this contractor working over here on 00:12:11.981 --> 00:12:13.660 the Flex app, and he was able to deploy 00:12:13.660 --> 00:12:15.880 those Swift assets out to production. And meanwhile the 00:12:15.880 --> 00:12:19.199 Rails app team was able to do their work 00:12:19.200 --> 00:12:21.770 and, kind of, push their updates out through a 00:12:21.780 --> 00:12:24.301 separate release cycle. And, of course, at the time, 00:12:24.301 --> 00:12:27.180 it was a lot easier for Flex to work 00:12:27.180 --> 00:12:30.550 with XML, so we had a very fashionable XML 00:12:30.550 --> 00:12:31.750 API. 00:12:31.750 --> 00:12:35.259 So, time went on, and mobile started to change. 00:12:35.260 --> 00:12:38.621 It wasn't just about SMS anymore. So we had 00:12:38.621 --> 00:12:41.870 to think about the smart phone thing that was, 00:12:41.870 --> 00:12:44.390 that was taking off. Really it was the advent 00:12:44.420 --> 00:12:46.180 of the iPhone. 00:12:46.180 --> 00:12:49.170 So, having a lot of really good luck in 00:12:49.170 --> 00:12:52.600 the past with frameworks, including Rails and, and some 00:12:52.600 --> 00:12:55.230 of the visual components that Flex gave us, naturally 00:12:55.230 --> 00:13:00.240 we gravitated towards using jQuery mobile. And the other 00:13:00.240 --> 00:13:02.559 thing, dot mobe extension, was this thing that I 00:13:02.560 --> 00:13:07.391 saw on RailsCasts about this new-fangled way to kind 00:13:07.400 --> 00:13:09.230 of say, hey, this dot mobe format is gonna 00:13:09.240 --> 00:13:11.560 serve up this, this mobile stuff that's kind of 00:13:11.560 --> 00:13:13.050 like html. 00:13:13.050 --> 00:13:16.790 So, it turned out that was a really bad 00:13:16.790 --> 00:13:20.620 idea. The way that jQuery mobile worked got us 00:13:20.620 --> 00:13:22.620 about 80% of the way there, but the other 00:13:22.620 --> 00:13:26.879 20% was just extraordinarily painful. The jQuery mobile framework 00:13:26.880 --> 00:13:30.901 was extremely opinionated. It wanted data in a certain 00:13:30.901 --> 00:13:32.220 way. It wanted the DOM to be structured a 00:13:32.240 --> 00:13:34.610 certain way. It felt kind of clunky and we 00:13:34.610 --> 00:13:36.650 just felt like we were kind of stuck inside 00:13:36.650 --> 00:13:40.260 of the, the jQuery mobile world. 00:13:40.280 --> 00:13:43.590 So, our team had to, had to do some 00:13:43.600 --> 00:13:46.180 soul searching on this front. And what we decided, 00:13:46.180 --> 00:13:48.880 at the time, was, you know, instead of trying 00:13:48.880 --> 00:13:52.209 to pick a framework, let's actually focus at the 00:13:52.209 --> 00:13:55.101 specific problems that we're trying to solve, and let's 00:13:55.101 --> 00:13:57.540 focus on picking libraries. 00:13:57.540 --> 00:14:00.569 So, that made our thinking a lot more clear, 00:14:00.569 --> 00:14:03.250 and we were able to pick exactly what we 00:14:03.250 --> 00:14:06.821 needed it. Or, yeah, pick exactly what we need, 00:14:06.821 --> 00:14:08.619 and bring it in our application where we needed 00:14:08.620 --> 00:14:09.261 it. 00:14:09.261 --> 00:14:11.320 So, at the time, as well, there was still 00:14:11.340 --> 00:14:14.600 a lot going on in the JavaScript MVC world. 00:14:14.600 --> 00:14:16.829 You had sproutcore was one, was one of the 00:14:16.829 --> 00:14:20.101 frameworks that we looked at. And that was not 00:14:20.101 --> 00:14:23.379 really that good-looking in terms of where we came 00:14:23.400 --> 00:14:25.001 from with jQuery mobile. 00:14:25.001 --> 00:14:28.790 So, we decided to go full speed ahead and 00:14:28.790 --> 00:14:31.730 use backbone.js, which was, I think, at version point 00:14:31.740 --> 00:14:33.380 eight at the time. And we knew that we 00:14:33.380 --> 00:14:35.790 would probably be swapping out libraries, because the space 00:14:35.790 --> 00:14:38.060 was still maturing very rapidly, and there were a 00:14:38.060 --> 00:14:41.030 lot of changes. So this approach really let us 00:14:41.030 --> 00:14:43.809 hand-pick the libraries we need and swap them out 00:14:43.820 --> 00:14:45.941 as something else kind of pulled ahead of, you 00:14:45.941 --> 00:14:48.280 know, another library. 00:14:48.280 --> 00:14:50.740 So we ended up with this single page mobile 00:14:50.740 --> 00:14:53.940 application that we built entirely inside of middleman. So 00:14:53.940 --> 00:14:57.259 middleman was handling all of the assets that, that 00:14:57.260 --> 00:14:59.820 this application was using. And it uses kind of 00:14:59.820 --> 00:15:02.991 the standard sprockets pipeline that, that you have in 00:15:03.000 --> 00:15:05.600 Rails. So whenever you build this thing, we have 00:15:05.600 --> 00:15:08.149 three files. We upload it to our EngineX server, 00:15:08.149 --> 00:15:11.791 and we were pretty happy with how this stuff 00:15:11.800 --> 00:15:15.639 ends up working out on production, especially for deployments. 00:15:15.640 --> 00:15:18.111 So, if you go down this route of building 00:15:18.111 --> 00:15:21.250 these single-page web applications, one thing that you need 00:15:21.260 --> 00:15:25.620 to be very aware of is CORS. So whenever 00:15:25.620 --> 00:15:28.779 you went to the pollit dot com single-page site 00:15:28.780 --> 00:15:32.291 on your phone, that was actually making a AJAX 00:15:32.291 --> 00:15:36.490 request to our polleverywhere dot com host to an 00:15:36.490 --> 00:15:38.530 API endpoint on there. 00:15:38.540 --> 00:15:40.370 So in order to do that without CORS is 00:15:40.380 --> 00:15:43.440 you get all these cross-domain errors for AJAX. But 00:15:43.440 --> 00:15:45.899 what CORS lets you do is, the pollit dot 00:15:45.900 --> 00:15:49.241 com host says, hey, polleverywhere dot com, I'm from 00:15:49.241 --> 00:15:51.560 a different domain. I want to make these types 00:15:51.560 --> 00:15:55.399 of HTTP requests. A GET request, a POST request, 00:15:55.400 --> 00:15:57.520 and, oh, by the way, I want access to 00:15:57.520 --> 00:16:00.171 these headers. So our polleverywhere dot com service says, 00:16:00.171 --> 00:16:02.530 OK, you're on our whitelist, polleverywhere dot com, so 00:16:02.540 --> 00:16:05.360 here you go. Here's the data. Great. You want 00:16:05.360 --> 00:16:08.940 to POST something. I'll accept that request. And if 00:16:08.940 --> 00:16:12.820 another domain tried to access it, it would just 00:16:12.820 --> 00:16:15.480 give them the cross-domain error. 00:16:15.480 --> 00:16:17.399 So that's how we, we got around that issue. 00:16:17.400 --> 00:16:20.541 And then another really great thing about the way 00:16:20.541 --> 00:16:22.959 that we deploy this mobile app is, it's really 00:16:22.960 --> 00:16:26.411 easy to deploy this to a CDN. You actually 00:16:26.411 --> 00:16:29.449 have these assets that you can push out to 00:16:29.460 --> 00:16:32.770 other servers. So you can't really do that with 00:16:32.770 --> 00:16:34.890 a Rails app, per se. You can't just take 00:16:34.890 --> 00:16:37.111 it and stick it over here on this file 00:16:37.120 --> 00:16:39.610 system on this server without having to boot a 00:16:39.620 --> 00:16:43.600 bunch of stuff and go through all that. 00:16:43.600 --> 00:16:47.250 So another interesting kind of feature of that is 00:16:47.250 --> 00:16:49.769 that you can deploy to floppy discs. So when's 00:16:49.769 --> 00:16:54.320 the last time that anybody's seen one of these? 00:16:54.340 --> 00:16:56.431 And we have these readers here. You pick these 00:16:56.431 --> 00:16:59.400 up for about fifteen bucks off of Amazon. And 00:16:59.400 --> 00:17:01.180 what I'm actually going to do is a live 00:17:01.180 --> 00:17:05.119 hardware demo. Possibly the only one at RailsConf. And 00:17:05.119 --> 00:17:09.829 let's plug this in. The really surprising thing, to 00:17:09.829 --> 00:17:15.732 me, was that Mac OS actually recognizes floppy drives. 00:17:15.740 --> 00:17:21.689 So let's plug this guy in here. Op. 00:17:21.920 --> 00:17:28.920 Devices. I think that's devices. Oh, I got to 00:17:32.520 --> 00:17:39.520 put the disc in. All right. So you can 00:17:44.640 --> 00:17:50.181 hear the, hear the disc spinning. Oh, let's see. 00:17:50.200 --> 00:17:54.489 There it is. Boy, that's hard to see up 00:17:54.489 --> 00:17:58.490 here. All right. So here's the application. We'll just 00:17:58.490 --> 00:18:03.410 launch this. 00:18:03.410 --> 00:18:09.719 [laughter] 00:18:11.620 --> 00:18:15.000 So hopefully your network connection is faster than a, 00:18:15.020 --> 00:18:18.150 a floppy disc, but if you have a customer 00:18:18.150 --> 00:18:20.370 living somewhere remote and the only way to get 00:18:20.370 --> 00:18:22.720 something to them is by Pony Express, you can 00:18:22.740 --> 00:18:26.000 just put this floppy disc in a satchel and, 00:18:26.000 --> 00:18:29.071 and send the pony on its way. 00:18:29.071 --> 00:18:31.769 The really fun thing is opening network inspector on 00:18:31.769 --> 00:18:35.030 this and seeing how Chrome measures this. Is it 00:18:35.040 --> 00:18:37.410 latency, or is the file really taking that long 00:18:37.420 --> 00:18:38.170 to load? 00:18:38.170 --> 00:18:41.311 So, here you go. You just saw a web 00:18:41.320 --> 00:18:46.460 application booted from a floppy disc. I can go 00:18:46.460 --> 00:18:53.460 to my pollev page and submit a vote. So, 00:18:54.620 --> 00:18:58.270 we joke about coming up with a floppy.js library, 00:18:58.270 --> 00:19:00.550 because if you can see the inspector down there, 00:19:00.550 --> 00:19:02.860 I don't know if it shows, but the retina 00:19:02.880 --> 00:19:04.990 assets aren't loaded. Those were too big to fit 00:19:04.990 --> 00:19:07.561 on this floppy disc, so we came up with 00:19:07.561 --> 00:19:11.099 some fun ideas to span our JavaScript across floppy 00:19:11.100 --> 00:19:14.370 discs. But we had better things to do like 00:19:14.370 --> 00:19:16.790 fix bugs in production. 00:19:16.790 --> 00:19:21.171 So, great. You can put this on floppy discs. 00:19:21.200 --> 00:19:22.809 But I think more importantly there is, you can 00:19:22.809 --> 00:19:25.770 put them inside of phone gap or Cordova apps 00:19:25.770 --> 00:19:27.451 or we have some customers that they want to 00:19:27.460 --> 00:19:30.789 bundle our voting application with one of their mobile 00:19:30.800 --> 00:19:33.081 applications. So we can say, here is our html 00:19:33.081 --> 00:19:35.899 assets, you can put them within your application, and 00:19:35.900 --> 00:19:38.020 then whenever there's three-hundred people sitting in a conference 00:19:38.020 --> 00:19:44.030 room, it won't overload the wifi. 00:19:44.030 --> 00:19:47.420 So, caching aside, there's, there's another component to this. 00:19:47.420 --> 00:19:51.170 Flex, Flex started getting old. It started getting outdated. 00:19:51.180 --> 00:19:53.040 The writing was on the wall that this stuff 00:19:53.040 --> 00:19:55.760 was going to die. So, you know, we set 00:19:55.760 --> 00:19:57.471 out to write a utilization app, it was very 00:19:57.471 --> 00:19:59.700 natural for us to think, oh, you know what, 00:19:59.700 --> 00:20:01.820 let's use middleman. We want this thing to work 00:20:01.820 --> 00:20:05.190 on tablets, iPhones, and everywhere, so naturally we're going 00:20:05.190 --> 00:20:06.550 to use - oh, what do we call it 00:20:06.550 --> 00:20:08.529 today? HTML5. Let's use that. 00:20:08.560 --> 00:20:11.890 Let's use that HTML5 thing to talk to our 00:20:11.890 --> 00:20:15.441 JSON API. And that worked great. We got this 00:20:15.441 --> 00:20:19.139 application out there. It's actually what you saw today, 00:20:19.140 --> 00:20:21.500 it's that HTML5 application. We have all the benefits 00:20:21.500 --> 00:20:24.840 of caching and the CDN and whatnot. But, but 00:20:24.840 --> 00:20:27.790 something came up. Whenever we were looking at these 00:20:27.790 --> 00:20:30.931 visualizations day in and day out, we just said, 00:20:30.940 --> 00:20:33.369 jeez, these feel really slow, because we were using 00:20:33.369 --> 00:20:35.230 short polling. We were hitting our server once every 00:20:35.230 --> 00:20:38.030 couple of seconds to get the new data from 00:20:38.060 --> 00:20:41.520 our server to, to update on the graph. 00:20:41.520 --> 00:20:42.880 So we decided we wanted to do better than 00:20:42.880 --> 00:20:46.390 that. We rolled out a Stream API. We actually 00:20:46.390 --> 00:20:48.831 wrote our own server at the time, because socket 00:20:48.840 --> 00:20:51.440 io wasn't quite what we wanted. I, I actually 00:20:51.440 --> 00:20:54.950 gave a talk in 2012 about this, about streaming 00:20:54.950 --> 00:20:58.060 resources. So we threw up that streaming API server, 00:20:58.060 --> 00:20:59.560 but there were some problems with it. 00:20:59.560 --> 00:21:02.509 Back in 2012, when I gave that talk, we 00:21:02.520 --> 00:21:06.191 were using AMQP on the backend of this thing. 00:21:06.191 --> 00:21:08.159 And there were just a lot of stability issues 00:21:08.160 --> 00:21:10.211 with that. It wasn't quite working with the, with 00:21:10.220 --> 00:21:13.190 the grain of the web and how resources work 00:21:13.190 --> 00:21:15.789 and, and how caching and all that stuff works. 00:21:15.789 --> 00:21:19.171 So, we had these stability issues that we were 00:21:19.180 --> 00:21:22.119 trying to deal with, and what was really nice 00:21:22.120 --> 00:21:25.000 about having these client-side applications, is we were able 00:21:25.000 --> 00:21:27.431 to spit up our stream server on its own 00:21:27.440 --> 00:21:30.779 host, its own completely different host, and isolate it. 00:21:30.780 --> 00:21:32.081 Our team had a lot of learning to do 00:21:32.081 --> 00:21:35.149 to understand how to, not only build these real 00:21:35.149 --> 00:21:37.590 time web applications, how to operate them. How to 00:21:37.590 --> 00:21:38.830 scale them. 00:21:38.830 --> 00:21:41.360 So whenever we rolled this thing out, we'd have 00:21:41.360 --> 00:21:45.181 crashes, and our client-side application was able to seamlessly, 00:21:45.181 --> 00:21:49.829 basically fail over to HTTP short polling. So over 00:21:49.860 --> 00:21:52.260 time, our team got much better at just kind 00:21:52.260 --> 00:21:58.560 of managing all these pieces. And we had client-side 00:21:58.560 --> 00:22:02.100 SOA going on there. So, you can also, with 00:22:02.100 --> 00:22:04.170 CORS, if there's several APIs that you have out 00:22:04.170 --> 00:22:08.170 there, you can consume those from your JavaScript and 00:22:08.170 --> 00:22:11.210 kind of munch all that stuff together client side 00:22:11.210 --> 00:22:13.561 and just do whatever it is that you please 00:22:13.561 --> 00:22:15.119 with that data. 00:22:15.140 --> 00:22:18.590 So, we had so much success with all these 00:22:18.590 --> 00:22:22.571 middleman, these single-page middleman applications, that we started to 00:22:22.580 --> 00:22:25.029 build all of our other applications in these. So 00:22:25.029 --> 00:22:28.490 our approach towards native integrations has been, basically, let's 00:22:28.490 --> 00:22:31.390 build a special web browser that has these certain 00:22:31.420 --> 00:22:34.480 hooks into JavaScript so that our web developers can, 00:22:34.480 --> 00:22:39.091 can be more productive and interact more with basically 00:22:39.091 --> 00:22:40.879 the native application. 00:22:40.880 --> 00:22:43.290 So we can control a lot of different things 00:22:43.300 --> 00:22:47.290 with these integrations from JavaScript. So we start having 00:22:47.290 --> 00:22:50.880 all these backbone applications pop up. Now, if you've 00:22:50.880 --> 00:22:54.260 dealt with several applications, you may be thinking, jeez, 00:22:54.260 --> 00:22:57.081 you know, you're probably repeating yourself with a lot 00:22:57.081 --> 00:22:58.739 of different things. So how do you get a 00:22:58.740 --> 00:23:02.850 handle on this stuff in this world of sprockets 00:23:02.850 --> 00:23:04.980 and middleman? 00:23:04.980 --> 00:23:06.910 So what we did is we took all of 00:23:06.920 --> 00:23:09.711 kind of the common components of this, the session 00:23:09.720 --> 00:23:13.269 components, the models and backbone. We pulled all these 00:23:13.269 --> 00:23:17.561 into this one asset gem that then everything consumes 00:23:17.561 --> 00:23:21.180 from there. So to make those gems, it's just 00:23:21.180 --> 00:23:24.889 like making any other gem. You just say bundler 00:23:24.889 --> 00:23:26.870 gem and then whatever the name is of your 00:23:26.870 --> 00:23:30.070 gem. Here we have pollitassets. And the kind of 00:23:30.080 --> 00:23:32.510 different thing about this gem is that, you check 00:23:32.520 --> 00:23:34.250 is sprockets is there. And if it is, then 00:23:34.250 --> 00:23:37.150 you start appending all these paths toward the assets 00:23:37.150 --> 00:23:38.210 where your asset gem lives. 00:23:38.220 --> 00:23:42.821 So, for example, in our lib/assets JavaScripts gem, we 00:23:42.840 --> 00:23:46.070 have a user backbone model. We have a poll 00:23:46.070 --> 00:23:50.690 backbone model. The stylesheets. We actually use font icons 00:23:50.700 --> 00:23:53.289 everywhere, so that we can fit all this stuff 00:23:53.289 --> 00:23:55.500 on a floppy drive. 00:23:55.500 --> 00:23:59.040 So, we can have all these assets located here, 00:23:59.040 --> 00:24:01.970 which whenever all the other applications consume that, they 00:24:01.970 --> 00:24:04.220 can have a consistent look and feel that uses 00:24:04.220 --> 00:24:06.311 kind of the visual language that we want to 00:24:06.320 --> 00:24:09.349 use throughout all of our applications and all the 00:24:09.349 --> 00:24:11.010 different platforms. 00:24:11.010 --> 00:24:13.480 And of course you have your vendor JavaScript assets. 00:24:13.500 --> 00:24:15.990 So if you have four different projects out there, 00:24:15.990 --> 00:24:18.681 you're probably using four different versions of jQuery. This 00:24:18.681 --> 00:24:20.519 lets us use one version of jQuery and one 00:24:20.520 --> 00:24:23.830 version of backbone. 00:24:23.830 --> 00:24:26.700 The way that we manage these in our development 00:24:26.700 --> 00:24:30.140 environment is just through bundler. So you can imagine 00:24:30.140 --> 00:24:32.580 if you have one version of jQuery, well what 00:24:32.580 --> 00:24:35.000 happens whenever you bump from the one dot x 00:24:35.020 --> 00:24:36.750 to two dot x? You're probably gonna break a 00:24:36.750 --> 00:24:39.500 lot of stuff. 00:24:39.520 --> 00:24:42.150 But we actually don't have that problem, because like 00:24:42.150 --> 00:24:44.691 with RubyGems, you don't really care if there's an 00:24:44.700 --> 00:24:47.359 upgrade happening. What you care about is that you're 00:24:47.360 --> 00:24:50.560 getting the version that you asked for in your 00:24:50.560 --> 00:24:55.600 gem bundle. So we're able to control that by 00:24:55.600 --> 00:24:59.670 pushing our pollev assets up to a basic Git 00:24:59.670 --> 00:25:02.730 repository, and we reference that from this gemfile. You 00:25:02.730 --> 00:25:04.870 don't actually see the, the git reference in there, 00:25:04.880 --> 00:25:07.201 but you can see that, in this case, we're 00:25:07.201 --> 00:25:09.320 saying, hey, I want to use the new feature 00:25:09.320 --> 00:25:13.669 branch of pollev assets. The assets path thing above 00:25:13.669 --> 00:25:17.051 that is a nice little hack so that if 00:25:17.060 --> 00:25:22.109 you're making changes to the pollev assets project, you 00:25:22.109 --> 00:25:23.790 can pull those locally so that you don't have 00:25:23.790 --> 00:25:26.020 to run bundle update every time. 00:25:26.040 --> 00:25:28.360 And what's cool about middleman is, if you're developing 00:25:28.360 --> 00:25:31.530 these pollev assets locally, whenever you reload middleman, it 00:25:31.530 --> 00:25:35.171 actually picks up the changes from the, the assets 00:25:35.180 --> 00:25:37.529 gem. You don't have to reboot the server or 00:25:37.540 --> 00:25:40.211 do anything crazy like that. 00:25:40.211 --> 00:25:44.249 So, the way that we can build new features 00:25:44.249 --> 00:25:46.580 now, let's say that, let's say the worst case 00:25:46.580 --> 00:25:48.380 scenario, I have to build a new API to 00:25:48.400 --> 00:25:52.020 support a new feature. I can branch my Rails 00:25:52.020 --> 00:25:54.260 app project, and I can say, hey, branch this 00:25:54.260 --> 00:25:57.850 off. It's called new feature. I'm gonna add some 00:25:57.850 --> 00:25:59.510 kind of new visualization to it that needs a 00:25:59.510 --> 00:26:01.880 new API. So I can build that API out 00:26:01.900 --> 00:26:04.240 on my server. I can develop that locally. And 00:26:04.240 --> 00:26:07.510 I can point my middleman project at my local 00:26:07.510 --> 00:26:08.540 server. 00:26:08.540 --> 00:26:09.831 And I can branch it in here and I 00:26:09.840 --> 00:26:12.559 can branch pollev assets, and basically have three different 00:26:12.560 --> 00:26:16.071 branches or, sorry, one branch and three different repos, 00:26:16.071 --> 00:26:18.560 all working on the same feature. And then whenever 00:26:18.560 --> 00:26:22.989 I go to deploy, obviously deploy the API server 00:26:22.989 --> 00:26:25.780 functionality first, and then it would go on to 00:26:25.800 --> 00:26:29.000 roll out these middleman single page websites. 00:26:29.000 --> 00:26:34.060 So, does it work? I think so. It's, it's 00:26:34.060 --> 00:26:37.029 worked really well for us. We have to deal 00:26:37.029 --> 00:26:40.990 with some weird kind of bandwidth constrained environments, where 00:26:41.000 --> 00:26:46.181 you can't trust conference wifi connections. And it also, 00:26:46.181 --> 00:26:48.080 I realized that it worked really well for us 00:26:48.080 --> 00:26:51.889 when, about two months ago, Microsoft wanted to launch 00:26:51.889 --> 00:26:58.600 their PowerPoint 2013 store inside of the Microsoft Office 00:26:58.600 --> 00:27:00.470 Applications. They actually have an app store inside of 00:27:00.480 --> 00:27:02.720 there. And we were able to pull a bunch 00:27:02.720 --> 00:27:06.240 of assets from our mobile application into our sprockets 00:27:06.240 --> 00:27:09.550 asset gem and reuse all of that stuff, most 00:27:09.550 --> 00:27:12.650 of it, in the PowerPoint 2013 app. And then 00:27:12.660 --> 00:27:15.880 we were able to quickly make some customizations to 00:27:15.880 --> 00:27:17.610 that whole user experience to make it fit in 00:27:17.610 --> 00:27:20.330 with Office 2013 a little bit better. 00:27:20.340 --> 00:27:22.920 And, of course, whenever you're running a single-page JavaScript 00:27:22.920 --> 00:27:26.730 application inside of this little web iframe, essentially in 00:27:26.730 --> 00:27:30.960 Office, it feels very close. It feels very native. 00:27:30.960 --> 00:27:32.469 So that, that worked pretty well for us. But 00:27:32.469 --> 00:27:35.920 I think, even better than that, than reusing functionality 00:27:35.920 --> 00:27:38.990 is, inevitably, whenever you work on some of these 00:27:38.990 --> 00:27:41.000 projects, you make some kind of improvement. Something just 00:27:41.020 --> 00:27:44.230 feels better about maybe handling a login or some 00:27:44.230 --> 00:27:46.240 kind of status code or something. 00:27:46.240 --> 00:27:48.571 So these improvements that we make in these individual 00:27:48.580 --> 00:27:50.830 projects, we're able to pull them back into the 00:27:50.830 --> 00:27:53.549 sprockets assets gem and then push them back out 00:27:53.560 --> 00:27:55.441 to all of our other projects. So all these 00:27:55.441 --> 00:27:58.019 other projects you see up here benefit from the 00:27:58.020 --> 00:28:02.660 PowerPoint 2013 app, and that just keep, kind of 00:28:02.660 --> 00:28:04.360 reinforces itself. Reinforcing itself. 00:28:04.360 --> 00:28:07.590 So, in a sense, the sprockets assets gem turns 00:28:07.590 --> 00:28:11.150 into this little, perfect little framework for your organization 00:28:11.150 --> 00:28:14.421 that's extracted in the right way, where it's being 00:28:14.421 --> 00:28:17.279 extracted from stuff that's actually being used and being 00:28:17.300 --> 00:28:21.760 proven as successful by customers. 00:28:21.760 --> 00:28:26.441 So, that's a pretty good overview of one of 00:28:26.441 --> 00:28:29.849 the more complex middleman deployments I would say is 00:28:29.849 --> 00:28:33.090 out there, and just managing kind of multiple projects. 00:28:33.100 --> 00:28:36.310 One of the downsides and also plus sides of 00:28:36.310 --> 00:28:40.870 middleman is that there's no out-of-the-box JavaScript MVC app 00:28:40.870 --> 00:28:44.790 solution in there. So in the case of backbone, 00:28:44.790 --> 00:28:46.890 it's up to you to organize all the assets 00:28:46.900 --> 00:28:49.710 in some way that, that makes sense. And different 00:28:49.720 --> 00:28:52.520 JavaScript frameworks have, some are more organized than others. 00:28:52.520 --> 00:28:56.220 So that's both a blessing and a curse. 00:28:56.220 --> 00:28:58.670 It worked out for us because there really wasn't 00:28:58.680 --> 00:28:59.840 a framework. We kind of came up with our 00:28:59.840 --> 00:29:01.480 own and we didn't have to deal with, with 00:29:01.480 --> 00:29:04.711 somebody else's bad framework. 00:29:04.711 --> 00:29:08.909 So, that was the overview of the highly dynamic 00:29:08.909 --> 00:29:11.191 website, which has all these static 00:29:11.200 --> 00:29:13.959 applications stashed everywhere. 00:29:13.960 --> 00:29:17.990 What about static websites? The other side of the 00:29:17.990 --> 00:29:21.280 kind of token where Rails fills the middle ground? 00:29:21.280 --> 00:29:25.700 So, we're developing a lot of content for, for 00:29:25.720 --> 00:29:29.610 our website. There's an explosion of use cases and 00:29:29.610 --> 00:29:32.561 all sorts of stuff that we have to implement. 00:29:32.561 --> 00:29:34.500 So one thing that we'll probably do on this 00:29:34.500 --> 00:29:39.360 front is extract out a content directory from Rails 00:29:39.360 --> 00:29:42.321 app. How many of you have a, in your 00:29:42.321 --> 00:29:44.200 Rails app, it starts out. You have kind of 00:29:44.200 --> 00:29:46.330 the home page, and then it turns into this 00:29:46.330 --> 00:29:48.649 directory called content, and then you have all these 00:29:48.649 --> 00:29:50.990 content pages. Maybe you end up with twenty or 00:29:51.000 --> 00:29:53.000 thirty of them one day and, before you notice 00:29:53.000 --> 00:29:55.670 this big junk drawer of content, and you have 00:29:55.670 --> 00:29:56.870 to look in your routes file and kind of 00:29:56.870 --> 00:29:58.480 make sense of all this stuff. 00:29:58.480 --> 00:30:02.870 So, in middleman, you don't, the directory structure is 00:30:02.880 --> 00:30:05.460 the routing structure. So that stuff checks out a 00:30:05.460 --> 00:30:07.520 lot nicer. And it's just much easier to handle 00:30:07.540 --> 00:30:11.060 this content. And there's also much better support in 00:30:11.060 --> 00:30:14.340 there for different things like image compression. You can 00:30:14.340 --> 00:30:18.441 png crush everything. So if you have designers building 00:30:18.441 --> 00:30:21.419 image assets and they don't understand the technicalities of 00:30:21.420 --> 00:30:24.660 making pngs much smaller, middleman can take care of 00:30:24.660 --> 00:30:26.400 that in its asset pipeline. 00:30:26.400 --> 00:30:30.970 And, of course, on a static website like that, 00:30:30.970 --> 00:30:34.420 you still have some dynamic components. You can't just 00:30:34.420 --> 00:30:37.451 throw a static website out there and just tell 00:30:37.460 --> 00:30:40.979 everybody, like, oh, no, forget about login state. There's 00:30:40.980 --> 00:30:42.880 some common things that people want to see, so 00:30:42.880 --> 00:30:45.211 you can take care of that with JavaScript, and 00:30:45.220 --> 00:30:46.729 you can run all that stuff client-side. 00:30:46.729 --> 00:30:49.100 So you can have some really lightweight JS that 00:30:49.100 --> 00:30:50.600 checks with the server. Maybe it checks for the 00:30:50.600 --> 00:30:53.760 presence of a cookie to see if, if the 00:30:53.760 --> 00:30:56.110 user's logged in or not. And then, of course, 00:30:56.120 --> 00:30:57.790 if you have a contact us form or anything 00:30:57.790 --> 00:31:02.020 like that, you would test these integration points with 00:31:02.020 --> 00:31:04.300 Rails so that whenever somebody types in stuff into 00:31:04.300 --> 00:31:06.170 a form and submits it, it hits your Rails 00:31:06.180 --> 00:31:07.810 app and hopefully it doesn't blow up. 00:31:07.810 --> 00:31:10.600 And, of course, you have other JavaScript applications, like 00:31:10.600 --> 00:31:13.490 Google Analytics, Optimize the Stripe. 00:31:13.500 --> 00:31:14.910 All these little JavaScript-y 00:31:14.910 --> 00:31:18.780 tools that you can throw in there. And, you 00:31:18.800 --> 00:31:21.470 know, it makes it a little more dynamic. 00:31:21.470 --> 00:31:23.160 So the nice thing about a static website is 00:31:23.160 --> 00:31:26.691 that you can't get taken down that easily, especially 00:31:26.700 --> 00:31:28.269 if you have this stuff up in an S3 00:31:28.269 --> 00:31:31.490 bucket or stashed in CDNs. I was at a 00:31:31.490 --> 00:31:33.200 middleman meet up about a year ago, and the 00:31:33.220 --> 00:31:35.880 folks from nest dot com were there. And they 00:31:35.880 --> 00:31:38.360 said they were using some CNS or some, some 00:31:38.360 --> 00:31:40.870 dynamic backend, and they kept being mentioned in the 00:31:40.870 --> 00:31:43.970 press. And their website kept getting really slow. 00:31:43.980 --> 00:31:45.780 So they looked at a few things and I 00:31:45.780 --> 00:31:48.310 think one option involved just throwing hardware at the 00:31:48.310 --> 00:31:51.340 problem. And they decided that wasn't sane. Let's just 00:31:51.340 --> 00:31:54.040 build a static website with middleman and push this 00:31:54.040 --> 00:31:56.480 stuff out there on a really simple server. And 00:31:56.480 --> 00:31:58.640 they no longer had any of these problems where 00:31:58.640 --> 00:32:00.340 their site would get taken down from a, an 00:32:00.340 --> 00:32:04.270 influx of, of traffic. 00:32:04.270 --> 00:32:06.510 So there's a lot of things to think about 00:32:06.520 --> 00:32:09.830 whenever you're building these middleman applications. 00:32:09.840 --> 00:32:10.480 I could probably 00:32:10.480 --> 00:32:12.480 give another two or three talks just on these 00:32:12.480 --> 00:32:15.650 items alone. If you want, ask me questions about 00:32:15.650 --> 00:32:19.170 this stuff later. But I don't have time to 00:32:19.170 --> 00:32:20.440 cover that now. 00:32:20.440 --> 00:32:22.950 And, of course, I encourage you to get out 00:32:22.950 --> 00:32:25.680 there. Build your next website with middleman, even if 00:32:25.700 --> 00:32:28.160 it's a personal website or a blog or something. 00:32:28.160 --> 00:32:31.840 Try it out. If you're working on single web 00:32:31.840 --> 00:32:34.660 page applications, you could take your handcrafted stuff and 00:32:34.660 --> 00:32:36.691 throw it into middleman and start using that. Start 00:32:36.700 --> 00:32:38.759 using the asset pipeline. 00:32:38.760 --> 00:32:41.400 A lot of these ideas that I've talked about 00:32:41.400 --> 00:32:43.571 today, and some of the things I didn't talk 00:32:43.571 --> 00:32:45.849 about, our company polleverything is 00:32:45.860 --> 00:32:47.191 actually abstracting out this 00:32:47.191 --> 00:32:50.529 framework and we're going to be releasing these bits 00:32:50.540 --> 00:32:53.770 into gitfannypack, or fannypack is gonna be the name 00:32:53.770 --> 00:32:56.540 of this, this kind of framework that uses middleman 00:32:56.540 --> 00:32:59.240 and deals with stuff like testing, binding to different 00:32:59.240 --> 00:33:01.941 environments and all that stuff. 00:33:01.941 --> 00:33:04.449 And, of course, if you want to work on 00:33:04.460 --> 00:33:06.470 this stuff every day and get paid for it, 00:33:06.470 --> 00:33:12.150 you can join at team at polleverywhere. So, that's 00:33:12.160 --> 00:33:15.900 my talk. I'm Brad Gessler. I'll be posting slides, 00:33:15.900 --> 00:33:19.390 links, and, and code, up on Twitter whenever I'm 00:33:19.390 --> 00:33:22.280 not working on these slides. Thanks.