Всё работает! Что вам ещё надо? — Антон Дорошкевич, PGConf.СПб 2023

За 6 лет моего опыта работы с 1С на PostgreSQL СУБД прошла огромный путь, и хочется осветить этот путь, чтобы понять, какой огромный прогресс уже достигнут. Но, как всегда, пользователям всего мало, так что помимо уже пройденного пути в докладе будут освещены пожелания к СУБД с точки зрения эксплуатации, а так же даны обходные пути решения.

https://youtu.be/iM-wVbhf8-E?si=Rbmc8E20E23mIy90

Доклад известного специалиста по PostgreSQL в связке с 1С. Рекомендуется всем к ознакомлению. У кого нет доступа к YouTube выкладываю отдельным файлом.

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

А надо было всего-лишь подстелить соломки...

Настраиваем централизованное управление электропитанием в сети при помощи NUT

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

Действительно, если питание пропадет надолго, то после разрядки батарей ИБП ваши системы аварийно завершат работу. Избежать этого позволяют модели, имеющие обратную связь, но, чтобы использовать эти возможности нам потребуется система управления электропитанием и сегодня мы расскажем об открытом и бесплатном продукте - NUT (Network UPS Tools).

https://interface31.ru/tech_it/2022/08/nastraivaem-centralizovannoe-upravlenie-elektropitaniem-v-seti-pri-pomoshhi-nut.html

Переносим контент на новый сайт, заодно заново перечитываем некоторые статьи

🔹 WD VelociRaptor - пожалуй, самый быстрый жесткий диск

Western Digital VelociRaptor можно без преувеличения назвать легендарной серией HDD и объектом мечтания многих пользователей. Как и у любой топовой "железки" основным сдерживающим фактором была и остается цена. Однако сегодня стоимость младших моделей линейки не сказать, что демократична, но вполне приемлема и поэтому мы решили протестировать один из таких дисков.

Статья от октября 2012 года, интересно было вернуться в те времена и посмотреть на одного из лидеров лагеря жестких дисков, тогда еще на равных конкурировавшем с массовыми SSD.

А теперь? Самый дешевый SATA SSD положит его на лопатки. Такое вот развитие технологий, да и времена поменялись, сегодня иные требования и иные критерии оценки накопителей.

​​Как сэкономить на регистрации и продлении доменов

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

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

Но если подойти к вопросу грамотно, то можно существенно экономить на регистрации и продлении доменов, а также не пропускать привлекательных предложений.

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

Прежде всего у каждой доменной зоны есть администратор, для RU и РФ — это Координационный центр доменов .RU/.РФ, сам он не выдает домены, но осуществляет общее управление зонами и осуществляет аккредитацию регистраторов.

Количество регистраторов невелико, всего в списке их 131 организация, но крупных, обслуживающих более 10 000 доменных имен ровно 20. Полный их список приведен тут: https://cctld.ru/domains/reg/

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

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

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

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

Сейчас средняя стоимость продления домена RU у регистраторов составляет примерно 600 руб. за домен. Если же брать партнеров, то продлить домен у них в среднем обойдется в 200 руб. Как говорится – почувствуйте разницу.

Что касается приобретения, то зарегистрировать домен можно вообще за копейки, а то и бесплатно. Например, самая вкусная цена на домены RU сегодня у Джино, всего 39 руб., правда за продление с вас уже попросят стандартные 589 руб.

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

Поэтому покупаете домены, где вам удобно, а затем в течении года переносите их к партнеру с низкими ценами и продляете их у него.

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

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

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

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

Если регистратор прекратил свое существование или отказывает вам в переносе, то AuthInfo-код можно запросить у Координационного центра.

Залить железом

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

Начнем с самого способа – он прост, как мычание. Его смысл – если вам не хватает аппаратных ресурсов, то просто пойдите и купите их.

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

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

Почему? Потому что дает бизнесу четкие суммы и сроки. Если у вас есть мониторинг (а он же есть?), то нет никакого труда выявить тренды и сделать прогнозы, тем более что с такими задачами прекрасно справляется ИИ. После чего вы говорите: нужно купить то и это, сумма такая, на год-полтора вопрос закроем.

