На самом деле, ситуация пока не понятная. Здесь есть некоторое искажение. Допустим, условно, 23-го января заразилась 1 тыс. человек. Что бы вылечиться полностью при благоприятном течении болезни, предположим, нужно 2 недели. При неблагоприятном течении, человек умрет за 1 неделю.
При гипотетической смертности 10% мы получим, что к концу месяца 100 человек погибнет. Но выздоравливать к этому моменту будут только те, кто заразился 14-го января, а таких людей было всего несколько десятков, а не тысяча.
Это я к тому, что впрямую сравнивать 200 умерших и 200 заразившихся для определения смертоносности — не совсем корректно. Я думаю, что это отношение со временем будет выправляться. Уже сейчас смертность упала ниже 50%, хотя еще неделю назад смертность, если сравнивать эти две цифры впрямую, была более 60% (60 выздоровевших к 106 умершим).
Но даже 10% это реально дофига. Особенно, если учесть, что имунитет от вирусов вообще — очень ненадежная штука. Переболев однажды, вы не получаете гарантию что больше не заболеете. Т.е. вполне могут быть и вторая и третья волна эпидемий. И в эту лотерею можно играть до посинения.
Очень интересно было бы узнать о том, что Ярополк считает своими собственными достижениями, чтобы определиться со степенью доверия к докладу. Беглый поиск показал причастность автора к игре Pagan Online, которая получила весьма сдержанные отзывы сообщества:
От авторов с дефицитом идей — игрокам с дефицитом внимания
Лично работал с 4-5 такими «медведями». Компания в Москве, «медведи» в Волгограде, Украине, Белоруссии. Один, кстати, был в Москве же, но на 100% удаленке (совмещал с основным местом работы). Речь именно про разработчиков. А что такого уникального в 1с, что не позволяет получать задания и деплоить код на удаленке?
В Swift 5.1 появились PropertyWrapper.
В своей статье о SwiftUI я приводил пример, как можно использовать их для работы с UserDefaults (пример я подглядел тут). Мне кажется, лучше всего было бы совместить PropertyWrapper и ваш подход к работе с типами значений. Результат можно использовать и без связи со SwiftUI.
Если речь о введении в тему, то можно посмотреть русскоязычный курс на SwiftBook.ru.
Если речь о промышленном, так сказать, использовании, то время на освоение очень сильно зависит от начальной базы. Я с мобильной разработкой никак не был связан, так что да, времени ушло много, чтобы со всем разобраться. Именно курс 100 дней я не проходил, но на Hackingwithswift действительно много полезных материалов. К сожалению, их недостаточно. Их можно взять за точку отсчета, но для реального использования придется значительно углубиться в тему.
Как я уже писал выше, у меня, например, возникли определенные сложности с CoreData. На Hackingwithswift есть раздел на тему SwiftUI + CoreData, но там подразумевается, что вы уже знаете как работать с CoreData в принципе, и нужно только понять, как это к SwiftUI приложить.
Следующая статья (или через одну, я еще работаю над планом выхода статей) будет именно об этом.
Не могу сказать, что обладаю большим опытом написания реальных приложений на SwiftUI. То, что я пока видел — очень воодушевляюще. Рисованные кнопки — да запросто. Что угодно может быть кнопкой, если к этому прилепить .onTapGesture(), в том числе и Image. Анимация — легко . Подписи к кнопкам — всего-то использовать .overlay(Text("Кнопка")). Единственное, для проигрывания аудио потребуется AVAudioPlayer из Foundation — но его в любом случае использовать, что в SwiftUI, что в UIKit (ну или какие-то другие библиотеки для работы со звуками, все таки SwiftUI — это про изображение).
В принципе, любую задачу, решаемую на SwiftUI, можно решить и на UIKit. И грамотно составленный код на UIKit, возможно, будет даже быстрее работать. Вопрос только во времени, которое вы затратите на этот код, и вероятности, что код написан не оптимально. В последнем случае, UIKit может оказаться медленнее SwiftUI.
Ну и последнее. SwiftUI умеет еще не все. Некоторые задачи решаются только путем создания элемента на UIKit и встраивания его в SwiftUI View с помощью специального контроллера.
Хорошо помню, как оно было с управляемыми формами от 1с. Пока перед заказчиками стыдно не стало, что мы все еще пилим на обычных формах, убедить себя с ними разобраться не получалось. А менеджменту вообще без разницы, на чем там мы кодим — главное чтобы спайс не переставал поступать.
Так что это в первую очередь люди не готовы, как мне кажется.
Рад помочь. Я планирую написать еще несколько статей в том же стиле, но уже более конкретных, на живых примерах. В частности о CoreData + SwiftUI. Подписывайтесь:)
Пожалуйста. Я довольно много времени потратил впустую, ковыряясь со своим первым проектом. В сети есть несколько примеров простых приложений, но стоит попытаться отойти от них чуть в сторону — и тут же начинаются грабли. Мне по началу очень не хватало системного понимания, что это такое, и как оно работает. Простые листинги кода в этом мало помогали. Пришлось прокачивать английский, и лезть на StackOverflow. Там довольно часто встречаются толковые объяснения.
Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.
А что касается UIKit, то переход на SwiftUI с целью трудоустройства может быть преждевременным. В SwiftUI полно багов. Разработка пока похожа на танцы с бубнами — больше чем обычно. Описание ошибок в SwiftUI — штука такая. Почти рандомная. Проблема может быть в одной строчке кода, а компилятор ругается на совсем другие, с совсем другим описанием ошибки.
И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.
Все зависит от того, насколько успешно все с моим пет-проектом. В данный момент, я сосредоточил на нем 100% своего времени. Надеюсь, с его помощью получится закрепиться на ниве мобильной разработки.
Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).
не совсем.
id нужен для внутренней работы ForeEach, что бы он мог для каждого элемента построить свою View с помощью переданного контента. Эту View нужно связать с элементом с помощью какого-то ключа. Параметр id, это именно указание, какой реквизит использовать для этой связи в качестве уникального ключа элемента коллекции. Для этого используется вариант инициализатора с указанием ключевого атрибута.
Когда указывается id: \.self, это значит, что в качестве ключа будет использован непосредственно сам элемент, а точнее, его хэш. Именно поэтому, указанный реквизит, или сам объект в случае \.self должен удовлетворять протоколу Hashiable
А в замыкание просто передается элемент коллекции Data, для которого нужно нарисовать отдельную View {Item in ...}
При гипотетической смертности 10% мы получим, что к концу месяца 100 человек погибнет. Но выздоравливать к этому моменту будут только те, кто заразился 14-го января, а таких людей было всего несколько десятков, а не тысяча.
Это я к тому, что впрямую сравнивать 200 умерших и 200 заразившихся для определения смертоносности — не совсем корректно. Я думаю, что это отношение со временем будет выправляться. Уже сейчас смертность упала ниже 50%, хотя еще неделю назад смертность, если сравнивать эти две цифры впрямую, была более 60% (60 выздоровевших к 106 умершим).
Но даже 10% это реально дофига. Особенно, если учесть, что имунитет от вирусов вообще — очень ненадежная штука. Переболев однажды, вы не получаете гарантию что больше не заболеете. Т.е. вполне могут быть и вторая и третья волна эпидемий. И в эту лотерею можно играть до посинения.
как лид работал. Постановка задачи, код ревью, все такое.
В своей статье о SwiftUI я приводил пример, как можно использовать их для работы с UserDefaults (пример я подглядел тут). Мне кажется, лучше всего было бы совместить PropertyWrapper и ваш подход к работе с типами значений. Результат можно использовать и без связи со SwiftUI.
Если речь о промышленном, так сказать, использовании, то время на освоение очень сильно зависит от начальной базы. Я с мобильной разработкой никак не был связан, так что да, времени ушло много, чтобы со всем разобраться. Именно курс 100 дней я не проходил, но на Hackingwithswift действительно много полезных материалов. К сожалению, их недостаточно. Их можно взять за точку отсчета, но для реального использования придется значительно углубиться в тему.
Как я уже писал выше, у меня, например, возникли определенные сложности с CoreData. На Hackingwithswift есть раздел на тему SwiftUI + CoreData, но там подразумевается, что вы уже знаете как работать с CoreData в принципе, и нужно только понять, как это к SwiftUI приложить.
Следующая статья (или через одну, я еще работаю над планом выхода статей) будет именно об этом.
.onTapGesture(), в том числе иImage. Анимация — легко . Подписи к кнопкам — всего-то использовать.overlay(Text("Кнопка")). Единственное, для проигрывания аудио потребуетсяAVAudioPlayerизFoundation— но его в любом случае использовать, что в SwiftUI, что в UIKit (ну или какие-то другие библиотеки для работы со звуками, все таки SwiftUI — это про изображение).В принципе, любую задачу, решаемую на SwiftUI, можно решить и на UIKit. И грамотно составленный код на UIKit, возможно, будет даже быстрее работать. Вопрос только во времени, которое вы затратите на этот код, и вероятности, что код написан не оптимально. В последнем случае, UIKit может оказаться медленнее SwiftUI.
Ну и последнее. SwiftUI умеет еще не все. Некоторые задачи решаются только путем создания элемента на UIKit и встраивания его в SwiftUI View с помощью специального контроллера.
Так что это в первую очередь люди не готовы, как мне кажется.
Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.
И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.
Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).
id нужен для внутренней работы ForeEach, что бы он мог для каждого элемента построить свою View с помощью переданного контента. Эту View нужно связать с элементом с помощью какого-то ключа. Параметр id, это именно указание, какой реквизит использовать для этой связи в качестве уникального ключа элемента коллекции. Для этого используется вариант инициализатора с указанием ключевого атрибута.
Когда указывается id: \.self, это значит, что в качестве ключа будет использован непосредственно сам элемент, а точнее, его хэш. Именно поэтому, указанный реквизит, или сам объект в случае \.self должен удовлетворять протоколу Hashiable
А в замыкание просто передается элемент коллекции Data, для которого нужно нарисовать отдельную View {Item in ...}
Подробнее о KeyPath можно почитать, например, тут