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

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

#мысли

Статус коды HTTP

В группе Naris подробно обсудили как нужно использовать статус коды в HTTP запросах. Хочу поделиться одним наблюдением.

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

Получается, что раз есть бизнес-логика, то у нас может быть такая ситуация, что ошибки БЛ не дают сформировать конечный результат, который был запрошен по HTTP, и возникает вопрос: "Ошибки бизнес-логики должны оформляться с использованием http кодов?".

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

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

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

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

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

#rfc

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

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

Про пассионариев в АйТИ

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

Я прикинул, кто у нас в блогосфере яркий пассионарий? И кроме Егора Бугаенко и Тимура Шемсединова никто не приходит на ум. Им почему-то норм и свои идеи двигать, и исследовать, и делиться знаниями.

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

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

#мысли

Про 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 больше, так как в одном STD может быть несколько RFC)

#rfc #кухаркеназаметку

Очень удивился цифре 50% выходимости курса. Это почти в два раза выше среднего показателя.
Послушал интервью, чтобы понять в чем проблема обучения программированию вместе с мальчиками. Пытаюсь в Naris сделать максимально комфортные условия для всех вне зависимости от пола.

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

https://youtu.be/jo59HLEk-8Y

Посмотрев интервью, понял, что надо срочно поднимать цены на стримы и делать участие в Naris платным, а то как девочка веду себя. Все! 20 млн чистой прибыли и ни центом меньше!!!

Девочки программисты, когда дошли до технической части повели себя чисто как инфоцыгане "не ну это все устаревшие технологии, ассемблер - фи, фортран - фи". На этом техническая часть интервью закончилась. Ну вы серьёзно? Блин, мы на последней встрече подписчиков три часа про технологии трепались, а вы на интервью с экспертом-программистом смогли только про то, что ассемблер фи?

Я вообще не понимаю зачем этот ваш ассемблер, javascript, python. Ведь верстать на html можно...

Посмотрел программу начальных классов, ни че не меняется. Наука сделала такой шаг вперёд, а у них до сих пор учат "жи ши пиши си", ну за столько-то лет могли сделать что-то новое, ну там "жи ши пиши с++".
Или вот три закона Ньютона, какой Ньютон? Это же старье. Вот поставьте клоуна, если вам в жизни пригодился хоть один из законов Ньютона.
А вот эти сортировки пузырьком. Зачем все это старье? Двоичная система... Старье....
В общем если согласны, что это старье надо в топку, то ставьте клоуна. Хватит мучить детей и заставлять их учить никому ненужные правила и законы!!!

У меня первая сотня подписчиков на Рутубе. Круто! Спасибо!

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

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

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

#мысли #графомания

Коллеги ищут на работу Frontend разработчика, основной стек React (Redux, Saga, SCSS, TS) вёрстка по макетам в фигме.

Рассмотрят от добротного джуна до Middle+

ЗП средняя по рынку, примерно от 60к для джуна и от 120к для мидла (обсуждаемо).

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

Контакты:
https://t.iss.one/Deneden
[email protected]

Вчера был стрим про RFC, рассказал про некоторые особенности формирования стандартов. Запись стрим здесь - https://rutube.ru/video/c6c880a3572531d9fc21e216632c07c9/

Наиболее распространенным подходом для версионирования является SemVer (семантическое версионирование). Реже встречается подход, который называется CalVer (версионирование на базе дат). Многие считают CalVer более удобным и понятным вариантом, потому что такая версия показывает не только версию как таковую, но и то когда продукт появился.

Такой вариант версионирования, например, использует Ubuntu, думаю обращали внимание, что у них версии выглядят как-то так - 22.04.1 LTS

Но, например, в мире REST API редко встретишь такой вариант версионирования. Так как часто версию API кодируют в урле (v1, v2 и т.д.) и даты выглядят не очень уместно, так как могут запутать. Если хочется использовать CalVer в построении REST API, то лучше спрятать его в заголовок, например "Accept: application/json;v23.01".

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