Всем привет, меня зовут Кирилл Мыльников, я frontend разработчик в ГК Юзтех.

Сегодня хочу рассказать о расширениях для разработчиков в Google Chrome.

Здравствуйте. Меня зовут Евгений Пригаров, я руководитель программы проектов в ГК Юзтех. С 2006 года я занимаюсь оценкой проектов, работал на пресейлах в 4-х компаниях разного масштаба. В совокупности за эти годы я отработал 1000+ пресейлов.

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

Из статьи вы узнаете:

1) Как качественно оценить проект?

2) Как создать качественное ТКП?

3) Как качественно подать результаты оценки?

Дисклеймер:

— Качественная оценка и ТКП не гарантируют победы в пресейле;

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

Проверки в автотестах являются обязательным компонентом, так как основная задача любого теста сравнить ожидаемый результат с фактическим. Меня зовут Вадим, я специалист по тестированию, и в этой статье я хочу уделить внимание одной из частей любого автотеста – Assert. Казалось бы, какие трудности могут возникнуть с этим, на первый взгляд, простым компонентом любого автотеста? На одном из своих проектов я столкнулся с большим количеством автотестов, проблемой которых как раз и были неверно написанные проверки. Хочу рассказать о причинах возникновения этих трудностей и поделиться путём решения проблемы, который мне удалось пройти вместе с командой. 

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

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

Для начала пара слов обо мне. Это поможет лучше понять и прочувствовать то, о чём я говорю. Меня зовут Наталья, мне 23. В прошлом году я получила степень бакалавра в сфере Информационных систем и технологий. После этого около полугода я искала себя и наконец в феврале 2022 пришла в IT.  Сейчас я младший тестировщик в ГК Юзтех. Три месяца я обучалась по внутрикорпоративной программе менторства и только после этого присоединилась к настоящему проекту по разработке внутреннего веб-продукта “Программа лояльности”.

Всем привет, я — Кирилл Мыльников, frontend разработчик компании Usetech.

Сегодня хочу рассказать о полифилах JavaScript: что это и зачем они нужны? На практике мы реализуем несколько полифилов: map, forEach, filter, reduce. 

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

Итак, начнём с определения полифила, а затем перейдём к методам.

Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В предыдущей статье я рассказывал о Kafka и её аналогах, а сегодня хочу рассмотреть NiFi.

Вы узнаете:

Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В этой статье я расскажу о нашем опыте разработки продукта и выборе технического стэка. Хочу добавить, что я буду давать лишь поверхностный Helicopter view на продукты и их аналоги.

Из статьи вы узнаете:

Добрый день! Меня зовут Александр Леонов, я руководитель группы разработки одной из распределённых команд Usetech. Сегодня я хочу рассказать вам о том, как написать карманный тест производительности на неблокирующий код Webflux. Статья рассчитана на разработчиков, которые разрабатывают API или выполняют оптимизационный рефакторинг медленного кода. Итак, начнём.

Всем привет, с вами Кирилл Мыльников, frontend разработчик компании Usetech.

Сегодня я хочу рассказать о вертикальном и горизонтальном центрировании CSS (Cascading Style Sheets). В сети есть много статей на эту тему, но я хочу выделить все виды горизонтального и вертикального центрирования с примерами.

Тема довольно популярная для тех, кто просто верстает или занимается полноценной frontend-разработкой (ведь нам всегда нужно что-то центрировать).

Существует множество способов, как нужно отцентрировать элемент, в тех или иных ситуациях, каждый способ по своему хорош.

В этой статье я разберу следующие виды центрирования:

— Горизонтальное центрирование;
— Вертикальное центрирование;
— Горизонтальное и вертикальное центрирование.

Начнём.

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

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

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

Меня зовут Женя, я руководитель UX-направления в компании Usetech. На досуге веду телеграм-канал «Мамкин Дизайнер», где рассказываю о вот таких штуках.

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

Как упростить пакетную обработку данных со Spring Batch на примерах.

