Programming

С уважением к пользователю, команда ZAYAC!

По всем вашим вопросам – добро пожаловать в комментарии!

Техническая база на переломе тысячелетий

Воспоминания с товарищами за рюмкой чая. На дворе стоял 2000 год. Старые времена плавно погружаются в Лету вместе с осколками предыдущей империи, по телевизору идут "Звёздный час" и "Сам себе режиссёр", я потихоньку разжёвываю кусочки от гранита науки. В те жутковатые годы купить что-то из деталей для создания чего-то электронного, для души, было не такой уж лёгкой задачей.

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

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

Это потом, в эпоху Интернета, технопарков, кода, написанного нейросетями и 3D-принтеров, всё для этого вы сможете найти в продаже, прямо не сходя с дивана. Хочешь — закажи печатную плату, а хочешь — выточку или выплавку детали под твои нужды, хоть с со своим выгравированным на них именем. Да хоть с доставкой прямо вам на диван. Вот только уже с одной разницей: почти всё, что вы захотите сделать сами, уже продаётся в магазине. Для этого не будет необходимости.

Проще всего какие-то детали можно было раздобыть, разобрав какое-то сломанное устройство, а также на радиорынках, например, на Митинском, Савёловском или Царицынском. Иногда что-то появлялось в магазинах электротоваров. Как-то я узнал, что в других странах есть целые магазины и торговые центры, в которых продаются товары для хобби под названием DIY. Меня тогда поразил большой контраст с нашей повседневностью, потому что найти все для своего устройства в одном месте вообще не было возможности, и магазинов "Сделай сам" (как и переводится DIY) у нас просто не существовало.

В то время у одного из нас только-только появился первый персональный компьютер. Это был Compaq Presario, моноблок с процессором SX486 и памятью, кажется, 8 мегабайт. Управлялся он ОС Windows 95. Windows 98 на нём подтормаживал.

В моноблоке были встроенные микрофон и динамики, CD-ROM, дисковод для дискет 1.44" и модем. Модем позволял устанавливать связь с Интернетом на скорости 33,6kbps. Очень удобно, когда в настольном компьютере есть всё нужное для работы и развлечений, но уже на то время он был устаревшим. Мне приходилось подолгу искать игры, которые на нём бы пошли. Игры тогда продавались с прилавков, покрытых картонками, на радиорынках. Их продавали, разумеется, как "лицензионные", а по факту, просто скопированные на болванки, крякнутые и с буклетом, напечатанным на принтере. Среди них, надо сказать, встречались и прекрасного качества типографские буклеты, аккуратно вложенные в компакт-диск. В них подробно, пошагово, рассказывалось, как правильно взломать игру прилагающимся на диске файлом.

Что касается подключения к Интернет, то в то время провайдеры продавали доступ во Всемирную Сеть по времени: например, один доллар в минуту. Похоже, что Интернета на всех не хватало, иначе как объяснить, что доступ к Сети был "по талонам" — провайдеры продавали карточки, по телефону, указанному на которых, надо было звонить со своего модема, а номинал был на них указан в долларах. На них под стираемым, как на лотерейных билетах, слоем, были написаны логин и пароль для доступа, который расходовался быстрее, чем сейчас остывает твой чай.

Анекдот про чай был придуман позже, уже при доступном проводном Интернете, поскольку по карточкам в Интернете столько просидеть было совершенно невероятно: Подключился, нашёл что-то, скопировал себе на диск, отключаешься и запускаешь программу или читаешь.

Как остудить горячий чай? Надо включить компьютер, залезть в интернет и бац! Чай остыл.

Ещё более точную информацию по ценам я помню из расклеенных повсюду объявления в 1997 году:

"Интернет по самой низкой цене: 1 цент в секунду!"

Ограничивающий фактор

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

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

Прототип

