«Всякая строка кода рождается без причины, продолжается в слабости и удаляется случайно», — Жан-Поль Сартр программирует на ANSI C.

Каждая новая строка кода приносит с собой затраты в виде необходимости ее поддержки. Чтобы избежать подобных затрат на работу с большим количеством кода мы прибегаем к его повторному использованию. Недостаток применения этого метода заключается в том, что он начинает мешать нам, в случае если мы захотим что-либо поменять в будущем.

Чем больше у вашего API пользователей, тем больше кода приходится переписывать для введения новых изменений. Верно и обратное: чем больше вы полагаетесь на сторонний API, тем больше проблем испытываете когда он изменяется. Упорядочивание взаимодействия и взаимосвязей разных частей кода является серьезной проблемой в больших системах. И по мере развития проекта, растет и масштаб этой проблемы.

Перевод статьи на русский язык подготовлен компанией PayOnline, провайдером платежных решений для вашего онлайн-бизнеса.

Продолжение:
Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер).
Пишем свой упрощенный OpenGL на Rust — часть 3 (растеризатор)

Наверное, мало кто на хабре не в курсе, что такое Rust — новый язык программирования от Mozilla. Уже сейчас он привлекает много интереса, а недавно наконец вышла первая стабильная версия Rust 1.0, что знаменует собой стабилизацию языковых возможностей. Мне всегда импонировали системные ЯП, а уж идея системного языка, предлагающего безопасность превосходящую языки высокого уровня, заинтересовала еще больше. Захотелось новый язык попробовать в деле и, заодно, интересно провести время, программируя что-нибудь увлекательное. Пока думал, что бы такого на расте написать, вспомнился недавний цикл статей про компьютерную графику, который я лишь бегло просмотрел. А очень интересно было бы попробовать все-таки написать все эти красивости самостоятельно. Вот так и родилась идея этого хобби-проекта, а также данной статьи.

Поскольку в оригинальной статье тщательно разжевываются все нюансы, касающиеся программирования непосредственно графической составляющей, то я в своем цикле статей буду сосредотачиваться главным образом на том, что касается непосредственно Rust'а. Постараюсь описать те грабли, на которые довелось наткнуться, а также как решал возникающие проблемы. Расскажу о личных впечатлениях от знакомства с языком. И, конечно, упомяну список ресурсов, которыми пользовался при разработке. Итак, кому интересно, добро пожаловать под кат.

Предупреждение: статья написана с позиции новичка и описывает тупые ошибки новичка. Если вы профи раста, возможно, посмотрев на мои потуги, вы захотите меня больно огреть чем-нибудь тяжелым. В таком случае рекомендую воздержаться от ее чтения.


Here is the Rust, which i hope to get at the end. (игра слов, Rust по-английски «ржавчина»)

Шла обычная пятница, ничто не предвещало беды…

Но червь «нужно что-то сделать» уже начал свою работу. После прочтения статьи я вспомнил, что у меня в барахле лет 15, если не больше, валяется сеговский геймпад. Забрал я его с твердым намерением сделать геймпад на процессоре AVR (про ардуино я тогда и не слышал, но пару небольших проектов на AVR сделал).

Еще больше утвердила мое намерение статья про MSX, и в пятницу я решил — делаю!

---

Official translation (with a bit of polishing) is available here.

---

В кратком курсе компьютерной графики, что я предоставил вашему рассмотрению пару недель назад, мы пользовались методами локального освещения. Что это значит? Это значит, что интенсивность освещения каждой точки мы выбирали независимо от её соседей.

Модель освещения Фонга — классический пример локального выбора:



Финальная интенсивность складывается из трёх слагаемых: окружающее освещение, постоянное значение для всех точек сцены. Диффузное освещение и блики зависят от вектора нормали к данной точке и направления света, но не зависят от геометрии остальной части сцены. Давайте подумаем, а почему, собственно, окружающее освещение было выбрано постоянным для всей сцены?

Очень часто на хабре появляются статьи о том как использовать Raspberry Pi как медиацентр, передвижную видеокамеру, удаленную web камеру и… собственно все. Очень странно, что в такой большой IT тусовке — довольно мало информации о том — как его программировать и использовать одноплатный компьютер там, где он действительно довольно полезен — во всяких встраиваемых системах, где есть ограничения по размеру и стоимости, но также есть потребность в производительности. В нескольких статьях постараюсь описать на примере создания мобильного колесного робота с компьютерным зрением — как можно использовать малинку для создания роботов(штук с интеллектом на борту, а не управляемых с андроида машинок с веб камерой).

Прочитал недавно статью «IPv6 под прицелом» и решил написать более подробно об атаке SLAAC (SLAAC Attack), т.к. эту атаку я уже давно в голове держу, развернутого материала на русском не нашел, да и самому интересно ее было повторить.

Суть атаки

