mayton2019

Да. Atom и Sublime, Notepad++ - это хорошие кандидаты на роль универсального редактора на все
случаи жизни. Многие из них работают с Markup/Markdown языками.

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

Вот. Все современные IDE (Visual Studio Code, Eclipse, Netbeans) тоже являются текстовыми редакторами
и автору я советую их тоже проверить и приходить сюда с выводами. Споры об годности IDE - это
вкусовщина. Я о них уже не спорю никогда и всегда соглашаюсь с выбором любого участника.

Выбирай. Проверяй.

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

Я не знаю что такое TerrainData в понимании Unity. Но обычно в игровых технологиях большие
локации режут на квадраты. Так что если главный герой покидает квадрат то всю картографию
в этом квадрате можно сохранить на диск. Главное - правильно расставить дистнцию видимости, туман,
или какие-то порталы чтобы максимально ограничить бесконечную локацию.

В наше время - наиболее дешево и удобно покупать Kubernetes и на нем разворачивать любые
серверы приложений по желанию. Я имею в виду в соотношении цена/производительность.

Как определить зашифрована ли строка с помощью функции openssl_encrypt или не зашифрована?

Такого метода вобщем-то нету. Но если openssl_encrypt возвращает строку в кодировке base64 - то эта строка будет
иметь характерный "хвостик" в виде символов равно (padding) для добивания строки кратного байтам размера.
И все прочие символы имеют равномерное (шумящее) распределение.

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

Разбей строку по амперсандам. А потом - по знаку равно.

Да. Ты правильно выбрал преобразование Хафа для кругов (окружностей). Только у тебя должен
быть pipeline из последовательного применения фильтров.

1) Сначала обесцветить картинку.
2) Применить фильтр границ. На этом этапе круги появятся
3) Ты заранее знаешь диаметр круга - желательно его вбить в настройки чтоб Хаф не искал все-все радиусы
которые возможны.
4) Ну и далее - твой метод должен их найти.

Найти посредника. Пообщать ему процент.

Возьми еще штук 10 SD-шек.

Если ты пошел по пути физика-экспериментатора - то эксперимент должен воспроизводиться и в статистике
показать что ты прав.

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

Так вроде лучше

for (int i = 0; i < 10; i++) {
        cout << i << endl;
}

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

20 лет назад этот вопрос был полнонстью решен с помощью технологий XML/XSLT/XPath.
Языки C#/dotNet, Java поддерживают этот стек. И много других языков и библиотек.

Потом еще создавали более простые вещи. Шаблонизаторы. Velocity, FreeMarker. Они немножко
переворачивают постановку. Но их тоже можно рассмотреть.

Хранить html код в столбце поста кажется нецелесообразным.

С точки зрения суммарной стоимости владения (TCO) база данных всегда будет дороже
чем файловая система. А самым дешевым будут хранилища типа Amazon S3, MS Blob, G-Drive.
Ну если пересчитать удельно сколько стоит гигабайт.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id),

Тут - непонятно. Но есть такое эвристическое правило дизайна
хороших NoSQL систем. Все данные для запроса должны лежать физически рядышком
и не требовать дополнительных действий. В идеале - для отдачи поста вы должны сделать
один единсвтвенный SELECT без joins и без подзапросов и агрегаций и без CONNECT-BY.

Почитай по ключевому слову - Кластеризация.

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

Чепуха какая-то. Какие выводы мы здесь должны сделать из хаотичного мигания?

Я вот так рассуждаю. Когда ничего непонятно - инженер должен отбросить сложные инструменты - и
взять простые. Бери мультиметр и проверяй целостность жил. И сопротивление изоляции между жил.

Свич убери вообще чтоб не мешал. Закольцуй кабель в кольцо чтоб было удобно мерять.

Ну я когда учил - группировал слова по тематике. Например спорт, природа, путешествия.
С какого на какой язык делать vocab - не имеет значения. Но важно слово тут-же начать применять.
Некоторые слова я разбирал на их составные части. Напрмер Pine-apple. Water-melon.
Если ты используешь карточки - то можно на них рисовать скетчи и это тоже помогает заучивать.

Некоторые слова включаются в устойчивые выражения и только в них и существуют.
Их надо знать в контексте. (do the washing up, carry on, eat out).

У меня вот со временами (tense) проблема. Все что past tense я просто заучиваю. Потому что базовая
формула из учебников просто для меня не работает в разговорной речи. Я - торможу и не успеваю
сформулировать мысль. Вот как-то так.

72 в десятой степени будет 3 743 906 242 624 487 424

Вот такое число. В физических величинах это будет ... эээ 3 квинтиллиона с хвостиком.

Эта задачка не на регулярки а на программирование. Если у вас есть список этих URL в виде CSV, то надо брать язык который вы знаете (PHP или Node) и писать логику нормализации. А потом унификации. Например.

Input:

habr.ru
habr.ru/test.htm
https://habr.ru
habr.ru/yyy
www.habr.ru
https://habr.ru

нормализуем. Отбрасываем например название протокола

habr.ru
habr.ru/test.htm
habr.ru
habr.ru/yyy
www.habr.ru
habr.ru

Сортируем

habr.ru
habr.ru
habr.ru
habr.ru/test.htm
habr.ru/yyy
www.habr.ru

И вот они дубли 3 штуки. Можете итератором пройти и собрать. Или сделать agg/count в языке где
такое с коллекциями делают.

И никаких регулярок.