пятница, 26 декабря 2014 г.

Итоги 2014

У меня сегодня последний рабочий день в 2014 году.

Весь "мордокниг" завален сгенерированными роботом историями прошедшего года.

А я подумал, надо взять и самому подвести свои итоги. И оказалось, что это был супергод!

Семья - это главное.
1. Ура, мы переехали в новую квартиру. Теперь всем хватает места, тихо, тепло и уютно. Спасибо моему главному мотиватору-толкателю-пинателю-любителю - жене :)

2. Я добил отделку дома на даче. Растянулось на 3 сезона. Внутри еще есть чем заниматься, но глаз снаружи радуется :)
Это первая сторона. 2012 год. Начало.Теперь он весь такой
3. Старший сын поймал первого "шнурка"

4. Я поймал первую "съедобную" щуку (вся рыба была поцелована в лобик и отпущена)

5. После переезда младший пошел в новую школу. Аклиматизировался и радует успехами. Старший пока еще учится в ФМЛ 239. Тоже достижение (кто не в курсе, что это за школа - просто поверьте :) )

Работа - это важно
В этом году был первый релиз нашего продукта. Год плотной работы.
Релиз 1.0
Мои разработчики - самые крутаны из крутанов. Леха, Вова - спасибо Вам. Я у Вас многому научился в этом году. Конечно, этот релиз не только наша заслуга. Всем сопричастным - искреннее спасибо.

Друзья - это нужно
Здорово, когда тебя окружают хорошие люди. В этом году мне посчастливилось познакомится с Мишей Рыжиковым и Никитой Макаровым. Получается, что собственно знакомство было в 2013, но в этом году оно укрепилось чем то большим. Вам - спасибо. Есть еще неожиданное знакомство, пока только онлайн (даже лица еще не видел). Миша Сорокин - это про тебя. Лица, еще не видел, а уже как то много друг про друга знаем ;) Хмм, подозрительно ;)
Спасибо всем старым друзьям, вы очень помогаете.

Собственно я
А я во всем выше описанном активно поучаствовал :)
Немного статистики: 
1 выступление на конференции. Мало.
45 постов в блоге. Спасибо тем, кто читает и оставляет свои комментарии. 
Аналитика Гугла говорит, что 18 тыс. просмотров.
10 прочитанных книг. Мало. Надо читать больше. Зато ревью стараюсь писать.

Всех с наступающим Новым 2015 Годом. 
Он наверняка будет непростым, но ведь трудности закаляют :)



пятница, 19 декабря 2014 г.

Новогодний IT talk#26. Питер

18 декабря прошел заключительный в этом году IT talk.
Тема была неожиданная, но мне показалась интересной и я не пожалел. DataArt переводит свою деятельность на новый уровень и, кроме традиционной для него заказной разработки, теперь предоставляет услуги IT-консалтинга. О новой для себя области Андрей и рассказывал.

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

Доклад вызвал неожиданный для меня интерес и вопросов задавали, по-моему, больше чем обычно.

Кому интересно сам доклад можно посмотреть, но, как я уже упомянул, в записи нет бонуса.



Вообще DataArt-Питер молодцы. Встречи IT talk проводятся достаточно регулярно, тематика разносторонняя. Спасибо вам. Насколько мне известно, это единственное IT-мероприятие, которое в Питере проводится таким образом.

Хотя нет, есть еще встречи сообществ Piter United, которые сейчас тоже стали проводится гораздо чаще.

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

Всем удачи :)

PS Вчера на IT talk новогодняя лотерея выбрала меня и теперь у меня на столе вот такой вот IT-"букет" :)


PS2 Интересующимся темой консалтинга хочу порекомендовать книгу "Закон малинового варенья". В интернете можно найти много рецензий. Скоро и у меня будет обзор этой книги.

четверг, 18 декабря 2014 г.

Technology Radar - январь 2015

Прошло полгода с прошлого выпуска радара.

Что нового на этот раз?

Из того, что мне показалось интересным или затронуло:

Методы (Techniques), элементы процесса разработки ПО
Воздержаться от применения:
  • long lived branches (долго ведущиеся ветки кода без мержа)
  • Avoid microservice envy (тема популярная, но не стоит ее внедрять только ради этого)
  • programming in the CI/CD tool (все максимально должно быть в репозитории. У нас с этим, на мой взгляд, есть над чем поработать - увлекаемся PowerShell-ом в Jenkins-работах)
  • testing as a separate organization (о-ооо, это моя боль :))
  • velocity as productivity (попытка использовать скорость работы команды как оценку ее производительности, усугубляющаяся желанием делать из этой скорости цели)
