Pull to refresh
0
0

User

Send message
Интересен ваш опыт использования AWS. С какими сложностями столкнулись, что пошло не так как вы ожидали? Если не секрет, сколько стоит использование AWS в вашем случае?
70К+ для senior developer это вполне хорошие деньги для Мюнхена. Проводя собеседования я сталкивался с тем что немцы с серьезной квалификацией были согласны и на меньшую сумму.
Если в eclipse мире, то www.eclipse.org/Xtext/
На практике, программные платформы, основынные на принципах интерпретации метамодели явлются тяжеловесными и страдают проблемами с производительностью. Исходя из опыта поддержки и расширения подобной системы могу утверждать что затраты на разработку весьма высоки, так как большенство технологий (имел опыт в основном с JEE) не применимы в данном контексте, так как они требуют наличия жестко заданной модели предметной области чаще всего в виде POJO. Как результат JPA, EJB, JAX-RS, JAX-WS, JAXB и т.п. — слабые помошники. Но зато сколько радости при проектированнии таких систем :)
Гляньте на www.channeladvisor.com/. Так взаимодействуют поставщики с крупными интернет магазинами типа амазона
Зарплта разработчика в Германии колеблется от 40000 (выпускник) до 75000 (опытный архитектор) в год. Распределение скошенно влево. То есть попадаются зарплаты и выше, но редко. Средняя зарплата в районе 57000. Таким образом от 20 до 39, средняя 29. Вот тут можно посмотреть цифры за 2011 (немецкий). От этого нужно еще вычесть 43% налогов (максимальный налог для здорового, неженатого, бездетного, белого).

Фрилансер, в отличии от разработчика на постоянном окладе, может получать и больше. Но! Налоги выше, обязательная медстраховка выплачивается самим фрилансером (500 — 600 в месяц). Отпускные не оплачиваются. Нет гарантий что занятность на 100% ( можно сидеть месяц без работы). В результате доход за год сравним с доходом на окладе. Фрилансом имеет смысл заниматься в виде подработки или обладая специальными и узкоспециализированными знаниями (типа SAP консультанта).
Основываясь на практическом опыте, могу сказать, что стоит весьма трепетно отнестись к производительности самого пула.

dbcp отличается низкой производительностью. В случае большого количества параллельных обращений к пулу он становится существенным затыком во всей системе. Проблема заключается в неэффективной реализации контейнера объектов (собственно говоря commons-pool), которая использует java synchronized.

Есть несколько альтернатив dbcp: c3p0, proxol, nanopool, miniconanectionpool, Oracle jdbc connection pool и др. После сравнительных тестов производительности мы выбрали Tomcat JDBC Connection Pool. Он использует java concurrent collections, прост в использовании и расширении, а конфигурация совместима c dbcp. Пропускная способность нашего приложения после этой замены варосла приблизительно на 30%.
Открытые технологии не с неба падают. Их разрабатывают сообщества, в многом состоящие из крупных компаний. И эти компании тратят не малые деньги на разработку тех самых «дешевых» технологий.
С ходу заработал с Motorola HT820 (далеко не самые новые bluetooth наушники).
Посмотрите на Japex japex.dev.java.net и на junitbench code.google.com/p/junitbench/
Japex так же позволяет сравнивать выгоду от использования нескольких ядер
Попробуйте избавиться от synchronized блока. Он может искажать картину.
Есть еще wmpodder. Работает как плагин для Windows Media Player. Умеет использовать движок синхронизации от WM, соответственно синхронизирует с любым mp3 плеером, в частности через MTP. Использует IE7 для управления подпиской на подкасты. ПРоект похоже в разработке, но я пробывал - работает. wmpodder.com
боюсь все же в web приложениях объекты наоборот проще, чем ERP приложениях.
Подобные системы уже существуют и используются в Европе. Сложность и стоимость их весьма высока. Не думаю что все врачи и больницы, например в Германии, станут активно пользоваться сервисом гугла. Что бы все врачи начали это использовать, необходимо решение на уровне минздрава и согласования со страховыми. Иначе информация о пациенте будет фрагментирована и мало полезна.
Интересная статья. Но необходимо так же учитывать как растет нагрузка на серевер.
При увеличении количества соединений от каждого пользователя увеличивается и средняя частота запросов. Таким образом, при одинаковом количестве одновременных пользователей нагрузка на серевер в случае 4 одновременных клиентских соединений выше, чем в случае двух. Соответственно среднее время ответа выше и максимальная пропускная способность достигается при меньшем количестве одновременных пользователей. Из этого следует проблема масштабируемости.
Хотя, при использовании нескольких серверов для статического контента, этот метод должен принести хорошие результаты.
На второй диаграмме отсутствует шкала времени.

Information

Rating
Does not participate
Registered
Activity