Здравствуйте, smeeld, Вы писали:

S>При слабом серверном железе и серьёзной нагрузке, сервис на java не взлетит.
При слабом серверном железе и на бусте не взлетит.

Здравствуйте, Lonely Dog, Вы писали:

C>>Вообще говоря, поддерживают. То есть, им пофиг — получаем каким-нибудь образом Kerberos ticket, а дальше оно само.
LD>Ну так вопрос именно в получении этого тикета. Для этого нужно куда-то отправить данные пользователя.
LD>И собрать их перед этим. А это все-таки зависит от технологии аутентификации.
В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, Cyberax, Вы писали:

C>>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
LD>Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.

я использую Cython на питтонном коде для сокрытия исходников и некоторого ускорения, если последнее важно, то применяя augmenting, можно добиться очень сильного ускорения, в 10-ки раз, при этом, это все еще питон в котором я гоняю палку в PyCharm'е, а в продакшн идет натив. рекомендую.

Добрый день!

Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.
1. С# — все задачи покрываются кроме поддержки Linux. Нет уверенности в том, что Mono достаточно стабилен. С другой стороны, я немнлого знаю .NET, мне будет легче контролировать разработку.
2. C++ — У меня вообще нет опыта кроссплатформенной разработки. Т.е. нет уверенности в том, что будут использоваться правильные библиотеки, подходы и пр. Кроме того, работа с базами данных на C# проще. Да и все остальное делается быстрее.
3. Java — наверное лучший выбор. Вот только я Java вообще не знаю. Никогда ничего не писал. Т.е. на первых порах надо будет ее осваивать. И будет сложно контролировать команду.
4. Python — мы не готовы отдавать исходный код. Возможно, его можно обфусцировать. Но опять же, Питон я почти не знаю. И какие там есть либы, подходы, инструменты не в курсе.

Коллеги, может вы что-нибудь подскажите?

PS: Не знаю, возможно мой подход к выбору технологий вообще не верен? Какая разница, в чем у меня есть опыт? На уровне архитектуры, структуры базы данных и внешнего API, я смогу разобраться с чем угодно. Ну, мне хочется верить в это . Да и в текущей команде есть люди с большим опытом разработки в разных областях. Если что, они помогут. Просто под этот новый сервер мы будем набирать еще народ (3-4 человека). И хочется как-то определиться с тем, кто нам нужен.

Здравствуйте, Lonely Dog, Вы писали:

boost не подойдёт?

S>Смотря что за сервис. Если это пар сотен KB, что-то отдающих обрабатывающих,
S>то на слабом (относительно) железе и нагрузке демон на boost вполне может ужиться.
S>C java серваку нужно будет прокручивать целую JVM или, того хуже, app сервер,
S>что значительно дороже.

А тебе не кажется странным сравнивать сервис "на пару сотен КБ" и апп сервер? Если нужен простой сервис, то никто не будет ставить апп сервер, а если нужен апп сервер, то его нельзя заменить сервисом "на пару сотен КБ"

Здравствуйте, Lonely Dog, Вы писали:

A>>А зачем писать свой сервис? Проще поставить ЛДАП и каждое приложение завязать на него. Куча софта и так уже поддерживают ЛДАП из коробки, так что в нашем случае это было именно доделка своих приложений.
LD>Потому-что LDAP (и куча приложений) не поддерживают отпечатки пальцев, сетчаки глаза, БСК и пр. А мы поддерживаем.
Вообще говоря, поддерживают. То есть, им пофиг — получаем каким-нибудь образом Kerberos ticket, а дальше оно само.

Здравствуйте, Lonely Dog, Вы писали:

LD>Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.

На Python – если нет серьезных требований к скорости работы и вы можете отдать исходники, на Java если требования к скорости довольно высокие и исходники отдавать вы не собираетесь. На C++, если первый и второй вариант не устроили.

Здравствуйте, Lonely Dog, Вы писали:

LD>Коллеги, может вы что-нибудь подскажите?

