Feed, why so complex?

A feed is probably the most common data representation in mobile applications. Just have a look at any app on your phone - Facebook, Instagram, Tweetbot, and even your favourite e-mail or RSS client. Feeds are everywhere. Despite it's a pretty common task we still got a lot of questions about its implementation. The problem gets even harder when there are different content types in one feed.

I've faced this problem not very long ago in LiveJournal application. Our product manager suddenly decided to add new content types in post feeds - marketing notifications, like don't forget to turn push-notifications on, and beloved advertisements.

How We Interview

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.

Divide et Impera

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.

The Story of One Unit Test

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.

Promises and Ads

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.