S0ER

🚨 Ваш Kubernetes небезопасен: 3 ошибки, которые делают все (и как их исправить за 5 минут) Люблю Docker, K8s и кликбейтные заголовки. Но если серьёзно, то ошибок при конфигурировании кубера можно сделать очень много. Сейчас многие играют с облаками (и я в том числе) в моей конфигурации опытный девопс сходу нашел 3 ошибки, из-за которых кластеры взламывают, майнят крипту или просто случайно роняют продакшен. 🔴 Ошибка 1: default namespace — мусорка, которая сожжёт вам всё - Проблема: запустил поды в default, забыв про изоляцию. - Чем опасно: Взлом одного сервиса = доступ ко всем. - Как исправить: kubectl create namespace my-app kubectl config set-context --current --namespace=my-app 🔴 Ошибка 2: ServiceAccount с правами бога - Проблема: сервисный аккаунт default:default имеет права cluster-admin (да, было лень разбираться с правами). - Чем опасно: Злоумышленник → получил токен → полный контроль над кластером. - Как исправить: kubectl create rolebinding restricted-view \ --clusterrole=view \ --serviceaccount=default:default \ --namespace=default 🔴 Ошибка 3: Не включён PodSecurityPolicy (или его аналоги) - Проблема: Поды могут запускаться от root, монтировать /etc и делать другие жуткие вещи. - Чем опасно: Escalation privileges → хостовая система под ударом. - Как исправить: # Для новых версий K8s (PSP deprecated, но есть замены): kubectl label ns my-app pod-security.kubernetes.io/enforce=restricted 💥 Бонус: Если ваш кластер уже живёт с этим годами — проверьте его : kubectl get pods --all-namespaces -o json | grep "serviceAccount: default" Есть и другие ошибки, которые я сделал, если тема интересна, то напишите в комментариях пользуетесь ли k8s для своих проектов, что предпочитаете manages cluster или колхоз а-ля minicube?

В этом году мы с моими клиентами, которые приходят ко мне на консультации, поставили цель повысить долю участия ИИ в процессе разработки ПО до 15% (а в идеале до 30%). Обсудили, где и как можно применить способности машины к автоматизации рутинных задач, как можно использовать парное программирование с ИИ, и другие задачи. Я подумал, что многие люди испытывают страх перед тотальными изменениями в работе, которые неминуемо коснутся каждого разработчика, поэтому написал заметку «Как конкурировать с ИИ в ближайшие пять лет». Доступно для подписчиков уровня STREAM. 💡

; проверка типа второго аргумента "b"
0x109706503    43  4c8b4520             REX.W movq r8, [rbp+0x20]
0x109706507    47  41f6c001             testb r8,0x1
0x10970650b    4b  0f8559000000         jnz 0x10970656a  <+0xaa>
; само сложение
0x109706511    51  03cf                 addl rcx,rdi

; если переполнение, то переход
0x109706513    53  0f8055000000         jo 0x10970656e  <+0xae> 

; упаковка результата
0x109706519    59  48c1e120             REX.W shlq rcx, 32

; результат кладем в rax
0x10970651d    5d  488bc1               REX.W movq rax,rcx

;  ====== эпилог ==========
0x109706520    60  488b4de8             REX.W movq rcx, [rbp-0x18]
0x109706524    64  488be5               REX.W movq rsp,rbp
0x109706527    67  5d                   pop rbp

0x109706528    68  4883f903             REX.W cmpq rcx,0x3
0x10970652c    6c  7f03                 jg 0x109706531  <+0x71>
0x10970652e    6e  c21800               ret 0x18

0x109706531    71  415a                 pop r10
0x109706533    73  488d24cc             REX.W leaq rsp, [rsp+rcx*8]
0x109706537    77  4152                 push r10
0x109706539    79  c3                   retl

0x10970653a    7a  48ba0000000010000000 REX.W movq rdx,0x1000000000
0x109706544    84  52                   push rdx
0x109706545    85  48bb107d7a0401000000 REX.W movq rbx,0x1047a7d10
0x10970654f    8f  b801000000           movl rax,0x1
0x109706554    94  48bef911d866da2e0000 REX.W movq rsi,0x2eda66d811f9    ;; object: 0x2eda66d811f9 <NativeContext[280]>
0x10970655e    9e  e89db146fb           call 0x104b71700  (CEntry_Return1_ArgvOnStack_NoBuiltinExit)    ;; near builtin entry
0x109706563    a3  eb82                 jmp 0x1097064e7  <+0x27>
0x109706565    a5  90                   nop

