Я с вами совершенно согласен, что для бизнеса по созданию сайтов, паскаль — очень плохой вариант. Это очевидно. Но если это бизнес, использующий 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-запросов).
В данном случае производительность упирается в БД, форматирование текста — это мизер. Если поставить задачу повысить производительность, то в первую очередь надо избавиться от лишних запросов к БД.
Дело и в поддержке, и в преемственности, и в опыте: куда как проще писать новую игру на хорошо знакомом языке, на своём движке. Чем с нуля начинать на Unity и C#. Путь наименьшего сопротивления. Хотя с точки зрения востребованности на трудовом рынке, это, конечно, большой минус.
Я с вами совершенно согласен, что для бизнеса по созданию сайтов, паскаль — очень плохой вариант. Это очевидно. Но если это бизнес, использующий 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.
Несколько лет назад была возможность поработать на lua, но предпочёл Java. Писать на Java в Idea — одно удовольствие :)
Дело и в поддержке, и в преемственности, и в опыте: куда как проще писать новую игру на хорошо знакомом языке, на своём движке. Чем с нуля начинать на Unity и C#. Путь наименьшего сопротивления. Хотя с точки зрения востребованности на трудовом рынке, это, конечно, большой минус.
Профессионал — это когда есть результат: задачи закрыты, оплата получена.
Выложите код, напишите статью о том, как пишете вы — будет интересно посмотреть! :)