Во время работы над крупным литературным произведением, будь то художественный или научный текст, постоянно сталкиваешься с трудностями, связанными с управлением большим объемом информации. Сложности возникают как на этапе планирования произведения, так и во время его написания. Если не пользоваться офлайн системой планирования, например, карточками, то сформировать сложное произведение только при помощи текстового процессора (Word или Лексикон) чрезвычайно трудно. Работая над произведением месяцы, а иногда и годы, начинаешь забывать детали, путать временные периоды, пропускать важные части.
Для грамотной реализации первоначальной идеи к ней стоит относиться как к проекту и реализовывать как проект. Нужна декомпозиция всей работы на кусочки различной величины, соединенные общим планом. Писатели всего мира давно поняли, что принцип разделения приводит к успеху. Поэтому на свет появилась целая когорта программных продуктов, позволяющих, с разной степенью свободы, превращать крупное литературное произведение в контролируемую структуру. На мой взгляд, один из лучших продуктов для писателей — Scrivener.
Scrivener специально разрабатывался для написания пьес, телевизионных постановок и прочих разновидностей манускриптов (в противовес генерируемых AI). В принципе, в Scrivener есть все, что требуется. Иерархическая панель файлов произведения (как текстов, так и картинок), двухпанельный редактор, редактор метаданных, заметки с привязкой к каждому файлу, корзина и версиализация текстов. Помимо всего прочего, в программе присутствует возможность визуального планирования произведения при помощи «пробковой доски». И Scrivener можно было бы пользоваться, если не появление более мощного и гибкого инструмента. Речь далее пойдет об Obsidian, который способен подмять под себя все нишевые программные продукты, предназначенные для операций с текстом. И пока разработчики Scrivener продолжают прилаживать к своей программе защиты от пиратов, я уже перебрался в Obsidian.
Подробно об Obsidian я писал в своей статье про уход с OneNote, поэтому повторяться не буду. Остановлюсь лишь на специфических моментах, характерных именно для работы над крупными текстовыми массивами.
В одной из своих недавних статей я поделился опытом переезда с HTTP-сервера Apache на HTTP-сервер OpenLiteSpeed. Преимуществ переезда оказалось много. Производительность блога выросла: странички стали загружаться посетителям куда быстрее, особенно с использованием современных протоколов, сервер начального уровня оказался способен выдержать несравнимо больший объем единовременных посетителей, а ресурсов при всем при этом потребляется чуть ли не вполовину меньше, нежели с решением на основе Apache.
Однако, просто установка OpenLiteSpeed — полдела в плане приведения проекта блога к более современному виду. Есть еще ресурс по оптимизации и улучшения параметров обслуживания. При правильной настройке кэширования страничек производительность может еще подрасти. Но, как оказалось, в плане кэширования веб-страничек присутствует определенная неразбериха. Пришлось разобраться в вопросе досконально.
Еще в 2015 году для ведения заметок я перешел с Evernote на OneNote. Причины, побудившие меня в то время на миграцию, весьма банальны — Evernote отвратительно работал без наличия подключения сети, перманентно намекал, что хочет денег, а OneNote на его фоне выглядел просто космическим кораблем с множеством инструментов. Но с тех пор прошло 8 лет и пришло время уходить с Microsoft OneNote на что-то более продуктивное.
Так чем же оказался так плох OneNote, что его пришлось начать процесс его замены? Начну издалека.
Microsoft фактически перестала развивать свой продукт. На протяжении лет OneNote не менялся, не эволюционировал, в нем не появлялось новых функций, не происходило никаких улучшений. Когда продукт не развивается, это означает, что он начинает стагнировать. Конкуренты стараются, выдумывают новые возможности, модернизируют старые опции. И как бы ни был хорош OneNote, а он действительно на момент своего выхода в широкие массы был очень хорош, есть велика вероятность, что компания его просто уничтожит, так как не проявляет к нему никакого интереса.
А каких функций мне не хватало в OneNote? Как оказалось, я довольно-таки серьезный пользователь этого электронного блокнота. За несколько лет у меня образовалось пять записных книжек общим объемом порядка 400 мегабайт. Но записные книжки превратились в кладбище идей, похороненных под кипой устаревшей и никому не нужной информации. Создатели OneNote увлеклись визуализацией своего решения, стараясь представить его как можно ближе к обычной запиской книжке бумажного формата, в которой можно писать от руки в любом месте, рисовать на изображениях и размещать одни заметки поверх других. В этом вопросе OneNote до сих пор находится вне конкуренции. Но за внешней красотой они забыли про продуктивность, точно так же, как дизайнеры Windows 11 сфокусировались на красоте рабочего стола, а специалисты по юзабилити вообще остались не у дел. Все закончилось тем, что OneNote стал похож на реальный кабинетный рабочий стол в несколько слоев заваленный разрозненными бумагами. И только считаные единицы из них используются более-менее активно, так как лежат они на вершине всей кипы.
Далее, Microsoft всеми силами, правдами и неправдами, старается перевести пользователей на использование своих сервисов по подписке. Ведь куда интереснее получать от потребителей регулярную оплату с полным пониманием, что платить он будет пожизненно, ведь уйти от сервисов Microsoft может не каждый. Вот уже и Office переехал в онлайн и очень хорошо там укрепился, а далее осталось совсем немного до полного закрепощения людей в инфраструктуре одного провайдера технологических решений. Первые шаги уже сделаны. Современные OneNote хранят все записные книжки в облаке OneDrive, скачать их оттуда невозможно. Ситуацию усугубил февраль 2022 года, когда Microsoft всего несколькими своими телодвижениями потерял статус надежного партнера для юридических лиц. Невнятная политика по работе в России, «кидок» юридических лиц, отказы от возврата уплаченных сумм, надолго испортили деловую репутацию Microsoft. Но еще и неясно, последуют ли физические лица вслед за юридическими, ведь нарушение обычаев делового оборота, оферт и своих же собственных политик, наглядно демонстрирует, что компания может творить любую дичь и сделать с ней ничего нельзя, кроме как перестать пользоваться ее услугами. Как следствие, необходимо спасти свои данные, будь они даже и малоценными, переложить их в надежное и подконтрольное место.
Резюмируя: причин для ухода с OneNote достаточно, основная их которых — риск того, что уйти на альтернативную систему придется все равно. Но лучше начать перемещение заранее, не дожидаясь безальтернативного решения с противоположной стороны земного шарика.
Известно, что работоспособность web-сайта зависит от множества факторов, но не в последнюю очередь от использования конкретного программного обеспечения веб-сервера. По данным Wikipedia, в мире существует более 60 различных программных продуктов, обслуживающих веб-запросы. Правильно называть такое ПО HTTP-сервер, но будем придерживаться более привычного web-сервер или веб-сервер. Какие-то из них узкоспециализированные, обслуживают только клиентов определенного направления и работает строго на платформе одного провайдера, другие же могут применяться для широкого спектра работ и доступны каждому. Но несмотря на обилие предложений, пятерка лидеров занимает почти 100% рынка веб-серверов. Причем за почти 30 лет существования массового Web на лицо консолидация и распределение рыночных долей, занимаемых лидирующими веб-серверами.
Еще 2-3 года тому назад безусловным лидером среди web-серверов был Apache. Свободный веб-сервер с многолетней историей (первая версия выпущена в свет в 1995). Надежный и устойчивый, проверенный поколениями системных администраторов. Но уже на конец 2022 года другой веб-сервер с именем Nginx занял лидирующую позицию (по данным W3Techs) сместив Apache с заслуженного первого места. А снизу их активно подпирают Cloudflare server и LiteSpeed. Microsoft, со своим IIS замыкает список популярнейших серверов.
Почему же «легенду» в виде Apache сместили с пьедестала? Apache разрабатывается уже более 25 лет. Его основы закладывались во времена, когда мало кто еще мог видеть в завтрашний день, а спроектировать систему, платформу, которая будет удовлетворять требованиям далекого будущего — затруднительно, если просто невозможно. Ведь компьютерные технологии развиваются стремительно, а рост Web-технологий вообще оказался взрывным на некоторых этапах своего существования. В последние годы Web из игрушки для самых продвинутых прочно вошел в жизнь людей и корпораций. А Apache оказался технологически неспособным к обслуживанию изменившихся и многократно возросших потребностей потребителей.
Основной проблемой Apache можно назвать неспособность выдерживать высокую нагрузку на сервер, справляться с изрядным количеством одновременных запросов, ну и для обеспечения высокой производительности ему необходимо самое высокопроизводительное железо. Ему требуется память и процессор, если хочется обслуживать более-менее живой, по современным меркам, сайт с посетителями. Но архитектура Apache не позволяет малой кровью справиться с возрастающей нагрузкой на веб-сервер. Именно по этой причине набрал популярность (и продолжает набирать) веб-сервер Nginx. В большинстве случаев Nginx используют в качестве промежуточного веб-сервера между конечным пользователем и Apache. Понятно, что такая схема не самая красивая, но по крайней мере она позволяет существенно увеличить пропускную способность сайта, в основе которого работает Apache. А перевести крупный веб-сайт, исторически работающий на Apache, на другую платформу — задача отнюдь нетривиальная. Ведь, веб-сервер крупного сайта — это не только статические html-файлы, а по большей части динамический контент, генерируемый интерактивно и настроенный на выполнение в рамках конкретной платформы.
Конечно, блог или персональный сайт, не предполагает излишней популярности и массовых набегов посетителей. Но ведь и оборудование, на котором размещается «сетевой дневник» из разряда супер-эконом. Ограниченная память, не самый мощный процессор, который еще и делится с другими арендаторами виртуального сервиса. Зато не бьет по карману и есть полигон, где присутствует нескончаемое поле для оптимизаций со стремлением выжать из оплаченного все что можно.
Мой собственный блог крутится на движке WordPress, самой популярной платформы для блогов (рейтинга, заслуживающего доверия, по блог-платформам я не обнаружил, но тем не менее), а это значит, что помимо HTTP-сервера мне требуется еще фреймворк для генерации динамического контента, это PHP, а еще и база данных для хранения статей и настроек, это MySQL (точнее её клон — MariaDB). Помимо всего этого хозяйства на сервере крутится еще множество другого программного обеспечения, связанного, так или иначе с обеспечением жизнедеятельности блога. После миграции с Blogger на WordPress помимо гибкости в настройках я получил еще и прирост скорости работы блога. Странички начали отдаваться без излишней задумчивости. И все это было проделано на Apache.
Но, постоянно хотелось большего. В первую очередь желание фокусировалось на ускорении выдачи материала. Настало время провести оптимизацию. Если до процесса глубокой настройки мой блог выдавал заглавную страничку за время порядка 3-х секунд, то после оптимизации, в первую очередь была подвергнута серьезной переработке база данных используемая WordPress и его плагинами (настроены индексы, созданы view и прочее), заглавная страница появлялась у потребителя уже за время порядка 0.35 секунды. Оптимизации была подвергнута не только база данных, но и все, что замедляло работу сервера. Дополнительно помогли переход на SSL (https), IPv6 и HTTP/2. Но проблема с производительностью никуда не ушла, она постоянно присутствовала в жизни моего блога. Единичный посетитель блога грузил его на 15-25 процентов процессорного времени, в зависимости от того, присутствует ли просматриваемая им страница в кэше или нет. А три-четыре одновременных читатели уже ощущали незримое присутствие друг друга.
Хотелось большего. И на тех же ресурсах. И еще хотелось HTTP/3. HTTP/2 с грехом пополам был внедрен, а вот с HTTP/3 у Apache уже не все так однозначно. Нужно искать и прикручивать модуль (если таковой вообще существует), ловить ошибки и проверять конфигурации. И тут мне на глаза попался список веб-серверов, которые из коробки обеспечивают пользователей всеми современными технологиями. Так и было принято решение попробовать перейти на OpenLiteSpeed (приставка Open означает принадлежность программного продукта к открытому программному обеспечению, которое распространяется на безвозмездной основе).
Я довольно долго пользовался для синхронизации файлов между своими серверами, компьютерами и мобильными устройствами такой программой, как Resilio Sync (в девичестве BTSync). Но от Resilio пришлось отказаться, поскольку на протяжении нескольких лет разработчики так и не смогли избавиться от проблемы, связанной с зависанием приложения для Android. Ошибка была признанной, обнаруживалась у многих пользователей, но не исправлялась. Вероятно, что у Resilio просто закончились программисты для Android. Пришлось перейти на Syncthing.
Syncthing – open-source аналог Resilio, а именно децентрализованная система синхронизации файлов между устройствами. Принципы ее работы схожи с Resilio, но благодаря обширному комьюнити – система работает стабильно, мобильное приложение не останавливается, синхронизация происходит без сбоев. Как и у большинства open-source проектов, связанных с программным обеспечением, у Syncthing самую малость хромает документация. Разработчики справедливо полагают, что пользователь, решивший погрузиться в мир open-source, вполне сам способен просмотреть исходный код и найти нужный ему параметр настройки, а заодно и понять, что он означает, в каких случаях применяется, а в каких нет.
Syncthing может проводить синхронизацию между устройствами как напрямую, если оба устройства находятся в одной сети или же хотя бы одно из них имеет «белый» IP-адрес, так и через сервер посредник, расположенный где-то в глобальной сети. Поиск устройства для синхронизации осуществляется через сервер посредник обнаружения, расположенный тоже где-то в глобальной сети. Сообщество Syncthing предоставляет несколько десятков или даже сотен серверов посредников обоих типов, разбросанных по всему миру.
Появилась у меня потребность чуточку «поиграться» с настройками сервера, который крутится у провайдера на VPS сервере. Изменять параметры на «боевом» сервере можно, если они не глобальные и отменить их можно очень быстро. Но вот если требуется произвести более значимые изменения, то лучше попробовать их сначала в тестовом окружении, проверить, все ли будет работать, разработать план отката изменений, если вдруг что-то пойдет не так. И только потом прибегать к изменениям на «боевом» сервере.
Самым четким способом, на мой взгляд, по организации тестового сервера, есть снятие полной копии боевого сервера и разворачивание этой копии на тестовой архитектуре. Так как мой боевой сервер крутится на VPS, то имеет смысл снять его полную копию и развернуть ее уже на тестовой системе виртуализации. К сожалению, из интерфейса панели управления VPS моего провайдера снять образ системы нельзя. Сам сервер VPS крутится на Ubuntu под системой виртуализации XEN, а в тестовой среде гипервизором у меня будет выступать уже Microsoft Hyper-V. Осталось только понять как снять образ диска и подключить его к новой виртуальной машине.
Проблема с нехваткой публичных IPv4 адресов возникла не вчера и даже не позавчера. Когда только на горизонте забрезжил лучик проблем, что IPv4 адресов на всех желающих не хватит, был разработан стандарт IPv6, в котором этих адресов настолько много, что хватит их очень на долго. Но… Переход на новый протокол длится уже более 20 лет, но до сих пор полный переход во всех сферах и направлениях так и не произошел. И похоже, что мы еще довольно долго будем валандаться с ограниченным по количеству публичных адресов наследием прошлого очень долго.
Для чего же нужен IPv6? Для меня лично он работает просто быстрее, чем IPv4. А еще на свое любое устройство с поддержкой IPv6 я могу подключиться откуда угодно. Да и вообще, надо идти в ногу со временем. Сколько же уже можно? Но, к сожалению, несколько из моих провайдеров, не будем показывать пальцами, хотя это Мегафон, MosLine и Билайн, совершенно не спешат переходить на современный протокол. Провайдеров отчасти тормозят такие вещи, как чрезмерно устаревшее оборудование, отсутствие квалифицированного персонала и недостаток желания что-то делать, ведь народ и так потребляется. И у меня есть сильное подозрение, что последний пункт он и есть ключевой в этой проблеме.
Но если у меня возникло желание заполучить IPv6, то я его заполучу. И в этом нам поможет… Нет, не киножурнал «Хочу все знать!», хотя он точно не помешал бы. Разбираться в том, каким образом можно получить себе IPv6, если провайдер дает только IPv4 и то не с публичным («белым»), а с «серым» адресом, будем по официальным мануалам, постам в сетях и всём таком прочем.
Итак. Протокол IPv6 достаточно гибкий и одновременно сложный в понимании. Чем дальше заходит технология, тем больше времени нужно ей посвятить, чтобы понять каким образом реализовать тот или иной финтель. Если сравнивать IPv6 с IPv4, то последний раза в два проще, как минимум. Поэтому будем решать задачу пошагово, стараясь пройти от простого к сложному, получая в каждый момент времени удобоваримый результат.
Во время работы над крупным литературным произведением, будь то художественный или научный текст, постоянно сталкиваешься с трудностями, связанными с управлением большим объемом информации. Сложности возникают как на этапе планирования произведения, так и во время его написания. Если не пользоваться офлайн системой планирования, например, карточками, то сформировать сложное произведение только при помощи текстового процессора (Word или Лексикон) чрезвычайно трудно. Работая над произведением месяцы, а иногда и годы, начинаешь забывать детали, путать временные периоды, пропускать важные части.
