S0ER

Пока мы тут морлока обсуждали, случилось страшное - нейросети догнали по популярности пиво и слово нейросеть прочно вошло в обиход. Кстати, я только сегодня думал, ChatGPT написан на Python (ну понятно там еще и Си где-то под капотом, куда без него?), но по факту получается, Python изменил мир! Вот бы чего никогда не подумал.

Очередная книга на вечер. Я стараюсь читать литературу не конкретно по каким-то фреймворкам и библиотекам, а что-то концептцальное, что позволяет получить технологическое преимущество в проекте. Сегодня основные тренды связаны с массовой обработкой и хранением данных. DataMesh - это современный подход к извлечению аналитических данных предприятия. Штука полезная и нужная.

Запись пятничного техтолка, смачно поговорили про трудоголизм.

С этого момента я считаю историю с мурычем закрытой, после его осознанного отказа выйти со мной один на один в публичном стриме, я доказал, что он не является тем, за кого себя выдает и мои претензии к нему обоснованы. По поводу того, что я как-то не так себя вел, то я оставался ровно в рамках тех моральных принципов, которые продвигает этот человек и в рамках поведения, которое этот человек себе позволяет. Надеюсь, что небольшая встряска, которую я ему устроил, приведет в чувство как его сообщество, так и его самого. P.S. ну и самое главное, и кому оказалось слабо?

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

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

4.1. Решение задач на codewars (например, sql движок, рекурсивный спуск) 4.2. Сбор и анализ исходников (на пример OBS) 4.3. Архитектурные вопросы 4.4. Ассемблер (мурыч не знает, что машинный код !== asm) 4.5. Числа с плавающей запятой, разные аспекты программирования мурыч: 4.1. Спека JS 4.2. V8 оптимизации ??? Вывод: ошибки в теории, необоснованные утверждения, отсутствие образования, придуманные термины, непонятная практика (если вообще есть). На чем строится мысль, что мурыч может советовать как делать проекты и писать код для продуктовых задач?

О чем я хочу поговорить с мурычем Основной тезис: "Мурыч - это виндертон 2.0". Что делал виндертон: 1. Сначала снимал хорошие технические ролики по спеке Си (уровня сеньера) 2. Далее канал получил развитие и Виндертон начал приписывать себе опыт и "хуесосить" других инженеров 3. Завел Patreon 4. Начал продавать пданы Что делает мурыч: 1. Сначала снимал ролики по JS 2. Начал приписывать себе знания архитектуры, ФП, ООП и другой теории, оскорбляет других инженеров 3. Завел патреон 4. Планы? Рассмотрения требует п. 2 - приписывание опыта 1. Предпосылки Знания - не бинарная оценка, а градиент, поэтому нужно оценивать не их наличие или отсутствие, а насколько они глубоки. Мурыч, раздает бинарные оценки "может/не может", "знает/не знает", "должен/не должен", однако на свои ошибки закрывает глаза, почему же учит людей, если сам ошибается? 2. Компетенция (теория, которую мурыч не знает или не рассказывает) Утверждения мурыча, которые противоречат теории ниже: 1. В редьюсерах функция математически доказуема, в for нет 2. Типы не нужны (тайпскрип - говно) 3. BigO - фигня (он готов котенка убивать, за каждое упоминание BigO) 4. Утверждение, что ФП базируется исключительно на лямбда 5. Утверждение, что лямбда изначально создавалась для создания алгоритмов (вообще, рассмотрение лямбды как языка программирования) 2.1 лямбда исчичление 2.1.1 проблема вычислимости 2.1.2 проблема разрешения 2.1.3 лямбда-исчисление как основа вычислений (книга "Теория вычислений для программистов") 2.1.4 Лямбда и машина тьюринга 2.2. Как лямбда-используется в ФП Основное утверждение Соера: "правильно типизированный лямбда терм завершается". ФП - лямда + Категория типов + теория категорий Пример, категория Хаск (которая не совсем категория) - Типы как решение проблем корректности программ (Пирс "Типы в языках программирования") - Соответствие Карри-Говарда (конструктивная логика) - Алгоритм Хиндли-Милнера - Полиморфизм в значении типов - Операционная и денатационная семантика - Невозможность проверить семантику - Структура != не семантика (поговорить в чем разница) - Корректность - продвижение и сохранение - классы эквивалентности (как не указав класс эквивалентности сравнивать const [ a, b] = value и const {0: a, 1: b} = value, ломается на генераторах) 2.3 Алгоритмы (книга Кормена "Алгоритмы") - проеб мурыча с мемоизацией (Динамическое программирование) - проеб мурыча с Мерой Хэмминга - проеб с "оптимизацией" на leetcode - Теорема Райса и невозможность создать универасльный алгоритм оптимизации - доказательство алгоритмов с for (индукция, инвариант) 2.4. Анализ сайта Соера (что не увидел мурыч): - Защиту через неясность (Security through obscurity) - Access + Refresh токены - Fingerprint - Рэйт лимиты - Заголовки безопасности (как способ косвенного анализа используемых инструментов) - Разницу Web1.0 и Web2.0 - современные архитектуры сервисной/микросервисной организации 3. Практика (что есть у Соера, а что у мурыча, что он делает вывод о некомпетенции Соера в создании сайтов?) Достижения Соера: 3.1 Красивый код, но что за ужас на стримах показывает мурыч? Это фп, структурный подход или что? 3.2 Метархия: - интегрировал PassportJS для Oauth - сделал свою реализацию Metacom - создал небольшой проект на Метархии (obsoverlay) - сделал Issue с ошибкой обработки параметров 3.3. Сделал учебный проект (бесплатный) через который прошли более 160 человек за Год 3.4. Архитектурные стримы, воркшопы 3.5. Видео на канале (см. ниже) 3.6. XDonate 3.7. ObsOverlay Достижения Мурыча: 3.1 Сайт не доделан 3.2. На сайте какие-то залипушные Cache и ленивая загрузка картинок 3.3. Пустой гитхаб 3.4. Делал что-то для метархии, но что? 3.5. Что вообще заставляет мурыча считать, что он хорош в практике? 4. Иженерные увлечения (что заставляет говорить мурыча, что Соер не шарит?) Соер:

