Попытаюсь перефразировать. Инженер как и любой другой человек подвержен заблуждениям и предрассудокам из-за которых сложно трезво оценивать технологии. Если мы всю жизнь использовали goto, то нам сложно признать что это было ошибкой. Такой эффект известен в психологии как эскалация обязательств [1].

Вопрос в том, как замечать такое поведение и избегать его. Хороший подход — смотреть за авторами технологий и гигантами индустрии. Если изобртатель технологии смог перешагнуть через свою гордость и признать ошибку, то вероятно что-то дейсвительно с ней не так. Ссылки выше были как раз про это. Tony Hoare придумал null ссылки, Erich Gamma и Ralph Johnson — синглтоны.

Я согласен, что каждому инструменту — свое назначение, просто назначение некоторых инструментов — отправиться на свалку истории :)

Забавно что вы упоминули спутники, вот тут [2] пишут что там как раз используют наработки сэра Tony Hoare и наисвежайшие идеи, такие как TLA+. В общем, не держитесь за то, что уже доказало свою несостоятельность.

[1] https://en.wikipedia.org/wiki/Escalation_of_commitment
[2] http://www.altreonic.com/content/main-mission-rosettas-philae-lander-accomplished

Я написал пару постов про Paxos и про измемение размера кластера. Если кратко, то я объединил подход Vertical Paxos (разные кворумы на чтение и на запись) с joint consensus Raft'а:

• How Paxos works
• Read write quorums in Paxos
• Best of both worlds: Raft's joint consensus + Single Decree Paxos

До TLA+ руки еще не дошли, но я попрактиковался в ручном теоремодоказательстве и привел его в статьях, упомянутых выше. Буду рад вопросам :)

Как ведет себя система при split brain и падениях отдельных узлов?

В Индии в основном договорные браки, так что девушка с детства может знать, за кого она выйдет.

Это сложно описать, но в Индии чувствуется многообразие, полнота и черезмерность жизни. Это касается как природы, так и традиций, культуры, еды. В Таиланде с природой все хорошо, но культурное многообразие не такое большое. Индия же воспринимается, как сама жизнь, колыбель цивилизации, по сравнению с ней, все остальные страны, где я был, — воспринимаются немного мертвыми. Например, Финляндия воспринимается вообще как страна, которая пережила нашествие зомби.

Шифровать данные — законно, правительство (США) не может потребовать их расшифровать, так как это противоречит 5ой поправке.

Прежде, чем писать, стоит задуматься, каково должно быть это единое мнение и может ли оно быть вообще? Единственная наука, где старые теории не пересматриваются это математика, что было верно 100 лет назад — верно и сейчас, а так же будет верно всегда. В остальном же, в любой момент могут появится новые данные; поэтому вынести окончательное мнение по чему-то невозможно.

Например, мультивитамины — annals.org/article.aspx?articleid=1789253 — до последнего времени считались полезны.

Кроме того, полезность — очень размытое понятие. Морфий, с медицинской точки зрения очень полезен, так как помогает спасать жизни. Но, в тоже время, в больших дозах он летален, а рекреационное использование приводит к проблемам как у самого человека, так и у его окружающих. Так полезен морфий или нет? К какому единому мнению пришли медики? Так же и конопля, медики подтверждают медицинским использованием, что в медицинских целях она полезна.

А можно ли её использовать в рекреационных целях это совсем другой вопрос, кроме того, вряд ли медики имеют здесь вес. Так как доказано разрушительное воздействие алкоголя на организм; спорная позиция по поводу малых доз алкоголя очень зыбка, если это и так, то эта «польза» может быть достигнута другими средствами (у алкоголя нет монополии); а раз так и сама польза под вопросом, то, с медицинской точки зрения, логично не использовать алкоголь вовсе.

P.S. Я не укурок, а logic nazi. Конопля полезна, медики это признали, но из этого совсем не следует, что нужно её использовать в рекреационных целях.

Это не так. Здесь — www.cancer.gov/cancertopics/pdq/cam/cannabis/healthprofessional/page5 — можно найти ссылки на медицинские статьи, в которых описывается применение различных каннабиноидов как дополнение к лечению рака. Эти каннабиноиды используются для:

