Подавляющее большинство из нас использует такое крайне полезное устройство, как источник бесперебойного питания. Качество питания не везде идеальное, да и просто мельчайшие проблемы с электропитанием иногда могут дорогого стоить. Потери данных это всегда неприятно, а иногда просто таки фатально. Устройство куплено, установлено под стол, подключено и владелец его находится в полной уверенности, что в любом случае при перебое в электропитании он успеет корректно завершить работу, а может быть и сделать бэкап на флешку. Время идет, бесперебойник периодически дает о себе знать — как заправский сторожевой пес он подает голос при малейших отклонениях в параметрах электросети. Хозяин спокоен и все хорошо. Но в один из дней перебой таки случается и в этот раз ИБП не просто подает голос и сразу переключается с батареи на сеть, в этот раз свет выключили на долго. Мы спокойно копируем файлы (ведь в запасе у нас минут 15, не меньше) и тут бесперебойник начинает пищать совсем часто и все выключается. Как так? Ведь бесперебойник же должен был нас защитить от подобных ситуаций, а он только вселял нам ложную уверенность в нашей безопасности! Почему так произошло?

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

Некоторое время назад я занимался поисками датчика давления для одного сайта. Требования были простыми — подключение по USB и минимум паяльника, т.к. опыт использования данного инструмента у меня только в криптоанализе. Оказывается, что в отличие от температуры и влажности, китайцы ещё не освоили этот рынок, и наиболее простой и дешёвый вариант: купить любой барометр, направить на него веб-камеру и анализировать показания.
Несмотря на бредовость данной затеи, она серьёзно рассматривалась, но в конце-концов была отметена по банальной причине — ночью нужна подсветка. Т.е. работать система ночью не будет, а если будет, то потребует дополнительных усилий по настройке.

Из других вариантов, наиболее подходящим была USB Meteo Board от Sparkfun на основе Arduino, или самодельная система на основе того же Arduino или Netduino.

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

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

Навигация по основам Linux от основателя Gentoo:

Часть I

1. BASH: основы навигации (вступление)
2. Управление файлами и директориями
3. Ссылки, а также удаление файлов и директорий
4. Glob-подстановки (итоги и ссылки)

Часть II

1. Регулярные выражения (вступление)
2. Назначения папок, поиск файлов
3. Управление процессами
4. Обработка текста и перенаправления
5. Модули ядра (итоги и ссылки)

Часть III: 1, 2, 3, 4

Эта статья нацелена на читателей, которые начинают или только хотят начать заниматься программированием модулей ядра Linux и сетевых приложений. А также может помочь разобраться с прозрачным проксированием HTTPS трафика.

Небольшое оглавление, чтобы Вы могли оценить, стоит ли читать дальше:

1. Как работает прокси сервер. Постановка задачи.
2. Клиент – серверное приложение с использованием неблокирующих сокетов.
3. Написание модуля ядра с использованием библиотеки Netfilter.
4. Взаимодействие с модулем ядра из пользовательского пространства (Netlink)

P.S. Для тех, кому только хочется посмотреть на прозрачный прокси-сервер для HTTP и HTTPS, достаточно настроить прозрачный прокси-сервер для HTTP, например, Squid с transparent портом 3128, и скачать архив с исходниками Shifter. Скомпилировать (make) и, после удачной компиляции, выполнить ./Start с правами root. При необходимости можно поправить настройки в shifter.h до компиляции.

Уже сегодня стала доступной для предзаказа 6я версия Лайтпака.
В новой ревизии устройства улучшена цветопередача в диапазоне цветов с низкой яркостью. Новая плата получила акриловую защиту, которой прикрыты все разъемы на плате. По словам разработчиков это самое удобное и лучшее решение для такого типа устройств. Лайтпак 6 получил квадратный корпус с удобными разъемами, теперь не придется зачищать проводки и прикручивать их отверткой. Скоро появится видео.

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

Звучит несложно, правильно?

У читателя предполагается наличие опыта компиляции программ и работы в Линуксе. Небольшое умение читать ассемблерный код тоже пригодится.

Вдохновившись статьёй Привет из свободного от libc мира, я так же решил проделать нечто подобное. Чтобы не заниматься этим бесцельно, я решил поставить перед собой следующую задачу. Сделать программу, выводящую какую-нибудь простую строку, вроде «ELF, hello!». Разобраться с тем, как именно она будет представлена в исполняемом файле. Ну и попутно, постараться уложиться в 100 байт.

В первой части статьи, переведенной уважаемым skb7, было рассмотрено идиому Pimpl (pointer to implementation, указатель на реализацию), ее назначение и преимущества. Во второй части будет рассмотрено проблемы, возникающие при использовании этой идиомы, а также предложены некоторые варианты их решения.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Почитал я немного про автовыставку в Детройте, про то, что Lane Departure Warning становится все более и более популярным и решил, что надо бы поделиться своим опытом изготовления прототипа этой системы из нехитрых компонентов в виде веб-камеры, Питона, OpenCV и пары дней усердной медитации:)

Историю создания прототипа можно почитать и посмотреть под катом… (там картинки, много...)

Восстановление искаженных изображений является одной из наиболее интересных и важных проблем в задачах обработки изображений – как с теоретической, так и с практической точек зрения. Частными случаями являются размытие из-за неправильного фокуса и смаз – эти дефекты, с которым каждый из вас хорошо знаком, очень сложны в исправлении – именно они и выбраны темой статьи. С остальными искажениями (шум, неправильная экспозиция, дисторсия) человечество научилось эффективно бороться, соответствующие инструменты есть в каждом уважающем себя фоторедакторе.

