Нет, это Вы не понимаете. Все эти универсальные архитектуры с красивым и правильным кодом — очень привлекательная теория, которая на практике практически не работает. В реальности существует простой выбор — либо универсально, либо эффективно.
И вопросы поддержки и разработки новых фич никто не отменял.
«Неудачники нам не нужны». (с) =)
А если кроме шуток, то реальность такова, что в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Иными словами, кампании разработчику выгоднее убедить клиента поставить еще одну машину с windows, чем портировать высокотехнологичный софт на другую платформу — wellcome to real world.
А меня просто забавляют такие теоретики… =)
Братцы линухоиды и просто любители писать «правильный кросс-платформенный софт», простите, но похоже, что вы этим просто никогда не занимались.
Посмотрев однажды за разработкой одного такого продукта, для тестирования которого необходимо было иметь порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков, я стал жутко преданным сторонником Microsoft.
Вы просто не представляете, какое счастье, что есть кампания, которая выпускает софт для 95% машин и разрабатывая свою продукцию под ее платформу, можно с чистой совестью забить на полпроцента неудачников!
Ребята, я хочу заниматься разработкой, а не изнурительной синхронизацией между разными платформами, которые сами не очень заботятся о совместимости (к слову, в отличии от той же MS).
Себистоимость производства и цена для конечного пользователя — две большие разницы.
Для примера можно посмотреть себистоимость одного процессора интел в начале и в конце жизненного цикла, (перед выходом на рынок и перед прекращением производства). И если, даже при массовом производстве не удалось снизить себистоимость ниже 30 USD, да еще и по тем временам — неудивительно, что его не стали применять.
SourceSafe благополучно сдох много лет назад и внутри Microsoft им не пользовались.
Для собственного использования, до недавнего времени, у MS был Source Depot, допиленный под их нужды, который являлся веткой Perforce. Сейчас весь MS плааавно переходит на Team Foundation Server, благодаря чему TFS постепенно становится довольно достойным продуктом.
У кого-то есть иллюзия равенства в компании без рангов?
Дискомфорт испытывается не от наличия рангов, так как четко понятен способ свой ранг повысить, а от отношения. Я встречал кампании, где никаких рангов нет, но начальство ест в отдельной столовой, пользуется отдельным входом и имеет массу других привелегий, которые простым смертным никогда не будут доступны — вот это действительно несколько озлобляет. А от рангов, на практике, только польза.
Система формальных рангов дает четкое понимание своей позиции и набор формальных критериев для достижения определенного положения, что в значительной мере избавляет от проявления различного рода офисного кун-фу.
Нет, это Вы не понимаете что происходит… =)
Вы хотите получить от ABBYY контент словарей. Для этого вам надо убедить ABBYY продать Вам эти словари, и я пытаюсь Вам помочь в свершении этого благого дела, рассказывая реальный путь решения проблемы.
И лицензионное соглашение Lingvo здесь совершенно не причем. Нет никакого смысла пытаться убедить компанию ABBYY позволить выдирать словари из готового продукта, вот это ABBYY совсем не нужно.
Я думаю, если вы напишите реальное коммерческое предложение на sales@abbyy.com, то вполне можете рассчитывать на внятный ответ.
Но со стороны, простите, такое заявление убедительным не выглядит. Каким образом Вы заручились поддержкой этих тысяч пользователей? Вы готовы гарантировать определенный объем продаж?
Вы должны быть готовы ответить на эти и множество других вопросов, которые наверняка зададут Вам специально обученные товарищи из отдела продаж, если в серьез хотите заняться этим делом.
Если Вы пришли смеяться, то боюсь, не по адресу. :)
На вопрос, «почему нет десктопных продуктов под линукс» был дан вполне развернутый ответ. Я понимаю, что он может Вам не нравится, но Ваше недовольство, боюсь, мало что изменит.
Вы можете считать, что компания ABBYY ошибается в позиционировании своего продукта, неправильно оценивает доли рынка и не знает, на чем работают их потенциальные клиенты. Это опять-таки, безусловно, Ваше право.
И Вы даже можете переубедить людей отвечающих за выпуск интересующих вас продуктов, если предоставите достаточно внятные доказательства правоты своей точки зрения, например, в виде тех самых маркетинговых исследований.
Конечно нормальное, а какие могут быть сомнения?
ABBYY продает цельный продукт, и хочет, чтобы его использовали именно так как это задумано, а не раздирали по частям, встраивая результат их работы неизвестно во что.
Продажа контентов словарей и продажа продукта в состав которого входят словари — это две большие разницы. Продажа контента это вообще отдельный рынок, и если у Вас есть реальное взаимовыгодное предложение, то не думаю что Вам откажут.
Нет, не правильно. Как ни крути, аудитория всех линуксов на десктопе меньше процента от общего числа десктопов. А разработка, в общем случае, сильно сложнее, учитывая количество дистрибутивов — это не под три версии винды протестировать.
Так что для в качестве альтернативы для тех кто сидит под *nix есть www.abbyyonline.com
Было бы странно иметь аналогичные ощущения про FRE — рынок серверов, сильно отличается от рынка рабочих станций.
С Lingvo та же история, это не отмазка, это факт — выпускать коммерческие продукты под Linux экономически не выгодно. Математика крайне проста — линухов на десктопе меньше процента, причем те, у кого на десктопе таки стоит линух, как правило не являются целевой аудиторией для Lingvo.
Нет. IoC-контейнер, как правило, является реализацией DI. SL-и тоже есть, но это отдельная песня.
Вся чехарда, на самом деле, из-за того, что четкого определения IoC нету, но традиционно, начиная с Pico-контейнера и Spring-а, под IoC понималось то, что мы сейчас называем DI, всед за фаулером. Поэтому подавляющее большинство IoC контейнеров являются DI контейнерами, то есть, они оборудованы механизмами инжекции зависимости в объект снаружи и их основная задача эту инжекцию обобщить и сделать прозрачной для разработчика.То что мы можем коде сказать Container.Resolve — ничего не меняет.
SL работает по совершенно противоположному принципу, вообще, правильный SL требует реализации некоторых интерфейсов в самих сервисах. Помните ISite, IContainer, в классах поддерживаемых дизайнером VS, и отдельно IServiceProvider? Это вот оно, данная реализация SL называется IServiceProvider, на нем вообще вся Visual Studio построена.
Верно, фаулер не мешает, фаулер вводит свою терминологию, более точно отражающую суть вещей. Что такое IoC точного ответа дать не может никто и внятной формулировки не существует, поэтому фаулер вводит DI, четко описывая что это означает. Поэтому да, в каком-то смысле DI можно считать вариантом IoC или «принципа голливуда».
Не верно. О противоположности DI и SL говорить не только можно, но и нужно. DI инжектит зависимость снаружи, в SL она разруливается изнутри, это принципиальная разница не смотря на то, что DI формально считается «принципом», а SL «паттерном», что тоже предмет для дискуссии.
Смешались в кучу люди, кони… IoC контейнер — это не реализация паттерна ServiceLocator, IoC контейнер — это фреймворк сделаннй для обобщения реализации принципа, сюрприз, IoC (он же DI, по терминологии фаулера). А SL — это совершенно отдельная конструкция, практически прямо противоположная, у того же фаулера все это достаточно подробно, хотя и мутно расписано.
Ну и всплеска ждать не стоит, куда уж больше, сейчас уже только ленивый свой контейнер не написал… =))
И вопросы поддержки и разработки новых фич никто не отменял.
А если кроме шуток, то реальность такова, что в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Иными словами, кампании разработчику выгоднее убедить клиента поставить еще одну машину с windows, чем портировать высокотехнологичный софт на другую платформу — wellcome to real world.
Братцы линухоиды и просто любители писать «правильный кросс-платформенный софт», простите, но похоже, что вы этим просто никогда не занимались.
Посмотрев однажды за разработкой одного такого продукта, для тестирования которого необходимо было иметь порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков, я стал жутко преданным сторонником Microsoft.
Вы просто не представляете, какое счастье, что есть кампания, которая выпускает софт для 95% машин и разрабатывая свою продукцию под ее платформу, можно с чистой совестью забить на полпроцента неудачников!
Ребята, я хочу заниматься разработкой, а не изнурительной синхронизацией между разными платформами, которые сами не очень заботятся о совместимости (к слову, в отличии от той же MS).
Для примера можно посмотреть себистоимость одного процессора интел в начале и в конце жизненного цикла, (перед выходом на рынок и перед прекращением производства). И если, даже при массовом производстве не удалось снизить себистоимость ниже 30 USD, да еще и по тем временам — неудивительно, что его не стали применять.
Для собственного использования, до недавнего времени, у MS был Source Depot, допиленный под их нужды, который являлся веткой Perforce. Сейчас весь MS плааавно переходит на Team Foundation Server, благодаря чему TFS постепенно становится довольно достойным продуктом.
Дискомфорт испытывается не от наличия рангов, так как четко понятен способ свой ранг повысить, а от отношения. Я встречал кампании, где никаких рангов нет, но начальство ест в отдельной столовой, пользуется отдельным входом и имеет массу других привелегий, которые простым смертным никогда не будут доступны — вот это действительно несколько озлобляет. А от рангов, на практике, только польза.
Вы хотите получить от ABBYY контент словарей. Для этого вам надо убедить ABBYY продать Вам эти словари, и я пытаюсь Вам помочь в свершении этого благого дела, рассказывая реальный путь решения проблемы.
И лицензионное соглашение Lingvo здесь совершенно не причем. Нет никакого смысла пытаться убедить компанию ABBYY позволить выдирать словари из готового продукта, вот это ABBYY совсем не нужно.
Но со стороны, простите, такое заявление убедительным не выглядит. Каким образом Вы заручились поддержкой этих тысяч пользователей? Вы готовы гарантировать определенный объем продаж?
Вы должны быть готовы ответить на эти и множество других вопросов, которые наверняка зададут Вам специально обученные товарищи из отдела продаж, если в серьез хотите заняться этим делом.
На вопрос, «почему нет десктопных продуктов под линукс» был дан вполне развернутый ответ. Я понимаю, что он может Вам не нравится, но Ваше недовольство, боюсь, мало что изменит.
Вы можете считать, что компания ABBYY ошибается в позиционировании своего продукта, неправильно оценивает доли рынка и не знает, на чем работают их потенциальные клиенты. Это опять-таки, безусловно, Ваше право.
И Вы даже можете переубедить людей отвечающих за выпуск интересующих вас продуктов, если предоставите достаточно внятные доказательства правоты своей точки зрения, например, в виде тех самых маркетинговых исследований.
ABBYY продает цельный продукт, и хочет, чтобы его использовали именно так как это задумано, а не раздирали по частям, встраивая результат их работы неизвестно во что.
Продажа контентов словарей и продажа продукта в состав которого входят словари — это две большие разницы. Продажа контента это вообще отдельный рынок, и если у Вас есть реальное взаимовыгодное предложение, то не думаю что Вам откажут.
К сожалению, маркетинговые исследования и анализ рынка говорят не в пользу этой привлекательной теории… :)
Так что для в качестве альтернативы для тех кто сидит под *nix есть www.abbyyonline.com
С Lingvo та же история, это не отмазка, это факт — выпускать коммерческие продукты под Linux экономически не выгодно. Математика крайне проста — линухов на десктопе меньше процента, причем те, у кого на десктопе таки стоит линух, как правило не являются целевой аудиторией для Lingvo.
Вся чехарда, на самом деле, из-за того, что четкого определения IoC нету, но традиционно, начиная с Pico-контейнера и Spring-а, под IoC понималось то, что мы сейчас называем DI, всед за фаулером. Поэтому подавляющее большинство IoC контейнеров являются DI контейнерами, то есть, они оборудованы механизмами инжекции зависимости в объект снаружи и их основная задача эту инжекцию обобщить и сделать прозрачной для разработчика.То что мы можем коде сказать Container.Resolve — ничего не меняет.
SL работает по совершенно противоположному принципу, вообще, правильный SL требует реализации некоторых интерфейсов в самих сервисах. Помните ISite, IContainer, в классах поддерживаемых дизайнером VS, и отдельно IServiceProvider? Это вот оно, данная реализация SL называется IServiceProvider, на нем вообще вся Visual Studio построена.
Не верно. О противоположности DI и SL говорить не только можно, но и нужно. DI инжектит зависимость снаружи, в SL она разруливается изнутри, это принципиальная разница не смотря на то, что DI формально считается «принципом», а SL «паттерном», что тоже предмет для дискуссии.
Ну и всплеска ждать не стоит, куда уж больше, сейчас уже только ленивый свой контейнер не написал… =))