 So, I'm Adam Kelsey, even with the feedback, okay, that's better, because I'm usually loud enough I don't actually need a microphone, so when I talk into a microphone it does all kinds of fun stuff. I'm from Tropo, the company that has been doing the text messaging stuff. We built that 20 minutes yesterday sitting here at a table, because Jim needed it and so we thought we'd do it. And what I'm going to talk today about a little bit is lock-in in cloud services. One of the things about the Ruby community is there's a lot of use of cloud services, whether it's Gmail for your email or GitHub or Heroku or IngenYard, more than any other developer community I come across, the Ruby community uses a lot of cloud services and a lot of apps out in the cloud. So, about 15 years ago, I was working for this company as an e-commerce ASP. ASP is what they called cloud providers before we had the name cloud providers because the names were invented by enterprise e-types that like three-letter acronyms, so that was cool. And we managed e-commerce stuff, warehouse management, finance, and all kinds of stuff for companies. We'd go into a company when we'd bring on a new customer and we would redesign their entire business process for e-commerce and around our platform. So, the entire way your company ran, big bricks and mortar companies, new startups didn't matter, we would help them change their entire business model to work around the way that we worked. So, that worked out pretty well. We had nearly a half a billion dollars between funding and revenue that was coming in and so everybody's thinking, hey, this is fantastic, this company's not going anywhere. So then we shut down and we had about a hundred companies that were on our platform and we gave them 60 days notice. Companies went out of business that were built on our stuff. It was not pretty. So, Tropo, the company I'm with, URL's there so you can jump on them real quick if you want to look. GitHub's got a bunch of open source. In fact, the whole source behind Tropo is up there on GitHub. We open source the whole thing. Because we start looking at examples like that and we don't want somebody to be screwed if they can't stick with us for any reason whatsoever. You could take your platform and run it on your own servers. So what is lock in? What keeps you locked in? Do you have an application or a deployment that only works on a single vendor? Is your data stuck on a single vendor? Do you have business processes that only work with their stuff? If you've built your business processes around a particular vendor, you're locked in with them. So now what happens if your vendor goes away or just plain sucks? So the vendor fails, maybe you look at it and go, my vendor's huge, they're not going to fail. They decide to exit the business. Microsoft won't stay in a business that they're not making $100 million a year on. So you look at Microsoft, they're not going away. They just might decide that this isn't a valuable business forum anymore, your company. So maybe you're certain that your vendor's safe. They're a good company, they're well funded, they're doing fantastic. You don't have to worry about them, even with a half billion dollars in revenue and everything else, they're going to stick around. So now what if they get acquired by somebody you don't like? Like maybe one of your competitors or a Canadian? Because you can't trust those Canadians, they're way too polite, there's got to be something wrong. Exactly. So okay, so how does lock in happen? You may build your platform on a closed system or it may be a completely open system that you build on, but you've got proprietary extensions that this vendor is using. And so they're pretty attractive, they do interesting stuff so you start using their proprietary extensions. You start relying on vendor tools. It's an entirely open system, but boy, they make this really nice easy way to do deployment. Or they make this really nice easy way to migrate or back up my data and so I start building those into my app and end up reliant on them. Or what about switching costs? Who actually was using the internet and involved in the internet about 95, 96? Do we have some people in here? Who had a business at that time and had an email address it was at aol.com. So that kind of sucked when later you decided to grow up and get rid of AOL, but you've got switching costs. Everybody you've given your email address out there and people are remembering this. So if you get stuck on something where it's hard to switch, that can create some lock in. On installed software, this is a little bit less of an issue. It can still exist, but there is a less of an issue than with cloud services and stuff up there. Legal agreements, you may have contracts that lock you in. You don't even realize it but hey somewhere in this contract you're stuck, you may be paying a monthly fee that's contracted out for 24 months. You may have guaranteed minimums or things like that that are locking you in. So how do you avoid lock in? I realize this can't go real in depth because I've got a whole seven minutes to talk but we'll give you some ideas here. So one of the things to do is know how you're gonna get out before you get in. What are you gonna do in order to get off of that platform before you start? What's involved in that process? Look at the cost-benefit analysis of switching and of getting off of that provider and what benefits the provider provides to you. If it took you five minutes to build an application on a provider and you can rebuild it in five minutes on someone else, then who cares if you're locked in? Stick with them. If you're building a thing that's nice to have on your business but if it goes away and it takes me three months or I never get it back, well then who cares if you're locked in? If it's convenient for you, go ahead. You've got a low cost and a great benefit. Stick with that. Look at legal options for avoiding locked in. Code escrow is a great idea. So you can get a lot of vendors to say if we go out of business or these certain events happen, we will give you a copy of our source code. Now, how many people have built an application that you built just for yourself and then someone said let me see the source code or let me install it somewhere else and you went damn I don't know how someone would have ever run this even if they had the code? So that can happen even with source code escrow. So keep that in mind that there will be investments in training and learning and redocumenting in doing code archeology to figure out how this platform works if you do get code escrow. A lot of people look at web services API and they go oh well there's no lock in there. It's this open API. An API that's only offered by a single vendor isn't open. It's not going to avoid lock in. Documented and well documented is not the same thing as being open. If you can't run it somewhere else, you can't move it. In fact, we're such a big believer of that. We take other companies APIs, our competitors, and we reverse engineer them and make them run on our platform so that if you are with one of our competitors and something happens you can move to us later if you decide you'd like to move. Standards are great for this. Either official standards or de facto standards. So HTML, XNPP, SIP those types of things mean that you can take your app and run it on any vendor. These are standards that are defined by standards bodies. They're defined by standards committees. If you have multiple vendors that can support this standard, well then great, you can run your app if you build it to those standards on multiple vendors. The AWS, the Amazon Web Services API is a standard. It's not an open standard. It's not, Amazon didn't set out to create a standard but because it became ubiquitous it became a de facto standard. Eucalyptus allows you to run AWS apps on your own private cloud. You can do use their deployment tools. Other cloud vendors are starting to make bug for bug compatible APIs with their clouds that fit the Amazon, the EC2 cloud. And then open source of course can help with lock in. It means that if you're running on something that's open source, you can pick it up and move it and run it anywhere. So that'll help. So here's what I'd like everybody to do. I'd like you to start thinking about what type of cloud services you're using. Think about if your apps and data is portable and if you think that they are the next question to ask yourself if the vendor vanished off the face of the earth tomorrow what would happen? If you can plan for that then you can work to be insured that you're not gonna be affected by cloud lock in. Thanks. So my name is Jeff Bowman. I'm with Valve Technologies and I'm doing Ruby and TK. I thought it would be more interesting than doing Ruby and the other one of million different web frameworks. It's a little bit more interesting to me and I don't like web frameworks. I use Ruby for glue to put things together and hold applications together and do useful things usually from the command line. Not that web applications are not useful. They're actually darned useful. It's just that I have a lot more fun writing stuff that's not in the web. So Ruby and TK. Again, my name is Jeff Bowman. My employer is Valve Tech Technologies. You may have seen the orange balls running around or the orange pens. I provided those. You're welcome. Someone once made the comment that this is the Ruby conference with balls. So Valve Tech, we write software mostly in Java.net. We also do agile training transformations. My job description is I'm sort of a senior developer and a lead tech for software teams. And for fun, I write software in a bunch of different languages. They're listed there. So what is TK? TK stands for Toolkit. It's really, really old. It was built way back in the day when all we did was X windows and stuff like that. Mostly for Unix systems. You want to think of forms, not graphical interface like something you would draw with, although you can. Yes. Then I will hit the page done button. That's sort of funny. There we go. We'll figure it out. It's working here. I don't know. Okay, so there we go. So TK, it's cross platform and it's lightweight and pretty simple. It's also very well documented because it's really old. So there is also a nifty Ruby interface that goes with it. And that's the part that we're gonna talk about. So what do you need? You need some libraries. If you're using macro shaft windblows, sorry. Go out to activestate.com and get the active tickle. It has everything you need except for the Ruby piece. You have to provide your own Ruby. If you're using Linux, Appget, whatever, your TK, TK tile, lib tickle Ruby to get all of your libraries. If you're using Mac OS X, not so sure because I don't use Mac. Not homebrew. Somebody said homebrew. That's awesome. What to look out for in some other tips? There's one of the things that the library does is it makes heavy use of instance eval. This will bite you in the scoping region. So if you don't keep everything in basically one single method and use nested methods to break up your code into something a little bit more maintainable, you're gonna have a hard time with this and you will pull your hair out. Mine's very short. It's kind of hard to grab. Everything in TK is a string so that kind of gets played out in weird ways in the Ruby library. Basically the method missing is implemented as whatever I get that I don't know about, that's not a method. Well I just package it up as a string and send it off to the library and hope that it works. Some days that goes. So here's some code. This is kind of what it looks like. You get a root window that's basically the place where you're gonna store everything. It's the big container, the big square that shows up on the screen whenever you're doing something you can create a frame which is a collection of other things to put in there. So that's how you create a frame and if you wanted to create an entry box that's what it looks like to create an entry box. The first thing is you can't, it doesn't work out real well to put the class, the instance value into the entry as the text variable. Don't know why, it just doesn't work out very well. So I created an alias for it and stick it and then that seems to work just fine. The pack is how you put it onto the screen. It coordinates it's X and Y where it fits into the frame. If it's expandable in both directions where it's anchored to, stuff like that. Let's see the next screen. Here's some resources. If you are going to do Ruby and TK it's kind of fun, it's cross platform. You can put it on Windows and it'll work just fine. You can put it on Mac and if you have X installed it'll probably work just fine. It works just fine on Linux but you need a good book. The book that I recommend is the Techland TK Toolkit by John K. Osterhout. I think it's in the second or third edition, second edition, something like that but it's about the best one out there for TK. There are Ruby books that mention TK and they have like a part of a chapter on it but it's not exactly helpful. That covers everything. The whole language. For web tutorials, there's some really good web tutorials on Ruby TK programming and one of the best places to go get information is that last one to the tkdocs.com tutorial. It has not only the tk that you would see if you were writing it with the library itself but you also get to see Ruby, Python, and Java, some other stuff, not Java. And that didn't work out like I thought it would either. So let's see if Alt-Tab works. So I was gonna show off the actual running application. Let's see if this one went all the way. Oh well. So I'm not gonna show off the running application. If you wanna see it, ask me for it later and I will show you the running application. It looks just like a swing application except for it's not. So that's Ruby TK. Questions? I think I'm out of time though. Really? Awesome. That was fast. And okay, that's it. So stop using dynamic software. I'm Jesse Crouch. I work with InfoChimps. I'm the product manager there and our chief developer evangelist. This is mainly about Jekyll and it's mostly about static sites but even more it's about agile development and building a minimum viable product. There are a lot of tutorials on Jekyll that can tell you how to use it and make it run on your site. What I'm going to focus on is not that because it's plentiful. Instead I'm going to focus on the stuff that's not plentiful on the internet such as why you should use Jekyll and how we used it to run our dynamic site. When you're building a site you make a lot of assumptions. You think that you need this and you think that you need that and because we are engineers and because we are educated people we believe that we are right but no matter how much we think we know there are always some unanswered questions. If I could have you remember one thing it's to remember that everything you know is wrong. The rule is if you think you need it you probably don't. I want to tell you a story about how we built the InfoChimps API. We made a lot of assumptions too. We thought that you have to have a way for people to sign up automatically and that you have to have an MVC based site and we thought that you have to have a live database of users to check every API call against and we thought that you have to be able to send out API keys instantly. If you're an engineer you like to engineer but you don't have to. In fact we didn't do any of these things. We could have started with a Rails app you know just like everyone else wants to but the thing is you never know what you'll really need and if you think you need it then you probably don't. Always remember to build only what you truly need and that is part of building a minimum viable product and the minimum viable products are the beating heart of the startup world. On another note, coding Ruby does not make you agile. Coding Rails does not make you agile and in fact there is no language or framework anywhere in the world that makes you agile or forces you to build a minimum viable product. Things like Ruby and Rails are merely vehicles that sometimes make being agile easier. So what should you do? You've got a lot of unanswered questions and does anyone even care about your product? Well, find out, build a minimum viable product. Find the minimum requirements for your product. What we needed for the InfoChamp's API was documentation, API calls, a basic site, a way for people to sign up and some sort of authentication. We could have built a big gigantic Rails app but we didn't actually need to. In fact for most of the site all we needed was some static HTML. Our documentation was all static files, the basic site could all be static files, it didn't need to be tied to models and controllers or anything like that. So instead of building a whole user model we used things like Perfinery and Chargeify for sign up. We used Win Netherlands Library to pull users out of Chargeify, then we pushed them to a Ruby file on command line and then we pushed it to a Google spreadsheet which we pushed to MailChimp and then we sent our API keys out in batch to users. Does anyone have an API key? Did you get an email from me? Yes, okay. So, Jekyll. We used Jekyll for our API site in docs and Jekyll's really simple. You make templates and you write in whatever you want and then it compiles to static HTML. Then all you need is a web server. No passenger, no unicorn, no thin, no Ruby server at all. It's all static HTML. This is Jekyll, this is how to use it and that's seriously honestly all there is to it. Tom, yeah, Tom's here, hey Tom. Tom made Jekyll. So, here are some other things that you can use. Tom wrote this too. You can find it on his GitHub. If you have a blog that's running Jekyll, this is a really easy way to get RSS to use it. If you need to do comments, discuss those comments, email me form, does forms, and you can do help and feedback using things like get satisfaction, user voice and tender. All that said, we did have some regrets. Probably the hardest thing was charging people money. We thought this was going to be easy. It really sucked because people wanted to give us money and we had no way to take it. It took about a month for us to get our merchant account with Authorize.net. We had PayPal but it sucked with Chargeify and all the other recurring billing services that we tried and we didn't really know which one to pick. And then our local bank, well our local branch of Bank of America, refused to take our money and refused to take fees by connecting our Authorize.net account with our bank account and that was ridiculous to us. So then we had to wait like another two weeks to a month in order to get Authorize to do it themselves. So this is pretty outrageous, right? The other thing is we quickly learned that nobody really wants to give you their credit card over the phone and if you try and email them and ask them, they politely don't reply. So stay minimum, don't build what you don't need and always remember that if you think you need it, you probably don't. Thanks.