Такая стратегия с форками никогда не работала с крупными проектами. Одно дело, когда уходит основной костяк команды и продолжает трудиться над продуктом, а другое -- когда ноунейм или лишь один из разработчиков. Он просто физически не в состоянии заменить оригинал. Это как если бы на проблемы в многоквартирном ТСЖ председатель посылал бы жильцов строить свой собственный дом и там управлять. Формально такая возможность есть, но в реальности нереализуема.
PR никто там не переоткрывал, от кода автора решили отказаться после его бана. Переоткрыли только одну связанную задачу. Причем это сделал мейнтейнер, который эту задачу пытался ревьювить и вести автора в правильном направлении. Так что шансы на закрытие необходимой автору фичи еще есть -- если кто-то другой разобьет большой PR на несколько исправлений и зальет от своего имени.
Если отбросить поведение украинского админа с первым issue (за которое в итоге другие админы флаттера извинились), то с остальными PR'ами не все так однозначно. Я посмотрел на них -- PR с кучей ревью и просьбами исправить те или иные проблемы, длинные дискуссии внутри, огромные куски кода, просьбы подождать ревью и мержа из-за апстрима и т.п. вещи, говорящие о том, что с PR не все так просто. Возможно, для флаттера или популярной библиотеки подобные вещи являются нормой -- я не знаю. Но мне, как мейнтейнеру на другом джава проекте -- такие большие и сложные PR'ы очень не нравятся. И когда дискуссия внутри PR разрастается до десятков комментариев и фиксов по сравнению с соседними -- это верный признак того, что PR надо закрывать или ставить на паузу.
Очень большая проблема такого подхода с лайфкодингом (на время, без IDE, без гугла или других современных помощников) -- вы отсеиваете большое количество грамотных специалистов, оставляя как раз тех, кто только что закончил курсы "войти в айти" и у кого еще в "оперативной памяти" все эти команды остались. Сейчас в программировании нет необходимости выучивать наизусть миллион разных команд и конструкций языка или фреймворка (да это и физически невозможно) -- всегда есть интернет под рукой, где можно посмотреть использование какой-то команды или конструкции. Особенно это касается php или javascript, где доступный синтаксис зависит не то что от версии языка, так даже и от фреймворка.
Т.е. хорошему специалисту не важны инструменты, на которых он работает -- он решает именно задачи. А инструменты/язык уже второстепенны. Поэтому хорошие задачи и вопросы должны привязываться к способам решения задачи, а не к самим реализациям.
Если это инкрементный парсинг только новых данных, то нормальные цифры. Там на трафик будет больше уходить на порядки (например, на 1 гб данных потребуется скачать 10 тб текстового трафика).
Проблема подставных компаний - это разовое мероприятие. После которого не будет ни поддержки, ни дополнительных закупок. Поэтому долгоиграющие вещи типа сложного софта или оборудования "пиратить" нет смысла, т.к. лишаешься довольного большого куска.
Не нашел в статье причины, по которой агентство было заблокировано (а причины были). И судя по тому, как вы называете своих клиентов "неадекватными" в своем же сообщении -- причина оказалась банальна: вы поссорились с клиентами, а те подали жалобу на обман и/или невыполнение работы.
По статье сложилось впечатление, что люди, отвечающие за "защиту от парсеров", сами не совсем в теме, как они работают.
Сначала идет рассказ о том, что технари на добровольной основе заставили парсеры перейти на полную загрузку страницы и выполнение скриптов, вместо отдачи простого текста. Тем самым в разы увеличив нагрузку на свои сервера и трафик (об экономии которого так рьяно заботились, судя по тексту далее).
Затем рассказывается про рекапчу и ее теневой режим. Но при этом строго настрого умалчивается то, что этот вариант защиты очень легко обходится путем использования сторонних сервисов по разгадыванию капч типа рукапчи.
Так же идет рассказ про ежедневное обновление данных о компаниях и что это может спасти от парсеров. При этом называются контактные данные, юридические адреса для примера -- данные, которые вообще изменяются раз в несколько лет. А ведь это основная цель большинства парсеров и баз, а вовсе не списки госконтрактов или судов. Т.е. данный пункт "защиты" вообще бесполезный.
В итоге из-за жадности тупо закрыли свои данные, в т.ч. и для обычных пользователей. Это и позволило отсечь парсеры. Получилось в духе: доктор, у меня болит палец -- несите пилу, сейчас будем ампутировать руку.
По мне, так это вовсе не победа, а признание поражения.
Т.е. вы и за спам не блокируете, когда приходят жалобы по тому или иному айпи? Не является ли это нарушением каких-либо общепринятых обязательств? Абузоустойчивые хостинги априори находятся вне закона.
Тратит. Как процессора, так и SSD. Собственно, поэтому и обратил внимание на эту настройку, когда заметил странную работу диска и начал разбираться, кто его так нагружает -- оказалось, что фаерфокс. После увеличения интервала -- всё прекратилось.
Возможно, это не плагин, а сам фаерфокс. Он по умолчанию список всех открытых вкладок сохраняет в бекап на жесткий диск. И делает это каждые несколько секунд. browser.sessionstore.interval в about:config (в миллисекундах).
Одно дело, когда исправление неправильное, и можно сразу об этом написать/отклонить, а другое дело -- когда чего-то не хватает или реальная проблема где-то в другом месте находится. Я сам не знаю точного ответа и в этом случае требуется самому провести исследования и собрать материал по тем местам, что требуют проверки/исправления. Т.е. сделать фактически половину работы.
Скажу как мейнтейнер одного крупного (1.5 млн строк) java-проекта:
Новичку зачастую не знакома история проекта и история различных "багов". В результате появляются исправления вида "я тут посмотрел код и нашел решение". Формально оно исправляет баг, но де-факто лишь прикрывает костылем одну из дырок.
Следствие из предыдущего пункта -- если человек сделал объемный PR и, алилуйа, даже тесты написал (что бывает крайне редко), но при этом не дожал или пошел не по тому пути, то приходится самому разбираться в проблеме и дописывать код. Это иногда раздражает и отнимает лишнее время.
Поэтому, как мейнтейнеру, мне очень не нравятся слишком инициативные разработчики, которые время от времени забегают в проект, накидывают всяких исправлений, а потом ты вынужден сидеть, разбираться и дописывать за них внеплановые фиксы и задачи. Но и правила хорошего тона не позволяют их остановить -- поэтому таких людей стараюсь ставить "на паузу" и "притормаживать" их активность.
А вообще, новый разработчик в проекте -- это всегда радость. Пусть даже и небольшие исправления от него. Собственно, как и любая активность от обычных пользователей вроде баг репортов или предложений.
Странная статистика. Например, для России они требуют наличия аж 59 подписчиков на твой аккаунт. А вовсе не количество публичных коммитов. В результате в половине топа какие-то левые аккаунты с всего десятком коммитов.
Такая стратегия с форками никогда не работала с крупными проектами. Одно дело, когда уходит основной костяк команды и продолжает трудиться над продуктом, а другое -- когда ноунейм или лишь один из разработчиков. Он просто физически не в состоянии заменить оригинал. Это как если бы на проблемы в многоквартирном ТСЖ председатель посылал бы жильцов строить свой собственный дом и там управлять. Формально такая возможность есть, но в реальности нереализуема.
PR никто там не переоткрывал, от кода автора решили отказаться после его бана. Переоткрыли только одну связанную задачу. Причем это сделал мейнтейнер, который эту задачу пытался ревьювить и вести автора в правильном направлении. Так что шансы на закрытие необходимой автору фичи еще есть -- если кто-то другой разобьет большой PR на несколько исправлений и зальет от своего имени.
Если отбросить поведение украинского админа с первым issue (за которое в итоге другие админы флаттера извинились), то с остальными PR'ами не все так однозначно. Я посмотрел на них -- PR с кучей ревью и просьбами исправить те или иные проблемы, длинные дискуссии внутри, огромные куски кода, просьбы подождать ревью и мержа из-за апстрима и т.п. вещи, говорящие о том, что с PR не все так просто. Возможно, для флаттера или популярной библиотеки подобные вещи являются нормой -- я не знаю. Но мне, как мейнтейнеру на другом джава проекте -- такие большие и сложные PR'ы очень не нравятся. И когда дискуссия внутри PR разрастается до десятков комментариев и фиксов по сравнению с соседними -- это верный признак того, что PR надо закрывать или ставить на паузу.
Очевидно же -- недо-бизнес-модель с захламлением поиска (ака сео-мусор) накрылась медным тазом из-за необходимости платить за поднятие карточек.
10 минут на задачу, да еще и оценка скорости печати кода как один из важных критериев -- без комментариев, как говорится.
Очень большая проблема такого подхода с лайфкодингом (на время, без IDE, без гугла или других современных помощников) -- вы отсеиваете большое количество грамотных специалистов, оставляя как раз тех, кто только что закончил курсы "войти в айти" и у кого еще в "оперативной памяти" все эти команды остались. Сейчас в программировании нет необходимости выучивать наизусть миллион разных команд и конструкций языка или фреймворка (да это и физически невозможно) -- всегда есть интернет под рукой, где можно посмотреть использование какой-то команды или конструкции. Особенно это касается php или javascript, где доступный синтаксис зависит не то что от версии языка, так даже и от фреймворка.
Т.е. хорошему специалисту не важны инструменты, на которых он работает -- он решает именно задачи. А инструменты/язык уже второстепенны. Поэтому хорошие задачи и вопросы должны привязываться к способам решения задачи, а не к самим реализациям.
Некие гении в нулевых додумались сделать кнопки быстрого выключения - как же бесили такие клавиатуры:
Если это инкрементный парсинг только новых данных, то нормальные цифры. Там на трафик будет больше уходить на порядки (например, на 1 гб данных потребуется скачать 10 тб текстового трафика).
Сайты на гитхаб.ио открываются. Пример: https://jaydi85.github.io/xmage-web-news/news.html
Проблема подставных компаний - это разовое мероприятие. После которого не будет ни поддержки, ни дополнительных закупок. Поэтому долгоиграющие вещи типа сложного софта или оборудования "пиратить" нет смысла, т.к. лишаешься довольного большого куска.
Не нашел в статье причины, по которой агентство было заблокировано (а причины были). И судя по тому, как вы называете своих клиентов "неадекватными" в своем же сообщении -- причина оказалась банальна: вы поссорились с клиентами, а те подали жалобу на обман и/или невыполнение работы.
Нет, не шутка. Идею о переименовании много кто поддержал из научного сообщества:
https://en.wikipedia.org/wiki/Quantum_supremacy#Criticism_of_the_name
По статье сложилось впечатление, что люди, отвечающие за "защиту от парсеров", сами не совсем в теме, как они работают.
Сначала идет рассказ о том, что технари на добровольной основе заставили парсеры перейти на полную загрузку страницы и выполнение скриптов, вместо отдачи простого текста. Тем самым в разы увеличив нагрузку на свои сервера и трафик (об экономии которого так рьяно заботились, судя по тексту далее).
Затем рассказывается про рекапчу и ее теневой режим. Но при этом строго настрого умалчивается то, что этот вариант защиты очень легко обходится путем использования сторонних сервисов по разгадыванию капч типа рукапчи.
Так же идет рассказ про ежедневное обновление данных о компаниях и что это может спасти от парсеров. При этом называются контактные данные, юридические адреса для примера -- данные, которые вообще изменяются раз в несколько лет. А ведь это основная цель большинства парсеров и баз, а вовсе не списки госконтрактов или судов. Т.е. данный пункт "защиты" вообще бесполезный.
В итоге из-за жадности тупо закрыли свои данные, в т.ч. и для обычных пользователей. Это и позволило отсечь парсеры. Получилось в духе: доктор, у меня болит палец -- несите пилу, сейчас будем ампутировать руку.
По мне, так это вовсе не победа, а признание поражения.
Т.е. вы и за спам не блокируете, когда приходят жалобы по тому или иному айпи? Не является ли это нарушением каких-либо общепринятых обязательств? Абузоустойчивые хостинги априори находятся вне закона.
Тратит. Как процессора, так и SSD. Собственно, поэтому и обратил внимание на эту настройку, когда заметил странную работу диска и начал разбираться, кто его так нагружает -- оказалось, что фаерфокс. После увеличения интервала -- всё прекратилось.
Возможно, это не плагин, а сам фаерфокс. Он по умолчанию список всех открытых вкладок сохраняет в бекап на жесткий диск. И делает это каждые несколько секунд. browser.sessionstore.interval в about:config (в миллисекундах).
Одно дело, когда исправление неправильное, и можно сразу об этом написать/отклонить, а другое дело -- когда чего-то не хватает или реальная проблема где-то в другом месте находится. Я сам не знаю точного ответа и в этом случае требуется самому провести исследования и собрать материал по тем местам, что требуют проверки/исправления. Т.е. сделать фактически половину работы.
Плюс код был некорректно оформлен (не соблюдено форматирование, используемое в проекте).
Скажу как мейнтейнер одного крупного (1.5 млн строк) java-проекта:
Новичку зачастую не знакома история проекта и история различных "багов". В результате появляются исправления вида "я тут посмотрел код и нашел решение". Формально оно исправляет баг, но де-факто лишь прикрывает костылем одну из дырок.
Следствие из предыдущего пункта -- если человек сделал объемный PR и, алилуйа, даже тесты написал (что бывает крайне редко), но при этом не дожал или пошел не по тому пути, то приходится самому разбираться в проблеме и дописывать код. Это иногда раздражает и отнимает лишнее время.
Поэтому, как мейнтейнеру, мне очень не нравятся слишком инициативные разработчики, которые время от времени забегают в проект, накидывают всяких исправлений, а потом ты вынужден сидеть, разбираться и дописывать за них внеплановые фиксы и задачи. Но и правила хорошего тона не позволяют их остановить -- поэтому таких людей стараюсь ставить "на паузу" и "притормаживать" их активность.
А вообще, новый разработчик в проекте -- это всегда радость. Пусть даже и небольшие исправления от него. Собственно, как и любая активность от обычных пользователей вроде баг репортов или предложений.
Странная статистика. Например, для России они требуют наличия аж 59 подписчиков на твой аккаунт. А вовсе не количество публичных коммитов. В результате в половине топа какие-то левые аккаунты с всего десятком коммитов.