Кроссплатформ — это однозначно java. От c# в принципе не слишком отличается.

Здравствуйте, a_g_99, Вы писали:


__>Кроссплатформ — это однозначно java. От c# в принципе не слишком отличается.

При слабом серверном железе и серьёзной нагрузке, сервис на java не взлетит.

Здравствуйте, a_g_99, Вы писали:

__>Здравствуйте, smeeld, Вы писали:

S>>При слабом серверном железе и серьёзной нагрузке, сервис на java не взлетит.
__>При слабом серверном железе и на бусте не взлетит.

Смотря что за сервис. Если это пар сотен KB, что-то отдающих обрабатывающих,
то на слабом (относительно) железе и нагрузке демон на boost вполне может ужиться.
C java серваку нужно будет прокручивать целую JVM или, того хуже, app сервер,
что значительно дороже.

Здравствуйте, smeeld, Вы писали:

S>Смотря что за сервис. Если это пар сотен KB, что-то отдающих обрабатывающих,
S>то на слабом (относительно) железе и нагрузке демон на boost вполне может ужиться.
S>C java серваку нужно будет прокручивать целую JVM или, того хуже, app сервер,
S>что значительно дороже.

Если пара сотен кб и планируется слабое железо то С будет пожалуй единственным правильным вариантом. Но если человек планировал использовать python like one of the ways то полагаю сервер должен быть ок. В таком случае java оптимальный вариант.

Здравствуйте, kaa.python, Вы писали:


KP> На Python – если нет серьезных требований к скорости работы и вы можете отдать исходники,
Исходники не отдаем. 100%. Посмотрел, для Python есть обфускаторы. Боюсь правда, что они могут испортить код.

KP> на Java если требования к скорости довольно высокие и исходники отдавать вы не собираетесь.
Особых требований к скорости нет. Нагрузки тоже большой не ожидаем.

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, Lonely Dog, Вы писали:

S>boost не подойдёт?
Я мало с ним работал. regex, shared_ptr. И все.

Здравствуйте, a_g_99, Вы писали:

__>Кроссплатформ — это однозначно java. От c# в принципе не слишком отличается.
Ага, спасибо.

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, a_g_99, Вы писали:


__>>Кроссплатформ — это однозначно java. От c# в принципе не слишком отличается.

S>При слабом серверном железе и серьёзной нагрузке, сервис на java не взлетит.
Серьезной нагрузки не ожидаем. Не более сотни запросов в секунду.

Здравствуйте, a_g_99, Вы писали:

__>Если пара сотен кб и планируется слабое железо то С будет пожалуй единственным правильным вариантом. Но если человек планировал использовать python like one of the ways то полагаю сервер должен быть ок. В таком случае java оптимальный вариант.
Речь 100% не идет о больших нагрузках. Это сервис аутентификации пользователей в компании. Т.е., в 8 утра все юзеры пришли, зашли в сеть, дальше в обед пик нагрузки. Даже если брать большую компанию на 10000 человек. Обычно они приходят с интервалом 15-30 минут. Т.е., 10000 / 15 / 60 = 10 человек в секунду. Понятно, что на каждую попытку входа будет несколько запросов к серверу. Поэтому и беру не больше нескольких сотен.

Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

LD>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

А зачем писать свой сервис? Проще поставить ЛДАП и каждое приложение завязать на него. Куча софта и так уже поддерживают ЛДАП из коробки, так что в нашем случае это было именно доделка своих приложений.

Здравствуйте, avpavlov, Вы писали:

A>А тебе не кажется странным сравнивать сервис "на пару сотен КБ" и апп сервер? Если нужен простой сервис, то никто не будет ставить апп сервер, а если нужен апп сервер, то его нельзя заменить сервисом "на пару сотен КБ"

Демон может выполнять одну две задачки, но для них потребуется функционал J2EE?
Можно будет реализовать как сервлет в app.
Но для одного такого, конечно, жирновато будет.

Здравствуйте, Lonely Dog, Вы писали:

