Такая стратегия с форками никогда не работала с крупными проектами. Одно дело, когда уходит основной костяк команды и продолжает трудиться над продуктом, а другое -- когда ноунейм или лишь один из разработчиков. Он просто физически не в состоянии заменить оригинал. Это как если бы на проблемы в многоквартирном ТСЖ председатель посылал бы жильцов строить свой собственный дом и там управлять. Формально такая возможность есть, но в реальности нереализуема.
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 подписчиков на твой аккаунт. А вовсе не количество публичных коммитов. В результате в половине топа какие-то левые аккаунты с всего десятком коммитов.
Помню, даже читал тут на хабре когда-то статью в духе «звоночки для фрилансера». И там подобное было одним из. С чем полностью согласен (по многолетнему опыту работы на фрилансе). Излишне требовательный к тех деталям заказчик — часто заканчивается проблемой для фрилансера.