Comments 20
TL;DR: мазохисты?
А как вы пишете тесты на эту логику?
Писать юнит-тесты для lua не сложнее, чем для cpp. Как по мне, даже проще.
lua-users.org/wiki/UnitTesting
lua-users.org/wiki/UnitTesting
Насколько сложно перейти на вашу версию LuaJIT с обычного Lua?
Просто перекомпилировать будет достаточно?
Просто перекомпилировать будет достаточно?
хм, не понял, а нафига LUA? есть же другие более удобные языки, а по быстродействию было ли сравнение с другими?
Удобство — понятие относительное. Луа изначально придумывалась как встраиваемый язык, поэтому делать любые сишные/плюсовые биндинги оказывается проще чем (почти) в чём угодно. Интеграция с уже существующей системой производится малой кровью, вплоть до выгрузки плюсовых объектов и использование их со скриптовой стороны практически аналогично плюсам. Такой глубины интеграции нет практически нигде. А инструментарий для бизнес-логики — или уже существует, или пишется за обозримые сроки. Ну и очень лёгкие корутины, приятный синтаксис (спорно, да) и всё такое. Скорость работы, для динамического языка (да ещё и с ffi/luajit) — очень хорошая, и не так много абстракций, чтобы они сильно протекали на разных платформах. Тут совокупность плюшек, а не какая-то конкретная киллер-фича.
Собственно, на вопрос уже ответили, но добавлю: мы используем Lua потому, что нас устраивает его производительность, скорость разработки на нем, скорость освоения технологии новичками. Иначе говоря, нас устраивает соотношение cost/benefit.
Подскажите, а как вы сопровождаете\поддерживаете все эти скрипты? У вас какая-то библиотека готовых «модулей»? Как происходит «миграция» бизнес логики, при изменении скриптов(к примеру, один из скриптов зависит от данных другого)?
Вы склонны писать большие бизнес сценарии и внутри их разбивать на ф-ии или же вы пишете больше отдельные скрипты?
Вы склонны писать большие бизнес сценарии и внутри их разбивать на ф-ии или же вы пишете больше отдельные скрипты?
В нашей команде более 40 разработчиков. Разумеется, есть библиотеки с готовыми модулями. Также в компании есть гайды по написанию и структурированию кода, позволяющие обеспечить легкую читаемость и дальнейшую поддержку кода.
Я работаю не в IPONWEB, но тоже пишу на луа в команде довольно приличные штуки, и в случае коллектива до 50 человек, вполне хватает гита. Есть протокол общения между подсистемами, есть модули верификации, мол «входные данные и выходные соответствуют стандарту», поэтому если кто-то от кого-то зависит — пока всё соответствует протоколу, оно будет нормально работать. А если зависимость именно от данных, то тут уже, как правило, договариваемся с человеком, занимающимся разработкой и поддержкой соседней подсистемы, мол «данные изменились, адаптируем», далее стыкуем обе части (опционально в git-flow фиче) и тестируем. Если обе части под твоей юрисдикцией, то всё проще: сам стыкуешь и тестируешь.
Отдельные модули сервисов или систем, как правило, являются наследниками абстрактного «класса сервиса», которые запускаются в таск-менеджере, который оперирует именно такими классами, соответственно для миграции модуля/сервиса обычно достаточно перенести класс и всю его вспомогательную требуху на другой кластер, и запустить, опционально указав в глобальной системной конфигурации, мол «а у нас вот тут появился новый сервис, и к нему можно обращаться по таким-то вопросам».
В общем-то ничем не отличается от разработки произвольной распределённой системы, всё примерно то же самое.
Отдельные модули сервисов или систем, как правило, являются наследниками абстрактного «класса сервиса», которые запускаются в таск-менеджере, который оперирует именно такими классами, соответственно для миграции модуля/сервиса обычно достаточно перенести класс и всю его вспомогательную требуху на другой кластер, и запустить, опционально указав в глобальной системной конфигурации, мол «а у нас вот тут появился новый сервис, и к нему можно обращаться по таким-то вопросам».
В общем-то ничем не отличается от разработки произвольной распределённой системы, всё примерно то же самое.
Возможна ли реализация на Lua back-end? Есть ли какие библиотеки для этого, типа Flask или Jinja2?
Да, возможна, OpenResty в помощь. Фреймворков не очень много, но есть, например Lapis (он на мунскрипте, это как тайпскрипт для жаваскрипта, только транслируется в луа перед исполнением), можно писать веб-часть на луа или мунскрипте на выбор, шаблонизаторы с драйверами до бд присутствуют.
Лично я предпочитаю катать полностью самописные велосипеды на OpenResty, но это уже мой персональный выбор для пет-проектов.
Лично я предпочитаю катать полностью самописные велосипеды на OpenResty, но это уже мой персональный выбор для пет-проектов.
Да, есть много web-фреймворков, можно использовать Lapis + OpenResty (работает через Nginx). Вот небольшой обзор: lua.space/webdev/the-best-lua-web-frameworks
Есть годный Luvit. Это как Node.js, только для Lua. Под капотом тот же libuv.
Действительно Lua классный ЯП. Например, игра сталкер, на нём значительная часть функционала реализовано. Конечно, это было сделано чтобы привлечь не слишком компетентных программистов, а значит дешёвых. Но как бы там ни было, Lua гораздо легче того же питона.
Встраиваемые языки встраивают не для того чтобы привлекать дешевых программистов, а потому что скриптовать игровую логику на тех же плюсах/си — это адок. Неудобно, громоздко, недружественно к непрограммистам (например геймдизайнерам, моддерам, и т.д.), и требует перекомпиляции на каждый чих. Скриптеры изначально есть в любой крупной геймдев команде, их не нужно привлекать на пол пути, и тем более не нужно называть их «не слишком компетентными». Кроме того, хоть какого-нибудь соискателя на Lua найти сложнее, чем дешевого на плюсах, просто потому что их намного, намного меньше. Из-за чего зачастую скриптерами выступают те же самые люди что пилят движковую часть.
Заметка хороша тем, что публично пишет то, что пишется в договорах — в случае факапа вы максимум получите стоимость услуг хостинга (а скорее меньше)
Поэтому, если владельца продукта волнует его SLA — он не должен полагаться на внешние SLA, а организовывать отказоустойчивость самостоятельно.
То есть договор не гарантирует SLA, но соблюдение SLA возможно, если выстроены процессы.
Поэтому, если владельца продукта волнует его SLA — он не должен полагаться на внешние SLA, а организовывать отказоустойчивость самостоятельно.
То есть договор не гарантирует SLA, но соблюдение SLA возможно, если выстроены процессы.
moderator коммент явно не к этой статье — удалите, пожалуйста.
Sign up to leave a comment.
Почему мы пишем бизнес-логику на Lua