Современные тенденции в сайтостроении. Классические 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С:Предприятие

Антон Дорошкевич. Тонкости эксплуатации 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.me/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С. Разумеется, это ни к чему не обязывает.

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

Имеется 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?

​​Подключения Winbox, ответ на вчерашний вопрос

Чтобы правильно ответить на вчерашний вопрос нужны знания как матчасти (служб и возможностей Mikrotik), так и понимание работы сетевой модели OSI.

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

Это протокол прикладного уровня L7 и у него нет никаких инструментов доставки. Но каким же образом роутер и приложение смогут общаться между собой? Очевидно, что нам нужно каким-то образом наладить между ними взаимодействие.

Поэтому мы последовательно спускаемся по модели OSI на транспортный уровень и находим там то, что нам надо – транспортный протокол TCP, после чего помещаем наш протокол Winbox в сегменты TCP и сообщаем на какой порт нам нужно их отправить.

Затем помещаем TCP-сегменты в IP-пакеты (это L3 - сетевой уровень) и сообщаем им адрес назначения. На этом закончим, фактически то, что мы сделали можно назвать протоколом Winbox over TCP.

Но у Mikrotik есть еще одна служба, которая называется MAC Server и которая позволяет нам спуститься с L7 сразу на L2 и поместить полезное содержимое протокола Winbox сразу в Ethernet-фреймы. И в данном случае мы получили совсем другой протокол Winbox over Ethernet.

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

MAC Server позволяет подключиться к устройству после полного сброса конфигурации, когда у него нет никакого IP-адреса и оно не может функционировать на сетевом уровне.

А теперь вернемся к нашему вопросу. Мы полностью сбросили конфигурацию и добавили в брандмауэр правила запрещающие любые входящие соединения на ether5. Сможем ли мы подключиться через Winbox?

Если мы попытаемся подключиться по адресу, то будет использован протокол Winbox over TCP и нас ожидаемо ждет неудача.

А если мы обратимся к MAC Server? Снова смотрим на модель OSI, брандмауэр Mikrotik работает на сетевом и транспортном уровнях (L3 и L4), не трогая фреймы канального уровня (L2), таким образом эти соединения проходят мимо пакетного фильтра, и мы без проблем установим соединение.

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

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

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

Поэтому помним, что Winbox over TCP и Winbox over Ethernet – это разные службы и настраиваются они в разных местах и вам при настройке роутера нужно уделить внимание им обоим.

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

Продолжаем разговор о современных тенденциях в сайтостроении, начало здесь:

🔹Классические CMS
🔹 Wiki-CMS

Flat CMS – плоские CMS составляют популярное и активно развивающееся направление современного сайтостроения. Как следует из их названия – плоские – основная их особенность, это отказ от СУБД и хранение всей информации в файлах.

Для хранения контента используется обычно Markdown, а для конфигурации и шаблонов YAML, TOML, JSON и т.п.

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

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

Что принципиально нового в Flat CMS? Это использование для сайта только файлов, что позволяет использовать версионирование Git не только для настроек, но и для контента, а также использовать DevOps практики для развертывания и поддержки сайта.

Фактически здесь мы приходим к модели сайт как код, а использование Markdown для контента позволяет надежно отвязать последний от технической реализации, так как данный формат сегодня стал стандартом де-факто и позволяет свободно переносить контент не только между движками, но и, например, блокнотами и базами знаний (Joplin, Obsidian и т.д.).

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

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

Именно SSD позволили Flat-CMS вырваться вперед и превзойти по производительности для небольших и средних сайтов классические CMS с СУБД. А появление на рынке NVMe и вовсе позволило взять хороший отрыв.

Но именно то, что обеспечило Flat CMS основные достоинства является и ее основным недостатком – файловая система. Она не масштабируется и на больших объемах контента способна стать причиной резкой деградации производительности.

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

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

Они просты, безопасны, портативны и прекрасно ложатся в лоно современных практик сайт как код и CI/CD.

Отдельной строкой можно поставить производительность. Если у вас не мегапортал с миллионами записей, то среднего хостинга со средними NVMe дисками хватит надолго, особенно если у вас преимущественно статический контент и грамотно организовано кеширование.

При этом все это будет стильно, модно, молодежно, а сам сайт будет просто лежать у вас в Git-репозитории со всей историей и всеми изменениями.

Кстати, Flat CMS последнее время активно используются вместо Wiki для ведения документации. Потому что проще, понятнее и удобнее, а версионирование обеспечивает Git.

В любом случае, если вы думаете создать новый сайт, то Flat CMS следует уделить самое пристальное внимание. Ведущие проекты, такие как Grav, Kirby или Statamic достаточно развиты, лишены «детских болезней» и имеют полноценную экосистему и сложившиеся сообщества.

