Как стать автором
Обновить
9
0

Пользователь

Отправить сообщение
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 их отревьюит/дополнит, и только после этого можно считать что ваш кусок тестами закрыт.

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность