 Hi everyone, so we're gonna do we're living social we Build this consumer marketing platform we You go to living social comm and it looks like it's a just a deal site and it looks small and boring But there's like actually a phenomenal amount of stuff under the waterline We have most of our apps are in the Ruby and rails, but we also have teams working in closure Scala Almost said small talk that would be a lie iOS native like native iOS native Android big data stuff Operations all sorts of stuff. So there's tons of interesting We're like big problems that we come upon And we're gonna do a few lightning talks on those technical things and then also a few on how we operate as a distributed team and how We just operate as developers. So the first That's gonna speak to you as Ed Wang. He's a he's a graduate from our hungry Academy training program where we pulled Basically just like 30 random people off the streets No, they They was not we did not press game them We they applied we put them through it was nine weeks nine nine months Six months It was some number of months. It was six months They did a really intensive training program and Are all really amazing developers And so he's a hungry Academy grad he works on our mobile consumer apps and If you meet him later ask him about his pin pal So this is it Hey guys So my name is Ed Wang and what I'm gonna talk to you today is about sharing templates in a service-oriented architecture Cool. So if you've never been to our site before if you go to living social comm This is the page that you land on and to give you some context about our architecture About two and a half three years ago. We were still a monolithic Rails app, right? So everything was inside this one gigantic Rails app Since then we've been working very hard to kind of break things out into smaller micro services So if you come to this page This is actually in an app that we call browse and browse is responsible for surfacing the browse experience to our customers So you can see some of the deals On our site if you click on let's say the audible deal You actually get taken to a page that looks like this So most of our users won't be able to tell but they actually just left the browse app And now they're in an app that we call sponsors. So sponsors is responsible for surfacing deals that are sponsored So this deal is sponsored by audible.com hence. It's free And let's say a user then decides to click on this tab up in the top the shop tab They get taken to here and this app again Is not the sponsors app anymore It's an app that we call products and products is responsible for surfacing physical goods that we sell to our customers So if we were to look back at the last three slides I just showed you and I were to ask you what is the one common thing that appears on all three slides You might say it's the navbar and you'd be correct One of the things that we've kind of discovered along the way of splitting things out into smaller services Is things that might be very simple in a monolithic Rails app can become quite complex When you move towards a service-oriented architecture So the big question that that we're going to ask ourselves today is well when it comes to sharing views How exactly do we keep ourselves dry, right? So I don't need to tell you guys that you know out of the box In a monolithic Rails app you have partials and layouts, right? So how much you show the navbar in every single page? Well, you'll throw it into a partial called navbar and then you'll just go into your application layout You'll render the navbar and then it just shows up everywhere, right? This is great for a monolithic Rails app But as soon as you move to a service-oriented architecture it starts to break down Well, why is that? The first thing is that it's a lot of copy and paste coding, right? So anytime you want to make a change you have to copy the navbar into a bunch of different places The second thing is that it requires changes in multiple places And so it kind of slows your development down anytime you want to make a tweak You have to go to five, ten, fifteen services and issue a pull request so that You know the navbar is updated in that specific application What we've noticed is that things tend to get out of sync very quickly if you take this approach So it leads to a bad kind of user experience in that the navbar starts to change as you go from page to page So this doesn't really work for us The next thing that you might think of doing is Well, what about putting everything inside an engine or a gem, right? And this is a much better solution, right? Why is it much better? Well, the first thing is that it eliminates that copy and paste coding that we were just talking about, right? So everything is kind of stored in this single central repository And then anytime you want to make a change you just update the gem and kind of release it into the wild One of the great things about putting this in an engine or a gem is that you can share more than just the markup, right? You can share translation files, you can share images, JavaScript, style sheets, etc, etc So that's great The problem with it though is that anytime you make an update you still have to go to every single app and issue a bundle update So, you know, it might work fine if you have a couple of apps As soon as you move to five, ten, fifteen apps it becomes a hassle So this is not quite good enough And at Living Social we have a saying that if services aren't solving all of your problems You're probably not using enough services So what did we do to solve our problem? Of course, we built another service And the service we built is called Stepford It was designed by a guy named Eric Brody And Stepford is responsible for sharing our views across our service-oriented architecture So when we were first building Stepford we went through kind of a DDD approach A dream-driven development approach And we asked ourselves what do we really want the interaction with a service to look like And this is kind of what we came up with So we have a client app, we wanted the client app to be able to ask Stepford and say send me the footer Stepford would then go off, do some stuff behind the scenes And then just come back and say, here's your package So let's kind of break that down to three separate steps So the first step, send me the footer We tried to come up with the simplest possible thing that we could think of And that is just a Git request to some JSON endpoint So this is what the request looks like inside the Stepford app It's a Git request to the packages controller And we just put the things that we want Different elements inside the query string So here we're requesting the footer We can also pass additional variables, things like city ID If we need that footer to be semi-personalized or modified So now you're probably asking, well what's inside a package, right? So a package is actually made up of three separate things, right? It's made up of markup, it's made up of styles, and it's made up of scripts And everything kind of revolves around the markup that you're requesting So you might imagine that if you're requesting the footer There's an associated set of styles with it An associated set of scripts with it If the styles don't come through, then your footer looks really ugly And if the scripts don't come through Then your footer probably isn't going to work the way that you want it to work So we kind of package all of the three things up Because they all have to kind of come together And we put it in this concept of a package Okay, so the next step So the next step is, Stepford gets that request And what does it do behind the scenes? So it's a little bit complicated And this is a very simplified high-level version of it But in the top left corner, we see that the get request comes into that package's endpoint Stepford then tries to make the package So it grabs the markup, it grabs the styles, it grabs the scripts It tries to pre-compile the styles, it pre-compiles the scripts It throws everything into the database And then it actually tries to render the markup on the server side So that's super interesting It takes the ERB template that is stored inside Stepford And it actually renders it into raw HTML It then sends it back via JSON So that's the last step of the three-step process But here's your package And I'm about to show you what a package response looks like So the package response contains the three things that we talked about The styles, the scripts, and the markup And here you can see that all we requested was the footer But you can imagine that in our architecture An app generally requests more than just the footer It probably requests the footer, it might request the navbar It might request button styles, etc, etc And that is kind of all going to show up in that markup as raw HTML And the nice thing is that Stepford will kind of package together all of the styles And all of the scripts for every single markup element that you've requested So everything just kind of boils down into one pre-compiled stylesheet And one pre-compiled JavaScript Cool So let's spend a little bit of time talking about the pros and cons Of spinning up a service like Stepford The obvious biggest pro is that you keep your views dry I don't need to tell you the benefit of having all of your views In a single central repository There's huge benefits, it's easy to maintain, etc, etc The second thing is that it's super easy to release changes So Stepford is all pull through Which means that any time you update a navbar or any time you update the footer You don't have to go to every single app and tell them There's a new navbar, there's a new footer The next request that it makes to Stepford Stepford is actually going to send back the latest version of whatever element there is In the database Okay, so there's obviously some cons The first con is that it's another service So one thing that we've realized by spinning up so many services at Living Social Is that any time you make a service You're trading application complexity for network complexity So that means that your tech ops team has to maintain one more application They have to make sure that it's up all the time Otherwise your styles won't come through The next thing is that because it's another service It also means that there's another network request going on So Stepford does introduce some amount of latency into your application There's another HTTP request that goes on on the server side At Living Social the way that we kind of have gotten around that Is we've put in a lot of caching So we have varnish caching around Stepford We also have memcache around it The reason is because a lot of times our main UI elements Don't change all that frequently And so it's okay to put things like varnish in front of it It's okay to put memcache in front of it And the last thing is that changes have a much larger impact So when I said it's easy to release changes Sometimes it's too easy to release changes There have been instances where we'll make a change in JavaScript And we can't quite anticipate what the effects downstream will exactly be And so as such you really need very close JavaScript monitoring To make sure that you understand when errors come through So that's it, that's my talk on Stepford If you have any questions please come find me after the talk And we'll chat Thanks, Ed So these guys get to watch me use a computer Which is great fun for my shoulder This is Tyler Tyler works also on our consumer apps team He's from Southern California His handsome looks Northern California I botched it, sorry But still handsome, but he's taken ladies And I just learned from his website that he wants to learn everything So if you see him in the hall just tell him anything And it will be the best part of his day Howdy, I'm Tyler I live in Northern California I work remote So how do you work a computer? Okay, let's start at the beginning, it's a good place to start Alright, so I'm talking about internal gem infrastructure Basically making it easy to write gems, release gems For us sharing is caring Being able to share code effectively across your apps Makes things really awesome It's easy like we said to extract things in the services Break down the monolith You can share code and you can put it into a gem really easily It reduces the copy paste mayhem We put up a little service and someone writes a little client It gets copy pasted 50 places and then we make changes It's really hard to track down who is hitting what endpoints So we've had to go back, put those things into a gem So we can share, keep things maintainable Building gems and having this code in gems Really helps build this culture of internal open source Gem gets its own repo, gets its own readme It's really easy for anyone to contribute to it People know where things are You get all the benefits of pull requests Helps with separating concerns Like we're told like, hey, you should make a mess But where do you put that mess in a Rails app? It's kind of weird Like where do I put all these little tiny objects With single responsibilities? Where do they live? How do I keep track of it? And putting the stuff in a gem is really nice It helps you draw boundaries around your code To find your domain better Isolating your code is actually really great For deleting it later You can track it down, you can find where it needs to go And get rid of it But you don't necessarily have to delete the code You don't have to go, where was that one commit That one time where I did that one thing And I got to go look through all these old commits You just go look at the repo But you've deleted all that code out of the other code bases You still have some of that history around Isolating is good too because it forces you And how does your code interact with Rails How do you interact with the database How do you do logging When you're isolated in your own little gem Do you even need Rails for this little business project That you're working on Does it need to be part of a Rails app This has really helped me try to constrain my code To the simplest form it needs to be To get the job done This helps me mock and stuff boundaries in my tests Because it's clearly defined where it needs to interact With other pieces of our architecture This has really helped me with writing good docs Because I have a readme for this thing It's really easy So a real example A few weeks ago I was tasked with automating A daily CSV report out of the database And uploading it to a third party's FTP site They then will return us a plain text email Telling us the results of processing this data A co-worker commented in 1997 Wants its architecture back So we've all done this We say hey man I'm just going to drop this in the model You know this FTP code CSV it uploads Gets the job done you know Fat models bro And a couple weeks later you're like What is this code Who put this here What does this even do A year later Two years later who did this And so you know I was saying This is really gnarly code It has a kind of a single responsibility It has this one thing it needs to do So I'll make a gem So the rest of my talk I'm just going to quickly go through Building gems Releasing gems And then hosting your own gems internally So building a gem This is another crash course Inside a crash course This might be a review for some of you This is just kind of the easy way That I see how to do it So it's another crash course So building a new gem is this easy You already have this installed You already have bundler installed You just type bundle gem Your gem name The LS on the front there That's to help us with name spacing I'll get into that in a second But bundler will do that for you This is what it creates This is your basic fresh gem It's the gem file A license which is MIT You get your read me like I said You get a rake file And then you get your lib directory With all your program code in there The most important file there Is the bottom That's the gem spec Without that you don't have a gem There's plenty of documentation on What goes in a gem spec But bundler does a good job Of doing defaults for you Name spacing If you hadn't seen this before I've done this at a couple different companies And it's really helpful You basically take your company name Shorten it down to two letters And you put it in a module And you put all your classes Under this global kind of module That's how you use it there It's LS for this one A gem in a box client And you require it If you've seen that like LS slash thing That's how it's That's how you're doing name spacing This is really helpful We have some early gems That didn't do this And I wasn't sure when I first started Is this an open source implementation Or is this internal Like where did this thing come from So maintaining this name space Is helpful in dealing with where Your code has come from And that it's an internal project So basic example This is just kind of An example that has a few more things in it We threw a changes file in there So we know what happens When the version changes And then we got some more program code And we have our own tests Like everything is nicely Tightly compacted for this little project A quick review on semantic versioning You can go to semver.org Yeah, thanks Some people don't understand it So I want to review it The last number in a version number Is the bug fix number You increment this when things change Like when you fix bugs But you haven't broken the public API You haven't changed You haven't broken anything The minor version number Is when you added a new feature Yeah, we have new stuff But you haven't removed anything You haven't broken the public API You haven't forced people into changing things And then finally The major version number Is you broke something You have changed Significant amounts of things And people beware Like this might break your code And you can think of this Like how hard it is to upgrade From Rails 2 to 3 Or from Rails 3 to 4 That's a big change So that is a major version number If it's stable It should be 1.0 If it's not stable It should not be 1.0 This is a good signifier It just says Hey, this has been used In production It's stable Everyone can use this When you go to 1.0 If it's before that You've probably seen gems That are 00, 1237 And it's like I'm not sure if I should use this That's a lot of version numbers So that's this quick refresher On building gems And versioning namespacing Now we need to let the world Behold your awesomeness Or at least the people At your company Releasing should be easy We say deploying should be easy Deploying and releasing gems Should be an easy thing This is not easy Remembering the version number And tagging it And rake build And this is not easy This is easy Rake release This is really easy When you use bundler You get this rake command for free But don't accidentally open source Your code This happens And there are bots In your Ruby gems Right away It's very hard to take that back So how do you go from this to this But keeping everything internal You can monkey patch I mean subclass bundler Gem in a box Will actually tell you On their wiki page To monkey patch bundler Don't do that So what we can do We wrote our own gem That just inherits from Bundler's gem helper There's tutorials on this But I'm just going to go through Real quick how this works In your rake file You see these bundler gem tasks At the top What that actually does Is that gives you those three default rake tasks The build, the install, and the release By default it's going to push it To Ruby gems And we don't want that So when we subclass it What we want to do Is we want to say We use gem in a box As our gem server Living social We want to say Hey, don't push to Ruby gems Push to gem in a box So we subclass bundler And said hey Don't push to Ruby gems If you try to If you even try to call The private The protected method there You're going to get an error So just don't do it And then once we release that gem It's just a really small gem We put ls gem tasks In place of bundler gem tasks In all of our other gems So by default this goes to our gem server When you release It's really easy So gem servers You know how to build one You know how to get it out there Now you need some place to put it There's three options There's gem in a box Stickler and then gem fury So if you're hosting your own It should be behind the firewall It's internal code You don't want anyone else accessing it Gem in a box provides a nice web interface For managing your code It has authentication You have to build your own rack middleware To do the authentication It does pull through mirroring Which is kind of cool You can tell it to mirror everything From Ruby gems as you install things So you don't need to depend On Ruby gems being up When you deploy Gem in a box will pull down Everything for you And it has a nice command line client It's pretty simple It patches gem with this in a box Command and allows you to push And set up your own machine To talk to your server The other option For open source thing Gem servers is stickler It provides authentication In the same kind of way It does selective mirroring So you can tell it You know mirror active record 3.2 And it will pull it from Ruby gems You can also give it A whole gem file lock It will take everything in there And it will mirror all of it For you Which is handy It has a really full featured Command line client You can do everything That you can do from their web interface And then it's The author wanted me to note That it's going to support The bundler dependency api In the next release It's coming soon For a hosted server That's not behind this Firewalls on someone else's machine There's only one option I know about It's gemfury.com They provide authentication obviously Because it's not on your machine They don't appear to do mirroring Which is You know if you're still relying On someone else's service You're going to probably be relying On Ruby gems too So they don't do mirroring They have command line client And then they do support No jails and python packages So that's it My name is Tyler Montgomery And Uber Majestic on Twitter Thank you Tyler Next up we have Dan Mayer He's also on our consumer app team Not everyone is on the consumer app team He does a lot of teaching In the DC area teaching people Ruby And I just learned That he can fix bugs from ski lifts Over the phone So that is a useful parlor trick Take it away Dan Alright Hello I'm going to be talking to you About production code analysis Obviously as you build up All these services And split out all your code It gets much harder to debug And start finding out things About your code Like a small application Is easy to reason about In your head But as your systems grow And your architecture grows It gets more difficult Could somebody fix the projector And get us all on Is that one on Or is that off as well If somebody could fix that one too That would be great You can't improve if you can't measure You can't improve what you don't know We often focus on performance And exception monitoring Some fixate on test code coverage There's a lot to learn From what your code actually does In production Ruby tools aren't quite as good As like the Java tools So we really are still trying As a community to improve those tools So that's some things we're working on internally And then I want to mention Etsy They have some great posts All about measuring production systems Graphing everything And actually release stats D Which we rely on quite heavily So I wanted to just say Thanks for that Alright, so I like to focus As we split things out And kind of forked off code bases On getting rid of unnecessary code Because I want to be able to only think About and reason about the code That we actually care about And what's actually being used In a system That code ends up in production For a whole lot of reasons I've blissed up a whole bunch there But we don't really need to go through everyone If you've ever worked on a team And as it grows You eventually find code That you're like This was written three years ago And nobody's using it Why is it here? I think it's important to try To track that down And get rid of it as soon as possible Especially as you're adding a lot of code Very quickly to systems So there's various ways to find dead code Some as simple as just using New Relic Or formerly Trace Linux You can do custom stats and instrumentation Which I'm going to talk about a little bit There's production code coverage There's a gem I've been working on That does code coverage But not on your test suite It's actually live code running in your system And after seeing some of the talks By Tilda I also realized I can make it much more Performance in Ruby 211 So I'll be working on doing that Because right now there's a high cost Which I'll talk about a little later You can use logs You should definitely have your logs All searchable And we'll go into that Using stats and instrumentation And production code coverage We've deleted 20 plus thousand lines Of app code And then hundreds of thousands Of lines of code If you start including our assets Or our JavaScript Test files And that sort of thing We've really been able to shrink down Our code bases as we expand out So third party real quick If you use New Relic You can go to the transactions Go look at the last seven days Sort by count The things at the bottom Likely are dead Deprecated Or you can start working on killing them They have like one request In the last seven days You might want to go look at what those are It's really easy It's so useful If you're ever finding an endpoint And you wonder Wait a minute What is this Go check It might not be hit In the last seven days You can probably kill it It's really easy It's actually even easier Because we have a gem New route Like route check Which basically you can download The CSV from New Relic This generates your Rails route file And then compares your routes Versus the output of New Relic And then starts telling you This was in your routes file But never actually hit You can go look at those endpoints Stats instrumentation We're going to step through All of these fairly quickly But basically There's a lot of different things You can do with stats To help you find code And tell what's going on In your systems So background events You want to know Which jobs are being executed You want to know If they're completing successfully You might want to know How long they take This is an example for rescue We actually have our own wrapper Around most of our background jobs So we do it at a different layer Stats D Before perform After perform You can throw in Whatever else you want there If you want timers Anything But it's really easy to instrument that Then you have your nice graphite graphs Where you can kind of follow And see the charts on everything You can also look at graphite And see if a job's no longer Ever being performed Emails Email templates Especially transaction emails Eventually you have a one-off Transactional email For some holiday thing Some special product Something that's no longer being triggered You can check all your emails No reason to work on updating them Or fixing them Especially when you're doing Say a Rails update And you have to change All your action mailer code This will let you know If it's worth your time Views rendered Eventually your view layer Will get very complicated With layers and layers of partials If you have layers and layers Of partials It's hard to reason about Which ones are still in use Which ones have been refactored Away entirely You can actually really quickly Using active support notifications Find all your layouts And all your partials And templates And track them This is an example Showing it to stats D Or you can just render it Into your Rails logger And then you can search it In something like Splunk Elastic Search See if it exists Again, we made a gem For this to make it easier You can see flat foot Basically you set up flat foot It does this for you And then it gives you Some helpers to find Used views, unused views You can reset it on each deploy It makes it really easy To kind of automate this process And generate reports on it One-off trackers Sometimes you just Find some coding You're not quite sure What's going on It's very easy with stats D To just throw on one-off trackers This is an example Of a controller We're trying to figure out Which of the types Or paths in the controller Are still being hit You can go ahead And throw increment On each of the formats On that request.xhr Now you're going to be able to say Oh, actually we stopped using The json format months ago Let's get rid of all the related code Production performance comparisons This one I owe thanks to Uber Majestic over here, Tyler He actually just threw this out And didn't really make Any fanfare of it On one of our applications Then I saw this And I was like That's really cool We had two different options For stripping out some HTML And we wanted to know What's faster You could benchmark it locally On some fake data But the production data Is very different Than what you're going to test with And it will vary a whole lot Over all our applications He threw this in there Splits at 50% Throws the timer around it Measures both one implementation Of the algorithm Versus the other A couple days later It's incredibly obvious That Nokogiri is much faster Than just using the regular Strip tags from Rails And that I just thought Was so interesting That I've kind of been carrying around To point out to everybody I can find that's interested Translation usage This one I owe Chris Morris Some credit He's another engineer At Living Social He works a lot On our payment systems But he used to do a lot Of our translation And internationalization work And eventually Your translation files Get really large And they actually take up A lot of memory In your running Ruby processes So if you're trying To get more memory So you can fit More workers on a box You might want to look At your translation files They tend to be A pain point For a lot of companies That have a lot of languages This lets us track Which keys are actually being used What are we still translating In production Or what is it we no longer Using the translation for As you delete all these views It's easy to forget About all the translations That were in the views This actually makes it very Simple to go and find those Production code coverage This is a little bit More experimental at the moment We do run it on production I have it on a lot of systems I cannot use coverage Which is what Like simple coven things Use in your test suite Because there's a bug in Ruby If you sample And turn it on and off It will crash Which luckily I learned prior to production So I switched to Using settracefunk And this lets us see Each line As it's being run live And then we do sampling To cover the fact That settracefunk Is extremely slow Sometimes four hundred Eight hundred percent slower So we can sample A very small rate of request But it still will Over a whole lot of volume Give you a pretty good idea Of what's used in production And like I said In 2.1.1 I just learned That you can actually get The CPU profiler Is a sampling profiler And you can get the line Number data out of it With a very small C extension So I'll probably be updating This and that will only Help 2.1.1 It'll still have to use Settracefunk on 1.93 and 2.0.0 But you can get some really Interesting data And delete a lot of code This way Here's a quick example Of the setup But really go to the Gems homepage You can see You can do ignores On things It'll check your app path It tracks in Redis I use a startup delay Because Rails Is very slow On the first few requests Because it actually Builds a lot of Code in memory At that time And you really don't want To be Checking your code coverage As it's building New methods It's just Not a good use of CPU Yeah And this shows How to set it up In your rake file And Real quick I was going to Have a demo I think I missed the slide We've got other speakers So I'm going to Skip ahead real quick On logs I just want to mention Make sure to get All your logs From all your applications In one place Elasticsearch Splunk Kibana Doesn't really matter You just want To see How requests are going Across your system I've been working on A gem Called imprint But also You can look at Zipkin Which is I guess some of Like Twitter's work Mostly they do Scala But I guess I have stuff for Ruby As well I just learned About that At this conference But basically If you put A trace ID On your request You can see As they're coming In your system And then As you make Multiple API So any event That fails You can track it To the incoming request If you have an exception It's going to be In the headers It'll be on your exception You can actually Take the exception And go see all the logs For all the Request and debug What was coming in That was so awkward To cause this exception And I think All these tools Can help you Clean up your code And actually Understand what's Happening in production Much better And that's all I've got Thanks Dan Are you going next Towards Okay Oh I don't know I'm telling Rodrigo to sit down Nick Nick is going to go next Nick is A Minnesotan He's on our mail tools team A JRU contributor And if you're wondering He's six foot four inches tall And can help you get things Off of tall shelves And he's going to talk to us A little about meditation So I'm French Which is French for I think Therefore I am And I'm very impressed By the famous Philosopher René Descartes I'd like to Ponder today A little bit About whether that's Really an appropriate Frame of mind You can interpret That statement To mean that We identify ourselves Our entire existence By the fact That we can think And I Personally think That's a really Bad idea Early in my Career I was obsessed With my capacity Of work done I wanted to work All the time And I was constantly Searching for That sort of state Of that elusive State of flow But in fact What I think I really got stuck in Most often was An off more Common state Of yak shave So When you think of yourself During the work day You know How often do you Find yourself Getting distracted Running down a rat hole And then once you Get done With that whole That whole rat hole Once you finally Unwind the stat And get all the way Out of that rat hole How many times You find yourself saying Wow, that felt great It's like no It probably did not And I'm arguing That one of the reasons Why it doesn't feel great Is because We all too often Let our minds run wild We take every thought That comes into our head And we believe It's the truth Or we believe There's some element Of truth to it We might even Have perceptions About ourselves And the way We perceive ourselves And we think that For some reason Those are true And I'm here to tell you That they're not I think that We have All of us inside of us We have a sort of A silent watcher Observer of our lives That's behind all the Thoughts And if we can All take a little Bit of time In our day To access that Part of ourselves We find that We're going to be Happier And that's Kind of A little bit of What I want to outline today So As far as meditation goes In terms of a discussion For today I'm going to say that Meditation is sort of Spending some quiet time Attempting to find Sort of an absence Of thought in your head And if you've ever Tried meditation You know This is actually Extremely hard People have been Meditating for Thousands of Thousands of years And it is most Certainly a life long Practice And when you realize Oh my gosh How am I going to Will I ever Get to a state Where I feel comfortable With this Is this something That's really worthwhile To do And I would Advise up front That meditation Like many other Things in our lives That we find worthwhile To do All it requires Is just a little Bit of time And making it A habit To get the Most out of it So don't make Don't listen To the voices In your head Again Don't listen So therefore I'm not going to try Just ignore all those And just try To do it There are a number Of studies out there Meditation does have Actual tangible Scientific health Benefits There is one study That had people Meditate for 30 Minutes a day For eight weeks And they did Brain scans On the people Before and after And found that They're a great Matter In brain regions Associated with memory And stress And empathy Actually increased You know We're long past Puberty Even as adult You can spend time And change The composition of your mind And the composition Of your body Another study At UC Davis Found that Folksy on the present Doing activities Like meditation Rather than letting The mind run away Or drift Actually lowered Levels of the stress Hormone cortisol On your body So meditation Also will allow you To get on top Of your Hormones And get a better Hormonal balance You'll feel a lot Better about yourself So unfortunately A lightning Talk is probably A bad place To actually Try to Try to lead A meditation session Since I think To do it justice You'd want to Probably have at least A five minute Quiet time to yourself But instead What I'm going to do Is take it Just a few moments And actually Ask all of you To You don't have to Do this yet But what I'm Going to do And try to clear Clear your mind Of any thoughts And then What I'm going to ask You to do Is to just Spend some time Trying to attain That clear head And watch your mind For the very next Thought that comes out And watch your mind Like a cat Would watch a mousehole So I'm going to Ask you all now To close your eyes And watch your mind And just try to Watch for the very Next thought That comes in And just try to Be focused And attentive And just be focused And attentive And try to look For that very Next thought And I'll just Give you a few moments And when that thought Comes in, go ahead And open your eyes Okay, some of you Actually lasted Quite a while there That's pretty good So what you might be Finding with this Little exercise Is that When you take The time to be Really attentive About having A clear mind It actually takes A little while longer For that Thought to come in So this is In fact You're actually trying to Rather than being Completely Completely lifeless Or almost like Well, you're actually Trying to be Very, very attentive To the immediate Present moment So when you're doing this It's important to not Be self-critical, right? So maybe A thought rushed in Right away again And you feel like Oh, gosh, I have No control of it Well, don't try to Control what's happening Don't try to be On top of it No, it freaks a lot We're in technology We like things to work We like to control computers Don't try to be And control the situation Just observe Where your thoughts Are jumping to And just Try to be That passive observer Of what's happening In your mind And then So once you start To get in this habit Of taking time To at least check in Yourself Maybe you start A meditation practice Or maybe you Just want to Take moments out of Your day To just take a break A little more self-aware Ask yourself throughout the day Am I at ease at this moment? Ask yourself How do I feel at this moment? Am I at ease? Or what's going on inside me? And just pay attention to Those feelings and those What's going on inside you Without judging Or trying to Make any changes about it We're just trying to cultivate Self-awareness here I also find that Doing meditation Has led me to doing Other things Really mindfully as well I like to cook I like to clean I like to do all these little Kind of tasks That don't require a huge amount Of mental energy And I like just focusing on them Intently And I find that even doing Things like chopping vegetables Or doing dishes Or any tasks which you think Normally would be completely You know What a waste of time I don't want to do this right now I really don't want to Do these chores You can actually find a little bit Of pleasure in just focusing Completely on the task And that's another way to just Kind of open yourself up And be more at ease And you know Of course We all have screens on us At all times of the day These days And that's another area Where it's like Looking at a screen You're putting your attention Out into either Somewhere else From where you are right now So when you're with someone Even when you're by yourself Maybe every now and then Put the screen down And just focus on Just what you're doing And I think For me My opinion of This lifelong process Of trying to be more mindful Trying to meditate Trying to make ourselves Better through meditation Is actually a contagious thing And one that we can contribute To the well-being Of the entire planet So I hope you will consider You know Reducing the crazy noise In your mind And maybe check out What meditation can do for you And kind of follow up On some of those studies I mentioned I will have I'll tweet a link later on I was planning on posting it Before this talk But I forgot to do it I have to get back to my computer But I will I will tweet a link later My Twitter handle is Nickseeger N-I-C-K-S-I-E-G-E-R And I'll tweet a link later With some of the articles And links to things That I look I refer to During the course of my talk So meditate Be happy Make the world better Thanks Now's your time, Rodrigo So Rodrigo is A developer on our merchant team And He's an avid gamer Both board and video, right? Yes And you're from Brazil, right? Yes Definitely south of the equator Yes And if you see him in the mall Ask him about his goats Yeah You're gonna They're gonna see them Alright Take it away Thank you You're stronger So Hello, everyone My name is Rodrigo And I'm here to give you One trick To boost your productivity When working for home My Twitter handle is Kaffo Even my wife calls me that So You can call me that too Or Rodrigo Whatever you want I wrote an article for Our tech blog About how I do work from home And How I try to focus on things While doing that And The most important thing That people talk about Was the pet goats That they were in the article Like briefly I'm gonna show you some Here's me with my pet goat In a hangout for work If you want to read the article It's available here It's a tiny link And I have been working remotely From home For about ten years So I had to find my way To focus on stuff Otherwise I would just play Video games all the time And That's why we have this Unrelated cat picture And This article name is One weird trick Because I was browsing the internet To vault ad block I saw a lot of these ads Like One tip for a flat belly And like Gigi said There's no way We can have a quick Flat belly So What would be this one trick That we can get To have focus And I think it's boundaries Like I had a couple of things I do That limit my work day And my personal day Because at home They are very together And I'm just gonna briefly show you Some of these things Like Every day I start my day With a start up ritual I get presentable Because we do hangouts And I need to be properly Dressed Not Undressed Whatever And then I do what I call I open the cafeteria I get like Some fizzy water done I put coffee in the air I press I grind the beans And then I have a very good Cup of coffee The other thing that I think It's important After all of that done I get my cup of coffee I sit down I start working And I think you You really need to Eliminate distractions You need to find a way To be In your mind office While In your home And what I found was very good For me Was having a good pair Of headphones The headphones are nice Because they allow you to Focus on stuff And Like people around you Like my wife knows When I'm with the Headphones She can talk to me The dog Don't care about A lot about it And the path goes Just gets sad Because He can't get my attention And I also have All sorts of gizmos Like I plug the headphones There So I can have even more Like Better sound And that way My wife just like Needs to throw stuff at me Like Wake up Get out of here And do something And I call that My focus flag It's like a way I can show to the world And to myself That It's time to work I'm not here I may be here In my body But my mind is doing Other things For my company So Okay You got there You had your Startup ritual You got your computer Your headset Goats away So You can really Start working And then You're done You do a lot Of multitasking And you can do that Like Why we spend all the time In hacker news on reddit Because It's way more fun Than do work Like You have That usually Is a thing to do But you want to be on reddit So you need to Cut down Multistasking You need to find ways To not Change what You are doing So if you're coding You're coding You don't have like If Gmail is low You should not open A new browser tab But before A second Your day is gone So What I've done For example I had these These Tiny Arduino Plugging into my computer So If someone sent me An IM message And they are in a white list I would get a light That says You need to answer them Because it's your boss Or someone from your team If it's not Like You can answer Whatever you have time So You need to find ways To not Multitask Another important thing Is Don't work all the time When I started working Remotely I said like Yeah I need to make sure I don't play video games All the time And I started working All the time And I would never stop So You need to find a good balance Between one thing And the other You should also Spend time With others Like Don't spend all the time At a computer Like Just working mindless Like Find time To spend time With other people And also Find time To challenge yourself In the cold wars Do some Khan Academy stuff Like You need to have A good balance in your life To make sure Your work Works well And everything goes fine Yeah That's it Thank you so much