Используем Cockpit для администрирования Debian и Ubuntu

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

Сегодня мы рассмотрим легкий и простой веб-интерфейс для администрирования Linux серверов - Cockpit, а также расскажем о том, как установить его и использовать в среде операционных систем Debian и Ubuntu.

✅ Читать статью

Современные тенденции в сайтостроении. Генераторы статического контента

Продолжаем разговор о современных тенденциях в сайтостроении, начало здесь:

🔹Классические CMS
🔹 Wiki-CMS
🔹 Flat CMS

В прошлой заметке мы рассмотрели Flat CMS и отметили наметившиеся с середины 2010 годов тенденции на упрощение систем управления контентом и переход на структуру сайт как код.

Апофеозом этого стало появление генераторов статических сайтов (Static Site Generators, SSG). При беглом взгляде они могут показаться откатом в прошлое, ну какие еще статические сайты в третьем десятилетии 21 века?

А почему бы и нет? Если это современные статические сайты. Отвечающие всем требованиям и поддерживающие все современные веб-стандарты?

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

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

Да и сами сайты пересмотрели свое отношение к интерактивности. Ну какое взаимодействие пользователю может предложить информационный ресурс? Вот статья, вот комментарии, вот поиск… Больше ничего и не надо.

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

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

А вот владелец такого сайта получает массу преимуществ. Так как генератор выдает готовый статический сайт, то можно спокойно развязать место генерации контента и хостинг. А также в полной мере задействовать технологии CI/CD и версионирование Git.

Также как и во Flat CMS весь контент хранится в Markdown, а шаблоны и конфигурационные файлы в YAML, TOML и/или JSON. Но разница заключается в том, что Flat CMS требуют наличие установленного движка и всех этих файлов на хостинге, а генераторы статических сайтов – нет.

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

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

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

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

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

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

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

Кстати, именно так и будет работать наш новый сайт.

​​Стандартные расположения данных

Иерархия файловых систем основных ОС предполагают различную структуру хранения данных и одной из частей этой структуры является пользовательская папка. В Linux и UNIX-подобных системах это /home, в Windows - C:\Users.

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

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

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

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

Отчасти в этом есть вина самой системы, так как в Windows нет общей иерархии файловой системы, то люди привыкли хранить свои данные на дополнительных логических томах (D:, E: т.д.) и делать это так, как удобно им.

Очень часто эта практика сохраняется и в том случае, когда логический том один. Такое чаще всего бывает на ноутбуках или моноблоках, а разбивать на разделы единственный быстрый SSD размером в 250-500 ГБ не имеет смысла.

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

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

Третьего дня у одного моего знакомого что-то случилось с системой, то ли сделали что-то не так, то ли скачали что-то не то, но загружаться она перестала.

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

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

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

Это чего-то заметила на следующий день его жена. Когда запустила 1С, а та ей бодро сообщила, что информационная база не обнаружена.

Как вы уже догадались, лежала база не в профиле пользователя, а в C:\1CBases или чем-то подобным.

Изучив то, что утилита сохранила на внешний диск, выяснилось, что туда попали папки Windows, Program Files, Program Data и т.д. для восстановления программ и полностью паки пользователей из C:\Users.

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

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

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

Семь раз отмерь – один отрежь

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

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

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

Научила меня этому одна старая история. Дело было в далеком и светлом 2003 году, я – молодой специалист только-только устроившийся в компьютерную фирму. Система оплаты труда у нас была смешанная: оклад 4 000 рублей на руки + 50% от стоимости выполненных работ.

Для понимания, 4 000 руб. в 2003 году были эквивалентны примерно сегодняшним 30 000 руб., для молодого человека в провинции без семьи, кредитов и ипотек в целом нормально, но сильно не развернешься. Поэтому интерес работать был и интерес неплохой, особенно если урвать заказы подороже.

И вот я взял хороший заказ – переустановить компьютер одной женщине-бухгалтеру, как сейчас принято говорить – на аутсорсе. А была тогда еще «семерка», которая 1С:Предприятие 7.7 и хранила она свой список баз и прочие настройки в реестре.

Это меня и подвело, 1С я знал тогда так себе и просто скопировал весь диск C: в папку OLD_C на диске D: прямо из-под винды и считал, что все хорошо, если что – все найдем. Но реестр, естественно, не скопировался, как и ряд других открытых файлов, но тогда я не придал этому значения.

В общем я все переустановил, даже 1С и всякие программы для ПФР и прочей налоговой отчетности поставил, только вот почему-то список баз оказался пустой и где он лежит я так и не нашел.

Обратился за помощью к старшим коллегам, но они только присвистнули, мол 1С, ну все пацан, ты попал…

