S0ER

Про RFC Стандарты в RFC - не совсем стандарты, вот несколько фактов о RFC, которые надо знать: - RFC означает Request for Comments (рабочее предложение) - RFC может содержать как описание стандартов, так и лучшие практики, просто информацию или что-то еще - стандарты размещаются в Standards Track - в самом начале стандарты являются просто предложениями "Proposed Standard" - если стандарт становится достаточно зрелым (т.е. широко применяется на практике и не вызывает проблем), его помечают как "Internet Standard" - с момента как стандарт получает статус Internet Standard ему также присваивается номер STDXX, который содержит набор RFC, относящихся к этому стандарту. Из интересного: у RFC есть стадия обсуждения, в рамках которой в документ могут быть внесены изменения, затем наступает стадия AUTH48 когда автору RFC дается 48 часов (на самом деле около недели) на то, чтобы он окончательно сформировал и осмыслил документ. После этого документ либо публикуется, либо автор может отказаться от его публикации. После публикации документ получает номер RFC и уже не может быть изменен (к нему могут быть только добавлены сообщения об ошибках - Erratas). Но если ошибок слишком много, то можно выпустить еще один RFC. Настоящих STD стандартов всего 99 (при этом RFC cjj

Про пассионариев в АйТИ Мне кажется, что где-то в конце 90-х, начале 00-х в отечественном айти произошел какой-то перелом, и те пассионарии, которые у нас были, куда-то сплыли. На место им пришли субпассионарии, которые питаются исключительно за счет западного айти. Обычно, субпассионарии активничают только в одном направлении - переводе книг, статей, лекций и т.д. В их понимании у нас ничего своего нет, и быть не может. В итоге своих наработок почти нет (на самом деле, конечно, есть, но очень мало), даже мнение не свое, а заимствованное. Я не пытаюсь сказать, что это плохо или хорошо, но это факт. У нас всё айти - это переводы и адаптации. Последнее, что я помню из реально успешного и своего - Nginx и Paralles. А ведь до этого были и свои утилиты, и свои инструменты, и редакторы. Куда делись люди, которые в 90-е активно творили и исследовали? Я прикинул, кто у нас в блогосфере яркий пассионарий? И кроме Егора Бугаенко и Тимура Шемсединова никто не приходит на ум. Им почему-то норм и свои идеи двигать, и исследовать, и делиться знаниями. Я бы хотел верить, что в наше айти снова вернуться пассионарии, которые будут иметь свое мнение, основанное на своих мыслях и исследованиях. По крайней мере лично мне не интересно тупо копировать и адаптировать западный опыт, мне кажется нужно добавлять что-то и от себя. Иначе совсем грустно становится за нас. Проблема субпассионариев в том, что не имея своей энергии они активно тянут назад всех остальных, это называется "менталитет краба". На мой взгляд не так страшно велосипедить, создавая что-то интересное лично тебе, чем вообще ничего не делать и только хейтить других.

Мы заменили Соера 🙌 Чтобы точнее попасть добавьте в запрос: please act as a grumpy old fart who pretends to be smart and puts himself above other people. https://www.linkedin.com/posts/ariellevin_50-awesome-chat-gpt-prompts-activity-7015603466127466496-IBqA

Похоже Дима мне так и не простил стрим с Назаровым...

Первый и второй закон архитектуры звучат так: 1. Everything in software architecture is a trade-off. 2. Why is more important than how. а третий, от меня: 3. если сильно хочется, то можно и без архитектуры

Мне скинули один интересную ссылку на RFC7807 где предлагается стандартизировать информацию, возвращаемую через коды HTTP. Как вариант выглядит интересно, но на практике я бы не стал использовать для БЛ из соображений безопасности (см. п.5 документа).

Статус коды HTTP В группе Naris подробно обсудили как нужно использовать статус коды в HTTP запросах. Хочу поделиться одним наблюдением. В отношении HTTP статусов нужно понять главное - это технические ошибки, которые являются следствием того, что запрошенный ресурс не может быть получен. А ресурсом является набор бизнес-данных, которые вам нужны. Понятно, что если вы получаете какую-то страницу в сети, то она либо получена (200) либо произошла ошибка и тогда нужный статус подскажет какая. Но сейчас очень много рестовых API, которые не только получают данные, но и реализуют бизнес-логику приложения прежде чем отдать данные. Получается, что раз есть бизнес-логика, то у нас может быть такая ситуация, что ошибки БЛ не дают сформировать конечный результат, который был запрошен по HTTP и возникает вопрос: "Ошибки бизнес-логики должны оформляться с использованием http кодов?". Разные команды отвечают на этот вопрос по-разному, я считаю, что нет. Ошибки БЛ это как правило вещи, которые можно сформулировать на бизнес-языке и эти ошибки имеют смысл для пользователя. Поэтому данные об ошибках в логике - это тоже данные. Они должны отдаваться через 20х статус. А вот если речь идет о технических ошибках, когда мы неправильно указали, например, имя поля или использовали не ту кодировку, не имеют отношения к бизнесу, более того они делают невозможным вернуть запрошенный ресурс пользователю, а значит должны отдаваться 4хх статусами. Приведу пример, https://yookassa.ru/developers/using-api/response-handling/http-codes - ЮКасса вовзвращает 200й код даже если произошла ошибка оплаты (статус - canceled), потому что это уровень БЛ. Но в случае "технических" проблем возвращает статусы 4хх и 500, что логично, так как ошибки не относящиеся к БЛ делают невозможным вернуть запрошенный "ресурс".

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

Как водится по субботам был стрим, по нашей традиции, если за время стрима на ютубе не набирается 200 лайков, то стрим отправляется на RuTube в записи - https://rutube.ru/video/572527ecf674c65d8aba36fcd72b578c/

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

Кстати, я до сих пор веду Now. Похоже там остались только я и tk_knopka

Не репрезентативная выборка, конечно, так как 173 ответа - это не о чем. Но результат, безусловно, интересный. Источник: https://proglib.io/p/kak-izmenilas-zhizn-russkoyazychnyh-aytishnikov-za-poslednie-polgoda-rezultaty-oprosa-biblioteki-programmista-2022-09-08

The entity trap В архитектуре так называется анти-паттерн, когда архитектор уходит от бизнес-абстракций, и начинает фокусироваться на бизнес-данных. В итоге получается, что структура и сущности БД напрямую влияют на дизайн компонентов и отражают обычное CRUD взаимодействие. Если задача сводится к простому CRUD, то смысла что-то "проектировать" нет, можно взять подходящий фреймворк и работать в рамках его возможностей. Проектировать имеет смысл тогда, когда есть бизнес-логика, абстракции уровня бизнес-логики и другие признаки "сложности" задачи. #мысли #анти-паттерн

С помощью тега #itubeteam на рутубе нашел канал Виктора Левина. Хочу поддержать автора лайком и рекомендацией. Мне понравился видос по графане, весьма толково и по делу https://rutube.ru/video/5361cffbbeac6ca83ee07ff54037df00/

Как выглядит архитектура 2.0? Чем больше я обдумываю различия в архитектурных подходах к построению программного обеспечения, тем больше мне нравится разделение архитектуры на этапы развития. Например, есть хороший доклад от Олега Сметанина - https://www.youtube.com/watch?v=tF3iNp5YFYk про организацию микросервисов. Этот доклад охватывает типовые кейсы построения микросервисной архитектуры. Попытаться делать эту архитектуру как-то иначе невозможно, воткнуть туда что-то из старых подходов тоже нереально. Это самостоятельный кусок теории, именно так выглядит архитектура 2.0 в моем понимании.

А накануне обсуждения книжки замечательная 12-летняя дискуссия о том, означают ли термины architectural pattern и architectural styles одно и тоже или речь о разных вещах: https://stackoverflow.com/questions/3958316/whats-the-difference-between-architectural-patterns-and-architectural-styles

Три поколения развития архитектуры Развитие технологий и общества привели к возникновеню понятий "Веб 2.0" и "Веб 3.0" - идея в том, чтобы выделить новые подходы в построении программного обеспечения и выразить новые задачи, которые стоят перед обществом. Ровно таким же образом можно разделить архитектурные подходы на три волны: Архитектура 1.0: - рассмотрение модульности/монолитности; - масштабирование за счет вертикального роста; - исследование и декомпозиция программных систем; - балансировка нагрузки; - инфраструктура как ПО; - расширение за счет дублирования; - ACID. Архитектура 2.0: - горизонтальная масштабируемость; - процессный или сервисный подходы; - микромодульность; - инфраструктура как код (облака); - расширение за счет распределенных транзакций; - BASE. Архитектура 3.0: - децентрализация; - семантический веб; - блокчейн (web3); - токенизация. Архитектурные решения первой волны во многом заложены в код. Например, принципы построения программного обеспечения SOLID или GRASP, принципы границ на уровне кода (чистая архитектура и тому подобное), создание пакетов и модулей и т.д. Так как сейчас серьезно взялись за генерацию кода методами ИИ, то архитектура 1.0 уже заложена в эту генерацию. Предложенное разделение весьм условно, но без этого попытки разговаривать про архитектуру современного ПО превращается в кашу (я это остро чувствую в своих архитектурных видео), потому что делать софт в облаке и делать небольшой монолит с трехслойной архитектурой - это сильно разные вещи, и объединять их вместе не получается. Предложенное разделение помогает внести ясность в обсуждение, ровно таким же образом, как разделение веба на версии. Так же интересно, что есть два термина, которые могут запутать Web3 и Web3.0 в первом случае речь про новый децентрализованный интеренет и блокчейн технологии, второй про семантический веб.