Аффтар! Вы не проанализировали первопричины и сделали абсолютно неправильные выводы.
Маша — проныра. При минимуме усилий и выполненной работы получает максимальнуй личную выгоду. Обычно ничего не знает и не умеет (пологое начало графика). Зато активно идет по головам, работает локтями и присваивает себе результаты чужого труда, не гнушаясь никаких методов. Как вариант: пришла обычной секретуткой, соснула у шефа и стала начальником отдела. Затем подлегла под директора и стала топменеджером. Вот Вам и производная.
Даша — типичная карьеристка. Суетится только там, где это сулит в будущем личные переспективы. Чужую работу на себя не берет, считает это недостойным ее уровня, и видит себя исключительно на руководящей должности. Методично подминает под себя всех остальных в коллективе.
Наташа — типичный трудоголик. Выполняет всю работу, которую ей дают. Знания и навыки ей позволили быстро достигнуть своего уровня (крутое начало графика). Собственно это единственный эксперт в компании, который знает и понимает всю кухню. Именно поэтому ее карьера уперлась в потолок, т.к. заменить ее не кем (нет таких крутых спецов), а наверху уже сидят Маша и Даша.
Так что, аффтар, если вы делаете ставку на Машу и Дашу, то рискуете очень быстро быть выпнутым из своего мягкого кресла.
«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 провайдера, но и от локального телефонного оператора и даже от монтера Васи, ковыряющегося в соседнем люке.
Поэтому пока, когда речь заходит об использовании облаков, обычно говорят о рисками связанных с этим.
Воспроизведение звука — это считывание устройством информации с носителя и преобразование в звуковые колебания. Одно дело если носитель полностью публичный. Например, если Вы услышали на улице композицию, или проходите мимо стадиона и слышите музыку от проходящего там концерта, то Вас никто не может заставить заткнуть уши. Но в данном случае носителем информации является эфир (волна с определенной частотой), которая к сожалению, публичной не является. Волна принадлежит радиостанции (за нее деньги уплачены). Поэтому настройка на частоту — это фактически считывание информации, принадлежащей радиостанции, которая распространяется посредством оной с определенными ограничениями (использование в некоммерческих целях).
Точно также Вы можете бесплатно получить диск с фильмом или музыкой на промоакции, но не имеете права использовать его в коммерческих целях (ставить у себя в парикмахерской и т.д.) Или даже программное обеспечение (напр. Oracle) находится в свободном доступе на сайте производителя. Его можно скачивать и использовать в личных целях для ознакомления. Однако для продакшн с вас потребуют купить дорогую лицензию.
Так что тут с юридической стороны все чисто. Любой контент, находящийся в свободном доступе свободном доступе, также имеет лицензионные ограничения. Даже в случае радио.
Единственный способ защиты для парикмахерской я вижу в том, что они не были знакомы с лицензией распространения контента данной радиостанцией (напр. лицензионное соглашение показывается всегда, когда Вы ставите DVD и появляется disclaimer, или софт при установке просит нажать Accept...). Т.е. радиостанция в перерыве между песнями должна постоянно информировать: «напоминаем Вам, что условия распространения...». Однако если уже принят закон о радиовещании, который все это оговаривает по дефолту, то дело проиграно. Незнание законов не освобождает от ответственности.
P.S. тем не менее иметь парикмахеру и клиенту личный плеер с fm никто не запрещает…
Маша — проныра. При минимуме усилий и выполненной работы получает максимальнуй личную выгоду. Обычно ничего не знает и не умеет (пологое начало графика). Зато активно идет по головам, работает локтями и присваивает себе результаты чужого труда, не гнушаясь никаких методов. Как вариант: пришла обычной секретуткой, соснула у шефа и стала начальником отдела. Затем подлегла под директора и стала топменеджером. Вот Вам и производная.
Даша — типичная карьеристка. Суетится только там, где это сулит в будущем личные переспективы. Чужую работу на себя не берет, считает это недостойным ее уровня, и видит себя исключительно на руководящей должности. Методично подминает под себя всех остальных в коллективе.
Наташа — типичный трудоголик. Выполняет всю работу, которую ей дают. Знания и навыки ей позволили быстро достигнуть своего уровня (крутое начало графика). Собственно это единственный эксперт в компании, который знает и понимает всю кухню. Именно поэтому ее карьера уперлась в потолок, т.к. заменить ее не кем (нет таких крутых спецов), а наверху уже сидят Маша и Даша.
Так что, аффтар, если вы делаете ставку на Машу и Дашу, то рискуете очень быстро быть выпнутым из своего мягкого кресла.
«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 провайдера, но и от локального телефонного оператора и даже от монтера Васи, ковыряющегося в соседнем люке.
Поэтому пока, когда речь заходит об использовании облаков, обычно говорят о рисками связанных с этим.
Точно также Вы можете бесплатно получить диск с фильмом или музыкой на промоакции, но не имеете права использовать его в коммерческих целях (ставить у себя в парикмахерской и т.д.) Или даже программное обеспечение (напр. Oracle) находится в свободном доступе на сайте производителя. Его можно скачивать и использовать в личных целях для ознакомления. Однако для продакшн с вас потребуют купить дорогую лицензию.
Так что тут с юридической стороны все чисто. Любой контент, находящийся в свободном доступе свободном доступе, также имеет лицензионные ограничения. Даже в случае радио.
Единственный способ защиты для парикмахерской я вижу в том, что они не были знакомы с лицензией распространения контента данной радиостанцией (напр. лицензионное соглашение показывается всегда, когда Вы ставите DVD и появляется disclaimer, или софт при установке просит нажать Accept...). Т.е. радиостанция в перерыве между песнями должна постоянно информировать: «напоминаем Вам, что условия распространения...». Однако если уже принят закон о радиовещании, который все это оговаривает по дефолту, то дело проиграно. Незнание законов не освобождает от ответственности.
P.S. тем не менее иметь парикмахеру и клиенту личный плеер с fm никто не запрещает…