Как видите, здесь довольно длинный ASM-кусок, в котором я добавил пояснения, чтобы было понятно по смыслу, что происходит, само сложение выполняется одной командой addl, всё остальное — это подготовки и обработка исключений, давайте коротко подведём итоги: 👑 сначала идёт пролог — это стандартная часть, которая сохраняет значения регистров; 👑 далее идёт загрузка аргументов функции «a» и «b»; 👑 проверка, что загруженные аргументы — это числа; 👑 далее идёт распаковка (обратите внимание, что на самом деле распаковка "b" сделана раньше, чем реальная проверка типа, это спекулятивная оптимизация, которая требует отдельного рассмотрения, как и само понятие «распаковка»); 👑 делаем вычисление; 👑 проверяем, что всё ок; 👑 упаковываем результат; 👑 финальные проверки и эпилог. Более детально каждую из частей мы рассмотрим в будущих статьях, а пока ставь лайк, если тема тебе интересна. Полный вариант статьи

TurboFan: анализ оптимизаций в V8 с помощью ассемблера (часть 1) Чем глубже мы узнаем языки программирования, тем больше начинаем любить и ценить ассемблер. Сегодня покажу, как знание ассемблера помогает в изучении возможностей движка V8. V8 — это движок для работы с языком JavaScript, он используется в NodeJS и браузере Chrome. Одна из особенностей этого движка — представление «горячего» кода в виде оптимизированных машинных инструкций. Для этого в движок интегрирован оптимизирующий JIT-компилятор TurboFan. Основные задачи, которые решает TurboFan: 💡 Анализ и оптимизация «горячих» функций (которые вызываются часто); 💡 Специализация кода под конкретные типы данных; 💡 Удаление избыточных операций; 💡 Векторизация вычислений; 💡 Инлайнинг функций. Для работы с машинным кодом традиционно используется ассемблер, поэтому давайте разберем небольшой пример, который позволит лучше понять, как работает TurboFan. В этой статье будет общее описание блоков кода, а в будущих статьях разберем детали каждого из них. Основные моменты, которые нужны для старта: 1️⃣ Мы будем использовать nodejs для получения машинного кода функции, для этого нужно запомнить следующий шаблон команды:

node --print-opt-code --code-comments -allow-natives-syntax your_script.js

2️⃣Мы будем использовать специальную инструкцию %OptimizeFunctionOnNextCall, без нее ничего не получится. Давайте сделаем простой скрипт:

// sum.js
function sum(a, b) {
return a + b;
}

// Прогреваем функцию (вызываем много раз, чтобы V8 её оптимизировал)
for (let i = 0; i < 10000; i++) {
sum(i, i + 1); // используем целые числа, чтобы TurboFan сделал оптимизацию именно под них
}

// Явно просим V8 оптимизировать функцию (требует --allow-natives-syntax) иначе в выводе не будет описане функции
%OptimizeFunctionOnNextCall(sum);
// Вызываем ещё раз (теперь с оптимизацией)
sum(1, 2);

Теперь запустим скрипт node --print-opt-code --code-comments -allow-natives-syntax sum.js, если мы сделали всё правильно, то получим огромный вывод на экран, из которого интересна вот эта часть:

--- Raw source ---
(a, b) {
return a + b;
}

--- Optimized code ---
optimization_id = 1
source_position = 22
kind = TURBOFAN
name = sum
stack_slots = 6
compiler = turbofan
address = 0x2edae09247a1

Instructions (size = 184)

; загрузка hidden класса объекта (проверка структуры)
0x1097064c0     0  488b59f8             REX.W movq rbx, [rcx-0x8]

; проверка контекста
0x1097064c4     4  f6433501             testb [rbx+0x35],0x1
0x1097064c8     8  0f85f2e03dfb         jnz 0x104ae45c0  (CompileLazyDeoptimizedCode)    ;; деоптимизация

; пролог
0x1097064ce     e  55                   push rbp
0x1097064cf     f  4889e5               REX.W movq rbp, rsp
0x1097064d2    12  56                   push rsi
0x1097064d3    13  57                   push rdi
0x1097064d4    14  50                   push rax

