У меня почти год уже как puppeteer основной рабочий инструмент скрэпинга и ни разу меня не забанили за `автоматизированность браузера`. Почти всегда банят за один и тот же IP источника исходящих запросов с высоким рейтом в единицу времени.
Нет такой проблемы. Есть сервисы с API, которые за дополнительную плату сами рендерят результирующую страницу со всеми яваскриптами и отдают тебе в готовом виде. При этом стоимость обычного запроса скажем 1 кредит, а стоимость запроса с рендерингом 5 кредитов. В общем вполне выгодное предложение, потому что действительно загрузка одной страницы способна сгенерировать сотню дополнительных запросов.
А еще будьте готовы арендовать несколько разных пакетов прокси на разных сервисах, когда столкнетесь с тем, что сайты, которые вы скрэпите начали включать защитные алгоритмы против любителей регулярного автоматического копирования их контента.
Если Вы, к примеру, програмист. То Ваш продукт — код. Если Вы PM, то Ваш продукт — состояние проекта.
Хм… мне всегда казалось что если я PM, то мой продукт все равно код. Я могу как угодно красиво с блэкджеком и графиками разрисовать заказчику состояние проекта, но он собака все равно просит мне показать как это работает в проде...
Ритуалы, описанные в двух первых вышеозначенных книгах я считаю бесполезной ерундой, а чтение этих книг, бесполезной тратой времени с точки зрения процесса софтверной разработки.
Что лично вы подразумеваете под терминами "скрам" и "канбан" мне конечно неизвестно. Может там у вас и впрямь алмазы-бриллианты-конкретные-методики.
Ну блин… эта ветка комментариев стартанула с принципов Agile манифеста, которые с одной стороны однозначно привязаны к софтверной разработке, с другой стороны вообще не являются никакой не методологией и не организацией процессов, а лишь набором заявлений.
Я внедрял. Да я думаю много кто внедрял. Однако я ни разу не видел чтобы в реальности оценки эти хоть сколько-нибудь точными. В общем на мой взгляд story point-ы это вообще хрень полная.
Пользовательские истории — это на мой взгляд удобная штука. Будучи включенными в итерацию, они однозначно и понятно показывают и заказчику и исполнителю, что они договорились реализовать к следующему деплою.
Мдауш… Однако извините за неточность вопроса. Я под практиками подразумевал не ритуалы вроде "куры со свиньями танцуют под бубен по понедельникам", а про инженерные практики, типа TDD, CI/CD.
Прочитал первую и вторую из вышеозначенных книг. На мой субъективный взгляд книги совершенно бесполезные, по меньшей мере в плане практическом, в софтверных проектах. Как с точки зрения управляющего разработкой, так и с точки зрения человека, который пишет код. Мой список правильных книг про гибкую разработку:
Кент Бек "Экстремальное программирование"
Кент Бек "Экстремальное программирование. Разработка через тестирование"
Роберт Мартин "Чистый Agile. Основы гибкости"
Роберт Мартин "Идеальный программист"
Роберт Мартин "Чистый код"
Роберт Мартин "Чистая архитектура"
Роберт Мартин "Гибкая разработка программ на Java и C++. Принципы, паттерны и методики"
Роберт Мартин "Принципы, паттерны и методики гибкой разработки на языке C#"
… Мы живем в Обществе Развитого Капитализма. Здесь перевод-на-дерьмо — высшая добродетель. Политики называют это 'оптимизацией потребления'. Я называю это 'переводом на дерьмо'…
Харуки Мураками "Дэнс, дэнс, дэнс"
Автору просто надо было в начале этого текста написать, что это перевод доклада.
Если щелкнуть по видео на youtube, которое там в начале этой статьи, и включить субтитры, то все становится вполне нормально. Можно смотреть и не ломать голову что это такое.
Менеджеры могут просить вас поторопиться. Ни в коем случае не поддавайтесь. Ваша работа — грамотно распоряжаться своими ресурсами, чтобы выстоять до конца.
… выстоять до конца или уйти… менеджеры в большинстве случаев уверены что они лучше умеют распоряжаться чьими угодно ресурсами… разве нет?
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
Scrum — это в смысле стендапы и ретро? Нееее… я не про это. Я про TDD и парное программирование с шаблонами, приемочными тестами и автоматизациями CI/CD.
У меня почти год уже как puppeteer основной рабочий инструмент скрэпинга и ни разу меня не забанили за `автоматизированность браузера`. Почти всегда банят за один и тот же IP источника исходящих запросов с высоким рейтом в единицу времени.
Нет такой проблемы. Есть сервисы с API, которые за дополнительную плату сами рендерят результирующую страницу со всеми яваскриптами и отдают тебе в готовом виде. При этом стоимость обычного запроса скажем 1 кредит, а стоимость запроса с рендерингом 5 кредитов. В общем вполне выгодное предложение, потому что действительно загрузка одной страницы способна сгенерировать сотню дополнительных запросов.
А еще будьте готовы арендовать несколько разных пакетов прокси на разных сервисах, когда столкнетесь с тем, что сайты, которые вы скрэпите начали включать защитные алгоритмы против любителей регулярного автоматического копирования их контента.
Хм… мне всегда казалось что если я PM, то мой продукт все равно код. Я могу как угодно красиво с блэкджеком и графиками разрисовать заказчику состояние проекта, но он собака все равно просит мне показать как это работает в проде...
Согласен. Чистый код и многие другие публикации Мартина отличное чтиво! Читал и перечитывал несколько раз.
Как скажете. Будь по вашему.
Ритуалы, описанные в двух первых вышеозначенных книгах я считаю бесполезной ерундой, а чтение этих книг, бесполезной тратой времени с точки зрения процесса софтверной разработки.
Что лично вы подразумеваете под терминами "скрам" и "канбан" мне конечно неизвестно. Может там у вас и впрямь алмазы-бриллианты-конкретные-методики.
Ну блин… эта ветка комментариев стартанула с принципов Agile манифеста, которые с одной стороны однозначно привязаны к софтверной разработке, с другой стороны вообще не являются никакой не методологией и не организацией процессов, а лишь набором заявлений.
Я внедрял. Да я думаю много кто внедрял. Однако я ни разу не видел чтобы в реальности оценки эти хоть сколько-нибудь точными. В общем на мой взгляд story point-ы это вообще хрень полная.
Пользовательские истории — это на мой взгляд удобная штука. Будучи включенными в итерацию, они однозначно и понятно показывают и заказчику и исполнителю, что они договорились реализовать к следующему деплою.
Мдауш… Однако извините за неточность вопроса. Я под практиками подразумевал не ритуалы вроде "куры со свиньями танцуют под бубен по понедельникам", а про инженерные практики, типа TDD, CI/CD.
Ну а что сейчас нового появилось из практик, чего не было в 2001 году?
Так Agile в исходном виде даже не методология… набор принципов… не более.
Прочитал первую и вторую из вышеозначенных книг. На мой субъективный взгляд книги совершенно бесполезные, по меньшей мере в плане практическом, в софтверных проектах. Как с точки зрения управляющего разработкой, так и с точки зрения человека, который пишет код. Мой список правильных книг про гибкую разработку:
… Мы живем в Обществе Развитого Капитализма. Здесь перевод-на-дерьмо — высшая добродетель. Политики называют это 'оптимизацией потребления'. Я называю это 'переводом на дерьмо'…
Харуки Мураками "Дэнс, дэнс, дэнс"
Автору просто надо было в начале этого текста написать, что это перевод доклада.
Если щелкнуть по видео на youtube, которое там в начале этой статьи, и включить субтитры, то все становится вполне нормально. Можно смотреть и не ломать голову что это такое.
Купил вчера. Прочитал пару глав. На мой взгляд с переводом все хорошо.
… выстоять до конца или уйти… менеджеры в большинстве случаев уверены что они лучше умеют распоряжаться чьими угодно ресурсами… разве нет?
Javascript мой любимый язык программирования… когда нет работы и проектов я только на нем и пишу…
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
Ни разу еще мне не удавалось с помощью собеседований и тестовых заданий определить станет ли кандидат хорошим коллегой впоследствии…
Понял лишь что если сразу что-то явно не нравится, то надо извиняться и вежливо расставаться.
Scrum — это в смысле стендапы и ретро? Нееее… я не про это. Я про TDD и парное программирование с шаблонами, приемочными тестами и автоматизациями CI/CD.