Эпичные пики q95 по 200-300мс, конечно. Оценить эпичность мешает незнание, как в их мониторинге агрегация идёт, конечно — по суммарной гистограмме или как максимум сигнала (от гистограмм с более высоким разрешением).
Выглядит, что принудительный запуск GC в сервисе, где вся память — LRU кеш на хеш-таблицах, сделал ребятам больно. Кто-то удивлён? Более примечательно, что у них при расшардировании сервиса на меньшие инстансы проблема уходила — это иллюстрирует, что GC всё же не абсолютное зло.
Кажется ожидаемым, что с определённого уровня масштаба (и уровня вырожденности поведения системы) любой «умный и универсальный» аллокатор/деаллокатор достигает границ своей универсальности. Сборщик мусора (автоматический деаллокатор) начинает болеть раньше и чаще. Но я встречал в реальной жизни проекты, которым glibc-шный malloc был недостаточно хорош, и его замена на специализированный возвращала много процентов производительности.
В русском выглядит иначе, т.к. в русском (не рассматривая поэтические тексты) слово «архитектор» обозначает две-три конкретные инженерные специальности. Дискретный набор, что характерно для латинизмов в русском.
В английском же спектр значений более непрерывен: architect — либо строитель, либо же… визионер, владеющий общим замыслом. Merriam-Webster приводит примеры типичных использований: Jared Kushner is the chief architect of Kushner Companies in its current form. [N.N.] is the architect of American foreign policy.
Поэтому, если на вопрос: What is your role in Microsoft? вы отвечаете: I am the architect! — это прозвучит так, как будто вы претендуете чуть ли не на роль отца-основателя или крупного визионера компании. Отсюда и улыбки :)
В то время как по-русски: «Какова ваша роль в Микрософте?» — «Архитектор.» — такого смыслового оттенка нет, понятно, что вы инженер, определяющий структуру и выбор технических средств какого-то частного проекта. Кажется, разница есть и существенная)
Architect в английском не обязательно означает архитектора ПО, если там нет приставки software. Конечно, в совсем неформальном тексте software будет подразумеваться, но даже в стиле semi-formal такая конструкция вызовет улыбку.
Второе. Безотносительно к переводу, «бригада архитекторов» многих в IT наведёт на ироничные мысли о процессах и методологии вашей организации. Старайтесь этого избегать.
Ну и в-третьих, в большинстве контекстов вашему англоязычному читателю будет непонятно, зачем вы расписываете свои или чьи-то ещё обязанности, вместо того, чтоб просто назвать должность и проект.
Если хочется ближе к тексту перевести, я бы предложил писать в стиле perform in a leadership role in a subdivision responsible for the software architecture and design of QuantumCalc для резюме или объявления о найме, а для пресс-релиза или корреспонденции просто указывать должность, например Lead Software Architect.
Удалёнка, конечно, другой расклад, я с ним мало знаком. Я лично вот не смог найти работу по удалёнке на $30/час, чтоб из этого получились упомянутые 3k. А Вам удавалось?)
Берем, для примера, Нью-Йорк и считаем: Junior Programmer — $90k gross. Круто?
Вычитаем налоги — $28k, обамакэр (медицина) — $12k, 401k (пенсия) — ну пусть $6k.
Итого наличных денег: $44k или $3.6k/mo
Теперь смотрим уровень цен:
Маленькая квартира не в центре — $1.9k. Осталось $1.9k/mo.
Groceries Prices in New York, NY are 220.91% higher than in Moscow + 5% налог с продаж = 232% — т.е. если пересчитывать по ценам супермаркетов, вся оставшаяся з/п это $818 «московских» долларов на руки плюс рента квартиры
Итого зарплата джуниора в NY обеспечивает уровень потребления, равный 80 т.р. «на руки» в Москве. Да, в Москве джуниорам платят чуток меньше, но разница, как вы видите, не кардинальная. За эти деньги на личном автомобиле вы ездить в центр не будете, в рестораны будете ходить очень иногда, и сбережений у вас не образуется.
А если ваш аргумент «без разницы, сколько стоит аренда, важно сколько работодатель платит за работу», то не забывайте при сравнении, что что НДФЛ+соцфонды составляют 1/3 от зарплаты, и даже если российский работодатель положит вам $3k gross «как в Америке», до вас дойдёт $2k. 2k больше, чем платят у нас джуниору, но не в разы. С учётом разницы цен — так совсем уж не в разы. Увы.
Не совсем понял, какое изменение вы предлагаете: умножать наивную оценку на X*Y*Z, т.е. на 3-6-12 и так далее? Как-то выглядит не очень, честно говоря. Попробуйте это на практике и поделитесь результатом)
Ну, это довольно логично, поскольку я писал не про то, как оценивать проекты, а про то, как оценивать задачи :) Проект, если под ним подразумевается блок работ с единственной целью, с проектным управлением и top-down декомпозицией, оценивается так:
Беретё вашу WBS, разбиваете до уровня задач в компетенции одного разработчика и оцениваете каждую из этих задач. Если метод сигнализирует скрытый объём части задач — переразбиваете. Далее делите метрику на скорость (в моей жизни, переходный коэффициент получался примерно 10 для опытных разрабов и 5 для новичков), получаете пессимистичные оценки времени. Оптимистичные оценки получаете другим способом экспертной оценки. Запускаете PERT, выделяете критичные пути, назначаете ресурсы, имеете обсчитанный проект. Проверялось в масштабе до года.
Что же касается чистого ресерча — не программистского «ресерча», когда мы боремся с техническими проблемами и пытаемся побыстрее выдать готовый код — а исследования рынков, выявления потребностей заказчика, каких-то инновационных R&D начинаний — такой ресёрч, конечно же, посчитать этим способом нельзя. Я, собственно, и не обещал :)
Смешная история, конечно, но получился пост-бальзам на душу двух типов разработчиков:
Я прикладной программист! Всегда надо вызывать библиотечные/системные функции, а если библиотечная функция чего-то не умеет, то это её проблемы! Пусть заказчик купит нам другую платформу, или заплатит нам миллион за то, чтоб мы таки написали копирование файла.
Я работаю по спецификации, а заказчик ничего не понимает в сложности задачи. Надо ему показать, какой он глупый, а с меня какой спрос? Спецификация всегда не полна… а я просто работаю по спецификации (goto start)
Добавим в эту аудиторию тех манагеров, кто не в состоянии поставить/описать задачу и сетует на плохих программистов, и получился прекрасный ragebait (ну или cringe bait) для широких слоев населения.
Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)
Вот так, братцы, строятся блинные заводы в представлении узбека из «привокзальной рыгаловки», и это во многом подытоживает Agile vs не-Agile дискуссию :)
можно комитить все что захочешь в контексте своей ветки, вот в паблик что-то неработающее отдавать нельзя да, при этом при сливе своей ветке в общую всегда можно все коммиты объеденить например в один, если хочется.
Если ветка куда-то пушится, то никак нельзя при сливе в общую «все коммиты объединить в один». Потому что если объединение коммитов делать через git rebase -i на себя — то у ветки появится новый хид, и пушить её придётся потом с --force (и с бубном по замене HEAD если она хоть куда-то зачекаучена, хоть даже на вторую твою же машину). Если это делать через git rebase на публичную ветвь — то тогда тебе нужно свою ветку закрыть и отделить заново (см. описание ситуации с merge --squash и сherry-pick). Не закроешь — все повторные мерджи будут выдавать все те конфликты слияния, которые ты уже разрешил раньше.
Если же своя ветка никуда не пушится, а существует только локально, то проблем нет, но здравствуй скрипт бэкапа воркспейса. Который нужен только для того, чтобы изменения, которые ты закоммитил в VCS, при отказе винта никуда не пропали. К чему я, собственно, и пришёл. Но прикручивать костыльное резервное копирование к крутой и прогрессивной системе версий, это так стильно…
Я могу рассказать о паре своих наиболее эпичных факапов с GIT. Попрошу фанатов Git-а не читать, так как это может быть больно. Как говорится: Graphic content; viewer discretion is adviced.
Случай раз случился, когда я возжелал использовать merge --squash. Отличная, казалось бы, возможность переносить изменения из приватной дев-ветки, где ты что-то делаешь, в общую ветвь репозитория, делая красивый коммит с комментарием «Исправлен баг #32143». Казалось бы, что может пойти не так? Идея умерла в муках, когда оказалось, что конфликт, единожды разрешённый при merge --squash, требуется разрешать снова и снова при каждом последующем слиянии между эти двумя ветками. То же самое относится и к git cherry-pick.
Что делать? Забудьте всё, что вы слышали про то, что гит круто мерджит коммиты. Вы должны делать cherry-pick или squash только в том случае, если после этого выбросите исходную ветку, все остальные варианты вам гарантируют боль. Разумеется, в документации об этом забыли сообщить. Не нравится? Используйте Mercurial. Или даже SVN. Потому что даже отсталый SVN вам позволит смержиться с той веткой, из которой вы перед этим делали cherry-pick, не разрешая повторно те же самые конфликты! Чертова магия.
Случай два случился, когда я попробовал реорганизовать проект моей группы с использованием git submodules. Идея заключалась в том, что, раз у нас есть пяток модулей, каждый из которых проходит свой небольшой цикл разработки и по сути версионируется, логично было бы разделить историю проекта на несколько репозиториев, чтобы упростить историю и облегчить мерджи. Опять же, казалось бы, что может пойти не так? Я уже предвкушал в своём воображении, как у меня в основном репозитории будет ветка RC с оттестированным кодом и ветка Dev, в которой мы будем проводить интеграцию…
Я затрудняюсь сказать, сколько рабочего времени мы потеряли, пытаясь использовать эту конструкцию. Правда заключается в том, что единственное, для чего предназначен git submodules — это чтобы вы могли зачекаутить версию Linux Kernel, которую специально обученный человек собрал для вас по модулёчку. Всякие идеи о том, что разработчик может зачекаутить проект с сабмодулями, внести изменения в один из модулей, исправить баг во втором, а потом засунуть всё это обратно на сервер, надо сразу отбросить, потому что git submodules не предоставляет вам ничего. Ссылки на сабрепы не трекают ветви (вернее, трекают на уровне default pull/push, но эта привязка никак не сохраняется на сервере); git commit толком не умеет обнаруживать изменения в сабмодулях; попытка откатить или смерджить корневой репозиторий обычно приводит вас куда-то в ад из конфликтов слияния, которые были сто лет назад разрешены… Опять же, какой ответ? Можно написать кучу скриптов для того, чтобы этот велосипед делал только безопасные действия: скрипт чекаута, скрипт коммита, скрипт слияния — но мы предпочли позорно отказаться от борьбы с сабмодулями.
А ещё я могу назвать третью идею из GIT-агиток, которую нужно сразу отбросить: «Коммитим часто!». Нет, даже не думайте, что git заменит вам ваш костыльный скрипт с бекапом воркспейса через rsync. Коммитить недоделанные вещи, потому что вы собрались в командировку или в отпуск, вам категорически не рекомендуется. Любая тестовая правка «туда-обратно» непременно потом вылезет на git blame, даже если в итоге ничего не изменилось; редактирование истории выходит себе дороже… в общем, просто представьте, что ваш GIT — это такой SVN, в который вы коммитите большой блоб кода раз в неделю, и не пытайтесь хотеть от него ничего большего. Ну, или используйте Mercurial.
Сложно представить, сколько я получу минусов за то, что не встроился в общий хвалебный хор, но это реальный опыт человека, который рвался использовать Git сам и учить этому других, но не получил в результате ничего, кроме боли и проблем. Мне жаль, что разработчики Гита считают себя выше того, чтоб думать о типовых сценариях использования VCS, но это их личный выбор, а мы делаем свой собственный: Mercurial.
Цифра 1500 ни о чём мне не говорит. Вы бы лучше рассказали, как часто эти кейсы пропускают незамеченными 'регрессионные' баги? И в каком проценте случаев, когда случилась регрессия, с помощью ваших 1500 кейсов невозможно локализовать проблему, а требуется бубен и долгая отладка? Вот как вы это скажете, тогда можно будет эти цифры сравнить с проектами на других языках и платформах.
Хотел бы напомнить, что один из принципов, благодаря которому TDD работает — это то, что минимальный разумный код, затыкающий новый тест, обычно является неплохим решением задачи, а другой — то, что вызванные добавлением нового юнит-теста изменения всегда достаточно локальны. Обе этих фактора страдают, если речь идёт о Javascript, где для реализации функциональности очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения, и всё это вместе считается хорошей практикой разработки. По-моему, глупо отрицать то, что каждый шуточный модуль «фольксваген», который хакает чужой код, чтобы обмануть тесты — это камень в огород платформы, демонстрирующий её очевидные слабости. Впрочем, толпы ̶о̶б̶и̶ж̶е̶н̶н̶ы̶х̶ ̶д̶е̶т̶е̶й̶ ̶ опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
Аппаратные токены (могут называться «генераторы паролей», «криптокалькуляторы» и т.д.) в банках бывают. Из числа тех банков, с которыми я сталкивался, такую услугу предоставляли Газпромбанк и Московский Индустриальный.
Стоимость такой штуки порядка 1 тыс., но в принципе, это дешевле отдельного мобильного телефона с СМС-авторизацией.
Действительно, совсем холопы обнаглели. Никакой благодарности! Нет, чтоб начать, к примеру, добровольную зачистку статей, рассказывающих про существование гомосексуалистов, или «оскорбляющих чувства верующих». Чтобы не было больше поводов.
А ещё неплохо бы всех модераторов, не живущих в РФ, лишить административных полномочий. Как же так можно — люди, говорящие по-русски, царских указов не выполняют? Да ещё и живут, как вы говорите, в Северной Америке, или в Украине, или в РФ, но почему-то мыслят непатриотично.
И вообще, давно пора бы назначить директором Википедии какого-нибудь «главу Севастопольского благочиния Сергия Халюту». Да только руки коротки.
Так посмотрите! они всё ещё здесь, их полно в комментариях выше. И не все они стараются за бабло, многие искренне верят в «пропаганду гомосексуализма» или что там в этот раз.
Подскажите кому-нибудь из Роскомнадзора идею: сделать русскоязычный форк Википедии (движок свободный, контент свободный же), а основную заблокировать. Тогда, наконец, появится возможность откатить всё то враньё, которое напихали в русскую Википедию с того момента, как государство начало тратить миллиарды на пропаганду в Интернете.
Сообщество РуВики не справляется с государственным давлением уже довольно давно, все эти пляски вокруг статьи о слове из трёх букв и статьях о наркотиках — это пустяки в сравнении с тем, что сейчас делается с содержанием статей…
Выглядит, что принудительный запуск GC в сервисе, где вся память — LRU кеш на хеш-таблицах, сделал ребятам больно. Кто-то удивлён? Более примечательно, что у них при расшардировании сервиса на меньшие инстансы проблема уходила — это иллюстрирует, что GC всё же не абсолютное зло.
Кажется ожидаемым, что с определённого уровня масштаба (и уровня вырожденности поведения системы) любой «умный и универсальный» аллокатор/деаллокатор достигает границ своей универсальности. Сборщик мусора (автоматический деаллокатор) начинает болеть раньше и чаще. Но я встречал в реальной жизни проекты, которым glibc-шный malloc был недостаточно хорош, и его замена на специализированный возвращала много процентов производительности.
В английском же спектр значений более непрерывен: architect — либо строитель, либо же… визионер, владеющий общим замыслом. Merriam-Webster приводит примеры типичных использований: Jared Kushner is the chief architect of Kushner Companies in its current form. [N.N.] is the architect of American foreign policy.
Поэтому, если на вопрос: What is your role in Microsoft? вы отвечаете: I am the architect! — это прозвучит так, как будто вы претендуете чуть ли не на роль отца-основателя или крупного визионера компании. Отсюда и улыбки :)
В то время как по-русски: «Какова ваша роль в Микрософте?» — «Архитектор.» — такого смыслового оттенка нет, понятно, что вы инженер, определяющий структуру и выбор технических средств какого-то частного проекта. Кажется, разница есть и существенная)
Второе. Безотносительно к переводу, «бригада архитекторов» многих в IT наведёт на ироничные мысли о процессах и методологии вашей организации. Старайтесь этого избегать.
Ну и в-третьих, в большинстве контекстов вашему англоязычному читателю будет непонятно, зачем вы расписываете свои или чьи-то ещё обязанности, вместо того, чтоб просто назвать должность и проект.
Если хочется ближе к тексту перевести, я бы предложил писать в стиле perform in a leadership role in a subdivision responsible for the software architecture and design of QuantumCalc для резюме или объявления о найме, а для пресс-релиза или корреспонденции просто указывать должность, например Lead Software Architect.
Берем, для примера, Нью-Йорк и считаем: Junior Programmer — $90k gross. Круто?
Вычитаем налоги — $28k, обамакэр (медицина) — $12k, 401k (пенсия) — ну пусть $6k.
Итого наличных денег: $44k или $3.6k/mo
Теперь смотрим уровень цен:
Маленькая квартира не в центре — $1.9k. Осталось $1.9k/mo.
Groceries Prices in New York, NY are 220.91% higher than in Moscow + 5% налог с продаж = 232% — т.е. если пересчитывать по ценам супермаркетов, вся оставшаяся з/п это $818 «московских» долларов на руки плюс рента квартиры
Итого зарплата джуниора в NY обеспечивает уровень потребления, равный 80 т.р. «на руки» в Москве. Да, в Москве джуниорам платят чуток меньше, но разница, как вы видите, не кардинальная. За эти деньги на личном автомобиле вы ездить в центр не будете, в рестораны будете ходить очень иногда, и сбережений у вас не образуется.
А если ваш аргумент «без разницы, сколько стоит аренда, важно сколько работодатель платит за работу», то не забывайте при сравнении, что что НДФЛ+соцфонды составляют 1/3 от зарплаты, и даже если российский работодатель положит вам $3k gross «как в Америке», до вас дойдёт $2k. 2k больше, чем платят у нас джуниору, но не в разы. С учётом разницы цен — так совсем уж не в разы. Увы.
Беретё вашу WBS, разбиваете до уровня задач в компетенции одного разработчика и оцениваете каждую из этих задач. Если метод сигнализирует скрытый объём части задач — переразбиваете. Далее делите метрику на скорость (в моей жизни, переходный коэффициент получался примерно 10 для опытных разрабов и 5 для новичков), получаете пессимистичные оценки времени. Оптимистичные оценки получаете другим способом экспертной оценки. Запускаете PERT, выделяете критичные пути, назначаете ресурсы, имеете обсчитанный проект. Проверялось в масштабе до года.
Что же касается чистого ресерча — не программистского «ресерча», когда мы боремся с техническими проблемами и пытаемся побыстрее выдать готовый код — а исследования рынков, выявления потребностей заказчика, каких-то инновационных R&D начинаний — такой ресёрч, конечно же, посчитать этим способом нельзя. Я, собственно, и не обещал :)
Добавим в эту аудиторию тех манагеров, кто не в состоянии поставить/описать задачу и сетует на плохих программистов, и получился прекрасный ragebait (ну или cringe bait) для широких слоев населения.
Хотя, возможно, мы имеем описание здравого человека, который решил доказать интервьюеру, что тот не умеет ставить задачи. Только непонятно, зачем такой садизм тогда?)
Если ветка куда-то пушится, то никак нельзя при сливе в общую «все коммиты объединить в один». Потому что если объединение коммитов делать через git rebase -i на себя — то у ветки появится новый хид, и пушить её придётся потом с --force (и с бубном по замене HEAD если она хоть куда-то зачекаучена, хоть даже на вторую твою же машину). Если это делать через git rebase на публичную ветвь — то тогда тебе нужно свою ветку закрыть и отделить заново (см. описание ситуации с merge --squash и сherry-pick). Не закроешь — все повторные мерджи будут выдавать все те конфликты слияния, которые ты уже разрешил раньше.
Если же своя ветка никуда не пушится, а существует только локально, то проблем нет, но здравствуй скрипт бэкапа воркспейса. Который нужен только для того, чтобы изменения, которые ты закоммитил в VCS, при отказе винта никуда не пропали. К чему я, собственно, и пришёл. Но прикручивать костыльное резервное копирование к крутой и прогрессивной системе версий, это так стильно…
Случай раз случился, когда я возжелал использовать merge --squash. Отличная, казалось бы, возможность переносить изменения из приватной дев-ветки, где ты что-то делаешь, в общую ветвь репозитория, делая красивый коммит с комментарием «Исправлен баг #32143». Казалось бы, что может пойти не так? Идея умерла в муках, когда оказалось, что конфликт, единожды разрешённый при merge --squash, требуется разрешать снова и снова при каждом последующем слиянии между эти двумя ветками. То же самое относится и к git cherry-pick.
Что делать? Забудьте всё, что вы слышали про то, что гит круто мерджит коммиты. Вы должны делать cherry-pick или squash только в том случае, если после этого выбросите исходную ветку, все остальные варианты вам гарантируют боль. Разумеется, в документации об этом забыли сообщить. Не нравится? Используйте Mercurial. Или даже SVN. Потому что даже отсталый SVN вам позволит смержиться с той веткой, из которой вы перед этим делали cherry-pick, не разрешая повторно те же самые конфликты! Чертова магия.
Случай два случился, когда я попробовал реорганизовать проект моей группы с использованием git submodules. Идея заключалась в том, что, раз у нас есть пяток модулей, каждый из которых проходит свой небольшой цикл разработки и по сути версионируется, логично было бы разделить историю проекта на несколько репозиториев, чтобы упростить историю и облегчить мерджи. Опять же, казалось бы, что может пойти не так? Я уже предвкушал в своём воображении, как у меня в основном репозитории будет ветка RC с оттестированным кодом и ветка Dev, в которой мы будем проводить интеграцию…
Я затрудняюсь сказать, сколько рабочего времени мы потеряли, пытаясь использовать эту конструкцию. Правда заключается в том, что единственное, для чего предназначен git submodules — это чтобы вы могли зачекаутить версию Linux Kernel, которую специально обученный человек собрал для вас по модулёчку. Всякие идеи о том, что разработчик может зачекаутить проект с сабмодулями, внести изменения в один из модулей, исправить баг во втором, а потом засунуть всё это обратно на сервер, надо сразу отбросить, потому что git submodules не предоставляет вам ничего. Ссылки на сабрепы не трекают ветви (вернее, трекают на уровне default pull/push, но эта привязка никак не сохраняется на сервере); git commit толком не умеет обнаруживать изменения в сабмодулях; попытка откатить или смерджить корневой репозиторий обычно приводит вас куда-то в ад из конфликтов слияния, которые были сто лет назад разрешены… Опять же, какой ответ? Можно написать кучу скриптов для того, чтобы этот велосипед делал только безопасные действия: скрипт чекаута, скрипт коммита, скрипт слияния — но мы предпочли позорно отказаться от борьбы с сабмодулями.
А ещё я могу назвать третью идею из GIT-агиток, которую нужно сразу отбросить: «Коммитим часто!». Нет, даже не думайте, что git заменит вам ваш костыльный скрипт с бекапом воркспейса через rsync. Коммитить недоделанные вещи, потому что вы собрались в командировку или в отпуск, вам категорически не рекомендуется. Любая тестовая правка «туда-обратно» непременно потом вылезет на git blame, даже если в итоге ничего не изменилось; редактирование истории выходит себе дороже… в общем, просто представьте, что ваш GIT — это такой SVN, в который вы коммитите большой блоб кода раз в неделю, и не пытайтесь хотеть от него ничего большего. Ну, или используйте Mercurial.
Сложно представить, сколько я получу минусов за то, что не встроился в общий хвалебный хор, но это реальный опыт человека, который рвался использовать Git сам и учить этому других, но не получил в результате ничего, кроме боли и проблем. Мне жаль, что разработчики Гита считают себя выше того, чтоб думать о типовых сценариях использования VCS, но это их личный выбор, а мы делаем свой собственный: Mercurial.
Хотел бы напомнить, что один из принципов, благодаря которому TDD работает — это то, что минимальный разумный код, затыкающий новый тест, обычно является неплохим решением задачи, а другой — то, что вызванные добавлением нового юнит-теста изменения всегда достаточно локальны. Обе этих фактора страдают, если речь идёт о Javascript, где для реализации функциональности очередной 'Experienced Front-end Developer' порой беззастенчиво ломает чужой объект (с неопределёнными глобальными последствиями), а затем утешает себя тем, что мы же написали тест на свои изменения, и всё это вместе считается хорошей практикой разработки. По-моему, глупо отрицать то, что каждый шуточный модуль «фольксваген», который хакает чужой код, чтобы обмануть тесты — это камень в огород платформы, демонстрирующий её очевидные слабости. Впрочем, толпы ̶о̶б̶и̶ж̶е̶н̶н̶ы̶х̶ ̶д̶е̶т̶е̶й̶ ̶ опытных JS-разработчиков, минусующих незлую в общем-то шутку, явно не желают это обсуждать.
Стоимость такой штуки порядка 1 тыс., но в принципе, это дешевле отдельного мобильного телефона с СМС-авторизацией.
А ещё неплохо бы всех модераторов, не живущих в РФ, лишить административных полномочий. Как же так можно — люди, говорящие по-русски, царских указов не выполняют? Да ещё и живут, как вы говорите, в Северной Америке, или в Украине, или в РФ, но почему-то мыслят непатриотично.
И вообще, давно пора бы назначить директором Википедии какого-нибудь «главу Севастопольского благочиния Сергия Халюту». Да только руки коротки.
Сообщество РуВики не справляется с государственным давлением уже довольно давно, все эти пляски вокруг статьи о слове из трёх букв и статьях о наркотиках — это пустяки в сравнении с тем, что сейчас делается с содержанием статей…