Одну важную вещь всегда опускают, когда говорят про транзакции — это принцип «let it fault». Транзакция не обязана завершиться успешно. В случае, когда возникает коллизия на write, одна из них всегда откатывается. Поэтому приложение должно уметь отлавливать такие случаи и повторять попытку изменений с самого начала. Практически нигде в примерах это даже не упоминается. К сожалению, во всех системах, с которыми я имел дело, подобная проверка отсутствует (если это не делается самой платформой).
Другое свойство, которое не часто упоминается, это изолированность транзакций. Большинство STM сделано на схеме MVCC, а она не отвечает «full-serialized» уровню, поскольку отсутствуют read locks. Работа на таком уровне чревата неприятным эффектом write skew.
На самом деле я не вижу сильно ограниченным использование STM, разве что в экзотических решениях. Для несложных структур можно использовать стандартные классы библиотеки java.concurrent, а сложные графы хранить в памяти без persistence как правило нет нужды. В большинстве архитектур shared state реализуется как раз на уровне persistence в базе данных, а все, что находится в памяти — это временные данные: либо immutable объекты, либо «isolated mutability». STM не масштабируются: для этого есть множество других решений типа distributed cache. Обход большого графа в STM достаточно накладен, требуются дополнительные индексирующие структуры для быстрого доступа. Вобщем, in-memory движки баз данных уже имеют весь необходимый функционал и являются более стандартным решением для хранения shared state.
В одно время в проекте встал вопрос использовать STM или in-memory database, и выбор именно на последний (JPA+H2).
Столкнулся с такой фичей браузера Андроида 4.x: после событий touchstart — touchend он всегда посылает mousedown — mouseup (после интервала в 300мс), даже если было запрошено event.preventDefault(), event.stopPropagation() или вообще удален handler. Это сильно мешает логике, если приложение хочет обрабатывать и мышку и тачи. Хорошего решения нет, кроме как отслеживать если mouseup пришел в интервале до 400мс после touchend с похожими координатами, то игнорировать его.
Про Израиль был пример того, что при помощи технологий можно эффективно обойти климатические условия. Посмотрите какие в Голландии теплицы! Это все технологии, в которые надо вкладываться и которые надо развивать. Если у нас экономика до сих пор «хапово-отжимательная», то естественно никто не будет вкладываться в серьезное предприятие с рентабельностью в 6-10 лет.
> решить проблему полива в пустыне дешевле, чем проблему обогрева и освещения в наших краях
Если ее не решать, то она сама собой не решится. Какие в России мы можем назвать специфические эффективные высокотехнологические решения для наших климатических условий? Сраная вебаста, колонка и нагреватель — и то все германское. Плюс положение России компенсируется природными энергоресурсами. Кто виноват, что мы предпочитаем их продавать за границу, за доллары-евро и затем на эти доллары-евро покупать там товары, нежели производить все прямо здесь? Опять же — у нас климат не тот, и рожей мы не вышли.
> Но прибыль от технологий получит тот, кто эти технологии имплементирует с минимальными издержками.
Как бы уже давно все разрабатывается в Европе/Штатах, а производится в Китае. США — крупнейший импортер товаров из Китая. Сидеть на печи и проектировать микрочипы или клепать софт — это, конечно, требует огромных энергоиздержек. Разрабатывать генетические модифицированные культуры — это тоже тонны нефти. Весь советский космический комплекс был создан в тюремной шаражке! И, как это ни странно, на фоне всех возможных типов индустрии у нас развито именно тяжелое энергопотребляющее производство — плавка чугунины, алюминия и прочее, которое по идее должно быть неэффективно в наших краях. Добыть и выплавить здесь чугунину, отправить с нефтегазом в Европу, чтобы там из него собрали автомобиль, потому что там это «эффективно из-за климата», а затем этот автомобиль привезти сюда и продать тут — это вообще нонсенс! Благо мировые концерны автомпроизводителей сразу сообразили, что такое положение вещей можно сильно оптимизировать, сделав заводы прямо в России, чтобы клепать не отходя от кассы. И вот тут кроется сильный аргумент: выходит, Форд и другие работают себе в убыток, раз производить в России не выгодно? Почему стоимость такого же автомобиля, выпущенного в России меньше, чем в Европе? Выходит, не климат решающий фактор?
> Да, с коррупцией надо бороться
И на этом мысль останавливается. Все ждут, что придет кто-то и эту коррупцию поганую ссаными тряпками выгонит. Коррупция начинается с себя, с соседа в квартире, с гаишника, требующего взятку.
А, ну да. Очень удобная книга! Оправдывает все и сразу: разгильдяйство, коррупцию, пассивность, тиранию, отсутствие роста и развития. Типа, успокойтесь, у вас все-равно нет будущего! Все построено в ней на заведомо ложной теории: зависимость от территориального расположения, и доказывается ненаучным путем. Опровергается просто.
Во-первых, в большинстве стран с разной степенью «благоприятности» климата мы не наблюдаем сильно развитой экономики. Во-вторых, также существуют экономически развитые страны, где климат хуже, либо не многим лучше, чем в России, напр. Скандинавия. В-третьих, основной упор сделан на то, что развитая экономика основана исключительно на экстенсивном производстве и сельском хозяйстве (для размышления, почему Израиль, находящийся в пустыне, экспортирует апельсины?). И что производимая энергия и зерно — это единственынй ресурс, который имеет смысл. А как же технологии? А банковское дело? И еще куча всяких ляпов. Основная проблема книги — доказываются заведомо неверные или ложные идеи. И делается это скорей всего преднамеренно.
> Но фактически, по-моему, есть величина, показывающая сколько сейчас денег в обороте и сколько можно товаров и услуг на них купить — просто моментальный срез
Ах, если бы все так просто было!
Во-первых, деньги в прямом обороте, деньги в кредитных обязательствах и деньги в ценных бумагах — это совершенно разные деньги с различными функциями. Даже сравнивать их некорректно. Объем рынка ценных бумаг во много раз превосходит товарный рынок.
Во-вторых, так уж устроена современная экономика, она оперирует в будущем. Есть различные понятия — фьючерс, кредит, финансовое обязательство, etc… которые соответствуют предполагаемому положению вещей в будущем, а не реальному на данный момент. По сути товар еще не выпущен на рынок, а для его производства и возможности его купить, уже напечатаны. Поэтому моментальный «срез» будет делать некорректно.
В-третьих, недостаток полной информации. Сейчас нет стран с полностью независимой экономикой. Экономики всех стран тесно связаны. Если положение внутри страны еще можно посчитать, то другие страны такой информацией особо не делятся. Никогда не знаешь кто на ком завязан и как отразится крах одного фонда на всех остальных.
Просто пример: цены на нефть вдруг начинают падать. Что происходит с экономикой Этой Страны — понятно. Непонятно почему? Товаров и услуг производится столько же, денег осталось столько же, даже нефтегаз вырабатывается в таком же количестве. Что изменилось для страны?
Это понятно и логично, но плоско и недалеко, поэтому верно лишь в ооочень отдаленном приближении. Реально не существует никакой физической величины как «обеспеченность валюты». Даже примерно посчитать похожую величину не представляется возможным, поскольку помимо величин, отражающих текущее состояние экономики (ВВП, займы, etc...) присутствует огромное количество неопределенных и вероятностных факторов: индексы развития, прогнозы, etc… То есть реальный курс валюты базируется на текущем доверии к ней гораздо в бОльшей мере, чем на реальных экономических показателях, формируя легенду о ее цене. А доверием можно успешно манипулировать.
То есть то, что Вам продали буханку за 34 рубля, не значит, что ее реальная стоимость такова, а то, что на данный момент времени предприниматель верит, что такова стоимость рубля по отношению к его буханке. В банке в свою очередь верят в то, что на данный 34 рубля соответствуют 1 доллару. Кому больше верит предприниматель — легенде о долларе или рубле легко заметить, как изменятся цены на хлеб, когда доллар поползет вверх. В России есть два товарного эталона доверия к любому обмену: хлеб и водка, к ним доверия больше, чем к рублю.
Проблема в манипуляции доверием. В локальном масштабе ЦБ может завышать/занижать курс валюты. В глобальном — различные рейтинговые агенства, крупные финансовые операции, СМИ и еще куча рычагов вплоть до войны и революции.
> Будет больше рублей при том же количестве буханок хлеба и 34 рубля уже не хватит
Это неверно. Акций АО МММ в определенный период становилось все больше и больше, но тем не менее их цена росла. Все дело в спросе на валюту и доверие к ней. Для этого нужно показать рост твоей собственной валюты, либо ослабить доверие покупателей к своим собственным.
Ну, Вы взяли клинические случаи. Обычно клиника резко отличается от нормальных девиаций тем, что происходит серьезный «сбой» одной из функций (иногда обусловленный физиологически) и это резко смещает всю остальную крышу. Поэтому клиника хорошо диагносцируется, изучена в достаточной мере и классифицирована.
А вот девиации в поведении «нормального» человека сложно описать. Во-первых, потому что «договориться о симптомах» не получается. Есть определенные наблюдаемые признаки, например коммуникабельность. Но вызваны они могут быть настолько разными совокупностями внутренних причин (время, место, внутреннее состояние, социальная среда и т.д.), что никакое обобщение тут не может быть. К счастью психологию спасает то, что она не требует научно достоверной корреляции. Более 60% — это уже прогресс для теории. Поэтому какую бы мы модель ни взяли, она вроде как бы работает, но всегда с некоторыми оговорками :)))
>> «чистых интровертов и экстравертов очень мало»
Это все-равно что сказать, что модель не работает. Есть куча попыток построить механистическую модель психики, но все они либо не работают, либо бесполезны. Если мы используем холистический подход и рассматриваем психику как единое целое, то это не позволяет нам выделить группы и их характерные черты — каждый человек будет уникальным и для каждого мы должны разрабатывать свою теорию. Если следовать редукционистскому подходу и пытаться выделить устойчиыве компоненты психики, то становится понятно, что по отдельности они ничего не значат и не описывают. Это хорошо заметно в популярной ныне соционике, где идея дробления доведена в модели А до абсурда.
Не так давно избавились в продакшне от Java 1.4. Используем тяжелые пропиетарные сервера типа Websphere и Weblogic. Практика показывает, что апгрейд продакшна происходит раз в 5 лет, и основной мотив апгрейда — окончание саппорта установленной версии. И как правило апгрейд происходит не до последней ветки, а до предыдущей или чаще пред-предыдущей. Плюс, компании-производители не спешат внедрять нововведения в свои сервера, а клиенты не спешат покупать последние версии. Поэтому цикл между выходом спецификации и появлением этой версии в продакшне для коммерческого продукта занимает годы. Для OpenSource все гораздо быстрее.
На сегодняшний день в продакшне: Java 6, JEE5 (с трудом для последнего проекта настоял на JEE6).
Возможно повторюсь, но ошибка здесь в частом ненужном обращении к индексам. Сразу надо заметить, что «оптимизация» треугольниками ложная, т.к. (i+j) — это ничего не стоящая операция, по сравнению с правильным обходом массива.
Надо понимать, что в Java двумерные массивы не являются матрицами, а массивами из массивов. Поэтому оптимальным способом представления матрицы является ее компактификация в одномерный массив. Но раз уж задание с двумерным массивом, попробуем оптимизировать…
g[i] дает указатель на одномерный массив строки, причем вычисляется при заполнении каждого столбца. При этом происходит вычисление смещения элемента, проверка выхода за границы и доступ к объекту по указателю. Это можно исключить:
for(int i = 0; i < n; i++) {
int[] row = g[i];
for(int j = 0; j < n; j++) {
row[j] = i + j;
}
}
Вопрос, а стоит ли овчинка выделки? Насколько эффективность разработки на Scala покрывает ее сложность? Если мы возьмем полный цикл разработки проекта в команде, окажется ли он менее затратным, чем, скажем на Java? Я очень сомневаюсь. Методы решения поставленной задачи сильно не отличаются. Да, Scala эффективней тем, что меньше приходится писать. Но написание кода — это лишь небольшой процент от всего объема работы. Возможно, выигрываешь в написании — проигрываешь в отладке и поддержке.
P.S. меня чисто эстетически воротит от Scala. Ее могли сделать только люди с напрочь отбитым эстетическим вкусом. При всей ее сложности синтаксис можно было бы сделять в сто раз приятнее, избегая засилия закорючек. В скале засилие сахара, искусственных конструкций, неявных преобразований и соглашений по умолчанию превышает все мыслимые и немыслимые пределы. Такое впечатление, что основная идея Одерски: «а давайте включим в язык сразу все, что есть в других языках, и это сделает его универсальным на все случаи жизни». Красота как раз в минимализме.
По-моему язык, в котором код делает не то, что написано, эффектно бы смотрелся в презентации Акопяна или Кио. Scala со всей своей подкапотной магией, стремится стать сборником всевозможных заклинаний. Куча неявного, скрытого, магического и эзотерического. Когда кругом одна магия начинаешь чувствовать себя Гарри Поттером. Я предпочитаю принцип «less magic, more logic», который со Scala не совместим.
По логике вещей, HFT должны предотвращать резкие колебания курсов, вызванных крупными сделками. И если все так плохо с HFT, почему бы не создать «долгосрочную» биржу, где сделки совершаются с заранее установленным интервалом? По принципу пошаговой стратегии…
Есть много методов, но все они так или иначе эксплуатируют уже известные вещи:
1. Γαστριμαργία (gastrimargia) чревоугодие
Как Вы думаете, почему обед с клиентом давно стал неотъемлимой частью бизнес переговоров? Еда усыпляет бдительность, тормозит мыслительный процесс и создает располагающее настроение.
2. Πορνεία (pornia) прелюбодеяние, блуд (половая распущенность)
Использовать неформальные отношения для получения личной выгоды — это целое искусство, которое дано не многим, но многие к нему прибегают. Использование обнаженного тела в рекламе привлекает внимание.
3. Φιλαργυρία (philargüria) алчность
Позволяет впаривать клиенту совершенно ненужные и бесполезные для него вещи. Необходимо лишь возбудить интерес и желание обладать ею.
4. Λύπη (lüpē) печаль
В таком состоянии клиент утрачивает адекватность и становится легко внушаемым. Здесь нужно быть настойчивей — клиент не будет сильно сопротивляться.
5. Ὀργή (orgē) гнев
Находясь в состоянии гнева, клиент тратит много сил впустую. Гнев затмевает разум. При жестком соперничестве это заставляет делать ошибки, принимать несвоевременные или неадекватные решения, которые оборачиваются проблемами или крахом.
6. Ἀκηδία (acēdia) уныние
Нежелание клиента думать и действовать самому. Предложите взять на себя все его проблемы, чтобы он подсел на вас и ваши услуги. Когда это произойдет, клиентом можно будет вертеть как угодно.
7. Κενοδοξία (cenodoxia) тщеславие
У желания выделиться перед остальными не существует цены! :) Клинт выбросит последние деньги, дабы иметь возможность продемонстрировать свое превосходство перед другими. Позиционирование элитного продукта «не для нищебродов» непременно возымеет свое действие.
8. Ὑπερηφανία (huperēphania) гордыня
Озвучивание несуществующих достоинств и пение хвалебных дифирамбов. Побольше лести! Лесть усыпляет бдительность и распахивает врата! ;)
Для экспериментов есть прекрасный легковесный контейнер Apache TomEE, который может запускаться в embedded режиме прямо из любого JavaSE приложения. Имеется неплохая документация и отличные примеры: tomee.apache.org/examples-trunk/index.html Не требует геморроя со сборкой и деплоем на сервак — пускаем/дебагим прямо из IDE!
Для работы я использую Eclipse+JBoss Tools и JBoss AS 7. Redhat молодцы — допилили процесс разработки до удобоваримого состояния. В JBoss Tools одним кликом можно добавить в workspace уже готовые шаблоны проектов и погонять их. Есть step-by-step tutorials & examples: www.jboss.org/developer/quickstarts.html (NB! некоторые примеры используют технологии JBoss, не входящие в JavaEE)
Если Вы разработчик и делаете реальные проекты, забудьте про JavaEE и будьте счастливы! JavaEE вам нужно исключительно для устройства на работу в какую-нибудь контору. Это набор раскрученных брендов, которые заставляют клиента выкладывать бабки. Какая-либо практическая ценность в ней отсутствует. Коротко: JavaEE — это о том как сложно, долго и дорого написать простую вебстраничку.
Я работаю с джава с 95 года, JavaЕЕ начал осваивать потихоньку с 2005. На всем протяжении постоянно не покидал вопрос: «нахрена так сложно»? Все задачи решались традиционным способом в разы быстрее на традиционной джаве с помощью библиотек. Все, что было заявлено в спецификации достаточно рудиментарно и не используется в 95% реальных проектов. А в 5% можно найти простую альтернативу. Более того, называть это все стандартом очень натянуто. Со 100% вероятностью EE-приложение, написанное под JBoss не будет работать под Weblogic без дополнительного допила. Это потому, что спецификация очень ограниченная, и производители всегда добавляют собственные расширения, чтобы обойти ограничения. Последние спецификации JavaEE взяли много от фреймворков типа Spring. Это позволило хоть как-то мало-мальски улучшить ситуацию, но не поменяло радикально.
Ну а сам процесс разработки под EE — это хождение по мукам. Просто начиная с того, чтобы запустить Weblogic нужно ждать пару минут, еще минут десять, чтобы сделать билд проекту, задеплоить, проверить сраную страничку и удалить. Примерно как в начале семидесятых. Поэтому существует куча технологий-хаков, которые ненамного пытаются улучшить ситуацию (Arquillian, JRebel, etc), которые надо будет тоже изучить. Вся разработка будет сводиться к поиску нужного рецепта, обходу ограничений платформы, борьбе с багами имплементации и непредвиденными сбоями приложений. Короче, ничего хорошего.
Это понятно, что при правильном использовании ORM также эффективен. Но мой опыт работы в реальных проектах показывает, что ORM везде используется неэффективно. Знание принципов работы ORM требует большей подготовки, нежели просто знание SQL, а его использование — меньшей. Поэтому сайтоклепатель или джавист-джуниор с легкостью напишет:
for ( Invoice in: em.createQuery(«SELECT i FROM Invoice i»).getResultList() ) {
… in.getClient().getName();
}
Для него это логично, несмотря на то, что клиент лежит в другой талице, и будет запрашиваться для каждого счета. Если Вы работаете в команде над достаточно большим проектом, за этим не уследить. Тем более что сам дизайн ORM всячески агитирует всех так делать.
В последнем проекте пришлось работать с относительно небольшим объемом связанных специальным образом данных, для которых приходилось производить процедуру проверки на целостность — много массивных запросов и джоинов. В итоге:
— 3 багрепорта в Hibernate JRA: проблемы связаны с compound PK: некорректной генерацией JOIN-ов для H2, некорректным связыванием в IN(), некорректной генерацией UPDATE WHERE x IN(SELECT...)
— 2 багрепорта в EclipseLink: неверной генерацией NOT IN(SELECT...), неверной генерацией UPDATE WHERE x IN(SELECT...)
При этом использовались последние версии обеих ORM и базы Oracle/H2.
— Стандарт ORM сильно ограничивал возможности запросов. В частности не поддерживаются: подзапросы FROM (SELECT), JOIN-ы между любыи сущностями (только те, для которых определено отношение в ORM).
— странности в поведении при попытке делать merge сущности с коллекцией элементов, замепленных в другую таблицу (EclipseLink).
— непредсказуемость, обусловленная внутренним кешированием объектов: UPDATE не изменяет полей объекта, если он ранее где-то испльзовался и был запрошен. Повторный SELECT и em.find() опять вернет старую версию объекта (тем не менее WHERE будет реагировать на изменения). Единственно верный способ — вызывать em.refresh() для каждого объекта (долго).
— сложности в передаче объектов по сети (deproxying, lazy fetch).
В итоге я не увидел практически никаких преимуществ использования ORM в проекте перед голым SQL-ем. Автоматический меппинг данных в структуры в состоянии написать любой java-программист. Библиотеки вроде jOOQ и QueryDSL делают код запросов typesafe и независимым от СУБД, полагаясь на SQL.
Я имею ввиду от NVidia. Пробовал и официальные из репозиториев убунту, и последние из ppa (304, 319, 331, etc...) Уже года три как не имел проблем с видеокартой — все ставилось из репозиториев и работало на ура. В последнем апдейте все драйвера nvidia начали сбоить и виснуть. Видимо какая-то несовместимость в ядре в ветке 3.11. Странно, что только у меня и еще у пары человек такая же проблема. (NVidia GT240)
Другое свойство, которое не часто упоминается, это изолированность транзакций. Большинство STM сделано на схеме MVCC, а она не отвечает «full-serialized» уровню, поскольку отсутствуют read locks. Работа на таком уровне чревата неприятным эффектом write skew.
На самом деле я не вижу сильно ограниченным использование STM, разве что в экзотических решениях. Для несложных структур можно использовать стандартные классы библиотеки java.concurrent, а сложные графы хранить в памяти без persistence как правило нет нужды. В большинстве архитектур shared state реализуется как раз на уровне persistence в базе данных, а все, что находится в памяти — это временные данные: либо immutable объекты, либо «isolated mutability». STM не масштабируются: для этого есть множество других решений типа distributed cache. Обход большого графа в STM достаточно накладен, требуются дополнительные индексирующие структуры для быстрого доступа. Вобщем, in-memory движки баз данных уже имеют весь необходимый функционал и являются более стандартным решением для хранения shared state.
В одно время в проекте встал вопрос использовать STM или in-memory database, и выбор именно на последний (JPA+H2).
> решить проблему полива в пустыне дешевле, чем проблему обогрева и освещения в наших краях
Если ее не решать, то она сама собой не решится. Какие в России мы можем назвать специфические эффективные высокотехнологические решения для наших климатических условий? Сраная вебаста, колонка и нагреватель — и то все германское. Плюс положение России компенсируется природными энергоресурсами. Кто виноват, что мы предпочитаем их продавать за границу, за доллары-евро и затем на эти доллары-евро покупать там товары, нежели производить все прямо здесь? Опять же — у нас климат не тот, и рожей мы не вышли.
> Но прибыль от технологий получит тот, кто эти технологии имплементирует с минимальными издержками.
Как бы уже давно все разрабатывается в Европе/Штатах, а производится в Китае. США — крупнейший импортер товаров из Китая. Сидеть на печи и проектировать микрочипы или клепать софт — это, конечно, требует огромных энергоиздержек. Разрабатывать генетические модифицированные культуры — это тоже тонны нефти. Весь советский космический комплекс был создан в тюремной шаражке! И, как это ни странно, на фоне всех возможных типов индустрии у нас развито именно тяжелое энергопотребляющее производство — плавка чугунины, алюминия и прочее, которое по идее должно быть неэффективно в наших краях. Добыть и выплавить здесь чугунину, отправить с нефтегазом в Европу, чтобы там из него собрали автомобиль, потому что там это «эффективно из-за климата», а затем этот автомобиль привезти сюда и продать тут — это вообще нонсенс! Благо мировые концерны автомпроизводителей сразу сообразили, что такое положение вещей можно сильно оптимизировать, сделав заводы прямо в России, чтобы клепать не отходя от кассы. И вот тут кроется сильный аргумент: выходит, Форд и другие работают себе в убыток, раз производить в России не выгодно? Почему стоимость такого же автомобиля, выпущенного в России меньше, чем в Европе? Выходит, не климат решающий фактор?
> Да, с коррупцией надо бороться
И на этом мысль останавливается. Все ждут, что придет кто-то и эту коррупцию поганую ссаными тряпками выгонит. Коррупция начинается с себя, с соседа в квартире, с гаишника, требующего взятку.
Во-первых, в большинстве стран с разной степенью «благоприятности» климата мы не наблюдаем сильно развитой экономики. Во-вторых, также существуют экономически развитые страны, где климат хуже, либо не многим лучше, чем в России, напр. Скандинавия. В-третьих, основной упор сделан на то, что развитая экономика основана исключительно на экстенсивном производстве и сельском хозяйстве (для размышления, почему Израиль, находящийся в пустыне, экспортирует апельсины?). И что производимая энергия и зерно — это единственынй ресурс, который имеет смысл. А как же технологии? А банковское дело? И еще куча всяких ляпов. Основная проблема книги — доказываются заведомо неверные или ложные идеи. И делается это скорей всего преднамеренно.
Ах, если бы все так просто было!
Во-первых, деньги в прямом обороте, деньги в кредитных обязательствах и деньги в ценных бумагах — это совершенно разные деньги с различными функциями. Даже сравнивать их некорректно. Объем рынка ценных бумаг во много раз превосходит товарный рынок.
Во-вторых, так уж устроена современная экономика, она оперирует в будущем. Есть различные понятия — фьючерс, кредит, финансовое обязательство, etc… которые соответствуют предполагаемому положению вещей в будущем, а не реальному на данный момент. По сути товар еще не выпущен на рынок, а для его производства и возможности его купить, уже напечатаны. Поэтому моментальный «срез» будет делать некорректно.
В-третьих, недостаток полной информации. Сейчас нет стран с полностью независимой экономикой. Экономики всех стран тесно связаны. Если положение внутри страны еще можно посчитать, то другие страны такой информацией особо не делятся. Никогда не знаешь кто на ком завязан и как отразится крах одного фонда на всех остальных.
Просто пример: цены на нефть вдруг начинают падать. Что происходит с экономикой Этой Страны — понятно. Непонятно почему? Товаров и услуг производится столько же, денег осталось столько же, даже нефтегаз вырабатывается в таком же количестве. Что изменилось для страны?
То есть то, что Вам продали буханку за 34 рубля, не значит, что ее реальная стоимость такова, а то, что на данный момент времени предприниматель верит, что такова стоимость рубля по отношению к его буханке. В банке в свою очередь верят в то, что на данный 34 рубля соответствуют 1 доллару. Кому больше верит предприниматель — легенде о долларе или рубле легко заметить, как изменятся цены на хлеб, когда доллар поползет вверх. В России есть два товарного эталона доверия к любому обмену: хлеб и водка, к ним доверия больше, чем к рублю.
Проблема в манипуляции доверием. В локальном масштабе ЦБ может завышать/занижать курс валюты. В глобальном — различные рейтинговые агенства, крупные финансовые операции, СМИ и еще куча рычагов вплоть до войны и революции.
> Будет больше рублей при том же количестве буханок хлеба и 34 рубля уже не хватит
Это неверно. Акций АО МММ в определенный период становилось все больше и больше, но тем не менее их цена росла. Все дело в спросе на валюту и доверие к ней. Для этого нужно показать рост твоей собственной валюты, либо ослабить доверие покупателей к своим собственным.
А вот девиации в поведении «нормального» человека сложно описать. Во-первых, потому что «договориться о симптомах» не получается. Есть определенные наблюдаемые признаки, например коммуникабельность. Но вызваны они могут быть настолько разными совокупностями внутренних причин (время, место, внутреннее состояние, социальная среда и т.д.), что никакое обобщение тут не может быть. К счастью психологию спасает то, что она не требует научно достоверной корреляции. Более 60% — это уже прогресс для теории. Поэтому какую бы мы модель ни взяли, она вроде как бы работает, но всегда с некоторыми оговорками :)))
Это все-равно что сказать, что модель не работает. Есть куча попыток построить механистическую модель психики, но все они либо не работают, либо бесполезны. Если мы используем холистический подход и рассматриваем психику как единое целое, то это не позволяет нам выделить группы и их характерные черты — каждый человек будет уникальным и для каждого мы должны разрабатывать свою теорию. Если следовать редукционистскому подходу и пытаться выделить устойчиыве компоненты психики, то становится понятно, что по отдельности они ничего не значат и не описывают. Это хорошо заметно в популярной ныне соционике, где идея дробления доведена в модели А до абсурда.
На сегодняшний день в продакшне: Java 6, JEE5 (с трудом для последнего проекта настоял на JEE6).
Надо понимать, что в Java двумерные массивы не являются матрицами, а массивами из массивов. Поэтому оптимальным способом представления матрицы является ее компактификация в одномерный массив. Но раз уж задание с двумерным массивом, попробуем оптимизировать…
g[i] дает указатель на одномерный массив строки, причем вычисляется при заполнении каждого столбца. При этом происходит вычисление смещения элемента, проверка выхода за границы и доступ к объекту по указателю. Это можно исключить:
for(int i = 0; i < n; i++) { int[] row = g[i]; for(int j = 0; j < n; j++) { row[j] = i + j; } }P.S. меня чисто эстетически воротит от Scala. Ее могли сделать только люди с напрочь отбитым эстетическим вкусом. При всей ее сложности синтаксис можно было бы сделять в сто раз приятнее, избегая засилия закорючек. В скале засилие сахара, искусственных конструкций, неявных преобразований и соглашений по умолчанию превышает все мыслимые и немыслимые пределы. Такое впечатление, что основная идея Одерски: «а давайте включим в язык сразу все, что есть в других языках, и это сделает его универсальным на все случаи жизни». Красота как раз в минимализме.
1. Γαστριμαργία (gastrimargia) чревоугодие
Как Вы думаете, почему обед с клиентом давно стал неотъемлимой частью бизнес переговоров? Еда усыпляет бдительность, тормозит мыслительный процесс и создает располагающее настроение.
2. Πορνεία (pornia) прелюбодеяние, блуд (половая распущенность)
Использовать неформальные отношения для получения личной выгоды — это целое искусство, которое дано не многим, но многие к нему прибегают. Использование обнаженного тела в рекламе привлекает внимание.
3. Φιλαργυρία (philargüria) алчность
Позволяет впаривать клиенту совершенно ненужные и бесполезные для него вещи. Необходимо лишь возбудить интерес и желание обладать ею.
4. Λύπη (lüpē) печаль
В таком состоянии клиент утрачивает адекватность и становится легко внушаемым. Здесь нужно быть настойчивей — клиент не будет сильно сопротивляться.
5. Ὀργή (orgē) гнев
Находясь в состоянии гнева, клиент тратит много сил впустую. Гнев затмевает разум. При жестком соперничестве это заставляет делать ошибки, принимать несвоевременные или неадекватные решения, которые оборачиваются проблемами или крахом.
6. Ἀκηδία (acēdia) уныние
Нежелание клиента думать и действовать самому. Предложите взять на себя все его проблемы, чтобы он подсел на вас и ваши услуги. Когда это произойдет, клиентом можно будет вертеть как угодно.
7. Κενοδοξία (cenodoxia) тщеславие
У желания выделиться перед остальными не существует цены! :) Клинт выбросит последние деньги, дабы иметь возможность продемонстрировать свое превосходство перед другими. Позиционирование элитного продукта «не для нищебродов» непременно возымеет свое действие.
8. Ὑπερηφανία (huperēphania) гордыня
Озвучивание несуществующих достоинств и пение хвалебных дифирамбов. Побольше лести! Лесть усыпляет бдительность и распахивает врата! ;)
Для изучения есть неплохая связка NetBeans+Glassfish и официальный тьюториал от Oracle: docs.oracle.com/javaee/6/tutorial/doc/
Для экспериментов есть прекрасный легковесный контейнер Apache TomEE, который может запускаться в embedded режиме прямо из любого JavaSE приложения. Имеется неплохая документация и отличные примеры: tomee.apache.org/examples-trunk/index.html Не требует геморроя со сборкой и деплоем на сервак — пускаем/дебагим прямо из IDE!
Для работы я использую Eclipse+JBoss Tools и JBoss AS 7. Redhat молодцы — допилили процесс разработки до удобоваримого состояния. В JBoss Tools одним кликом можно добавить в workspace уже готовые шаблоны проектов и погонять их. Есть step-by-step tutorials & examples: www.jboss.org/developer/quickstarts.html (NB! некоторые примеры используют технологии JBoss, не входящие в JavaEE)
P.S. В помощь EE-разработчику: www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html
Я работаю с джава с 95 года, JavaЕЕ начал осваивать потихоньку с 2005. На всем протяжении постоянно не покидал вопрос: «нахрена так сложно»? Все задачи решались традиционным способом в разы быстрее на традиционной джаве с помощью библиотек. Все, что было заявлено в спецификации достаточно рудиментарно и не используется в 95% реальных проектов. А в 5% можно найти простую альтернативу. Более того, называть это все стандартом очень натянуто. Со 100% вероятностью EE-приложение, написанное под JBoss не будет работать под Weblogic без дополнительного допила. Это потому, что спецификация очень ограниченная, и производители всегда добавляют собственные расширения, чтобы обойти ограничения. Последние спецификации JavaEE взяли много от фреймворков типа Spring. Это позволило хоть как-то мало-мальски улучшить ситуацию, но не поменяло радикально.
Ну а сам процесс разработки под EE — это хождение по мукам. Просто начиная с того, чтобы запустить Weblogic нужно ждать пару минут, еще минут десять, чтобы сделать билд проекту, задеплоить, проверить сраную страничку и удалить. Примерно как в начале семидесятых. Поэтому существует куча технологий-хаков, которые ненамного пытаются улучшить ситуацию (Arquillian, JRebel, etc), которые надо будет тоже изучить. Вся разработка будет сводиться к поиску нужного рецепта, обходу ограничений платформы, борьбе с багами имплементации и непредвиденными сбоями приложений. Короче, ничего хорошего.
for ( Invoice in: em.createQuery(«SELECT i FROM Invoice i»).getResultList() ) {
… in.getClient().getName();
}
Для него это логично, несмотря на то, что клиент лежит в другой талице, и будет запрашиваться для каждого счета. Если Вы работаете в команде над достаточно большим проектом, за этим не уследить. Тем более что сам дизайн ORM всячески агитирует всех так делать.
В последнем проекте пришлось работать с относительно небольшим объемом связанных специальным образом данных, для которых приходилось производить процедуру проверки на целостность — много массивных запросов и джоинов. В итоге:
— 3 багрепорта в Hibernate JRA: проблемы связаны с compound PK: некорректной генерацией JOIN-ов для H2, некорректным связыванием в IN(), некорректной генерацией UPDATE WHERE x IN(SELECT...)
— 2 багрепорта в EclipseLink: неверной генерацией NOT IN(SELECT...), неверной генерацией UPDATE WHERE x IN(SELECT...)
При этом использовались последние версии обеих ORM и базы Oracle/H2.
— Стандарт ORM сильно ограничивал возможности запросов. В частности не поддерживаются: подзапросы FROM (SELECT), JOIN-ы между любыи сущностями (только те, для которых определено отношение в ORM).
— странности в поведении при попытке делать merge сущности с коллекцией элементов, замепленных в другую таблицу (EclipseLink).
— непредсказуемость, обусловленная внутренним кешированием объектов: UPDATE не изменяет полей объекта, если он ранее где-то испльзовался и был запрошен. Повторный SELECT и em.find() опять вернет старую версию объекта (тем не менее WHERE будет реагировать на изменения). Единственно верный способ — вызывать em.refresh() для каждого объекта (долго).
— сложности в передаче объектов по сети (deproxying, lazy fetch).
В итоге я не увидел практически никаких преимуществ использования ORM в проекте перед голым SQL-ем. Автоматический меппинг данных в структуры в состоянии написать любой java-программист. Библиотеки вроде jOOQ и QueryDSL делают код запросов typesafe и независимым от СУБД, полагаясь на SQL.