Это не факт, это ваше предположение. Вы запросто можете ошибиться в этом предположении. Вообще речь шла о другом — о том, чтобы не переносить весь код прямо сейчас. Может быть, через какое-то время станет ясно, что код должен быть (N+P)-1 разрядным — вот туда реально и нужно будет переносить, а пока решение с эмуляцией всех устраивает. Мы не тратим время на перенос сейчас, вместо этого тратим его на что-то реально полезное. Fire and Motion ведь как раз об этом.
Вы рискуете сломать палец об небо, в которое постоянно попадаете. Recognition Server — набор отдельных процессов. Код технологических библиотек (распознаватель и все, что рядом) никогда не оказывается в одном процессе с программой клиента даже на 32-битной машине.
Да, вы правы — парк машин с 64-битной Windows растет. Но 32-битные программы на них отлично работают. Какой смысл переносить код на 64 бита, если он нормально работает в режиме эмуляции?
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Вот тут вы попали пальцем в небо точнее некуда. Recognition Server — набор отдельно работающих процессов, клиенты никогда ни с одним из этих процессов не общаются программно напрямую (только через компонент интеграции). Какая им разница, какая разрядность у тех процессов?
>порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
Вот это как раз очень соответствует действительности. Реальных платежеспособных клиентов волнует:
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
Представьте себе сколько существует разных операционных систем (в смысле настолько разных, что под каждую нужно делать отдельный дистрибутив).
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Те 100500 библиотек обычно приходится пересобирать под конкретную систему. Это не очень удобно, учитывая, что наши продукты не open source и следовательно пересобирать их придется нам.
Код можно перекомпилировать под 64 бита, но он запросто может перестать работать, потому что написание кода без привязки к разрядности требует еще лучшего знания языка и еще большей дисциплины, чем написание просто (не так и просто) хорошего (поддерживаемого, понятного, надежного и эффективно работающего) кода, который компилируется только на 32 бита. Вот примеры.
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Даже интересно. Вдруг мы правда заняты не тем… Есть ссылка на описание того, как конкретно написать библиотеку, чтобы можно было использовать ее из-под всего и везде?
POSIX… Это стандарт интерфейса операционной системы?
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.
«По-хорошему» звучит прочто отлично. Но что за этим стоит? Ощущение, что использована «правильная, достойная технология»? Хорошо, но бессмысленно. Никого не волнует, что там внутри, пока оно нормально работает. Переписывать на очередную «правильную и достойную» можно так долго, что к окончанию процесса она уже окажется «старой и немодной» и надо будет переписывать дальше.
Очень интересно. У меня есть скажем те же два миллиона строк кода на С++. Мне нужно сделать из них библиотеку, которую можно будет использовать из программы на любом языке на любой платформе. Как сделать это правильно?
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Вопросы на собеседованиях очень простые. Отличить человека, который может писать хороший код на С++, можно без выяснения тонкостей написания кода без привязки к разрядности. В конце концов, описание наиболее типичных проблем можно найти Гуглом за 10 минут.
Семинары есть, на них происходит обмен опытом по разным специфическим проблемам. Например, опытом разработки распределенных программ.
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.