Рубрика «процесс»

Как воспитать здорового довольного червя: разбираем инструкцию 1910 года - 1
В общем, я давно хотел рассказать вам про шелкопряда

Стимпанк с дирижаблями и авиацией казался в Российской империи светлым будущим. Но вот только возможностей обычных материалов не хватало. В этот момент мы решили обратиться к биотеху — конкретно, шелковичному червю, способному делать нанонити того времени — шёлк.

В стране были уже и единичные деревья, и плантации, но с 1720 года шёлка понадобилось в разы больше. Пётр I основал большие плантации шелковичных деревьев. Но несмотря на все старания, червь у нас часто болел, чах и вообще капризничал. Тем не менее, в Астрахани на местном сырье к концу восемнадцатого века работало 20 шелковых и 70 полушелковых фабрик.

В СССР в доперестроечные времена производилось до 900 тонн коконов в год. Потом постепенно шёлк вытеснили синтетические материалы. Но речь не об этом.

Сейчас я буду учить вас выращивать тутовое дерево и воспитывать червя. На самом деле, предлагаю почитать инструкцию 1885 — 1910 года по процессу. Обещаю, она прекрасна ровно как и захватывающа. По дороге нам встретятся Луи Пастер не с тем подвигом и другие интересные люди.

Ну и, конечно, я отсканировал свой экземпляр и, обсудив с юристами, могу сказать, что книга доступна для всеобщего пользования.
Читать полностью »

Портал тестовых сред, или Спасём наш девопс - 1

Пару лет назад мы чувствовали себя в каком-то сюрреалистическом сне. Все вокруг шли в облако для тестирования (удобно же разворачивать-сворачивать тестовые среды), а мы пытались выяснить, какие инструменты «из коробки» нужно поставлять. Для этого мы вместе с заказчиками разбирались, как устроены процессы девопса. И оказалось, что только единичные компании в России как-то грамотно применяют автоматизацию.

Сразу поясню, что мы по большей части общались или с теми, кто занимается разработкой в компании до 150–200 человек, или с производствами, где с ИТ традиционно тяжело. У компаний крупнее обычно есть и процесс, и собственное облако, и к нам они приходят за резервным размещением.

Производство обычно хорошо отлажено. Есть цикл, план релизов, есть цель, код идёт к цели вместе с разработчиками.

Тестирование и QA тоже хорошо отлажены чаще всего.

А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA. Читать полностью »

Очень хочу поделиться с вами переводом статьи про эксперимент с моб-программированием от одного из его создателей, Вуди Зила. Это когда вся команда сразу работает за одним компьютером. Как парное программирование, только групповое. Я бывший Java-разработчик и тимлид с 11-летним стажем, и раньше меня бы удивил такой подход. Оказалось, работает очень интересно. Внутри — как взаимодействуют участники, какие преимущества им это даёт, и с какими сложностями они столкнулись. Это отчёт об эксперименте, который уже три года успешно продолжается в команде Вуди. Полезно, если вы хотите настроить такое у себя.

Перевод

Оригинал: статья Вуди Зила.
Оригинальное название: «Моб-программирование — командный подход к работе».
Примечание: Статья переведена с согласия автора, в переводе максимально сохранена авторская стилистика.

1. Введение

Эксперимент — от парного программирования к программированию всей командой - 1 Моб-программирование или моббинг — это подход к разработке программного обеспечения, при котором вся команда целиком работает над одним и тем же, в одно и то же время и в одном и том же месте за одним компьютером. Это похоже на парное программирование [PAIR], где двое человек сидят за одним компьютером и совместно работают над одним и тем же кодом в одно и то же время. При моб-программировании эта совместная работа распространяется на всех в команде, при этом всё ещё используется только один компьютер для написания кода.Читать полностью »

Быстрая проверка десятков гипотез: как мы вырываемся из рутины и устраиваем себе обсуждение в другом городе - 1

У нас в каждой из шести команд разработки бэклог расписан примерно на два года вперёд с учётом почти неминуемого рефакторинга, фиксов, фич и хотелок продуктологов. Внутри всё может ездить по приоритетам, и некоторые большие блоки то становятся важнее, то убираются, то туда добавляется что-то новое. Но всегда есть понимание, куда копать в ближайшие месяцы.

У такой системы, кроме кучи плюсов, есть два очевидных недостатка:

  1. Это банально скучно, а скука — это не то, что мотивирует нас писать код.
  2. Накапливается много гипотез, которые по обычному процессу падают куда-то в конец бэклога, но каждая из которых может дать быстрый результат. А может и не дать. Некоторые из них интересные.

В обычном режиме разбирать эти гипотезы сложно, потому что нужно взаимодействие продуктолога, бизнес-человека (обычно руководителя направления) и ещё пары человек из других команд разработки. То есть когда у тебя есть два свободных часа, всё равно не сделать. А поскольку мы часто зарабатываем на том, что протаптываем дорожку в бизнесе к новым интерфейсам и новым фичам, проверка гипотез — это жизнь.

Сначала мы выделяли время внутри офиса и делали в общем рабочем процессе. Оказалось, что, если проверять как можно быстрее, получаются средние решения. Чтобы повысить качество, надо вырваться из общей рутины.

