С момента своего появления в 2017 году в публикации Attention is All You Need трансформеры стали доминирующим подходом в обработке естественного языка. В 2021 году в статье An Image is Worth 16x16 Words трансформеры были успешно адаптированы для задач компьютерного зрения. С тех пор для компьютерного зрения было предложено множество архитектур на основе трансформеров.

В этой статье мы рассмотрим трансформер зрения (Vision Transformer, ViT) в том виде, в котором он был представлен во второй статье. Она включает в себя открытый код ViT, а также концептуальные объяснения компонентов. Реализация ViT, рассмотренная в статье, выполнена с использованием пакета PyTorch.

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

Конечно, сейчас уже есть инструменты на базе искусственного интеллекта, такие как GitHub Copilot, ChatGPT и Claude, которые пытаются облегчить нам жизнь. Но давайте будем честны — они также заставляют нас желать большего.

Вам когда-нибудь хотелось, когда вы активно погружались в сложный проект, чтобы ваш AI-помощник видел всю картину в целом? Например, понимал общую архитектуру, ваш стиль кодирования и специфические особенности проекта?

Вот тут-то и приходит на помощь Cursor.

Большинство программистов отлично разбираются в работе процессоров и последовательном программировании, поскольку с самого начала пишут код для CPU. Однако многие из них меньше знают о том, как устроены графические процессоры (GPU) и в чем заключается их уникальность. За последнее десятилетие GPU стали чрезвычайно важны благодаря широкому применению в глубоком обучении, и сегодня каждому разработчику необходимо обладать базовыми знаниями о том, как они работают. Цель этой статьи — дать вам это понимание. 

Разработка через тестирование (TDD) — это отличный метод, который позволяет быстро получать обратную связь по идеям дизайна и реализации, а также быстрее прийти к работающему решению.

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

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

Продолжение первой части цикла. В первой части мы разобрались в причинах, по которым загрузка данных в блоке init{} может помешать прогрессу; изучили наиболее рациональные методы организации пользовательского интерфейса и логики приложения с помощью ViewModels. Также мы обсудили простые решения и важные тактики, позволяющие избежать часто встречающихся подводных камней.

В этой части мы продолжим фокусироваться на важных принципах разработки и оптимизации ViewModel в Android, направленных на улучшение архитектуры приложения и повышение его производительности. Рассмотрим подробнее рекомендации, касающиеся раскрытия изменяемых состояний, использования update{} при использовании MutableStateFlows и «ленивого» внедрения зависимостей в конструктор.

CocoaPods — это менеджер зависимостей для разработки под iOS и macOS, который упрощает процесс включения внешних библиотек в проект. С помощью CocoaPods можно быстро добавлять и управлять сторонними библиотеками и фреймворками, не беспокоясь о сложностях, которые неизбежно возникают при их интеграции вручную. В этой статье предлагаем ознакомиться с пошаговым руководством по началу работы с CocoaPods на Mac, включая установку и обновление, создание Podfile, а также добавление и управление зависимостями с помощью CocoaPods. Руководство довольно детальное и будет полезно для новичков.

Сто лет назад экономисты и философы предполагали, что к 2000 году в промышленно развитых странах продолжительность рабочего дня будет составлять всего 4 часа. И, хотя мы прошли долгий путь от длинного 12-14-часового рабочего дня в первой половинк XIX века, мы всё ещё даже не приблизились к этому прогнозу.

Более того, мне кажется, что большинство людей чувствуют себя так, будто они работают больше, чем когда-либо.

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

Правда в том, что мы можем работать меньше часов. Просто большинство компаний предпочитают этого не делать.

В этой статье на примере опыта компании Planio рассмотрим преимущества и особенности перехода на четырёхдневную рабочую неделю.

Когда приложения начинают расти в размере и усложняться, становится всё труднее решать проблемы производительности с помощью простых методов. Проблемы производительности, как и ваше приложение, становятся всё более сложными — а это означает, что появляется потребность воспользоваться более сложными инструментами для профилирования и проверки фиксов.

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

С некоторых пор я предпочитаю использовать фейки вместо стабов и моков, поскольку использование фейковых объектов вместо других тестовых дублёров делает тестовые наборы более надёжными. Я написал кодовую базу для своей книги Code That Fits in Your Head полностью с использованием фейков и тестового шпиона, и мне редко приходилось исправлять неработающие тесты. Никаких Moq, FakeItEasy, NSubstitute или Rhino Mocks, только написанные вручную тестовые дублёры.

Недавно я понял, что проблема с моками и стабами заключается в том, что они нарушают инкапсуляцию.

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

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

Деминг разработал 14 идей или принципов управления, позволяющих заметно повысить эффективность любой организации. Впервые эти принципы были представлены широкой публике в его книге «Выход из кризиса» (1982).

Реподжекинг или захват репозитория / перехват контроля над репозиторием — это особый вид атак на цепочки поставок. В этой статье поговорим о том, что это такое, каков риск и как можно себя обезопасить.

Этот тип атаки привлёк мое внимание из-за своего потенциального влияния на программное обеспечение с открытым исходным кодом. В этой статье я объясню, что такое захват репозитория и что можно сделать, чтобы оставаться в безопасности. Говоря вкратце: если вы получаете все свои программные зависимости из менеджера пакетов — например, npm или PyPI, то эта атака не может на вас повлиять. Если вы берёте зависимости напрямую с GitHub, нужно быть более осторожными, но есть простое решение — заблокировать определённый ID коммита. Я поясню, как это сделать, в нескольких наиболее распространённых сценариях.

Проверка кода (Code Scanning) автоматически обнаруживает ReDoS-уязвимости, но исправить их бывает не всегда просто. В этой статье описана 4-х этапная стратегия исправления багов ReDoS.

Я уже писал историю о том, как создал и развил инфраструктуру, которую Amazon использует для проведения нагрузочного тестирования и тестирования производительности (TPSGenerator). Но я ещё не писал о том, как я её масштабировал.

Первая версия была довольно убогой и предназначалась только для одного хоста. Я запускал её как инструмент командной строки, указывал, сколько тысяч транзакций (“TPS”) в секунду мне нужно — и TPSGenerator порождал потенциально тысячи потоков, радостно потребляя все аппаратные ресурсы, которыми вы были готовы пожертвовать. В тщетной попытке избежать проблем с распределёнными системами я профилировал каждую строчку кода и оптимизировал её до последней степени. На обычной машине он мог генерировать несколько сотен тысяч TPS, что было достаточно для многих сервисов.

Но приближался день больших распродаж «Киберпонедельник» — в этот день совершалось самое большое количество покупок в году. По мере приближения даты всё больше команд стали спрашивать меня, как генерировать большую пропускную способность, чем та, на которую способна одна машина — чтобы убедиться, что их сервисы справятся с пиком.