Отлично. Если проблема решается деньгами – то это не проблема, а просто статья затрат. Бизнес понимает что именно он сейчас покупает и на какой период эти затраты следует относить.

А вот тропа оптимизации куда более скользкая. Там нет ответа сколько это будет стоить и что мы в итоге получим. Потому что для начала надо оплатить аудит и анализ. Стоит это будет XXXX руб./час, оплатить надо минимум NN часов.

Ну а по факту вы получите просто анализ вашей инфраструктуры и рекомендации. И не факт, что вердикт не будет звучать как: купите новое железо.

Оптимизация, тоже не дешевое удовольствие и хорошо если разовое. Иначе бизнес попадает в зависимость от оптимизаторов и их поддержки. Особенно это касается оптимизации коробочных продуктов с регулярными обновлениями, например, 1С:Предприятие.

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

А теперь снова посмотрим на это все со стороны бизнеса. В первом случае ему предлагают потратить некоторую сумму денег здесь и сейчас и закрыть проблему на год-полтора. Потом повторить.

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

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

Ладно, оставим аутсорс, возьмем нужного специалиста в штат. А сколько будет стоит этот специалист? Явно не дешево, так что это та же самая ежемесячная «дань», только несколько в ином виде.

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

Но вы не подумайте, мы вовсе не против оптимизаций. Но подходить к этому вопросу нужно трезво и взвешенно.

Если проблему можно залить железом – просто залейте. Особенно если это решает проблему на продолжительный временной отрезок.

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

🔥 Готов принять настоящий бизнес-вызов? Участвуй в VTB API hackathon 2025!

Когда: 27 октября – 22 ноября
Формат: онлайн + офлайн

⚡ В 2025 году еще больше возможностей: реальные и практические кейсы, общение с экспертами, карьерные консультации от HR-специалистов и призовой фонд 2 млн ₽

Выбери свой трек из 3 актуальных направлений для открытого банкинга:
🔹 Мультибанк: единый интерфейс финансового сервиса
🔹 Защита API: автоматический анализ уязвимостей
🔹 «Оркестр» из API: анализ и тестирование бизнес-процессов

Участвуй, особенно если ты:
- Студент или выпускник технического вуза
- Backend/Frontend-разработчик
- Аналитик, QA, AQA и SDET
- Product/Project-менеджер
- Системный архитектор
- Специалист по ИБ

📌 Подробнее о треках и условиях участия — на сайте хакатона!

➡️ Регистрируйся до 2 ноября, 23:59 (МСК) по ссылке.

​​Сказка о потерянном времени

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

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

1️⃣ На первом месте с огромным отрывом стоят локальные базы знаний, чаще всего выполненные на Wiki-движках, но абсолютно необязательно.

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

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

2️⃣ Второе место – это всякие внутренние порталы. В теории это видится некой точкой консолидации, в которой размещают новости, объявления, внутренние документы, инструкции и т.д. и т.п.

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

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

3️⃣ Третье место по ненужности занимает, как это не странно, мониторинг. Но здесь тоже все достаточно прозаично. Ожидания не совпадают с реальностью. Многие представляют мониторинг как красивые графики и диаграммы, которые можно вывести на отдельный монитор и с гордостью показывать начальству.

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

4️⃣ Четвертое место, хотя можно и поменять местами с мониторингом, это системы учета заявок и инцидентов, тот же GLPI. Но мы все-таки вынесли его на четвертое, потому что внедряют его уже более-менее осознанно и данные системы менее популярны у начинающих, нежели мониторинги.

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

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

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

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

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

Еще один вариант, это когда инструменты явно перерастают потребности и квалификацию персонала. Понятно, что это круто, но нафиг никому не нужно. Чаще всего такие проекты тихо саботируются и тут же сворачиваются после ухода инициатора или потери его интереса к проекту.