LD>Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.
LD>Коллеги, может вы что-нибудь подскажите?
Попробуй посмотреть на http://pocoproject.org, С++ серверная часть на ней пишется очень легко и просто.

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, avpavlov, Вы писали:

A>>А тебе не кажется странным сравнивать сервис "на пару сотен КБ" и апп сервер? Если нужен простой сервис, то никто не будет ставить апп сервер, а если нужен апп сервер, то его нельзя заменить сервисом "на пару сотен КБ"

S>Демон может выполнять одну две задачки, но для них потребуется функционал J2EE?

Давай пример функционала, для которого нужен app server, но который можно заменить простейшим сервисом

S>Можно будет реализовать как сервлет в app.

Можно много как сделать, только почему ты думаешь, что придётся делать сервлет или использовать апп сервер?

Здравствуйте, avpavlov, Вы писали:


A>Давай пример функционала, для которого нужен app server, но который можно заменить простейшим сервисом

JAAS как раз в контексте решаемой автором задачки.

Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, avpavlov, Вы писали:


A>>Давай пример функционала, для которого нужен app server, но который можно заменить простейшим сервисом

S>JAAS как раз в контексте решаемой автором задачки.

JAAS — часть стандартной Явы, тут не только апп сервер не нужен, тут даже о Java EE рчь не идёт

Здравствуйте, Lonely Dog, Вы писали:

LD>Добрый день!

LD>Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.
LD>1. С# — все задачи покрываются кроме поддержки Linux. Нет уверенности в том, что Mono достаточно стабилен. С другой стороны, я немнлого знаю .NET, мне будет легче контролировать разработку.
LD>2. C++ — У меня вообще нет опыта кроссплатформенной разработки. Т.е. нет уверенности в том, что будут использоваться правильные библиотеки, подходы и пр. Кроме того, работа с базами данных на C# проще. Да и все остальное делается быстрее.
LD>3. Java — наверное лучший выбор. Вот только я Java вообще не знаю. Никогда ничего не писал. Т.е. на первых порах надо будет ее осваивать. И будет сложно контролировать команду.
LD>4. Python — мы не готовы отдавать исходный код. Возможно, его можно обфусцировать. Но опять же, Питон я почти не знаю. И какие там есть либы, подходы, инструменты не в курсе.

LD>Коллеги, может вы что-нибудь подскажите?

Без знания конкретики, с такими условиями(сервер, кроссплатформ, работа с базой) — java. C шарпом и моно правда могут быть проблемы там, где их не ждете. Плюсы можно конечно, но будет дольше и затратнее.
То, что на джаве никогда не писали — это не проблема, так как она простая как пробка, и во многом похожа на шарп.

Здравствуйте, avpavlov, Вы писали:


LD>>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

A>А зачем писать свой сервис? Проще поставить ЛДАП и каждое приложение завязать на него. Куча софта и так уже поддерживают ЛДАП из коробки, так что в нашем случае это было именно доделка своих приложений.

Потому-что LDAP (и куча приложений) не поддерживают отпечатки пальцев, сетчаки глаза, БСК и пр. А мы поддерживаем.

Здравствуйте, Аноним, Вы писали:

LD>>Коллеги, может вы что-нибудь подскажите?
А>Попробуй посмотреть на http://pocoproject.org, С++ серверная часть на ней пишется очень легко и просто.
Спасибо, посмотрю!

Здравствуйте, Lonely Dog, Вы писали:

LD>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

не знаю что там за продукты такой же направленности у оракла, а с Novell NDS я работал оч плотно. и нет, оно не на Java! там все внутренности на С (разумеется). от Java там только средство администрирования (ConsoleOne), и то, местами платформо-зависимое (было). Была еще нелепая попытка сделать ГУЙ на сервере (!) на Java (начиная с NW5)... было жутко!

насчет разных авторизаций: я еще в конце 90стых с помощью Novell NDS логинился голосом -- а ты говоришь "не поддерживается"
кроме голоса было доступно куча другой биометрии (железа для которой я в жизни не видывал).