Поэтому мы три раза уже выезжали в какой-нибудь иностранный город и работали там.Читать полностью »

Как мы развивали ИТ в «Леруа Мерлен»: пересборка двигателя на ходу - 1

Четыре года назад база клиентов велась отдельно в каждом магазине плюс ещё одна — на сайте.

В предыдущих сериях: три года назад мы решили, что нужно делать свою разработку в России. Два года назад начали писать собственный код вместо того, чтобы модифицировать форк кода материнской компании. Сегодняшняя история будет про то, как мы переключались с одного большого легаси-монолита на кучу маленьких микросервисов, соединённых своего рода шиной (оркестратор).

Самый простой юзеркейс: сделать заказ через сайт и забрать его в реальном магазине «Леруа Мерлен» в России. Раньше заказы интернет-магазина обрабатывались в другом приложении вообще и по другой схеме. Теперь нам нужна была омниканальная витрина, чтобы любой заказ был разбит на интерфейс: касса в магазине, мобильное приложение, терминал в магазине, сайт — что угодно. Если вы поставите Linux на микроволновку — пускай будет микроволновка. Главное, чтобы какие-то интерфейсы могли стучать по API к беку и говорить, что вот тут надо оформить такой-то заказ. И получали на это внятный ответ. Вторая история была с запросами наличия и свойств товара из его карточки.

На фронте (скоро и про это напишем) у нас монстр — AEM, а за ним в беке было два больших приложения: OPUS и MoVe. Первое — это база данных свойств каждого товара (от габаритов до описания), второе — отвечает за чекаут, то есть монолит касс. Если сильно упростить.Читать полностью »

Привет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.

Дело в том, что «Леруа Мерлен» есть во многих странах. Головная компания — во Франции, называется ADEO. Там пишут код под Францию, Италию, Испанию и Россию. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:

Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек - 1

Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Накатывались они примерно за полгода и не всегда правильно. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.

Полугодовой цикл неспешной головной компании нам не подходил. Естественно, мы предложили написать свой код, отдать на ревью и подождать внедрения… Правда, из этого ничего хорошего не вышло.Читать полностью »

Как мы сделали форк российского Леруа Мерлен на Казахстан - 1
Нужно было успеть адаптировать все ИТ-системы до конца строительства магазина.

В 2016 году было решено открыть магазин в Казахстане (в Алматы). В логике группы компаний Adeo (это все магазины Leroy Merlin по всему миру) на каждую новую страну нужно создавать отдельный бизнес-юнит со своей инфраструктурой и всем-всем-всем. Например, Украина — это отдельный юнит из пяти магазинов со всеми собственными подразделениями, службами и ИТ-процессами.

На Казахстан мы решили (впервые в истории развития компании) сделать форк российской инфраструктуры, фактически расширяя наши системы на новый регион. Почему? Потому что закупки, цепи поставок, юридические и финансовые службы централизованы. Рынки близки. Законодательство близкое, хотя и есть свои особенности (каждый департамент выявлял для себя отличия с помощью коллег из юротдела). Это евразийский Таможенный союз. У нас было 90 магазинов в России, и можно было закупать на условиях, которых в Казахстане поставщики просто не дадут, да и местного производства не так много. У нас много отлаженных процессов, работающее ПО и так далее.

Осталось только чуть-чуть докрутить пару ИТ-систем. Простая работа года на полтора, потому что переписать пришлось не всё, но очень-очень многое. Началось с того, что, оказывается, надо подписать дополнительные соглашения с 800 поставщиками, чтобы их товары правильно маркировались и сертифицировались при необходимости. Чтобы в Казахстане их можно было правильно учесть, соответственно и правильно напечатать ценник, на котором по закону наименование товара должно быть на казахском и русском языках.

На этом сюрпризы только начинались. Читать полностью »

Визуализация дерева приматов

Станислав Дробышевский в начале года опубликовал подробное дерево происхождения приматов. Версия в ПДФ

Комментаторы во «Вконтакте» просили интерактивную версию (1, 2, 3, 4), потому что её удобнее изучать и проще обновлять при появлении новых данных.

Мы с Олей Моховой решили помочь палеоприматологии и сделали прототип на d3js.

Читать полностью »

Что такое сетевой сервис? Это программа, которая принимает входящие запросы по сети и обрабатывает их, возможно, возвращая ответы.

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

Выбор способа обработки запросов имеет далеко идущие последствия. Как сделать чат-сервис, выдерживающий 100.000 одновременных соединений? Какой подход выбрать для извлечения данных из потока слабоструктурированных файлов? Неправильный выбор приведет к пустой трате сил и времени.

В статье рассмотрены такие подходы как пул процессов/потоков, событийно-ориентированная обработка, half sync/half async паттерн и многие другие. Приводятся многочисленные примеры, рассматриваются плюсы и минусы подходов, их особенности и области применения.

Читать полностью »

Реальный дизайн-процесс. Пошаговый рассказ о том, как создать бизнес-ориентированный сайт - 1

По дизайну написано тысячи статей и записано столько же вебинаров, но начинающих специалистов заботит один и тот же резонный вопрос: «Так что же мне конкретно делать?!». В этом материале я на реальном примере поэтапно покажу, какие действия нужно совершать для создания дизайн-проекта, нацеленного на решение задач бизнеса.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js