; выравнивание стека и проверка лимитов
0x1097064d5    15  4883ec08             REX.W subq rsp,0x8
0x1097064d9    19  488975e0             REX.W movq [rbp-0x20],rsi
0x1097064dd    1d  493b65a0             REX.W cmpq rsp, [r13-0x60] (external value (StackGuard::address_of_jslimit()))
0x1097064e1    21  0f8653000000         jna 0x10970653a  <+0x7a> ; если стек переполнен, переходим

;  ====== Основная функция ======

; Загрузка аргумента "a"
0x1097064e7    27  488b5518             REX.W movq rdx, [rbp+0x18]
0x1097064eb    2b  f6c201               testb rdx,0x1
0x1097064ee    2e  0f8572000000         jnz 0x109706566  <+0xa6>

; Загрузка аргумента "b"
0x1097064f4    34  488b4d20             REX.W movq rcx, [rbp+0x20]
0x1097064f8    38  48c1f920             REX.W sarq rcx, 32 ; сразу распаковка SMI для "b"

; Подготовка аргументов к сложению
0x1097064fc    3c  488bfa               REX.W movq rdi,rdx
0x1097064ff    3f  48c1ff20             REX.W sarq rdi, 32 ; распаковка для "a"

Любую проблему можно решить введением дополнительного уровня абстракции, кроме одной — слишком большого количества уровней абстракции.

Иногда слушаешь человека, вроде и говорит хорошо, вроде и по делу, а потом он брякнет что-то типа «идентификатору присвоили значение 10», и хочется плакать, ведь даже чат-бот знает, что с идентификатором значение можно только ассоциировать (или слинковать, кому как нравится), а присвоить значение можно только переменной. Хуже становится, только если особо гениальный ум скажет: «Так переменная — это и есть идентификатор», сразу становится понятно, что человек не понимает разницы между семантикой языка программирования и его синтаксисом. Для многих открытие, что переменная и идентификатор — это термины, которые существуют на разных уровнях абстракции. Да чего там, сам факт, что в программировании - всё есть абстракции, выглядит для человека как непосильная для осмысления и анализа мысль. 💡 Поэтому просто запомните, что переменная принимает и хранит значения, можете спросить у ИИ, почему это так, а идентификатор — это имя, которое обозначает переменные, функции, объекты, по сути, это просто ссылка. Идентификатор существует на уровне синтаксиса языка программирования, немного на уровне семантики (например, при определении области видимости). Когда уместно говорить «идентификатор», когда «переменная»? В случаях, когда речь идет о синтаксисе языка, можно говорить «идентификатор», а можно «имя переменной», что есть одно и то же, но когда речь идет об алгоритме, то правильно говорить «переменная». Надеюсь, мое объяснение поможет лучше разобраться и не использовать термины не по назначению.

Есть известная фраза «Преждевременная оптимизация — корень всех зол». Современные программисты используют эту фразу в качестве индульгенции своего невежества. Многие знают, что фраза принадлежит Дональду Кнуту — известному компьютерному учёному, автору монументального труда «Искусство программирования» (The Art of Computer Programming). Но мало кто знает контекст и изначальный посыл этой фразы, на самом деле в 1974 году Кнут написал статью «Structured Programming with go to Statements», где сказал:

«Программисты тратят колоссальное время на размышления и беспокойство о скорости некритичных частей своих программ, и эти попытки повысить эффективность на самом деле оказывают сильное негативное влияние при отладке и поддержке. Мы должны забыть о мелких оптимизациях, скажем, в 97% случаев, потому что преждевременная оптимизация — корень всех зол. И всё же наше внимание к этим критичным 3% не должно ослабевать.»

Всегда ли короткие имена переменных - зло? Никто не будет спорить с тем, что имена переменных в коде должны быть понятными и выразительными. Но с тем, что выразительное имя - это всегда полное длинное описание из которого можно сделать вывод для чего существует та или иная переменная - это тема для спора. Я люблю короткие имена переменных, люблю аббревиатуры, часто их использую и мне не нравится писать длинные имена по типу "encodedDataBasePasswordStr", даже с автокомплитом. Поэтому давайте сформулирую свои правила в отношении коротких имен переменных. 👑 Когда короткие имена приемлемы ✅В небольших методах с очевидным контекстом ✅В математических вычислениях, где традиционно используются короткие обозначения ✅Для итераторов в небольших циклах ✅В лямбда-функциях, где контекст ясен Пример оправданного короткого имени.

