Scaling iOS apps: How did Rambler do it?
Today, our interlocutor is Yegor Tolstoy , head of iOS development at Rambler & Co, organizer and permanent speaker of the almost-every-in-two-month Rambler.iOS meeting. In addition to working on applications such as Rambler. Mail, Rambler. News and LiveJournal, a lot of time is devoted to opensource projects, in particular Typhoon - for about a year has been an active member of the community and one of the main contributors. In general, we again have something to talk about.
- Good day. Tell us briefly about yourself.
- Hello. My name is Egor, recently I became the head of the iOS department at Rambler & Co. A graduate of the Faculty of Radio Electronics of the Moscow Aviation Institute. While still on the third course, I took up mobile development, so after graduating from the university I decided not to follow the path of information protection and then continued to develop under iOS.
')
In Rambler & Co came two years ago, before that he worked in a small outsourcing company. In addition to the main work, I devote a lot of time to participating in the life of the community - articles, speaking at conferences, open source projects. I organize the one-month-two-month Rambler.iOS mip, and I try to constantly perform there myself. By the way, at the end of the post there will be a video, like the last time I cried about how difficult it is to do a normal pagination in mobile applications. I also keep my small blog .
- You are engaged in iOS development in Rambler & Co. When you came, what were your goals?
“When I came here two years ago, we had a small mobile development department, Four iOS nicks and a couple of Android players. At that time, everyone was sitting together, we had one head of mobile development and basically everything we did was supported by legacy code of old mobile applications. They were really old, the code was written in some bearded years and there was a complete horror. A little later, a separate structural unit called Rambler Digital Solutions was formed at the Rambler, which included all the techies. It has a matrix structure, that is, everything is divided into several departments. And since then everything has become much better.
At that moment, my former manager German Saprykin came to us, with whom we once started working on the Rambler project. Mail. Just when we had it, everything went on the amendment and we began to adjust the development processes. A rather vague definition, which includes a bunch of all sorts of different things: development standards, teamwork, code review, continuous integration, continuous delivery, knowledge sharing - and so on. In particular, we have implemented the practice of unit-testing and moreover - on some projects we have adapted TDD, mainly when developing the service layer. And the department began to grow like an avalanche.
At that moment we stopped supporting old projects. All efforts were focused on writing new products. I was then engaged in Rambler. Mail, the first release was a year ago. This just turned out to be an indicator of how well and efficiently we began to make mobile apps. It would seem that the mail program, a complex product, a lot of logic, but at the start we had a crash-free in the region of 99.9%. This is a very good result.
Now we are in a state of continuous development, we are organizing various work processes, including the Continuous Delivery. We are still actively working on project status Dashboard. In the department there will be a large plasma, which will display statistics on all projects: how many unit tests, how many crash-free and everything in this spirit.
One of the important milestones in the development of the team was the adoption of common architectural standards for all developed applications. First, it is the use of n-tier architecture, most often consisting of two layers: presentation - everything related to the display of specific screens, and business logic - an independent business logic, which includes working with the network, data caching, synchronization mechanisms.
Let's dig a little deeper. Instead of the standard MVC at the Presentation level, we use the VIPER architectural approach, which allows us to achieve maximum modularity, testability and reusability of screen components. VIPER, by the way, is practically our own topic. During its use, we wrote a bunch of articles and components to work with it. And, of course, they started spamming the conferences. As my colleague Sergey Krapivensky aptly noticed, we are like Affectionate May - we also have the same theme in different parts of Russia at the same time (by the way, his performance on CodeFest ). To build a layer of business logic, we use the SOA model, dividing it into independent services that work with a single business entity.
Now we have 25 people in the department. In addition to working projects, we devote a lot of time to various open source things. For example, we have such a popular code generator, which we wrote for ourselves, then we decided to zaopensorsit and sort of went into the people. In addition, we often participate in various conferences. Just a year ago, they began to hold their meetings, and after that we began to be invited to larger conferences (such as, in fact, Mobius ). We continue to recruit new employees, we have new projects and new tasks.
And, of course, during my work at Rambler & Co, I managed to participate in several interesting projects: Rambler. Mail, Rambler. News and not yet released in LiveJournal production. There were, of course, sad moments - for example, the development of a geolocation chat that had not seen the light of peer-to-peer, which I still remember and weep about, put its whole heart into it.
- Typhoon Framework. Tell in brief about him? What role do you play in its development?
- Typhoon is the most popular and frequently used DI container for Objective-C. The first version of it came out about three years ago. This is the cement that binds together all the components of our applications. Typhoon is embedded in our application and it allows you to take the configuration of all dependencies, create all objects, initialize the dependency graph somewhere to a higher level. This allows decomposing the modules of our application. All components become as independent as possible, do not know anything about each other and implement the DI-principle.
I joined the Typhoon contributors team last year. It all started when I talked about Typhoon on a local mitap, why it’s good and why it should be used. After that, I wrote a series of articles on Habré about what Typhoon is and how it works. And at the same time, I myself found some problems in Typhoon, I myself relied on their rules, sent re-requests. And then they called me to the main team.
Of the interesting features I have implemented, it is possible to highlight support for working with several stpryboards, advanced container activation mechanisms, and processing the logic of using configs. Now I am finishing a major task - adding special TyphoonStoryboardDefinition, which will allow working with controllers created from storyboard just like with any other objects. For example, it will be possible to manage their life cycle.
Now we are actively preparing for the release of version 4.0 with the support of a new cool syntax and a separate project for working with swift. At present, the typhoon syntax is very complex and cumbersome, but everything should be easier and more native. The entry threshold will decrease.
Working with Typhoon gave a strong impetus to my development as a specialist - this is a very large project, which brings together a huge number of interesting and unusual technical solutions. In addition, a team of strong developers is closely working on him - our compatriot Alexei Garbarev, a programmer with n-year experience Jasper Blues and German Saprykin already mentioned by me. The guys not only helped me to understand the logic of the framework, but also simply connected to various technical and architectural discussions, which in many ways influenced my views on the development.
I appeal to colleagues from the world of iOS development - allocate at least a few hours a week to work on an open source project. This benefits not only the community, but you as well. And Typhoon for the kind of such a project is great, now we open about 30 Issues.
- Tell us about the features of Typhoon Framework (autoinjection, etc.)
- First, Typhoon is cool because the main team that develops it, started to do it to fit their needs. In most of the time they are engaged in quite large projects for different customers. And they understand what they really need, and they initially did the framework for themselves.
That is why Typhoon is in fact not just a primitive DI-container, it allows the user to work with many different chips. For example, these are Typhoon-configs. You can enter data into configs, and they can be injected into our objects just like any other dependencies. This can be useful for constructor applications. We have it, for example, Rambler. Kassa.
For example, in the regions it is not convenient to use the entire application Rambler. Kassa and they can order a branded application. We have a common container application, from which we automatically collect branded versions on the fly, changing configs, where the color schemes, API data and so on are announced.
There are many interesting things about Typhoon for testing.
In fact, the best for me will tell the cycle of my articles on Habré about working with Typhoon - starting from a general acquaintance and ending with just listing its interesting features.
- Let's talk about scaling iOS-applications for, in fact, Rambler applications. How was it implemented?
- If we talk about scaling development, everything is interesting here. As I said, we have a team of 25 people. In other companies, programmers are divided by product teams. You come to work, for example, not in mail.ru, but in the search command for mail.ru. You work in a small department and with other iOS-nicknames you can never see. Maximum shared chat. Accordingly, each team has its own stack of technologies, its own processes, its own approaches to development. And team experience circulates only within this team.
We are all different. We all sit side by side and work in the same department, and we have a widespread rotation between projects. It is clear that the business side is, of course, a problem. He has his own team that makes the project, and they understand that changing the developer can lead to mistakes and loss of time. We were faced with the task of using universal tasks and universal approaches so that the transition between projects would not affect anything. A large role in this was played by a single approach to the architecture of applications. We agreed that the application is divided into several layers and described common approaches to the architecture of each layer. Due to the fact that all our applications are quite similar, it helps a new person to easily integrate into the process. In addition, we actively maintain detailed technical documentation of all projects.
- Why do you use Typhoon, but not “invent your own bike”?
- I will have a separate slide on this topic in my speech . There is a section in which I tell legends and myths about Typhoon. One of the myths is that you can write your own framework. What can I say to that? Typhoon greatly reduces the amount and complexity of the code responsible for creating object graphs and passing dependencies when navigating between screens. He gives us centralized dependency management without the flaws of his “bike”. Your "bicycle" is almost always some kind of service locator. Their problems are known and a lot of articles have been written about them. The integration of Typhoon into the project is very simple and everything that you may need and even more is implemented in it.
We do not see anything problematic or dangerous in the use of third-party components, especially those that have been tested by the community and time. The time we could spend writing our bike is better spent on something really useful. Say, the organization of the next Rambler.iOS or the implementation of a new feature in Generamba.
- What will your Mobius report be on June 4th?
- About a year ago, I already talked about Typhoon. After that, I and the other guys from our team mentioned it in their speeches. Unfortunately, this led to a small local HYIP - many of our guests began to embed it in their projects, not fully understanding what particular benefits it could bring to them. For some, it caused disappointment in the spirit of "I can write the same thing with my hands in five lines," for someone - chaos in the code.
This time I want to tell you a little about something else - my performance does not revolve around the Typhoon device and its syntax, but around specific juz-cases in which it helps in one way or another. Something like a set of small stories of the form "problem-> solution-> Typhoon". I hope that through the prism of these examples they will see their real tasks and will be able to make an informed choice whether they need Typhoon or not.
___________
Useful links:
- The promised video of the correct pagination ;
- Egor's report on Mobius 2016 (St. Petersburg, June 4);
- All reports from Mobius on iOS development.
- Good day. Tell us briefly about yourself.
- Hello. My name is Egor, recently I became the head of the iOS department at Rambler & Co. A graduate of the Faculty of Radio Electronics of the Moscow Aviation Institute. While still on the third course, I took up mobile development, so after graduating from the university I decided not to follow the path of information protection and then continued to develop under iOS.
')
In Rambler & Co came two years ago, before that he worked in a small outsourcing company. In addition to the main work, I devote a lot of time to participating in the life of the community - articles, speaking at conferences, open source projects. I organize the one-month-two-month Rambler.iOS mip, and I try to constantly perform there myself. By the way, at the end of the post there will be a video, like the last time I cried about how difficult it is to do a normal pagination in mobile applications. I also keep my small blog .
- You are engaged in iOS development in Rambler & Co. When you came, what were your goals?
“When I came here two years ago, we had a small mobile development department, Four iOS nicks and a couple of Android players. At that time, everyone was sitting together, we had one head of mobile development and basically everything we did was supported by legacy code of old mobile applications. They were really old, the code was written in some bearded years and there was a complete horror. A little later, a separate structural unit called Rambler Digital Solutions was formed at the Rambler, which included all the techies. It has a matrix structure, that is, everything is divided into several departments. And since then everything has become much better.
At that moment, my former manager German Saprykin came to us, with whom we once started working on the Rambler project. Mail. Just when we had it, everything went on the amendment and we began to adjust the development processes. A rather vague definition, which includes a bunch of all sorts of different things: development standards, teamwork, code review, continuous integration, continuous delivery, knowledge sharing - and so on. In particular, we have implemented the practice of unit-testing and moreover - on some projects we have adapted TDD, mainly when developing the service layer. And the department began to grow like an avalanche.
At that moment we stopped supporting old projects. All efforts were focused on writing new products. I was then engaged in Rambler. Mail, the first release was a year ago. This just turned out to be an indicator of how well and efficiently we began to make mobile apps. It would seem that the mail program, a complex product, a lot of logic, but at the start we had a crash-free in the region of 99.9%. This is a very good result.
Now we are in a state of continuous development, we are organizing various work processes, including the Continuous Delivery. We are still actively working on project status Dashboard. In the department there will be a large plasma, which will display statistics on all projects: how many unit tests, how many crash-free and everything in this spirit.
One of the important milestones in the development of the team was the adoption of common architectural standards for all developed applications. First, it is the use of n-tier architecture, most often consisting of two layers: presentation - everything related to the display of specific screens, and business logic - an independent business logic, which includes working with the network, data caching, synchronization mechanisms.
Let's dig a little deeper. Instead of the standard MVC at the Presentation level, we use the VIPER architectural approach, which allows us to achieve maximum modularity, testability and reusability of screen components. VIPER, by the way, is practically our own topic. During its use, we wrote a bunch of articles and components to work with it. And, of course, they started spamming the conferences. As my colleague Sergey Krapivensky aptly noticed, we are like Affectionate May - we also have the same theme in different parts of Russia at the same time (by the way, his performance on CodeFest ). To build a layer of business logic, we use the SOA model, dividing it into independent services that work with a single business entity.
Now we have 25 people in the department. In addition to working projects, we devote a lot of time to various open source things. For example, we have such a popular code generator, which we wrote for ourselves, then we decided to zaopensorsit and sort of went into the people. In addition, we often participate in various conferences. Just a year ago, they began to hold their meetings, and after that we began to be invited to larger conferences (such as, in fact, Mobius ). We continue to recruit new employees, we have new projects and new tasks.
And, of course, during my work at Rambler & Co, I managed to participate in several interesting projects: Rambler. Mail, Rambler. News and not yet released in LiveJournal production. There were, of course, sad moments - for example, the development of a geolocation chat that had not seen the light of peer-to-peer, which I still remember and weep about, put its whole heart into it.
- Typhoon Framework. Tell in brief about him? What role do you play in its development?
- Typhoon is the most popular and frequently used DI container for Objective-C. The first version of it came out about three years ago. This is the cement that binds together all the components of our applications. Typhoon is embedded in our application and it allows you to take the configuration of all dependencies, create all objects, initialize the dependency graph somewhere to a higher level. This allows decomposing the modules of our application. All components become as independent as possible, do not know anything about each other and implement the DI-principle.
I joined the Typhoon contributors team last year. It all started when I talked about Typhoon on a local mitap, why it’s good and why it should be used. After that, I wrote a series of articles on Habré about what Typhoon is and how it works. And at the same time, I myself found some problems in Typhoon, I myself relied on their rules, sent re-requests. And then they called me to the main team.
Of the interesting features I have implemented, it is possible to highlight support for working with several stpryboards, advanced container activation mechanisms, and processing the logic of using configs. Now I am finishing a major task - adding special TyphoonStoryboardDefinition, which will allow working with controllers created from storyboard just like with any other objects. For example, it will be possible to manage their life cycle.
Now we are actively preparing for the release of version 4.0 with the support of a new cool syntax and a separate project for working with swift. At present, the typhoon syntax is very complex and cumbersome, but everything should be easier and more native. The entry threshold will decrease.
Working with Typhoon gave a strong impetus to my development as a specialist - this is a very large project, which brings together a huge number of interesting and unusual technical solutions. In addition, a team of strong developers is closely working on him - our compatriot Alexei Garbarev, a programmer with n-year experience Jasper Blues and German Saprykin already mentioned by me. The guys not only helped me to understand the logic of the framework, but also simply connected to various technical and architectural discussions, which in many ways influenced my views on the development.
I appeal to colleagues from the world of iOS development - allocate at least a few hours a week to work on an open source project. This benefits not only the community, but you as well. And Typhoon for the kind of such a project is great, now we open about 30 Issues.
- Tell us about the features of Typhoon Framework (autoinjection, etc.)
- First, Typhoon is cool because the main team that develops it, started to do it to fit their needs. In most of the time they are engaged in quite large projects for different customers. And they understand what they really need, and they initially did the framework for themselves.
That is why Typhoon is in fact not just a primitive DI-container, it allows the user to work with many different chips. For example, these are Typhoon-configs. You can enter data into configs, and they can be injected into our objects just like any other dependencies. This can be useful for constructor applications. We have it, for example, Rambler. Kassa.
For example, in the regions it is not convenient to use the entire application Rambler. Kassa and they can order a branded application. We have a common container application, from which we automatically collect branded versions on the fly, changing configs, where the color schemes, API data and so on are announced.
There are many interesting things about Typhoon for testing.
In fact, the best for me will tell the cycle of my articles on Habré about working with Typhoon - starting from a general acquaintance and ending with just listing its interesting features.
- Let's talk about scaling iOS-applications for, in fact, Rambler applications. How was it implemented?
- If we talk about scaling development, everything is interesting here. As I said, we have a team of 25 people. In other companies, programmers are divided by product teams. You come to work, for example, not in mail.ru, but in the search command for mail.ru. You work in a small department and with other iOS-nicknames you can never see. Maximum shared chat. Accordingly, each team has its own stack of technologies, its own processes, its own approaches to development. And team experience circulates only within this team.
We are all different. We all sit side by side and work in the same department, and we have a widespread rotation between projects. It is clear that the business side is, of course, a problem. He has his own team that makes the project, and they understand that changing the developer can lead to mistakes and loss of time. We were faced with the task of using universal tasks and universal approaches so that the transition between projects would not affect anything. A large role in this was played by a single approach to the architecture of applications. We agreed that the application is divided into several layers and described common approaches to the architecture of each layer. Due to the fact that all our applications are quite similar, it helps a new person to easily integrate into the process. In addition, we actively maintain detailed technical documentation of all projects.
- Why do you use Typhoon, but not “invent your own bike”?
- I will have a separate slide on this topic in my speech . There is a section in which I tell legends and myths about Typhoon. One of the myths is that you can write your own framework. What can I say to that? Typhoon greatly reduces the amount and complexity of the code responsible for creating object graphs and passing dependencies when navigating between screens. He gives us centralized dependency management without the flaws of his “bike”. Your "bicycle" is almost always some kind of service locator. Their problems are known and a lot of articles have been written about them. The integration of Typhoon into the project is very simple and everything that you may need and even more is implemented in it.
We do not see anything problematic or dangerous in the use of third-party components, especially those that have been tested by the community and time. The time we could spend writing our bike is better spent on something really useful. Say, the organization of the next Rambler.iOS or the implementation of a new feature in Generamba.
- What will your Mobius report be on June 4th?
- About a year ago, I already talked about Typhoon. After that, I and the other guys from our team mentioned it in their speeches. Unfortunately, this led to a small local HYIP - many of our guests began to embed it in their projects, not fully understanding what particular benefits it could bring to them. For some, it caused disappointment in the spirit of "I can write the same thing with my hands in five lines," for someone - chaos in the code.
This time I want to tell you a little about something else - my performance does not revolve around the Typhoon device and its syntax, but around specific juz-cases in which it helps in one way or another. Something like a set of small stories of the form "problem-> solution-> Typhoon". I hope that through the prism of these examples they will see their real tasks and will be able to make an informed choice whether they need Typhoon or not.
___________
Useful links:
- The promised video of the correct pagination ;
- Egor's report on Mobius 2016 (St. Petersburg, June 4);
- All reports from Mobius on iOS development.
Source: https://habr.com/ru/post/300886/
All Articles