User
Всем привет!
Я уже давненько не писал и подзабыл, как это делается, но хочу поделиться информацией, которая многим может пригодиться. Ведь ко мне постоянно пристают с вопросами, вроде:
Пост вышел длиннее, чем планировалось, — я попытался описать все моменты, которые вам нужно учесть. В этой статье я покажу разные структуры удаленных команд, как и почему удаленные команды работают иначе, когда стоит, а когда не стоит работать удаленно, и, наконец, приведу реальные примеры. Спасибо за чтение.
И раз… два… три… Поехали!
Иногда молодые команды разработки охватывает неразбериха.
Это случается в тот момент, когда они ещё не до конца разобрались, что такое эджайл; проджект и продакт спорят, кто из них кто, а задачи каждый ведёт сам по себе. Или все уже всё знают, но планировать спринты не получается — задачи не прорабатываются, демо и ретро проходят нерегулярно.
У нас тоже была похожая история, но мы нашли свой путь.
Это рассказ от команды личного кабинета Яндекс.Кассы, и подробнейшая инструкция для тех, кто хочет улучшить своё планирование.
История, которую я расскажу, началась 13 лет назад на уроке информатики. Мы с друзьями-семиклассниками решили все задачи на Паскале и весело играли в первый Quake. Наша учительница увидела это, подошла ко мне и сказала всего одну фразу, которая перекосила мою картину мира: «Если ты хочешь играть в игры на уроке, пиши их сам». С тех пор я эпизодически делаю игры. Одна из них — футбольный симулятор, о котором и пойдёт речь.
Это захватывающая история про мой путь разработчика, недоделанные проекты и о том, почему иногда их и не нужно доделывать.
Особенностью данного тестирования является некая приближенность к реальным условиям, когда есть необходимость определять страну одного посетителя на лету за один запуск скрипта, то есть: один запуск скрипта — один ip-адрес. В подобном тестировании от zapimir использовался другой принцип, который, как мне кажется, имеет мало общего с реальной необходимостью: один запуск скрипта — определение нескольких тысяч ip-адресов в цикле.Да, тщательное исследование. Но всё-таки есть способы, чтобы тебя заблокировать. *ухмыляется*
В 2020 году библиотека Natasha значительно обновилась, на Хабре опубликована статья про актуальную версию. Чтобы использовать инструменты, описанные в этом тексте, установите старую версию библиотекиpip install natasha<1 yargy<0.13.
Раздел про Yargy-парсер актуален и сейчас.
Natasha — это аналог Томита-парсера для Python (Yargy-парсер) плюс набор готовых правил для извлечения имён, адресов, дат, сумм денег и других сущностей.В статье показано, как использовать готовые правила из Natasha и, самое главное, как добавлять свои с помощью Yargy-парсера.
Вероятно, в любой команде рано или поздно возникает вопрос создания и утверждения стандартов кодирования. На первый взгляд, задача вполне тривиальная. Но лишь в том случае, когда решается на раннем этапе развития проекта. Тогда разработчикам необходимо лишь выбрать и применить один из популярных стандартов, и чаще всего этот выбор за них делает фреймворк, который они используют.
В нашем случае всё не так просто. Проект, над которым мы работаем, начал свою жизнь ещё до того, как различным стандартам и описаниям лучших практик в среде разработки стали уделять большое внимание. В том числе, задолго до появления столь популярных ныне PSR стандартов для PHP. По этим причинам задача стандартизации кода не ставилась на более ранних этапах, а теперь – предстала нашей команде в качестве вызова.
В этой публикации мы расскажем о том, как пришли к пониманию необходимости единого code style, и выработали методы его постепенного внедрения в масштабный проект. Этот опыт может быть интересен тем, кто пока не использует стандартизацию, но уже ощущает в этом потребность.