function calculateDistance(x1: number, y1: number, x2: number, y2: number): number {
    const dx = x2 - x1;
    const dy = y2 - y1;
    return Math.sqrt(dx * dx + dy * dy);
}

В этом случае: x1, y1, x2, y2 - стандартные математические обозначения координат dx, dy - общепринятые сокращения для "delta x" и "delta y" А типы параметров (number) делают назначение переменных ещё понятнее 👑 Когда короткие имена недопустимы Однако есть ситуации, когда короткие имена действительно становятся проблемой: ✅ В больших методах, где контекст теряется ✅ Для переменных с широкой областью видимости ✅Когда назначение переменной неочевидно ✅Для булевых флагов, где важно понимать критерий Пример плохого использования:

function processUserData(u: User, d: DataProcessor, c: Config) {
    // ... 50 строк кода ...
    if (u.s) { // Что такое 's'? Статус? Субscription? Счёт?
        d.p(u); // Что делает 'p'? process? print? persist?
    }
}

При этом вместо 'u' вполне можно было использовать сокращения usr, а вместо 'c' использовать cfg, это устоявшиеся сокращения, поэтому использовать их можно. Когда есть возможность аннатировать переменную ее типом, с учетом небольшого размера функции, нормальным становится и вариант с u:

interface User {
    id: string;
    name: string;
    age: number;
}

// Хорошо - тип ясен из контекста
function greet(u: User) {
    console.log(`Hello, ${u.name}!`);
}

Для итераторов в небольших циклах короткие имена допустимы:

const numbers = [1, 2, 3];
// i - общепринятое имя для индекса
for (let i = 0; i < numbers.length; i++) {
    console.log(numbers[i]);
}

В функциональном программировании для простых операций:

const users = [{name: 'Alice'}, {name: 'Bob'}];
// n - понятно в контексте map
const names = users.map(u => u.name);

👑 Надеюсь, приведенные пример убедили вас, что в зависимости от ситуации короткие имена переменных не только допустимы, но и помогают писать выразительный код.

Всегда ли короткие имена переменных - зло? Никто не будет спорить с тем, что имена переменных в коде должны быть понятными и выразительными. Но с тем, что выразительное имя - это всегда полное, понятно описание из которого можно понять для чего существует та или иная переменная - это тема для спора. Я люблю короткие имена переменных, люблю аббревиатуры, часто их использую и мне не нравится писать длинные имена по типу "encodedDataBasePasswordStr", даже с автокомплитом. Поэтому давайте сформулирую свои правила в отношении коротких имен переменных. 👑 Когда короткие имена приемлемы ✅В небольших методах с очевидным контекстом ✅В математических вычислениях, где традиционно используются короткие обозначения ✅Для итераторов в небольших циклах ✅В лямбда-функциях, где контекст ясен ✅ Пример оправданного короткого имени.

function calculateDistance(x1: number, y1: number, x2: number, y2: number): number {
    const dx = x2 - x1;
    const dy = y2 - y1;
    return Math.sqrt(dx * dx + dy * dy);
}

В этом случае: x1, y1, x2, y2 - стандартные математические обозначения координат dx, dy - общепринятые сокращения для "delta x" и "delta y" А типы параметров (number) делают назначение переменных ещё понятнее 👑 Когда короткие имена недопустимы Однако есть ситуации, когда короткие имена действительно становятся проблемой: ✅ В больших методах, где контекст теряется ✅ Для переменных с широкой областью видимости ✅Когда назначение переменной неочевидно ✅Для булевых флагов, где важно понимать критерий Пример плохого использования:

function processUserData(u: User, d: DataProcessor, c: Config) {
    // ... 50 строк кода ...
    if (u.s) { // Что такое 's'? Статус? Субscription? Счёт?
        d.p(u); // Что делает 'p'? process? print? persist?
    }
}

При этом вместо 'u' вполне можно было использовать сокращения usr, а вместо 'c' использовать cfg, это устоявшиеся сокращения, поэтому использовать их можно. Когда есть возможность аннатировать переменную ее типом, с учетом небольшого размера функции, нормальным становится и вариант с u:

interface User {
    id: string;
    name: string;
    age: number;
}

