Да не считает клиент часовые ставки, месячные доходы и все остальное. 10$ это мало, 300$ это много. 10$ за минуту это все еще мало, а 300$ пускай и за месяц — все равно много. Не знают они сколько там времени уходит и все остальное. С небольшими суммами человек может не заморачиваться, а когда суммы растут — начинает жадничать. Не ассоциирует он 10$ в минуту с «дорого». Просто меньше платить может быть как-то не удобно.
>>если клиенту дорого, следовательно и в дальнейшем вытянуть его на нормальный уровень не получиться.
Не согласен. Во первых клиенты меняются, у них меняются условия, накапливается опыт.
А еще есть бывает, что человек без проблем платит полтинник за работу на пол часа, но не готов заплатить 500$ единоразово. У меня был такой клиент — у него было много достаточно мелких правок, за каждую из которых он без проблем платил. По кругу выходило ого-го сколько.
По поводу общения с заказчиком я бы еще рекомендовал проговаривать после каждого этапа все что было оговорено, чтобы закрепить собственно правильно ли все было понятно. Полезно.
Показывать работу в процессе — довольно спорный момент, не все понимают, что это не окончательный результат, некоторые расстраиваются так как считают, что качество низкое и так далее. Спорно весьма. Бывает не просто убедить заказчика, что его опасения напрасны и это не конечный результат.
Перепад температур мало говорит о энергии. Я не слишком хорошо знаю теплоемкость лунных пород — сложно оценить сколько же там энергии рассеивается. Да и днем надо будет опять же отражать довольно много энергии.
Согласен. Надо считать конечно что там как. Теплоемкость то огромного вала земли выходит все равно весьма приличная, и теплопроводность не нулевая. Так что там будет некая температура на которой стабилизируется теплоотвод. Тепло будет уходить «наружу». Смысл в том, что нет этих колебаний как на поверхности. +-20 градусов уже надо ловить, уже выходит пара систем.
Под водой еще более высокая влажность. Но это мало кого останавливает при эксплуатации плавсредств.
Совсем не обязательно просто брать воздух и гнать его на сервера. Замкнутый контур с осушенным азотом и он уже охлаждается землей.
А еще можно зарывать датацентры под землю :). Там и температура стабильная и от внешних воздействий защита хорошая. Можно еще откачать воздух и тогда не страшен пожар :).
Это конечно шутки, но подземный (или подводный, в море?) контур вполне мог бы помочь в борьбе с теплом где угодно. А может даже и применяют подобные системы.
Вообще территорий с похожим климатом довольно много. Где-то возле морей можно вообще такое место выбрать, что температуру не придется регулировать совсем, либо регулировать очень не значительно.
Я думаю, что если бы интерфейс был проще и понятнее, мануал покороче и все это вкупе прозрачнее — просто нельзя было бы что-то там намутить. Негде было бы.
Я вас понял.
Да, если подстраиваться под окружение — можно выдурить прирост. Но тоже самое ведь можно сделать и сейчас? Определить на серверной стороне браузер и отдать нужный файл.
Облегчение компиляции — да, было бы здорово. Но думаю и это не так сложно реализовать. Не тянет на отдельный «новый язык».
Мне кажется, что если дело будет стоящее, то в firefox это будет включено. От кого бы не следовала инициатива. Почему-то я верю, что там смотрят не на источник инициативы, а на суть нововведений.
Замена и трансляция не даст прироста. Ну не бывает так, чтобы наворачиванием еще одного слоя повышалась производительность. Разве что там будут какие-то суровые оптимизации, но мне это представить сложно.
Прирост можно получить только поддержкой со стороны браузера, переложение критичных вещей на браузер (а он там уже может и видеокарту задействовать и много других недоступных инструментов) и в этом месте будет профит. А если что-то транслировать в js, то как оно может быть быстрее js?
Ну здорово. Только вот компиляция в JS вряд ли сильно поможет в борьбе за производительность. А в остальном пока что фреймворки справляются. Мне больше верится в развитие браузеров в сторону поддержки фреймворков. Интеграция в движок если не всего функционала, то критичных к производительности вещей и как следствие повышение производительности.
Не согласен. Во первых клиенты меняются, у них меняются условия, накапливается опыт.
А еще есть бывает, что человек без проблем платит полтинник за работу на пол часа, но не готов заплатить 500$ единоразово. У меня был такой клиент — у него было много достаточно мелких правок, за каждую из которых он без проблем платил. По кругу выходило ого-го сколько.
Показывать работу в процессе — довольно спорный момент, не все понимают, что это не окончательный результат, некоторые расстраиваются так как считают, что качество низкое и так далее. Спорно весьма. Бывает не просто убедить заказчика, что его опасения напрасны и это не конечный результат.
Водичкой из океана куда проще охлаждать.
А вообще я с вами согласен — идея не лучшая.
— Отлично. Вы приняты главным администратором в ДЦ. Садитесь в вертолет.
А там уже есть вопросы, нет вопросов — какая разница? До следующего вертолета будет время обдумать. :D
Совсем не обязательно просто брать воздух и гнать его на сервера. Замкнутый контур с осушенным азотом и он уже охлаждается землей.
Это конечно шутки, но подземный (или подводный, в море?) контур вполне мог бы помочь в борьбе с теплом где угодно. А может даже и применяют подобные системы.
Да, если подстраиваться под окружение — можно выдурить прирост. Но тоже самое ведь можно сделать и сейчас? Определить на серверной стороне браузер и отдать нужный файл.
Облегчение компиляции — да, было бы здорово. Но думаю и это не так сложно реализовать. Не тянет на отдельный «новый язык».
Ну а у microsoft своя дорожка.
Прирост можно получить только поддержкой со стороны браузера, переложение критичных вещей на браузер (а он там уже может и видеокарту задействовать и много других недоступных инструментов) и в этом месте будет профит. А если что-то транслировать в js, то как оно может быть быстрее js?