Первый пример — p00skimKS. Вы запрещаете перетекание данных в другой дата центр.
Второй пример — p00smev_archKS. Вы запрещаете распределять в текущем дата центре и разрешаете отдавать в другой дата центр.
Из двух примеров получается как минимум дубликат своих данных в двух разделах. Допустим, нам места на диске не жалко. Но у нас несколько внешних дата центров и для каждого надо подготовить свой набор данных, которые надо отдать. Получаем картину из кучи N+1 разделов.
N — количество внешних дата центров. +1 — это текущий дата центр. И первый из N — это общий (федеральный) центр.
Может я и не прав. Не проще ли реализовать аналог почтового сервера, или MQ сервера, с указанием адресатов доставки? Затрат на распределение данных по разным разделам меньше.
Можно заменить SMTP или MQ сервер на FTP сервер. Выкладывать данные для других центров на ftp обменник. И принимаемый дата центр сам решает проблему, как обрабатывать эти данные. То есть, не завязаны на использование одного ПО.
Далее, технология MapReduce. Да, это модно и потому, круто. Но почему графика не в виде логарифма, а в виде прямой линии? По мне, всё дело в этой технологии. Хотим добиться увеличения скорости за счет обработки данных текущего узла кластера. Но на поверку получаем обратный эффект. Каждый узел имеет часть данных другого узла. Другими словами, при 3-х уровневой репликации данных, мы получаем полных 3 прохода обработки одних и тех же данных. Проще было бы получить поток не повторяющихся данных. И этот поток нарезать на кучу потоков в одном узле и на несколько узлов.
Хоть убей, не пойму, при чем здесь NoSQL.
Появилась связь между узлами большого кластера. NoSQL база перераспределила данные на разные узлы кластера.
Совсем не факт, что данные одного центра обработки данных будут находится на узлах данного центра, а не утекут безвозвратно в другой центр данных. При потере связи, текущий центр теряет часть своих данных.
Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
Если кому то стало интересно, в добрый путь. Основы теории электромагнитных полей являются уравнения Максвела.
Всё остальное очень тяжело воспринимается для не подготовленного человека.
На мой взгляд, математика и физика должны быть интересными и познавательными. Если удастся объяснить тяжелые вещи на простых примерах, значит вас будут слушать раскрыв рот, а не зевать во всю площадь лица.
Честное слово, не хочу вас обидеть. Вы кажетесь умным человеком.
Обратимся к азам катушек индуктивности. Для примера, можно посмотреть ресурс базовые формулы. В теории магнитной индукции нет места разности потенциалов и точечным зарядам. Указанный термин «распределенного электрического заряда» не очень то подходит для описания происходящих процессов.
И я, описывая пример воздействия изменяемого магнитного поля на катушку, не говорил, что она подключена к нагрузке.
Электрический ток есть, а электрического потенциала нет.
Ладно, предлагаю мир. Мы немного ушли от темы. Истина всегда где то рядом.
Представим задачу с катушками более простым способом. Катушку можно представить в виде магнитной палочки из детского магнитного конструктора. Конструктор состоит из набора палочек с магнитами на концах и стальных шариков.
Одну палочку положим на гладкий стол и будем подносить конец другой палочки. Мы увидим, что палочка на столе будет поворачиваться обратной стороной магнита к палочке в нашей руке.
Усложним задачу. В руках у нас магнитная палочка, а на столе лежит катушка индуктивности, по которой не течет электрический ток. Подносим магнит. В катушке, под действием изменения внешнего магнитного поля начинает бежать электрический ток. Катушка становится магнитом и так же старается принять упорядоченное положение к магниту в нашей руке.
Изменение внешнего магнитного поля опять сказывается на образование заряда в катушке. И так действует до тех пор, пока катушка не займет определенного положения и магнитное поле для нее перестанет изменяться. В результате, в ней прекратиться выработка электрического тока и она станет инертной по отношению к магниту у нас в руке.
О таком не сложный примере, я говорил как о не самой простой задаче.
Стрелка амперметра или движение катушки диффузора динамика под действием тока внутри постоянного магнита, это одно. Я говорил о явлении наводящейся магнитной индукции.
Тут самое главное, понимание. Для чего эта сложная штука нужна. Людям проще воспринимать занимательную математику, нежели смотреть на сухие формулы тригонометрии.
Косоугольные координаты переведем в прямоугольные координаты.
Воспринимать эту штуку очень сложно по рисунку 2. Для примера, косой угол между базисами рисунка 1 больше 90 градусов. Почему нет?
Пойдем дальше. Почему точка отсчета координат одна и та же. Два объекта, находящихся в пространстве, не вложенные один в другой, являются разными точками отсчета.
Возьмем практический пример. Все мы знаем металлическую метровую линейку с дырочкой. Дырочка нужна, чтобы линейку можно было повесить на гвоздик, на стене. Вот и скажем, что дырочка, будет началом вектора. Положим линейку на пол и посмотрим на нее.
Будем условно считать себя точкой отсчета координат. По правую руку будем откладывать ось X. Вперед, куда смотрят глаза, будет координата Y. Постояли, посмотрели на линейку. Сделали несколько шагов, немного повернулись, посмотрели на линейку. Вот вам две не соосные системы координат с разными точками отсчета. В уме то мы соображаем, что линейка осталась одного размера.
Теперь возвращаемся к математике и пытаемся на пальцах объяснить что такое тензор. И как влияет изменение точки отсчета на матрицу пересчета координат вектора.
Дальше еще интереснее и вкуснее. Тут один из комментаторов приводил теорию с трансформатором. Раскладывал его на катушки и переставлял их. Продолжим его исследования и одну из катушек поставим не вертикально, как все остальные, а на бок, чтобы она каталась по столу. Вот не задача, это уже не тривиальная задача в теории катушек.
Возвращаюсь к любимым линейкам и зайдем в подъезд многоэтажного дома. Положим одну линейку на несколько ступенек пролета, идущего вверх, а вторую на несколько ступенек пролета, идущего вниз. Смотрим на линейки и думаем, как бы применить тензор к разным векторам с одинаковой длиной. И пусть сухой математик объяснит, что это суть разные вектора, а не смещение координатных пространств относительно одного вектора (метровая линейка).
XAML надо читать и на его основе строить статическую модель. QML я сравниваю с WEB JavaScript. По сути, это одна из разновидностей реализации этого языка.
Вы сами всегда придерживаетесь шаблона MVC?
Я — нет. У меня как минимум две буквы M. Первая — модель данных. Вторая — proxy модель для визуальной таблицы. И уже V — визуальный компонент таблицы.
Может пора забыть о MVC и вспомнить «абырвалг» (Собачье сердце).
Еда штука хитрая. Есть нужно уметь, а представьте себе — большинство людей вовсе есть не умеют. Нужно не только знать что съесть, но и когда и как. И что при этом говорить. Да-с. Если вы заботитесь о своем пищеварении, мой добрый совет — не говорите за обедом о большевизме и о медицине. И — боже вас сохрани — не читайте до обеда советских газет. Пациенты, не читающие газет, чувствуют себя превосходно. Те же, которых я специально заставлял читать «Правду», — теряли в весе.
Я не стал вам сразу отвечать. Вы бы для начала посмотрели уроки по QML. Все ваши экранные формы сразу живут в дизайнере и могут легко добавляться в другие формы. Это чем-то напоминает web разработку. А ведь это приложение на Qt, то есть, С++.
Работа с сигналами и слотами на уровне описания формы, а не на уровне описания шаблонов, как в Qt Widget.
Можно еще много разных плюшек написать. Вам интересно, изучайте. Не интересно, тогда зачем объяснить? Статья то совсем не про Qt.
В плане разработки WEB UI части, считаю себя начинающим. Мой конек — серверная часть.
Решил попробовать Angular 1 и понял, что лучше сразу смотреть на Angular 2.
Нашел более менее нормальный пример, маршрутизации (в git исходный код измен). На мой взгляд, так писать можно. Тем более, что маршрутизация поддерживается внутри любого компонента, а не одного html раздела. Бонус — проверка на авторизацию пользователя.
Проблема не в том, быть ответственным лицом в проекте, чтобы вносить изменения, или предлагать эти изменения.
Скажу по себе. Многие мои идеи вошли в Apache Camel, правда идей было не так много. Тем не менее, личного кода там почти нет. И меня это совсем не смущает.
Кто чаще всего является ответственным за код? Я думаю, далеко не автор идеи, а тот, кто чаще отвечает на вопросы. А это люди уже с большим стажем работы.
Возьмем для примера закрытый проект в компании. Проект использует Git и корпоративный сайт GitLab. Вы выполняете работу и вносите свои изменения в ветку с номером вашего задания. Рядом может сидеть ваш товарищ по несчастью, который принимает решение о слиянии вашей ветки в основную ветку проекта. Вы хотите сами принимать решение о внесении десятка веток в основную ветку? Я скажу, как тот, кто сливает ветки в одном из проектов, я был бы рад передать часть этих забот на другого.
Это одна из причин, почему таких людей мало. Причина — скучная работа.
Вторая причина для мира OpenSource, это преподавательский навык на иностранном языке. Если вы будете предлагать хороший код, но не сможете объяснить свою цель, вас банально не поймут.
Простая ситуация. В одном из Open Source проектов, я предложил очень хорошую идею. Руководители проекта заинтересовались. Я предоставил код. Меня попросили предоставить тесты. Я написал тесты и даже кое что написал в JavaDoc. Следующий шаг — документация. Вот тут то я и скис. Описать на русском языке одно, а на английском, совсем другое.
Ваш пример с тапками очень интересный. Вы, наверное, не радиолюбитель, а заведующий складом готовой продукции на обувной фабрике. Уличные фонари, суть, тот же фонарик. Вы их тоже, тапками?
Я вам о другом. У вас один приемник излучения. Когда приемников больше, можно следить за положением объекта. Сейчас вы следите за дистанцией.
Поставте чашку чая рядом с излучателем, а потом, делайте магические пасы руками. Ваш конструктор вас не увидит.
Один датчик не очень то интересно.
Приближая руку к излучателю, вы переключаете в одну сторону. Но руку рано или поздно надо отвести от излучателя. Данное применение познавательно, но не интересно.
Если вам так интересно, то свет и звук имеют одинаковую природу — частотные колебания. Отличие только в диапазоне частот. Поэтому, не важно, эксперимент идет со звуком или со светом.
У человека лучше развито зрение. Возьмем фонарик в темном коридоре. Вы стоите в одном конце коридора. Партнер ходит по коридору и периодически включает фонарик так, чтобы свет его был направлен к вам в лицо. Частота света не меняется. Интенсивность света не большая. Вы можете определить удаление фонарика от вас. Если фонарик очень яркий, он будет вас ослеплять и вы не сможете определить расстояние до партнера. Это я говорю об эффекте затухания волны. Ваш мозг, зная мощность излучения источника сопоставляет затухание яркости и рассчитывает дальность до источника излучения.
В вашем эксперименте, фонарик стоит неподвижно, рядом с вами, а партнер двигает зеркало.
Китообразные и мыши используют «музыку». Сигналы разной частоты и модуляции позволяют строить картину препятствия.
Не задумывались ли вы, почему у летучей мыши два уха, а рот один? Вам два уха/глаза помогают определить направление и дальность. Тем самым, ваш мозг строит трехмерную картину. Если наш мозг с изображением справляется успешно, то со звуком у нас немного хуже. Наш мозг больше отдает пространства на обработку видео сигнала. Звуку досталось гораздо меньше.
Попробуйте задействовать два или большее количество приемников. Большое количество приемников — фазированная решетка. Как у насекомых — фасеточные глаза. Сопоставляя большое количество информации с разных приемников, можно не иметь большой размер мозга для анализа избыточной информации. Опять же, те же самые насекомые, с совершенно крошечным мозговым отделом и огромными глазами, составляющими большую часть головы мухи, пчелы или стрекозы.
Проект Apache Karaf развивается не так быстро. Примерно один фикс релиз в пол года. Задержки вызваны медленным развитием дополнительных компонентов. Для примера, 4 версия всё еще на стадии тестирования, хотя первые альфы были года 2 назад.
Так что, все работают на версиях 2 или 3. Должен отметить, что есть очень интересная версия — 2.4.x. По сути, это стабильный функционал от 4 версии. Если сравнивать версии 2.4.x и 3.0.x, то младшая версия выглядит гораздо привлекательнее.
Правда, в выборе версии Apache Karaf не последнюю роль играет используемая версия Apache Camel.
Apache Camel развивается гораздо быстрее. Жизненный цикл одного фикс релиза составляет 3 месяца. На сайте проекта есть таблица соответствия версий проектов Apache Camel и Apache Karaf. В выборе версий желательно придерживаться данных этой таблицы. В последнее время, весной, проект Apache Camel начал хандрить. Люди постарались выпустить версию 2.15.0. В этой версии очень много интересных решений и многие ожидали. В частности, этот релиз переходил на Apache Karaf 2.4.x. Как обычно, люди старались и некоторые ошибки просто упустили.
Так к слову, Apache Camel потерял функционал управления из командной консоли Apache Karaf. Я отметил данный нюанс на форуме проекта. Разработчики постарались в сжатые сроки, через 20 дней, выдать исправленную версию. Как говориться, спешка нужна при ловле блох. Пришлось еще через месяц выпускать новую версию фикс релиза.
У вас проблема роста системы — компонент нельзя перегрузить.
Если компонент используется как библиотека классов, выгрузить ее почти не реально. Надо ждать, когда остановятся другие компоненты.
Если компонент предоставляет сервис, надо смотреть, где находится интерфейс. Если интерфейс лежит в том же компоненте, та же история, как в первом случае.
Рецепт один. Предоставляйте не реализацию классов, а интерфейсы. Интерфейсы держите в отдельном компоненте.
Горячая замена. Да, есть проблема в OSGi Blueprint. Не хочет отпускать захваченный сервис. По этой причине надо останавливать компонент (bundle) сервиса и запускать снова.
По поводу использования не OSGi библиотек. По началу, я тоже ломал голову, что надо делать OSGi wrapper. Решение пришло с другой стороны. В Apache Karaf есть файл описания плана развертки особенностей (features). Пример команды установки
features:instal war
Пример установки Google Guava, библиотеки, которая давно обзавелась OSGi манифестом:
<bundle>mvn:com.google.guava/guava/15.0</bundle>
Пример установки JDBC драйвера, не обладающего OSGi манифестом:
Как бы сказать получше.
1) У меня проект с использует Apache Camel. В OSGi все Camel процессы стартуют автоматически.
2) В Apache Karaf есть хорошая WebConsole для управления параметрами сервисов. Изменил, нажал сохранить, система работает с этими параметрами. Опять же, изобретать и отлаживать ничего не надо.
3) Большое количество версий документов. На уровне OSGi сервисов я указываю параметр версии обрабатываемых документов. Указываю в фильтре версию обрабатываемого документа. Система возвращает нужный сервис. В EJB я такого функционала не обнаружил.
4) В сочетании Apache Camel и OSGi сервисов, я использую динамическую регистрацию процессов (recepientList). Тем самым, получаю одну систему приема документов и много систем обработки.
5) Можно поставить hawt.io для визуального отслеживания производительности системы.
Да бы не писать разные наборы Entity компонентов под разные системы обработки, использую трансформацию XML => JAXB => MyBatis. Да, некоторые XML радуют размерами в десятки мегабайт.
Использую отдельный OSGi компонент (bundle + service) под обработку документов одной версии.
Система поднимает OSGi сервис для обработки документа определенной версии. После обработки, сервис становится не востребованным и Framework может освободить память.
Делаем упор на то, что версий документов может быть много. Поднимать Entity, сразу для всех типов документов одной версии, дело не благодарное. В MyBatis используется динамическое поднятие интерфейсов обращения к базе данных. Это значительно ускоряет процесс. В рамках JPA надо дробить систему еще сильнее — один OSGi bundle для каждого документа одной версии.
Везде я указывал, что можно использовать WEB сервис для получения входного документа. На самом деле, в проекте документы появляются по расписанию и большими пачками. До тысячи документов в пачке. Apache Camel процессы позволяют вести обработку в несколько потоков. Логично предположить, что маленькие документы обрабатываются быстрее, а большие медленнее.
Документы этого сайта были предложены только в качестве примера. Количество проходящих документов за день довольно большое. Документы не будут меняться от версии к версии хотя бы потому, что их очень много.
Можно придумать другую задачу, где регулярно меняются форматы документов. В бухгалтерском деле это случается довольно часто. Документы должны храниться от 3 до 5 лет.
Специфика системы такая, что может прийти документ старого и нового форматов.
Задачи использования полученных данных можно придумать самому. И это будет уже другая история.
В качестве примера можно рассмотреть обработку данных с федерального сайта государственных закупок.
За прошлый год структура документов сменилась семь раз. В каждой версии порядка 40 типов документов. 7 * 40 = 280 типов документов. Получается, что в системе, для каждой версии свой компонент с JAXB объектами. Средний объем бинарных кодов JAXB классов от 4М до 6М. При таких объемах начинаешь воевать за крошки в JVM permgen. Далее, строим некую систему хранения данных своей организации. Появляется новая версия документов. Зачем ломать тот код, что уже работает? Делаем новую систему раскладки под новую версию документов.
Задачи использования полученных данных можно придумать самому. И это будет уже другая история.
Проблема не столько в Entity объектах. В MyBatis можно обойтись объектами, созданными из JAXB модели. Главная задача, это выгрузка классов. А для этого надо аккуратно убирать все классы обработки, где используются импорты JAXB классов. Кто у нас главный поставщик этих классов обработки? Правильно, сервис со своей JPA фабрикой или MyBatis фабрикой.
Динамические сервисы, по умолчанию, являются уничтожаемыми SCR компонентами (DelayedComponent).
Если SCR компонент не реализует интерфейсы, будет создан сразу (Immediate).
Если для SCR компонента указать название фабрики, будет режим фабрики.
Работу фабрики можно описать. В пределах одного компонента, Bundle, Framework кеширует сервис. Первый запрос сервиса заставляет фабрику создать новый объект, реализующий сервис. При следующем запросе сервиса из этого же Bundle, если счетчик запросов больше нуля, возвращается ранее созданный объект. При разрегистрации компонента, когда счетчик использования достигает нуля, фабрика уничтожает объект сервиса.
Теперь представим работу с уничтожаемым динамическим сервисом. При первом запросе сервиса, Framework поднимет реализацию сервиса. Каждый Bundle, запрашивающий данный сервис, получит один и тот же объект. При разрегистрации компонента, когда счетчик использования достигает нуля, объект сервиса будет уничтожен.
Прочувствуйте разницу на сложном примере. У нас есть JAXB объекты, генерированные из xsd схемы. Для работы нам надо поднять JaxbContext. Если количество классов в схеме около сотни, процесс будет достаточно медленным. Можно поднять JaxbContext в фабрике и передавать его в каждый создаваемый экземпляр. Когда все экземпляры сервисов будут уничтожены, фабрика может обнулить данный параметр. А можно поднять уничтожаемый динамический сервис. При активации, он поднимет JaxbContext. При деактивации, JaxbContext будет уничтожен по ходу уничтожения объекта сервиса.
Теперь подумаем, как ведет себя JPA в фабрике. В пределах одной транзакции сервис запрашивается из двух компонентов, OSGi bundle. Для каждого будет создан свой сервис со своим EntityManager. Первый bundle создал часть объектов и не сделал flush. После этого работает второй компонент. Программист думает, что часть нужной информации доступна, так как она сделана в этой транзакции. Но в базе данных объектов еще нет и сервер базы данных отдает устаревшие данные. Теперь, раздается общий commit по транзакции. Как вы думаете, какой из двух EntityManager запишет свои данные раньше? Ответ — второй. Для этого надо углубиться в диаграммы описания работы JTA транзакций.
Вы разве этого хотели достичь своей фабрикой?
Я точно, так не хочу.
Другими словами. Когда создается новый объект EntityManager всё решается. Все зарегистрированные и измененные объекты, сохраняются этим менеджером.
А вот с соединениями к базе данных беда. Да мы можем открыть новое соединение в новой транзакции. Но все изменения объектов, сделанные до открытия транзакции, выполняться в новой транзакции.
Значит, нам нужно открепить объект от старого EM (detach) и прикрепить к новому EM (push). После завершения вложенной транзакции, вернуть объект в старый EM. Эта процедура для того, чтобы лишний раз не поднимать часть объектов из базы данных. Ведь в разных EM кеш объектов не пересекается.
Немного сложная технология. А если есть прикрепленные объекты (one2one, one2many, many2one), тогда, после открепления основного объекта, надо откреплять все сопроводительные объекты.
Мне это немного надоело в JDO. По этой причине перешел на MyBatis.
JPA и JDO, красивые технологии, но в них столько нюансов, что иногда хочется выключить монитор, чтобы не видеть стек невероятных ошибок.
Первый пример — p00skimKS. Вы запрещаете перетекание данных в другой дата центр.
Второй пример — p00smev_archKS. Вы запрещаете распределять в текущем дата центре и разрешаете отдавать в другой дата центр.
Из двух примеров получается как минимум дубликат своих данных в двух разделах. Допустим, нам места на диске не жалко. Но у нас несколько внешних дата центров и для каждого надо подготовить свой набор данных, которые надо отдать. Получаем картину из кучи N+1 разделов.
N — количество внешних дата центров. +1 — это текущий дата центр. И первый из N — это общий (федеральный) центр.
Может я и не прав. Не проще ли реализовать аналог почтового сервера, или MQ сервера, с указанием адресатов доставки? Затрат на распределение данных по разным разделам меньше.
Можно заменить SMTP или MQ сервер на FTP сервер. Выкладывать данные для других центров на ftp обменник. И принимаемый дата центр сам решает проблему, как обрабатывать эти данные. То есть, не завязаны на использование одного ПО.
Далее, технология MapReduce. Да, это модно и потому, круто. Но почему графика не в виде логарифма, а в виде прямой линии? По мне, всё дело в этой технологии. Хотим добиться увеличения скорости за счет обработки данных текущего узла кластера. Но на поверку получаем обратный эффект. Каждый узел имеет часть данных другого узла. Другими словами, при 3-х уровневой репликации данных, мы получаем полных 3 прохода обработки одних и тех же данных. Проще было бы получить поток не повторяющихся данных. И этот поток нарезать на кучу потоков в одном узле и на несколько узлов.
Появилась связь между узлами большого кластера. NoSQL база перераспределила данные на разные узлы кластера.
Совсем не факт, что данные одного центра обработки данных будут находится на узлах данного центра, а не утекут безвозвратно в другой центр данных. При потере связи, текущий центр теряет часть своих данных.
Мой старый блог «Apache CXF и ЭЦП для SOAP сообщений СМЭВ».
Всё остальное очень тяжело воспринимается для не подготовленного человека.
На мой взгляд, математика и физика должны быть интересными и познавательными. Если удастся объяснить тяжелые вещи на простых примерах, значит вас будут слушать раскрыв рот, а не зевать во всю площадь лица.
Обратимся к азам катушек индуктивности. Для примера, можно посмотреть ресурс базовые формулы. В теории магнитной индукции нет места разности потенциалов и точечным зарядам. Указанный термин «распределенного электрического заряда» не очень то подходит для описания происходящих процессов.
И я, описывая пример воздействия изменяемого магнитного поля на катушку, не говорил, что она подключена к нагрузке.
Электрический ток есть, а электрического потенциала нет.
Ладно, предлагаю мир. Мы немного ушли от темы. Истина всегда где то рядом.
Одну палочку положим на гладкий стол и будем подносить конец другой палочки. Мы увидим, что палочка на столе будет поворачиваться обратной стороной магнита к палочке в нашей руке.
Усложним задачу. В руках у нас магнитная палочка, а на столе лежит катушка индуктивности, по которой не течет электрический ток. Подносим магнит. В катушке, под действием изменения внешнего магнитного поля начинает бежать электрический ток. Катушка становится магнитом и так же старается принять упорядоченное положение к магниту в нашей руке.
Изменение внешнего магнитного поля опять сказывается на образование заряда в катушке. И так действует до тех пор, пока катушка не займет определенного положения и магнитное поле для нее перестанет изменяться. В результате, в ней прекратиться выработка электрического тока и она станет инертной по отношению к магниту у нас в руке.
О таком не сложный примере, я говорил как о не самой простой задаче.
Стрелка амперметра или движение катушки диффузора динамика под действием тока внутри постоянного магнита, это одно. Я говорил о явлении наводящейся магнитной индукции.
Косоугольные координаты переведем в прямоугольные координаты.
Воспринимать эту штуку очень сложно по рисунку 2. Для примера, косой угол между базисами рисунка 1 больше 90 градусов. Почему нет?
Пойдем дальше. Почему точка отсчета координат одна и та же. Два объекта, находящихся в пространстве, не вложенные один в другой, являются разными точками отсчета.
Возьмем практический пример. Все мы знаем металлическую метровую линейку с дырочкой. Дырочка нужна, чтобы линейку можно было повесить на гвоздик, на стене. Вот и скажем, что дырочка, будет началом вектора. Положим линейку на пол и посмотрим на нее.
Будем условно считать себя точкой отсчета координат. По правую руку будем откладывать ось X. Вперед, куда смотрят глаза, будет координата Y. Постояли, посмотрели на линейку. Сделали несколько шагов, немного повернулись, посмотрели на линейку. Вот вам две не соосные системы координат с разными точками отсчета. В уме то мы соображаем, что линейка осталась одного размера.
Теперь возвращаемся к математике и пытаемся на пальцах объяснить что такое тензор. И как влияет изменение точки отсчета на матрицу пересчета координат вектора.
Дальше еще интереснее и вкуснее. Тут один из комментаторов приводил теорию с трансформатором. Раскладывал его на катушки и переставлял их. Продолжим его исследования и одну из катушек поставим не вертикально, как все остальные, а на бок, чтобы она каталась по столу. Вот не задача, это уже не тривиальная задача в теории катушек.
Возвращаюсь к любимым линейкам и зайдем в подъезд многоэтажного дома. Положим одну линейку на несколько ступенек пролета, идущего вверх, а вторую на несколько ступенек пролета, идущего вниз. Смотрим на линейки и думаем, как бы применить тензор к разным векторам с одинаковой длиной. И пусть сухой математик объяснит, что это суть разные вектора, а не смещение координатных пространств относительно одного вектора (метровая линейка).
Вы сами всегда придерживаетесь шаблона MVC?
Я — нет. У меня как минимум две буквы M. Первая — модель данных. Вторая — proxy модель для визуальной таблицы. И уже V — визуальный компонент таблицы.
Может пора забыть о MVC и вспомнить «абырвалг» (Собачье сердце).
Работа с сигналами и слотами на уровне описания формы, а не на уровне описания шаблонов, как в Qt Widget.
Можно еще много разных плюшек написать. Вам интересно, изучайте. Не интересно, тогда зачем объяснить? Статья то совсем не про Qt.
Решил попробовать Angular 1 и понял, что лучше сразу смотреть на Angular 2.
Нашел более менее нормальный пример, маршрутизации (в git исходный код измен). На мой взгляд, так писать можно. Тем более, что маршрутизация поддерживается внутри любого компонента, а не одного html раздела. Бонус — проверка на авторизацию пользователя.
На мой взгляд, система более лаконична, чем Angilar 1.x.
Скажу по себе. Многие мои идеи вошли в Apache Camel, правда идей было не так много. Тем не менее, личного кода там почти нет. И меня это совсем не смущает.
Кто чаще всего является ответственным за код? Я думаю, далеко не автор идеи, а тот, кто чаще отвечает на вопросы. А это люди уже с большим стажем работы.
Возьмем для примера закрытый проект в компании. Проект использует Git и корпоративный сайт GitLab. Вы выполняете работу и вносите свои изменения в ветку с номером вашего задания. Рядом может сидеть ваш товарищ по несчастью, который принимает решение о слиянии вашей ветки в основную ветку проекта. Вы хотите сами принимать решение о внесении десятка веток в основную ветку? Я скажу, как тот, кто сливает ветки в одном из проектов, я был бы рад передать часть этих забот на другого.
Это одна из причин, почему таких людей мало. Причина — скучная работа.
Вторая причина для мира OpenSource, это преподавательский навык на иностранном языке. Если вы будете предлагать хороший код, но не сможете объяснить свою цель, вас банально не поймут.
Простая ситуация. В одном из Open Source проектов, я предложил очень хорошую идею. Руководители проекта заинтересовались. Я предоставил код. Меня попросили предоставить тесты. Я написал тесты и даже кое что написал в JavaDoc. Следующий шаг — документация. Вот тут то я и скис. Описать на русском языке одно, а на английском, совсем другое.
Я вам о другом. У вас один приемник излучения. Когда приемников больше, можно следить за положением объекта. Сейчас вы следите за дистанцией.
Поставте чашку чая рядом с излучателем, а потом, делайте магические пасы руками. Ваш конструктор вас не увидит.
Алексей
Приближая руку к излучателю, вы переключаете в одну сторону. Но руку рано или поздно надо отвести от излучателя. Данное применение познавательно, но не интересно.
Если вам так интересно, то свет и звук имеют одинаковую природу — частотные колебания. Отличие только в диапазоне частот. Поэтому, не важно, эксперимент идет со звуком или со светом.
У человека лучше развито зрение. Возьмем фонарик в темном коридоре. Вы стоите в одном конце коридора. Партнер ходит по коридору и периодически включает фонарик так, чтобы свет его был направлен к вам в лицо. Частота света не меняется. Интенсивность света не большая. Вы можете определить удаление фонарика от вас. Если фонарик очень яркий, он будет вас ослеплять и вы не сможете определить расстояние до партнера. Это я говорю об эффекте затухания волны. Ваш мозг, зная мощность излучения источника сопоставляет затухание яркости и рассчитывает дальность до источника излучения.
В вашем эксперименте, фонарик стоит неподвижно, рядом с вами, а партнер двигает зеркало.
Китообразные и мыши используют «музыку». Сигналы разной частоты и модуляции позволяют строить картину препятствия.
Не задумывались ли вы, почему у летучей мыши два уха, а рот один? Вам два уха/глаза помогают определить направление и дальность. Тем самым, ваш мозг строит трехмерную картину. Если наш мозг с изображением справляется успешно, то со звуком у нас немного хуже. Наш мозг больше отдает пространства на обработку видео сигнала. Звуку досталось гораздо меньше.
Попробуйте задействовать два или большее количество приемников. Большое количество приемников — фазированная решетка. Как у насекомых — фасеточные глаза. Сопоставляя большое количество информации с разных приемников, можно не иметь большой размер мозга для анализа избыточной информации. Опять же, те же самые насекомые, с совершенно крошечным мозговым отделом и огромными глазами, составляющими большую часть головы мухи, пчелы или стрекозы.
Так что, все работают на версиях 2 или 3. Должен отметить, что есть очень интересная версия — 2.4.x. По сути, это стабильный функционал от 4 версии. Если сравнивать версии 2.4.x и 3.0.x, то младшая версия выглядит гораздо привлекательнее.
Правда, в выборе версии Apache Karaf не последнюю роль играет используемая версия Apache Camel.
Apache Camel развивается гораздо быстрее. Жизненный цикл одного фикс релиза составляет 3 месяца. На сайте проекта есть таблица соответствия версий проектов Apache Camel и Apache Karaf. В выборе версий желательно придерживаться данных этой таблицы. В последнее время, весной, проект Apache Camel начал хандрить. Люди постарались выпустить версию 2.15.0. В этой версии очень много интересных решений и многие ожидали. В частности, этот релиз переходил на Apache Karaf 2.4.x. Как обычно, люди старались и некоторые ошибки просто упустили.
Так к слову, Apache Camel потерял функционал управления из командной консоли Apache Karaf. Я отметил данный нюанс на форуме проекта. Разработчики постарались в сжатые сроки, через 20 дней, выдать исправленную версию. Как говориться, спешка нужна при ловле блох. Пришлось еще через месяц выпускать новую версию фикс релиза.
У вас проблема роста системы — компонент нельзя перегрузить.
Если компонент используется как библиотека классов, выгрузить ее почти не реально. Надо ждать, когда остановятся другие компоненты.
Если компонент предоставляет сервис, надо смотреть, где находится интерфейс. Если интерфейс лежит в том же компоненте, та же история, как в первом случае.
Рецепт один. Предоставляйте не реализацию классов, а интерфейсы. Интерфейсы держите в отдельном компоненте.
Горячая замена. Да, есть проблема в OSGi Blueprint. Не хочет отпускать захваченный сервис. По этой причине надо останавливать компонент (bundle) сервиса и запускать снова.
По поводу использования не OSGi библиотек. По началу, я тоже ломал голову, что надо делать OSGi wrapper. Решение пришло с другой стороны. В Apache Karaf есть файл описания плана развертки особенностей (features). Пример команды установки
features:instal war
Пример установки Google Guava, библиотеки, которая давно обзавелась OSGi манифестом:
Пример установки JDBC драйвера, не обладающего OSGi манифестом:
1) У меня проект с использует Apache Camel. В OSGi все Camel процессы стартуют автоматически.
2) В Apache Karaf есть хорошая WebConsole для управления параметрами сервисов. Изменил, нажал сохранить, система работает с этими параметрами. Опять же, изобретать и отлаживать ничего не надо.
3) Большое количество версий документов. На уровне OSGi сервисов я указываю параметр версии обрабатываемых документов. Указываю в фильтре версию обрабатываемого документа. Система возвращает нужный сервис. В EJB я такого функционала не обнаружил.
4) В сочетании Apache Camel и OSGi сервисов, я использую динамическую регистрацию процессов (recepientList). Тем самым, получаю одну систему приема документов и много систем обработки.
5) Можно поставить hawt.io для визуального отслеживания производительности системы.
Да бы не писать разные наборы Entity компонентов под разные системы обработки, использую трансформацию XML => JAXB => MyBatis. Да, некоторые XML радуют размерами в десятки мегабайт.
Использую отдельный OSGi компонент (bundle + service) под обработку документов одной версии.
Система поднимает OSGi сервис для обработки документа определенной версии. После обработки, сервис становится не востребованным и Framework может освободить память.
Делаем упор на то, что версий документов может быть много. Поднимать Entity, сразу для всех типов документов одной версии, дело не благодарное. В MyBatis используется динамическое поднятие интерфейсов обращения к базе данных. Это значительно ускоряет процесс. В рамках JPA надо дробить систему еще сильнее — один OSGi bundle для каждого документа одной версии.
Везде я указывал, что можно использовать WEB сервис для получения входного документа. На самом деле, в проекте документы появляются по расписанию и большими пачками. До тысячи документов в пачке. Apache Camel процессы позволяют вести обработку в несколько потоков. Логично предположить, что маленькие документы обрабатываются быстрее, а большие медленнее.
Можно придумать другую задачу, где регулярно меняются форматы документов. В бухгалтерском деле это случается довольно часто. Документы должны храниться от 3 до 5 лет.
Специфика системы такая, что может прийти документ старого и нового форматов.
За прошлый год структура документов сменилась семь раз. В каждой версии порядка 40 типов документов. 7 * 40 = 280 типов документов. Получается, что в системе, для каждой версии свой компонент с JAXB объектами. Средний объем бинарных кодов JAXB классов от 4М до 6М. При таких объемах начинаешь воевать за крошки в JVM permgen. Далее, строим некую систему хранения данных своей организации. Появляется новая версия документов. Зачем ломать тот код, что уже работает? Делаем новую систему раскладки под новую версию документов.
Задачи использования полученных данных можно придумать самому. И это будет уже другая история.
Проблема не столько в Entity объектах. В MyBatis можно обойтись объектами, созданными из JAXB модели. Главная задача, это выгрузка классов. А для этого надо аккуратно убирать все классы обработки, где используются импорты JAXB классов. Кто у нас главный поставщик этих классов обработки? Правильно, сервис со своей JPA фабрикой или MyBatis фабрикой.
Если SCR компонент не реализует интерфейсы, будет создан сразу (Immediate).
Если для SCR компонента указать название фабрики, будет режим фабрики.
Работу фабрики можно описать. В пределах одного компонента, Bundle, Framework кеширует сервис. Первый запрос сервиса заставляет фабрику создать новый объект, реализующий сервис. При следующем запросе сервиса из этого же Bundle, если счетчик запросов больше нуля, возвращается ранее созданный объект. При разрегистрации компонента, когда счетчик использования достигает нуля, фабрика уничтожает объект сервиса.
Теперь представим работу с уничтожаемым динамическим сервисом. При первом запросе сервиса, Framework поднимет реализацию сервиса. Каждый Bundle, запрашивающий данный сервис, получит один и тот же объект. При разрегистрации компонента, когда счетчик использования достигает нуля, объект сервиса будет уничтожен.
Прочувствуйте разницу на сложном примере. У нас есть JAXB объекты, генерированные из xsd схемы. Для работы нам надо поднять JaxbContext. Если количество классов в схеме около сотни, процесс будет достаточно медленным. Можно поднять JaxbContext в фабрике и передавать его в каждый создаваемый экземпляр. Когда все экземпляры сервисов будут уничтожены, фабрика может обнулить данный параметр. А можно поднять уничтожаемый динамический сервис. При активации, он поднимет JaxbContext. При деактивации, JaxbContext будет уничтожен по ходу уничтожения объекта сервиса.
Теперь подумаем, как ведет себя JPA в фабрике. В пределах одной транзакции сервис запрашивается из двух компонентов, OSGi bundle. Для каждого будет создан свой сервис со своим EntityManager. Первый bundle создал часть объектов и не сделал flush. После этого работает второй компонент. Программист думает, что часть нужной информации доступна, так как она сделана в этой транзакции. Но в базе данных объектов еще нет и сервер базы данных отдает устаревшие данные. Теперь, раздается общий commit по транзакции. Как вы думаете, какой из двух EntityManager запишет свои данные раньше? Ответ — второй. Для этого надо углубиться в диаграммы описания работы JTA транзакций.
Вы разве этого хотели достичь своей фабрикой?
Я точно, так не хочу.
А вот с соединениями к базе данных беда. Да мы можем открыть новое соединение в новой транзакции. Но все изменения объектов, сделанные до открытия транзакции, выполняться в новой транзакции.
Значит, нам нужно открепить объект от старого EM (detach) и прикрепить к новому EM (push). После завершения вложенной транзакции, вернуть объект в старый EM. Эта процедура для того, чтобы лишний раз не поднимать часть объектов из базы данных. Ведь в разных EM кеш объектов не пересекается.
Немного сложная технология. А если есть прикрепленные объекты (one2one, one2many, many2one), тогда, после открепления основного объекта, надо откреплять все сопроводительные объекты.
Мне это немного надоело в JDO. По этой причине перешел на MyBatis.
JPA и JDO, красивые технологии, но в них столько нюансов, что иногда хочется выключить монитор, чтобы не видеть стек невероятных ошибок.