July 23, 2016
We have a team over 25 iOS developers at the moment. Despite this is a pretty large number we're still looking for more people to come. In short, that means three things:
- We've got a lot of interviews every week
- Many collegues want to take part in this process and sharpen their interviewing skills
- You can apply too - our team and projects are really cool!
Till the last time this process was pretty chaotic. We didn't clearly understand what to ask, how to process the results and how to compare different candidates for one role. So I spent some time on researching and organizing it with a great help from my collegues - and we developed a noticable system.
April 17, 2016
This is just another story inspired by problems encountered in Rambler.Mail application. Our AppDelegate was really huge. And that wasn't great at all.
Spotlight, Handoff, state restoration, push notifications - all of this technologies require specific logic. Apple provided us with the only visible solution -
AppDelegate class. And we put these methods in it. Besides system callbacks, this class seems like a nice container for other things as well - CoreData setup, analytics integration, checking different permissions and showing onboarding screens. At the end
AppDelegate becomes a real mess, which is hard to read and understand.
April 10, 2016
What makes a clean test? Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code. What makes tests readable? The same thing that makes all code readable: clarity, simplicity, and density of expression. In a test you want to say a lot with as few expressions as possible.
Robert Martin, Clean Code
It's very easy to turn your unit tests into an unreadable and unmaintainable mess. The main reason of such attitude is a wrong understanding of test cases role. It's not "write once, never read". It's not just in verifying your methods behaviour. Unit tests are all about documentation. It's "write once, refactor often, consult daily". The easier a test is, the more it tells to a developer.
March 20, 2016
A promise is a really simple and easy to understand pattern. In general, it's just an object that represents a result of some action which is not finished yet. That's all, nothing more.
This simple concept reduces a complexity of asynchronous code a lot. Imagine that you don't have to write these awful nested completion blocks - every operation is synchronous. You just ask your service to return data - and it returns you something to work with.
February 28, 2016
I was working on Rambler.Mail project for the whole year. It's a client for one of the most popular Russian e-mail providers. The application itself is rather ordinary, it has the very same features you'd expect from an e-mail application - and nothing more. However, I spent a lot of time building a solid and maintainable architecture for both business logic and presentation layers.
One of the most interesting features was a rendering engine for displaying e-mail content. I won't dive into implementation details - all you need to know at the moment is that we used
Before I had a chance to refactor it I was switched to another project. To my great surprise I've encountered there a very similar task - I had to build a rendering engine for displaying blog posts. This time I was prepared well - I already knew how NOT to build such systems. So, instead of spaghetti code, I've used another approach - the cell containing
UIWebView was built using the VIPER architecture.