RailsClub'Moscow 2014: Interview with Ravil Bayramgalin


    At the end of this week, the RailsClub conference will be held . Our guests pack their bags (here Aaron Patterson tweeted that he was going to Russia). And we look forward to meeting you!

    We asked a couple of questions about life and programming for the developer at Evil Martians , the lead developer of Oh My Stats, Ravil Bayramgalin . Ravil is a contributor of 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 now?

    From interesting things I’m working on a prototype queuing system with a specific set of pros and cons, the rest is a secret: D

    What is the best and worst part of your work?

    The best part is analysis and reflection. What - architecture, API, code organization, optimizations or bugs - doesn’t matter. The worst part is when you come across simple template tasks, but voluminous in time costs.

    What do you consider to be your main achievement in life / career at the moment?

    An opportunity to hug Aaron Paterson in the near future. An unintentional github dDoS during the ramble 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 the ruby.

    The next direction in which new big changes will follow is competition. As everyone already knows, Matz wrote a few months ago that he wants to add a new abstraction to the language of competition and remove the 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 kinds of primitives and abstractions for competition (including more exotic ones, for example, software transactional memory and dataflow )).

    But the decision to remove GIL indicates the seriousness of the changes, and not just copying some kind of library into the ruby ​​kernel. And this is not about the smaller locks that Matz rejected for a long time. Judging by the latest presentations by Koichi Sasada (ko1, one of the three members of the Matza team), we are waiting for 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 the shared memory will probably be with some kind of protective mechanism, so that the actors do not get ordinary threads with an additional communication mode. But I’m 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 raising errors 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 easy way .

    It does not matter which method will be chosen in the end, the main thing is that the dialogue in the field of competition has begun, and previous discussions (for example, with refinances) show that Matz is ready for a constructive dialogue (I hope that a formalized memory model is pushed through).

    Do not be afraid or hope for radical solutions. The decisions made by Matz are evolutionary enough so that the entire community moves forward and does not fragment by version due to the difficulties of transition.

    Therefore, in the field of large changes in the language, probably this is all for the near future. It is necessary to give time so that the society not only supports Ruby 2.x, but also a consensus is formed on the use of new functionality, for example, keywords, prepend, refinements. Therefore, the news that only 5 2.2 rubles will be supported in 5 rails is good.

    I won’t guess what will be among the minor changes, fortunately, in each release there are enough such changes generated as a result of feedback from the community. The main thing is that the gradual modernization of stdlib is underway.

    But in the area of ​​development of MRI itself and additional tools for analyzing runtime, everything will continue to be better with each version.
    Now tracing and monitoring the execution of methods and allocations of objects in rubles is easier than ever with the stackprof gem (author - github engineer and ruby ​​contributor Aman Gupta), there is only a web interface missing for easier interactive analysis of profile dumps.

    Most likely, the JIT compiler for MRI from Koichi expects us from the future, although Matz does not exclude AOT.

    Despite this good news, I connect 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 significantly lucky that the talented guys from the Oracle Labs VM Research department decided to test their theoretical achievements in the field of developing and optimizing VMs for rubies. I recommend that you follow the Chris Seaton blog, which explains how they speed up Rub by an order of magnitude. Another difference from regular jruby is the support of C-extensions without speed degradation. Hope to see the public release in 2015. There are plans for a slightly more distant future to achieve startup time like at MRI (which, as demonstrated by the prototype of functionality, is achievable).

    About the rails.

    From the 5th rails, which will be this spring, I expect, mainly, 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.

    I hope that under the leadership of Aaron Paterson rack 2.0 will be brought to mind. Maintaining streaming without crutches is the simplest statement of the problem. At the end of the year, a stable specification of HTTP 2.0 will be released, and request-response format even with streaming is not enough. Native support for HTTP semantics, as webmachine and http-2 gems are trying to do, simplifies the solution of various specific tasks, but complicates the general IPA - the difficulty, as usual, is in finding a compromise.

    In parallel with the rails, the related infrastructure will continue to develop. On the basis of the docker, there will be development tools that, 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 completely transparent: I went to the project folder, wrote setup and all the necessary services have risen, and the ruby, bundle, rails and other binaries 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 deployment area, switching to docker can also bring a lot of benefits, but for this you need a higher-level tool on top of it, which will be responsible for deploying, proxing for switching and rolling back without downtime, collecting logs,

    The formation of new conventions for rail applications is far from complete, the general ideas are clear, but there is no generally accepted consensus on the details. More comprehensive approaches, such as the trailblazer gem, are more likely to spread, as many conventions work best in conjunction. 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 an overhead of full-fledged services or in situations where ordinary engines are considered as overkill.

    Perhaps in the future, abstractions will be added over the streaming to the rails for building a data flow with the client (while experiments with reactive communication between the server and the client are quite widespread, even if you look only within the framework of the ruby ​​community, then voltrb became popular quite quickly, although it is located on very early stage of development).

    This is the first thing that came to mind. If you think about it, there are a lot of interesting directions and developments and you can talk about them for a long time, I will be glad 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 developer community faces now?

    In my opinion, this is a blur of the open source culture. It is important to remember that the ecosystem is formed by the hands of the community and everyone’s duty is to develop it. Many people simply work and try to get around ecosystem and open source issues (sometimes with caustic criticism), instead of participating in their solution.

    I don’t know how to solve this. It would seem that hacking and so is conducive to making it easy to research runtime and solve problems, but it means you need tools to make it even easier. It would be nice, albeit unrealizable, if on _why day there was a tradition at the level of work etiquette, so that instead of work, every Ruby programmer could spend time and try to figure out the problem that he had to face. With the presence of mentors within the company or on the irc-channel. And then ubiquitous publications on the topic of what they did to further spread the spirit. It would seem that one day in a year, but in order to start more, it is not necessary, and often this is the most difficult.

    Is there a gem that you could point your finger at and say, “That's how you need to write code”?

    The gem is the result of teamwork, and the code with a certain handwriting is a reflection of the individual's style, so I will simply list the github nicknames of several of those that come to mind: evanphx , eregon , banister , dkubb , ConradIrwin , amatsuda , mbj , solnic , jeremyevans .

    You are contributing a lot to open source. Why are you doing this and why should others do it?

    I do this when I run into problems and have free time. In Martians, working with open source code is almost mandatory, so in addition to the opportunity to justify the waste of working time on open source, there are periodic material contests and bonuses.

    In general, I recommend the rest, since with small steps the whole community moves forward, plus you will have to understand the problems well, that is, pump your skill.

    What do you read about Ruby / RoR? Blog, resource, book?

    Various blogs, twitter, mailing lists, mailing lists that have accumulated in large numbers over a long time.

    Shame on the code you wrote a few years ago?

    It doesn’t happen - if I’d write it differently now, it means there is new information in my mind, but it’s impossible to know everything, therefore it’s not worth to be ashamed of ignorance, the main thing is to put your soul into it :)

    What do you like to do besides programming?

    Read about current economic reforms and criticize the current government: D

    Thank you 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

    Undev.ru - 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, such large projects as Web Elections 2012, SPIEF, broadcasting of the Vancouver and London Olympiads, and several more projects of a similar scale were made. Evrone is a development team on RoR, Clojure and Scala. Community enthusiasts and permanent organizers of RailsClub. Stay up to date with our newsletter by signing up for the newsletter on railsclub.ru and stay tuned: RailsClub.ru


    Also popular now: