Программирование, Путешествия, Покер

Привет всем !
Тоже захотелось поделиться своей историей ухода из покера. Плотно играл лет 7, первые 5лет все складывалось , каждый год в плюс заканчивал , но последние 1,5 года были просто адовые. В основном играл на пати,и после того как они не предупредив убрали фуллринг с 1 ноября, осознал, что пора сваливать окончательно.
У меня бекграунд офисной работы как фин аналитика был лет 9 за спиной. Пассивно искал работу месяца 4-5 и в активной фазе нашел за 2-3 месяца, хотя был а полном упадке, ничего не складывалось - на собесы не приглашали.
В финансы уже не хотелось возвращаться, конкуренция там сильная и надо постоянно учиться развиваться, получать сертификаты - а именно в финансах у меня таланта не было , душа не лежала.
В итоге пригласили в известную fmcg компанию на новое направление, по доходу дали больше чем я рассчитывал.
Страсть к покеру у меня потухла, новости читаю и форум иногда, бывает посмотрю вечерком стрим какого-нибудь Васи на твиче, вспомню былое)). Было интересно, но не сложилось!
Если кто задумывается о выходе из покера - дерзайте! У вас получится!
Всем удачи!

Не так давно, когда я писал про новый проект и про выстраивание процессов на нем, меня вполне логично спросили:

zaebiz @ 8.7.2019
strkk, а что подразумевается под "выстраивать процессы" - ведь предыдущий лид уже что-то делал... некое расписание митингов, зоны ответственности, план проекта и тд - все это уже должно быть готово в каком-то виде?

С момента начала более-менее продуктивной работы прошло около месяца и можно сравнить пару процессов до и после.
Сильно преобразилось выкатывание последней сборки приложения на тестовый сервер.
Раньше процесс выглядел примерно так:
1. Тестер просит выкатить билд
2. Я пишу анонс в специальном чатике
3. Затем логинюсь в систему, которая оркестрирует сервера.
4. Копирую команду логина, затем ввожу ее в командной строке
5. Ввожу 2 команды для деплоя в командной строке
6. Проверяю логи что все выкатилось норм
7. Открываю менеджер задач, во всех необходимых задачах выставляю номер билда и тестера
8. Пишу в чатик что все ок.
Каждая операция не занимает много времени, однако все вместе превращается в полчаса или час, которые можно потратить на что-то более полезное. Не говоря уже о том, что если меня нет на месте, то все стопорится еще на 1 пункте. Да и без аппрува тестера выкатывать не стоит.

Сейчас процесс выглядит следующим образом:
1. Тестер открывает систему сборки приложения.
2. Тестер нажимает специальную кнопку "Выкатить последнюю сборку"
3. Я перевожу задачи и пишу номера билдов в комментах. Этот пункт автоматизируем в ближайшие недели.
4. При успешном билде всей команде приходит письмо, где указан номер билда и список задач, которые туда вошли.

Теперь процесс превратился в self-service. Когда есть необходимость - тестер сам может все сделать в удобное ему время.
Всякие ненужные чаты теперь пустуют, а сам процесс занимает минимальное количество времени и никого не отвлекает.

Процесс разработки тоже преобразился. Если раньше он выглядел примерно так:
1. Создается отдельная ветка с любым именем
2. Делается сколько угодно коммитов (изменений кода)
3. Без всякого ревью все изменения добавляются в основную ветку приложения.

Вот здесь все очень быстро причесалось в такое:
1. Создается ветка со строго определенным шаблоном
2. Любой коммит должен иметь в начале номер задачи, в рамках которого он был сделан.
3. Любые изменения по задаче должны быть в 1 коммите.
4. Необходимо пройти ревью у минимум 2 человек, а также сборка обязательно должна быть успешной.
5. Стиль написания кода жестко зафиксирован, любые несоответствия приводят к тому, что сборка приложения падает и код не может быть добавлен.
6. Я требую добавление тестов почти для каждой задачи.
7. Код анализируется специальными тулзами и показывается покрытие тестами.
8. Перешли на стандартный git flow.

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

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

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

strkk, Месяц как работаю в новой компании и у нас процессы выстроены очень похоже. На предыдущем месте работы такого не было и был по большому счёту подход - лишь бы работало. Помнится, подошёл к своему PM спросить надо ли покрывать проект Unit-тестами, на что он ответил - на моё усмотрение. Конечно же тесты я не стал писать

Теперь же, к примеру, код не запушишь, пока покрытие тестами не будет составлять 80% проекта минимум. Обязательное следование обозначенному checkstyle. Также на первых порах было непривычно, что ветки необходимо называть в соответствии с определенным шаблоном + не забывать их удалять ;) В общем и целом, также согласен, что так процесс разработки становится более очевидным и сокращает степень недопонимания в команде.

strkk, Привет, классный пост, со всеми пунктами согласен, но по двум появились вопросы:

Создается ветка со строго определенным шаблоном

Что ты имеешь в виду под шаблоном? Название ветки? Если да, то какой шаблон у вас используется?)

Любые изменения по задаче должны быть в 1 коммите.