Сейчас я вижу в качестве конструктора, который почему-то используется для создания прототипов самодвижущихся устройств чаще всего, Lego. Мне же кажется, что металлические конструкторы, наподобие тех, что были доступны Советском Союзе, с множеством деталек, крепящихся с помощью болтов и гаек, подходят для этого больше. Сравнительно недавно для Лего стали появляться подключаемые к собранным из него фигурам электронные компоненты, типа моторов, реостатов, редукторов и различных датчиков. Однако детали металлических конструкторов поставляются самых разных форм, поэтому к ним можно прикручивать обычные электронные компоненты и крепить теми же болтами прямо из набора, и тут ты уже не ограничен в своём творчестве тем, что тебе положили в коробку.

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

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

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

Мотор был вот такой:

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

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

В сложившейся ситуации, после долгих раздумий и испытаний нескольких различных вариантов, было принято решение сделать редуктор в виде шкивов. Для этого я взял самые большие колёса, имевшиеся в наборе конструктора Юность-3:

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

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

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

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

Раму корпуса и оси я взял из конструктора "Механик". Получился самодвижущаяся машина в стиле , с огромными ведущими колёсами и маленькими вспомогательными.

Сходство с ним получилось не спроста — ведь его создатель тоже пытался получить преимущество гусениц за счёт свойств проходимости больших колёс.

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

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

Смена положения вещей

К концу года для учёбы мне требовался более современный компьютер, и поэтому у меня появился компьютер совершенно другого уровня: Pentium Pro с частотой 200МГц, оперативкой в 32Мб и жёстким диском на 850Мб. В корпусе АТ, а не ATX, как сейчас. Ну, вы помните эту надпись. Оххх...., были ВРЕМЕНА!)

Скорость его работы просто поражала: Internet Explorer 3 грузился за секунды, почти без тормозов работал Office 97, шустро открывался почтовый клиент The Bat, а Windows 98 устанавливался в несколько раз быстрей! Ведь мы же все знаем, что это был тогда важный параметр, потому что раз в несколько месяцев, или даже недель — кому как — приходило время, когда Windows, как ни крути, должен был быть переустановлен.

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

А через некоторое время завелось у меня, для того времени, что-то ещё, совершенно невероятное. Штука, которую было совершенно не понятно как применить. Чудо-чудное, диво-дивное: веб-камера Kensington Videocam VGA Digital PC Camera производства 1999 года.

Для меня это было первое цифровое устройство, с которого можно было захватывать изображение прямо на компьютер. Да и, наверное, первое из подключающихся по USB. Тогда больше ни для чего этот порт я применить не мог, так как флешки, если уже и были, то только появлялись, и были дико дорогими. Да и мы до сих пор везде пользовались дискетами. Помню, я еще, в дополнение, устанавливал в него дисковод 5,25" для того, чтобы брать у преподавателей в институте программы, писавшиеся для зачётов и курсовых в прошлые годы.

Её максимальное разрешение было 400х300, но это только для фотографий. Видео она могла снимать лишь в 320х240 или 352х288. Благодаря ей, я сегодня могу добавить в эту статью фотографии. У меня здесь, а мы уже в 2001 году, фотки для этой статьи, по вашим меркам, не очень.

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

Подключение к компьютеру

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

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

Программа

В качестве языка программирования я использовал Visual Basic. Под Windows 95 и 98 в нём можно было управлять LPT. Под Windows XP было уже нельзя. Поскольку я не торопился менять Windows 98 на другую ОС, то у меня всё работало, а, возможно, я тогда уже установил Windows Millenium.

Я стал искать информацию о работе с различными портами. Скачав статьи по теме доступа к портам, скачанными с сайтов — а, так как подключение было по Dial-Up, то я их скачивал на жёсткий диск и с него открывал — и всякими справочниками по Visual-Basic в различных форматах, среди которых встречались и TXT, и HTM, и CHM. Одним из самых известных сайтов был VBstreets.ru, где было публиковалось больше всего полезной для меня, на тот момент, информации.

В этом языке есть библиотека для работы с портами ввода/вывода: "vbio32.dll". Используя её, я предпринял первую попытку подать сигналы на LPT. Сначала я просто выводил числа на порт. Я поместил в программу, открывающуюся сейчас из папки 2001 года, поле для ввода числа и две кнопки для посылки числа на порт и снова сброса его на ноль.

Вводишь число, нажимаешь кнопку — и число появляется на выводах LPT-порта в двоичном коде. Его можно пощупать тестером.

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

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

