 This was all pre-planned, of course, because I want to talk about technology constraints. So have you found yourself at work daydreaming about doing your own project, something where you get to pick the language, the stack, the feature set. You want to be liberated from the to-do list, the issue tracker, from Jira. You want to be liberated from the list that's been handed down to you. Hopefully this talk will be for you. Hello, Jay Rubiconf. A little bit about me. No, actually, before we talk about me, and Toby don't go too far away, Toby had a birthday two days ago. So I was thinking, Toby has also taken over the Jay Rubiconf this year, so I'm extremely grateful to him. And I think he should come to the front. And I think we should give him a Friday hug. Thank you. Yeah, so now really the boring parts about me. This is where you can find me on Twitter, et cetera. Where I live, Berlin, great city, supposedly. Now a wonderful place. I worked for a company as of two weeks ago called Q-Learning. We make exam study materials, so check them out if you decide to go back and study. Things I worked on in the past include paid open source work on a project called Open Project, hacked on things like data mapper in the past, even have committed patches to Jay Ruby. Like many Rubyists, I followed an unorthodox path into software development. Where do I come from? Although I've been programming for close on, well, actually more than two decades, my background is actually in humanities and linguistics. Does that make me a good coder? Who knows? I'm decent. I'm by far away not the best person in this room. Maybe I'm the worst, but you can check my patches on GitHub. But I think the fact that we have various different backgrounds, and you'll hear a lot to Eurocamp about diversity, but the various different backgrounds gives us a lot of insight. Outlook helps to be versatile. So what brings me to do this talk? This talk is pretty, my actually is unashamedly meta philosophical. There will be a few lines of code, but if you're feeling sugar shock after ice cream, feel free to fall asleep. No, this is lightweight and fun. Let's do a little survey. What are the things we love to work with? The fact is, most of us Rubyists are pretty strongly opinionated. Dynamic languages are probably, I would say, are attracting some of the best developers right now, and Ruby is no exception. And good developers are supposedly characterized by making good choices. So we choose things that we like. We choose things, yeah, whatever. Maybe not go, but everything else. Just had to throw that in. Our tastes also extend strongly to our environments, our desktop. This is something that we occupy for hours on hours every day, maybe 20 hours a day. So we're very opinionated about what we work with. Yeah, some people even like to work with Windows. But choice, what about it? Wasn't Rails really about the fact that we had hundreds of different Java frameworks out there, and then all of a sudden we have one canonical way of doing things. But Rails has become, in itself, is now, or rather, it is now something that's inflicted by or suffers from too much choice. Just to do templating, for example, you have all these different options. So maybe we want to reintroduce constraints. Constraints don't exist in a vacuum. They are actually themselves a sub-product. They occupy a space between the developer and the final goal. Constraints are something that enter into the process. They're something that provide obstacles. It's a little bit like, if you have constraints in your development process, I can find my cursor. It's a little bit like Mario. These things along the way. The overall goal you see it at some point at the end, but you've got to navigate. But isn't that part of the fun? That's why we play games in the first place. Let's talk about freedom. Freedom is in freedom fries. No, freedom, freedom. There are really, you can think of there being two different frameworks of freedom. And the thinking here about these matters is long. It spans 2,000 years of Western civilization. But hopefully we can summarize freedom in two different ways. First of all, positive freedom. So here, what is good? We use the word good as kind of a goal. What is good is already clear. Subject just follows naturally something that is good for everyone. The intermediate steps may well be known. As a consequence, there are few choices. But the result of that might be that quality is good. Afterwards, happiness is achieved. Happiness is achieved when the subject grasps the good, when the subject gets to the goal. Through this, we achieve quality. The problem with this, though, the problems with this are many. The developer, if you like, is there, becomes some sort of clerk checking off a list of tasks. In the end, it's quite an idealistic position. Then we have negative freedom. Freedom here is defined as the lack of constraints. Happiness is where nothing opposes personal will. It's all about you. It's all about what you can decide. The developer can get the code working, but all choices look tempting. This is the problem. And as a result, quality may well suffice. But on the positive side, what is nice about this is you get to use your own thought processes. Nothing is prescribed for you. Think of a world maybe AngularJS, compared with EmberJS. That's two good examples. In Angular, nothing is laid down for you. You have a lot of freedom, negative freedom there, but you can also screw up badly. Demo, and I don't think we have sound. It didn't quite go as well as expected. I don't know if anyone could actually hear that. The dangers of positive freedom are someone else dictating to you what is good or not. The dangers of negative freedom, on the other hand, are perhaps even more compelling or even more numerous. In current times, even when we're working with companies, we developers often think of ourselves or act in the same way as freelancers, as free people able to change. And we, of course, all of us, I think, very privileged, able to change from one company, from one city to another, travel all around the world, from one branch to another. But companies and clients have quite different meetings than the one we're in right now. They spend a lot of money on some technologies, pushing some platform, and that some person who's been at the company before you has said, this technology is worthy, this technology is the right choice, and you come in and you say, no, it's not. And that contradicts that point of view. So the solution in all of this between positive freedom and negative freedom must be somewhere in the middle, which we know is good. We have some found position. Every one of us prefers Ruby, or perhaps JRuby. It's logic, it's semantics, it's syntax, maybe. But this should guide like a goal. So a few more examples. Political events. Two examples, one with one for each outcome. So political events. Our actual political world. Dictators stumbling, failing, because peoples are not asking for, people are asking for their rights. And I don't want to get too much into politics here, but let's read dictators as people who are not elected by a democratic process. So people like Mabarak Gaddafi a few years ago, now maybe Yakovic in Ukraine, I used to live in luxury environments and to have every desire fulfilled for them. So this is really an example of positive freedom. But what really suffers here is quality. The second example comes from a short story by Arthur C. Clarke. He wrote it in 1951, and its title is superiority. It was about a captured general telling the story from his prison cell, who in giving the reasons why his side lost a war due to superior technology. And after the war he was ended, he decided to tell the true reason why his side was defeated. According to him, that reason is plain, it's simple. They got too caught up in trying to develop superior technology. So they were all concerned about having the best thing out there. And they lost touch with the basics. So for a software analogy that would be losing your use case or forgetting about your use case, the opponents using old technology, so the Java developers out there, were far more constant in how they were applying technology, but they ended up winning the war. So as I said, the way the solution to all of this is some sort of middle ground. We could always code in technologies just when they come out, use the latest in the graces, use the fad, use the trendy technology. But we first need to check if they're worthy. We first need to apply some critical thinking to that process. The motto being less choices and better quality. And last but not least, we need to check. We need to still need to get shit done. I'd like to spend the second half of my talk going into a particular example of where I've been counted constraints and where really the quietly versatile Ruby learns to keep out of trouble. Before I go into case study where I use JRuby, I want to talk about freedom and startups. So I've worked in a couple of different startups in Berlin, and in many cases you have this negative freedom when it comes to software choices. You can choose whatever technology stack you use, you can choose whatever language you like, whatever stack you like. There are no real preconceived ideas about technology. On the other hand, I guess you are confronted with other constraints. You might for instance in a high pressure environment have a VC breathing down your back. You might have limited budgets and resources which you might not have if you're working for a big company where they have a lot of corporate policies laid down about what technology stack you use. There are things like pressure to do overtime in startups. Washing machines. So this talk is a little bit recycled like this washing machine here. But a couple of years ago you might have heard that this company, a great German engineering company, Bosch, I did some work for them. This was in 2011, so please forgive the fact that the case study is a little bit old. I still think it's quite pertinent though. So the task, I was working at a Berlin based agency. Agency work is usually pretty dull, content, CMS heavy kind of things. The company where I was working, our agency was tasked with building an internal social media site to celebrate 125 years of Bosch place. And the site was really just a place for employees to share stories, experiences, social media, nothing too exciting, but it was 125 years of a very prolific company. And we wanted employees all around the world to, in many different countries, to engage with us, all integrated with Twitter, fully internationalised. But from a technical standpoint, nothing terribly interesting. I'm sure no one would get in this room here, get all that excited about technical requirements. So thought processes, well, we were emerging, our agency was emerging as a Ruby shop at the time. But we had to make some decisions about the technology stack, about the solution that we should go for. Of course, I think the prudent option would have been to have an out-of-the-box CMS that might involve hacking the hell out of Drupal, Type 3 or whatever. Type 3 can be bent to do these kind of content-y sites. But we wanted to provide extra value, we wanted to provide something a little bit unique we wanted. And just generally, our team preferred finely crafted tools. And that's why we're Rubyists. So we threw the sensible out-of-the-box CMS option out of the window, and we decided to roll our own thing. But there were some constraints involved. Big corporations, this thing was to be deployed at Bosch. Big corporations have big IT policies. It had to be hosted internally. So I'm sorry to say there was no Heroku for us, there was no Engine Yard for us. We had to have this hosted internally on Bosch servers in Bosch data centers. And there were also other middleware constraints. So in terms of stacks, what we were offered by them, the application service, what the application service would support, where it was PHP or a WIMP environment, .NET, Java. And even worse, all of this was on Windows. And sidetracking a little bit, talking just .NET, I don't know, it's just not quite my cup of tea. Actually, really, I don't mind C-Sharp, but I never really bought into the whole platform. Iron Ruby was cool, though. PHP, redeeming quality for me was ubiquity. Okay, that's a bit tongue-in-cheek. A true pragmatist will have PHP in their toolbox, and it's certainly capable of powering major sites. Just ask Facebook, well, maybe not Facebook. But I would never choose to work with it. The language just has too many limitations in my opinion. I just don't like Java enough said, or really. So this ought to be a JRuby talk, and I love the JVM. It's a super platform for applications. So why don't we try and exploit the JVM? Well, as Joe would tell us, it's just this simple to deploy an application with JRuby. Well, perhaps having to change your active records, GDVC driver, make a few other changes, but you can just pre-compile your application, and that just works. Unfortunately, that wasn't the end of our problems. That wasn't the end of the constraints that we were faced. So when we took on the project, we were told we would have free choice of application server. Unfortunately, there was no choice here. The choice for us was IBM WebSphere. So, as I said, we thought we would be allowed to use JBoss with all of its talkbox, with all of its wonderful integrations. Unfortunately, that wasn't possible. So, of course, when I was told this, I thought, oh, shit, what do I do? Went Google for documentation. There was almost none. There were only one or two articles that really mattered, which gladly share, although they're probably out of date by now. Of course, the constraint that comes with this is not just that it's WebSphere, but you are using completely different JDK, which in itself might not be problematic. But this was in 2011, and there was aggression somewhere between JRuby 1.56 and 1.60. And I think the CI server for the JRuby project was read for quite some time during that era. And we found that class generation, so when we bundled up or when we built war files with Warbler, we did this with an option to AOT, ahead of time compile all of our Ruby. And there are Java classes generated for each Ruby method. And to do this, it generates Java method names, but unfortunately the mangling of method names was somehow mangled and there was aggression. So we didn't manage J9 or the IBM JDK, didn't like our class method name, so we couldn't actually get anything to run on the JDK, on the IBM JDK, until we got a patch into JRuby itself. But fortunately, it was a fairly straightforward process to get a patch or it was fixed fairly quickly by the JRuby team. More constraints. I apologize to the Oracle employees in the room. I did refer to the Oracle database though, the thing that Larry Ellison made his money with. And we faced a few other problems. We decided at the time I was a Committer on the DataMapper project, kind of an evangelist for that. I had also written the DataMapper JDBC drivers, so I was fairly familiar with JDBC. But we encountered a few problems there. DataMapper, for example, had problems with Oracle serials, or primary key generation. And there were also problems with the way that, with class loading and the way that IBM application server creates proxies for JDBC drivers, stuff that I've never completely understood, but it didn't work out of the box. And we actually had to, I believe we had to fork Oracle's, we had to fork or use our own JDBC driver to get this working. There were more constraints. One problem we had was serving user uploaded content. For some reason, we weren't able to, there was no control over the file over IIS, which was the web server in front of this whole stack. And so we weren't able to serve user uploaded content with IIS, but that was solved, fortunately, through RackStatic. So we let RackStatic do the heavy lifting there, and it just turned out to be much, much easier. No file system access for us also meant we had no way by FTP, SFTP, SSH of getting access to logs. So we would get a dump of logs every couple days from someone at Bosch, but this was not ideal. If we had thought about this and spent, had more resources, then maybe we would write back logs to a database and provide some user interface for that. But that wasn't possible at the time. So lessons learned. Don't do this, just go with PHP. No, this lesson taught me to be the first time. I think I would go with more off-the-shelf solutions in the future. I am mainly using Rails, mainly following the recommended path now, or the standard path of C-Ruby deployments of Rails and ActiveRecord. But I think we have the opportunity to try out something on a project like this and go for it. High-level conclusions for this talk. Versatility does not necessarily mean use J-Ruby. J-Ruby is something you really should consider, and can let you get Ruby into a lot of companies where they wouldn't normally consider it. JVM is just a fantastic thing, and you're going to hear many more and much better talks here for the rest of the day about why we should be using JVM and why we should be promoting JVMs at that point. So embrace those constraints. If you're clever, you can really get around a lot of things. So focus on the goals. Focus on what I mentioned earlier. They use the word the good. Think that synonymously as goals. Low-level conclusions will know your Ruby primitives. They're not just Rails, of course. Learn the standard lib by your means. But you should really have synarch for tilt, rack, rack-static ActiveSupport under your belt. And I'm sure there are many more libraries that are worth learning. And that is it from me. If you have any questions, I don't know if there's time for them. Otherwise, no, no time for questions, but you can hit me up at the party tonight and ask away.