Today what I am going to discuss is that education applications for high school students, first on tablets or whatever it might be there are two kinds of applications namely core applications and the applications developed which are using web. So core applications like the SMS program, calendar, maps, all these are also called applications that are built in applications and all these applications are developed basically using Java and they are currently total 5 lakhs apps in android, all these apps are, these many apps are possible on android just because that android provides open development framework so that whatever the innovative thoughts you have you can develop an application with that. I said one is called client-side application, these are developed using Android, HTK and other is web application, these are developed using web standards like HTML, HTML and all those things. Actually when we install an application where do these applications run? Actually these applications run in an area of operating system called Sandbox. What is this Sandbox? What is this Sandbox is that it is an area of operating system which does not have access to other resources. Suppose you have installed an application, suppose if that application takes your contacts messages and sends you some intruder then all your confidential information is lost. So that type of things should not happen. So the applications are running Sandbox, before installing an application, there is an android that is called Play Store, what it does is that when you install an application it displays all the required permissions which are need to be enabled. Suppose you want to run a game on a tablet then it needs to enable the vibration, some music has to come for that. So such type of permissions the Play Store will display and the user will, it is up to user to enable it or not. So in brief if you think what is Sandbox then it is nothing but a progress of security. Suppose right now after I talked about the applications and where they run, now I want to talk about what are the disadvantages of classroom teaching. And what are the disadvantages means that suppose I am teaching something and the user may not assemble the things at that time, he may be sleeping, he may be something else. So the worst in drawing, so whatever the teacher says those come only once and if the student is not ready to accept those things he has left something. And suppose in a large classroom active learning is very much difficult, a instructor can't concentrate on each and every student personally and when it is something, when the instructor teaches something he doesn't know whether the student has understood or not. There is nothing like a shot wheels all the time this right, so in the classroom teaching. And suppose the main thing where a student learns is homework problems, suppose the instructor has given a homework problem, the review of that homework problem will be given one week or 10 days back where the student forgets the concept themselves. So there is nothing called instantaneous feedback is not there in the classroom teaching. And review questions, suppose the following course are there, after the course is a 15-20 minutes of the course you will be given a review questions, some review questions like a sir, no choice, some multiple choice, whatever it might be with can give it. So the instructor itself can understand whether the student has understood or not. If the most of the people answered it wrong, then the instructor himself understands that something is mistaken and it has to be taught and some more material can be given. In classroom teaching all these are not possible, all this led to use of OLA, which is called as online learning initiative, the Relate Online Courses. The motivation is that today technology is very good and it helps to, so that we can use it for education and teachers also can use technology to enhance their learning. Learning happens, suppose if a, if a given homework and instantaneous feedback is given so that the student can understand their mistakes immediately and then they get enthusiasm. If they do not get enthusiasm then there is no point of studying. And today the costs of the college cells are becoming huge so that the middle class families cannot afford good colleges. Hence developing the following education applications is very much important so that the student can understand easily. Okay, you have developed an application. Today suppose if I have developed an online course website, then the user may access it through via PCs, normal desktop computers, laptops, tablets or something personal, digital, anything it might be. So suppose the format which I have to send to tablet is different from the format which I have to send to personal computers because all the screen resolution is different, the format which they display is different. And the web browser also, suppose if you take a word, web browser also supports different markup language, HTML, XML and mobile applications is like WML, different thing. And file formats and all are different. So what we have to do is that for the developed electronic content we should be able to send to different devices depending on what devices they are accessing. So hence content visualization model is very much important. Suppose see there is an e-learning shell, this is an online course website where like this course are offered online. But the problem with this e-learning shell is that it can be accessed only through PCs. So what is this making?  The solution is that we have to develop a visual level subsystem so that everybody can access through other devices. Then how to recognize the things? Suppose right now web browsers and servers all those things use HTTP protocol to transfer the information on the internet. So servers can identify the particular device using a request using a request data-free limit HTTP protocol editor. Using that protocol they later through that they can understand through what device they are able to access. And this is also called HTTP user agent editor. What is there is a client says this HTTP user agent editor. What the client says is that it says what type of format it accepts and the browser supports and different things about screen resolution all those things. This user agent editor contains the information about the browser type and the OS and the hardware just these three things. But as the many tablets are coming so this user agent editor is not sufficient to recognize the device. So what they have done is that they have different they have found new thing like composite capabilities of preference profiles. What this WWW web documents standard says that the devices are allowed to transmit the configuration details like screen resolution, audio characteristics, what frequency band it can accept so that it can identify the device and according to that device we can send the content itself. This is this previously that HTTP protocol editor we can identify user agent editor. But it contains only information about hardware and operation and the browser type. But as many devices are in right now so just that three things are not sufficient to display correctly on the tablets or whatever it might be. So WWW web document is new standard like a composite capability. So that it displays like this many things are there. I have written few screen resolution audio, what kind of 48 supports and all those things. What is the content adaptation approach? Means that when we are developing some content it should be adapted to every tablet or every PC. So what does it do? Suppose it has to modification the content like it has to compress the text, compress the images, image must be resized, some text must be formatted according to the device. All this is content approach. Content will be adopted according to the device type. Suppose if the website is accessing normal desktop computer then no modification is required. If the same website is accessing via mobile device or something else then all these things will happen. There are three types for this content adaptation approaches. This is called server based approach, proxy based approach and client based approach. There are three approaches for this content adaptation approach. The first one is server based approach and the second is proxy based and client based. What is server based approach? The web server will contain different modules for content adaptation. Means the web server itself contains different suppose the same content is there. It will be storing one format for one device and the format for another device and the format for another device. It can be stored like this. But the problem with this is that if there are lakhs of devices then for the same content, lakhs of information is stored. This is not a good thing. This is not a good approach for this. So what they do is they store the information in the XML and transform it using accessibility. There is transforming languages there to transfer one same content into different types based on the devices. So I am storing the same content that the server said but using accessibility I am getting transformed. So the device will be arranged for what type of device and then according to client's profile the content will be sent. And the proxy based approach all these things which the server has done the proxy we do. They are good because the server will have many other loads. The proxy itself is good. And the proxy also catches the adopted content which can be used later. And the client based approach the necessary transformation is done by the browser at the client's side itself. For example in mobile browser Opera software is a client based adaptation technology. It is called small scale rendering. It displays the content according to the device type and displays the things. The visualization model means the same format will be different for text sheet may be different for audio it may be different and media it may be different. So for different things we have to develop each model for different things. The visualization feature requires a different approach and different type of templates must be used. The main advantage of this online teaching is that we can combine the voice and the graphics at the same time. Then the words can be linked to some diagram where we explain it then you can understand it easily and instead of that if you read a textbook some diagram will be there some explanation will be there there is no animation in the diagrams in the textbook so instead of studying like that online teaching will be very much helpful. The main problem is that if suppose I did not understand some video there is no alternative way of explanation then what we can do is that for enhancing the learning of the students we can pose some big problems and some frequently short questions so that we can make the students understand better. That's what I said previously so instant in assessment can be given by online learning and surely we can practice textiles and all those things so that they can understand better. So we can do that textiles and all those things so that they can learn much more things and one more thing is there we can log the data used by the students suppose if the student is asking some material many times it means that the student does not understand that material much time using data mining techniques and machine learning techniques you can identify where the student does not understand and teach that once again in a different manner and the advantage of OLA is that peer interaction develop a discussion forum then one doubt can be known the answer for doubt can be known by all the students and the review is also very much easy keystrokes, mosquitos everything will be log so that data mining techniques and machine learning techniques can be applied to know where the student is feeling difficulty and according to that some new questions can be posed or teach in an altered manner or give some additional materials so that student can understand the things very much easily The advantage of main advantage is that the teacher is teaching the feelings then to explain it all these things while the voice and the graphics both run at the same time so it can understand very much easily rather than in textbook if it is given in somewhere else explanation is given you cannot understand whatever again using animation also if I apply 10 Newton's force and 20 Newton's force how it rotates you can show all these things all these things are possible in online learning rather than classroom teaching and there is one thing like learn by doing it means that take assignment and get feedback so that you can understand where you are going wrong and even in the homework problems it's can be given suppose in normal work problems no it's will be given suppose you are stuck at the 40th step then at that time if I will give an option where get it then if you click that you will be getting where you are wrong like that it's can be provided according to where you are stuck same feedback, grade, homework so all these are benefits of the problem but the challenge is that lecturer cannot explain it again and again and good interface is given as to be there because throughout the world there will be actually stand for online courses throughout the world everyone will access so the user interface which you are developing should be very much good no personal interactions right we have the references that's all any more questions


