Системы сборки *

Привет, Хабр! Я участвую в разработке крупного Web приложения и мы с коллегами на этапе проработки и планирования архитектуры пришли к выводу о необходимости выносить всю логику приложения в отдельный поток Web Worker, т.к. предполагается большое число фоновых операций и вычислений. К чему это привело? Сложности? Пути их решения? Обо всем попорядку.

Недавно передо мной встала задача — есть 250 тестов, каждый из которых занимает от 5 до 30 минут, а иногда и часы. Надо запустить их в параллель на одной машине, но не больше 16 одновременно. Ограничение связано с некоторым лимитированным ресурсом, а также количеством ядер CPU. Реальное число одновременно запущенных задач нужно вычислять динамически, то есть пойти простым путем и зарегистрировать имя или лэйбл ресурса заранее с помощью плагина Lockable Resource не получится.

По случаю выхода версии 0.11.0 языка Zig я решил написать ещё одну статью о языке Zig. В этот раз речь пойдет о системе сборки языка. А точнее, как пользоваться кодом написанным на языке C в проекте на языке Zig, с небольшими ответвлениями в стороны для описания некоторых возможностей системы сборки. Тем более, что она претерпела несколько изменений, о чём я так же коротко упомяну. Эксперименты проводились мной на Windows 11. Стоит сразу упомянуть, что указанные в статье команды будут работать и на других операционных системах. Это одна из особенностей языка Zig. Но пример кода линковки системных библиотек для сборки библиотеки raylib будет платформозависимый, так как для разных платформ набор библиотек отличается. Если интересно, то прошу...

Сегодня мы с радостью объявляем о релизе GitLab 16.2 c совершенно новым редактором текста, палитрой команд, поддержкой подписей без ключей с Cosign, новым уровнем настроек для панели аналитики разработки и многими другими фичами!

Это 2-ая часть статьи "Как задеплоить монолитный pet проект на Java с 0 и не сойти с ума". Первую часть вы можете найти по ссылке.

В первой части мы успешно добавили свои наработки в репозиторий GitHub, в этой части мы рассмотрим что такое GitHub Actions и как с помощью них добавить свой образ docker контейнера с приложением в хранилище DockerHub.

Хочу поделиться своим видением сборки для быстрого старта разработки на React.

Помогает быстро запуститься, когда нужно «на скорую» войти в разработку.

Что‑то я подглядел здесь же, на Хабре, к чему‑то пришёл сам, ну и «ангажировал» немного на просторах «необъятного».

Что «под капотом»

Webpack 5
React v.18
Redux (Redux Toolkit)
Typescript
Css modules
Jest
VS Code

Привет! Я Даша, Android-разработчик в команде онлайн кинотеатра PREMIER.

В прошлой статье я рассказывала, как мы настроили сборку проекта с помощью Gitlab CI. Дальше нужно отправить приложение в маркеты для внутреннего тестирования, а затем конечным пользователям.

Сегодня разберемся, как автоматически опубликовать приложение в Google Play, Huawei App Gallery и Firebase на примере нашего приложения онлайн-кинотеатра PREMIER. Также расскажу, как мы отправляем сборку в Nexus.

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

Сложность написания плагина сравнима со сложностью написания сценария для Gulp или GitHub Actions. Для примера напишем плагин, который будет вставлять фрагменты кода в файл index.html. В зависимости от проекта в данный файл необходимо помещать код Google Analytics, метатэги Open Graph и Twitter, подключение Service worker-a, виджета чата поддержки, сплэш скрин и многое другое. В результате index.html становится очень большим и ориентироваться в нем и блоках кода довольно сложно.

Наш плагин позволить держать фрагменты кода в отдельных файлах, а при сборке все будет помещаться в index.html. Причем это будет происходить не только при непосредственно сборке ( npm build ), но и при запуске Vite dev сервера с поддержкой HRM (Hot Module Replacement).

Сегодня мы с радостью объявляем о новом релизе GitLab 16.1 с полностью изменившимся опытом навигации, GitLab Dedicated в общем доступе, визуализацией ресурсов Kubernetes, аутентификацией через сервисные аккаунты и многими другими фичами!

