Скоро исполнится 3 года с момента, как Apple открыла свой язык Swift, но за это время не случилось серьезного толчка в развитии. Все изменения, которые были внесены за это время сделали язык лучше, но он все же остался в рамках инфраструктуры Apple. На Swift можно писать приложения для iOS, но он так и не пошел дальше.
Когда Microsoft представили миру C#, то не смотря на отсутствие поддержки со стороны самого гиганта, нашлись энтузиасты, которые начали переносить его на другие платформы и появился Mono. Это говорит о том, что C# действительно великолепный язык и его люди готовы переносить самостоятельно.
Да уж, после iPhone 6 переход на XR сразу же заметен, если посмотреть на фотографии, они на много лучше. Это мы были на Ниагарском Водопаде и в воскресенье был неплохой салют. Я считаю, для телефона очень неплохо. Выкладываю фотографии без какой-либо дополнительной обработки.
В случае с программами и ОС мне в принципе все равно - открыт исходный код или нет. Я уже долгие годы работаю с Windows, Linux и macOS и у меня не возникало желания поменять код. Конечно же из этих трёх ОС, я даже теоретически смог бы поменять что-то только в Linux, потому что исходники остальных не доступны. Но все равно, тут я говорил о желании, а не о возможности.
Я просто пользуюсь программами и не думаю о коде. Если нет нужной возможности, то буду искать программу, в которой эта возможность есть, а реализовывать ее самостоятельно не хочется. Каждый должен заниматься своим делом и у меня есть своя работа, у разработчиков ОС и программ, которыми я пользуюсь - своя работа.
Самая первая игра, которую я написал для iOS была World Wide Wall и я ее написал с помощью Objective-C + OpenGL.
С тех пор уже много времени прошло и я решил ее убить, а выпустил новую версию под новым именем - Wall of Ball. Идея почти та же самая, но немного отличается и теперь игра написана на Swift и SpriteKit.
Игра бесплатная, ее я писал просто для себя, потому что люблю создавать такие простенькие вещи. Это как отдых для мпеня. В общем, если есть iOS устройтво и интересно посмотреть - качаем - Wall of Ball.
До сих пор я писал мобильные приложения только под iOS поэтому выбирал Objective-C или Swift и мне нравилось использовать их. Меня несколько раз спрашивали, а почему не Xamarin, ведь тогда я смогу писать и для iOS и для Андроида.
У меня не было цели писать для нескольких платформ. Я на работе пишу на C# и приходить домой и снова писать на C# не особо хотелось. Мне нужно было разнообразие в виде Swift, ведь это новый мир для меня, который интересно и хочется познавать.
Но вот понадобилось написать для iOS и Андроид платформ и вот тут я выбрал Visual Studio и его возможность создавать приложения сразу для нескольких платформ. И пока это интересно. Немного непривычно, но по своему интересно.
Я помню, когда появился iPhone 4 с ретина дисплеем, все восхищались картинкой и это стоило того, чтобы купить телефон. Но сразу после покупки все опускали яркость для того, чтобы сэкономить на батарее, иначе её не хватает на весь день.
Я долго воевал с дочкой, потому что у неё яркость всегда была на самом минимуме и не напрягая глаза видеть что-то было проблематично. Это же вредно для глаз пользоваться таким образом телефоном с минимальной яркостью (по крайней мере у меня глаза устают приглядываются), а у неё проблемы со зрением. Слишком ярко тоже плохо, нужно что-то посередине.
Под страхом запрета телефона дочка стала устанавливать среднюю яркость.
Бывают такие случаи, когда нужно написать код, который будет компилироваться в проект при определенных обстоятельствах. Например, при сборке проекта в конфигурации отладки (Debug) может возникнуть необходимость включить в проект определенные участки кода, которые будут сохранять в ваш журнал состояние выполнения программы. Или наоборот, в окончательную версию (Release) включать код, который будет отвечать за проверку легальности копии, а в отладочной версии этот код должен быть отключен, чтобы не загружал вас лишними проверками при старте программы.
Далеко не всегда удается писать код абсолютно без ошибок. Если ошибки компиляции нам помогает отловить компилятор, то с ошибками логики дело обстоит немного сложнее. Как узнать, почему какая-то переменная не изменяется или почему результат выполнения какого-то кода не такой, как вы ожидали? Все это сложно, если в вас нет мощного средства отладки программы, а в Visual Studio средства отладки достаточно мощные, чтобы найти любые ошибки.
На работе у нас перешли с TFS на git и команда архитектуры зачем-то написала power shell скрипты, которые должны были бы облегчить работу с git. Теоретически да, с PS скриптами стало удобно работать тем, кто всегда работал с TFS и никогда не понимал, как работает git, потому что с помощью скриптов идеологию git превратили в tfs, что очень даже...
Но даже если сделать power shell скрипты гибкими, я не вижу в них смысла по двум причинам.
1. git итак не сложный, если понимать, как он работает. Не нужны PS скрипты для того, чтобы выполнить команду fetch и merge, это легко сделать напрямую