Лабораторная работа: введение в Docker с нуля. Ваш первый микросервис

Привет, хабрапользователь! Сегодня я попробую представить тебе очередную статью о докере. Зачем я это делаю, если таких статей уже далеко и не одна? Ответов здесь несколько. Во-первых не все они описывают то, что мне самому бы очень пригодилось в самом начале моего пути изучения докера. Во-вторых хотелось бы дать людям к теории немного практики прямо по этой теории. Одна из немаловажных причин — уложить весь накопленный за этот недолгий период изучения докера (я работаю с ним чуть более полугода) в какой-то сформированный формат, до конца разложив для себя все по-полочкам. Ну и в конце-концов излить душу, описывая некоторые грабли на которые я уже наступил (дать советы о них) и вилы, решение которых в докере просто не предусмотрено из коробки и о проблемах которых стоило бы задуматься на этапе когда вас расприет от острого желания перевести весь мир вокруг себя в контейнеры до осознавания что не для всех вещей эта технология годна.

Что мы будем рассматривать в данной статье работе?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие
Читать дальше →

#Ускорение4X. Кастомизация целей команды

Генеральные цели перехода на #Ускорение4X мы обсудили. Теперь нужно сделать еще более важную штуку — учесть цели каждого участника команды. Мы же ускоряемся сами для себя, а не для начальника. Кстати, спасибо, что заминусовали публикацию про генеральные цели. Минусы освобождают от необходимости пытаться вам понравиться, т.е. от зла. Остается чистое намерение дать информацию. Чем и займусь. Итак, зачем кастомизировать цели? Вроде нормально они звучат — ускориться, научиться работать на форсаже, научиться переводить на форсаж. Неприятность в том, что цели звучат слишком нормально. Банально звучат, пошло и неискренне. И в них не слышно ничего вашего. Вам как будто опять ставят чужую цель, и говорят, что вы должны хотеть ее достичь. Такое сплошь и рядом есть во всех компаниях, от всех собственников и менеджеров. Что они там обычно говорят? Давайте увеличим продажи вдвое! Наша цель — войти в список Forbes! Мы хотим через 5 лет выйти на IPO! Наша цель — 5 новых продуктов через год! Ну и т.д. Еще там непонятные миссии добавляются,ценности сейчас модно стало писать, и подобную ересь. Что с ними не так, вы уже понимаете — там нет вас. Ни про вас, ни для вас, ни про ваше будущее. Вы как были винтиком, шпунтиком или целой шестеренкой, а может быть редуктором/мультипликатором, так и останетесь, пока не выкинут, или сами не уйдете. Никому нет до вас никакого дела. Все корпоративные культуры — искусственная хрень, все похлопывания шефа по плечу — прием из книги по менеджменту (вроде ...Далее...

#Ускорение4X. Генеральные цели

Все, вступления закончились, начинаем изучать практические приемы, из которых состоит #Ускорение4X.

Если вы — тот человек, который берется за внедрение #Ускорения4X в команде, то первый шаг придется сделать вам.

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

Я постараюсь объяснить цели, и дам пример согласования — его можно использовать в качестве подсказки. А можно не использовать, главное — результат. Но разговаривать с людьми придется вам. Не лишним будет всем дать ссылку на эту публикацию — если переживаете за свое красноречие. Читать дальше →

Agile коммуникация в распределенных командах, без пересекающихся рабочих часов

Главный вопрос этого поста: какие же изменения претерпевает agile коммуникация (и скрам, в частности), натягиваясь на распределенные команды?

Для этого, давайте сначала классифицируем коммуникацию:

  1. стратегические митинги (планирование / ретроспектива)
  2. ежедневную синхронизацию (в том числе daily standups)
  3. прояснение рабочих вопросов


image

Давайте добавим еще одно измерение! Если попробуем наложить вышеприведенную классификацию на географию, то появляются дополнительные срезы для вышепреведенного:
Читать дальше →

#Ускорение4X. Принцип № 0/3. Системное подчинение

Напомню, что мы изучаем практику #Ускорение4X.

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

Не знаю, как вы, а я наблюдаю за проектами изменений лет 10. Кроме наших любимых ИТ-проектов (которые ведь тоже — изменения), много приходилось и видеть, и делать самому обычных, организационных изменений.

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

