1. БД — это внешний ресурс, и состояние БД — это не есть состояние самого сервиса.
Сервисы с состоянием — это например сервисы в виде конечных автоматов (workflow services), которые ожидают вызовов от пользователя в строго определенном порядке и в зависимости от передаваемых данных
Давайте определимся все-таки. Есть аутентификация — выдача пользователю некоего токена-пропуска, на основе его логина и пароля.
Авторизация — определение пользователя на основе токена и обеспечение доступа к некоторым запрошенным ресурсам.
Отличается это тем, что токен может нести в себе некоторые дополнительные данные, которые можно проверить и по которым можно определеить пользователя БЕЗ обращения к каким-либо базам данных.
Еще один плюс — у вам может быть несколько механизмов аутентификации (своя БД, аутентификация через всякие openauth, внешние сервисы и тому подобное), но единая авторизация за счет единого авторизационного токена. Ну или единый сервис аутентификации, который выдает токен и набор разных сервисов, которые этот токен принимают.
Всё бы хорошо, но!
Для редактирования Storyboard пока без Xcode никуда.
И не все ошибки показывает, например, с теми же var/let и Optional variable.
В целом IDE хороший, но желаю вам разработать полное замещение Xcode.
Пока использую оба IDE в паре.
На Java не надо запускать новый процесс каждый раз когда нужно обработать http запрос. Сервер запускается 1 раз, слушает на 80 или 443 порту и обслуживает все запросы в рамках 1 процесса. На Java это достаточно просто, так как есть хорошие примитивы для работы с многопоточностью, памятью итп. Такая модель более эффективна, так как позволяет оперировать данными в рамках одного процесса, что значительно быстрее, например, походов в мемкеш на каждый запрос.
Как следствие, продакшен http запросы, связанные с формированием динамического html/json (естественно более сложные, чем hello world), полностью обслуживаются в среднем за 15-20мс. Не связанные с динамикой — быстрее.
Если хотите писать приложения в соответствии с логикой Swift, то полезно посмотреть русский перевод стэнфордских лекций «Developing iOS 8 Apps with Swift» на сайте «Разработка iOS + Swift + Objective-C». Там профессор учит писать приложения именно в соответствии с логикой Swift (Наблюдатели Свойств, вычисляемые свойства, отложенная инициализация и т.д.).
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.
Конечно, это Swift код, но обращение к С-функциям напрямую, без всяких UnsafeMutablePointer.
Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h
А вот это вы зря! Только что поставил и погонял Beta релиз Xcode 7.1 (Build: 7B91b) с поддержкой Swift 2.1.
В версии 2.1 добавили возможность использования си кода без всяких бриджей (наконец то избавились от костылей что юзали раньше) :)
func xyz() throws {
let f = fopen("x.txt", "r")
defer { fclose(f) }
try foo(f) // f is closed if an error is propagated.
let f2 = fopen("y.txt", "r")
defer { fclose(f2) }
try bar(f, f2) // f2 is closed, then f is closed if an error is propagated.
} // f2 is closed, then f is closed on a normal path
Более подробно можно почитать тут: https://developer.apple.com/library/prerelease/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html
Apple делает правильные шаги для того, чтобы заменить Objective C на более перспективный и мощный язык программирования; и как мне кажется делает это весьма успешно ;)
Разумеется это не киллер-фича, но это критически необходимая вещь для выживания любого нового языка.
Вообще в индустрии так сложилось, что каждый крупный (да и не очень крупный) игрок старается или вынужден разрабатывать свой собственный язык. И Apple просто сделала очередной необходимый шаг. Можно обожать ObjC сколько угодно, но давайте по-честному всё-таки он уже устарел, так что Apple даже несколько затянула с этим и вынуждена сейчас форсировать события. Поэтому мы наблюдаем такие частые и сильные изменения в языке.
Как бы то ни было, лично я считаю, что Swift может и не лучше других модных ныне языков (Go, C#, Rust и тд) но по крайней мере не хуже и благодаря поддержке Apple имеет хорошие шансы занять существенную долю рынка даже за пределами инфраструктуры Apple.
Почему нельзя перемешивать? Пожалуйста, можете использовать любые Objective-C классы в Swift проектах, для облегчения доступа к ним в Xcode 7 добавлены 3 новые возможности для Objective-C:
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.
Проходя мимо, вы, возможно, не в курсе, что на Swift 1.x вам никто и не предлагал разрабатывать промышленные библиотеки, хотя смельчаки, конечно, находились, потому что это совершенно новый язык и никто не знал, куда он «вывернет». Были прогнозы, что он вообще уйдет в сторону функционального программирования. Но прошел год, когда весь мир участвовал в отладке Swift, и сейчас мы получили не только новый язык Swift 2, но и новые концепции программирования — помимо Объектно-Ориентированного Программирования (OOП), которое было там изначально, помимо элементов Функционального Программирования, еще и Протоколо-Ориентированное Программирование. Кроме того язык очень краткий и очень красивый. Программирование на нем — очень увлекательное занятие. Так что странного ничего нет. Пробуйте. Я думаю он и вас не оставит равнодушным.
Я не очень поняла ваше замечание. От 0.5 к 0.6 — это больше или меньше 1.2 от 2.0? Но, если по делу, то переходить очень легко — работает автоматическая миграция от Swift 1.2 к Swift 2.0 и работает очень хорошо, даже для больших проектов — все попробовала. Остаются только мелочи, которые легко поправить, если знаешь, как это должно быть.
Ну, это вы загнули насчет #available. Если вы писали приложения, то наверно, знаете, что первое, что вы указываете при создании проекта, это либо приложение на iOS, либо на OS, либо tvOS, либо watchOS.
Так что они никогда не перемешаются.
Да, сейчас можно писать на Swift 2.1. Посмотрите мои Задания для стэнфордских курсов на Swift здесь. Есть очень не простые.
Единственное, где Objective-C выигрывает, — это вставка C кода напрямую в Objective-C. Но они над этим работают.
Сейчас адаптирую стэнфордские курсы на русском языке на Objective-C для iOS 9, и хотя API абсолютно одинаковые для Swift и Objective-C, несопоставимо легче писать на Swift.
До Swift 2, как в Objective-C, так и в Swift 1.x, протоколы содержали только декларацию методов (это то, о чем вы говорите).
С расширениями протокола (Protocol extensions) в Swift 2, протоколы теперь могут содержать наряду с декларацией, реализацию методов по умолчанию.
Часто некоторую функциональность необходимо добавить всем типам, которые подтверждают определенный протокол (интерфейс). Например, все коллекции (протокола CollectionType) могут поддерживать концепцию создания новой коллекции на основе преобразований своих элементов.
Если в расширении протокола CollectionType реализовать эту функциональность, то все типы, которые подтверждают протокол CollectionType, автоматически получат эту функциональность совершенно бесплатно.
Расширения протоколов лежат в основе нового подхода к конструированию программного обеспечения, заявленного Apple как Протокол-Ориентированное Программирование (ПОП), существующее в Swift 2 наряду с традиционным Объектно-Ориентированное Программированием ( ООП) и элементами Функционального Программирования (ФП). Оно должно преодолеть такие проблемы ООП, как «хрупкий базовый класс» и жесткость наследования (rigidity and fragility of inheritance), «проблему ромба» (“diamond problem”), неявное разделение ссылок на объекты, необходимость частого использования «кастинга» вниз (downcasting) в переопределенных методах.
Это сплошная деза. Зачем же это делать? Это какая-то статья-провокация.
Сегодняшний Swift не имеет ничего общего с тем, что написано в этой статье.
Да, год с небольшим назад, когда Apple объявила о Swift, некоторые, конечно, решили, что им дают готовый, как всегда очень качественный продукт. Но Apple оказалась хитрее, ни для каких больших проектов Swift 1.0 никто и не предлагал.
Она заставила весь мир работать над отладкой языка Swift и очень оперативно реагировала на все хорошие предложения.
Долго сопротивлялась, но сделала очень красивую обработку ошибок в Swift. Одни операторы guard и defer чего стоят. Сейчас язык в очень хорошей форме и действительно c многими парадигмами: хочешь ООП, хочешь элементы ФП, а сейчас еще и протокол-ориентированное программирование. Он отличается от того самого первого варианта 1,5 годичной давности как мобильные телефоны 90-х годов прошлого столетия величиной с портфель от iPhone.
То что автор статьи поскулил немного 1,5 года назад еще понять можно. Но то, что переводчик выложил это сейчас можно объяснить только тем, что целый год переводил, перевел и выбрасывать жалко.
Objective-C здесь вообще не причем. Apple его очень любовно сопровождает, API фреймворков и для Swift, и для Objective-C абсолютно одинаковые. Программируйте на чем хотите.
Но программировать на Swift приятно — всем советую попробовать и есть замечательные фишки типа if #available(iOS 9, *) без которых уже трудно обходиться.
А вот кстати интересный пример. В Swiftz есть операторы которые вообще не понятно как с клавиатуры вводить: •, ∪, ∩. По моему вменяемые разработчики должны такого избегать. Зачем это вообще в язык добавили? Чтобы кто-нибудь мог brainfuck.swift реализовать? :)
Сервисы с состоянием — это например сервисы в виде конечных автоматов (workflow services), которые ожидают вызовов от пользователя в строго определенном порядке и в зависимости от передаваемых данных
msdn.microsoft.com/en-us/magazine/cc164251.aspx
2. Есть целый стандартизованный формат для токенов (правда больше для soap) — en.wikipedia.org/wiki/Security_Assertion_Markup_Language
Соответственно, и примеры там есть ;)
Авторизация — определение пользователя на основе токена и обеспечение доступа к некоторым запрошенным ресурсам.
Отличается это тем, что токен может нести в себе некоторые дополнительные данные, которые можно проверить и по которым можно определеить пользователя БЕЗ обращения к каким-либо базам данных.
Еще один плюс — у вам может быть несколько механизмов аутентификации (своя БД, аутентификация через всякие openauth, внешние сервисы и тому подобное), но единая авторизация за счет единого авторизационного токена. Ну или единый сервис аутентификации, который выдает токен и набор разных сервисов, которые этот токен принимают.
Чат был сделан с нуля, и это была весьма интересная история, о которой скоро будет отдельный пост.
Для редактирования Storyboard пока без Xcode никуда.
И не все ошибки показывает, например, с теми же var/let и Optional variable.
В целом IDE хороший, но желаю вам разработать полное замещение Xcode.
Пока использую оба IDE в паре.
Как следствие, продакшен http запросы, связанные с формированием динамического html/json (естественно более сложные, чем hello world), полностью обслуживаются в среднем за 15-20мс. Не связанные с динамикой — быстрее.
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.
Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h
хотя сигнатура у нее очень накрученная
В версии 2.1 добавили возможность использования си кода без всяких бриджей (наконец то избавились от костылей что юзали раньше) :)
Более подробно можно почитать тут: https://developer.apple.com/library/prerelease/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html
Apple делает правильные шаги для того, чтобы заменить Objective C на более перспективный и мощный язык программирования; и как мне кажется делает это весьма успешно ;)
Вообще в индустрии так сложилось, что каждый крупный (да и не очень крупный) игрок старается или вынужден разрабатывать свой собственный язык. И Apple просто сделала очередной необходимый шаг. Можно обожать ObjC сколько угодно, но давайте по-честному всё-таки он уже устарел, так что Apple даже несколько затянула с этим и вынуждена сейчас форсировать события. Поэтому мы наблюдаем такие частые и сильные изменения в языке.
Как бы то ни было, лично я считаю, что Swift может и не лучше других модных ныне языков (Go, C#, Rust и тд) но по крайней мере не хуже и благодаря поддержке Apple имеет хорошие шансы занять существенную долю рынка даже за пределами инфраструктуры Apple.
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.
Так что они никогда не перемешаются.
Да, сейчас можно писать на Swift 2.1. Посмотрите мои Задания для стэнфордских курсов на Swift здесь. Есть очень не простые.
Единственное, где Objective-C выигрывает, — это вставка C кода напрямую в Objective-C. Но они над этим работают.
Сейчас адаптирую стэнфордские курсы на русском языке на Objective-C для iOS 9, и хотя API абсолютно одинаковые для Swift и Objective-C, несопоставимо легче писать на Swift.
С расширениями протокола (Protocol extensions) в Swift 2, протоколы теперь могут содержать наряду с декларацией, реализацию методов по умолчанию.
Часто некоторую функциональность необходимо добавить всем типам, которые подтверждают определенный протокол (интерфейс). Например, все коллекции (протокола CollectionType) могут поддерживать концепцию создания новой коллекции на основе преобразований своих элементов.
Если в расширении протокола CollectionType реализовать эту функциональность, то все типы, которые подтверждают протокол CollectionType, автоматически получат эту функциональность совершенно бесплатно.
Расширения протоколов лежат в основе нового подхода к конструированию программного обеспечения, заявленного Apple как Протокол-Ориентированное Программирование (ПОП), существующее в Swift 2 наряду с традиционным Объектно-Ориентированное Программированием ( ООП) и элементами Функционального Программирования (ФП). Оно должно преодолеть такие проблемы ООП, как «хрупкий базовый класс» и жесткость наследования (rigidity and fragility of inheritance), «проблему ромба» (“diamond problem”), неявное разделение ссылок на объекты, необходимость частого использования «кастинга» вниз (downcasting) в переопределенных методах.
Сегодняшний Swift не имеет ничего общего с тем, что написано в этой статье.
Да, год с небольшим назад, когда Apple объявила о Swift, некоторые, конечно, решили, что им дают готовый, как всегда очень качественный продукт. Но Apple оказалась хитрее, ни для каких больших проектов Swift 1.0 никто и не предлагал.
Она заставила весь мир работать над отладкой языка Swift и очень оперативно реагировала на все хорошие предложения.
Долго сопротивлялась, но сделала очень красивую обработку ошибок в Swift. Одни операторы
guardиdeferчего стоят. Сейчас язык в очень хорошей форме и действительно c многими парадигмами: хочешь ООП, хочешь элементы ФП, а сейчас еще и протокол-ориентированное программирование. Он отличается от того самого первого варианта 1,5 годичной давности как мобильные телефоны 90-х годов прошлого столетия величиной с портфель от iPhone.То что автор статьи поскулил немного 1,5 года назад еще понять можно. Но то, что переводчик выложил это сейчас можно объяснить только тем, что целый год переводил, перевел и выбрасывать жалко.
Objective-C здесь вообще не причем. Apple его очень любовно сопровождает, API фреймворков и для Swift, и для Objective-C абсолютно одинаковые. Программируйте на чем хотите.
Но программировать на Swift приятно — всем советую попробовать и есть замечательные фишки типа
if #available(iOS 9, *)без которых уже трудно обходиться.