Сначала я просто хотел написать комментарий к моему предыдущему тексту, в котором я рассказал, как за день на расте мне удалось написать новую, неспецифицированную, глючную и медленную реализацию половины OTP.
Но пока я тот комментарий писал, внезапно оказалось, что, несмотря на общее положительное впечатление от раста, претензий к нему у меня набралось на целый текст. Ну что ж, заточите свои минусаторы, ниже —
Привет, Хабр! Меня все так же зовут Матвей. В прошлой статье я собрал простое Android‑приложение из сайта с помощью конструктора. Мы убедились, что для лендинга или каталога зачастую достаточно одной WebView‑обертки. Во второй части возьмем тот же небольшой веб‑сервис, создадим под него URL и соберем полноценное приложение с пушами и доступом к системным функциям.
Разбираться в Swift, Kotlin или Flutter по‑прежнему не придется: вместо этого используем конструктор. На примере посмотрим, как сайт превращается в приложение, какие настройки важны, чтобы оно адекватно работало и выглядело хорошо на Android и iOS. И как довести этот результат до состояния, когда не стыдно использовать. Детали внутри.
Пока программа остается замкнутой системой, в ней нет истинной случайности. Она появляется как только программа становится открытой и начинает получать данные извне. При этом источник данных должен выступать для программы непредсказуемой и неподдающейся контролю внешней системой, то есть быть черным ящиком.
С другой стороны, в самой программе может быть псевдослучайность, когда каждое следующее значение является вычисляемым и предсказуемым, но сторонний наблюдатель, тот, кто получает данные из программы, воспринимает их случайными, потому что не знает внутреннюю логику ее работы.
В таком случае на уровне системы, объединяющей все остальные и не получающей внешние данные, случайности быть не может.
Serverless — это не отсутствие серверов. Это состояние, когда вы перестаете о них думать. Вы не патчите ядра Linux, не настраиваете Nginx и не мониторите свободное место на дисках. Вы пишете функцию, загружаете код в облако, и платформа сама решает, где и как это запустить.
Звучит идеально. Но на практике Serverless — это сделка. Вы отдаете контроль над инфраструктурой в обмен на удобство. И часто цена этой свободы — новые, совершенно неочевидные архитектурные проблемы.
Привет, Хабр! Я бэкенд-разработчик в спортивном медиа Спортс”. В этой статье расскажу о glinq – LINQ-подобном API для работы с коллекциями в Go. После появления дженериков в Go 1.18 стало возможным реализовать type-safe функциональные операции без рефлексии и дорогостоящих приведений типов.
Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся со всем сообществом.
Этот месяц в мире Java выдался насыщенным. В JDK 26 готовят превью Lazy Constants и Structured Concurrency, собираются убрать режим строк только UTF‑16, а стандартный HttpClient получает более гибкую поддержку TLS.
Главное событие — GA‑релизы Spring Framework 7 и Spring Boot 4: модульная автоконфигурация, новый HTTP‑клиент, версионирование REST API, переход на Jackson 3 и множество других улучшений.
Из практики: разбор пагинации в Spring Data JPA, подводные камни MapStruct и заметка о балансе между чтением и написанием кода. Приятного чтения!
Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.
Возможно, причиной восторга стала мысль о том, что я смогу снова разнести его примеры кода, как сделал в своей первой статье.
Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.
А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.
Несмотря на весь свой цинизм и любовь постебаться, я искренне уважаю тех, кто может признать свои ошибки и взглянуть на вещи по-новому. Я испытываю глубокую радость, когда мой посыл доходит до умов людей и меняет их взгляд на вопросы, в которых они грубо заблуждаются (хотя порой мне кажется, что мой напористый подход может, наоборот, этому мешать).
Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!
Невероятно!
Но я забегаю вперёд…
Мы встроили SourceCraft во все кодовые сниппеты в публикациях на Хабре. Он объяснит, что делает код. Как это работает, кому нужно и как использовать — читайте под катом.
Разработка софта всегда была поиском баланса между разными аспектами, вроде скорости разработки (как быстро ты выкатываешь новые фичи), производительности приложения, потребления им памяти, красотой интерфейса и отполированностью логики.
В большинстве случаев скорость разработки важнее, чем производительность и потребление памяти.
ORM — это как раз инструмент, экономящий время разработки. Но за счёт чего?
Недавно команда TypeScript представила TypeScript 7 — новую версию, переписанную на Go. Главные обещания: до 10× ускорения компиляции и до 8× более быстрый старт анализа проекта. Но самое интересное спрятано чуть глубже: вместе с TS-Go появляется полноценный LSP-сервер, встроенный прямо в компилятор.
Для многих IDE это шаг вперёд.
Для нас, команды OpenIDE, — это ещё и освобождение от ограничений, с которыми TypeScript приходилось поддерживать долгие годы.
В статье делимся контекстом, собственными экспериментами и наблюдениями — что уже работает, что нет и как новый сервер ощущается в реальной IDE.
Команда Go for Devs подготовила перевод статьи о том, почему автор почти десять лет не использует JSON в своих API и предпочитает Protobuf. Он объясняет, как строгая типизация, компактная бинарная сериализация и генерация кода дают разработчикам больше надёжности и скорости.
Команда Python for Devs подготовила перевод статьи о том, почему Python — несмотря на свою популярность — не всегда идеален для Data Science. Автор показывает, как отсутствие нестандартной оценки выражений усложняет анализ данных, и сравнивает Python с R, где такие задачи решаются куда элегантнее.
Мы запустили практику публичных разборов проектов чтобы наглядно продемонстрировать важность внешнего вида и удобной структуры вашего репозитория, подчеркивая эти факторы они облегчат вход в проект новым пользователям и контрибьюторам.
Не стесняйтесь, и присылайте свой проект на конструктивный разбор!
Привет, Хабр!
Сегодня рассмотрим тему неопределённости в моделях. Классические ML-модели детерминированы: на вход получили – на выход выдали одно число или метку. Но жизнь полна неопределённости, и игнорировать её плохая идея. Представьте, у вас мало данных, модель предсказывает конверсию 15%. Но насколько она уверена? Может, разброс от 5% до 30%. Обычная модель этого не скажет, а вот вероятностная модель скажет.
В этой статье в коротком формате разберём, как с помощью байесовского подхода и фреймворка Pyro моделировать такую неопределённость на примере A/B-теста конверсии и заставить модель честно признавать свою неуверенность.
Иногда маленькие вещи случаются не потому, что ты их планировал, а потому что... ну а кто ещё это сделает? Я пару месяцев подряд писал небольшие ML-прототипы на PHP (да, знаю, иногда судьба заносит в странные места), и каждый раз сталкивался с одним и тем же раздражением: массивы печатаются так, будто пытаются скрыть правду.
Я смотрю на этот разъехавшийся print_r(), и думаю: а что, если я просто хочу увидеть аккуратную табличку? А если я хочу форматирование как у Python? А если я хочу имитировать пайторчевский tensor([...])?
Спойлер: я таки написал маленький хелпер. И чем больше я его использовал, тем больше понимал - возможно, он не только про удобство, но и про какое-то внутреннее право на ясность.
Этот хелпер - не "фреймворк", не "революция", не "супер-мегапринтер", просто очень маленькая утилитка, которая делает одну вещь и делает её хорошо.
Всем привет.
В данной статье я хочу поделиться двумя новостями. Во первых открытый российский Embox выложил в открытый доступ базовые драйвера для российского процессора семейства KOMDIV64, и данный российский процессор стал более открытым и доступным. А во вторых вдохновившись командой Северстали, которые делают открытую АСУ-ТП, мы запустили на этом открытом российском процессоре открытую среду для МЭК 61499 (4Diac).
Всем привет! Меня зовут Герман Кравец, я больше десяти лет в IT. В МойОфис работаю руководителем группы Календаря в отделе разработки Mailion — это наша отказоустойчивая корпоративная почта для крупного бизнеса.
В этой статье расскажу, как мы с командой искали новое решение для нашего API Gateway: зачем вообще понадобилось его менять, с какими проблемами столкнулись и как проходили все этапы — от первых «что-то идёт не так» до финального рефакторинга и запуска нового Gateway в прод.
Будет немного боли, немного архитектуры и чуть-чуть магии. Если вам интересно, как решать нетривиальные задачи в продуктовой разработке, где стоит использовать готовые решения, а где всё писать вручную, или просто хочется узнать, как мы сократили простои на регрессе с 4–6 часов до пары минут, — добро пожаловать под кат!
Приветствуем, коллеги.
Расскажем вам о нашей долгожданной новинке – «Python для инженерных задач». Эту книгу написал уважаемый Евгений Ильин @jenyay, кандидат технических наук, преподаватель Московского Авиационного Института. В основу книги легли его университетские наработки, объём более чем внушительный – 672 страницы. Тем не менее, поскольку эта книга ориентирована на самую широкую аудиторию инженеров, мы решили выпустить её в серии «Самоучитель», из которой вам также может быть известен знаменитый «Компас-3D V 23» Анатолия Герасимова.
В начале двадцатых годов нейросети воспринимались скорее как любопытный эксперимент. Они могли подсказать строку кода или помочь с документацией, но оставались чем‑то дополнительным, не слишком надежным. Постепенно ситуация изменилась: сначала разработчики привыкли к автодополнению в редакторах, затем начали доверять ИИ анализ архитектуры проектов, а к 2026 году стало очевидно, что без таких инструментов работа выглядит неполной.
Сегодня нейросети встроены в привычную инфраструктуру: они живут внутри IDE, сопровождают процесс тестирования и деплоя, помогают вести документацию и даже участвуют в обсуждениях архитектурных решений. Разработчик уже не думает о том, «использовать ли ИИ», — он выбирает, какой именно помощник лучше впишется в его задачи и команду. Искусственный интеллект перестал быть экспериментом и превратился в стандарт профессии.
В нашем обзорном материале рассмотрим, какие решения стали самыми полезными, а также как они меняют саму логику взаимодействия с кодом и дают иной взгляд на работу программиста.
Мы все привыкли писать new List<int> { 1, 2, 3, 4 } или new int[] { 1, 2, 3, 4}, чтобы инициализировать коллекции какими-то значениями. Синтаксически это выглядит похоже, но поведение отличается, и вам следует быть осторожными, если вы заботитесь о производительности.
