Привет, Хабр! Меня зовут Максим. Я занимаюсь QA около двух лет, хотя тестированием и проверкой функциональности немного дольше. Работаю как с веб-продуктами, так и standalone-приложениями. Во время аудитов и при тестировании проектов мы периодически сталкиваемся с использованием защищенных лицензией продуктами, например, библиотеками.  И хотя большинство разработчиков знакомы с лицензиями, об авторском праве и правах правообладателя нередко забывают. Если не соблюдать «технику безопасности», могут возникнуть серьезные проблемы.

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

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

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

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

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

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

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

Привет! Меня зовут Наталья, в QA я с 2010 года. За это время была тестировщиком, QA, QA Lead, спикером на курсах по тестированию, ментором. С 2018 года возглавляю группу менторов в направлении QA компании SimbirSoft. Мы с командой развиваем внутреннюю программу обучения для новых сотрудников (Примечание. Ниже по тексту мы их иногда будем называть менти). В статье расскажем, какие подходы оказались эффективными у нас – возможно, они будут полезны и вам. 

Наш опыт учитывает особенности заказной разработки: нужны специалисты, готовые влиться в самые разные проекты – от банков до промышленного ПО, с командами от 3 до 100+ человек. В статье рассмотрим, что нужно знать менторам в QA, как составить программу обучения, выстроить непрерывный процесс передачи знаний и погружения в проект. Также наши коллеги поделятся своими лайфхаками.

Мы часто слышим в новостях фразы «Хакеры атаковали», «Хакеры взломали», «Хакеры украли» и подобные. Как сообщают legaljobs, хакеры проводят 1 атаку в вебе каждые 32 секунды. По прогнозам cybercrime magazine, ущерб от киберпреступлений к 2025 году составит $10,5 трлн против $3 трлн в 2015 году. Но почему у них получается произвести атаку, как это происходит и кто же они такие, “эти хацкеры”?

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

Статья предназначена как frontend-разработчикам, которые хотят познакомиться с основными видами уязвимостей на клиенте и методами защиты от них, владельцам продуктов, которые заботятся о безопасности своих пользователей, так и тем, кто искал повод «никогда больше не быть онлайн».

Одна из проблем использования языков объектно-ориентированного программирования (ООП) и баз данных в сложности их согласования между собой. Знание языка структурированных запросов (SQL) и умение писать запросы позволяют взаимодействовать с БД напрямую. Но использование «чистого» SQL может занять довольно много времени, предъявляя повышенные требования к навыкам специалиста.

Облегчить рабочий процесс может объектно-реляционное отображение (ORM). Сторонники этой технологии заявляют, что она повышает производительность, улучшает архитектуру приложений, повторно использует код и поддерживает приложение с течением времени. По мнению критиков, отрицательным аспектом ORM является производительность.

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

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

Поговорим про тестирование моделей процессов Camunda, приведем примеры кода, конфигураций для запуска процессов в тестовой среде, а также поделимся best practice и некоторыми библиотеками, которые значительно облегчают тестирование процессов. Основная задача данного туториала – сэкономить время и упростить задачу командам разработчиков, которые создают приложения на SpringBoot и Camunda, а также тем, кто хочет начать покрывать модели процессов автотестами.

Привет! В прошлой статье мы рассказывали о 7 из 14 кейсов, с которыми столкнулись только за последний год, работая в саппорте на зарубежном проекте. Напомним, уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей и обеспечивает целый ряд шагов бизнес-процесса. Предысторию проекта и то, как работа в саппорте помогает развивать IT-продукт и повышать квалификацию, описали здесь. 

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

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

Привет! Недавно мы разработали для российского банка и запустили сервис, который помогает пользователям при получении финансовых услуг. Как и всегда в финтехе, сервис должен был отвечать требованиям безопасности, отказоустойчивости и надежности. А для его внедрения нужно было решить еще одну интересную задачу – разобраться в бизнес-процессах банка и улучшить их автоматизацию, используя движок Camunda BPM. 

Изучая задачу, мы выяснили, что материалов об автоматизации бизнес-процессов в Camunda немного, особенно на русском языке. Поделимся своим опытом реализации проекта на Camunda, Java и Spring Boot.

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

Продолжаем делиться опытом нашего коллеги Алексея, который после 7 лет программирования на зарубежном проекте неожиданно для себя возглавил службу поддержки третьей линии. В этой статье расскажем про первые семь кейсов, которые были найдены и устранены только за последний год.

Материал может быть полезен разработчикам, аналитикам и QA для того, чтобы по-новому взглянуть на бизнес-процессы и предотвратить некоторые баги. 

...Был отличный зимний день, ничего не предвещало беды. Внезапно данные от одного госпиталя перестали приходить. Прошло 5 минут, мы были спокойны – ранее такое случалось несколько раз по 10-15 минут из-за проблем в сети госпиталя. 

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

Стремясь к профессиональному росту, многие разработчики делают ставку на конкретные технологии, новые языки и другие аспекты, связанные с IT. При этом IT-решение – часть бизнес-процесса, которая делает его быстрее и эффективнее в том случае, если сам процесс выстроен правильно. Если он неверный, то хорошая IT-часть ускорит “проявление” ошибок, но не исправит их, не предотвратит возможные потери. Есть области, где цена ошибки может быть очень велика, например, в медицине.