CI/CD-пайплайны автоматизируют процессы создания, тестирования и развертывания программного обеспечения, позволяя командам быстро и надежно выпускать обновления. В этой статье рассмотрим, как создать пайплайн с помощью AWS, как использовать CodeBuild для запуска при размещении кода в ветке. Также разберем, как запускать тесты, затем собирать и размещать образ Docker в ECR, и сохранять артефакты кода в S3, после чего можно использовать функцию Lambda для запуска CodeDeploy, которая развернет код на группе EC2-инстансов.

Приветствую всех читателей, что забрели на эту страницу. Вероятно, вы тоже как и я, не нашли должной информации по этой теме, поэтому наслаждайтесь, ведь тут будет вся нужная информация для корректной работы runtime импорта!

По мере того, как ваше приложение растёт и развивается, растут и затраты времени на его тестирование и сборку, достигая нескольких минут при пересборке в dev-режиме и, возможно, десятков минут при «холодной» production-сборке. Что, конечно, совершенно неприемлемо. И если поначалу увеличение временных затрат может казаться незначительным, то впоследствии это непременно ведёт к ухудшению процесса разработки и может негативно повлиять на скорость выкатки важных релизов или хотфиксов. Таким образом, в какой-то момент вопрос оптимизации и ускорения сборки приложения может стать критически важным для разработчика.

Всем привет, меня зовут Фёдор — я руководитель фронтенд-разработки на проекте Smartbot Pro в компании KTS. 

Наш проект — конструктор ботов для социальных сетей, в котором алгоритм бота представлен в виде визуального графа. Конструктор включает большое количество интеграций. Недавно на проекте остро встал вопрос оптимизации наших ci/cd пайплайнов, потому что релиз мог занимать от 4 до 18 минут.

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

Как вы знаете, формат изображений WebP в большинстве случаев имеет меньший вес, по сравнению со своими братьями: png и jpeg. Поэтому использовать его в своих приложениях - это хорошая практика.

Бывает ситуация, когда надо чтобы прошивка или любой другой артефакт сам сказал в каком состоянии был GIT репозиторий с кодовой базой, когда эту прошивку собирали. Надо как-то добавить в text/rodata сегмент памяти такие метаданные как "из какой ветки собрали прошивку", "какой была контрольная сумма последнего коммита".

Данная подсказка может существенно помочь при сопровождении ПО.

В тексте представлен скрипт, который делает эту работу.

Как вы думаете сколько строк кода надо для подписи прошивки?

❯ Чем интересен Nix

• Указывать в коде зависимости от проектов, не написанных на rust;
• Автоматически добавлять в путь все инструменты/зависимости ваших проектов при помощи direnv;
• С лёгкостью собирать тонкие контейнеры Docker.

В этом тексте представлена инструкция настройки ToolChain(а) для работы с микроконтроллером CC26x2 при помощи языка программирования С и компилятора GCC. Сборка осуществляется прямо из Makefile(ов).

Тут же представлена инструкция для настройки пошаговой отладки в консоли Windows.

В принципе, если вы собираете из Makefile, то вам всё равно какой там микроконтроллер и какого он вендора. Для добавления поддержки очередного MCU достаточно написать всего один *.ld и один *.mk файлик.

Во многом по этому сборка из Makefile является предпочтительнее, когда в организации много разнообразного оборудования на разных МК (или просто много сборок) и одна переносимая кодовая база на всё.

Разработка программного обеспечения связана не только с написанием кода, но и с его отладкой. И отладка должна быть по возможности комфортной.

С некоторыми ошибками мы пишем в лог стек вызовов. Используемая нами IDE (Idea, GoLand) позволяет по скопированному стеку вызовов получить комфортную навигацию по файлам (Analyze external stack traces). К сожалению, эта возможность хорошо работает только в том случае, если бинарый файл собран на том же хосте, на котором запущена IDE.

Этот пост посвящён тому, как мы пытались подружить формат стека вызовов и IDE.

«Наши инструменты сборки веб-приложений от 10 до 100 раз медленнее, чем они могут быть» – считает Эван Уоллес, сооснователь Figma. По его мнению, прямо сейчас, а не в будущем, можно собирать фронтенд в 10–100 раз быстрее. Рассмотрим, как этого добиться, и причём тут webpack.

Поможет нам в этом Евгений Кувшинов, фронтендер и тренер по инженерным практикам с двенадцатилетним опытом в продуктовой разработке. Он расскажет про свой опыт работы с webpack и поможет поставить запятую в заголовке статьи.