Программирование *

Привет! Я ex. Разработчик из VK, сейчас принял оффер от Ozon'a, и за последний месяц я прошел собеседования в 4х бигтех компаниях: Ozon, Avito, Wildberries и T-Bank и везде дошел до финалов/офферов. Пообщавшись во многих группах, посвященных Go-разработке, я понял, что много умных ребят готовясь к собесам не имеют четкой системы подготовки, и из-за этого заваливают технические собесы в компании. Не претендуя на истину в последней инстанции, предлагаю свою методику подготовки к собесам, которая помогла мне и моим знакомым подготовиться к техническим собесам во все популярные ру-бигтехи.

Финансы, ритейл, соцсети, облака – везде свои тараканы, но требования схожи: чтобы летало и не падало. Балансировка нагрузки – это как фундамент для небоскреба. Криво зальешь – все рухнет. И вот тут стандартный Round Robin, при всей его простоте, часто оказывается тем самым кривым фундаментом.

Человек купил в магазине ящик елочных игрушек. На следующий день приносит его обратно:

- Ваш товар бракованный.
- Что, игрушки битые?
- Нет, целые.
- Не блестят?
- Блестят.
- Так в чем же дело?
- НЕ РАДУЮТ!

Автодополнение всегда было силой и гордостью современных IDE. Сравнивая IDEA, VSCode и Eclipse, мы смотрим — оно вообще адекватные вещи пишет в выпадающей менюшке? Знает про Spring, про Next.js, про свежие апдейты в Питоне?

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

Этот текст — адаптированный перевод статьи из блога JetBrains (я постарался сделать текст более читабельным и менее похожим на политкорректный пресс-релиз). Мы посмотрим, как обучилась модель Mellum, лежащая в основе облачного автодополнения, и что из этого вышло.

Напоминаю, основной продукт JetBrains — это их IDE, редактор кода для программистов. Модель Mellum занимается автодополнением кода в редакторе, и является одной из самых быстрых и миниатюрных в своем классе. Она способна запускаться на устройстве (не только в облаке у арабских шейхов). Чем-то похожим по смыслу можно считать Microsoft Phi.

OLMo — моделька от AI2, разработанная учёными для учёных. Если вы занимаетесь экспериментами над нейронками, это идеальный вариант: весь код и данные, необходимые для тренировки, открыто лежат на GitHub. Более того, выложены даже промежуточные чекпоинты, с очень высокой гранулярностью. Это отличает ее от якобы "открытых" нейронок, которые обычно приходят к тебе монолитным финальным бинарём.

Эта статья — короткий гайд, адаптированный с GitHub создателей нейросети и проверенный на практике.

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Жил-был в норе под землей… разработчик группы разработки защитных решений безопасной платформы. Привет! Я Максим Жуков, занимаюсь безопасностью различных аспектов KasperskyOS. Расскажу про один из них, ELF-парсер.

Эта история не про то, как мы в «Лаборатории Касперского» сделали парсер с нуля. А про то, как я отправился в долгое исследовательское путешествие в поисках способа сделать наш существующий парсер безопаснее, что узнал о разных инструментах в пути и какую неожиданную помощь получил от Темного Владыки Мелькора.

Интересно будет тем, кто работает с бинарными данными, занимается безопасностью или просто хочет сделать свой код надежнее. Особое приглашение под кат — фанатам Rust, ему уделю немало внимания. Поехали!

Статья-практикум показывает, как устроены HTTP/2, HTTP/3 (QUIC) и gRPC на самом низком уровне. Вместо толстых библиотек мы пишем минимальный учебный фреймворк «Mini-Transport» на Rust (~600 строк): реализуем кодек HTTP/2-фреймов, упрощённый gRPC-протокол и базовую обёртку над QUIC. В результате получаем рабочий echo-клиент и сервер, которые пересылают «hello ↔ world» через собственноручно собранные фреймы. Разбор сопровождается поясняющими схемами, ссылками на RFC, вариантами дальнейшего развития (HPACK, flow-control, TLS/ALPN) и готовым репозиторием для самостоятельных экспериментов. Материал рассчитан на разработчиков, желающих понять «как всё крутится под капотом» и прокачать навыки низкоуровневой сетевой работы в Rust.

