Lynn «Кофеман»

засунуть нужный скрипт в crontab

эмм.... код в айфреймах спокойно показывается в девтулзах.

Более четырёх лет пишу на Go, лично для меня поддерживать проекты на других языках сложнее ))
До Go много лет писал на Perl/PHP/Python/Java/C/Ruby on rails/JavaScript и "крутил" еще не мало чего.
Сейчас пишу только на Go и Python.

Основная сложность в Go - это то, что если вы начинаете писать "криво" - то писать так очень трудно :))
Подход к реализации в Go достаточно непривычный для тех, кто приходит из скриптовых языков.
Например запрет циклических импортов - это самое первое, что "взрывает" мозг :)
Нужно время чтобы адаптироваться после скриптовых языков.

Про обработку ошибок - это да, это, пожалуй, единственное что мне не нравится в Go.
Для себя я решил эту проблему за 1-2 часа :) и больше меня это не беспокоит.

По ООП - в Go оно есть, лично мне оно нравится намного больше, чем ООП в других языках ))
Всё, что реально нужно - всё есть, но при этом ничего лишнего нет.
Интерфейсы - просто прекрасны :)) Каналы, горутины - это просто "счастье" :))

А если объективно - то я бы не стал говорить о сложности поддержки проекта применимо к какому то конкретному языку.

Как правило сложность поддержки возникает там, где нормальная архитектура не заложена в проект.
Т.е. проект как могла так и писала куча людей плюс, как обычно, сделать нужно было побыстрее )), от этого никто вообще не думал об архитектуре и получилось то, что получилось :))
Про покрытие тестами и документацию мы вообще не говорим )))

А когда в таком проекте нужно что-то доработать или исправить ошибку, то почти всегда очень не просто найти то место, где нужно править, и после правок в одном месте, как правило, что-то ломается в другом :)

Как минимум, нужно соблюдать принципы SOLID, иначе код получается, мягко говоря, не поддерживаемым.
Но понимание этих принципов так же приходит с опытом, их нельзя научиться соблюдать просто прочитавши книгу или статью. Нужно сделать несколько проектов используя эти принципы, написать криво, понять как было бы правильно, всё переделать и так несколько раз.
Тогда, со временем, начнёт получаться понятный и легко поддерживаемый код.

Так мы приходим к тому, что если опыта нет - тогда проект поддерживать будет достаточно тяжело не взирая на язык и т.д.

Хочется добавить, что как бы не писали про Go, что он простой и т.д. - он явно сложнее Python/PHP и т.д.
Это еще один повод сказать, что поддерживать код на Go сложно ))

Также стоит учитывать, что проекты которые пишут на Go зачастую сложнее, чем проекты для которых выберут скриптовый язык. Go выбирают когда планируются большие нагрузки, параллельная обработка чего-либо и т.д., а это, в свою очередь, дополнительно усложняет проект.

Давайте разберём самое начало процесса, когда запускается ab и в нгинкс примерно одновременно начинают лететь 80 запросов. Счётчики в этот момент по нулям, но выставлен лимит в 1000 rps, то есть запросы могут обрабатываться не чаще, чем раз в 1 мсек.

По факту, внутрь провалятся ровно 1+10=11 запросов, а остальные 80-11=69 отобьются с 503 кодом - это даже больше 62%.

В дальнейшем, поскольку запросы постепенно размажутся во времени, перестав приходить синхронно, процент отлупов снизится, но отнюдь не до ожидаемых вами (1026-1000)/1000*100%, потому что время от времени (и скорее часто, чем редко) запросы всё-таки будут приходить чаще, чем раз в 1 мсек (бурст в 10 rps можно не учитывать, он по сравнению с лимитом микроскопический) - на это намекает среднее время исполнения 0.974 мсек, делёное на 80 потоков.

Попробуйте увеличить бурст, скажем, до 500-1000 и посмотреть, как это отразится на результатах.

https://developer.mozilla.org/ru/docs/Web/JavaScri...

Отправить на эту почту письмо с ссылкой для продолжения регистрации.

Больше никак

Это происходит из-за неправильной организации работы с HTTP.

Вы запрашиваете данные через XMLHttpRequest методом GET и по тому же url, что и сама страница. В результате получается, что у вас один и тот же HTTP метод и один и тот url отдают два разных ответа в зависимости от... непойми чего (видимо проверяется заголовок X-Requested-With), но это явно не то, что описано в спецификации HTTP.

Ключевым моментом, естественно, является то, что запрос идёт методом GET. Если вы читали спецификацию HTTP или хотя бы статьи о протоколе HTTP, то должны помнить, что метод GET является идемпотентным. Из этого следует что клиент (в данном случае - браузер), имеет полное право (если разрешают условия кэширования) ожидать, что он получит тот же ответ на этот запрос и может оптимизировать это, использовав уже имеющийся в кэше результат. Именно это и происходит.

Убедиться в том, что это так, можно очень просто: достаточно открыть dev.tools и на вкладке Network включить опцию "Disable cache". После этого вы увидите что проблема исчезла.

Правильным решением будет выделение API для XHR запросов фильтра в отдельный endpoint. Также логичнее будет использовать метод POST, а не GET.

Если же не хочется переделывать - хотя бы добавьте к XHR запросам ещё один query параметр, например xhr=1 и убедитесь что он никогда не появляется в url страниц. Это сделает ваши url для страниц и XHR запросов разными и уберёт проблему.

Также имеет смысл пересмотреть объём данных, передаваемых в ответ на каждый запрос, ведь вам нужны только значения, передавать постоянно почти 100кб текста описаний нет особого смысла, они у вас и так уже есть.

Решение будет либо перебором, либо аналитически. Частотный анализ пробовать можно, но на таком маленьком тексте он вряд ли даст хороший результат.

https://ru.wikipedia.org/wiki/HMAC

const bindFunction = (F, ...args) => F.bind(null, ...args);

Эта библиотека предназначена для сборки. Это скорее тулза для генерирования компонентов, а не для работы на лету.
В теории ты можешь её подключить и на живую, но через зад.

Изучать Angular или любой другой js фреймворк без владения js или ts равноценно, как строить ракету, не зная физику. Может быть что-то вы и построите, но полетит ли?

Вывод:

Изучите язык, чтобы иметь возможность пользоваться инструментом.

- res.writeHead(200, { 'Content-Type': 'text/plain' });
+ res.writeHead(200, {
+     'Content-Type': 'text/plain',
+     'Access-Control-Allow-Origin': '*'
+ });

канешно. в линукс можно всё и еще чуть-чуть :)

find /path/to/req -type d -exec chmod 0755 {} \;
find /path/to/req -type f -exec chmod 0644 {} \;

- type d (directory) - папки прощеее говоря.
- type f (file) - файлы
/path/to/req - путь, "внутри" котрого начинается просмотр. (./ для текущего)
- exec над каждым найденным сделать действие
chmod *** {} \; change mode - изменить параметры файла. {} \; -вместо этого подставляется путь к файлу.