Сами базы 1С были преимущественно на диске D:, но было их там некое запредельное количество, штук, наверное, 150-200. Ну да дурной собаке 100 км не крюк, сейчас открою, посмотрю, впишу, но там почти везде оказались пароли.

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

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

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

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

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

Сегодня, когда доступны быстрые и емкие носители я обычно просто снимаю полный образ системного диска с конвертацией в VHDX через Disk2vhd от Sysinternals.

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

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

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

Утилита sed - потоковый текстовый редактор. Широко используется для работы с потоками данных в скриптах и консольных командах. Владение данной утилитой относится к основам администрирования Linux.

В общем случае работа sed задается конструкцией:

команда/вхождение/замена/флаги

Например, результатом работы команды:

echo "Сегодня 1 апреля"  | sed 's/апреля/мая/'

Будет строка “Сегодня 1 мая” , в данном случае s – обозначает действие замены, далее идет вхождение и замена.

Если нужно выполнить несколько действий, то разделяем их точкой с запятой и добавляем ключ -e:

 "Сегодня 1 апреля"  | sed -e 's/сегодня/Завтра/i; s/апреля/мая/'

Так как мы не уверены, как именно может быть написано слово «Сегодня», то мы добавили к первому действию флаг i, который предписывает игнорировать регистр.

Пока что мы работали с потоками стандартного ввода-вывода, но также на вход можно подать файл:

 's/апреля/мая/' file.txt

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

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

Другой вариант – использовать флаг w с указанием файла, но в этом случае в него будут записаны только те строки, где была произведена замена:

sed 's/апреля/мая/w out.txt' file.txt

Если нам нужно редактировать непосредственно исходный файл, то следует запустить команду с ключом -i (не следует путать с командой i):

sed -i 's/апреля/мая/' file.txt

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

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

sed '2s/апреля/мая/' file.txt

Или со 2 строки по 5:

sed '2,5s/апреля/мая/' file.txt

Для указания последней строки используйте символ $:

sed '5,$s/апреля/мая/' file.txt

Данная конструкция заменит вхождения с 5 строки по последнюю.

Если не указано иного, то sed заменят только первое вхождение в строке, номер вхождения можно указать при помощи флага или использовать флаг глобальной замены – g, при использовании данного флага с номером будут заменены все вхождения начиная с указанного, например, с третьего:

sed 's/апреля/мая/3g' file.txt

Кроме изменения строк sed можно использовать для удаления строк из потока, для этого просто укажите их номер или диапазон номеров:

sed '2,5d' file.txt

Также можно использовать вхождения, например, удалим все строки со словом «апреля»:

sed '/апреля/ d' file.txt

Можно использовать и несколько вхождений, но будьте осторожны, sed удалит все строки между ними:

sed '/апреля/,/мая/3d' file.txt

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

sed 'i\Это первая строка' file.txt

В конец:

sed 'a\Это последняя строка' file.txt

Или явно укажите номер строки от начала или конца:

sed '2i\Это вторая строка' file.txt

Команда с полностью заменит содержимое указанной строки:

sed '3c\Это новое содержимое третьей строки' file.txt

Еще одна возможность sed – замена символов, но при этом область замены нельзя ограничить, будет выполнена обработка всего потока, например заменим a на b, с на d и e на f:

sed 'y/ace/bdf/' file.txt

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

Иван Чёрный, автор Вороньего блога опубликовал статью:

🔹 Поднимаем свой сайт на Hugo с публикацией контента через Obsidian

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

Также он предлагает достаточно оригинальный способ написания заметок через Obsidian.

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

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

✅ Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702

Работаем над новым сайтом, переносим контент и местами не можем себя заставить не перечитать заново...

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

🔹Направленная антенна для Wi-Fi своими руками

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

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

Схема генератора статических сайтов на базе HUGO с автоматической сборкой и развертыванием. Начало

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

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

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

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

Так как мы используем GitHub Action, который создает виртуальные машины, то и для локальной среды используем виртуальную машину с Ubuntu, если же вы используете GitLab, который оперирует Docker контейнерами, то имеет смысл и локальный контур выполнить по той же технологии.

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

Сразу дам простой совет: используйте основную ветку репозитория – main, только для повседневной работы с сайтом – т.е. создания контента, все остальные работы выполняйте в отдельной ветке, например – dev (от developer – разработка). Это немного усложняет работу, зато серьезно упрощает всю следующую эксплуатацию. Мы коснемся этого вопроса позже.

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

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

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

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

Что делает HUGO? Собирает статический сайт из файлов проекта и отдельной ценности этот сайт не имеет, в отличие от проекта. Почему? Да потому, что его всегда можно сгенерировать заново.

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

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

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

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

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