Если проблема с хостингом, то тогда точно надо переезжать, а не искать способ показывать свои страницы вместо 500.
Переезд сильно зависит от требований сайта, поэтому так особо сложно что-то посоветовать. Думаю, надо посмотреть что есть из недорогого вокруг и смотреть если там есть нужные фичи.
Я тоже индивидуальный разработчик и обычно делаю примерно так:
Начальные данные: App Store берёт примерно неделю на проверку.
Если я хочу сделать изменения, то я их делаю, потом тестирую в тот же день и выставляю на очередь на проверку в App Store.
После этого я начинаю более детальные тесты, подключаю бета-тестеров (если есть желающие на данный момент).
Если я во время этих нескольких дней нахожу проблему, то я снимаю приложения с релиза и делаю новый фикс.
Если во время этих дней проблем нет, то обновление выходит в App Store.
Таким образом я достаточно хорошо экономлю время на review комбинируя это со своим внутренним тестированием.
Единственный риск — это если вдруг review будет очень быстрым, но за полтора года это было один раз (review занял 2 дня, но мне этого хватило что бы достаточно протестировать и понять что проблем нет).
Обновления не должны зависеть от процедуры проверки. Если важные проблемы найдены и требуется срочное обновление, то надо обновлять. Если обновление мелкое и хочется побольше потестировать, то можно и подождать.
Я бы делал разные если заранее известно количество свойств и оно точно не будет изменяться. Маленькие таблицы будут кешироваться.
Так же нету риска когда по какой-то причине (баг в коде или ещё что-то) style_id, например, указывает на id цвета.
Не уверен что он подойдёт для автора вопроса. У этого WR1043ND, например, памяти мало (всего 32MB). Обычно у современных более-менее нормальных начинается от 128MB и выше. Малое количество памяти достаточно часто является причиной частых перезагрузок.
Для своей цены, пожалуй, нормальный, но для задач автора вопроса — не очень.
1. У меня для pycurl как раз отдельный модуль. Там есть post, get. Вместо этих post, get можно возвращать содержимое локальных файлов в зависимости от запроса.
То есть, твой основной скрипт будет иметь что-то типа:
web = webclient.webclient()
data = web.get('http://www.google.com/')
Соотвественно get можно подменить на другой get в зависимости от, например, флага или настройки.
Можно даже делать что-то типа такого:
web = webclient.webclient()
if DEBUG:
web.get = web.get_file
....
data = web.get('http://www.google.com/')
2. Я это реализовывал сам (примерно как в #1), так как слишком просто что бы не заморачивать с каким-то фреймворком.
3. Как я понимаю, речь идёт про высокоуровневое тестирование, где это будет не так важно.
Для задержек есть специальные примочки. Например, на мобильных платформах такие штуки встроены.
Не важно в каком месте почта, главное — что бы procmail и dovecot смотрели в одно и тоже место.
Если procmail перекидывает в /var/www/username/..., то надо просто сделать что бы dovecot смотрел там же.
Мне кажется, DDR1 не делали FB. А тут просто Registered ECC судя по маркировке.
Лет 10 назад я над такими модулями старался не дышать резко и только пылинки сдувал.
Сборка из исходников в локальное окружение это почти как #2 с теми же особенностями (надо вручную собирать ещё раз когда будут изменения).
Но в любом случае я рад что проблема решена. Всё-таки, намного интереснее заниматься самой разработкой, чем на решение каких-то проблем и обходных путей для неё.
Если нет паролей, то тогда только через пользователя надо отдавая ему url и смотреть что получил в ответ с надеждой на токен.
Я так скриптом на Twitter авторизируюсь — сначала сам авторизировался, получил токен, вставил токен в скрипт и он пляшет уже сам без меня. Если кто-то у меня стырил скрипт с токеном, то я просто де-авторизирую токен и создам новый.
У меня пять языков.
В порядке убывания по статистике: английский (75%), немецкий (14%), русский (3%), французский (1%) и испанский (0.5%).
Английский был первым при разработке приложения.
По странам у меня штаты берут примерно 45%.