Ценность IT-специалиста зачастую повышается по мере того, как он на своем проекте осваивает не только программирование, но и смежные области – аналитику, основы работы с большими данными, работу на саппорте, управление командами. Об этом погружении “в глубину IT” рассказывает Алексей – один из наших опытных программистов. После 7 лет разработки он возглавил саппорт на своем проекте и готов поделиться опытом, к чему это привело.

“Как говорится, если вы хотите быть лучшим, вам надо войти или в 1% лучших в определенной области, или в 15% лучших в двух смежных областях, или в 30% лучших в трех смежных областях. При этом усилия, затрачиваемые на то, чтобы стать лучшим в конкретной области, возрастают по экспоненте”, - отмечает наш коллега.

О хуках в фронтенд-разработке на Хабре писали уже не раз, и в этой статье мы не сделаем великого открытия. Наша цель другая – рассказать про React Hooks настолько подробно и просто без трудной терминологии, насколько это возможно. Чтобы после прочтения статьи каждый понял про хуки всё. Эта статья будет полезна как начинающим React-разработчикам, так и тем, кто хочет, не уходя в глубины документации, получить практическую информацию в сжатом виде. 

Мы продолжаем делиться полезными материалами и сегодня поговорим о Selenium – инструменте тестирования web-приложений. Изучая его особенности, мы обнаружили в комьюнити ряд сообщений о различных ошибках: например, разработчики сталкивались с падением тестов, связанных с Shadow DOM, и получали ошибки в значениях root для Selenium. Однако, существует мнение, что такие сбои тестов могут оказаться не багом, а фичей. О своем подходе к работе с теневым DOM рассказал Титус Фортнер – core contributor в Selenium и автор материалов о тестировании. С разрешения автора переводим его статью, дополнив наблюдениями из нашей практики. Материал может быть полезен всем, кто занимается автоматизацией UI-тестирования с помощью Selenium.

Продолжаем делиться своей практикой и переводами статей, которые могут быть полезны мобильному разработчику. В прошлых статьях мы разобрали инструменты тестирования и оптимизацию внедрения зависимостей в Android, а сейчас рассмотрим одно из нововведений в iOS 13 – поддержку многооконного режима и разделение AppDelegate (жизненный цикл и настройка приложения) и SceneDelegate (отображение приложения). 

От автора: Ещё до Xcode 11, при создании нового проекта вы знали, что по умолчанию создаются некоторые файлы, такие как AppDelegate.swift, ViewController.swift и StoryBoard, а также некоторые другие. Но в Xcode 11 вы могли заметить, что наряду с файлами по умолчанию, указанными выше, создается новый файл – SceneDelegate.swift.

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

Проводя автотесты для скорости и надежности тестирования, в разработке и процессах CI/CD зачастую используют следующий стек технологий – Jenkins, Selenoid и Allure. Можно выделить несколько их преимуществ: у Jenkins это бесплатный доступ, большое количество возможностей и плагинов для расширения; у Selenoid – независимость окружений, каждый браузер запускается в отдельном контейнере; Allure, в свою очередь, в последние годы стал популярным инструментом для построения отчетов по результатам автотестов (подробнее об этом мы писали в прошлой статье). При этом информации о том, как эти инструменты можно сочетать, до сих пор достаточно мало, и мы хотим поделиться своим примером.

Для удобства отражения сайта на мобильных устройствах зачастую нужно внедрить в проект страницу Accelerated Mobile Pages (AMP). Делимся примером, как можно выполнить эту задачу, если вы работаете с приложением на React.

Начнем с того, что AMP — технология ускоренных мобильных страниц от Google с открытым исходным кодом. Этот способ позволяет оперативно загрузить веб-страницу при низкой скорости подключения к сети.

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

Именно такая задача появилась в одном из наших проектов, где стек технологий включал в себя Next.js, React, Styled components и Effector, при этом не было доступа к стору на стороне клиента. Большинство инструкций и гайдов по внедрению AMP, в свою очередь, были ориентированы на обычные html-страницы.

Бывает так, что ваше приложение обрабатывает графику и нуждается в высокой производительности – например, если это сервис для бронирования мест в зале, который мы показали в одной из прошлых статей. При этом зачастую нужны плавный зум или скроллинг элементов, а также поддержка различных библиотек. Рассмотрим, как сохранить производительность и скорость, на примере работы с библиотекой react-three-fiber.

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

Эта статья предназначена в первую очередь начинающим мобильным разработчикам, которые хотят изучить процессы тестирования и свое участие в них. На примере  Android-разработки обсудим подходящие инструменты тестирования – от JUnit до Kaspresso, а также немного познакомимся с методологиями Test Driven Development (TDD) и Behaviour Driven Development (BDD). Наконец, рассмотрим их отличия на примере кейса.

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

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

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

Для того чтобы ускорить тестирование крупных приложений, как правило, проверки вручную сочетают с автотестами. После их прогона SDET-специалисты разбирают успешные и «упавшие» тесты – их нужно проверить вручную и зафиксировать результаты, например, в Confluence.

Рассмотрим на примере, как можно ускорить экспорт этих данных, если вы работаете с некоммерческой версией Allure Framework. При использовании Allure-EE такие доработки не нужны – информацию по ручному прохождению кейсов можно хранить в самих отчетах.