Инструменты (Tools) разработки
Готово к использованию, но аккуратно:
  • Docker
  • Gitlab
Оба мы уже используем. Что радует.

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


пятница, 12 декабря 2014 г.

Бережливое производство в промышленности или Lean в реале

Попал тут по блату, Миша - спасибо, на забавное мероприятие: "II Российская научно-LeanProm»".
практическая конференция по промышленности и производству «

Хорошее такое расширение кругозора получилось. Многие аспекты того, как ложится эта теория на нашу работу (разработку ПО), прояснились.

Пока надо все утрясти в черепе, но тема оказывается интересней, чем я себе представлял.

Тут "напочитать" себе ссылок:

"Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании"

Понятие OEE (забавная была дискуссия)

Концепция "социальной инженерии" А.К.Гастева (1924 год - русский lean?)

Самым интересным был доклад Анатолия Филипишина. Тут нашел интересный отзыв об одном из его семинаров.

Мой главный вывод с мероприятия: когда мы говорим, что разработка ПО - это что то уникальное, со своим путем, и совсем не классическое промышленное производство, что у нас их методы не работают - то, мягко говоря, мы ошибаемся.




понедельник, 8 декабря 2014 г.

Нужны ли тестировщики, если разработчики пишут тесты?

Ура, вопрос из зала после статьи о разработчиках и тестах:

"Я вот все никак понять не могу. У тебя очень много всяких постов встречается про то, что тестировщики не особо то нужные люди... это вот как? В смысле, ты сам как считаешь - нужны они или не нужны? :) Никак твою точку зрения не могу понять".

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

Действительно, зачем нам нужен такой Петя? Такой Петя нам не нужен, потому что см.картинку.

Но нам очень нужны правильные тестировщики, хорошие . Мне такие попадались :)

Где их взять? Хороший вопрос, но пока похоже риторический...
Кроме капитанского "учить, искать" ничего на ум и не приходит.

