 Yes Okay guys Welcome back to Part 2 So today it's a little bit different We have a remote speaker So PJ is from Engine Yard Who is the sponsor of The last few meetups for our food So a big thank you to Engine Yard And today PJ actually woke up Really early Cause it's not on the Singapore time zone So a huge thank you to him Without further ado Let him take over So you can't really see him He's like invisible speaker But you should be able to hear him PJ, can you try speaking? Ya, can everybody hear me okay? Yes Alright cool It's all yours PJ Alright, thank you very much Winston Talking with Winston a little bit ago And we talked about What I was going to talk about And I decided I was going to talk about The rails So what I'm going to do is I'm going to go through different aspects Of both of them and talk about When it's appropriate to use them And when it's maybe better to use One instead of the other So Winston said I'm PJ I go by his clinic on Twitter And my email is PJengineer.com So it's pretty easy to remember So let's go ahead and get started So what is rails? We'll start with what rails is We'll start with IDHH To make Ruby Have a web presence The whole idea was to get Ruby on the web And the idea is That it would make developers happier Since Ruby was designed to make developers happy Getting them on the web Would make them happier and it would be more efficient For the record I think that what David did Was absolutely amazing I begrudge him absolutely nothing Because frankly without rails I wouldn't be here today It's how I got started in Ruby In the first place So rails Is an amazing thing that's come a long way Since it first came out in 2004 So that brings us to Sinatra What's Sinatra? Sinatra came around a little bit later It came around in 2007 It was originally developed by Blake Mizorati And it's currently maintained by Konstantin Haas That took the opposite approach I think it has the basics Of what you need to put an application Up on the web There's no magic, there's no unicorns It's just simple, elegant routes To put your application up on the web With a DSL Overwrap So I think very simple Very easy to use Very sparse And obviously Not quite as popular as rails Because not as many people know about it So let's take a look at how easy it is To get started in both of these things We'll start with rails Probably the appeal of rails Is that it's so easy to use To inside If you're already familiar enough with Ruby You know how to do a gem install So rails is the same thing You just grab the version of rails you want And go for it Within minutes, you have this page That I'm showing right here We've all seen this page You've never seen anything in rails You've seen this page Sometimes you get sick of seeing this page But within minutes You have this page up And you feel as though something's been accomplished You've done it So getting started in rails Seems really easy It's really simple But there's some caveats You're starting But from there you need to acquire A billion dollars before moving forward You know, failures And these pitfalls But no matter what We start to see some of these issues creeping up No matter how often you use rails Or how familiar you are with it All these little pretty rat errors Start popping up all over the place So even the best veterans in the world Can get caught So you have to pay attention But once you get over that initial startup You get to iron out some of the kinks And you can be very successful with a rails app I mean if that wasn't possible No one would use it And people are using it all over the place For some of the biggest applications Imaginable Including even our own Engine yard runs on rails So The keys here With rails it's easier to get started With database integration It's easier for managing larger scale application needs Running an enterprise little app With just a little bit of You know, a little bit of code And there's plenty of resources for getting started Part of the beauty of rails Is the amount of documentation And literature available on how to get started This is just a few like Quick URLs on getting started in rails There's Literally Thousands of books and tutorials And I like I like resources All kinds of things Just to Learn rails So this list is barely inclusive This is just some of the things that like Immediately opted into my head When I started to think about doing this talk So there are so many more resources And The question is Well, how does that really compare to Sinatra So let's take a look at Sinatra real quick So getting started in Sinatra The beginning is not so much different For the rails It's really all about the gems So again, just There's a few dependencies When you download Sinatra It downloads really quickly You install the gem, you're ready to go So I guess that's a plus for Sinatra Right off the bat It's not quite as Time consuming As getting started in rails As far as the setup As getting started In fairness, Sinatra's Are a bit more descriptive And generally they get you moving in the right direction Compared to rails Which are kind of esoteric and sometimes Misleading And they give you this huge trail Or this huge stack trace That you don't even know where you're going In Sinatra They give you a little bit more direction It's a little bit more specific And therefore it's a little bit easier To look around and figure out Exactly what it is you're looking to fix After the start Of course in the same way If you aren't careful When you're getting started You end up with errors But once those first roadblocks are overcome It gets easier to use Sinatra In the same way that getting familiar with rails Makes it easier So a lot of this is familiarity If you're used to using rails You're used to using rails If you're using Sinatra You're probably going to continually go to that So once those First roadblocks are over You start using Sinatra in the same way As he's getting familiar with rails The interesting difference is probably time Sinatra Is simpler It takes significantly less time I would even argue Sinatra is a good way to get started In order to understand routes So what's Sinatra for them? Sinatra really is for simplicity It's for building things super quickly For building things that are Family straight forward Not your super complicated Enterprise type applications When you look at an application Like Groupon Which seems simpler when you look at it In the background there's just a ton of stuff Going on that we don't even know about So Sinatra again To be fair It's going to have fewer resources There's less documentation When it comes to getting started In Sinatra when compared to rails And the reason of this is due to A lot of it's the press And in many ways Because we're the community using these things We are the press Rails simply gets more attention Because rails has been around for longer And more people talk about it Or the craziness Of things that are going on in the rails community Or the Ruby community People talk about rails And you almost always hear when people say Ruby, oh you do Ruby Ruby on rails No not necessarily There's so many other things out there There's a lot more to Ruby than rails But the two things have become Utterly linked Just 100% linked Maybe with a bit of diligence Getting Sinatra kicked off To that level where when we think of Ruby We also think of Sinatra And rails is the only thing we think about So let's take a look at What's the difference between these two things It seems that When we compare the bare basics That they're pretty much the same I mean sure Sinatra is a bit More straightforward and rails has a bit More magic to make things easier But are we still getting our Ruby stuff On the web? Is there really a need to choose That's kind of a huge question And hopefully when we look at this We'll see that there's definitely a need to choose And there's a reason why these two things Are actually quite different So the first thing we're going to look at Is the API When it comes to tapping into the power Of an API And bringing information from an API To something else Sinatra has the upper hand Because it's simple Sinatra has the flexibility To focus on the main task Which is employing the information needed So the information we have here To start off with is From the meetup.com API And what it does is This is just one single query It pushes it back in JSON You can do it in different modes But it pushes it back in JSON And what you're looking at is actually The metadata, the information For my Meetup Group The Western Europe Ruby Group And you can see Just basic simple information For those of you who don't know That it's very close to Niagara Falls We focus on Rubius We have an ID To group this We was created by Wayne Sagwin Who created RBM So you guys probably know that name Little stuff like that All this information It just kind of All comes in from this JSON format And Sinatra takes that Really simple And parses it This is code from A little internal app Yeah, that was clever Don't use my personal key For Meetup.com You might pull a bunch of information Blah, blah, blah Anyway, seriously though This is A query that I used To get all of the Ruby Meetup Groups Around the world And I'm using it to Display real simply We just wanted to see How many Meetup Groups we could pull What information could we pull from Meetup.com How many different Meetups In each of the different key focus areas Were we looking at Then how can we say How can we reach out to these people And say let's get involved with them So really quickly I put this together You have your route at the top Which is just get Ruby Do, it has type, programs type It pulls the API result Which is JSON We parsed JSON We kicked that back out to a view And does this for a bunch of different Does it for Ruby, PHP All the different Meetups that we focus on So this is all the code that's needed It's not here to pull the information For the top 200 Meetups According to Meetup.com The reason why I say top 200 Is because for some reason Meetup.com We're going to pull in the first 200 Groups For smaller Groups Like the note Meetups So we don't get a full 200 And we get every node Meetup That's on Meetup.com But like I said The previous slide was It's easy to just take this information Display it, manipulate it, whatever you need to do When it comes time to move it into a database Though, that's when things start to get Kind of railsy More often than not We're working with Sinatra And trying to inject the information into a database The first few suggestions You try to implement We'll tell you to try to implement it to record And this is where the line start to blur Maybe you should wonder if Sinatra's the right answer If you're just pulling the API Display that data Maybe making a graph out of it Simple manipulation Really easy to do When you start pulling it into a database Eyebrow will start to raise Like I said, you can literally Google Sinatra with database Or something along those lines Google that and your first five responses Are going to be Implement active record And as we all know active record Is already part of rails So it does have an API controller That can handle APIs And extract them away from the application controller So they won't interfere with the function of main application But if the only function Of the application is to pull from the API This is totally Like why do you need The top heaviness of the rails To just pull Information from the API To figure out if that's all you're doing So it's too much overhead For the whole application Rails is too much for just API grabs So what about When we start looking at the full application When it comes to building a full scale application Rails is going to be more likely About better choice Rails is large But that also means It's more robust And you can handle a lot of things That you'll need to focus on When you're building an application And you'll have things like A database And various background jobs And what you're looking at You're having more end-users You're working with more people So when we consider scale Rails is going to far outstrip Sinatra As we grow our application It's soothing we started it in Sinatra We'll see that if the number of users And end points grows To something beyond 5 or 10 The more we're implementing parts Or we'll keep up So let's assume that we started this application And we did it in Sinatra And we started it with Your brother And your friend from school And we're using it And that was all you had to worry about But then they started talking to people And eventually like 10-15 people started using it And you see that you're getting absolutely slammed Well, maybe it's time to move From Sinatra to Rails Or formation So once that starts happening Once Sinatra apps Is very difficult to manage It's time to rebuild it in Rails And maybe obviously over time The timing is crucial And knowing your application Having intimate knowledge of your application Will help you determine When this switch needs to take place Now, if you look at These two diagrams up here I know that the one on the left Diagram that I wanted for the simplicity of it Like, this is kind of A lot of times how I think of my Sinatra apps Like, super simple I have a simple model and it kicks out To a simple view And it's just a few lines of code Not a big deal, it's the behavior that I want No big role And then sometimes when I think about Some of the Rails apps I've developed It's exactly like this one on the right here Where it's literally like My god, there's parts I don't understand There's a server, there's a giant snake Eating something, I don't know exactly What that is, but whatever I need it, it's necessary Like, this is how Rails apps often look After a little bit of time So that's What you have to start looking at What's the right thing to do And even if there's a possibility That maybe your Rails isn't the right answer You need to move to something different But we'll talk about that later In the series, beyond complexity We also need to focus on performance Availability Latency and scalability Are the cornerstone Of whether or not we have customers Using our application at the end of the day Whether it's a money-making venture Or an open source gift To the community If our app has no users It is useless We have to focus on the ability Of having things ready To go for our customer And that's something that I think That especially we at engineer Try to focus on it all the time We talk about 24-7 uptime And that's what end users want They want the ability to always Be able to use an application They don't want to think about Whatever went into it They just want to make sure it's always there Performance Is also an issue that comes down To the size of application I'm going to start to see Dipsy performance Before it grows, Sinatra's Like unbelievably fast With Rails There's many ways to offer those certain Aspects of an application To lighten the world to improve performance Things like database indexing Creating ETLs Background jobs for the application Things that just make it much easier To implement in Rails Therefore You can get a boost to performance I'm not going to never see it as fast as it was in Sinatra But you can see it To a point that it only You know, it only Dips so far Things only gets so much slower And you can control that with various other things You know Tossing stuff out to utility instances Not keeping everything on the same server There's different things you can do to tweak Rails To get better performance It's never going to be as good as Sinatra But you can get it to be pretty done good So who makes? In this situation There's really no clear winner Rails and Sinatra each speak to a specific need As a developer Your job is to see The needs of the code Now and see the needs of the users over time So we look at what We certainly have And then we look at what we're going to eat Part of your job, maybe it's not your job as a developer Maybe it's your project manager's job But someone in your organization It's their specific job To see what's going on now And make sure you're serving your customers As best as possible The more familiar you are With both Rails and Sinatra The better off you're going to be To make that decision As far as what needs to be done Now, how it needs to be done moving forward So When do you use Rails? When you're looking at larger scale applications Or professional sites A lot of times I know people that use Sinatra In development only As soon as they're ready to go full scale They will convert to Sinatra after Rails It does come off as being A little bit more polished Whenever you have an Expect to see of many users And more than 10-15 endpoints You're going to want to use Rails Rails is for the big jobs It's for the heavy cleanup Or the big money making Killer app idea That you have that's going to make you a millionaire And move to Silicon Valley And move on with each When do you use Sinatra? Small projects, APIs Pet projects Little things in Ruby that you want to do That Aren't exactly huge Something that's For a small number of users That you're not going to be too concerned about If you have lots and lots of users In endpoints Sinatra is great, it's fast It gets you moved quickly Even fast in Rails You don't have to worry about things like database setup Right off the bat Or anything like that You can just go and write things in Sinatra And have something capable of running What you want it to run in 5-10 min Sinatra is great for the quick startup However, when it's time to start Thinking about production To do Rails So just for the sake of argument There are other alternatives Out there Cuba is something that I've been playing around with For a big note It's very much like Sinatra Almost just like Sinatra But a little bit more lightweight Based on routes Padrino, also very similar to Sinatra It's kind of like a step between Sinatra and Rails It's a little heavier than Sinatra It works in the same way Cramp, gin, salad, camping All great alternatives There's one that I didn't include Called Rails-Natra Which is pretty much the perfect middle ground Between Rails and Sinatra So When we talk about taking those steps I have a Sinatra application It's working great But it's time for me to move forward To do something bigger Maybe Rails-Natra can be that middle step So I mean this is all to say Rails and Sinatra aren't your only options There are plenty of full And micro frameworks out there For the average Ruby developer Most but not all of them are rack based Sinatra is rack based Most Most infrastructure and platform providers Work with rack It's been a part of the Ruby infrastructure for so long So take a look and figure out What's the right tool for your application And again, that's going to change over time But that's just another part of iterative development So Rails and Sinatra All have their purpose These all have their purpose You have to find what fits your application What fits your project and what's right for you So with that That seemed to go really fast Do you guys have any questions? We have one question Can you hear me? Never mind, I'll repeat the question So This is not related to Sinatra Rails at all But something I noticed That engineer Pushard recently Is an active record Is a data method On migration data So I was wondering If you had any idea Like Were you guys using Data method in production In a large scale fashion And You guys transition through active record And how was that? PJ, do you get it? Yeah I'm not sure if I'm the best person to answer that question Mostly Because I don't work directly with the development team But I know That we were using data method And I do know that there wasn't move To go to active method There's also a bunch Of stuff going on with our user interface And how we're using Rails So I'm not sure How to Correct the answer to that question But I know At this point in time Everything is being taken into consideration As we move towards the new version The next gen version of engineer Which I can't talk that much About Yet So ask me that question again in like 3 months Ada plans for Engineer to have Ada In the future Ya We are working With all of our infrastructure providers To A, we're working To add more infrastructure providers And B, we are working To add more centers for each of the infrastructure Providers that we work with So I know that The whole of Asia Pacific Is something that we've been trying to work And we started with Working with the AWS centers That are in Australia And that was our first jump Into the whole Asia Pacific idea So yes, we are planning on Getting more data centers Close to Singapore I know that because we actually have A bunch of guys working in the Philippines And they're pushing for all the data centers In the Philippines first So we'll see which one Which ball of wax gets caught first But yes, it's something we definitely are working on Email So that if you have questions You can email PGA privately Ya, absolutely I'm always open to questions I'm available much of the time Like I'll answer things after hours So the only thing I have to say I do work in the engineer I have to include this slide We do Ruby, PHP, Node.js, Java Platform as a service High performance, open access Best support in the world So if you have any questions We have a free trial so check it out And that's my information there So if anyone needs to take it down Before Winston gets it up Feel free to get in touch with me Thank you so much, P.J. Thank you so much for the rest of your day Ya, you too, I'll see you soon Alright, thanks, bye