Приветик, это чат про монго?

да

джойны завезли, но они такие себе

да

А как мне ноду на солярке скомпилить? ;)

А как мне ноду на солярке скомпилить? ;)

я настолько толсто не умею, только на openSuse

я настолько толсто не умею, только на openSuse

Извините, у меня пул ZFS отклеился :(

Родина 20 Гб бесплатно дала

а ссыль есть?

А как мне ноду на солярке скомпилить? ;)

что-то вас уже трое

нанюхавшихся солярки

хорошая ОС

и ФС интересная

А как мне ноду на солярке скомпилить? ;)

зачем?

зачем?

Это был намеренный стеб, в стиле вопроса "Как мне зарутовать мой гэлакси?" в чате поклонников продукции Apple.

Нахрена вообще такое говно писать

Сделай отдельную функцию, сделай что надо в ней и верни

Резалт

На кой ляд переменные-то замыкать

>async Task... >OpenStreamForReadAsync >.Result

пристрелите его

бота написать модерационного шоле

слышал, что при блокировании незнакомого акка тг, ему спам дают

осталось проверить

Не дают

Боты для модерации - нормальная практика

Не дают

странно, просто видел человек жаловался на выданый спам, после блока и другой подтвердил

странно, просто видел человек жаловался на выданый спам, после блока и другой подтвердил

Тот же чатварс модерируется ботом

Мы его даже репортами закидывали

Мы его даже репортами закидывали

мб ботов можно только выгнать?

админом

А почему нельзя ?

Мы его даже репортами закидывали

да и боты же ограничены, вот и не реализовали им спам блок

Вообще, чем глубже копаю, тем больше складывается ощущение, что С# состоит из ненужного функционала чуть менее, чем полностью. То, что без generic выйдет длиннее мне и так ясно) Почти всегда так и бывает, то же самое с return, get, set. Что угодно можно делать без них, но некоторым людям проще сделать код нечитаемым, чем длинным.

Лолбля

Лолбля

Как будто это не так) Любое укорачивание это снижение понятности кода. А удлиннение — снижение читаемости.

Как будто это не так) Любое укорачивание это снижение понятности кода. А удлиннение — снижение читаемости.

ни кто не мешает, писать без сахара

ну сейчас 17. вообще хотел в 12 программирование начать, но тогда взялся за с++ и бросил, когда упёрся в "if"

Найс троллинг

Не понимаю, почему вся эта околоООПшная тема легальна, а вот goto так люто бешено ненавидим. goto наверное идеальный пример сокращения кода в ущерб его простоты

Хотя goto мне лично доставил не мало лулзов еще на форумах обсуждений

Найс байтануо

Прям слишком толсто

Не понимаю, почему вся эта околоООПшная тема легальна, а вот goto так люто бешено ненавидим. goto наверное идеальный пример сокращения кода в ущерб его простоты

Жир вытекает из монитора

ну сейчас 17. вообще хотел в 12 программирование начать, но тогда взялся за с++ и бросил, когда упёрся в "if"

а я начал прогить в 10 лет, в машинных кодах, потом перешел ассемблер

А работу дженериков я кстати осмыслил)))) но все еще не понимаю смертельную в них надобность

а я начал прогить в 10 лет, в машинных кодах, потом перешел ассемблер

на msil переходи, копилить сможешь под бубунту.

господа, поясните плиз, почему не рекомендуют асинк авейт внутри parallel foreach?

Не будет ждать

Вроде как

есть мат. библа написанная в парадигме асинкавейт, а запустить нада 24 потока, по процессорам

А работу дженериков я кстати осмыслил)))) но все еще не понимаю смертельную в них надобность

Предлагаешь создавать списки под все типы вручную?

Это как асинк в асинке

обычно делал в parallel foreach

есть мат. библа написанная в парадигме асинкавейт, а запустить нада 24 потока, по процессорам

не надо

сделай Таск.Ран для всех задач, а потом сделай вен ол

он сам будет управлять всей этой кучей

он сам будет управлять всей этой кучей

понял, спс

Предлагаешь создавать списки под все типы вручную?

Ну насколько титанических усилий это может стоить? По-моему все вытекает чисто из enterprise'ности языка. Где еще типов может быть настолько ниибацца много, кроме как гигантов IT индустрии?

Ну насколько титанических усилий это может стоить? По-моему все вытекает чисто из enterprise'ности языка. Где еще типов может быть настолько ниибацца много, кроме как гигантов IT индустрии?

В любом проекте

И каждый раз тебе придется писать новый список/словарь/методы

Это как в 10 подъездный дом поставить 1 лифт и выдолбить 9 коридоров от каждого подъезда к нему

