ITnan

Все публикации Хабрахабр и Гиктаймс в одном месте
Выбран стиль: blue



Выбран хаб Open Source


  1. EvilBeaver
    /#19635436

    Вы скучаете по этому времени, или радуетесь, что оно прошло?

  2. Kroid
    /#19635434

    Ну, если на то пошло, первая строка читается почти как нормальное предложение, слева направо.

  3. safari2012
    /#19635404

    Это же всё "народные движения"...

  4. safari2012
    /#19635402

    Это подростки, в основном. Много с них не возьмёшь:)

  5. Groramar
    /#19635400

    Поговаривают, что MS недурно наехала на Борланд, когда та начала плотно продвигать Кайликс. Нужно было кровь из носу продвигать свой дотнет. И тут под Линукс появляется мега-тул быстрой разработки. В то время на рынке ничего даже близко сравнимого просто не было. Ну и результат мы все знаем.

  6. EasyLy
    /#19635394

    Попробовать на перемычке TIO и ICP?
    Кстати, чисто к слову. У PSoC есть две очень приятных особенности по сравнению с обычными контроллерами

    1) Если мы хотим соединить ножки — мы это просто через внутреннюю коммутацию делаем. Точнее, мы соединяем сигналы, а ресурс «ножки» при этом не расходуется.

    2) Не надо думать о схождении пасьянса ножек. Я когда перетаскивал Marlin с Ардуино на STM32, долго и упорно раскладывал пасьянс, ведь часть ножек может быть выходом таймера, часть — входами АЦП, часть — SPI, часть — UART, причём часто на одной ноге может быть часть функций на выбор, а одна функция выбрасывается всего на 2-3 ножки. Короче, пасьянс я раскладывал долго. А тут всё через трассировку делаем. Какую ножку на функцию назначили, на ту нам и выбросят сигнал. Ибо всё-таки простенькая, но ПЛИС внутри. Теоретически, даже аналоговая коммутация есть, но на практике не проверял, только видел, что сопротивление будет килоомное.

    Но это так, просто к месту высказывание. Само собой, за это надо платить. Причём рублями. При равных ядрах Cortex M3 в PSoC5LP и STM32F103, первый дороже. Но если его уж по тем или иным причинам взяли, то эта особенность очень греет душу.

  7. drai3
    /#19635392

    С моей точки зрения React Context можно и нужно использовать как дополнение к, например, Apollo (если не хочется использовать apollo-link-state) для хранения простых состояний каких-либо фильтров/переключателей. Это избавит вас от своих велосипедов и решит проблему стора средствами самого реакта.

    Если действительно нужен гибкий, масштабируемый стор, то mobx/redux или какие-либо event-driven модели конечно же выглядят намного более подходящим решением.

  8. BuPy7
    /#19635378

    лучшей архитектурой

    Кто сказал?


    более продуманным API

    С чего Вы взяли?


    лучшей документацией (она как минимум есть)

    Допустим, но какая она и дает ли она ответа? У Zend Framework тоже есть документация, но люди все равно читают исходники.


    меньшей когнитивной нагрузкой на новичков в проекте (не нужно читать исходники реализации)

    Никогда документация не отражала сути вещей, а только базовые возможности. Не читать код нереально.


    и наконец, большей надежностью

    Кто Вам сказал? Почему Вы так уверены, что там нет какой-то заподлянки.


    Все ваши утверждения надуманны и никто никаких гарантий не дает.


    А мой велосипед будет выполнять необходимые задачи и от него больше ничего не требуется. И да, я публикую их время от времени.

  9. gnaeus
    /#19635366

    В итоге мобх методы превращаются в смесь из бизнес действий и переключения состояния

    Ну, на бекэнде эту проблему давно решили разделением на DomainLayer (переключение состояния модели) и BusinessLayer (эффекты). Кто мешает сделать такьв MobX?

  10. gnaeus
    /#19635364

    Но в нем ничего не говорится про изменение состояния, которое распространяется по дереву с помощью контекста. В итоге при достаточно большом приложении мы придем к аналогу Redux с несколькими сторами.