Гантовая теория релизов по Канбану

"Что будет, если взять Канбан, смешать его с Гантом и весь этот соус вылить на релизную политику? Давайте разбирать на практике!"

Делаем веб лучше

"Что будет, если взять Канбан, смешать его с Гантом и весь этот соус вылить на релизную политику? Давайте разбирать на практике!"

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

Есть небольшая книжка написанная более 20 лет назад, переведенная на русский как «Экстремальное программирование». При обсуждении этой книжки с коллегами я часто встречал мнение, что она только про то, что надо сначала тесты писать, а потом код и больше в ней нет ничего полезного. Когда у самого добрались руки до нее, я понял, что видимо читают выжимки из статей на Хабре или просто статьи википедии, потому что там есть и паттерны проектирования, и правила написания тестов и практические примеры. А все запоминают только мантру «Утром тесты — вечером стулья код».

Привет, Хабр! Я Катя Саяпина, менеджер продукта МТС Exolve. Сегодня расскажу, как сделать двухфакторную аутентификацию через звонок с применением технологии text-to-speech. Работает просто — пользователь получает код, продиктованный роботом во время голосового вызова. Этот альтернативный SMS и push-уведомлениям способ доставки кода, при этом относительно простой в реализации, дешевле SMS и работает без интернета.
Я покажу, как это работает, на конкретном кейсе.

Всем привет, меня зовут Дмитрий Кремнев и я Java-разработчик в команде Jmix. Недавно на конференции смотрел доклад, в котором спикер рассказывал, как его команда справлялась с проблемой быстрого написания админок для внутренних сервисов. Сначала они реализовали дорогое самописное решение для своей команды, затем появилась идея масштабировать его и для остальных команд. Искали готовые альтернативы на рынке, которые удовлетворят все их бизнес-требования, но в итоге остановились на гибридном кастомном решении, основанном на low-code платформе. Проблемы, которые они решали мне показались очень знакомыми, ведь мы в команде тоже с ними сталкивались. В этой статье я хочу показать, как с помощью Jmix решаются типовые задачи при создании админок. Постараюсь быть конкретным, показать плюсы и ограничения.

Представьте, что в Solana начинают заводить не только токены и мемкоины, а реальные финансовые активы — от гособлигаций до золота.
На днях у меня было интервью с одной любопытной Web3-компанией, которая работает на стыке блокчейна и традиционных финансов. И вот сейчас они готовят протокол для вывода триоллионов RWA ликвидности в DeFi Solana.
В статье мои рассуждения и анализ того, зачем это нужно, как это будет работать и почему это может перевернуть DeFi? На примерах и простыми словами.

На каждом созвоне слышно одни и те же правильные слова:
Надо думать наперед,
Архитектура должна быть мощной,
Давайте писать с запасом на рост.
А к вечеру — очередной релиз на костылях, баги в проде и геройская починка в ночи. И самое забавное, что команда не состоит из новичков. Все прекрасно знают, как делать правильно.

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

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