Почему же для устранения смаза и расфокусировки практически ничего нету (unsharp mask не в счет) – может быть это в принципе невозможно? На самом деле возможно – соответствующий математический аппарат начал разрабатываться примерно 70 лет назад, но, как и для многих других алгоритмов обработки изображений, все это нашло широкое применение только в недавнее время. Вот, в качестве демонстрации вау-эффекта, пара картинок:



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

Цель этой статьи — заставить всех, особенно программистов на Си, сказать «я не знаю Си».
Хочется показать, что тёмные углы в Си значительно ближе, чем кажется и даже тривиальные строки кода несут в себе undefined behavior.

Я заметил, у разработчиков совершенно полярное отношение к библиотеке Boost.Spirit: либо она им жутко не нравится, либо они фанатеют от нее. Конечно, описывать грамматику на C++ – занятие на любителя. Таким любителем оказался и я, когда познакомился со Спиритом. Хочу показать, как с помощью Спирита можно довольно просто решать повседневные задачи разбора текста.

Простая задача – как два пальца

На Спирите очень удобно писать маленькие парсеры «не отходя от кассы» – прямо в C++ коде. Вот например, как вы поступите если нужно распарсить строку вида «число-число», которая задает диапазон страниц для печати? На Спирите – одна строчка:

bool ok = parse(First, Last, (uint_ >> L"-" >> uint_), MinMax) && (First == Last);

Посложнее…

Более того – можно ненамного сложнее создавать и парсеры побольше. В качестве примера рассмотрю парсер мини-языка, который я делал для API Яндекс.Бара. Задача была такова: для облегчения загрузки плагинов в баре используется XML, который довольно избыточный сам по себе. Но зато XML легче грузить из JavaScript-а, чем парсить произвольный формат (на JS пишутся расширения под FireFox, в том числе и Я.Бар).

Итак, что мне было нужно – имея на входе обычную инфиксную нотацию:

Недавно на профильном ресурсе один программист задал вопрос: «Что использовать в сервере ММО для работы с потоками?». Программист склонялся к Intel TBB, но даже не к базовым примитивам, а к кастомному планированию задач (task scheduling). Ну нравится TBB — ну и ладно. А немного позже я увидел исходники сервера ММО другого программиста, который недавно начал переписываться его с нуля для улучшения архитектуры. И там было очень много велосипедов, которые писались самим программистом вместо того что бы использовать сторонние компоненты такие как boost (к примеру класы обертки над pthread-ом, и это в 2010 году, когда boost.thread уже почти в стандарте). Была там реализована и поддержка пула потоков с планировщиком задач. Тема эта мне очень интересна и я начал копать информацию о готовых решениях планировки задач (как в TBB) и нашел boost.task, про что и решил написать.

Казалось бы — что может быть проще, чем работа с файлами в C++. Но отдельные личности поражают своей находчивостью в поиске наихудшего подхода.
Не стоит делать так:

std::string filepath("C:\\тест");
std::ofstream file(filepath.c_str());

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

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

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Недавно взглянул на сорцы Farseer Physics Engine. Стало интересно как в этом движке реализован динамический объект. Как и ожидал, не встретил там привычных мне дифференциальных уравнений и их дискретных реализаций в виде разностных уравнений или дискретных моделей пространства состояний. Главная отмазка заявляемая причина отказа от «честной» механики во многих игровых физических движках — излишняя сложность работы с дифференциальными уравнениями и слишком большая вычислительная нагрузка.

Думаю у каждого из нас имеются директории «Разобрать» и «Downloads», заглядывая в которые все мы ужасаемся от их содержимого, и в особенности от самой идеи, что когда-нибудь все это придется разгребать. Предлагаю свое решение проблемы с недостатком места, это не способ суперархивации, и не способ бесконечного наращивания места где-либо в облаке, лишь идея по организации скачанной информации.



Какова вероятность того, что если о файле не вспомнилось в течение 2 недель, вспомнятся через год или два, при том, что почти все скачанное в Интернете имеет свойство быстро устаревать. Данное решение так же подходит и для организации shared ресурсов (файловых помоек).

В субботу на прошлой неделе «дело было вечером, делать было нечего», и мы с хабраюзером sourcerer разговаривали не понятно о чём. И почему-то речь зашла речь о задаче обратной к задаче построения графика функции по её выражению. То есть, например, у нас есть выражение y(x) = (cos^0,5x ⋅ cos 200x + |x|^0,5 − 0,7)(4 − x²)^0,01. График такой функции чем-то напоминает сердечко. Но нам был интересен обратный вопрос, как, имея, например, изображение сердечка, получить выражение для функции, графиком которой будет это самое сердечко.

Какие-нибудь ряды Фурье вспоминать не хотелось, а хотелось чего-то простого и красивого. Мы начали вспоминать известные нам результаты, связанные с этим вопросом. В результате получилась программка, которая по изображению генерирует ломаную линию, чем-то напоминающую исходное изображение. На примере котёнка по имени Гав это выглядит примерно так (смотреть лучше издалека):



Если интересно как такое сделать, а также узнать про формулу конопли, формулу, график которой является этой же формулой, то добро пожаловать под хабракат. (Будет много картинок.)