• снятия беспокойства
• устронения тошноты
• стимуляции аппетита
• обезболивания

Помимо этого, рядом — www.cancer.gov/cancertopics/pdq/cam/cannabis/healthprofessional/page4 — описывается, что каннабиноиды сами по себе имеют противоопухолевое действие.

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

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

Поэтому не надо говорить, что медики про пользу ничего не говорят.

P.S. Я против употребления конопли там, где это противоречит законодательству

Спасибо за упоминание (я про Warp9), с момента статьи на хабре я немного изменил внутренности (переключился на явный граф зависимостей) это позволило избежать проблем, характерных для многих реактивных библиотек. Например, с помощью Knockout легко:

• создать текущее по памяти приложение
• нарваться на экспоненту при repeated diamond shape problem
• наблюдать неконсистентное состояние

Так как у вас система основана на идеях, близких knockout проверьте эти сценарии на своей библиотеке, возможно и у вас есть, что исправить :)

Со спуском данных в компоненты (state) проблем нет, но если мы нашу иерархическую фигню, не только показываем и редактируем, но и сохраняем, то тут нужно писать дополнительный код в компонентах для экстракции данных из state.

Получается, что в небольших приложениях мы можем держать всю модель в state одного компонента (случай TodoMVC), а в больших — придется его распиливать и доставать. В этом нет ничего плохого, просто кода станет еще больше, а так React классный.

Я, кажется, в презентации это упоминал — у реактивный переменных, полученных иначе, чем через вызов конструктора, нет методов set/unset (если это Cell) и add/remove (если это List).

О, тогда Warp9 действительно похож на Javelin+Hoplon. Правда сложность инструментария меня убивает — нужно поставить Java, Clojure, Leiningen, Make, Boot, Hoplon, Javelin и выучить clojure чтобы написать hello world. Как-то уже не хочется проверять его на текучесть, но, подозреваю, что он тоже течет.

По поводу AngularJS. Нет, ну нельзя сказать, что мы используем templateUrl и проблем нет. Потому что в этом случае мы не имеем права говорить:

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

Разница между подключением одного файла (js) и двух файлов (js и шаблон) огромна. В первом случае мы можем говорить про удобную дистрибьюцию, например, AMD, во втором нет — все делаем вручную. Кроме того, во втором случае перед нами открывается целый класс новых ошибок: что если один файл потеряется, что если файл шаблона я положу не туда куда нужно и так далее…

По поводу стилизации, да можно, но пока, к сожалению, можно добавить только один класс элементу. Это не фундаментальный недостаток, просто руки не дошли пока — большую часть разработки я боролся с утечками и несогласованностью событий. Пример с input-text можно переписать так:

["input-text", {
    "class": hello.isSet().when(false, "empty")
}, name]

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

Вы, ваще-то, пробовали его запускать? Там нету чекбоксов, нету информации, сколько осталось задач, нету табов 'All', 'Active', 'Completed', нету удаления всех завершенных задач, нету редактирования и, подозреваю, что нету работы с local storage…

Мне кажется, что эти два преимущества друг другу противоречат: при разработке директив активно смешиваются код и разметка, а если так, то где разделение труда?

Кроме того, в сложном приложении трудно разделить логику и шаблон, особенно, когда интерфейс активно меняется из логики, а если так, то зачем создавать себе дополнительные сложности, может есть другой путь?

Не совсем. Я, скорее, думал про случаи, когда логика приложения сложнее, чем интерфейс. Возьмем, допустим gmail, врят ли при его разработке отталкивались от верстальщика. Вообщем, это библиотека для приложений посложнее CRUD.

Я, например, создал приложение для конфигурации топологии MongoDB кластера с помощью этой библиотеки, а там куча всяких правил, типа в одной шарде должно быть от 2 до 12 нод, только 7 могут голосовать, лучше намекать пользователю, когда он вручную назначает свойства canVote при числе нод меньше 7ми и так далее.

В смысле, странный? Я считаю то, что течет — подписки у переменной driver, если я начну считать что-то другое (кол-во элементов в списке), то memory leak от этого никуда не денется.