не знаю как они там щаз поживают (Novell в смысле, несколько у них все полимеры вылетели в унитаз...?), но в свое время это были лучшие программные продукты с, которыми мне доводилось работать!

Здравствуйте, Cyberax, Вы писали:

C>Вообще говоря, поддерживают. То есть, им пофиг — получаем каким-нибудь образом Kerberos ticket, а дальше оно само.
Ну так вопрос именно в получении этого тикета. Для этого нужно куда-то отправить данные пользователя.
И собрать их перед этим. А это все-таки зависит от технологии аутентификации.

Здравствуйте, zaufi, Вы писали:

Z>Здравствуйте, Lonely Dog, Вы писали:

LD>>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

Z>не знаю что там за продукты такой же направленности у оракла, а с Novell NDS я работал оч плотно. и нет, оно не на Java! там все внутренности на С (разумеется). от Java там только средство администрирования (ConsoleOne), и то, местами платформо-зависимое (было). Была еще нелепая попытка сделать ГУЙ на сервере (!) на Java (начиная с NW5)... было жутко!
Например Novell Access Manager.


Z>насчет разных авторизаций: я еще в конце 90стых с помощью Novell NDS логинился голосом -- а ты говоришь "не поддерживается"
Z>кроме голоса было доступно куча другой биометрии (железа для которой я в жизни не видывал).
Ну дело не только в логоне в NDS. А в поддержке кастом-приложений. Аутентификации с мобильных клиентов, поддержке AD FS.

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, Cyberax, Вы писали:

LD>Ну так вопрос именно в получении этого тикета. Для этого нужно куда-то отправить данные пользователя.
LD>И собрать их перед этим. А это все-таки зависит от технологии аутентификации.

Kerberos тут точно не к месту, потому что предпологает выдачу разным сущностям, программам, как-то
называемым, ключей, которые сохраняются на машинах, где эти программы будут исполняться. И
аутентификация между сторонами есть отправка запросов со стороны аутентифицирующихся к серверу
Kerberos, тот высылает обоим сторонам зашифрованные сообщения сообщения, стороны их расшифровывают
и обмениваются результатами, по результатам стороны определют зарегестрирован ли партнер у Kerberos,
если да, то всё OK. И Аутентификацию ставнением битовых массивов, сравнивая те, что генерит
аппаратура и те, что хранятся в базе тут с Kerberos не свяжешь. Вот для хранения этих массивов, данных
о пальзах, глазах, или ещё чего там, можно использовать существующие rdbms.

Здравствуйте, smeeld, Вы писали:


S>Kerberos тут точно не к месту, потому что предпологает выдачу разным сущностям, программам, как-то
S>называемым, ключей, которые сохраняются на машинах, где эти программы будут исполняться. И
S>аутентификация между сторонами есть отправка запросов со стороны аутентифицирующихся к серверу
S>Kerberos, тот высылает обоим сторонам зашифрованные сообщения сообщения, стороны их расшифровывают
S>и обмениваются результатами, по результатам стороны определют зарегестрирован ли партнер у Kerberos,
S>если да, то всё OK. И Аутентификацию ставнением битовых массивов, сравнивая те, что генерит
S>аппаратура и те, что хранятся в базе тут с Kerberos не свяжешь. Вот для хранения этих массивов, данных
S>о пальзах, глазах, или ещё чего там, можно использовать существующие rdbms.

Ага, именно так.

Здравствуйте, Cyberax, Вы писали:

C>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.

Здравствуйте, savitar, Вы писали:


S>я использую Cython на питтонном коде для сокрытия исходников и некоторого ускорения, если последнее важно, то применяя augmenting, можно добиться очень сильного
ускорения, в 10-ки раз, при этом, это все еще питон в котором я гоняю палку в PyCharm'е, а в продакшн идет натив. рекомендую.
Ага, спасибо!

Здравствуйте, smeeld, Вы писали:

S>boost не подойдёт?

и при чем тут буст?

Здравствуйте, Abyx, Вы писали:

