Введение

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

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

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) Анализатор текста.
Казалось бы есть куча всяких редакторов текста, токенизаторов, лексеров, парсеров. Но где спрашивается удобное решение.

На мой взгляд интересная новость.

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

Это и другое за что ругали Steam Deck было исправлено в Steam Deck OLED.

Steam Deck OLED (Официальный сайт)

Главное из превью Steam Deck с OLED-экраном от Digital Foundry (DTF)
Представлена портативная консоль Steam Deck OLED (IXBT)
Valve представила обновлённую Steam Deck OLED (3DNews)

Введение

Тетрис учит нас, что ошибки в этой жизни накапливаются, а успехи исчезают. И что длинная палка — это хорошо.

От процессов к решению задач

Ранее у меня была статья Разработка через документирование (documentation-driven development). Основной упор в ней делался на процессы разработки.

Процесс (роль).
1) Разработка через моделирование (бизнес аналитик)
2) Разработка через требования (системный аналитик)
3) Разработка через проектирование (архитектор)
4) Разработка через кодирование (кодировщик)
5) Разработка через тестирование (тестировщик)
6) Разработка через отладку (отладчик)
7) Разработка через документирование (документовед)
8) Разработка через развёртывание (мейнтейнер)
9) Разработка через сопровождение (поддержка)

Процессы RUP

Обратите внимание на процессы и итерации. Процессы занимают строки, а не столбцы, то есть являются главными.