// Хорошо - тип ясен из контекста
function greet(u: User) {
    console.log(`Hello, ${u.name}!`);
}

Для итераторов в небольших циклах короткие имена допустимы:

const numbers = [1, 2, 3];
// i - общепринятое имя для индекса
for (let i = 0; i < numbers.length; i++) {
    console.log(numbers[i]);
}

В функциональном программировании для простых операций:

const users = [{name: 'Alice'}, {name: 'Bob'}];
// n - понятно в контексте map
const names = users.map(u => u.name);

👑 Надеюсь, приведенные пример убедили вас, что в зависимости от ситуации короткие имена переменных не только допустимы, но и помогают писать выразительный код.

Заметил за собой странное искажение, которое возникает при работе с LLM. Когда что-то не получается, я злюсь на себя, думая что не могу правильно сформулировать задачу, так чтобы ИИ меня понял. Ищу другие промпты, пытаюсь играть с версиями моделей, менять русский на английский и т.д. Мысль, что я пытаюсь заставить решать GPT что-то выходящие за рамки его возможностей в голову почему-то не приходит.

У нас изменился способ авторизации на soer.pro, теперь основной вход через логин и пароль, если у вас есть подписка, чтобы ее не потерять, нужно на странице логина пройти регистрацию. Спасибо за понимание.

Устраивайтесь поудобнее: будем разворачивать ВМ 🚬 Делимся новым видео на канале S0ER. Женя рассказал, как выбрать и настроить ВМ, как установить Docker, Node.js и другие инструменты для разработки, а также как настроить терминал и плагин Tix для совместной работы. Посмотреть можно по ссылкам: 😶‍🌫️ YouTube 😶‍🌫️ VK видео 😶‍🌫️ RuTube Еще больше сценариев использования платформы Cloud․ru Evolution ищите по ссылке 👈

Code of Leadership #31 - Hooked: how to build habit-forming products (Рубрика #Management) Новый эпизод подкаста посвящён обсуждению книги Нира Эяля «На крючке» и её модели создания продуктов, формирующих привычки. Для обсуждения книги пришел Евгений Сергеев (S0ER), который поделился опытом применения модели в разработке ПО, обсуждения её этических аспектов и влияния на пользователей. В общении мы затронули темы поведенческих триггеров, адаптации продуктов к привычкам пользователей, а также эволюции технологий, программирования и роли разработчиков. Особое внимание уделили важности обратной связи, доверия пользователей и интеграции продуктов в экосистемы. Евгений уже много лет публикует хорошие видео на Youtube на канале S0ER, а также у него есть каналы в tg (@softwareengineervlog и @soer_live). Он много рассказывает про хард скиллы в обще, а также про проектирование и архитектуру в частности. Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Architecture #Software #Engineering #ProductManagement #Management #Economics

Сегодня начал дарить подарки 🎁 за развитие айти блогинга, думаю, что это отличный способ мотивировать авторов развиваться и делать ещё более крутой контент. Сегодня я раздал подарков на 10.000 рублей, предпочтение отдавал молодым техническим каналам, авторы которых продвигают хардскилы, поэтому проверьте, если у вас появилась 🤵 в подарках канала, то это от меня. В следующий раз раздам подарков ещё больше. Поэтому накидайте в комментарии хороших технических телеграм пабликов 💡 И главное помните хардскилы - это сила. 💡

