S0ER - архитектура и кодинг

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

На 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-проект может стать стандартом индустрии и вдохновить миллионы разработчиков по всему миру.

Низкий уровень: как выглядят вызовы функций по указателю на ASM В языках высокого уровня, таких как C или C++, часто используются указатели на функции. Это позволяет динамически выбирать, какую функцию вызвать в runtime. Но как это выглядит на уровне ассемблера? Давайте разберемся. Для начала рассмотрим простой пример на C, где используется указатель на функцию: int callme() { return 1; } void main() { int (*func_ptr)() = callme; func_ptr(); } Здесь мы создаем указатель на функцию func_ptr, который указывает на функцию callme, и затем вызываем функцию через этот указатель. Как это выглядит в ассемблере? Используем Compiler Explorer, чтобы преобразовать этот код в ассемблер. Вот что получилось: callme: push rbp mov rbp, rsp mov eax, 1 pop rbp ret main: push rbp mov rbp, rsp sub rsp, 16 mov QWORD PTR [rbp-8], OFFSET FLAT:callme mov rax, QWORD PTR [rbp-8] call rax nop leave ret Что здесь происходит? Создание указателя на функцию: В функции main мы видим, что адрес функции callme сохраняется в памяти по адресу [rbp-8]: mov QWORD PTR [rbp-8], OFFSET FLAT:callme Здесь OFFSET FLAT:callme — это адрес функции callme в памяти. Загрузка указателя в регистр: Затем этот адрес загружается в регистр rax: mov rax, QWORD PTR [rbp-8] Вызов функции по указателю: После этого происходит вызов функции через регистр rax: call rax Инструкция call использует значение в регистре rax как адрес функции, на которую нужно перейти. Пролог и эпилог Как и в случае с обычным вызовом функции, здесь также присутствуют пролог и эпилог: Пролог: push rbp mov rbp, rsp sub rsp, 16 Здесь сохраняется значение rbp, устанавливается новый кадр стека и выделяется место для локальных переменных. Эпилог: leave ret Здесь восстанавливается значение rbp и выполняется возврат из функции. Пример с массивом в функции Давайте добавим массив в функцию callme и посмотрим, как это повлияет на ассемблерный код: int callme() { char a[128]; return 1; } В ассемблере это будет выглядеть так: callme: push rbp mov rbp, rsp sub rsp, 8 ;

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

Сделал мастеркласс по версионированию документов в SPA В этой задаче мы разберемся, как спроектировать свой подход к версионированию документов в проекте и как это помогает решать следующие проблемы: 👉 множественная обработка одних и тех же данных (например, мы редактируем документ с мобильного и десктопа), нужно понять, какие данные в каком порядке были изменены; 👉двойная загрузка данных на клиенте и, как следствие, потеря несохраненных изменений; 👉ошибки синхронизации стейта (кто раньше, кто позже). В качестве примера взят механизм создания документов, которые используются в NarisApp. Посмотреть воркшоп на платформе. так же можно посмотреть видео с описанием проблемы.