Существует миф, что один сильный программист может быть в 10 раз продуктивнее другого — ten-X developer. Я считаю, что таких программистов не бывает, но есть ten-X команды, которые перформят в 10 раз лучше самой слабой команды. Чтобы стать ten-X team, нужно поменять отношение к техдолгу.

Всем привет! Меня зовут Олег Федоткин, я руковожу разработкой PAAS в компании «СберМаркет». Эта история про менеджмент и инженерные практики.  Ten-X появляется как раз там, где соприкасаются эти два понятия. Начну с детективной истории: кто-то утопил команду  в айтишке. Спойлер: убийца — техдолг. Расскажу как его оценивать и измерять, причём здесь зебры, бихевиоризм и психология. А главное — расскажу про выезд из кризиса. Что делать, если вы уже погрязли в техдолге, как им управлять. Поехали!

Python библиотека pywinauto — это open source проект по автоматизации десктопных GUI приложений на Windows. За последние два года в ней появились новые крупные фичи:

• Поддержка технологии MS UI Automation. Интерфейс прежний, и теперь поддерживаются: WinForms, WPF, Qt5, Windows Store (UWP) и так далее — почти все, что есть на Windows.
• Система бэкендов/плагинов (сейчас их двое под капотом: дефолтный "win32" и новый "uia"). Дальше плавно двигаемся в сторону кросс-платформенности.
• Win32 хуки для мыши и клавиатуры (hot keys в духе pyHook).

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

Эта статья — частично расшифровка доклада с конференции SQA Days 20 в Минске (видеозапись и слайды), частично русская версия Getting Started Guide для pywinauto.

• Основные подходы
  
  • Координатный метод
  • Распознавание эталонных изображений
  • Accessibility технологии
• Основные десктопные accessibility технологии
  
  • Старый добрый Win32 API
  • Microsoft UI Automation
  • AT-SPI (Linux)
  • Apple Accessibility API
• Как начать работать с pywinauto
  
  • Входные точки для автоматизации
  • Спецификации окон/элементов
  • Магия доступа по атрибуту и по ключу
  • Пять правил для магических имен

Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и API, но сегодня хотим рассказать о более редком направлении – тестировании десктоп-приложений.

Кратко рассмотрим подходы, инструменты, технологии и «грабли», на которые можно наступить при выполнении этой задачи. Статья будет полезна специалистам, которые хотят попробовать автоматизировать ежедневную монотонную работу, а также коллегам по цеху в сфере автоматизации gui-тестирования – как начинающим, так и разработчикам с опытом.

Привет, я Илья — Frontend Team Lead в Альфа-Банк. Отвечаю не только за команду, но также веду и техчасть. Как тимлид я часто задаюсь вопросом «В чем моя роль?», «Как измерить эффективность моей работы?» и «Какой профит от лидов для проекта в целом?»

Для себя я вывел определение и задачи лида. Это всего лишь мои субъективные умозаключения, и искушенной публике Хабра могут быть хорошо знакомы, иногда слишком очевидны, но…повторение мать учения, как когда-то говорили. И даже если мы сто раз что-то слышали — не значит, что мы начали это делать. То, о чем я хочу рассказать – простые шаги, которые работают только при регулярном повторении, без пропуска какого-то пункта, это важно.

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

Продолжаем делиться полезными материалами в backend-разработке. Осваивая новые инструменты, специалисты SimbirSoft часто читают материалы зарубежных авторов, чтобы быть в курсе актуальных тенденций. В этот раз наш выбор пал на серию материалов британского разработчика Эндрю Лока про новые возможности .NET 6. С разрешения автора мы перевели статью, в которой он разбирает функции внедрения зависимостей в .NET 6. Материал будет полезен тем, кто хочет познакомиться с нововведениями в .Net 6 при переходе на эту технологию.

Периодически меня на начальном курсе просят дать "список всех-всех команд с кратким описанием что делает"... Ну прям "всех-всех". И ведь если искать в интернете "такие" справочники существуют - либо про "20-30 команд, но самых важных", либо с неточностями и устаревшей информацией. Так что предлагаю вашему вниманию свою версию такого "краткого" справочника (на 300, 515, 612, 716, 842, 1005,... 1260 команд) с ссылками на wiki-описание и на cheat.sh-примеры наиболее важных команд.

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

Введение

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

• Балансом между костылями и оверинжинирингом.
• Балансом между тестированием кода и быстрой выкаткой на прод.
• Балансом между техническим долгом и TTM.
• Балансом между «пиши код» и «развивай своего джуна» и так далее.

Почти девять лет назад миру был представлен новый опенсорсный проект под названием NuGet. Спустя два года после своего дебюта NuGet начал поставляться в Microsoft Visual Studio, что актуально и по сей день. NuGet — это один из нескольких пакетных менеджеров (диспетчеров пакетов), таких как Node Package Manager (NPM) для JavaScript и Maven для Java. Пакетные менеджеры упрощают и автоматизируют использование библиотек. Например, если вам нужна библиотека для реализации JavaScript Object Notation (JSON) в вашем .NET-приложении, потребуется всего несколько кликов мышью, и ваше приложение получит мощные возможности, которые вам не нужно реализовывать самим, совершенно бесплатно.