Используем силу уравнений Ньютона и численных методов для моделирования динамики простых плоских мешей в реальном времени! В конце вы сможете моделировать падение ножниц ✂️ как на анимации

Привет, Хабр! Сегодня хочу поделиться своим личным опытом участия в Забайкальском хакатоне и рассказать, к чему стоит готовиться, если вы планируете принять участие в подобном мероприятии.

Что такое хакатон?

Хакатон- это соревнование для программистов, дизайнеров, аналитиков и других специалистов, в котором за ограниченное время необходимо разработать прототип или даже полноценное решение определённой задачи (кейса) .

Цель мероприятия

Главная цель фестиваля- создать условия для раскрытия потенциала одарённых школьников и студентов. Конкретные задачи включают:

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

Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается фундаментальная сложность. Как заставить кучу разрозненных компонентов работать вместе надежно? Как гарантировать, что данные, размазанные по сети, останутся корректными и доступными? Эта головная боль знакома любому, кто проектировал системы сложнее калькулятора, будь то в требовательном финтехе, динамичном e-commerce или где-либо еще.

И вот тут на помощь (или, скорее, для обозначения поля боя) приходят три понятия: ACID, BASE и теорема CAP. Может показаться, что это сухая теория, но игнорировать их – все равно что выходить в море без компаса и карты. Эти концепции описывают фундаментальные компромиссы, с которыми приходится иметь дело каждому архитектору. Понимание их – не гарантия успеха, но его необходимое условие. Давайте погрузимся в их суть и посмотрим, как они влияют на реальные архитектурные решения.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86.

На первый взгляд, это абсурд В сущности, так и есть. Однако есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода. Так и задумано, что писать код с очень высоким показателем IPC непросто. Следовательно, челлендж «Напиши медленный код» оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

Это происходит абсолютно со всеми IT-направлениями для начинающих.

Вы откликаетесь на вакансию на любом популярном ресурсе по поиску работы, например hh.ru.

Мошенники создают впечатление заинтересованности: дают тестовые задания, расспрашивают о вашем опыте и вообще делают всё так, как будто это обычный работодатель, который обратил на вас внимание.

Вы успешно проходите отбор, и кажется, ваша мечта сбылась, но...

Demo | GitHub

Особенности Fast Data Grid:
— Невероятно быстрый
— Многопоточный
— Всего 523 строчки кода
— Нет зависимостей
— Vanilla JavaScript

Попробуйте скролл и поиск по 1 000 000 строк — Fast Data Grid.

В статье расскажу про работу с потоками.

Весна в самом разгаре, а вместе с ней — обновления, гайды, инсайды и бум активности в экосистеме Dart и Flutter. В этом выпуске вы найдёте мощные инструменты для DevTools, свежие идеи для архитектуры, backend-направление на Dart и многое другое.

Привет, Хабр! Меня зовут Андрей Гетманов, я работаю ML-инженером в Исследовательском центре “Сильный ИИ в промышленности” в ИТМО, а кроме того являюсь энтузиастом open source. В этой статье хочу рассказать о нашей новой разработке ― ИИ-инструменте, который помогает репозиторию стать лучшей версией себя.

Разнообразных «улучшателей» много, но все они фокусируются преимущественно на качестве самого кода. Мы же смотрим шире ― на репозиторий в целом, насколько он понятен стороннему наблюдателю. Инструмент нацелен на наших коллег от науки ― например, биологов и химиков ― которые не обладают опытом коммерческой разработки и соответствующего оформления кода. Он поможет в несколько кликов сделать репозиторий более читаемым и воспроизводимым.

Привет, Хабр! Мы — Настя, Эвелина и Миша — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные новости и собственные комментарии. Мотивацию мы черпаем из желания развиваться и делиться полученными знаниями. 

Приветствуем любую обратную связь! (づ ◕‿◕ )づ