Comments / Profile of kogoia / Habr

kogoia Feb 10 2018 at 10:27

Есть ещё много таких:
fable.io
bridge.net

но это всё не то.

kogoia Feb 9 2018 at 22:42

Да это уже давно, я имел в виду что сам реакт на шарфе напишут. Идея виртуального дума очень прикольная, иммутабельностьб компоненты и всё такое. Скоро запилят API чтоби с WASM c DOM-ом общаться или что то в этом направлении. Помнию читал где то статеику про такое.

kogoia Feb 9 2018 at 12:43

В этом интервью об этом есть немного
WebAssembly with Brendan Eich

kogoia Feb 9 2018 at 11:29

Вах какой новост!!!
Будет интересно когда другие платформы вступят в гонку. Не удевлюсь если React как ViewEngine на .NET появится, а «back-end в front-end»-е ASP.NET Core оставят :) Или можно ещё помечтать и WPF во всей красе увидеть. А если приглядеться ещё к этой новости Welcoming Progressive Web Apps to Microsoft Edge and Windows 10, то могут наверное чудеса произойти.

Шаблон проектирования «состояние» двадцать лет спустя

kogoia Oct 30 2017 at 10:59

Статья на хорошую тему. Я думаю одна из важных моментов при проектировании предметной области. («Make illegal states unrepresentable»)

Мне больше нравится с Union Type.

Есть TabType, который реализован с помощю Uniont Type-а.
Есть Tab у которого 3 состояния: DefaultTab, ClosedTab, OpendTab и соответствующие интерфейсы.

А вот переход из одного состояния в другое.

kogoia Jul 10 2017 at 16:16

Понятно что люди во нениях не часто сходятся, но просто выражать не довольство без мнении, как то странно. Может я в праде чушь несу и есть решения иные, по лучше.

Пусть высказываются сначало хотябы :)

kogoia Jul 10 2017 at 13:44

Просто хотел поделиться каким методом я добиваюсь такого

kogoia Jul 10 2017 at 12:11

Да правда в перекос, я согласен что вместо использования object аргумента лучше использовать generic, тот коментарий так для разнообразия.

kogoia Jul 10 2017 at 11:49

Вам ещё расти:)

kogoia Jul 8 2017 at 15:34

Использование проверок на Null, нужно стараться вообще исключить из кода. Не передавать ни в качестве аргумента в методы ни ожидать в параметрах конструктора. Если такое случается это повод задуматься об дизаине кода. Скорее всего проблема в нём. Вот как я обхажусь без всего этого:

В принципе это Maybe, но чуть изменённая под себя.

Я определяю два интерфейса и наследую их от IEnumerable:

public interface IOptional<T> : IEnumerable<T> { }
public interface IMandatory<T> : IEnumerable<T> { }

Это может показатся странным, но даст нам возможность делать прекрасные вещи :)

Далее я деляю два класса и наследую их от этих интерфеисов:

public class Some<T> : IOptional<T>
{
    private readonly IEnumerable<T> _element;
    public Some(T element)
        : this(new T[1] { element }){}
    public Some()
        : this(new T[0]) {}
    private Some(T[] element)
    {
        _element = element;
    }
    public IEnumerator<T> GetEnumerator()
    {
        return _element.GetEnumerator();
    }
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

public class Just<T> : IMandatory<T>
{
    private readonly T _element;

    public Just(T element)
    {
        _element = element;
    }
    public IEnumerator<T> GetEnumerator()
    {
        yield return _element;
    }
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

Несколько вспомогательных статических методов как Exstensions к этим интерфеисом:

public static class LinqExtensions
{
    public static IMandatory<TOutput> Match<TInput, TOutput>(
        this IEnumerable<TInput> maybe,
        Func<TInput, TOutput> some, Func<TOutput> nothing)
    {
        if (maybe.Any())
        {
            return new Just<TOutput>(
                        some(
                            maybe.First()
                        )
                    );
        }
        else
        {
            return new Just<TOutput>(
                        nothing()
                    );
        }
    }
    public static T Fold<T>(this IMandatory<T> maybe)
    {
        return maybe.First();
    }
}

Их можно било определить в самих интерфеисах и сделать имплементацию в соответственныйх классах, но здесь показываю как пример, а так можно ещё пару интересных методов добавить.

А теперь можно творить такие вещи:

var five = new Just<int>(5);
var @null = new Some<int>();

Console.WriteLine(
            five
                .SelectMany(f => @null.Select(n => f * n))
                .Match(
                    some: r => $"Result: {r}",
                    nothing: () => "Ups"
                )
                .Fold()
        );

Вот так, немного фукциональной парадигмы здорого выручает, даже не нужно объястять Монады, а она здесь присутствует. (SelectMany)
Всё легко и просто :)

Пять книг по программированию, которые стоит прочесть

kogoia May 16 2017 at 11:21

Можно расширить список :)

