Сергей Бодров serbod

Да, эта штука сможет работать по модему или через общую папку (filebox). Вернее, пока только TCP или UDP, но наработки уже есть. Функционал IM на уровне ранней аськи — только обмен сообщениями и контактами. Но внутри есть обмен между узлами, групповые чаты (аналог IRC), почта, файлы.

Однажды мне поставили задачу — на офисно-бытовом железе (P4-2GHz, 1Gb RAM) формировать отчеты по данным из десятка филиалов, которые представлены в виде сотен отдельных баз данных по тысяче файлов каждая. Это были базы 1С-Торговля 7.7 (dbf), обрезаные по месяцам, которые приезжали из филиалов на флешках. Суммарный объем измерялся сотнями гигабайт, только на копирование уходило больше часа. Но отчеты за 3 года по всем филиалам выполнялись за несколько минут. Как?



Очень просто. Была создана супербаза. Нет, это не одна большая общая база, куда слиты данные со всех баз. Я пробовал, фигня получается. Слишком большие объемы, слишком много проблем с синхронизацией данных. Все гораздо проще…

С 28.07.2011 по 31.07.2011 рядом с городом Орёл пройдет всероссийский слёт сисадминов, посвященный празднованию дня системного администратора.

Жила-была технология FTN aka FidoNet. Она и сейчас живет где-то на пыльных системниках, но когда интернеты в России были маленькими, это была весьма популярная технология обмена сообщениями.

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

Стандарт OSSIRIUS SCS 702 задаёт порядок применения компактных настенных шкафчиков при построении структурированных кабельных систем коммерческих зданий, оптимизирован под задачи обслуживания объектов до 130 000 кв.м. (при охвате в 368 метров) и до 1000 пользователей, что определяет набор правил, решений и технологий, вошедших в него. При этом максимальное число пользователей ограничивается 50 000.

Стандарт OSSIRIUS SCS 702 является открытым и независимым. Положения стандарта формируются и изменяются исключительно в ходе публичных обсуждений в пределах, заданных положениями международных стандартов ИСО/МЭК 11801, ANSI/TIA/EIA-568B и российским стандартом ГОСТ Р 53246-2008.

Некоторые утверждают, что серьезные ERP-системы имеют 100% внедряемость и поддержку производителя.

На практике это обычно выглядит так:

Пролог — охмурение. К гендиру/заму/главбуху еженедельно (а то и ежедневно) ходят люди с горящим взором и вдохновенно рассказывают о чудесах такой-то системы, демонстрируя красивую полиграфию. Сулят счастье, радость, откаты и путевки на курорты. Называют громкие имена и бренды. Контракт подписан.

Идея проста — подключаем к программе внешний модуль через pipe (STDIO или TCP/IP).
Обмен текстовыми командами в формате командной строки: <команда> [параметр [параметр [...]]]<CR/LF>
В качестве параметров могут быть любые сериализованные данные. Как в протоколах POP3/SMTP.

Таким образом, можно подключать к программе, например, проверку синтаксиса или переводчик, который реально находится где-то в интернете. Можно подключать плагины, написанные на любых скриптовых языках (батники, например) и платформах. Можно даже подключить программу саму к себе. =)

Весь нюанс в том, чтобы использовать пайпы как API для плагинов (вместо прямого вызова кода), а не для фильтров. Идея далеко не нова, но почему-то очень редко используется.

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

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

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

Вообщем, идея протокола такая — он позволяет строить распределенную децентрализованую сеть обмена сообщениями, предоставляющую различные сервисы. Сеть должна строиться и настраиваться автоматически, при минимальном вмешательстве со стороны пользователя. По техническим причинам, автонастройка допустима только в одном сегменте (256 узлов), но с учетом того, что каждый узел может обслуживать до 2^32 клиентов, это более, чем достаточно.



Некоторые принципы и идеи позаимствованы из FTN (фидонет). Что-то придумано с нуля или по образу и подобию уже существующих систем. Многое предстоит придумать и реализовать, а потом много раз переделывать и дополнять. Не знаю, сколько это займет времени… Но попробовать стОит.

Вот такой текст я разместил на своем сайте год назад. И вот что из этого получилось…