Вообще, когда начинаешь разбираться с сутью разговоров про стандартизацию процессов, часто выясняется, что всё дело в угадывании сроков. Только в этом, в основном.
То есть, риторика такая: команда всё время даёт неправильные оценки сроков, причем всегда в меньшую сторону. Для заказной разработки это выливается в недооценку стоимости проекта, потому что они продают не результат для клиента, а стоимость разработки ПО. Для внутренней разработки — потому что попадание в озвученные сроки оценить удобнее, чем поставленную ценность — срабатывает эвристика доступности, ментальное искажение "замена атрибута".
В любом случае, задача оценки сроков мучительна для людей и почти всегда сводится к угадайке. Тут можно откалиброваться, и научиться давать более-менее похожие оценки. То есть, натренировать свою нейросеть.
Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.
LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.
Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите🤷♂️
Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.
В целом, не сильно отличается от человека, вот что.
Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.
Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:
На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335
На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1
По запросу 'RNN software effort estimation' много статей гуглится.
UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
После уточнения вводных накинул ещё 30%:
То есть, риторика такая: команда всё время даёт неправильные оценки сроков, причем всегда в меньшую сторону. Для заказной разработки это выливается в недооценку стоимости проекта, потому что они продают не результат для клиента, а стоимость разработки ПО. Для внутренней разработки — потому что попадание в озвученные сроки оценить удобнее, чем поставленную ценность — срабатывает эвристика доступности, ментальное искажение "замена атрибута".
В любом случае, задача оценки сроков мучительна для людей и почти всегда сводится к угадайке. Тут можно откалиброваться, и научиться давать более-менее похожие оценки. То есть, натренировать свою нейросеть.
Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.
LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.
Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите
Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.
В целом, не сильно отличается от человека, вот что.
Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.
Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:
На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335
На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1
По запросу 'RNN software effort estimation' много статей гуглится.
UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
Для системы средней сложности с базовым функционалом: 8-12 месяцев. При наличии готовых модулей (например, аутентификации) срок может сократиться до 6-9 месяцев.
После уточнения вводных накинул ещё 30%:
Этап Длительность Комментарий
Проектирование 5-8 недель Учёт новых интеграций (визы, календари)
Бэкенд-разработка 6-9 месяцев Особое внимание интеграциям с высокорисковыми системами
Фронтенд 4-6 месяцев Сложные интерфейсы для конструктора маршрутов и планировщика
Тестирование 10-12 недель Проверка сценариев мультивалютных операций и модерации
Общий срок: 12-16 месяцев
(увеличение на 30-40% к первоначальной оценке)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥8❤1
Очень много событий, совсем забыл написать про Analyst Marathon, а там было, что посмотреть.
Небольшой обзор, что успел посмотреть:
Андрей Бураков, "Ничего мы вам не гарантируем или как брокеры НЕ гарантируют доставку сообщений"
Ну, Андрея всегда интересно послушать, а особенно когда он потрясает основы. Например как в этот раз -- когда он шатает основы гарантированной доставки сообщений и глубоко раскапывает механизмы их реализации. Всё всегда может сломаться, сообщения могут задублироваться, но мы можем с этим работать, нужно знать, как. Если хотите разобраться с гарантиями доставки, идемпотентностью, транзакционной целостностью в брокерах -- посмотрите доклад.
Руслан Сафин "Принцип каскадного снижения связанности"
Руслан так же глубоко разбирает темы связанности и сцепленности (coupling and cohesion). И показывает на примере разбивку системы -- уменьшение связности. Кстати, впервые услышал перевод cohesion как "прочности". Кажется, это должно быть связано с робастностью, нужно подумать эту мысль. Ну и когда тепреь слышу про coupling, не могу выбросить из головы фразу Роя Филдинга: "в архитектуре системы было так много связей, что на диаграмму нужно ставить пометку 18+".
Алексей Краснов "Использование Abuse cases и Attacker stories для анализа требований по безопасности"
Очень интересная мысль в докладе -- как аналитику понять безопасность. Напишите юскейсы злоумышленника! Как настоящие, с целями и успешными результатами, только вредные для системы. Очень крутая идея, и понятная. Потом, конечно, можно ввести требования, которые рушат все вредные юскейсы и на допускают их успешного окончания. Очень практичные требования к безопасности, не какая-то абстракция.
Валерий Разномазов, "Математический аппарат для системного и бизнес-анализа". Многообещающее название, но внутри очень спорный. Я сам топлю за использование математических методов и моделей в системном анализе, по пока мало что могу предложить. Ждал инсайтов, но тут не совсем та математика, которую я ожидал. В основном здесь про теорию множеств, графы и матрицы. Кажется, это лично моя проблема, потому что множества и операции с ними, графы и матрицы у меня настолько вросли в базовую картину мира, что я их уже не воспринимаю, как что-то особенное. Это просто повседневный язык мышления. Если у вас не было этого в школе или в институте -- посмотрите доклад, это база.
Понравился доклад Елизаветы Акмановой про API -- она подробно разобрала разные варианты версионирования API и какие есть плюсы и минусы у каждого варианта. Полезно, я писал об этом тут, а в докладе -- с примерами из практики. Начинаю всё лучше понимать Филдинга с его идеей вписывать версию API в имя домена.
Ну и доклад Николая Лебедева просто огненный, с разными кейсами применения ИИ -- особенно любопытно, как сразу в процессе созвона по ключевым словам ИИ автоматически ставит таски -- это какая-то фантастика.
В общем, очень интересный набор докладов, рекомендую. Если вы конференцию пропустили, у Analyst Marathon записи прошедших конференций есть (за деньги), ссылка та же.
Небольшой обзор, что успел посмотреть:
Андрей Бураков, "Ничего мы вам не гарантируем или как брокеры НЕ гарантируют доставку сообщений"
Ну, Андрея всегда интересно послушать, а особенно когда он потрясает основы. Например как в этот раз -- когда он шатает основы гарантированной доставки сообщений и глубоко раскапывает механизмы их реализации. Всё всегда может сломаться, сообщения могут задублироваться, но мы можем с этим работать, нужно знать, как. Если хотите разобраться с гарантиями доставки, идемпотентностью, транзакционной целостностью в брокерах -- посмотрите доклад.
Руслан Сафин "Принцип каскадного снижения связанности"
Руслан так же глубоко разбирает темы связанности и сцепленности (coupling and cohesion). И показывает на примере разбивку системы -- уменьшение связности. Кстати, впервые услышал перевод cohesion как "прочности". Кажется, это должно быть связано с робастностью, нужно подумать эту мысль. Ну и когда тепреь слышу про coupling, не могу выбросить из головы фразу Роя Филдинга: "в архитектуре системы было так много связей, что на диаграмму нужно ставить пометку 18+".
Алексей Краснов "Использование Abuse cases и Attacker stories для анализа требований по безопасности"
Очень интересная мысль в докладе -- как аналитику понять безопасность. Напишите юскейсы злоумышленника! Как настоящие, с целями и успешными результатами, только вредные для системы. Очень крутая идея, и понятная. Потом, конечно, можно ввести требования, которые рушат все вредные юскейсы и на допускают их успешного окончания. Очень практичные требования к безопасности, не какая-то абстракция.
Валерий Разномазов, "Математический аппарат для системного и бизнес-анализа". Многообещающее название, но внутри очень спорный. Я сам топлю за использование математических методов и моделей в системном анализе, по пока мало что могу предложить. Ждал инсайтов, но тут не совсем та математика, которую я ожидал. В основном здесь про теорию множеств, графы и матрицы. Кажется, это лично моя проблема, потому что множества и операции с ними, графы и матрицы у меня настолько вросли в базовую картину мира, что я их уже не воспринимаю, как что-то особенное. Это просто повседневный язык мышления. Если у вас не было этого в школе или в институте -- посмотрите доклад, это база.
Понравился доклад Елизаветы Акмановой про API -- она подробно разобрала разные варианты версионирования API и какие есть плюсы и минусы у каждого варианта. Полезно, я писал об этом тут, а в докладе -- с примерами из практики. Начинаю всё лучше понимать Филдинга с его идеей вписывать версию API в имя домена.
Ну и доклад Николая Лебедева просто огненный, с разными кейсами применения ИИ -- особенно любопытно, как сразу в процессе созвона по ключевым словам ИИ автоматически ставит таски -- это какая-то фантастика.
В общем, очень интересный набор докладов, рекомендую. Если вы конференцию пропустили, у Analyst Marathon записи прошедших конференций есть (за деньги), ссылка та же.
👍15❤7🔥1
Больше видео хороших и разных про ИИ!
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
👍10
Как разобраться с JSON?
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
{ "id": 12345,
"name": "Константин",
"surname": "Константинопольский",
"birthdate": "1990-04-14"
}Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
👍20🤯7❤6
Вообще я хотел серьезный пост написать про математику, которая помогает в интеграциях, но потом вспомнил — какое сегодня число и какой день недели, и понял, что никто толком не работает, и умная тема не зайдет.
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
5😁59❤8👍3
Или вот хардкорный пост.
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javanoscript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.💐 🌸 🌷
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javanoscript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥47❤30❤🔥13👍5👎3