Используем на проекте TeamCity + встроенный в него dotCover. Настраивается это все минут за 15 через GUI. Советую попробовать для какого-нибуть нового проекта — очень классное решение, у меня одни позитивные эмоции.
Не нужно быть професионалом в обеих технологиях, что бы понимать как они устроены и работают. Любому человеку, мало-мальски знакомому с архитектурой обех платформ, понятно, что принципы, заложенные в основу там одинаковые. Это, а так же результаты сотен тестов в сети — вполне надежное основание утверждать, что джава и дотнет — технологии одного типа и одного порядка быстродействия. Если вам показывают разницу в быстродействии более чем на два порядка — значит вас где-то обманывают.
Я вот дотнетчик и вообще коренной виндузятник, но прекрасно понимаю, почему было принято такое решение. Высоконагруженные трейдинговые системы такого масштаба — это настолько дорогие и критичные к производительности системы, что они могут позволить себе взять хоть голое ядро линукса и допилить его до нужного состояния. Понятно, что специально заточеный под определенную задачу инструмент будет куда эффективнее другого, рассчитанного на широкий круг задач. И опять же понятно, что допилить открытый линукс куда проще чем закрытую винду.
Кроме того, выше уже писали, что совершенно неясно, какого качества была предыдущая система. Переход с дотнета на джаву не может дать прирост быстродействия в 400 раз, более того скорее всего этого прироста не будет вообще. Скорее всего все дело в кривой архитектуре предыдущей системы.
Не совсем так. Конечно очередь нам все равно нужна, но памяти она будет занимать намного меньше чем стек в случае рекурсии. Например в крайнем случае, когда вся картинка размером NxM будет залита одним цветом, в случае поиска в глубину нам понадобится стек глубиной N*M, тогда как максимальный размер очереди в поиске в ширину в этом случае будет чуть больше чем min(N, M). Реализовать очередь, зная, что в ней никогда не будет больше чем определенное количество элементов, очень просто, например с помощью циклического буфера в памяти.
По времени — поиск это тоже один проход по изображению, поэтому я не понимаю почему углы будут быстрее. По памяти, да у них есть небольшое преимущество. Зато у поиска есть другое преимущество: можно сразу выделить связанные области и пометить их разными «цветами», попутно еще и определив размер каждой области.
Нетрудно заметить, что этот алгоритм использует рекурсию, а значит, у нас возникает две потенциальных проблемы. Во-первых, скорость работы алгоритма может быть недостаточной для обработки данных в реальном времени, во-вторых, потенциально нам может не хватать размера стека, особенно, если мы говорим о реализации этого алгоритма в железе (ПЛИС).
Достаточно заменить поиск в глубину поиском в ширину и можно обойтись без рекурсии.
1. В случае с 2-х звенкой у вас в БД просто неявно будет спрятано два уровня — логики и доступа к данным. В противном случае очень сложно, а то и вовсе невозможно будет организовать юнит-тесты бизнес-логики, а без них жить очень сложно. Соответственно, в общем случае нет никакой разницы, где находится логика — на сервере БД или на middle-tier сервере, а так как последний проще масштабируется, то выбор очевиден. Конечно, если приложение небольшое и развивать его не планируют, то 2-х звенка банально дешевле, поэтому стоит выбирать ее. В таком случае 3-х звенка это как использовать паттерн MVC для домашней странички с фотографией кота — профита никакого, а затраты непропорционально огромны, лучше написать простейший скрипт на РНР. Но если ваш проект куда больших масштабов то нужны другие подходы.
2. Приложение с логикой в БД у нас браузерное. Построено на паттерне MVP, где модель как раз большей частью и лежит в БД, а остальные части в виде XML/XSLT на веб-сервере. Поэтому как апдейтить клиенты в таком случае я и сам не знаю. Другое приложение, в котором есть клиенты, работает через middle-tier, который как раз и обеспечивает изоляцию структуры БД от клиента.
Что касается апдейта структуры БД и логики на лету — то это очень сложно. У нас специфика позволяет это делать например ночью, когда приложением не пользуются, поэтому мы особо не заморачиваемся. Но вообще, процесс у нас обычно занимает считанные минуты, так что иногда это возможно сделать и на ходу, просто временно заблокировав сервер (клиенты умеют работать в оффлайне).
3. Каждое изменение структуры таблиц в БД оформляется в виде отдельного скрипта с именем вида 20110205.000.vasya.pupkin.sql и кладется в специальную папку в репозитории. Плюс есть специальный инструмент, который позволяет отслеживать изменения в процедурах и других обьектах основной девелоперской БД и раз в пол часа коммитит их в репозиторий. При обновлении сначала сносятся все процедуры и прочие обьекты кроме таблиц, потом проганяются скрипты, которые еще не применялись к этой БД, в нужном порядке, после чего пересоздаются все процедуры с нуля. Все автоматизированно. Единственный минус — не видно кто из разработчиков что менял в процедурах и для чего, так как скрипт все комитит от одного аккаунта и с одним комментарием «автоматический коммит». Процес довольно сложный и не совсем удобен, но отточен за годы разработки и сейчас его менять никто уже не будет.
В общем, по моему личному мнению, чем больше вы отвязываетесь от БД, тем легче вам жить. Но это мнение основано на моем опыте разработки довольно специфического корпоративного софта.
Я про все это прекрасно знаю.
1. Да, мы это даже используем в одном из наших приложений. Небольшие куски кода вполне возможно разворачивать на сервере с БД и динамически переносить на внешние сервера, но чесно говоря, по моему мнению это уже как бы и не хранимки. Плюс, если вы например попытаетесь сделать какое-нибуть кеширование данных в памяти с помощью статических полей или просто распаралелить какой-нибуть алгоритм, который должен обращатся к синхронизированным данным, то это выльется в головную боль при разворачивании, в связи с тем, что это требует UNSAFE-прав от пользователя, а это сложно и часто пугает заказчиков.
2. Знаю. Помогает не сильно.
Да-да, но удовольствием это перестает быть когда у вас в проекте полтора миллиона строк кода и десятки компаний-заказчиков с тысячами пользователей.
Все зависит от задач и масштабов. Подход прекрасно работает с мелкими проектами и малой загрузкой. Но когда масштабы растут, архитектура тоже должна менятся.
У нас есть довольно крупный проект, написанный на MSSQL/.Net/XSLT в котором используется как раз такой подход. Вообще да, это работает, но у подхода довольно много недостатков, например сложнее горизонтально масштабировать, ошибки в коде хранимок часто невозможно отследить в силу того, что код не компилируется, я уже молчу про юнит-тесты для этого добра.
П.С. Тому проекту скоро уже лет 7, поэтому поменять что-либо уже не представляется возможным, но если бы я сейчас стартовал аналогичный — ни за что бы не выбрал подобную модель.
Фокус с интегралами Ворд тоже умеет (одна и та же формула в строке и в отдельном блоке):
И, что стало для меня новостью, формулы в OOXML это тоже язык разметки, да еще и TeX-like, как утверждает википедия. Даже не знаю зачем я это пишу, видимо просто чтобы поделится интересной информацией :)
Ну я немного утрировал. Но в конце-концов нужно же понимать, что многие ошибки, которые были допущены в той же ХР уже давно исправлены в той же Висте или 7. Между ХР и 7 почти десятилетие работы над ошибками. И вместо того, чтобы сидеть под древней по нынешним меркам ХР и ругать ее, стоит попробовать новые версии. И что вопя «венда — говно» в комментариях на Хабре многие персонажи забывают о том, что Винда Винде рознь.
2 года сижу на 7 (еще с беты) и ни разу не отключал UAC. И софта с таким требованием не встречал. Игрушка ваша лицензионная была или с торрентов скачаная?
Кроме того, выше уже писали, что совершенно неясно, какого качества была предыдущая система. Переход с дотнета на джаву не может дать прирост быстродействия в 400 раз, более того скорее всего этого прироста не будет вообще. Скорее всего все дело в кривой архитектуре предыдущей системы.
По времени — поиск это тоже один проход по изображению, поэтому я не понимаю почему углы будут быстрее. По памяти, да у них есть небольшое преимущество. Зато у поиска есть другое преимущество: можно сразу выделить связанные области и пометить их разными «цветами», попутно еще и определив размер каждой области.
2. Приложение с логикой в БД у нас браузерное. Построено на паттерне MVP, где модель как раз большей частью и лежит в БД, а остальные части в виде XML/XSLT на веб-сервере. Поэтому как апдейтить клиенты в таком случае я и сам не знаю. Другое приложение, в котором есть клиенты, работает через middle-tier, который как раз и обеспечивает изоляцию структуры БД от клиента.
Что касается апдейта структуры БД и логики на лету — то это очень сложно. У нас специфика позволяет это делать например ночью, когда приложением не пользуются, поэтому мы особо не заморачиваемся. Но вообще, процесс у нас обычно занимает считанные минуты, так что иногда это возможно сделать и на ходу, просто временно заблокировав сервер (клиенты умеют работать в оффлайне).
3. Каждое изменение структуры таблиц в БД оформляется в виде отдельного скрипта с именем вида 20110205.000.vasya.pupkin.sql и кладется в специальную папку в репозитории. Плюс есть специальный инструмент, который позволяет отслеживать изменения в процедурах и других обьектах основной девелоперской БД и раз в пол часа коммитит их в репозиторий. При обновлении сначала сносятся все процедуры и прочие обьекты кроме таблиц, потом проганяются скрипты, которые еще не применялись к этой БД, в нужном порядке, после чего пересоздаются все процедуры с нуля. Все автоматизированно. Единственный минус — не видно кто из разработчиков что менял в процедурах и для чего, так как скрипт все комитит от одного аккаунта и с одним комментарием «автоматический коммит». Процес довольно сложный и не совсем удобен, но отточен за годы разработки и сейчас его менять никто уже не будет.
В общем, по моему личному мнению, чем больше вы отвязываетесь от БД, тем легче вам жить. Но это мнение основано на моем опыте разработки довольно специфического корпоративного софта.
1. Да, мы это даже используем в одном из наших приложений. Небольшие куски кода вполне возможно разворачивать на сервере с БД и динамически переносить на внешние сервера, но чесно говоря, по моему мнению это уже как бы и не хранимки. Плюс, если вы например попытаетесь сделать какое-нибуть кеширование данных в памяти с помощью статических полей или просто распаралелить какой-нибуть алгоритм, который должен обращатся к синхронизированным данным, то это выльется в головную боль при разворачивании, в связи с тем, что это требует UNSAFE-прав от пользователя, а это сложно и часто пугает заказчиков.
2. Знаю. Помогает не сильно.
Да-да, но удовольствием это перестает быть когда у вас в проекте полтора миллиона строк кода и десятки компаний-заказчиков с тысячами пользователей.
Все зависит от задач и масштабов. Подход прекрасно работает с мелкими проектами и малой загрузкой. Но когда масштабы растут, архитектура тоже должна менятся.
П.С. Тому проекту скоро уже лет 7, поэтому поменять что-либо уже не представляется возможным, но если бы я сейчас стартовал аналогичный — ни за что бы не выбрал подобную модель.
И, что стало для меня новостью, формулы в OOXML это тоже язык разметки, да еще и TeX-like, как утверждает википедия.
Даже не знаю зачем я это пишу, видимо просто чтобы поделится интересной информацией :)