Завтра в 10:00 стрим с мурычем. Я ему скидываю ссылку на зум, он подключается и шарит экран на своём стриме. Формат - каждый высказывает претензии и даёт свою оценку. Вывод каждый делает сам.

Сегодня узнал, что Валерий Лис снова вернулся на ютуб, я очень люблю этого автора, за его глубокие знания и техническую компетенцию, а главное за скромный характер. Я помню как несколько лет назад провел всю новогоднюю ночь на его стриме, где он писал программу для отображения фрактала Мандельброта. И это было очень круто! А еще Лис отлично знает ассемблер и X86 архитектуру, развлекается тем, что с нуля пишет эмулятор процессора и запускает на нем что-нибудь олдовое. В целом, если хакеры и существуют, то это Лис! А ссылку на видео я не дам, так как Лис очень скромный и явно этого не одобрит! Ура Лису!

Ну что, завтра у нас снова пятница, и может быть стоит провести еще один техтолк? Если да, то пишите темы, на которые хотите пообщаться, в комментарии к этому посту. Побеждает тема, которая наберет больше всего реакций!

Басня про математиков и программистов Решили как-то раз три математика на охоту сходить, да беда в том, что патроны у них старые были. Непонятно какие стреляют, а какие нет. Подумали они, подумали. И решили патроны в виде функций описать, если патрон стреляет, то функция "истину" возвращает, а если нет, то ложь. Да вот беда, если запустить функцию, то патрон ломается, и больше не работает. Пошел тогда первый математик к программисту на JavaScript, говорит, вот функция, напиши программу которая не запуская функцию проверяет что она возвращает. Подумал JS-разработчик, посмотрел функцию, видит, что если в функции встречается переменная "порох", то она вроде истину возвращает, если нет, то ложь. Написал быстро программу, отдал математику. Математик проверил свои патроны, пошел на охоту. Больше его никто и не видел. Второй математик пошел к Haskell разработчику, так как не доверял императивщикам. Начали они обсуждать проблему, да только поругались в пух и прах, не сошлись во мнении, что круче монада или функтор. До сих пор не разговаривают, так сильно поругались. А третий математик никуда не пошел, так как знал про теорему Райса. Купил новых патронов, сходил на охоту, добыл дичь и жил долго и счастливо. Мораль сей басни такова - хочешь жить долго и счастливо, не связывайся с программистами, особенно если они программируют на Haskell.

Вижу, что предыдущий пост вызывает сомнения у некоторых подписчиков. Давайте я дам другое объяснение. Итак, у нас есть функция f() которая считает время выполнения нашей программы в некотором окружении. Мы точно знаем, что эта функция многих переменных, более того, мы точно знаем, что одна из переменных - это O(n), т.е. функция выглядит как-то так: f(O(n), x1, ..., xn) Проблема в том, что функция f() на каждом вычисляющем устройстве своя, т.е. на самом деле - это множество функций. И все что мы точно знаем, что O(n) - это тривиальное свойство этой функции, а x1..xn - это нетривиальные свойства, а по теореме Райса мы точно знаем, что проверить наличие нетривиальных свойств функции - невозможно (эта задача неразрешима) Таким образом, улучшить работу алгоритма гарантированным способом можно только через оптимизацию O(n), в остальных случаях надо брать и рассматривать каждый конкретный запуск отдельно, искать те x1...xn, которые нам нужны (откидывая ненужные) и оптимизировать что-то конкретное, при этом мы никогда не будем уверены, что запуск который мы отпимизировали будет быстрее, чем запуск, который мы не оптимизировали (всегда лотерея). Собственно мой предыдущий пост как раз об этом - изучая алгоритмы вы получаете хороший инструмент улучшеня своего кода, уповая на "технические" оптимизации вы будете в ситуации "может да, а может нет". Поэтому попытки выработать "общие рекомендации как технически улучшить ваш код", которые всегда работают - это утопия. Пишите код красиво и понятно, а не занимайтесь решением "неразрешимых задач".

Про оптимизацию Многие начинающие разработчики думают, что зная внутреннюю реализацию (рантайм) языка можно получить огромный выигрыш в производительности, невзирая на алгоритм работы программы. Это не так. Общее правило гласит "сильный алгоритм лучше чем слабый + оптимизации". Оптимизировать на уровне языка имеет смысл только если уже нет возможности улучшить алгоритм, а проблемы с производительностью есть. На практике в большинстве случаев помогает поиск "сильного алгоритма", байтоебство как правило ничего не дает, там где алгоритм слабый. Чтобы проиллюстрировать проблему, я привел два скрина с leetcode, перый - это оптимизация от человека, который много лет изучает движок V8 и спеку JS, а второй решение "в лоб" от меня. Как видите, оставаясь в рамках одного и того же алгоритма, значительно усложнив запись кода и используя "технические трюки" добиться значимых результатов не получается. Поэтому учите алгоритмы, господа. Учите алгоритмы!

Стоило упомянуть Мурыча как тут же набежали агрессивные маслятки, которые знают, что такое "ЯваСкрипт". Ребята, отдыхайте, ваш "гуру" уже слился никакого "эпичного" разоблачения в прямом эфире не последовало, а после драки, как известно, кулаками не машут.