И у некоторых файлов поменялась дата последнего изменения файла: после то ли какого-то сбоя жёсткого диска, то ли после вируса-шифровальщика, не помню когда, некоторые даты поменялись на 31.01.2020 и исчезли длинные имена файлов, оставив после нескольких знаков "~1". Зашифровать он успел не всё, когда я заметил подозрительную активность жёсткого диска, я сразу выключил компьютер. Однако после лечения Доктором Вебом или Касперским, даты некоторых исполняемых файлов просто стали неправильными. Похоже, как раз, я "поймал" вирус в 2008 году, так как антивирус расшифровывал и пересоздавал спасённые файлы.

Запрограммировать, как надо, вывод на LPT у меня получилось не сразу, но я на каком-то сайте нашёл пример. Программу, написанную неким Алексом Новожиловым, которая выводила на порт последовательности чисел. Я увидел, что она написана, как раз, на VB и это придало мне сил, к тому же, как раз в ней была нужная мне библиотека "vbio32.dll".

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

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

Первые попытки выхода на белый свет

После широкого распространения персональных компьютеров, Савёловский рынок окончательно перепрофилировался в компьютерный, и там я, для дальнейшего улучшения условий учёбы, с помощью друга и семисот долларов, приобрёл нового помощника — Duron 700, с памятью 128Мб и видеокартой GeForce MX200. В него я переставил модем из Pentium Pro-200.

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

У всех уже была ICQ, но в ней можно было только писать текст и, уже несколько позже, пересылать файлы. Ещё был IRC, но он был менее удобный. После долгих поисков в Интернете, я нашёл две программы, с помощью которой можно было общаться в Интернете. Одна представляла собой прямое соединение пользователей по IP и позволяла общаться, в отличие от ICQ, голосом а тем, у кого есть камера, и с видео. Она называлась Microsoft NetMeeting.

Вторая звалась MSN Messenger. В нём можно было найти различные группы, где общались иностранцы, в основном, из США, под названием MSN Groups или MSN Chat rooms. Они обсуждали что-то или сидели в чатах просто так и шутили на английском. Однако в некоторых чат-группах люди уже использовали веб-камеры.

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

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

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

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

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

Хотя он просил меня этого не делать и уверял, что у нас получится разговор, я отключился. Я потом уже понял, то о чём он меня просил и что рассказывал:

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

Я поколебался и "повесил трубку".

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

Я был потрясён тем, что собеседника можно не только слышать, но и видеть. Напомню, что тогда самым популярным мессенджером была ICQ, в ней люди посылали свой адрес электронной почты, и уже по Email пересылали фотки с плёночного фотоаппарата, отсканированные сканером. По телевизору шла программа "Сам себе режиссёр", которая состояла из были видео, снятых на камеры с магнитными кассетами, и которые её участники присылали в телестудию по обычной почте. А тут: ты сам видишь окружение, природу, людей не только рядом с тобой, но и из разных стран! Я поначалу просил собеседников просто помахать в камеру или покрутить перед ней кружкой или книжкой, настолько казалось невероятным видеть собеседника.

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

— Зачем ты на меня смотришь?

Я сказал, что просто хочу пообщаться. А на кого мне еще смотреть?

Он сказал:

— Смотри на девушек!

"Чёрт возьми, — подумал я тогда, —наверное, в будущем у веб-камер будут и правда стоящие применения".

Через другую программу, NetMeeting, можно было подключиться к собеседнику напрямую, введя IP-адрес. Мы попробовали общаться так через камеру с моим другом.

Для того, чтобы поговорить с видео, мы созванивались по модему через обычную телефонную линию, потом смотрели свой IP через Winipcfg, запускали NetMeeting. Один вводил IP другого, и так устанавливался видеозвонок. По-русски говорить было проще, чем по-английски, и, казалось бы, звони — не хочу, но больше созваниваться из друзей было не с кем. К тому же, нельзя было надолго занимать общий телефон, а разговаривать по телефону и лазить в Интернете в одно и то же время было невозможно. Если во время связи снять трубку телефона, то в ней будет слышен писк модемов.

Неожиданная находка и связующее звено

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

