Зачастую, в проектах ограничивается использование препроцессора по следующим причинам:
— Он не похож на весь остальной язык;
— Макросы могут возвращать неполные синтаксические конструкции, или вовсе различные, в зависимости от параметров.
Ввиду перечисленных особенностей, читать код с активным использованием препроцессора зачастую становится на порядок сложнее кода без него.
Со всеми его недостатками, инструмент есть в языке и достоин изучения.
Будущее разработки ПО, возможно, станет похожим на джаз. Каждый импровизирует, никто не смотрит на ноты.
На прошлой неделе я выпустил Protocollie. Сделал его за 4 дня, используя языки, которых не знаю, и даже не касаясь кода напрямую. Люди без конца спрашивают: «Как это удалось?» Но я даже не уверен, что получится повторить то же самое второй раз.
Мы все придумываем этот процесс на ходу.
Как удалось с помощью GitHub Copilot автоматизировать отслеживание изменений в базе знаний Ozon. Мой опыт создания собственного сервиса для мониторинга и сравнения обновлений без знаний программирования, с пошаговым описыванием создания архитектуры процесса.
Недавно работал в команде, занимавшейся разработкой встроенного ПО. Это ПО в значительной степени основывалось на конечных автоматах, которые десятками были разбросаны по множеству функций. И хотя такая архитектура весьма распространена в разработке встраиваемых систем, в особенности систем без ОС, я задался вопросом: неужели нет способа выразить поток управления более чисто?
Конечные автоматы в нашем коде работают прекрасно, но их понимание и обслуживание зачастую вызывало головную боль. В их работе отсутствовал линейный поток, плюс они требовали мысленного жонглирования флагами, состояниями и переходами, происходящими в функциях опроса.
Меня не покидала мысль: «А не будет ли проще написать логику в виде последовательной программы, ожидающей события и возобновляющей выполнение с места остановки?»
Естественно, в проекте не допускалось использование RTOS, посему традиционный подход применения потоков или систем блокирования для управления конкурентностью не рассматривался. Но я знал, что должна быть некая золотая середина.
Часто при передаче продукта заказчику, в виде готовой программы или некоторого аппаратного продукта, необходимо также защитить интеллектуальную собственность в виде исходных текстов программ и скриптов.
Компилируемые языки хоть как-то защищаются, соответственно, с помощью компиляции, хотя и это не панацея. А вот что делать со скриптами, которые могут быть написаны на bash или pyton?
Как вариант решения такой проблемы, может быть, шифрование скриптов с аппаратной привязкой дешифратора к платформе, на которой этот скрипт исполняется. Звучит красиво, но надёжно ли? Насколько будет эффективен и взломостойкий этот метод?
У меня в одном проекте была проба пере такого решения. Заодно проверил, и вскрыл это шифрование.
Продолжаю рассказывать широкой аудитории о «гусарских забавах» компьютерной элиты — третий по счету Binary Golf Grand Prix.
Немного рассуждений о языках программирования (ЯП) с уклоном на надежное и безопасное программирование.
Статья не публиковалась ранее, хотя была написана в 2019г, теперь можно смотреть как некую ретроспективу. Чем и воспользуюсь, вставляя замечания о былом по тексту (тег Upd).
Но тормозит развитие серии, ибо вышли уже 3 части и несколько переводов в тему:
Привет, меня зовут Марат Зимнуров, я тимлид в кросс-функциональной команде HR Admin Tech Авито. Тема функционального программирования не обделена вниманием — и все же тяжело найти действительно понятный и структурно изложенный разбор данного инструмента. Нет нормального гайда для старта — ни у нас, ни на Западе. Многие говорят про иммутабельность и монады, но путаются в основах. В статье разбираю, что такое функциональное программирование на самом деле и зачем оно нужно.
На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся.
Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.
Мы традиционно разрешали пользоваться всеми благами интернета, включая ИИ. На эту тему многие сейчас переживают, но, честно говоря, я пока не вижу причин для беспокойства. Вот если бы все участники показали одинаково прекрасный результат, пришлось бы что-то придумывать. И то, конечно, не запрещать ИИ, а делать задачи более сложными. Но результаты у всех разные, и без собственной головы на плечах их не удалось бы получить (я попробовал), поэтому пока все хорошо. Если финалисты меня читают, было бы интересно услышать комментарии от первого лица: пользовались ли вы ИИ, насколько он вам помог или, может быть, наоборот, только отвлекал?
Я очень надеюсь, что не довёл ещё @bodyawmдо белого каления постоянными упоминаниями — но мимо этого я пройти, конечно, не мог. Как вы все помните, я сам что‑то пытался изобразить на тему «кастомизируемого телефона‑звонилки». Я давно обещал выложить свои наработки, но даже просто вспомнить, на чём я там сломался N лет назад — уже труд немалый, и если бы не активность единомышленника в этом направлении, которая меня стронула, сподвигла и стриггерила — стронуться, наверное, так бы и не смог. Особенно учитывая тот прискорбный факт, что я открываю свои собственные записки на эту тему и не понимаю там ни слова — положите на могилку Элджернона, что на заднем дворе, хотя бы пару цветочков...
...которая работает на первых Android-смартфонах в мире, компьютерах из 90-х и даже Mac'ах! Часть 2.
Иногда у меня лежит душа просто взять и написать какую-нибудь небольшую игрушку с нуля, без использования готовых движков. В процессе разработки я ставлю перед собой интересные задачки: игра должна весить как можно меньше, работать на как можно большем числе платформ и использовать нетипичный для меня архитектурный паттерн. Недавно я начал писать ремейк классических «танчиков» и в рамках серии статей готов рассказать о всех деталях разработки трёхмерной игры с нуля в 2025 году. Если вам интересно узнать, как работают небольшие 3D-демки «под капотом» от написания фреймворка до разработки геймплея и тестов на экзотических устройствах — жду вас под катом!
Однажды на собеседовании меня попросили привести примеры написанного мной кода: один — которым я наиболее горжусь, и другой — который я считаю наиболее неудачным. Недолго думая, я осознал, что на оба вопроса у меня готов ответ, и это один и тот же фрагмент кода. Горжусь я им потому, что, пожалуй, из всей моей практики именно этот код оказался наиболее весом, а стыжусь из-за него, так как, по мнению большинства из его читателей, этот код начался с костыля, который затем стали развивать:
Когда речь заходит о налоге на добавленную стоимость (НДС), концепция кажется элементарной, но на деле процесс может быть весьма запутанным и сложным. И тут возникает тот самый "налог на дизайн".
Привет, Хабр! Меня зовут Александр, я лидер команды DevSup (это как DevOps, только с функцией поддержки больших клиентов которым Saas не подходит) в IT-компании ПравоТех.
Мы создаем решения (например, case.one для ведения дел и doc.one для документооборота), чтобы юристы, менеджеры и все кто рядом с юриспруденцией могли работать быстрее, умнее и спокойнее. Наша миссия – «Помогаем людям получать удовольствие от работы».
Сейчас у нас активно внедряются ИИ-инструменты. Создаются боты для консультаций и опросов, часто обращаемся к большим моделям чтобы «обстучать» какую-то идею.
В этой статье поделюсь историей о том, как эффективно и безопасно использовать ИИ, превратив рутину в решенную задачу.
Итак, представьте: вам в руки попадает договор поставки ПО. Не просто договор, а целая книжечка на 50-70 страниц А4. Нужно срочно – за 2-3 дня! – проанализировать его вдоль и поперек: проверить сроки, штрафы, бонусы, риски для вашей компании. Знакомая ситуация для менеджеров, юристов, закупщиков?
Дилемма: Выкроить время и вычитать всё дотошно, рискуя не успеть? Или пробежаться по диагонали, надеясь, что глаз «зацепит» опасную формулировку? Соблазн велик: закинуть текст в публичный ИИ-чат (типа ChatGPT или DeepSeek) и спросить: «Эй, ИИ, моя компания ООО «Рога и копыта» – найди всё, что нам невыгодно!»
Цена такого «упрощения» может быть огромной. Давайте разберемся, почему это крайне опасно:
1. Конфиденциальность — прощай! Условия договора (а они почти всегда секретны!) отправляются владельцу ИИ-сервиса. Нарушение пункта о неразглашении – гарантировано.
Мы продолжаем свое участие в международной олимпиаде «IT-Планета». Как и в прошлые годы, проводился конкурс по SQL, состоящий из трех этапов: теоретический и практический туры, проходящие онлайн, и финальный очный тур.
В первом туре участвовало свыше 4 500 человек, из которых 245 были отобраны во второй. В этом году я занимался разработкой задач и проведением первых двух туров. Предлагаю перейти к рассмотрению задач практического этапа.
Давно думаю над моделью, в которой есть всего две формулы:
State = Static + Dynamic
и
State = Fact + Delay.
Казалось бы – пора звонить в Спортлото, не стыковались они у меня, хотя по отдельности каждая формула вроде работает. Но заявить, что на все вопросы я готов ответить по этим формулам – такого ощущения не было.
И вот... Сидел я как-то над пиццей, подумал, что прикольно раскидали начинки. «Четыре вкуса» и всё такое. И как бы мысленно (а потом и физически) ее ни резал – всё равно что-то влезет на соседний кусок. Итогом стало это...
В этой статье мы познакомимся с эффектом Доплера, но не так, как об этом рассказывается в школьном учебнике физики, а посредством своих любопытных глазок и ушек. Поможет нам в этом специально разработанное мной приложение для Андроид-смартфона.
Статья предназначена для девочек и мальчиков, а также их родителей.
Я постарался охватить только основы, но текст всё равно получился очень длинным.
libriscv — это зрелый эмулятор RISC-V, который в настоящее время используется в игровых движках. Насколько мне известно, это единственный эмулятор, в котором основной акцент делается на обработке задержек, а также предоставляются специализированные решения и инструменты для выполнения быстрых вызовов при обращении с функциями — как входящих, так и исходящих. Причём, всё это заключено в безопасной песочнице. Задержки, наблюдаемые в libriscv, гораздо ниже, чем в эталонных эмуляторах.
Меня многие спрашивали, как им пользоваться, но здесь интереснее то, как вообще может прийти в голову мысль писать скрипты на C++ — не слишком ли сложно это будет? Оказывается, нет, не очень. Вот уже несколько лет я пишу на C++ скрипты для одной большой и одной не очень большой игры, и меня почти не посещало ощущение, что виной каким-то возникающим при этом проблемам являются язык C++ или связанные с ним скриптовые API. Я много лет программирую на Lua, а до этого пользовался обычным C. Но сейчас современный идиоматический C++ — то, что мне нужно. Причём, я могу писать на этом языке как в самом игровом движке, так и за его пределами, при этом опираясь (буквально) на одни и те же абстракции и оперируя одинаковыми структурами данных. Наконец, C++ просто очень мощный. Правда, я признаю, что о вкусах не спорят, и при работе с C++ также не обойтись без компромиссов.
