+1 к Goodreads. Сам перешел на него после лет 10 использования Google Spreadsheets. Все описанные кейсы он решает. Интерфейс, конечно, не ахти. Но огромное количество книг и пользователей делают свое дело. По сути, это даже мини-соцсеть с друзьями, challenges и т.п.
Книга написана лаконично, так что ничего лишнего там нет — и в издании всего 100 страниц.
Выглядит так, что автор обзора не открывал книгу :) Из русского перевода даже выкинули фразу "100 page book".
Плюс, имхо, это точно не "первая книга, чтобы прочитать и погрузиться в тему". Очень много материала, очень сжато, с множеством формул и т.п. Книгой 3 или 4-ой, наверное, стоит читать.
Читал ряд книг по теме и больше всего понравилась "Grokking Machine Learning" (не путать с "Grokking Deep Learning"). В книге, имхо, отличный баланс между теорией, математикой и практическими примерами. Чувствуется, что у автора большой опыт преподавания - старается донести так, чтобы читателю было максимально понятно. Поэтому именно "Grokking Machine Learning" рекомендовал бы в качестве первой книжки погружения в тему.
ничего специфического для bash я и не заметил в статье
И тем не менее оно есть ) Писать алиасы qcd, тренироваться с dirs, pushd/popd, жать два раза tab и т.п. становится совершенно не нужно, если пользоваться zsh/ohmyzsh или тем же fish.
сам перешел на fish, попробуйте может понравится больше чем zsh
Пробовал и перешел в итоге на ohmyzsh :) Это не совсем про ванильный zsh. У fish были свои плюсы в том, что ряд фичей работал сразу "из коробки", но ребята с ohmyzsh порешали эти вопросы.
Довольно странное впечатление от прочитанного: все больше это становится "музеем". Для написания скриптов на bash'е может еще и будет практическая польза. А вот для повседневной жизни, навигации и упрощения работы после ohmyzsh возвращаться обратно не особо виден смысл.
Просто подождите немного, либо обратитесь в их техподдержку. Утверждения вида, что это "развод" и "предлагают читать только на сайте" - мягко говоря, неправда.
Книга на "горячую тему" весьма сомнительного содержания. Сложилось впечатление, что целевой аудиторией автор видел project manager'ов в вакууме, которые раньше ничего не запускали и тут первый их проект. Программисту она точно не понравится.
Если за последние 20 лет прочитать только пару классических книг, далеко не уедешь. Про "Thinking, fast and slow" (одну из моих самых любимых книг) лишь скажу, что она написана человеком, получившим Нобелевскую премию и имеющему огромный опыт в той области, о которой пишет. А комментарий "базовые положения [в ней] неверны" написаны анонимным пользователем интернета без каких-либо ссылок-пруфов. Идеи Канемана (автора книги) по-прежнему активно используют. Регулярные упоминания возникают и в разных докладах (на тех же TeamLead Conf'ах, например).
С неявным утверждением, что не стоит читать современные книги, я согласиться не могу :)
У нас, вероятно, с вами совершенно разные боли. В свете сильной ограниченности времени хочется начинать с максимально близких к текущей реалиям советов. Если у меня спросит техлид, что почитать, чтобы прокачать управленческие навыки, я буду советовать что-то из списка выше, например, "Мама, я тимлид!", а не Peopleware. Мне нравились книги Тома ДеМарко, но они больше в формате историй и написаны очень давно (а я здесь делал обзор современных книг). Фразы в духе "а вот в 1980 году было интересное исследование, которое показало ..." в нашей, весьма динамичной, индустрии воспринимаются довольно негативно. Кроме того, я ж не говорю, что их читать совсем не надо (плюс есть еще много довольно полезных книг общей направленности, которые в этот обзор не попали), но предлагаю их подвинуть вниз в списке чтения.
Есть еще пара практик, как новому тимлиду быстра набрать понимание контекста (или как передавать проекты новым тимлидам):
Ревью задач, сделанных командой за последние 6-12 месяца. Садитесь со старым тимлидом или максимально осведомленным товарищем, идете по списку и обсуждаете какие были нюансы с той или иной задачей. Эти 1-2 дня анализа позволят понять, с какими трудностями сталкивалась команда в прошлом.
Ревью сотрудников, которые работают в команде. Идете по списку и обсуждаете каждого: какие интересы, сильные стороны, что обратить внимание, как зовут собаку, какое хобби и т.п. Сессия делается с предыдущим тимлидом или тем, кто передает дела. Если повезет, то у предыдущего менеджера будут личные записи о каждом сотруднике и он сможет раскрыть много деталей. Маша хоть и QA-инженер, но мечтает быть дизайнером, а Петя последнее время делает сильный упор на изучение Go, но задач пока таких нет и т.п. Пока вы сами это осознаете, пройдет куча времени. Потраченные 2-3 часа на ревью окупятся очень быстро.
Если основная причина непринятия Selenium — нестабильные тесты
Нет, в первую очередь — это скорость разработки, стоимость поддержки и удобство. Наши тесты для Selenium были исторически на PHP. Как обычно, все вокруг за годы обросло говном вспомогательными инструментами, helper'ами и даже иерархиями классов :) Но даже если все это убрать и пробовать начинать с нуля в новом проекте, то все равно оказывается с Cypress'ом удобнее. Вы скажете, что это субъективщина и будете правы. В конце концов, мы же просто своим опытом делимся.
Кроме того, а что насчет вендор-лока в Cypress?
Он open source под MIT. Имхо, это не более опасный вендор-лок, чем с Selenium. В конце-концов, где-то ~2004-2005 мы выкинули e2e тесты на Perl'е и пошли в сторону Selenium. Иногда это вполне полезно — заменять внутренние инструменты, если прошлый инструмент перестал чем-то устраивать :)
Справедливости ради, у нас не только заблуждения по поводу Selenium, но и 15-летняя практика его использования с 2006 года, тысячи написаных тестов и несколько продуктов, которые подвергались тестированию им. Используем мы, конечно, и Selenoid для автопрогонов. Практика использования Cypress — примерно 2 года. Начинали эксперименты в рамках research days, далее были небольшие проекты и дошли до активного внедрения в основном продукте. Мы спрашивали внутри команды и люди реально говорят, что им нравится и удобно создавать тесты с использованием Cypress. Также мы пробовали писать тестами силами совершенно разных людей и время на погружение довольно маленькое, где не последнюю роль играет удобство отладки и all batteries included.
Тут становится вообще непонятно, зачем разработчики ввязываются в инструмент с такими ограничениями.
Наверное, потому что мы не искали целенаправлено "что же не работает", а взяли некоторые текущие проекты и задачи и попробовали написать ряд тестов, чтобы увидеть плюсы и минусы именно в нашем контексте.
Не обязательно. WebDriver – это протокол
Чисто технически, Selenium WebDriver — это просто полное название продукта, который написан на Java. Так что в упомянутой фразе — все верно )
Как вы пишете expects на моках? На моем проекте мы выносим их в переиспользуемые хелпер методы
В зависимости от ситуации. Хелперы есть, прямое использование в рамках теста — тоже. Эволюционно мы пришли к мысли стараться в тестах делать как можно меньше абстракций и дополнительных слоев. В идеале — идея теста четко видна из кода тестового метода. Шанс, что мы наймем разработчика, знакомого с PHPUnit, очень высок, а вот шанс, что новый разработчик будет знаком с нашими доморощенными наворотами и абстракциями — равен нулю. Некоторое дублирование в рамках кода тестов — это вполне ок, если это улучшает их читабельность. В целом, стараемся это применять ко всем тестовым фреймворкам, которые используем.
Пользуетесь ли вы withConsecutive
Да. Не конкретно к этому методу, но в целом к мокам отошение следующее: чем их меньше, тем лучше :)
МБ вы используете другую библиотеку моков, вроде phpspec/prophecy
У нас, собственно, тоже хватало таких моментов. Вводили базовый класс для TestCase, в нем setUp и по-тихоньку добавляли туда ClassA::setup/setInstance/init, а в tearDown уже ClassB::reset(), ClassC::reset() и т.п. С одной стороны, мест много. С другой стороны, начинаем с теста на какой-то конкретный метод и он уже имеет ограниченное количество зависимостей, стараемся "добить" и максимально изолировать этот метод. А далее, только упорство :)
Codeception все-таки не для unit-тестирования. То есть делать его, конечно, можно, но мне не очень понятно зачем. Попытки использования Codeception для написания acceptance-тестов (в виде BDD) у нас были и некоторое количество тестов осталось до сих пор. Очень сомнительно в плане долгосрочной поддержки, поэтому развивать не стали. Большая часть e2e на модифицированный PHPUnit/Selenium/WebDriver и сейчас делаем довольно масштабный переход на Cypress.
Обычно со статическими методами нет никаких проблем с тестированием, пока это чистые функции (нет side effects) и нет использования других статических классов и методов.
Проблема зависимости статического метода от других статических классов разбивается на подпроблемы. Первая подпроблема: возможность управлять поведением зависимого класса. Например, это некий класс Config, который в рамках работы приложения может вообще быть readonly. Но в рамках теста мы можем подсунуть другую (более управляемую) реализацию сманипулировав на includ'ах. Понятно, что потом уже класс Config уже потестить не получится. Поэтому чаще для таких классов добавляется возможность внешнего управления. Вторая подпроблема: созависимый класс все-таки очень хочется подменить mock'ом. Тут либо DI, либо runkit. Но лучше DI (для кодовой базы и развития лучше), хоть и более трудней добавлять.
Когда-то очень давно занимался редактированием аудио, микшированием и т.п. Мне в статье, внезапно, не хватило технических деталей. В каких программах делалось сведение, какое оборудование, на что писали, что со светом, чем управляете и т.п.?
В любом коде могут быть ошибки :) Что ж после этого код не писать и чужими наработками не пользоваться?
Пока что да, на линуксе и антивирусы-то редко ставят.
Можете глянуть в профиле мое место работы :) Я довольно хорошо в курсе насколько часто на Linux-серверах бывает DrWeb и Kaspersky. Но суть даже не в этом. Антивирусам прекрасно знакомы все более-менее популярные упаковщики и анализ выполняется распакованного кода.
Тем более что код кроссплатформенный и не везде одинаково хорошо протестирован.
Код там конкретный под каждую платформу/архитектуру. Кода относительно немного и он не такой магический, как может показаться на первый взгляд (говорю это в первую очередь в контексте ELF/Linux). Не хочу спорить кто и где хорошо или плохо протестирован. Но проект не вчера появился и является достаточно стабильным и популярным. Пользоваться ли им в своем проекте — решать вам. Но убеждать меня в том, что он глючит и плохо работает, а ближаший апдейт CentOS'а — рассыпется, немного странно.
+1 к Goodreads. Сам перешел на него после лет 10 использования Google Spreadsheets. Все описанные кейсы он решает. Интерфейс, конечно, не ахти. Но огромное количество книг и пользователей делают свое дело. По сути, это даже мини-соцсеть с друзьями, challenges и т.п.
Выглядит так, что автор обзора не открывал книгу :) Из русского перевода даже выкинули фразу "100 page book".
Плюс, имхо, это точно не "первая книга, чтобы прочитать и погрузиться в тему". Очень много материала, очень сжато, с множеством формул и т.п. Книгой 3 или 4-ой, наверное, стоит читать.
Читал ряд книг по теме и больше всего понравилась "Grokking Machine Learning" (не путать с "Grokking Deep Learning"). В книге, имхо, отличный баланс между теорией, математикой и практическими примерами. Чувствуется, что у автора большой опыт преподавания - старается донести так, чтобы читателю было максимально понятно. Поэтому именно "Grokking Machine Learning" рекомендовал бы в качестве первой книжки погружения в тему.
И тем не менее оно есть ) Писать алиасы qcd, тренироваться с dirs, pushd/popd, жать два раза tab и т.п. становится совершенно не нужно, если пользоваться zsh/ohmyzsh или тем же fish.
Пробовал и перешел в итоге на ohmyzsh :) Это не совсем про ванильный zsh. У fish были свои плюсы в том, что ряд фичей работал сразу "из коробки", но ребята с ohmyzsh порешали эти вопросы.
Довольно странное впечатление от прочитанного: все больше это становится "музеем". Для написания скриптов на bash'е может еще и будет практическая польза. А вот для повседневной жизни, навигации и упрощения работы после ohmyzsh возвращаться обратно не особо виден смысл.
Просто подождите немного, либо обратитесь в их техподдержку. Утверждения вида, что это "развод" и "предлагают читать только на сайте" - мягко говоря, неправда.
Если вас интересует эта тема, то есть смысл посмотреть mrsk - https://github.com/mrsked/mrsk Пилит его сам DHH (автор Rails).
Уже есть перевод.
Никакого отношения теме "красивого кода".
Книга на "горячую тему" весьма сомнительного содержания. Сложилось впечатление, что целевой аудиторией автор видел project manager'ов в вакууме, которые раньше ничего не запускали и тут первый их проект. Программисту она точно не понравится.
Algorithms от Sedgewick'а (с вполне практичными примерами на Java)
Classic Computer Science Problems in Python (тоже практичней некуда, еще и владение Python'ом подкачаете)
Algorithms Design Manual от Skiena (имхо, одна из самых популярных рекомендаций в FAANG'ах)
Если за последние 20 лет прочитать только пару классических книг, далеко не уедешь. Про "Thinking, fast and slow" (одну из моих самых любимых книг) лишь скажу, что она написана человеком, получившим Нобелевскую премию и имеющему огромный опыт в той области, о которой пишет. А комментарий "базовые положения [в ней] неверны" написаны анонимным пользователем интернета без каких-либо ссылок-пруфов. Идеи Канемана (автора книги) по-прежнему активно используют. Регулярные упоминания возникают и в разных докладах (на тех же TeamLead Conf'ах, например).
С неявным утверждением, что не стоит читать современные книги, я согласиться не могу :)
У нас, вероятно, с вами совершенно разные боли. В свете сильной ограниченности времени хочется начинать с максимально близких к текущей реалиям советов. Если у меня спросит техлид, что почитать, чтобы прокачать управленческие навыки, я буду советовать что-то из списка выше, например, "Мама, я тимлид!", а не Peopleware. Мне нравились книги Тома ДеМарко, но они больше в формате историй и написаны очень давно (а я здесь делал обзор современных книг). Фразы в духе "а вот в 1980 году было интересное исследование, которое показало ..." в нашей, весьма динамичной, индустрии воспринимаются довольно негативно. Кроме того, я ж не говорю, что их читать совсем не надо (плюс есть еще много довольно полезных книг общей направленности, которые в этот обзор не попали), но предлагаю их подвинуть вниз в списке чтения.
Есть еще пара практик, как новому тимлиду быстра набрать понимание контекста (или как передавать проекты новым тимлидам):
Нет, в первую очередь — это скорость разработки, стоимость поддержки и удобство. Наши тесты для Selenium были исторически на PHP. Как обычно, все вокруг за годы обросло
говномвспомогательными инструментами, helper'ами и даже иерархиями классов :) Но даже если все это убрать и пробовать начинать с нуля в новом проекте, то все равно оказывается с Cypress'ом удобнее. Вы скажете, что это субъективщина и будете правы. В конце концов, мы же просто своим опытом делимся.Он open source под MIT. Имхо, это не более опасный вендор-лок, чем с Selenium. В конце-концов, где-то ~2004-2005 мы выкинули e2e тесты на Perl'е и пошли в сторону Selenium. Иногда это вполне полезно — заменять внутренние инструменты, если прошлый инструмент перестал чем-то устраивать :)
Справедливости ради, у нас не только заблуждения по поводу Selenium, но и 15-летняя практика его использования с 2006 года, тысячи написаных тестов и несколько продуктов, которые подвергались тестированию им. Используем мы, конечно, и Selenoid для автопрогонов. Практика использования Cypress — примерно 2 года. Начинали эксперименты в рамках research days, далее были небольшие проекты и дошли до активного внедрения в основном продукте. Мы спрашивали внутри команды и люди реально говорят, что им нравится и удобно создавать тесты с использованием Cypress. Также мы пробовали писать тестами силами совершенно разных людей и время на погружение довольно маленькое, где не последнюю роль играет удобство отладки и all batteries included.
Наверное, потому что мы не искали целенаправлено "что же не работает", а взяли некоторые текущие проекты и задачи и попробовали написать ряд тестов, чтобы увидеть плюсы и минусы именно в нашем контексте.
Чисто технически, Selenium WebDriver — это просто полное название продукта, который написан на Java. Так что в упомянутой фразе — все верно )
В зависимости от ситуации. Хелперы есть, прямое использование в рамках теста — тоже. Эволюционно мы пришли к мысли стараться в тестах делать как можно меньше абстракций и дополнительных слоев. В идеале — идея теста четко видна из кода тестового метода. Шанс, что мы наймем разработчика, знакомого с PHPUnit, очень высок, а вот шанс, что новый разработчик будет знаком с нашими доморощенными наворотами и абстракциями — равен нулю. Некоторое дублирование в рамках кода тестов — это вполне ок, если это улучшает их читабельность. В целом, стараемся это применять ко всем тестовым фреймворкам, которые используем.
Да. Не конкретно к этому методу, но в целом к мокам отошение следующее: чем их меньше, тем лучше :)
Нет, не используем.
У нас, собственно, тоже хватало таких моментов. Вводили базовый класс для TestCase, в нем setUp и по-тихоньку добавляли туда ClassA::setup/setInstance/init, а в tearDown уже ClassB::reset(), ClassC::reset() и т.п. С одной стороны, мест много. С другой стороны, начинаем с теста на какой-то конкретный метод и он уже имеет ограниченное количество зависимостей, стараемся "добить" и максимально изолировать этот метод. А далее, только упорство :)
Codeception все-таки не для unit-тестирования. То есть делать его, конечно, можно, но мне не очень понятно зачем. Попытки использования Codeception для написания acceptance-тестов (в виде BDD) у нас были и некоторое количество тестов осталось до сих пор. Очень сомнительно в плане долгосрочной поддержки, поэтому развивать не стали. Большая часть e2e на модифицированный PHPUnit/Selenium/WebDriver и сейчас делаем довольно масштабный переход на Cypress.
P.S. Последняя картинка в более высоком разрешении — https://habrastorage.org/webt/kz/ek/ay/kzekaym4io39v3hwigwxkref_n0.png
Обычно со статическими методами нет никаких проблем с тестированием, пока это чистые функции (нет side effects) и нет использования других статических классов и методов.
Проблема зависимости статического метода от других статических классов разбивается на подпроблемы. Первая подпроблема: возможность управлять поведением зависимого класса. Например, это некий класс Config, который в рамках работы приложения может вообще быть readonly. Но в рамках теста мы можем подсунуть другую (более управляемую) реализацию сманипулировав на includ'ах. Понятно, что потом уже класс Config уже потестить не получится. Поэтому чаще для таких классов добавляется возможность внешнего управления. Вторая подпроблема: созависимый класс все-таки очень хочется подменить mock'ом. Тут либо DI, либо runkit. Но лучше DI (для кодовой базы и развития лучше), хоть и более трудней добавлять.
Когда-то очень давно занимался редактированием аудио, микшированием и т.п. Мне в статье, внезапно, не хватило технических деталей. В каких программах делалось сведение, какое оборудование, на что писали, что со светом, чем управляете и т.п.?
В любом коде могут быть ошибки :) Что ж после этого код не писать и чужими наработками не пользоваться?
Можете глянуть в профиле мое место работы :) Я довольно хорошо в курсе насколько часто на Linux-серверах бывает DrWeb и Kaspersky. Но суть даже не в этом. Антивирусам прекрасно знакомы все более-менее популярные упаковщики и анализ выполняется распакованного кода.
Код там конкретный под каждую платформу/архитектуру. Кода относительно немного и он не такой магический, как может показаться на первый взгляд (говорю это в первую очередь в контексте ELF/Linux). Не хочу спорить кто и где хорошо или плохо протестирован. Но проект не вчера появился и является достаточно стабильным и популярным. Пользоваться ли им в своем проекте — решать вам. Но убеждать меня в том, что он глючит и плохо работает, а ближаший апдейт CentOS'а — рассыпется, немного странно.