Забавные у вас цифры. Я вот живу в Иркутске, что 5000 км от Москвы. У нас средняя зарплата программистов 35 тысяч рублей, и найти не могут! Кстати, по региону средняя зарплата обычных людей всего 25 тысяч. Когда я уходил с прошлого места работы (программист в медицинском учреждении), мне предлагали 60 тысяч на руки! И это кстати не предел для прожигателей жизни на внутреннем рынке, можно увеличить еще на 30-50 процентов :)
Так что незачет по цифрам вам :) Хотя фриланс это порой круто, мой друг получает 5600$ (170 тысяч рублей) в месяц, плюс премии всякие. Но он нашел компанию, большинство фрилансеров живут на 2-3 тысячах долларов (60-90 тысяч рублей) в месяц.
«Сколько позволит выиграть ваше решение в процентах от бюджета на поддержку медицины?» — по мне так это правильно, проводить полный анализ ситуации. Но глубоко внутри я за создание рабочих мест и покупки принтеров долгосрочной эксплуатации.
«Перфекционизм сам по себе вредная штука» — это мой взгляд на мир, и я его никогда не скрывал. И меня за это никто не уволил. Даже работая в ИДЦ.
p/s
В том бложике у меня цель пнуть айтишников и задуматься о жизни. Возможно стоит написать о вашей ситуации. Но я не могу быть полностью на вашей стороне.
И еще мысль вдогонку. Если взять не одноразовые принтеры, то появятся затраты на обслуживании. Возможно даже первое время это будет соизмеримо с одноразовыми устройствами. Но зато появится дополнительные рабочие места и налоговые отчисления в регион. Хотя оно надо? Людьми управлять это всегда дополнительные затраты и головная боль. А люди в иркутском руководстве привыкли жить одним днем, до перевода в Москву.
Вы молодец. Хотя не один вы боретесь с системой в Иркутске. В Иркутском областном клиническом-консультативно-диагностическом центре активно используют kyocera. Можете с ними связаться и они поделятся головной болью, хотя скорее всего вы и так знакомы. И кстати они посчитали что kyocera выгоднее чем hp.
Но стоит отметить, что геморроя с этим не меньше. Мало просто купить технику, надо еще покупать правильные расходные материалы (с неправильными гарантия идет лесом). Хотя вы наверное и тут в курсе, что на аукционах постоянно пытаются протолкнуть китайское гавно по цене близкой к оригинальным запчастям и картриджам. По всей стране судятся люди, но многие просто опускают руки и соглашаются на гавно. Ибо судится долго, дорого и муторно.
Вот и получается что порой проще покупать одноразовые принтеры, чем огребать на перфекционизме и чувстве справедливости. А свои силы направить в более важном/интересном направлении. Хотя вы молодец.
Есть еще одна причина опозданий: чтобы получить заказ продавец с руководителем занизили сроки на реализацию. И благодаря этому получили деньги и бонусы для себя. И тут особо ничего не сделаешь.
1. Кстати, а у вас есть данные сколько времени в среднем отрабатывает запрос на получение данных из хранилища? И среднее время обработки запроса при попадании в кэш? Просто мне довольно интересна тема оптимального выбора количества потоков. Может быть вы посоветуете почитать что-нибудь на эту тему?
2. Возможно для оптимизации можно реализовать свою стратегию ReadWriteLock с группировкой писателей в кэш (с некоторым таймаутом для писателей в кэш). Например при накоплении 5-10 писателей запрещать write и отрабатывать пакетную запись в кэш. При этом можно сэкономить на числе перестановок (переупорядочивания) в для ключей.
4. Согласен, вам не особо требуются дополнительные плюшки внешних хранилищ. К примеру, в очень крайнем случае вы кэш пересоберете заново. Распределенность кэширования скорее всего ухудшит производительность.
Итак много букв:
1. Вы так активно бросились оптимизировать под процессор, что стало интересно: как ваши оптимизации сочетаются с тем что у вас всего 16 железных обработчиков потоков (без HT 8 штук)? Просто вы упомянули что у вас 100 потоков, и любопытно понять как они вмещаются в 16 исполнителей? Переключения вас не страшат или много потоков в ожидании висят?
2. Можно предположить что есть четыре базовых стратегии для ReadWriteLock: справедливая (по времени прихода) без разделения на read/write, приоритет на read, приоритет на write, случайная. Судя по вашим заявлениям у вас обычная справедливая стратегия. Почему так? Вы проверяли другие варианты? Может быть приоритет на read повысит производительность?
3. Судя по всему у вас у каждой картинки есть уникальный числовой key. Вы его генератором фигачите? Просто меня смутила немного функция определения сегмента. Она или слишком простая, или вы для упрощения не стали приводить полную функцию. К примеру можно придти к выводу что возможно у вас перекос по нагрузке на сегменты, а часть сегментов занимает память и не используется (не исключаю что на ваших объемах таких проблем нет, но вдруг). У вас накапливается статистика по оптимальности функции определения сегмента по ключу?
4. Еще был вопрос почему вы не используете inmemory базы данных? Было бы довольно любопытно сравнение их с вашим решением. Например почему бы не взять какое нибудь nosql решение? Также из-за предвзятости разработчиков решения, я бы доверил настройку других решений для сравнения, другим людям (которые специалисты в них). Надеюсь вы поступили именно так, а то так эти цифры только для улучшения самолюбия ваших инженеров.
А тут тоже выпили редактор в wiki синтаксисе? Они вроде во всех своих продуктах такое надругательств творят. В итоге народе остается на старье, либо валит где есть вики.
gwt штука хорошая, главное вовремя сказать нет, когда заказчик захочет превратить интернет приложение в интернет. Подтачивать gwt под браузеры это маленький ад, особенно при использовании сторонних компонентов.
Java идеальный язык для разработки бизнес приложений, есть библиотеки всякие, есть программисты доступные по цене. Кривая обучения довольно неплоха, но даже при этом есть проблемы с очень большим выбором библиотек и подходов. По моему мнению надо улучшать то что есть, а не громоздить новые фичи-костыли. Чем проще апи, и чем меньше путей сделать одну и ту же штуку, тем проще (лучше, удобнее, логичнее).
Писал я на java в функциональном стиле, lambdaj и подобное ему пользовал. Фигня это все, у начинающих программистов мозг плавиться (а опытные коллеги по голове бьют). Да и для нетвиальных штук приходится так извращаться, что плакать хочется (эмо наше все).
Кстати, многопоточность это конечно хорошо, но надо ее явно использовать. Иначе индусы студенты напишут такую лапшу, что все подавяться только. Проще надо быть, проще!
А вот если мне будет нужна такая красивая и проста многопотоность, да еще и функциональный стиль писания с лямбдами всякими, то я лучше язык другой выберу. Выбирать язык и инструменты под задачу это нормально, и нефиг городить кровавых монстров энетерпрайза.
Ну и конечно ООП наше все, ведь красивый код это красиво. Программисты это любят, написал говнокод, а потом его рефакторишь, хотя иногда надо просто выкинуть все и сызнова написать. Средства не всегда оправдывают цель. Вы меня конечно извините, но говно все эти (именно это) изменения, маркетинг сплошной.
«Suum cuique»@кто-то-умный, а вообще javascript довольно удобен для скриптования, мы вот например в одном приложении всю клиентскую бизнес логику в него вынесли (возможно и серверная тоже частично там будет).
Любопытный велосипед, хотя описано все довольно сумбурно. Сам писал похожее несколько раз, последний раз пользовал Janino (интерпретация) + JMX (транспорт) + jconsole (клиент). Но опять же Janino это типизированная Java, и даже не очень 1.6.
Кстати, а насчет rhino (javascrip) вы не задумывались. По умолчанию в дефолтной java даже есть какой то не очень свежий интерпретатор. Да и javacript немного похож на Java Ж)
Нет очень важного пункта: компания занимается деятельностью которая противоречит моим убеждения. Например, спам рассылает, или делает средство контроля деятельности сотрудников, ну или еще какую гадость. Я вот по причине делания софта для контроля других людей ушел из прошлой конторы. В деньгах конечно выиграл, но то не главное. Идеалист я, да.
Так что незачет по цифрам вам :) Хотя фриланс это порой круто, мой друг получает 5600$ (170 тысяч рублей) в месяц, плюс премии всякие. Но он нашел компанию, большинство фрилансеров живут на 2-3 тысячах долларов (60-90 тысяч рублей) в месяц.
«Перфекционизм сам по себе вредная штука» — это мой взгляд на мир, и я его никогда не скрывал.
И меня за это никто не уволил.Даже работая в ИДЦ.p/s
В том бложике у меня цель пнуть айтишников и задуматься о жизни. Возможно стоит написать о вашей ситуации. Но я не могу быть полностью на вашей стороне.
Вот давайте на примере принтеров. Сколько позволит выиграть ваше решение в процентах от бюджета на поддержку медицины?
p/s
Эти рассуждения верны, только если там нет откатов конечно. в случае откатов они неправы конечно. Но тут надо писать в прокуратуру.
Но стоит отметить, что геморроя с этим не меньше. Мало просто купить технику, надо еще покупать правильные расходные материалы (с неправильными гарантия идет лесом). Хотя вы наверное и тут в курсе, что на аукционах постоянно пытаются протолкнуть китайское гавно по цене близкой к оригинальным запчастям и картриджам. По всей стране судятся люди, но многие просто опускают руки и соглашаются на гавно. Ибо судится долго, дорого и муторно.
Вот и получается что порой проще покупать одноразовые принтеры, чем огребать на перфекционизме и чувстве справедливости. А свои силы направить в более важном/интересном направлении. Хотя вы молодец.
2. Возможно для оптимизации можно реализовать свою стратегию ReadWriteLock с группировкой писателей в кэш (с некоторым таймаутом для писателей в кэш). Например при накоплении 5-10 писателей запрещать write и отрабатывать пакетную запись в кэш. При этом можно сэкономить на числе перестановок (переупорядочивания) в для ключей.
4. Согласен, вам не особо требуются дополнительные плюшки внешних хранилищ. К примеру, в очень крайнем случае вы кэш пересоберете заново. Распределенность кэширования скорее всего ухудшит производительность.
1. Вы так активно бросились оптимизировать под процессор, что стало интересно: как ваши оптимизации сочетаются с тем что у вас всего 16 железных обработчиков потоков (без HT 8 штук)? Просто вы упомянули что у вас 100 потоков, и любопытно понять как они вмещаются в 16 исполнителей? Переключения вас не страшат или много потоков в ожидании висят?
2. Можно предположить что есть четыре базовых стратегии для ReadWriteLock: справедливая (по времени прихода) без разделения на read/write, приоритет на read, приоритет на write, случайная. Судя по вашим заявлениям у вас обычная справедливая стратегия. Почему так? Вы проверяли другие варианты? Может быть приоритет на read повысит производительность?
3. Судя по всему у вас у каждой картинки есть уникальный числовой key. Вы его генератором фигачите? Просто меня смутила немного функция определения сегмента. Она или слишком простая, или вы для упрощения не стали приводить полную функцию. К примеру можно придти к выводу что возможно у вас перекос по нагрузке на сегменты, а часть сегментов занимает память и не используется (не исключаю что на ваших объемах таких проблем нет, но вдруг). У вас накапливается статистика по оптимальности функции определения сегмента по ключу?
4. Еще был вопрос почему вы не используете inmemory базы данных? Было бы довольно любопытно сравнение их с вашим решением. Например почему бы не взять какое нибудь nosql решение? Также из-за предвзятости разработчиков решения, я бы доверил настройку других решений для сравнения, другим людям (которые специалисты в них). Надеюсь вы поступили именно так, а то так эти цифры только для улучшения самолюбия ваших инженеров.
В целом спасибо за обзор. Было любопытно читать.
Писал я на java в функциональном стиле, lambdaj и подобное ему пользовал. Фигня это все, у начинающих программистов мозг плавиться (а опытные коллеги по голове бьют). Да и для нетвиальных штук приходится так извращаться, что плакать хочется (эмо наше все).
Кстати, многопоточность это конечно хорошо, но надо ее явно использовать. Иначе индусы студенты напишут такую лапшу, что все подавяться только. Проще надо быть, проще!
А вот если мне будет нужна такая красивая и проста многопотоность, да еще и функциональный стиль писания с лямбдами всякими, то я лучше язык другой выберу. Выбирать язык и инструменты под задачу это нормально, и нефиг городить кровавых монстров энетерпрайза.
Ну и конечно ООП наше все, ведь красивый код это красиво. Программисты это любят, написал говнокод, а потом его рефакторишь, хотя иногда надо просто выкинуть все и сызнова написать. Средства не всегда оправдывают цель. Вы меня конечно извините, но говно все эти (именно это) изменения, маркетинг сплошной.
Кстати, а насчет rhino (javascrip) вы не задумывались. По умолчанию в дефолтной java даже есть какой то не очень свежий интерпретатор. Да и javacript немного похож на Java Ж)