lucky today because we have not one but we have four Ruby core committers here today and you're going to hear from many of them individually over the next couple of days but we wanted to take this opportunity to bring them all together up on this stage and get a sense of where Ruby is moving as a whole. So it's my very very big pleasure to invite them up onto the stage. Can I please invite the one and only Matz? Let's give him a huge round of course Hiroshi Shibata. We'll be speaking to you tomorrow and the one and only Aaron Patterson with his selfie stick, Aman Gupta who's very graciously joined us today as well. Please have a seat gentlemen and joining me for this panel is Winston the man who brought you this conference. So Matz of course needs no introduction. I'm sure you guys all know who he is. He's the reason we're here today. Shibata-san next to him is a C Ruby committer and he's going to be speaking to us about M Ruby tomorrow. Aaron is a core contributor to both Ruby and Rails. He's a 2010 Ruby hero and he's giving a closing keynote tomorrow and Aman next to me is a 2009 Ruby hero and he's been working on making Ruby leaner, meaner and faster for you. So how this is going to work is we're going to start with a couple of questions for our team panelists and then we will give it over to you guys if you have any questions for them. Okay so maybe what we can do is while we start with the first few questions if you have a question for our panel if you can line up behind the microphones then we'll know to give you your turn at the end of the question. Okay so thank you everyone shall we begin? Sure so to give a little bit of background of why we are doing this panel this year I was sort of inspired when I went over to Ruby Kaigi last year and I saw this Ruby committer on stage and it was overwhelming because on stage they had like I don't know 50 people maybe. Around that I don't know it was like the stage was full of Ruby commuters so I'm like oh can we do something like this in Singapore but it's difficult to you know to get 50 Ruby commuters in Singapore honestly so you know I'm really honored that we have them here today and that's why I thought we shouldn't miss this opportunity especially to interview them about the future of Ruby and what they think about Ruby etc and I hope that you all will find this chance really awesome as well because there's a chance for you to voice out any opinions feedback that you have about Ruby as well to our panelists. Great so maybe we can begin with something a little more simple and this is a question for all of you what are you working on right now what was the last thing you worked on before you came here? Mimi? Let's start with you Matt. Okay I spent my time designing Ruby to make a decision about the language future like accepting proposals rejecting proposals and write a future world map and then at the same time I'm working on as a programmer on M-Ruby and the stream languages. It's already on. Okay so I maintain a lot of websites or like Ruby Rangorg and Ruby CI com and Bronx Ruby Rangorg as an issue trucker so I operate I'm an infrastructure engineer of Ruby Rang and I'm met over C Ruby and R-Doc and Rake and Ruby James and Ruby Beaded so I support to build the issue and synchronizing called Upstream and Ruby trunk. Maybe you can use one of the other mics. Hello. Hi I work on a few of the I maintain a couple of the libraries in the standard library like Fiddle and Psych and recently I've been working on I mean mainly I look at how Ruby works from a Rails perspective so I'm on both the Rails and the Ruby core team so basically I look at how our application runs performs or our Rails application runs and performs and then I think about improvements that we could do to Ruby to deal with that and recently I've been looking at code loading which I'm going to talk a lot about during my talk so I don't want to say too much more. I work mostly on performance so whenever there's we run I work at GitHub so we have a pretty large Rails application and we have a lot of extraneous Ruby code as well so we try to optimize as much as possible on the Rails side but there's times that we need to jump down to Ruby and make improvements there. I am most interested in boot time sort of similar to the work that Erin's been doing but I'm working on a couple patches that are still very experimental but trying to get boot time as fast as possible for our app. That's great thank you so much. So just now in the earlier keynote we have already heard about MADS talking about you know there are other languages out there right now like Go, Elixir, RAS etc that probably you know has some good features that we should adopt for probably Ruby 3.0 but Ruby 3.0 is probably going to be a little bit away from now. More of looking at the whole community in general are you worried that people are moving away from Ruby to to go into other languages? And this is a question for all of you as well so feel free to jump in. Actually it's up to each individual's decision so we cannot say anything but so at least you know we often say the open source community is kind of like a shark so if we stop swimming we will die so we have to indicate to the community or to the world we are alive we are improving we are moving forward so that's the things I am thinking of always. It's in my opinion it's hard not to get worried about stuff like that I think maybe because I spend way too much time reading hacker news. Seriously though because you read it and they're like oh it's one day it's JavaScript the next day it's Rust the next day it's you know whatever so you always think about that but then I remember like well I'm actually building real applications not you know some blog so it's it's difficult to say it's difficult to say for sure I think probably sorry Matt I think probably Ruby's not cool anymore I mean I love I love it I love programming in Ruby it's just I'm maybe I'm not very cool I don't know. Do you guys think Ruby is cool? A little more enthusiasm please come on. It's not it's not cool for hacker news. I agree you know maybe ten years ago when Rails came into the world so though everyone is new to Ruby basically and it it appeared very cool new new things but you know these days you know we have Ruby for a long time so Ruby hasn't changed drastically for a long time so you know but it's how we earn money. I would say that competition is definitely a good thing you know like I'm not worried because it's cool to see all these new ways of approaching programming and we can learn a lot from them and at the end of the day you know like when you're trying to get something done there's advantages to using one thing over another so for instance I maintain the event machine gem and for a long time like Ruby developers that tried to do event programming in event machine had a really hard time because it was a very different way of thinking about stuff and it was very easy for those developers to use a blocking library or use a gem off the shelf and then try to fit that into that machine and those two paradigms didn't work as well and so for me it was actually nice to see people start to use Go or Node.js or other technologies for those applications because they were better suited towards getting those types of things done and that doesn't mean that Ruby is not as good or or any less because you know like for me I write a lot of C I do a little bit of Go but at the end of the day I still think in Ruby and there's certain class of applications where Ruby's might go to whereas there's other sorts of applications where if I am very performance sensitive or I am thinking about getting something done in two megs of RAM then maybe Ruby's not the right solution there and I can experiment with these other things learn concepts there and then bring those back to Ruby to improve Ruby in the long term. That's great. This is a question for Matt's since we're gonna do one for each of you and then we're gonna jump back to the audience and see what you guys have for us. Have you ever thought about creating another new language from scratch so you talked a little bit about that this morning? Yeah, I just created the stream program language last December. It was just experimenting. I had no intention to make it public but as a workplace I put my soul into the GitHub so someone found the repository and then he passed it to the hackaniers. It became cool again. At that time it was the 200 lines of code. It was just a toy. The huge threads in the hackaniers or the reddit and everyone gave a star in the toy program. I had a 3,000 star on GitHub stars and 200 lines of code. That was funny. I thought of the source was the community around some kind of the workable working code. The stream proved it was wrong. It was just quite easy to be popular if the hackaniers found it. To follow up, would you have done anything differently looking back now that you know everything that you know about how Ruby has progressed and now starting this new thing from scratch? As I mentioned in Keynote, 1993 was a totally different situation. We had single core machine and we had very simple programs. If I saw the 2015 back then, I would do differently for concurrency and I would do differently. I would have less inherited from pro as a scripting features. The importance of the scripting features is getting less and less important. Do you think that M-Ruby is sort of something that would solve some of the problems? Some of them, yes. M-Ruby is confirming to the ISO standard we defined in 2012 and it lacks the definition of some kind of the dollar special variables or something like that. Even regular expression is optional. In that sense, M-Ruby is much simpler and smaller. This is a question for Shibata-san. You're using Ruby from a very practical angle. What do you think is the most important benefit that Ruby gives you? Sorry. So maybe the question would be why are you still using Ruby? Yeah, I will be an interpreter. I think Ruby language, so I feel I write Ruby code, so I feel a pun. I think it's the most important thing for Ruby. So he feels his coding when he code in Ruby. So that means if you're working in other languages, you're probably working rather than coding. You know, sometimes we feel we are doing some kind of bookkeeping. Okay. So I feel I wrote some languages, so I feel I'm working. That I write Ruby, so I'm programming. So I feel... So I guess a lot of us probably share the same sentiments exactly, which is why we are all still here. Some from even the first ever read.ruby.com because we all felt that using Ruby is really productive, really fun, which is why we continue to do it even though there might be other languages out there as well. This question is for Erin. A lot of people depend on the improvements that you make to the code and the work that you do every day. And people closely follow what you're doing and what all of you are doing to a certain extent. How do you decide what you're working on next? Oh, dear. Questions. Well, so usually, I mean, basically the way that it works is I take the specific features that I want to do, and then I have a system of levers and coins that I flip. And... No, no. Basically, the stuff that I choose to work on is driven by... Well, it'll either be... There's a few different things that drive me. First off, it'll be things that we need for our application. So that's one of the things that it'll work on. Other times, it'll just be like somebody files a bug and it's like, oh, this is a pretty bad bug. We should probably fix that. So that'll be something that I work on. And then probably the third category is where I just get...  So it's typically one of those three things. But yeah, I think most of the time, it's driven by the applications that we use at work. So that's where I put most of the weight. So one last question for Aman. So you have done a lot of work on performance, tuning and debugging for Ruby. What has been your biggest challenge so far when you were doing this performance-related work? That's interesting. The one that comes to mind right away is not even... It's a little bit technical, but I think... So there was a point of about three to four months before the 2.1 release, where I was working very closely with Koichi-san. And it was a really good collaboration, but it was challenging in one, in terms of time zones, because I found myself basically waiting the entire day for 5 p.m. my time, because I was like, okay, Koichi-san's gonna wake up and I have 10 sessions for him. So that was interesting. And then also the language barrier was definitely a big part of it. So we collaborated on the garbage collector for a long time, and a lot of the first couple of months was really talking about variable names and doing renaming and refactorings and cleaning up the code so that it was much more easy to understand. A lot of it was like... He would ask me questions about what is the subtle difference between this word and this word in the English language and try to get the exact right naming. But it felt kind of cumbersome for a while, but I think it ended up in a really good place where a lot of the commits during that time were search and replace one word to another word. But the end result was after a few weeks of that, the code was much easier to read, much easier to understand. You could look at a function name and really get a sense of, okay, this is what it's doing. And so I think that was the most challenging in terms of even understanding a lot of the code and understanding why it was written in that way and then getting to a point where we could simplify it. I think it ended up in a spot where now it's much easier for anybody who has a basic understanding of C to be able to go in and read that code, even though it is, you know, GT.C is one of the largest, most complicated files in the VM right now. That's great. And to round off, back to Matt's for one more question for you. In a previous interview, you mentioned that for the first few years you wrote Ruby largely on your own, and then people started to join and contribute. Can you tell us a little bit more about how this first community formed? Right after the... Right after I put the Ruby on the Internet on December 1995, so I formed the mailing list, and I didn't expect many people to have interest in the new unknown programming language, but I expected more than 200 people to join the mailing list, and the first mail in the mailing list is from my friend, so the congratulations to open your software. Then the second one is, okay, I found a bug. The third one was for me, and absolutely I fixed that bug, and the fourth one, I found another bug. So I realized it's kind of difficult to implement the programming language, which is, you know, most applications has intention, so the purpose, but the programming language can't do anything. So it's quite difficult to predict the combination of the features. So the... And the bug thing, I really didn't have any test of the language. So in that sense, Ruby is kind of working, but it has a lot of bugs, so it's easier to find, easier to fix. So the people helping me to fix the bug, okay, I found the bug, and this is the patch to fix that. So in that kind of involvement, it could become a core of the core development team now. So we just, in that sense, Ruby had many smart developers involved in. So then from the... gradually from the community of the developers and users, then their popularity was formed. And Dave Thomas found Ruby, then wrote a book, and then DHH found Ruby, and Ruby on Rails framework. So the rest is the history. Awesome, and now we're here today. So it seems like if you want to form a community, you should release buggy software, which people can help fix now, I'm kidding. Actually, I got one question. Because we are all doing open source, have you ever felt discouraged when you are doing open source, or have you ever thought of, I don't want to do this anymore. People are not appreciative of me, et cetera. Have you ever felt like this, and almost wanted to give up? Well, 15 years ago, the term open source was invented in 1998, I think. And as soon as I said that, I had a lot of things, misunderstanding of the source, or free software, free, I was in free beer, or they didn't trust any open source, so that they considered open source as a toy software or something like that. It's kind of discouraging for me, but not that big to stop the project. But back then I was tired to explain about the benefit of open source and the trustworthiness of the open source software. The situation has changed a lot in the last 15 years. What about the rest? Do you have anything you'd like to add? I can give you an earful, I suppose. Ask me tomorrow night after a few years. I'll tell you, I'll really tell you. Honestly, the worst for me is like, maybe you saw Andre's talk this morning about security issues. I think that's probably the most discouraging thing, especially because, well, it's hard because somebody comes to you and says, okay, I've got a bug, and you have to keep it secret. And by the way, I'm going to tell the world about the bug on a certain date, so now you need to make sure to fix it by that date, or everybody's going to know that it's broken. And then since you have to do it in secret, or since you have to fix it in secret, it's harder to get people to review it, so it's possible that the thing that you release is actually broken, which this has absolutely happened to me. And then you also have the potential of breaking people's software with the security release, so maybe you fix the bug, you release it, and then all of a sudden you get people reporting and saying, well, you actually ruined our application. Sorry. This happened to me with a high-profile company who is sitting to my right. So, yeah, I mean, that sort of stuff is really discouraging, especially you'll get a lot of people who say, oh, how could you have written that bug? How could that bug exist? When it's just like, I don't know, I mean, it just does.  I mean, that's basically just the way I have to think about it, but, yeah. I think after this question we're gonna throw things back to you guys, so if you have a question for our panelists, please head up to the mics right now so that we can go right straight to you afterwards. So, come on. This is a question for all of you as well. The Ruby community is really nice because, well, Matt's is very nice, and so we are all very nice. I don't agree. Well, if that's the case, that leads me to my question. So what are some common sources of disagreements between you guys among the contributors within the community, and how do you solve them? So I try to consider that everyone is among the same team. Like, you know, sometimes the people complain about the Ruby or the reporting bug with very angry fearing, but I consider them to be a member of a team, like the team of the broader Ruby community. So by thinking like that, I don't have to react with the aggressiveness. I don't have to reflect their feelings. So, okay, I'm sorry, but you can solve the problem, solve the issue together. So in that sense, we can at least try to be nice. Do you think they're adding emojis? Yeah, emoji is great invention. And in GitHub issues, we have a lot of sushi as a reward. So that makes me wonder, so when are we going to add macros? Great, so maybe we can go to the questions. If you could let us know who the question is addressed to and what your name is. This can be for anybody. My name is Casey. Ruby, I've found, has been a fantastic language for people that are brand new to programming because it takes away a lot of the boilerplate, a lot of the extra syntax and just lets you start thinking and typing. But part of that simplicity can make it difficult for people that are brand new to programming as well because as soon as you get past that surface layer and you actually try to be a core committer or be a committer to some gem and not just a consumer of these products, the complexity gets pretty deep pretty quick. And it's been hard for me as a mentor to get people from that first step to the second step of going back and contributing again. What advice do you have for me as the mentor and for the people that I mentor to get past that first step of now you've learned how to code but maybe Ruby is your first language and it made things easier for you. How do you get to the next part? You know, I have never been a beginner, at least in Ruby. But in programming, so we often see the very deep complexity often. But I think it reflects the fact that the world itself is complex. So the problem we are going to solve is complex. So we have to face it. But we have the power of abstraction, so most of the cases we can abstract away the complexity of the world and the issues. But when we first solve those issues, we have to struggle with that complexity. Then the only strategy we can take is divide and conquer. So divide the complexity into the small pieces and abstract away to the inside detail into the say class or library or framework. I think that is the only way so we have to step forward bit by bit. So then we have to face the complexity of the world. I'm not sure I answered the question. I'll try. The question was about getting new Ruby developers to contribute to open source stuff, essentially. So on the Rails team, we kind of have to deal with that. We get a lot of students every year. So, well, I think we have them all year, honestly. But we get a lot of students who are there. Some of them are new to programming. Many of them are not new to programming, but they're new to Ruby. And we have to get them working on Rails source code itself. One of the biggest challenges for that is you can't ask them to just go look through the bugs. That's impossible with a project like Rails, because it's so big or it's so popular that any bugs that are left over, I guarantee are hard. The reason they are still in the tracker is because they are hard. So it's difficult. You can't just point the students straight at that. So typically what we do is we come up with particular projects that we want, features we want them to add that we know that they can basically tailored for their particular skill level. So if they're super, if they're a really, really beginner, maybe we'll have them start refactoring tests or something like that. Just something that's very... It's still contributing, but not too deeply. Not deep into the APIs. And then if they're more advanced, they can put them further down. But some of the things we'll do is, since they're new projects, it'll be a little bit more... Well, I don't want to say greenfield, but less brown. And then of course we have to make sure that we don't ever put those projects in the bug tracker. But that's typically our process for onboarding new people with development on Rails. What about for GitHub? I'm sure you have a lot of new developers as well with a very old code base. Yeah, it's tricky. In terms of advice, I would say... The biggest advice I would give is don't give up. To you as a mentor and to the people that are trying to get caught up, it's not like I started programming and I was great all of a sudden. It took me a really long time to learn the basics and put all the building blocks together to a point now where I can jump into the VM and understand what's going on. It takes a lot of practice. I really like what Matt said about divide and conquer. I think that's really the only way to approach it is to find those small pieces, find those smaller projects, and start to put those building blocks together such that you can actually even approach. Because that's what it is when you're going after a large project like that. That mindset that you have to go into it with is understanding how do I break this up into maybe five tests or five different libraries or five different smaller pieces and then try to tackle them one by one. Because if you try to go at it all together and even try to fit the whole problem in your head, it's just impossible. There's too much to it to try to understand and grapple with. Thank you so much. Can we have the next question? Hi, I'm Peter. My question is for Matt. So considering all the progress that has happened on Jay Ruby and Rubinius, is there a future for MRI? And if so, what is that future? At least the MRI or CRuby will remain as the reference experimentation. And the original CRuby is optimized for the scripting. So for the memory footprint the startup time is much smaller than the same Jay Ruby. So I don't think we use the Jay Ruby for the tiny text processing but CRuby also serves that purpose. And then the new idea is come from the CRuby always just because I'm a C programmer but my core team is C programmer. So the CRuby will remain the breathing edge implementation of Ruby language. Thank you. We have a question on this side. Hi, I'm Joel. I'd like to pose this question to the entire team. So when in the design of Ruby language say someone comes up with a new language feature that would bring the language forward but at the same time could potentially break backwards compatibility what would the team tackle such a proposal? Right now we are basically rejecting any backwarding compatible changes just because we have the millions of Ruby users including us here in the auditorium and we have tens of millions of lines of Ruby code so we cannot break them. So we cannot introduce any backwarding compatible change the huge backwarding compatible change except for the big reasons. So maybe I will make some kind of decision to make a huge backwarding compatible change but in that sense we will see the situation like Python 3 and Python 2 or even Power 5 and Power 6. So that the situation I am not pleased to see so probably I am not going to make that kind of decision. Thank you very much. We have one more question here and then one on this side. This question is for the panel. With all the different versions of Ruby out there MRA, JRuby, and ARubyneas are there any plans to formalize some of the properties of the Ruby language and some kind of formal specification? Yeah. So as a standard the dual we have the ISO which is kind of subset of the Ruby language though and we are working on updating the ISO spec 3000, 301, 27 or something like that. And then that is the spec. The spec comes from ISO. It's nothing but spec. And then the standard defect we are working on the Ruby spec. So we are working on the Ruby spec. So we are working on the Ruby spec. We are working on the Ruby spec. And we are updating it as a standard the executable spec. So and we still have some problems in the corner cases in the spec but we are working on it. I hope that there is never a formalized spec because one of the things I really enjoy about Ruby programming language, the Ruby programming language is it seems or the culture is it seems like a very hacker centric culture. Like it's a programming language for hackers by hackers and I'm afraid that introducing some sort of formal like this is how you do it thing would ruin that feeling. So I agree. So the ISO only defined the core so not the corner cases. It also allows the enhancements for each implementation. Thank you. Hi, so maybe this time question for cometers except for Matt. Imagine that you live in a perfect world where you don't have to care about backwards compatibility. What Ruby features would you remove from the language? Two things I'm thinking of. The Polish variables, like a dollar or something and the second one is thread. What about the rest of you? The others? I like threads. I would add, so if there was something I could add, well I would remove the dollar variables for sure. I don't know, but what I would add is a good way to do immutable shareable data structures so that you could share among threads and not break stuff, hopefully. Yeah, I'm trying to think there's a lot of features that I don't use which maybe removing would make language simpler and the implementation simpler. There's the go-to equivalent, the catch-and-throw stuff. There's coroutines or something. There's fibers, but there's also the legacy. Call CC. Is that gone now? That's not in two. It's still live, so I would have to require the continuation. Yeah, continuation. Yeah, continuation. Yeah, I'd love to remove that. I don't know why people hate that operator so much. I like that operator. Sorry, I didn't have a mic. I was saying that I like the flip-flop operator. There's a lot of people that hate the flip-flop operator, but I like it. I don't know why people hate it so much. I don't know what it is. It's the two dots, and you have a conditional on either side of that. Maybe it's three dots, but you just do the two dots, and it flips back and forth.  Anyway. Don't remove that. Some improvements don't have the flip-flop. For example, and when we don't have. What about you, Shibata-san? I'd like to leave this all to you. We had a lot of problems. Yeah. I hope to minimize standard rivalries and reprise operational rivalries to newer and modern rivalries. For example, for Are they it's a big incompatible changes. His trouble. So we introduce, in Ruby 2.0, we introduce a bundle of gems, so that you can download it as a standard distribution, but it's implemented by gem, so you can replace it by a gem update. So we are making some old libraries, like net.telnet.http into gem and then making it a bundle of gems. So gradually we can remove it from the standard distribution, since they are all implementation-wise and spec-wise. Do we have more questions from Flo? I love this reaction. I have a question from Matt about typing in Ruby 3.0. So you say that adding type annotations in Ruby feels redundant, because it's not required. But in Common Lisp, Common Lisp has type annotations, but they are used, as you know, in the object system, to specialize methods in generic functions. So they are there, but they are used, and then they can be used for type checking or compiler optimizations. So I was wondering if you thought about that for maybe a future version of Ruby about introducing something like that, like generic functions, instead of the small talk-like object system. The idea of the generic function is considered before, and actually, I don't know, 18 years ago, 17 years ago, the guy named Guy Deku implemented the generic function, multiple dispatch in Ruby, and it's based on the class. And he didn't disclose the implementation, he just implemented by himself, and he just reported the result, and he reported it was failure. But then I didn't understand what he said, but thinking, yeah, and then he passed away a few years ago. And I'm thinking right now, the generic function dispatch is based on the class, which is totally against the dark typing. So I think that is the reason Guy considered it was failure. Well, from a user's perspective, it's different than leaving classes, right? Yeah, in multiple dispatch, you have to specify class to dispatch, but the dispatch-based class is against the dark typing. And what about the macro system? I recommended some kind of a transpiler. Okay. Thank you. This is a question, I guess, kind of to the panel. Ruby comes with mutable strings by default, and a lot of the new languages out there are just giving up on this concept and going with non-mutable strings by default, and you have to opt in. And is this something that could be considered removed from, let's say, for Ruby 3 in favour of performance, or is this one of those cases where elegance is always going to win? The compatibility wins, unfortunately. But we have some kind of optimization, say, that the string.freeze does not invoke the method, and then freeze in compile time. We may add some kind of prefix or suffix to say, this string is frozen and immutable. And the things would come in the future. Or maybe we have some kind of magic variable so that all the literals in this file is immutable or something like that. So we are thinking about those kind of ideas. But it's always in the explicit path of the transition. Otherwise we cannot do any progress for the sake of incompatibility. Any more questions from Floor? We have time for maybe one more question.  Don't be shy. We're all very nice. You don't see Max and Aaron and Shibara-san and Aman in town every day. Okay, if not, then I'll ask a question. Yeah, we'll ask a question. So as you can see, a lot of us over here are pretty shy. And at the same time, probably most of us are involved in building applications rather than going deep into Ruby itself. For people who really want to get into Ruby, into committing to Ruby and contributing to Ruby, what do you think is the best thing for them to do? So, you know, for the first step, so don't consider yourself, don't exclude yourself from the core community. So you are part of a team in a broader Ruby community, which is the bridge to the core community. So the problem you see is the problem for us and the problem we see is the problem for you guys. So you can do many things. So use Ruby and see the... You can think about how to improve the language or find out the complain about, okay, this is too slow or something like that. And then submit your proposal, complain to the bug truckers. Then we start discussing about the issue. So in that sense, we can move on, we can improve the language, so we can have the fresh aspect, fresh insight from the community. So that is the driving force of the core community, core developers. So consider yourself involved in the core developers. I would say if you run into things... So if you want to get involved, what you should do is, if you ever run into something, you don't understand why it's working or you just want to understand how something works, you should always be asking why it does that. So say, okay, why is this particular thing slow? Or why does it behave this way? And this probably won't sound very fun, but you should just keep researching it and don't give up until you understand exactly why it behaves that way. And once you do that, you're going to start finding yourself digging into, eventually digging deeper and deeper into the thing, trying to understand that particular thing that you're dealing with. And once you do that, maybe you'll discover why and then you'll fix it and send a patch. Or if you finally do understand why and there is a valid reason for it, you've gained some knowledge about the internals or the thing that you're trying to deal with. But the important thing is to be persistent about it, as Amon was saying earlier. Well, thank you so much. Do you have something to add? Yes. Contribution is not the only core language code. So we have our Ruby Rang website and API documentation. So you can contribute to translation to WW Ruby Rang. So, for example, for emoji guides, Junior Fatas, he leads to translate Chinese language from English on WW Ruby Rang. So I think East Asia have a lot of languages. So Thailand and Philippines and Japan, Chinese. But WW Ruby Rang main language is English. So that Roka Rang is not available on our website. So please contribute to translate your language from English. So we are welcome to contribute to our GitHub. WW Ruby Rang is available on GitHub. We accept your pro requests. Please. Amon, anything to add? I was just going to echo what Aaron and... There's a lot of different ways to contribute. You can contribute in terms of VM code, but there's also... We talked earlier about standard library. We're trying to clean up a lot of the code in there as legacy. It's very old. Going in there is helping split it out into gem or even just improving it, rewriting it to match style. Guys writing more tests for it. Doing documentation. Even the English documentation, a lot of it has typos or was written by non-native English speakers. So there's parts where it's hard to parse in. Someone can easily go in. A lot of times if you're reading documentation, you see something like that. Make it a point to go in and open a pull request and just rewrite those two words in that one sentence because it really pays it forward. The next time somebody is reading through that, it makes it that much easier for them to understand. But at the same time, if you are interested in getting into the deep VM level stuff, Ruby is a great way of doing that. I started as an application developer and I just had that itch. Like Aaron said, I was writing all this application code and I wanted to know what is it actually doing out of the hood. When I write this one line of Ruby that's so expressive, a lot of things are happening and there's n number of objects being created. How does objects actually exist? How does Ruby allocate them and get rid of them? You can dive into the implementation and there's a lot of good resources in terms of Ruby under the microscope and other books like that that really explain how the language is implemented. Even if you don't end up contributing at that level just knowing how that works really can inform how you write Ruby code because if you understand that, if you're writing a line of Ruby and there's a string on there that under the hood every time that a loop is being iterated over there's a new object being created over it because you didn't call freeze at the end, that really informs and makes you that much more aware of when you're writing Ruby code if whether or not it's going to be performed because you actually understand what it's doing under the hood, how is it being executed. That's a scratch that I've scratched a lot and I've written a lot of tools that I would encourage you to also check out. Sam up there has some tools as well, like profilers and debuggers and tracers and those really give you that level of insight where you have an application, all of us have big applications, you can attach these debuggers and stuff to it and start to understand when this request is being processed what's happening and that's really the best way to get in there and a lot of times you'll find random bugs and things that can be made easily better even a few months ago I attached a very simple C memory profiler and found that 20 megs of RAM was just being wasted because every time you require a file we would expand the filename and we were allocating a 4 kilobyte buffer for the filename even if the filename was 4 bytes there was a 4 kilobyte buffer and our app had thousands and thousands of requires added up to 20 megs, you know all I did was attach a memory profiler and just saw that's what was happening. So at this point I want to give a plug as well because even though I said the people here don't really contribute back to Ruby actually in the last year we have seen a very promising project coming out from Singapore itself it's called Ruby Bench which is working on profiling the various Ruby pull requests and making sure that they don't regress in terms of performance so it's actually done by Guo Xiang over there and he's probably going to talk about it more in his talk tomorrow I'm pretty bullish I hope we can see more people over here as well participating and contributing more to Ruby as well Next year it could be you I think that the folks here on stage have done so much hard work to make sure that we don't have to so let's give them a big thanks