Но еще важнее другой, побочный итог — мы убедились, что методика_такая-то — фуфло. Потому что не работает.

Так часто бывает, например, с внедрением принципов agile, или конкретно методики скрам. Так будет и с методикой #Ускорение4X, если действовать с той же ключевой ошибкой — главной ошибкой внедрения изменений в нашей стране.

Ошибка, увы, настолько банальна, что вы мне не поверите. Это не страшно, если не поверите, но если начнете наблюдать за внедрением изменений вокруг вас — в компании, в городе, в стране, то убедитесь, что дело именно в этом. Читать дальше →

#Ускорение4X. Принцип № 0/2. Скрам-мастер

Продолжаем тему ускорения разработки в 4 раза.

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

Сегодня — второй базовый принцип, без которого ничего не получится: команде нужен правильный скрам-мастер.

Если вы использовали скрам или любую другую методику, требующую наличия скрам-мастера, то с вероятностью 99 % у вас был неправильный скрам-мастер. Увы, но и скрам у вас в этом случае был неправильный — на уровне детского сада.

Вы в этом не виноваты.

Виноваты горе-консультанты — те, что решили заработать на хайповой теме, и применили к философии (а скрам — это философия) методы маркетинга, чтобы превратить ее в ПРОДУКТ.

Их цель — продать продукт. Кто купит продукт, на коробке которого написано «вам придется много думать, иначе ни хрена не выйдет»? Когда рядом на полке целый патронташ серебряных пуль? Покупай, и будет тебе счастье!

Мы это упущение раскурили, рассказываем вам. Читать дальше →

Как мы достигли идиллии, работая без менеджеров. Часть 2. Тайная комната

Привет тебе, дорогой читатель! В предыдущей статье я рассказывал о том, как 28 разработчиков смогли выстроить рабочий процесс, в котором нет роли менеджера. Мы продолжаем с удовольствием работать и выпускать сложные фичи одну за одной. Скоро нам предстоят бессонные ночи перед выпуском релиза. И затем самый приятный этап — технический спринт и проведение ретро релиза, а также мероприятия по планированию следующего релиза.

Сегодня я расскажу об активностях, которые обеспечивают максимальную прозрачность рабочего процесса и позволяют не выпадать разработчикам из событий, происходящих в целом компании и в других командах в частности. Хотите выстроить качественные процессы и работать с удовольствием? Добро пожаловать под кат!


Читать дальше →

Гибкая методология для мобильной разработки

image

Agile development is especially useful for mobile app development. The agile methodology provides our clients with a continuous feedback loop. Sourcebits mobile app design and development clients see milestones every 2-3 weeks. They aren’t left to wait until the very end of the project. Agile development for mobile apps means clients provide feedback every step of the way to ensure the success of the project. – Joe Chen, CTO, Sourcebits

Читать дальше →

#Ускорение4X. Принцип № 0/1. Изменяемая среда

Итак, мы хотим ускорить разработку в 4 раза. Нет, мы не хотим, мы уже ускорили. Вы хотите.
Серебряной пули, ускоряющей в 4 раза, нет. Есть целая обойма пуль разного калибра, типа, убойной силы и применимости в конкретной ситуации.

Я просто расскажу вам, как это делали мы. Какие нашли решения, фишки, подходы, философию. Нужно это вам или нет – решайте сами. Мы не навязываем. Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре. Тут же разработчики опытом обмениваются? Все спрашивающим будем ссылки давать.

На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.

Если согласны – под кат. Читать дальше →

Как сторимэп помогает не завязнуть в разработке нового продукта на годы

«Додо Пицца» развивается в США. В середине 2016 года мы открыли доставку в Оксфорде и быстро поняли, что предпочтения клиентов в США и России отличаются. Американцы — индивидуалисты. Они привыкли, что можно собрать пиццу из любых ингредиентов — пусть даже бекон с шоколадным соусом. Поэтому нам надо было сделать такой функционал для американских Додо. Мы назвали проект «Своя пицца».


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


Чтобы разобраться, мы использовали сторимэп. Этот инструмент помог спланировать работу и запустить «Свою пиццу» за 2,5 месяца. В статье рассказываем, как применяем сторимэп.

Читать дальше →
  • Новее
  • 1


Последние посты