• Лови промокод з яким знижка 50 грн - promo50grn

На каком языке писать серверную часть в данном случае? (БФ)

Статус: Offline
Реєстрація: 20.05.2007
Повідом.: 46
На каком языке писать серверную часть в данном случае? (БФ)

Решил удалить вопросы по технической части, чтобы те, кто в первые заходят, не перечитывали несколько страниц зря.

Техническая часть будет выполняться не мной. Спасибо всем, кто сэкономил мне время от моих глупых попыток сделать прототип самому.

Актуальные вопросы здесь.

Вопрос к модератору: тема сменила тематику, может ее переместить в нужный раздел? можно ли ее переименовать? или просто новую создавать?
 
Останнє редагування:
Re:java


Прошу не пинать ногами. Может глупость спрошу.
С Java не знаком совсем. Там их много видов на сайте. Какой мне использовать? (мне уже один человек здесь рекомендовал Nodejs)

И как все это потом в кучу собрать? Не могу найти подобной инфы.

Очень хочется таки осилить все это...
 
Для начала определитесь с архитектурой. Если это однопоточное приложение, которое постоянно должно случать порт и запускать обработку принятых данных в отдельных потоках, то С/Java в самый раз. В Вашем случае, все же лучше С++ - не придется переучиваться. Инфы море - не пойму, по каким запросам Вы увидели пустой гугл.
php - для rest архитектуры. Конечно на нем, как и на перле, питоне и т.д., можно писать CLI приложения и демоны, но это как трахаться стоя в гамаке.
 
Для начала определитесь с архитектурой. Если это однопоточное приложение, которое постоянно должно случать порт и запускать обработку принятых данных в отдельных потоках, то С/Java в самый раз. В Вашем случае, все же лучше С++ - не придется переучиваться. Инфы море - не пойму, по каким запросам Вы увидели пустой гугл.
php - для rest архитектуры. Конечно на нем, как и на перле, питоне и т.д., можно писать CLI приложения и демоны, но это как трахаться стоя в гамаке.

Видимо я ищу не по тем запросам. Я же говорю, это совсем новое для меня.
Я еще с этими многопоточными/однопоточными сижу разбираюсь.

К описанию задачи, приведенному мной в первом посте, могу добавить (думаю, это важно), что скрипт на сервере должен иметь возможность выполняться круглосуточно (при необходимости), без остановки, независимо от обращения клиента(ов) к нему. Своеобразный робот. Он все время в динамике отрабатывает определенный алгоритм с объектами в памяти.

Пользователи через web-сервис могут внедрять / удалять объекты, которые тут же подхватываются сервером в обработку без остановки. При этом должна быть возможность одновременного обращения с серверу и одновременного создания объектов от разных пользователей.

Вот это то, как должно быть. А какими словами это назвать, я не знаю. Многопоточный мне нужен сервер или однопоточный? Совсем зеленый я в этом. Поэтому, наверное и не могу найти книг на эту тему, потому что не знаю что искать.


Может где-то я глупые вещи пишу, но я все же учусь.
Спасибо всем, кто помогает.

На java нашел Collections для множеств.
P.S. Все же не хочется быть ярким представителем темы "научите меня быть девелопером", поэтому пытаюсь учиться :)
 
Для начала определитесь с архитектурой. Если это однопоточное приложение, которое постоянно должно случать порт и запускать обработку принятых данных в отдельных потоках, то С/Java в самый раз. В Вашем случае, все же лучше С++ - не придется переучиваться. Инфы море - не пойму, по каким запросам Вы увидели пустой гугл.
php - для rest архитектуры. Конечно на нем, как и на перле, питоне и т.д., можно писать CLI приложения и демоны, но это как трахаться стоя в гамаке.
Если человек боиться джавы, значит его квалификация в С++ непозволит написать эфективный бэкофис на С++ так что бы он безотказно работал в режиме 24*7.
Более того связать вэбморду и С++ бэкофис не то что бы сложно но по крайней мере геморно.

Так что по теме - таки джава или Сшарп - во первых не стоит бояться мемориликов. во вторых в этом случае вэб сервис будет объеденен с бэкофисом и отпадет проблема в их связывании.
 
Если человек боиться джавы, значит его квалификация в С++ непозволит написать эфективный бэкофис на С++ так что бы он безотказно работал в режиме 24*7.
Более того связать вэбморду и С++ бэкофис не то что бы сложно но по крайней мере геморно.

Так что по теме - таки джава или Сшарп - во первых не стоит бояться мемориликов. во вторых в этом случае вэб сервис будет объеденен с бэкофисом и отпадет проблема в их связывании.

Спасибо, полезу тогда в java копаться.
 
Прошу не пинать ногами. Может глупость спрошу.
С Java не знаком совсем. Там их много видов на сайте. Какой мне использовать?

есть несколько версий. сейчас актуальна 1.6, 1.7.

реализацию JVM от
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
(сейчас уже oracle)
 
есть несколько версий. сейчас актуальна 1.6, 1.7.

реализацию JVM от
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
(сейчас уже oracle)

Спасибо.
Уже скачал и поставил. Роюсь.

Нашел про Сервлеты. Это оно?
 
