 So Dylan is going to talk to us about Dave and Goliath and giving Ruby into the Enterprise. I don't think it's the Enterprise from the Star Trek stuff, I think it's the other Enterprise. And he just flew in a mountain in Colorado somewhere. So give Dylan a big round of applause. This presentation, well they exist and there's some good things and bad things and bad things. A lot of differences between the small startups and the big monsters. This presentation, I haven't even done it before and I don't know how long it's going to be. It could probably be five minutes or it could be seven, maybe seven plus. I tried that really quick in the back, but totally didn't work. It's not going to be very pretty either. I think all the people performing are closet designers or something. I have fancy pictures and stuff. I'm Dylan Stomins. I work for a company called ELC Technologies. What was that actually? See? Was it? See? We're for a company called ELC Technologies. We're a Ruby Rails consulting company out of Portland, Oregon at the moment. We've got offices in lots of different places. We also do global development as well. We work with a lot of small startup-type companies and we also work with giant behemoth-type companies. This is about the giant behemoth-type companies. It was going to be a little more technical in nature, but then I thought I'm going to switch it up and make it a little more generic about how to work yourself into these large companies. I think that Ruby has a language, a fantastic language, and I'd like to see more of it in the space. Some different companies talk here. New Zealand. Any New Zealanders here? I lived there for a few years. Enterprise, the term is kind of a bizarre term. I know a lot of people are cringing out there. When I say enterprise, I've just made a giant model of the companies that have existed for a long time. Fortune 500s that have really, really old technology stacks. Technology departments scattered across the world using basically everything under the sun. We all wish it could be just a simple, nice rail installation where you throw a database in the back and then you might get a little bit more complicated. That's not really the real world when it comes into these giant installations. But you can get pretty far. I think GitHub is a perfect example of something that probably started semi-small, but now they're pretty darn big in there. They have lots of awesome technology in the mix. Ruby is kind of cool because it can do stuff like that. Required Java. How about any J Ruby in the diary? Yeah. Alright. There's some fantastic things like that in life that are easier. When I say enterprise, I'm talking about, let's say these are distributed software teams and then you've got data centers across. These are all physical locations and then corporate offices. Then you've got this mess of technology that's not totally out of... I mean, yeah, I just place camels and place it up on camels. But it's not out of the ordinary. This is a slew of different technologies and getting them to integrate, getting them all working together and everybody on the same page in regards to what's actually happening, what's running, getting people on the same page. That's hard to do when you've got something like this. So what does this have to do with Ruby? Not much actually. Sorry, everybody. It has to do with Ruby because that's the language that I really, really enjoy programming. I think there's a lot of reasons that Python is great as well, but I prefer Ruby and there's some things you can do with Ruby that you can do a lot of languages. So enterprises still need to iterate quickly. And Ruby and Rails, especially, came out and made that possible by blowing the kittens out of nowhere. You can do that. And in large brownfield applications that exist out there, that's one of the responsibilities that need to happen, benchmarking, profiling, regression testing, analytics, when you do releases across different continents. And so those get added to the mix, so you're not just developing stuff or releasing it, you have to do all this other stuff in order to get your deployments out there. And a lot of these companies are not doing continuous deployments or continuous integration. So any time they do a release, it's like next year we're going to do a release and it's going to be amazing and it's probably going to be a month of not sleeping. But these companies, they still need to innovate. So a lot of large enterprise companies, we hope that they have small internal teams that are playing with new technology because if you don't innovate, you die. And there's lots of companies that we run into that don't really even think that way and they think, hey, we've got more going, our stuff's written in FORTRAN, it's awesome, and it's going to live forever. But there's obviously the job market factors are in play that are sort of the numbers that happen. And they need to integrate. So the map with all the different technologies all over the place, they still need to talk to each other. And so Ruby is one of these languages that has amazing bindings with other languages. So Landscape, you know, Ruby 93, this is stuff for you guys to follow already, but Ruby as a language, I came to it from Java. I was really excited about it. I'm sure that a lot of you have come from different languages as well and are here because you really like languages like Ruby. And having a talk on enumerable, how awesome is that? I mean, I've never been to a Java conference where they have an iterator talk. Did you imagine how cool that would be? Super. So this is something that's pretty unique with the Ruby community. You have just simple features of the language that are just so beautiful that we all want to present and talk about and have user groups about it. We're diving into the code and making things better. So this is kind of just a metric of where Ruby's at in terms of the rankings, I mean, from 2006 to 2011, Ruby's made quite a change there. The only one that compares is Objective C, next to Apple. And that's kind of the more metrics we have like this, the more you're able to kind of make the case for yourself at large companies. And I don't know if you've ever worked in some of the other stuff, like JSP or other frameworks like Struts or Springer. I mean, it's not the most fun thing to do. I mean, it's painful. And I think that's what Rails came out. And everybody's like, oh, this is really nice. I just did a Hubot command. And it's like a web application. So I mean, I think a lot of people jumped onto Rails, too, because it gave us lots of nice constraints. It gave us an active record, super strict MVC framework. And so it was kind of hard to mess up when you were building Rails applications. And so there's big companies using Ruby for lots of different reasons. And what you'll find is you'll find that there's these little kind of innovators within these large companies that need to do, whether it be an internal tool or a larger project, that they will find out about Ruby, they'll find out about Rails, they'll hear it being spoken around the tech scene, and they'll hire a group of people to come in and do Ruby and do Rails work. And when you are in that situation and you're able to get into the system, I mean, that's the first step. And that's kind of an important step, because you're not going to come from the top and be like, hey, Ruby, Rails, change your whole infrastructure. You need to find a small way and then grow from there. And you need to approach that delicately. So also there's a good case of, you know, you can hit J-Ruby, I-M-Ruby, you can ray it. I mean, these are all awesome virtual machines that people are writing a Ruby like syntax on top of. I think that is kind of a testament to how nice Ruby is. I mean, everybody likes programming it. The language itself is nice. And in the landscape, there's lots of stuff happening in Ruby. You know, Amazon just announced the official SDK for AWS service. So, but perception, so perception of Ruby, I think, is kind of a hard nut to crack because you still get, I think when Rails came in, you still get the kind of like, you get this, you get like the people working in the garage. Ruby is great for small little toys. And I actually had somebody from a large company say, hey, Rails, Ruby, it's great what you guys are doing. You know, our Java team are really proud of you guys. It's fantastic, keep it up. But it's like, no, this is actually real language. We're doing things. But he said it was like two guys in a garage. It's like it's great for things that you can do in a garage. It's serious. And I think, you know, from the Rails perspective, a lot of people when Rails came out were really excited about Rails because it was just so easy. And so you had a lot of like the fanboy type attitude. And that's the passion. That's fantastic. But at the same time when you're going to these large companies that you need to be able to get kind of factual with their technology departments. So one of the percentages is that slow. It kind of is slow. It's not the fastest language in the world. But that's not always that dangerous trade-offs. It's immature. It's not really immature. It's not around for, you know, since 1993 I believe. So that's the case that you can make against it. And it's dangerous. It's not a statically typed. So it's scary. You can do all kinds of crazy things. And that's totally true. It's super, super dangerous. You can do some crazy stuff for it. It's super, it's super scary. But that's a good thing. That's a good thing. That's what testing is for. That's what, you know, it's like giving a nice to kids, right? I mean, we all give a nice to kids. And you have to learn, you have to teach the kid how to use the knife. So people across this, this is kind of a, I think a lot of, you know, what in the last talk we were talking about, communication, that's a paramount to almost anything. There it is. That's a lot of what, what spawns failures in these large companies. So like, we're humans and that's how we communicate. That's how we do things is if we're not communicating, we're not getting anything done. So, you know, you come into situations where it's, you've got, you know, somebody saying something, this happens in hierarchical structures where there's levels of management. You say something and then it gets transqueued into something else and then they start talking about this and they start talking about that and it's like, just the message you just changed. It's like, how did that even happen? You try to make these cases in... Anybody use Dukely out here? Play with it? It's the Duke and Ruby, Nutter, Charles and I's application. But you can see how stuff like this totally gets construed and it's happened where we've been in companies and it's verbally the chain of command. As stuff grows up, it gets more complicated and it can just get totally outrageous. So I think that is... That's an important thing to think about because even when it's, even when you've got this formal hierarchy that these people have been using for such a long time, you can see consistent failures in the process. So this is kind of the... I don't know if you've all heard about the two pizza teams. The Amazon hasn't been... I think they've joined. It was Jeff Bezos. He said that if you can't beat a team with two pizzas, it's too large. So you keep small teams and that way you can communicate. Because a lot of companies now are virtual and not in the same place. And this is really important thing because a lot comes out of this, keeping your teams small. The one concern is scalability and I'll talk about that. But it keeps teams targeted. You've got low costs. You've got high innovation. And then everyone on the team knows what everybody else is doing. And goals. And also accountability. So when you're on a small team, you know everybody on the small team. And you don't want to let the other people down. If you've got a 50-person team, there could be some guy just sitting there just drinking coffee all day and you wouldn't even know he was drinking coffee all day and doing nothing. So that's what management is for. So it's easier to manage in terms of commits, code poly, getting actual work done. And then it's non-higher ground. It's basically flat. Everybody's on the same page. Everybody's driven to do something good. And Greg Winden of Amazon, he's the guy who built the recommendation engine. He had kind of a... He wasn't totally sold in this. He liked the fact that it's an informal network, that it's flat. Because you actually run some scalability issues at bigger levels with this pizza team approach. But there's a couple of case studies that are working in larger organizations. And this is one of the most important things is keeping communication going. So we're talking with a client who refused to set up a chat room with all the developers. And there was some DDAs. There was all kinds of QA teams involved. Email, that's the worst form of communication ever. It's like postal letters to people. Carrier pigeons. You send an email to somebody because you need something and then all of a sudden you get it at the very end of the day and it's not really the way it worked. You only get things done to be a blogger. So obviously setting something up like having campfire set up, chat, or voice it in person, that kind of happens less because everybody's lazy and this one actually, a phone or push the button with a Skype or a blog. So that doesn't always happen well. This slide is not a crusade. That is a crusade. I'll take it back. It's a crusade because it's a crusade in one respect. In the respect that you need to you need that you're passionate about something and you have the facts there and you want to bring that up to and make more people aware. You want that to happen and you want it to be consistent. But it's not a crusade in respect to the being a war. This is a diplomatic thing and as you, as you, you want people to be on your side. And you don't want to burn any bridges. So these next slides are kind of an interesting way to evaluate kind of large system personnel hierarchy. And that's crazy. That's complicated and slight. So here we have a hierarchy of different levels of management that you might have a detective organization or just an organization general. And this is kind of a method and it's kind of mad to go and kind of do a little evaluation on where you're at, where you're, what you're trying to bring to the table and how well you're doing it. So you've got, you know, approvers, decision makers, evaluators and users of whatever endeavor you're doing. And you're able to basically you know who these people are. So it's easy to map out. And then you kind of have the people who are adaptability to change. So if we're bringing Ruby to the system, there might be some people that don't want that to happen. Like the laggards, they just don't want any change. They just want you to go away. And then you have, you know, people with different types of, you know, the conservatives, the innovators, the visionaries. Usually you find the innovators and the visionary people who are your sponsors, the stewards to what ideas they're, the ones that are going to trust you and really drive you forward. So you can see you're kind of building out this, this little diagram here. And then you have just kind of who you're talking to there. You know, you might be talking to some of the people quite often. And you might be talking to some of the people that already know what you're doing. And they already believe in what you're doing. And so those aren't necessarily the people you want to spend the most time with, because they're already on your set. They already know what you're doing. This sounds all crazy, but it actually helps when you're in these really, really kind of high-level situations and you really need to kind of, you need to get things done and you need it to happen or you need to move slowly because it's not a fastest process. And then you have kind of your status. So there might be people that just don't like Ruby or don't like dynamic languages. And so they're going to be people you're going to have to work on, people you have to spend more time on, people you don't have to talk to. And then you have like a political structure of an organization. So you've got, you know, these two people are kind of the inner circle. They make a lot of decisions. And then you have the general, who advises them. Just a weird exercise to go through if you over find yourself in a situation like this on a large team or coming in to a large organization where you're trying to make change. So just some examples of failures in these types of situations. You know, one is, this is a quote I read recently not necessarily fixing problems and navigating contradictions. So we want to, as Rubyists, we want to build stuff because that's what's fun. That's what we like to do. And we don't want to get into a position where we're just sitting there in meetings all day and trying to convince people of certain things and reasons why they do things. We want to keep building. So we try to, that's a failure in itself right there. Some examples. We're working on a, with a company who had about 50 person team with QA with other people and a few different technologies in the mix. And we had the problem that we were constrained or in development environment to some machines that did HIPAA compliant stuff so we could run it locally. Which is a problem. So in our internal development environment we actually relied on these servers that were remote. One guy had a key to these servers and he went on paternity leave and when they went down one morning it was not available. So there was really two days of full development where nobody could work. 50 people not working for two years. That's just a big fail right there. If it was a smaller team it would have been a lot easier to get things done. If people had access to things it would have been a lot easier to get things done. And this also can happen. I mean it's great to have everybody be able to do things but not everybody on the larger team they're competent. So we've had production systems just go down completely because people are, I think they're in their local console but they're actually remote from production. And then another thing you can get rid of do with coming into organizations is just internal influence. You might not be sitting next to these people who are the product owners on the company's end and they might have people there that are they don't like Ruby and so they're going to sit there and whisper in the ear that anything that you do to try to convince them that this is a good thing there's always going to be someone there saying that's not a good thing. Sometimes being on site helps. Success stories I've had some serious stories one that we had was a company that had 120 machines doing God knows what. It was a Java application and we came in and we looked at the scenario and said okay hey we think we can break this down and rewrite the whole thing in Ruby it's rails and we're going to consolidate all the projects into a smaller amount so there's about 30k months spent just on machines and 5 developers were maintaining this so they had 5 job developers maintaining the system 8 different projects so we started looking at the code base and it was there was no reason for any of any of that to happen code was bad there's no reason for any of the 8 projects no reason for the 120 machines so we were able to refactor this Java project and we break it down to it ran about 40 application processes we refactored it into one project and there only needed one developer internally that they needed to maintain and this is ideal if you can come into a large organization and you have the opportunity to rewrite everything I mean that's like who wouldn't want to do that but that never happens like this was like a random example that didn't actually happen we were able to break it down to about 5k per month server spend and just one developer site but in most cases that's not going to happen and you're going to be Fets of Pyramid you're going to be at the end of the pyramid with a little kick and shovel and you're going to be trying to get into the middle of the pyramid where you're able to make influence and say hey we're going to change technology we're going to use this technology we're going to move forward with this different parts of the system and it's a long process it's a long process to get from the outside to the middle unless you can find the little grand gallery that doesn't happen that often so what can we do as Rubyists to actually get in there and make change and get this language more adopted in these huge companies one is knowing you can use it so Ruby is great for a lot of things but there's a lot of things it's not really good for and so being able to go in confidently and assess whatever situations that technology problems that people have and come up with good solutions so we have the opportunity to have some projects within some large companies and it was the fact that Ruby wasn't actually the best idea so we passed it along because we didn't want to come in and that would be that would be worse if we went in and implemented something that wasn't the right fit so it's kind of knowing the right tool for the right job and the second one that doesn't I think it should happen more is just the documentation of success there's a lot of case studies out there about Ruby and about its applications but I think there needs to be more I think companies like Engiard they do great white papers they're very active in getting PR out there and I think there's more that us as consultants, us as companies can go and document the before and after of products that we work on that's kind of paramount and this is just another horrible slide I need some designs it starts with education so when we're at school, we're in college we're learning like Pascal great like that and that doesn't really that doesn't really get people excited about programming I almost quit because I was learning Pascal as my first course and I thought this is programming this is horrible so you want to have fun doing it and so when you have fun doing it you start making money and you start making money by working out of business and that feeds back into the education so as we start as large companies start adopting Ruby it gets more and more commonplace we're going to see Ruby become put into the education more and more so it's this kind of cyclic thing and you've got MIT teaching Python as one of those first courses and that's fantastic to see it doesn't happen enough within universities so if we can keep this cycle going that's a really really really important thing for us kind of programming languages along removing technology along and making our lives better because we all want to do fun things and we want to like what we do that's it that was I don't know I was the question please this question was that the framework for evaluating hierarchical structures with organizations is that something that I just made up no I learned that I was taught that from somebody and if you have the time to do that and you have the resources to do that I highly recommend it I'm sure the slides will be available so I think it's a standard in some field cool thanks guys