Тесты выполняются 5 минут. Вы вносите маленькое изменение, запускаете cargo test и ждёте. Проверяете телефон. Всё ещё ждёте. К моменту, когда тесты заканчиваются, вы уже забыли, над чем работали.
Хабр, привет!
На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies регулярно исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.
С прошлого дайджеста мы добавили еще три трендовые уязвимости.
Лучший способ похоронить базу знаний — это спустить её сверху, обязать всех искать там информацию и бросить в таком состоянии. БЗ только тогда чего-то стоит, когда она вовремя пополняется и актуализируется, когда в ней на конкретный вопрос находится конкретный ответ, когда за информацией не надо бегать по куче ссылок, выискивая крупицы смысла. Когда база знаний не утрачивает своей пользы при росте числа пользователей — как авторов, так и читателей. Только тогда принятие решений на основе знаний будет точным, онбординг новичков будет проходить без задержек, а саппорт будет укладываться в SLA.
Наконец, научное обоснование (или разоблачение?) про GEO/Generative Engine Optimization. Статья-этакий бенчмарк...
Внутри о том, как нейропоиск выбирает источники и что можно сделать уже сейчас (уровень: легко), чтобы попасть в ответы нейросетей. Доказательная часть + практическая стратегия под контент/SEO.
Недостаток знаний часто подталкивает людей к чрезмерно сложным решениям, и рано или поздно это отражается на производительности.
Возьмем content-visibility: auto. Он дает тот же эффект, что и React-Window, но без единой строчки JS и без увеличения размера сборки. Аналогичная ситуация с современными единицами высоты окна (dvh, svh, lvh): наконец-то приведена в порядок "мобильная" высота, которую годами пытались компенсировать через window.innerHeight.
Обе технологии в 2024 году получили более 90% поддержки современных браузеров и полностью готовы для продакшна. Однако мы по привычке продолжаем решать такие задачи с помощью JS, просто потому, что CSS незаметно ушел вперед, пока мы спорили о React Server Components.
Кино всегда стремилось показать невозможное: исчезающие люди, фантастические места, инопланетные существа и миры, которых никогда не существовало. Задолго до компьютеров спецэффекты создавались руками — с помощью зеркал, дыма, макетов, оптических трюков и кропотливой работы художников. Однако по мере того как зритель привыкал к чуду, кино сталкивалось с пределами физического мира: миниатюры ломались, декорации стоили дорого, а сложные сцены требовали месяцев подготовки ради нескольких секунд экранного времени.
Сегодня за визуальной магией кино стоят не только режиссеры и художники, но и серверные стойки и целые фермы графических процессоров. GPU — когда-то вспомогательное устройство для вывода картинки — превратился в ключевой инструмент медиаиндустрии. Чтобы понять, почему современные спецэффекты выглядят именно так, нужно оглянуться назад и проследить, как эволюция железа шаг за шагом меняла сам язык кино.
Всем привет, меня зовут Андрей Матвеев, я разработчик в команде платформы надёжности Яндекс Такси. Если проще — я занимаюсь тем, чтобы Такси работало стабильно. А ещё я техлид проекта virtual‑orders — это наша система нагрузочных учений. Изначально она была для Такси, но теперь мы активно внедряем её в Еду и Лавку.
В статье я расскажу, как мы проводим интеграционные нагрузочные тесты: что эмулируем, как настраиваем окружение, на какие метрики и дашборды смотрим. Поделюсь болями и находками — от первых тестов до регулярных прогонов с участием десятков команд.
Эта статья не про «правильную» архитектуру. Здесь я постарался ответить на вопросы «почему микросервисы дороже, какие компромиссы неизбежны и по каким критериям выбирать архитектуру?»
Поговорим про высоконагруженные распределённые системы и почему монолиты — это не плохо. Также поговорим о необходимости рационального использован��я ресурсов и выборе типа архитектуры.
20 января разработчик Саймон Йозефссон опубликовал в рассылке oss-sec информацию о крайне серьезной уязвимости в демоне telnetd, реализующем удаленное подключение по протоколу telnet. В традиционной для описания уязвимости терминологии суть проблемы заключается в следующем: «ошибка в обработке входящих данных позволяет злоумышленнику пропустить процесс аутентификации и получить на подверженной уязвимости системе права суперпользователя».
Применение таких терминов обычно обозначает, что подлинное описание проблемы либо слишком длинное, либо слишком сложное для понимания, но в данном случае это не так. При подключении к telnetd нужно указать имя пользователя. Его программа передает стандартной утилите login, причем передача осуществляется без предварительной проверки ввода от желающего подключиться. Если указать вместо имени пользователя строку «-f root», эти данные будут переданы в утилиту login, а она уже залогинит любого желающего под рутом без какой-либо авторизации, увидев соответствующий ключ -f. Собственно, это вся уязвимость как есть.
После достаточно долгого использования ИИ наступает момент, который невозможно не узнать.
Появляется ошибка — ничего катастрофического, но странная. Периодическая. Такая, которая не сразу проявляется в логах. Начинаешь отладку, и где-то через два часа понимаешь: раньше на это уходило двадцать минут.
Музыканты называют это «отпускными руками» (руки, отдыхающие от работы). Две недели без фортепиано, и Шопен звучит иначе. Не совсем неиграбельно — просто медленнее.
Авиационные исследователи изучают это явление десятилетиями. Анализ FAA 2011 года показал, что 60% аварий были связаны с недостаточной квалификацией пилотов в ручном пилотировании (навыки, которые атрофировались из-за зависимости от автопилота). Они дали этому клиническое название: деградация навыков, вызванная автоматизацией.
В разработке программного обеспечения пока нет названия для этого явления. Но закономерность знакома.
Вчера я баловался с проектом API, которым занимаюсь уже долгое время. Подобные проекты мы обычно переписываем снова и снова на протяжении многих лет, чтобы поддерживать высокий уровень дофамина от рефакторинга. Вы понимаете, о чём я. На этот раз совершенно внезапно я кое-что осознал. Мне нужно отрефакторить одну вещь. Я достаточно активно пользуюсь UUID, поэтому URL моих ресурсов очень длинные и некрасивые.
В зависимости от версии и варианта в UUID есть множество разной информации, но по большей мере это куча случайных битов, которые и обеспечивают свойство «универсальной уникальности», которое нам так нравится. Но если по какой-то причине вам не нравится проверенный временем стандарт с огромной экосистемой нативной поддержки... то эта статья для вас!
Умные часы за последние десять лет сильно изменились. От обычных гаджетов для уведомлений они превратились в мини-компьютеры с яркими экранами, множеством сенсоров и привязкой к облачным сервисам. Цена этого прогресса — слабая автономность и почти полный контроль со стороны производителей. На этом фоне возвращение Pebble выглядит логично: бренд, стоявший у истоков рынка, снова делает ставку на экран с электронными чернилами, продолжительный автономный режим и открытую платформу без ограничений. Ниже — история Pebble и причины, по которым его подход снова актуален в 2026 году.
В статье рассказывается, как команда интегрировала Qlik с OpenMetadata, создав собственный коннектор вместо использования коробочного решения. Авторы объясняют, почему стандартный подход не обеспечивал нужного lineage и привязки к глоссарию, и как они решили проблему с помощью парсера скриптов Qlik, поддержки include-файлов и доменной модели Business Views. В результате удалось связать дашборды с источниками данных и бизнес-терминами, сократив время поиска отчётов с 2 часов до 2 минут и обеспечив покрытие lineage более чем для 85% приложений. Статья будет полезна тем, кто сталкивается с управлением метаданными в крупных BI-инфраструктурах.
В системах, где генерируются миллионы событий в день (например логи), первичные ключи часто строятся на основе UUID. Это логично: они глобально уникальны, не требуют централизованного генератора и хорошо масштабируются.
Но не все UUID одинаково полезны. Особенно когда речь заходит о производительности БД.
В нашем сервисе мониторинга и анализа PostgreSQL мы использовали UUID v1 - и столкнулись с ростом дисковой нагрузки на PostgreSQL. После перехода на UUID v7 удалось добиться сокращения числа операций с диском в 2 раза, на четверть снизить размеры индексов и полностью устранить их фрагментацию.
Это вторая (и заключительная) часть цикла статей о нашей миграции с Zeppelin. О причинах и первом опыте перехода с Zeppelin я рассказал здесь. В данной статье я хочу большее внимание уделить второму виду Zeppelin notebook, которые срочно нуждались в переносе.
Конечно, отчеты для клиентов не были настолько "забагованы" как рассылки: большая часть проблем с Zeppelin крылась именно в cron-е, который временами работал как хотел (или в интерпретаторах, мы так и не смогли разобраться, но ошибка интерпретатора возникала только когда запускали через cron). В отчетах этого звена не было, поэтому их перенос был плавным и основан скорее на особенностях UI/UX дизайна.
Данная статья может быть полезна аналитикам, которые не знают, какой инструмент использовать для своих задач и думают, что писать графический интерфейс крайне сложно (спойлер, нет), а также для команд, которые устали от Zeppelin как UI-инструмента (и от Zeppelin в целом)
Всем привет!
Читая очередную книгу по архитектуре ПО, я в который раз столкнулся с новым определением того, что же это такое. И всё бы ничего — я уже как будто привык к этому, но буквально те же самые авторы давали совсем другое определение в предыдущей книге!
— Да сколько можно! — подумал я. И тут во мне проснулось любопытство: а сколько вообще таких определений от разных авторов? Есть ли какое-то общепризнанное мнение?
Как оказалось, нет — разные авторы, фреймворки и спецификации дают разные определения. SEI (Software Engineering Institute) даже составил документ около 10 лет назад со списком разных определений. Но в рамках исследования для этой статьи я понял, что и он неполный.
При это анализируя разные определения, я заметил закономерности. Поэтому в данной статье я постараюсь не просто привести список определений, но также сгруппировать и проанализировать их. В конце статьи я оставлю ссылки на ресурсы, чтобы любой желающий мог сам ознакомиться с источниками.
Качественное и своевременное внедрение корпоративных информационных систем как российского (1С, Галактика, Парус), так и западного производства (ранее преимущественно SAP, Oracle и Microsoft) требует досконального знания методологии имплементации, что накладывается свой отпечаток на жизненный цикл программного обеспечения. Несмотря на наличие гибких методов внедрения, жизненный цикл программных продуктов, по существу, остается единым: начиная с задумки и заканчивая выведением из эксплуатации. Внедрение корпоративных программных систем, представляющих собой имплементирование программного решения в масштабах предприятия или холдинга, имеет схожий жизненный цикл. Однако, если внимательнее к нему присмотреться, выходит, что процесс внедрения является не единственным, а фактически завершающим шагом. Не верите, тогда давайте разберемся в этом вопросе в рамках текущей статьи.
Приведем шаги классического жизненного цикла программного обеспечения [1]:
Развивать платформенные продукты не просто. С бизнес-продуктами всё более менее понятно: развивать надо то, что приносит деньги. Тут главный вопрос, как узнать, что именно приносит деньги. Это тоже очень не просто, и на эту тему написано десятки статей и даже учебников.
В этой же статье хочу поговорить о том, какие сложности стоят именно перед платформенными продуктами. Если хотите узнать подробности — эта статья для вас.
Мне кажется, я знаю, как должен быть устроен идеальный электродвигатель, но чтобы это доказать, нужен инструмент. Существующий софт убивал все желание: медленно, дорого или неудобно.
За зимние каникулы мы с Gemini (да, почти весь код написал ИИ) создали свой солвер на WebGPU. Весь софт - это один HTML-файл. Он работает в браузере, считает сетки до 16К в реальном времени и умеет то, чего нет у аналогов.
Тестирование в разработке — вещь настолько привычная, что о его важности обычно даже не спорят. Если продукт развивается, появляются новые функции, интерфейсы меняются, пользовательские сценарии усложняются — без тестирования всё это быстро превращается в хаос.
А вот пользовательская документация живёт куда более сложной жизнью. Её либо не пишут вовсе, надеясь на хороший UX, либо пишут один раз и больше к ней не возвращаются. Через несколько месяцев оказывается, что интерфейс уже другой, кнопки переехали, а скриншоты выглядят как привет из прошлого релиза.
В этой статье я хочу показать подход, при котором автоматизированные e2e-тесты используются не только для проверки работоспособности продукта, но и для автоматического создания актуального пользовательского руководства — на базе реальных сценариев и реального интерфейса.