Ну насколько титанических усилий это может стоить? По-моему все вытекает чисто из enterprise'ности языка. Где еще типов может быть настолько ниибацца много, кроме как гигантов IT индустрии?

Забаньте уже его

Хотя по идее в стройке это бы очень много сэкономило

@nikita_tsukanov тут тролль 270 уровня жирности

Забаньте уже его

Тоньше уже некуда)

ERROR: S client not available

а тут весело :)

Забайтил поцанов

кстати, какая альтернатива дженерикам кроме шаблонов и отсутствию типизации?

Так посоны

кстати, какая альтернатива дженерикам кроме шаблонов и отсутствию типизации?

Зависит от цели. Можно и рефлексию расчехлить.

Щас будет длиннопост

Возьмем например мввм для увп/впф. Что делать, когда приложение очень сильно разрастается? Становится нужно это, нужно то, и вот это прикрутить, и получается, что с течением времени поддерживать всю полученную лапшу становится очень сложно. Окидываю щас взглядом сильно связные компоненты своего пет-приложения и думаю, ведь зачем-то же Б-г дал нам интерфейсы, DI, IoC-контейнеры. Но как лучше всю эту братию использовать в десктопных/мобильных нативных приложениях? Можно биндить вьюхи не на конкретные классы, а на интерфейсы, это удобно, поскольку в будущем такое приложение можно будет с лёгкостью расширить, написать новые вьюмодели для этих вьюх с другим поведением (например одинаковый интерфейс текстбокса, но с разными вьюмоделями => можно использовать один UI для бокса сообщений, комментов туда, комментов сюда, диалоговых окон обратной связи). Но также Б-г дал нам shared-прожекты, в которых можно хранить вьюмодели и шарить их между разными UI-провайдерами — андроидовским, эппловским, увпшным или каким-нибудь другим. Однако какой подход лучше избрать, когда приложение очень большое? Более ста вьюмоделей хранить в папке ViewModels, как завещал нам Caliburn.Micro, как-то некруто, путано, эти списки файлов листать можно с ума свихнуться и спутаться. То же самое с вьюхами. Получается, следует структуру разбить на модули-неймспейсы и выстроить иерархию типа: - ViewModels [separate project] -- Audio --- AudioCollectionViewModel --- AudioPageViewModel --- AudioItemViewModel -- Video --- <...> - Views [separate project] -- Audio --- AudioView --- AudioShareView -- Video --- <...> С таким подходом становится возможно шарить кодовую базу между разными UI-провайдерами и при этом она довольно проста и очевидна. Но что тогда делать с DI и биндами контролов на интерфейсы? Заметив, что проект может неконтролируемо расширяться, стоит ли делать ещё один проект-схему или же интерфейсы вью-моделей следует складывать вместе вьюхами приложения? Или с вьюмоделями? Пожалуй, этот вариант логичнее всего. Но необходимо ли для каждого класса выделать интерфейс и нигде не использовать прямых биндингов на инстансы? Ведь вдруг нам понадобится использовать несколько реализаций поведения одного и того же элемента управления (а еще один такой же элемент управления нам копипастить лень — и это антипаттерно). Что мы получим, имея ввиду всё вышесказанное? Какова будет структура нашего нового проекта со слабой связностью компонентов? Попробуем разобраться! - ViewModels [shared project] -- Audio --- Implementation ---- AudioCollectionViewModel ---- AudioPageViewModel ---- AudioViewModel --- IAudioCollectionViewModel --- IAudioPageViewModel --- IAudioViewModel Соответственно во всех компонентах реализованных моделек мы обмазываемся выделенными интерфейсами и слабо связываем наши компоненты, ни в коем случае не используя ключевое слово new (конечно же, потому что это антипаттерн). Получилось у нас всё просто, тестируемо и по фен-шую (ну, почти). Некоторые интерфейсы можно явно не описывать (например, IAudioCollectionViewModel), если они являются потомками generic-класса (например, IFetchableCollection<IAudioCollectioViewModel>). Итого мы ещё чуть-чуть упростили себе жизнь. Или такое всё же лучше описать явно, что думаете?

