 of having a traditional panel discussion, what we're gonna have, and we should get off stage, by the way, is a fishbowl instead. So how many of you know what a fishbowl is? Okay, so a fishbowl is, we're trying to make it much more interactive than a traditional panel discussion. So here's how this is gonna work. Swan and then I are gonna moderate this sort of like a regular panel discussion. But you'll notice we have five chairs over here, but there are only four people sitting in these chairs. The fishbowl basically states that anyone who is currently sitting is allowed to speak, all at the same time, whatever. But anyone who's currently sitting is allowed to speak. So Swan and then I are gonna try to guide the conversation or whatever in general. And whoever's sitting here is allowed to answer the questions or put in their thoughts on whatever the points are. Now you as the audience, right? You obviously know much better than these panelists. So you are gonna get here. I get to speak all the time, this works. So if you as the audience wants to put in your two cents and you wanna make your points known, just come up on stage and just sit in the empty chair. The rule is as soon as someone sits in the empty chair, one of you four people have to leave. What if four of us leave together? They'll make you sit. That's what we are here for. So one of you have to leave. In case of none of you leaving, we are going to choose, we are gonna be the tie breakers to figure out which one of you we're gonna boot off. Can I ask people over here to kind of occupy the seats in the middle please? So you can enter the stage from over here. So we expect, if people are gonna queue up cause they really wanna say something about this topic, this is the area. What if the fifth person doesn't come? Nobody, that's not gonna happen. We just continue talking in that case. You can continue. You can just come back. So we're gonna ask a couple of questions and we're gonna just see how it goes. The very first question we're gonna start with is gonna be Ruby because this is a Ruby conference. So I wanna ask all the panelists here. What is the one thing that confuses the most about Ruby to you? Or what is one thing that you really dislike about Ruby? We've been hearing a lot of good things about Ruby so far. So now is the time to speak up something you don't like about Ruby or it's very confusing. You don't know how to use. Or what is the one thing that makes you wanna strangle someone every time you see this, every time you see this, and something ideally unique to Ruby? Can I go first? Sure, please. So that is not really specific to Ruby, but ROR, which I'm assuming a lot of people here use. I think one of the things that I find early on you just find really confusing is everything is super easy to do, but you don't realize what queries, DB queries end up happening when you do a very simple lookup. Maybe you're just accessing something from a product, from a bunch of tables and multiple joins are happening or N plus one queries are happening. And you don't find out about it until you really start digging deep. So everything seems super easy, but to really do it well and to do it right, you need to understand what kind of queries end up happening because of what you're trying to do. So that was like too much magic, I thought. Too much magic, yeah. Could get good points. That's why I like to recommend to people to have all their database queries in their views, because then they're really easy to find. Sure. So I'm going to go a little meta on this question and not talk about the Ruby language itself, but I'm going to talk about more about people and a lot of people in the Ruby community and overall across all communities. There's this habit of you face a problem and you see that there is this one particular gem which is in 0.0.1 version, but it solves your problem. You just want to go and install it without even looking at the code, without understanding what exactly that gem does. What impact it is going to have on your overall ecosystem when you go for upgrade and raise your upgrade every six months. That's like, and gems don't work. You can just not upgrade forever. I mean, that's what I usually do. Yeah, and if I see those projects, those are the most confusing projects. Like if you see a raised 2.0 project right now, you wouldn't know what to do. 2.0, that feels like the future. And if there is a security issue that is fixed, then you'll have to upgrade and then install. Indeed. Well, Siddhu, it sounds like you want to come up here and say this. Yeah? For me, what confuses me most is more than Ruby, it's the Ruby Easter, actually, like car. Go ahead. It's actually like you take one pattern, one person speaking very good about that, and then you speak on the same topic, there would be another person who would be like, totally speaking the other way about it. Like Ruby is not one way to, there is no right way to do it, and then it's always like, many more ways to do it. So we have our first country today. So I personally dislike it when, so there's this really productive part of the Ruby community that writes a lot of gems we all rely on, they're mostly in Seattle, and they all use this project management library called Ho, and I just dislike it. Every time they start a new project, like Erin starts a new project, the first thing I want to do is send them a pull request to remove Ho. It's just way too much magic for what you could just write in your gem file, your gem spec, sorry. I mean, you just put the whole gem in the gem file, right? Yeah, yeah, we could also all just use jist and github. I usually run into this problem where someone's worked on a code base, especially in Rails, with all of these super nice, high level declarative, extremely expressive APIs, without understanding how any of that translates into plain vanilla Ruby. Which, and the code that produces is really hard to understand because whoever wrote it hasn't paid attention to what it's actually doing. Sometimes it's even buggy because you know, I mean, there is a common thing we hear about this, right, Rails programmer, not a Ruby programmer. And I think that Rails programmers easily produce extremely, extremely difficult to understand Ruby code. I want to say I love flip flops. Does anyone know of flip flops in Ruby? Yeah. Yes, they're the best thing ever. Okay. One thing that I'm not sure whether I like it, it's not technical, it's a, let's say, culture thing, that if you are not changing everything every other week, then you're just not cool in the Ruby community. So I don't remember whether, I don't know whether anybody remembers WebRat, which used to be a thing, okay. And then I kinda got distracted for like 10 days, then I got back to Ruby, I tried to use WebRat and it's bugged. I mean, it's seriously bugged. Something core doesn't work. And I asked on Twitter, and people are like, oh man, WebRat, that's your so last month. Now everybody's using KappiBot. And this looks cool to us, but there are people like operations. There are people my age in operations who are really wrapped the wrong way by this. So they poke fun at me, oh, you're doing Ruby, yeah, you're a young man, you're a hipster. What did you change tonight? Does it still work this morning in your life? And I'm a bit fed up with that. Okay, so maybe playing in, oh, sorry, go ahead. So I wanted to share this. I've seen most people are getting confused with how scoping works in Ruby. So many people write private class methods in wrong way. Even in today's one of the talk, one of the slide, I've seen they have written private class method under just private that scope. That doesn't make it private. So people have to really read about how scoping works in Ruby. Yeah, the one thing that is the smallest piece of stuff which always bugs me and gets me really pissed off over Ruby is the equality part. You have equal to equal to, you have the case equality operative, EQL method, you have EQUAL question mark method. That's crazy for me. Okay, one thing which I want to say is interview people, a lot of, and they are Ruby on Rails programmer. And I ask them questions, sorry, Ruby programmer. And they say, no, no, no, I'm Rails programmer. And that bugs me like anything. Okay. How do people complain about Rails developers? So next question. What I find most annoying on Facebook is people with DSLR cameras, you know, like taking photos of themselves. What I figured out is DSLR stands for DSLs and Ruby. Are this the most annoying thing you've ever seen? DSLs and Ruby. I have another complaint that you cannot leave. So. I have to say about DSL as well. All right, let's hear it. Can you elaborate on that a little bit more? DSLs and Ruby, are they an amazing thing to happen or are they horrible? Aspect? No, I'm saying aspect is an amazing thing to have. It's amazing. But does it like, does it hide like what's actually happening underneath it, like? So obviously, you cannot say that I'm going to use this DSL and I'm not going to read about that gem. That was my first complaint, right? Whenever you're using a DSL, you have to dig into it. You have to understand how that library is actually working. How that library is actually converting that DSL into runnable code. When you, in aspect, write, it should something. Where that method is coming from, you need to go and dig it. Unless and until you dig that, yes, it is annoying. Let's say that for a DSL like anything else, it should be easy to do simple things and impossible to do complex things. So if it works the other way around, then it probably sucks. But for example, rake works like that and it's great because you can use rake and then go deeper when you need it. Yeah, and one more thing is that DSLs are very opinionated. Like the person who is trying to solve a generic problem. It's his point of view. And unless he fails to mature it over the period of time over the community, then things like folks happen. Like, I don't want to get into this, but whole puppet shift thing happened because of that. Because it was very open at DSL. If anyone has anything else to add, don't hesitate. Just come straight up. If audience have questions. Can you please let me complete, no? Okay. I'm done. It's actually interesting that you brought this up because the other thing that really bugs me about DSLs is pretty much all you're doing is depending heavily on that particular specific API. And when the library doesn't respect versioning, I mean, it's just appalling. Like, I just did this coaching session a few months ago and I was like, well, Rails 4, obviously we're gonna use can-can. And I hadn't touched Rails in two months and can-can was broken. I mean, what? A can-can-can was broken. That was also broken. Everything was broken. And I mean, what? And what about can-can-can-can? That, that, no, the joke was can-can can't. Not anymore. Yeah, the problem with DSLs is that when you start designing a DSL, you have to name it properly. And if you actually get it wrong, it can be pretty stupid. You know, when, when it should and it should not, it really doesn't make much sense. Oh, the next question. Oh, before you continue. I just realized that it just happened by coincidence. It is the RubyConf organizing team sitting on stage. Sorry. Yeah. So, you're gonna move on to the next question. The question is, when you're starting on a new Ruby project, what's the one gem that must exist in your gem file, not counting rails and bundler? I can tell you what I don't like is a Rails Bootstrap gem. And I'll tell you what I like is R-Spect. Yeah, that's one R-Spect. The one I don't like to have is the Ruby Racer. And obviously, there has to be one of either PG or MySQL or SQLite or... Mongord. Mongord, too. Okay. Send her a book, dude. Send her a book, dude. Okay. The gem for me I use by default is I could just start it, I just add using a device, but I think Rails, the latest version, has got Hasic or Password now, so I don't feel really needed. Okay, so since we have the RubyConf team on stage, let's break you guys up a little bit. Sidhu, can you stay where you are? Ajay, onwards, please. And can I have Lina on stage? Lina, please. Maybe Steve and Satish Talim if he's around. Okay, sorry, Paulo, do you wanna come on stage? Also, yell at Steve, he didn't actually pay for his conference ticket. I'll pay later. Okay, so, go ahead. So the next question, actually, we wanna put forward to everybody, not just the panel, is about building a career in software. Should you be a general purpose programmer knowing your entire stack or should you be building your career towards focused, towards a particular technology or a particular part of the stack? That's the larger question I wanna put forward and I wanna hear what everybody, all of you have to say on this. So remember, these four get the first shot at this question, but everyone else, feel free to come and displace any of them. Yeah, I think these are the kind of things where everybody does have an opinion, so folks, please come up. Are you trying to run away from stage? Sorry? Are you trying to go away from the stage? Is that self-serving, I mean? I don't know if you have anything to say. Steve, do you have something to say? Sure, so, we have a few folks in our office, actually, who don't speak English and who a couple of guys in the office have been teaching English to for the past month or two and conversely, I've been trying to learn Hindi and part of why I haven't learned Hindi in four years of living in India is because it's very painful to go back and be a baby again and when I'm learning Hindi, I am younger than two years old, like I sound completely ridiculous, my accent is wrong, all the letters are wrong and if you step out of your comfort zone, you are doing exactly that, right? So, if I go and try to do operations, I am a two-year-old trying to do operations. So, like, oh, I don't know how to set up the diagnostics and I don't know how to automate this thing, I don't know pretty much everything in the stack, right? But what's fun about that is that when we're teaching the folks in the office English, I can draw comparisons to computer science, right? And as I'm learning Hindi or at least attempting to learn Hindi, I can draw more comparisons to teaching English and to computer science and to operations and to Ruby and to C and to whatever other parts of my job exist. And so I think there's been pushes from both sides to become overall generalists or overall specialists and I think that they're both wrong, right? And I actually had a mental answer to the very first question which is what bothers me about the Ruby community and it's not on the whole but it's something that I see in every community a little bit and Ruby more than others sometimes is that you've stopped learning if there isn't a point where there's no magic, right? So the first time you come to Ruby, Ruby itself is magical and then when you come to Ruby on Rails, Ruby on Rails is magical. If you feel like you know it all, then you need to go find the thing that's magical and confusing and makes you feel stupid so that you can learn and relearn the things that you already know again in my opinion. Great point. Here's someone else. I have a more, so this is the question that I got a lot. I was at the college I graduated from for the batch which was starting to do placements and I got a very specific aspect of this question, depth versus breadth, right? Do I go really deep down and specialize in one language even versus breadth? And I think that's a very difficult question to answer because it fundamentally depends on what you want your working life to look like over the next five to 10 years because this is not a question that you take lightly. I think the trade-offs lie between, say, something like becoming an expert with the JVM or with a particular kind of database. Now what this means is it puts you in a position where all the hardest problems in the space come to you because that's why people hire you to crack that problem. But you are taking the risk that if something changes in the industry and your area of specialization becomes obsolete overnight, which does happen, you're left high and dry and you're looking at a fairly steep learning curve. The other advantage with this is if you're a freelancer, your rates are really good because again, I mean, you've got a depth of knowledge which very few people have. But on the flip side, yet again, you're talking about niche, relatively niche skill sets. So you may have a hard time finding a suitable role to, you know, that sort of fulfills you in terms of what you want to do. People who go abroad, on the other hand, have a different set of advantages and disadvantages. You get a much wider range of work. The work is likely to be more choppy because you're doing so many different things. So there may be some things you enjoy and don't. But I think it's completely a personal choice as to how you went your way between these two. I don't think anybody else can tell you. Okay, hi. Can you hear me? Not really. Oh, God. I'll hold the mic closer to your... All right. Would somebody else like to come up? Okay. What I, I mean, just give a quick background, okay? I'm actually an SAP professional. I'm an enterprise architect. I work for HP. My primary, it's not at all related to me. But the point, I'm a software engineer. I mean, I started as a software engineer. I'm still a software engineer. Even though I'm an enterprise architect, I've been through different roles. And what I have learned, and I've been learning Ruby and Rails and stuff for the past two years as a hobby. And now I'm a little more interested. But what I have figured out is that the question was, you know, whether you need to have depth in one area or just have a broad classification is important. I mean, if you call yourself a software engineer or a developer or a programmer, whatever. The first thing is you're an engineer. I mean, you want to be an engineer. And the point of being an engineer is one, you need to understand how it works. And the first thing you need to know very well, before you even go into the depth of a particular language or what it is, you need to get your fundamentals right. And you need to be constantly learning. Like the fundamentals I learned in 98, I'm that old. Okay, when I graduated, I'm very different from now. I mean, we had totally, the paradigms were different. What the paradigms are now, even more are better, I would say, in some areas. But unless the fundamentals are good and proper, I mean, it's very difficult to actually be a good developer, even just a good programmer. So once you get your fundamentals right, it'll guide you on whether you want to go in depth or broader, either way, you'll be a good developer. But if your fundamentals are not good, it doesn't really matter. I mean, you could be, you could study and whatever, but somewhere your code will not be proper. Sometimes, somewhere you're, why is she shaking, right? Not really. Somewhere your architecture, you're in the way you design stuff. I mean, even as a programmer, the first thing you do as a programmer is you sit and design in your own mind, how the logic is gonna flow, right? Unless your fundamentals are good. And this is something I see when we have new staff or we have new hires coming in. If the fundamentals are good, we can do everything else. I mean, your communications, we can improve, everything else we can work on. We can even teach you to code. But the basic software fundamentals, they have to be really good. Like we're talking Ruby, Rails, so the fundamentals we're talking are SAS, IAS, PAS, those need to be very strong. You can understand those well, then you know what, language is just, is just a matter of a couple of months. Aira, you had something to say? Yeah. I think it depends. That's the easiest answer, right? Both has pros and cons of going into weather, but you need to get some breadth first to go into depth, to understand, okay, to experiment with many things and then go into depth. So I, and I think I completely agree with Stephen what he mentioned earlier. If you're ready to go outside your comfort zone, you can always get into depth. Actually, guys, I disagree with you. By the way, I noticed all five chairs are spilled, so someone needs to get up and leave. All right, actually, I disagree with all of you all to a certain extent. Way to totally ignore what I said. Yeah. Let's do that again. So, knowing that we are at a Ruby conference, I'm assuming everyone here is at least a developer. Are there any managers in the house? Are there any solution architects in the house? I actually can't see any hands. Are there any people who really do any work here? And when you're actually doing this, you can become a solution architect and you can become a manager only if you actually have the technology depth to get into a technology role. And when you're doing this as early as possible, the deeper you dig into any sort of code actually makes a difference. So whether you are getting to learn Ruby or if you're looking at RSpec, dig as deep. And the good part is that we're working on sometimes open source systems. You can dig as deep as you want to learn as much as you can. It's only going to improve your knowledge. So in my opinion, if you're a developer and you enjoy it, just keep digging deeper. I mean, question everything and it'll make you a better programmer if that's what you intend to be. If you're not a programmer, then you probably shouldn't be sitting here. I'll just take this point forward that I got this job because and one of the best database company in the world was because in the last five years, I have explored or have worked on almost all the web frameworks, mobile frameworks and all. So I'm not a master of all, but you know, Jack, Jack of all, but what I would recommend is you need to be good in one area at least, and then you have to spread out and broad base yourself. So if you want to be a solution architect, then you need to broad base. And if you want to be a specialist, then you need to stick. That's actually completely opposite of what Lena said. Okay, I have a different question because Lena had been good, talked about it. Are you saying our questions aren't good enough? That's what it is. Just asking a question, okay. So basically, when I was starting my last company, that time we chose PHP, I had a lot of prejudice with it, but eventually it worked out very well. But in Ruby, I'm starting my next company and the biggest problem I'm facing right now of choosing Rails as the primary technology is basically Ubuntu, it has LDS. It promises something for a longer time. There is PHP. In PHP, people actually criticize it to the death. I have spoke to a lot of people and I don't like it myself, but it worked for me. But the most important thing is they said that five years will support this framework. In Ruby world, I did not code for three and a half years and two major language changes happened and the framework was changed completely. We moved fast, man. Now, the thing is, I'm not against moving fast. The biggest problem is if I'm basing my next company on it and I have to actually support that product for four, five years, am I going to rewrite that whole product twice during that time or I'm going to actually start losing gem like my soldiers on the ground one by one and these people don't support me at all. So I am always in this perplex situation. What is the right thing? What people do think about this? Is it really bad to support something for a long time or is it just not good enough to support something for a long time? Okay, and I think we're coming to the last five minutes. So let's just keep all our statements quick. In one word, it's evolution, right? Everything changes. And one of the keywords in Ruby is always called refactoring. You always end up refactoring. What we actually miss out on is, in production environment, you need to have the, I wanted to say the right word, you know it's the round spherical thing. You need to have the guts to actually say that, you know what, I am going to upgrade my systems. I am going to do this, whether if you're your own product, you should upgrade to the latest version. You should take the leap of faith. Don't, and if you're in the services- The most important word I'm getting at. If you're in the services company, it's a big issue. I know there are a lot of people who work in services companies here. Customer did not allow me. We've actually got- That is more like an excuse. Exactly, exactly. We actually have an unwritten rule. Don't tell the customer, just create a GitHub branch, upgrade it, make sure it works, make sure text passes, you have good code quality, and just run with it. It just works. Yeah, you didn't ask the customer when you start around with Rails. So why should I ask you when you have to upgrade, so. I have two things to say here. So one is something related to the current discussion, which is instead of putting it as an issue, it is something which keeps you going. So which keeps your meter running because the customer always needs you. Dependency doesn't go. So that is one way of putting it. So people in Rails do make money because of that. Anyway, coming to the original question, I have one more angle to the whole thing, which would be, it depends on how comfortable a person is in adapting to new things and picking up new skills and learning. Okay, so if somebody is really good, I myself have worked over different domains and verticals altogether. Okay, I was in infrastructure space and now I'm a solution architect and blah, blah, blah. I'm comfortable picking up things. Okay, so where a full stack programmer, programmer, I mean diverse, if I do a skill set, everything works, yes. If you find picking up new things, working outside the comfort zone, everything takes time, I would say stick to the particular thing what you're doing, do it good, it'll be helpful. So we're open to audience QA now, anybody has any questions? We're gonna just take one question for the audience again, like whatever you guys want, just. Anything, it could be. Anyone raise their hand? Got them. What after Ruby? What language? If you had a choice, what would you choose? So the question is, what's next after Ruby? If you had a choice, what would you choose next? Functional stuff, yeah. Whatever pays my bills. Which one? I would go with anything which makes money. If I have to do that, after it. I like the way you say it. I like we finally have one honest panelist on this. I got solution. Yes, you keep talking about solution architects, I don't exactly know what that is. It sounds like fun because everybody's laughing, but what the heck is that? That was too tempting, man. A solution architect, pardon the, if anybody has that title in your company, I'm really sorry about it, but in my opinion, my opinion, a solution architect is a person who comes there. How many of y'all have seen MasterChef, right? MasterChef Australia? Like, hmm, I think the consistency of this, the database is not right. I think the scalability in this serve is pretty cool. I haven't fucking gone and made anything. I have just tasted it, but I have given an opinion. Okay, so that is a solution architect of bigger companies, typical big companies, groups. Solution architect for smaller startups and growing companies are much different. I'm gonna say you have one. It's the same thing without the scale, really. So the bigger companies, yes, what is it, makes a lot of sense there, but startups and growing companies, it's more like where you need to be hands-on, you need to have depth, okay. Any other questions? I think we're out of time. I think we're out of time, so on that happy note, we're gonna move over to the keynote. Siddhu and Ranjan, do you guys wanna start?