S0ER

У нас в клубе много профессионалов, которые открыто делятся знаниями, хочу порекомендовать человека из клуба, который завёл канал, где фиксирует мысли по менеджменту, канал называется "Management stuff". Не реклама, реально ведёт один из наших соеров.

На Boosty добавил запись стрима "Как разбить монолит на компоненты" (доступ только для подписчиков Boosty, так же стрим доступен на soer.pro)

Брендированные типы в typescript Привет, с вами снова @devmargooo и сегодня мы с вами поговорим о типизации в приложении на typescript. Структурная типизация в typescript, в отличие от номинативной, определяет совместимость типов, основываясь не на названии типа, а на его наборе полей. В этом структурная типизация похожа на утиную: если это выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка. К сожалению, это может приводить к проблемам. Следующий код не приведет к ошибке компиляции, несмотря на то, что тип some_string указан как string, а не Email :

type Email = string;

function auth(login:Email) {}

const some_string:string = "some_string";

auth(some_string); // ok

Тип string структурно идентичен типу Email , поэтому ошибки нет. Номинативные типы работают по-другому - они совместимы только при явном использовании. К сожалению, встроенной поддержки таких типов в typescript нет, но есть хак, который называют брендированием. Его суть заключается в том, что мы добавляем к типу уникальное свойство:

type Email = string & { _: 'Email' };

Теперь тип Email будет структурно не совместим с типом string. Мы получим ошибку компиляции:

type Email = string & { _: 'Email' };

function auth(login:Email) {}

const some_string:string = "some_string";

auth(some_string); // Argument of type 'string' is not assignable to parameter of type 'Email'.

Чтобы код заработал, нам придется явно указывать, что переменная имеет тип Email:

const some_string = "some_string" as Email;

Или добавить проверку в наш код, которая также будет выводить нужный нам тип:

function isEmail(value:string): value is Email {
    const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
    return emailRegex.test(value);
}

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

type Brand<B extends string, T> = T & { readonly _: B }

Пример использования:

type Email = Brand<'Email', string>;

Конвертируем строку в дату Способы получения даты из строки и основные ошибки, которые при этом допускают разработчики https://www.rajamsr.com/javascript-convert-string-to-date/

Так, пацаны, все меняется, нас заменит не ChatGPT, а Devin но это неточно!

Идет мужик по лесу, смотрит - другой мужик лес рубит топором. - Что делаешь? - Лес рублю. - Бензопила же рядом лежит. Возьми её - быстрее будет. - Я не умею ею пользоваться. - Инструкция лежит же рядом. Возьми, прочитай. - Мне некогда - лес рубить надо. К чему я вспомнил этот анекдот? Состояние кода может замедлить разработку более, чем на порядок, и продолжать замедлять по экспоненте. В процессе программирования программист вводит символы с клавиатуры не более 10% времени (зачастую - не более 1% времени). Остальное время он читает существующий код и борется со сложностью. Плохой код пишется одним программистом, однократно, не более 10% времени. А читается он всеми программистами команды, многократно, постоянно, более 90% времени программирования. Т.е. однократно написанный одним программистом плохой код будет замедлять всю команду более 90% её времени. Таким образом, фраза "некогда писать правильно" является самообманом. Если у команды медленный темп разработки, то он более чем на 90% времени вызван медленным чтением и затрудненным пониманием написанного ранее кода. Именно поэтому скорость разработки деградирует обычно в геометрической прогрессии. Самообманом является и фраза "потом исправим". Как сказал Randy Shoup, если у вас нет времени сделать это правильно, то с чего вы взяли, что у вас будет время сделать это дважды? Тем более, что потом скорость разработки будет ниже, а напряжение - выше. Количество введенных символов слабо коррелирует со скоростью разработки. Например, ребята, увлекающиеся спортивным прохождением кат по программированию, заметили, что используя TDD они пишут в разы больше объем кода, но проходят каты процентов на 10% быстрее, чем без ТДД. Все просто - используя TDD, появляется слабосвязанный код (иначе его сложно было бы протестировать), который легче читать и понимать. Но я сейчас не об этом. А о том, что для того, чтоб писать высокоэффективный код, нужно обладать определенными знаниями. Я вспоминаю, когда я начал работать с литературой по Software Design, то мой код начал существенно преображаться. Мой старый код вызывал у меня стыд. Я взял паузу в программировании Open Source проектов и засел за книжки. Я понимал, что лучше "прочесть инструкцию к бензопиле", нежели продолжать "рубить топором" то, что потом все-равно переделывать. К тому моменту я уже начал немного разбираться в том, чем хороший код отличается от плохого. И я хотел, чтоб то же самое испытал мой товарищ, который продолжал "рубить топором" и не находил времени на прочтение "инструкции к бензопиле". Хороший код отличается простотой, и выполняет главный императив разработки - управление сложностью. Но хороший код не спасает от еще одной сложности, про которую недавно написал @BorisRomanov (начиная отсюда). На эту же тему писал Егор Толстой и даже сам E. Dijkstra: 💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." —Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896) Менеджмент не сможет оценить качество кода, если не обладает соответствующим образованием. Но менеджмент рано или поздно заметит разницу в темпах разработки между вашей командой и другими командами, и начнет доверять вам больше. Если, разумеется, у вас хватит выдержки дотянуть до этого момента. Тут главное - взобраться на горку. Труднее обстоит дело, когда вы не можете передавать знания команде личным примером, например, на позиции лида или архитектора. Для менеджмента ваши "инструкции к бензопиле" - просто отвлекание команды "от рубки леса". Возникает дилемма: спасать менеджмент от самого себя, вопреки его воле, понимая, что он никогда это не оценит, или же проявить внешний конформизм, осознавая, что 💬 "Те компании, которые не осознают, что знания являются средством производства более важным, чем земля, труд или капитал, постепенно умрут и никогда не поймут, что их погубило." —Ларри Прусак Хотелось порассуждать дальше, но закончилось место. Ладно, потом...