Фальсифицируемость стратегии «сверхзанятости». Когда мы выбираем ту или иную стратегию, нам нужно понять, насколько хороша идея следовать тем или иным принципам? Можно любую стратегию рассматривать как упрощенную научную теорию, если теория научна, то мы можем ее фальсифицировать, это важный момент, так как прежде чем оценивать стратегию нужно понять, а проверяема ли она в принципе. Может, нельзя проверить, то и оценивать смысла нет. Сверхзанятость — это стратегия, при которой сотрудник одновременно работает более чем на одной работе. Определим для проверки успешности следующие критерии: совокупный доход и надежность (риск увольнения). Проверим стратегию на «фальсифицируемость», введя следующие критерии. 1. Сохранение всех рабочих мест - Критерий фальсифицируемости: Если человек теряет одну или несколько работ из-за невозможности совмещать их (например, из-за конфликта графиков, снижения качества работы или раскрытия факта overemployment), стратегия считается неудачной. Пример: Сотрудник был уволен с основной работы после того, как работодатель узнал о его подработке. 2. Качество выполнения задач - Критерий фальсифицируемости: Если качество работы на одной или нескольких должностях значительно снижается (например, из-за переутомления или нехватки времени), стратегия считается неудачной. Пример: Проекты сотрудника на основной работе начали срываться, и он получил выговор от руководства. 3. Отсутствие негативных последствий для здоровья - Критерий фальсифицируемости: Если у человека появляются проблемы со здоровьем (физические или психические) из-за переутомления, стратегия считается неудачной. Пример: Сотрудник начал испытывать хроническую усталость, бессонницу или стресс, что привело к ухудшению его общего состояния. 4. Сохранение дохода - Критерий фальсифицируемости: Если общий доход от всех работ не покрывает расходы (например, из-за штрафов, снижения зарплаты или увольнения), стратегия считается неудачной. Пример: После увольнения с одной из работ общий доход сотрудника упал ниже уровня, необходимого для покрытия его финансовых обязательств. 5. Отсутствие юридических или этических проблем - Критерий фальсифицируемости: Если сотрудник сталкивается с юридическими последствиями (например, судебные иски от работодателей) или теряет репутацию в профессиональной среде, стратегия считается неудачной. Пример: Работодатель подал в суд на сотрудника за нарушение трудового договора, запрещающего подработку. 6. Достижение личных целей - Критерий фальсифицируемости: Если overemployment не помогает достичь поставленных целей (например, накопление средств, развитие навыков или карьерный рост), стратегия считается неудачной. Пример: Сотрудник взял вторую работу, чтобы накопить на дом, но из-за переутомления и снижения эффективности не смог достичь этой цели. 👑 Оценка успешности. Так как мы смогли сформулировать, что стратегия "проверяема", и в некоторых случаях ее можно считать неудачной, но при этом она все равно имеет право на существование, то теперь давайте оценим ее качество. Важно уточнить, что фальсифицируемость — это не просто проверяемость, а возможность опровергнуть стратегию при определённых условиях. Например, если стратегия сверхзанятости приводит к потере работы, это опровергает её успешность. Исходя из имеющихся данных, стратегия плохо реализуема на «длинной дистанции», потому что вероятно наступление одного из событий: выгорание, профессиональная «яма», увольнение, конфликт интересов. При этом есть исключения, когда некоторые люди могут успешно совмещать несколько работ без серьёзных последствий, особенно если они тщательно планируют своё время и ресурсы. Стоит ли рисковать? Тут каждый должен ответить для себя сам, для многих не существует иного варианта заработать за счет карьерного роста или предпринимательской деятельности, поэтому за неимением лучшего используют то, что есть. Но в связи с рискованностью стратегии я бы не советовал оформлять долгосрочные кредиты, лучше рассчитывать на накопление средств, а то по итогу можно оказаться не только без средств, но и без имущества.

На S0ER Talks выпустил видео "Технологические моменты разработки", немного попытался затронуть вопрос, что не кодом единым живет продукт. 👀 YouTube | 👀VK | 📹RuTube

На S0ER Talks выпустил видео "Технологические моменты разработки", немного попытался затронуть вопрос, что не кодом единым живет продукт. 👀 YouTube | 👀VK | 📹RuTube