Далее встаёт главный вопрос — чем инстансить классы наших вьюмоделей, где инстансить классы вьюмоделей, как инстансить классы вьюмоделей. Из того, что я знаю, получается, что все конструкторы инжектируемых и принимающих инъекцию моделей должны быть без лишних параметров. То есть мы хардкодим в классе его поведение и особенность, а при шаге вправо - шаге влево делаем другой класс, который реализует нужный интерфейс. Ок, удобно и вроде бы по паттернам. Но есть вот у нас хамлы, в которые надо закинуть нужные вьюмодели. Что делать-то? <SampleView.DataContext> <SampleViewModel /> </SampleView.DataContext> Инжектируем прямо в Уихе (одним лёгким движением руки убивая слабую связность компонентов)? Или ViewModelLocator с ужасно громоздким описанием лейзи-инстансов наших моделей (по понятным причинам это тоже антипаттерн)? Или всё-таки делать конструктор с параметром, чтобы потом где-нибудь (где?) выполнить IoC.Resolve<ISampleViewModel>? Вот этот вариант, кажется, самый вкусный. И всё же, если сервис-локатор и вьюмодел-локатор — антипаттерны, то где же нам резолвить это это добро? В конструкторе вьюхи, в код-бихайнде? public SampleView { public SampleView() { this.InitializeComponent(); this.DataContext = IoC.Resolve<ISampleViewModel>(); } } Однако нередко в чатах слышны громкие заявления, что идеальный MVVM — это когда код-бихайнд не содержит ничего, кроме InitializeComponent(). Для меня в иок-контейнерах пока самый сложный и непонятный момент — это отсутствие явного ответа на вопрос КОГДА их использовать в контексте ГДЕ их использовать.

Зависит от цели. Можно и рефлексию расчехлить.

кодогенерацию сразу, чего уж :)

Мб у кого есть мысли по этому поводу (помидорами не кидайтесь, но если что бейте по рукам, пожалуйста)

Рыба, я тебе 100 раз говорил про CaliburnMicro ))

Далее встаёт главный вопрос — чем инстансить классы наших вьюмоделей, где инстансить классы вьюмоделей, как инстансить классы вьюмоделей. Из того, что я знаю, получается, что все конструкторы инжектируемых и принимающих инъекцию моделей должны быть без лишних параметров. То есть мы хардкодим в классе его поведение и особенность, а при шаге вправо - шаге влево делаем другой класс, который реализует нужный интерфейс. Ок, удобно и вроде бы по паттернам. Но есть вот у нас хамлы, в которые надо закинуть нужные вьюмодели. Что делать-то? <SampleView.DataContext> <SampleViewModel /> </SampleView.DataContext> Инжектируем прямо в Уихе (одним лёгким движением руки убивая слабую связность компонентов)? Или ViewModelLocator с ужасно громоздким описанием лейзи-инстансов наших моделей (по понятным причинам это тоже антипаттерн)? Или всё-таки делать конструктор с параметром, чтобы потом где-нибудь (где?) выполнить IoC.Resolve<ISampleViewModel>? Вот этот вариант, кажется, самый вкусный. И всё же, если сервис-локатор и вьюмодел-локатор — антипаттерны, то где же нам резолвить это это добро? В конструкторе вьюхи, в код-бихайнде? public SampleView { public SampleView() { this.InitializeComponent(); this.DataContext = IoC.Resolve<ISampleViewModel>(); } } Однако нередко в чатах слышны громкие заявления, что идеальный MVVM — это когда код-бихайнд не содержит ничего, кроме InitializeComponent(). Для меня в иок-контейнерах пока самый сложный и непонятный момент — это отсутствие явного ответа на вопрос КОГДА их использовать в контексте ГДЕ их использовать.

Да ты ростёшь

Рыба, я тебе 100 раз говорил про CaliburnMicro ))

Да гавно он)

Мб стоит попробовать. Там нейминг конвеншны непонятные, надо попробовать. Интересно даже, получится ли всё по смыслу и по интерфейсам разделить.

Да гавно он)

Ага, попался! Используешь ViewModelLocator в сэмпле Медузы-клиента!

Рыба го веб

Плес

Рыба го веб

Ты думаешь почему я тут это всё пишу?! Потому что Ангуляр попробовал и понял, что надо Make Desktop Great Again!

Если серьезно то как бы смысла нет

То есть дело даже не в самих технологиях или ПО

Не в подходах

А именно в надобности и модели распространения

Плюс уязвимости ПО вроде Me.doc

Которые привели к распростанению Пети

Да просто проект есть и надо бы доделать. Мб взлетит даже совсем чуть-чуть, позволит купить мешок шавух :3

Вряд ли

Лично я это так вижу

Ага, попался! Используешь ViewModelLocator в сэмпле Медузы-клиента!

Это устойчивое выражение. В 11 или 12 году я не знал что калибёрн есть)

Это устойчивое выражение. В 11 или 12 году я не знал что калибёрн есть)

А сейчас тоже Калибёрн используешь?

Надо таки вкатываться в него, спасибо за советы.

Правда, видимо, переписывать придётся много.