RailsClub'Moscow 2014: Interview with Ravil Bayramgalin
Hello!
Already at the end of this week there will be a RailsClub conference. Our guests are packing their bags (and Aaron Patterson tweeted that he was going to Russia). And we look forward to meeting you!
We asked a couple of questions about the life and programming of Evil Martians , the lead developer of Oh My Stats, Ravil Bayramgalin . Ravil is a contributor to more than 40 open source projects, including Ruby on Rails, rack, cassandra-rb, sidekiq and others. It turned out interesting!
')
What are you working on right now?
Of the interesting work on the prototype of the queue system with a specific set of pros and cons, the rest is a secret: D
What is the best and worst part of your job?
The best part is analysis and reflection. What it is about - architecture, API, code organization, optimizations or bugs - doesn't matter. The worst part is when simple routine tasks come across, but they are voluminous in time.
What do you consider your main achievement in life / career at the moment?
Opportunity to hug Aaron Paterson in the near future. Unintentional dithos githaba during rambl rail after launching our crawler on several hundred heroku servers was also a memorable event;)
In your opinion, in what direction will Ruby and Ruby on Rails develop in the coming years?
I'll start with ruby.
The closest direction in which the new big changes will follow is to compete. As everyone already knows, Matz wrote several months ago that he wanted to add a new abstraction to the language to compete and remove GIL.
In the community, ideas on the first topic have been quite successfully investigated for a long time (as a result, we have a concurrent-ruby gem with a very strong development team that provides all sorts of primitives and abstractions for competing (including more exotic ones, for example, software transactional memory and dataflow )).
But the decision to remove GIL indicates the seriousness of the changes, rather than simply copying some library into the Ruby core. And this is not about smaller locks that Mats has rejected for a long time. Judging by the latest presentations of Koichi Sasada (ko1, one of the three members of the Matza team), we are awaiting a model with separate memory and a limited region of shared memory. Separate memory will be presented, most likely, with the help of actors. Access to shared memory will apparently be with some kind of defense mechanism, so that the actors do not get the usual threads with an additional mode of communication. But I am not sure that such a compromise will work in practice.
A proposal from Tony Arcieri (best known for celluloid): the ability to bind related objects to a specific thread (with automatic error raising when accessing from other threads) would allow current implementations of actors and channels to solve the problem of isolating data between threads in a very efficient and simple way .
It doesn't matter what method will be chosen in the end, the main thing is that the beginning of the dialogue in the field of competition is set, and the previous discussions (for example, with refinments) show that Matz is ready for a constructive dialogue (I hope that the formalized model of memory will be pushed).
Do not be afraid or hope for radical solutions. Matz’s decisions are evolutionary enough that the entire community moves forward and does not fragment by versions due to the difficulties of the transition.
Therefore, in the area of ​​major changes in the language, this is probably all in the near future. It is necessary to give time for the society not only to support Ruby 2.x, but also to form a consensus on the use of the new functionality, for example, keywords, prepend, refinements. Therefore, the news that in the 5 rails will support only Ruby 2.2+ pleases.
What will be among the minor changes, I won’t be guessing, good, in each release of such changes, formed as a result of feedback from the community, is enough. The main thing is that the gradual modernization of the system is underway.
But in the field of development of the MRI itself and additional funds for the analysis of runtime, everything will continue to get better with each version.
Now tracing and monitoring the execution of methods and allocations of objects in Ruby is easier than ever with the help of the stackprof heme (the author is a github engineer and rubi contributor Aman Gupta); all that is needed is a web-based interface for a simpler interactive analysis of profile dumps.
From the future we are expected, most likely, by the JIT compiler for MRI from Koichi, although Mats does not exclude AOT.
Despite this good news, I associate the future development of Ruby with jruby. But not just jruby, but on top of truffle (in combination with graal and substrate VM). Our community was greatly fortunate that the talented guys from the Oracle Labs VM Research department decided to run their theoretical developments in the development and optimization of VM on Ruby. I recommend to follow the blog Chris Seaton, which explains how they speed up Ruby by an order of magnitude. Another difference from the usual jruby is to support C-extensions without speed degradation. Hope to see the public release in 2015. Plans for a slightly more distant future to achieve a start-up time like that of an MRI (which, as the functionality prototype demonstrates, is achievable).
About rails.
From the 5th rails, which will be this spring, I expect, basically, a superficial update of the API, associated with the already mentioned cessation of support for previous versions of Ruby. More characters, simpler logic with prepend, cleaner methods with keyword arguments and the like.
Hopefully, under the guidance of Aaron Paterson rack 2.0 will be brought to mind. Keeping streaming without crutches is the simplest task setting. At the end of the year there will be a stable specification for HTTP 2.0 and the request-response format, even with streaming, is not enough. Native support for HTTP semantics, as they try to make webmachine and http-2 gems, simplifies the solution of various specific tasks, but complicates the overall API - the complexity, as usual, in the search for a compromise.
In parallel with the rails, the related infrastructure will continue to develop. On the basis of the docker, there will appear development tools, which, on the one hand, fully provide all the necessary services and libraries for the application (including the Ruby version), while, on the other hand, working with them will be absolutely transparent: I went to the project folder, wrote setup and you have all the necessary services up, and the ruby ​​binaries, bundle, rails and the rest are proxied to the running image. The developer's system is always clean, the project is always ready to run on any system, and there is no difference between the development. In the area of ​​deployment, switching to a docker can also bring many benefits, but this requires a higher-level tool on top of it, which will be responsible for deployment, proxying for switching and rollback without downtime, collecting logs, monitoring crown, and the like.
The formation of new conventions for rail applications is far from complete, general ideas are understandable, but there is no generally accepted consensus on details. More comprehensive approaches, such as the trailblazer gem, are more likely to be spread, since many conventions work best in a bundle. In the same gem, there is an idea of ​​concepts that can take root in a community in which they want to achieve greater modularity, but are not always ready for the overhead of full-fledged services or in situations where ordinary endjains are viewed as overkills.
Perhaps in the future, over the streaming, they will add abstractions to the rails to build dataflow with the client (while experiments with reactive communication between the server and the client are of rather wide interest, even if you only look within the ruby ​​community, then voltrb became popular quite quickly, although it is on very early development).
This is the first thing that came to mind. If you think that there are a lot of interesting directions and developments and you can talk about them for a long time, I will be happy to talk on the railclub with those who wish :)
What, in your opinion, is the most important problem that the Ruby and Ruby on Rails developers community is facing now?
In my opinion, this blur of open source culture. It is important to remember that the ecosystem is formed by the hands of the community and the duty of each to develop it. Many people simply work and try to circumvent the problems of the ecosystem and open source (sometimes with harsh criticism), instead of participating in their solution.
How to solve it - I do not know. It would seem that Ruby is so inclined to make it easy to investigate runtime and solve problems, but it means that you need tools to make it even easier. It would be wonderful, though unrealizable, if on _why a day there was a tradition at the level of working etiquette, so that instead of working each Ruby programmer could spend time and try to sort out the problem he had to face. With the presence of mentors within the company or on the irc-channel. And then ubiquitous publications on what they did to further spread the spirit. It would seem that one day a year, but in order to start more and not need, while this is often the most difficult.
Is there a heme you could point your finger at and say: “That's the way to write code”?
Heme is the result of collective work, and the code with a certain handwriting is a reflection of the individual's style, so I will simply list the githukhs of several of those that come to mind: evanphx , eregon , banister , dkubb , ConradIrwin , amatsuda , mbj , solnic , jeremyevans .
You contribute a lot in open source. Why do you do it and why would it be worth doing to others?
I do this when I run into problems and have free time. In the Martians work with open source is almost mandatory, so in addition to the possibility of justifying the waste of working time for open source, there are periodic material contests and bonuses.
In general, I recommend the rest, as the whole community moves forward in small steps, plus you have to understand the problems well, that is, to pump your skill.
What do you read about Ruby / RoR? Blog, resource, book?
Various blogs, twitter, mailing lists, maillist that have accumulated in large numbers over a long time.
Is it embarrassing for the code that you wrote a few years ago?
It does not happen - if now I would have written differently, then this means the availability of new information in my mind, but it is impossible to know everything, therefore you should not be ashamed of ignorance, the main thing is to invest your soul :)
What do you like to do besides programming?
Read about modern economic reforms and criticize the current government: D
Thanks for the interview!
At the conference, Ravil will talk about Big Data: September 27, at the Digital October center. The entire program is on the RailsClub 2014 website .
Registration and payment of participation - here.
There are very few tickets left!
Our sponsors:
General sponsor - Toptal
Gold Sponsors: Boookmate and FunBox
Silver Sponsors: AT-Consulting and Lookatme
HR partner: DigitalHR
Organizers:
Undev.ru is a strong development team for Ruby, Objective C, C ++, C #, JavaScript. They are working on the creation of a unique technological platform for television broadcasting via the Internet. On the basis of this platform were made such major projects as Web elections 2012, SPIEF, broadcast Vancouver and London Olympiads, and several more projects of a similar scale.
Evrone is a development team for RoR, Clojure and Scala. Enthusiasts community and permanent organizers RailsClub.
Stay up to date with our news by subscribing to the newsletter on the website railsclub.ru, and stay tuned for updates:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
Already at the end of this week there will be a RailsClub conference. Our guests are packing their bags (and Aaron Patterson tweeted that he was going to Russia). And we look forward to meeting you!
We asked a couple of questions about the life and programming of Evil Martians , the lead developer of Oh My Stats, Ravil Bayramgalin . Ravil is a contributor to more than 40 open source projects, including Ruby on Rails, rack, cassandra-rb, sidekiq and others. It turned out interesting!
')
What are you working on right now?
Of the interesting work on the prototype of the queue system with a specific set of pros and cons, the rest is a secret: D
What is the best and worst part of your job?
The best part is analysis and reflection. What it is about - architecture, API, code organization, optimizations or bugs - doesn't matter. The worst part is when simple routine tasks come across, but they are voluminous in time.
What do you consider your main achievement in life / career at the moment?
Opportunity to hug Aaron Paterson in the near future. Unintentional dithos githaba during rambl rail after launching our crawler on several hundred heroku servers was also a memorable event;)
In your opinion, in what direction will Ruby and Ruby on Rails develop in the coming years?
I'll start with ruby.
The closest direction in which the new big changes will follow is to compete. As everyone already knows, Matz wrote several months ago that he wanted to add a new abstraction to the language to compete and remove GIL.
In the community, ideas on the first topic have been quite successfully investigated for a long time (as a result, we have a concurrent-ruby gem with a very strong development team that provides all sorts of primitives and abstractions for competing (including more exotic ones, for example, software transactional memory and dataflow )).
But the decision to remove GIL indicates the seriousness of the changes, rather than simply copying some library into the Ruby core. And this is not about smaller locks that Mats has rejected for a long time. Judging by the latest presentations of Koichi Sasada (ko1, one of the three members of the Matza team), we are awaiting a model with separate memory and a limited region of shared memory. Separate memory will be presented, most likely, with the help of actors. Access to shared memory will apparently be with some kind of defense mechanism, so that the actors do not get the usual threads with an additional mode of communication. But I am not sure that such a compromise will work in practice.
A proposal from Tony Arcieri (best known for celluloid): the ability to bind related objects to a specific thread (with automatic error raising when accessing from other threads) would allow current implementations of actors and channels to solve the problem of isolating data between threads in a very efficient and simple way .
It doesn't matter what method will be chosen in the end, the main thing is that the beginning of the dialogue in the field of competition is set, and the previous discussions (for example, with refinments) show that Matz is ready for a constructive dialogue (I hope that the formalized model of memory will be pushed).
Do not be afraid or hope for radical solutions. Matz’s decisions are evolutionary enough that the entire community moves forward and does not fragment by versions due to the difficulties of the transition.
Therefore, in the area of ​​major changes in the language, this is probably all in the near future. It is necessary to give time for the society not only to support Ruby 2.x, but also to form a consensus on the use of the new functionality, for example, keywords, prepend, refinements. Therefore, the news that in the 5 rails will support only Ruby 2.2+ pleases.
What will be among the minor changes, I won’t be guessing, good, in each release of such changes, formed as a result of feedback from the community, is enough. The main thing is that the gradual modernization of the system is underway.
But in the field of development of the MRI itself and additional funds for the analysis of runtime, everything will continue to get better with each version.
Now tracing and monitoring the execution of methods and allocations of objects in Ruby is easier than ever with the help of the stackprof heme (the author is a github engineer and rubi contributor Aman Gupta); all that is needed is a web-based interface for a simpler interactive analysis of profile dumps.
From the future we are expected, most likely, by the JIT compiler for MRI from Koichi, although Mats does not exclude AOT.
Despite this good news, I associate the future development of Ruby with jruby. But not just jruby, but on top of truffle (in combination with graal and substrate VM). Our community was greatly fortunate that the talented guys from the Oracle Labs VM Research department decided to run their theoretical developments in the development and optimization of VM on Ruby. I recommend to follow the blog Chris Seaton, which explains how they speed up Ruby by an order of magnitude. Another difference from the usual jruby is to support C-extensions without speed degradation. Hope to see the public release in 2015. Plans for a slightly more distant future to achieve a start-up time like that of an MRI (which, as the functionality prototype demonstrates, is achievable).
About rails.
From the 5th rails, which will be this spring, I expect, basically, a superficial update of the API, associated with the already mentioned cessation of support for previous versions of Ruby. More characters, simpler logic with prepend, cleaner methods with keyword arguments and the like.
Hopefully, under the guidance of Aaron Paterson rack 2.0 will be brought to mind. Keeping streaming without crutches is the simplest task setting. At the end of the year there will be a stable specification for HTTP 2.0 and the request-response format, even with streaming, is not enough. Native support for HTTP semantics, as they try to make webmachine and http-2 gems, simplifies the solution of various specific tasks, but complicates the overall API - the complexity, as usual, in the search for a compromise.
In parallel with the rails, the related infrastructure will continue to develop. On the basis of the docker, there will appear development tools, which, on the one hand, fully provide all the necessary services and libraries for the application (including the Ruby version), while, on the other hand, working with them will be absolutely transparent: I went to the project folder, wrote setup and you have all the necessary services up, and the ruby ​​binaries, bundle, rails and the rest are proxied to the running image. The developer's system is always clean, the project is always ready to run on any system, and there is no difference between the development. In the area of ​​deployment, switching to a docker can also bring many benefits, but this requires a higher-level tool on top of it, which will be responsible for deployment, proxying for switching and rollback without downtime, collecting logs, monitoring crown, and the like.
The formation of new conventions for rail applications is far from complete, general ideas are understandable, but there is no generally accepted consensus on details. More comprehensive approaches, such as the trailblazer gem, are more likely to be spread, since many conventions work best in a bundle. In the same gem, there is an idea of ​​concepts that can take root in a community in which they want to achieve greater modularity, but are not always ready for the overhead of full-fledged services or in situations where ordinary endjains are viewed as overkills.
Perhaps in the future, over the streaming, they will add abstractions to the rails to build dataflow with the client (while experiments with reactive communication between the server and the client are of rather wide interest, even if you only look within the ruby ​​community, then voltrb became popular quite quickly, although it is on very early development).
This is the first thing that came to mind. If you think that there are a lot of interesting directions and developments and you can talk about them for a long time, I will be happy to talk on the railclub with those who wish :)
What, in your opinion, is the most important problem that the Ruby and Ruby on Rails developers community is facing now?
In my opinion, this blur of open source culture. It is important to remember that the ecosystem is formed by the hands of the community and the duty of each to develop it. Many people simply work and try to circumvent the problems of the ecosystem and open source (sometimes with harsh criticism), instead of participating in their solution.
How to solve it - I do not know. It would seem that Ruby is so inclined to make it easy to investigate runtime and solve problems, but it means that you need tools to make it even easier. It would be wonderful, though unrealizable, if on _why a day there was a tradition at the level of working etiquette, so that instead of working each Ruby programmer could spend time and try to sort out the problem he had to face. With the presence of mentors within the company or on the irc-channel. And then ubiquitous publications on what they did to further spread the spirit. It would seem that one day a year, but in order to start more and not need, while this is often the most difficult.
Is there a heme you could point your finger at and say: “That's the way to write code”?
Heme is the result of collective work, and the code with a certain handwriting is a reflection of the individual's style, so I will simply list the githukhs of several of those that come to mind: evanphx , eregon , banister , dkubb , ConradIrwin , amatsuda , mbj , solnic , jeremyevans .
You contribute a lot in open source. Why do you do it and why would it be worth doing to others?
I do this when I run into problems and have free time. In the Martians work with open source is almost mandatory, so in addition to the possibility of justifying the waste of working time for open source, there are periodic material contests and bonuses.
In general, I recommend the rest, as the whole community moves forward in small steps, plus you have to understand the problems well, that is, to pump your skill.
What do you read about Ruby / RoR? Blog, resource, book?
Various blogs, twitter, mailing lists, maillist that have accumulated in large numbers over a long time.
Is it embarrassing for the code that you wrote a few years ago?
It does not happen - if now I would have written differently, then this means the availability of new information in my mind, but it is impossible to know everything, therefore you should not be ashamed of ignorance, the main thing is to invest your soul :)
What do you like to do besides programming?
Read about modern economic reforms and criticize the current government: D
Thanks for the interview!
At the conference, Ravil will talk about Big Data: September 27, at the Digital October center. The entire program is on the RailsClub 2014 website .
Registration and payment of participation - here.
There are very few tickets left!
Our sponsors:
General sponsor - Toptal
Gold Sponsors: Boookmate and FunBox
Silver Sponsors: AT-Consulting and Lookatme
HR partner: DigitalHR
Organizers:
Undev.ru is a strong development team for Ruby, Objective C, C ++, C #, JavaScript. They are working on the creation of a unique technological platform for television broadcasting via the Internet. On the basis of this platform were made such major projects as Web elections 2012, SPIEF, broadcast Vancouver and London Olympiads, and several more projects of a similar scale.
Evrone is a development team for RoR, Clojure and Scala. Enthusiasts community and permanent organizers RailsClub.
Stay up to date with our news by subscribing to the newsletter on the website railsclub.ru, and stay tuned for updates:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
Source: https://habr.com/ru/post/237617/
All Articles