Что за «база», которая нужна в IT? Что такое эта ваша «база»? Все знают, что она нужна, но проблема в том, что никто не может толком сказать, о какой такой «базе» идет речь. Профессионалы под базой понимают не набор знаний, который можно чекнуть вопросами по типу «Скажи, сколько битов в одном байте?», а способность человека усваивать новые навыки при развитии в IT. База — это набор навыков, которые позволяют человеку декомпозировать задачи, искать алгоритмическое решение, уметь планировать ресурсы и правильно распределять нагрузку. Условные «тренажеры» для формирования базы — это книги, «коммерческая» практика, обмен опытом с коллегами и прочие вопросы. Но есть нюанс: сами по себе книги не являются этой самой базой, а только инструментом! Давайте на примере. Вы наверняка слышали фразу, мол, если хочешь вкатиться в IT, то тебе нужна БАЗА, которую лучше постигать с ментором, и прочие бла-бла-бла. Помните этот идиотский пример про «спортзал» и тренера? Типа «хочешь идеальное тело, то тебе будет проще его получить с тренером». Подвох тут в том, что идеальное тело не достигается исключительно правильным подходом к нужным тренажерам под присмотром тренера. Любой, кто хоть раз ставил перед собой задачу получить идеальное тело, знает, что существует огромное количество нюансов: гормоны, возраст, метаболизм, генетика, режим дня и т. д. И кроме всего этого еще есть годы упорного труда. Хороший тренер помогает не только составить программу тренировок, но и отправляет сдать анализы, посмотреть гармоны, скорректировать режим дня. И базой в спортзале обладает не тот, кто знает кучу умных слов, а тот, кто имеет натренированное тело. База — это результат труда и длительного воздействия на организм с помощью упражнений. Натренированный спортсмен может выполнять нужное количество повторений нужных упражнений, сведя риск травмы к минимуму. Человек без спортивной базы просто получит травму. С мозгом всё ровно так же: база — это проработанный мозг, который, как и тело, требует тренировки для формирования необходимых связей между нейронами. Тренировать мозг так же обязательно, как качать тело. В нужный момент тренировка помогает концентрироваться и решать сложные задачи, и получать прочие бонусы, связанные с вполне практическими аспектами работы. Именно на эту базу легко ложатся новые алгоритмы, новые знания, новые подходы. Если у специалиста нет базовой подготовки, то он будет вечным почемучкой, который создает кучу головной боли коллегам и не приносит особой пользы. В итоге при первой возможности его сольют за счет сокращения. Когда я говорю про базу, я лишь в очень малой части имею в виду знания (по сути, знания устаревают очень быстро). Куда важнее те навыки и ментальные способности, которые приобретает человек, работая над своим разумом. Когда вам в очередной раз начнут впаривать про спортзал и волшебных менторов, задайте вопрос: «Что я буду УМЕТЬ после твоей помощи, какие НАВЫКИ ты поможешь сформировать, чтобы дальше я шел своим путем без постоянной необходимости возвращаться к тебе при каждом новом задании на работе?» Удивитесь, но вам расскажут про спортзал и тренажеры, про «чек-листы с правильными ответами» и ни слова про умения и навыки. Потому что никаких умений и навыков вам давать не планируют. Так работает современный бизнес: сначала вам скажут «пройдешь собес, и все завертится», а потом «подпишут» на помощь при прохождении испытательного срока. Еще раз запомните: база — это навыки и опыт, которые помогают сформировать ваш главный инструмент как инженера — ваш мозг!

Вышло видео "Архитектура веб-приложения для облачного решения" Давно хочу рассказать о том, как можно мигрировать приложение в облако, сделать обзор на разные облачные инструменты и показать как можно управлять ресурсами в зависимости от нагрузки. Первый шаг к реализации этой идеи сделан, на канале появилось вводное видео в котором я рассказал: 👑 как будет строиться архитектура NarisApp в облаке 👑 какие ресурсы понадобятся 👑 какие проблемы заметны уже сейчас Видео доступно на всех площадках: 👀YouTube | 👀VK | 📹RuTube

Пластичность психики Норман Дойдж в своей книге "Пластичность мозга" раскрывает вопросы, связанные с пластичностью психики. В норме у здорового человека психика находится в состоянии равновесия благодаря своей способности адаптироваться к изменениям. В жизни постоянно происходят различные неприятные события, как мелкие, так и значительные. Пластичность психики позволяет человеку переключать внимание, адаптироваться к новым условиям и справляться даже с трудными ситуациями. Однако иногда психика становится ригидной (негибкой). В таком состоянии человек вместо того, чтобы адаптироваться и переживать проблемы, начинает зацикливаться на них. Это приводит к концентрации на негативных моментах, даже если они произошли давно. В результате человек может долго переживать из-за мелких обид или неудач. Если вовремя не обратиться к специалисту, такое состояние может привести к неврозам, бессоннице и другим психологическим трудностям. Как развить психическую гибкость? Вот несколько советов, которые помогут сохранить и развить пластичность психики: 👑 Осознайте свои ценности и жизненные приоритеты. Понимание того, что для вас действительно важно, поможет сосредоточиться на главном. 👑 Четко определите свои стратегические цели. Это позволит вам двигаться вперед, не отвлекаясь на второстепенное. 👑 Поймите, как ваши ценности связаны с вашими целями. Это поможет отфильтровать лишнее и сосредоточиться на том, что действительно имеет значение. 👑 Работайте над тем, что важно именно для вас. Не стоит принимать чужие ценности и цели как свои собственные. 👑 Старайтесь реагировать проактивно, а не реактивно. Проактивность помогает сохранять контроль над ситуацией и не поддаваться эмоциям. 👑 Помните, что никто не идеален. Вы не обязаны оправдывать чужие ожидания — важно оставаться верным себе. Если интересно продолжить обсуждение книги, то подключайтесь в группу Книжник на soer.pro

