У каждого программиста бывает желание велосипедостроения. Это случилось и у меня. Решил зарефакторить кусочек кода в приложении на текущей работе. Было приложение, которое выполняло работу в бесконечном цикле. И в этом цикле работа выполнялась, когда приложение было активно. То, что приложение активно в данный момент определялось через группу булевых значений. То есть каждую итерацию цикла приложение проверяла все эти булевы условия. Я подумал, что не лучше ли будет проверять одно значение вместо пачки. Так родился простой велосипед небольшого хранилища булевых условий в битах целочисленного типа.

В статье все примеры взяты из головы. Все совпадения случаны

Резкий и дерзкий релиз версии 0.13.0. Очень удивил своей внезапностью. Нововведений немного, потому коротко. Но есть заметные изменения. О них чуть детальнее. Критически релиз связан с выходом LLVM версии 18. Эндрю Келли хотел скорее выпустить версию для синхронизации. Потому такой быстрый релиз. У вас может возникнуть вопрос, ведь я вроде указывал в прошлой статье, что произойдёт отказ от LLVM? Не так быстро это происходит. Повторюсь, релиз слишком «внезапный», чтобы произошли такие серьёзные изменения. По найденной информации (спасибо чатику в телеге) полного отказа всё же не произойдёт. Будет опциональная возможность подключать LLVM на тех платформах, где нет внутренней поддержки. В общем win-win ситуация.

По случаю выхода версии 0.12.0 языка Zig я снова решил написать статью об этом языке. И в этот раз о том, что изменилось в языке относительно версии 0.11.0. Сразу уточню, что я не буду описывать все изменения. Ссылка на примечания к выпуску под цифрой выше. Список изменений хоть и нетакой большой, как у версии 0.11.0, не все изменения мне интересны. Я опишу только те, что мне показались более важными для языка. Да, и если уж делать полный обзор, нужно давать подробные примеры - более детальные, чем те, что предложены в примечаниях к выпускам. Потому что не все изменения будут понятны сразу, нужно сделать сравнение. Это не претензия к авторам, просто есть детали, которые понятны только на более конкретных примерах (если прочитать между строк, то это я нифига не понял).

Бывает так, что в продуктовой IT-компании выстраивается иерархия, в которой верхние уровни работников компании совершенно не понимают как производится продукт, который компания производит и продаёт. По сути руководители знают как продать, но не знают как произвести. Для производства, что логично, нанимаются исполнители с опытом. Это нормальная практика. Но дальше в зависимости от того, как выстроены процессы внутри компании могут быть проблемы. О некоторых проблемах я бы хотел написать в этой статье.

Я не имею опыта работы в компаниях, где руководители верхних уровней доверяют исполнителям нижних уровней. Может быть доверие и было, но я его не замечал. С моей стороны все действия руководства выглядели так, будто их не интересует мнение людей, которые имеют опыт в конкретной области и непосредствено работают с конкретными направлениями в компании, для которых их, собственно, наняли. Мой опыт сейчас основан только на тех компаниях, где руководство оставляет за собой принятие всех ключевых решений по продукту. Что определённо негативно сказывается на продукте, так как результат принятия решения очень сильно зависит от опыта руководства. То есть, если руководство знает только как продавать, то оно будет принимать решения имено в этом направлении.

Я столкнулся с тем, что я иногда не понимаю код, с которым мне приходится работать. И это сильно сказывается на моей производительности и на качестве конечного результата. Неделю назад я прочитал статью Плохо девелопмент за авторством @dalerank(Сергей Кушниренко), в которой описывается проблема молодых специалистов, которые упрощая себе работу пользовались готовыми решениями, а не писали код с нуля. Моя статья не об этой статье и не ответ к ней. В самой статье Сергея Кушниренко была ссылка на другую статью - You should refuse to develop what you don’t understand. И вот эта статья меня несколько озадачила. Я задумался о проблеме понимания того, с чем я работаю. О ней я бы хотел написать, но и некоторые тезисы из статьи Сергея Кушниренко я тоже затрону.

ВНИМАНИЕ! Дальше вас ждет душная простыня текста без юмора.

Этой статьёй я бы хотел рассказать свой небольшой опыт поиска работы и непосредственно самой работы в области разработки игр, в частности игровых движков. Может быть статья поможет тем, кто только собирается войти в эту область, понять, что эта область имеет свои особенности и многое может казаться слишком романтизированным.

ВНИМАНИЕ! Дальше вас ждет простыня текста без юмора. Душнилово так же присутствует. Я не буду называть некоторые компании, в том числе и ту, в которой я работаю сейчас, чтобы, если меня понесёт, я не переписывал статью. Из песни слов не выкинешь. Позже, когда уволюсь, отредактирую добавив название компании. По тем же соображениям, чтобы ненарушать права на интеллектуальную собственность я не выкладываю куски кода, о которых пишу в статье. Опять же в будущем может быть добавлю.

По случаю выхода версии 0.11.0 языка Zig я решил написать ещё одну статью о языке Zig. В этот раз речь пойдет о системе сборки языка. А точнее, как пользоваться кодом написанным на языке C в проекте на языке Zig, с небольшими ответвлениями в стороны для описания некоторых возможностей системы сборки. Тем более, что она претерпела несколько изменений, о чём я так же коротко упомяну. Эксперименты проводились мной на Windows 11. Стоит сразу упомянуть, что указанные в статье команды будут работать и на других операционных системах. Это одна из особенностей языка Zig. Но пример кода линковки системных библиотек для сборки библиотеки raylib будет платформозависимый, так как для разных платформ набор библиотек отличается. Если интересно, то прошу...

По случаю выхода версии 0.11.0 языка Zig я решил написать статью о том, что привлекло меня в языке, что мне в нём нравится. В Zig есть ряд интересных решений. И я рассматриваю его, как альтернативу языку C. Так собственно его позиционируют его создатели. И не без причин. Причина, по которой я решил изучать Zig - я не захотел полноценно учить C. Многое в C исторически устарело. И Zig для меня, как глоток свежего воздуха.