1. Попробуйте получить из приложения UWP доступ к системным файлам. Да к любым файлам на диске, которые не выбраны пользователем лично и не относятся с самому приложению.
2. Обратите внимание на пакет Microsoft.NETCore.UniversalWindowsPlatform который устанавливается автоматически с каждым приложением.
По сути UWP тот же .NET, но с некоторыми ограничениями. Это как минус привычному для разработчиков функционалу, так и плюс безопасности и масштабируемости. Зато платформа определенно гораздо более современна и близка кроссплатформенной .NET Core.
По поводу того что ASP.NET API больше подходит я согласен (и с вами и с документацией). Но мне по старой памяти знаком WCF, потому и написал о нем.
Касательно сниппета, да, пожалуй длинноват, но он в оригинальном виде пропускал ошибочные элементы.
Это всего лишь один из способов получить элемент. Да, в данном примере он не используется. Преимущество, на мой взгляд, в том, что разработчик приложения и разработчик тестов могут использовать свои идентификаторы, которые не взаимосвязаны.
Сейчас вы можете использовать или RemoteWebDriver или IOSDriver
В данном случае, если вы используете IOSDriver, то можете искать элемент по его AutomationId:
AppSession.FindElementByAccessibilityId("txtResult") as IOSElement;
Когда выйдет специализированный Windows драйвер тоже скорее всего можно будет использовать поиск по AutomationProperties.Name
Это тема для отдельного разговора вроде «Login или Log in?»
Кстати, термин клон уже занят созданием локальной копии на компьютер, так что для fork не совсем подходит.
Я понял ваше мнение. В нем есть логика.
Да, для того, чтобы различать fork и branch, возможно, стоит говоря по-русски называть fork — клоном, а branch — веткой.
Но какие могут быть претензии ко мне, если на официальном сайте (смотрите ссылку выше) англоязычный термин “fork” это создание ветвления проекта.
Подборка лучших советов из комментариев:
1. Если вы пишете про GitHub, то пишите только про GitHub. GitHub и Git совершенно разные вещи, которые не взаимосвязаны.
2. С помощью GitHub расширения для VS командой push можно отправить изменения в любой репозиторий
3. В Visual Studio уже встроена поддержка GitHub и совсем не нужно рассказывать о каком-то еще расширении
4. Если вы хотите внести вклад в чужой проект, то вам нужно сделать его branch
Ну, спасибо, что не замолчали.
1. Для того чтобы научиться работать с GitHub необходимо познакомиться и с Git. Все верно. Что здесь не так?
2. Push рассматривается в контексте работы с GitHub. Слово английское и означать может много что.
У меня был случай, что на собеседование приехал за 100 км., а мне на месте предложили компьютер с которого я пообщался по скайпу… Бардак, конечно, но нужно отметить, что общались больше часа и это было одно из самых лучших собеседований из тех, что я проходил.
А как-то раз пообещали супер-мега вопросы от суперспецов. В результате общение по скайпу с примерно 6-тью лбами, и ни одного нормального вопроса. Больше часа потерянного времени. Все вопросы были стандартными и шаблонными. Причем, такое чувство, что на джуниорский вопрос а-ля «что такое полиморфизм» ожидался джуниорский ответ, заученный из учебника, а не объяснения своими словами. То чувство, когда собеседующие смотрят на тебя свысока, но сами при этом никакие. К собеседованиям должен готовится и собеседующий, и у него есть большой козырь, он может повести разговор в сторону любой технологии. А вот собеседуемому вспомнить технологию, которой он занимался пару лет назад может быть сложно. Касательно логических задачек — бррр… Согласен. Читать и заучивать решения из сети это дурной тон. И оценивать кандидата скорее нужно по оригинальности предложенного решения или варианта. Пусть даже и ошибочного. В этом суть.
PS: собеседования в Люксофт у меня были — понравились.
Фактически тот exe, который полуается, это обертка для команды «dotnet run».
Про компиляцию в native у Хансельмана тоже есть артикул Exploring the new .NET «dotnet» Command Line Interface (CLI), но посмотрите на дату — он старенький.
Если не ошибаюсь, то .NET Native доступен только под Win 10.
2. Обратите внимание на пакет Microsoft.NETCore.UniversalWindowsPlatform который устанавливается автоматически с каждым приложением.
Касательно сниппета, да, пожалуй длинноват, но он в оригинальном виде пропускал ошибочные элементы.
Спасибо за уточнения/дополнения/исправления!
2. А если есть что-то невалидное?
Попробуйте:
В данном случае, если вы используете IOSDriver, то можете искать элемент по его AutomationId:
Когда выйдет специализированный Windows драйвер тоже скорее всего можно будет использовать поиск по AutomationProperties.Name
Кстати, термин клон уже занят созданием локальной копии на компьютер, так что для fork не совсем подходит.
Да, для того, чтобы различать fork и branch, возможно, стоит говоря по-русски называть fork — клоном, а branch — веткой.
Но какие могут быть претензии ко мне, если на официальном сайте (смотрите ссылку выше) англоязычный термин “fork” это создание ветвления проекта.
1. Если вы пишете про GitHub, то пишите только про GitHub. GitHub и Git совершенно разные вещи, которые не взаимосвязаны.
2. С помощью GitHub расширения для VS командой push можно отправить изменения в любой репозиторий
3. В Visual Studio уже встроена поддержка GitHub и совсем не нужно рассказывать о каком-то еще расширении
4. Если вы хотите внести вклад в чужой проект, то вам нужно сделать его branch
1. Для того чтобы научиться работать с GitHub необходимо познакомиться и с Git. Все верно. Что здесь не так?
2. Push рассматривается в контексте работы с GitHub. Слово английское и означать может много что.
А как-то раз пообещали супер-мега вопросы от суперспецов. В результате общение по скайпу с примерно 6-тью лбами, и ни одного нормального вопроса. Больше часа потерянного времени. Все вопросы были стандартными и шаблонными. Причем, такое чувство, что на джуниорский вопрос а-ля «что такое полиморфизм» ожидался джуниорский ответ, заученный из учебника, а не объяснения своими словами. То чувство, когда собеседующие смотрят на тебя свысока, но сами при этом никакие. К собеседованиям должен готовится и собеседующий, и у него есть большой козырь, он может повести разговор в сторону любой технологии. А вот собеседуемому вспомнить технологию, которой он занимался пару лет назад может быть сложно. Касательно логических задачек — бррр… Согласен. Читать и заучивать решения из сети это дурной тон. И оценивать кандидата скорее нужно по оригинальности предложенного решения или варианта. Пусть даже и ошибочного. В этом суть.
PS: собеседования в Люксофт у меня были — понравились.
Про компиляцию в native у Хансельмана тоже есть артикул Exploring the new .NET «dotnet» Command Line Interface (CLI), но посмотрите на дату — он старенький.
Если не ошибаюсь, то .NET Native доступен только под Win 10.