Приветствую уважаемых читателей.
В этой небольшой статье я бы хотел рассмотреть вопрос взаимодействия с оборудованием (в данном случае с USB устройствами) в операционной системе MacOS X.
Будет рассмотрены очень интересный и полезный фреймворк IOKit, способ получения уведомлений о добавлении/удалении обордования, а так же получения полной информации об устройствах. Конечно данный материал не претендует на какую либо уникальность, т.к. каждый может разобраться с этими вопросами самостоятельно, изучив документацию Apple, а так же покурив разнообразные исходники на opensource.apple.com
Моя статья — попытка восполнить пробелл в русскоязычном материале подобного рода и описать некоторые грабли, с которыми могут столкнуться новичики.
Все кто заинтересовался — добро пожаловать под кат.

Об изготовление печатных плат с использованием фоторезиста уже много раз рассказывали, в том числе и на хабре. Долгие годы (серьёзно) я с этим мучался, но у меня не получалось абсолютно ничего. Потратив подаренную много лет назад половину банки POSITIV-а, я получил только одну, на половину получившуюся, плату. В 50% случаев резист смывался весь, в 50% — не смывался нигде. Учитывая, что в будущем мне придется работать с фоторезистом в более сложных условиях (для своих «домашних» микросхем), я решил устранить все возможные источники проблем.

Одна из таких проблем, которая может испортить всю работу с фоторезистом — фоновая засветка фоторезиста комнатным / дневным освещением. Решить её можно с помощью неактиничного освещения, т.к. освещения, которое не вызывает засветки. Для черно-белой фотографии например — это была лампа красного света. В этой статье я расскажу о том, как решил эту проблему.

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



Zsh красив, приятен, чертовски функционален, но, признаюсь честно, я не смог совладать со всеми его многочисленными настройками. Я хочу работать, а не бороться со своим рабочим окружением. Простой пример: пару раз из-за автодополнения zsh я удалял все директории и файлы в текущей директории — zsh просто ставил пробел между автодополненной директорией и введённой мною звёзочкой (я хотел удалить всё в выбранной папке). Помните тот эпичный баг с пробелом и удалении директории /usr? У меня было то же самое. Спасибо гиту, выручил в который раз.

Впрочем, дело не в zsh — будь я чуточку умнее, я бы с ним обязательно справился бы, и всё было бы хорошо, но мы, суровые программисты, будем использовать bash и vim, а гламурные zsh и textmate оставим хипстерам и прочим модникам ;)

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

Однажды передо мной встала задача разработать встраиваемую систему, в которой бы данные могли передаваться между узлами c максимальной надежностью. Тогда то я впервые и узнал о CAN.

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

CAN (Controller Area Network) — это стандарт, созданный компанией Bosсh для сетей, используемых в автоматизации и промышленности. Стандарт нашел широкое применение в промышленном производстве, технологиях «умного дома», а так же в автомобилестроении. Очень хорошо подходит для связывания различных датчиков и управляющих устройств в единую сеть.
Как правило, CAN-сеть это сеть типа «шина», в которой все узлы могут передавать и принимать данные.
Она обладает небольшой скоростью, но высокой надежностью.

Далее я хочу поверхностно описать стандарт и рассказать об использовании такой сети на практике.

Во всех 3G модемах есть внутренние антенны. В некоторых моделях их даже по две-три. Об этих антеннах никто и не задумывается, пока модем без проблем прокачивает через себя пяток-другой Мбит в секунду. Но если скорость составляет считанные килобиты и если компьютер с модемом уже побывал во всех углах комнаты в поисках хоть какого-то сигнала, но так его и не нашёл, то первое, что может помочь – это внешняя антенна.

30 ноября 2010 года Дэвид Коллиер (David Collier) писал:

Я заметил, что в busybox ссылки разложены по этим четырём директориям.
Есть ли какое-то простое правило, чтобы определить, в какой директории какая из ссылок должна лежать…
К примеру, kill лежит в /bin, а killall — в /usr/bin… Я не вижу никакой логики в таком разделении.

Вы, наверное, знаете, что Кен Томпсон и Дэннис Ритчи создали Unix на PDP-7 в 1969-ом. Так вот, примерно в 1971 они проапгрейдились до PDP-11 с парой дисков RK05 (по 1,5 мегабайта каждый).

Когда операционная система разрослась и перестала помещаться на первом диске (на котором была расположена корневая ФС), они перенесли часть на второй, где располагались домашние директории (поэтому точка монтирования называлась /usr — от слова user). Они продублировали там все необходимые директории ОС (/bin, /sbin, /lib, /tmp ...) и складывали файлы на новый диск, потому что на старом кончилось место. Потом у них появился третий диск, они примонтировали его в директории /home и перенесли туда домашние директории пользователей, чтобы ОС могла занять всё оставшееся место на двух дисках, а это были целых три мегабайта (огого!).

Я уже писал, как собирал Maximite.

Вчера как-то был настрой, и решил я поставить туда RetroBSD.