Всем привет!
Хочу поделиться историей создания проекта, над которым я работал последние несколько лет — foxBase (https://fox-base.ru).
Как часто вам приходилось переключаться между десятком приложений для управления разными аспектами вашей работы и жизни? Блокнот для заметок, Excel для финансов, Trello для задач, отдельные инструменты для хранения кода и документации... Знакомая ситуация?
Меня зовут Игорь, я разработчик, и я столкнулся с этой проблемой в полный рост. Мне нужен был один инструмент, который объединил бы всё: от личных заметок до сложных бизнес-форм, от хранения кода до ведения домашнего бюджета. Так родилась идея foxBase.
Что это такое?
foxBase — это веб-приложение для создания универсальных баз знаний и данных. Его ключевая особенность — невероятная гибкость. Это не жёсткий конструктор, а скорее «цифровой конструктор ЛЕГО», где вы сами решаете, как структурировать информацию.
Для кого это?

Привет! Я — Александр Дудукало, автор базового курса по JavaScript. Продолжаем погружение в этот язык — на этот раз поговорим про циклы. Обсудим, зачем они нужны, какими бывают и как с ними работать.

В период моей работы фронтенд-разработчиком в компании, была поставлена задача создать внутренний веб-аналог Excel, чтобы пользователи перенесли всю работу в веб-приложение.
Первым шагом стал поиск подходящей JavaScript-библиотеки для табличного редактора. Выбор пал на Hansontable за многофункциональность, простоту подключения и за легкую кастомизацию. В общем, на работе задача была выполнена, приложение отвечающее потребностям узкого круга пользователей было создано.
Но мой личный интерес был удовлетворен не полностью, и я решил написать более универсальное приложение до известных пределов - альтернативу Google таблиц и Excel, где будет самый важный функционал из Google таблиц и Excel: это формулы, условное форматирование, построение графиков и тд.
В качестве стека я выбрал Vue3 и TypeScript, а в качестве табличного редактора – проверенный Handsontable.

ГОСТ Р 57580.1-2017, как и любой другой стандарт на территории Российской Федерации, не является обязательным для применения. Однако Банком России выпущены нормативные акты, устанавливающие необходимость применения ГОСТ Р 57580.1-2017. В статье мы расскажем, как можно автоматизировать и упросить процесс проведения оценки соответствия требованиям ГОСТ Р 57580, используя SECURITM.
Под ГОСТом 57580 подразумевается набор критериев, благодаря которым определяется уровень защиты информации в соответствии с требованиями.
Проверка на соответствие требованиям ГОСТ 57580 в финансовых организациях основывается на том, насколько организация придерживается мер для защиты данных.
Из значимых особенностей ГОСТ 57580, следует отметить выделение стандартом трех направлений оценки:

Вам нужно создать сложный запрос к реляционной БД с изменяющимися параметрами?
В этой статье рассмотрим основные возможности Criteria API. Также рассмотрим более продвинутые вещи, например создание CTE и оконных функций, которые есть у Hibernate Criteria API. В статье много примеров, которые смогут помочь при написании запросов Criteria API на практике.
Бывает полезно проводить валидацию данных из формы ввода и на фронте и на бэке, например чтобы не гонять лишний запрос с заведомо "плохими" данными. Отсюда появляется задача написания двух одинаковых валидаторов для фронта и бэка.
Если фронт и бэк написан на одном языке (привет js+node), то мы можем напрямую использовать один код валидатора и там и там.
В остальных случаях (js+php, java, python, go, dotnet) есть проблема. Во-первых, придётся два раза писать примерно одно и то же на двух языках, во-вторых, нужно убедиться, что написанное работает одинаково. Особенно печальны случаи, когда фронт ошибочно зарезает данные, валидные с точки зрения бэка и логики приложения.

Сегодня хотелось бы поговорить с вами о такой теме как Легаси.
Давайте дадим определение, что такое легаси.
Легаси - это тот код, который писали до нас и который пришел нам от других.
Легаси - это не всегда «плохой» код, а просто код, который устарел по технологии, по структуре или по пониманию.
Почти любой проект со временем превращается в легаси, если его не обновлять.
На своем опыте разработки я могу классифицировать легаси на три категории. Опять же я не претендую на абсолютную объективность. Это только моя классификация, на основе того, с чем лично я столкнулся.
1) Технологии, которые еще работают, но есть обновленные версии пакетов, фреймворков и инструментов. Просто в данный момент код работает на предыдущих версиях. Самый очевидный пример проект написанный на Vue2, когда есть Vue3. Переписать его на новую версию с одной стороны не так уж и трудно. А с другой это связано с подводными камнями. Если мы переходим с Option Api на Composition Api то простой заменой одного кода на другой не обойтись. Некоторые вещи работают иначе. И придется отлавливать локальные проблемы. Если проект небольшой и сложной логики там мало, то это делается быстро. Если же она есть то проблемы точно будут. Кроме того не стоит забывать, что часть пакетов и библиотек, которые работают с Vue2, не работают с Vue3. Следовательно придется искать аналоги. В целом проблемы и способ перехода здесь прозрачны и это самый легкий вариант.
2) Нельзя переписать, но можно работать. Это проекты написанные на старых технологиях, как jquery и других. Они не могут быть быстро и легко переведены на современные инструменты. Так как для этого придется все писать заново. Однако код, который был написан, достаточно понятен и его не так сложно поддерживать. А переезд на новый вариант это параллельная разработка нового. Здесь тоже все понятно. Мы не имеем возможности бесшовно перейти на новые версии, потому что их просто может не быть. Поэтому приложение пишется с нуля на новом стеке.

Привет, Хабр!
Вы, наверно, привыкли к стандартным HTTP-ответам – 200, 301, 404, 500 и т. д. А тут подкрался новый статус 103 – Early Hints. Это небольшой пинок браузеру: сервер шлет код 103 с заголовками Link: rel=preload ещё до того, как сформировал основной HTML. Пока бэкенд думает над ответом, браузер параллельно начинает грузить критические ресурсы (CSS, JS, шрифты и т. д.). Звучит просто, но эффект на производительность и LCP может быть весьма значительным.

Салют, Хабр!
Меня зовут Паша, я вхожу в группу обеспечения производительности интерфейсов; неформально это команда «Скорость» SberDevices. Мы с коллегами отвечаем за то, чтобы сайты sberdevices.ru, giga.chat, developers.sber.ru и другие быстро работали и красиво выглядели. Если пользователю неудобно использовать сайт, он быстро с него уйдёт (и не станет ничего читать и покупать).
Как только потребовалась оценка качества веб-страниц, появилось и множество подходов к ним. Но в итоге индустриальным стандартом стали методы, предложенные Google и реализованные на уровне браузерных API. Чтобы понять, как сайты стоит оптимизировать и что влияет на их быстродействие, Google оперирует тремя метриками — Core Web Vitals. Две из них действуют с мая 2020 года, а третьей не исполнилось и года. Сегодня расскажу, как разработчик может оценить их и улучшить без консультации команды скорости (если она есть). А ещё благодаря оптимизации метрик Core Web Vitals сайт ранжируется в поисковиках выше. Поехали!

Вы когда-нибудь радовались идеальному прототипу парсера, который у вас летал на демо-странице, а в проде внезапно начал ловить 403, 429, пустые HTML и «куда-то делись карточки»? Контент отрисовывается на JS, сервер требует токен, после смены IP, старая сессия перестаёт работать.
В этой статье я подробно разберу, как собирать данные устойчиво и предсказуемо, без излишней магии и с упором на реальную эксплуатацию.
Привет, я Сергей Маркизов, разработчик диджитал-продакшна Далее. В наших проектах часто использую Drizzle — современную, типобезопасную ORM для TypeScript, которая не усложняет базовую задачу: читать и писать данные. В этой статье расскажу, чем библиотека отличается от других и как с ней работать.