• Директор по здравому смыслу: как перестать все контролировать и начать работать в команде
    +1
    вот эти ребята (при условии что они не вышли из тех кто ниже) всегда казались мне лишним звеном усложняющим коммуникации при любом размере компании.

    Не одному вам так кажется ;) Есть правда мнение, что дело не в системе управления, а в банальном отсутствии компетенции у «этих ребят». Тимлид — тоже не железный. На Хайлоаде заметил интересный тренд: все без исключения ищут тимлидов, дескать на рынке их нет, нужно выращивать внутри, чтобы пропитались культурой компании. Это все так, но сложно одному человеку и разрабокту тащить и отчеты строить и коммуникацию вести.

    Менеджеры как раз и должны взять на себя большой объем административной работы, освободив время тимлидов на работу с командой и управление рисками. А вот где учат менеджеров и почему они такие бестолковые в IT — это совершенно другой вопрос.
  • Привет из мезозоя
    –1

    Все верно. Там проблема только в том что старая версия спецификации web components, потому что polymer сделали когда их только Хром поддерживал как раз в том числе, чтобы продемонстрировать, что технология жизнеспособна

  • Пишем свой маппер для .NET Standard 2.0
    0

    Можно обойти это ограничение с помощью protected-конструктора и protected setter'ов. Не совсем элегантно, но mapper сможет дотянуться. Поправьте, если я ошибаюсь и через expression такой делегат не скомпилируешь.

  • Функциональная архитектура — это порты и адаптеры
    +2
    Для ясного и наглядного введения в монады типа Either смотрите отличную статью Скотта Улашина (Scott Wlaschin) «Railway oriented programming» (EN)

    Перевод есть на Хабре.
  • Шаблон проектирования «состояние» двадцать лет спустя
    0
    боль из-за разрастающихся switch-ей и необходимости изменять множество мест сразу — хотя именно этого хотелось бы избежать.

    Вы правы по поводу switch'ей. Поэтому я в конце добавил, что использование полиморфизма предпочтительней для control flow. Pattern matching хорошо подходит там где между состояниями нет ничего общего. По идее такие switch'и должны встречаться только в передаче управления в слой представления. Если состояния абсолютно разные, то вам действительно необходимо отредактировать каждый switch, потому что общего поведения нет и в каждом контексте требуется своя обработка ситуации.

    «а давайте, пользователь может в уже оплаченной корзине добавлять или убирать бесплатные опции — доставку, например, или подарок...»

    Вы реализуете в PaidCartState интерфейс IAddableCartState и продолжите работать по интерфейсной ссылке, используя полиморфизм.
  • Шаблон проектирования «состояние» двадцать лет спустя
    –2
    У вас это не получилось. Давайте рассмотрим не общий метод GetViewResult, а метод контроллера который отвечает за добавление элемента в корзину. Попробуйте избавиться от невозможных операций там.

    Добавляем шаблон «Форма не реализована» и вставляем в default и исключения не будет.

    Программа, которая выдает ошибку при попытке выполнения некорретной операции — работает корректно.

    Если для вас это корректное поведение и все устраивает, то вам и не нужно структурировать состояния таким образом.
  • Шаблон проектирования «состояние» двадцать лет спустя
    0
    Как эта идея уживается с default: throw new InvalidOperationException();?

    Возможно, получится написать анализтор на Roslyn для того чтобы заставить в pattern matching обработать всех наследников. Тогда от этого InvalidOperationException в этом месте можно будет отказаться. Я думаю, что лучше одно исключение в pattern matching, чем неизвестно сколько в реализациях состояний.

    Кстати, в чем именно вы видите нарушение принципа подстановки Лисков?

    Есть ICartState { Add, Remove, Pay}. Мы не можем заменить ActiveCartState: ICartState на PaidCartState: ICartState, потому что оплаченное состояние выбросит исключение. Основная идея избавиться именно от этих InvalidOperationException.
  • Объясняем современный JavaScript динозавру
    0
    Можете написать модель на беке и сделать генератор кода для vue на основе бек-модели. Работы на пару дней.
  • Модули вместо микросервисов
    0
    Ответил выше. От термина «компонент» решили отказаться на бекенде, чтобы не вводить путаницу с «компонентами» на фронте. В итоге решили, что есть модули и они компонуются. Это вопрос терминалогии уже, кому как удобнее.

    Специально проверял значение термина «модуль» в Википедии. Этому определнию наш подход не противоречит. А стоит ли выделять отдельную сущность «компонент» и из них строить модули — вопрос организационный.
  • Модули вместо микросервисов
    0
    У нас этот подход применяется к веб-разработке. Модуль — семантическая единица. Area — модуль, папка — модуль. В папке контроллер, DTO, все необходимое для работы модуля. В этом смысле мы полагаемся на соглашения MVC-фреймворка про «интерфейс доступа». Точками входа являются контроллеры, а MVC-фреймворк знает как их найти.
  • Модули вместо микросервисов
    0

    Уже давно пишем почти весь код в "модульном" стиле. Модуль = папка в проекте. В папке весь код модуля. Если модуль по каким-то причинам больше не нужен, удаляем папку и забываем. Довольны.

  • Железнодорожно-ориентированное программирование. Обработка ошибок в функциональном стиле
    +1
    Возможно, потому что некоторые программисты не совсем эффективно «редактируют код»?:)
  • Железнодорожно-ориентированное программирование. Обработка ошибок в функциональном стиле
    0
    Кстати, на F# же вроде есть аналог do-нотации, почему бы не использовать его?

    Можно. Скотт пояснил, что не использовал их, чтобы «сработало» его маркетинговое обещание про то, что код с обработкой ошибок и без будет одинаковым:) Более того, Mark Seemann нечто подобное уже предложил уже в своем блоге. Правда там Either и Async. Идея немного другая, но сделано как раз с помощью computation expressions.
  • Железнодорожно-ориентированное программирование. Обработка ошибок в функциональном стиле
    0
    В плюсы ещё список всех Failure (как с checked exceptions). Минусы масштабируемости как с checked exceptions:) Для валидация ИМХО такой подход хорошо работает. Для всего приложение — на любителя.
  • Железнодорожно-ориентированное программирование. Обработка ошибок в функциональном стиле
    –2
    Мне тоже жаль мобильных пользователей, но из песни слов не выкинешь. Если резать выше, то непонятно будет о чем статья.
  • Железнодорожно-ориентированное программирование. Обработка ошибок в функциональном стиле
    0
    А EntityId свой не покажете? Хочется со своим сравнить.
  • «Если бы сейчас начали сначала, снова выбрали бы Scala»: Tinkoff.ru о Scala-разработке
    +3
    но чем выше уровень абстракции, тем лучше надо понимать что «под капотом» и как эта магия работает.
  • Необразованная молодёжь
    0
    Пожалуй, вы правы. Нам до MIT как до луны. Я рассуждаю с точки зрения бизнеса: сначала нужно хотя-бы уровень подготовки студентов повысить, чтобы залатать кадровую дыру, а потом уже исследованиями заниматься. Возможно, что эта точка зрения однобока и без фундаментальных исследований никогда не будет хорошего преподавания и нужно развивать оба направления одновременно или сначала «наладить» исследовательскую деятельность.
  • Необразованная молодёжь
    0
    В чем конкретно ваш вопрос? ВУЗ должен кадры готовить, а не пропеты / инновации. Уровень кадров на выходе я считаю неплохим: лучше среднего по больнице.
  • Необразованная молодёжь
    0

    У нас в Казани есть ИТИС (http://kpfu.ru/itis). Не знаю на сколько сложно поступить и сколько стоит обучение (какая-то гранатовая система). Курсы у студентов хорошие.

  • 12 инструментов повышения личной продуктивности, которые помогут вам не профакапить дедлайн
    0
    Я про мотивацию солидарен с Карлином.
  • 12 инструментов повышения личной продуктивности, которые помогут вам не профакапить дедлайн
    0

    Вы забыли добавить, что при этом подходе может урезаться не только функциональность, но и бюджет проекта.:) Тут зависит от того, что в договоре написано про "вылезающие проблемы".

  • 12 инструментов повышения личной продуктивности, которые помогут вам не профакапить дедлайн
    –2

    Да нигде. Сидите в *опе:)

  • «Паттерны» функционального программирования
    0
    Пожалуй, нужно ответить более развернуто. Да, я согласен, что в TPL с обработкой ошибок все здорово. Гораздо лучше, чем при работе с Thread напрямую. Да, сильно сложнее с TPL не становится. Я говорю о том, что с TPL появляются дополнительные нюансы.

    var t = a.ContinueWith().ContinueWith().ContinueWith(); t.Wait();

    Этот код не имеет практического применения. Какой смысл использовать асинхронную модель, чтобы потом принудительно ее «синхронизировать» с помощью t.Wait()?

    Я имел в виду следующие особенности:

    • Fire & Forget: не все разработчики одинаково полезны ответственно относятся к обработке исключений. Кто-то просто напишет так и ошибка будет потеряна.
      Task.Run(() => {
          // ...
          throw new Exception("please help me")
      }; // Fire & Forget
    • Про AggregateException.Flatten для TaskCreationOptions.AttachedToParent нужно знать, иначе можно потерять часть исключений.
      void Handle(AggregateException ex)
      {
          foreach (var exception in ex.Flatten().InnerExceptions)
          {
              Console.WriteLine(exception.Message);
          }
      }
    • Возможность обработать исключение с помощью TaskContinuationOptions.OnlyOnFaulted, а не try/catch — еще один exit point.
    • Можно потерять одно из исключений при использовании Task.WhenAll (да, они ССЗБ).
    • UnobservedTaskException — настраиваемое поведение
    • Wrapping / Unwrapping AggregateException при использовании await или t.Wait() — нужно внимательно следить, что мы ловим в try/catch.

    Возможно, для кого-то эти аргументы покажутся несущественными. Для меня это дополнительная сложность с которой нужно работать.

    Спасибо за комментарий. Пока отвечал понял, что зря вообще докопался до TPL. Мне больше не понравилась идея строить на исключениях control-flow на самом деле, а TPL как-то под «замес» попал:)
  • Functional C#: Primitive obsession (одержимость примитивами)
    0
    А если Customer'у потребуется менять email, то добавляем такое?
    public void UpdatePrimaryEmail(Email email)
    {
        _primaryEmail = email;   
    }
    
    public void UpdateSecondaryEmail(Email email)
    {
        _seconaryEmail = email;   
    }
    
    public void ClearSeconaryEmail()
    {
        _seconadryEmail = null;
    }
  • Functional C#: Primitive obsession (одержимость примитивами)
    0
        [Required(ErrorMessage = “E-mail is required”)]
        [RegularExpression(@”^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$”, ErrorMessage = “Invalid e-mail address”)]
        [StringLength(100, ErrorMessage = “E-mail is too long”)]
        public string Email { get; set; }

    Этот код работал с ORM «из коробки». Можете привести пример как вы рекомендуете мапить обертки?
  • «Паттерны» функционального программирования
    –1
    синхронный код:
    try
    {
        var a = someMethodThrowingArgumentException(123);
        var b = someMethodThrowingInvalidOperationException(a);
        var c =  someMethodThrowingGenericException(b);
        return c.ToString();
    }
    catch(ArgumentException)
    {
        retrun "ArgumentException happened";
    }
    catch(InvalidOperationException)
    {
        retrun "InvalidOperationException happened";
    }
    catch(Exception)
    {
        retrun "Ooops!";
    }
    

    С TPL:
    someTask.ContinueWith(a => {
        try
        {
            someSyncMethod(a);
            someAsyncMethod(a).ContunueWith(b => {
                try
                {
                    // ну и так далее
                }
                catch(InvalidOperaionException)
                {
                     // только для синхронного метода
                     return "InvalidOperationException happened";
                }
            })
        }
        catch(ArgumentException)
        {
             return "ArgumentException happend"
        }
    })
    

    Да, есть async/await. Но код с async/await только выглядит императивным, а компилируется в нечто другое, работающее с помощью SyncronizationContext и по духу ничем не отличается от монад. Т.е. в чисто-императивном коде без «примочек» придется писать try/catch в каждом ContinueWith. Код становится менее читаемым, exit points «размазываются» по разным callback'ам и их приходится «собирать». Основная проблема такая.
  • «Паттерны» функционального программирования
    0
    del
  • «Паттерны» функционального программирования
    0
    Стиль изложения материала у автора намеренно упрощен, его даже обвиняют в популизме. При переводе я не стал корректировать, потому что тогда получилось бы уж совсем вольное изложение по мотивам, а это и так рерайт.
  • «Паттерны» функционального программирования
    –1
    «react+redux» не имеет никакого отношения к ФП
    и
    У Редакса есть элементы ФП. Код там процедурный. Диспатч — процедурный. В языке С sqrt — тоже чистая функция, которая не изменяет свой аргумент, но от этого весь язык не становится функциональным

    Спорите со мной уже вы про Абрамова. А оригинальный вопрос был:
    Вот например какие паттерны мне надо применить при проектирование GUI библиотеки?

    React и Redux — это примеры применения элементов ФП в UI-библиотеках. Это максимально точный ответ. В комментариях мне пишут, что «react и redux не имеют отношения» а потом «содержат элементы».

    Содержать элементы уже != иметь отношение?

    Очевидно, что react и redux — не хаскель. Это никто утверждать не будет. Кстати, если перейти на ссылку с видео то там он утверждает ровно тоже самое «redux использует идеи функционального программирования. Они не новые».

    Суть вопроса «какие есть примеры ФП в UI» уже утратила актуальность. В ветке мы обсуждаем недобросовестный маркетинг и девочек.

    вы признаете, что были неправы?

    В чем конкретно я не прав? Может и признаю, пока не понял.
  • «Паттерны» функционального программирования
    –2
    По-моему, вы просто переходите на личности. Ну не нравится он вам и все. Остальное уже не важно, главное похейтить. Вот вам не нравится его pr. Вы делаете pr на хейте Абрамова. У него хотя-бы не вторично.
  • «Паттерны» функционального программирования
    0
    … ни одна функция из определенных в обсуждаемом тексте не имеет явной сигнатуры! Тут не то что о наличии «красных путей», тут в принципе о типах аргументов и возвращаемых значений надо догадываться!

    В статически-типизированных все хорошо с сигнатурами, просто их можно опускать, потому что вывод типов работает лучше. Но можете и объявлять везде.
  • «Паттерны» функционального программирования
    0
    Вы вырываете из контекста. Я сослался на мейнтейнера. У меня к redux много вопросов, особенно к процедурному стилю. Приходится писать очень много boilerplate или не идиоматичный redux'у код (проблема с обучением новых сотрудников).
    «react+redux» не имеет никакого отношения к ФП.

    Вы и другие участники ветки уже признали, что отношение есть: react / redux используют элементы ФП. Очевидно, что в них много побочных эффектов, потому что в web-ориентированном UI по-другому быть вообще не может.

    В JS идеи начали просачиваться в том числе из-за проблем с data-flow и callback hell. Оказалось, что есть продолжения и с ними все попроще. А вот монады в JS пока никому не нужны, потому что никто целей чистоты, как в хаскеле не ставит.

    Есть проблема — асинхронный код, который есть в 90% приложений и необходимость его как-то поддерживать и развивать. Есть решение — промисы. Копнули чуть дальше, оказывается еще и чистые функции есть. Подход прагматичный и инструментальный.
  • OO VS FP
    –1
    Аналогично «виртуальный метод» — паттерн для процедурных языков, но для ООП уже есть простое готовое решение.
    А, в ФП некоторые фичи встроенные в язык заменяют ООП-паттерны (стратегия, декоратор).

    Не смотря на свойственную Мартину сварливость в статье есть коротко-сформулированный и важный тезис: ФП и ООП — вещи не взаимоисключающие, а наоборот — дополняющие.
  • «Паттерны» функционального программирования
    +1
    Вы не поверите, это юмор:) Лисп — старейший из «выживших» ЯП. На коболе и фортране никто уже нового не пишет, а Clojure — это современный диалект Лиспа.
  • OO VS FP
    0
    У него консалтинговая компания. Есть клиенты, вероятно собирают статистику. Если бы совсем не работало, наверное со временем его услугами перестали бы пользоваться. С моим опытом большинство утверждений Фаулера согласуются. Конкретные цифры конечно подтвердить не могу.
  • «Паттерны» функционального программирования
    –1
    Вы по ссылке пройдите все-таки. Там ещё один полуторачасовой доклад, посвященны этой теме. С примерами и доскональным разбором как же эта магия работает. Продолжительность доклада «паттерны фп» — ещё полтора часа. Если тема будет востребована, я могу попробовать собраться с силами и перевести и его:)
  • «Паттерны» функционального программирования
    0
    Я целенаправленно скачал лекции по лябда-исчислению и даже посмотрел первые три. Кому как, конечно, но мне с вишенками и яблочками «заходит» лучше. Для математики такие аналогии смехотворны. Но мы же программы пишем, а не теоремы доказываем.
  • «Паттерны» функционального программирования
    0
    Ошибки там не игнорируются. Возвращается первая ошибка, дальше выполнение не идет. Druu верно отметил: есть разница между Maybe и Either. Кстати, Скотт не кисло глумится над тем, как обычно объясняют монады апологеты ФП и какое впечатление это производит.
  • «Паттерны» функционального программирования
    +1
    В данном случае проблема вообще в нарушении SRP изначально как мне кажется. Исключения и доступ к БД уже сверху наложились.

    Если бы валидация была чистой функцией и если бы ее потрудились выделить в отдельный класс, а необходимые данные загружались бы из бд на основе спецификаций через QueryObject, инжектируемого через интерфейсную ссылку с помощью IOC-контейнера, то мне бы осталось только немного перекомпоновать код и распараллелить. Но этого не случилось.

    В данном случае есть «правильный» вариант (болты). Нужно было их сразу ставить. Была бы дополнительная сложность, кривая обучения, но я заметил, что по примеру джуниоры копипастят код разного качества примерно с одной эффективностью. Лучше учить копипастить сразу хороший:)

    Я строго на стороне дяди Боба: ФП и ООП — инструменты, не заменяющие, а дополняющие друг-друга. Полезно знать и применять при необходимости приемы и той и другой.

    На мой взгляд ФП поднимает ряд вопросов, традиционно игнорируемых ООП-сообществом: формальное доказательство корректности программ (вместо решения задачи численным методом: юнит-тестами), точное определение возможных случаев и реакций на них. С помощью Either можно перенести проверку на этап компиляции с рантайма. Как известно, чем раньше найдена ошибка, тем дешевле ее поправить.

    Практическая применимость и tool-support таких концепций — отдельный вопрос. Я не считаю, что IO — супер-элегантное решение проблемы ввода-вывода в хаскеле: «посмотрите это выглядит как императивный код, но это не он»:)