Here's the best way to bleach your roots from an extremely dark color to nearly white which makes the perfect base for any color to absolutely pop on top. It's my newest and best method that works in literally one round with the least damage possible so I'm making this to update my last tutorial since this one is better and healthier for your natural texture or curl pattern. I call this the rubber band method which I created to solve my personal biggest problem with bleaching my curly hair at home and that was how long and tedious it is to part my hair into super thin sections while bleaching it to get everything even but quickly enough so the bleach doesn't over process. If you have super straight or easily combed hair thankfully you can skip this step but I promise you this made all the difference in mind being perfect in one round versus light enough after two rounds but more damaged. So to solve that problem I do all the parting first so I'm not racing and losing to the clock every time so I part my hair in half front to back and then create super thin long sections less than a centimeter wide and put a small rubber band elastic in the middle of that section to keep it together. I like to measure the length of my new growth and use that to figure out how much bleach I'll be needing because the most annoying thing is running out of bleach in the middle of doing your hair but the second most annoying thing is when you activate too much and end up wasting your products and your money so in this economy I would suggest measuring. Buying a scale is so worth it so you get the perfect ratio of ingredients for best results so I'm using my favorite bleach which lightens so well and also contains a bond builder and for the first time ever I'm using a 20 volume developer which is less strong than my usual 30 therefore less damaging but will it get me all the way to blonde in one round? Let's find out. Now I'm adding in part one of my favorite affordable bond builder to protect my hair as much as possible and mixing everything up and I have tried tons of bleaches and developers over the past decade but this specific schwarzkopf line is my absolute favorite and the ion bond builder is pretty much just affordable oleplex so for my length and type of hair in total I used 2.4 ounces of bleach 4.8 ounces of developer and a quarter ounce of the bond builder and everything I use in this video is linked and on my amazon storefront in the collection called Bleaching Your Roots. You can paint the bleach on your hair with a brush but I always use my fingers so I can actually feel what I'm doing much better and kind of massage the bleach in so I can make sure that every single strand is perfectly saturated and you do have to wear gloves while using bleach or it will melt your fingers off. Also try your best to get right up to that line of new growth without overlapping onto your already bleached hair. It's best to do your roots on a regular basis like every 6-8 weeks or when your hair is like an inch or shorter because your roots bleach faster and lighter than the hair that's farther away from your head due to heat from your scalp so this length of growth is my last chance to get it light enough with just 20 volume and before it would come out uneven or with banding and I am so bad at doing things consistently which is why I usually miss this sweet spot for doing my roots but for the sake of healthy hair it's definitely been worth it and my curl pattern has been absolutely thriving. You can do half of your head at a time if you're not able to get through everything quick enough before it starts developing for too long. Wash it then do the other side so it comes out evenly which I do have my roots get too long but I was able to do all this in just one round had my mans check the back for mistakes and while it processed I used the Joico Moisture Recovery Treatment Balm to deeply moisturize the rest of my hair. When I saw it had finished processing which is about 40 minutes later I rinsed out the bleach thoroughly with no shampoo yet. You have to put step two of the bond builder in for 10 minutes then you can shampoo, condition and dye on top of it. Here's how light it is after just one round which was the perfect base for the color I did on top which was a bright pink that I ombre faded into the red I already had and I also have a full tutorial showing how I did that already posted but hopefully this video was helpful for those of you who bleach or dye your hair and will help you keep your hair as healthy as possible.


