Личная база знаний всё время меняется, в результате могут образоваться битые ссылки.
1. Меняются названия якорей атрибута id в html5.
2. Меняются названия страниц html5.
3. Меняются относительные пути к страницам html5.
4. Меняются ссылки к внешним ресурсам html5.
5. Меняются значения внутренних и внешних ресурсов.

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

Причём понятие не обязательно полностью меняет смысл.
1. Оно может получить уточнение от общего к частному.
2. Или напротив нужно обобщить его от частного к общему.
3. Но, конечно, и не исключён вариант полной смысловой замены.

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

Я искал ручное решение без специальных программ и "нашёл".

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

В очередной раз задумался, стоит ли использовать при проектировании программ Расширенные Формы Бэкуса Наура (англ. Extended Backus Naur Form), сокращённо РБНФ (англ. EBNF). И дело не только в них, возможно что-то другое подобное, включая различные парсеры.

Локализация ISO/IEC 14977:1996(E) (Extended BNF)

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

Введение

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

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

1. Файлы (*).
2. Текст (txt).
3. Гипертекст (hypertext markup language).
4. Zim (wiki markup).
5. Obsidian (markdown).

Markdown это видимо игра английских слов, в противовес markup. Ведь технически markdown это именно markup, а не markdown.

Файлы

В начале можно было рассказать как упорядочивать файлы в файловой системе.
1.1. Свалка.
1.2. Имена.
1.3. Списки.
И возможно кое-что ещё.

Свалка это по сути файлопомойка, когда файлы и папки лежат в одном месте.

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

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

Для примера производители софта из США игнорируют рынки России и Китая намеренно не делая локализацию. Или производители софта из Японии концентрируются на японском рынке.

Более того, даже китайский рынок имеет своих гигантов, которые так же нацелены лишь на свою внутреннюю аудиторию.

Чтобы не думали, что я рассуждаю чистыми абстракциями приведу пару примеров для каждой страны.
1. США. Microsoft, Apple.
2. Япония. Sony, Nintendo.
3. Китай. Tencent, NetEase.

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

Да и сейчас тоже самое...

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

https://rsdn.org/poll/9967

Одностраничная документация

Плюсы.

1. Страницу нужно загрузить лишь один раз.
2. Можно переходить по всей документации с помощью полосы прокрутки.
3. Поиск по странице работает на всю документацию.
4. Данные можно переносить по всей документации без перехода на другие страницы.

Минусы.

1. Загрузка и обработка документации происходит дольше.
2. Нет изолированности одного раздела документации от другого.

Многостраничная документация

Плюсы.

1. Загрузка и обработка документации происходит быстрее.
2. Есть изолированность одного раздела документации от другого.

Минусы.

1. Страницы нужно загружать каждый раз.
2. Нельзя переходить по всей документации с помощью полосы прокрутки.
3.

Введение

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

Предыдущие статьи.
1. Систематизация личной базы знаний по программированию в Zim (26.07.2023)
2. Синхронизация личной базы знаний по программированию в Zim (03.10.2023)
Связанные статьи.
1. Разработка через документирование (documentation-driven development) (29.05.2022)
2. Обучение с помощью карточек (21.11.2020)

Размеры изображений

Недавно размышлял по поводу целесообразности схем в личной базе знаний.
1. Нужны ли схемы в личной базе знаний?
2. Если нужны, тогда в каком размере и формате?

По поводу размеров исходя из опыта написания статей для rsdn пришло в голову, что ориентироваться нужно на ширину.
1. 640 пикселей может оказаться слишком мало.
2.

Катастрофа ООП

Перевод статьи: Объектно-ориентированное программирование — катастрофа на триллион долларов

C++ — ужасный объектно-ориентированный язык. Ограничение вашего проекта до C означает, что люди не напортачат ни с какой идиотской «объектной моделью».
Линус Торвальдс, создатель Linux
...
Методы или свойства, которые обеспечивают доступ к определённым полям, не лучше, чем непосредственное изменение значения поля. Не имеет значения, изменяете ли вы состояние объекта с помощью необычного свойства или метода, результат один и тот же — изменённое состояние.
...
Падение четырёх столпов:
1) Абстракция.
2) Наследование.
3) Инкапсуляция.
4) Полиморфизм.

Модель данных
[q]
В классической теории...

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

Википедия:К_удалению/19_февраля_2020#Список_алгоритмов

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

И куда же делась страница? А вот сюда.
https://ru.wikipedia.org/wiki/Проект:Математика/Списки/Список_алгоритмов
https://en.wikipedia.org/wiki/List_of_algorithms

Ну то есть модеры просто решили вставить Проект:Математика/Списки/.

Содержание

Введение
1. Тип
2. Соответствие
3. Краткость
4. Зона
5. Близнецы
Заключение

Введение

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

1. Тип

Для начала нужно выбрать тип к которому относится сайт.

Это может быть.
1. Компания.
2. Продукт.
3. Сообщество.
И многое другое.

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

2. Соответствие

Далее нужно подобрать название точно соответствующее сайту.

Возьмём для примера какую-нибудь компанию.
120 брендов и торговых марок, названия которых состоят из 4х букв

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

Для примера список из головы, чего не хватает мне:

1) Каталогизатор файлов.
Есть программы вроде WhereIsIt и другие, но функционал бедноват. Хотелось бы совмещение виртуальных каталогов с файловой системой, то есть открываешь каталоги как в файловом менеджере, они записываются в базу данных. Хотелось бы вычисление различных хеш-сумм и возможность контроля изменений содержимого директорий и файлов. Опять же автоматическое восстановление виртуальных каталогов, даже если файлы случайно разбросаны по диску. Мгновенный поиск дубликатов по хеш-суммам с досканированием, а не полным пересканированием дисков. А ещё хотелось бы вменяемую синхронизацию файлов между своими устройствами.

2) Анализатор текста.
Казалось бы есть куча всяких редакторов текста, токенизаторов, лексеров, парсеров. Но где спрашивается удобное решение.