Ядерный рывок: АЭС малой мощности захватывают мир!

Лонгрид : Энергетический кризис - прошлое, настоящее и будущее..
Сегодня я расскажу про все скрытые смыслы и спрятанные сокровища в выпуске «Жадоникс и сигналы бедствия»
Евгений Иванович Замятин — русский и советский писатель, публицист и литературный критик, киносценарист, морской инженер, педагог. Родился: 1 февраля 1884 года, Лебедянь, Лебедянский уезд, Тамбовская губерния, Российская империя. Умер: 10 марта 1937 года (53 года), Париж, Третья Французская республика. Политические взгляды: социализм.
Если хотите создать много слойный и интересный текст, примените предлагаемый художественный прием. Вы получите инструмент для соединения различных слоев текста. Слои погрузят читателя в мир литературных и жизненных образов. Автор делится личным опытом чтения знаменитого романа Джеймса Джойса «Улисс», исследуя механизмы мышления и восприятия реальности. Роман отражает хаотичную природу человека.
Отвечаю на вопрос «А как решать задачи на литкоде?», который часто встречаю в разных формулировках у себя в комментариях.
Сразу обозначу, что чтобы научиться решать литкод задачи, нужно решать литкод задачи. Некоторые решают литкод задачи чтобы подготовиться к собеседованию. Некоторые просто для расширения кругозора, для набора общего опыта (я для этого решаю).
Если вы думаете, что научившись решать литкод задачи вы станете классным прогаммистом, скажу, что это так не работает. Не станете.
Решение задачек на литкоде это заучивание паттернов. Если вы пробовали решать дейли задачки, то могли заметить, что одну-две недели подряд идёт примерно одна и та же тема, просто под разными соусами.
Выбирайте популярные задачи, у которых высокий процент принятия, начинайте с Easy задач. Не на каждом собесе спросят Medium, а Hard вообще нужен только чтобы потешить своё самолюбие.
Открываете задачку. Читаете условие, выводите для себя границы задачи. Я в каждом ролике начинаю с чтения условий задачи, объясняю своими словами, что имеется в виду.
Пытаетесь решить задачу. Нужно сначала потупить, попытаться решить. Посмотрите, что у вас вообще получается. Вдруг выйдет решить задачу.
Если не получается, можно (как опциональный этап) посмотреть похожие задачи, попробовать решить их. Но, скорее всего, вам будет лень.
Поэтому переходите к поиску разборов решения. Нужно не просто готовое решение, а целый разбор с объяснением, почему именно так. Текстовый разбор, видео с решением (например как у меня) — на ваше усмотрение. После просмотра объяснения попробуйте решить задачу самостоятельно. Вы уже знаете суть, понимаете решение. Если не поняли, то посмотрите другой разбор. И переходите к коду.
Воспроизведите код как запомнили: это важно сделать по памяти, ведь когда вы запоминаете, вы не заучиваете расположение символов, вы выстраиваете логическую связь: что за чем идёт, какие сравнения, и так далее.
Если не удаётся воспроизвести, пересмотрите разбор и попробуйте ещё раз.
Всё ещё не можете понять? Это не повод расстраиваться. Таблицу умножения мы тоже когда-то заучивали. Нет ничего страшного в том, что вы не поняли суть, но запомнили решение. Из этих кирпичиков потом строится более сложное решение. Перепишите весь код вручную (никакой копипасты!), но **все переменные** называйте иначе, как-то по-своему. Это заставит вас следить за сутью кода, а не переписывать вслепую, вам придётся следить за сущностями, которыми вы оперируете.
Если полученный код не работает, сравните через любой diff checker (в PyCharm это compare with clipboard). Возьмите готовое решение, поменяйте там переменные на свои, сравните, где вы перепутали оператор, добавили лишний отступ, или обратились не к той сущности.
После того, как удалось подготовить рабочее решение, и литкод показал вам случайные числа, поставьте себе напоминание на завтра, чтобы вы решили эту задачку снова. Через неделю вернитесь к этой задаче вновь. После решения вернитесь к этой задаче ещё через месяц.
Так вы запомните суть и решение этой задачи.
Ну, это всё актуально, если вам действительно хочется разобраться и научиться.
Через сотню-другую задач вы начнёте замечать повторяющиеся модели / структуры задач, и будет легче.
Список ИИ нейросетей
Когда я только начинал программировать (писать сайты, создавать приложения с графическим интерфейсом), мне казалось, что есть какие-то секреты, тайны, которые скрывают настоящие программисты. Как делают сборку приложений? Как эти приложения запускают? А как обрабатывают пользовательские данные? Как реализуют уровни доступа?
Оказалось, что никаких секретов нет. Делают как делают. Чаще всего делают как попало. Потому что самое главное, чтобы хоть как-то работало. А какой ужас творится под капотом. лучше бы вот это реально никому не показывали.
Да, есть крутые спецы, которые умеют построить технологичные и понятные системы. Но они существуют где-то там, в другом месте. А работать придётся с тем, что есть. С тем, что выполняет бизнес-требования.
PlantUML
Если вы хоть чуть-чуть в сфере ИТ, вы точно встречали PlantUML диаграммы. Это такие схемки с пошаговым описанием действий в системе, или описанием структуры проекта (сервисы, базы, и тд). Визуализация это, конечно, прекрасно, но хорошая визуализация ещё лучше. А PlantUML предоставляет хорошую визуализацию только для одного уровня абстракции.
С4
В проекте всегда можно выделить несколько уровней абстракции, и именно про это модель C4. Четверка в названии означает уровни:
1. Диаграмма системы — что приносит пользу пользователю. Система состоит из контейнеров.
2. Диаграмма контейнера — наши программистские сущности: базы данных, s3, отдельные приложения и микросервисы, это всё контейнеры. И каждый контейнер состоит из компонентов.
3. Диаграмма компонента — это модули ПО. Например, микросервис состоит из нескольких компонентов: СУБД, контейнер с приложением, веб-сервер.
4. Диаграмма кода — каждый компонент как-то напрограммирован. Вот тут можно сделать описание модулей и классов (опускаться до этого уровня обычно не нужно).
Кто кого?
Ещё есть правило, что нужно указывать направленность взаимодействия. Например, код ходит в базу данных. Да, тут сразу понятно, кто к кому обращается, ведь БД сама не ходит к приложению.
Если взаимодействие с API, то указывать направленность очень важно: мы можем запрашивать данные с внешнего ресурса, а также ресурс может уведомлять наше приложение о новом событии. И при указании направленности мы ещё и подписываем стрелочку, уточняем, что именно тут происходит.
А самый кайф C4, что никому не нужно приближение дальше второго уровня, изредка третьего.
PlantUML всё ещё актуален для Sequence диаграмм — схем с последовательностью действий, например «пользователь запросил А, система вытащила данные из B, перепроверила через C и отдала пользователю». А вот если структура системы описана по C4, то это гораздо понятнее.
Кстати, что PlantUML, что C4 рисовать руками не нужно, используйте для этого текстовый формат: его легко версионировать и распространять. Есть свои языки для этого, а также реализации на привычных нам Python, JS и тд.