RetroBSD — это настоящий UNIX, являющийся наследником 2.11BSD и предназначенный для встраиваемых систем с фиксированной структурой памяти. На текущий момент работает на микроконтроллере Microchip PIC32 с 128 килобайтами памяти и 512 килобайтами Flash. Данный процессор позволяет разделять адресное пространство ядра и пользовательских процессов.

RetroBSD обеспечивает защиту памяти ядра, используя аппаратные возможности микропроцессора, полноценную вытесняющую многозадачность, POSIX API (fork, exec, wait4 и т.д.). Можно писать программы прямо на устройстве, так как есть компилятор С. Ядро системы прошивается в кристалл, а файловая система загружается с SD-карты.

RetroBSD поддерживает не только аппаратуру Maximite, но и ряд альтернативных устройств на базе PIC32 (chipKIT Max32, Sparkfun UBW32, Microchip Explorer 16, Microchip PIC32 USB/Ethernet Starter Kit, Olimex Duinomite, Duinomite-Mini и Duinomite-Mega, eflightworks).

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

Торжественный момент включения, и…

У великого русского поэта Тютчева не было компьютера и сети, иначе он бы не писал: «Люблю грозу в начале мая». В последние годы актуальность грозозащит стала поменьше — оптика, беспроводные технологии, но все же все же.
Если к вам в квартиру заходит кабель, и этот кабель — не оптический, гроза представляет угрозу для вашего оборудования.

Если у вас есть телевизор и он подключен к общей сети — кабельное ТВ, коллективная антенна (вдруг) — к чему угодно, что находится за пределами квартиры, гроза представляет угрозу для телевизора, (причем даже бОльшую, чем для компьютера).

Недавно познакомился со структурами C/C++ — struct. Господи, да «что же с ними знакомиться» скажете вы? Тем самым вы допустите сразу 2 ошибки: во-первых я не Господи, а во вторых я тоже думал что структуры — они и в Африке структуры. А вот как оказалось и — нет. Я расскажу о нескольких жизненно-важных подробностях, которые кого-нибудь из читателей избавят от часовой отладки…

— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».

Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

• Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
• Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
• Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
• Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
• Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

Началось все с того, что я откопал в полке с железками USB модем huaweiE1550, купленный мной прошлым летом для организации резервного канала Интернет. Проработал он тогда недолго и за ненадобностью был убран в «закрома» до лучших времен. Первое что сделал, разлочил его для работы с МТС (так уж сложилось исторически, что я предпочитаю именно этого оператора). Изначально в голову пришла идея отправки смс с предупреждениями от Nagios, вместо почты. Бегло пробежавшись по Интернетам, наткнулся на smsd демона для отправки/приемки смс-ок из пакета smstools. После прочтения документации по этому зверю, в голову пришла идея о том, что можно принимать сообщения с нужных телефонов, с командами для сервера. Так и родилась идея «Управлять сервером посредством СМС», которая может применяться для чего угодно: перезагрузить сервер, выключить его, перезапустить демона, сбросить кеш, открыть порт на фаерволе для удаленного подключения по ssh.

Не так давно друг предложил мне работу, связанную с созданием прошивки для микроконтроллера, который должен был связываться с сервером при помощи GSM-модуля SIM900D. Ранее я с программированием микроконтроллеров дела не имел, да и на C программировал последний раз в студенческие времена, но любопытство перевесило и я принялся за работу. Документация по данной железке присутствует в интернете, однако хороших примеров работы с TCP/IP в коде найти не удалось. Ничего не оставалось, кроме как обложиться документацией, запастись сигаретами и чаем и приступить к лавированию между граблями. А граблей оказалось немало. Собственно, поэтому я и написал эту статью — чтобы другим было легче.

Далее будет много AT-команд, не слишком много кода и очень много букв.

Mosh — замена(или дополнение) SSH. Он быстрее и отзывчивее, особенно на линках с высокой задержкой, например, в мобильных сетях. Набираете символ, и моментально видите его на экране, так же, как и в локальном терминале. Почему? Потому, что в Mosh реализован так называемый local line editing, который не дожидается ответа от сервера, а сразу все отображает на экране. Работает даже в полноэкранных приложениях, вроде vim или emacs. И это далеко не единственный плюс!

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

Наверное многие из Вас работают с Maven. Если так, то полагаю каждый из Вас ежедневно собирает свой проект по несколько раз, особенно если Вы сейчас в активной фазе разработки и изменения затрагивают много модулей. В определенный момент времени проект становится довольно большим и билд с каждым днем начинает выполнятся все дольше и дольше… И вот приходит время, когда пора что-то с этим делать.

Мигрируйте с Maven 2 на Maven 3

Вы еще используете maven2? Странно. Одна только миграция на 3-ю версию может значительно ускорить процесс сборки. В моем проекте переход на Maven 3 дал прирост в скорости сборки на 10%. Вероятней всего за счет каких-то фиксов и оптимизаций, что были сделаны в новой версии (так как заявляют разработчики количество кода было существенно уменьшено и сильно отрефакторено). Миграция займет у Вас несколько минут и в большинстве случаев будет безболезненной. Хотя есть шанс, что некоторые конфигурационные файлы все же придется подправить.