Антоха, я посмотрел что ты сказал, огромная просьба, послушай что я реально сказал на стриме. Ты зачем-то добавляешь смысл которого не было. Тебе правильно сказал Артем, что ты додумываешь то чего нет. Это очень сильно нивелирует твои остальные слова, тебе почему-то кажется, что я борюсь с волками и это объясняет почему последнее время ты так агрессивно реагируешь на меня. https://youtu.be/407IiK-UUFk?si=_xxkgeS0vVq0PRiL&t=4524

Наконец-то будет во что проиграть — заанонсили постсоветский симулятор сельского водителя «Заря». Вы будете играть за водителя Василия, который на своём старом УАЗике рассекает бездорожье, чтобы доставить посылки своим односельчанам. Одна из фишек игры: можно будет жарить шашлык с мужиками в гараже. Ссылочка тут. 🕒 1337

Типизация рулит! Кто бы что не говорил, а типы - это один из самых эффективных инструментов управления программой. Поэтому рекомендую максимально использовать типизацию в своих проектах. Неплохой доклад о том как типы использовать для Redux Toolkit есть у Михаила Непомнящего.

Вот что происходит, когда ChatGPT пишет вам отклик 😁 ОтветственнЫЙ и исполнительнЫЙ дэвушка по имени Анна, кажется, не смоГ определиться со своим полом 😄 Да еще и формат сопроводительного написаЛ такой, что только робот читать согласится 😄 А потом еще у меня люди спрашивают "Таня, а почему мне постоянно отказы приходят? Почему мои отклики игнорируют?" Блять, ну не знаю, Анна. Возможно потому, что ты настолько ответственнЫЙ дэвушка, что не читаешь свой сгенерированный текст перед отправкой 🙈 #Таня_бомбит

Сегодня в клубе Марго подняла отличную тему про индексы в базе данных, обменялись полезной информацией. Спешу поделиться ссылкой на ламповое выступление с вами - https://youtu.be/ju9F8OvnL4E?si=vEekMN8pnMvX7U7N

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

Взгляд на Архитектуру с позиции кода. Мне не всегда понятно почему люди уделяют такое большое внимание нюансам построения архитектуры на уровне кода, в большинстве случаев это выглядит как "неправильно ты дядя Федор бутерброд ешь". Вот, например, статья про Заблуждения Clean Architecture вроде и по делу, но на практике никак не будет влиять на код небольшого приложения, а в большом такие мелочи, как описаны в статье, нельзя учесть. Архитектурный стиль (а чистая архитектура скорее стиль, чем шаблон) просто дает вам удобные референсы как стоит делать, но без супер деталей "а что же на самом деле имелось в виду", это уже природа человека такая - бесконечно уточнять. Поэтому не пугайтесь если вы вдруг поняли, что по чьиму-то мнению вы неправильно поняли "Чистую архитектуру", в этом прелесть архитектуры - это набор рекомендаций, а не законов )

Стоило сказать, что кворума нет, и за ночь проголосовало аж тысяча человек. Я готов пойти на встречу своему сообществу. По опыту предыдущих голосований мои условия следующие: Время: суббота 10:00 по Мск Место: одна из площадок - ExtreamCode, Владилен Минин, Рома Сакутин Организатор (он же модератор): не я, любой кто хочет организовать свяжитесь со всеми сторонами. Решение всех вопросов от вас, от меня явка по ссылке на сам стрим Тема: сравнение сообщества соеров и волков Формат: презентация своего сообщества по набору вопросов (список вопросов уточнятся в рамках подготовки дебатов), затем сами дебаты в регламенте 2-3 минуты на ответ, с четким мьютом по истечению времени (отвечает за это модератор) Примерные вопросы, которые я хочу затронуть: 1. Ценности и цели сообщества 2. Стратегия и тактика достижения целей 3. Отношения бизнесом и проблемы бизнеса 4. Цели и проблемы участников, которые решаются 5. Токсичность, хейт, нечестная конкуренция (давление сообществ друг на друга) 6. Претензии волков к моему сообществу и обратно 7. Попытка найти обоюдный компромисс Если кто-то хочет вписаться в организацию, дайте знать.

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

Многие принебрижительно относятся к MySQL, но не я. Мне понравилась статья от GitHUB о построении кластера под высокую нагрузку на базе MySql, как говорится важен не размер, а умение.

Небольшое изменение на завтра, у меня будет гость на стриме, который расскажет историю о том как он решил бросить ММА и начать заниматься АйТи. Поэтому секции ЗЭН не будет.