S>>boost не подойдёт?

A>и при чем тут буст?

Кроссплатформен, сэр. В смысле по исходникам.
В смысле нужно только перекомпилировать, и не нужно переписывать.

Здравствуйте, Lonely Dog, Вы писали:

C>>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
LD>Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.
Поставляйте только .pyc-файлы, и ещё слегка их обфусцируйте.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Lonely Dog, Вы писали:

C>>>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
LD>>Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.
C>Поставляйте только .pyc-файлы, и ещё слегка их обфусцируйте.

не знаю на счет обфускации, но давать только .pyc думая, что ты не даешь исходники, это очень наивно. это https://github.com/wibiti/uncompyle2 поможет развеять сомнения.

Здравствуйте, Lonely Dog, Вы писали:

LD>...

еще вариант языка: Go (golang)? или это уже слишком...

Здравствуйте, smeeld, Вы писали:

S>>>boost не подойдёт?

A>>и при чем тут буст?

S>Кроссплатформен, сэр. В смысле по исходникам.
S>В смысле нужно только перекомпилировать, и не нужно переписывать.

да, там разве что ASIO с сокетами, а ТСу надо БД, LDAP и еще хз знает что.

Здравствуйте, Abyx, Вы писали:


A>да, там разве что ASIO с сокетами, а ТСу надо БД, LDAP и еще хз знает что.

API клиентских либ у всех СУБД тоже, чаще всего, одинаковое, что для unix-like, что под win.

Здравствуйте, savitar, Вы писали:

S>еще вариант языка: Go (golang)? или это уже слишком...
Нет, тоже вариант. Вопрос в том, насколько легко найти разработчиков на этом языке.

Здравствуйте, Lonely Dog, Вы писали:

LD>Добрый день!

LD>Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.
LD>1. С# — все задачи покрываются кроме поддержки Linux. Нет уверенности в том, что Mono достаточно стабилен. С другой стороны, я немнлого знаю .NET, мне будет легче контролировать разработку.
LD>2. C++ — У меня вообще нет опыта кроссплатформенной разработки. Т.е. нет уверенности в том, что будут использоваться правильные библиотеки, подходы и пр. Кроме того, работа с базами данных на C# проще. Да и все остальное делается быстрее.
LD>3. Java — наверное лучший выбор. Вот только я Java вообще не знаю. Никогда ничего не писал. Т.е. на первых порах надо будет ее осваивать. И будет сложно контролировать команду.
LD>4. Python — мы не готовы отдавать исходный код. Возможно, его можно обфусцировать. Но опять же, Питон я почти не знаю. И какие там есть либы, подходы, инструменты не в курсе.

LD>Коллеги, может вы что-нибудь подскажите?

LD>PS: Не знаю, возможно мой подход к выбору технологий вообще не верен? Какая разница, в чем у меня есть опыт? На уровне архитектуры, структуры базы данных и внешнего API, я смогу разобраться с чем угодно. Ну, мне хочется верить в это . Да и в текущей команде есть люди с большим опытом разработки в разных областях. Если что, они помогут. Просто под этот новый сервер мы будем набирать еще народ (3-4 человека). И хочется как-то определиться с тем, кто нам нужен.

А что ты вообще знаешь? C# нормально не знаешь, С++ не знаешь, Java не знаешь, пайтон не знаешь. Ты — Windows-программист с опытом С++ и небольшим опытом C#? Моё мнение — если задача несложная — пиши на джаве. Её легко выучить до уровня, достаточного для написания небольших приложений. Документации огромное количество. Проблем с кроссплатформенностью — 0. Советую именно её.

Здравствуйте, Lonely Dog, Вы писали:

LD>Добрый день!

LD>Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.
...
LD>Коллеги, может вы что-нибудь подскажите?

Под твои задачи идеально подходит PHP

Здравствуйте, vsb, Вы писали:

