UR🙃, или разбираемся с URL, URI и URN
На днях в очередной раз запнулся о термин URI и решил наконец разобраться в вопросе. Обратился к определениям.
📌 URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса. Это общий термин, охватывающий два типа идентификаторов ресурсов: URL и URN. URI служит для уникальной идентификации любого ресурса независимо от способа его нахождения или адресации.
📌 URL (Uniform Resource Locator) — адрес конкретного местоположения ресурса в сети Интернет. URL определяет конкретный путь к ресурсу, включая протокол передачи данных, доменное имя сервера и путь к файлу/странице.
📌 URN (Uniform Resource Name) — уникальное название ресурса, которое не зависит от физического расположения ресурса. Оно используется для постоянного именования объектов вне зависимости от их текущего местонахождения в Интернете.
Определения прекрасные, но, поскольку лично у меня всё равно вопросы остались, решил углубиться и порассуждать. И вот к чему я пришёл.
💡 URL предназначен для точного указания физического местоположения ресурса в сети. URL указывает на ресурс, ключевое — это "где" (место, адрес). Если ресурс перемещён, доступ к нему прекращается (получаем "битую" ссылку) и нужен новый URL.
Примеры: путь к файлу (file://C:/Users/boss/Downloads/pic.png), адрес в интернет (https://t.iss.one/humane_analyst/222), электронная почта (mailto:[email protected]) и т.д.
💡 URN служит для однозначного определения ресурса независимо от его текущего физического размещения. URN называет объект, ключевое — это "что" (идентификатор, имя). Если ресурс перемещён, его глобальная идентификация остаётся неизменной.
Примеры: UUID, пространства имён (xmlns="https://www.w3.org/1999/xhtml", Namespace="https://www.contoso.com/" и т.п.), постоянные идентификаторы изданий и публикаций (ISBN, ISSN, DOI) и т.д.
💡 Следствие из ранее озвученного: один и тот же идентификатор не может удовлетворять требованиям URL и URN, то есть не может быть способом доступа и идентификатором ресурса одновременно. В этой связи пространство имён при всей его внешней схожести с URL (см. выше) таковым не является, это исключительно URN.
💡 Фундаментально разные цели URL и URN приводят к тому, что с позиции объектно-ориентированной парадигмы URI является родительским классом для классов URL и URN. URL и URN, соответственно, — это дочерние классы (подтипы) для URI. А поскольку примеры URL и URN существуют (см. выше), то URL и URN — это конкретные классы.
💡 URI не сводится к паре URL и URN, есть и другие URI.
Пример 1. Data URI используется для встраивания небольших файлов непосредственно в тело веб-документа. Data URI уникально не идентифицирует ни положение, ни внедряемый файл. Соответственно, Data URI не является URL и не является URN. Вместе с тем ограниченная специализация Data URI и его общность с URI позволяют считать Data URI экземпляром (объектом) класса URI.
Пример 2. Номер телефона в соответствии со спецификацией RFC 3966 (tel:+79211234567) является только URI. Номер телефона не является URL, так как не содержит компонентов для идентификации ресурса в Интернет, и номер телефона не является URN, поскольку URN только называет ресурс, но не говорит, как к нему добраться (а номер телефона позволяет понять, как можно провзаимодействовать с ресурсом и предложить совершить звонок).
Следствие: URI — не просто базовый класс, как говорилось выше, но ещё и конкретный класс.
💡 На практике терминология часто является взаимозаменяемой. Поэтому, говоря, например, про веб-адреса, можно оперировать как термином "URL", так и "URI". Это согласуется с приведёнными выше рассуждениями.
💡 Строго говоря, чтобы идентификатор мог считаться URI, URL или URN, он должен соответствовать определённым форматам.
#проектирование #термины #любопытное
На днях в очередной раз запнулся о термин URI и решил наконец разобраться в вопросе. Обратился к определениям.
📌 URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса. Это общий термин, охватывающий два типа идентификаторов ресурсов: URL и URN. URI служит для уникальной идентификации любого ресурса независимо от способа его нахождения или адресации.
📌 URL (Uniform Resource Locator) — адрес конкретного местоположения ресурса в сети Интернет. URL определяет конкретный путь к ресурсу, включая протокол передачи данных, доменное имя сервера и путь к файлу/странице.
📌 URN (Uniform Resource Name) — уникальное название ресурса, которое не зависит от физического расположения ресурса. Оно используется для постоянного именования объектов вне зависимости от их текущего местонахождения в Интернете.
Определения прекрасные, но, поскольку лично у меня всё равно вопросы остались, решил углубиться и порассуждать. И вот к чему я пришёл.
💡 URL предназначен для точного указания физического местоположения ресурса в сети. URL указывает на ресурс, ключевое — это "где" (место, адрес). Если ресурс перемещён, доступ к нему прекращается (получаем "битую" ссылку) и нужен новый URL.
Примеры: путь к файлу (file://C:/Users/boss/Downloads/pic.png), адрес в интернет (https://t.iss.one/humane_analyst/222), электронная почта (mailto:[email protected]) и т.д.
💡 URN служит для однозначного определения ресурса независимо от его текущего физического размещения. URN называет объект, ключевое — это "что" (идентификатор, имя). Если ресурс перемещён, его глобальная идентификация остаётся неизменной.
Примеры: UUID, пространства имён (xmlns="https://www.w3.org/1999/xhtml", Namespace="https://www.contoso.com/" и т.п.), постоянные идентификаторы изданий и публикаций (ISBN, ISSN, DOI) и т.д.
💡 Следствие из ранее озвученного: один и тот же идентификатор не может удовлетворять требованиям URL и URN, то есть не может быть способом доступа и идентификатором ресурса одновременно. В этой связи пространство имён при всей его внешней схожести с URL (см. выше) таковым не является, это исключительно URN.
💡 Фундаментально разные цели URL и URN приводят к тому, что с позиции объектно-ориентированной парадигмы URI является родительским классом для классов URL и URN. URL и URN, соответственно, — это дочерние классы (подтипы) для URI. А поскольку примеры URL и URN существуют (см. выше), то URL и URN — это конкретные классы.
💡 URI не сводится к паре URL и URN, есть и другие URI.
Пример 1. Data URI используется для встраивания небольших файлов непосредственно в тело веб-документа. Data URI уникально не идентифицирует ни положение, ни внедряемый файл. Соответственно, Data URI не является URL и не является URN. Вместе с тем ограниченная специализация Data URI и его общность с URI позволяют считать Data URI экземпляром (объектом) класса URI.
Пример 2. Номер телефона в соответствии со спецификацией RFC 3966 (tel:+79211234567) является только URI. Номер телефона не является URL, так как не содержит компонентов для идентификации ресурса в Интернет, и номер телефона не является URN, поскольку URN только называет ресурс, но не говорит, как к нему добраться (а номер телефона позволяет понять, как можно провзаимодействовать с ресурсом и предложить совершить звонок).
Следствие: URI — не просто базовый класс, как говорилось выше, но ещё и конкретный класс.
💡 На практике терминология часто является взаимозаменяемой. Поэтому, говоря, например, про веб-адреса, можно оперировать как термином "URL", так и "URI". Это согласуется с приведёнными выше рассуждениями.
💡 Строго говоря, чтобы идентификатор мог считаться URI, URL или URN, он должен соответствовать определённым форматам.
#проектирование #термины #любопытное
🙏4🔥3👍2
🤔 Мысли об устойчивости и интерпретациях этого понятия
Много лет назад применительно к разработке сетевых протоколов был сформулирован принцип устойчивости (robustness principle), известный как закон Постела (Postel's law). Его формулировка: "Будь консервативен в том, что делаешь, и либерален в том, что принимаешь от других".
Если применить этот принцип к построению интеграционных взаимодействий, то можно сказать, что при отправке данных стоит строго соблюдать все стандарты, соглашения и схемы данных, чтобы не обманывать ожиданий, обеспечить совместимость и предсказуемое поведение участников взаимодействия.
На стороне получателя же это можно трактовать так, что надо подходить гибче, игнорировать незначительные нарушения и предусматривать план "Б", не "падая" по пустякам. Какие это могут быть действия (моя версия):
💡 Игнорировать неизвестные (дополнительно появившиеся) поля, свойства, параметры. Причина их появления может быть самой разной, в том числе развитие схемы API.
💡 Использовать, где это возможно по смыслу, разумные умолчательные значения и типы данных, допускающие неопределённое значение (nullable).
💡 Обрабатывать отсутствие некритических для сценария значений (иллюстрация на примере скрытия кнопки в GUI здесь).
💡 Применять схемы проверок данных, игнорируя незначительные ошибки, не влияющие на семантику (например, лишние пробелы, неверный регистр символов, отличный от ожиданий формат даты-времени).
💡 Быть готовым принимать иные, но совместимые типы данных, например, когда числовые и булевы значения поступают в форме строк.
💡 Не закладываться на порядок следования ключей в объектах JSON, даже если в примерах ваши смежники всегда выдерживают один и тот же порядок.
💡 Если это несущественно, игнорировать вложенность полей (скажем, если поставщик данных практикует частую модификацию структуры, а вам требуется по ID найти небольшое число полей).
💡 Стараться мягко обрабатывать неопределённости, когда поступают неполные и/или противоречивые данные (например, восстановление состояния по доступным данным, запрос недостающих данных, организация переспросов клиента).
💡 По возможности предусматривать обобщённую логику обработки при отсутствии обязательных параметров (например, если нельзя ответить конкретному клиенту специфически, поскольку в запросе не был передан его идентификатор, то можно ответить более общо на ту же тему).
💡 Предвидеть возможные нарушения хронологии при асинхронном взаимодействии (условно, логически второе событие может поступить раньше первого) и дублирующие/повторные данные.
Наверняка, список можно продолжить, но я остановлюсь на этом.
Что ещё ☝️
Поскольку списка официальных и авторитетных рекомендаций нет, то практика применения принципа устойчивости складывается по принципу: "Я художник, я так вижу". В частности, мне довелось несколько раз столкнуться с мнением, что намеренная передача внутри JSON различных типов в форме строк (например, вместо true нужно "true") — это тоже следование принципу устойчивости.
На это я хочу возразить: передача чисел и булевых данных в виде строк сама по себе не может считаться соблюдением закона Постела, поскольку нарушается правило консервативной (!) отправки (в стандарте JSON типы данных введены не для того, чтобы кто-то их оборачивал кавычками, сводя всё к строкам ). А вот готовность обработать такое "чудо" на принимающей стороне — это уже хорошо и правильно, это повышает устойчивость решения.
#проектирование #интеграции
Много лет назад применительно к разработке сетевых протоколов был сформулирован принцип устойчивости (robustness principle), известный как закон Постела (Postel's law). Его формулировка: "Будь консервативен в том, что делаешь, и либерален в том, что принимаешь от других".
Если применить этот принцип к построению интеграционных взаимодействий, то можно сказать, что при отправке данных стоит строго соблюдать все стандарты, соглашения и схемы данных, чтобы не обманывать ожиданий, обеспечить совместимость и предсказуемое поведение участников взаимодействия.
На стороне получателя же это можно трактовать так, что надо подходить гибче, игнорировать незначительные нарушения и предусматривать план "Б", не "падая" по пустякам. Какие это могут быть действия (моя версия):
💡 Игнорировать неизвестные (дополнительно появившиеся) поля, свойства, параметры. Причина их появления может быть самой разной, в том числе развитие схемы API.
💡 Использовать, где это возможно по смыслу, разумные умолчательные значения и типы данных, допускающие неопределённое значение (nullable).
💡 Обрабатывать отсутствие некритических для сценария значений (иллюстрация на примере скрытия кнопки в GUI здесь).
💡 Применять схемы проверок данных, игнорируя незначительные ошибки, не влияющие на семантику (например, лишние пробелы, неверный регистр символов, отличный от ожиданий формат даты-времени).
💡 Быть готовым принимать иные, но совместимые типы данных, например, когда числовые и булевы значения поступают в форме строк.
💡 Не закладываться на порядок следования ключей в объектах JSON, даже если в примерах ваши смежники всегда выдерживают один и тот же порядок.
💡 Если это несущественно, игнорировать вложенность полей (скажем, если поставщик данных практикует частую модификацию структуры, а вам требуется по ID найти небольшое число полей).
💡 Стараться мягко обрабатывать неопределённости, когда поступают неполные и/или противоречивые данные (например, восстановление состояния по доступным данным, запрос недостающих данных, организация переспросов клиента).
💡 По возможности предусматривать обобщённую логику обработки при отсутствии обязательных параметров (например, если нельзя ответить конкретному клиенту специфически, поскольку в запросе не был передан его идентификатор, то можно ответить более общо на ту же тему).
💡 Предвидеть возможные нарушения хронологии при асинхронном взаимодействии (условно, логически второе событие может поступить раньше первого) и дублирующие/повторные данные.
Наверняка, список можно продолжить, но я остановлюсь на этом.
Что ещё ☝️
Поскольку списка официальных и авторитетных рекомендаций нет, то практика применения принципа устойчивости складывается по принципу: "Я художник, я так вижу". В частности, мне довелось несколько раз столкнуться с мнением, что намеренная передача внутри JSON различных типов в форме строк (например, вместо true нужно "true") — это тоже следование принципу устойчивости.
На это я хочу возразить: передача чисел и булевых данных в виде строк сама по себе не может считаться соблюдением закона Постела, поскольку нарушается правило консервативной (!) отправки (
#проектирование #интеграции
👍3🔥1🙏1
Вчера Сбер представил руководство по созданию AI-агентов. В документе излагаются:
🔹 теоретические основы разработки AI-агентов;
🔹 имеющиеся архитектурные подходы;
🔹 принципы разработки мультиагентных систем.
Скачать данный гайд можно в соответствующем разделе базы знаний официального сайта (ссылка). Также для удобства продублирую данный документ в первом комментарии 👇.
P.S. Когда я в прошлый раз размещал подобного рода документ от Google (ссылка), кто-то их подписчиков поставил дизлайк 😳. Скромно надеюсь, что данная работа ему понравится больше.
#книги #ai #сбер
🔹 теоретические основы разработки AI-агентов;
🔹 имеющиеся архитектурные подходы;
🔹 принципы разработки мультиагентных систем.
Скачать данный гайд можно в соответствующем разделе базы знаний официального сайта (ссылка). Также для удобства продублирую данный документ в первом комментарии 👇.
P.S. Когда я в прошлый раз размещал подобного рода документ от Google (ссылка), кто-то их подписчиков поставил дизлайк 😳. Скромно надеюсь, что данная работа ему понравится больше.
#книги #ai #сбер
👍3🙏1🏆1
На Хабре недавно прочитал статью о когнитивных искажениях системных аналитиков. Несмотря на отсутствие революционных идей, материал заставляет задуматься о рабочих практиках и взглядах на процесс анализа. В общем, делюсь ссылкой.
#психология
#психология
Хабр
Когнитивные искажения в работе системного аналитика
Работа системного аналитика — это постоянный баланс между техникой и бизнесом, между хаосом требований и порядком спецификаций. Аналитик соединяет интересы заказчиков, пользователей, разработчиков и...
👍3🔥2🤔2
Знаете, не могу отделаться от мысли, что системный аналитик — это тот человек, которому поручают собирать пазл 🧩, но зачастую не говорят, какой рисунок должен получиться в итоге. А ещё пикантней, когда выясняется, что половина элементов картины затерялась где-то в недрах компании, и теперь нужно завершить работу, используя подручные средства. 😅
🔥8💯4🙏3🏆1😭1🙊1
Не знаю, как у вас, а я в последние дни часто наблюдаю сложности с доступом к ресурсам в сети. И это касается не только веб-сайтов, но и работы различных приложений на телефоне: вместо элементов UI с контентом отображаются мерцающие контуры. Знакомо? Вот по этому случаю у меня для вас краткий ликбез 🤓.
Шиммер (shimmering views) — это прообраз реального экрана в виде мерцающих блоков, который указывает пользователю на то, что содержимое UI ещё загружается. Считается, что это улучшает общее впечатление, предоставляя визуальную подсказку вместо пустого экрана.
#uxui #термины
Шиммер (shimmering views) — это прообраз реального экрана в виде мерцающих блоков, который указывает пользователю на то, что содержимое UI ещё загружается. Считается, что это улучшает общее впечатление, предоставляя визуальную подсказку вместо пустого экрана.
#uxui #термины
👍6🔥1🏆1
📖 "Мифический человеко-месяц, или Как создаются программные системы" Фредерика Брукса
Ну вот добрался я до обзора этой довольно известной работы.
🌟 Содержание. Книга достаточно интересна хотя бы тем, что позволяет посмотреть на историю развития индустрии разработки ПО и проследить за мыслями о сложностях и размышлениями, которые возникали на этом пути у автора.
На страницах книги чëтко прослеживаются идеи, которые годы спустя мир узнал уже под "этикетками": Agile, микросервисная архитектура, быстрое прототипирование, выпуск пилотов/MVP, версионирование, инкрементальная разработка и пр. Всё ли это придумал Брукс? Конечно, нет, но, как минимум, это занимало его мысли.
Поскольку книга представляет собой сборник эссе, посвящённых различным вопросам разработки, то она будет интересна широкому кругу читателей из сферы IT: разработкам, аналитикам, менеджерам, архитекторам, тестировщикам.
К слову, известные фразы о невозможности родить ребёнка за месяц девятью женщинами и об отсутствии серебряной пули берут начало именно здесь.
🍯 Ложка дëгтя. Во-первых, слог автора не всегда простой. Но точно не критично. Во-вторых, не все мысли и термины понятны и релевантны современности. 1-е издание книги (а это костяк) вышло в свет в 70-е годы, а значит опирается на ещё более ранний опыт и подходы. Что тут можно сказать: если какая-то глава вообще "не идёт", еë (благодаря тому, что это независимые эссе ☝️) можно пропустить без особых потерь для понимания остальной части книги.
🧙♂️ Резюме. Не смотря на всю "бородатую" историю, книга, как я уже отмечал, будет полезна широкому кругу читателей от разработчиков до менеджеров. В конце концов, многие до сих пор полагают, что добавление людей в проект линейно и предсказуемо уменьшит сроки на его выполнение.
📜 Бонус для тех, кто любит читать выжимки и краткие изложения. В Википедии для вас есть 2 коротенькие статьи по материалам данной книги. Читаем здесь и здесь.
#книги #методыуправления #программирование #нетленка
Ну вот добрался я до обзора этой довольно известной работы.
🌟 Содержание. Книга достаточно интересна хотя бы тем, что позволяет посмотреть на историю развития индустрии разработки ПО и проследить за мыслями о сложностях и размышлениями, которые возникали на этом пути у автора.
На страницах книги чëтко прослеживаются идеи, которые годы спустя мир узнал уже под "этикетками": Agile, микросервисная архитектура, быстрое прототипирование, выпуск пилотов/MVP, версионирование, инкрементальная разработка и пр. Всё ли это придумал Брукс? Конечно, нет, но, как минимум, это занимало его мысли.
Поскольку книга представляет собой сборник эссе, посвящённых различным вопросам разработки, то она будет интересна широкому кругу читателей из сферы IT: разработкам, аналитикам, менеджерам, архитекторам, тестировщикам.
К слову, известные фразы о невозможности родить ребёнка за месяц девятью женщинами и об отсутствии серебряной пули берут начало именно здесь.
🍯 Ложка дëгтя. Во-первых, слог автора не всегда простой. Но точно не критично. Во-вторых, не все мысли и термины понятны и релевантны современности. 1-е издание книги (а это костяк) вышло в свет в 70-е годы, а значит опирается на ещё более ранний опыт и подходы. Что тут можно сказать: если какая-то глава вообще "не идёт", еë (благодаря тому, что это независимые эссе ☝️) можно пропустить без особых потерь для понимания остальной части книги.
🧙♂️ Резюме. Не смотря на всю "бородатую" историю, книга, как я уже отмечал, будет полезна широкому кругу читателей от разработчиков до менеджеров. В конце концов, многие до сих пор полагают, что добавление людей в проект линейно и предсказуемо уменьшит сроки на его выполнение.
📜 Бонус для тех, кто любит читать выжимки и краткие изложения. В Википедии для вас есть 2 коротенькие статьи по материалам данной книги. Читаем здесь и здесь.
#книги #методыуправления #программирование #нетленка
👍4🔥4🤝2
Сегодня хочу поделиться с вами статьёй Алекса Сюя (автора книги по системному дизайну) на тему различных видов API. https://blog.postman.com/api-protocols-in-2023/
Несмотря на то, что название статьи явно отсылает к протоколам, на самом деле в ней кратко описаны архитектурные стили, протоколы, фреймворки и прочие представителифлоры и фауны терминологического разнообразия.
Отдельной похвалы заслуживает иллюстрация в стиле "всё в одном". Помимо смыслового наполнения Алекс с помощью различных размеров секторов на круговой диаграмме проиллюстрировал относительное распространение той или иной технологии по состоянию на конец 2023г. Собственно, эту картинку я и прикрепил к данному посту.
Также, пользуясь случаем, напомню, что ранее я делал достаточно глубокое сравнение веб-сервисов (ссылка). Так что материалы должны неплохо дополнять друг друга. Пользуйтесь 😉
#интеграции #сервисы #проектирование
Несмотря на то, что название статьи явно отсылает к протоколам, на самом деле в ней кратко описаны архитектурные стили, протоколы, фреймворки и прочие представители
Отдельной похвалы заслуживает иллюстрация в стиле "всё в одном". Помимо смыслового наполнения Алекс с помощью различных размеров секторов на круговой диаграмме проиллюстрировал относительное распространение той или иной технологии по состоянию на конец 2023г. Собственно, эту картинку я и прикрепил к данному посту.
Также, пользуясь случаем, напомню, что ранее я делал достаточно глубокое сравнение веб-сервисов (ссылка). Так что материалы должны неплохо дополнять друг друга. Пользуйтесь 😉
#интеграции #сервисы #проектирование
🔥4👍2🤔1
🎬 Подборка видео-собеседований
Некоторое время назад я задался вопросом, что происходит на рынке труда, поспрашивал вокруг (например, здесь). И информация такова, что ряд крупных компаний с конце прошлого года резал проекты вместе с сотрудниками.
Надеюсь, никого из вас это не коснулось, но я решил, что не помешает собрать свежую подборку публичных собеседований. Просмотр (или даже просто прослушивание в фоне во время прогулки) позволяет освежить теорию в памяти и, что самое полезное, можно сделать выводы относительно того, что на текущий момент спрашивают во время таких мероприятий.
🔶 T-Банк | Junior системный аналитик
🔶 Предположительно МТС | Middle/Middle+ системный аналитик (реальное 🔥)
🔶 Просто тестовое | Middle/Middle+ системный аналитик
Также рекомендую ознакомиться со следующим:
🔶 Моя предыдущая подборка собесов
🔶 Разговор с рекрутёром о найме в 2025
И на закуску несколько видео про System Design. Обычно в таком формате аналитиков не спрашивают, но отдельные элементы дизайна могут встречаться. Если же вы будете претендовать на позицию архитектора, то вероятность столкнуться с такого рода задачами сильно возрастает.
🔶 Lamoda Tech | Доклад про проектирование систем
🔶 T-Банк | Доклад про то, как подготовиться к собесу
🔶 T-Банк | Моковый собес – проектирование системы бронирования номеров в отелях
🔶 T-Банк | Моковый собес – проектирование системы проведения A/B-тестирования
#подборки #собесы #проектирование
Некоторое время назад я задался вопросом, что происходит на рынке труда, поспрашивал вокруг (например, здесь). И информация такова, что ряд крупных компаний с конце прошлого года резал проекты вместе с сотрудниками.
Надеюсь, никого из вас это не коснулось, но я решил, что не помешает собрать свежую подборку публичных собеседований. Просмотр (или даже просто прослушивание в фоне во время прогулки) позволяет освежить теорию в памяти и, что самое полезное, можно сделать выводы относительно того, что на текущий момент спрашивают во время таких мероприятий.
🔶 T-Банк | Junior системный аналитик
🔶 Предположительно МТС | Middle/Middle+ системный аналитик (реальное 🔥)
🔶 Просто тестовое | Middle/Middle+ системный аналитик
Также рекомендую ознакомиться со следующим:
🔶 Моя предыдущая подборка собесов
🔶 Разговор с рекрутёром о найме в 2025
И на закуску несколько видео про System Design. Обычно в таком формате аналитиков не спрашивают, но отдельные элементы дизайна могут встречаться. Если же вы будете претендовать на позицию архитектора, то вероятность столкнуться с такого рода задачами сильно возрастает.
🔶 Lamoda Tech | Доклад про проектирование систем
🔶 T-Банк | Доклад про то, как подготовиться к собесу
🔶 T-Банк | Моковый собес – проектирование системы бронирования номеров в отелях
🔶 T-Банк | Моковый собес – проектирование системы проведения A/B-тестирования
#подборки #собесы #проектирование
👍7🔥2🍾1
Друзья, у меня объявление.
Знакомые ребята делают пет-проект — IDE для системных аналитиков. Далее детали.
☝ Чего хочется достичь
Получить удобную и мощную среду на основе VSCode с плагинами, которая закроет все ключевые потребности, а именно:
✔ Гибкость – привычный интерфейс с расширенными возможностями.
✔ Интеграция – поддержка BPMN, UML, US, UC, OpenAPI и других стандартов.
✌️ Кто требуется в этом деле
👨💻 Разработчики — чтобы воплотить идеи в код.
🔍 Тестировщики — чтобы протестировать функциональность и дать обратную связь.
🧠 Практикующие аналитики — чтобы попробовать продукт в работе и поделиться впечатлениями.
💡 Неравнодушные эксперты — чтобы высказать свои идеи, поделиться советами.
Если интересно, то вот канал этого проекта: ссылка.
И ниже вы увидите приглашение на открытое планирование спринта 👇
#анонсы
Знакомые ребята делают пет-проект — IDE для системных аналитиков. Далее детали.
☝ Чего хочется достичь
Получить удобную и мощную среду на основе VSCode с плагинами, которая закроет все ключевые потребности, а именно:
✔ Гибкость – привычный интерфейс с расширенными возможностями.
✔ Интеграция – поддержка BPMN, UML, US, UC, OpenAPI и других стандартов.
✌️ Кто требуется в этом деле
👨💻 Разработчики — чтобы воплотить идеи в код.
🔍 Тестировщики — чтобы протестировать функциональность и дать обратную связь.
🧠 Практикующие аналитики — чтобы попробовать продукт в работе и поделиться впечатлениями.
💡 Неравнодушные эксперты — чтобы высказать свои идеи, поделиться советами.
Если интересно, то вот канал этого проекта: ссылка.
И ниже вы увидите приглашение на открытое планирование спринта 👇
#анонсы
🔥4👍2🙏2
Forwarded from AI IDE BAS 🧠 ИИ агент для аналитики и архитектуры 🧠
🔥 Открытое планирование спринта по развитию IDE для
для БА, для архитектора, для СА🔥
Планирование спринта — важный этап и основопологающая веха.
Еще ценнее, если это происходит открыто и с участием всех, кто заинтересован в продукте🎲
На следующей неделе 02.07.2025 готовим для вас открытую сессию в онлайне по работе с нашей IDE, где вместе с вами в онлайне — погенерируем артефакты и ответим на ваши вопросы.
Всё разложим по полочкам и покажем на реальных примерах.
💥 Планируйте и приходите
🗺 Встреча по планированию 27.06.2025 в 18.00
🔗 https://salutejazz.ru/calls/qmy7yz?psw=OBxWAkYDDAMADFEUGRcbEA8GTA
Приходите поделиться своим видением того, как развить продукт! 🚀
для БА, для архитектора, для СА🔥
Планирование спринта — важный этап и основопологающая веха.
Еще ценнее, если это происходит открыто и с участием всех, кто заинтересован в продукте🎲
На следующей неделе 02.07.2025 готовим для вас открытую сессию в онлайне по работе с нашей IDE, где вместе с вами в онлайне — погенерируем артефакты и ответим на ваши вопросы.
Всё разложим по полочкам и покажем на реальных примерах.
💥 Планируйте и приходите
🗺 Встреча по планированию 27.06.2025 в 18.00
🔗 https://salutejazz.ru/calls/qmy7yz?psw=OBxWAkYDDAMADFEUGRcbEA8GTA
Приходите поделиться своим видением того, как развить продукт! 🚀
salutejazz.ru
SaluteJazz – бесплатные видеоконференции
Создавайте и планируйте видеовстречи с SaluteJazz. Присоединяйтесь к видеоконференции по ссылке прямо в браузере
👍5🙏1🏆1
Как сказали бы англичане, этот комментарий сделал мой день.
Считаю, это яркое подтверждение неискоренимой веры в халяву, умело эксплуатирумой на рынке образовательных услуг.
#войтивайти
Считаю, это яркое подтверждение неискоренимой веры в халяву, умело эксплуатирумой на рынке образовательных услуг.
#войтивайти
💯9🔥3👍1
▀▄▀▄▀▄ Вам шашечки или ехать?
На прошлой неделе столкнулся на работе, можно сказать, с вариацией классической ситуации, когда заказчик предлагает решение, не вербализируя исходную потребность и, в общем-то, не сильно понимая пользу своего предложения.
Теперь детали. Есть мегастрочная задача, все бегут её решать, бегут старательно, со знанием дела. И тут на одной из рабочих встреч от представителя бизнеса доносятся примерно такие слова: "Я считаю, что надо брать эти данные в системе Х, а не в системе Y". Зачем, если накануне уже договорились о другом, какую цель преследует автор этих слов — для многих загадка. Когда на следующий день состоялась рабочая встреча с автором исходного варианта, представитель бизнеса соглашается не настаивать на своём и удовлетворился вариантом получения данных из источника Y. Всё равно цель будет достигнута.
Мотив "смутьяна", насколько я потом уловил, был довольно простой и незатейливый: система Х — это мастер-система, там много всего "вкусного", вдруг в будущем что-то ещё потребуется брать оттуда, а мы уже "прокопали" туда доступы, берём данные и, казалось бы, всё легко. Однако действительность сильно сложнее этого радужного представления. Следует понимать, что собирать данные там в нужном виде — это что-то вроде изобретения велосипеда, притом сразу современного: с регулировкой положения руля, переключением скоростей и прочим "фаршем". И зачем это всё, когда "велосипед" уже собрали другие люди и достаточно его просто освободить от заводской упаковки и пользоваться?
Мораль: ни доводы о светлом будущем, ни статус стейкхолдера, ни уверенный тон последнего не должны затмевать здравый смысл и трезвую оценку наших возможностей. В общем, не поддаёмся на провокации, критически оцениваем предложения, ведь, в конечном счёте, техническое воплощение — это наша зона ответственности и нам потом с ним жить.
На прошлой неделе столкнулся на работе, можно сказать, с вариацией классической ситуации, когда заказчик предлагает решение, не вербализируя исходную потребность и, в общем-то, не сильно понимая пользу своего предложения.
Теперь детали. Есть мегастрочная задача, все бегут её решать, бегут старательно, со знанием дела. И тут на одной из рабочих встреч от представителя бизнеса доносятся примерно такие слова: "Я считаю, что надо брать эти данные в системе Х, а не в системе Y". Зачем, если накануне уже договорились о другом, какую цель преследует автор этих слов — для многих загадка. Когда на следующий день состоялась рабочая встреча с автором исходного варианта, представитель бизнеса соглашается не настаивать на своём и удовлетворился вариантом получения данных из источника Y. Всё равно цель будет достигнута.
Мотив "смутьяна", насколько я потом уловил, был довольно простой и незатейливый: система Х — это мастер-система, там много всего "вкусного", вдруг в будущем что-то ещё потребуется брать оттуда, а мы уже "прокопали" туда доступы, берём данные и, казалось бы, всё легко. Однако действительность сильно сложнее этого радужного представления. Следует понимать, что собирать данные там в нужном виде — это что-то вроде изобретения велосипеда, притом сразу современного: с регулировкой положения руля, переключением скоростей и прочим "фаршем". И зачем это всё, когда "велосипед" уже собрали другие люди и достаточно его просто освободить от заводской упаковки и пользоваться?
Мораль: ни доводы о светлом будущем, ни статус стейкхолдера, ни уверенный тон последнего не должны затмевать здравый смысл и трезвую оценку наших возможностей. В общем, не поддаёмся на провокации, критически оцениваем предложения, ведь, в конечном счёте, техническое воплощение — это наша зона ответственности и нам потом с ним жить.
💯7👍3🔥2👎1
Тут подъехали новости из параллельной вселенной.
Представитель Центрального банка РФ предлагает передать часть АйТишных проектов аутсорсинговым компаниям из Индии. Мотивировка: существенная нехватка квалифицированных специалистов в России. Подробнее.
Я, конечно, понимаю, что в ЦБ ещё не придумали, как совладать с инфляцией, и поэтому у отдельных сотрудников могло появиться свободное время для творчества. Но, как мне кажется, лучше выбрать более нейтральное хобби: макраме, бёрдвотчинг, рыбалка — да мало ли чего ещё! — но вот не управление сферой IT. Ведь и без этого есть вопросы к занятости отечественных специалистов. 🥺
А вы что думаете от этом? Делитесь в комментариях.
Представитель Центрального банка РФ предлагает передать часть АйТишных проектов аутсорсинговым компаниям из Индии. Мотивировка: существенная нехватка квалифицированных специалистов в России. Подробнее.
Я, конечно, понимаю, что в ЦБ ещё не придумали, как совладать с инфляцией, и поэтому у отдельных сотрудников могло появиться свободное время для творчества. Но, как мне кажется, лучше выбрать более нейтральное хобби: макраме, бёрдвотчинг, рыбалка — да мало ли чего ещё! — но вот не управление сферой IT. Ведь и без этого есть вопросы к занятости отечественных специалистов. 🥺
А вы что думаете от этом? Делитесь в комментариях.
👍5😁1
📖 "Прикладной системный анализ" Ф.П. Тарасенко
Сегодня хочу поделиться книгой, которую сложно встретить в подборках вроде "Лучшие книги для системных аналитиков", поскольку уже достаточно давно в профессии аналитика сместились акценты больше на применение IT, построение интеграций и прочие вещи, о которых любят спрашивать на собеседованиях. Некое ядро, теоритическая база перестала многих интересовать.
Так вот, перед нами учебное пособие для студентов технических ВУЗов. Но в этом и плюс данной работы: информация приводится сжато, а значит можно достаточно быстро погрузиться в материал.
🌟 Содержание. Данная работа посвящена методологии системного анализа и её применению в различных областях деятельности. На этом месте стоит сделать паузу и пояснить: под системным анализом здесь понимается научный подход к исследованию и управлению сложными объектами и процессами. Этот подход рассматривает объекты и процессы как целостные системы.
В этом понимании задача системного аналитика состоит в выявление структуры и взаимосвязей элементов системы, построении адекватных моделей, позволяющих оценить возможные последствия принимаемых решений и выбрать наилучший вариант действий (спойлер: лучший — это не всегда автоматизация).
Если сказать грубо: это тот самый системный анализ, который преподают в ВУЗах и который не все любят.
🔍 Что внутри. Пособие состоит из двух примерно равных частей. В первой части даётся понятие системы, приводятся свойства систем, объясняется, что такое модель и моделирование в широком смысле (никаких UML, BPMN и пр. тут не будет). Вторая часть полностью посвящена этапам системного анализа и она потенциально может быть полезна тем, кто интересуется практиками Problem Solving.
💡 Резюме. Нужно ли читать эту книгу конкретно системному аналитику в IT? Я бы сказал, что крайне желательно прочитать главы 2-4, а остальное — уже по желанию. Почему я так думаю? Вдумчивое прочтение, во-первых, позволит уяснить, что такое система в принципе (к сожалению, современные ИТ-аналитики оперируют этим термином, не понимая сути), и, во-вторых, настроить мозг на нужную волну.
#книги #системныйподход
Сегодня хочу поделиться книгой, которую сложно встретить в подборках вроде "Лучшие книги для системных аналитиков", поскольку уже достаточно давно в профессии аналитика сместились акценты больше на применение IT, построение интеграций и прочие вещи, о которых любят спрашивать на собеседованиях. Некое ядро, теоритическая база перестала многих интересовать.
Так вот, перед нами учебное пособие для студентов технических ВУЗов. Но в этом и плюс данной работы: информация приводится сжато, а значит можно достаточно быстро погрузиться в материал.
🌟 Содержание. Данная работа посвящена методологии системного анализа и её применению в различных областях деятельности. На этом месте стоит сделать паузу и пояснить: под системным анализом здесь понимается научный подход к исследованию и управлению сложными объектами и процессами. Этот подход рассматривает объекты и процессы как целостные системы.
В этом понимании задача системного аналитика состоит в выявление структуры и взаимосвязей элементов системы, построении адекватных моделей, позволяющих оценить возможные последствия принимаемых решений и выбрать наилучший вариант действий (спойлер: лучший — это не всегда автоматизация).
Если сказать грубо: это тот самый системный анализ, который преподают в ВУЗах и который не все любят.
🔍 Что внутри. Пособие состоит из двух примерно равных частей. В первой части даётся понятие системы, приводятся свойства систем, объясняется, что такое модель и моделирование в широком смысле (никаких UML, BPMN и пр. тут не будет). Вторая часть полностью посвящена этапам системного анализа и она потенциально может быть полезна тем, кто интересуется практиками Problem Solving.
💡 Резюме. Нужно ли читать эту книгу конкретно системному аналитику в IT? Я бы сказал, что крайне желательно прочитать главы 2-4, а остальное — уже по желанию. Почему я так думаю? Вдумчивое прочтение, во-первых, позволит уяснить, что такое система в принципе (к сожалению, современные ИТ-аналитики оперируют этим термином, не понимая сути), и, во-вторых, настроить мозг на нужную волну.
#книги #системныйподход
👍3🔥1🤩1
💣 Регулярные выражения нерегулярны
Заголовок сегодняшнего поста звучит парадоксально, но, если копнуть вглубь(я сам это недавно сделал, а теперь хочу поделиться с вами) , то всё встаёт на свои места. Он отражает историческую и теоретическую эволюцию термина "регулярные выражения".
В формальной теории языков и автоматов регулярные языки — это класс языков, распознаваемых конечными автоматами. Они описываются регулярными выражениями в классическом смысле, то есть выражениями, которые поддерживают только:
✔ конкатенацию (ab);
✔ объединение (a|b);
✔ звезду Клини (a*).
Однако со временем различные реализации (например, на JavaScript, Python и пр.) регулярных выражений вышли за эти рамки и стали Тьюринг-полными, то есть получили способность распознавать языки, не являющиеся регулярными в теоретическом смысле.
🤔 А если конкретнее?
Рассмотрим пример с так называемыми обратными ссылками (\1, \2,...). Это механизм, позволяющий ссылаться на группы символов, которые были найдены ранее, при поиске совпадений.
Данный код выведет на экран "pp". Следующий же позволит найти уже повтор слов.
Достижение этих результатов требует памяти, что невозможно для классического конечного автомата.
💬 Другой пример
Существуют конструкции lookahead и lookbehind, позволяющие проверять условия, не двигаясь по строке. Так, если мы хотим найти слово "cat", но только при условии, что после него следует пробел или знак препинания, то это можно реализовать следующим образом:
В данном случае результат будет содержать единственное слово "cat", так как второе вхождение не отвечает нашим условиям.
💡 Заключение
Современные реализации регулярных выражений содержат возможности, делающие их значительно более мощными инструментами, чем предполагалось изначально. И это же делает "регулярки" нерегулярными.
P.S. Осознаю, что приведённые рассуждения и примеры могут выглядеть сложными, а я фактически никак не прокомментировал, как работают конструкции из примеров. Это было сделано осознанно, так как целью было сжато проиллюстрировать справедливость тезиса из заголовка. При необходимости вы сможете найти более детальное описание интересующих вас аспектов в открытых источниках.
#любопытное #программирование
Заголовок сегодняшнего поста звучит парадоксально, но, если копнуть вглубь
В формальной теории языков и автоматов регулярные языки — это класс языков, распознаваемых конечными автоматами. Они описываются регулярными выражениями в классическом смысле, то есть выражениями, которые поддерживают только:
✔ конкатенацию (ab);
✔ объединение (a|b);
✔ звезду Клини (a*).
Однако со временем различные реализации (например, на JavaScript, Python и пр.) регулярных выражений вышли за эти рамки и стали Тьюринг-полными, то есть получили способность распознавать языки, не являющиеся регулярными в теоретическом смысле.
🤔 А если конкретнее?
Рассмотрим пример с так называемыми обратными ссылками (\1, \2,...). Это механизм, позволяющий ссылаться на группы символов, которые были найдены ранее, при поиске совпадений.
import re
text = 'Kappa'
pattern = r'(\w)\1'
result = re.search(pattern, text)
print(result.group(0)) # Output: pp
Данный код выведет на экран "pp". Следующий же позволит найти уже повтор слов.
import re
text = 'scary scary movie'
pattern = r'\b(\w+)\s\1\b'
result = re.search(pattern, text)
print(result.group(0)) # Output: scary scary
Достижение этих результатов требует памяти, что невозможно для классического конечного автомата.
💬 Другой пример
Существуют конструкции lookahead и lookbehind, позволяющие проверять условия, не двигаясь по строке. Так, если мы хотим найти слово "cat", но только при условии, что после него следует пробел или знак препинания, то это можно реализовать следующим образом:
import re
text = "I have a cat. My friend has two cats!"
pattern = r"\bcat\b(?=[\W\s])"
matches = re.findall(pattern, text)
print(matches) # Output: ['cat']
В данном случае результат будет содержать единственное слово "cat", так как второе вхождение не отвечает нашим условиям.
💡 Заключение
Современные реализации регулярных выражений содержат возможности, делающие их значительно более мощными инструментами, чем предполагалось изначально. И это же делает "регулярки" нерегулярными.
P.S. Осознаю, что приведённые рассуждения и примеры могут выглядеть сложными, а я фактически никак не прокомментировал, как работают конструкции из примеров. Это было сделано осознанно, так как целью было сжато проиллюстрировать справедливость тезиса из заголовка. При необходимости вы сможете найти более детальное описание интересующих вас аспектов в открытых источниках.
#любопытное #программирование
🔥3👍1
Находясь в отпуске в Стамбуле 🇹🇷, я невольно задумался о его уникальной транспортной системе. Здесь столкнулись не только культуры Европы и Азии, но и специфические условия: этот город расположен на гористой местности, сразу на двух континентах, отделённых Босфором, а европейская часть вдобавок разрезана протяжённой бухтой.
К чему это привело? Вот несколько тезисов на основе моих наблюдений.
👉 Инфраструктура. Мосты, туннели, эстакады и паромы связывают разные районы города, позволяя быстро перемещаться между ними, не взирая на водные преграды и сложности рельефа.
👉 Интероперабельность. Разнообразные виды транспорта — метро, автобусы, трамваи, фуникулёры, электрички, морские переправы — объединены достаточно понятной схемой передвижения, пересадочными узлами и единой системой оплаты Istanbulkart.Хотя тут есть и свои нюансы.
👉 Масштабируемость. Город постоянно растёт (один участок издали даже напоминает виды Нью-Йорка), а значит, транспортным службам надо успевать адаптироваться. Проведение ветки метро до нового аэропорта — тому пример.
👉 Резервирование. Из пункта А в пункт Б часто можно добраться несколькими способами. Наличие дублирующих схем позволяет повысить надёжность и, что немаловажно, комфорт для жителей и гостей города.
👉 Балансировка нагрузки. Составы в метрополитене включают от 4 до 8 вагонов, причём на некоторых станциях на электронных табло указывается не только время (в минутах) до прибытия следующего поезда, но также число вагонов и, в виде инфографики, полнота их наполнения у прибывающего состава. С другими видами транспорта ситуация похожая.
Ну как, ничего не напоминает?😉
В общем, приятно осознавать, что мир вокруг тебя может работать по схожим законам, независимо от масштаба и конкретной локации.
К чему это привело? Вот несколько тезисов на основе моих наблюдений.
👉 Инфраструктура. Мосты, туннели, эстакады и паромы связывают разные районы города, позволяя быстро перемещаться между ними, не взирая на водные преграды и сложности рельефа.
👉 Интероперабельность. Разнообразные виды транспорта — метро, автобусы, трамваи, фуникулёры, электрички, морские переправы — объединены достаточно понятной схемой передвижения, пересадочными узлами и единой системой оплаты Istanbulkart.
👉 Масштабируемость. Город постоянно растёт (один участок издали даже напоминает виды Нью-Йорка), а значит, транспортным службам надо успевать адаптироваться. Проведение ветки метро до нового аэропорта — тому пример.
👉 Резервирование. Из пункта А в пункт Б часто можно добраться несколькими способами. Наличие дублирующих схем позволяет повысить надёжность и, что немаловажно, комфорт для жителей и гостей города.
👉 Балансировка нагрузки. Составы в метрополитене включают от 4 до 8 вагонов, причём на некоторых станциях на электронных табло указывается не только время (в минутах) до прибытия следующего поезда, но также число вагонов и, в виде инфографики, полнота их наполнения у прибывающего состава. С другими видами транспорта ситуация похожая.
Ну как, ничего не напоминает?😉
В общем, приятно осознавать, что мир вокруг тебя может работать по схожим законам, независимо от масштаба и конкретной локации.
🔥5
Чётко сформулированные и согласованные требования — залог успеха любого проекта. Или нет? Вспомнился относительно недавний случай, когда даже составленное ТЗ не уберегло от провала проекта.
Оказалось, заказчик и исполнитель по договору заранее не обсудили вопрос миграции данных из старой системы в новую. А без этого "ингредиента" заказчик отказался от приёмки работ, мотивируя тем, что разработанная для него система не работоспособна.
Попадали ли вы в подобные ситуации? Если да, то обязательно делитесь в комментариях: в чём был камень преткновения, чем всё закончилось и какой урок вы для себя вынесли.
#требования
Оказалось, заказчик и исполнитель по договору заранее не обсудили вопрос миграции данных из старой системы в новую. А без этого "ингредиента" заказчик отказался от приёмки работ, мотивируя тем, что разработанная для него система не работоспособна.
Попадали ли вы в подобные ситуации? Если да, то обязательно делитесь в комментариях: в чём был камень преткновения, чем всё закончилось и какой урок вы для себя вынесли.
#требования
👍2🔥2🤔1