S0ER

Сегодня в стриме: - В рубрике "Зачем это надо?" поговорим про архитектурные границы - В рубрике "Годное чтиво на неделю" поговорим про книгу "Программируй & типизируй" - В рубрике "Сплетни" обсудим что писали ЛОМы на этой неделе - В рубрике "Донаты решают" отвечу на вопросы донатеров. Ну и в целом поболтаем про АйТи https://youtube.com/live/JY-DOXRWI_o?feature=share

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

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

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

Пример "позитивного" is-a правила:

Программирование в значительной степени эмпирическая штука, теория строится не на базе строго доказанных теорем, а на основе обобщения личного опыта. Поэтому трудно винить программистов в том, что они придумывают и придумывают новые правила. Ради справедливости стоит сказать, что некоторые правила оказываются весьма удачными, потому что просты и понятны. Примеры хороших правил - "is-a" и "has-a". IS-A гласит, что наследование уместно использовать там, где можно вместо слова "наследование" подставить "is-a" (является). Если мы хотим понять, может ли стул наследоваться от стола, то фраза "стул является столом" подсказывает, что нет, не можем. HAS-A гласит, что композицию уместно использовать там, где слово "композиция" может быть заменена на "has-a" (имеет). Например, "Стол это композиция столешницы и ножек" может быть заменен на "Стол имеет столешницу и ножки", правило выполняется, а следовательно композиция в данном случае применима. #программирование #правила

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

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

Очень редко попадаются книги, которые хочется прочитать. Книга "Программируй & типизируй" как раз из них. Нравится тем, что здесь всего понемногу - немного про паттерны, немного про типы, немного про ООП, немного про ФП. Но этим книга и хороша - это книга-обзор с базовыми понятиями и поясняющими примерами. Хорошая отправная точка, чтобы узнать про изоморфизм Карри-Говарда, типобезопасность, структурную и номинальную типизацию, алгебраические типы и т.д. #книга #отзыв #книганавечер

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

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

Правильно называть - это главное, или казусы именования в IT Если разобраться, то за историю развития АйТи каких только забавных ситуаций не возникало. Например, IBM в 1984 придумала сокращение AT, что означало Advanced Technology, что на русский переводится как "передовая технология", по сути это был новый форм фактор, пришедший на смену XT и PC. Ирония в том, что "передовая технология" так глубоко врезалась в названия различных стандартов, что осталась на долгие годы (например в сокращении SATA), но при этом давно перестала быть "передовой". Другой пример - "материнская плата", которую под влияние политических метаморфоз в США стали называть "Родительской платой", но в России это название не прижилось от слова "совсем", правда прижилось название "системная плата", которое является идеальным компромиссом. Пример более близкий к программистам - "master ветки", которые опять же под влиянием политкорректности не принято больше называть "master", и теперь они стали где "main", где "latest" ну и другие варианты. Вывод всех этих историй простой - чем более массовым становится явление, тем сильнее массы на него влияют. Верните мои любимые года, когда айти было только для гиков и хакеров!

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

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

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

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

Вдумчивое чтение не главное, конечно, как котлетки не главное в блюде высшей мишленовской кулинарии «котлетки с пюрешкой»! Но и без котлеток будет не то:) Я не проходил никаких курсов скорочтения и не очень понимаю всю эту тему. Можно Войну и Мир прочесть за 20 минут и потом на вопрос о чем книга ответить — ну, там что-то про Россию. Смысл? Художка читается для удовольствия, развития жизненного опыта через перенятие опыта автора, развитие языка и эрудированности. Но ключевое все же для удовольствия, потому что если его нет, то и читать не будешь. Пробегать абзацы по диагонали в погоне за page per second как-то не коррелирует с удовольствием. Это как прийти в кинотеатр и весь фильм ёрзать и орать ну давайте уже дальше, поставьте 2х! Проф литература читается уже для получения профита, для явного применения на практике, для улучшения своей работы и жизни. Но, кажется, что каждый и сам в состоянии быстрее пробегать глазами то, что уже ему знакомо, или то, что ему из этой книги не нужно. Никакого скорочтения для этого не требуется изучать. А вот то, что нужно, надо читать вдумчиво=осмысленно, с напряжением головушки, имея это в первом приоритете, а не page per second. Это никак не отменяет всех остальных важных сторон, например, применения прочитанного на практике, повторения и тп. Я с некоторых пор делаю по каждой книге небольшое резюме — то, что новое и хочется применять. Это: а) даёт возможность самому сформулировать для себя своим языком конкретные самые важные для тебя пункты книги; б) это помогает их ещё раз осмыслить и понять — не получится честно сформулировать своими словами то, что не понял; в) к такому краткому резюме всегда можно вернуться и освежить в памяти всё самое важное для тебя по толстой книге за несколько минут. Похожее на цеттелькастен, но я не фанат методики и не следую ей, просто выписываю в одно место, в одну заметку резюме, обязательно своими словами. Подробнее можно почитать в книге Зонке Аренса «Как делать полезные заметки». И периодически к этому возвращаешься и убеждаешься в том, что применяешь это на практике. https://t.me/softwareengineervlog/1502

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

Для себя давно понял - важно не то что вы знаете, важно то что вы реально используете из своих знаний. Именно использование формирует привычки и "укладывает" знания по полочкам. Что толку, например, что каждый второй знает расшифровку SOLID, может рассказать как "правильно" его использовать, а на практике не использует эти знания? Все что невостребованно быстро забывается, перед собесом, конечно, помогает освежить знания, чтобы успешно ответить на типовые вопросы, типовыми ответами. Но потом большая часть программистов как "чистый лист". Так что закрепляйте все на практике, пока не получите устойчивые привычки. Искренне ваш, Кэп.