Как у нас вчера провели первое апреля:
https://twitter.com/ThePracticalDev/status/1112759560547258368

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

#devto

Написала первый пост на dev.to (не считая поста для shecoded).
Пока введение в тему обучения через чтение книг 📚
Чувствую необходимость написать ещё несколько постов про книги, прежде чем переходить к другим темам 💁🏻‍♀️
https://bit.ly/2Vm8ov9

#книги

https://github.com/github/personal-website

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

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

https://m.signalvnoise.com/to-smile-again/
Интересный пост про выгорание и восстановление от бывшего сотрудника 37signals/Basecamp.
Мне сложно представить, как можно сразу же после увольнения из-за серьёзного выгорания, начинать бизнес, хоть и в другой сфере.
Наверное, я больше сталкивалась с общей усталостью, а не выгоранием именно от программирования.

https://dev.to/devteam/expanding-the-dev-core-team-5b0g
Теперь совсем официально в команде.

#devto

https://twitter.com/github/status/1131477029730308096?s=12
На гитхабе теперь можно спонсировать людей, напоминает Patreon.

📚 Дочитала "How to bake pi" (https://amzn.com/0465097677), очень крутая, попробую написать обзор на неё.
Сейчас дочитываю "Working with Legacy Code" и вместо чтения буду выделять побольше времени на письмо.
Следующей книгой скорее всего будет "Release it!"(https://amzn.com/1680502395), но читать её буду в более свободном режиме.

#книги

Доклад о TDD и о том, что с ним не так

https://www.youtube.com/watch?v=EZ05e7EMOLM

Вот что можно из него вынести:

- читайте Кента Бека, многие проблемы там уже разобраны (я ещё не читала)
в частности "TDD by example" https://www.amazon.com/gp/product/0321146530/

- не следуйте tdd религиозно
Как обычно, нужно в первую очередь думать своей головой. Не всегда оптимально использовать TDD. Тут так же, как с говнокодом: иногда писать его - нормально.

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

- не мокайте слишком много
Лучше мокать только "дорогие" операции, а не всё подряд. Если пытаться изолировать класс, чтобы протестировать только его, то очень легко пропустить ошибки.

Сама недавно столкнулась с такой ситуацией: опечатку отловила только глазами на код-ревью, хотя тесты присутствовали. Просто замокано было слишком много.
Если следовать этому правилу и не мокать все зависимости, юнит-тесты становятся мини-интеграционными. Я думаю, что в этом нет ничего страшного, пока тесты действительно "мини-" и проходят достаточно быстро.
Понравилось определение из доклада: developer-тесты вместо юнит-тестов. То есть название по роли в разработке, а не по тому, что они тестируют.

- причиной написать тест должно быть изменение поведения, а не добавление нового метода

Принцип "Red-green-refactor", по-моему, описан стандартно:
- сначала пишем "красный" тест (который падает), иначе можно случайно написать тест, который ничего толком не тестирует
- пишем грязный код, только чтобы прошли тесты
- рефакторим "под прикрытием"
- не пишем новые тесты, когда рефакторим детали (приватные методы, реализацию публичных)

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

Меня несколько раз спрашивали, как dev.to зарабатывает деньги.
Вот ответ одного из фаундеров: https://dev.to/ben/comment/bdlb

#devto

Удобный плагин для VsCode для переключения между кодом и тестом (на рельсовых проектах), почему-то не сразу стала им пользоваться.
https://marketplace.visualstudio.com/items?itemName=sporto.rails-go-to-spec
Ещё один похожий для js и руби:
https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec

"Свободное" время на работе

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

Часто дополнительно обучение — это и пожелание работодателя, поэтому некоторые компании пытаются решить эту проблему, выделяя рабочее время.

В первый раз я услышала о немного другой, но похожей практике, применительно к Google. Это было "правило 20%". Суть в том, что один рабочий день в неделю можно выделить на "свои" проекты. Меня это не очень впечатлило, т.к. проекты, естественно, являлись собственностью компании, хотя теоретически это даёт некоторую свободу. С самим правилом тоже не всё так просто, его реализацию много критикуют. Например, говорят, что самом деле это не 20, а 120% (https://bit.ly/2WrtUyh), и что людей нельзя заставить "быть креативными" в определённое время.

В последнее время мне стала попадаться информация о других компаниях, в которых есть подобная практика.
Например, "investment time" в thoughbot (https://thoughtbot.com/blog/investment-time). 4 дня в неделю сотрудники работают над клиентскими проектами, а по пятницам — над другими полезными для компании вещами: можно подготовить доклад, написать пост, записать подкаст, поработать над опенсурсом, почитать книгу или пройти курс. Это не обязательно что-то техническое, например, мне понравился вариант — расписать стену в офисе.

В небулабе (https://bit.ly/2MBk8tL) делают примерно так же.

У Thoughtbot и Nebulab есть открытые плейбуки, из которых можно узнать, как устроена работа в компаниях:
https://thoughtbot.com/playbook
https://playbook.nebulab.it/

Сокращённая рабочая неделя — другая тема, и скорее служит бонусом для сотрудников и защитой от выгорания. Впрочем, дополнительный выходной можно потратить и на вклад в свою карьеру.
Вот пара примеров:
- в icelab'е просто заявлена 4-хдневная 32-хчасовая рабочая неделя (https://www.icelab.com.au/careers)
- в basecamp'е — 4-хдневная рабочая неделя с начала мая по конец августа. https://bit.ly/31rwMyT

#работа

Плейлист о карьере от Маюко.
Скорее ориентирован на начало карьеры, но будет полезен и опытным. Мне понравились части про нетворкинг и карьерные цели.
Видео очень короткие - по 2-5 минут и их удобно смотреть по кусочкам.
https://www.youtube.com/playlist?list=PL1hNTJtl-Vt5FGkgnfo3e0HjK-YPYCQzR

В рельсах появится вью-компоненты (ActionView::Component)
https://dev.to/andy/rails-to-introduce-view-components-3ome

На одной из первых работ (в конце 2000-х) у нас была своя супер-cms на php и там была похожая концепция.
Как тогда они меня бесили! Тогда хотелось простой mvc, т.к. параллельно изучала всякие php-фреймворки и казалось, что это единственный правильный вариант.
Сейчас уже мало что о них помню, но в последние годы уже не раз вспоминала эти компоненты, например, после изучения реакта. Возможно, они были не такой уж плохой идеей :D
Интересно, как меняется восприятие со временем и приобретённым опытом.

Но надо помнить, что mvc - не mvc☝️
https://twitter.com/avdi/status/1139232955530993665

https://twitter.com/jessleenyc/status/1139586747208273920
Команда растёт за счёт интернов и единорогов ✨

#devto

Я подозрительно отношусь к shoulda_matchers [https://git.io/fj23m] 🕵️‍♀️
Вроде красиво, но пока не заглянешь в код гема, не видно, как и что там на самом деле проверяется:

it { is_expected.to validate_uniqueness_of(:username) }

На днях напоролась на одну особенность:
Для проверки уникальности shoulda сама создаёт записи в минимальными атрибутами, но не валидирует их:
https://git.io/fjg2g

При этом создание может зафейлиться из-за органичений в базе данных, а в нашем случае — из-за того, что не хватило данных для коллбека:
https://git.io/fjadm

Конечно, наличие такой логики в коллбеках само по себе не очень, но это уже отдельная тема.

Трекинг рабочего времени

Подсмотрела пример из плейбука небулаба (https://bit.ly/2XXBL8l)

Они трекают:
- время присутствия. Если меньше или больше 8 часов в день, нужно отрепортить. Овертаймы и недоработки компенсирую друг друга не автоматически, а только по просьбе.
- время, оплачиваемое клиентом (billable time). Это время, потраченое непосредственно на работу над проектом.
- время на обучение, 1:1, внутренние проекты и т.д.
- "потерянное" время (time wasting)

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

На моих работах было так:
- пропускная система + жёсткий рабочий график в госучреждении (но я парттаймила, поэтому было не так жёстко)
- мягкий офисный график без отчётов, но с примерным временем прихода-ухода
- относительно свободный график + таймер на офисном компьютере, который считал общее рабочее время за неделю/месяц
- на удалёнке - отчёты о потраченном времени на ту или иную задачу по часам, относительно свободный график
- сейчас - ещё более свободный график, трекаю только общее количество часов за месяц

Не очень люблю почасовку, но использую её, как компромисс. Обычно всё равно получается так, что у меня скорее "покупают" месяц работы.

Трекинг времени я рассматриваю скорее как инструмент для личной эффективности и планирования.
Иногда расписываю день по часам, но обязательно закладываю буфер на все задачи. Это время в любом случае уйдёт на переключение контекста, внеплановые отвлечения и задачи.

#работа

Do you use time-tracking for work or for your personal time? - DEV Community 👩‍💻👨‍💻
https://dev.to/