👆 А по факту все это – потерянное время и ресурсы. И каждый раз, когда возникнет желание внедрить что-нибудь такое следует спросить себя - а оно мне точно нужно? А зачем? А нужно ли оно еще кому-нибудь кроме меня?

И если вы затрудняетесь дать твердые и аргументированные ответы – оно вам не нужно.

Современные тенденции в сайтостроении. Классические CMS

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

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

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

Классические CMS – это всем известные Wordpress, Joomla, Drupal или Битрикс. Они имеют монолитную архитектуру и представляют из себя связку из набора скриптов, чаще всего на PHP – движка, который занимается генерацией контента и СУБД, в которой этот самый контент хранится, вместе с настройками веб-приложения.

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

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

Но все это имело и обратную сторону медали. Во-первых – сложность, для работы динамического сайта кроме веб-сервера требовались СУБД и сервер-приложений для обработки скриптов движка.

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

Во-вторых, остро вставала проблема безопасности. Вам требовалось поддерживать актуальность самого движка, плагинов и тем к нему, скриптового языка (PHP), СУБД, а также правильно настроить права доступа.

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

Но при этом классические CMS оказались очень просты в использовании для создателей контента. Развитые админ-панели позволяли делать все просто и интуитивно понятно, с использованием концепции WYSIWYG – что вижу, то и получаю.

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

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

Еще одна проблема таких CMS – это производительность. Так как сайт у нас динамический, то веб-страниц как таковых не существует до обращения к ним пользователя. Получив от пользователя URL нужной страницы движок вытаскивает нужные данные из СУБД и генерирует веб-страницу налету, отдавая ее пользователю через веб-сервер.

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

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

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

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

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

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

Перенос баз данных PostgreSQL между серверами

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

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

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

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

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

Для того, чтобы подключиться к другому узлу используйте ключ -h:


-h имя_сервера


Если пользователь удаленного сервера отличается от текущего пользователя СУБД, то дополнительно используем ключ -U:


-U имя_пользователя


Теперь несколько практических примеров:

На целевом сервере переключаемся на учетную запись суперпользователя СУБД:


su - postgres


Теперь можно посмотреть базы на текущем сервере:


psql -l


И на удаленном:


psql -h SRV-02 -l 


Перед тем как переносить базы на сервере приемнике их нужно создать, причем обязательно использовать для этого template0:


createdb -T template0 newbase


Это также можно сделать удаленно, не вставая с любимого дивана:


 createdb -h SRV-02  -T template0 newbase


Ну вот, все готово к переносу. Выгружаем здесь и по конвейеру передаем туда:


pg_dump  oldbase | psql -h SRV-02 newbase


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

Все что вам понадобится – это клиент Postgres:


apt install postgresql-client-<VERSION>


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

Теперь переносим базы с одного на другой командой:


pg_dump -h SRV-01  oldbase | psql -h SRV-02 newbase


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

​​Postgres + 1C = сильно тормозит?

Самое частое нарекание на работу свежеустановленной связки PostgreSQL + 1С:Предприятие – это тормоза. Причем именно тормоза, а не замедление, и часто видимые невооруженным глазом.

Означает ли это, что Postgres плох? Вовсе нет, просто привычный подход Далее – Далее – Готово здесь не работает.

Если MS SQL из коробки имеет вполне оптимальные настройки и без проблем будет работать на небольших инсталляциях 1С, то Postgres настроен на запуск и работу в минимальной конфигурации, что сразу сказывается на производительности.

Поэтому, вне зависимости от используемой платформы и версии PostgreSQL сразу после установки следует выполнить несложный тюнинг, после которого работа Postgres перестанет вызывать нарекания.

Как это сделать – написано в нашей статье: Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

ИИ в кино — это уже реальность. На примере Wink AI Challenge показываем, как ML-инженер может превратить фильм в набор данных и помочь продюсерам:
🔸 Анализировать сценарий с помощью NER и NLP.
🔸 Генерировать раскадровки на базе text-to-image и text-to-video.
🔸 Прогнозировать  возрастной рейтинг фильма по описанию сцен и готовым кадрам.

