September 15, 2016 at 17:32RailsClub 2016: Interview with Alexei Taktarov
Hello! Before RailsClub 2016 just over a month. It's time to register!
We have already said that this year Yukihiro Matsumoto, Akira Matsuda, Sean Griffin, Steve Klabnik and Zach Briggs will come to us. And today we are starting to publish traditional interviews with our speakers. This year, the RubyNoName podcast helps us make the conversation with speakers interesting .
The guys recorded the first conversation with Alexei Taktarov, a front-end (!) developer from These Guys. Alexey specializes in the development of single-page applications, promotes the purity and simplicity of design and code. He participated in Smartato projects, ficus.io and resume.io, worked with Evil Martians; its main tools are Ember.js, React and Ruby on Rails. In his spare time, he is engaged in the southern near-front hangout with Code Hipsters.
This is the first time we have put a report about the front in the backend conference program. Nowhere without him in 2016 :). Leschin's report is called “ Give the frontend in Rails a second chance! ”.
What will be discussed:
In the front-end community in recent years, not boring! It’s difficult to say whether this is fatigue or enlightenment from JavaScript, one thing is clear - front-end development rushes ahead of the rest with the speed of a supersonic locomotive. At the same time, business and projects live a normal life. Rails frontend development approaches are hopelessly outdated: Asset building through Sprockets is a long, uncomfortable, inflexible process.
In his report, Alexey will briefly touch upon the current state of the frontend and talk about the urgent problems of assembling assets in Rails. He will conduct an excursion into the modern assembly systems Webpack, Gulp, Brunch and Rollup and show how they can be integrated into the Rails ecosystem using real projects as examples.
Audio can be heard on the podcast site , but here we share the transcript.
Today we realized that your report is the first front-end report on RailsClub. And it’s very cool! I was afraid to ask you questions about Ruby, the front-end, but it turned out that you understand and understand him. Tell me how it happened? How did you come to Ruby?
My history of exploring these technologies is quite atypical. I started my career as a person who makes system tools. I didn’t meet with the front-end either, I just worked on native interfaces for Windows. I spent some time on making programs that work with a large number of threads, which work with concurrency, and so on. And then somehow smoothly moved to the front end, then just a hype appeared. I started working with Ruby and rails after that, and for me it was a little revelation, because not all the things that work there work as I used to. Best example: in some environments where you should always keep an eye on resources, if you took something in one thread and work, you should be sure that there will be no problems with that in another thread - in ruby all these problems were bypassed. I came across completely different concepts. And that was cool!
Specifically, I came to the project as a front-end, doing only the front-end tasks. And then we didn’t have a back-end :) He left, there was nobody to solve his tasks, and I decided to try. It was unusual: there was no one to discuss with, the person who helped me was a sort of sage. I came to him once a week, he spoke some magic words about what should I do. Then I left, sighed, thought: “Oh my God, what's going on.”
After some time, I kind of managed to comprehend this wisdom, although probably not all. The part that is in the framework and language, I felt this taste.
Where and what are you doing now?
From personal - getting ready for the wedding. I’m working on my project, which is still too raw to talk about. I also work with a partner in a team calledThese Guys . We specialize in the rapid development of MVP. I try to make the most of the experience that I got while working with the Evil Martians, and with other teams. But now I focus more now not on solving technical problems, but on solving business problems, I am thinking over how to optimally build everything for the client.
So you opened your company now?
Yes. Although now I’m very scared to say this out loud, for some reason :)
What do you dislike about the current implementation of rails from the point of view of the front end?
It seems to me that this situation happened: two or three years ago, the frontend jumped sharply and rushed forward at the speed of a locomotive, sweeping everything in its path. The guys from other communities looked at this, someone was skeptical, someone inspired. But I must admit that he rode away very far. In this regard, the world of rail remained unchanged.
It is believed that the rail should cease to be a tool that has both a front and a back, focus only on the back. Because the front end part in the rail itself is clearly not in time now. We have to use rails as a server part, and the front one is separate, there are separate tools, a separate team, a separate story. What is your position on this?
I always try to look wider. When I see a hype around the front end, I always try to find both good and bad sides. It’s good that everything develops and moves, a lot of ideas, a lot of things can be done that will help the next generation of developers. But you need to look at it with caution, look at whether everything is really as it seems? This also applies to companies: which stack they choose, how they communicate with their developers. For example, the developers took some popular stack now, and then everything fell apart. The company stopped working because the technology was raw. Have you had this?
I try to stick to the middle ground. Recently I read an article by Ravil Bayramgalin from the Martians about the new renderer. It’s interesting not even the implementation itself, but what comes at the beginning of the article: DHH does not have much time to devote to its development, but it writes down and talks about many ideas that other developers can pick up to successfully develop the framework. I think it's great. Cool when there is a vision, when DHH understands where to go. There may be disagreements, somewhere it will not be the right way. But I like it when I have an understanding of the overall mission. In rails there is such a vision, you need to survive the hype and move on. I think we will succeed, my position is quite positive :)
If we talk about hype in the front. What is hype now, and what can you really use? What do you think should be paid attention to? And what will be interesting next?
Some time ago, my friends and I organized a small party in Rostov called Code Hipsters . This is mainly a news feed in VKontakte and in a Telegram, we write about all kinds of fashionable things in the front-end (we are trying to beat this in the title). Now I am a little retired, everything is done by my friend Vitya. He has a wonderful style, I really like the way he writes. Sometimes we get together and understand that we have not read anything new over the past week :) Apparently, we are a little tired.
The last thing I heard about is Rollup . In my opinion, there is nothing revolutionary, but it's interesting to see. The movement towards smart bundlers, the correct assembly of dependencies, I think is very important, this is a good direction. Although it cannot be said that this is rocket science.
Secondly, the component approach. He came a long time ago, everyone accepted him, and that's great.
Thirdly, FRP. There is a big gap between theory and practice on this issue. Surely something will appear to overcome it.
Returning to the question of rail as a framework and to the front. What would you add to a rail or remove from it, from the point of view of front-end development? Maybe he would have removed the front from the rails?
I would not clean the front. It seems to me that the solution that is now will allow us to survive in 80% of projects, at least those that are on the market. It’s very convenient for Ingoda to have such functionality.
Even when we are talking about assembling files, which is not really an assembly, but simply concatenation in the correct order. I think this is bad.
I heard that they do not like turbolinks, although I am quite normal towards them, I use them in some projects.
Yes, sometimes you have to spend a lot of time figuring out how to do it right. But it accustoms to order. It was easier for me: I did not write scripts, I immediately started writing single page applications. I had to think about how to allocate resources, how to extinguish them correctly, about services, about the application’s life cycle, about how it can work for a long time. When you make a simple multi-page website interspersed with scripts, you don’t think about it.
But sometimes a project requires that all this be taken into account, it makes you keep in mind the patterns that the correct frontend taught us.
I don’t know what I would add directly to the rails. There is a tendency to throw away all unnecessary, to facilitate, to leave rails only for API. Right?
There is a separate branch related specifically to Rails API development, disabling unnecessary things.
Yes, this also applies to assembly. If you are launching a rail project, it would probably be great to be able to somehow control the processes that are starting. Now it is not just a rails server, or some Sidekiq. It would be cool to be able to monitor the processes that run for the assembly, which Node.js processes are running. It would be cool to come up with something like that. Although here you can, in principle, offer solutions like Foreman or Hivemind.
Since we started talking about tools: what are you watching now? What projects do you like, which ones are worth paying attention to?
In some cases I use Webpack , it suits me perfectly. I understand all the humor behind the fact that he has a complicated configuration. It seems to me the main concept that the modules are cool. I used the Brunch builder for a long time . He was always bypassed, he remained in the shade. But for me it is an ideal tool when you need to throw something very quickly, when you just need modules in the common js style, when you need a very fast build. Because it really works very fast. It struck me that many of the guys who make the frameworks start sculpting boilerplate and command line tools like Ember CLI, or a thing for React that has appeared recently. In the case of Ember, it struck me that you are very rigidly attached to the collector, you cannot choose a collector other than Broccoli (which I could not configure at that time, and it collected everything for a very long time). At least on my machine, it worked forever.
I had experience working with Ember, we fully assembled our project on Brunch. Even considering the fact that I had to port a lot for myself, because the whole community switched to Ember CLI and, we still used the brunch, put up with it. In our case, we sacrificed convenience for speed and fast assembly, because we had a lot of files and we could not afford to wait forever.
You did not try to join the open source story and start helping some projects? If so, where did you commit?
Yes, I have commits. I would not call myself an active contributor. Committed to front-end projects at the level of small pull-quests.
I have several of my open source projects (if I may say so). Perhaps they are not very interesting, did not get a lot of stars on the github, but still. I wrote a wrapper for working with printers under Node.js, for one of my hobby projects. I did something like distributed printing of photos from Instagram, found a cool little printer for photos and connected it to Raspberry. Fortunately, Node.js worked at Raspberry, I had to assemble it. I wrote something like an agent system (I don’t know if this term is correct or not). The idea was to connect such printer devices and then print photos on an arbitrary station. All this formed the basis of my graduation project, which I fully laid out on the github, I am proud of this to some extent. Having a github is great, and use it for education too.
Where do you get information about the front: resources, twitter accounts that you follow, news sites? About Ruby, we all know where to look, what to subscribe to, and personally, nothing comes to my mind with the front-line part.
In the first place for me is Code Hipsters. Even if I don’t read articles, I don’t look for them, I still use the telegram and read the Code Hipsters channel with great pleasure. Of course, I take it a little differently, because these are my friends.
Twitter, especially English-speaking helps. I will not name any specific accounts, this is a layer of information that has accumulated over many years. Sometimes you can flip through a tape, and if something really trendy happened in the front-end, you will see it right away, the whole tape will be filled with it.
I also like podcasts. I'm listening toVebstandarty . By the way, in a recent issue they asked who listens to which podcasts - it turned out that no one was listening :).
FrontFlip , probably?
No, it didn’t, it’s not possible to listen to Russian-language podcasts at all. I listen to The Changelog , I also like the Thougtbot podcast . More Giant RobotsI really like the style, the atmosphere. Usually these are two speakers, and it seems that they just meet on the weekend, discuss what happened, forget that there is a topic for the podcast. But it's still interesting to listen to. It’s even two podcasts, one more about business (this is a podcast from one of the creators of foreign key and some other platform. And about development, this is a guy’s podcast that will also be on RailsClub, which supports Phoenix for Elixir.
What will you talk about on RailsClub us, the backend to the developers?
The fact that the frontend has ridden far and the framework is not keeping pace with this. I will talk about how to assemble the frontend surrounded by rails, what are the solutions, what are the problems. And why is this really necessary. I will try rely on your personal experience.
As I understand it, you have not been to RailsClub before. What do you expect from the conference?
Many interesting acquaintances. I would like to see many guys with burning eyes. Anyway, the guys who are ready to talk, not only on the topic of the conference. Conferences are interesting to people.
I had an interesting situation: last year we went to Frontend Union Conf , it was in Moscow last August, in this somewhere in the Baltic states. We arrived with the whole party, but were so tired of the road that it was very difficult to catch a wave of reports, we listened with one ear. The drive began at the afterparty. We met a guy from SoundCloud, Jan Monschke. I don’t remember what his report was, but the conversation after the conference was memorable. He's a cool dude, told us about his projects. We are talking about Brunch, the collector of which I have already spoken. And it turned out that he was one of the dudes who started this project. Come on!? This is exactly what you need to go to the conference for: communication. Well, reports too :)
Besides development, what do you like? Do you read, sing, play something, go to the mountains?
Code Hopsters, although this is more related to work. I can say that I am inspired (both in work and in life) by many things that I learned when I was a child. As a child, I liked all sorts of things, mechanisms. I had a small workshop in which I made all kinds of bows and crossbows from wood. Unfortunately, I did not have a mentor who would show how you can connect all this to electricity, how to do more advanced things.
I once stumbled upon a book called Code, it was written by Charles Petzold. The book was interesting in that it told about childhood: imagine that you have a friend, you live in houses opposite. And you wanted to communicate, giving each other secret signs. You take out a flashlight, start drawing letters on the wall of his house. Then he smoothly switches to Morse codes and alphabet, Braille, talks about the telegraph. If you want to make a telegraphic connection, then you need a repeater, and a repeater can be done on the basis of a relay ... And then the fun begins. According to the book, you can make all sorts of logis gate, etc. Spoiler: The book ends with showing how to write a prototype of an operating system in assembler. This book is an ideal description of what inspires me, these are such mental experiments.
I also like it when the code is somehow interwoven with the design. I can recommend the book “ The Nature of Code ”, it is written in a common language, but it shows how to write processing, how to simulate natural systems, such as flocks of birds and so on. Such things inspire me greatly. I think this to some extent determines what kind of developer I am, how I work and live.
How many projects do you have and what kind of frontend stack are you currently using?
Talking about the current time is difficult: I have a stage when I try to close everything. I can tell you about what I use in real life. It all depends on the tasks, I try to be as flexible as possible, for the benefit of the team I work with, and for the benefit of the client.
If I understand that a project with a large number of states does not require strong interface logic, then why not make it multipage, why not make it on rails, they have everything for this.
If you go into details, then I use Slim, I write in SCSS. I noticed that when you write a single page application for a long time, the frontend changes you. We had a complex project: a separate backend and many single page applications. They were all written in ember.js.
In general, ember has an interesting way, from the moment the idea has ripened to the moment when the community began to appear around it and it began to compete with react in terms of performance. I am very pleased with this framework, it has everything for a quick start. Some things are confusing, especially the Convention over configuration. The guys who made Ember (Yehuda Katz from the rails core team) were inspired by rails and tried to transfer many principles. It seems to me that not everything turned out great. Convention over configuration in front-end projects, in my opinion, is very doubtful. It’s easier for me to write more front-end code than relying on some things that are built into the framework. On the other hand, there are a lot of convenient helpers, you can quickly start a project and so on.
Returning to the topic of multipage. I noticed for myself that on rail projects that do not use an external collector, but rely entirely on the assets pipeline, I begin to organize my front-end files into some kind of structure, write services, organize everything in a kind of view. Although these are just pure ES6 classes that receive a root node in the constructor, from which you can work. Such a lightweight backbone view, but only without everything, just for isolation. I think this is a good trend. This allows you to keep the code base in good condition and avoid the effects that often come out when it grows.
Now there is some confrontation between Angular and React. Which side are you on, dark or light? And what is dark and what is light?
I practically did not work with Angular. I understand what you're driving at, but it's hard to talk about. I believe that these disputes are meaningless. No need to look for who is in charge, who is right, who is not. You need to understand who is good in what situation, where what is better to use. If there is an application in which I will see a clear structure, transitions, routes, authorization, downloads and so on - I would probably rely on Angular. Although I never saw him in my eyes, but I suppose there is a lot of support for such things. If it were necessary to write some kind of widget, embedded part, some simple application, with a small number of states, in this case, I will probably choose React. I would not focus on performance measurements and some features like serverside rendering. I think that these issues are discussed too much, serverside rendering is not worth it. In reality, this is necessary in 10% of cases, at least it seems to me so. Therefore, I would look at those things that the framework offers: what will be useful for the team, for the entire project, for the company.
So you have neutrality in this war?
Yes! If I were asked to advise something to the next generation, I would advise you to read an interesting article about how it feels to be a 40-year-old developer . The author very interestingly talks about his whole life, what he was taught by work in more than 10 companies. He says a very important thought: do not rely on hype, this is a false feeling, try to look at everything with a sober look. Evaluate without relying on short-term feelings. I think this is very wise. I would also like to adhere to this position.
If you want to talk with Alexei personally, come to the conference! All the details are here , the ticket price is 8000 rubles.
Thanks to the companies that support the conference:
Stay up to date with our newsletter by signing up for the newsletter on railsclub.ru .
See you!
We have already said that this year Yukihiro Matsumoto, Akira Matsuda, Sean Griffin, Steve Klabnik and Zach Briggs will come to us. And today we are starting to publish traditional interviews with our speakers. This year, the RubyNoName podcast helps us make the conversation with speakers interesting .
The guys recorded the first conversation with Alexei Taktarov, a front-end (!) developer from These Guys. Alexey specializes in the development of single-page applications, promotes the purity and simplicity of design and code. He participated in Smartato projects, ficus.io and resume.io, worked with Evil Martians; its main tools are Ember.js, React and Ruby on Rails. In his spare time, he is engaged in the southern near-front hangout with Code Hipsters. This is the first time we have put a report about the front in the backend conference program. Nowhere without him in 2016 :). Leschin's report is called “ Give the frontend in Rails a second chance! ”.
What will be discussed:
In the front-end community in recent years, not boring! It’s difficult to say whether this is fatigue or enlightenment from JavaScript, one thing is clear - front-end development rushes ahead of the rest with the speed of a supersonic locomotive. At the same time, business and projects live a normal life. Rails frontend development approaches are hopelessly outdated: Asset building through Sprockets is a long, uncomfortable, inflexible process.
In his report, Alexey will briefly touch upon the current state of the frontend and talk about the urgent problems of assembling assets in Rails. He will conduct an excursion into the modern assembly systems Webpack, Gulp, Brunch and Rollup and show how they can be integrated into the Rails ecosystem using real projects as examples.
Audio can be heard on the podcast site , but here we share the transcript.
Today we realized that your report is the first front-end report on RailsClub. And it’s very cool! I was afraid to ask you questions about Ruby, the front-end, but it turned out that you understand and understand him. Tell me how it happened? How did you come to Ruby?
My history of exploring these technologies is quite atypical. I started my career as a person who makes system tools. I didn’t meet with the front-end either, I just worked on native interfaces for Windows. I spent some time on making programs that work with a large number of threads, which work with concurrency, and so on. And then somehow smoothly moved to the front end, then just a hype appeared. I started working with Ruby and rails after that, and for me it was a little revelation, because not all the things that work there work as I used to. Best example: in some environments where you should always keep an eye on resources, if you took something in one thread and work, you should be sure that there will be no problems with that in another thread - in ruby all these problems were bypassed. I came across completely different concepts. And that was cool!
Specifically, I came to the project as a front-end, doing only the front-end tasks. And then we didn’t have a back-end :) He left, there was nobody to solve his tasks, and I decided to try. It was unusual: there was no one to discuss with, the person who helped me was a sort of sage. I came to him once a week, he spoke some magic words about what should I do. Then I left, sighed, thought: “Oh my God, what's going on.”
After some time, I kind of managed to comprehend this wisdom, although probably not all. The part that is in the framework and language, I felt this taste.
Where and what are you doing now?
From personal - getting ready for the wedding. I’m working on my project, which is still too raw to talk about. I also work with a partner in a team calledThese Guys . We specialize in the rapid development of MVP. I try to make the most of the experience that I got while working with the Evil Martians, and with other teams. But now I focus more now not on solving technical problems, but on solving business problems, I am thinking over how to optimally build everything for the client.
So you opened your company now?
Yes. Although now I’m very scared to say this out loud, for some reason :)
What do you dislike about the current implementation of rails from the point of view of the front end?
It seems to me that this situation happened: two or three years ago, the frontend jumped sharply and rushed forward at the speed of a locomotive, sweeping everything in its path. The guys from other communities looked at this, someone was skeptical, someone inspired. But I must admit that he rode away very far. In this regard, the world of rail remained unchanged.
It is believed that the rail should cease to be a tool that has both a front and a back, focus only on the back. Because the front end part in the rail itself is clearly not in time now. We have to use rails as a server part, and the front one is separate, there are separate tools, a separate team, a separate story. What is your position on this?
I always try to look wider. When I see a hype around the front end, I always try to find both good and bad sides. It’s good that everything develops and moves, a lot of ideas, a lot of things can be done that will help the next generation of developers. But you need to look at it with caution, look at whether everything is really as it seems? This also applies to companies: which stack they choose, how they communicate with their developers. For example, the developers took some popular stack now, and then everything fell apart. The company stopped working because the technology was raw. Have you had this?
I try to stick to the middle ground. Recently I read an article by Ravil Bayramgalin from the Martians about the new renderer. It’s interesting not even the implementation itself, but what comes at the beginning of the article: DHH does not have much time to devote to its development, but it writes down and talks about many ideas that other developers can pick up to successfully develop the framework. I think it's great. Cool when there is a vision, when DHH understands where to go. There may be disagreements, somewhere it will not be the right way. But I like it when I have an understanding of the overall mission. In rails there is such a vision, you need to survive the hype and move on. I think we will succeed, my position is quite positive :)
If we talk about hype in the front. What is hype now, and what can you really use? What do you think should be paid attention to? And what will be interesting next?
Some time ago, my friends and I organized a small party in Rostov called Code Hipsters . This is mainly a news feed in VKontakte and in a Telegram, we write about all kinds of fashionable things in the front-end (we are trying to beat this in the title). Now I am a little retired, everything is done by my friend Vitya. He has a wonderful style, I really like the way he writes. Sometimes we get together and understand that we have not read anything new over the past week :) Apparently, we are a little tired.
The last thing I heard about is Rollup . In my opinion, there is nothing revolutionary, but it's interesting to see. The movement towards smart bundlers, the correct assembly of dependencies, I think is very important, this is a good direction. Although it cannot be said that this is rocket science.
Secondly, the component approach. He came a long time ago, everyone accepted him, and that's great.
Thirdly, FRP. There is a big gap between theory and practice on this issue. Surely something will appear to overcome it.
Returning to the question of rail as a framework and to the front. What would you add to a rail or remove from it, from the point of view of front-end development? Maybe he would have removed the front from the rails?
I would not clean the front. It seems to me that the solution that is now will allow us to survive in 80% of projects, at least those that are on the market. It’s very convenient for Ingoda to have such functionality.
Even when we are talking about assembling files, which is not really an assembly, but simply concatenation in the correct order. I think this is bad.
I heard that they do not like turbolinks, although I am quite normal towards them, I use them in some projects.
Yes, sometimes you have to spend a lot of time figuring out how to do it right. But it accustoms to order. It was easier for me: I did not write scripts, I immediately started writing single page applications. I had to think about how to allocate resources, how to extinguish them correctly, about services, about the application’s life cycle, about how it can work for a long time. When you make a simple multi-page website interspersed with scripts, you don’t think about it.
But sometimes a project requires that all this be taken into account, it makes you keep in mind the patterns that the correct frontend taught us.
I don’t know what I would add directly to the rails. There is a tendency to throw away all unnecessary, to facilitate, to leave rails only for API. Right?
There is a separate branch related specifically to Rails API development, disabling unnecessary things.
Yes, this also applies to assembly. If you are launching a rail project, it would probably be great to be able to somehow control the processes that are starting. Now it is not just a rails server, or some Sidekiq. It would be cool to be able to monitor the processes that run for the assembly, which Node.js processes are running. It would be cool to come up with something like that. Although here you can, in principle, offer solutions like Foreman or Hivemind.
Since we started talking about tools: what are you watching now? What projects do you like, which ones are worth paying attention to?
In some cases I use Webpack , it suits me perfectly. I understand all the humor behind the fact that he has a complicated configuration. It seems to me the main concept that the modules are cool. I used the Brunch builder for a long time . He was always bypassed, he remained in the shade. But for me it is an ideal tool when you need to throw something very quickly, when you just need modules in the common js style, when you need a very fast build. Because it really works very fast. It struck me that many of the guys who make the frameworks start sculpting boilerplate and command line tools like Ember CLI, or a thing for React that has appeared recently. In the case of Ember, it struck me that you are very rigidly attached to the collector, you cannot choose a collector other than Broccoli (which I could not configure at that time, and it collected everything for a very long time). At least on my machine, it worked forever.
I had experience working with Ember, we fully assembled our project on Brunch. Even considering the fact that I had to port a lot for myself, because the whole community switched to Ember CLI and, we still used the brunch, put up with it. In our case, we sacrificed convenience for speed and fast assembly, because we had a lot of files and we could not afford to wait forever.
You did not try to join the open source story and start helping some projects? If so, where did you commit?
Yes, I have commits. I would not call myself an active contributor. Committed to front-end projects at the level of small pull-quests.
I have several of my open source projects (if I may say so). Perhaps they are not very interesting, did not get a lot of stars on the github, but still. I wrote a wrapper for working with printers under Node.js, for one of my hobby projects. I did something like distributed printing of photos from Instagram, found a cool little printer for photos and connected it to Raspberry. Fortunately, Node.js worked at Raspberry, I had to assemble it. I wrote something like an agent system (I don’t know if this term is correct or not). The idea was to connect such printer devices and then print photos on an arbitrary station. All this formed the basis of my graduation project, which I fully laid out on the github, I am proud of this to some extent. Having a github is great, and use it for education too.
Where do you get information about the front: resources, twitter accounts that you follow, news sites? About Ruby, we all know where to look, what to subscribe to, and personally, nothing comes to my mind with the front-line part.
In the first place for me is Code Hipsters. Even if I don’t read articles, I don’t look for them, I still use the telegram and read the Code Hipsters channel with great pleasure. Of course, I take it a little differently, because these are my friends.
Twitter, especially English-speaking helps. I will not name any specific accounts, this is a layer of information that has accumulated over many years. Sometimes you can flip through a tape, and if something really trendy happened in the front-end, you will see it right away, the whole tape will be filled with it.
I also like podcasts. I'm listening toVebstandarty . By the way, in a recent issue they asked who listens to which podcasts - it turned out that no one was listening :).
FrontFlip , probably?
No, it didn’t, it’s not possible to listen to Russian-language podcasts at all. I listen to The Changelog , I also like the Thougtbot podcast . More Giant RobotsI really like the style, the atmosphere. Usually these are two speakers, and it seems that they just meet on the weekend, discuss what happened, forget that there is a topic for the podcast. But it's still interesting to listen to. It’s even two podcasts, one more about business (this is a podcast from one of the creators of foreign key and some other platform. And about development, this is a guy’s podcast that will also be on RailsClub, which supports Phoenix for Elixir.
What will you talk about on RailsClub us, the backend to the developers?
The fact that the frontend has ridden far and the framework is not keeping pace with this. I will talk about how to assemble the frontend surrounded by rails, what are the solutions, what are the problems. And why is this really necessary. I will try rely on your personal experience.
As I understand it, you have not been to RailsClub before. What do you expect from the conference?
Many interesting acquaintances. I would like to see many guys with burning eyes. Anyway, the guys who are ready to talk, not only on the topic of the conference. Conferences are interesting to people.
I had an interesting situation: last year we went to Frontend Union Conf , it was in Moscow last August, in this somewhere in the Baltic states. We arrived with the whole party, but were so tired of the road that it was very difficult to catch a wave of reports, we listened with one ear. The drive began at the afterparty. We met a guy from SoundCloud, Jan Monschke. I don’t remember what his report was, but the conversation after the conference was memorable. He's a cool dude, told us about his projects. We are talking about Brunch, the collector of which I have already spoken. And it turned out that he was one of the dudes who started this project. Come on!? This is exactly what you need to go to the conference for: communication. Well, reports too :)
Besides development, what do you like? Do you read, sing, play something, go to the mountains?
Code Hopsters, although this is more related to work. I can say that I am inspired (both in work and in life) by many things that I learned when I was a child. As a child, I liked all sorts of things, mechanisms. I had a small workshop in which I made all kinds of bows and crossbows from wood. Unfortunately, I did not have a mentor who would show how you can connect all this to electricity, how to do more advanced things.
I once stumbled upon a book called Code, it was written by Charles Petzold. The book was interesting in that it told about childhood: imagine that you have a friend, you live in houses opposite. And you wanted to communicate, giving each other secret signs. You take out a flashlight, start drawing letters on the wall of his house. Then he smoothly switches to Morse codes and alphabet, Braille, talks about the telegraph. If you want to make a telegraphic connection, then you need a repeater, and a repeater can be done on the basis of a relay ... And then the fun begins. According to the book, you can make all sorts of logis gate, etc. Spoiler: The book ends with showing how to write a prototype of an operating system in assembler. This book is an ideal description of what inspires me, these are such mental experiments.
I also like it when the code is somehow interwoven with the design. I can recommend the book “ The Nature of Code ”, it is written in a common language, but it shows how to write processing, how to simulate natural systems, such as flocks of birds and so on. Such things inspire me greatly. I think this to some extent determines what kind of developer I am, how I work and live.
How many projects do you have and what kind of frontend stack are you currently using?
Talking about the current time is difficult: I have a stage when I try to close everything. I can tell you about what I use in real life. It all depends on the tasks, I try to be as flexible as possible, for the benefit of the team I work with, and for the benefit of the client.
If I understand that a project with a large number of states does not require strong interface logic, then why not make it multipage, why not make it on rails, they have everything for this.
If you go into details, then I use Slim, I write in SCSS. I noticed that when you write a single page application for a long time, the frontend changes you. We had a complex project: a separate backend and many single page applications. They were all written in ember.js.
In general, ember has an interesting way, from the moment the idea has ripened to the moment when the community began to appear around it and it began to compete with react in terms of performance. I am very pleased with this framework, it has everything for a quick start. Some things are confusing, especially the Convention over configuration. The guys who made Ember (Yehuda Katz from the rails core team) were inspired by rails and tried to transfer many principles. It seems to me that not everything turned out great. Convention over configuration in front-end projects, in my opinion, is very doubtful. It’s easier for me to write more front-end code than relying on some things that are built into the framework. On the other hand, there are a lot of convenient helpers, you can quickly start a project and so on.
Returning to the topic of multipage. I noticed for myself that on rail projects that do not use an external collector, but rely entirely on the assets pipeline, I begin to organize my front-end files into some kind of structure, write services, organize everything in a kind of view. Although these are just pure ES6 classes that receive a root node in the constructor, from which you can work. Such a lightweight backbone view, but only without everything, just for isolation. I think this is a good trend. This allows you to keep the code base in good condition and avoid the effects that often come out when it grows.
Now there is some confrontation between Angular and React. Which side are you on, dark or light? And what is dark and what is light?
I practically did not work with Angular. I understand what you're driving at, but it's hard to talk about. I believe that these disputes are meaningless. No need to look for who is in charge, who is right, who is not. You need to understand who is good in what situation, where what is better to use. If there is an application in which I will see a clear structure, transitions, routes, authorization, downloads and so on - I would probably rely on Angular. Although I never saw him in my eyes, but I suppose there is a lot of support for such things. If it were necessary to write some kind of widget, embedded part, some simple application, with a small number of states, in this case, I will probably choose React. I would not focus on performance measurements and some features like serverside rendering. I think that these issues are discussed too much, serverside rendering is not worth it. In reality, this is necessary in 10% of cases, at least it seems to me so. Therefore, I would look at those things that the framework offers: what will be useful for the team, for the entire project, for the company.
So you have neutrality in this war?
Yes! If I were asked to advise something to the next generation, I would advise you to read an interesting article about how it feels to be a 40-year-old developer . The author very interestingly talks about his whole life, what he was taught by work in more than 10 companies. He says a very important thought: do not rely on hype, this is a false feeling, try to look at everything with a sober look. Evaluate without relying on short-term feelings. I think this is very wise. I would also like to adhere to this position.
If you want to talk with Alexei personally, come to the conference! All the details are here , the ticket price is 8000 rubles.
Thanks to the companies that support the conference:
General partner: Toptal
Gold partners: Rambler & Co and AT-Consulting
Silver partner: JetBrains
Bronze partners: Gitlab and VoltMobi
Beer partner supporting traditional afterparty - CloudCastle
Stay up to date with our newsletter by signing up for the newsletter on railsclub.ru .
See you!