Гитхаб-счастье!
#лайт
Горячо любимый мною Microsoft, взявший в последние годы курс на опенсорс, продолжает меня радовать. Не так давно они возглавили крупнейший вэб-хостинг опенсорс-проектов GitHub, и на днях провели в нём первую крупную реформу: сменили тарифные планы.
Главное изменение касается бесплатных аккаунтов. Если раньше бесплатно можно было вести только публичные репозитории, то теперь можно создавать неограниченное количество приватных проектов до 3 пользователей. Напомню, что GitHub, в отличие от большинства аналогов, никак не ограничивает дисковое пространство, так что количество пользователей — это единственное условие. А трёх пользователей зачастую достаточно для современных инди-команд.
Конечно, приватные репозитории можно было заводить бесплатно и до этого на том же BitBucket, причём аж до 5 пользователей; но нововведение от GitHub — это счастье, прежде всего, для одиночек. Просто если вы программист и занимались когда-нибудь опенсорс разработкой, то у вас уже есть аккаунт и репозитории на GitHub. Если теперь вы решите пилить что-то коммерческое для себя, то вам не надо никуда ходить, можно завести приватный репозиторий здесь же. И даже можно в случае чего подключить к проекту художника или второго программиста.
Кстати, мало кто знает, но публичный репозиторий не означает, что проект опенсорный. Вам никто не мешает положить в репозиторий свою проприетарную лицензию. Более того, отсутствие какой-либо лицензии (что встречается повсеместно на гитхаб) по умолчанию оставляет все права на код за автором. Такой код можно просматривать, но нельзя копировать или перепродавать. Так что те, кто не боялся, что его код украдут, могли спокойно вести коммерческую разработку на гитхаб и до этого. Как, например, делал я. Между прочим, всем рекомендую завести публичные репозитории. Это отличное упражнение, позволяющее в короткие сроки избавиться от комплекса «здесь не прибрано», когда люди стесняются показывать неидеальный код, и в итоге вообще ничего никому не показывают.
А на картинке сверху моя плюшевая игрушка в виде маскота Github. Да, у меня и такая есть. Правда милота?
Обсудить
#лайт
Горячо любимый мною Microsoft, взявший в последние годы курс на опенсорс, продолжает меня радовать. Не так давно они возглавили крупнейший вэб-хостинг опенсорс-проектов GitHub, и на днях провели в нём первую крупную реформу: сменили тарифные планы.
Главное изменение касается бесплатных аккаунтов. Если раньше бесплатно можно было вести только публичные репозитории, то теперь можно создавать неограниченное количество приватных проектов до 3 пользователей. Напомню, что GitHub, в отличие от большинства аналогов, никак не ограничивает дисковое пространство, так что количество пользователей — это единственное условие. А трёх пользователей зачастую достаточно для современных инди-команд.
Конечно, приватные репозитории можно было заводить бесплатно и до этого на том же BitBucket, причём аж до 5 пользователей; но нововведение от GitHub — это счастье, прежде всего, для одиночек. Просто если вы программист и занимались когда-нибудь опенсорс разработкой, то у вас уже есть аккаунт и репозитории на GitHub. Если теперь вы решите пилить что-то коммерческое для себя, то вам не надо никуда ходить, можно завести приватный репозиторий здесь же. И даже можно в случае чего подключить к проекту художника или второго программиста.
Кстати, мало кто знает, но публичный репозиторий не означает, что проект опенсорный. Вам никто не мешает положить в репозиторий свою проприетарную лицензию. Более того, отсутствие какой-либо лицензии (что встречается повсеместно на гитхаб) по умолчанию оставляет все права на код за автором. Такой код можно просматривать, но нельзя копировать или перепродавать. Так что те, кто не боялся, что его код украдут, могли спокойно вести коммерческую разработку на гитхаб и до этого. Как, например, делал я. Между прочим, всем рекомендую завести публичные репозитории. Это отличное упражнение, позволяющее в короткие сроки избавиться от комплекса «здесь не прибрано», когда люди стесняются показывать неидеальный код, и в итоге вообще ничего никому не показывают.
А на картинке сверху моя плюшевая игрушка в виде маскота Github. Да, у меня и такая есть. Правда милота?
Обсудить
О трамвайчиках
#лайт
Давайте отдохнём немного от программирования и поговорим про трамвайчики. Все же любят поезда, да? Я решил побыть сегодня Ильёй Варламовым и поделиться путевыми наблюдениями об урбанистике.
Наверное, такое решение для трамвайных путей много, где встречается, но я увидел впервые в Касабланке. Здесь для трамваев проложены отдельные дороги, по которым машины не ездят. Не полосы, а именно отдельные дороги: даже если трамвайная и автомобильная дороги идут параллельно, они обязательно разделяются тротуаром, бордюром или посадкой деревьев. А вот трамвайная дорога от пешеходной зоны бордюром не отделяется!
Ограждения попросту не нужны, поскольку машин на этой дороге нет, а трамвай с рельс сойти не может. Для людей же получается огромный пешеходный проспект, который одинаково просто пересекать, как на своих двоих, так и на инвалидной коляске или велике. Да, велосипедисты используют трамвайные пути, как одну большую велодорожку, потому что почему бы и нет? Пешеходы, конечно, гуляют не по рельсам, а по тротуару, но если сравнивать с обычными улицами, то гораздо приятнее идти по визуально широкому проспекту, где или нет машин вовсе, или они спрятаны за полосой деревьев. Ни шума, ни выхлопных газов, хороший обзор на архитектуру и ощущение простора. Изредка проезжающие стильные трамваи на электротяге совсем не портят картину и не раздражают. Движутся они не очень быстро и уступают пешеходам. Словом, кайфово.
Вот такая заметка получилась. Немножко не формат, но больше такого можно читать у меня в твиттере. Там я, конечно, в основном просто старчески ворчу на всех и вся, но иногда и что-то интересное бывает. Ну и чатик как всегда работает.
#лайт
Давайте отдохнём немного от программирования и поговорим про трамвайчики. Все же любят поезда, да? Я решил побыть сегодня Ильёй Варламовым и поделиться путевыми наблюдениями об урбанистике.
Наверное, такое решение для трамвайных путей много, где встречается, но я увидел впервые в Касабланке. Здесь для трамваев проложены отдельные дороги, по которым машины не ездят. Не полосы, а именно отдельные дороги: даже если трамвайная и автомобильная дороги идут параллельно, они обязательно разделяются тротуаром, бордюром или посадкой деревьев. А вот трамвайная дорога от пешеходной зоны бордюром не отделяется!
Ограждения попросту не нужны, поскольку машин на этой дороге нет, а трамвай с рельс сойти не может. Для людей же получается огромный пешеходный проспект, который одинаково просто пересекать, как на своих двоих, так и на инвалидной коляске или велике. Да, велосипедисты используют трамвайные пути, как одну большую велодорожку, потому что почему бы и нет? Пешеходы, конечно, гуляют не по рельсам, а по тротуару, но если сравнивать с обычными улицами, то гораздо приятнее идти по визуально широкому проспекту, где или нет машин вовсе, или они спрятаны за полосой деревьев. Ни шума, ни выхлопных газов, хороший обзор на архитектуру и ощущение простора. Изредка проезжающие стильные трамваи на электротяге совсем не портят картину и не раздражают. Движутся они не очень быстро и уступают пешеходам. Словом, кайфово.
Вот такая заметка получилась. Немножко не формат, но больше такого можно читать у меня в твиттере. Там я, конечно, в основном просто старчески ворчу на всех и вся, но иногда и что-то интересное бывает. Ну и чатик как всегда работает.
Подробности про командную строку
#код
Запилил на днях по работе командную строку с проверкой синтаксиса и автодополнением и похвастался этим в чатике. Народ проявил интерес и поэтому рассказываю подробнее.
Нужна эта штука для двух вещей. Во-первых, сценаристы, собирающие диалоги в редакторе, должны иметь возможность проверять доступность вариантов ответа (например, реплика возможна только при заданном уровне интеллекта или после выполнения квеста), а также вызывать скрипты при ответах. Во-вторых, для разработки нужна классическая игровая консоль для ввода читов и отладки. Чтобы разом покрыть оба этих юзкейса нужно написать нехитрый интерпретатор строки. Разумеется, он не будет поддерживать все фишки C#, а только некоторый базовый сабсет, вроде функций, операторов и скобочек.
Теперь о реализации. Несмотря на кажущуюся сложность задачи, имплементация у меня до боли простая и занимает чуть более тысячи строк. Первый элемент системы — это, конечно, лексический анализатор. Который у меня в коде какого-то фига называется Parser (надо не забыть переименовать в Lexer, а то чё я, как наркоман). Лексер представляет собой одну единственную функцию-генератор, которая в цикле читает символы строки и возвращает по одной токены лексем, которыми могут быть:
Между лексемами могут быть пробелы, они игнорируются. Помимо типа, токен также хранит начало и длину фрагмента внутри входной строки (чтобы подсветить красным место, в котором произошла ошибка) и поле типа object для дополнительной информации: для value это считанное значение, для оператора — информация о том, какой конкретно оператор и т.п. Единственный нюанс, при чтении знака минус, нужно взглянуть на то, какой токен был перед этим: если значение, идентификатор или закрывающая скобка, то это оператор минус, в противном случае начало отрицательного числа.
Едем дальше. Непосредственно сам интерпретатор совмещённый с валидатором. Он у меня однопроходный, то есть я читаю очередь лексем слева направо и сразу же выполняю. Командная строка может выполнять только выражения. Выражение — это один или несколько операндов, разделённых операторами. Например,
или просто
Когда мы дошли до конца выражения (конец строки, запятая или закрывающая скобка), мы выполняем операторы в порядке их приоритета («схлопываем» по два операнда, пока не останется только один).
Операндом может выступать как значение, так и другое выражение в скобках. Поэтому если наткнёмся на открывающуюся скобку, то просто запускаем процесс парсинга вложенного выражения рекурсивно. И также операндом может выступать цепочка идентификаторов, типа такой:
В данном случае мы тоже выполняем всё последовательно. Сначала ищем объект среди глобальных. У меня разрешены только классы скриптов (считай, синглтоны) и enum’ы. Затем на каждый доступ через точку достаём через рефлекшн соответствующий member класса, а при вызове функции запускаем сперва вложенный парсинг выражений-аргументов через запятую.
Собственно, всё. Ну ещё есть оператор присваивания, который умеет вызывать сеттер для поля или свойства, но теперь точно всё.
Валидация происходит точно также, как и выполнение, только в «холостом» режиме: вместо честных вызовов функций и операторов, мы возвращаем объект-заглушку, которая знает какого типа должен быть результат. Этой информации достаточно, чтобы проверить весь синтаксис.
Автодополнение же сделано запуском валидации строки, в которую в определённом месте вставлен символ многоточие. При разборе
лексер вернёт не идентификатор «Pl», а специальную лексему типа Autocomplete «Pl...». Ну а синтаксический анализатор, если наткнётся на эту лексему там, где предполагается идентификатор, посмотрит, какие вообще есть варианты, и если что-то подходит, то бросит AutoCompleteException, содержащий остаток строки. Заменой выделенного текста на автодополненный вариант занимается уже гуишный контрол наверху.
#код
Запилил на днях по работе командную строку с проверкой синтаксиса и автодополнением и похвастался этим в чатике. Народ проявил интерес и поэтому рассказываю подробнее.
Нужна эта штука для двух вещей. Во-первых, сценаристы, собирающие диалоги в редакторе, должны иметь возможность проверять доступность вариантов ответа (например, реплика возможна только при заданном уровне интеллекта или после выполнения квеста), а также вызывать скрипты при ответах. Во-вторых, для разработки нужна классическая игровая консоль для ввода читов и отладки. Чтобы разом покрыть оба этих юзкейса нужно написать нехитрый интерпретатор строки. Разумеется, он не будет поддерживать все фишки C#, а только некоторый базовый сабсет, вроде функций, операторов и скобочек.
Теперь о реализации. Несмотря на кажущуюся сложность задачи, имплементация у меня до боли простая и занимает чуть более тысячи строк. Первый элемент системы — это, конечно, лексический анализатор. Который у меня в коде какого-то фига называется Parser (надо не забыть переименовать в Lexer, а то чё я, как наркоман). Лексер представляет собой одну единственную функцию-генератор, которая в цикле читает символы строки и возвращает по одной токены лексем, которыми могут быть:
Value (строки, числа, true и false),
Identifier,
Dot,
Comma,
OpenBracket,
ClosedBracket,
Operator,
AssignmentOperator,
EndOfLine
Между лексемами могут быть пробелы, они игнорируются. Помимо типа, токен также хранит начало и длину фрагмента внутри входной строки (чтобы подсветить красным место, в котором произошла ошибка) и поле типа object для дополнительной информации: для value это считанное значение, для оператора — информация о том, какой конкретно оператор и т.п. Единственный нюанс, при чтении знака минус, нужно взглянуть на то, какой токен был перед этим: если значение, идентификатор или закрывающая скобка, то это оператор минус, в противном случае начало отрицательного числа.
Едем дальше. Непосредственно сам интерпретатор совмещённый с валидатором. Он у меня однопроходный, то есть я читаю очередь лексем слева направо и сразу же выполняю. Командная строка может выполнять только выражения. Выражение — это один или несколько операндов, разделённых операторами. Например,
a + b * c + d
или просто
a
Когда мы дошли до конца выражения (конец строки, запятая или закрывающая скобка), мы выполняем операторы в порядке их приоритета («схлопываем» по два операнда, пока не останется только один).
Операндом может выступать как значение, так и другое выражение в скобках. Поэтому если наткнёмся на открывающуюся скобку, то просто запускаем процесс парсинга вложенного выражения рекурсивно. И также операндом может выступать цепочка идентификаторов, типа такой:
Foo.bar.foo(a + b, c).foo.bar
В данном случае мы тоже выполняем всё последовательно. Сначала ищем объект среди глобальных. У меня разрешены только классы скриптов (считай, синглтоны) и enum’ы. Затем на каждый доступ через точку достаём через рефлекшн соответствующий member класса, а при вызове функции запускаем сперва вложенный парсинг выражений-аргументов через запятую.
Собственно, всё. Ну ещё есть оператор присваивания, который умеет вызывать сеттер для поля или свойства, но теперь точно всё.
Валидация происходит точно также, как и выполнение, только в «холостом» режиме: вместо честных вызовов функций и операторов, мы возвращаем объект-заглушку, которая знает какого типа должен быть результат. Этой информации достаточно, чтобы проверить весь синтаксис.
Автодополнение же сделано запуском валидации строки, в которую в определённом месте вставлен символ многоточие. При разборе
GlobalVars.Pl…
лексер вернёт не идентификатор «Pl», а специальную лексему типа Autocomplete «Pl...». Ну а синтаксический анализатор, если наткнётся на эту лексему там, где предполагается идентификатор, посмотрит, какие вообще есть варианты, и если что-то подходит, то бросит AutoCompleteException, содержащий остаток строки. Заменой выделенного текста на автодополненный вариант занимается уже гуишный контрол наверху.
Курсы геймдизайна
#реклама
Знаете, чем занятия с живым человеком лучше самостоятельных? Помогает соблюдать регулярность и систематичность. Я вот перед новым годом писал, что занимаюсь английским с преподователем через вэбку и также собираюсь изучать темы по списку ключевых слов Андрея Аксёнова. И знаете что? По английскому у меня есть заметный прогресс, а ключевые слова я всё ещё собираюсь начать изучать.
И поэтому я не устану рекламировать курсы по геймдизайну от Skillfactory. Это отличный вариант для тех, кто всё собирается вкатиться в отрасль, но либо руки не доходят усесться плотно, либо не хватает систематизации. На этих курсах лид дизайнер финской BON Games объяснит и поможет вам пройти через все этапы геймдизайна: от разработки игровой мехаики до монетизации и планирования. Регулярные занятия каждую неделю в сочетании с активным участием класса и фидбеком от преподователя не дадут сбиться с ритма на протяжении всех 4 месяцев. А стартует всё это уже 11 февраля, так что записывайся сейчас: https://goo.gl/FGC6wS
#реклама
Знаете, чем занятия с живым человеком лучше самостоятельных? Помогает соблюдать регулярность и систематичность. Я вот перед новым годом писал, что занимаюсь английским с преподователем через вэбку и также собираюсь изучать темы по списку ключевых слов Андрея Аксёнова. И знаете что? По английскому у меня есть заметный прогресс, а ключевые слова я всё ещё собираюсь начать изучать.
И поэтому я не устану рекламировать курсы по геймдизайну от Skillfactory. Это отличный вариант для тех, кто всё собирается вкатиться в отрасль, но либо руки не доходят усесться плотно, либо не хватает систематизации. На этих курсах лид дизайнер финской BON Games объяснит и поможет вам пройти через все этапы геймдизайна: от разработки игровой мехаики до монетизации и планирования. Регулярные занятия каждую неделю в сочетании с активным участием класса и фидбеком от преподователя не дадут сбиться с ритма на протяжении всех 4 месяцев. А стартует всё это уже 11 февраля, так что записывайся сейчас: https://goo.gl/FGC6wS
SOLIDные рассуждения
#код
Месяц назад я твитнул, что, дескать, как только слышу от соискателя или работодателя в геймдеве что-нибудь про SOLID, так сразу автоматически помечаю их в своей голове как нубов, либо поехавших. С тех пор мне пришлось пару раз подискутировать на эту тему в разных уголках интернета, и я решил, что стоит уже это оформить в отдельный пост.
Понятно, что это своего рода упрощение и навешивание ярлыков, которое отражает ситуацию лишь до определённой точности, но оно взято не из воздуха, а основывается на наблюдениях за реальным положением дел. И главный мой тезис в том, что в геймдеве на реальных проектах принципами SOLID никто никогда не руководствуется. Соответственно, если человек декларирует их своими ценностями, то он либо новичок в области, начитавшийся умных слов и книжек, но ещё не нюхавший пороху как следует на практике; либо же, мягко говоря, довольно неординарный геймдевелопер. То есть наглухо поехавший с моей точки зрения.
Поехавшие, в свою очередь, делятся, на две основные категории. Первые — это люди, пришедшие из энтерпрайза. Я никогда в энтерпрайзе не работал, но похоже, что там написание абстрактного кода эволюционно более привлекательная стратегия. Я ничего против этого не имею, но когда эти люди приходят в геймдев, с ними бывает тяжело сработаться, так как это зачастую сплошное ООП головного мозга. Там, где типичный программист из кровавого энтерпрайза в рубашке с длинными рукавами заведёт десять интерфейсов и фабрику фабрик; типичный геймдевелопер в перепачканной пиццой футболке вооружится принципами KISS и YAGNI и удалит это всё нахрен, написав взамен простой и понятный класс, решающий конкретную задачу. Пусть и наплевав при этом на принцип открытости/закрытости, разделения интерфейсов и другие святая святых ООП. То есть, конечно, наверняка где-то в природе существуют игры, написанные полностью по канонам SOLID. Но, во-первых, я такого не встречал, а во-вторых, боюсь представить, что там за монструозная кодобаза, и не считаю это нормальным.
Вторая важная категория «поехавших», которую хотелось бы разобрать — это люди, утверждающие, что применяют принципы SOLID, но на самом деле этого не делающие. Их аргументация обычно сводится к тому, что солид следует применять не по всему проекту, а лишь в тех местах, где он подходит. Но тут налицо непонимание разницы между паттерном и принципом. Солид это не паттерн, а принцип. Ты либо стараешься следовать ему везде, либо это уже не солид.
Поясню. Вот есть DRY. Очень простой принцип о том, что надо стараться избегать копипаста. Конечно, где-то в коде могут быть отступления от этого правила, но если человек исповедует dry, то в какой-то момент он может посмотреть на некий участок кода, решить, что он недостаточно dry, и переписать его менее влажно. Не потому, что этот участок кода работал плохо, а только лишь потому, что он не соответствует принципам, по которым мы решили писать код. И это действительно происходит в реальных проектах. То же касается KISS и YAGNI. Но не SOLID. Не бывает такого, что чувак в геймдеве смотрит на код, и решает, что дай-ка я его перепишу, потому что он какой-то недостаточно солидный. Ну не бывает такого на практике. А если ты так не делаешь, значит, ты и не следуешь этому принципу. У тебя просто в случайных местах код написан в соответствии с его правилами, но ты ими на самом деле не руководствовался.
Вот так и получается, что если кто-то в геймдеве на полном серьёзе топит за SOLID, то для меня это или нуб или поехавший.
Обсудить
#код
Месяц назад я твитнул, что, дескать, как только слышу от соискателя или работодателя в геймдеве что-нибудь про SOLID, так сразу автоматически помечаю их в своей голове как нубов, либо поехавших. С тех пор мне пришлось пару раз подискутировать на эту тему в разных уголках интернета, и я решил, что стоит уже это оформить в отдельный пост.
Понятно, что это своего рода упрощение и навешивание ярлыков, которое отражает ситуацию лишь до определённой точности, но оно взято не из воздуха, а основывается на наблюдениях за реальным положением дел. И главный мой тезис в том, что в геймдеве на реальных проектах принципами SOLID никто никогда не руководствуется. Соответственно, если человек декларирует их своими ценностями, то он либо новичок в области, начитавшийся умных слов и книжек, но ещё не нюхавший пороху как следует на практике; либо же, мягко говоря, довольно неординарный геймдевелопер. То есть наглухо поехавший с моей точки зрения.
Поехавшие, в свою очередь, делятся, на две основные категории. Первые — это люди, пришедшие из энтерпрайза. Я никогда в энтерпрайзе не работал, но похоже, что там написание абстрактного кода эволюционно более привлекательная стратегия. Я ничего против этого не имею, но когда эти люди приходят в геймдев, с ними бывает тяжело сработаться, так как это зачастую сплошное ООП головного мозга. Там, где типичный программист из кровавого энтерпрайза в рубашке с длинными рукавами заведёт десять интерфейсов и фабрику фабрик; типичный геймдевелопер в перепачканной пиццой футболке вооружится принципами KISS и YAGNI и удалит это всё нахрен, написав взамен простой и понятный класс, решающий конкретную задачу. Пусть и наплевав при этом на принцип открытости/закрытости, разделения интерфейсов и другие святая святых ООП. То есть, конечно, наверняка где-то в природе существуют игры, написанные полностью по канонам SOLID. Но, во-первых, я такого не встречал, а во-вторых, боюсь представить, что там за монструозная кодобаза, и не считаю это нормальным.
Вторая важная категория «поехавших», которую хотелось бы разобрать — это люди, утверждающие, что применяют принципы SOLID, но на самом деле этого не делающие. Их аргументация обычно сводится к тому, что солид следует применять не по всему проекту, а лишь в тех местах, где он подходит. Но тут налицо непонимание разницы между паттерном и принципом. Солид это не паттерн, а принцип. Ты либо стараешься следовать ему везде, либо это уже не солид.
Поясню. Вот есть DRY. Очень простой принцип о том, что надо стараться избегать копипаста. Конечно, где-то в коде могут быть отступления от этого правила, но если человек исповедует dry, то в какой-то момент он может посмотреть на некий участок кода, решить, что он недостаточно dry, и переписать его менее влажно. Не потому, что этот участок кода работал плохо, а только лишь потому, что он не соответствует принципам, по которым мы решили писать код. И это действительно происходит в реальных проектах. То же касается KISS и YAGNI. Но не SOLID. Не бывает такого, что чувак в геймдеве смотрит на код, и решает, что дай-ка я его перепишу, потому что он какой-то недостаточно солидный. Ну не бывает такого на практике. А если ты так не делаешь, значит, ты и не следуешь этому принципу. У тебя просто в случайных местах код написан в соответствии с его правилами, но ты ими на самом деле не руководствовался.
Вот так и получается, что если кто-то в геймдеве на полном серьёзе топит за SOLID, то для меня это или нуб или поехавший.
Обсудить
Исходники командной строки
#код
Удивительное дело, но моего недавнего поста про командную строку в нашем проекте оказалось недостаточно, чтобы утолить к ней интерес. Народ продолжил требовать запилить ассет. С ассет стором я, конечно же, возиться не стал, но код, так уж и быть, заопенсорсил.
Код не идеальный. Например, он много мелочи аллочит, чего по идее можно было бы избежать (впрочем, задачи такой не стояло, так как командная строка не каждый кадр выполняется). Тем не менее, это вполне боевой код. В нашем проекте он почти в таком виде и существует. Я вычистил кое-какие зависимости от Encased, чутка причесал и накатал минимальный пример использования. Если очень захотеть, то вполне можно заюзать это в своём проекте.
Обсудить
#код
Удивительное дело, но моего недавнего поста про командную строку в нашем проекте оказалось недостаточно, чтобы утолить к ней интерес. Народ продолжил требовать запилить ассет. С ассет стором я, конечно же, возиться не стал, но код, так уж и быть, заопенсорсил.
Код не идеальный. Например, он много мелочи аллочит, чего по идее можно было бы избежать (впрочем, задачи такой не стояло, так как командная строка не каждый кадр выполняется). Тем не менее, это вполне боевой код. В нашем проекте он почти в таком виде и существует. Я вычистил кое-какие зависимости от Encased, чутка причесал и накатал минимальный пример использования. Если очень захотеть, то вполне можно заюзать это в своём проекте.
Обсудить
Паровозик вакансий
#лайт
А мы расширяемся и у нас целая пачка открытых вакансий:
C#-программист (Middle)
3D Artist (Lead)
Quest Designer (Junior)
QA (Junior)
Напомню, что мы делаем Encased (RPG в духе первых FallOut) и расположены в Санкт-Петербурге. Все вакансии предполагают работу в офисе. Удалёнка в данном случае не проканает.
По непрограммерским вакансиям можете почитать инфу непосредственно по ссылкам (и, пожалуйста, не спрашивайте меня про них, пишите сразу на почту).
А вот по поводу C# мидла хотелось бы рассказать подробнее. Работать предстоит непосредственно под моим руководством, фигачить геймплей и тулзы для дизайнеров всех мастей. В основном в виде расширений для нашей модульной системы. Сейчас в команде три программиста (включая меня), ищем четвёртого. Рутинную часть кода пишем не мы, а дизайнеры-скриптеры. В задачи программистов входит написание удобного API для них. Иногда с кодогенерацией. В качестве VCS у нас Plastic (считайте, что это оказуаленный git). Юнит-тестов нет, билд-машина есть. Кодстайл можете глянуть в предыдущем посте.
Резюмехи присылайте на [email protected]. Желательно сразу с примерами кода. Организационные вопросы можно обсудить заранее, и если всё ок, то перспективным кандидатам мы предложим небольшое тестовое. Без тестового на эту позицию, скорее всего, не получится.
Обсудить
#лайт
А мы расширяемся и у нас целая пачка открытых вакансий:
C#-программист (Middle)
3D Artist (Lead)
Quest Designer (Junior)
QA (Junior)
Напомню, что мы делаем Encased (RPG в духе первых FallOut) и расположены в Санкт-Петербурге. Все вакансии предполагают работу в офисе. Удалёнка в данном случае не проканает.
По непрограммерским вакансиям можете почитать инфу непосредственно по ссылкам (и, пожалуйста, не спрашивайте меня про них, пишите сразу на почту).
А вот по поводу C# мидла хотелось бы рассказать подробнее. Работать предстоит непосредственно под моим руководством, фигачить геймплей и тулзы для дизайнеров всех мастей. В основном в виде расширений для нашей модульной системы. Сейчас в команде три программиста (включая меня), ищем четвёртого. Рутинную часть кода пишем не мы, а дизайнеры-скриптеры. В задачи программистов входит написание удобного API для них. Иногда с кодогенерацией. В качестве VCS у нас Plastic (считайте, что это оказуаленный git). Юнит-тестов нет, билд-машина есть. Кодстайл можете глянуть в предыдущем посте.
Резюмехи присылайте на [email protected]. Желательно сразу с примерами кода. Организационные вопросы можно обсудить заранее, и если всё ок, то перспективным кандидатам мы предложим небольшое тестовое. Без тестового на эту позицию, скорее всего, не получится.
Обсудить
Неотчёт о еврейском митапе
#лайт
Тусил я не так давно несколько недель в Израиле/Палестине, ну и забежал по случаю на местный митап-конфу в Тель Авиве. Он был посвящён прошедшему Global Game Jam, где начинающее бесполезное инди показывало свои конкурсные игры на проекторе и выбирало победителя. Ну а заодно в холле чуть более осмысленное инди устраивало шоукейс своих коммерческих проектов.
Обычно после таких мероприятий принято писать подробный фотоотчёт о том, в какие игры поиграл, с кем разговаривал и каких плюшек поел, но я таким страдать не буду. Если уж и писать что-то, то лучше поделиться своими мыслями, чем засыпать читателя тоннами ничего не значащих подробностей.
Несмотря на то, что это был мой первый митап за пределами постсоветского пространства, новая мысль у меня ровно одна: инди-геймдев везде одинаковый. Вот собранный из ассетов упоротый проект, совмещающий два несочетаемых жанра, и непонятно как финансируемый. Вот чуваки, делающие богомерзкие социалки с интерфейсом в стиле Angry Birds. А вот и хардкорный платформер с пикселями разного размера. Всё то же самое. Каждый типаж до боли знакомый и ты заранее знаешь, что он тебе скажет. Иногда даже прямо на русском. Израиль всё-таки.
Эмоции очень противоречивые вызывает такое сходство. С одной стороны, это грустные мысли. Но и объединяющие. Как-то по-грустному объединяющее. Куда ни поедь на земном шаре, везде одни и те же мечты, одна и та же боль.
А, ну ещё до этого был в Сенегале — там вообще нихрена нет.
Обсудить
#лайт
Тусил я не так давно несколько недель в Израиле/Палестине, ну и забежал по случаю на местный митап-конфу в Тель Авиве. Он был посвящён прошедшему Global Game Jam, где начинающее бесполезное инди показывало свои конкурсные игры на проекторе и выбирало победителя. Ну а заодно в холле чуть более осмысленное инди устраивало шоукейс своих коммерческих проектов.
Обычно после таких мероприятий принято писать подробный фотоотчёт о том, в какие игры поиграл, с кем разговаривал и каких плюшек поел, но я таким страдать не буду. Если уж и писать что-то, то лучше поделиться своими мыслями, чем засыпать читателя тоннами ничего не значащих подробностей.
Несмотря на то, что это был мой первый митап за пределами постсоветского пространства, новая мысль у меня ровно одна: инди-геймдев везде одинаковый. Вот собранный из ассетов упоротый проект, совмещающий два несочетаемых жанра, и непонятно как финансируемый. Вот чуваки, делающие богомерзкие социалки с интерфейсом в стиле Angry Birds. А вот и хардкорный платформер с пикселями разного размера. Всё то же самое. Каждый типаж до боли знакомый и ты заранее знаешь, что он тебе скажет. Иногда даже прямо на русском. Израиль всё-таки.
Эмоции очень противоречивые вызывает такое сходство. С одной стороны, это грустные мысли. Но и объединяющие. Как-то по-грустному объединяющее. Куда ни поедь на земном шаре, везде одни и те же мечты, одна и та же боль.
А, ну ещё до этого был в Сенегале — там вообще нихрена нет.
Обсудить
Курсы как строчка в портфолио
#реклама
Последняя остановка в моей заграничной зимовке была в Южной Корее, а по пути назад я залетел в город, в котором вырос — во Владивосток. Собрались там с друзьями и коллегами с моей первой работы поболтать в ресторане, ну и зашла речь о том, как же в 2019 году устроиться геймдизайнером к этим самым бывшим коллегам. Мол, человек даже курсы проходил по геймдизайну, о чём имеет сертификат, а устроиться не может, так как вакансий открытых на геймдизайнера нет. И прозвучала фраза о том, что аргумент «я проходил какие-то курсы по геймдизайну» уже достаточно сильный, чтобы заинтересоваться как минимум поговорить. И что с таким аргументом стоит писать, даже если открытых вакансий сейчас нет. А там уже тестовое задание и дальше как пойдёт. А вы спрашиваете, зачем нужны курсы геймдизайна?
Вот, например, курсы от Skillfactory, на которых вы:
- Напишете сценарий и разработаете механику своей игры;
- сделаете прототип интерфейса и продумаете персонажей;
- посчитаете экономику и спланируете продвижение;
- разработаете дизайн-документацию.
Получите программу курса → http://bit.ly/2NCxsuU
Обсудить
#реклама
Последняя остановка в моей заграничной зимовке была в Южной Корее, а по пути назад я залетел в город, в котором вырос — во Владивосток. Собрались там с друзьями и коллегами с моей первой работы поболтать в ресторане, ну и зашла речь о том, как же в 2019 году устроиться геймдизайнером к этим самым бывшим коллегам. Мол, человек даже курсы проходил по геймдизайну, о чём имеет сертификат, а устроиться не может, так как вакансий открытых на геймдизайнера нет. И прозвучала фраза о том, что аргумент «я проходил какие-то курсы по геймдизайну» уже достаточно сильный, чтобы заинтересоваться как минимум поговорить. И что с таким аргументом стоит писать, даже если открытых вакансий сейчас нет. А там уже тестовое задание и дальше как пойдёт. А вы спрашиваете, зачем нужны курсы геймдизайна?
Вот, например, курсы от Skillfactory, на которых вы:
- Напишете сценарий и разработаете механику своей игры;
- сделаете прототип интерфейса и продумаете персонажей;
- посчитаете экономику и спланируете продвижение;
- разработаете дизайн-документацию.
Получите программу курса → http://bit.ly/2NCxsuU
Обсудить
GoTo the Dark Side
#код
Сегодня чатик что-то беснуется по поводу использования goto. Орден джедаев не позволяет использовать этот оператор в личных целях, а я же призываю вас перейти на Тёмную сторону Силы.
Но обо всём по порядку. Мой преподаватель программирования на первом курсе университета говорила, что goto в рамках учебного курса применять нельзя, и что она не будет принимать лабораторные работы с ним. И это очень правильно: личинкам кодера нельзя давать в руки такой инструмент, иначе они обмажут им все стены. Чтобы стать хорошим программистом всё-таки нужно сперва научиться писать код без goto.
Проблема начинается в тот момент, когда забывают добавить волшебную фразу «в рамках учебного курса». Людям преподносят goto как абсолютное зло, которое нельзя допускать ни в коем случае. Это превращается в примитивную пропаганду и, судя по количеству приверженцев идеи, так происходит достаточно часто. Да простят меня читатели за то, что я сейчас сворую блок мыслей у Андрея Коняева, но всё дело в том, что пропаганда, какие хорошие практики она бы не пыталась прививать, всё равно остаётся пропагандой. И ничего путного из этого не получится. Пропаганда даёт человеку позицию, но не объясняет её; и на выходе мы получаем кучу людей, которые не способны ответить на вопрос, почему они делают то, что делают. Максимум, что мы услышим, это лозунги вида «goto — это зло», «goto ухудшает читабельность!». Любая попытка разобраться, а действительно ли пострадала, например, читабельность исходников lua из-за того, что там обработка ошибок происходит через goto, будет встречена лишь непониманием и хейтом: «А разве не очевидно? Тут же стоит goto. А это худшая практика из всех. Или ты чё, защитник goto?»
Вам может сейчас показаться, что я утрирую, а на самом деле ненависть к goto обоснована и никакого фанатизма нет, но давайте проанализируем. Вы без труда можете представить человека (а может сами им являетесь), который ненавидит всей душой goto, но при этом любит и обильно использует макросы. Но если вдуматься, негативные эффекты от злоупотребления этими вещами крайне схожи. В обоих случаях от одного использования не случится никакой катастрофы, и даже более того, этим можно сильно облегчить себе жизнь и повысить читабельность в конкретном месте. В обоих случаях, если не локализовать применение, можно нарваться на опасные сайд-эффекты. И в обоих случаях, если пихать повсеместно, проект очень быстро превращается в неуправляемую кашу. Но в первом случае человек борется до последнего против появления в проекте «вредного сорняка», а в другом смотрит сквозь пальцы: не, ну а чё такого? Макросы же не включены в расстрельный список — значит, можно обмазываться.
Переходите на Тёмную сторону Силы и начинайте использовать не хорошие или плохоие практики, а здравый смысл.
Обсудить
#код
Сегодня чатик что-то беснуется по поводу использования goto. Орден джедаев не позволяет использовать этот оператор в личных целях, а я же призываю вас перейти на Тёмную сторону Силы.
Но обо всём по порядку. Мой преподаватель программирования на первом курсе университета говорила, что goto в рамках учебного курса применять нельзя, и что она не будет принимать лабораторные работы с ним. И это очень правильно: личинкам кодера нельзя давать в руки такой инструмент, иначе они обмажут им все стены. Чтобы стать хорошим программистом всё-таки нужно сперва научиться писать код без goto.
Проблема начинается в тот момент, когда забывают добавить волшебную фразу «в рамках учебного курса». Людям преподносят goto как абсолютное зло, которое нельзя допускать ни в коем случае. Это превращается в примитивную пропаганду и, судя по количеству приверженцев идеи, так происходит достаточно часто. Да простят меня читатели за то, что я сейчас сворую блок мыслей у Андрея Коняева, но всё дело в том, что пропаганда, какие хорошие практики она бы не пыталась прививать, всё равно остаётся пропагандой. И ничего путного из этого не получится. Пропаганда даёт человеку позицию, но не объясняет её; и на выходе мы получаем кучу людей, которые не способны ответить на вопрос, почему они делают то, что делают. Максимум, что мы услышим, это лозунги вида «goto — это зло», «goto ухудшает читабельность!». Любая попытка разобраться, а действительно ли пострадала, например, читабельность исходников lua из-за того, что там обработка ошибок происходит через goto, будет встречена лишь непониманием и хейтом: «А разве не очевидно? Тут же стоит goto. А это худшая практика из всех. Или ты чё, защитник goto?»
Вам может сейчас показаться, что я утрирую, а на самом деле ненависть к goto обоснована и никакого фанатизма нет, но давайте проанализируем. Вы без труда можете представить человека (а может сами им являетесь), который ненавидит всей душой goto, но при этом любит и обильно использует макросы. Но если вдуматься, негативные эффекты от злоупотребления этими вещами крайне схожи. В обоих случаях от одного использования не случится никакой катастрофы, и даже более того, этим можно сильно облегчить себе жизнь и повысить читабельность в конкретном месте. В обоих случаях, если не локализовать применение, можно нарваться на опасные сайд-эффекты. И в обоих случаях, если пихать повсеместно, проект очень быстро превращается в неуправляемую кашу. Но в первом случае человек борется до последнего против появления в проекте «вредного сорняка», а в другом смотрит сквозь пальцы: не, ну а чё такого? Макросы же не включены в расстрельный список — значит, можно обмазываться.
Переходите на Тёмную сторону Силы и начинайте использовать не хорошие или плохоие практики, а здравый смысл.
Обсудить