vsb>А что ты вообще знаешь? C# нормально не знаешь, С++ не знаешь, Java не знаешь, пайтон не знаешь. Ты — Windows-программист с опытом С++ и небольшим опытом C#?
Я — Windows-программист с 12-летним опытом, с уклоном в системные технологии MS: системные компоненты польззовательского режима (фильтры паролей, GINA, Credential Providers), Active Directory и пр., плюс куча всего другого из моей прикладной области. Плюс сертификаты Brainbench, Microsoft и пр.

Моё мнение — если задача несложная — пиши на джаве. Её легко выучить до уровня, достаточного для написания небольших приложений. Документации огромное количество. Проблем с кроссплатформенностью — 0. Советую именно её.
А писать не я буду. Писать будут другие. Моя роль на на проекте это требования, high-level дизайн и общее управление.

PS: За совет про Java спасибо. Остальное, мимо кассы.

Здравствуйте, Аноним, Вы писали:

А>Под твои задачи идеально подходит PHP
Гм, в эту сторону не думал. Считал, что PHP не подходит для серьезных разработок enterprise-уровня.

Здравствуйте, Lonely Dog, Вы писали:

LD>PS: За совет про Java спасибо. Остальное, мимо кассы.

Контролировать Java проблем не будет, думаю. С точки зрения архитектуры Java и С++ особо не отличаются. У С++ всякие мелкие особенности вроде контроля за владением объекта и тд, которые в Java не особенно актуальны, но в целом классы там и там одни и те же, интерфейсы там и там одни и те же, принципы построения архитектуры одни и те же, паттерны одни и те же. Код на Java С++ник может читать и оценивать на адекватность без какой-либо подготовки (кроме пары тонких моментов, которые по ходу дела быстро разбираются).

Основные моменты — правильный выбор фреймворков и больших библиотек. Ну тут можно ориентироваться на популярность и четко смотреть, для каких задач они предназначены и какие у них есть ограничения.

Здравствуйте, vsb, Вы писали:


vsb>Контролировать Java проблем не будет, думаю. С точки зрения архитектуры Java и С++ особо не отличаются. У С++ всякие мелкие особенности вроде контроля за владением объекта и тд, которые в Java не особенно актуальны, но в целом классы там и там одни и те же, интерфейсы там и там одни и те же, принципы построения архитектуры одни и те же, паттерны одни и те же. Код на Java С++ник может читать и оценивать на адекватность без какой-либо подготовки (кроме пары тонких моментов, которые по ходу дела быстро разбираются).
vsb>Основные моменты — правильный выбор фреймворков и больших библиотек. Ну тут можно ориентироваться на популярность и четко смотреть, для каких задач они предназначены и какие у них есть ограничения.

Вот именно. Смущает именно большой набор библиотек для Java. В которых я пока не ориентируюсь. Но пока планирую купить книжку по языку. А дальше видно будет.
Понимаю, что Java (и C#) похожи на C++. Но ведь везде есть свои нюасны и шишки, которые набиваются только с опытом.

В общем, решение уже практически принято. Сервер будем писать на Java. Админскую часть возм. тоже.

Всем спасибо за ответы и помощь.

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, Аноним, Вы писали:

А>>Под твои задачи идеально подходит PHP
LD>Гм, в эту сторону не думал. Считал, что PHP не подходит для серьезных разработок enterprise-уровня.

Ну если enterprise то java

Здравствуйте, Lonely Dog, Вы писали:

LD>Коллеги, может вы что-нибудь подскажите?

Всё зависит от состава будущей команды.

Если есть возможность найти высококлассных профессионалов в C++, то это будет самый эффективный вариант. В этом случае могу посоветоваться использовать для доступа к БД библиотечку SOCI, ну и Boost просто по всяким мелочам. С доступом к нативному коду тут вопросов естественно нет. Но этот вариант подходит только при наличие подобных профессионалов, а в случае каких-нибудь там студентов в роли исполнителей, это будет худшим вариантом.

Если же для разработки подразумевается использовать слабых специалистов, то оптимальнее всего будет Java. С библиотеками для БД и т.п. тут вообще вопросов нет и наверное самой нетривиальной частью будет взаимодействие с нативным кодом (JNI).

P.S. Я там понимаю, что проект всё же не из пары строк, иначе как раз небольшой Python скрипт был бы оптимальным. )))