В чем суть атаки? Во-первых, она очень простая и надежная, т.к. использует стандартные технологии и инструменты ОС. По сути, вы просто становитесь единственным IPv6-маршрутизатором в сети и раздаете клиентам IPv6-подсеть, из которой клиенты берут себе адреса либо автоматически генерируя их (SLAAC), либо спрашивая у вашего же DHCPv6-сервера. Напомню, что IPv6 включен по умолчанию во всех современных десктопных, мобильных и серверных ОС, имеет приоритет над IPv4 (кроме некоторых случаев), адрес IPv6, в отличие от IPv4, может быть получен в любой момент, а не только в момент совершения подключения, и крупные веб-сайты уже давно доступны через IPv6. Атака работает как в проводных сетях, так и в беспроводных. Не все свитчи, даже современные, поддерживают фильтрацию Router Advertisement, и, как я полагаю, не все включают эту функцию, даже если она поддерживается свитчем, полагая, что раз в сети нет IPv6, то и фильтровать ничего не нужно. К слову, на данный момент, фильтр Router Advertisement можно обойти на всех свитчах, использовав недостатки реализации.

Я смог придумать две реализации атаки:

Это продолжение статьи: Умный дом (Самое начало) — ч.1

В прошлой статье я писал о том что такое умный дом и с чего начать при его создании. Теперь я постараюсь описать техническую часть: железо и ПО. На всякий случай напомню дорогому читателю, что это не HOW to, а обзорный материал, потому конкретных решений и code-вставок для копипаста тут скорей всего не будет. Технологий и методов решения поставленной инженерной задачи очень много и описать все в моих статьях не получится.

Вся информация написана с упором на личный опыт, никаких «диванных» домыслов.

Хотя про этот троян известно достаточно давно, настоящую массовость он приобрел в конце ноября.
Интересно в нем то, что вместо обычной кражи логинов и паролей, от которой можно вполне просто защититься, он напрямую ворует предметы из инвентаря Steam.

Компания Valve давно в курсе проблемы, но каких-то особых действий за несколько месяцев так и не предприняла, хотя текущую волну можно без проблем остановить небольшими изменениями в клиенте Steam.

В данной статье я постараюсь рассказать о своем опыте создания и реализации алгоритма для обработки сигналов с нескольких стандартных датчиков, входящих в состав ИНС (в английской версии IMU), для решения задачи стабилизации высоты многороторного летательного аппарата (в моем случае — квадрокоптера). На хабре уже был ряд статей, описывающих, что это за игрушка и как её сделать самому. Как программисту по профессии, мне было интересно не только его собрать, но и поковыряться в «мозгах» и сделать что-то полезное для сообщества. В качестве «мозгов» я выбрал Arduino и замечательный проект MultiWii. Он полностью открытый, динамично развивается, но в нем пока есть «белые пятна». Например, неудовлетворительно работает стабилизация положения по высоте. И я решил разобраться, можно ли с имеющимся оборудованием улучшить эту часть системы.

Статья ориентирована на аудиторию, не имеющую какого-либо опыта. В ней не содержится описание каких-либо взломов и «плохих» патчей.

Предисловие

Однажды мне в руки попалась игра Unturned, построенная на движке Unity3d. Позже выяснилось, что она не лишена недостатков. Она находится в альфа версии, так что сервер даже не оповещает игроков о убийстве другого персонажа, что было не удобно в боях PvP. До этого случая у меня не было опыта работы с cil и реверс-инжинирингом c# приложений, тем более Unity.

Добрый день уважаемый читатель, вашему вниманию предоставляется проект разработки системы сенсорного управления мини-дирижаблем.
Задачей управления является движение дирижабля по линии. Также была реализована простая система дистанционного управления.
Объектом управления является мини-дирижабль разработанный на кафедре ЭиМ, ТТИ ЮФУ.


Рисунок 1 — Общий вид мини-дирижабля.

В проекте ставится цель: разработка системы технического зрения для обнаружения линии (траектории движения); разработка курсового регулятора, учитывающего факторы положения линии и угла наклона линии относительно дирижабля; разработка регулятора высоты; разработка системы дистанционного управления.

Создание игры процесс захватывающий и познавательный. Особенно это заметно, когда ремейк «классики» делаешь сам, руководствуясь идеями оригинала и десятками часов, потраченных на прохождение кампании. У меня не было сколь-нибудь значимого опыта разработки для Android'a, поэтому создание работающего «как надо» приложения для планшета поначалу выглядело довольно туманно, но от этого не менее притягательно. При наличии времени и возможностей, можно стряхнуть пыль со старых игр, подмазать и подклеить, добавив поддержку «больших» разрешений и окажется, что они выглядят не хуже современных продуктов, выложенных на маркете, даже с палитрой RGB565 без альфа-канала. Я предполагал, что будут подводные камни и заботливо спрятанные грабли, которые лежат тихонько во время разработки, но больно лупят по голове, стоит запустить игру на реальном железе. Чего сильно не хватало, так это отладчика, а возникающие проблемы лишь укрепили желание достичь поставленной цели. Под катом будет рассказ о том, как это все заработало.