Т.н. «актеры» — основа API в Windows и существуют еще с незапямятных времен (кто помнит обмен сообщениями WM_).
Каждый актер — это single-threaded объект, доступ к которому осуществляется через очередь сообщений (и различные враперы типа TypedActors). Т.о. не болит голова о синхронизации и блокировках. Все, что внутри объекта используется им эксклюзивно.
У архитектуры, построенной на актерах есть одно преимущество в то же время недостаток — она асинхронная. То есть в заданный момент времени нельзя определить четко состояние всей системы, что становится проблемой например при ее остановке. Не совсем ясно в какой последовательности останавливать актеров, т.к. они могут зависеть друг от друга. И если актер уже остановлен, а другой пытается послать ему сообщение, он вылетит с ошибкой. Поэтому у асинхронной архитектуры очереди сообщений обычно делают persistent и выносят в отдельный леер (JMS,MQ), чтобы при рестарте компонентов сообщения не терялись.
Также у асинхронной архитектуры есть пробемы для реализации сложной атомарной операции между актерами (транзакция), поскольку их состояние ни в какой момент несинхронизровано. В Akka для этой цели используют механизм транзакторов, которые могут координировать работу нескольких актеров. Другое решение — использовать Software Transaction Memory, реализация которой в Akka очень примитивна.
P.S. Еще замечание: использование синхронного request-reply в асинхронной архитектуре, равно как и «request-reply-with-future» — это 99% DEADLOCK. Единственное safe-решение — это request-with-callback.
Я знаю, этот человек — Эрвин Шредингер. Только сам он яд не пил, а согласно слухам, экспериментировал с котами… ;))) Думаю, квантовая механика — это идеальный пример работы нечеткой логики.
Я не совсем понял как автор использует нечеткую логику в своем алгоритме. По-моему при работе такого алгоритма каждый if вычисляет сразу оба возможных варианта, форкая выполнение в новую ветвь и ставя в соответствие этой ветви вероятность, из условия. Результат работы такого алгоритма — это все множество результатов каждой из ветвей, взятых с соответствующей вероятностью (вообще не люблю термин «вероятность» и предпочитаю говорить «плотность»).
P.S. Еще такая мысль: практически любое высказывание человека объективно носит нечеткий характер. Однако субъективно (в его логической системе) оно всегда принимает либо истину, либо ложь. Отсюда корень непонимания между людьми ))
Аффтар! Вы не проанализировали первопричины и сделали абсолютно неправильные выводы.
Маша — проныра. При минимуме усилий и выполненной работы получает максимальнуй личную выгоду. Обычно ничего не знает и не умеет (пологое начало графика). Зато активно идет по головам, работает локтями и присваивает себе результаты чужого труда, не гнушаясь никаких методов. Как вариант: пришла обычной секретуткой, соснула у шефа и стала начальником отдела. Затем подлегла под директора и стала топменеджером. Вот Вам и производная.
Даша — типичная карьеристка. Суетится только там, где это сулит в будущем личные переспективы. Чужую работу на себя не берет, считает это недостойным ее уровня, и видит себя исключительно на руководящей должности. Методично подминает под себя всех остальных в коллективе.
Наташа — типичный трудоголик. Выполняет всю работу, которую ей дают. Знания и навыки ей позволили быстро достигнуть своего уровня (крутое начало графика). Собственно это единственный эксперт в компании, который знает и понимает всю кухню. Именно поэтому ее карьера уперлась в потолок, т.к. заменить ее не кем (нет таких крутых спецов), а наверху уже сидят Маша и Даша.
Так что, аффтар, если вы делаете ставку на Машу и Дашу, то рискуете очень быстро быть выпнутым из своего мягкого кресла.
«I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.»
Основной недостаток Groovy — это динамическая типизация, когда тип переменной может быть вычислен только в runtime. В Scala была реализована сложная модель вычисления статических типов на этапе компиляции.
Один из бонусов type-safe языка, который я люблю — это то, что IDE знает типы и предлагает список полей и методов по Ctrl-Space В Groovy же приходится ползать в документацию.
Тем не менее для Groovy списывать рано. Для него написано огромное количество библиотек, и использование его для написания скриптов или второстепенных утилит очень оправдано. Однако для основного проекта я бы использовал его с осторожностью.
Извиняюсь, но по-моему корпоративные тролли существуют в голове начальника, как результат самооправдания своей профессиональной несостоятельности. Если техзадание написано херово, если основные идеи не донесены до разработчиков, и если начальник сам не имеет четкого представления о результате работы, то троллинг — это единственная возможность заставить напрячься его голову (или чем он там думает).
Тролли — жертвы — это те, кто реально пашет и пытается угнаться за постоянными изменениями, каждое из которых заставляет переделопачивать код.
Тролли-киллеры — это те, кто реально пытается разобраться в хреново написанной документации и состыковать бредовые идеи начальства между собой.
Тролли — выскочки — это те, кто реально умнее своих шефов, и у которых от работы с ними еще не угас весь энтузиазм.
Создать реальную сцену из фанеры и пенопласта, полностью соответствующую игровой, раскрасить ее, сфотографировать и сохранить в .png
Затем пишите тест:
1. Установить камеру в нужную позицию на игровой сцене
2. Отрендерить и сохранить в .png
3. Сравнить отрендеренное изображение с полученным с фотокамеры )))
А вообще подобные проекты тестируется при помощи хомячков (ну или лемингов) )))
Для Oracle есть Toad, который умеет делать оочень много полезных вещей по работе со схемами. В свое время мы делали полный экспорт схем двух баз в скрипты, а затем сравнивали обычным diff-ом. Хотя у Toad-а для этого есть специальная тулза.
Очень правильная статья, заставляет задуматься!
Основной ошибкой проектирования систем является непонимание архитектора, что ошибка выполнения транзакции — это НОРМАЛЬНОЕ состояние, а не исключительная ситуация. При optimistic locking справедливо правило: «let it fault!». Стандартное решение в данной ситуации — это отслеживать коллизии и делать повтор. Однако ни один фреймворк по дефолту это не предлагает.
На практике во всех движках вместо ТруЪ serializable level используют более слабый snapshot isolation en.wikipedia.org/wiki/Snapshot_isolation
Каждая транзакция видит «снимок» базы на момент ее начала. Метод базируется на сохранении нескольких версий измененных данных, доступных на время другим транзакциям: en.wikipedia.org/wiki/Multiversion_concurrency_control
MVCC вместе с write lock дает хорошую производительность, и уровень близкий к serializable. Различие заключается лишь в том, что последовательность обработки двух разных транзакций не гарантируется.
entradas.com
Там надо нажать кнопку «Check your purchase» и «Credit Card»… Контора очень мажорная, поэтому, думаю, все сертификаты имеются. Только вот в свое время, когда у них сайт был написан еще на .asp список карт выфигачивался простой sql-injection. И даже не это главное. После демонстрации данной уязвимости клиенту, он ответил уже как-то неактуально, потому что через полгода у них вводится новый сайт (для которого я писал модуль интеграции с системами оплаты). После этого я зарекся оставлять номер карточки везде, кроме сайтов, делающих редирект на систему оплаты моего банка.
Кстати, многие авиакомпании просят иметь карточку при себе, когда регистрируешься на рейс, если билет был куплен по карточке. То есть они тоже сохраняют ее.
Второй десяток третьего тысячелетия. Тесты стали настолько сложными, а их конфигурация настолько нетривиальная, что пришлось писать тесты для тестов, используя более старые, но более простые фреймворки )))
Мы в проекте все изменения базы данных записываем в два скрипта: статичный, для создания базы с нуля (с create-ами), и инкрементный лог, для апгрейда версий (с alter-ами). Задача — удостовериться, что оба метода создают одинаковые базы данных. Это делает ночной билдер, создавая базы обоими методами и сравнивая их information schema.
В свое время вставал вопрос: если пользователь делает покупку без регистрации, и по какой-то причине во время денежной транзакции происходит сбой (напр. виснет компьютер или обрывается связь), то пользователь даже не знает, прошла покупка или нет. Ясно, что идентифицировать через куку — плохое решение (как пример, покупка может быть сделана с публичного терминала).
Поэтому на одном крупном сайте по заказу билетов по интернету покупку пользователя идентифицируют по номеру его кредитной карточки — единственная информация, которую пользователь оставляет о себе. В кассе необходимо лишь показать карточку.
1. Java не умеет множественно наследовать функциональность, поэтому приходится извращаться либо с Proxy, либо громоздить с delegate. В Scala это делается очень изящно при помощи трейтов. Так что есть смысл переходить на Scala.
2. > Необходимо позаботиться о многопоточном использовании observable-объекта
Отделите мух от супа. Многопоточная архитектура имеет совершенно иную специфику: синхронные и асинхронные события, блокирование, коллизии и повторы. В этому случае Вам подойдет модель актеров (Actors) akka.io
А для десктопной апликации не стоит так извращаться.
3. В Вашей реализации есть одна типичная ошибка: если обзервер, получив событие, больше не хочет принимать, он дерегистрирует себя из объекта-источника. В таком случае ваш цикл отсылки
for (T listener: _listeners) {
вылетит с ConcurrentModificationException, т.к. список _listeners был изменен во время прохода. Нужно проходить по копии _listeners.
4. Вообще модель продьюсер-обзервер плоха не столько количеством лишнего кода, сколько необходимостью строгого контроля регистрации/дерегистрации обзерверов. Это есть корень всех ошибок с memory leaking в программах Java. Java девелоперы, привыкшие к GC, редко заботятся об освобождении ресурсов, в том числе и дерегистрации обзерверов, которые так и болтаются в списке. Друкая проблема — запутанность логики, структуры и зависимостей. Поэтому все чаще в проектах используют EventBus как замену архитектуре producer-observer, напр. www.eventbus.org/
J2ME не актуальна, т.к. современные устройства уже способны запускать полную J2SE. Была попытка прикрутить JavaFX к мобильным платформам как подмножество J2SE, но с выходом JavaFX 2.0 Oracle ообъявила, что основная их цель десктопы.
Мы убрали капча создавала много проблем «людям с ограниченными способностями». Поэтому мы убрали ее. А заодно и о тупых бло… эээ… «представителях женской половины со светлым типом волос и ограниченными умственными способностями» позаботились ;)))
В свое время Телефоника делала анализ возможностей исопльзования облачных платформ и выявила два принципиальных недостатка:
— Безопасность данных. Возможность доступа третьих лиц к данным компании в облачных платформах в сотни! раз больше. Потенциальный доступ имеют люди, не имеющие отношения к прозводственному циклу вашей компании (обслуживание DC). Облачные платформы не позволяют строить многоуровневую политику безопасности. Все аккаунты также хранятся в облаке. Использование публичных каналов для доступа к системе делает ее потенциально доступной для любого злоумышленника.
— Зависимость от провайдера. Ваш бизнес будет полностью зависеть от условий сервиса, который предоставляет провайдер. А провайдер, как правило, никаких гарантий не дает. В случае сбоя он пальцем о палец не ударит, чтобы восстановить данные, даже если сбой по его вине. Также он может в любой момент поменять условия контракта, или забить на качество сервиса, разориться, наконец, или поменяется геополитическая ситуация. И главное — вы ничего не сможете поделать. Мигрирация на другую платформу будет связана с большими затратами и временем в течении которой ваш бизнес… ну вы поняли…
Иногда еще приводят причину как «day X» (день П). Это когда ВНЕЗАПНО отключают интернет, или банальная авария на линии связи. Компания становится отрезана от облака, и весь ее бизнес стоит. Так что ваш бизнес зависим не только от SaaS провайдера, но и от локального телефонного оператора и даже от монтера Васи, ковыряющегося в соседнем люке.
Поэтому пока, когда речь заходит об использовании облаков, обычно говорят о рисками связанных с этим.
Каждый актер — это single-threaded объект, доступ к которому осуществляется через очередь сообщений (и различные враперы типа TypedActors). Т.о. не болит голова о синхронизации и блокировках. Все, что внутри объекта используется им эксклюзивно.
У архитектуры, построенной на актерах есть одно преимущество в то же время недостаток — она асинхронная. То есть в заданный момент времени нельзя определить четко состояние всей системы, что становится проблемой например при ее остановке. Не совсем ясно в какой последовательности останавливать актеров, т.к. они могут зависеть друг от друга. И если актер уже остановлен, а другой пытается послать ему сообщение, он вылетит с ошибкой. Поэтому у асинхронной архитектуры очереди сообщений обычно делают persistent и выносят в отдельный леер (JMS,MQ), чтобы при рестарте компонентов сообщения не терялись.
Также у асинхронной архитектуры есть пробемы для реализации сложной атомарной операции между актерами (транзакция), поскольку их состояние ни в какой момент несинхронизровано. В Akka для этой цели используют механизм транзакторов, которые могут координировать работу нескольких актеров. Другое решение — использовать Software Transaction Memory, реализация которой в Akka очень примитивна.
P.S. Еще замечание: использование синхронного request-reply в асинхронной архитектуре, равно как и «request-reply-with-future» — это 99% DEADLOCK. Единственное safe-решение — это request-with-callback.
Я не совсем понял как автор использует нечеткую логику в своем алгоритме. По-моему при работе такого алгоритма каждый if вычисляет сразу оба возможных варианта, форкая выполнение в новую ветвь и ставя в соответствие этой ветви вероятность, из условия. Результат работы такого алгоритма — это все множество результатов каждой из ветвей, взятых с соответствующей вероятностью (вообще не люблю термин «вероятность» и предпочитаю говорить «плотность»).
Алгоритм «if ( c ) then A else B» должен выдать:
A: с вероятностью ©
B: с вероятностью (1-c)
Если требуется, из этого множества результатов можно произвести дефазификацию (фон-неймановскую редукцию) методом взвешенного бросания костей (произвести измерение распределенной величины).
P.S. Еще такая мысль: практически любое высказывание человека объективно носит нечеткий характер. Однако субъективно (в его логической системе) оно всегда принимает либо истину, либо ложь. Отсюда корень непонимания между людьми ))
Маша — проныра. При минимуме усилий и выполненной работы получает максимальнуй личную выгоду. Обычно ничего не знает и не умеет (пологое начало графика). Зато активно идет по головам, работает локтями и присваивает себе результаты чужого труда, не гнушаясь никаких методов. Как вариант: пришла обычной секретуткой, соснула у шефа и стала начальником отдела. Затем подлегла под директора и стала топменеджером. Вот Вам и производная.
Даша — типичная карьеристка. Суетится только там, где это сулит в будущем личные переспективы. Чужую работу на себя не берет, считает это недостойным ее уровня, и видит себя исключительно на руководящей должности. Методично подминает под себя всех остальных в коллективе.
Наташа — типичный трудоголик. Выполняет всю работу, которую ей дают. Знания и навыки ей позволили быстро достигнуть своего уровня (крутое начало графика). Собственно это единственный эксперт в компании, который знает и понимает всю кухню. Именно поэтому ее карьера уперлась в потолок, т.к. заменить ее не кем (нет таких крутых спецов), а наверху уже сидят Маша и Даша.
Так что, аффтар, если вы делаете ставку на Машу и Дашу, то рискуете очень быстро быть выпнутым из своего мягкого кресла.
«I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.»
Основной недостаток Groovy — это динамическая типизация, когда тип переменной может быть вычислен только в runtime. В Scala была реализована сложная модель вычисления статических типов на этапе компиляции.
Один из бонусов type-safe языка, который я люблю — это то, что IDE знает типы и предлагает список полей и методов по Ctrl-Space В Groovy же приходится ползать в документацию.
Тем не менее для Groovy списывать рано. Для него написано огромное количество библиотек, и использование его для написания скриптов или второстепенных утилит очень оправдано. Однако для основного проекта я бы использовал его с осторожностью.
Тролли — жертвы — это те, кто реально пашет и пытается угнаться за постоянными изменениями, каждое из которых заставляет переделопачивать код.
Тролли-киллеры — это те, кто реально пытается разобраться в хреново написанной документации и состыковать бредовые идеи начальства между собой.
Тролли — выскочки — это те, кто реально умнее своих шефов, и у которых от работы с ними еще не угас весь энтузиазм.
Затем пишите тест:
1. Установить камеру в нужную позицию на игровой сцене
2. Отрендерить и сохранить в .png
3. Сравнить отрендеренное изображение с полученным с фотокамеры )))
А вообще подобные проекты тестируется при помощи хомячков (ну или лемингов) )))
Основной ошибкой проектирования систем является непонимание архитектора, что ошибка выполнения транзакции — это НОРМАЛЬНОЕ состояние, а не исключительная ситуация. При optimistic locking справедливо правило: «let it fault!». Стандартное решение в данной ситуации — это отслеживать коллизии и делать повтор. Однако ни один фреймворк по дефолту это не предлагает.
На практике во всех движках вместо ТруЪ serializable level используют более слабый snapshot isolation en.wikipedia.org/wiki/Snapshot_isolation
Каждая транзакция видит «снимок» базы на момент ее начала. Метод базируется на сохранении нескольких версий измененных данных, доступных на время другим транзакциям: en.wikipedia.org/wiki/Multiversion_concurrency_control
MVCC вместе с write lock дает хорошую производительность, и уровень близкий к serializable. Различие заключается лишь в том, что последовательность обработки двух разных транзакций не гарантируется.
Там надо нажать кнопку «Check your purchase» и «Credit Card»… Контора очень мажорная, поэтому, думаю, все сертификаты имеются. Только вот в свое время, когда у них сайт был написан еще на .asp список карт выфигачивался простой sql-injection. И даже не это главное. После демонстрации данной уязвимости клиенту, он ответил уже как-то неактуально, потому что через полгода у них вводится новый сайт (для которого я писал модуль интеграции с системами оплаты). После этого я зарекся оставлять номер карточки везде, кроме сайтов, делающих редирект на систему оплаты моего банка.
Кстати, многие авиакомпании просят иметь карточку при себе, когда регистрируешься на рейс, если билет был куплен по карточке. То есть они тоже сохраняют ее.
Поэтому на одном крупном сайте по заказу билетов по интернету покупку пользователя идентифицируют по номеру его кредитной карточки — единственная информация, которую пользователь оставляет о себе. В кассе необходимо лишь показать карточку.
2. > Необходимо позаботиться о многопоточном использовании observable-объекта
Отделите мух от супа. Многопоточная архитектура имеет совершенно иную специфику: синхронные и асинхронные события, блокирование, коллизии и повторы. В этому случае Вам подойдет модель актеров (Actors) akka.io
А для десктопной апликации не стоит так извращаться.
3. В Вашей реализации есть одна типичная ошибка: если обзервер, получив событие, больше не хочет принимать, он дерегистрирует себя из объекта-источника. В таком случае ваш цикл отсылки
for (T listener: _listeners) {
вылетит с ConcurrentModificationException, т.к. список _listeners был изменен во время прохода. Нужно проходить по копии _listeners.
4. Вообще модель продьюсер-обзервер плоха не столько количеством лишнего кода, сколько необходимостью строгого контроля регистрации/дерегистрации обзерверов. Это есть корень всех ошибок с memory leaking в программах Java. Java девелоперы, привыкшие к GC, редко заботятся об освобождении ресурсов, в том числе и дерегистрации обзерверов, которые так и болтаются в списке. Друкая проблема — запутанность логики, структуры и зависимостей. Поэтому все чаще в проектах используют EventBus как замену архитектуре producer-observer, напр. www.eventbus.org/
— Безопасность данных. Возможность доступа третьих лиц к данным компании в облачных платформах в сотни! раз больше. Потенциальный доступ имеют люди, не имеющие отношения к прозводственному циклу вашей компании (обслуживание DC). Облачные платформы не позволяют строить многоуровневую политику безопасности. Все аккаунты также хранятся в облаке. Использование публичных каналов для доступа к системе делает ее потенциально доступной для любого злоумышленника.
— Зависимость от провайдера. Ваш бизнес будет полностью зависеть от условий сервиса, который предоставляет провайдер. А провайдер, как правило, никаких гарантий не дает. В случае сбоя он пальцем о палец не ударит, чтобы восстановить данные, даже если сбой по его вине. Также он может в любой момент поменять условия контракта, или забить на качество сервиса, разориться, наконец, или поменяется геополитическая ситуация. И главное — вы ничего не сможете поделать. Мигрирация на другую платформу будет связана с большими затратами и временем в течении которой ваш бизнес… ну вы поняли…
Иногда еще приводят причину как «day X» (день П). Это когда ВНЕЗАПНО отключают интернет, или банальная авария на линии связи. Компания становится отрезана от облака, и весь ее бизнес стоит. Так что ваш бизнес зависим не только от SaaS провайдера, но и от локального телефонного оператора и даже от монтера Васи, ковыряющегося в соседнем люке.
Поэтому пока, когда речь заходит об использовании облаков, обычно говорят о рисками связанных с этим.