GitHub *

Статья будет полезна разработчикам встраиваемых систем, которые хотят автоматизировать процесс тестирования своих проектов. Отдельный блок посвещен отладке gdb в эмуляторе QEMU. В качестве примера используется библиотека логирования (GitHub, Habr)

Привет, меня зовут Ася Исакова, и я организационный психолог. Возможно, единственный в мире организационный психолог, который умеет создавать пулл-реквесты на GitHub. Как так вышло? Дело в том, что я 2+ года занималась тем, что выстраивала нормальную работу на удаленке без 8 звонков в день для одной распределенной команды, используя GitHub как основной инструмент. Подробности о том, что это, как это было, что получилось и вдруг вам тоже надо, под катом.

Multi-Agent Orchestrator — гибкая и мощная платформа для управления несколькими AI-агентами и обработки сложных разговоров.

GitHub Repo - https://github.com/awslabs/multi-agent-orchestrator

Как специалист по контролю качества с опытом работы на Java и Selenium, я с гордостью расскажу о Robot Framework.

TL;DR: Узнайте, как создать приложение для обратного поиска изображений с использованием Manticore Search. В статье рассказывается об истории технологии, её устройстве и практических подходах к системам поиска изображений.

Введение

Обратный поиск изображений изменил способ поиска цифрового контента, позволяя искать с помощью изображений, а не текста. Эта технология широко используется: от помощи покупателям в поиске товаров до проверки дизайнов у дизайнеров. Она стала важным инструментом во многих цифровых платформах.

Попробуйте демо на image.manticoresearch.com или посмотрите реализацию на GitHub.

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

Большое количество специалистов в области IT используют переводчики текста в своей работе, и я тому не исключение. Достаточно часто в вакансиях Системного администратора можно встретить требуемый навык - "чтение технической документации на английском языке", но, не всегда такая документация может быть очевидной в полной мере, даже имея базовый уровень английского языка, и как мне кажется, тут нечему стесняется. Для перевода текста чаще всего используется браузер, а также десктопные приложения, я же расскажу про альтернативу таким решениям, для перевода текста прямо в консоли Linux или Windows.

Как и многие, я храню свой код на GitHub. Пару лет назад я сделал простой пайплайн для сборки, анализа и тестирования моих веб‑приложений и сервисов. Он выполнял свою задачу, и так как это был мой первый опыт по настройке пайплайна CI/CD на GitHub, он сводился к одному шагу.

build (and deploy)

Со временем я стал замечать, что я стараюсь избегать вносить изменения в код. Будучи счастливым обладателем ADHD, я часто замечаю за собой сложность в решении задач с большим количеством препятствий и одним из них стало то, что выполнение пайплайна занимало больше 5 минут. Я коммитил изменения и шел делать кофе, пока пайплайн тестировал и деплоил код. И не всегда возвращался, отвлекаясь на другие вещи.

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

Из Википедии: фактор автобуса (англ. bus factor, либо truck factor) проекта — это мера сосредоточения информации среди отдельных членов проекта; фактор показывает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

Мотивация

Во всех компаниях, где я работал (в строительстве и разработке ПО), в тот или иной момент времени возникал вопрос «фактора автобуса» в управлении разработкой проектов.

Инженеру-строителю вычислить его было крайне сложно, потому что наша отчётная документация была сильно распределена между сотрудниками и существовал дефицит документации. Единственный раз, когда это стало очевидно, случился после увольнения одного из сотрудников — спустя полгода возник срочный запрос RFI (запрос информации) по чьему-то пакету расчётов (хотя официальный пакет должен быть подписан инженером-проектировщиком, а не инженером, непосредственно отвечающим за расчёты). После таких инцидентов нам обещали улучшить документацию, но это неизбежно отходило на второй план, когда все участники группы переходили на новые проекты даже без итогового совещания. Я был свидетелем того, как в долговременных проектах инженерный состав менялся на 100%, поэтому это ужасный антипаттерн.

