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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

Пример позитивного 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

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

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

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

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

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

Про ВУЗ

Когда речь заходит про успешный успех тех кто бросил ВУЗ и создал что-то нереально крутое, частенько используется подлог, когда "создание компании" приравнивают к созданию "продукта". Типа "Билл Гейтс создал Windows", а Стив Джобс "Создал айфон". На самом деле и тот, и другой "наняли людей", которые "создали".

Фактически люди без ВУЗа, могут создавать что-то только если у них есть сотрудники, которые имеют ВУЗ за плечами, причем сотрудники должны быть не последними студентами, так как лодырь и в ВУЗе лодырь.

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

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

Почему джунам так тяжело устроиться на работу? Откуда такие дикие требования? Что вообще происходит?
Обо всем этом в пятничном разговоре на S0ER TALKS
Смотрим на: VK | YouTube

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

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

https://youtube.com/live/lwh0LT3DN00?feature=share

Хакеры и все остальные

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

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

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

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

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

Возникает вопросы, кто из них нужнее, кто из них прав? Ответ прост - у каждой группы свой "пузырь" в котором они себя чувствуют комфортно.

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

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

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

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

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

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

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

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

Всем бобра...

Интересная статья об искусственном интеллекте от Ивана Оселедец. Отметил для себя одну мысль, которая раньше в голову не приходила - энергоэффективность.

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

Так и представил реальность ближайших лет - "Наймите челочека на работу и сэкономьте на счетах за электричество".

#статья #ссылка #мысли

https://engineer.yadro.com/article/artificial-intelligence-into-natural/