В поисках подходящих микросхем я обыскал весь Интернет образца 2001 года, скачал каталоги в виде DOS-программ, даже сходил в библиотеку, но и там ничего про микросхемы, подходящие мне, не было. В отношении новых программ и программирования вообще, время тогда не летело так быстро, и программы могли писаться годами. Передо мной стояли примеры работ разных преподавателей, аспирантов и дипломников кафедры, когда вынашивали идею, разрабатывали подход к её решению, план ПО, по нескольку лет. Каталоги микросхем под DOS, которые я скачал, оказались сильно устаревшими.

Показать её работу, увы, не получится.

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

— Не может быть!

— Да правда. Пошли, проверим!

И мы пошли проверять. Этим магазином, так стремительно ворвавшимся в мир творчества и радиолюбителей, и оказавшимся, уже после, лучше западных "Сделай сам", был Chip&Dip. Сначала там, насколько я сейчас помню, продавались только микросхемы, светодиоды, транзисторы-резисторы всех номиналов, но не было такого ассортимента, как сейчас. И таким образом, благодаря сарафанному радио, я нашёл недостающий элемент для моего компьютерного управления. На меня, поблёскивая глянцем прозрачного пластика, смотрел компакт-диск с названием "Микросхемы для управления электродвигателями".

В виду ограничения фотоматериалов

ПРОДОЛЖЕНИЕ СЛЕДУЕТ...

Во-вторых, а это было самое сложное для меня, отправка уведомлений по времени, каждому пользователю. Здесь пришлось подумать, есть библиотека "schedule" она позволяет выполнять определённую функцию в определённое время.

Написал функцию, которая сверяет текущее время и время, которые установили себе пользователи, если есть совпадения отправляет настроенное сообщение. Решено.

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

Вот ссылка на первую версию бота, кому интересно, можно глянуть весь код там. Второю версия пока не выкладывал.

P.S. Бот функционирует. Доступен в поиске телеграм по: @pytginform_bot

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

В крупных компаниях слой интеграций между ИТ-системами часто становится источником множества проблем — от потерь данных до перегрузок и сбоев. Эти задачи помогают решать инструменты вроде Apache Kafka или других брокеров сообщений.

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

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

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

В моменты «катаклизмов» — пиковых нагрузок или массовых сбоев — нужен мощный инструмент, способный взять управление на себя. Таким инструментом становится Apache Kafka, выступающая в роли координатора движения: она разгружает трафик, организует потоки, даёт системам передышку.

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

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

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

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

Важно понимать: брокер никак не помогает выявить причины сбоев или перегрузок, особенно в периоды пиков вроде «чёрной пятницы». Он не анализирует природу ошибок — и часто проблемы продолжают возникать, даже если брокер присутствует в системе.

Что можно использовать вместе с Kafka, чтобы полностью устранить сложности, связанные с интеграцией между системами?

1. Kafka
– Сглаживает пиковую нагрузку на ИТ-системы
– Снижает риск потерь данных
– Асинхронность — системам не требуется постоянное соединение

2. ESB с использованием Kafka
– Исключает потери информации
– Существенно уменьшает нагрузку на ИТ
– Упрощает построение бизнес-аналитики (BI)

3. Архитектура слабой связанности через ESB и Kafka
– Позволяет заменять системы мгновенно
– Существенно снижает ИТ-расходы
– Легко передаётся внешней ИТ-команде
– Данные высокого качества = удобная бизнес-аналитика

2. ESB с Kafka внутри
Для достижения перечисленных выгод важно осознавать, что ни одна из матрешек не может функционировать обособленно от остальных

Что именно представляет собой ESB?

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

По сути, ESB — это как переводчик, который точно передаёт смысл сказанного с учётом культурных особенностей. Системы — словно жители разных стран. При этом ESB может взаимодействовать даже с группой туристов — каждый говорит на своём языке, но через одного переводчика, который передаёт всё сказанное. В автобусе сохраняется полное взаимопонимание. Более того, переводчик сохраняет контекст всех разговоров, и при необходимости любой спор можно восстановить по памяти, включая весь диалог.

