Десктоп программирование что это
На чем писать мультиплатформенное desktop-приложение? Взгляд менеджера
Сегодня авторы большинства приложений уже не могут позволить себе выпускаться под одну платформу. Early adopters сидят под маками, мейнстрим сидит под Win32, а гики и адепты open source предпочитают Linux. Каждая из этих аудиторий обладает уникальными свойствами, а поэтому важна для большинства проектов.
Данная статья задумывалась как открытая попытка разобраться, на чем стоит писать мультиплатформенное desktop-приложение. Приглашаю высказать свое мнение людей с опытом создания таких приложений.
Изначально определим критерии, по которым будем оценивать различные платформы. В первую очередь — это удобство пользователя. Уверен, что вы замечали общие черты у приложений, написанных под разные платформы. Во вторую — это интересы проекта. Моя задача — построить успешный бизнес, а не играться с различными инструментами.
Обозначим рамки исследования. Мое приложение — небольшая утилита для пользователя-«чайника», которая качает файлы из интернета: минимум GUI, небольшой набор функциональности, использование внешних С++ библиотек.
Ну что, начнем. Какие есть варианты? Я рассмотрю Java, C#, C++, Python. Буду рад, если вы расскажите о других альтернативах.
Данный язык/среда изначально задумывались как нечто мультиплатформенное. На Java написано большое количество приложений, крупные проекты вроде Eclipse используют именно этот фреймворк.
Все приложения, которыми мне доводилось пользоваться, не использовали «родной» интерфейс Win32. Не знаю, чем руководствовались разработчики, но с точки зрения конечного пользователя это выглядит очень не симпатично.
Примеры приложений: Eclipse, ZDE, клиент для Gnutella Limewire.
Плюсы: мультиплатформенность, большое количество кадров, развитость фреймворка.
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
Аналогично с Java, приложения на C# имеют большой минус — необходимость устанавливать фреймворк. Я сам отказался от установки несколько приложений, которые требовали этого фреймворка. Менее продвинутые пользователи будут ещё более требовательными.
В остальном — сплошные плюсы, на мой взгляд.
Примеры приложений😕
Плюсы: мультиплатформенность, большое количество кадров, хорошая производительность, развитость фреймворка.
Минусы: необходимость установки фреймворка.
Старичок дотянул до наших дней и замечательно себя чувствует. Много приложений под платформы Linux и Windows до сих пор пишутся на этом языке.
Программы, написанные на C++, являются примером для других по размеру дистрибутива и экономному использованию системных ресурсов (процессор, память). Тем не менее у разработчиков есть масса претензий к С++. По моему мнению, язык является «устаревшим» и его популярность в дальнейшем будет снижаться, что подтверждается индексом TIOBE.
С точки зрения развития проекта, по сравнению с динамическими интерпретируемыми языками (вроде Ruby и Python), разработка на данном языке может иметь менее высокую скорость и более высокие издержки изменения проекта. Для стартапа, которому не столь важна производительность приложения, это может стать существенным минусом.
Примеры: Firefox.
Плюсы: отличная производительность, большое количество кадров, большое количество библиотек.
Минусы: невысокая скорость разработки.
Python
Взглянуть на Python в качестве платформы для desktop-приложений меня заставила программа MusicBrainz Picard. Несмотря на свою скриптовую сущность, Python легко собирается в один exe-файл, не требуя от пользователя установки дополнительных компонентов.
В случае разработки небольшого приложения, интерпретируемые языки вроде Python будут большим плюсом. Легкость написания и высокая скорость изменения приложения пригодится любому стартапу.
Огромным минусом различных «модных» технологий является их низкое распространение, а значит серьезные проблемы в поиске квалифицированных кадров. Ситуация с поиском программистов итак плачевная, а если ограничиться узким языком — можно вообще никого не найти. С другой стороны, храбрость перейти на новый язык имеют наиболее прогрессивные разработчики. Может получиться так, что выбрав «перспективный» язык, мы сразу отсечем миллионы середнячков, оставив себе выбор из нескольких перспективных разработчиков.
Пример: MusicBrainz Picard, оригинальный BitTorrent.
Плюсы: высокая скорость разработки и изменений, хорошая интеграция с библиотеками на С и С++.
Минусы: мало кадров, низкая производительность.
Выводы
К сожалению, любая из вышеперечисленных платформ имеет свои плюсы и минусы, однозначного решения найти не удалось. Выбор одной из них сегодня принесет преимущества и недостатки, влияние которых на проект мы увидим только завтра.
Я пока выбираю между С++ и Python. Первый является «надежным» решением с известными недостатками. Второй является «рискованным», но интересным и перспективным. Надеюсь, ваши отзывы помогут мне сделать окончательный выбор. Какую платформу выбрали бы вы на моем месте?
PS. Я сейчас ищу программистов в этот стартап (с++/python/php), поэтому если кому интересно — присылайте свое резюме.
8 видов российских программистов
Какие кодеры наиболее востребованы в нашей стране?
Если сказать простому человеку, что ты работаешь программистом, то в ответ можно услышать одну из следующих реплик:
Если в ответ сказать, что ты ни разу не делал сайты и лабы на VBA, а Windows видишь только в страшных снах, то собеседник может искренне удивиться и на его лице отразится искреннее сомнение в твоей профессиональной пригодности. Некоторые разработчики слабеют под таким взглядом и идут доказывать, что они что-то могут. Из-за таких лохов в голове обывателя слово «программист» является синонимом понятия «бесплатная компьютерная помощь».
Ведь многие люди не знают, чем на самом деле занимаются программисты и судят об этом по навыкам своих родственников/знакомых. Но разные представители специальности делают абсолютно разные вещи и нельзя говорить за всех.
Эта статья расскажет об основных специализациях программистов, которые наиболее востребованы на российском рынке. Для каждого типа будут указаны организации, где его можно встретить чаще всего и технологии, с которыми ему надо уметь работать.
В статье будут упомянуты только главные знания, без которых не обойтись в адекватном коллективе, где программиста не заставляют закручивать гайки, рисовать дизайн и выкладывать статьи на сайт.
1. Front-end веб-разработчик
Если мы заходим на сайт и там есть кнопочки, которые меняют местоположение и цвет при наведении на них мышкой, то это дело рук front-end разработчика. Он пишет весь код на JavaScript, который выполняется без перезагрузки страницы на стороне клиента.
Где работает?
В серьезных фирмах, занятых созданием сайтов и веб-приложений. Разделение фронтенда и бекенда один из признаков наличия в компании определенного уровня культуры разработки.
Что делает?
Разрабатывает динамику пользовательского интерфейса. Если в компании нет верстальщика, то еще и переводит PSD-шаблоны в HTML-код.
Технологии
2. Back-end разработчик
Человек на плечи которого ложиться основное бремя по разработке веб-проекта. Он как бы строит фундамент, на который front-end разработчик прицепляет «декоративные элементы».
Где работает?
В серьезных фирмах, занятых созданием сайтов и веб-приложений. Разделение фронтенда и бекенда один из признаков наличия в компании определенного уровня культуры разработки.
Что делает?
Разрабатывает “ядро” сайта или веб-приложения: код исполняемый на сервере и архитектуру базы данных.
Технологии
Один из нижеперечисленных языков и фреймворки/библиотеки для него:
3. Full-stack веб-разработчик
Человек, который может сделать сайт любой сложности «от и до».
Где работает?
Чаще всего в стартапах и небольших студиях веб-дизайна. В крупных компаниях содержится в команде наряду с front-end и back-end разработчиками, чтобы контролировать и координировать их работу.
Что делает?
Сайты и веб-приложения. Выполняет работу front-end и back-end разработчика одновременно.
Какие технологии ему желательно знать?
См. списки двух предыдущих типов.
4. Разработчик игр
Очень широкое понятие, которое включает как минимум три крупных категории: разработчик десктопных игр, разработчик мобильных игр и разработчик MMORG.
Где работает?
Что делает?
Какие технологии ему желательно знать?
5. Разработчик приложений под Android
Где работает?
В студиях мобильных приложений, стартапах или крупных компаниях, которые решили сделать для себя мобильное приложение собственными силами.
Что делает?
Разрабатывает приложения под операционную систему Android.
Какие технологии ему желательно знать?
6. Разработчик приложений под iOS
Где работает?
В студиях мобильных приложений, стартапах или крупных компаниях, которые решили сделать для себя мобильное приложение собственными силами.
Что делает?
Разрабатывает приложения под операционную систему iOS.
Технологии
7. Программист 1C
Многие разработчики не считают язык, встроенный в 1C, языком программирования, а людей, которые пишут на нем, программистами. У них есть на это свои основания. Тем не менее, людей которые называют себя программистами 1C и вакансий для них очень много.
Где работает?
В любой фирме активно ведущей экономическую деятельность. Часто не включен в основной штат сотрудников, а приходит пару раз в месяц или реже.
Что делает?
Пишет программы для автоматизации документооборота в компании.
Технологии
8. Инженер-программист
Если одним из 7 предыдущих типов можно стать отучившись на курсах или путем самообразования, то инженеров-программистов выпускают только технические ВУЗы. Часто на этих должностях работают люди старше сорока лет, получившие образование в советское время.
Где работает?
На производстве или в научном учреждении.
Что делает?
Разрабатывает программы для управления самыми разными устройствами: от печи на хлебозаводе до робота-пылесоса.
Технологии
Один из нижеперечисленных языков:
+ огромный багаж технических знаний, соответствующий отрасли в которой человек работает.
Если посмотреть объявления о найме программистов на российских сайтах, то 90% из них будут подходить под эти семь типов. На Западе рынок вакансии несколько разнообразнее. Кто интересуется, может зайти на Odesk и посмотреть, какая работа там предлагается.
С грустью замечаю, что 14-летние пакистанцы требуют там за html-верстку от 500 рублей в час.
А судить о том, какие языки сейчас наиболее популярны в мире можно по данным Tiobe Index. Этот рейтинг строится по числу запросов в поисковых системах с упоминанием разных языков программирования.
P.S. Напоследок, жизненный анекдот в тему.
Если бы водителей нанимали на работу так же как программистов:
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО. Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами “Формулы 1″ — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.
Зарплата: определяется по результатам собеседования.
C# Desktop программист, куда податься?
Оценить 3 комментария
За вас искать работу никто не будет
Нам даже лучше если вы присоединитесь к своему другу
1. Сходить на 2-3 собеседования в ит-конторы вашего города
2. Оформить ИНН и купить трудовую
3. Начать работать на полставки
В основном увлечен разработкой клиент-серверных приложений(чатов, систем друзей, защиты и т.д.).
Немного мало у меня в городе имеется компаний, занимающихся IT.
600 000 жителей. Как и у нас.
1) Проанализировать местный рынок вакансий.
2) Скорректировать стек изучаемых технологий под пункт 1.
Скорей всего это ASP.NET.
Так что в путь, на работу возьмут джуном, за зп в первый год не гонитесь, главное опыт.
Погуглите IT компании в вашем городе, в идеале в вашем районе.
Посмотрите на их сайтах вакансии.
Подготовьте резюме (1 страничка с кратким описанием навыков), разошлите по найденным вакансиям.
Рекомендую позвонить договориться о встрече с HR, узнать есть ли в компании стажировка, как на нее устроиться.
Десктопизация по-питоновски. Инструменты для создания автотестов
Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и API, но сегодня хотим рассказать о более редком направлении – тестировании десктоп-приложений.
Кратко рассмотрим подходы, инструменты, технологии и «грабли», на которые можно наступить при выполнении этой задачи. Статья будет полезна специалистам, которые хотят попробовать автоматизировать ежедневную монотонную работу, а также коллегам по цеху в сфере автоматизации gui-тестирования – как начинающим, так и разработчикам с опытом.
По архитектуре большинство десктоп-решений можно разделить на слои UI, Business, Transport и DB, а по их соотношению – на следующие группы:
standalone-приложения (все слои в одном месте);
клиент-серверные – тонкий клиент» (ui на клиенте, остальное на сервере);
«толстый клиент» (ui и business на клиенте, db-сервер).
Подобные решения чаще всего реализуют в web, чтобы обеспечить их гибкость, кроссплатформенность, легкость в разработке и поддержке. Из-за этой тенденции становится меньше десктоп-проектов, как и запросов на автотесты для них – по нашим наблюдениям, их доля не превышает 5-10% среди других проектов, поэтому для поиска актуального how-to гайда иногда нужно немало времени. Однако, в энтерпрайзе по-прежнему много десктопных приложений, качество работы которых оказывает влияние на бизнес.
Особенности
Рассмотрим несколько особенностей, которые мы учитываем при создании автотестов для десктопа:
Для начала нам нужен активный десктоп. Некоторые методы не смогут отработать, если запустить тесты через RDP и свернуть это окно. К счастью, для этого есть “костыли”:
перехват сессии rdp через tscon на саму себя позволит оставить рабочий стол активным с отключенным соединением;
небольшая правка реестра на хосте оставит активным рабочий стол на удалённой машине, что обеспечит возможность свернуть окно rdp-сессии.
На первый взгляд может показаться, что при работе с приложением с различными локализациями существуют затруднения: например, что некоторые локаторы будут находиться по имени элемента, которое может различаться в разных локализациях. Однако, на практике эти элементы достаточно легко найти по определенным критериям (тип, automation_id, активности и т.д.).
Поиск нужного элемента иногда выливается в интересную историю. Если открыть несколько разных приложений, то число элементов в дереве по ним может добраться до десяти тысяч, что значительно замедлит поиск отдельного элемента. Для того чтобы этого избежать, принято использовать поиск элементов по системе «родитель-наследник». Например, исходное окно приложения будет «родительским» элементом, а тулбар в нём – «дочерним». По мере «хождения» по приложению можно существенно ускорить поиск, отсекая лишние элементы и оставляя только нужную нам ветку. Данный подход имеет свои особенности. Например, некоторые приложения могут кидать popup-окно вне дерева элементов вкладки и даже самого приложения. В таком случае, именно рабочий стол следует принимать как исходный родительский элемент и работать от него.
Взаимодействие с элементами в случае MS UIA может происходит через обычные COM-интерфейсы, но допускается использовать и нестандартные, и это не редкость. Для Python есть библиотека comtypes, которая в связке с CPython решает такие вопросы.
Хотя технология MS UIA и имеет относительно подробную документацию, понять её «с лёту» может быть трудно. Для быстрого погружения можно воспользоваться разделом How-to Topics с полезными советами (на английском, само собой) и примерами кода (С#), но не стоит возлагать на него лишние надежды.
Комьюнити меньше, чем в других направлениях (web, mobile, api), поэтому вы можете столкнуться с недостатком информации.
Подходы
Существуют три основных подхода к автотестам desktop-приложений: координатный метод, распознавание изображений и accessibility. Все реализующие их инструменты взаимодействуют с первым слоем, UI.
Суть координатного метода – в эмулировании клика мыши по указанным координатам. Это самый легко реализуемый и простой метод с большим количеством библиотек. К минусам стоит отнести неустойчивость к изменениям, сложную поддержку тестов и невозможность извлечения данных из приложения.
Распознавание изображений – технология поиска местоположения на экране на основе изображения области или отдельного элемента. Хотя этот метод с каждым годом развивается и совершенствуется, на данный момент его инструменты все еще бывают нестабильны и “прожорливы”. В некоторых кейсах возможно получить значение поля с помощью методологий распознавания текста.
Accessibility-метод – достаточно стабильный и совершенный. Позволяет удобно управлять приложением во время теста, получать и использовать любые атрибуты элементов. Используется привычный подход с локаторами. Сами локаторы можно детектить с помощью инструмента Inspect из пакета Windows SDK.
Инструменты
На Github в топ инструментов для автоматизации десктопа входят следующие:
RobotJS – фреймворк для JavaScript (координатный подходом);
pyautogui – Python-фреймворк (координатный подход + распознавание изображений);
AutoHotkey (C++) – keyword-driven фреймворк (accessibility);
Appium Desktop – один из самых популярных фреймворков для автоматизации мобильных приложений (accessibility);
pywinauto – фреймворк для Python (accessibility).
В одном из наших проектов команда SDET-разработчиков использовала Python, и для относительной унификации процесса разработки и поддержки автотестов мы выбрали фреймворк на этом языке. На основе этого опыта мы предлагаем рассмотреть подробнее несколько инструментов для Python.
1) Pyautogui
Вот несколько примеров команд, которые помогут познакомиться с этим популярным инструментом.
Как получить текущую позицию курсора:
. или размер экрана в целом:
При этом размеры второго экрана выводятся некорректно. Кликаем дважды по точке на экране:
Фреймворк позволяет искать область на основе заранее подготовленного скриншота:
Также можно найти целый список областей:
Помимо этого, фреймворк также умеет работать с клавиатурой и создавать alert-подобные окна с функцией ввода. В документации перечисленные функции описаны подробнее, впрочем, без каких-либо неожиданностей.
2) Lackey (SikuliX)
Библиотеку Lackey мы выбрали как пример инструмента для реализации подхода с распознаванием изображения. Она работает на основе библиотеки Sikuli с использованием “великого и ужасного” OpenCV для распознавания элементов на экране. Сам OpenCV поддерживает, например, технологию CUDA, которая может дать ускорение распознавания в 5-100 раз. Вычислительные мощности видеокарт имеют стабильный ежегодный прирост, и подобные технологии дают хорошую прибавку.
Клик по распознанному элементу:
Документация Lackey составлена достаточно подробно, однако, отдельные вопросы – например, прикручивание CUDA – приходится искать отдельно.
3) Pywinauto
Одна из популярных библиотек в рамках accessibility-подхода. На данный момент поддерживает технологии Win32 API и UIA, но есть подвижки в сторону AT SPI.
Запуск приложения:
Ни для кого не секрет, что поиск рабочих локаторов процесс довольно трудоемкий. В проекте мы использовали инструмент Inspect, он входит в пакет Windows SDK и скачивается отдельно. Фреймворк позволяет нам искать элементы по критериям, которые с лёгкостью можно получить “на лету” через этот инструмент:
Левая половина окна инструмента отражает дерево элементов от рабочего стола и позволяет искать и выбирать инструменты, а правая содержит критерии поиска (в т.ч. координаты относительно края экрана), атрибуты элемента, поддерживаемые паттерны (методы взаимодействия) и список дочерних отношений с другими элементами.
В числе удобных “фишек” инструмента: вывод границ элемента и краткий список атрибутов сразу при наведении, быстрый переход к родительским/дочерним элементам.
Локаторы можно искать и иными путями. Например, список элементов и критерии для их поиска может печатать сам фреймворк через функцию print_control_identifiers.
Открываем закладку бокового меню:
И ожидаем открытия списка с файлами:
Файлов в нашей директории очень много. Ускорим поиск файла, используя родительский элемент из предыдущего шага, и проверим его активность:
Методы в документации описаны довольно подробно, у вас не будет особых трудностей с тем, чтобы разобраться в коде (до момента с подключением comtypes).
Технологии
Фреймворки, которые мы перечислили выше, это своеобразные “обёртки” для технологий, обеспечивающих управление на стороне ОС:
Windows: Win32 API, MS UI Automation
Mac: Apple Accessibility API
Расскажем подробнее о технологиях под Windows, т.к. подавляющее число gui-приложений пишут под эту ОС.
Поддерживаемость архитектур построения приложений
Частично Windows Forms, без WPF
Особенности архитектуры тестового фреймворка
В нашей практике мы чаще всего применяем паттерн Page Object. Однако, так как в десктопе в большинстве случаев вся архитектура строится как “слоистая”, при таком подходе мы получаем достаточно длинную наследуемую цепочку из родительских элементов. Поэтому для того чтобы облегчить читаемость кода, нужно прокачать его до Page Elements, где среди «пейджей» выделяются общие элементы и выносятся в отдельный объект. На этапе проектирования архитектуры важно выстроить иерархию классов (пейджей) и для этого изучить UI приложения. При этом с ростом количества тестов огрехи в архитектуре могут дорого стоить.
Не следует забывать и о паттернах проектирования. Тут нам точно пригодятся двое из ларца – “декоратор” и “посредник”, и вполне вероятно, что в эту компанию может затесаться синглтон.
“Декоратор” в разработке автотестов используется повсеместно. Чаще всего в фикстурах.
При переключении вкладки в одном из пейджей нам необходимо будет сообщить об этом другим пейджам. Тут на помощь придёт “посредник”.
При построении архитектуры автотестов для веб-приложения мы считаем, что у нас есть элемент и десяток методов для взаимодействия с ним. Десктоп “открывает дверь ногой” и представляет нам около 40 разных типов элементов (link): от простого checkbox до сложного DataGrid. Если говорить о количестве методов взаимодействия с каждым из типов, то тот же checkbox мы можем «выделить» 4 разными способами. Случается, что в приложении попадаются и «кастомные» элементы, и «общаться» с ними приходится путём “чёрной уличной магии” – обращения к низкоуровневому comtypes или нативной C#-библиотеке.
Возможные проблемы при автоматизации
Из-за взаимодействия с UI к списку можно смело добавить все «грабли» автоматизации тестирования UI. Как вишенка на торте, встречаются случаи, когда элемент приложения уже существует, но долго инициализируется – и вызов метода управления может не отработать корректно, так как элемент неактивен.
Есть довольно частный кейс с фреймворком pywinauto. Например, в приложении реализован поиск по товарам. Если результат поиска достаточно велик или весь список товаров выводится при открытии окна с поиском, то количество элементов в этом списке будет следующим: количество колонок*кол-во строк в результате*3 (в нашем кейсе). Если строк будет более двух сотен, то pywinauto не справится с таким количеством объектов. Есть подозрения, что и другие фреймворки accessibility-подхода имеют подобную особенность. Как вполне рабочий вариант, можно реализовать метод обхода дерева генератором через фреймворк и comtypes.
Вывод
В нашей статье мы рассмотрели проблематику и особенности тестирования desktop-приложений, с которыми столкнулись, кратко пробежались по инструментам, технологиям и подходам. В выводе хочется подсветить главный вопрос, который напрашивается после прочтения статьи: “стоит ли погружаться в автоматизацию десктопа?”.
По нашему опыту, автоматизация тестирования под десктоп не так сложна, как может показаться на первый взгляд. При принятии решения об автоматизации владелец продукта, как правило, исходит из частоты изменения функционала, текущего этапа проекта и его сложности. Подробнее об этих критериях мы рассказали ранее.
Кроме того, стоит учитывать и следующие особенности:
в зависимости от окружения автотесты desktop-приложения могут быть менее быстрыми и стабильными относительно остальных видов
более требовательны к компетенциям DevOps и/или SDET в случае необходимости параллелизации или внедрения через CI/CD
Так или иначе, автоматизация десктоп-приложения по сравнению с ручным тестированием дает ощутимый прирост – по нашему опыту, от 3 до 30 раз – к скорости прохождения тестов и снижает влияние человеческого фактора на процессы обеспечения качества.
Надеемся, что у нас получилось внести чуть больше ясности в эту область автоматизации. Будем рады, если наша статья окажется вам полезной. А если вам есть что сказать в ответ – ждем ваших комментариев!