Здравствуйте.
В продолжение тематики самостоятельного изучения схемотехники предлагаю вашему вниманию статью, связанную с синтезом автоматов на триггерах.
А начинается все так:

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

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

Многим разработчикам знакома ситуация когда кешировать страницы сайта, скажем, на 5-10 минут нельзя всего из-за одного небольшого блочка, актуальность которого нужно поддерживать если не в реальном времени, то с временем «старения» не больше 5-10 секунд. При этом посещаемость сайта продолжает расти, растет время генерации страниц и c этим надо что-то делать…

• Вариант решения 1: Подкрутить то, до чего не доходили руки последнее полгода. Все Вас поймут и передвинут сроки на другие задачи. Вы будете в роли «Супермена» один спасать сайт от непомерной нагрузки, решая проблему «бесплатно» (без доп. вливаний в оборудование). Вам может пригодиться статья «Тюнинг nginx».
   
• Вариант решения 2: Улучшить техническую базу (докупить мозгов на сервер, улучшить дисковую систему, поставить под БД отдельный сервер). В принципе проблема не решена, а скорее отложена. Теперь у Вас есть время «окопаться» и подготовиться ко второй волне наплыва нагрузки, она будет больше и накроет сильнее.
   
• Вариант решения 3: Ваш вариант, о котором я, вероятно, узнаю из комментариев.
   

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

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

Некая программа (допустим, foo) не умеет писать вывод в stdout, только в файл. Даже "-" в качестве имени файла всего лишь создаёт файл с названием "-" [большинство умных программ под unix знают, что одиночный минус вместо имени файла означает вывод в stdout]. Аналогично она отвергает и /dev/stdout.

Другая же программа, обрабатывающая результаты первой, допустим, bar, читает из stdin и пишет в stdout. (если быть точным, первое — это трейсер специального вида, дающий двоичный дамп, а второе — конвертор, печатающий их же в человекочитаемом виде).

Нужно их объединить в конвеер.

Некрасивый вариант — использование обычного файла. Записал, прочитал.

Есть куда более красивый вариант — это именованные пайпы. Так как у пайпа есть имя, мы можем передать его как файл первой программе, а потом передать содержимое другой.

Выглядит это так:

mkfifo mypipe
cat mypipe | bar &
foo mypipe&
rm mypipe

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

1. Введение

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

Статья написана, собрана и сверстана Brotherofken. Спасибо ему огромное.
В предыдущей статье я попытался изложить все основные определения и принципы, чтобы сделать эту статью максимально понятной. Все не уместилось, так что я настоятельно советую ознакомиться с этими файлами:
Базис, Базис2, Минимизация. Далее в этой статье я оставил несколько разъясняющих пометок курсивом.

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

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

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

Вторая часть статьи об управлении трафиком в Linux. В статье приведены примеры приоретизации трафика (QoS) и рассказано об использовании hash таблиц при фильтрации трафика (fast hash tables), использование которых позволяет существенно увеличить производительность.

И снова здравствуйте!

Продолжим обзор модулей FreeBSD netgraph.
Сегодня у нас в гостях ng_ipfw, ng_one2many и старый друг ng_netflow.
С их помощью попробуем посчитать трафик по определенным условиям и посмотрим как это можно использовать на практике.

Что за модули?

ng_ipfw — модуль, создающий интерфейс для доступа к подсистеме netgraph из фаервола IPFW. При загрузке в ядро, модуль автоматически создает свой узел в пространстве подсистемы netgraph с именем «ipfw:», и может присутствовать только в единственном экземпляре. Ng_ipfw принимает подключения к произвольным номерным хукам, номера хуков указываются в правилах ipfw. Каждый входящий в модуль пакет тэгируется по нескольким параметрам (ipfw правило, интерфейс, направление), для того чтобы его можно было идентифицировать при возврате обратно в ipfw. Не тэгированные пакеты, возвращаемые в фаервол, уничтожаются. Контрольных сообщений модуль не принимает.

Всем привет.

Думаю многим системным администраторам, работающим с FreeBSD, известно о существовании ядерной подсистемы Netgraph. Но не многие знают/понимают как это работает, и что из этого можно построить.

Расскажу что это такое, а также разберу на простом примере сборку Ethernet моста через интернет.

С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.

Небольшое введение

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

Постановка задачи

Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.

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

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

Если к базе данных обращаться из нескольких соединений и проводить изменения, то возникновение конфликтов — это лишь вопрос времени и везения.

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

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Возможно, кому-то эта задача покажется пустяковой, но лично я потратил на неё несколько часов, израсходовав подсказки «мнение зала» и «звонок другу». Зачем я это решал? Ответ прост: мне действительно нужно было реализовать такой подход для моего небольшого сайтика Одио.ру. Если вкратце, то там публикуются записи с самых разных сайтов, стягиваемые по RSS. Сложность в том, что даты в этих записях могут полностью совпадать (даже в рамках одной ленты), при этом последовательность ID имеет смысл только в рамках одной ленты, но никак не влияет на весь поток записей. Итак, давайте перейдем к условиям задачи.

Когда я в очередной раз использовал LogParser, то чтобы проникнуться и чужим опытом, ввел его название в поиск на Хабре. Как результат — сообщение «Удивительно, но поиск не дал результатов». Вот уж воистину удивительно, когда столь интересный инструмент обойден вниманием. Пришла пора восполнить этот пробел. Итак, встречайте LogParser. Маленькая, но чертовски полезная утилита для любителей SQL.

Из названия инструмента, казалось бы, очень непросто понять, что он делает в разделе SQL. А правда заключается в том, что он такой же LogParser, как и ChartGenerator. В то смысле, что он справляется с обоими задачами с одинаковыми успехом. В целом я бы его охарактеризовал как SQL-процессор гетерогенных данных. Концепция работы в общем такова, что он берет данные из некоторого формата и преобразует их в табличный вид (собственно говоря, только на этом этапе и выполняется иногда парсинг). Затем, посредством выполнения над этими табличными данными некоторого SQL-запроса формирует таблицу с результатом и сохраняет ее опять же в некотором формате. Если коротко, то цепочка выглядит как подготовка входных данных->SQL-процессинг->генерация выходных данных.

Ваша компания медленно, но верно выходит из кризиса, открываются новые офисы или магазины, появляются рабочие места — растет количество сотрудников. Вы, как системный администратор, уже позаботились об этом заранее и внедрили Active Directory или LDAP. Фух, проблем с учетками больше нет.
Но в нашем деле проблемы не заставляют себя долго ждать: вчера взяли пять бухгалтеров, троих продавцов и кладовщика. Всем нужна корпоративная электропочта. Отлично, если вы продумали достаточное количество ходов наперед и вместе с установкой AD перевели авторизацию почтосервера на домен. Тратим пять минут на добавление учеток, вписываем правильные данные, отдаем вашим помошникам — они настроят почтоклиенты этим сотрудникам. Но как теперь сообщить новые адреса всем остальным сотрудникам? Написать каждому письмо? Скинуть в чат? Слишком много работы для среднестатистического и вечно ленящегося сисадмина.

Я вижу два удобных пути решения: можно уговорить почтоклиенты бегать в AD за адресами, а можно показывать их на корпоративном сайте. Сегодня мы попробуем обеспечить корпоративный веб-сайт нужной информацией — будем выводить список сотрудников и их почтовые адреса, а за данными ходить к участковому прямо в Active Directory.

ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.

Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании.
Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.

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