В разработке ПО можно провести множество параллелей, но по природе нашей работы поставка выпущенного кода — это единственный способ измерения фактора автобуса. По крайней мере, именно её изучали многие исследователи, в том числе и в научной статье, имеющей большое количество цитирований (156, согласно Google Scholar!) с момента её публикации в 2016 году (препринт выпустили в 2015 году). Ша отправил мне статью, а после того, как мы обнаружили её исходные данные и исходный код, это стало идеальным проектом на выходные, который бы позволил, как минимум, получить представление об интересных метриках open source.

Разработка программного обеспечения становится все более коллективным процессом. В этом контексте все бóльшую значимость обретают открытые проекты, что в совокупности задает тренд на сотрудничество и совместное использование знаний.

Open Source — это не просто способ создания программного обеспечения, а целая культура инноваций, сотрудничества и обмена знаниями. Каждый, кто хочет внести свой вклад в эту динамичную среду, может сделать это вне зависимости от своего опыта или уровня технических навыков.

Как мобильный разработчик TAGES, я не раз сталкивался с миром Open Source, активно поддерживая и участвуя в различных проектах. Открытые инициативы становятся все более важными в современном процессе разработки программного обеспечения, создавая культуру инноваций, сотрудничества и обмена знаниями.

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

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

Буквально месяц назад, мы с моим коллегой участвовали в HAKATON. Наша команда взялась за интересную задачу от компании МТС: на основе тысяч опросов, найти усредненный синоним к определенной категории ответов и визуализировать это в виде графика, либо облака слов.

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

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

Совсем недавно разработчики, применяющие сканер образов Trivy, столкнулись с ошибкой TOOMANYREQUESTS. Она произошла из-за достижения максимального количества пользователей инструмента и предельной скорости по загрузкам из Container Registry (CR) ghcr.io.

Меня зовут Алиса Кириченко, я занимаюсь разработкой контейнерной платформы «Штурвал». Мы вовсю используем Trivy, но совсем не хотим зависеть от доступности сторонних сервисов. Иначе заказчики не поймут. Поэтому базы у нас свои, и обновляются они каждую ночь.

Если лень дальше читать, то вот, берите:

Trivy DB: public.shturval.tech/trivy-db

Trivy Java DB: public.shturval.tech/trivy-java-db

Детали — под катом.

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

Обыкновенный вторник второй половины октября, через час запланирован релиз в продакшн, ничего не предвещало, а ожидаемые заказчиком фичи уже протестированы вдоль и поперёк, ожидая своего часа.

В какой-то момент от коллег поступает информация о том, что официальная библиотека elasticsearch-php в момент сборки через composer install перестала устанавливаться.

Дисклеймер: если ты продвинутый разработчик с Х годами опыта, пожалуйста, закрой эту статью. Здесь ты не найдешь абсолютно ничего полезного для себя.

Итак, небольшое вступление. Когда мне впервые пришлось делать коммит на GitHub, я помню, что перерыла кучу источников, и везде все было как-то не так, как в итоге сделала я.

В этой статье я расскажу о том, как сделать первый коммит на GitHub, и как делать последующие. Только мой опыт и сочетание консоли и фич IntelliJ Idea + у меня mac os, поэтому здесь именно про него (важно для установки).

Погнали.

Автоматизация деплоя React-приложения на VPS с Jenkins и Nginx: настройка вебхуков GitHub и триггеров для запуска деплоя при каждом изменении в коде.

Привет, уважаемый читатель!

В рамках данной статьи мы узнаем:

* Какие API уязвимости есть в VAmPI?

* Из-за чего эти уязвимости существуют и эксплуатируются?

* Какие есть способы защитить веб-приложение?

* Какой есть дополнительный материал для самостоятельного изучения?

Ссылка на GitHub VAmPI: https://github.com/erev0s/VAmPI

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

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

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