Качественные данные — это логичный результат архитектуры слабой связанности, реализованной через ESB. Это достигается за счёт строгих правил трансформации и чётко заданных протоколов обмена между системами.

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

ИТ становится помощником бизнеса, а не его тормозом.

В чём разница между подходом слабой связанности и прямыми интеграциями или взаимодействием через брокер? И по какой причине информация теряет точность и становится некачественной:

Данные можно передавать напрямую и преобразовывать их внутри самих систем.

Ключевой момент — логика преобразования: при любом изменении в одной системе — вторая должна «подстроиться». Сначала это выглядит продуктивно: быстро связались по API — данные пошли, отлично!

Но без общего слоя интеграции и единых стандартов, без применения слабой связанности, всё начинает разваливаться. Типовая ситуация такова:
Множество ИТ-систем
У каждой — своя логика преобразования и передачи
Системы могут создавать десятки и сотни сущностей с ошибочными данными — это влечёт за собой ещё больше сбоев и некачественных данных
Добавляются средства, призванные «навести порядок» в данных — MDM, PIM. Но они устраняют последствия, а не причины
В результате одна система должна учитывать трансформации и связи всех остальных.

Это и есть жёсткая связанность: узел сложных зависимостей, в которых тяжело разобраться даже внутри команды, не говоря о внешних подрядчиках. Появляется эффект “замкнутой системы”, в которой любая правка — отдельный проект.

Поэтому внедрение одного только брокера сообщений вроде Kafka или даже ESB без концепции слабой связанности — это как принять цитрамон от тяжёлого похмелья. Станет немного легче — но причина так и останется нетронутой.

ESB обеспечивает чистые данные и простую бизнес-аналитику (BI)!

Для двух различных систем одна и та же товарная карточка может означать разные структуры данных. С помощью ESB можно просто организовать преобразование информации с учетом особенностей каждой из систем. Это снижает нагрузку и исключает ошибки из-за некорректного формата данных при передаче.

В хранилище данных (DWH) информация сохраняется в структурированном виде, а в Data Lake — в исходном. Всё это прозрачно и четко организовано. Система бизнес-аналитики (BI) легко формирует нужные отчеты. Подключение самой BI-системы происходит через единый интеграционный слой ESB.

ESB обеспечивает надёжную передачу сообщений между системами.

ESB самостоятельно отслеживает доступность сети и подключённых систем. Он инициирует забор данных и гарантирует их доставку. Также он выполняет преобразование данных в нужный формат для каждой системы. В такой архитектуре логика ETL выступает как мозг всей схемы, а Kafka или другой брокер выполняют функции передачи и приёма.

ESB позволяет сразу обнаруживать ошибки в момент их появления.

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

ESB — это существенное снижение нагрузки на системы.

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

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

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

3. Слабая связность реализуется через ESB, в составе которой используется Kafka.

Почему использование ESB или Kafka отдельно, без подхода слабой связности, не приводит к нужному эффекту?

Всё сказанное выше полезно, но чтобы действительно создать ИТ-контур, где можно быстро менять системы, сильно снижать ИТ-затраты и без труда передавать поддержку новой команде, необходима слабая связанность. Только с таким подходом возможна точная, понятная и лёгкая в использовании бизнес-аналитика. Это становится реальностью при построении слабой связанности одновременно на уровне архитектуры и организации — через грамотно созданную корпоративную шину (ESB), внутри которой Kafka может играть роль транспортного слоя.

Просто внедрять точечные «решения» в рамках ИТ-структуры неэффективно, ведь цифровая модель бизнеса всё дальше уходит от реальной картины. Между настоящими процессами и тем, что отображается в ИТ-системах, возникает всё больший разрыв.

Можно сколько угодно менять подрядчиков, внедрять новые инструменты и популярные методы, но без соответствия между реальностью и её цифровым отражением всё это лишь усиливает хаос. Новые «решения» накладываются на уже искажённую структуру, создавая эффект рубцов от старых вмешательств. Так начинается цифровая эрозия, когда искажения накапливаются, и ИТ перестаёт отражать то, как бизнес работает на самом деле.

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

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