Чтобы менеджмент на голову не садился

The Clean Coder by Robert Cecil Martin

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

Elegant Objects by Yegor Bugayenko

Для коллаборации команды и разруливания говнокода в монолитных проектах

Domain-driven design by Eric J. Evans

Чтобы иметь представление как организовывать высоконагруженные проекты и предоставлять клиентам

Building Microservices by Sam Newman

Тут можно ещё добавить про SCRUM и TDD, остальное практика
Также очень подтягивает изучение другой парадигмы, углубление в алгоритмы и куда же без Математики :)

Функциональное программирование: в Java и C# слишком много церемоний

kogoia May 5 2017 at 16:00

Если вы посмотрите на объектно-ориентированный код, там будут какие-то переменные, какие-то данные, потом их куда-то посылают, и ко всему этому осуществляется доступ из многих потоков.

По моему это не про ООП, а о том, как многие его неправильно используют. :)

О функциональном программировании в фронтенде

kogoia Mar 20 2017 at 23:24

Ну так приведите пример, где это не выглядит избыточным. Зачем нам плохие примеры?

Выглядит сложным и избыточным, совсем не означает, что он таким является. Ключевое слово «выглядит». А плохим примером, он вовсе не является и я такого не писал. Раз этот для вас плохой, может просвятите хорошим примером?!

Угу. Накладные расходы посчитайте.

Там был и второй вариант, но мне и первый нравится. Можете придумать свой и посчитать.

Вам не нужны переходы из каждого состояния в каждое — только валидные.

Я сказал что если состоянии N количество, то возможность всех переходов N * (N-1). Ключевое слово «возможность».

Серьезно?

Да преставте себе такое, не трудно.

new Sum(x, y).Result()

Для того, чтобы воссоздать конечный результат, нужно знать, каким условиям он удовлетворяет (а они зависят от предыдущих условий).

Вот именно, нужно знать, каким условиям он удовлетворяет и я опишу это конечное состояние, удовлетворяя эти условия, а не путь как до него дойти с предыдущего состояния.
Императивный код всегда можно спрятать под красивую абстракцию. (Это чтобы вы не подумали что я всегда буду писать декларативно и не буду пользоваться if-ом или о чём вы там подумаете). Если поддерживаемость кода важна, то к такому всегда нужно стремиться.

(кстати, интересно, как машины состояний пишутся на прологе)

Да мне тоже интересно, могли бы вы привести пример, а не писать раздражающие комментарии?!

О функциональном программировании в фронтенде

kogoia Mar 20 2017 at 20:51

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

А может кадый раз содаётся новая вселенная когда её состояние меняется?! Или их изначально безконечное количество, а момент набудения реализует его в конкретном состоянии. )) Это в шутку.

А вообще гараздо легче создать всё заного, чем задавать переход от каждого состояния в другое. Ведь если состоянии N количество, то возможность всех переходов N * (N-1). А создание всех возможных состоянии изначально, дает возможность описать программу декларативно. Будет писаться, не как доидти до конкретного состояния, а просто потребовать воссоздать конечный результат.

Хорошим примером здесь будет, то как React подходит к решении этой проблемы в фронте.

Кароче суть одна и та же, как я считаю.

О функциональном программировании в фронтенде

kogoia Mar 19 2017 at 22:49

В ООП тоже никто не отменял иммутабельность.

Я бы так переписал приведённый пример:

    public interface IDoor 
    { 
        IDoor Open();
        IDoor Close();
        bool Locked();
    }

    public class OpendDoor: IDoor 
    {
        private readonly string _color;
        private bool _isOpend = true;
        public OpendDoor(string color) 
        {
            _color = color;
        }

        public IDoor Open() 
        {
            return this;
        }

        public IDoor Close() 
        {
            return new ClosedDoor(_color);
        }

        public bool Locked() 
        {
            return !_isOpend;
        }
    }

    public class ClosedDoor: IDoor 
    {
        private readonly string _color;
        private bool _isOpend = false;
        public ClosedDoor(string color) 
        {
            _color = color;
        }

        public IDoor Open() 
        {
            return new OpendDoor(_color);
        }

        public IDoor Close() 
        {
            return this;
        }

        public bool Locked() 
        {
            return !_isOpend;
        }
    }

    var myDoor = new OpendDoor("red");
    myDoor = myDoor.Close();

Почему мы выбрали Vue.js (а не React)

kogoia Mar 6 2017 at 12:41

начни с этого

Идеальный программист. Часть 2

kogoia Dec 18 2016 at 18:42

Помню как то менеджеру скинул эту книгу, месяц за ним гнался, спрашивая прочситал ли что-нибудь :D
Кароче, нужна вторая книга «Как заставить менеджера прочитать <<Идеальный Программист>>»