Привет, меня зовут Федоров Кирилл, я менеджер продукта компании Forecast NOW!. Мы делаем систему для прогнозирования спроса, автозаказа и управления запасами. В конце прошлого года мы выпустили новую версию с обновленным интерфейсом. В статье расскажу о том, почему решили менять интерфейс, как тестировали новые наработки и с какими сложностями столкнулись в процессе.
Общее количество всех команд во всех этих расширениях — 1342 инструкции!
От комментариев воздержусь, оставлю эту привилегию читателю ))
При этом SIMD на RiscV очень хвалят, как очень продуманный, минималистичный, при этом мощный и выразительный: https://www.youtube.com/watch?v=lwIBp6cc-HY
C 2019 года мир привыкал к новой реальности и приспосабливался к удаленной работе. На дворе 2025 год и теперь вызов для распределенных команд — не просто организовать совместную работу вне офиса, но и подготовиться к блокировкам сервисов, к которым уже успели привыкнуть. Как организовать работу небольшой команды разработчиков (до 50 человек), если у вас нет отдела DevOps и бесконечного бюджета на on-premise и облака, а каждый новый день доступных сервисов становится всё меньше? В статье постараюсь ответить на этот вопрос.
Я Олег Юрчик — старший python-разработчик, сейчас работаю в Cloud.ru За последние два года я организовывал инфраструктуру для трех небольших команд (до 15 человек), а еще около двух лет держу домашний сервер с семейной инфраструктурой: файлохранилище, менеджер паролей, календарь, книгу контактов и так далее. Хочу поделиться, к каким решениям я пришел за это время, а также пошагово, но не вдаваясь в подробности, рассказать, как развернул собственную цифровую крепость.
Перспективная технология сначала какое-то время ищет своё место на рынке, а затем уже закрепляется – и зачастую не там, где планировалось. Из примеров, которые приходят на ум: SMS разрабатывался как технический канал связи между инженерами и операторами мобильных сетей, детский пластилин Play-Doh в 1930-х был инновационной смесью для обработки обоев от сажи и пыли, а исследования радиолокации в ходе РЭБ стали микроволновками на наших кухнях. Кажется, что Deepfake пока что не «устаканился» на каком-либо из рынков (хотя киноиндустрия – наиболее вероятный претендент) и пока находится в стадии активного поиска.
Разумеется, чем более прорывной является технология, тем сильнее возникает соблазн использовать «тёмную сторону силы»: согласно Юнгу, Тень всегда стремится к проявлению – иногда так, что полностью заменяет собой Персону – это справедливо и для рыночных ниш. Дипфейк не уникален: когда-то давно порох изначально был атрибутом праздника (фейерверки), а динамит помогал шахтёрам прокладывать тоннели, но если бы мы с вами сейчас играли в игру «100 к 1», это были бы далеко не самые популярные ответы о применении пороха и динамита. Возможно, люди скоро забудут о том, что airTag на самом деле помогает искать потерянные вещи, а вовсе не следить за неверными мужьями – рынок иногда преподносит сюрпризы, оставляя поиск ответа на вопрос «почему?» грядущим поколениям. «Серый» функционал часто является фоновым сопровождением для основного назначения, и иногда с этой проблемой приходится активно взаимодействовать на старте самой компании-прародителю. Например, подделка документов и фото в Photoshop в какой-то момент вылилась в инициативу компании Adobe по созданию Content Authenticity Initiative (CAI) и проекта C2PA. Однако если на рынке не сложилась система взаимной ответственности, внутри которой имидж бенефициаров находится в плотной ассоциативной связке с неоднозначным продуктом, то работа по «обелению» становится неприоритетной. Создаётся впечатление, что подчёркивать светлые стороны deepfake для широких масс пока что не представляется нужным или возможным – слишком много «грязной» работы придётся проделать.
Публикуем примеры взлома информационной инфраструктуры четырех объектов. Под раздачу попали: банк, два дата‑центра и умный дом. Как видно из заголовка, только три варианта произошли в реальности, а один мы выдумали сами. Ответы — в конце статьи.
Полагаем, что учиться на чужих ошибках всегда приятнее, чем на своих, поэтому желаем приятного чтения.
Хочу поделиться идеей, как сделать признание в любви особенным, запоминающимся и искренним, не прибегая к классическим цветам или банальным текстам в телеграме/вацапе на миллиард строк. Я расскажу про интерактивный веб-сайтик, который можно создать своими руками, чтобы передать свои чувства. Это не просто слова, а целая история, которая разворачивается на экране, погружая человека в атмосферу тепла и эмоций. Код, который я приложил, пример такого проекта, и сейчас я объясню, как он работает и почему это может стать идеальным способом признаться в любви.
Greengage DB — это массивно-параллельная реляционная СУБД на базе Greenplum OSS, которая подходит для хранения и обработки данных. Позволяет выполнять сложные аналитические запросы над большими объёмами данных, предоставляя к ним гетерогенный доступ за счёт различного рода коннекторов и средств интеграции.
Но помимо функциональных возможностей, есть и ряд других необходимых вещей, таких как мониторинг, аудит, резервирование и пр. Они требуются для обеспечения полноценной и надёжной работы системы, особенно если речь идёт о промышленной эксплуатации. В рамках данной статьи как раз хочется обсудить подход к резервированию кластера Greengage: какие тут есть возможности, каковы подводные камни и многое другое.
Kubernetes является мощным инструментом для оркестрации контейнеризированных приложений. Построение инфраструктурной платформы на основе K8s является очень нетривиальной задачей, и в этой статье мы рассмотрим основные вопросы и проблемы, возникающие при разработке архитектуры платформы.
Привет, Хабр! В этой статье я расскажу о возможностях API Magic Eden - одного из крупнейших NFT-маркетплейсов на Solana, и покажу, как с его помощью можно создавать интересные проекты.
Сидел я с ними в одном офисе и своими глазами видел, как старший разработчик забирал все сложные и интересные задачи себе, хотя по идее должен был обучать новичка. У этого «младшего» был такой же опыт, просто в других компаниях.
Гиперконвергентная инфраструктура (HCI) зарекомендовала себя как надежный и эффективный способ построения современных IT‑систем. Однако вокруг гиперконвергенции до сих пор существует множество мифов. И несмотря на очевидные преимущества этого архитектурного подхода, многие компании по‑прежнему с осторожностью относятся к его внедрению. Давайте разберем страхи, которые мешают ИТ‑руководителям перейти на гиперконвергентный подход, и проанализируем, насколько они соответствуют действительности.
Сегодня рассмотрим вопросы, касающиеся ТСО (или совокупной стоимости владений).
В рамках проекта продвижения открытого исходного кода в России я подготовил open-source Telegram-бота, реализующего базовую бизнес-логику — и выложил его в открытый доступ под лицензией MIT. Проект ориентирован на предпринимателей, технических специалистов и разработчиков, которым необходимо быстрое, автономное и прозрачное решение.
Почему для меня это важно
В условиях изменений в законодательстве (в частности, вступающий в силу с 1 июля 2025 года запрет на хранение персональных данных россиян на зарубежных серверах) актуальность локальных решений существенно возрастает.
Этот бот не использует сторонние облачные платформы и может быть развернут на обычном локальном ПК с самой распространённой Windows 10 x64 — например, на ноутбуке, постоянно подключённом к сети (даже самый простой конфиг справится).
В последнее время тема собеседований, особенно на Хабре, стала очень актуальна. В каждой статье кандидаты жалуются, что стало много собеседований и советуют друг другу ИИ‑инструменты, которые помогут сломать эту стену. С другой стороны, компаниям не нравится, что просто обычного разработчика средней квалификации уже сложно найти и надо потратить много времени на это.
Совсем недавно появилась статья: «Читерство в законе. Как пройти собеседование и устроиться на работу в дивном новом мире». Если коротко, то в ней говорится о том, что для того, чтобы устроится на работу необходимо специально тренироваться для прохождения собеседований. Все друг друга обманывают (как HR со стороны компании, так и сам кандидат).
И с этим сложно не согласится. Мне иногда приходится иметь дело с наймом. И что я вижу на собеседовании? Или что я проверяю на собеседовании? Правильно: умение проходить собеседования, а не навыки и опыт работы. А ведь не должно быть так!
Привет, Хабр. Меня зовут Антон, я работаю в группе нагрузочного тестирования ЮMoney и занимаюсь исследованием производительности. В статье расскажу про xk6-browser — что у нас было до него, какие у этого решения преимущества и метрики.
В первой части статьи с помощью инструмента Jmix AI Assistant начато создание системы для проведения онлайн курсов.
Были сгенерированы сценарии использования (use cases), разработана UML-диаграмма в формате PlantUML для этих use cases, разработана доменная модель для системы и ее реализация на JMIX. Далее все классы разбиты по пакетам.
Продолжим эксперименты по разработке кода с помощью Jmix AI Assistant, включая следующие:
- Генерация класса, заполняющего доменную модель тестовыми данными
- Генерация REST API для модели домена, включая создание контроллеров и REST сервисов
- Генерация пользовательского интерфейса
START — опенсорсная LLM для точных вычислений и проверки кода. В START решены две главные проблемы большинства обычных моделей: галлюцинации и ошибки в многоэтапных расчетах. В статье разберемся, зачем и как именно эти проблемы решены.
Нам нужны новые системы безопасности, учитывающие их странности
Люди регулярно ошибаются — это часть нашей повседневной жизни. Мы можем допустить промах как в новых, так и в привычных действиях. Одни из них несущественны, другие — фатальны. Они способны подорвать доверие окружающих, испортить репутацию на работе или даже стать вопросом жизни и смерти.
За тысячелетия человечество создало множество механизмов, минимизирующих типичные промахи. В казино, например, часто меняют крупье, поскольку монотонность увеличивает вероятность сбоев. В больницах пациенты перед операциями получают пометки на теле, чтобы врачи не перепутали часть тела, и проводят проверку инструментов, чтобы ничего не осталось внутри. Мы научились справляться с человеческим фактором — от корректуры текстов и двойной бухгалтерии до апелляций в судах.
Теперь в обществе активно внедряется новый тип участника процессов — искусственный интеллект (ИИ). Системы, вроде больших языковых моделей (LLMs), решают когнитивные задачи, которые ранее были доступны только людям. Но и они не безупречны. Порой их «советы» — как есть камни или добавлять клей в пиццу — вызывают недоумение. Однако важен не сам факт наличия сбоев, а природа этих сбоев — она совсем иная, чем у человека.
Многие риски, связанные с ИИ, проистекают из этой разницы. Нам нужны новые системы безопасности, адаптированные под специфику машинного мышления, чтобы свести к минимуму потенциальный вред.
Человеческие ошибки vs. ошибки ИИ
Жизненный опыт помогает нам предсказывать, где и почему может оступиться человек. Обычно сбои происходят на границах знаний: большинство из нас легко допустит ошибку в сложной математике. Мы понимаем, что промахи часто идут "пачкой": неуверенность в одном вопросе тянет за собой другие. Мы также знаем, что на надежность влияет усталость или отвлеченность. И чаще всего человек осознаёт, когда чего-то не знает: тот, кто не силён в матанализе, вероятно, прямо скажет «не знаю».
После громкого дебюта ChatGPT и Midjourney в 2022 году нейросети стали появляться как грибы после дождя. Интернет наполнился большим количеством сервисов, предлагающих генерацию текста, кода, изображений, видео и аудио по текстовым запросам.
Разумеется, многие из таких сервисов существовали и раньше, однако именно на 2022 и 2023 годы пришелся их рассвет — настолько стремительный и яркий, что неподготовленный пользователь может легко заблудиться в этом новом направлении.
Для выбора подходящего инструмента необходима наглядность — знать, какие сервисы существуют, чем они отличаются и какими возможностями обладают. Так проще разобраться и сложнее запутаться.
В этой статье собраны самые популярные платформы для генерации контента, работающие сразу «из коробки» — открыл, ввел, получил. Их можно классифицировать двумя способами — по контенту и по моделям.
Ошибки в приложениях неизбежны, но мы можем их смягчить и упростить отладку. Но как выбрать правильный способ обработки?
В этой статье предлагаю разобраться, как организовать работу с ошибками в Go так, чтобы они не просто сигнализировали о проблеме, но и помогали быстро её локализовать, воспроизвести и устранить. Рассмотрим инструменты и ограничения Go, обсудим подходы к обработке ошибок, а в финале сформулируем регламент, который поможет выбрать оптимальный способ работы с ошибками в разных сценариях.
Я структурировал способы обработки в зависимости от контекста — ситуации и типа программ, в которой возникает ошибка. Типы разделений — условные, в реальных задачах рекомендую опираться на требования к ошибке:
· Библиотека — узкоспециализированная программа, основной потребитель разработчик.
· Command Line Interface — консольные утилиты, где пользователем может быть кто угодно, а даже если это программист, то он не обязан понимать как CLI устроен внутри.
· Сервисы — Worker, WEB/API/RPC-сервисы и др.
