Сегодня мы установили сразу три рекорда на стриме:
- Собрали самый большой донат - 8105 рублей
- Самое большое число лайков - 261
- Самое большое число зрителей - в пике 235

Спасибо всем огромное!

Хочу пропиарить стрим коллеги по цеху - https://youtube.com/live/QMjtoph-oZ4?feature=share

Безопасность = продвижение + сохранение

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

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

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

#мысли #программирование

Правильно называть - это главное, или казусы именования в IT

Если разобраться, то за историю развития АйТи каких только забавных ситуаций не возникало. Например, IBM в 1984 придумала сокращение AT, что означало Advanced Technology, что на русский переводится как "передовая технология", по сути это был новый форм фактор, пришедший на смену XT и PC. Ирония в том, что "передовая технология" так глубоко врезалась в названия различных стандартов, что осталась на долгие годы (например в сокращении SATA), но при этом давно перестала быть "передовой".

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

Пример более близкий к программистам - "master ветки", которые опять же под влиянием политкорректности не принято больше называть "master", и теперь они стали где "main", где "latest" ну и другие варианты.

Вывод всех этих историй простой - чем более массовым становится явление, тем сильнее массы на него влияют. Верните мои любимые года, когда айти было только для гиков и хакеров!

Логическое время исполнения

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

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

- пакетную;
- интерактивную;
- реальное время.

Большая часть клиент-серверный (или веб) систем работает в пакетной среде, и установить реальное время в таком взаимодействии невозможно (элементарно проблема согласования "реальных" часов, когда по факту событие, произошедшее в реальном мире, будет иметь разную метку времени на разных устройствах системы). Поэтому вместо "реального времени" применяется понятие "логического времени", которое позволяет установить последовательность обработки данных, но не отражает сколько реального (физического) времени будет на обработку затрачено.

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

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

#мысли #архитектура

Реальное время

Под реальным временем обычно понимают такой режим работы, когда время обработки данных выполняется за некоторое малое время t. Причем t подбирается таким образом, чтобы пользователю казалось, что обработка происходит непрерывно и без швов.
Например, проигрывание видео или другие мультимедийные задачи - это пример работы "реального времени". Если у нас видео должно воспроизводится со скоростью 25 кадров в секунду, то время t = 1/25 сек. Если кадр не успевает отобразится за данное время, то реальное время нарушается.

Есть два варианта реального времени:

Жесткое - в котором не допускается нарушение времени на обработку данных.
Мягкое - где допускается что приложение может не уложится в отведенное время.

Если речь про видео, то как правило приложения работают в режиме "мягкого" реального времени, если что-то пошло не так, то допускается дропнуть кадр или обработать отклонение от заданного времени как-то иначе.

Мягкое время планируется исходя из принципа "избыточности" ресурсов и оптимизации расчетов, в случае их недостатка. Жесткое время проектируется только в условиях гарантированного предоставления необходимых ресурсов (квотирование).

#архитектура

Очень редко попадаются книги, которые хочется прочитать. Книга "Программируй & типизируй" как раз из них.

Нравится тем, что здесь всего понемногу - немного про паттерны, немного про типы, немного про ООП, немного про ФП. Но этим книга и хороша - это книга-обзор с базовыми понятиями и поясняющими примерами.

Хорошая отправная точка, чтобы узнать про изоморфизм Карри-Говарда, типобезопасность, структурную и номинальную типизацию, алгебраические типы и т.д.



#книга #отзыв #книганавечер

Пока Иван (канал в Офисе) негодует насколько безграмотна (в техническом плане) нынче молодежь, я у него в комментариях нашел годную ссылку по UDP и TCP, годное чтиво на утро https://habr.com/ru/company/oleg-bunin/blog/461829/

#ссылка #годнота

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

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

Ради справедливости стоит сказать, что некоторые правила оказываются весьма удачными, потому что просты и понятны. Примеры хороших правил - "is-a" и "has-a".

IS-A
гласит, что наследование уместно использовать там, где можно вместо слова "наследование" подставить "is-a" (является). Если мы хотим понять, может ли стул наследоваться от стола, то фраза "стул является столом" подсказывает, что нет, не можем.

