Не профессиональный веб-разработчик. Т.е. зарабатываю я не разработкой сайтов, а разработкой игр. Но в играх примерно такой же код и там тоже нет юнит тестов. Больше того, у других разработчиков игр, которых я знаю, тоже нет юнит-тестов!
Справедливости ради, минимальное консольное приложение выглядит так:
{$APPTYPE CONSOLE}
begin
end.
Многословность не есть недостаток, зачастую она повышает читаемость кода. Код гораздо чаще читают, чем пишут, поэтому читабельность важнее "писабельности", тем более что с последней хорошо помогает IDE — автодополнение, шаблоны.
Кстати я тоже не в восторге от того, что в Delphi сделали со строками, считаю это большой глупостью. Нормально же всё было! Захотели сократить зоопарк строковых типов — добавили ещё один :(
Так есть и FastCGI и SCGI. Но идея писать, а тем более дебажить такое на Perl меня весьма пугала. Хотя вероятно для опытного Perl-разработчика это норм.
Если таблицу можно кэшировать сервером, значит её можно и вовсе сделать статической. Что, собственно, я в итоге и сделал. Ведь смысл скрипта как-раз в том, чтобы генерировать уникальный контент.
Спасибо!
Насчёт memory leaks и падений: у меня там запущено еще 2 сервера старых игр, написанных на Delphi, которые уже года 3-4 никто не трогал. Кроме рестартов, связанных с обновлением системы (примерно раз в полгода), они не перезапускались. И вот они работают, люди играют — ни одного падения за эти годы, и память не течет. Конечно, так получилось не сразу, но постепенно я пришел к простому выводу: если не создавать объекты, не выделять явно память, а использовать лишь managed-типы, то и течь нечему :) Включенный Range Check защищает от выходов за пределы массивов, тем самым предотвращая порчу памяти. А повсеместные блоки try/except не дают мелким проблемам перерасти в крупные.
Вероятно в ближайшее время на Patreon'е будет достигнута следующая цель: тогда опубликую код сервера игры и напишу новую статью о его устройстве.
Не упадёт — всё везде завёрнуто в try/except. Ну и есть же способы следить за процессом и запускать его в случае падения.
Перезапуск при обновлении — да, на 2-3 секунды сайт отключается. При большом желании можно повозиться чтобы этого избежать.
Ну вот например я недавно скачал свежий официальный дистрибутив и установил Лазарус, запустил его пересборку — ошибка! Скачал 32-битную версию — то же самое. Ну как так?
Другой пример:
var s:string
...
s.ToUpper;
В mode=Delphi — работает, в mode=DelphiUnicode — ошибка. А по документации должно работать.
Imho с грамматикой проблем нет. Основных проблем на мой взгляд две:
Долгое время не было бесплатного инструмента, тогда как C++, Java, Nodejs, Python — всё бесплатно.
Долгое время была фактически монополия на язык, который был железобетонно связан с библиотеками. Получается закрытая проприетарная экосистема, которая пусть и хороша как коммерческое решение, но долгосрочно с ней связываться стрёмно: мало ли что… С развитием FPC/Lazarus стало менее стрёмно.
Другой тест — на 150 клиентов, тут уже видно, что некое равновесие наступает при нагрузке в ~45 запросов в секунду, сайт при этом уже тормозит:
Судя по логам, worker тратит на выполнение запроса 20-100 мс, в среднем примерно 40 мс. Запросы сложились в очередь — отсюда большое время ожидания.
Вообще результат сильно зависит от того, как написана реализация конкретной страницы. Можно запросто обрабатывать и тысячи запросов в секунду, если не делать в каждом запросе десятки обращений к БД, а использовать только данные в памяти.
Обратите внимание, все эти warning'и происходят из сторонних скриптов.
Что касается непосредственно кода сайта — да, он получился скомканным, я это и в статье отметил. Первый блин, стройная структура формируется не сразу. Второй сайт получился уже гораздо стройнее.
Не профессиональный веб-разработчик. Т.е. зарабатываю я не разработкой сайтов, а разработкой игр. Но в играх примерно такой же код и там тоже нет юнит тестов. Больше того, у других разработчиков игр, которых я знаю, тоже нет юнит-тестов!
Тем не менее, сайт в продакшене, сервер игры — тоже, как и сервера еще 3-х игр. В продакшене с 2004-го (один правда уже закрылся).
Модули. Именно это я и сделал — выделил модуль SCGI для самостоятельного использования.
https://loader.io
Справедливости ради, минимальное консольное приложение выглядит так:
Многословность не есть недостаток, зачастую она повышает читаемость кода. Код гораздо чаще читают, чем пишут, поэтому читабельность важнее "писабельности", тем более что с последней хорошо помогает IDE — автодополнение, шаблоны.
Кстати я тоже не в восторге от того, что в Delphi сделали со строками, считаю это большой глупостью. Нормально же всё было! Захотели сократить зоопарк строковых типов — добавили ещё один :(
Какие плейсхолдеры?
Так есть и FastCGI и SCGI. Но идея писать, а тем более дебажить такое на Perl меня весьма пугала. Хотя вероятно для опытного Perl-разработчика это норм.
Если таблицу можно кэшировать сервером, значит её можно и вовсе сделать статической. Что, собственно, я в итоге и сделал. Ведь смысл скрипта как-раз в том, чтобы генерировать уникальный контент.
Спасибо!
Насчёт memory leaks и падений: у меня там запущено еще 2 сервера старых игр, написанных на Delphi, которые уже года 3-4 никто не трогал. Кроме рестартов, связанных с обновлением системы (примерно раз в полгода), они не перезапускались. И вот они работают, люди играют — ни одного падения за эти годы, и память не течет. Конечно, так получилось не сразу, но постепенно я пришел к простому выводу: если не создавать объекты, не выделять явно память, а использовать лишь managed-типы, то и течь нечему :) Включенный Range Check защищает от выходов за пределы массивов, тем самым предотвращая порчу памяти. А повсеместные блоки try/except не дают мелким проблемам перерасти в крупные.
Вероятно в ближайшее время на Patreon'е будет достигнута следующая цель: тогда опубликую код сервера игры и напишу новую статью о его устройстве.
Не упадёт — всё везде завёрнуто в try/except. Ну и есть же способы следить за процессом и запускать его в случае падения.
Перезапуск при обновлении — да, на 2-3 секунды сайт отключается. При большом желании можно повозиться чтобы этого избежать.
Ну вот например я недавно скачал свежий официальный дистрибутив и установил Лазарус, запустил его пересборку — ошибка! Скачал 32-битную версию — то же самое. Ну как так?
Другой пример:
В mode=Delphi — работает, в mode=DelphiUnicode — ошибка. А по документации должно работать.
Imho с грамматикой проблем нет. Основных проблем на мой взгляд две:
Другой тест — на 150 клиентов, тут уже видно, что некое равновесие наступает при нагрузке в ~45 запросов в секунду, сайт при этом уже тормозит:
Судя по логам, worker тратит на выполнение запроса 20-100 мс, в среднем примерно 40 мс. Запросы сложились в очередь — отсюда большое время ожидания.
Вообще результат сильно зависит от того, как написана реализация конкретной страницы. Можно запросто обрабатывать и тысячи запросов в секунду, если не делать в каждом запросе десятки обращений к БД, а использовать только данные в памяти.
Стресс-тест: 20 запросов в секунду в течение 20 секунд.
Домашняя страница (самая тяжелая):
И шаблоны там выглядят как-то так:
Но писать в Лазарусе — это боль.
Пока к сожалению нельзя.
Обратите внимание, все эти warning'и происходят из сторонних скриптов.
Что касается непосредственно кода сайта — да, он получился скомканным, я это и в статье отметил. Первый блин, стройная структура формируется не сразу. Второй сайт получился уже гораздо стройнее.
А по мне так запах хлора вполне себе приятный. Только долго его нюхать не получится :)
Здесь MySQL, кавычки повсюду использую двойные, поскольку запросы со строками обычно выглядят так:
т.е. поскольку одинарные уже задействованы, логично использовать двойные.
Но вообще спасибо за замечание, действительно стоит обрабатывать и одинарные.