Используем ядра и дополнительные потоки

В Maven 3 есть замечательная опция:

mvn -T 4 clean intall
mvn -T 2C clean install

В первом случае мы явно указываем, что хотим запустить процесс сборки на 4 потока. Во втором случае мы указываем, что на каждое ядро должно быть выделено по 2 потока для процесса сборки. Это одна из новых фич нового мавена — Parallel Builds. Эта фича анализирует граф зависимостей Вашего проекта
и распихивает модули по разным потокам, сборка которых может быть выполнена параллельно.
Для моего текущего проекта скорость сборки со вторым параметром (-T 2C) ускорилась на 20%. Правда тут есть один минус. Количество ресурсов, что будет потребляться для билда может значительно вырасти. В моем случае это +30% к потребляемой памяти.
Хочу сразу обратить внимание — если связанность модулей в Вашем проекте очень низкая — то
скорость сборки этой опцией можно увеличить на порядок.
Это, кстати, повод задуматься об Вашей архитектуре проекта. Ведь если билд занимает довольно много времени, то небольшой рефакторинг поможет уменьшить эту цифру. Хотя, конечно, это все очень индивидуально.
Вообще разработчики заявляют, что прирост в скорости сборки может быть 20-50%.

От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Хочу поделиться опытом своей команды по миграции с древнего VMware Server 2.0 на ESXi 4.1. В ходе оптимизации расходов на обслуживание перед нами встала задача уйти с сильно подтормаживавшего VMware Server под виндой на бесплатный ESXi. Задача усложнялась территориальной распределённостью серверов (по всей России) и сжатыми сроками, в которые необходимо было это сделать.

Дано:

1. Полтора десятка серверов в удалённых локациях. Возьмём за данность, что они имеют интерфейс удалённого управления (DRAC/ILO/IP KVM). Без этого миграция сильно усложняется большим количеством командировок.
2. На серверах крутится по 3 виртуальных машины — контроллер домена, работающий также как DNS и DHCP-сервер (виртуальный диск 40 гигабайт), WSUS + хранилище дистрибутивов (150 гигабайт), и сервер, сканирующий сеть филиала на уязвимости (ещё 40 гигабайт).
3. Промежуточных серверов, на которые можно было бы временно поставить ещё один ESXi и осуществить конвертацию на него «живых» машин у нас нет, но для хранения слитой информации у нас есть файлсервера, подключённые с нашими серверами в тот же свитч — в лучшем случае гигабитный, но чаще всего 100 мегабит.
4. На все сервера у нас есть админские права через AD-группы (в большой компании это не всегда так, но в данном случае мы их получили). Паролей локального админа на эти сервера у нас нет.

Требуется:
Избавиться от связки Windows + VMware Server. Профит: высвобождаем лицензии на ОС, а также ускоряем работу виртуалок, ибо периодически хост-машина сжирала все процессорные ресурсы (причина — процесс tomcat всё того же реликтового гипервизора) — виртуалкам становилось очень неуютно.

Теория создания самодельной автомобильной спутниковой сигнализации с web-интерфейсом и поддержкой eCall / ЭРА-ГЛОНАСС на базе микроконтроллеров STM32 как основа концепции «Умный автомобиль», и её использование в системах «Умный дом». Реализация аналога технологии Volvo On Call и автомобильной социальной сети Toyota Friends.

Сначала «скелет», а потом «мясо».
Сначала процесс, а потом инструмент под процесс.
Автоматизация хаоса дает хаос.

Это все — разные формулировки одной простой идеи. Идея, которая часто не учитывается во множестве вещей.

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

Не учитываются следующие моменты
1. Сам процесс может существовать только в воображении создателя стартапа. К примеру, процесс аггрегации результатов матчей ЦСКА вовсе может быть не нужен фанатам этого футбольного клуба, как бы себе это не представлял стартапер. Поэтому важно быть в самом процессе, понимать, какой процесс — реален, а какой нет.

Недавно мне задали вопрос: как бы я реализовал механизм виртуальных функций на языке C?

Поначалу я понятия не имел, как это можно сделать: ведь C не является языком объектно-ориентированного программирования, и здесь нет такого понятия, как наследование. Но поскольку у меня уже было немного опыта с C, и я знал, как работают виртуальные функции, я подумал, что должен быть способ сымитировать поведение виртуальных функций, используя структуры (struct).

Краткое пояснение для тех, кто не знает, что такое виртуальные функции:
Виртуальная функция — это функция, которая может быть переопределена классом-наследником, для того чтобы тот имел свою, отличающуюся, реализацию. В языке C++ используется такой механизм, как таблица виртуальных функций
(кратко vtable) для того, чтобы поддерживать связывание на этапе выполнения программы. Виртуальная таблица — статический массив, который хранит для каждой виртуальной функции указатель на ближайшую в иерархии наследования реализацию этой функции. Ближайшая в иерархии реализация определяется во время выполнения посредством извлечения адреса функции из таблицы методов объекта.

Давайте теперь посмотрим на простой пример использования виртуальных функций в C++