В стремительно развивающейся области искусственного интеллекта новая архитектура обещает произвести революцию в понимании и создании нейронных сетей. Названная сетью Колмогорова-Арнольда (KAN), инновационная структура от MIT готова трансформировать традиционные модели своим уникальным подходом.

Для обеспечения статических проверок каждый метод и аргумент метода должны быть обозначены аннотациями @Nullable и @Nonnull. Чтобы не утонуть в этих аннотациях, можно прийти к соглашению, что аннотацию @Nonnull не нужно указывать, т.е. она станет неявной. Чтобы научить Idea определять отсутствие аннотации как аннотацию @Nonnull нужно выполнить простую настройку.

Вместе с дата-сайентистом и биоинформатиком Марией Дьяковой подготовили подробный гайд о том, как устроены языковые модели и что нужно знать, чтобы начать с ними работать.

Думаю, ни для кого не секрет, что Scrum сегодня – одна из самых популярных Agile-методологий. В сети можно найти много позитивных отзывов от людей, которые его попробовали. Но очевидно, что положительных результатов удается добиться не всем, поэтому есть и немалое количество критических статей. Вот, например, недавно тут же – на Хабре – был опубликован перевод подобной статьи  «Почему оценка задач сломала Agile».

У меня есть хороший опыт использования этого самого Scrum`а и оценки задач в нем, поэтому возникла мысль написать разбор приведенных тезисов и ответить на критику (что-то  в стиле «Антипаттерны Scrum»). Но в итоге, я решил, что будет честнее (по крайней мере для моей первой публикации), если я начну с позитива, и сначала попытаюсь сам разъяснить главное на мой взгляд заблуждение в статье – что же такое Story Points, и что такое оценка в Scrum.

При этом я не хочу писать новую инструкцию. Если вам нужны формальное описание и детали, то можете обратиться к первоисточникам, например к книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами» (МИФ, 2015) – там все подробно описано с обоснованиями и прочим. Я же, в свою очередь, хочу предложить более короткий путь: «с использованием местных идиоматических выражений».

Завершение цикла

Нагрузочное тестирование СУБД в облачной среде — часть 1 / Хабр (habr.com)

Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат / Хабр (habr.com)

Задача

Оценить производительность СУБД при постоянной нагрузке, в условиях нестабильной инфраструктуры .

Проблема

На производительность СУБД влияет множество случайных факторов. Производительность инфраструктуры не постоянна и меняется в очень широком диапазоне.

Гипотеза

В идеальных условиях, при постоянной нагрузке, значения производительности СУБД должно иметь нормальное распределение.

В мире победившего эджайла, SCRUM, как один из наиболее популярных фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков он стал чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах scrum-мастеров (речь не обо всех, но о об очень многих). В посте попытался обобщить все проблемы SCRUM, как "фреймворка" для проектного управления и создания продуктов.

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.

С появлением sealed классов и интерфейсов Java открыла перед разработчиками новые горизонты в области проектирования устойчивого и предсказуемого кода. 

В новом переводе от команды Spring АйО было рассмотрено, как эти элементы языка позволяют строго контролировать иерархию классов, обеспечивая тем самым безопасность и простоту поддержки кода. Мы рассмотрим ключевые особенности sealed классов и интерфейсов, их влияние на архитектуру приложений и практические примеры их применения.

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

Что для нас качественный бэклог? Под самим словом бэклог будем понимать список задач, в частности пользовательских историй, которые должна реализовать команда разработки в определенные сроки. Как правило, появляются они в результате декомпозиции функциональности. Что касается качества, то его основным критерием здесь будет результат выполнения этих задач. Другими словами, если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным. О нем и поговорим. На связи Владислав Филимонов, инженер-аналитик КОМПАС-3D.

Сейчас в моде слово «клиентоцентричность», которое заменило привычное мне, бумеру, «клиентоориентированность». И для меня это выглядит так: если раньше важно было делать свой продукт или сервис, ориентируясь на клиента, то сейчас надо просто пойти и сделать, как тебе приказали. И неважно, что ты думаешь, ты же должен быть клиентоцентричным. Для гос. проектов это весьма актуально, кто работал, тот знает.

Однако есть один маленький нюанс: Руководитель проектов должен соблюдать границы проекта, он не волшебник. У него нет бесконечного бюджета и сроков, а значит, иногда придется спорить и отстаивать границы. А значит, говорить «НЕТ». Как это делать так, чтобы не разрушать отношения на проекте, в команде, на аккаунте, а, наоборот, их укреплять? Вот об этом и предлагаю поговорить.

Меня зовут Александр Шаповалов, я руководитель отдела разработки систем расчёта и доставки Mediascope. Количество людей и задач в нашем отделе росло постепенно. Когда в моей команде был только один сотрудник, было легко держать весь рабочий контекст на листке бумаги и в голове: аналитика, архитектура, стек, взаимодействие с заказчиком. Но когда нас стало больше 10, я заметил, что часть аспектов стала ускользать из фокуса. Любые ручные проверки для такого объёма задач не приемлемы, поэтому мы внедрили калибровку процессов с помощью метрик разработки.

Привет, Хабр!

В Java никогда не бывает скучно, особенно когда речь заходит о вещах, которые делают нашу жизнь проще и код — чище.

Сегодня я хочу рассказать вам о четырех фичах в Java, которые сам активно использовал в своих проектах и которые, на мой взгляд, заслуживают внимания. Да, это мой личный список, и я не претендую на то, что эти фичи новы или являются последним писком моды. Однако, по моему опыту, они действительно могут упростить жизнь.

И знаете, что самое приятное? Когда коллеги начинают говорить: "А почему я об этом не знал раньше?"

Когда в последний раз вы сталкивались с трудной для понимания темой? Или проводили часы за просмотром обучающих видео на YouTube?

Существует множество эффективных методик обучения, позволяющих усвоить сложные концепции и обрести уверенность в своих знаниях. Если вы, как и я, постоянно стремитесь к саморазвитию, то понимаете важность правильного подхода к обучению. Одним из наиболее простых и действенных методов является техника Фейнмана.

В этой статье я расскажу, как эффективно применять метод Фейнмана и использовать искусственный интеллект для восполнения пробелов в знаниях.

По окончании чтения вы научитесь использовать ChatGPT для разбора сложных концепций и их интуитивного освоения всего за четыре простых шага.

У вас бывает ощущение, что год прошел зря? Коллеги влетают на вершины карьерной лестницы, бизнес знакомых активно развивается, друзья объездили весь мир и покупают очередную квартиру? А у нас жопа в огне, мы тонем в рабочих задачах, едва успевая найти время на бытовую рутину, не оставляя время на себя?

Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач. 

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

Привет! В этой статье я рассказываю о чистой архитектуре и о паттернах для нее простыми словами. Где, когда и как применять тот или иной паттерн?

• MVVM
• Inversion of Control
• Dependency Injection
• Service Locator

Так же вы узнаете как можно применять ViewModel вместе со своими стейт менеджерами (Bloc), избавив свой виджет от ненужного.

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.

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