При 1500 хостах в день на Медиатемпле выходило двухкратное превышение лимитов? Т.е. теоретически 1000 GPU = 750 хостов в день WordPress? А по хитам сколько было?
С саппортом APC сталкивался, когда на одном серверном упсе возникла плавающая проблема. Привозим к ним, а там все нормально. Оставили себе, недели 2 тестили, в результате отдали — сказали что все ок. Но проблема как была, так и осталась. Потом возили еще 2 раза с тем же результатом, и только потом они решили его заменить на новый.
А потом приходит сообщение от саппорта вконтакте: «К сожалению Ваш аккаунт был взломан, данные удалены и пароль изменен. Однако мы восстановили все данные, для входа в аккаунт используйте пароль ###. С любовью Ваша служба поддержки В контакте. Спасибо что Вы с нами» :)
Имхо, нужно сочетать преимущества спрайтов и data:URI.
Я сначала создаю 1-2 спрайта с маленькими картинками (до 5kb), а что не влазит в них делаю через data:URI. Таким образом я избегаю множества HTTP запросов к маленьким файлам и в то же время не пытаюсь запихать в спрайт все, что возможно, тем самым увеличивая его геометрические размеры.
Картинки размером более 5kb при возможности загоняю в спрайт, либо оставляю как есть.
На выходе получается CSS файл небольшого размера (за счет того, что там не хранятся картинки по 20kb), 1-2 спрайта с элементами оформления и 2-3 картинки, которые в спрайт не влезли и слишком велики, чтобы бросать их в data:URI.
Наверное ни один программный продукт не заработал сразу идеально после окончания программирования. У любой программы есть ошибки, есть недоделки (не ошибка, но вещь явно не помогающая ее работе). Когда Вы сдаете программу в ней уже есть ошибки, которые могут обнаружиться после просмотра другим программистом, тестером или клиентом. Не надо этого бояться, Вы не создадите сразу идеальный продукт.
Качество программы определяется не числом ошибок в первой версии, а эффективностью их исправлений. Поэтому не надо бояться ошибок в программах, это обычный процесс разработки. Только исправляйте их и старайтесь в следующий раз их не допускать.
Обычно программные проекты имеют тенденцию меняться по желаниям заказчика. И тогда судорожно разработав все по ТЗ и уложившись в сроки Вы услышите а как эта штучка здесь не отображается, мы думали это же очевидно. И чтобы внести это изменение надо вернуться к началу этапа программирования и переписать ядро программы.
Вы конечно можете сослаться что такого в ТЗ не было и запросить дополнительных денег для реализации этой функции, но тогда удовлетворенность клиента будет ниже. Не проще ли наглядно показать и объяснить функции ядра на ранней стадии, когда внесение изменений в него не столь трудоемко и сразу получить комментарии клиента?
Указанная Вами система ведь также требует установки на сайте? То есть чтобы можно было зарабатывать на сайте, владельцу сайта нужно выполнить действия по подключению к системе. Автору также нужно зарегистрироваться в системе.
Тогда чем Ваш вариант отличается от AdSense? Также нужно предварительно настроить сайт, а автору зарегистрирваться на Google. Только в этом варианте потенциальный охват больше и выше вероятность что у автора уже есть аккаунт на Google.
На одном форуме видел. В профиле пользователя хранится id его аккаунта в AdSense, а при создании топика выводится именно его рекламный блок. Получаем полностью прозрачную систему без сторонних сервисов.
Даже имея в инвесторах Microsoft, Apple и Google вряд ли удастся пропихнуть новую билетную систему в масштабах страны без поддержки государства. А в мире так и подавно.
Аналогично и с денежной системой, если это конечно не будет лишь Яндекс.деньги. Но тогда и смысла в этом немного.
Постепенно к этому будущему нас Google ведет. Операционка для «терминалов» уже фактически есть. А в качестве вашей «флешки» пойдет обычный токен. Воткнул токен в терминал и ты в своем компе. Теоретически в тот же токен можно добавить и паспорт, и деньги, и билеты, было бы желание со стороны государства.
— 10GB $4.99/month or $49/year
— 20GB $6.99/month or $69/year
— 25GB $7.99/month or $79/year
Кому нужно, пишите в личку — скину ссылку с промо-кодом.
Я сначала создаю 1-2 спрайта с маленькими картинками (до 5kb), а что не влазит в них делаю через data:URI. Таким образом я избегаю множества HTTP запросов к маленьким файлам и в то же время не пытаюсь запихать в спрайт все, что возможно, тем самым увеличивая его геометрические размеры.
Картинки размером более 5kb при возможности загоняю в спрайт, либо оставляю как есть.
На выходе получается CSS файл небольшого размера (за счет того, что там не хранятся картинки по 20kb), 1-2 спрайта с элементами оформления и 2-3 картинки, которые в спрайт не влезли и слишком велики, чтобы бросать их в data:URI.
Качество программы определяется не числом ошибок в первой версии, а эффективностью их исправлений. Поэтому не надо бояться ошибок в программах, это обычный процесс разработки. Только исправляйте их и старайтесь в следующий раз их не допускать.
Вы конечно можете сослаться что такого в ТЗ не было и запросить дополнительных денег для реализации этой функции, но тогда удовлетворенность клиента будет ниже. Не проще ли наглядно показать и объяснить функции ядра на ранней стадии, когда внесение изменений в него не столь трудоемко и сразу получить комментарии клиента?
Тогда чем Ваш вариант отличается от AdSense? Также нужно предварительно настроить сайт, а автору зарегистрирваться на Google. Только в этом варианте потенциальный охват больше и выше вероятность что у автора уже есть аккаунт на Google.
Аналогично и с денежной системой, если это конечно не будет лишь Яндекс.деньги. Но тогда и смысла в этом немного.