Разработчик ПО

Согласен. Но тогда это уже совсем другая история. - Т.к. сервер, сдаваемый в аренду предприятию - это несколько иная схема продаж. Ну бэкэнд можно и на .net написать, но как бы джава более переносима. В любом случае, фронт-энд - это в большинстве случаев пресловутый джаваскрипт. ИМХО, в данном случае он (фронт-энд) составляет порядка 70% задачи. Хотя еще есть варианты написать чудо на флеше+экшнскрипт - язык по сути ощутимой похожий на си# и джаву. - Но как бы для командной работы это слегка сложнее. Хотя и это больше на вкус и цвет.

Была пару лет назад подобная идея. Как бы и опыт есть в плане создания SAAS-систем (на буржуйнет, правда), и опыт в создании оконного софта (пусть и не столь распространенного, но зато работающего http://forum-okna.ru/index.php?showtopic=20168 ), но... сразу задумался над концептуальным набором проблем: 1. безопасность данных - как ни крути, для большинства клиентов намного спокойнее спать, когда все данные у них на хорошо охраняемом сервере в их собственном помещении, к котрому хотя бы формально доступа никто иметь не может. - Т.е. тут собственно концептуальная проблема: дедик все равно используется многими юзерами, и мало кто надеется на реальную защищенность хранения данных. Ибо даже у того же гугла бывают проколы со сливом конфиденциальной инфы - куда там третьим разработчикам. И SSL и прочие технологии защиты от перехвата ничего особо не меняют. 2. собственно тема расчета не нова - есть несколько бесплатных или условно-бесплатных не-SAAS-конкурентов, урвать кусок рынка у которых очень и очень сложно. Т.е. основное преимущество саас - дешевый старт - здесь не работает. 3. ответственность за хранение данных, его конфиденциальность, потенциальные проблемы с отличиями в технологических зазоров в разных версиях и/или при разных настройках оборудования и пр. Т.е., взвесив хотя бы эти факторы, убивать несколько месяцев на разработку ПО для такого сервиса, мне показалось просто не рентабельно, даже с учетом того, что есть ощутимые наработки в виде оффлайн ПО для расчета и других саас-приложений. PS: Хотя, если бы сейчас нужно было с нуля написать оконный софт, с 99% вероятностью писал бы в виде AJAX+DHTML-приложения с j2ee-бэкэндом.

В принципе, проста. Но это скорее дело привычки. Если создается что-то из стандартного набора или на его основе (пару импостов добавить, например), то это вообще моментально. Если что-то менее тривиальное, то первый раз может быть относительно сложно, т.к. нужно понять, что и как делится + как выравниваются проемы, а после обычно вопросов и затруднений не возникает. Почему же. Все возможно. Можно хоть 10-ть разных систем профилей внести (ровно, как и систем фурнитуры).

Полностью бесплатная программа для расчета металло-пластиковых окон, дверей и фасадов из ПВХ. Позволяет подготовить все необходимые типы производственных распечаток, коммерческое предложение, складские ведомости. Есть встроенный количественный склад (работает по принципу средних цен для подсчета себестоимости). Поддерживает неораниченное количество систем профилей и фурнитуры створок. Есть автоматический пересчет из одной системы профилей в другую. В дистрибутиве системы профилей Aluplast 2000 и Veratec + фурнитура Maco. Можно по аналогии ввести неограниченное количество систем профилей. При желании за небольшую плату можно сделать сетевую версию программы. Стандартная поставка позволяет помимо ручного ввода использовать инструмент для быстрого создания часто используемых конструкций (более 30). Более подробная информация и примеры выходной документации на сайте программы Адрес сайта в профиле или в гугле. Хотелось бы услышать отзывы и критику по существу. PS/2: поддерживаются только конструкции прямоугольной формы, т.е. косых импостов, арок и иже с ними не было и нет, ибо изначально такие вещи предпочитали считать исключительно вручную.