HAS-A
гласит, что композицию уместно использовать там, где слово "композиция" может быть заменена на "has-a" (имеет). Например, "Стол это композиция столешницы и ножек" может быть заменен на "Стол имеет столешницу и ножки", правило выполняется, а следовательно композиция в данном случае применима.

#программирование #правила

Пример позитивного is-a правила при наследовании:
- "Собака" наследуется от "животного" - собака "является" животным - true
- "Клавиатура" наследуется от "устройства" - клавиатура "является" устройством - true
- "Событие" наследуется от сообщения - "событие" является "сообщением" - true (а может и false, тут уже от контекста).

Легко увидеть что наследование удачно работает "от общего к частному". Это, кстати, хорошо сочетается с принципом Лисков:
- предусловия не могут быть усилены в подклассе
- постусловия не могут быть ослаблены в подклассе

#программирование #правила #лисков

Угадай по картинке о каком ютубере идет речь? И это не SSV! )

Одна из моих самых любимых книг по ООП это книга Мейера - ОО конструирование программных систем, круче этой книги я никогда ничего не встречал по ООП. #книга #годнота

Сегодня в стриме:
- В рубрике "Зачем это надо?" поговорим про архитектурные границы
- В рубрике "Годное чтиво на неделю" поговорим про книгу "Программируй & типизируй"
- В рубрике "Сплетни" обсудим что писали ЛОМы на этой неделе
- В рубрике "Донаты решают" отвечу на вопросы донатеров.

Ну и в целом поболтаем про АйТи

Запись можно посмотреть тут:

https://rutube.ru/video/61f2e3674c2d84f09d81a202899ceceb/

https://vk.com/video/@soerdevs?z=video-148822001_456269759%2Fclub148822001%2Fpl_-148822001_-2

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

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

Если бы я рекламировал курсы на своем канале, то только на этой рекламе мог бы зарабатывать около 150-200 тыс. рублей в месяц. Курсоделы готовы платить за рекламу больше чем другие, имеют низкие требования к конечной интеграции и в целом это были бы легкие деньги.

С учетом, что стабильно в месяц приходит от 3 до 7 предложений о рекламе курсов, можно представить сколько денег проходит мимо меня.

Теперь осталось вспомнить ту важную и принципиальную причину по которой я отказался от рекламы курсов... Есть идеи?

Коротко о разном

Курсы - это не плохо и не хорошо, это специфический продукт, у которого есть свои потребители.

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

Контент на канале
Не знаю пока что снимать. Лента забита видосами про софт скилы и chatgpt, не хочу вливаться в этот тренд. Делать скучные технические ролики тоже не хочу. Думаю о том, что я хочу...

ChatGpt
Уже не интересно.

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

Водянистых книг я видел прилично, но эта превзошла многие из них. Обычно я ставлю закладки на технических моментах, которые мне кажутся важными.
Как видите в этой книге я поставил только 4 закладки. Остальное это "вода", рассказывающая, как организовать процессы рефакторинга вашей компании.
Авторы книг тоже ударились в софт скилы.

Ретроспектива и регрессия

Короткое правило успешного проекта "Регулярно делаем ретроспективу и не допускаем регрессий".

Ретроспектива - это процесс поиска недостатков в текущей кодовой базе и обдумывания способов улучшения сложившейся ситуации.

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

Негатив в отношении данной практики в основном есть в командах со слабой технической базой, потому что любые изменения кодовой базы, сделанные из самых лучших побуждений, приводят к регрессиям. Чтобы этого избежать повсеместно используется правило "работает, не трогай!".

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

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


#понятия #база

YouTube VK RuTube

Как применять чужой опыт

Вообще, спрашивать у профи как он бы поступил в твоей ситуации - это гиблое дело. В паре предложений вряд ли можно объяснить свою ситуацию, да еще так, чтобы специалист быстро нашел в своем багаже знаний релевантный опыт. В такой ситуации лучше спрашивать Яндекс, и искать людей, которые сталкивались с максимально похожими ситуациями. Хотя если повезет, то шанс на хороший совет есть. Если реально человек недавно сталкивался с чем-то похожим, ну либо речь о какой-то супер типовой штуке.

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

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

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