Данная статья является продолжением рассмотра основ GLTF и GLB форматов. Вы можете найти первую часть статьи здесь. В первой части мы рассмотрели с вами зачем изначально планировался формат, а также такие артефакты и их атрибуты GLTF формата как Scene, Node, Buffer, BufferView, Accessor и Mesh. В данной же статье мы рассмотрим Material, Texture, Animations, Skin, Camera, а также закончим формировать минимальный валидный GLTF файл.

Material и Texture

С мешем неразрывно связаны материалы и текстуры. При необходимости меш может быть анимирован. Материал хранит информацию о том, как модель будет отрендерена движком. GLTF определяет материалы, используя общий набор параметров, которые основаны на Physical-Based Rendering (PBR). PBR модель позволяет создавать “физически корректное” отображение объекта в разных световых условиях благодаря тому, что шейдинговая модель должна работать с “физическими” свойствами поверхности. Есть несколько способов описания PBR. Самая распространенная модель — это metallic-roughness model, которая и используется по умолчанию в GLTF. Также можно использовать и specular-glosiness модель, но только при помощи отдельного расширения (extenstion). Основные атрибуты материала следующие:

1. name — имя меша.
2. baseColorFactor/baseColorTexture — хранит инфомрацию о цвете. В случае атрибута Factor информация хранится в числовом значении для RGBA, в случае Texture — хранится ссылка на текстуру в объекте textures.
3. metallicFactor — хранит информцию о Metallic
4. roughnessFactor — хранит информцию об Roughness
5. doubleSided — имеет значение true либо false (значение по умолчанию) и указывает на то, будет ли меш рендериться с обоих сторон или только с "лицевой" стороны.

Что такое GLTF и GLB?

GLTF (GL Transmission Format) — это формат файла для хранения 3Д сцен и моделей, который является крайне простым в понимании (структура записана в стандарте JSON), расширяемым и легко взаимодействующим с современными веб-технологиями. Данный формат хорошо сжимает трёхмерные сцены и минимизирует обработку во время выполнения приложений, использующих WebGL и другие API. GLTF сейчас активно продвигается Khronos Group как JPEG от мира 3D. На сегодняшний день используется GLTF версии 2.0. Существует и бинарная версия данного формата, которая называется GLB, единственное различие которого в том, что все хранится в одном файле с расширением GLB.

Эта статья — 1 часть из 2х. В ней мы с вами рассмотрим такие артефакты формата и их атрибуты, как Scene, Node, Buffer, BufferView, Accessor и Mesh. А во второй статье мы рассмотрим оставшиеся: Material, Texture, Animations, Skin и Camera. Больше общей информации о формате можно найти здесь.
Если в процессе просмотра статьи захочется лично поработать с данным форматом, то можете скачать модели GLTF 2.0 с официального репозитория Khronos на GitHub

Проблематика и её решение

Изначально GLTF формат был задуман Khronos Group как решение для передачи 3D контента по интернету и был призван минимизировать количество импортеров и конвертеров, разные виды которых создаются при работе с графическими API.

На текущий момент GLTF и его бинарный брат GLB используются как унифицированные форматы и в CAD программах (Autodesk Maya, Blender и т. д.), в игровых движках (Unreal Engine, Unity и прочих), AR/VR приложениях, соц. сетях и т.д.

Мы уже несколько лет выпускаем на Хабре истории о переезде. Некоторые успешные, некоторые не очень (примерно 30% экспатов со временем возвращались).

Сейчас тема стала особенно актуальной. И, может быть парадоксально, но количество вакансий из других стран (тег «Релокейт») у нас в боте тоже выросло в полтора раза. Никакой русофобии и близко не наблюдается, компании понимают, что сейчас уникальный шанс получить мозги, выезжающие из страны.

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

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

Обсудили волнующую многих тему на нашем митапе с Захаром Овчаровым (Respona front-end team-lead, Toptal senior front-end developer). Встреча прошла перед конференцией IT-People Conf в Казани и вызвала интересную дискуссию. Полная версия обсуждений в нашем видео. 

Дисклеймер от Захара: все персонажи выдуманы, все действия нереальны, автор не несет никакой ответственности за ваши действия, поэтому действуйте на свой страх и риск;) 

Внезапно для себя вместо фронтенд-разработчика я стал тимлидом. Казалось бы, ничего страшного. Но как результат — огромная куча проблем.

Я всегда считал себя уравновешенным и мотивированным человеком. Думал, что в моей жизни всё прекрасно, у меня нет проблем со здоровьем и психикой. Но однажды я понял, что не так уж все хорошо: что-то мне спать не хочется, нет аппетита и настроения. Я решил обратиться к главному источнику информации — гуглу. Это было не лучшее решение. Я выяснил, что мёртв. 

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

12 разных издательств отказывали Джоан Роулинг в публикации первой части Гарри Поттера. Многим программистам отказывали не меньше.

В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы

⚠️ Материал средней сложности

С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работы. Имеется ввиду, конечно же, длительность работы делегатов. Чтобы достичь хороших показателей, гранулярность работы не может быть абы какой: она должна быть правильной. И помимо планирования задач на ThreadPool, планировать их можно также как через TPL так и через какой-либо свой собственный пул потоков. Например, если взять обычный ThreadPool, то можно примерно измерить издержки алгоритмов ThreadPool в тактах Time Stamp Counter счётчика времени (можно, конечно и в чём-то более привычном типа микросекунд, но там на многих сценариях вполне могут быть нули)