Заметки о разработке, тестировании, управлении проектами, людях в ИТ.
30 ноября 2017
Напочитать:ТСТРВЩК УПРЛСЯ
1. Chrome теперь умеет быть headless, умеет параллелить Remote Debugging сессии, команда хрома выпустила Puppeteer. Firefox просто научился быть headless.
2. Test Impact Analysis - просто офигенная статья от Paul Hammant в блоге Мартина Фаулера.
3. Более менее внятно про Pact и Consumer-Driven Contracts c примерами на github.
4. Скалирование Selenium-тестов на Amazon Lambda - новый уровень упоротости!
5. Для тех кому нечем будет заняться долгими новогодними вечерами - видеозаписи симпозиума Facebook про тестирование и формальную верификацию систем.
6. Тем же кому хочется тем более приземленных - записи с закрытой конференции @Scale про Developer Tools и очень много про тестирование и темы смежные с ним.
P.S. тем кому этих шести пунктов не хватило чтобы упороцца предлагается пройти видеокурс по TLA+
31 октября 2017
Напосмотреть: Тестирование: Пред-Heisenbug-овый
Часть докладов пересекается с темами которые будут на Гейзенбаге.
А часть - нет, но спойлерить ту часть которая будет на Гейзенбаге я не буду.
1. Ребята из 2GIS о том сколько геморроя можно поиметь при построении инфраструктуры автоматизации тестирования для Adnroid приложений
2. О том что можно получать СМС-ки для регистрации аккаунтов на номера Twillio и как заставить Google анализировать его же собственные голосовые сообщения.
3. Про Test Containers от их же создателя
TestContainers – Richard North from Official ZeroTurnaround Account on Vimeo.
4. Даже такое серьезное издание как Guardian не ссыт тестировать в продакшене, а ты ?
5. Обзор инструментов визуального тестирования
26 октября 2017
Напочитать: так тестируют только @#$%исты!
Про то, как тестируют программисты
1. JCunit для комбинаторики и тестирования на основе моделей.
2. Какие типы моков бывают - с примерами для Mockito.
3. Как можно (нужно ли?) комплексно протестировать Spring Boot приложение - подробно и детально тут.
4. Как Facebook ищет баги с помощью генетических алгоритмов и как к этому прикрутить crowdsourcing.
5. Infer от Facebook живет и они даже про него рассказывают: видео , статья . (maven-плагин для интеграции)
6. как тестируется язык Rust - очень интересно.
7. Как программисты GitHub устраивали back-to-back тестирование в продакшене.
8. Infer (ныне фейсбуковский) учится находить race conditions.
9. Как протестировать отправку почты с простейшим SMTP сервером и модными
26 сентября 2017
Напочитать: JUnit 5
Собственно 10 сентября, после 2-х лет разработки в свет вышел JUnit 5 он же JUnit Lambda.
Если для вас это ничего не значит и Вы не понимаете почему это событие
А тем, кто остается собственно воть:
1. Выступление Марка Филлипа о том как переехать с JUnit 4 на 5.
Кстати Марку видимо понравилось и он приедет с продолжением темы на Joker.
2. Большая статья на Хабре про фичи и фишки.
3. Tutorial от Petri Kainulainen по JUnit 5 - тут
4. Параметризация тестов на JUnit 5 c примерами и картинками - тут.
5. Большая презентация в качестве шпаргалки.
6. Параметризация из JSON
7. Расширение для удобной работы с WireMock
8. Альтернативный движок для тестов - jqwik
9. Слегка уродливое расширение для Selenium на JUnit5.
10. JFairy для рандомизации тестовых данных.
11. Комплексный пример с JUnit5 и Selenium для проекта на Vaadin. Пояснительная текстовочка на немецком.
12. Тестировать интеграцию с базами тоже можно - Rider.
13. Тестировать логи (логи, епта!) тоже можно. Пример тут для JUnit 4 и 5.
14. Тестирование самих расширений JUnit5, Guice, интеграция с Mockito - все тут.
15. Перехват out и err потоков через расширение - тут.
16. Набор extension-ов от разработчков JUnit5 - JUnit Pioneer.
17. Extension для Vert.X под JUnit5 - детали тут.
18. Программная регистрация расширений - детали в официальной доке.
19. Поддержка Vert.X для JUnit5 - тут
20. Расширения для RestAssured - тут
21. Расширение для Jersey - тут
Мигрируйте!
13 сентября 2017
Полезняшка для тестировщика : пишем видео с телефона
Я не очень хочу распыляться на тему почему такая потребность возникает - и так понятно что гораздо удобнее когда к багу приложен скриншот или даже видео.
У меня эта потребность возникла с несколько неожиданной стороны - проводя собеседования кандидатов мы для оценки того как он умеет тестировать мобильные приложения руками даем ему в руки телефон с нашей приложенькой и смотрим как он по ней будет шариться/тестировать.
Все бы ничего, но команда у нас географически распределенная и довольно часто приходится проводить интервью с кандидатом людям из разных городов, и в такой ситуации посмотреть на то как человек тестирует мобилку руками не представляется возможным.
Точнее не представлялось.
Итак, рецепты.
Рецепт №1, простой.
AZ Screen Recorder - совершенно замечательная софтина без регистрации и СМС, которая ставится на телефон и позволяет снимать видео с экрана , со звуком (хотя это требуется крайне редко) и делает это хорошо.
Собственно пример видео снятого этой софтиной с моего телефона ниже.
Жамкаем Показать и вбиваем этот самыйц ключик трансляции в настройках Screen Stream Mirroring для YouTube
У меня эта потребность возникла с несколько неожиданной стороны - проводя собеседования кандидатов мы для оценки того как он умеет тестировать мобильные приложения руками даем ему в руки телефон с нашей приложенькой и смотрим как он по ней будет шариться/тестировать.
Все бы ничего, но команда у нас географически распределенная и довольно часто приходится проводить интервью с кандидатом людям из разных городов, и в такой ситуации посмотреть на то как человек тестирует мобилку руками не представляется возможным.
Точнее не представлялось.
Итак, рецепты.
Рецепт №1, простой.
AZ Screen Recorder - совершенно замечательная софтина без регистрации и СМС, которая ставится на телефон и позволяет снимать видео с экрана , со звуком (хотя это требуется крайне редко) и делает это хорошо.
Собственно пример видео снятого этой софтиной с моего телефона ниже.
Этого инструмента вполне достаточно чтобы репортить баги, но не достаточно для кейса с собеседованиями. Поэтому идем дальше.
Рецепт №2. Screen Stream Mirroring + YouTube.
Для этого варианта потребуется, установить Screen Stream Mirroring и сделать себе левую учетку у Google - можно конечно и не делать , но тогда в ваш личный канальчик на YouTube будет заливаться видео того как вы тестируете - вас это конечно может устраивать, но вот меня нет, я ведь бьютиблоггер.
Идем под учеткой Google на YouTube, вот сюда https://www.youtube.com/live_dashboard, внизу страницы находим раздел настроек видеокодера.
Жамкаем Показать и вбиваем этот самыйц ключик трансляции в настройках Screen Stream Mirroring для YouTube
Теперь открываем приложеньку на телефоне и в менюшке слева выбираем YouTube.
После чего идем в настройки и настройках трансляции вводим ключик трансляции который нашли на YouTube.
Собственно для того чтобы начать трансляцию ваших похождений на телефоне в YouTube все готово, но делали ты мы это все для телеприсутствия, и вот тут остался последний шаг - поделиться ссылкой!
А ссылка для живой трансляции всегда будет одна и та же - https://www.youtube.com/user/live.
И только после того как вы остановите трансляцию видео осядет в анналах истории YouTube и будет просто обычным видео на YouTube с которым вы и так знаете что можно делать.
Пример видео сделанного такой связкой инструментов.
19 июля 2017
Напочитать: 13 друзей Оушена
1. LinkedIn продолжает опенсорсить. На этот раз Flashback - mock-инструмент для тестирования. Плохая новость - c https все так же плохо, то есть MITM на который орет хром.
2. Большой список строк для тестирования - тут
3. Что, как, зачем и почему mock-ают и stub-ят девелоперы в своих тестах - рассказывается тут.
4. Заготовочка проекта для написания автотестов под мобилки - тут.
5. Atlassian Clover теперь валяется в open source - мало ль кому будет полезно
6. Apple продолжает стараться делать хоть что-то для тестирования своих приложений, но по прежнему получается так себе - новый релиз TestFligth с новыми фичами.
7. Тестировать процедуры A/B-тестирования - рецепт от HeadHunter.
8. Великий и ужасный Лэсли Лампорт c лекцией про TLA.
9. Лекции от ИСП РАН про тестирование на основе моделей - тут.
10. Newman - это cli для Postman, который позволяет использовать postman в CI.
11. JGoTesting - это когда на Java натянули идеологию тестирования от Go. Стоит скзаать что написал ее Dan North.
12. Если вам когда-нибудь потребуется потестировать SNMP на Java - то говорят, да, это возможно.
13. ArchUnit и Freud - для тех кто не ссыт смотреть в код.
Ярлыки:
ab-testing,
apple,
archunit,
calabash,
clover,
flashback,
freud,
jgotesting,
lamport,
linkedin,
model-based testing,
newman,
postman,
snmp,
split testing,
strings,
testflight,
tla
10 июля 2017
Напочитать: Джавайский
1. Hollow от Netflix и YoctoDB от ребят из Яндекса - вестники новых парадигм.
2. Property-Based Testing c помощью Javaslang - даже лямбды не спасают от такого уровня упоротости.
3. Как упороться блокчейном или пускаем Etherium по Java-e - раз и два.
4. cfg4j - пусть это хотя бы будет не вашим велосипедом
5. Circuit Breaker но не Hystrix - resilience4j и его младший брат - failsafe
6. Reladomo или почему Goldman Sachs упоролся своим ORM
7. Звонить из java-приложеньки - можно, тут рассказывают как.
8. Это пожалуй первая статья где нормальным языком рассказано про GraphQL, а вот тут еще и видео можно посмотреть .
9. Atlassian про то как расширять гит , но ссылки в конце статьи интересней.
10. Peter Lawrey про паттерны взаимодействия микросервисов - красочно, чо.
11. Стандартный грабли при запуске Java-приложенек в Docker перечислены тут.
12. Макаруны - это не только сладкие ништяки из миндального теста, но волшебные токены из недр Гугла. Смотреть тут, читать тут.
27 апреля 2017
Напосмотреть: Продуктовые грезы
Про продуктовую разработку, культуру и жизнь в продуктовых компаниях.
1. Олег Щеголев про то как живет внутри SEMrush
2. Болезненная тема - быстрый рост компании и как меняются процессы - бесценный опыт от CarPrice
3. Обратный пример - маленькая компания которая живет монопродуктом на очень сложном рынке и со своей спецификой.
4. Максим Дорофеев про буферы и планирование.
А если хочется окунуться в эту тему поглубже то вам сюда
13 апреля 2017
Напосмотреть: Подрывные инновации
Этот выпуск копился очень долго.
Просматривая разные видео с конференций попадаются интересные, но по тематике не подходящие ни в одну категорию.
Этот выпуск из них.
1. Энтони Голдблум о том как машины отнимут нашу работу
2. Теория заговора, мировое массонское правительство и прочая конспирология меркнут в сравнении с взаимной интеграцией корпораций и хрупкостью этой системы в целом. Тему раскрывает Джейм Глаттерфельд.
3. О том что нас ждет в эру посткапитализма и причем тут open source рассказывает Джейми Добсон
4. О том что такое Dark Design Patterns я узнал года три назал, но вот тут вот есть шикарная подборка.
5. Совершенно восхитительное выступление на тему Clean Disruption - если этот парень прав хотя бы на половину, то мы будем жить в очень интересное время.
30 марта 2017
Книга: Debfriefing Facilitation Guide by Etsy
В большинстве организаций которые занимаются операционной деятельностью со своим софтом (то есть ставят его в свой или чужой продакшен, оно там работает, иногда падает) рано или поздно отрастает практика разбора инцидентов с этим софтом.
Эти самые ретроспективы, after-action review и как бы они еще не назывались (имя им Легион) постепенно врастают в культуру, и некоторые организации начинают пристально смотреть на то, что вросло в их культуру.
Тут нужно сделать небольшое отступление.
В процессе разбора различных неприятностей, которые случаются в процессе операционирования - чем дальше, тем больше - вы будете сталкиваться с тем, что причиной инцидентов или масштаба их последствий становится человеческий фактор.
Примеры
список можно продолжать, и долго.
Это случается потому, что нормальный, здоровый процесс разбора полетов на методичной и регулярной основе убирает причины инцидентов обусловленные техникой и технологией.
Остаются только люди и процессы взаимодействия между этими людьми.
Собственно, регулярно слышать на разборах инцидентов формулировку «человеческий фактор» надоедает и вот в Etsy решили что-то начать с этим делать.
С человеческим фактором не так много чего можно сделать - убирать его по максимуму (Убить всех человеков (с) Бендер Родригес) или налаживать взаимодействие. Несмотря на то, что первый путь сильно более эффективный , решили пойти по второму да еще и с прицелом на обучение :).
Собственно говоря, книга раскажет (при том весьма поверхностно) о том как проходят дебрифинги в Etsy и как они пытаются встроить обучение в это вот все.
Научится делать эти самые дебрифинги по книжке вы вряд ли сможете, но сможете посмотреть на то как выглядит довольно самобытная практика фасилитации в большой организации.
Вообще тема человеческого фактора и человеческой ошибки исследована чуть менее чем нихера и пожалуй одним из пионеров в этой области и является Сидни Деккер, кучей ссылок на книги которого пестрит миникнига (в частности https:// www.youtube.com/watch?v=PVWjgqDANWA).
И что в итоге, спросите вы ? Выхода нет, все тлен и безысходность?
Нет, не совсем так.
Просто процитирую кусок из книги
Most traditional accident investigations tend to focus on discovering things around an event that never actually happened. In an attempt to prevent future accidents, there is an underlying assumption (Shorrock, 2014) for this somewhat peculiar emphasis, which is:
Someone did not do something they should have, according to someone else.
Through this lens, what generally surfaces in investigations are “findings” about what people did not do (pay attention, make the right decision, etc.) rather than what they actually did. Without anyone really noticing, these items get labeled as “human error” and through a seductive and convenient contortion of logic, an event that never actually happened is deemed after the fact as the “cause” of the accident. Perhaps unsurprisingly, this results in an obvious recommendation for the future:
“Next time, do what you should.”
Unfortunately, this approach does not result in the safer and improved future we want.
Держа в памяти этот пассаж, вы должны смотреть на каждый разбор полетов в своей организации (если у вас таковые есть, конечно) и выбивать этот самый пресловутый "человеческий фактор", милиметр за милиметром.
21 марта 2017
Напосмотреть : HR : Кризис (пере)оценки
Асхат Уразбаев про то как измерять эффективность IT-специалистов
Интересный рассказ от Яндекса на тему организации школ для подготовки специалистов. Некоторые цифры мне кажутся весьма спорными (ну или я не знаю до конца как считали), но вот про воронки - соответствует тому что я вижу.
В продолжение темы оценки и ревью - опыт коллег из Badoo про внедрение процесса оценки
Пара коротких видео-шпаргалок от Crisp:
про размеры команд и процессы с этим связанные
про ловушку утилизации ресурсов
Отличный доклад с иллюстрацией когнитивных искажений в организациях
Оценивайте своих коллег по заслугам
15 марта 2017
Про GTD
Этот пост я порывался написать давно, и так или иначе меня просили его написать(«слушай, интересно, напиши, почитаем») разные люди, долгое время. Крайним в очереди оказался Барух Садогурский.
Почему я говорю «успешный» ? Мне и самому странно писать это слово в этом бложике, но тем не менее это так - существует очень много талантливых и одаренных распиздяев, которые не могут собрать себя или предмет своего труда в кучу и организовать поставку чего-то тому, кого можно фигурально назвать «заказчиком».
Таким образом, успешными становятся не всегда одаренные, но очень часто организованные.
Вернемся - каждый специалист учится управлять своим временем - явно или не явно.
У каждого эта система вырабатывается по-своему и выглядит по-своему - кому-то хватает липких бумажек, кому-то ежедневника, кто-то делает заметки в календаре (бумажном или электронном).
Но в общем на каком-то этапе у всех специалистов эта система есть.
Почему она есть ?
Потому что «дефицит приносит ясность» как говорилось в одной книге про Гугл, а люди думают что у них дефицит времени, а у специалистов это думание про дефицит времени развито особо сильно.
Время хорошего специалиста (это я про любого специалиста, не только про IT) стоит дорого, всегда и везде.
Это знает его работодатель (если таковой у него есть), это знает сам специалист, это знают его клиенты.
Поэтому работодатель стремится загрузить специалиста по полной (resource-utilization trap в химически-чистом виде) , специалист старается сделать как можно больше работы (особенно, если он работает на себя), ну а клиент- тут и так понятно, пытается отжать либо как больше времени спеца за свои деньги, либо как можно больше пользы для себя.
И в какой-то момент времени, специалист понимает что его текущая система управления временем является ограничением для его дальнейшего роста (финансового, профессионального... - нужное подчеркнуть). И решается пойти искать себе новую систему управления временем.
Идет в интернеты и видит там …
Книги, тренинги и методики довольно разные, и у каждой есть какой-то круг приверженцев/адептов/последователей, которым она подходит.
Иногда там еще есть такое словосочетание «личная эффективность», но такую тему шевелить мне противно, даже палочкой и издалека.
А вот чего нет и вот что самое главное, что я хочу донести.
Никакого тайм-менеджмента или управления временем нет.
Просто, блядь, нет.
Выдохните, успокойтесь и можете читать дальше.
Управлять временем нельзя - вы не можете его замедлить, остановить, ускорить, отмотать назад, взять в банке в кредит или положить под процент.
В ваших сутках 24 часа, каким бы вы специалистом не были, равно как и в сутках папуаса с Новой Гвинеи тоже 24 часа, но по что ему, папуасу, об этом знать ?
Вы не можете управлять временем, но вы можете управлять тем на что вы это (свое) время тратите.
Звучит намного более проигрышно с маркетингово-рекламной стороны в отличии от тайм-менеджмента и управления временем, да ? Зато правдоподобно, не так ли ?
Собственно говоря, все книжки,тренинги и методики пытаются научить именно этому.
Как известно, на вкус и цвет все фломастеры разные, поэтому далее я буду говорить только о тех фломастерах, что пробовал сам.
Но учится я хотел продолжать бесплатно, а для этого учится надо было хорошо.
Осложнялось все тем что работа находилась ровно на противоположном конце Москвы от ВУЗа.
Когда-то тогда, на третьем курсе и родилась моя первая, естественная система управления задачами.
Состояла она из одного Excel-файла с табличкой типа:
Предмет, Задача, Срок, Приоритет, Доп. инфа, Выполнено
Табличка создавалась раз в семестр, по окончании семестра и сдачи сессии, напиваясь, я ритуально ее удалял.
С такими табличками я закончил институт, сдавая по меньшей мере половину экзаменов автоматом и работая не менее 20 часов в неделю.
Это работало. Через год (это я сейчас уже осознаю) у меня произошел первый срыв этой системы , продлился он недели 2, и вот тогда я понял что эта система вывозила меня целый год.
Собрал себя, загнал в эту систему обратно и закончил ВУЗ.
С окончанием ВУЗа вся нагрузка перешла в исключительно рабочую плоскость и эта система себя изжила.
Это нормально, я считаю: нет проблемы которую решала система - нет и самой системы.
Точнее так, я про нее слышал и до этого, но речи Максима в курилке Auriga стали той каплей, которой не хватало до критической массы, чтобы реакция пошла.
В тот год я прочитал две книги - «7 навыков высокоэффектиных людей» Стивена Кови и «Как привести дела в порядок» Дэвида Аллена.
Я могу смело и честно сказать, что эти книги меня изменили, но не берусь оценить какая больше.Я рассматриваю их как систему: Кови рассказывает верхнеуровневую философию, а Аллен - показывает тебе конкретные приемы только для одного из разделов этой философии.
Итог - в 2010 году я «ударился» об GTD.
У меня в памяти остались несколько воспоминаний о том периоде.
Одно из самых ярких - когда ты осваиваешь привычку вытеснять из головы во Входящие любые задачи.
В какой-то момент я поймал себя на том что даже 2-минутные задачи вытесняю туда - уж так мне нравилось понимать и документально фиксировать то, что я что-то не продолбал.
Потом этот перегиб прошел.
Второе самое значимое что появляется - это свободная голова.
Мало кто из вас скорее всего ей обладает, а если это и бывает - то скорее всего случайно.
Восхищает не само состояние свободной головы, а то что оно искусственное и управляемо тобой.
В качестве инструмента для своей тогдашней системы я выбрал Outlook.
Да-да, это офигенный почтовый клиент.
Задачи у меня были в виде писем которые я слал сам себе, и далее рассортировывал из входящих на папки Действия, Документы, Контроль и МодетБыть/КогдаНибудь.
Что очень круто в Outlook - это офигенная интеграция с календарем и (даже!) заметками OneNote.
Более того - она не вечна.
Эта система имеет свойство деградировать и разрушаться (срывы, про которые я писал выше).
Происходит это, на мой взгляд, по ряду причин:
1. Не все изначально освоенные методики и приемы вам подходят - понять это можно только применив их.
2. Окружающая среда и то чем вы в ней занимаетесь меняется. И система должна меняться вместе с Вами. Если вы чувствуете что ваша система разрушается - это не всегда только потому что вы распиздяй.
3. Ваше желание успевать больше на самом деле не ваше - точнее то что вы хотите успевать вам на самом деле не надо.
4. Вы - распиздяй, но такое бывает крайне редко, не обольщайтесь.
В общем ваша система будет регулярно ломаться, вы ее будете чинить и переделывать.
И это нормально.
В свою систему v 1.0 я вносил очень много всяких улучшений, часть из них отмерла, часть из них стабильно живет со мной по сей день.
Например, управление чем-то что чуть больше чем один проект по Аллену я вынес в MindMap-ы (Xmind, Freemind).
Даже у моей текущей системы ( равно как и у всех предыдущих) есть один вроженный недостаток который обуславливается мною - я не люблю работать с календарем, потому что не люблю быть загнанным в сроки.
Точнее даже вот как - понять я это понял сильно раньше, чем у меня в руках появился нормальный инструмент для того чтобы сделать другую систему.
Сейчас я использую MaxDone (бывший Micromiles), пробовал Remember The Milk и другие инструменты, но не прижились.
Для управления проектами и неструктурированной информацией я продолжаю пользоваться XMind, но в нагрузку к нему у меня появился Evernote за деньги.
Что изменилось в моей системе 2.0 :
1. Я научился пользоваться контекстами выполнения задач и планировать на контекст - работая в компании, которая размазана на три локации это, наверное, не удивительно.
2. В ней почти нет календаря - точнее есть , но календарь живет отдельной жизнью.
Вот уже почти два года я менеджерствую - то есть управляю людьми и процессами, и код практически сам не пишу - только по большим праздникам и выходным.
Это отразилось на системе.
В моей системе появилось много регулярных задач - еженедельных, ежемесячных, ежеквартальных - повторяющихся.
В моей системе 1.0 было очень мало задач в папке Контроль - теперь у меня нет папки Контроль, но есть куча задач проконтролировать что-то.
Работа с контекстами расширилась и углубилась - ты набрасываешь себе задач на работу в конкретной локации и оценивая список задач (попутно умножая его на 2 - потому что на месте вылезет еще что-то) можешь прикинуть на сколько дней тебе нужно ехать.
Сказать, что инструментально GTF чем-то отличается от GTD - нельзя.
Ты просто в ту же систему суешь несколько другие вещи.
Ты суешь контрольные точки и дэдлайны по проектам, ты суешь в цели различные степени зрелости(этапы) продукта.
Это не какая-то новая оформленная система, это мутация старой.
Система помогает выполнять задачи из проектов, но проекты управляются этой системой только частично. Часть информации находится во внешних системах - Jira, Wiki, XMind прочее.
GTD дает вам понимание того что вы успеваете и что не успеваете. GTD дает вам бюжет - вы понимаете с какими последствиями вы можете чем пожертвовать и чем позаниматься.
GTD заставляет вас не помнить.
Это можно расценивать как и отрицательное последствие - вы реально не помните всякий шмурдяк - оплата счетов, регулярные митинги - это не в голове.
И как только ты не видишь свою систему - ты ничего не помнишь. И это иногда плохо.
Через то, что ты реально делаешь и доводишь до конца, ты, в первую очередь, меняешь свою жизнь и жизнь вокруг себя.
Это про все - про отсутствующее в холодильнике молоко, перегоревшую и не замененную до сих пор лампочку, про стоматолога и невылеченные зубы. Про проект который ты давно хочешь сделать, но все нет времени.
Ну а тем кто дочитал этот первый в истории уютненького лонгрид - ачивка - вы молодцы!
Преамбула
Каждый успешный специалист, осознанно или нет, в некий момент своей жизни учится управлять своим временем.Почему я говорю «успешный» ? Мне и самому странно писать это слово в этом бложике, но тем не менее это так - существует очень много талантливых и одаренных распиздяев, которые не могут собрать себя или предмет своего труда в кучу и организовать поставку чего-то тому, кого можно фигурально назвать «заказчиком».
Таким образом, успешными становятся не всегда одаренные, но очень часто организованные.
Вернемся - каждый специалист учится управлять своим временем - явно или не явно.
У каждого эта система вырабатывается по-своему и выглядит по-своему - кому-то хватает липких бумажек, кому-то ежедневника, кто-то делает заметки в календаре (бумажном или электронном).
Но в общем на каком-то этапе у всех специалистов эта система есть.
Почему она есть ?
Потому что «дефицит приносит ясность» как говорилось в одной книге про Гугл, а люди думают что у них дефицит времени, а у специалистов это думание про дефицит времени развито особо сильно.
Время хорошего специалиста (это я про любого специалиста, не только про IT) стоит дорого, всегда и везде.
Это знает его работодатель (если таковой у него есть), это знает сам специалист, это знают его клиенты.
Поэтому работодатель стремится загрузить специалиста по полной (resource-utilization trap в химически-чистом виде) , специалист старается сделать как можно больше работы (особенно, если он работает на себя), ну а клиент- тут и так понятно, пытается отжать либо как больше времени спеца за свои деньги, либо как можно больше пользы для себя.
И в какой-то момент времени, специалист понимает что его текущая система управления временем является ограничением для его дальнейшего роста (финансового, профессионального... - нужное подчеркнуть). И решается пойти искать себе новую систему управления временем.
Идет в интернеты и видит там …
Тайм-менеджмент.
Видит он там именно эту самую фразу, сопрягаемую с кучей книг, тренингов, методик.Книги, тренинги и методики довольно разные, и у каждой есть какой-то круг приверженцев/адептов/последователей, которым она подходит.
Иногда там еще есть такое словосочетание «личная эффективность», но такую тему шевелить мне противно, даже палочкой и издалека.
А вот чего нет и вот что самое главное, что я хочу донести.
Никакого тайм-менеджмента или управления временем нет.
Просто, блядь, нет.
Выдохните, успокойтесь и можете читать дальше.
Управлять временем нельзя - вы не можете его замедлить, остановить, ускорить, отмотать назад, взять в банке в кредит или положить под процент.
В ваших сутках 24 часа, каким бы вы специалистом не были, равно как и в сутках папуаса с Новой Гвинеи тоже 24 часа, но по что ему, папуасу, об этом знать ?
Вы не можете управлять временем, но вы можете управлять тем на что вы это (свое) время тратите.
Звучит намного более проигрышно с маркетингово-рекламной стороны в отличии от тайм-менеджмента и управления временем, да ? Зато правдоподобно, не так ли ?
Собственно говоря, все книжки,тренинги и методики пытаются научить именно этому.
Как известно, на вкус и цвет все фломастеры разные, поэтому далее я буду говорить только о тех фломастерах, что пробовал сам.
Система v 0.1
Я был студентом и начал работать.Но учится я хотел продолжать бесплатно, а для этого учится надо было хорошо.
Осложнялось все тем что работа находилась ровно на противоположном конце Москвы от ВУЗа.
Когда-то тогда, на третьем курсе и родилась моя первая, естественная система управления задачами.
Состояла она из одного Excel-файла с табличкой типа:
Предмет, Задача, Срок, Приоритет, Доп. инфа, Выполнено
Табличка создавалась раз в семестр, по окончании семестра и сдачи сессии, напиваясь, я ритуально ее удалял.
С такими табличками я закончил институт, сдавая по меньшей мере половину экзаменов автоматом и работая не менее 20 часов в неделю.
Это работало. Через год (это я сейчас уже осознаю) у меня произошел первый срыв этой системы , продлился он недели 2, и вот тогда я понял что эта система вывозила меня целый год.
Собрал себя, загнал в эту систему обратно и закончил ВУЗ.
С окончанием ВУЗа вся нагрузка перешла в исключительно рабочую плоскость и эта система себя изжила.
Это нормально, я считаю: нет проблемы которую решала система - нет и самой системы.
Система v 1.0
Еще пока я учился и работал в Auriga, я познакомился с Максимом Дорофеевым, который поведал мне о книге Дэвида Аллена Getting Things Done.Точнее так, я про нее слышал и до этого, но речи Максима в курилке Auriga стали той каплей, которой не хватало до критической массы, чтобы реакция пошла.
В тот год я прочитал две книги - «7 навыков высокоэффектиных людей» Стивена Кови и «Как привести дела в порядок» Дэвида Аллена.
Я могу смело и честно сказать, что эти книги меня изменили, но не берусь оценить какая больше.Я рассматриваю их как систему: Кови рассказывает верхнеуровневую философию, а Аллен - показывает тебе конкретные приемы только для одного из разделов этой философии.
Итог - в 2010 году я «ударился» об GTD.
У меня в памяти остались несколько воспоминаний о том периоде.
Одно из самых ярких - когда ты осваиваешь привычку вытеснять из головы во Входящие любые задачи.
В какой-то момент я поймал себя на том что даже 2-минутные задачи вытесняю туда - уж так мне нравилось понимать и документально фиксировать то, что я что-то не продолбал.
Потом этот перегиб прошел.
Второе самое значимое что появляется - это свободная голова.
Мало кто из вас скорее всего ей обладает, а если это и бывает - то скорее всего случайно.
Восхищает не само состояние свободной головы, а то что оно искусственное и управляемо тобой.
В качестве инструмента для своей тогдашней системы я выбрал Outlook.
Да-да, это офигенный почтовый клиент.
Задачи у меня были в виде писем которые я слал сам себе, и далее рассортировывал из входящих на папки Действия, Документы, Контроль и МодетБыть/КогдаНибудь.
Что очень круто в Outlook - это офигенная интеграция с календарем и (даже!) заметками OneNote.
Система v 1.X
Система управления задачами которую вы припаяли к своей голове - нестатична.Более того - она не вечна.
Эта система имеет свойство деградировать и разрушаться (срывы, про которые я писал выше).
Происходит это, на мой взгляд, по ряду причин:
1. Не все изначально освоенные методики и приемы вам подходят - понять это можно только применив их.
2. Окружающая среда и то чем вы в ней занимаетесь меняется. И система должна меняться вместе с Вами. Если вы чувствуете что ваша система разрушается - это не всегда только потому что вы распиздяй.
3. Ваше желание успевать больше на самом деле не ваше - точнее то что вы хотите успевать вам на самом деле не надо.
4. Вы - распиздяй, но такое бывает крайне редко, не обольщайтесь.
В общем ваша система будет регулярно ломаться, вы ее будете чинить и переделывать.
И это нормально.
В свою систему v 1.0 я вносил очень много всяких улучшений, часть из них отмерла, часть из них стабильно живет со мной по сей день.
Например, управление чем-то что чуть больше чем один проект по Аллену я вынес в MindMap-ы (Xmind, Freemind).
Даже у моей текущей системы ( равно как и у всех предыдущих) есть один вроженный недостаток который обуславливается мною - я не люблю работать с календарем, потому что не люблю быть загнанным в сроки.
Система v 2.0
Переход на систему версии 2.0 у меня состоялся когда я понял, что почтовый ящик не является более источником моих задач, а прилетают они из любых других мест, но не из него.Точнее даже вот как - понять я это понял сильно раньше, чем у меня в руках появился нормальный инструмент для того чтобы сделать другую систему.
Сейчас я использую MaxDone (бывший Micromiles), пробовал Remember The Milk и другие инструменты, но не прижились.
Для управления проектами и неструктурированной информацией я продолжаю пользоваться XMind, но в нагрузку к нему у меня появился Evernote за деньги.
Что изменилось в моей системе 2.0 :
1. Я научился пользоваться контекстами выполнения задач и планировать на контекст - работая в компании, которая размазана на три локации это, наверное, не удивительно.
2. В ней почти нет календаря - точнее есть , но календарь живет отдельной жизнью.
Система 2.X - GTF
По аналогии с Getting Things Done у меня возникла аббревиатура GTF (Getting Things/Them Fuck) - это когда твоя система управления задачами заточена на то, чтобы другие люди выполняли задачи, которые являются строительными блоками твоих проектов. Да, вы все правильно поняли - это для менеджеров и про менеджеров.Вот уже почти два года я менеджерствую - то есть управляю людьми и процессами, и код практически сам не пишу - только по большим праздникам и выходным.
Это отразилось на системе.
В моей системе появилось много регулярных задач - еженедельных, ежемесячных, ежеквартальных - повторяющихся.
В моей системе 1.0 было очень мало задач в папке Контроль - теперь у меня нет папки Контроль, но есть куча задач проконтролировать что-то.
Работа с контекстами расширилась и углубилась - ты набрасываешь себе задач на работу в конкретной локации и оценивая список задач (попутно умножая его на 2 - потому что на месте вылезет еще что-то) можешь прикинуть на сколько дней тебе нужно ехать.
Сказать, что инструментально GTF чем-то отличается от GTD - нельзя.
Ты просто в ту же систему суешь несколько другие вещи.
Ты суешь контрольные точки и дэдлайны по проектам, ты суешь в цели различные степени зрелости(этапы) продукта.
Это не какая-то новая оформленная система, это мутация старой.
Система помогает выполнять задачи из проектов, но проекты управляются этой системой только частично. Часть информации находится во внешних системах - Jira, Wiki, XMind прочее.
Что дает GTD
GTD дает вам чистую голову - у вас не жужжит в голове рой мыслей на тему всякого говна.GTD дает вам понимание того что вы успеваете и что не успеваете. GTD дает вам бюжет - вы понимаете с какими последствиями вы можете чем пожертвовать и чем позаниматься.
GTD заставляет вас не помнить.
Это можно расценивать как и отрицательное последствие - вы реально не помните всякий шмурдяк - оплата счетов, регулярные митинги - это не в голове.
И как только ты не видишь свою систему - ты ничего не помнишь. И это иногда плохо.
Самое главное
Восприятие(внимание) управляет реальностью, как говорилось в одном фильме который я не люблю, но это так.Через то, что ты реально делаешь и доводишь до конца, ты, в первую очередь, меняешь свою жизнь и жизнь вокруг себя.
Это про все - про отсутствующее в холодильнике молоко, перегоревшую и не замененную до сих пор лампочку, про стоматолога и невылеченные зубы. Про проект который ты давно хочешь сделать, но все нет времени.
Ну а тем кто дочитал этот первый в истории уютненького лонгрид - ачивка - вы молодцы!
14 марта 2017
Напосмотреть: Лицекнижие
Большей частью про тестирование.
1. Кирилл Толкачев о том в какую правильную позу надо ставить Jenkins особенно если ты часть кровавого ынтерпрайза
2. Неочевидные подходы к обеспечению качества путем анализа архитектуры (осторожно, UML), коммитов и работы кода в продакшене.
кстати говоря код их поделия можно посмотреть здесь
3. Продолжая тему Jenkins и то сколько там вокруг граблей и как это все натягивать на суровую разработку
4. Про то как в Яндексе пишут автотесты прямо в браузере
5. Концентрат мудрости - Алексей Лупан про обучение тестировщиков
В завершение два видео от Facebook на тему автоматизации тестирования Android и IOS.
IOS
Android
27 февраля 2017
Книга : Planning as a social event - Scaling Agile at LEGO, Henrik Kniberg
Традиционного ревью на книжку не будет - она очень маленькая, вы можете прочитать ее сами, я сделал это за пару дней в метро, урывками.
Будут мысли:
0. Маленькие книжки с описанием конкретных кейсов и опыта - это просто блеск, а Книберг, как никто другой, умеет писать их емко и по делу.
1. Читая эту книжку в уме всплывали ГОСТы которыми нас дрючили в моей первой alma mater, и корявые описания артефактов и инструментов RUP, которыми дрючили во второй alma mater.
Вывод из всей книжки далеко не свежий - agile-методологии хреново масштабируются. Да и вообще с чего бы им масштабироваться хорошо ? Все инструменты устремлены в заказчика и команду, и в то как навести мосты любви и дружбы между ними, а не в то как это сделать в случае с N командами, где N>2.
2. Коллективный сеанс планирования длительностью в два дня на 4 итерации разработки по две недели (два месяца, в итоге) как практика - что еще может лучше иллюстрировать эквивалентную стоимость хренового планирования и издержек, которые несет организация по этой причине. Выдернуть 50-80 человек из процесса написания и поставки кода на два дня - эти расходы можно очень просто посчитать. Видимо издержки от непроведения такого мероприятия сильно выше (принимая во внимание масштабы операционной деятельности Lego можно смело сказать что они запредельно выше). Итог: план - ничто, планирование - все.
3. Очень интересный момент, что менеджеров заставляют напрямую работать с рисками выявленными при планировании командами по ROAM-фреймворку (Resolved, Owner, Accepted, Mitigated). Очень интересно, что само планирование - является ответственностью команды, а адекватность планов и учет рисков - зоной ответственности менеджмента. Итого : менеджмент нужен.
4. Из четырех итераций три посвящены самой разработке, а четвертая - буфер для инноваций, рефакторингов, и просто для того чтобы успеть. 25% плана - в буфер. Суровая реальность.
Собственно сама книжка вот тут.
А вот тут все про тоже выравнивание только уже от Мартина Фаулера - тоже очень интересно.
Будут мысли:
0. Маленькие книжки с описанием конкретных кейсов и опыта - это просто блеск, а Книберг, как никто другой, умеет писать их емко и по делу.
1. Читая эту книжку в уме всплывали ГОСТы которыми нас дрючили в моей первой alma mater, и корявые описания артефактов и инструментов RUP, которыми дрючили во второй alma mater.
Вывод из всей книжки далеко не свежий - agile-методологии хреново масштабируются. Да и вообще с чего бы им масштабироваться хорошо ? Все инструменты устремлены в заказчика и команду, и в то как навести мосты любви и дружбы между ними, а не в то как это сделать в случае с N командами, где N>2.
2. Коллективный сеанс планирования длительностью в два дня на 4 итерации разработки по две недели (два месяца, в итоге) как практика - что еще может лучше иллюстрировать эквивалентную стоимость хренового планирования и издержек, которые несет организация по этой причине. Выдернуть 50-80 человек из процесса написания и поставки кода на два дня - эти расходы можно очень просто посчитать. Видимо издержки от непроведения такого мероприятия сильно выше (принимая во внимание масштабы операционной деятельности Lego можно смело сказать что они запредельно выше). Итог: план - ничто, планирование - все.
3. Очень интересный момент, что менеджеров заставляют напрямую работать с рисками выявленными при планировании командами по ROAM-фреймворку (Resolved, Owner, Accepted, Mitigated). Очень интересно, что само планирование - является ответственностью команды, а адекватность планов и учет рисков - зоной ответственности менеджмента. Итого : менеджмент нужен.
4. Из четырех итераций три посвящены самой разработке, а четвертая - буфер для инноваций, рефакторингов, и просто для того чтобы успеть. 25% плана - в буфер. Суровая реальность.
Собственно сама книжка вот тут.
А вот тут все про тоже выравнивание только уже от Мартина Фаулера - тоже очень интересно.
21 февраля 2017
Напосмотреть: Девелоперско-попсовый
Подобралась пачечка попсовых девелоперских тем.
1. О том что такое CRDT но человеческим языком и с картинками
2. Отличный рассказ о том что есть Kotlin и каковы его возможности. После этого рассказа даже я ударился об хипстерство и попробовал.
3. Dan North в очередной раз про микросервисы, но вот тирады про "Costs" и "Fits in your head" просто заставляют меня поставить это видео в выпуск.
4. Умный дядька про распределенные системы
5. О том что такое gRPC , зачем оно вообще надо, в двух частях (вторую найдете сами :))
13 февраля 2017
Напочитать: Мобилизация автоматизированного тестирования
1. О том как расширять Calabash с помощью UIAutomator рассказывают ребята из Badoo
2. Что такое Robolectric и надо ли оно вообще - от eLegion.
3. Потестировать свой сайтик на соответствие представлениям гугла о верстке мобильных сайтов теперь можно за счет самого гугла. Детали тут.
4. LinkedIn выкинул в open source BluePill - свою приспособу для параллельного запуска тестов на IOS.
5. Подборка онлайн-курсов по мобильной разработке - врага надо знать в лицо.
6. Курсы яндекса по мобильную разработку, интерфейсы и дизайн - тут.
7. Про то как тестируют в Cloudera: mrunit для unit-тестирования Map-Reduce Job и Fault-Injection Testing
8. Gremlin-ы для тестирования пользовательского интерфейса - старая идея Monkey Testing в новом обличии
9. Помните макросы в MS Word/Excel ? Google вмутил тоже самое у себя - Google App Script.
10. Пацаны из SpringTest окончательно упоролись (хотя казалось бы куда уж дальше, и так Spring) и начали писать вложенные друг в друга тесты. И все бы ничего, но эти же поцы причастны к JUnit 5 (Lambda), так что скоро это
11. Dex Test Parser или как LinkedIn борется с граблями Android разложенными в области тестирования.
Ярлыки:
bluepill,
calabash,
cloudera,
courses,
dextestparser,
Google,
junit5,
linkedin,
mobile-friendly,
mooc,
mrunit,
robolectric,
uiautomator
07 февраля 2017
Книга: Agile Ретроспектива
Собственно соучаствовал в издании, пора бы и отчитаться за труды.
Вообще тема ретроспектив меня интересует очень давно - я даже и сам писал на эту тему.
Я действительно считаю ретроспективы сильнейшим инструментом.
Собственно, фундаментальным трудом в области ретроспектив проектов является книга Норма Керта, и волей-неволей любую книгу на тему ретроспектив я буду сравнивать с ней.
Книга Дианы Ларсен и Эстер Дерби никак не претендует на звание фундаментального труда.
Скорее методичка для "отчаянных агилистов", которые забыли про ретроспективу .
Что смутило с самого начала и не отпускало до конца книги - пример ретроспективы которую команда проводит за час и каждый раз у команды новый ведущий.
Итак, что предложит вам книга:
1. Общее описание процесса ретроспективы
2. Каталог активностей (упражнений) для каждого этапа, сопровождаемый комментариями а-ля "умелый фасилитатор-самоучка".
3. заключительные мысли.
За что книгу можно похвалить:
1. за хороший каталог активностей (упражнений). Действительно их там не мало, по сравнению с книгой Норма Керта. Особенно понравилось , ИПОЗ.
2. Мысль о том что "день рождения - это ваша ретроспектива которая всегда с вами" - блеск.
3. Менять помещение для свежего взгляда - тоже очень хорошая мысль, проверял на практике сам.
За что книгу хочется поругать :
1. Утверждения о целях на ретроспективу - на мой взгляд, это скорее редкость. Обычно ретроспектива и служит для поиска цели, а не отталкивается от нее.
2. Примерные выкладки по времени ретроспективы, вида "недельная итерация -часовая ретроспектива" - бред. Существует нижний предел времени, меньше которого ретроспективу (качественно!) провести невозможно, и он, по моим наблюдениям, в районе 1,5-2 часов. Все что выше - вполне валидно, все что меньше - не возможно.
Итого: читать книгу если и стоит то только после того как прочтете книгу Норма Керта, она даст вам знаний больше.
Вообще тема ретроспектив меня интересует очень давно - я даже и сам писал на эту тему.
Я действительно считаю ретроспективы сильнейшим инструментом.
Собственно, фундаментальным трудом в области ретроспектив проектов является книга Норма Керта, и волей-неволей любую книгу на тему ретроспектив я буду сравнивать с ней.
Книга Дианы Ларсен и Эстер Дерби никак не претендует на звание фундаментального труда.
Скорее методичка для "отчаянных агилистов", которые забыли про ретроспективу .
Что смутило с самого начала и не отпускало до конца книги - пример ретроспективы которую команда проводит за час и каждый раз у команды новый ведущий.
Итак, что предложит вам книга:
1. Общее описание процесса ретроспективы
2. Каталог активностей (упражнений) для каждого этапа, сопровождаемый комментариями а-ля "умелый фасилитатор-самоучка".
3. заключительные мысли.
За что книгу можно похвалить:
1. за хороший каталог активностей (упражнений). Действительно их там не мало, по сравнению с книгой Норма Керта. Особенно понравилось , ИПОЗ.
2. Мысль о том что "день рождения - это ваша ретроспектива которая всегда с вами" - блеск.
3. Менять помещение для свежего взгляда - тоже очень хорошая мысль, проверял на практике сам.
За что книгу хочется поругать :
1. Утверждения о целях на ретроспективу - на мой взгляд, это скорее редкость. Обычно ретроспектива и служит для поиска цели, а не отталкивается от нее.
2. Примерные выкладки по времени ретроспективы, вида "недельная итерация -часовая ретроспектива" - бред. Существует нижний предел времени, меньше которого ретроспективу (качественно!) провести невозможно, и он, по моим наблюдениям, в районе 1,5-2 часов. Все что выше - вполне валидно, все что меньше - не возможно.
Итого: читать книгу если и стоит то только после того как прочтете книгу Норма Керта, она даст вам знаний больше.
17 января 2017
Напочитать: DEV-ственные Heap-стеры
1. нечеткие регулярные выражения - случайно попали в поле зрения (Осторожно, хипстеры! По ссылке sourceforge)
2. Netflix сливает в open-source очередную порцию своих проектов: Hollow и Conductor
3. jcmd прямо в коде. Прикрутил себе кое-куда, удобно чо.
4. О том как ByteBuddy может помочь в борьбе за SecurityManager да и вообше много про SecurityManager в этом бложике.
5. А вот тут можно заглянуть под юбку java разработке в Facebook - jcommons
6. Spring тоже решил ударится об реактивщину (на самом деле давно) - Reactor. Мне это все начинает напоминать JavaScript-мир - каждый задрот на коленке пилит свой новый велосипед, думая что ну вот в его-то исполнении колеса точно будут круглыми. А вот тут вот еще можно посмотреть примеров холодных и горячих стримов.
7. Надоело наблюдать как все python-ируют на Machine Learning (привет, Coursera)? Не расстраивайтесь, на Java тоже можно. Ну и канальчик от Гугла на ту же тему - вот да.
8. Что такое service images и executable images и чем они отличаются в Docker? Нет, не подумайте, у меня не докер головного мозга, но вот у некоторых - да.
9. Конструктор дэшбордиков от NASA - OpenMCT. NodeJS, если что.
10. MutabilityDetector для ваших хипстерских POJO-ей.
11. Огромнейшая простыня про Nashorn - тут.
12. Про то как хипстота из гугла запускает Python на Go - Grumpy.
13. метод 3-I (Isolate-Improve-Inline) или как правильно рефакторить. Руководство для начинающих хипстеров.
14. failsafe - не hystrix единым.
15. Ну и напоследок набор хипстерских git alias-ов
Ярлыки:
byte buddy,
conductor,
docker,
Facebook,
frej,
go,
grumpy,
hollow,
immutability,
jcmd,
jcommons,
machine learning,
mutability detector,
nasa,
nashorn,
netflix,
python,
security manager
Подписаться на:
Сообщения (Atom)