Если нет единого архитектора, который видит общую картину и управляет связанностью систем, весь ИТ-ландшафт превращается в спутанный клубок: вроде работает, но неуклюже, перегрет и полон уязвимостей. Это похоже на спортсмена, который тренируется сам — он может добиться прогресса, но без тренера не будет стабильного роста и выдающихся результатов.

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

Вот и позитивные вести!

Как правило, внедрение ESB не начинается с глобальной перестройки всех IT-систем. Обычно всё начинается с самой острой и ощутимой проблемы. Допустим, отдел заказов перегружен: теряются заявки, сотрудники не справляются с объёмом ручной обработки — именно туда и направляется внимание. С помощью ESB создаётся слабосвязанная интеграция: автоматизируются приём, преобразование и передача данных. Через 2–3 месяца хаос превращается в стабильный поток, который легко масштабировать. Бизнес видит результат: «работает!» — без капитального ремонта, без глобального переписывания, просто благодаря правильной архитектуре. Это как островок порядка посреди шторма интеграций — корабли заходят, разгружаются, всё чётко разложено, никто не сталкивается. А капитан продолжает путь, не отвлекаясь на рутину.

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

ESB - преимущества для управления бизнесом

ESB - преимущества для построения IT-контура бизнеса

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

Добавлена анимация поиска собеседника.

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

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

Наконец-то, был реализован функционал уведомления пользователей через бота.

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

Первое, можно будет реализовать фичу, что если пользователям понравилось общаться друг с другом, то по запросу отдаются данные из тг, чтобы там пользователи продолжили общение.

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

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

На этом все, котаны, ребята, бобрята и пацантре.

Не забываем,  потестить чат-рулетку  можно по ссылке t.me/Socionyx_Bot/socionyx.

Кроме того, ссылка на мой telegram канал t.me/socionyxchannel, где я пишу про будни разработчика.

По приезду мы начали обзванивать арендодателей квартир — денег было очень мало. Даже пришлось сдать всё золото, какое было... После нудных обзвонов и просмотров квартир мы очень сильно устали: ни одна квартира не была пригодна для жилья. Но случилось чудо — под вечер, когда уже смеркалось, мы позвонили по удачному объявлению и нашли квартиру — очень приличную и за небольшие деньги. Квартира, кстати, была на улице Музыкальной. Хозяева оказались хорошими людьми.

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

Казалось бы, при чём тут вообще Java? Когда пойдёт рассказ об этом? Всё по порядку.

Через некоторое время моей супруге предложили должность в новом городе. Так как она занималась подбором IT-специалистов, её рассмотрели как кандидата и пригласили на собеседование в город Иннополис. Мы впервые тогда услышали об этом городе и начали изучать информацию по нему и были приятно удивлены. Сама мысль, что город новый, давала какую-то надежду. Оказалось, город совсем молодой, стройка шла полным ходом. По всей России приглашали IT-спецов с релокацией и разными плюшками. В итоге супругу взяли на работу, и мы переехали.

После переезда я сильно задумался: а там ли я работаю, где хочу? Всю жизнь на заводе? Не, это не про меня. И я начал искать IT-курсы с нуля. Изучая рынок, понял, что самый востребованный язык — это Java. Нашёл курсы молодого бойца Java в КФУ (Казанский (Приволжский) федеральный университет). Учёба сперва пошла довольно плавно, но со временем я заметил, что теряю фокус и не могу сфокусировать себя по полной. Постоянные вопросы самому себе и преподавателям — как это всё работает — не давали никакого результата, я чувствовал, что упёрся в стену, и никто не мог объяснить мне и поставить на путь истинный, дать конкретную базу по программированию. В итоге ничего хорошего не произошло: я потерял веру в себя, был просто полностью опустошён из-за этого. Вдобавок меня ещё и сократили с работы. Начался самый грустный период, в который любая попытка взяться за программирование самостоятельно, даже просто выучить БАЗУ — просто БАЗУ, Карл! — заканчивалась ничем. Не понимая, что происходит, я просто опустил руки и забил на это.

В итоге, не реализовав себя как IT-специалиста, и с текущей работы меня тоже попёрли — мы уехали обратно на родину.

P.S. Если увижу интерес — продолжу дальше свой рассказ.