Важно! Я хочу ещё раз предостеречь своих подписчиков, в сети появились фейковые материалы в мой адрес:
- каналы от моего имени (Внимание! у одного из каналов скопировано отображаемое имя и аватарка с S0ER.live)
- комментарии форварднутые из фейковых каналов, а так же скриншоты этих сообщений
- аудиозаписи сделанные с использованием нейронок (дипфейки)
- вероятно есть и фейковые фото.

У меня есть только два канала где я пишу, активность в телеграм на других ресурсах я практически не веду. Обязательно проверяйте реальный userId, в том числе на похожее написание.

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

Вы не просили, но я выпустил очередной разговорный ролик для канала S0ER Talks
YouTube | VK | RuTube

Сделал мастеркласс по версионированию документов в SPA

В этой задаче мы разберемся, как спроектировать свой подход к версионированию документов в проекте и как это помогает решать следующие проблемы:

👉 множественная обработка одних и тех же данных (например, мы редактируем документ с мобильного и десктопа), нужно понять, какие данные в каком порядке были изменены;

👉двойная загрузка данных на клиенте и, как следствие, потеря несохраненных изменений;

👉ошибки синхронизации стейта (кто раньше, кто позже).

В качестве примера взят механизм создания документов, которые используются в NarisApp.

Посмотреть воркшоп на платформе. так же можно посмотреть видео с описанием проблемы.

Низкий уровень: как выглядят вызовы функций по указателю на 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 ; <-- обратите внимание, тут сработала Red Zone
  mov eax, 1
  leave
  ret

Здесь видно, что в прологе добавилась инструкция sub rsp, 128, которая выделяет место на стеке для массива a[128].

Вывод

Сегодня мы узнали, как вызов функций по указателю выглядит на уровне ассемблера.

Основные моменты:

Указатель на функцию — это просто адрес функции в памяти.
Вызов функции по указателю осуществляется через регистр, в котором хранится адрес функции.

Пролог и эпилог присутствуют как при обычном вызове функции, так и при вызове через указатель.

Таким образом, даже такие высокоуровневые конструкции, как указатели на функции, имеют свое прямое отражение в ассемблерном коде.

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

Что за «база», которая нужна в IT?

Что такое эта ваша «база»? Все знают, что она нужна, но проблема в том, что никто не может толком сказать, о какой такой «базе» идет речь.

Профессионалы под базой понимают не набор знаний, который можно чекнуть вопросами по типу «Скажи, сколько битов в одном байте?», а способность человека усваивать новые навыки при развитии в IT.

База — это набор навыков, которые позволяют человеку декомпозировать задачи, искать алгоритмическое решение, уметь планировать ресурсы и правильно распределять нагрузку. Условные «тренажеры» для формирования базы — это книги, «коммерческая» практика, обмен опытом с коллегами и прочие вопросы. Но есть нюанс: сами по себе книги не являются этой самой базой, а только инструментом!

Давайте на примере.

Вы наверняка слышали фразу, мол, если хочешь вкатиться в IT, то тебе нужна БАЗА, которую лучше постигать с ментором, и прочие бла-бла-бла. Помните этот идиотский пример про «спортзал» и тренера? Типа «хочешь идеальное тело, то тебе будет проще его получить с тренером». Подвох тут в том, что идеальное тело не достигается исключительно правильным подходом к нужным тренажерам под присмотром тренера.

Любой, кто хоть раз ставил перед собой задачу получить идеальное тело, знает, что существует огромное количество нюансов: гормоны, возраст, метаболизм, генетика, режим дня и т. д. И кроме всего этого еще есть годы упорного труда. Хороший тренер помогает не только составить программу тренировок, но и отправляет сдать анализы, посмотреть гармоны, скорректировать режим дня. И базой в спортзале обладает не тот, кто знает кучу умных слов, а тот, кто имеет натренированное тело. База — это результат труда и длительного воздействия на организм с помощью упражнений. Натренированный спортсмен может выполнять нужное количество повторений нужных упражнений, сведя риск травмы к минимуму. Человек без спортивной базы просто получит травму.

С мозгом всё ровно так же: база — это проработанный мозг, который, как и тело, требует тренировки для формирования необходимых связей между нейронами. Тренировать мозг так же обязательно, как качать тело. В нужный момент тренировка помогает концентрироваться и решать сложные задачи, и получать прочие бонусы, связанные с вполне практическими аспектами работы. Именно на эту базу легко ложатся новые алгоритмы, новые знания, новые подходы.

Если у специалиста нет базовой подготовки, то он будет вечным почемучкой, который создает кучу головной боли коллегам и не приносит особой пользы. В итоге при первой возможности его сольют за счет сокращения. Когда я говорю про базу, я лишь в очень малой части имею в виду знания (по сути, знания устаревают очень быстро). Куда важнее те навыки и ментальные способности, которые приобретает человек, работая над своим разумом.

Когда вам в очередной раз начнут впаривать про спортзал и волшебных менторов, задайте вопрос: «Что я буду УМЕТЬ после твоей помощи, какие НАВЫКИ ты поможешь сформировать, чтобы дальше я шел своим путем без постоянной необходимости возвращаться к тебе при каждом новом задании на работе?» Удивитесь, но вам расскажут про спортзал и тренажеры, про «чек-листы с правильными ответами» и ни слова про умения и навыки. Потому что никаких умений и навыков вам давать не планируют. Так работает современный бизнес: сначала вам скажут «пройдешь собес, и все завертится», а потом «подпишут» на помощь при прохождении испытательного срока.

Еще раз запомните: база — это навыки и опыт, которые помогают сформировать ваш главный инструмент как инженера — ваш мозг!