Посмотрел программу начальных классов, ни че не меняется. Наука сделала такой шаг вперёд, а у них до сих пор учат "жи ши пиши си", ну за столько-то лет могли сделать что-то новое, ну там "жи ши пиши с++". Или вот три закона Ньютона, какой Ньютон? Это же старье. Вот поставьте клоуна, если вам в жизни пригодился хоть один из законов Ньютона. А вот эти сортировки пузырьком. Зачем все это старье? Двоичная система... Старье.... В общем если согласны, что это старье надо в топку, то ставьте клоуна. Хватит мучить детей и заставлять их учить никому ненужные правила и законы!!!
Девочки программисты, когда дошли до технической части повели себя чисто как инфоцыгане "не ну это все устаревшие технологии, ассемблер - фи, фортран - фи". На этом техническая часть интервью закончилась. Ну вы серьёзно? Блин, мы на последней встрече подписчиков три часа про технологии трепались, а вы на интервью с экспертом-программистом смогли только про то, что ассемблер фи?
Стандарты в 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)
Мне кажется, что где-то в конце 90-х, начале 00-х в отечественном айти произошел какой-то перелом, и те пассионарии, которые у нас были, куда-то сплыли. На место им пришли субпассионарии, которые питаются исключительно за счет западного айти. Обычно, субпассионарии активничают только в одном направлении - переводе книг, статей, лекций и т.д. В их понимании у нас ничего своего нет, и быть не может. В итоге своих наработок почти нет (на самом деле, конечно, есть, но очень мало), даже мнение не свое, а заимствованное. Я не пытаюсь сказать, что это плохо или хорошо, но это факт. У нас всё айти - это переводы и адаптации. Последнее, что я помню из реально успешного и своего - Nginx и Paralles. А ведь до этого были и свои утилиты, и свои инструменты, и редакторы. Куда делись люди, которые в 90-е активно творили и исследовали?
Я прикинул, кто у нас в блогосфере яркий пассионарий? И кроме Егора Бугаенко и Тимура Шемсединова никто не приходит на ум. Им почему-то норм и свои идеи двигать, и исследовать, и делиться знаниями.
Я бы хотел верить, что в наше айти снова вернуться пассионарии, которые будут иметь свое мнение, основанное на своих мыслях и исследованиях. По крайней мере лично мне не интересно тупо копировать и адаптировать западный опыт, мне кажется нужно добавлять что-то и от себя. Иначе совсем грустно становится за нас.
Проблема субпассионариев в том, что не имея своей энергии они активно тянут назад всех остальных, это называется "менталитет краба". На мой взгляд не так страшно велосипедить, создавая что-то интересное лично тебе, чем вообще ничего не делать и только хейтить других.
Первый и второй закон архитектуры звучат так: 1. Everything in software architecture is a trade-off. 2. Why is more important than how. а третий, от меня: 3. если сильно хочется, то можно и без архитектуры
Мне скинули одну интересную ссылку на RFC7807 где предлагается стандартизировать информацию об ошибке, возвращаемую через коды HTTP. Как вариант выглядит интересно, но на практике я бы не стал использовать для БЛ из соображений безопасности (см. п.5 документа).
Смотрю как разгоняют хайп вокруг ChatGPT, и думаю о том, что через полгода-год программисты проснуться и такие "опа, а в моей жизни ничего и не поменялось". Потому что прогнозы, разогретые на ожидании чуда, так сильно преувеличены, что реальность слегка расстроит. Надеюсь, вы не относитесь к тем, кто считает, что буквально завтра, всю вашу работу будет делать ИИ?
Забавно, что пять лет назад все активно отрицали саму возможность генерации кода с помощью ИИ, а сегодня все наоборот уже мысленно расстались со своей работой программиста.
Ответ на вопрос Доброго времени суток! Можете подсказать, в каком отношении между собой находятся качество, объём и сложность при разработке проекта в портфолио? Спасибо!
Ответ на вопрос Здравствуй, S0er. Работаю на backend node.js 2.5 года. Хочу сменить ЯП и начать работать на c++ или rust. На сколько вообще реально сменить язык(направление в разработке)? Как к этому относятся на интервью, да и вообще как HR смотрят резюме, тех кто хочет сменить ЯП(без опыта в нем, но при этом с опытом в другом ЯП и стэке) или же врать про опять тип был как второй не основной язык? Причина по которой хочу сменить ЯП, связана с тем, что хочется задел на будущее, уйти в более сложное направление, с высоким порогом входа, чтобы быть более "нужным" в будущем, учитывая постоянно увеличивающийся приток новых людей в ИТ и всякие nocode(ChatGPT) и ИИ.
Многие воспринимают мои архитектурные стримы как "курс по архитектуре", это не так, даже близко не так, совсем. Это как сравнивать книгу и методичку. В своих архитектурных стримах я собираю весь доступный мне опыт и знания по архитектуре, структурирую их по темам, с целью дать людям информацию, которая позволяет воспринимать задачи с архитектурной точки зрения. В дальнейшем на основе этих знаний можно решать практические задачи. Поэтому цель стримов - это формирование базы.
Курсы же ставят перед собой цель научить вас пользоваться каким-то конкретным инструментарием, в конкретных условиях. При этом одно другому не мешает, просто служит для разных целей.
В архитектуре так называется анти-паттерн, когда архитектор уходит от бизнес-абстракций, и начинает фокусироваться на бизнес-данных. В итоге получается, что структура и сущности БД напрямую влияют на дизайн компонентов и отражают обычное CRUD взаимодействие. Если задача сводится к простому CRUD, то смысла что-то "проектировать" нет, можно взять подходящий фреймворк и работать в рамках его возможностей.
Проектировать имеет смысл тогда, когда есть бизнес-логика, абстракции уровня бизнес-логики и другие признаки "сложности" задачи.