История успеха: NPM — как небольшой проект стал основой экосистемы JavaScript Сегодня поговорим о NPM (Node Package Manager) — одном из самых важных инструментов в мире JavaScript. Это не просто менеджер пакетов, а целая экосистема, которая изменила способ разработки программного обеспечения. Давайте разберемся, как NPM стал таким успешным. Начало: 2009 год В 2009 году Райан Дал (Ryan Dahl) представил миру Node.js — среду выполнения JavaScript на стороне сервера. Node.js быстро набрал популярность благодаря своей асинхронной модели и высокой производительности. Однако разработчикам не хватало удобного способа делиться кодом и управлять зависимостями. Именно тогда на сцену вышел NPM. Его создал Айзек Шлютер (Isaac Z. Schlueter) в 2010 году. Изначально NPM задумывался как простой инструмент для установки и управления пакетами в Node.js. Первая версия NPM была выпущена в январе 2010 года, и уже через несколько месяцев она стала стандартом для работы с пакетами в Node.js. Рост экосистемы NPM быстро стал популярным благодаря своей простоте и удобству. Вот несколько ключевых факторов, которые способствовали его успеху: Простота использования NPM предоставил разработчикам простой интерфейс командной строки для установки пакетов. Например, чтобы установить пакет, достаточно было выполнить команду: npm install package-name Централизованный реестр пакетов NPM создал централизованный реестр пакетов, где разработчики могли публиковать свои библиотеки и находить нужные инструменты. Это сделало процесс обмена кодом быстрым и удобным. Поддержка зависимостей NPM автоматически управлял зависимостями между пакетами, что значительно упрощало разработку. Файл package.json стал стандартом для описания проекта и его зависимостей. Расцвет: 2014–2016 годы К 2014 году NPM стал неотъемлемой частью экосистемы JavaScript. Количество пакетов в реестре росло экспоненциально. Рост числа пакетов В 2014 году в реестре NPM было около 100 000 пакетов. К 2016 году их количество превысило 350 000. NPM Inc. В 2014 году Айзек Шлютер основал компанию NPM Inc., чтобы коммерциализировать проект. Компания начала предлагать платные услуги, такие как приватные репозитории и инструменты для корпоративных клиентов. Интеграция с другими инструментами NPM стал интегрироваться с популярными инструментами, такими как Webpack, Babel и React, что сделало его еще более востребованным. Кризис и восстановление В 2016 году NPM столкнулся с серьезным кризисом. Один из разработчиков удалил свой пакет left-pad, что привело к сбою в работе тысяч проектов. Этот инцидент показал уязвимость экосистемы, зависимой от небольших пакетов. Однако NPM быстро отреагировал на ситуацию: Была введена политика, запрещающая удаление пакетов, которые используются другими проектами. Команда NPM начала активно работать над улучшением стабильности и безопасности реестра. NPM сегодня Сегодня NPM — это огромная экосистема, которая включает: Более 2 миллионов пакетов в реестре. Десятки миллионов разработчиков по всему миру. Интеграцию с современными инструментами, такими как Yarn и pnpm. В 2020 году компания GitHub (принадлежащая Microsoft) приобрела NPM Inc. Это событие укрепило позиции NPM как стандарта для управления пакетами в JavaScript. Причины успеха NPM: - Простота и удобство NPM сделал процесс управления пакетами настолько простым, что даже новички могли легко его использовать. - Сильное сообщество Открытость и поддержка сообщества стали ключевыми факторами роста. - Адаптивность NPM смог пережить кризисы и адаптироваться к меняющимся требованиям разработчиков. - Коммерциализация Создание NPM Inc. позволило проекту развиваться и предлагать новые функции для корпоративных клиентов. Заключение NPM — это не просто инструмент, а целая экосистема, которая изменила мир разработки. Его история успеха показывает, как OpenSource-проект может стать стандартом индустрии и вдохновить миллионы разработчиков по всему миру.