Если вы знаете об этом сайте с момента его создания (то был июнь 2013), то видели предыдущие дизайны. Они варьировались по сложности, но в итоге их последовательность приблизительно описывает мой путь по полю front-end, полному обломков. На чём я остановился сейчас, вы видите перед глазами. Ну… на данный момент. К моменту прочтения этого материала кем-нибудь я уже в очередной раз могу всё переписать. Кто знает, если не знаю даже я?
Каково, просидев долгие годы на очень удобном конструкторе, сделав на нём несколько игрушек, взять “сырой игровой движок” и начать шаманить с ним? Ну… это не катастрофа. Жить можно. Это многому учит из того, что конструктор делал за вас, и какую вы можете извлечь выгоду из явного управления этим делом. Я считал когда-то, что понимаю, как устроен GM. Что при большом желании, необходимости и наличии ресурсов я смогу его написать сам. И, наверное, я был прав, но я всё ещё узнал бы немало.
По большей части, здесь пойдёт речь об инструментах разработки. Каждому программисту необходим инструмент, в котором он может печатать программный код. И он заинтересован в том, чтобы это можно было делать быстрее. Чем он в этом случае воспользуется?
Мы посовещались и решили, что люди хотят знать больше о принципах работы с базами данных. Я уже немножко о них рассказывал ранее, в контексте Rails, но сейчас расскажу немножко больше. Говорить мы будем об ActiveRecord, об “SQL с человеческим лицом”. Эта система служит “мостиком” между объектами Ruby и реляционной базой данных (РСУБД). Для таких штук даже придуман специальный термин — ORM.
Это по большей части небольшой но мощный и разочаровывающий (скорее всего) для многих анонс. Этот момент должен был наступить, вопрос был во времени. Я нашёл хорошую альтернативу GMS для себя, в которой у меня будет больше контроля над ситуацией. Я, в общем-то, её не искал. Но безумные идеи, которые приходили в голову, подталкивали к тому, что с GMS и GM вообще мне стало весьма неудобно работать.
Если вы это читаете, то скорее всего играли в онлайн-игру хотя бы однажды. И если не по этой, то по другой причине, знаете, что в наше время большинство применений сети выполнено по шаблону “клиент-сервер”. Все коммуникации и тяжёлую работу выполняет сервер, а клиент занимается только общением с ним. В случае с играми объяснение вполне простое — важно, чтобы все игроки были равны (а некоторые “чуть равнее”). Чаще всего удобно считать, что клиент в любой момент может быть разобран, расшифрован и использован против вас, поэтому и планировать его так, чтобы никаких вредоносных действий с него было выполнить в принципе нельзя.
Что вообще такое Rails? Это библиотека. Это философия. Это приёмы и соглашения. Но, в первую очередь, это целый набор всякого разного программного обеспечения, связанного одной целью — лёгкая разработка веб-приложений, соответствующих всяким хорошим нормам. Это фреймворк, но основанный во многом на отдельных частях, причём они работают вместе так слаженно, что возникает вопрос, что из этого является “используемым” рельсами, а что “частью” рельс. Стоп-стоп-стоп, я даже не рассказал, что такое фреймворк, а уже почти ругаюсь другими страшными словами.
Для начала расшифрую заголовок, хотя если предыдущий пост вы читали, вы уже знаете. Речь пойдёт о языке программирования Ruby. Как я уже писал, гибкость синтаксиса Ruby располагает к сооружению на его основе “новых языков” (кавычки не просто так). И именно Ruby хорош для этих целей тем, что у нового языка получается синтаксис, от которого не скручиваются мозги.
Жил да был когда-то человек, называвший себя в интернете Matz, и вывели его как-то раз разные языки программирования из себя настолько, что он решил создать свой язык, с чаем и плюшками. Так появился Ruby. И никто бы о нём не узнал, если бы не нашумевший фреймворк Rails, написанный на этом языке. Как ни странно, эти вещи появились почти независимо друг от друга: язык разработал один человек, а взрыв популярности ему обеспечил совсем другой. Зададимся вопросом — стоит ли язык изучения, даже если вы не планируете строить веб-приложения?
Поднимается много вопросов о том, как портировать код с GameMaker на GameMaker Studio. Зададимся более глубоким вопросом — а почему это вообще приходится делать? Я имею в виду то, что все удалённые в GMS функции имели свои причины умереть. Некоторые из них действительно жалко, и часть их них может вернуться в ином обличии. И можно надеяться, что это произойдёт скоро… но вряд ли это будут функции, о которых я расскажу сейчас. Потому что они действительно не нужны.
Полным ходом идёт переезд с WordPress на Jekyll, а также лёгкая реорганизация происходящего здесь. Я уже не раз объяснял зачем, но миграция слегка затянулась. На то есть целый ряд причин, и поверьте — они того стоят.
Любой человек, решивший заняться разработкой любого масштаба программок, рано или поздно натолкнётся на системы контроля версий. Если не из-за необходимости вести в ней собственный проект, то из-за использования их в проектах многих других разработчиков. Чтобы понять, зачем вообще нужны эти системы и какие задачи они решают, нужно взглянуть на типичный процесс разработки.