https://www.youtube.com/watch?v=kdfTuE9XHas

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

Тяжелее всего общаться по архитектурно-софтварным вопросам с бывшим технарём. Человек много лет назад писал код, потом перестал, плотно ушёл в менеджмент, но гештальт не закрыл и в эту щель при первой же возможности выдавливается всякое. Самое типичное — уход в детали реализации на самом раннем и поверхностном этапе обсуждения даже не архитектуры, а лишь примерных потребностей. (Напомню стандартную иерархию: потребности → требования → архитектура). Ну то есть мы даже не особо представляем, чего хотят стейкхолдеры, а человек уже начинает схему базы данных рисовать и обсуждать, контролы из какой визуальной библиотеки накидывать на страницу.

The unplanned impact of mathematics

В статье собрали несколько примеров, как вроде бы совершенно абстрактные и никому ненужные области математики внезапно нашли прикладное применение, да ещё какое.

Оказывается, гугл банит или демонетизирует видео, в которых упоминается covid или coronavirus, вот буквально этими словами. Поэтому люди, живущие за счёт ютубовского видео, вынуждены тщательно фильтровать текст и вместо covid/coronavirus использовать эвфемизмы типа “the current situation”. Слово, Которое Нельзя Называть.

«…Термин MITM вызвал недовольство из-за гендерной привязки, вместо него было предложено использовать слово PITM (people-in-the-middle).»

Какой же ад творится…

Статистика в прикладном применении — очень тонкая и неоднозначная штука. Вот классический пример: По статистике, люди, не употребляющие алкоголь в принципе, находятся в группе риска по заболеваниям печени.

А всё очень просто: среди вообще не употребляющих алкоголь людей много тех, кому это делать нельзя по медицинским причинам, а также «завязавшие» алкоголики.

Так что к любым статистическим исследованиям нужно относиться очень осторожно и аккуратно.

Туда же вдогонку пример: Статистически, любители яхтенного спорта и гольфа живут дольше и лучше, чем остальные.

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

Проблема и одновременно преимущество UML — для его использования и понимания нужно кристально ясное понимание. UML по сути — это небольшое щупальце, которое пролезло из чистой академической среды в прикладную область программирования. Но так как изначально это очень сложная для понимания система понятий и связей между ними, в айти UML не смог прижиться глобально. Да, куча людей весьма ограниченно используют какие-то из диаграмм, чаще всего это class и sequence diagrams. Но этим всё и ограничивается, хотя возможностей по описанию строения системы и её поведения в UML гораздо больше, но они уж очень сложные и непонятные.

А ещё по UML очень мало толковых книг, в бо́льшей части которых делается упор на объектно-ориентированность языков программирования, отчего создаётся ложное ощущение, что это всё про OOP only. Но нет, широта охвата гораздо больше: жизненный цикл разработки (реализация, внедрение и т.п.), понятия и связи между элементами предметной области. И UML может использоваться не только архитекторами и кодерами, но вообще всеми участниками процесса разработки, для каждого найдётся свой уровень диаграмм.

UML — нечёткий, сложный и запутанный язык описаний. Не существует эталонного способа его применения и в нём в принципе считается нормальным, если вы некоторые его концепты используете с собственной семантикой, если такой подход решает ваши проблемы.

Есть две малопересекающиеся реальности (realms) в UML.

Первая — это адская пучина UML метамодели, в которой обитают полностью оторванные от реальности учёные, это царство идеальной семантики, комитетов по стандартизации и прочей мета-бюрократии. Нормальные люди должны это полностью игнорировать и никогда не читать их материалы.

Вторая — собственно прикладная область, где реально используются какие-то из концептов UML. Практически любой сложный кейс в этой области можно в пух и прах разнести с позиции «учёных» из пучины стандартов. Если вы рисуете сложную диаграмму или их набор, вы гарантированно сделаете что-то не так. Но если ваша диаграмма работает и её все в вашей команде воспринимают одинаково, то цель достигнута.

За свои годы работы в ИТ я проработал "архитектором ПО" 3-5 лет, смотря как классифицировать совмещение с другими ролями.

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

Что я наблюдаю в последние годы:
1. Очень многие архитекторы пишут что язык моделирования UML мёртв. Действительно я практически не вижу UML диаграмм в хороших примерах и во многих областях они словно исчезли полностью. Вместо этого используют всё чаще модели C4 (Context, Containers, Components and Code) сделанные в нотации "boxes and lines"
2. Есть ощущение что многое сместилось в сторону легковесного описания архитектурных решений, таких как Architecture decision record (ADR) со структурированным описанием решений в Markdown
3. Восхождение и падение микросервисной архитектуры. О ней всё ещё говорят, но мало кто может показать живой пример с обоснованием и демонстрацией. За исключением микросервисов которые являются частью облачных платформ.
4. Каждый разработчик теперь мини-архитектор. Современное ПО состоит из множества "кубиков" и, зачастую, нужно лишь написать код для их "склейки".
5. Во многих процессах разработки облачные решения/продукты/API стали неотъемлимой частью архитектуры. Cloud-as-a-code - всё более распространённая концепцияи владельцы крупных облаков всячески это продвигают.
6. Нарастающее использование low-code/no-code платформ
7. Всё больше [Word]Ops. DevOps, DataOps, GitOps и, наконец, NoOps для полностью автоматической инфраструктуры.


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