Боюсь что на десятках миллионов объектов и более явы и шарпы не будут подавать признаков жизни.
 
Боюсь что на десятках миллионов объектов и более явы и шарпы не будут подавать признаков жизни.

Ничего, сейчас ТС покопается, нароет map reduce, освоится с облаками и пойдет архитектором в оракл))
 
Боюсь что на десятках миллионов объектов и более явы и шарпы не будут подавать признаков жизни.

А С++ будет? :D Понятно чот тазик нужен будет помощнее чем для бэка написанного на С++. Однако разница в стоимости тазиков с лихвой окупиться на сэкономленном времени разработки и внедрения.
 
А С++ будет? :D Понятно чот тазик нужен будет помощнее чем для бэка написанного на С++. Однако разница в стоимости тазиков с лихвой окупиться на сэкономленном времени разработки и внедрения.
Возможно и С++ нужно будет помогать ассемблерными вставками, зависит от алгоритмов обработки. По поводу времени внедренни С++, так тут процесс будет проще паренной репы. А тазика помощнее может и в природе не существовать, чтобы сравняться с С++, а городить распределительные системы, так точно не дешевле будет.
А если web-морда простая, то можно и в С++ её реализовать, чтобы не использовать другие инструменты.

Я уже переделывал и шарповые и явовские проги по этой самой причине.
 
Возможно и С++ нужно будет помогать ассемблерными вставками зависит от алгоритмов обработки.
Ога, в 21 веке. И при этом незабыть прочесьт пару сотен томов по оптимизации машинного кода, что бы соптимизировать ассемблерный код лучше, чем мелкосовтовский или интеловский компайлер. Да и при этом память чистить не забывать, ога.

По поводу времени внедренни С++, так тут процесс будет проще паренной репы.
Ну да... А вы знакомы с тонкостями созданий переносимых приложений между различными ОС и разрядностями?
А тазика помощнее может и в природе не существовать, чтобы сравняться с С++, а городить распределительные системы, так точно не дешевле будет.
Та шо вы говорите... А в чем разница в производительности между С и Джавой основная, вы в курсе? Неужели в том, что С код выполянеться нативно, а Жабо код в ужасно тормознутой ЖВМ? :D
А если web-морда простая, то можно и в С++ её реализовать, чтобы не использовать другие инструменты.
Ага :D СЖИ-Бин рулит :D
Я уже переделывал и шарповые и явовские проги по этой самой причине.
:рл:
Может проблема была в радиусе кривизны рук Джава и Шарп девелоперов, а так же интеграторов. Ибо как-то сложно представить себе проект который имеет смысл "переделывать" на С++, с учетом высоких зарплат в этой сфере и малого количества квалифицированных кадров в этой области, и что бы это было дешевле покупки нового железа.
 
Ога, в 21 веке. И при этом незабыть прочесьт пару сотен томов по оптимизации машинного кода, что бы соптимизировать ассемблерный код лучше, чем мелкосовтовский или интеловский компайлер. Да и при этом память чистить не забывать, ога.
Не надо ничего читать, ничего не забывать - специалист всё это уже знает и умеет. Я не говорю о написании глобальных функций на асме, а о некоторых узких местах.

Ну да... А вы знакомы с тонкостями созданий переносимых приложений между различными ОС и разрядностями?
У меня проект есть у которой 90% кода без изменения компилится в 16/32/64 разрядных системах на AVR/Intel/Motorola-процессорах под различными OC. Так что проблема надумана. Но TC это как бы не нужно. Он ничего про это не говорил.


Может проблема была в радиусе кривизны рук Джава и Шарп девелоперов, а так же интеграторов. Ибо как-то сложно представить себе проект который имеет смысл "переделывать" на С++, с учетом высоких зарплат в этой сфере и малого количества квалифицированных кадров в этой области, и что бы это было дешевле покупки нового железа.
Поверьте иногда бывает дешевле.
 
Боюсь что на десятках миллионов объектов и более явы и шарпы не будут подавать признаков жизни.
я тоже так думал пока на с++ писал, на самом деле разницу ощутить нереально, даже ассемблерная вставка не дает выиграть по скорости, миллисекунды на миллионах объектов это несерьезно

если это, конечно, какой-то адронный коллайдер, то там может быть эти миллисекунды играют роль, вы же не ПО для коллайдера переписывали? =)
 
Боюсь что на десятках миллионов объектов и более явы и шарпы не будут подавать признаков жизни.
На 32 bit 1.7 JVM 5,000,000 объектов Point(long x, long y, long z) в структуре HashMap<Long, Point> будут занимать 516 мб. Вроде бы,
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
начинаются с 4 гб.


Нашел про Сервлеты. Это оно?
Протокол
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
можно использовать и без сервлетов, если нужен примитивный обработчик запросов.
 
На 32 bit 1.7 JVM 5,000,000 объектов Point(long x, long y, long z) в структуре HashMap<Long, Point> будут занимать 516 мб. Вроде бы,
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
начинаются с 4 гб.

На 32 бита проблемы точно начнуться с 4гб и не только со сборщиком мусора ;)
 
Назад
Зверху Знизу