Здравствуйте, savitar, Вы писали:

S>не знаю на счет обфускации, но давать только .pyc думая, что ты не даешь исходники, это очень наивно. это https://github.com/wibiti/uncompyle2 поможет развеять сомнения.

Java или C# в этом плане ничуть не лучше.

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, Аноним, Вы писали:

А>>Под твои задачи идеально подходит PHP
LD>Гм, в эту сторону не думал. Считал, что PHP не подходит для серьезных разработок enterprise-уровня.
Да с PHP очень трудно поддерживать порядок в окромном количестве кода.

Тут все советуют C++ — не ведитесь это дорого и не эффективно. Не в плане производительности а в плане управления большим проектом.
Лучше уж посмотрите Erlang будет дешевле и надёжнее. На практике кода получается в 10раз меньше чем тоже самое на C++ и работает стабильнее (меньше багов).

Но самые жуткие монстры делаются всё таки на java там такой over engineering как раз для enterprise.
Да и если сравнить ресурсы то на java бюджет будет в десятки раз больше. Для освоения денег самый лучший кандидат.

Здравствуйте, alex_public, Вы писали:


_>Если есть возможность найти высококлассных профессионалов в C++, то это будет самый эффективный вариант. В этом случае могу посоветоваться использовать для доступа к БД библиотечку SOCI, ну и Boost просто по всяким мелочам. С доступом к нативному коду тут вопросов естественно нет. Но этот вариант подходит только при наличие подобных профессионалов, а в случае каких-нибудь там студентов в роли исполнителей, это будет худшим вариантом.

_>Если же для разработки подразумевается использовать слабых специалистов, то оптимальнее всего будет Java. С библиотеками для БД и т.п. тут вообще вопросов нет и наверное самой нетривиальной частью будет взаимодействие с нативным кодом (JNI).

_>P.S. Я там понимаю, что проект всё же не из пары строк, иначе как раз небольшой Python скрипт был бы оптимальным. )))
Да, проект довольно большой. Текущая версия занимает несколько сотен тысяч строк кода. На C++/C#/Java/Obj-C.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Lonely Dog, Вы писали:

LD>>Коллеги, может вы что-нибудь подскажите?

_>Всё зависит от состава будущей команды.

_>Если есть возможность найти высококлассных профессионалов в C++, то это будет самый эффективный вариант. В этом случае могу посоветоваться использовать для доступа к БД библиотечку SOCI, ну и Boost просто по всяким мелочам. С доступом к нативному коду тут вопросов естественно нет. Но этот вариант подходит только при наличие подобных профессионалов, а в случае каких-нибудь там студентов в роли исполнителей, это будет худшим вариантом.

_>Если же для разработки подразумевается использовать слабых специалистов, то оптимальнее всего будет Java. С библиотеками для БД и т.п. тут вообще вопросов нет и наверное самой нетривиальной частью будет взаимодействие с нативным кодом (JNI).
Да со командой все ок. Людей с опытом меньше 5 лет нет. У многих больше 10 (именно C++).

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Lonely Dog, Вы писали:

А>Тут все советуют C++ — не ведитесь это дорого и не эффективно. Не в плане производительности а в плане управления большим проектом.
А>Лучше уж посмотрите Erlang будет дешевле и надёжнее. На практике кода получается в 10раз меньше чем тоже самое на C++ и работает стабильнее (меньше багов).
Это уж совсем экзотика. Людей найти наверное тяжело будет.

А>Но самые жуткие монстры делаются всё таки на java там такой over engineering как раз для enterprise.
А>Да и если сравнить ресурсы то на java бюджет будет в десятки раз больше. Для освоения денег самый лучший кандидат.
Задачи освоения денег нет
Это новая версия коробочного продукта, который мы успешно продаем. Т.ч. делаем за свои деньги