#software #it

Очередное американское техническое чудо: https://youtu.be/qFezqz2Wcdo

По сути это короткий диафильм со звуком. Удивительно, что в СССР этот девайс не своровали. Или своровали, но это было такой редкостью, что никто не видел?

Почему-то мало кто поднимает тему эксплойтов NLP и прочего ML.

Как только эти технологии начнут интенсивно использоваться, люди начнут интенсивно их обманывать. Это, конечно, хорошо, что ML-движок может на «чистых» текстах отлично отработать классификацию. А если тексты будут специально подхачены, чтобы целенаправленно обманывать AI/ML/NLP/etc? Причём для обмана будут использоваться современные технологии! И уже есть примеры, где на картинке расставляется несколько точек в определённых местах, из-за которых полностью ломается технология распознавания, но человек прекрасно видит, что именно на картинке изображено.

Это, кстати, очень старая тема, которую ещё Лем поднимал в «Стиральной трагедии» — новые технологии форсятся исключительно со «светлых» и «оптимистичных» позиций, интересы злоумышленников и эксплойтеров полностью игнорируются, а потом ВНЕЗАПНО выясняется, что всё сломали. И так повторяется раз за разом.

Общеизвестный факт — всё начальники телепаты, они умеют узнавать статус и прогресс из мыслей сотрудников, которым для этого совершенно не нужно ничего озвучивать или описывать.

Мы живём в очень динамичном и быстром времени, значения терминов меняются не только во времени, но и в пространстве. Не существует единого всеобщего словаря, где бы все слова однозначно определялись. В каждой предметной области, в каждом контексте у слова может оказаться своё значение, причём не одно. И люди обычно мыслят значениями, а не словами, поэтому для консенсуса критично важно, чтобы все участники выстроили в голове единую локальную систему понятий, чтобы в ней слово «объект», например, создавало в голове у каждого одинаковое значение. Как только значения начинают «плавать», консенсус либо распадается, либо вообще не возникает в принципе. Но это ещё не самое плохое, самое — это когда у каждого создаётся своё представление о консенсусе и они не совпадают. В итоге все считают, что договорились, а по факту — нет.

Этот скилл (согласование понятий) является чуть ли не самым главным, однако ему нигде не учат и нигде не тренируют. Некоторые люди эту «необученность» сознательно или бессознательно осознают и эксплуатируют, обычно такое называется политикой или демагогией.

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

• function
• product
• component
• object
• module

Сегодня узнал, что линзы для ИК-камер делают из германия. Этот полуметалл непрозрачный в обычном видимом спектре и прозрачный в инфракрасном.

Про упадок правды: https://www.facebook.com/natallia.andreeva/posts/3077501255679052

«Медийно-информационная ситуация, которую можно смело назвать "упадком правды" (truth decay; собственно, именно так её и называют коллеги из RAND): налицо рост числа интерпретаций фактов и данных; смешение понятий "факт" и "мнение"; предпочтение личного опыта статистике; падение доверия к официальным источникам информации»

Прекрасная история про изобретательность.

Исследователи навесили на альбатросов GPS-датчики и выпустили в океан. Альбатросы в открытом море находят рыбыловецкие суда и слетаются к ним (они чувствуют запах выловленной рыбы очень хорошо очень издалека). В итоге в центре мониторинга просто смотрят, в какой точке моря находятся кластеры из чипованных птиц и проверяют, есть ли там корабль со включенным трекером AIS. Если по данным системы в этой точке никого нет, то с большой вероятностью там браконьерское судно.

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

Одна из главных проблем openssl в том, что там семантика команд очень мутная и нечёткая. Более-менее в порядок стало приходить с появлением отдельных команд в 1.0 для управления секретными ключами (genpkey, pkey) без привязки к конкретным алгоритмам. К сожалению, все старые команды остались на месте, но они привязаны к конкретным алгоритмам (rsa, например). При этом для новых алгоритмов обязательно нужны уже новые команды, это же касается «модульных» алгоритмов типа гостовских.

Так что надо писать всё с нуля.

*Об обучение разработке*

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

Моя позиция в этом отношении достаточно простая: мы не обучаем. Вы хотите, чтобы важную операцию вам делал хирург, который пришел учиться? Или зарплату начислял бухгалтер, который многого не знает. Не можешь, не знаешь? Сходи куда-нибудь в другое место, рынок ждет.
Наша градация инженеров простая:
- джуну по каждой задаче нужен инструктаж и надзор и в плане задачи/предметной области, и технологии производства ПО;
- миддл серьезного инструктажа по самой технологии производства не требует, только в плане задачи и подбора конкретной технологии под задачу;
- сеньор способен сам принести на резолюцию решение во всех аспектах, и потом сильно не накосячить при реализации.
Все текущие джуны это исключительные ребята, которые попали в джуны не потому, что их надо учить делать работу, а потому, что их опыт не позволяет отправить их в свободное плавание.

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

Считаете ли вы, что это нечестно по отношению к людям и другим игрокам рынка? Может быть, и да, ну и что? Мы будем так делать, пока мы можем так делать.