Всем привет, с вами я, Анна Жаркова, ведущий разработчик компании Usetech. 

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

В этой версии ставку сделали как на поддержку новых возможностей iOS, так и на улучшение и доработку уже существовавших. Основными направления развития SwiftUI стали:

1. Поддержка нового фреймворка для графиков Charts.

2.Навигация (своя, родная, нативная).

3.Сложные контролы.

4.Поддержка шаринга.

5.Графика и разметка.

Предлагаю рассмотреть их детальнее.

Charts

Начнем по порядку с API для графиков.

Всем привет, с вами я, Анна Жаркова, ведущий разработчик компании Usetech. 

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

- игры и разработку

- иммерсивный звук и изображение

- многооконность

- расширенный и улучшенный шаринг, механизмы обмена самыми разными данными и совместные процессы, взаимодействие между устройствами

- улучшенные возможности отслеживать состояние здоровья и физическую активность

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

Сразу скажу, что все сессии упомянуть не возможно. В этом году их много, они довольно разнообразные и разноплановые. От улучшений уже известных нам фреймворков (SwiftUI, WidgetKit, SharePlay) до совсем новых (WeatherKit, ScreenCaptureKit). Также верно сказано, что описания сессий в этом году не сильно многословны, видимо, что подстегнуть зрителей к просмотру всех.

Недавно, 6 мая этого года, в OpenJDK вошёл JEP 425, который добавит к Java 19 в качестве превью-фичи Виртуальные треды.

Пожалуй, этот JEP — самое большое изменение семантики языка после появления Дженериков. Его масштабы трудно оценить. Для начала попробуем прикинуть, как оно может отразиться на нашей зарплате.

Привет! Меня зовут Елена Поплоухина, я руководитель группы тестирования в компании Usetech. Ранее я рассказывала о практике обучения в QA отделе: квартальных целях и профиле тестировщика. Сегодня я хочу поговорить об ошибках, с которыми я сталкивалась на собеседованиях, поделиться историями и дать несколько советов.

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

Хочу уточнить, что материал основан на моём личном опыте и может отличаться от вашего. Надеюсь, он поможет новичкам понять, как делать не нужно, а опытные специалисты могут рассказать свою историю в комментариях. Итак, начнём.

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

Но в мире контроля качества программного обеспечения есть и другие интересные грани, о которых многие даже и не слышали — не только джуны, но и даже тестировщики со стажем. Среди таких популярных видов тестирования, как проведение нагрузки на систему, оценки надёжности работы программы, проверки локализации на разные языки внутренней лингвистики, в рамках которой у пользователя есть возможность использования программного продукта, и даже исследование юзабилити интерфейсов, есть не такой популярный вид тестирования как доступность.  Да-да, есть и такое в мире контроля качества программного обеспечения. И хотя в большинстве требований к ПО вы их не увидите, но доступность тоже бывает очень важной и полезной.

В современной практике отечественных компаний инициативы управления знаниями сталкиваются со сложностями, связанными с воплощением теории управления знаниями в конкретные инструменты. Меня зовут Иван Анненков, я ведущий аналитик в Usetech, и в этой статье я рассмотрю ряд конкретных предложений, а именно:

В этой статье Илья Гершман, ведущий разработчик Юзтех, рассматривает понятия сериализации и десериализации в сравнении между двумя языками программирования — Java и Kotlin.

Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.

Это следующие причины:

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

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

● Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.

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

Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.

Всем привет! На связи команда Usetech. В нашем блоге мы уже рассказывали о стереотипах в работе тестировщиков, о практике обучения в QA отделе и разработке на iOS. Наверняка многие в детстве читали Остера и в вашей библиотеке была книга с его вредными советами? Специально к 1 апреля мы подготовили подборку вредных советов от аналитиков и разработчиков. Материал основан на личном опыте сотрудников и носит исключительно развлекательный характер. Надеемся, он поможет новичкам понять, как делать не нужно и заставит опытных специалистов улыбнуться и поделиться собственной историей. Ну что, поехали? 😎