Вскользь упомянулась тема, которая не дает мне покоя уже многие годы. Когда загружается java приложение выполняется загрузка и валидация байткода, линковка методов, профайлинг кода и компиляция кода. Все это делается очень и очень долго, и именно поэтому джава до сих пор носит ярлык тормозной платформы. Было бы разумным хранить метаданные линковки, профайлинга и скомпилированный код между запусками jvm. И якобы из соображений безопасности этого не делают (хотя я навскидку могу предложить 10 secure способов хранения данных между запусками).
Кроме того, подобную вещь можно сделать для runtime library — заранее прекомпилировать частоиспользуемые методы и загружать в память уже native-код. Все современные ОС используют профайлинг апликаций для ускорения запуска, а Win7 даже предзагружает в бекграунде частоиспользуемые апликации. Если бы приложение запускалось 0.5 секунд вместо 10-15, то Java быстро нашла бы своих поклонников на десктопах.
В таком случае у Вас есть риск сорвать проект. Согласитель, что накладывание жестких дополнительных требований (таких как полный тестинг, документация, коментарии, etc...) повышает объем работы, увеличивает риски, а соответственно, и стоимость проекта. Но на такую вещь как риски далеко не все смотрят и не умеют их оценивать. Скажем, непрофессиональный подрядчик может неправильно оценить проект, поставить заведомо низкую цену и выиграть тендер. Когда же обнаружится, что это недоделка, и объем работ сильно превышает запланированное, он просто откажется дальше делать (ему просто это будет не выгодно). А суды, согласитесь, не лучший результат для исполнительного директора.
С другой стороны, даже если Вы обрежете Васей Пупкиных снизу и будете общаться только с подрядчиками, которые предложили более-менее адекватную цену, нет гарантии, что разработчик использует все эти «дополнительные» («тестовые») деньги по назначению. И это не проконтролировать. Чаще бывает, что делают такой же сырую разработку, а на остальное пьют. Еще чаще (специфика работы в стране, где я живу), субподряжают Васю Пупкина делать всю разработку за половину стоимости и сдают еще худший код.
Поэтому обычно закладывают, если объем незапланированных работ не превышает 10-15%. Если больше, то за пересматривается цена. К этому должны быть готовы как подрядчик, так и заказчик.
Есть еще модель, в которой с подрядчиком помимо разработки заключается договор на обслуживание системы. Часть денег снимается а разработки и раскидывается на поддержку. За фиксированную плату в месяц он обязуется оперативно исправлять все возникшие инциденты. Это хорошо тем, что ответственность ложится на самого разработчика (ему выгоднее делать хорошо), и за фиксированную плату заказчик гарантирует себе функциональность с минимальными рисками.
Больше интересно какие у Scala есть возможности интеграции с J2EE проектами. Web framework — это одно. Его пишут все кому не лень. Реально нужны следующие вещи:
Hibernate,
JAXB,
WS на Scala,
Spring+Scala,
etc…
У Groovy есть одно большое преимущество над Scala: source-совместимость с Java. Поэтому один и тот же код (например модель) можно использовать в Groovy и Java.
Это все хорошо, но как это ни странно звучит, данный гидлайн — пособие как заработать минимум денег при максимуме работы. Моя практика показывает, что если у клиента все будет работать «как надо», то клиент к Вам больше не обратится. Естественно, у клиента что-то все-таки должно работать. Но вот беда, если изначально в цену засандалишь все затраты на тесты, рефакторинг, коментарии и все прочее о чем тут писалось, просто провалишь тендер. Клиент скажет: «Вася Пупкин Консалтинг делает дешевле» и точка. Качество работы — не объективный показатель при заключении сделки. Чаще всего выигрывается тендер, заключается контракт, клиенту предоставляется первая рабочая, но сырая версия системы, не лишенная недостатков. Далее исправление ошибок, доработка, доводка техзадания — за отдельную плату. А то, что у вас в коде нет комментариев, гарантирует, что клиент для второй фазы обратится к Вам.
Поняв недостатки Maven, Apache потихоньку переходит на новую систему билдинга проектов, названную Ivy. Основное отличие от Maven2 — это именно интеграция с Ant-ом. Собственно Ivy — это не более чем облегченный менеджер зависимостей, а билдинг модулей осуществляется именно Ant-ом.
Основной недостаток Maven состоит в том, что сборка модуля осуществляется только при помощи стандартных плагинов или расширений, которые плохо документированы, и очень не гибкие. Адаптировать сборку для неординатрого случая в Maven бывает очень сложно. В Ivy же можно иметь абсолютно свой сценарий сборки для каждого конкретного случая.
P.S. в последнее время стал смотреть в сторону OSGi. OSGi bundles уже внутри прописывают все зависимости. Имеются несколько репозиториев с бандлами.
> Q: Я физически могу скопировать информацию – значит, по закону, мне никто не может это запрещать.
> A: Я физически могу подойти к вам ночью и пырнуть вас заточкой под ребра. Что будет со мной потом – это отдельная статья (105, если я не ошибаюсь)
Подумайте на досуге, если существует статья существует за воровство, почему каждый из нас, уходя из дома, запирает его? И почему машины запираем и стараемся в них не хранить ничего ценного? И вообще, зачем нам замки? Давайте хранить вещи прямо на улице! Ведь каждый осознает, что брать чужое нельзя, и кроме того за это есть статья!
Закон не устраняет физическую возможность воровства. Поэтому пытаться устранить законом физическую возможность копирования информации также будет глупо. А раз вы не можете физическим способом защитить авторское право — изворачивайтесь как хотите. Меняйте бизнес-модель, сбавляйте цены, берите за счет массовости, делайте фильмы, которые можно смотеть только в кинотеатрах…
> Q: Почему это так дорого стоит? Я считаю, что оно должно стоить дешевле.
> A: Потому что правообладатель считает, что именно столько оно должно стоить. И у него, замечу, на это есть полное право.
Не забываем, что правообладатель и производитель — это в нынешнем мире не одно и то же. Правообладатель — это медиаконцерн, зачастую монополист в своей области. Тогда как только ничтожная часть моих денег до производителя. Зачем мне кормить систему по впариванию мне же дерьма, которое я не хочу?
Более 5 лет работаю на рынке интеграции систем для телефонных компаний. Могу сказать точно — до сих пор нет НИ ОДНОГО нормального middleware для интеграции. И что самое печальное, до сих пор маюсь вопросом: НАФИГА оно вообще нужно? Клиент думает, что покупает панацею от всех проблем, но все с точностью до наоборот.
1. Любое Enterprise middleware не решает проблему дизайна архитектуры системы, которую все-равно так или иначе приходится разрабатывать.
2. Не устанавливает никакой четкой медотики разработки. Цикл разработки и versioning процессов — бич всех BPM-систем, до сих пор не разрешенный.
3. Лимитирует разработчика в использовании средств. Сильно усложняет многие простые концепты. Как правило даже невозможно сделать нормально модульный тестинг.
4. Такое ощущение, что SCA вообще не предназначена для бизнес-решений. Нет динамической линковки между модулями и сервисами! А когда количество модулей и связей между ними растет, и диаграмма зависимостей становится сложной, возникают неразрешимые проблемы при deploy.
5. А BPEL между прочим абсолютно не предназначен для бизнес-процессов! Через 4-5 лет поняли, наконец, и пытаются заменить BPMN.
6. А повсеместное испльзование WSDL и XSD приводит к тому, что если меняется интерфейс, то изменения затрагивают сразу ВСЕ модули, что создает дополнительные проблемы с versioning-ом.
7. Решения жутко тяжелые, глючные и тормозные. Абсолютно непредсказуемы в поведении. Требуют гораздо больше затрат в support & maintenance (чаще всего кто-то должен крутить педали, чтобы это все работало).
P.S. С BizTalk не работал. Использовали Websphere — глюкалово, которае просто не работает (с дорогущей и бесполезной поддержкой). Относительно неплохое Middleware от Oracle, но очень тяжелое.
В качестве эксперимента был использован OSGi+Camel+Spring+jBPM. Результат превзошел ожидания.
Пока одни исследуют шаблоны программирования, предлагают архитектуру систем, концепции интеграции, изучают различные методики командной работы над проектом, разрабатывают фреймворки и библиотеки, etc… другие посвящают себя вопросу «как написать еще короче».
А третьи уверены, что единственно верный и прогрессивный способ лечить зубы — это засунуть бор-машину вместе с дентистом в рот пациенту. И призывают всех к этому.
Это еще один пример, когда разработчик совсем не думает о тех, кто его изделием будет пользоваться. Задача решена методично и в лоб.
А дабы не портить иммидж минкульта (оно же в народе «хуячечная»), в настройках поиска требовалось бы приделать галочку типа: «выводить результаты, включая порнуху».
Ясное дело… В Новой Зеландии нет ни одной IT-компании с патентами на ПО. Поэтому сие здравое решение принимается с такой легкостью. Я бы пошел дальше и вообще бы отменил патенты. Успешная идея и разработка всегда дают тебе преимущество на рынке. Но спекулировать на идее, при этом ничего не производя — это не есть гут.
1. Делая запрос в релационных рбд каждый раз приходится полностью или частично указывать модель данных (пересечение таблиц, импортируемые ключи), а это не есть хорошо. В ообд модель данных определяется один раз и используется автоматически при запросах.
2. Рбд не поддерживают наследование в полной мере.
3. Попытка реализовать иерархическую модель в рбд также упирается в сложности, особенно если модель с нечеткой структурой.
4. Для ОРМ можно легко и прозрачно использовать кэш-прослойку между бизнес леером и datastore (JBoss Cache, Oracle Coherence). Как показывают тесты, производительность в таком случае увеличивается в разы.
5. ОРМ-объекты могут предоставлять бизнес приложению более гибкие средства доступа к данным, например можно мепить значения полей в свои типы. Тогда как набор типов в SQL очень ограничен (например далеко не все поддерживают тип поля Array).
6. Реальная переносимость у SQL никакая. Приложение, написанное для Oracle, 100% не будет работать на MSSQL. Тогда как для ORM нужно поменять всего лишь пару строчек.
7. И последнее. Даже если использовать голый SQL, на каком-то этапе приложения все-равно придется меппинг полей в бизнес-объекты (напр. для представления или для отдачи вебсервису). Так или иначе придется организовывать свой уровень DAO. И ORM здесь возьмет на себя всю рутинную часть задачи.
Может не в тему, но на моей тачке со включенным Cool&Quiet USB-audio временами издавал достающие клики, особенно при нагрузне на графику. Подозреваю, что причиной является то же самое.
С коммерческим использованием есть одна большая проблема: огромная энергия сосредоточена в маленьком объеме. Для того, чтобы работали генераторы, нужен очень быстрый отвод, который невозможно достичь никаким средствами — при таких температурах любая структура начинает разрушаться.
Напишите официальный документ, в котором подробно расписаны возникшие проблемы. Приложите дневную статистику вашего бизнеса и посчитайте ущерб. Потребуйте возмещения потерь провайдером, хотя бы в качестве нескольких месяцев без оплаты за хостинг.
В Европе тоже такое бывает. У нашего провайдера случился пожар. В результате страницы нескольких крупных банков и министерств лежали, а сотни тысяч пользователей ADSL не могли нормально открыть страницу (оказывается в этом датацентре стояли ОБА DNS одного крупного провайдера).
Вообще в случаях сбоев и крупных технических неполадок провайдер ответственность нести не будет — у них в датацентре могут крутиться многомиллионные деньги, которые он естественно компенсировать не в состоянии. Поэтому если хотите обезопасить свой бизнес, заключите договор со страховой компанией.
Операционная система располагает рядом сервисов и api, которые используют программы. В идеале, процесс должен иметь соответствующий мандат на вызов каждого потенциально опасного api. Набор мандатов можно объединить в security-профайл, который объединяет все права, данные конкретному процессу.
Проблема вот в чем, каждый процесс зачастую должен для конкретного действия повышать уровень своих привелегий. Например, если у нас браузер болтается в самом закрытом профайле, то он не сможет сохранять скачиваемые файлы на диск. Для этого ОС должна иметь соответствующий сервис, который имеет более высокие привелегии, но лимитирует возможность клиента на использование этого API. Дополнительно этот сервис может спрашивать подтверждения у пользователя на небезопасное действие.
Кстати, в Java подобным образом реализована система привилегий.
А почему бы просто вручную не монтировать шифрованный раздел каждый раз, когда сервер стартует? Все-равно перезагрузки всегда делает администратор…
Чтобы не обвинили в препятствии расследованию, можно хранить фейковые данные на основном разделе. То есть сервисы запускаются, но данные используют из фейковой базы. Шифрованный раздел потом монтируется поверх фейковой базы (напр. в /var/lib/mysql).
Кроме того, подобную вещь можно сделать для runtime library — заранее прекомпилировать частоиспользуемые методы и загружать в память уже native-код. Все современные ОС используют профайлинг апликаций для ускорения запуска, а Win7 даже предзагружает в бекграунде частоиспользуемые апликации. Если бы приложение запускалось 0.5 секунд вместо 10-15, то Java быстро нашла бы своих поклонников на десктопах.
С другой стороны, даже если Вы обрежете Васей Пупкиных снизу и будете общаться только с подрядчиками, которые предложили более-менее адекватную цену, нет гарантии, что разработчик использует все эти «дополнительные» («тестовые») деньги по назначению. И это не проконтролировать. Чаще бывает, что делают такой же сырую разработку, а на остальное пьют. Еще чаще (специфика работы в стране, где я живу), субподряжают Васю Пупкина делать всю разработку за половину стоимости и сдают еще худший код.
Поэтому обычно закладывают, если объем незапланированных работ не превышает 10-15%. Если больше, то за пересматривается цена. К этому должны быть готовы как подрядчик, так и заказчик.
Есть еще модель, в которой с подрядчиком помимо разработки заключается договор на обслуживание системы. Часть денег снимается а разработки и раскидывается на поддержку. За фиксированную плату в месяц он обязуется оперативно исправлять все возникшие инциденты. Это хорошо тем, что ответственность ложится на самого разработчика (ему выгоднее делать хорошо), и за фиксированную плату заказчик гарантирует себе функциональность с минимальными рисками.
Hibernate,
JAXB,
WS на Scala,
Spring+Scala,
etc…
У Groovy есть одно большое преимущество над Scala: source-совместимость с Java. Поэтому один и тот же код (например модель) можно использовать в Groovy и Java.
Основной недостаток Maven состоит в том, что сборка модуля осуществляется только при помощи стандартных плагинов или расширений, которые плохо документированы, и очень не гибкие. Адаптировать сборку для неординатрого случая в Maven бывает очень сложно. В Ivy же можно иметь абсолютно свой сценарий сборки для каждого конкретного случая.
P.S. в последнее время стал смотреть в сторону OSGi. OSGi bundles уже внутри прописывают все зависимости. Имеются несколько репозиториев с бандлами.
> A: Я физически могу подойти к вам ночью и пырнуть вас заточкой под ребра. Что будет со мной потом – это отдельная статья (105, если я не ошибаюсь)
Подумайте на досуге, если существует статья существует за воровство, почему каждый из нас, уходя из дома, запирает его? И почему машины запираем и стараемся в них не хранить ничего ценного? И вообще, зачем нам замки? Давайте хранить вещи прямо на улице! Ведь каждый осознает, что брать чужое нельзя, и кроме того за это есть статья!
Закон не устраняет физическую возможность воровства. Поэтому пытаться устранить законом физическую возможность копирования информации также будет глупо. А раз вы не можете физическим способом защитить авторское право — изворачивайтесь как хотите. Меняйте бизнес-модель, сбавляйте цены, берите за счет массовости, делайте фильмы, которые можно смотеть только в кинотеатрах…
> Q: Почему это так дорого стоит? Я считаю, что оно должно стоить дешевле.
> A: Потому что правообладатель считает, что именно столько оно должно стоить. И у него, замечу, на это есть полное право.
Не забываем, что правообладатель и производитель — это в нынешнем мире не одно и то же. Правообладатель — это медиаконцерн, зачастую монополист в своей области. Тогда как только ничтожная часть моих денег до производителя. Зачем мне кормить систему по впариванию мне же дерьма, которое я не хочу?
www.youtube.com/watch?v=CAEQuE-ygjA
1. Любое Enterprise middleware не решает проблему дизайна архитектуры системы, которую все-равно так или иначе приходится разрабатывать.
2. Не устанавливает никакой четкой медотики разработки. Цикл разработки и versioning процессов — бич всех BPM-систем, до сих пор не разрешенный.
3. Лимитирует разработчика в использовании средств. Сильно усложняет многие простые концепты. Как правило даже невозможно сделать нормально модульный тестинг.
4. Такое ощущение, что SCA вообще не предназначена для бизнес-решений. Нет динамической линковки между модулями и сервисами! А когда количество модулей и связей между ними растет, и диаграмма зависимостей становится сложной, возникают неразрешимые проблемы при deploy.
5. А BPEL между прочим абсолютно не предназначен для бизнес-процессов! Через 4-5 лет поняли, наконец, и пытаются заменить BPMN.
6. А повсеместное испльзование WSDL и XSD приводит к тому, что если меняется интерфейс, то изменения затрагивают сразу ВСЕ модули, что создает дополнительные проблемы с versioning-ом.
7. Решения жутко тяжелые, глючные и тормозные. Абсолютно непредсказуемы в поведении. Требуют гораздо больше затрат в support & maintenance (чаще всего кто-то должен крутить педали, чтобы это все работало).
P.S. С BizTalk не работал. Использовали Websphere — глюкалово, которае просто не работает (с дорогущей и бесполезной поддержкой). Относительно неплохое Middleware от Oracle, но очень тяжелое.
В качестве эксперимента был использован OSGi+Camel+Spring+jBPM. Результат превзошел ожидания.
А третьи уверены, что единственно верный и прогрессивный способ лечить зубы — это засунуть бор-машину вместе с дентистом в рот пациенту. И призывают всех к этому.
А дабы не портить иммидж минкульта (оно же в народе «хуячечная»), в настройках поиска требовалось бы приделать галочку типа: «выводить результаты, включая порнуху».
2. Рбд не поддерживают наследование в полной мере.
3. Попытка реализовать иерархическую модель в рбд также упирается в сложности, особенно если модель с нечеткой структурой.
4. Для ОРМ можно легко и прозрачно использовать кэш-прослойку между бизнес леером и datastore (JBoss Cache, Oracle Coherence). Как показывают тесты, производительность в таком случае увеличивается в разы.
5. ОРМ-объекты могут предоставлять бизнес приложению более гибкие средства доступа к данным, например можно мепить значения полей в свои типы. Тогда как набор типов в SQL очень ограничен (например далеко не все поддерживают тип поля Array).
6. Реальная переносимость у SQL никакая. Приложение, написанное для Oracle, 100% не будет работать на MSSQL. Тогда как для ORM нужно поменять всего лишь пару строчек.
7. И последнее. Даже если использовать голый SQL, на каком-то этапе приложения все-равно придется меппинг полей в бизнес-объекты (напр. для представления или для отдачи вебсервису). Так или иначе придется организовывать свой уровень DAO. И ORM здесь возьмет на себя всю рутинную часть задачи.
Есть более простой и переспективный проект — котел взрывного сгорания.
www.ntpo.com/invention/invention2/3.shtml
В Европе тоже такое бывает. У нашего провайдера случился пожар. В результате страницы нескольких крупных банков и министерств лежали, а сотни тысяч пользователей ADSL не могли нормально открыть страницу (оказывается в этом датацентре стояли ОБА DNS одного крупного провайдера).
Вообще в случаях сбоев и крупных технических неполадок провайдер ответственность нести не будет — у них в датацентре могут крутиться многомиллионные деньги, которые он естественно компенсировать не в состоянии. Поэтому если хотите обезопасить свой бизнес, заключите договор со страховой компанией.
Проблема вот в чем, каждый процесс зачастую должен для конкретного действия повышать уровень своих привелегий. Например, если у нас браузер болтается в самом закрытом профайле, то он не сможет сохранять скачиваемые файлы на диск. Для этого ОС должна иметь соответствующий сервис, который имеет более высокие привелегии, но лимитирует возможность клиента на использование этого API. Дополнительно этот сервис может спрашивать подтверждения у пользователя на небезопасное действие.
Кстати, в Java подобным образом реализована система привилегий.
Чтобы не обвинили в препятствии расследованию, можно хранить фейковые данные на основном разделе. То есть сервисы запускаются, но данные используют из фейковой базы. Шифрованный раздел потом монтируется поверх фейковой базы (напр. в /var/lib/mysql).