Спасибо, что поделился. Учтем ;)
В ближайшее время у нас выйдет статья о курсе, из которой ты узнаешь, почему мы делали так, а не иначе по многим пунктам. Не знаю точной даты, но если интересно — следи за обновлениями тут: https://www.facebook.com/WargamingMinsk/ Если после прочтения еще останутся вопросы — пиши, с удовольствием ответим.
Пока могу сразу сказать, что создавая курс, мы серьезно подошли к вопросу, изучили множество референсов и вариантов. И всегда выбирали оптимальные для реализации нашей цели — познакомить с основами геймдизайна максимально широкую аудиторию.
Хотя, конечно, никто не идеален. Многие вопросы, которые возникали по ходу курса, мы старались оперативно решать. Например, опубликовали список дополнительной литературы (если не видел, то он тут:
http://195601023.r.worldcdn.net/modules/1078/pdf/Literatura8i8poleznyie8ssyilki.pdf)
Привет! Расскажи, что именно тебе понравилось или не понравилось в курсе? Мы хотели бы и далее организовывать подобные курсы, поэтому мнение учеников очень важно для нас.
Правильно понимаю, что тебя не устроило количество пользователей, которые проверяли твое дз начиная со второго модуля?
Если хочешь почитать текст о Erlang, то обязательно глянь вот эту статью: https://habrahabr.ru/company/wargaming/blog/279621/
Но вообще мы бы рекомендовали посмотреть видео выступлений — они действительно интересные. А если будут вопросы — свяжемся со спикерами, зададим)
Мы (Wargaming) видим смысл в том, чтобы использовать эрланг для веба. При желании этот смысл можно посчитать в человекочасах разработки или деньгах. Один и тот же веб-сервис можно построить на Python, а можно на Erlang. И после определенного уровня нагрузки, которую должен держать сервис, второй вариант выходит дешевле в человекочасах и деньгах.
У нас часто бывают вакансии для Erlang-разработчиков) Можете мониторить http://wargaming.com/ru/careers/vacancies/ или отправить ссылку на резюме/резюме в личку. Добавим в базу, если будут подходящие места — свяжемся.
В языках Python/Ruby/PHP обработчик http-запроса имеет свою область памяти, которая актуальна только на время обработки запроса. Если нужно хранить какие-то данные между запросами, то приходится обращаться к внешним сервисам, таким как Radis.
В Erlang обработчику доступна вся память узла (не напрямую, конечно), и хранилище данных можно организовать прямо внутри сервиса. Например, с помощью ets-таблиц.
С Haskell многие из нас знакомы, но как язык для разработки веб-сервисов мы его не рассматриваем. Основная причина — нет накопленного индустрией опыта разработки и поддержки крупных веб-проектов. Ну например, в 19:05 внезапно на 200% выросло время ответа сервиса на http-запросы клиентов. Что делать, как с этим разбираться? С Erlang и Python мы знаем что делать, а с Haskell нет.
Опытом делиться будем. Не обещаю, что прям завтра и начнем, но будем.
"Проблема именования переменных" — тут надо бы на конкретных примерах. И тогда будет ясно, кто виноват, язык или разработчик )
Вопрос больше касается чистых функциональных языков, например Haskell. А про Haskell рассказать кратко я не могу)
Что касается Erlang, то в нем можно (и нужно) делать грязные функции, и с вводом-выводом никаких сложностей нет. Для хранения состояния — gen_server. Ну а в целом применение Erlang на практике хорошо изложено в книге Фреда Хеберта Learn you some Erlang. Ну и в моем учебном курсе тоже :)
Это в значительной мере дело вкуса. Но кое-где есть объективные проблемы. Например, некоторым новичкам требуются значительные усилия, чтобы разобраться, где ставить точку, где точку с запятой, а где просто запятую. Достаточно понаблюдать немного за тем, как пишут код новички, чтобы понять, что проблема есть)
Увы, мы не знаем никого, кто использует Chicago Boss. В этом отношении даже Elixir/Phoenix лучше. Ибо есть разработчики = есть у кого попросить о помощи в случае проблем.
Та или иная парадигма сама по себе не защищает от плохого кода. И тут дело не в парадигме, а в том, что это редко используемая технология. Значит, ей интересуются любопытные разработчики, а нелюбопытные игнорируют.
Вообще любопытство разработчика хорошо коррелирует с его способностью писать хороший код :)
Основная миссия WG Labs – это поиск новых интересных проектов со сторонними разработчиками для дальнейшего сотрудничества. С помощью конкурса, во-первых, мы хотим привлечь внимание к нашему направлению, а во-вторых — воодушевить молодые и амбициозные команды двигаться вперед и не бояться посмотреть на игровую индустрию с другой стороны.
Отладка правил происходит после их введения в препродакшене, уже на реальных данных. Валидность оценивается по откликам, срабатыванию и т. п. Поэтому в нашем случае главное четко понимать какова цель введения того или иного правила.
В ближайшее время у нас выйдет статья о курсе, из которой ты узнаешь, почему мы делали так, а не иначе по многим пунктам. Не знаю точной даты, но если интересно — следи за обновлениями тут: https://www.facebook.com/WargamingMinsk/ Если после прочтения еще останутся вопросы — пиши, с удовольствием ответим.
Пока могу сразу сказать, что создавая курс, мы серьезно подошли к вопросу, изучили множество референсов и вариантов. И всегда выбирали оптимальные для реализации нашей цели — познакомить с основами геймдизайна максимально широкую аудиторию.
Хотя, конечно, никто не идеален. Многие вопросы, которые возникали по ходу курса, мы старались оперативно решать. Например, опубликовали список дополнительной литературы (если не видел, то он тут:
http://195601023.r.worldcdn.net/modules/1078/pdf/Literatura8i8poleznyie8ssyilki.pdf)
И еще раз спасибо, что поделился)
Правильно понимаю, что тебя не устроило количество пользователей, которые проверяли твое дз начиная со второго модуля?
Но вообще мы бы рекомендовали посмотреть видео выступлений — они действительно интересные. А если будут вопросы — свяжемся со спикерами, зададим)
Мы (Wargaming) видим смысл в том, чтобы использовать эрланг для веба. При желании этот смысл можно посчитать в человекочасах разработки или деньгах. Один и тот же веб-сервис можно построить на Python, а можно на Erlang. И после определенного уровня нагрузки, которую должен держать сервис, второй вариант выходит дешевле в человекочасах и деньгах.
В Erlang обработчику доступна вся память узла (не напрямую, конечно), и хранилище данных можно организовать прямо внутри сервиса. Например, с помощью ets-таблиц.
Посмотрите здесь https://ru.hexlet.io/courses/erlang_101/lessons/practical_erlang_gen_server/theory_unit
"Проблема именования переменных" — тут надо бы на конкретных примерах. И тогда будет ясно, кто виноват, язык или разработчик )
Что касается Erlang, то в нем можно (и нужно) делать грязные функции, и с вводом-выводом никаких сложностей нет. Для хранения состояния — gen_server. Ну а в целом применение Erlang на практике хорошо изложено в книге Фреда Хеберта Learn you some Erlang. Ну и в моем учебном курсе тоже :)
Увы, мы не знаем никого, кто использует Chicago Boss. В этом отношении даже Elixir/Phoenix лучше. Ибо есть разработчики = есть у кого попросить о помощи в случае проблем.
Вообще любопытство разработчика хорошо коррелирует с его способностью писать хороший код :)