Прям как в хромиуме. Да и что вам эти дырки? Вы их использовать собрались что ли?
Нет, я хочу, чтобы платформу, которую я использую не приходилось обновлять раз в неделю, потому что в ней нашли критический Security баг.
Закрытый код чего? Компилятора?
Да, компилятора и инструмента. Я, как разработчик, хочу видеть и разбираться как оно работает внутри. Это даст мне больше понимания как написать эффективное приложение.
Тоже самое для плюсов вас не смущает (да, я знаю о последних редакциях, но там мало чего юзабельного из нового).
Почитайте мои ответы повыше, на «чистых» плюсах писать в 2-3 человека мы будем много лет. Поэтому, естественно, мы смотрим в сторону фреймворков.
Вы серьёзно? По вашему скомпилированный двоичный байт-код будет работать медленее, чем реал-тайм интерпретатор от браузера?
Это только мое предположение, на основе использования (не разработки) флеша под браузером. Всякие плееры отъедают достаточно много памяти и лично на моем компьютере HTML5 video player работает быстрее флешевой реализации (опять таки не мерял конечно, сугубо субъективно).
И непонятно, то вам «сугубо Enterprise» нужно, то чтоб красиво было.
А что Enterprise решения должны быть корявыми и неудобно выглядеть? Стандарт что ли такой есть? Посмотрите в сторону, например, Atlassian. Они делают Enterpise решения и они очень неплохо выглядят.
Xamarin только недавно ушел в просторы бесплатного ПО, надо будет его тоже поглядеть.
Проблема кроется в головах на самом деле. Мы закажем дизайн, мы его согласуем с функциональными фичами, даже на макет его распилим… И вот, когда мы его отдадим программисту-плюсовику, тут то и окунемся по полной в проблемы. На выходе я боюсь увидеть монстра, потому что «это очень сложно сделать на QT» или «ну ведь так же нормально, вон большинство программ так выглядит»…
Не хочу никого обидеть, но еще не видел вживую программиста, который мне хороший (и поддерживаемый) интерфейс на плюсах соорудит. А такие спецы есть, судя по приложениям :)
Вот тут правильно подмечено, что плюсы неплохо сюда подходят. Остается одна проблема — внешний вид и поддержка GUI.
Если хотим кроссплатформу, нужно что то вроде QT. Но поискав хорошего программиста на QT я сильно приуныл: во-первых их мало, во-вторых из те кто остался не найдешь хорошего «программиста интерфейсов».
Я думаю со мной все согласятся, что приятно работать и использовать удобную (эргономичную в хорошем смысле слова) и красивую (внешне) программу. Поэтому альтернатив HTML+JS интерфейса и логики на node.js я не вижу. Возможно сочетание с хромом не такое выигрышное конкретно у электрона, может быть Microsoft когда нибудь подтянут Edge в эту же среду, но пока я бы радовался и тому что есть. Проект активно развивается, о нем много пишут и поддерживают технологические гиганты.
Так что повторюсь, альтернатив Electron/nw.js нет.
Хотел написать саркастический комментарий, но не стал, раз наш тред без сарказма.
Флэш уже сильно устарел морально — куча дырок (см. ленту хабра), закрытый код и, по сути, мертвый неразвивающийся проект. К тому же, мне не нужна платформа нацеленная на анимацию и графику, приложение сугубо Enterprise.
К слову, я не думаю, что флэш будет выигрывать или иметь преимущества перед тем же электроном по быстродействию.
А можете мне предложить альтернативу? Требования:
1) Единая кодовая база и GUI на платформах Mac, Linux, Windows, веб-сайт и экзотика (QNX к примеру).
2) Команда из 2-3 человек.
3) Работать должно на скромных по ресурсам машинах (до 512МБ оперативы).
4) Времени размусоливать на разных языках нет — к моменту релиза решение морально устареет, надо будет заново переписывать.
Спасибо, отличная статья! Не думали выложить исходный код? Мне кажется на примере таких игр (и такого кропотливого подхода к созданию) можно учить молодёж :)
В принципе можно было бы поставить логирование времени на входе выполнения в MyBatis и на выходе с учетом кеша.
Вход понятен где — это вызов метода маппера.
В методе по выборке из кеша это второе время.
После вызова маппера это третье время.
Работу самого MyBatis'a в данном случае можно пренебречь. Уже тремя этими параметрами можно как то манипулировать и делать выводы.
Кстати, у Вас все виртуальные машины расположены локально? Если да, то имеет смысл их разнести на разные машины в рамках локальной сети, это будет еще ближе к "боевым" измерениям (потери на сетевом транспорте).
Эка вы как классно профилируете запросы! Я так тоже умею — можно несколько раз позапускать запрос в SQL Developer и он закешируется в самой оракл и никакой MyBatis 2 Level Cache не нужен :)
Если серьезно, MyBatis кеш конечно помогает и выручает, но профит посчитан неверно.
Извиняюсь за оффтоп, но не могу не спросить. Ваша замечательная библиотека https://github.com/tamtakoe/oi.select планирует дальше развиваться? Мы ее используем в своих проектах, но хотелось бы решение некоторых тикетов. И кстати спасибо за труд :)
Вообще так и делал, но показалось не слишком удобно, особенно когда нужно не просто разделить данные, а реагировать на их изменение.
С реакцией на изменения будет чуть сложнее. Тут надо определится кто инициатор изменений и где и как их надо ловить. Из этого и строить этот интерфейс. Но в целом, тоже не так уж и сложно. И кстати, можно вполне обойтись без коллбеков. В директивах есть $watch (он как раз тут подойдет), в котором будут вызываться методы интерфейса для передачи значения в интересующий модуль.
Костыль для скорости — это one-time binding в первом ангуляре, который {{:: foo }}. А one-way data flow — это архитектурное решение.
А в чем разница? Сам React пишет "React's one-way data flow (also called one-way binding) keeps everything ..." По мне, так это одно и то же. В ангуляр это добавили не как костыль, а как решение проблем с подходами двустороннего связывания (там, где оно не требуется).
Насколько я понимаю абстрактная проблема с двусторонним связыванием та же, что и с глобальными переменными. Есть у вас какая-то переменная в VM которая связана с несколькими элементами UI и может меняться с сервера, допустим. И вот эти элементы и сервер одновременно её меняют, как это разрулить? А никак, т.к. логика связывания неявно зашита где-то в глубинах фреймворка.
Не встречал такого мнения, заберу в копилку. Может кто то сталкивался уже с такой проблемой? Имхо, она решается достаточно просто (обычные merge-стратегии).
Имею ввиду все эти ng-директивы: циклы, условия и пр.
Ну строго говоря, они работают по спецификации HTML, т.е. на атрибутах и тегах. В нашем случае есть html (шаблоны) и есть js (логика), для связи которых нам нужен бридж. Мне сложно представить, как это можно было бы сделать иначе.
В Ангуляре 1, мне кажется, очень неудобно связывать между собой директивы, расположенные «на одном уровне», т.е. не вложенные. Может подскажете как вы такие проблемы решаете? Только без событий в $rootScope.
Рискну предложить Вашему вниманию свою статью. В рекомендациях я привел пункт 2, который подойдет для решения такой задачи. Вкратце — общение должно происходить через сервис, который будет своего рода интерфейсом взаимодействия между разными частями приложения и компонентом. Интерфейс лучше, потому что он понятен и точно инкапсулирует логику, т.е. наружу дает только тот функицонал, который нужен. При этом мы не связываем код, потому что этот сервис, можно инъектить в любую сущность ангуляра.
В реальной жизни оставлять шаблоны чистыми не получится. Логика все равно будет, если у вас что-то серьезнее Hello World.
Мне это в жизни не мешает, если я вижу логику в шаблоне — я ее выношу в контроллер или директиву (для того они в Angular 1.x и придуманы).
Идея собственного языка для первого Ангуляра была ужасной.
Не очень понял, про какой язык речь?
Кстати, выражение «бороться с фреймворком» я первый раз узнал именно читая о первом ангуляре.
Не холивара ради, знаете Реакт? Там можно писать на JS в любом месте шаблона. И почему-то это не мешает, а только упрощает жизнь.
Да, я тоже узнал об выражении «бороться с фреймворком» именно в контексте ангуляра. И знаете какой я для себя вывод сделал? Люди, кто так писал, как правило, не понимали как работает фреймворк. Они не понимали структуры, использовали $rootScope где ни попадя, кидали события где только можно — короче сами себе раскладывали грабли, чтобы об них потом биться. Поэтому я считаю это утверждение людей, для которых javascript заканчивался на jquery и они старались все те подходы, которые использовались там перенести на Ангуляр. При этом, конечно, я не отрицаю проблем самого Ангуляра (например, дебаг который реализован отвратно).
Что касается реакта, то да, я его пробовал. Он мне напомнил ExtJs, но я ни тем ни другим не проникся. Я не увидел структуры в коде и удобного его построения (в первую очередь для последующей поддержки и переиспользования). Но это все имхо, я больше адепт Java и люблю все стройное и разделенное :)
В таком случае, это не из разряда "правильное/не правильное". Смена подхода просто помогла решить проблему фейсбука в своем фреймворке, вот и все.
Вопрос не праздный я задавал. Мне тут с пеной у рта доказывали, что one-way биндинг это костыль, чтобы ангуляр работал быстрее. Теперь вот оказывается, что one-way биндинг это "правильно"… Во всех этих спорах я не вижу ни одного аргумента, который смог бы принять, к сожалению.
Имхо, шаблоны должны оставаться по максимуму "чистыми" от логики. Хочется если что-то мелкое написать, можно это сделать через компонент (контроллер в Angular 1.x). Я не вижу проблемы, почему надо добавлять или менять сложившееся поведение.
Нет, я хочу, чтобы платформу, которую я использую не приходилось обновлять раз в неделю, потому что в ней нашли критический Security баг.
Да, компилятора и инструмента. Я, как разработчик, хочу видеть и разбираться как оно работает внутри. Это даст мне больше понимания как написать эффективное приложение.
Почитайте мои ответы повыше, на «чистых» плюсах писать в 2-3 человека мы будем много лет. Поэтому, естественно, мы смотрим в сторону фреймворков.
Это только мое предположение, на основе использования (не разработки) флеша под браузером. Всякие плееры отъедают достаточно много памяти и лично на моем компьютере HTML5 video player работает быстрее флешевой реализации (опять таки не мерял конечно, сугубо субъективно).
А что Enterprise решения должны быть корявыми и неудобно выглядеть? Стандарт что ли такой есть? Посмотрите в сторону, например, Atlassian. Они делают Enterpise решения и они очень неплохо выглядят.
Проблема кроется в головах на самом деле. Мы закажем дизайн, мы его согласуем с функциональными фичами, даже на макет его распилим… И вот, когда мы его отдадим программисту-плюсовику, тут то и окунемся по полной в проблемы. На выходе я боюсь увидеть монстра, потому что «это очень сложно сделать на QT» или «ну ведь так же нормально, вон большинство программ так выглядит»…
Не хочу никого обидеть, но еще не видел вживую программиста, который мне хороший (и поддерживаемый) интерфейс на плюсах соорудит. А такие спецы есть, судя по приложениям :)
Если хотим кроссплатформу, нужно что то вроде QT. Но поискав хорошего программиста на QT я сильно приуныл: во-первых их мало, во-вторых из те кто остался не найдешь хорошего «программиста интерфейсов».
Я думаю со мной все согласятся, что приятно работать и использовать удобную (эргономичную в хорошем смысле слова) и красивую (внешне) программу. Поэтому альтернатив HTML+JS интерфейса и логики на node.js я не вижу. Возможно сочетание с хромом не такое выигрышное конкретно у электрона, может быть Microsoft когда нибудь подтянут Edge в эту же среду, но пока я бы радовался и тому что есть. Проект активно развивается, о нем много пишут и поддерживают технологические гиганты.
Так что повторюсь, альтернатив Electron/nw.js нет.
Флэш уже сильно устарел морально — куча дырок (см. ленту хабра), закрытый код и, по сути, мертвый неразвивающийся проект. К тому же, мне не нужна платформа нацеленная на анимацию и графику, приложение сугубо Enterprise.
К слову, я не думаю, что флэш будет выигрывать или иметь преимущества перед тем же электроном по быстродействию.
1) Единая кодовая база и GUI на платформах Mac, Linux, Windows, веб-сайт и экзотика (QNX к примеру).
2) Команда из 2-3 человек.
3) Работать должно на скромных по ресурсам машинах (до 512МБ оперативы).
4) Времени размусоливать на разных языках нет — к моменту релиза решение морально устареет, надо будет заново переписывать.
Без сарказма.
Вход понятен где — это вызов метода маппера.
В методе по выборке из кеша это второе время.
После вызова маппера это третье время.
Работу самого MyBatis'a в данном случае можно пренебречь. Уже тремя этими параметрами можно как то манипулировать и делать выводы.
Кстати, у Вас все виртуальные машины расположены локально? Если да, то имеет смысл их разнести на разные машины в рамках локальной сети, это будет еще ближе к "боевым" измерениям (потери на сетевом транспорте).
Эка вы как классно профилируете запросы! Я так тоже умею — можно несколько раз позапускать запрос в SQL Developer и он закешируется в самой оракл и никакой MyBatis 2 Level Cache не нужен :)
Если серьезно, MyBatis кеш конечно помогает и выручает, но профит посчитан неверно.
С реакцией на изменения будет чуть сложнее. Тут надо определится кто инициатор изменений и где и как их надо ловить. Из этого и строить этот интерфейс. Но в целом, тоже не так уж и сложно. И кстати, можно вполне обойтись без коллбеков. В директивах есть $watch (он как раз тут подойдет), в котором будут вызываться методы интерфейса для передачи значения в интересующий модуль.
А в чем разница? Сам React пишет "React's one-way data flow (also called one-way binding) keeps everything ..." По мне, так это одно и то же. В ангуляр это добавили не как костыль, а как решение проблем с подходами двустороннего связывания (там, где оно не требуется).
Не встречал такого мнения, заберу в копилку. Может кто то сталкивался уже с такой проблемой? Имхо, она решается достаточно просто (обычные merge-стратегии).
Ну строго говоря, они работают по спецификации HTML, т.е. на атрибутах и тегах. В нашем случае есть html (шаблоны) и есть js (логика), для связи которых нам нужен бридж. Мне сложно представить, как это можно было бы сделать иначе.
Рискну предложить Вашему вниманию свою статью. В рекомендациях я привел пункт 2, который подойдет для решения такой задачи. Вкратце — общение должно происходить через сервис, который будет своего рода интерфейсом взаимодействия между разными частями приложения и компонентом. Интерфейс лучше, потому что он понятен и точно инкапсулирует логику, т.е. наружу дает только тот функицонал, который нужен. При этом мы не связываем код, потому что этот сервис, можно инъектить в любую сущность ангуляра.
Мне это в жизни не мешает, если я вижу логику в шаблоне — я ее выношу в контроллер или директиву (для того они в Angular 1.x и придуманы).
Не очень понял, про какой язык речь?
Да, я тоже узнал об выражении «бороться с фреймворком» именно в контексте ангуляра. И знаете какой я для себя вывод сделал? Люди, кто так писал, как правило, не понимали как работает фреймворк. Они не понимали структуры, использовали $rootScope где ни попадя, кидали события где только можно — короче сами себе раскладывали грабли, чтобы об них потом биться. Поэтому я считаю это утверждение людей, для которых javascript заканчивался на jquery и они старались все те подходы, которые использовались там перенести на Ангуляр. При этом, конечно, я не отрицаю проблем самого Ангуляра (например, дебаг который реализован отвратно).
Что касается реакта, то да, я его пробовал. Он мне напомнил ExtJs, но я ни тем ни другим не проникся. Я не увидел структуры в коде и удобного его построения (в первую очередь для последующей поддержки и переиспользования). Но это все имхо, я больше адепт Java и люблю все стройное и разделенное :)
Вопрос не праздный я задавал. Мне тут с пеной у рта доказывали, что one-way биндинг это костыль, чтобы ангуляр работал быстрее. Теперь вот оказывается, что one-way биндинг это "правильно"… Во всех этих спорах я не вижу ни одного аргумента, который смог бы принять, к сожалению.