Эти задачи предстоит решать на Wink AI Challenge — хакатоне на стыке кино и ИИ. Регистрация открыта до 31 октября.

Если вас пугает слово «превизуализация», вы не знаете, чем отличаются форматы сценариев и как рассчитывается возрастной рейтинг, статья поможет разобраться. Внутри — реальные примеры из культовых фильмов и рекомендации по использованию моделей CLIP, Wan-AI, Qwen3-Omni и множества других.

В статье есть всё, чтобы быстро погрузиться в тему и подобрать рабочие инструменты: https://cnrlink.com/winkinterblogarticle?erid=2W5zFK7UYHn

Антон Дорошкевич. Тонкости эксплуатации PostgreSQL

Тема перехода с MS SQL на PostgreSQL становится все актуальнее. В докладе на конференции Infostart Event 2022 Saint Petersburg руководитель проектов Антон Дорошкевич рассказал, что ждёт после перехода, к чему нужно быть готовым, и какие варианты решения задач существуют на данный момент в мире PostgreSQL для его успешной эксплуатации. https://youtu.be/sx1FCw0zPCY?si=Oo4CbF1JybZ9IJln

Доклад в виде статьи: https://infostart.ru/1c/articles/1883272

У кого нет доступа к YouTube видео приложено отдельно

Современные тенденции в сайтостроении. Wiki-CMS

Продолжаем разговор о современных тенденциях в сайтостроении, начало здесь: https://t.iss.one/interface31/5138

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

Ключевое отличие Wiki-CMS от иных систем управления контентом – это отсутствие строгой иерархии данных. Если в обычной CMS вы так или иначе должны распределить контент по таксономиям, то в Wiki такого требования нет. Здесь вы можете динамически развивать контент снизу вверх, как дерево.

Эта особенность делает Wiki-движки наилучшим выбором для ведения баз знаний, документаций, справочников, энциклопедий. А отсутствие строгих структурных ограничений допускает живое развитие проекта по мере добавления и накопления знаний.

Одним из ключевых изобретений Wiki стала концепция Red Links (красных ссылок), когда в процессе написания материала автор понимает, что ему нужно дополнительно объяснить некоторый термин, явления, сослаться на другую страницу – то он просто добавляет ссылку.

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

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

Вообще именно ссылки являются основным способом навигации по Wiki-сайтам. Именно взаимные ссылки связывают страницы в единую сеть данных и позволяют перемещаться по ее структуре.

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

Это же является и отдельной большой проблемой Wiki-CMS, особенно если ее ведут разные люди и команды. Если в обычной системе для проставления ссылки нам нужно пойти, найти и хотя бы краем глаза посмотреть на страницу, то тут ссылки ставятся легко и непринужденно.

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

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

Отсюда плавно вытекает еще одна беда – потерянные страницы, на которые больше нет ссылок и найти их пользователь просто так не сможет, разве что будет точно знать, что искать. Напомним, что четкой иерархии у Wiki нет и нельзя просто взять и посмотреть все записи по какой-то выбранной таксономии.

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

А вообще Wiki-CMS – это как качели, и мы снова приходим к минусам – специальная Wiki-разметка, которая чем-то похожа на Markdown, но именно что похожа. Она очень своеобразна, сложна и местами совсем нелогична.

Отдельные движки, какие как DokuWiki, пытались упростить это процесс, придумывая собственную «упрощенную» разметку, но по факту сделали только хуже, наплодив местечковых вариантов.

В современных версиях движков это нивелируется визуальными редакторами, но если вы намерены серьезно работать с Wiki, то с ее языком разметки вам придется непосредственно столкнуться.

​​Пятничное, о жизни. Информационный шум.

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

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

Фактически мы уже к этому привыкли и если тот же телефон долго молчит, то начинаем беспокоиться, а все ли в порядке со связью?

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

Навигация в незнакомом месте, такси, деньги, контакты – все сосредоточено в одном месте. И если мы находимся вне дома, то это место – телефон.