В чем ты видишь преимущества этого подхода?
Если мы для задачи создаем отдельную ветку, то чем хуже поделить коммиты например на:
1. написал фукнцию 1
2. написал функцию 2
3. добавил тесты
и т.д.

flek @ 25.8.2019
Что ты имеешь в виду под шаблоном? Название ветки? Если да, то какой шаблон у вас используется?)

Да, названия ветки. В целом, взяли дефолтную схему битбакета.
Еще обязательно добавляется имя задачи и опциональное описание.

flek @ 25.8.2019
В чем ты видишь преимущества этого подхода?
Если мы для задачи создаем отдельную ветку, то чем хуже поделить коммиты например на:
1. написал фукнцию 1
2. написал функцию 2
3. добавил тесты

Наверное я немного неправильно расписал.
Изменения могут быть смерджены только если в бранче находится только 1 коммит. Ничего не мешает делать хоть 20 штук во время работы над задачей, а также во время ревью кода (упрощает ревью). Только перед мерджем все должно быть объединено в один. Некоторые тулзы (gitlab, например) умеют это делать автоматом. Битбакет не умеет, приходится смотреть за этим на ревью.

Мотивация достаточно простая - все эти промежуточные коммиты не нужны в основной ветке приложения, там требуется только цельное изменение в рамках задачи. Также это сильно упрощает анализ и просмотр истории. А в случае уведомлений о новых билдах тескт письма генерится из как раз истории основной ветки. И если там будет по 20+ коммитов для одной задачи, то информативность и полезность рассылки существенно снижается.

strkk, Да, теперь все понятно, спасибо)
А можешь рассказать, как у вас происходит постановка задачи и написание ТЗ?
Например, нужно добавить новую фишку, есть основная идея что должно получится в итоге, но без подробностей. Что происходит дальше? Программист сам пишет ТЗ, потом его обсуждаете? Или вы вместе в каком-нибудь ишшью создаете топик и обсуждаете там все вместе? Программист сам решает, какие технологии использовать для написания?
Ты как тим лид, должен уметь сам все написать если нужно будет или необязательно?

flek @ 25.8.2019
А можешь рассказать, как у вас происходит постановка задачи и написание ТЗ?

Ничего необычного. Просто приходят описания фичей в формате user story, которая затем анализируется и уточняется/дополняется.
После чего производится оценка трудозатрат и она берется в работу или откладывается на потом.
Программист не пишет никакие ТЗ, его задача - технический дизайн и имплементация.

flek @ 25.8.2019
Программист сам решает, какие технологии использовать для написания?

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

flek @ 25.8.2019
Ты как тим лид, должен уметь сам все написать если нужно будет или необязательно?

В идеале наверное да, но в реальности это сложнее гораздо. Тут скорее глобальная задача - чтобы у нас был отлаженный процесс и выполнение задач в срок. Плюс с меня просят оценки по трудозатратам. Без понимания реализации оценки даются довольно трудно, в этом аспекте я пока проседаю, как мне кажется.

его задача - технический дизайн и имплементация.

Видимо я имел в виду технический дизайн. Сейчас попробую объяснить, что я имею в виду.

Допустим, нужно добавить показ рекламы в приложение(первое что пришло в голову). Описание задачи примерно такое: нужно показывать рекламу пользователям каждый раз, когда они нажимают на кнопку Х, но каждый пользователь должен увидеть одну рекламу только один раз. Так же, нужно сделать возможность добавлять новую рекламу и удалять старую для администратора(в админской панеле, например).

Вот в таком примере, что может быть техническим дизайном(если пример неудачный, то можно взять любой другой)? И когда вы обсуждаете это задание, то все уточнения каждый записывает себе сам? Используете ли какую-нибудь программу для таких записей?

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

flek @ 26.8.2019
Вот в таком примере, что может быть техническим дизайном(если пример неудачный, то можно взять любой другой)? И когда вы обсуждаете это задание, то все уточнения каждый записывает себе сам? Используете ли какую-нибудь программу для таких записей?

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

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

Если что-то совсем неясное или всплывают какие-то неоднозначности - то задача отправляется обратно в анализ, после чего с пояснениями (опять же, в комментах или описании) возвращается в работу.

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

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

Еще кейс по поводу американской визы - одна моя коллега с епама подавала заявление на иммигрантскую визу зимой, и рассмотрение ее доков не закончилось до сих пор (уже 7 месяцев идет). Также она прожила в Варшаве 2 месяца, т.к. изначально визу несколько раз собирались выдать "точно на следующей неделе" и ее пребывание в Варшаве все время увеличивалось.

Интересно, что американцам не понравилось в ее случае.

П.С. все-таки решили оформить визу моей супруге и слетать в штаты на новый год (наверное, в Нью-Йорк). Надеюсь, у нее квест пройдет без приключений.

strkk, А что это за контора? Как они выбирают адресатов? Получается, что и правда отправляют в США так или иначе))) Тебе самому не интересно попробовать такое?

strkk @ 30.8.2019
наверное, в Нью-Йорк

