Шутки-шутками, а будет уместным напомнить хабровчанам, что вопреки распространённому в нынешние времена мнению, порно не следует считать чем-то обыденным и совершенно безвредным. Согласно ряду опубликованных исследований, бесконтрольное потребление порнографического контента может оказывать губительное воздействие на мужское здоровье. С другой стороны, исследователи обнаружили положительную корреляцию между риском развода и количеством партнёров у женщин. Уместным будет также почитать вот этот тред в Твиттере — согласно некоторым исследованиям (см. ссылки), чрезмерное употребление контента для взрослых может приводить к нарушениям функционирования органов эндокринной системы, повышать риск возникновения депрессии. И это только верхушка айсберга — в запущенных случаях начинаются проблемы с мозговой активностью, памятью. Будьте здоровы.
Например, могли бы отказаться от Electron в пользу AvaloniaUI. Почему бы и нет! Там есть и реактивные расширения, и поддержка шаблона Model View Update, если кто-то вдруг не любит объектно-ориентированный код.
Возможно, из-за большой загруженности или других жизненных проблем у автора не хватило времени, но ваш PR вполне мог оказаться у него в todo list на ближайшее будущее. Да и потом, если что-то нужно сделать срочно, всегда можно форкнуть проект, применить исправление и не ждать. Разумеется, если лицензия позволяет (обычно позволяет). Мы так делаем время от времени, в результате нервы мотать не приходится ни себе, ни авторам, бампами и настойчивостью. Хотя, признаться, иногда можно и бампануть, некоторые люди могут что-то забыть и с этим придётся смириться.
Можно проигнорировать один раз, можно два. Но когда блейм на тебя обрушивается постоянно, желание дистанцироваться от проекта вполне закономерно возникнет рано или поздно. Форкнуть возможность есть, люди форкнули, пусть делают дальше, что хотят. Конечно, дяди с серьёзными напряженными лицами не согласятся и будут рассказывать про инантильность автора, и про то, что он не должен был так поступать. Но между инфантилами и серьёзными дядями есть большая разница — серьёзные дяди на опенсорс время не тратят, потому что опенсорс не приносит доход.
Очень удобный инструмент для прототипирования или логирования этапов исследования, широко используемый в мире ML и в университетах. Например, можно почитать про квантовую телепортацию, деревья решений, рекуррентные нейронные сети, а потом скачать себе на устройство докер-образ с ноутбуком и воспроизвести эксперименты, либо разработать что-то своё. В основном материалы по ссылкам содержат реализации на Python, и очень круто, что ML.NET и C# теперь тоже поддерживаются, и с удобствами.
Glad to hear you find it useful! And yes, you can either use the code-behind ReactiveUI bindings as in your example, or the regular XAML markup bindings. Both approaches should work as expected.
ReactiveUI.Fody не добавляет свой weaver автоматически в FodyWeavers.xml. <ReactiveUI/> туда надо добавлять ручками. И если банально забыть это сделать, то приложение спокойно скомпилится, но не будет правильно работать, а разработчик будет голову ломать в чем же проблема, когда вроде бы все правильно написано. Сам несколько раз так попадался :)
В 2019 это наконец починили на уровне Fody. Теперь, при установке любого weaver-а, запускается задача MSBuild, которая создаёт FodyWeavers.xml в корне проекта с включённым установленным плагином, либо модифицирует существующий FodyWeavers.xml!
Тут скорее вопрос неуважения редактора Jeditobe к своим читателям, ведь фактически репозиторий не был удалён. Всем новоприбывшим см. комментарий ValdikSS. Правильнее было бы заменить слово «удалил» в заголовке на фразу «скрыл из публичного доступа», но кто мы такие, чтобы советовать журналистам? Жёлтая пресса такая жёлтая, очень неприятно видеть такие набросы поутру.
А есть примеры real-world-проектов с кроссплатформенным GUI на GO? Существует реализация реактивных расширений для GO, было бы интересно посмотреть на что-нибудь в связке с ней — а у них в ридми нет ссылок на готовые проекты :(
In order to increase efficiency when making multiple amendments, the cache provides a means of batch editing. This is achieved using the .Edit method which ensures only a single change notification is produced.
Не лишним будет упомянуть в обсуждении фреймворк ReactiveUI и библиотеку DynamicData, которые решают ряд проблем MVVM реактивным программированием, и позволяют писать кроссплатформенный софт, используя общую модель и общие модели представления. Более того, ReactiveUI предоставляет инструменты для использования биндингов в Windows Forms и Xamarin.iOS/Xamarin.Android, выглядит это следующим образом:
this.WhenActivated(disposable =>
{
this.Bind(ViewModel, x => x.Title, x => x.TitleBox.Text)
.DisposeWith(disposable);
});
Главное преимущество и цель системы типов F# в том, чтобы не допустить существование структур, содержащих некорректные значения. Making invalid states unpresentable, как пишет Scott Wlaschin в своей книге «Domain Modelling Made Functional». Вещи, которые в C# мы будем проверять и логировать, в грамотном F#-коде просто не смогут существовать.
Конечно, на F# можно разрабатывать не только серверную часть, но и UI. Обязательно посмотрите замечательный доклад от Zaid Ajaj про разработку scalable UI на F#+Elmish, очень познавательно: youtu.be/-Oc4xJivY78 Проще говоря, F# может всё, что могут и C#, и JS
Всё-таки лучше указывать датаконтекст в xaml-е, а не в конструкторе
На самом деле, лучше всего использовать шаблон NavigationService или ViewModelLocator, чтобы можно было легко и непринуждённо использовать IoC-контейнер!
Поэтому ReactiveUI и PropertyChanged.Fody — наши друзья и товарищи! Удивительная эффективность, опенсорс, никакой коммерции, кроссплатформенность и хорошая документация.
Реактивные расширения и в частности ReactiveUI позволяют решать задачи существенно быстрее. "Переломить мозг" не так уж и сложно, тем более, что потом это быстро окупится. Туда же PropertyChanged.Fody. После того, как попробуешь эти две библиотеки, пути назад уже не будет. Начинаешь понимать, что вот эти ручные реализации INotifyPropertyChanged — нечто из далёкого прошлого. См. https://m.habr.com/post/418007/
Согласен с вами, что знания английского — это то, без чего и на рынке, и в целом в отрасли придётся плохо. Но давайте не будем за других людей решать, что им делать и как начинать изучать предмет? :)
Шутки-шутками, а будет уместным напомнить хабровчанам, что вопреки распространённому в нынешние времена мнению, порно не следует считать чем-то обыденным и совершенно безвредным. Согласно ряду опубликованных исследований, бесконтрольное потребление порнографического контента может оказывать губительное воздействие на мужское здоровье. С другой стороны, исследователи обнаружили положительную корреляцию между риском развода и количеством партнёров у женщин. Уместным будет также почитать вот этот тред в Твиттере — согласно некоторым исследованиям (см. ссылки), чрезмерное употребление контента для взрослых может приводить к нарушениям функционирования органов эндокринной системы, повышать риск возникновения депрессии. И это только верхушка айсберга — в запущенных случаях начинаются проблемы с мозговой активностью, памятью. Будьте здоровы.
Например, могли бы отказаться от Electron в пользу AvaloniaUI. Почему бы и нет! Там есть и реактивные расширения, и поддержка шаблона Model View Update, если кто-то вдруг не любит объектно-ориентированный код.
Возможно, из-за большой загруженности или других жизненных проблем у автора не хватило времени, но ваш PR вполне мог оказаться у него в todo list на ближайшее будущее. Да и потом, если что-то нужно сделать срочно, всегда можно форкнуть проект, применить исправление и не ждать. Разумеется, если лицензия позволяет (обычно позволяет). Мы так делаем время от времени, в результате нервы мотать не приходится ни себе, ни авторам, бампами и настойчивостью. Хотя, признаться, иногда можно и бампануть, некоторые люди могут что-то забыть и с этим придётся смириться.
Можно проигнорировать один раз, можно два. Но когда блейм на тебя обрушивается постоянно, желание дистанцироваться от проекта вполне закономерно возникнет рано или поздно. Форкнуть возможность есть, люди форкнули, пусть делают дальше, что хотят. Конечно, дяди с серьёзными напряженными лицами не согласятся и будут рассказывать про инантильность автора, и про то, что он не должен был так поступать. Но между инфантилами и серьёзными дядями есть большая разница — серьёзные дяди на опенсорс время не тратят, потому что опенсорс не приносит доход.
Очень удобный инструмент для прототипирования или логирования этапов исследования, широко используемый в мире ML и в университетах. Например, можно почитать про квантовую телепортацию, деревья решений, рекуррентные нейронные сети, а потом скачать себе на устройство докер-образ с ноутбуком и воспроизвести эксперименты, либо разработать что-то своё. В основном материалы по ссылкам содержат реализации на Python, и очень круто, что ML.NET и C# теперь тоже поддерживаются, и с удобствами.
Glad to hear you find it useful! And yes, you can either use the code-behind ReactiveUI bindings as in your example, or the regular XAML markup bindings. Both approaches should work as expected.
В 2019 это наконец починили на уровне Fody. Теперь, при установке любого weaver-а, запускается задача MSBuild, которая создаёт
FodyWeavers.xmlв корне проекта с включённым установленным плагином, либо модифицирует существующийFodyWeavers.xml!IReactiveList и реализации были депрекейтнуты в пользу DynamicData в ReactiveUI 8.6.1, см. reactiveui.net/blog/2018/08/deprecated-reactive-list
Ещё есть вариант задать вопрос сообществу в Slack или Gitter.
На самом деле, лучше всего использовать шаблон NavigationService или ViewModelLocator, чтобы можно было легко и непринуждённо использовать IoC-контейнер!
Поэтому ReactiveUI и PropertyChanged.Fody — наши друзья и товарищи! Удивительная эффективность, опенсорс, никакой коммерции, кроссплатформенность и хорошая документация.
Реактивные расширения и в частности ReactiveUI позволяют решать задачи существенно быстрее. "Переломить мозг" не так уж и сложно, тем более, что потом это быстро окупится. Туда же PropertyChanged.Fody. После того, как попробуешь эти две библиотеки, пути назад уже не будет. Начинаешь понимать, что вот эти ручные реализации INotifyPropertyChanged — нечто из далёкого прошлого. См. https://m.habr.com/post/418007/
Просто взгляните на Type Providers и попробуйте их в действии. На мой взгляд, одной этой фичи уже достаточно, чтобы, как минимум, начать присматриваться к F#.
Согласен с вами, что знания английского — это то, без чего и на рынке, и в целом в отрасли придётся плохо. Но давайте не будем за других людей решать, что им делать и как начинать изучать предмет? :)