https://twitter.com/github/status/1131477029730308096?s=12
На гитхабе теперь можно спонсировать людей, напоминает Patreon.
На гитхабе теперь можно спонсировать людей, напоминает Patreon.
Twitter
GitHub
GitHub Sponsors is here—see it in action! #GitHubSatellite
📚 Дочитала "How to bake pi" (https://amzn.com/0465097677), очень крутая, попробую написать обзор на неё.
Сейчас дочитываю "Working with Legacy Code" и вместо чтения буду выделять побольше времени на письмо.
Следующей книгой скорее всего будет "Release it!"(https://amzn.com/1680502395), но читать её буду в более свободном режиме.
#книги
Сейчас дочитываю "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", по-моему, описан стандартно:
- сначала пишем "красный" тест (который падает), иначе можно случайно написать тест, который ничего толком не тестирует
- пишем грязный код, только чтобы прошли тесты
- рефакторим "под прикрытием"
- не пишем новые тесты, когда рефакторим детали (приватные методы, реализацию публичных)
Ещё доклад помогает потренироваться понимать неидеальную английскую речь.
Поначалу очень трудно было разобрать, что он говорит, но через несколько минут мозг натренировался. Одновременно смотреть слайды и слушать всё равно трудно, а вот в формате подкаста усвоить информацию получилось.
https://www.youtube.com/watch?v=EZ05e7EMOLM
Вот что можно из него вынести:
- читайте Кента Бека, многие проблемы там уже разобраны (я ещё не читала)
в частности "TDD by example" https://www.amazon.com/gp/product/0321146530/
- не следуйте tdd религиозно
Как обычно, нужно в первую очередь думать своей головой. Не всегда оптимально использовать TDD. Тут так же, как с говнокодом: иногда писать его - нормально.
- тестируйте стабильное, а не детали имплементации
Тестируйте интерфейс класса, то есть то, что доступно извне (в руби это будут просто публичные методы). Интерфейс должен быть небольшим, а детали имплементации должны быть скрыты. Таким образом, их можно будет поменять, не меняя тесты. Если возникает вопрос, как тестировать приватные методы, возможно стоит вынести логику в отдельный класс.
- не мокайте слишком много
Лучше мокать только "дорогие" операции, а не всё подряд. Если пытаться изолировать класс, чтобы протестировать только его, то очень легко пропустить ошибки.
Сама недавно столкнулась с такой ситуацией: опечатку отловила только глазами на код-ревью, хотя тесты присутствовали. Просто замокано было слишком много.
Если следовать этому правилу и не мокать все зависимости, юнит-тесты становятся мини-интеграционными. Я думаю, что в этом нет ничего страшного, пока тесты действительно "мини-" и проходят достаточно быстро.
Понравилось определение из доклада: developer-тесты вместо юнит-тестов. То есть название по роли в разработке, а не по тому, что они тестируют.
- причиной написать тест должно быть изменение поведения, а не добавление нового метода
Принцип "Red-green-refactor", по-моему, описан стандартно:
- сначала пишем "красный" тест (который падает), иначе можно случайно написать тест, который ничего толком не тестирует
- пишем грязный код, только чтобы прошли тесты
- рефакторим "под прикрытием"
- не пишем новые тесты, когда рефакторим детали (приватные методы, реализацию публичных)
Ещё доклад помогает потренироваться понимать неидеальную английскую речь.
Поначалу очень трудно было разобрать, что он говорит, но через несколько минут мозг натренировался. Одновременно смотреть слайды и слушать всё равно трудно, а вот в формате подкаста усвоить информацию получилось.
YouTube
🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
🗓️ Upcoming developer events: https://dev.events Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent's original rules so that TDD practice bears little resemblance…
Меня несколько раз спрашивали, как dev.to зарабатывает деньги.
Вот ответ одного из фаундеров: https://dev.to/ben/comment/bdlb
#devto
Вот ответ одного из фаундеров: https://dev.to/ben/comment/bdlb
#devto
DEV Community
We have a few pillars of monetization, some mat... — DEV Community
There has been renewed backlash against Medium lately. It stems from an idea that Medium has engaged...
Удобный плагин для VsCode для переключения между кодом и тестом (на рельсовых проектах), почему-то не сразу стала им пользоваться.
https://marketplace.visualstudio.com/items?itemName=sporto.rails-go-to-spec
Ещё один похожий для js и руби:
https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec
https://marketplace.visualstudio.com/items?itemName=sporto.rails-go-to-spec
Ещё один похожий для js и руби:
https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec
Visualstudio
Rails Go to Spec - Visual Studio Marketplace
Extension for Visual Studio Code - Switch between code and spec in Rails
"Свободное" время на работе
Многим айтишницам хотелось бы делать свои проекты, контрибьютить в опенсурс, читать книги, писать посты. На это сложно выделить время, потому что работа фуллтайм занимает примерно всю жизнь. Даже если время есть, хочется заняться чем-то ещё, а не тратить силы на околорабочую деятельность.
Часто дополнительно обучение — это и пожелание работодателя, поэтому некоторые компании пытаются решить эту проблему, выделяя рабочее время.
В первый раз я услышала о немного другой, но похожей практике, применительно к 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
#работа
Многим айтишницам хотелось бы делать свои проекты, контрибьютить в опенсурс, читать книги, писать посты. На это сложно выделить время, потому что работа фуллтайм занимает примерно всю жизнь. Даже если время есть, хочется заняться чем-то ещё, а не тратить силы на околорабочую деятельность.
Часто дополнительно обучение — это и пожелание работодателя, поэтому некоторые компании пытаются решить эту проблему, выделяя рабочее время.
В первый раз я услышала о немного другой, но похожей практике, применительно к 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
#работа
Business Insider
The truth about Google's famous '20% time' policy
Only about 10% of employees are using it.
Плейлист о карьере от Маюко.
Скорее ориентирован на начало карьеры, но будет полезен и опытным. Мне понравились части про нетворкинг и карьерные цели.
Видео очень короткие - по 2-5 минут и их удобно смотреть по кусочкам.
https://www.youtube.com/playlist?list=PL1hNTJtl-Vt5FGkgnfo3e0HjK-YPYCQzR
Скорее ориентирован на начало карьеры, но будет полезен и опытным. Мне понравились части про нетворкинг и карьерные цели.
Видео очень короткие - по 2-5 минут и их удобно смотреть по кусочкам.
https://www.youtube.com/playlist?list=PL1hNTJtl-Vt5FGkgnfo3e0HjK-YPYCQzR
YouTube
How to Kickstart Your Software Engineering Career - YouTube
В рельсах появится вью-компоненты (
https://dev.to/andy/rails-to-introduce-view-components-3ome
На одной из первых работ (в конце 2000-х) у нас была своя супер-cms на php и там была похожая концепция.
Как тогда они меня бесили! Тогда хотелось простой mvc, т.к. параллельно изучала всякие php-фреймворки и казалось, что это единственный правильный вариант.
Сейчас уже мало что о них помню, но в последние годы уже не раз вспоминала эти компоненты, например, после изучения реакта. Возможно, они были не такой уж плохой идеей :D
Интересно, как меняется восприятие со временем и приобретённым опытом.
ActionView::Component)https://dev.to/andy/rails-to-introduce-view-components-3ome
На одной из первых работ (в конце 2000-х) у нас была своя супер-cms на php и там была похожая концепция.
Как тогда они меня бесили! Тогда хотелось простой mvc, т.к. параллельно изучала всякие php-фреймворки и казалось, что это единственный правильный вариант.
Сейчас уже мало что о них помню, но в последние годы уже не раз вспоминала эти компоненты, например, после изучения реакта. Возможно, они были не такой уж плохой идеей :D
Интересно, как меняется восприятие со временем и приобретённым опытом.
The DEV Community
Rails to Introduce View Components
Анна Буянова (Anna Codes)
В рельсах появится вью-компоненты (ActionView::Component) https://dev.to/andy/rails-to-introduce-view-components-3ome На одной из первых работ (в конце 2000-х) у нас была своя супер-cms на php и там была похожая концепция. Как тогда они меня бесили! Тогда…
Но надо помнить, что mvc - не mvc☝️
https://twitter.com/avdi/status/1139232955530993665
https://twitter.com/avdi/status/1139232955530993665
Twitter
Avdi Grimm
Rails is not and has never been MVC. MVC is a pattern for managing rich *live* UIs, like the Smalltalk desktop GUIs it was created for. In MVC, GUI widgets subscribe to models. Rails delivers static information (HTML or JSON) in response to requests.
https://twitter.com/jessleenyc/status/1139586747208273920
Команда растёт за счёт интернов и единорогов ✨
#devto
Команда растёт за счёт интернов и единорогов ✨
#devto
X (formerly Twitter)
Jess Lee (she/her) (@jessleenyc) on X
Look at how our team has grown!!!
Not only did we bring on two awesome interns for the summer, but we managed to convince a super-elusive-and-sought-after unicorn to join the team as well!
https://t.co/GMWXdZXPnC
Not only did we bring on two awesome interns for the summer, but we managed to convince a super-elusive-and-sought-after unicorn to join the team as well!
https://t.co/GMWXdZXPnC
Я подозрительно отношусь к
Вроде красиво, но пока не заглянешь в код гема, не видно, как и что там на самом деле проверяется:
На днях напоролась на одну особенность:
Для проверки уникальности shoulda сама создаёт записи в минимальными атрибутами, но не валидирует их:
https://git.io/fjg2g
При этом создание может зафейлиться из-за органичений в базе данных, а в нашем случае — из-за того, что не хватило данных для коллбека:
https://git.io/fjadm
Конечно, наличие такой логики в коллбеках само по себе не очень, но это уже отдельная тема.
shoulda_matchers [https://git.io/fj23m] 🕵️♀️Вроде красиво, но пока не заглянешь в код гема, не видно, как и что там на самом деле проверяется:
it { is_expected.to validate_uniqueness_of(:username) }На днях напоролась на одну особенность:
Для проверки уникальности shoulda сама создаёт записи в минимальными атрибутами, но не валидирует их:
https://git.io/fjg2g
При этом создание может зафейлиться из-за органичений в базе данных, а в нашем случае — из-за того, что не хватило данных для коллбека:
https://git.io/fjadm
Конечно, наличие такой логики в коллбеках само по себе не очень, но это уже отдельная тема.
GitHub
thoughtbot/shoulda-matchers
Simple one-liner tests for common Rails functionality - thoughtbot/shoulda-matchers
Трекинг рабочего времени
Подсмотрела пример из плейбука небулаба (https://bit.ly/2XXBL8l)
Они трекают:
- время присутствия. Если меньше или больше 8 часов в день, нужно отрепортить. Овертаймы и недоработки компенсирую друг друга не автоматически, а только по просьбе.
- время, оплачиваемое клиентом (billable time). Это время, потраченое непосредственно на работу над проектом.
- время на обучение, 1:1, внутренние проекты и т.д.
- "потерянное" время (time wasting)
Подход интересный и удобный для выставления счетов клиентам. Но, по-моему, необходимость отчитываться за каждую минуту напрягает и добавляет стресса.
То, что каждые полчаса недоработки/переработки надо репортить, тоже.
На моих работах было так:
- пропускная система + жёсткий рабочий график в госучреждении (но я парттаймила, поэтому было не так жёстко)
- мягкий офисный график без отчётов, но с примерным временем прихода-ухода
- относительно свободный график + таймер на офисном компьютере, который считал общее рабочее время за неделю/месяц
- на удалёнке - отчёты о потраченном времени на ту или иную задачу по часам, относительно свободный график
- сейчас - ещё более свободный график, трекаю только общее количество часов за месяц
Не очень люблю почасовку, но использую её, как компромисс. Обычно всё равно получается так, что у меня скорее "покупают" месяц работы.
Трекинг времени я рассматриваю скорее как инструмент для личной эффективности и планирования.
Иногда расписываю день по часам, но обязательно закладываю буфер на все задачи. Это время в любом случае уйдёт на переключение контекста, внеплановые отвлечения и задачи.
#работа
Подсмотрела пример из плейбука небулаба (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/
https://dev.to/
DEV Community
A space to discuss and keep up software development and manage your software career
Анна Буянова (Anna Codes)
Do you use time-tracking for work or for your personal time? - DEV Community 👩💻👨💻 https://dev.to/
Написала вчерашний пост и на английском, чтобы обсудить 💁🏻♀
Анна Буянова (Anna Codes)
Do you use time-tracking for work or for your personal time? - DEV Community 👩💻👨💻 https://dev.to/
Не прикрепилась ссылка на пост 🤦🏻♀️
https://bit.ly/2XHX2X3
https://bit.ly/2XHX2X3
The DEV Community
Do you use time-tracking for work or for your personal time?
. Tagged with discuss, productivity.
Glue Work / Работа-клей
Доклад Тани Рейли про "склеивающую" работу и как она может тормозить карьеру.
Glue Work - это работа, связанная с "мягкими" навыками, такая както есть это организация общения между командами, налаживание процессов, написание документации, консультации новичков и т.п. Она противопоставляется выполнению технических задач (программированию в нашем случае), которые развивают "твёрдые", основные навыки для карьеры.
"Мягкие" навыки -- это важно, и о них сейчас много говорят, но сначала нужно укрепить основные. Если этого не сделать, то продвигаться будет намного сложнее. Подумайте, прежде чем брать на себя "ничью" работу, особенно в начале карьеры. Не факт, что это оценят, а вот основные задачи будут страдать.
Кроме этого, из доклада вы узнаете, как выделить время на сфокусированную работу, и что делать, если вы уже набрали много смежных задач, а теперь понимаете, что это неоптимальная трата времени.
Видео: https://www.youtube.com/watch?v=5cr2Yn_MrKg
Доклад в текстовом формате: https://noidea.dog/glue
Доклад Тани Рейли про "склеивающую" работу и как она может тормозить карьеру.
Glue Work - это работа, связанная с "мягкими" навыками, такая както есть это организация общения между командами, налаживание процессов, написание документации, консультации новичков и т.п. Она противопоставляется выполнению технических задач (программированию в нашем случае), которые развивают "твёрдые", основные навыки для карьеры.
"Мягкие" навыки -- это важно, и о них сейчас много говорят, но сначала нужно укрепить основные. Если этого не сделать, то продвигаться будет намного сложнее. Подумайте, прежде чем брать на себя "ничью" работу, особенно в начале карьеры. Не факт, что это оценят, а вот основные задачи будут страдать.
Кроме этого, из доклада вы узнаете, как выделить время на сфокусированную работу, и что делать, если вы уже набрали много смежных задач, а теперь понимаете, что это неоптимальная трата времени.
Видео: https://www.youtube.com/watch?v=5cr2Yn_MrKg
Доклад в текстовом формате: https://noidea.dog/glue
YouTube
Being Glue | Tanya Reilly | athenahealth Tech Talk
As part of the athenahealth Tech Talk series, Tanya Reilly, a principal software engineer at Squarespace, discusses “being glue”; the idea of doing whatever it takes to make the project work and to make the team or organization successful by filling all the…
Пишу последний пост серии про чтение и немного исследую тему, попадаются интересные материалы на тему обучения.
Например, по 10 правил хорошего и плохого обучения из "Mind for Numbers"("Думай, как математик") Барбары Оакли:
http://www.math.toronto.edu/nhoell/10rules-of-studying.pdf
Например, по 10 правил хорошего и плохого обучения из "Mind for Numbers"("Думай, как математик") Барбары Оакли:
http://www.math.toronto.edu/nhoell/10rules-of-studying.pdf
Один из подкастов, которые регулярно слушаю в последнее время https://softskills.audio/
Хосты обсуждают нетехнические вопросы, связанные с программированием и карьерой, отвечают на вопросы слушателей.
На мой вкус моговато шуток, иногда они смешные, иногда нет. Но мне нравится сам неформальный стиль общения + удобно, что серии небольшие, около получаса, вполне влезают в обеденную прогулку.
Хосты обсуждают нетехнические вопросы, связанные с программированием и карьерой, отвечают на вопросы слушателей.
На мой вкус моговато шуток, иногда они смешные, иногда нет. Но мне нравится сам неформальный стиль общения + удобно, что серии небольшие, около получаса, вполне влезают в обеденную прогулку.
Soft Skills Engineering
It takes more than great code to be a great engineer. Soft Skills Engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into being a great software developer.
Новая книга от Basecamp о том, как устроены рабочие процессы в их компании.
https://basecamp.com/shapeup
Для тех, кто не знает, Basecamp (ранее 37signals) — это компания, в которой родился фреймворк Ruby on Rails. Basecamp - это первое rails-приложение.
Больше о них можно прочитать тут — https://basecamp.com/about
Другие книги: https://basecamp.com/books
Я читала "Getting Real", "Rework" и "Remote". Наиболее полезной оказалась первая книга, она сильно повлияла на меня, несмотря на то, что читала её в непрофессиональном переводе с ошибками.
Из Rework и Remote не могу сказать, что много вынесла, но читать всё равно было интересно и приятно. Думаю перечитать Rework и оценить с учётом нового опыта.
"It Doesn't Have to Be Crazy at Work" ещё не читала, но думаю, что как-нибудь доберусь и до неё. Вряд ли много вынесу оттуда, ведь я и так стараюсь спать много, а работать поменьше :D
Новая "Shape Up" выглядит куда более интересной. Плюс в том, что она бесплатная, но пока нет удобного формата, только веб.
#книги
https://basecamp.com/shapeup
Для тех, кто не знает, Basecamp (ранее 37signals) — это компания, в которой родился фреймворк Ruby on Rails. Basecamp - это первое rails-приложение.
Больше о них можно прочитать тут — https://basecamp.com/about
Другие книги: https://basecamp.com/books
Я читала "Getting Real", "Rework" и "Remote". Наиболее полезной оказалась первая книга, она сильно повлияла на меня, несмотря на то, что читала её в непрофессиональном переводе с ошибками.
Из Rework и Remote не могу сказать, что много вынесла, но читать всё равно было интересно и приятно. Думаю перечитать Rework и оценить с учётом нового опыта.
"It Doesn't Have to Be Crazy at Work" ещё не читала, но думаю, что как-нибудь доберусь и до неё. Вряд ли много вынесу оттуда, ведь я и так стараюсь спать много, а работать поменьше :D
Новая "Shape Up" выглядит куда более интересной. Плюс в том, что она бесплатная, но пока нет удобного формата, только веб.
#книги
Basecamp
Shape Up: Stop Running in Circles and Ship Work that Matters
Shape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.
https://dev.to/lightalloy/getting-more-value-from-reading-43pd
Новый пост на DEV
Почему-то его было труднее написать, чем другие посты серии. Возможно, получился неуклюжим, но, на мой взгляд, более полезным, чем другие посты серии.
#книги
Новый пост на DEV
Почему-то его было труднее написать, чем другие посты серии. Возможно, получился неуклюжим, но, на мой взгляд, более полезным, чем другие посты серии.
#книги
DEV Community
Getting more value from reading
In the last part of the “Technical reading“ series, I would like to share what helps me to comprehend...
Пока пишу "большой" пост, поделюсь кусочком про книгу "Удовольствие от X" Стивена Строгаца:
Стивен Строгац уверен, что если математику преподавать правильно, люди не будут скучать на занятиях и полюбят её. И уж тем более не будут думать, что математика -- это только для "избранных", с определённым складом ума.
Похоже на то, о чём пишет Барбара Оакли в книге "Думай, как математик". Но если "Думай, как математик" больше о процессе обучения и о том, как эффективно усваивать информацию, то "Удовольствие от X" -- о самой математике.
Автор проходится по темам от арифметики до дифференциальных уравнений и операций над бесконечными множествами. Книга читается легко, кроме теории, в ней много фактов из прошлого, историй и задачек. Ещё мне интересно было прочитать о том, где встречаются те или иные понятия в жизни и на производстве.
Темы разобраны поверхностно, поэтому она больше подойдёт для того, чтобы (снова) заинтересоваться математикой или просто хорошо провести время, чем для серьёзного обучения. Если захочется изучить темы из книги подробнее, то в сносках ОЧЕНЬ много ссылок на другие книги и материалы.
#книги
Стивен Строгац уверен, что если математику преподавать правильно, люди не будут скучать на занятиях и полюбят её. И уж тем более не будут думать, что математика -- это только для "избранных", с определённым складом ума.
Похоже на то, о чём пишет Барбара Оакли в книге "Думай, как математик". Но если "Думай, как математик" больше о процессе обучения и о том, как эффективно усваивать информацию, то "Удовольствие от X" -- о самой математике.
Автор проходится по темам от арифметики до дифференциальных уравнений и операций над бесконечными множествами. Книга читается легко, кроме теории, в ней много фактов из прошлого, историй и задачек. Ещё мне интересно было прочитать о том, где встречаются те или иные понятия в жизни и на производстве.
Темы разобраны поверхностно, поэтому она больше подойдёт для того, чтобы (снова) заинтересоваться математикой или просто хорошо провести время, чем для серьёзного обучения. Если захочется изучить темы из книги подробнее, то в сносках ОЧЕНЬ много ссылок на другие книги и материалы.
#книги