Just in case — ИНН у сетки филиалов будет общий, удачи в попытке их различить :)

Да, но ведь дело не в конвертации. Проблема в том, что просто БД на большой нагрузке – это тупо медленно :) И желательно иметь человека, который ее правильно приготовит.
Здесь MaxMind и SypexGeo имеют свои форматы баз, которые на нагрузке быстрее, чем «а давайте зальем csv в Postgres, у нас же хайлоад». А Дадата вообще убирает нагрузку с сервера и базы.

Такой формат сильно бьет по скорости работы с базой, как и конвертация в обычную БД.

Думаю, что Яндекс свою базу собирает, во всяком случае по РФ.

Да, в Европе с этим весело :) Меня находит в трех соседних странах периодически.

Трекинг пользователей и последующее сопоставление данных о них — это отдельная веселая история, которую, к сожалению, никто не расскажет :)

Да, интересный проект, на Go и в Докере. Интересно, какую базу они используют как основу?

Не знаю, как в Badoo, но крутой ручной тестировщик by design не получает меньше крутого автоматизатора :) Поэтому не понимаю ваш вопрос.

Бывает, и бывает очень хорошо :) Работаю в такой компании, продуктовая разработка, не перепродажа.

у меня нет времени час беседовать с каждым кандидатом и угощать его колой, наверное, мне просто меньше повезло в жизни.

Самое страшное, что можно сделать – нанять в команду неподходящего человека. Час – очень короткое время для хорошего собеседования, круто, что автор поста успевает :)

А я вот вам скажу, что не стоит.
Вам бы с этим военным подходом идти руководить в армию, но никак не в IT. Читаю комменты и любуюсь просто – должностная инструкция, формальные права. Упаси боже с таким работать, видно, что вы вообще не чувствуете людей и их потребности. Кнут, пряник – вы можете эту бинарную логику оставить для разработки, в менеджменте и общении с людьми все сильно сложнее и по-другому.
Формальный лидер как сущность опять же работает в армии, но не в разработке – если с вами плохо, люди просто уйдут, слишком много хороших мест и слишком мало разработчиков.

Автору спасибо за статью, она шикарная, очень интересный подход к тестированию автокомплита.
Ребята из Ахантера, я вот ваше API тестировал для имен (и даже в похожей статье сравнения вас упоминал), а потом для адресов. С именами ладно, вот по адресам много вопросов к вам возникло тогда :) А сейчас читаю ваш коммент и, простите, не удержусь его разобрать публично:

Вот, например, какая польза от того, что человек в подсказках увидит индекс и район города?

Про индекс не знаю, а вот про районы очень даже знаю :) Мне были нужны районы городов, чтобы стоимость доставки считать, а вы в них не умеете.

чаще всего магазины доставляют по своему городу

Что значит «чаще всего»? :) Много кто доставляет по всей России, потому что отправляет товар почтой по всей России. Будем предлагать пользователю выбрать город руками?

Координаты, индекс и прочую информацию об адресе можно получить уже после того, как пользователь завершит вводить адрес. Для этого у нас есть отдельное API.

То есть вы мне под предлогом «избыточности» отдаете куцые данные, а если мне надо больше данных – предлагаете для решения задачи юзать ваше платное API стандартизации адресов, прикручивать на бэкенд дополнительную логику обработки адресов, и считаете что это окей и называется «можно получить»? :) Нет, нельзя, во всяком случае очень неудобно. Зато есть офигенно полезный параметр request_process_time.

По крайней мере, в Ахантере вводить дом и кваритру в одну строку с адресом можно без проблем

Можно узнать, как? Мне вот ваше API Подсказок отдает пустой ответ на «санкт-петербург ул 2 жерновская д 26».

У меня был опыт работы во внешней команде, есть опыт разработки в команде с разработчиками – так вот скорость и качество разработки во втором случае это небо и земля. Внешняя команда играет в пинг-понг с разработчиками и не имеет общих интересов.

Все передовые банки давно перешли на Agile, где тестировщик – неотъемлемая часть команды любой разработки. Отдельно сидящие тестировщики – это архаизм :)

Интересно :) Мне всегда казалось, что тестирование отдельно от разработки не продать.

Да, это один из способов решения данной проблемы. Другие разработчики эффективны, но не всегда есть время :) а QA в идеале – такой же разработчик, который умеет писать код, только с экспертизой в тестировании. Если QA не пишет код и не знает кодовой базы, толку от него будет мало, это да.

Не смешивайте функциональные тест-кейсы от QA и кейсы, которые нужно проверить для отдельной функции и куска кода. Я про первые и не писал. Вы все правильно расписали про условные if и ветки и про их покрытие. Вопрос в том, что разработчик – человек, и может что-то забыть, а QA это увидит при код-ревью и подскажет. Или даст идей, что проверить. Или увидит, что тест ничего не проверяет на самом деле, или проверяет неправильно (и код работает неправильно). Затем и нужен. И да, QA должен хорошо знать приложение и код, чтобы уметь так делать.

Я вот даже и не пойму, вы троллите или серьезно пишете :)
Ну да, нагрузку можно по-разному моделировать, по сценариям – тоже можно. А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю. Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).

Если ни один из этих десятков тестировщиков не может настроить JMeter который эмулирует нагрузку в миллионы пользователей – вопрос, стоит ли вообще работать в такой «солидной компании».

QA вообще не должно быть никакого дела до наличия или отсутствия юнит-тестов.

Вот это вот очень интересно :) А разработчик сам придумает все покрытие? Уметь писать код != уметь тестировать, а тестировать свое же еще сложнее. В идеале QA накидает кейсов, разработчик напишет юниты, QA их отревьюит/дополнит, и только после этого можно считать что ваш кусок тестами закрыт.