Добавлю, что на фоне общего времени, потраченного на создание сайта, время на разработку этого модуля SCGI — это просто капля в море. Основное время занимают создание макета, нарезка HTML, написание кода на JS и кода функционала бэкенда, локализация, тестирование и т.д.
Описание SCGI в вики занимает страницу текста, чтобы с ней разобраться, достаточно 10 минут. Час-полтора — написать реализацию. После написания и отладки эту инфу можно навсегда выбросить из головы.
Для изучения языка программирования нужно гораздо больше времени. И гораздо больше "памяти" в голове, чтобы запомнить основные стандартные функции.
Что касается PHP, то я его в принципе не рассматривал из-за его репутации. Может быть в современном PHP всё не так, как было раньше, но в памяти отложилось, что с PHP лучше не связываться, т.к. на каждом шагу — то выстрел в ногу, то уязвимость.
В принципе любой интерпретируемый язык, в котором есть eval() — это пороховая бочка.
В логике генерации запроса есть смысл, если есть множество однотипных запросов. Например, у меня есть много однотипных SELECT'ов — для них написаны обобщённые методы. А если запрос уникальный или их пара штук, то замена их на генератор выглядит как создание избыточного уровня абстракции. Это снижает понятность кода: когда видишь "UPDATE xxx WHERE yyy" — сразу понятно что это и как работает, потому что это SQL. А когда видишь this->update('xxx','yyy') — уже не очень понятно, потому что это придуманный кем-то интерфейс, у которого неизвестно что под капотом.
А что касается фреймворков, которые не допиливают: наверно их бы просто не было в таком количестве, если бы их создатели руководствовались принципом: "Зачем писать, лучше взять уже готовое".
Я с вами совершенно согласен, что для бизнеса по созданию сайтов, паскаль — очень плохой вариант. Это очевидно. Но если это бизнес, использующий Delphi в основной своей деятельности, и у этого бизнеса появилась побочная задача сделать себе сайт и поддерживать его, то не исключена ситуация, когда окажется выгоднее не нанимать для этого отдельного веб-разработчика, а справиться своими силами.
К сожалению, чудес не бывает: если нужна определенная логика — её нужно где-то написать. За исключением фантастического случая, когда готовое решение реализует на 100% то, что нужно. Вопрос лишь в том, что выгодней: допиливать чужое решение под свои условия, или реализовать своё. Выбор не всегда очевиден.
То есть на официальном сайте Lazarus — неправильная версия? Ну Ok.
Вообще я в курсе, что в инете есть допиленные версии Лазаруса, но сам факт того, что такие версии нужно где-то искать, вместо того, чтобы взять на официальном сайте — уже о чём-то говорит!
Дейстивтельно, какая куча ошибок? Как-раз таки куча ошибок возникла бы начни я писать всё это на каком-нибудь PHP-фреймворке. Из-за незнания особенностей языка, фреймворка, незнакомых и непривычных инструментов разработки и отладки.
Собственно, достаточно взглянуть на JS-код этого же сайта, чтобы понять, как мог бы выглядеть код сайта на PHP :-) ПРи том, что JS для меня не такой уж незнакомый, ведь я использую его для фронтенда сайтов достаточно давно.
Community Edition бесплатный, а если доход >$5K, то можно и раскошелиться на лицензию. Я слышал много нытья от разных людей про дороговизну лицензии, но серьёзно — на фоне burn rate программиста это не такая уж значительная сумма. Хотя я, конечно, предпочёл бы чтобы он стоил дешевле. Тот же 3D Max стоит дороже, но им вовсю пользуются, несмотря на наличие бесплатного Blender'а.
У меня сайт и сами игры написаны вообще в Turbo Delphi Explorer, который бесплатный без ограничений по доходу.
Кстати, написать парсер (сервер) HTTP — задача не сложная и не дорогая даже без каких-либо библиотек. Протокол сложный в реализации на клиенте, а на сервере можно ограничиться весьма простой реализацией. У меня сервер игры как-раз работает как HTTP-сервер. А SCGI еще проще.
Сервер: Xeon 3430@2.4GHz
База: MySQL 5.1
Типичное время обработки запроса к главной странице — 50 мс (12 SQL-запросов).
В данном случае производительность упирается в БД, форматирование текста — это мизер. Если поставить задачу повысить производительность, то в первую очередь надо избавиться от лишних запросов к БД.
Добавлю, что на фоне общего времени, потраченного на создание сайта, время на разработку этого модуля SCGI — это просто капля в море. Основное время занимают создание макета, нарезка HTML, написание кода на JS и кода функционала бэкенда, локализация, тестирование и т.д.
Описание SCGI в вики занимает страницу текста, чтобы с ней разобраться, достаточно 10 минут. Час-полтора — написать реализацию. После написания и отладки эту инфу можно навсегда выбросить из головы.
Для изучения языка программирования нужно гораздо больше времени. И гораздо больше "памяти" в голове, чтобы запомнить основные стандартные функции.
Что касается PHP, то я его в принципе не рассматривал из-за его репутации. Может быть в современном PHP всё не так, как было раньше, но в памяти отложилось, что с PHP лучше не связываться, т.к. на каждом шагу — то выстрел в ногу, то уязвимость.
В принципе любой интерпретируемый язык, в котором есть eval() — это пороховая бочка.
В логике генерации запроса есть смысл, если есть множество однотипных запросов. Например, у меня есть много однотипных SELECT'ов — для них написаны обобщённые методы. А если запрос уникальный или их пара штук, то замена их на генератор выглядит как создание избыточного уровня абстракции. Это снижает понятность кода: когда видишь "UPDATE xxx WHERE yyy" — сразу понятно что это и как работает, потому что это SQL. А когда видишь this->update('xxx','yyy') — уже не очень понятно, потому что это придуманный кем-то интерфейс, у которого неизвестно что под капотом.
А что касается фреймворков, которые не допиливают: наверно их бы просто не было в таком количестве, если бы их создатели руководствовались принципом: "Зачем писать, лучше взять уже готовое".
Так я в статье как-раз и привел пример "Hello World" на SCGI.
Стандартного менеджера пакетов к сожалению нет — imho это серьёзная проблема, возникшая из-за исторически сложившейся дистрибуции бинарных пакетов.
Сейчас в Delphi есть GetIt Package Manager, но там ловить в общем-то нечего — все классные библиотеки нужно искать на сайтах.
Я с вами совершенно согласен, что для бизнеса по созданию сайтов, паскаль — очень плохой вариант. Это очевидно. Но если это бизнес, использующий Delphi в основной своей деятельности, и у этого бизнеса появилась побочная задача сделать себе сайт и поддерживать его, то не исключена ситуация, когда окажется выгоднее не нанимать для этого отдельного веб-разработчика, а справиться своими силами.
Вы про версию FPC или Лазаруса?
Сайт FPC гласит: "The latest release is 3.0.4." (ноябрь 2017).
Сайт Лазаруса: 2.0.6 — ноябрь 2019, на базе FPC 3.0.4.
Связываться с версиями, которые в разработке — ну, такое… По-моему проще взять Delphi.
К сожалению, чудес не бывает: если нужна определенная логика — её нужно где-то написать. За исключением фантастического случая, когда готовое решение реализует на 100% то, что нужно. Вопрос лишь в том, что выгодней: допиливать чужое решение под свои условия, или реализовать своё. Выбор не всегда очевиден.
То есть на официальном сайте Lazarus — неправильная версия? Ну Ok.
Вообще я в курсе, что в инете есть допиленные версии Лазаруса, но сам факт того, что такие версии нужно где-то искать, вместо того, чтобы взять на официальном сайте — уже о чём-то говорит!
Оно преобразуется в \", поскольку все строки, передаваемые в Query(), проходят обработку.
И в чём разница?
Для типичных запросов там есть QueryHash() и QueryValues() — это устраняет дублирование кода, но в целом его очень немного.
Для больших структур есть генератор кода для импорта/экспорта этих структур в БД, но в данном проекте это неактуально.
Дейстивтельно, какая куча ошибок? Как-раз таки куча ошибок возникла бы начни я писать всё это на каком-нибудь PHP-фреймворке. Из-за незнания особенностей языка, фреймворка, незнакомых и непривычных инструментов разработки и отладки.
Собственно, достаточно взглянуть на JS-код этого же сайта, чтобы понять, как мог бы выглядеть код сайта на PHP :-) ПРи том, что JS для меня не такой уж незнакомый, ведь я использую его для фронтенда сайтов достаточно давно.
Community Edition бесплатный, а если доход >$5K, то можно и раскошелиться на лицензию. Я слышал много нытья от разных людей про дороговизну лицензии, но серьёзно — на фоне burn rate программиста это не такая уж значительная сумма. Хотя я, конечно, предпочёл бы чтобы он стоил дешевле. Тот же 3D Max стоит дороже, но им вовсю пользуются, несмотря на наличие бесплатного Blender'а.
У меня сайт и сами игры написаны вообще в Turbo Delphi Explorer, который бесплатный без ограничений по доходу.
"Без тени сомнений, не пряча лица — идти к своей цели дорогой бойца."
Сервер физический, 4 ядра, 4GB RAM. Сайт работает с 2 worker threads, так что полностью загрузить процессор не может.
Кстати, написать парсер (сервер) HTTP — задача не сложная и не дорогая даже без каких-либо библиотек. Протокол сложный в реализации на клиенте, а на сервере можно ограничиться весьма простой реализацией. У меня сервер игры как-раз работает как HTTP-сервер. А SCGI еще проще.
Сервер: Xeon 3430@2.4GHz
База: MySQL 5.1
Типичное время обработки запроса к главной странице — 50 мс (12 SQL-запросов).
В данном случае производительность упирается в БД, форматирование текста — это мизер. Если поставить задачу повысить производительность, то в первую очередь надо избавиться от лишних запросов к БД.
А сайт Унигуя сделан на Унигуе? ;)
Можно ссылку на документ?
Кэш валиден только для того конкретного пользователя, для которого этот ответ сформирован.
Но если контент статический, то действительно не вижу особой разницы между включением кэширования и рендером статической страницы.
Не знаю, не интересовался. Но в целом десктопный геймдев сейчас — это либо C++ (UE), либо Unity.