Disclaimer: автор не призывает экономить “на спичках”. Вряд ли стоит работать с заказчиком, с которым вы не можете себе позволить $5 на виртуалку в DO и $10 на Jira. Однако всегда есть сайд-проекты, личные эксперименты, случайные разработки на голом энтузиазме – на которые никаких денег не напасёшься, если покупать под каждую отдельный набор. Поэтому мне было интересно собрать full stack (полный комплекс) инструментов, позволяющих построить процесс от разработки до непрерывной интеграции, деплоя и мониторинга – в приватном (закрытом) проекте – исключительно на freeware или бесплатных тарифах публичых сервисов. Continue reading “Строим full-stack environment для приватных проектов на основе бесплатных инструментов”
Category: Работа
А как ты насчёт немного покодить?
Этот вопрос задают мне поголовно все работодатели. С первого взгляда ответ кажется очевидным, но… Всегда есть это “но”. Если рассматривать вопрос в лоб, то очевидно: предлагать “покодить” человеку, который более 15 лет работает менеджером, практически с нуля поставил ряд технологических и бизнес-процессов в UMI.CMS, неоднократно формировал успешные команды веб-разработчиков, но никогда в жизни официально не работал программистом, – по меньшей мере странно. Continue reading “А как ты насчёт немного покодить?”
Мои жизненные принципы
Будь пунктуален
Пренебрежение чужим временем просто невежливо само по себе. Хроническое опоздание на работу выглядит как нелепый мальчишеский протест с претензией на независимость.
Умей себя подать и “продать”
Держись уверенно и не скрывай свои способности. Плохие люди, встретившиеся тебе, в любом случае будут стремиться унизить твои достижения, чтобы “купить тебя по-дешёвке”. Хорошие люди, встретившиеся тебе, увидят твою уверенность в себе, начнут сами верить в тебя и в успех вашего общего дела.
Поменьше переживай о том, что думают о тебе другие
Большинство встретившихся тебе на улице людей тебя даже не заметят. Люди, с которыми ты работал год, забудут тебя через месяц. Следи за собой, но помни что люди прежде всего зациклены на себе самих.
За бизнесом стоят люди, а люди иррациональны
Эмоции, зависть, соперничество, личные амбиции – значат на порядки больше, чем цифры, факты, графики и аналитические исследования.
Выполняй мелкие обещания
Внимательно относись к словам “я подумаю”, “обсудим позже”, “это можно решить потом”. Люди запоминают эти слова как буквальные обещания подумать, обсудить и решить. Ждут, а затем разочаровываются в тебе. Выполняй эти обещания.
Умей концентрироваться
Нет ничего более нелепого, чем люди которые в рабочее время читают башорг, обсуждают вчерашние баталии в сетевом мультиплеере или политическую обстановку. Концентрируйся. Используй состояние потока, помидорные таймеры, внутренние ритуалы, всё что угодно.
Расти свой широкий профессионализм
Это единственный актив, цена которого постоянно растёт на фоне обесценивания всего остального мира – денег, вещей, техники и программного обеспечения.
Извиняйся, если принял точку зрения оппонента
Оппонент потратил на тебя, на спор с тобой, достаточное количество душевных сил, времени и эмоций. Сколько бы минут или лет не прошло с тех пор, если ты просто подумал про себя “мда, а он наверное был прав”, или даже осознал “блин, да ведь он прав”, принеси свои извинения за то что спорил.
Объясняй, если поменял своё мнение
Многие люди постоянно обдумывают то дело (бизнес, проект), в котором проводят основное время своей жизни. Иногда, после тяжёлых раздумий, кажется очевидным какое-то значительное изменение. Не думай, что ты окружён телепатами. Доведи изменение до людей ясно и чётко.
Смотри с разных сторон
Избегай единственных каналов информации, единственных точек зрения в споре, единственных мнений в обзорах. Абсолютной однополярной истины не существует.
Не стесняйся задавать наивные прямые вопросы
Легче всего – детям. Они ещё наивно смотрят на мир и не боятся спрашивать. Взрослые же часто используют отказ отвечать как средство манипуляции, или чтобы банально скрыть ложь. Если на твоей работе, в твоём офисе, не принято задавать вопросы – беги оттуда со всех ног.
Не смей унижать неспециалистов в твоей профессиональной области
Если ты умеешь сочинять трёхэтажные команды в консоли linux, или жонглировать сложными алгоритмами в программном коде, – это делает тебя богом не больше, чем для автослесаря – знание 8 отличий коленвала от распредвала.
Недостаток квалификации – не порок
Это всего лишь вопрос времени. Человек в твоей команде, знающий меньше тебя, за несколько месяцев или лет может наверстать эти знания (а то и больше). То, что в данный краткий миг времени он этого ещё не сделал – не даёт тебе никаких прав.
Профессиональный опыт – это не сумма знаний “как делать не надо”
Наука бихевиористика говорит нам, что человек избегает повторения негативного опыта, потому что уверен, что он повторится. Это не обосновано. Поверь на слово.
В работе есть лишь одно мерило крутизны – профит в долгосрочной перспективе
Сисадмин, который защитил компанию от обозримых рисков на ближайший год, так же крут, как сейлз который обеспечил годовые доходы. Сисадмин, который настроил один сервер, достоин похвалы не более, чем сейлз, продавший одну коробку товара.
Не ругай людей, которые в 19:00 встают и уходят домой
Не смей решать за других людей, что работа для них важнее личной жизни. Конечно, если рабочий день действительно кончается в 19.
Не завидуй людям с айфонами и айпадами, если у тебя их нет
Это просто признак принадлежности к секте. Никаких уникальных преимуществ техника Apple (равно и никакая другая) не несёт. Самый дорогой из этих приборов можно купить на одну месячную зарплату. Это – не достижение.
Сторонись людей, которые в воспитании детей полагаются на отказы и запреты
Потом эти дети выросли и пошли работать в Госдуму. Результат ты наблюдаешь каждый день.
Покупай технику, аппаратуру, машину – пусть не самую дорогую, но в самой максимальной комплектации
Не наоборот. Потому что дорогая, но обделённая комплектацией машина – это внешний ложный статус, который понадобится пару раз в жизни, и в котором ты всё время будешь осознавать эту ложь. А богатая комплектация – это те десятки и сотни мелочей, которые будут греть твою задницу каждый день.
Обеспечь себе минимальный бытовой комфорт
Старик Маслоу не врал. Нельзя продуктивно жить и работать, если каждое утро тебя встречает ржавый кран в ванной, а каждый вечер ты засыпаешь под вопли алкоголиков за стенкой. Вложись, прямо сейчас, в минимальный комфорт.
Не впадай в панику, силясь возродить свой угасающий энтузиазм
Большинство людей мучаются, вставая по утрам на работу. Даже владельцы бизнесов. Даже овнеры стартапов. Это нормально. Тот, кто заявляет, что годами способен вприпрыжку бежать заниматься одним и тем же делом – лжец или фанатик. Отдых и смена обстановки не повредит никому.
Окружай себя людьми, у которых за словом стоит дело
Посчитай в курилке своего офиса, сколько сотрудников жалуется на свою работу, босса, клиентов. На следующий день посчитай, сколько из них написали заявление по собственному.
Поощряй инициативу и успехи подчинённых
Подчинённые нужны для того, чтобы тебе работать меньше, а достигать больше.
Жестко исключай из жизни тех, кто тянет тебя вниз
Не стремись быть для всех хорошим парнем. Называй м*даков – м*даками, хотя бы про себя. Когда тебе что-то нужно от жизни – общайся с теми, у кого это получилось.
Читай книги, смотри презентации, ходи на конференции
В предпринимательстве не меньше “изобретателей велосипедов”, чем в мире программирования – желающих написать свою CMS, свой фреймворк, и свою архитектуру базы данных. Опирайся на чужой опыт.
Сторонись людей, которые требуют “точно в срок”, “согласно техзаданию”, “по регламенту”
Они проиграют. Они неспособны меняться. Они не гибкие. Первая же реальная катастрофа выбьет их из колеи.
Множество людей всегда будут несогласны с тобой
На самом деле, большинству даже нет дела до этого. Другие люди ценны тем, что они другие. Они покажут тебе твои слабые стороны, а если повезёт – прикроют их своими преимуществами в командной работе.
Остерегайся тех, кто хвастается что работает 16 часов в сутки
Это из той же оперы, что нанять в два раза больше программистов – чтобы вдвое сократить срок выпуска продукта.
Используй профессиональные инструменты и методики
Кодить “на коленке”, редактировать в vim, деплоить копированием файликов по ftp – всё равно что заниматься онанизмом. Никто не будет возражать, пока ты делаешь это в одиночестве и для себя.
Losers have a goals, winners have a systems.
Без комментариев.
SOA: делаем высоконадёжный отказоустойчивый веб-сервис на PHP иначе, чем вы привыкли
Статья не про кластеры, не про шардинг с репликацией и даже не про облака. Статья – про построение высоконадёжной вычислительной архитектуры, в которой число пользователей и их запросов может вырасти лавинообразно. И для бизнеса критично, чтобы веб-сервис принял каждый запрос, отработал его корректно и до конца (независимо от сбоев и падений каких-то компонентов), и гарантированно доставил бы ответ клиенту. Причём, разумеется, без “космических” затрат на оборудование и зарплату сисадминам.
Другими словами, в первую очередь задумайтесь – “а надо ли оно мне”. Если у кого-то интернет-магазин, торгующий говорящими хомяками с оборотом 100 заказов в месяц – скорее нет. А если вы планируете вести бизнес, способный принять сотни тысяч и миллионы пользователей, требущий большого объёма вычислений, работающий с высокоценными данными, гарантирующий транзакционность каждого бизнес-процесса, нуждающийся в параллельной обработке данных, – это оно самое. Continue reading “SOA: делаем высоконадёжный отказоустойчивый веб-сервис на PHP иначе, чем вы привыкли”
Когда записывать, и когда не записывать задачи в таск-менеджер
Тут Мегаплан постепенно приобретает человеческое лицо, и начинает понимать что нельзя “с наскока” внедрить процесс постановки задач, как лампочку Ильича, в каждую избу на деревне. Выскажу и я своё скромное мнение.
Существует две крайности относительно постановки задач: одна из них – полное отсутствие таск-менеджера вообще, передача задач устно, по аське, по е-майлу, на стикерах к монитору. Вторая – запись всего-всего-всего в таск-менеджер, и обсуждение всех подробностей и шагов решения задачи там же в комментариях, даже между людьми сидящими за соседними столами.
В реальности большинство компаний болтаются где-то между, что-то записывая в трекер, а что-то передавая исключительно на словах. Давайте разберёмся, что же там происходит и почему. Для начала – лирическое отступление и правда жизни:
Даже тщательное ведение таск-менеджера не приближает вас к успеху проекта.
Никакие инструменты не приближают вас к успеху проекта. Успех проекта не зависит от качества кода, применения автоматизированного тестирования и кодоанализаторов, процессов непрерывной интеграции, деплоя с миграциями и так далее. Никто в здравом уме не делает большой проект без этих инструментов, но они не являются залогом успеха.
Успех проекта зависит наполовину от того, насколько хорошо сработают люди, его создающие. А на вторую половину – от того, с какими эмоциями его будут использовать клиенты. Поэтому вы должны быть сосредоточены на том, чтобы набрать правильных людей, помочь им сработаться и убирать препятствия с их пути, и в том числе – поддерживать полезные инструменты и на%уй саботировать неполезные. А вот кто есть кто – зависит от вашего конкретного случая.
Вернёмся к теме:
Записывать в таск-менеджер (трекер) нужно:
Когда команда распределена. Если у вас команда и/или заказчики значительно разделены территориально и по рабочему времени, то очевидно рекомендуется записывать задачи и результаты, чтобы передавать их друг другу.
Когда задача – это на самом деле баг. Баг, как сущность, – это формализованно описанная проблема. Есть даже мантра тестировщиков, помощающая составить хорошее описание: что я делал, что я получил, что я ожидал получить. Говоря умными словами – шаги по воспроизведению, полученный результат, ожидаемый [по спецификации] результат. Однозначно записывать, иначе потеряется.
Когда задача ясна от начала до конца. Бывают такие задачи, над которыми не нужно думать, а нужно просто сделать. Добавить такие-то виртуальные хосты под такое-то число сервисов, вот список. От человека требуется взять и накатать рецепты в chef. Не нужно долго думать, достаточно сработать по известному алгоритму, и требуемый результат чётко понятен.
Когда задача содержит много формализованных значений. Например, увеличить максимальную длину логина с 8 до 16 символов, и допускать логины начинающиеся только с маленькой буквы из диапазона [a-z].
Когда исполнитель пьян. Ну, или не пьян, а с похмелья. Или не с похмелья, а всю ночь херачил над другими проектами, а утром вспомнил что нужно идти на работу. Или всю ночь укачивал капризничающего ребёнка. В общем, в тех случаях, когда над ним нужно сидеть и помогать нажимать пальцами на кнопки.
Записывать в таск-менеджер (трекер) НЕ нужно:
Когда задачу лучше сделать прямо сейчас. Как в GTD есть правило – если входящее письмо требует меньше двух минут на решение, то нужно решать сразу, не перекладывая в todo или later. Так и в разработке – если проще обсудить и тут же решить, то надо обсудить и тут же решить. Вспоминаем начало этого поста, если забыли.
Важно, чтобы это реально была задача класса “быстро решить”, а не бравада вашего разработчика в стиле “плавали-знаем”, которая выльется в полдня работы.
Когда задача требует исследования и/или проектирования. Педанты скажут, что надо делать две задачи – на исследование и на реализацию. Если вам так удобно – делайте. Но если вы сами работали программистом, то вы знаете, что в фазе исследования вы можете уже накодить так много пробных вариантов, что фаза реализации превратится по сути в рефакторинг уже сделанной работы. Как теперь отчитываться по двум задачам?
Можно не оформлять исследовательскую работу, но оформить в задачу когда исследование проведено и стало понятно что делать. Но опять же, в большинстве случаев исполнитель уже настолько погрузился в проблему, уже исписал так много листиков с алгоритмами и схемами, что переоформлять это в трекере нет никакого смысла: и так всем понятно (а главное – исполнителю понятно), что надо сделать и как оно будет работать.
Автор этих строк пользуется простым методом, и вам рекомендует: берите свой айфон и фоткайте все эти листики. Или маркерные доски, если там нарисовано. Это и будет документацией, если она вдруг понадобится кому-то из коллег.
Когда задача очевидна. Говоря другими словами, когда мимо неё не пройти, не споткнувшись. Очевидно, что в проекте должен быть процесс деплоя (скрипты, выполняющие выгрузку новой версии в продакшен). Очевидно, что у проекта должны быть группы dev-, stage-, prod-серверов. Очевидно, что когда у интернет-магазина есть корзина, то должен быть и способ фиксации заказов.
Замечание: речь про собственные (внутренние) проекты. Это не подходит, если вы работаете по fix-price и фиксированному ТЗ с внешним заказчиком.
Когда конечный результат не определён. Мой любимый пример – система аутентификации, авторизации, и распределения прав. Не смотря на (казалось бы) универсальный стандарт ACL, я не встречал ни одного проекта, в котором система прав доступа была бы сделана так, чтобы удовлетворять всех от разработчиков до клиентов. Если у вас нет возможности воткнуть какой-то готовый модуль и успокоиться, то единственный вариант – принудить команду запилить конкретное относительно нормальное и легко расширяемое (в будущем) решение. Иначе холивар вырастет на месяц.
Возвращаясь к теме поста, это пример задачи, не имеющей формализованного результата. Понятно, что система авторизации в проекте (в общем случае) должна быть. Понятно также, что на начальных этапах всем по%уй, как она устроена. Это потом, в результате тестовой эксплуатации первых альфа-версий, к ней появятся конкретные требования. Туда ходи, сюда не ходи. Это мочь, это не мочь. Но это только потом, а сейчас, на берегу, у вас есть несколько вариантов:
– привлечь профессиональное проектирование и запроектировать от начала до конца. В большинстве случаев означает бездарно потерять время [/деньги], потому что всё равно половина будет переделана, а вторая половина сразу не подойдёт.
– надавить авторитетом и сформулировать как что должно работать от начала до конца. Говно-вариант, потому что если ваша команда – не роботы, то они и сами смогут выдвинуть встречный десяток альтернативных идей, и будут демотивированы вашим давлением.
– выбрать исполнителя, соответствующего по квалификации, который сам (с небольшими подсказками) выберёт нормальный алгоритм и запилит хорошее расширяемое решение.
По какому варианту пойти – вам должно быть очевидно. И очевидно, что по такой задаче бесполезно записывать в трекер что-то большее чем заголовок “Внедрить подсистему разграничения прав доступа”.
Резюме:
Автор этих строк использует простое правило: если результат формализован и нельзя сделать прямо сейчас – записывать. В иных случаях – на%уй. Как действовать вам – зависит от вашего проекта и команды. Выберите способ, с которым команда будет наиболее продуктивна, и действуйте по нему.