Меня зовут Ярослав Французяк. Я фронтенд-разработчик в GARPIX. В этой статье расскажу о таком инструменте, как фреймворк MediaPipe от Google. На основе готовых моделей он позволяет разработчикам внедрять сложные функции компьютерного зрения и обработки мультимедиа в веб-приложениях — распознавать лица, анализировать изображения, отслеживать движение, обрабатывать видео в реальном времени и многое другое. Мы разберём работу фреймворка на примере, погрузимся в векторную математику в трёхмерном пространстве и сложности распознавания ключевых точек лица.

Привет, Хабр! Сегодня поговорим о фронтенде, а точнее, о способах улучшения веб-приложения. В этом могут помочь JS-библиотеки для анимации. В подборке их пять, но если вы знаете и другие, причём те, что применяете в работе сами, расскажите о них в комментариях.

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

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

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

Приятного прочтения :-)

Введение

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

Привет всем, я, Надежда Дудник, главный инженер по тестированию в СБЕРе, а ещё ментор по тестированию ПО.

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

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

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

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

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

При выполнении каждого запроса API нам необходимо и важно проверить:

Привет, дамы и господа, которые кликнули на эту статью с горячим заголовком! Давайте знакомиться: меня зовут Артем Соловьев, и в данный момент я Middle iOS‑разработчик в крупной лизинговой компании, где мы с командой занимаемся разработкой и поддержкой внутренних CRM‑систем.

Все, кто так или иначе связаны с миром IT — уже работают на каких‑либо позициях или только «вкатываются» — все время задаются вопросами: «Как мне получить оффер мечты?», «Как найти свою первую работу?», «Что вообще происходит за кулисами собеседований и как это все устроено?». В этой пилотной статье я расскажу о своем личном опыте поиска работы на позицию iOS‑разработчика.

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

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

Я по фану нарисовал куклу, чтобы потом на ее основе делать разные фанарт скины с анимациями и выкладывать их во все запрещенные и нет соцсети.

Всем привет!

Меня зовут Гребенюк Гузель, я QA-руководитель группы тестирования в АЭРО. Мы занимаемся разработкой eCommerce- и data-решений для крупного бизнеса.

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

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

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

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

В рамках этих тестов мы проверяли коды ответов, время отклика, типы полей,  json схемы, требования по ограничениям для получаемых значений. Это дало хороший прирост в скорости регресса и качестве тестирования.

Я и мои коллеги всегда склоняем своих клиентов полностью автоматизировать процесс деплоя. Автоматизация помогает сократить количество конфликтов и задержек, которые возникают в процессе между "завершением" работы над программой и введением в эксплуатацию. Дэйв Фарли (Dave Farley) и Джез Хамбл (Jez Humble) заканчивают книгу "Непрерывная доставка" (Continuous Delivery) на эту тему. Она основывается на множестве идей, которые в целом связаны с непрерывной интеграцией и подталкивают к возможности быстро пустить софт в работу. Глава о сине-зеленом деплое привлекла мое внимание, потому что это один из малоиспользуемых методов, и я решил кратко его осветить.

Название ENTRYPOINT всегда меня смущало. Это название подразумевает, что каждый контейнер должен иметь определенную инструкцию ENTRYPOINT. Но после прочтения официальной документации я понял, что это не соответствует действительности.

У меня в квартире установлен аналоговый домофон Vizit, которому больше 10 лет.

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

Постараюсь ужать многолетний опыт изучения навыков в одну малюсенькую статейку. Расскажу, как на практике освоить набор навыков любого размера, включая все необходимое, чтобы получить первую работу в IT. Объясню пошагово, как создать и придерживаться очень практичного и эффективного индивидуального плана обучения, по которому я сам занимался, в результате чего из полного чайника без диплома и платных курсов за пол года смог влететь в разработку на высококонкурентном рынке с 1000+ откликов на вакансию во времена массовых увольнений сразу в топовую IT‑компанию без связей, накрутки опыта и ментора и даже успешно пройти там испыталку, ведь план обучения позволил накопить багаж полезных знаний.

Правильный план обучения — это 70% получения работы. По этому плану ты сможешь освоить программирование без покупки курсов, то есть стать программистом бесплатно. Да и любой другой скилл или профессию тоже сможешь быстро и бесплатно получить, что сейчас особенно актуально с этим ИИ. Гарантирую, что по этому плану за короткий срок ты добьёшься больших результатов, а это автоматически значит, что потребуется тяжелая работа с твоей стороны. В конце статьи также будет секретный ингредиент, о котором никто не говорит и который может сделать процесс твоего обучения чуть ли не вдвое более эффективным. Ещё я приведу пример реального плана обучения и объясню, почему каждый его пункт настолько логичен, что ты просто не сможешь ему не придерживаться. Цель плана — получить максимальный результат при минимальных затратах времени и сил.

В 2018-м я собрал 1 тонну клубники, и заработал на этом 150 000 ₽, это неприятно за 5 мес. тяжелого труда агробизнесмена. Поэтому в 2019-м я решил, что если заниматься сельским хозяйством, то заниматься по-взрослому. По моим расчетам, с 18 000 саженцев клубники можно заработать 11 млн ₽ за 3 года. В статье я расскажу, что из этого вышло.

Чем проще и понятнее описаны требования — тем меньше багов будет в функционале. Потому что не будет разных прочтений, додумок и прочего. А еще в простыне текста легко потеряться и что-то просто забыть реализовать.

Как же сделать ТЗ понятнее? Можно улучшить текст — вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...

Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое =)

А ещё техники, помогающие лучше понять требования, относятся к техникам тест-дизайна. Значит, о них стоит знать! В одну статью всё запихивать не стала и сделала отдельные:

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

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