Лучше летите в ЛА, по деньгам не сильно дороже, если заранее взять билеты, но там зато Тихий океан, а не Атлантический).
Потеплее малясь и помягче будет)

В Нью-Йорке тоже хорошо, но ведь можно полететь в LA с пересадкой в NY ;) Например, брать рейс с максимально большой пересадкой и в итоге можно потусить там во время дороги туда/назад. Этого будет предостаточно сгонять на таймс сквэр, в централ парк, забраться на ESB или пройтись по Бруклинскому мосту, уверяю.

А вот колоритная Калифорния для первого знакомства с US - идеальный вариант, особенно с женой. Там можно (нужно) взять тачку и поездить везде, впитав тру Америчку. Прокатиться по Route 1 до Сан-Хосе и СФ, или до Вегаса, или до Сан-Диего. Там все рядом. И кремниевая долина, и горы красивейшие рядом, и пустыня, и вино местное вкусное и тд.

Поярче впечатления будут. Если что - пиши в ЛС, поделюсь опытом, я там 3000км+ накатал в последний раз.

vsobakekot, такой концентрации достопримечательностей на единицу пространства как в Нью-Йорке вряд ли где еще можно найти. Думаю и недели не хватит все обойти, не то что пару часов между пересадками. Тот же центральный парк, чтобы только вдоль его пройти нужно не останавливаясь часа 3 где-то пешком идти, а хочется же остановиться и пофоткать черепашек в пруду или послушать какого-нибудь музыканта играющего на цимбалах. Там столько дорожек, что порой ходишь и не понимаешь ты здесь когда-нибудь был и нет. На тайм сквер и бруклинском мосту в принципе тусуются только туристы и там делать в общем то нечего, хватит по полчаса на каждый. Но зато есть очень крутые места типа green-wood cemetery, про которые туристы не знают и когда мы там были встретили только человек 10. Возможно их отпугивает, что это кладбище, но надо признать атмосфера там просто охренительная, как будто попал в фильм про 18 век. Там ходят туристические автобусы и патрулирует охрана на машинах, все ухожено и вылизано. Мы там нашли прудик с плавающими лебедями и лавочкой под огромным деревом. Еще немного посидел бы там и наверно стихи начал бы писать

flek @ 30.8.2019
strkk, А что это за контора? Как они выбирают адресатов? Получается, что и правда отправляют в США так или иначе))) Тебе самому не интересно попробовать такое?

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

Насчет машины для поездки в штаты.
Я неоднократно думал брать машину в других местах, но все время эти варианты отменялись.
Мне реально стремно садиться за руль с учетом того, что я водил последний раз в 2012 году. Сейчас я не пользуюсь машинами, даже каршерингом, передвигаясь на самокате, общественном транспорте и такси. Честно, я даже на заправке вряд ли смогу сейчас полный бак залить в машине, настолько я не помню ничего из моей недолгой водительской жизни.

Конечно, есть вариант потренироваться несколько часов с инструктором. Наверное, когда я все-таки решусь, то именно так и поступлю, но пока подобные штуки видятся мне минусовыми. Стоит также помнить о том, что еду я не один.

Нью-Йорк был выбран из-за наличия большого количества интересных мест (я еще думал над посещением Бостона), ну и сидящей в голове картинки из фильмов типа "Один дома" про красоту рождественского/новогоднего города.
Плюсом к этому тот факт, что можно как раз обойтись без машины, тоже играет свою роль.

Если без машины, то только НЙ, в Калифорнии нечего делать без авто, в то время как в НЙ нечего делать с авто :)
Но, сам НЙ конечно, та еще помойка (да простят меня фанаты этого города)

strkk, так же как и ты за рулём сидел последний раз хз когда, но в этом году во время путешествия взяли авто и проехали 2к км на нем. Очень кайфонули. Вначале небольшой стресс был,а потом ок.
Так что если умеешь водить все будет ок)

Насчет того как стать программистом, многие спрашивали различные советы. А один мужик собрался и написал замечательную книгу об этом, очень рекомендую к прочтению, я когда-то наткнулся на его канал на ютубе и удивился, что какой-то качок рассказывает про программирование на C++. В общем его книга мне нравится (пока прочитал 6 глав только). Может сперва показаться водяной водой, но по мне он все грамотно рассказывает, создает нужный настрой насчет софтостроения в целом и расставляет правильные акценты где это необходимо. Кто собирался начать с нуля - идеальное руководство.

Достаточно адекватное мнение по книге тут.
Это если кому хочется до начала чтения составить представление и примерно понять , о чем там.

vsobakekot @ 5.9.2019
Достаточно адекватное мнение по книге тут.
Это если кому хочется до начала чтения составить представление и примерно понять , о чем там.

Я думал там разгромный обзор будет , а так да, со всем согласен, все грамотно расписал. Если опустить специфичные для США вещи или допустим главу про одежду (бред, я на собесы ходил в майке с надписью "I don't need google, my wife knows everything" и пошел бы в ней и в сам гугл), пока что лучшая обзорная книга на сегодняшний день. Многие вещи которые там указаны я по крупицам сам собирал из сотен статей, книг, блогов и т.д.