Из интересного на эту тему (свеженькое после #xpdays):
Добавка по комментариям: вопрос "нужны ли тестировщики" возникает регулярно. На самом деле вопрос неоднозначный и требует рассмотрения в конкретных условиях: размер проекта (в т.ч. его возраст, широта предметной области), частота релизов, цена ошибки, какие процессы и тд. Но в общем и целом - нужны.

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

Вопрос скорее надо ставить как "зачем нам нужны тестировщики?", чем их наличие может помочь в достижении поставленной цели и что они должны делать.


четверг, 4 декабря 2014 г.

Почему разработчики не тестируют свой код?

На недавно прошедшем IT Global Meetup Леша Федоров спросил (а может трольнул) меня: "А почему разработчики не тестируют свой код?".

Что то я там ему ответил, но вопрос продолжал свербить и в итоге вылился в этот пост.

Это то, как я вижу себе эту проблему, которая для многих и вовсе не проблема. 

"Мнение редакции" может не совпадать с мнением "ведущих" экспертов в области разработки ПО.

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

Причин на самом деле немного и все они тесно связаны:

1. Разработчик не знает, что он должен тестировать свой код или как это делать
Это может показаться странным, но такое действительно бывает. Особенно это касается начинающих.
Я абсолютно уверен, что этому не учат в институтах и прочих университетах (там у нас и с программированием то беда).
Этому, как правило, не учат на первом месте работы (по причинам приведенным ниже).
Если человек, обучаясь, писал сам, то сам потом и проверял - больше некому было. А на работе есть специально обученные товарищи - тестировщики. Значит, это не моя работа.

2. Разработчик знает про тестирование, но ему не дают их писать - "много времени занимает"
Кому то может показаться это странным - но это тоже бывает. Такие товарищи подходят ко мне на конференциях, пишут вопросы в комментариях - "Я хочу делать все правильно, но мне не дают. Когда я пытаюсь что-то предлагать,  отвечают - Зачем тебе это надо? Нам некогда писать тесты." и тд. Я даже знаю, тссс, тестировщиков, которые такое говорят разработчику. Наверно за свой хлеб переживают? Часто, в этом случае, разработчики пишут тесты втихаря, но, по опыту, пользы от них (тестов) в этом случае немного.
Регулярно слышу мнение: "время разработчика стоит дороже времени тестировщика". БРЕД! (извинения за upper case) Понятно, что если говорить о квалификации большого количества тестировщиков, то стоимость их действительно ниже (на первый взгляд). Но если мы говорим о продукте, который надо поддерживать от 3 лет и выше, то итоговая стоимость неквалифицированной и продолжительной проверки каждого релиза + стоимости затраченного времени (а время деньги) будет многократно превышать стоимость правильно разработанных тестов (даже с учетом их поддержки). Кстати, тут неважно, как обзывается тот, кто эти тесты писал.

3. Разработчик знает про тестирование, но лично считает это потерей времени
"Я могу писать тесты, но тогда фича займет в 2 раза больше времени. Поэтому не буду писать" - говорит тот, кто никогда не писал и не пишет тесты. Знаете почему он неправ? Потому что на самом деле, очень часто, "с тестами" получается в 4 и больше раз времени! Особенно в начале. Но вопрос - какого времени? Что для этого разработчика (и его менеджера) понятие "Сделано"? Когда фича считается готовой к релизу? А вот тут как раз и надо посчитать это самое время и не забыть про тех.поддержку.
Вы спросите - а как же его менеджер? А никак. 
Иногда он считает разработчиков "голубой кровью" - пусть тестировщики смотрят. Тут солидарность с пунктом 2. 
Иногда он боится надавить и заставить писать с тестами - мой мегакодер (ключевое слово "кодер") обидится и уйдет. 
Иногда у него нет возможности (нет знаний) объяснить людям, зачем эти самые тесты нужны, что их "быстро без тестов" никому не нужно.

Итого: кто виноват? Правильно - менеджер!
Все описанное выше целиком и полностью лежит на совести руководителей (тех.лидов, менеджеров проекта и тп).

Почему? Потому что:
  • не учит, потому что,
  • не знает, как писать тесты или -
  • не ищет правильных и умных людей
  • не доверяет тем, кто сам предлагает
Не будет этого - не будут ваши разработчики писать тесты.

Что делать? Решать вопросы выше.

И да, на всякий случай, рекомендации:


Читать дальше: а если разработчики все же пишут тесты, нужны ли тестировщики?

вторник, 2 декабря 2014 г.

Как прошел 3й IT Global Meetup (Питер)

"To be or not to be" - Ты все еще одинок? Приходи в IT-сообщество.

28 ноября в Питере прошел 3-й IT Global Meetup
Черт возьми, у них это получилось! Это я про организаторов. Я был более пессимистичен, но они это сделали. За что им большое спасибо.

Собрать в одном месте столь разношерстную (с точки зрения специфики деятельности - см итоговую программу), но единую по образу мышления компанию - это дорого стоит.
Как сейчас говорят, по данным exit-polls, в мероприятии поучаствовало около 450 человек. Неплохо (даже пожалуй отлично) для вечера рабочего дня.

17 IT-сообществ Питера собрались в одном месте, чтобы заявить о своем существовании, рассказать о себе и пообщаться в тесной компании единомышленников.

Те коллеги, с которым удалось пообщаться уже после мероприятия, отмечают, что не ожидали такого количества участников и уровня проведения. Обычно, чего уж греха таить, на бесплатные мероприятия приходит много случайных людей. Здесь, если они и были - то меньшинство.

Можно было найти сообщество по интересу, настроению или просто пообщаться с друзьями в кулуарах. Места хватало всем (ну может некоторым было чуть тесновато). И все это с 17 до 22.45 - еще один рабочий день, да еще и в пятницу! Я этого не осилил, но фанаты были :)




Основная идея мероприятия, по задумке одного из главных организаторов Миши Рыжикова -это рассказать о существующих сообществах, дать идеи для новых сообществ. А они, в свою очередь, выступают в качестве средства борьбы с профессиональным одиночеством. 

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

Кстати, Миша, надо подумать - может имеет смысл сделать мероприятие условно-бесплатным? Я понимаю, тема спорная, но думаю, организация при этом будет несколько проще. А многие с кем я говорит на эту тему не против.

Официальный отчет о мероприятии можно найти здесь.

Еще фото с мероприятия - можно оценить масштаб мероприятия.


(слева-направо) Владимир Лапардин, Миша Рыжиков, я