Это настолько плотно вошло в нашу жизнь, что наши дети уже с трудом представляют себе, что был когда-то мир без интернета и смартфонов. Что такси заказывали по телефону и предварительно еще надо было узнать точный адрес куда вызываешь. А таксист мог попросить показать дорогу…

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

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

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

Если представитель организации в мессенджере молчит более 5 минут – тоже, ну действительно, что там у них случилось…

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

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

Хотите одним глазком заглянуть в то, как устроена IT-поддержка у разработчиков ITSM/ESM-системы?

Где обрабатывают 1200+ обращений в месяц через веб-портал, телеграмм, почту, форум и даже 1С-Connect. Без хаоса, Excel и потерянных задач.

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

Онлайн-экскурсия от IT-компании «Деснол» — это:
✔️ реальные сервисные процессы тех, кто сам разрабатывает и внедряет в компании по всей стране ITSM/ESM-систему;
✔️ готовые идеи, стратегии и практики, которые вы сможете забрать себе;
✔️ ответы на вопросы от экспертов;
✔️ возможность увидеть реальные IT-процессы в других крупных компаниях.

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

🎁 Участие бесплатное, регистрация по ссылке

Чтобы в числе первых узнавать о новых кейсах, практиках и полезных инструментах в IT, подписывайтесь на Telegram-канал 1C:ITILIUM по ссылке

#реклама
О рекламодателе

​​Про обслуживание и оптимизацию баз 1С

Тема широкая, тема сложная, поэтому будет дайджест.

🔸 MS SQL

Как первоначально настроить и первично оптимизировать:

▫️ Установка и настройка MS SQL Server для 1С:Предприятие

Как обслуживать:

▫️ Обслуживание баз 1С в MS SQL Server. Часть 1

▫️ Обслуживание баз 1С в MS SQL Server. Часть 2

▫️ Обслуживание баз 1С в MS SQL Server. Часть 3

Статьи не новые, а про обслуживание – старые, причем довольно сильно старые. Но все они основаны на рекомендациях вендора на ИТС, а там с тех пор ничего нового не появилось. Поэтому в основных настройках актуальность сохраняется.

🔹 PostgreSQL

Здесь все свежее, ну и тема гораздо более свежая, на ИТС материалов откровенно мало, поэтому мы более ориентировались на рекомендации ведущего эксперта по этой теме Антона Дорошкевича.

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

▫️ Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

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

▫️Настройка и тонкости эксплуатации PostgreSQL для 1С

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

🎥 Вебинар по сетям: Основные протоколы сети Интернет

🧠 Что будет на занятии:
- От битов до браузера: что такое сетевой протокол и зачем нужна модель osi/tcp-ip. Простое объяснение сложной концепции.
- Фундамент Интернета: детальный разбор ip, tcp и udp. Узнаем, кто отвечает за адресацию, а кто — за надежность доставки.
- Протоколы прикладного уровня: как работают знакомые всем http, https и dns, когда вы открываете сайт.
- Ответы на ваши вопросы: живая сессия с экспертом, где можно спросить о любых нюансах, связанных с сетевыми технологиями.

💪 В результате :
Систематизируете знания о ключевых протоколах и сможете увереннее разбираться в сетевых вопросах.

🎁 Проходит в преддверии старта курса «Network engineer. Basic». Все участники вебинара получат специальные условия на полное обучение курса.

👉 Регистрируйтесь для участия https://otus.pw/roCq/?erid=2W5zFG7raqN

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Вопрос в субботний вечер

Имеется Mikrotik, конфигурация сброшена, в брандмауэр добавлены следующие правила:

/ip firewall filter
add action=accept chain=input connection-state=established,related in-interface=ether5
add action=drop chain=input connection-state=invalid in-interface=ether5
add action=accept chain=input in-interface=ether5 protocol=icmp
add action=drop chain=input in-interface=ether5

Остальная конфигурация не редактировалась.

❓❓❓ Вопрос: можно ли подключиться с помощью Winbox через интерфейс ether5?