Good afternoon, everyone. It's Melissa with thestockswish.com and welcome. Welcome to a Netflix preview. The earnings are out tonight. And, you know, this is just such a nice, beautiful chart. And really the stock's rallying today and actually got to the dream target since the day of the gap. I did say 350 and it's there today. I knew would make new highs and 350 was the first target after that and it's doing it and it's doing it. And now it has earnings out tonight. So really, I said earlier this morning when I saw this, of course it didn't look like this. 375, 400 for the stock to gap up to. But actually it's gonna go beyond that now. Just think where this is gonna go. And I think this could gap up to $500 tonight. And the chart's so bullish. And if it does that, it's probably gonna go red on the day and sure day tomorrow unless it holds, which, you know, it very well could do. This is gonna have a gap up tonight. It's not gonna gap down. And if it gaps down, it's gonna be a stinky gap down and I'm probably not gonna do it. I could be wrong, but I doubt it. I don't think this gaps down. And I don't think if it gaps down, it's gonna be a quality good gap that would rate over 20 points per my system. If it does gap down, I'll look at it. But I hardly doubt that's gonna happen. My earnings call, my preview call for Netflix is A, it gaps up. And B, now that it's hit over 350, I think it's gonna gap up to $500. That sounds insane, but I think it's actually gonna do that. There's so much power in this. So much power. And then having a conversation in the room today, someone said, you know what? They think it's overvalued. I understand where people are coming with this. They think, gosh, you know, what this company does, but the reality is it doesn't matter. Some things never overvalued or undervalued. It's valued exactly what it's worth. Right now, if people are willing to pay this for the stock, then that's what it's worth. It's just like saying, you don't wanna short something that's at $10. You think, God, a good company, a solid company, amazing company, the stock price, the strike price might be $10 a share. You think, God, this company's just totally undervalued. People were saying that about Groupon a year ago. And it was, when it gapped down, at one point it was at $6. I said, oh, this company is just undervalued or whatever. But it just kept going lower. So things are worth exactly what they're worth. And that's how you know how to trade them. It's actually the great thing because if there was hidden stuff to know, then it would be difficult to trade for a living. But because you can see exactly what the price is, you know exactly what people are willing to pay for it and that is exactly what it's worth. And something can keep going higher, just like something can keep going lower. But for a day trade to trade as a bullish gap tomorrow, if this gap's up to 500, I wouldn't do anything with it because you're not gonna fade something that is in a bullish up trend, that is just broke out to new highs. And you just can't short something like that. But it probably will go red on the day, into a day and then fall through later. But then again, it could hold on the day because if it gaps up and does basically a beautiful, beautiful bullish gap, which I think this is going to do, then it's higher in the chart. And as crazy as it sounds, things can keep going forever, you know? Any of the interaction. So whatever you think about Netflix, the company, whether you think it's overvalued or not, people are paying this much money for it and this chart is keep going higher. And when I actually did this here, when I made this call on Netflix back here in January, it was a great call. Actually, if this goes up to $500 today, that'll be in 10 months, then if anyone bought this bullish gap, which was a corrective gap, which was a gap that changed the chart in an immediate buy, would have gapped up here $100 back in January 24th and the earnings in first quarter. You know, profit would be on this today if it gaps up to $500. $350, in one share, if you just bought one share of it, just bought one share of that, it would have made $350. If it goes up to 500. And you never look back, you were never down. That's why understanding gaps is so crucial. It's so critical. I don't think people realize how important gap trading is to absolutely every type of trading, day trading, swing trading, court trading. Now, I day trade, I don't do anything else, but there is, without a shadow of a doubt, if I ever chose to swing or court trade, I do it just the same and just as well as I do my day trades. The fact is that you cannot take over nights unless you understand gaps. They can hurt you if you don't understand them or you miss taking good positions if you don't understand them or you take things off and something that's gonna work if you don't understand them. So you gotta know gaps for everything, everything that you do. My Netflix preview is that it gaps up to $500 since it booped over $350 today. Earlier I said $375, $400, but there's no way now. If the stock's gonna gap up, it's gonna gap up big time. And if it does, the market and everything else is gonna be pulled up and the market will gap up then tonight. So at this point right now, this is how I'm looking at Netflix now. The stock hasn't closed today, it's one o'clock. It's got three more hours left, but I don't think it matters now at this point. It's gonna hold looking like this today. Beautiful fall through in Netflix. Amazing pattern, just fantastic. Set everything right and more. So we'll see what it does. This could very well gap down and then I'll look at it to short tomorrow, but I don't think so. And instead I think it's gonna gap up big time now that it's rallied over $350 here into a lunchtime play. I mean, look at this actually. Really nice, really nice move up in here. Woop, loop-de-loop. Actually even here, this is a better entry in here, right over $345, right up to the number. Actually it's gotten up to 350 to 63, look at this thing. So this is Melissa with the stockswish.com with the Netflix preview earnings are tonight. My call is the Netflix gaps up. Number one, where it goes, I don't know exactly, but at this point now, since the stocks rallied so well today, it's gotten a lift. It's gotten to the dream target that I set back in January of this year, over 350 today, just the afternoon before earnings. The stocks most likely gonna gap up tonight to $500 or some thereabouts. And that's the scoop. So if you'd like more information on how to learn, how to read gaps and trade gaps and play gaps and understand gaps, I'm doing a gap class this weekend, October 26th and 27th. If you'd like more information, email me at Melissa at the stockswish.com. Thanks everyone, have a great day.