Не подумайте что я не рад этому начинанию, я очень рад что такая возможность появилась наконец, но я оплатил участия онлайн, просто что бы понять смысл — какой профит мне дает то что я купил участие онлайн, если теперь я могу то же самое получить бесплатно? :)
Если купить бумажную версию, то электронная версия доступна? Или если хочешь и бумажную версию и электронную то их надо оплачивать каждую по отдельности?
К сожалению по работе не смог принять участие в вебинаре "Новые подходы в облачной архитектуре: контейнеры и микросервисы". Можно ли где нибудь посмотреть запись?
Я полез в оригинал еще раз. Там все таки скорее всего не об этом говорится.
"it doesn’t quite measure up to the rich and polished experience of C# and VB."
Ну т.е. можно перевести как очень большой опыт работы с C# и VB. С этим трудно не согласиться. Практически все самые лучшие книги по разработке в срезе .NET — все исключительно на C#. Если дело доходит до практической реализации (ASP.NET, WPF, Xamarin, Unity и т.д.) — все книги на C#.
В этом плане "опыт" F# просто не сранится с опытом на C#. Так что можно просто списать на неточность перевода.
Я сам хочу в следующем году написать книгу о применении F# на практике. А то большинство книг по F# о самом языке F# а не о его применении в практике.
Если честно меня тоже очень сильно удивило — ведь F# всегда по возможностям опережал C#. Я даже не знаю чем именно C# богаче. Собственно именно поэтому у F# всегда были такие ярые фанаты.
Но все равно так резго и грубо отзываться тоже не стоит — автор оригинала статьи не какой то левый человек c улицы, а человек который отвечает за развитие .net. Надо понять почему у него такая точка зрения. Статья старая, я читал оригинал примерно пару месяцев назад, и еще тогда остался в замешательстве. А автору статьи спасибо, просто и понятно доносит стратегию которая видит Microsoft на понятном русском языке, (иначе Вы бы не смогли узнать вообще об этой стратегии и так бурно возмутиться).
Простите за оффтоп, но как же раздражают многочисленные "в 2017 году". Т.е. в 2016 можно было говнокодить по страшному и резко, меньше чем за 2 месяца все прозрели и стали писать абсолютно по другому?
Спасибо за работу. Жалко что мало плюсов набирают статьи. Но я внимательно слежу за вашими статьями и читаю с большим удовольствием. Пожалуйста, не бросайте.
Спасибо за статью. Но есть несколько замечаний и вопросы на который я не нашел для себя ответа.
Преимущество Realm не в том что он "вживую" обновляет данные и сам дергает NotifyPropertyChanged. Это все прекрасно умеет и Fody.PropertyChanged. Но в случае Fody вам не придется ваши модели наследовать от конкретного объекта (RealmObject). Собственно если посмотрите исходники Realm для C# то можете что они всю эту "магию" реализуют через Fody
Как и сказано выше, Realm дает преимущество когда есть и сервер на Realm Object Server. Таким образом Realm продвигает идею что вам не надо самим писать логику синхронизации данных с сервером. Просто сохраняйте данные в модели и данные синхронизируются сами.
Я так и не нашел ответа на вопрос и во всех статьях про Realm "забывают" уточнить про этот самый важный вопрос. Приложения почти никогда не пишутся на века. Схема данных меняется. Там где у нас был Category Category {get; set; } завтра может быть IList Tags {get; set;}. Даже проще. Name может быть переименован во FirstName и т.д. и т.п. Как в таком случае мигрировать категории в теги? В случае SQL мы можем на новую схему написать скрипт миграции. А в случае Realm? Я спрашивал тех кто в бою используют Realm. Они по сути забивают на возможность потери данных или стараются ничего не менять без крайней необходимости ради удобства синхронизации данных клиента и сервера.
Следующий вопрос как следствие из предыдущих двух пунктов: Если схема данных меняется и даже есть какой то способ смигрировать данные. Как работает синхронизация данных с сервером если часть устройств обновилась и работает с новой схемой а часть устройство еще не обновилась и работают со старой схемой? В случае ручной работы с API мы можем легко поддержать работоспособность старого API до тех пор пока большинство устройств не обновятся и мигрировать вживую старые модели в новые. А как это все делается в Realm Object Server ?
В статье ссылки на цены версий IDE а не на Xamarin который полностью бесплатный.
О том что есть отдельно Xamarin без какого либо XAML (который сам по себе не меньше популярен чем Forms) и есть совсем другая платформа Xamarin Forms с XAML разметкой (надстройка над Xamarin) который относительно недавно стал набирать популярность в сообществе Xamarin в статье вообще ни слова.
Судя по всему в остальных платформах Вы разбираетесь примерно на таком же уровне.
Я могу понять (хотя на самом деле не могу понять), что вы не захотели разобраться в теме о которой Вы пишете. Но неужели было слишком трудно хотя бы пройти по той ссылке что вы привели в таблице и посмотреть на что именно Вы указываете в ссылке?
Вам конечно виднее как именно продвигать продукт и уверен у вас очень крутые маркетологи… Но лично меня всегда отпугивала необходимость писать вам письмо для того что бы узнать во сколько мне обойдется ваш продукт. Может я ошибаюсь, но непрозрачное ценообразование и само осознание что от умения общаться может зависеть цена и даже в этом случая тебя могут обмануть может многих отпугивать.
"… файл конфигурации Web.config, добавив в behaviors..." — Автор и использовал ASP.NET. Могли бы уточнить что именно из ASP.NET использовали бы Вы для этой задачи?
В основном это практикуют разработчики которые работают на Mac так как на маке нет возможности собирать приложения под Windows. Да и с другой стороны сейчас не так часто хотят решения под UWP — гораздо чаще просят поддержку только Android, iOS.
Очевидно что это первое что гуглится на эту тему и как порядочно ленивый человек эта библиотека первое что я пробовал использовать. Конкретно эта библиотека не устраивает по нескольким причинам. Поддержка — этому проекту два года и нет никаких намеков что будет обновляться. В силу давности проекта там и речи быть не может о Xamarin.Forms 2.x. В целом было много проще было создать свое решение так как мы используем проект в бою и в основном пользуемся последними стабильными версиями и будет активно развивать в рамках нашего решения.
Да, вы правы — документация там очень хорошая. Но, как неоднократно повторял в статье, из документации нет возможности понять что ожидать в узлах:
T
или
List<T>
или
Dictionry<int,T>
Именно эти правки после генерации кода необходимо вносить руками. Соответственно этот момент сильно мешает сделать полностью рабочую и более простую реализацию сгенерированного клиентского кода.
А вот для простых типов полей вся необходимая информация есть. Местами по разному но тем не менее все остальное указано.
Приношу извенения за дублирование статьи, в первый раз когда нажал «опубликовать» хабр сообщил что страница устарела. Видимо в первый раз публикация все же прошла успешно. Скрыл первую в черновики.
Не подумайте что я не рад этому начинанию, я очень рад что такая возможность появилась наконец, но я оплатил участия онлайн, просто что бы понять смысл — какой профит мне дает то что я купил участие онлайн, если теперь я могу то же самое получить бесплатно? :)
Если купить бумажную версию, то электронная версия доступна? Или если хочешь и бумажную версию и электронную то их надо оплачивать каждую по отдельности?
К сожалению по работе не смог принять участие в вебинаре "Новые подходы в облачной архитектуре: контейнеры и микросервисы". Можно ли где нибудь посмотреть запись?
Я полез в оригинал еще раз. Там все таки скорее всего не об этом говорится.
"it doesn’t quite measure up to the rich and polished experience of C# and VB."
Ну т.е. можно перевести как очень большой опыт работы с C# и VB. С этим трудно не согласиться. Практически все самые лучшие книги по разработке в срезе .NET — все исключительно на C#. Если дело доходит до практической реализации (ASP.NET, WPF, Xamarin, Unity и т.д.) — все книги на C#.
В этом плане "опыт" F# просто не сранится с опытом на C#. Так что можно просто списать на неточность перевода.
Я сам хочу в следующем году написать книгу о применении F# на практике. А то большинство книг по F# о самом языке F# а не о его применении в практике.
Если честно меня тоже очень сильно удивило — ведь F# всегда по возможностям опережал C#. Я даже не знаю чем именно C# богаче. Собственно именно поэтому у F# всегда были такие ярые фанаты.
Но все равно так резго и грубо отзываться тоже не стоит — автор оригинала статьи не какой то левый человек c улицы, а человек который отвечает за развитие .net. Надо понять почему у него такая точка зрения. Статья старая, я читал оригинал примерно пару месяцев назад, и еще тогда остался в замешательстве. А автору статьи спасибо, просто и понятно доносит стратегию которая видит Microsoft на понятном русском языке, (иначе Вы бы не смогли узнать вообще об этой стратегии и так бурно возмутиться).
Простите за оффтоп, но как же раздражают многочисленные "в 2017 году". Т.е. в 2016 можно было говнокодить по страшному и резко, меньше чем за 2 месяца все прозрели и стали писать абсолютно по другому?
Спасибо за работу. Жалко что мало плюсов набирают статьи. Но я внимательно слежу за вашими статьями и читаю с большим удовольствием. Пожалуйста, не бросайте.
Спасибо. Гораздо понятнее стало с Realm. А был опыт использования F# + Realm ?
Спасибо. В принципе все понятно.
Похоже ссылка о миграции отвалилась. Это получается что в модели надо хранить и старые и новые поля одновременно?
Спасибо за статью. Но есть несколько замечаний и вопросы на который я не нашел для себя ответа.
Преимущество Realm не в том что он "вживую" обновляет данные и сам дергает NotifyPropertyChanged. Это все прекрасно умеет и Fody.PropertyChanged. Но в случае Fody вам не придется ваши модели наследовать от конкретного объекта (RealmObject). Собственно если посмотрите исходники Realm для C# то можете что они всю эту "магию" реализуют через Fody
Как и сказано выше, Realm дает преимущество когда есть и сервер на Realm Object Server. Таким образом Realm продвигает идею что вам не надо самим писать логику синхронизации данных с сервером. Просто сохраняйте данные в модели и данные синхронизируются сами.
Я так и не нашел ответа на вопрос и во всех статьях про Realm "забывают" уточнить про этот самый важный вопрос. Приложения почти никогда не пишутся на века. Схема данных меняется. Там где у нас был Category Category {get; set; } завтра может быть IList Tags {get; set;}. Даже проще. Name может быть переименован во FirstName и т.д. и т.п. Как в таком случае мигрировать категории в теги? В случае SQL мы можем на новую схему написать скрипт миграции. А в случае Realm? Я спрашивал тех кто в бою используют Realm. Они по сути забивают на возможность потери данных или стараются ничего не менять без крайней необходимости ради удобства синхронизации данных клиента и сервера.
Следующий вопрос как следствие из предыдущих двух пунктов: Если схема данных меняется и даже есть какой то способ смигрировать данные. Как работает синхронизация данных с сервером если часть устройств обновилась и работает с новой схемой а часть устройство еще не обновилась и работают со старой схемой? В случае ручной работы с API мы можем легко поддержать работоспособность старого API до тех пор пока большинство устройств не обновятся и мигрировать вживую старые модели в новые. А как это все делается в Realm Object Server ?
Судя по статье они и не встраивали, а написали все с нуля:
Xamarin давно уже OpenSource и любой может отправить PR и при чем регулярно публикуют кто и что за PR отправилял:
https://releases.xamarin.com/pre-release-xamarin-forms-2-3-4-184-pre1/
В статье ссылки на цены версий IDE а не на Xamarin который полностью бесплатный.
Судя по всему в остальных платформах Вы разбираетесь примерно на таком же уровне.
Я могу понять (хотя на самом деле не могу понять), что вы не захотели разобраться в теме о которой Вы пишете. Но неужели было слишком трудно хотя бы пройти по той ссылке что вы привели в таблице и посмотреть на что именно Вы указываете в ссылке?
Почему то по ссылке ( https://connectevent.microsoft.com/ )в статье не видно трансляции стрима (или намека на плеера где это может проигрываться).
Нашел на канале Youtube — смотрю там:
https://www.youtube.com/watch?v=rUUd4S3FBrQ
А вот для простых типов полей вся необходимая информация есть. Местами по разному но тем не менее все остальное указано.