Машинное обучение без лишних слов

...

Книга написана лаконично, так что ничего лишнего там нет — и в издании всего 100 страниц.

Выглядит так, что автор обзора не открывал книгу :) Из русского перевода даже выкинули фразу "100 page book".

Плюс, имхо, это точно не "первая книга, чтобы прочитать и погрузиться в тему". Очень много материала, очень сжато, с множеством формул и т.п. Книгой 3 или 4-ой, наверное, стоит читать.

ничего специфического для bash я и не заметил в статье

И тем не менее оно есть ) Писать алиасы qcd, тренироваться с dirs, pushd/popd, жать два раза tab и т.п. становится совершенно не нужно, если пользоваться zsh/ohmyzsh или тем же fish.

сам перешел на fish, попробуйте может понравится больше чем zsh

Пробовал и перешел в итоге на ohmyzsh :) Это не совсем про ванильный zsh. У fish были свои плюсы в том, что ряд фичей работал сразу "из коробки", но ребята с ohmyzsh порешали эти вопросы.

Building Machine Learning Powered Applications: Going from Idea to Product

1. Уже есть перевод.

2. Никакого отношения теме "красивого кода".

3. Книга на "горячую тему" весьма сомнительного содержания. Сложилось впечатление, что целевой аудиторией автор видел project manager'ов в вакууме, которые раньше ничего не запускали и тут первый их проект. Программисту она точно не понравится.

С неявным утверждением, что не стоит читать современные книги, я согласиться не могу :)

1. Ревью задач, сделанных командой за последние 6-12 месяца. Садитесь со старым тимлидом или максимально осведомленным товарищем, идете по списку и обсуждаете какие были нюансы с той или иной задачей. Эти 1-2 дня анализа позволят понять, с какими трудностями сталкивалась команда в прошлом.
2. Ревью сотрудников, которые работают в команде. Идете по списку и обсуждаете каждого: какие интересы, сильные стороны, что обратить внимание, как зовут собаку, какое хобби и т.п. Сессия делается с предыдущим тимлидом или тем, кто передает дела. Если повезет, то у предыдущего менеджера будут личные записи о каждом сотруднике и он сможет раскрыть много деталей. Маша хоть и QA-инженер, но мечтает быть дизайнером, а Петя последнее время делает сильный упор на изучение Go, но задач пока таких нет и т.п. Пока вы сами это осознаете, пройдет куча времени. Потраченные 2-3 часа на ревью окупятся очень быстро.

Нет, в первую очередь — это скорость разработки, стоимость поддержки и удобство. Наши тесты для Selenium были исторически на PHP. Как обычно, все вокруг за годы обросло говном вспомогательными инструментами, helper'ами и даже иерархиями классов :) Но даже если все это убрать и пробовать начинать с нуля в новом проекте, то все равно оказывается с Cypress'ом удобнее. Вы скажете, что это субъективщина и будете правы. В конце концов, мы же просто своим опытом делимся.

Кроме того, а что насчет вендор-лока в Cypress?

Он open source под MIT. Имхо, это не более опасный вендор-лок, чем с Selenium. В конце-концов, где-то ~2004-2005 мы выкинули e2e тесты на Perl'е и пошли в сторону Selenium. Иногда это вполне полезно — заменять внутренние инструменты, если прошлый инструмент перестал чем-то устраивать :)

Тут становится вообще непонятно, зачем разработчики ввязываются в инструмент с такими ограничениями.

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

Не обязательно. WebDriver – это протокол

Чисто технически, Selenium WebDriver — это просто полное название продукта, который написан на Java. Так что в упомянутой фразе — все верно )

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

Пользуетесь ли вы withConsecutive

Да. Не конкретно к этому методу, но в целом к мокам отошение следующее: чем их меньше, тем лучше :)

МБ вы используете другую библиотеку моков, вроде phpspec/prophecy

Нет, не используем.

P.S. Последняя картинка в более высоком разрешении — https://habrastorage.org/webt/kz/ek/ay/kzekaym4io39v3hwigwxkref_n0.png

В любом коде могут быть ошибки :) Что ж после этого код не писать и чужими наработками не пользоваться?

Пока что да, на линуксе и антивирусы-то редко ставят.

Можете глянуть в профиле мое место работы :) Я довольно хорошо в курсе насколько часто на Linux-серверах бывает DrWeb и Kaspersky. Но суть даже не в этом. Антивирусам прекрасно знакомы все более-менее популярные упаковщики и анализ выполняется распакованного кода.

Тем более что код кроссплатформенный и не везде одинаково хорошо протестирован.

Код там конкретный под каждую платформу/архитектуру. Кода относительно немного и он не такой магический, как может показаться на первый взгляд (говорю это в первую очередь в контексте ELF/Linux). Не хочу спорить кто и где хорошо или плохо протестирован. Но проект не вчера появился и является достаточно стабильным и популярным. Пользоваться ли им в своем проекте — решать вам. Но убеждать меня в том, что он глючит и плохо работает, а ближаший апдейт CentOS'а — рассыпется, немного странно.