Инженер-конструктор, руководитель проектов.
В этой статье моей целью было дать краткий обзор интернет-ресурсов, которые могут помочь вам в поиске научных публикаций и их анализе. Перед обзором самих методов я также кратко излагаю, зачем нужен раздел Related Works и в чем его особенность в научных публикациях и диссертациях.
Это компиляция основных знаний по проектированию архитектуры ПО, которые мне удалось собрать. Конспект доступен по ссылке на Miro-доску.
Можно сказать, что это взгляд на System Design с точки зрения фронтенд-разработчика, который пытается разобраться в теме.
Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.
В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.
Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.
Эта статья носит практический характер, составлена в виде пошагового чек-листа. Если вы сочтёте полезными описанные в статье техники и начнёте применять что-то из изложенного в этом материале, буду рад получить обратную связь.
Проектирование и работа с REST-сервисами стали повседневными задачами для многих аналитиков. Однако мы часто встречаемся на работе с различными или даже противоречащими друг другу трактовками таких понятий, как REST, RESTful-сервис, RESTAPI.
Сегодня мы разберём, какие принципы вложил в парадигму REST её автор и как они могут помочь нам при проектировании систем.
Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.
Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.
Roadmap или дорожная карта продукта — это не только расписанный план деплоя фичей, это по сути стратегия и тактика на поле боя. Это огромная система фреймворков, методологий и артефактов, в конченом счете визуализированная в виде диаграммы Ганта, таблицы в конфлюенсе с эпик+релиз или ином виде.
Я фронтенд-разработчик в небольшой команде и 2 месяца назад чуть не лишился работы. После двух лет в компании, сотен часов переработок и десятков исправленных багов меня собирались уволить. И они были правы.
Каждый день я опаздывал, допускал ошибки в коде и срывал дедлайны. А потом тратил ночи на исправление собственных косяков в предыдущих проектах.
На этом моя карьера могла закончиться — но я нашёл выход.
Кадровый дефицит — хроническая болезнь российской промышленности. Токарь не вышел на смену, смена не вышла целиком, план сорвался, клиенты ждут, а конкурент дышит в спину. Вдобавок к этому проблемы с нехваткой ресурсов, недостаточная квалификация у вышедших, нет сырья/материалов на складе (но не в учете) и много чего ещё. Но что, если решение может лежать не в плоскости найма людей, а в использовании умных систем? Например, MES может взять на себя часть работы и дать предприятиям возможность не просто продержаться в экономически сложной ситуации , но и стать сильнее. Но, разумеется, есть нюансы… Про них сегодня и расскажу.
Для этого исследования мы спарсили около 2000 вакансий и резюме технических директоров (CTO) в РФ. Мы выделили основные отличия вакансий от резюме и определили, какие наиболее популярные слова используются в описании навыков, должностей и обязанностей. Мы построили карту навыков этой профессии. А главное – посмотрели, как работодатели и соискатели оценивают всё это в деньгах.
Привет, Хабр!
Меня зовут Сергей Громов, я работаю в IT уже 30 лет. Прошел путь от программиста на Assembler и преподавателя до ведущего системного аналитика.
В этой статье мы разберемся с некоторыми основами проектирования микросервисов. Моя цель — объяснить принципы проектирования начинающим и тем, кто работает с уже готовой микросервисной архитектурой. Порой новичкам архитектура сервиса кажется неочевидной. На самом деле, все не так страшно. Есть определенные принципы, которые помогают в этом разобраться.
Диаграммы причинно-следственных связей помогают выявить системную динамику. Обычно их создание требует больше работы, чем чтение, но они могут быть нарисованы абсолютно любым человеком. Главное — быть готовым потратить время на обдумывание и поиск взаимосвязей.
Даже долго работая в одной команде, люди смотрят на вещи по-разному – у них отличается бэкграунд, взгляды на технологии и подходы к работе., т.е. всегда есть проблема синхронизации. И для ее решения необходим общий способ коммуникаций, который исключает недопонимания. Без него даже аналитики не всегда могут договориться между собой, что уж тут говорить про передачу информации в другие сферы проекта. Можно писать огромные талмуды текстом, но на практике гораздо удобнее обмениваться диаграммами.
На подготовку данной заметки меня натолкнула картина, которую я наблюдал совсем недавно в скоростном, двухэтажном поезде АО «ФПК» по направлению Новороссийск-Москва. Состав из 15 новых вагонов, произведенных на Тверском вагоностроительном заводе (ТВЗ, входит в состав АО «Трансмашхолдинг»). Серийно их делают с 2011 года, на рельсы они встали в 2013.
Я написал этот гайд для использования аналитиками в компании (мы интегратор решений 1С в медицине), как настольная шпаргалка и некий базовый «стандарт унификации» формируемых диаграмм данного типа.
Полезно будет как тем, кто только делает первые шаги к стандартизации своего подхода при описании логики бизнес-процессов так и тем, кто уже имеет опыт применения данной нотации.
Многие пользователи диаграмм, создаваемых аналитиком зачастую не готовы читать схемы, содержащие большое кол-во элементов, виды которых нужно знать и понимать. Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь.
Программисты не понаслышке знают, как важно периодически давать отдых уставшим запястьям. И в этом случае возможность диктовки текста – будь то во время длительных сессий программирования или в стремлении к более эргономичной организации работы – может стать настоящим спасением. В данном туториале я вместе с вами подробно рассмотрю процесс создания современного инструмента для транскрибации речи в текст на языке Python, отличающегося высокой скоростью и точностью благодаря использованию ИИ, а именно API Whisper от Groq.
Наша цель – разработать скрипт, работающий в фоновом режиме и позволяющий активировать голосовой ввод в любом приложении простым нажатием кнопки. После отпускания кнопки скрипт мгновенно преобразует речь в текст и автоматически вставит его в активное поле ввода. Таким образом, мы получаем возможность голосового ввода практически в любом вашем приложении.
Приятного прочтения!
Всех категорический приветствую. Буквально первого августа, прямо в ночь, стал у меня жутко лагать YouTube. Естественно, мне это сильно не понравилось. Ну, что же, давайте разбираться, почему и как это исправить в условиях моей личной сети.
Что случилось?
Хорошо описано произошедшее здесь, на Хабре. Если совсем кратко, своими словами - во время установки SSL соединения в открытом виде домен передается к которому мы подключаемся(так называемое SNI). И если это googlevideo.com то начинают твориться "интересные вещи". Можно проверить это локально коммандами из статьи.
$ curl https://speedtest.selectel.ru/100MB -o/dev/null
Цель любого стартапа – выход на рынок в течение минимального срока, постцель – создание условной монополии своим продуктом, как это сделали Я.Такси. Больше никто не мыслит об открытии колл-центров для таксопарков. И хотя Яндекс и его продукты сложно назвать стартапами, принцип развития продукта один – вкладываться в интеллектуальную собственность.
Проблема российских стартапов в том, что в головах их участников укоренили мысль: "Защита интеллектуалки и ее последующая монетизация возможна только с помощью патента", – это вызывает new big aim получение патента, чтобы опираться на него при получении инвестиций и выходить на рынок под защитой.
На деле способ охраны (авторское право, патент, товарный знак, ноу-хау) – это всего лишь способы для защиты технологии, а не цель.
В статье даны пошаговые инструкции, как стартапу правильно проработать свой продукт и защитить права на него в сжатые сроки (до недели) и без глобальных трат, чтобы повысить стоимость проекта на 30%, выходить на питчинги с доказательствами правообладания на продукт и без боязни стать донором идей на рынке!
Привет, ХАБР! Недавно я писал научную статью с AIRI по графовым рекомендательным системам. Это был мой первый практический опыт работы с этой технологией, поэтому пришлось углубиться в исследования и изучение доступных материалов. Я решил, что пока я разбираюсь в этой теме, было бы полезно поделиться своими находками с вами.
Эта статья будет частью серии, состоящей из двух или трех частей. В первой части мы рассмотрим базовые понятия, концепции и простые модели, а также выделим их ключевые особенности. Вторую часть напишут мои знакомые из WildRecSys, где они расскажут о lightGCN и поделятся своим опытом использования этой модели. Все остальные части можно будет найти в моем телеграм канале, поэтому приглашаю подписаться что бы не пропустить, а вам приятного чтения.