Какое-то время назад Upcase (обучающая платформа от thoughtbot) стал бесплатным.
А теперь открыли и книги ==> https://thoughtbot.com/blog/books-free
Сами книги: https://books.thoughtbot.com/

https://dev.to/shecoded
Истории программисток на dev.to . Я тоже написала.

Отличный эпизод подкаста devzen ==> https://devzen.ru/episode-0232/
Темы: менторство и спонсорство, варианты развития карьеры и навыков, процесс ревью на работе.
Обычно я 2 с половиной часа подкаста не выдерживаю, но в этот раз было очень интересно было услышать опыт участниц (не за один присест, конечно :)

Хотела сделать маленький пост про rubycritic, но оказалось, что дефолтный отчёт не генерируется.
Пришлось контрибьютить 💁🏻‍♀️ https://github.com/whitesmith/rubycritic/pull/299

Начала вести маленький книжный клуб по "Working Effectively with Legacy Code" Майкла Физерса.
Сделала краткое содержание первых двух глав на русском ==> https://gist.github.com/lightalloy/2d1f05d5ba2dce3f59d8facdbb0b2b39

#книги

Недавно изучала информацию по книжным клубам, полелюсь:

Пост от Эллисон МакМиллан с советами по организации клуба:
http://daydreamsinruby.com/running-a-book-club/

Несколько полезных мыслей в комментариях к посту на dev.to
https://dev.to/acflint/dev-book-club-36cl
Результата я не увидела, предполагаю, что никто так и не организовал.

Dev Empathy Book club - Книжный клуб онлайн
https://devempathybook.club/
Книги можно посмотреть на сайте.
Обсуждения раз в неделю в слаке и примерно раз в месяц видео-обсуждение + трансляция на ютуб.
Я присоединилась к слаку, на мой взгляд там очень мало активности. Подумывала почитать-пообсуждать с ними, но решила пока сконцетрироваться на своём книжном клубе.

#книги

Подписалась на рассылку "Developer Avocados" ==> http://developeravocados.net/
Не то чтобы я собиралась переквалифицироваться в авокадо 🥑, но хотелось бы развивать не только программерские, но и смежные навыки.
Поэтому почитываю про письмо, речь и т.д.

Читаю "Working with Legacy Code" в оригинале, но иногда интересно посмотреть как перевели те или иные понятия на русский (бедный переводчик!)

> 1. Определение точек изменения.
> 2. Нахождение тестовых точек.
> 3. Разрывание зависимостей.
> 4. Написание тестов.
> 5. Внесение изменений и реорганизация кода.

Параллельно слегка читаю "Слово живое и мёртвое" Норы Галь. Думаю, она заругала бы за такой перевод :D
В английском есть герундий (*-ing) и это очень удобно. На русский его часто переводят как существительное, и получается что-то неестественное. Например, "разрывание" 🤨 Обычно можно переписать так, чтобы вместо существительных были глаголы.

Да, Нора писала не про технические тексты, но я думаю, что часто её советы подходят и к ним.

#книги

Нужно что-то читать параллельно "Working with Legacy Code", поэтому купила "How to Bake pi" Евгении Ченг.
Ожидаю введение в теорию категорий для самых маленьких. Посмотрим, что будет на самом деле.

#книги

Как у нас вчера провели первое апреля:
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", по-моему, описан стандартно:
- сначала пишем "красный" тест (который падает), иначе можно случайно написать тест, который ничего толком не тестирует
- пишем грязный код, только чтобы прошли тесты
- рефакторим "под прикрытием"
- не пишем новые тесты, когда рефакторим детали (приватные методы, реализацию публичных)

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