RailsClub 2016: Interview with Alexey Taktarov
Hello! RailsClub 2016 has a little more than a month left. It's time to register!
We have already told that this year Yukihiro Matsumoto, Akira Matsuda, Shaun 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 to make a conversation with speakers interesting.
The guys recorded the first conversation with Alexey Taktarov , a frontend (!) Developer from These Guys. Alexey specializes in the development of single-page applications, promotes the purity and simplicity of design and code. Took part in the projects SmartMato, ficus.io and resume.io, worked with Evil Martians; its main tools are Ember.js, React and Ruby on Rails. In his free time he is engaged in the southern near-frontend party Code Hipsters.
')
For the first time, we put a report on the front in the backend of the conference. Nowhere without him in 2016 :). Leshin report called " Give the frontend in Rails a second chance! ".
What will be discussed:
In the frontend community in recent years, not boring! It is difficult to say if this is fatigue or enlightenment from JavaScript, one thing is clear - front-end development rushes ahead of the rest of the planet at the speed of a supersonic locomotive. At the same time, business and projects live a normal life. Approaches to the development of frontend in Rails are hopelessly outdated: assembling assets via Sprockets is long, inconvenient, inflexible.
In his report, Alexei will briefly touch on the current state of the front end and talk about the acute problems of assembling assets in Rails. Take an excursion into modern Webpack, Gulp, Brunch and Rollup build systems and show how they can be integrated into the Rails ecosystem using real projects.
You can listen to the audio on the podcast site , and here we share the decoding.
We understood today that your report is the first report about the frontline on RailsClub. And this is very cool! I was afraid to ask you, the front-line reader, questions about Ruby, but it turned out that you understand him and understand him. Tell me how it happened? How did you come to Ruby?
My story of acquaintance with these technologies is rather atypical. I started my career as a person who makes system tools. I didn’t meet the front-end then, just dealt with the native interfaces for Windows. For some time I spent on doing programs that work with a large number of threads that work with concurrency and so on. And then somehow smoothly moved to the frontend, then the HYIP just appeared. I started working with Ruby and rails after that, and for me it was a small revelation, because not all the things that work there work like I used to. The best example: in some environments where you should always monitor resources, if you took something in one stream and work, you should be sure that there will be no problems with another stream - in ruby, all these problems were avoided. I am faced with completely different concepts. And it was cool!
More specifically, I came to the project as a fronder, I did only the frontend task. And then we did not have a back-tender :) He was gone, there was no one 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 I should do. Then I left, sighed, thought: “O God, what is happening.”
After some time I sort of managed to comprehend this wisdom, although probably not all. That part, which is laid in the framework and language, I felt this taste.
Where and what are you doing now?
From personal - I am preparing for the wedding. I work on my project, which is still too raw to talk about. I also work with a partner in a team called These Guys . We specialize in the rapid development of MVP. I try to maximally apply the experience that I got from working with Evil Martians and with other teams. But now I’m more oriented now not on solving technical problems, but on solving business problems, I think about how best to build everything for a client.
So you just opened your company?
Yes. Although it is very scary to say this out loud to me now, for some reason :)
What do you dislike about the current implementation of rails in terms of the frontend?
It seems to me that this situation happened: two or three years ago the front end abruptly jumped and rushed forward at the speed of a locomotive, sweeping away everything in its path. The guys from other communities looked at it, someone was skeptical, someone was enthusiastic. But I must admit that he rode away very far. In this regard, the world rail remained unchanged.
It is believed that the rail should cease to be a tool that has both the front and the 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 the rails as the server part, and the front one stands alone, there are separate tools, a separate team, a separate story. What is your position about this?
I always try to look wider. When I see HYIP 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, to look at that, is everything 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. Did you have this?
I try to stick to the golden mean. Recently I read an article by Ravil Bayramgalin from the Martians about the new renderer . It is not even the implementation itself that is interesting in it, but what goes at the beginning of the article: DHH does not have much time to devote to its development, but it records and tells a lot of ideas that other developers can catch up to successfully develop the framework. I think it's great. Cool when there is a vision, when DHH understands where to go. Perhaps there will be disagreements, somewhere it will be not quite the right way. But I like it when there is an understanding of the overall mission. There is such a vision on the tracks, you need to survive the HYIP and move on. I think we will succeed, my position is quite positive :)
If we talk about HYIP in the front. What is now HYIP, and what can you really use? What do you think is worth paying 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 basically a news feed on VKontakte and Telegram, we write about all sorts of fancy stuff in the front end (this is what we are trying to beat in the title). Now I am a little retired, my friend Vitya is doing everything. He has a great style, I really like the way he writes. Sometimes we are going and we understand that we have not read anything new over the past week :) Apparently, we are a little tired.
The last thing I heard about was the Rollup . In my opinion, there is nothing revolutionary there, but it's interesting to see. Moving in the direction of smart bandlers, I consider the correct assembly of dependencies to be very important, this is a good direction. Although it can not be said that this is rocket science.
Secondly, the component approach. He came a long time, everyone accepted him, and that's great.
Third, the FRP. In this matter there is a big gap between theory and practice. Surely something will appear to overcome it.
Returning to the issue of rail as a framework and to the front. What would you add to the rail or removed from it, in terms of front-end development? Could it even remove the front from the rails?
I would not clean the front. It seems to me that the solution that exists now will allow us to survive in 80% of the projects, at least those that are on the market. Ingoda is very convenient to have such functionality.
Even when we are talking about building files, which is not really an assembly, but just a concatenation in the correct order. I think this is bad.
I heard that they do not like turboLinks, although I treat them quite normally, I use them in some projects.
Yes, sometimes you have to spend a lot of time trying to figure out how to do everything correctly. But it teaches 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 properly extinguish them, about services, about the life cycle of an application, about how it can work for a long time. When you make a simple multi-page site with a splash of scripts, you don’t think about it.
But sometimes the project requires that all this be taken into account makes you keep in mind the patterns that the right frontend taught us.
I do not know what I would add directly to the rails. There is a tendency to throw out all unnecessary, to facilitate, to leave the rails only for the API. Right?
There is a separate branch associated with Rails API development, disabling unnecessary things.
Yes, this also applies to assembly. If you start a rail project, it would probably be great to be able to somehow manage the processes that are running. Now this is not just a rails server, or some Sidekiq. It would be cool to be able to monitor the processes that run for assembly, which Node.js processes run. It would be cool to come up with something like that. Although here you can, in principle, offer solutions like Foreman or Hivemind.
Once we started talking about the tools: what are you watching now? What projects do you like, which ones should you pay attention to?
In some cases, I use Webpack , it suits me perfectly. I understand all the humor that stands behind the fact that he has a complex configuration. I think the main concept is that the modules are cool. I have been using the Brunch collector for a long time. He was always avoided, he remained in the shadows. But for me, this is an ideal tool when you need to distribute something very quickly, when you just need modules in the style of common js, when you need a very fast build. Because it really works very fast. It struck me that many guys who are doing frameworks are starting to sculpt the boilerplate and command line tools, for example Ember CLI , or the piece for React, which appeared recently. In the case of Ember, I was struck by the fact that you are very tightly tied to the collector, you cannot choose another collector other than Broccoli (which I couldn’t set up at that time, and he collected everything for a very long time). At least on my machine, it worked forever.
I have had experience with Ember, we have fully assembled my project at Brunch. Even taking into account the fact that we had to port a lot for ourselves, because all the community switched to Ember CLI and, we still used Branch, we were patient. In our case, we sacrificed convenience in favor of speed and quick build, 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 are you kommitil?
Yes, I have commits. I would not call myself an active contributor. Committed to frontend projects at the level of small pullrequests.
I have some 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 githaba, but still. I wrote a wrapper for working with printers under Node.js, for one of my hobby projects. I did something like a distributed printing of photos from Instagram, found a cool little photo printer and connected it to Raspberry. The blessing on Raspberry worked Node.js, it was necessary to collect it. I wrote something like an agent system (I don’t know if this is a correct term or not). The idea was to connect such printers-devices and then print photos on an arbitrary station. All this formed the basis of my graduation project, which I completely laid out on the githab, I am to some degree proud of it. Having a githab is great, and using it for education too. In general, the thesis project turned out pretty cool.
Where do you get information about the front: resources, twitter accounts you follow, news sites? About Ruby, we all know where to look, what to subscribe, and with the front part I personally have nothing to do with the move.
In the first place for me is Code Hipsters. Even if I don’t read the articles, don’t look for them, I still use the telegram and read the Code Hipsters channel with great pleasure. Of course, I perceive 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 the tape, and if something really trendy happened in the frontend, you will immediately see it, the whole tape will be filled with it.
I also like podcasts. I listen to Webstandards . By the way, in a recent issue they asked who listens to which podcasts - it turned out that no one listens to anything :).
FrontFlip , probably?
No, it’s not, it’s impossible to listen to Russian-speaking podcasts. I listen to The Changelog , I also like the Thougtbot podcast. Another Giant Robots , I really like the style, the atmosphere. Usually these are two speakers, and it seems that they just meet on the weekend, discuss what happened to them, forget that there is a topic for a podcast. But it's still interesting to listen. There are even two podcasts, one more about business (this is a podcast from one of the founders of the foreign key and another platform. And about the development of this podcast of a guy who will also be on RailsClub, which supports Phoenix for Elixir.
What will you tell us on the RailsClub to us, the backend developers?
The fact that the front-end has rode away and the framework does not keep up with it. I will talk about how to assemble a frontend surrounded by rail, what are the solutions, what are the problems. And why is it really necessary. I will try to rely on my personal experience.
As I understand it, you were not at RailsClub before. What do you expect from the conference?
Many interesting acquaintances. I would like to see a lot of guys with burning eyes. And in general, guys who are ready to talk, not only on the topic of the conference. Conferences are interesting for people.
I had an interesting situation: last year we went to Frontend Union Conf , it was last August in Moscow, somewhere in the Baltic States. We came all over the party, but we were so tired from the road that it was very difficult to catch a wave of reports, we listened with one ear. Drive started on the afterpart. We met a guy from SoundCloud, Jan Monschke . I do not remember what his report was, but the communication after the conference was remembered. 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: communication. Well, reports too :)
In addition to development, what are your hobbies? Do you read, sing, play on something, go to the mountains?
Code Hopsters, although it 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. In childhood 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 make more advanced things.
Once I came across a book called Code , written by Charles Petzold. The book was interesting because it talked 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 to draw letters on the wall of his house. Then he moves smoothly to Morse code and Braille, tells about the telegraph. If you want to make a telegraph connection, then you need a repeater, and you can make a repeater on the basis of a relay ... And then the fun begins. According to the book, you can make all sorts of logi gate and so on. Spoiler: the book ends with the fact that it shows how to assemble an operating system prototype in assembler. This book is the perfect description of what inspires me, these are thought experiments.
I also like it when the code is somehow intertwined with the design. I can advise the book “ The Nature of Code ”, it is written in ordinary language, but it shows how to write processing, how to model natural systems, such as flocks of birds and so on. These things inspire me a lot. I think this to some extent determines what kind of developer I am, the way I work and live.
How many projects do you have and what kind of front-end 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 a strong interface logic, then why not make it a multipage, why not make it on the rails, they have everything for it.
If you go into details, then I use Slim, I write on 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. All of them were written in ember.js.
In general, ember has an interesting way, from the moment the idea matured, until the moment when the community began to appear around it and it began to react with react in performance. , . - , Convention over configuration. , Ember ( rails core team), . , . Convention over configuration , , — . , - , . , help', .
multipage. , , , assets pipeline, - , , view. ES6 , , . backbone view, , . , . , , .
- Angular React. , ? , ?
Angular . , , . , . , , . , , . , , , , , — , , Angular. , , . - , , - , , , , React. - . , , . 10% , , . , : , , , .
?
Yes! - , , 40- . , 10 . : , , . , . , . .
, ! , — 8000 .
Thanks to the companies that support the conference:
, railsclub.ru .
See you!
We have already told that this year Yukihiro Matsumoto, Akira Matsuda, Shaun 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 to make a conversation with speakers interesting.
The guys recorded the first conversation with Alexey Taktarov , a frontend (!) Developer from These Guys. Alexey specializes in the development of single-page applications, promotes the purity and simplicity of design and code. Took part in the projects SmartMato, ficus.io and resume.io, worked with Evil Martians; its main tools are Ember.js, React and Ruby on Rails. In his free time he is engaged in the southern near-frontend party Code Hipsters.')
For the first time, we put a report on the front in the backend of the conference. Nowhere without him in 2016 :). Leshin report called " Give the frontend in Rails a second chance! ".
What will be discussed:
In the frontend community in recent years, not boring! It is difficult to say if this is fatigue or enlightenment from JavaScript, one thing is clear - front-end development rushes ahead of the rest of the planet at the speed of a supersonic locomotive. At the same time, business and projects live a normal life. Approaches to the development of frontend in Rails are hopelessly outdated: assembling assets via Sprockets is long, inconvenient, inflexible.
In his report, Alexei will briefly touch on the current state of the front end and talk about the acute problems of assembling assets in Rails. Take an excursion into modern Webpack, Gulp, Brunch and Rollup build systems and show how they can be integrated into the Rails ecosystem using real projects.
You can listen to the audio on the podcast site , and here we share the decoding.
We understood today that your report is the first report about the frontline on RailsClub. And this is very cool! I was afraid to ask you, the front-line reader, questions about Ruby, but it turned out that you understand him and understand him. Tell me how it happened? How did you come to Ruby?
My story of acquaintance with these technologies is rather atypical. I started my career as a person who makes system tools. I didn’t meet the front-end then, just dealt with the native interfaces for Windows. For some time I spent on doing programs that work with a large number of threads that work with concurrency and so on. And then somehow smoothly moved to the frontend, then the HYIP just appeared. I started working with Ruby and rails after that, and for me it was a small revelation, because not all the things that work there work like I used to. The best example: in some environments where you should always monitor resources, if you took something in one stream and work, you should be sure that there will be no problems with another stream - in ruby, all these problems were avoided. I am faced with completely different concepts. And it was cool!
More specifically, I came to the project as a fronder, I did only the frontend task. And then we did not have a back-tender :) He was gone, there was no one 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 I should do. Then I left, sighed, thought: “O God, what is happening.”
After some time I sort of managed to comprehend this wisdom, although probably not all. That part, which is laid in the framework and language, I felt this taste.
Where and what are you doing now?
From personal - I am preparing for the wedding. I work on my project, which is still too raw to talk about. I also work with a partner in a team called These Guys . We specialize in the rapid development of MVP. I try to maximally apply the experience that I got from working with Evil Martians and with other teams. But now I’m more oriented now not on solving technical problems, but on solving business problems, I think about how best to build everything for a client.
So you just opened your company?
Yes. Although it is very scary to say this out loud to me now, for some reason :)
What do you dislike about the current implementation of rails in terms of the frontend?
It seems to me that this situation happened: two or three years ago the front end abruptly jumped and rushed forward at the speed of a locomotive, sweeping away everything in its path. The guys from other communities looked at it, someone was skeptical, someone was enthusiastic. But I must admit that he rode away very far. In this regard, the world rail remained unchanged.
It is believed that the rail should cease to be a tool that has both the front and the 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 the rails as the server part, and the front one stands alone, there are separate tools, a separate team, a separate story. What is your position about this?
I always try to look wider. When I see HYIP 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, to look at that, is everything 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. Did you have this?
I try to stick to the golden mean. Recently I read an article by Ravil Bayramgalin from the Martians about the new renderer . It is not even the implementation itself that is interesting in it, but what goes at the beginning of the article: DHH does not have much time to devote to its development, but it records and tells a lot of ideas that other developers can catch up to successfully develop the framework. I think it's great. Cool when there is a vision, when DHH understands where to go. Perhaps there will be disagreements, somewhere it will be not quite the right way. But I like it when there is an understanding of the overall mission. There is such a vision on the tracks, you need to survive the HYIP and move on. I think we will succeed, my position is quite positive :)
If we talk about HYIP in the front. What is now HYIP, and what can you really use? What do you think is worth paying 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 basically a news feed on VKontakte and Telegram, we write about all sorts of fancy stuff in the front end (this is what we are trying to beat in the title). Now I am a little retired, my friend Vitya is doing everything. He has a great style, I really like the way he writes. Sometimes we are going and we understand that we have not read anything new over the past week :) Apparently, we are a little tired.
The last thing I heard about was the Rollup . In my opinion, there is nothing revolutionary there, but it's interesting to see. Moving in the direction of smart bandlers, I consider the correct assembly of dependencies to be very important, this is a good direction. Although it can not be said that this is rocket science.
Secondly, the component approach. He came a long time, everyone accepted him, and that's great.
Third, the FRP. In this matter there is a big gap between theory and practice. Surely something will appear to overcome it.
Returning to the issue of rail as a framework and to the front. What would you add to the rail or removed from it, in terms of front-end development? Could it even remove the front from the rails?
I would not clean the front. It seems to me that the solution that exists now will allow us to survive in 80% of the projects, at least those that are on the market. Ingoda is very convenient to have such functionality.
Even when we are talking about building files, which is not really an assembly, but just a concatenation in the correct order. I think this is bad.
I heard that they do not like turboLinks, although I treat them quite normally, I use them in some projects.
Yes, sometimes you have to spend a lot of time trying to figure out how to do everything correctly. But it teaches 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 properly extinguish them, about services, about the life cycle of an application, about how it can work for a long time. When you make a simple multi-page site with a splash of scripts, you don’t think about it.
But sometimes the project requires that all this be taken into account makes you keep in mind the patterns that the right frontend taught us.
I do not know what I would add directly to the rails. There is a tendency to throw out all unnecessary, to facilitate, to leave the rails only for the API. Right?
There is a separate branch associated with Rails API development, disabling unnecessary things.
Yes, this also applies to assembly. If you start a rail project, it would probably be great to be able to somehow manage the processes that are running. Now this is not just a rails server, or some Sidekiq. It would be cool to be able to monitor the processes that run for assembly, which Node.js processes run. It would be cool to come up with something like that. Although here you can, in principle, offer solutions like Foreman or Hivemind.
Once we started talking about the tools: what are you watching now? What projects do you like, which ones should you pay attention to?
In some cases, I use Webpack , it suits me perfectly. I understand all the humor that stands behind the fact that he has a complex configuration. I think the main concept is that the modules are cool. I have been using the Brunch collector for a long time. He was always avoided, he remained in the shadows. But for me, this is an ideal tool when you need to distribute something very quickly, when you just need modules in the style of common js, when you need a very fast build. Because it really works very fast. It struck me that many guys who are doing frameworks are starting to sculpt the boilerplate and command line tools, for example Ember CLI , or the piece for React, which appeared recently. In the case of Ember, I was struck by the fact that you are very tightly tied to the collector, you cannot choose another collector other than Broccoli (which I couldn’t set up at that time, and he collected everything for a very long time). At least on my machine, it worked forever.
I have had experience with Ember, we have fully assembled my project at Brunch. Even taking into account the fact that we had to port a lot for ourselves, because all the community switched to Ember CLI and, we still used Branch, we were patient. In our case, we sacrificed convenience in favor of speed and quick build, 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 are you kommitil?
Yes, I have commits. I would not call myself an active contributor. Committed to frontend projects at the level of small pullrequests.
I have some 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 githaba, but still. I wrote a wrapper for working with printers under Node.js, for one of my hobby projects. I did something like a distributed printing of photos from Instagram, found a cool little photo printer and connected it to Raspberry. The blessing on Raspberry worked Node.js, it was necessary to collect it. I wrote something like an agent system (I don’t know if this is a correct term or not). The idea was to connect such printers-devices and then print photos on an arbitrary station. All this formed the basis of my graduation project, which I completely laid out on the githab, I am to some degree proud of it. Having a githab is great, and using it for education too. In general, the thesis project turned out pretty cool.
Where do you get information about the front: resources, twitter accounts you follow, news sites? About Ruby, we all know where to look, what to subscribe, and with the front part I personally have nothing to do with the move.
In the first place for me is Code Hipsters. Even if I don’t read the articles, don’t look for them, I still use the telegram and read the Code Hipsters channel with great pleasure. Of course, I perceive 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 the tape, and if something really trendy happened in the frontend, you will immediately see it, the whole tape will be filled with it.
I also like podcasts. I listen to Webstandards . By the way, in a recent issue they asked who listens to which podcasts - it turned out that no one listens to anything :).
FrontFlip , probably?
No, it’s not, it’s impossible to listen to Russian-speaking podcasts. I listen to The Changelog , I also like the Thougtbot podcast. Another Giant Robots , I really like the style, the atmosphere. Usually these are two speakers, and it seems that they just meet on the weekend, discuss what happened to them, forget that there is a topic for a podcast. But it's still interesting to listen. There are even two podcasts, one more about business (this is a podcast from one of the founders of the foreign key and another platform. And about the development of this podcast of a guy who will also be on RailsClub, which supports Phoenix for Elixir.
What will you tell us on the RailsClub to us, the backend developers?
The fact that the front-end has rode away and the framework does not keep up with it. I will talk about how to assemble a frontend surrounded by rail, what are the solutions, what are the problems. And why is it really necessary. I will try to rely on my personal experience.
As I understand it, you were not at RailsClub before. What do you expect from the conference?
Many interesting acquaintances. I would like to see a lot of guys with burning eyes. And in general, guys who are ready to talk, not only on the topic of the conference. Conferences are interesting for people.
I had an interesting situation: last year we went to Frontend Union Conf , it was last August in Moscow, somewhere in the Baltic States. We came all over the party, but we were so tired from the road that it was very difficult to catch a wave of reports, we listened with one ear. Drive started on the afterpart. We met a guy from SoundCloud, Jan Monschke . I do not remember what his report was, but the communication after the conference was remembered. 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: communication. Well, reports too :)
In addition to development, what are your hobbies? Do you read, sing, play on something, go to the mountains?
Code Hopsters, although it 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. In childhood 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 make more advanced things.
Once I came across a book called Code , written by Charles Petzold. The book was interesting because it talked 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 to draw letters on the wall of his house. Then he moves smoothly to Morse code and Braille, tells about the telegraph. If you want to make a telegraph connection, then you need a repeater, and you can make a repeater on the basis of a relay ... And then the fun begins. According to the book, you can make all sorts of logi gate and so on. Spoiler: the book ends with the fact that it shows how to assemble an operating system prototype in assembler. This book is the perfect description of what inspires me, these are thought experiments.
I also like it when the code is somehow intertwined with the design. I can advise the book “ The Nature of Code ”, it is written in ordinary language, but it shows how to write processing, how to model natural systems, such as flocks of birds and so on. These things inspire me a lot. I think this to some extent determines what kind of developer I am, the way I work and live.
How many projects do you have and what kind of front-end 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 a strong interface logic, then why not make it a multipage, why not make it on the rails, they have everything for it.
If you go into details, then I use Slim, I write on 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. All of them were written in ember.js.
In general, ember has an interesting way, from the moment the idea matured, until the moment when the community began to appear around it and it began to react with react in performance. , . - , Convention over configuration. , Ember ( rails core team), . , . Convention over configuration , , — . , - , . , help', .
multipage. , , , assets pipeline, - , , view. ES6 , , . backbone view, , . , . , , .
- Angular React. , ? , ?
Angular . , , . , . , , . , , . , , , , , — , , Angular. , , . - , , - , , , , React. - . , , . 10% , , . , : , , , .
?
Yes! - , , 40- . , 10 . : , , . , . , . .
, ! , — 8000 .
Thanks to the companies that support the conference:
General partner: Toptal
: Rambler&Co AT-Consulting
Silver Partner: JetBrains
: Gitlab VoltMobi
Beer partner supporting traditional afterparty - CloudCastle
, railsclub.ru .
See you!
Source: https://habr.com/ru/post/310104/
All Articles