Я когда читал ваш комментарий у меня волосы дыбом вставали. Ну как такое можно писать не разобравшись в теме?
Большинство проблем у вас возникало, только потому что вы в один присест хотели освоить целый стек технологий. Причем постоянно прослеживается мысль, что вы толком не изучали документацию.
Чего только стоит ваше:
На некоторое время такой оптимизации хватало, но по мере роста числа пользователей вновь превысился лимит. Пришлось провести следующий этап оптимизации — активно использовать кэш (memcache). Теперь вся работа с записями была целиком помещена в кэш, операции с которым полностью бесплатны, а в базу его содержимое скидывалось раз в сутки. Кэш периодически сбрасывается, причём логики в этом процессе я не увидел — может работать неделю, а может по три раза в сутки очищаться.
Логики? Какой логики вы ожидали? Кэш, он на то и кэш, что не гарантирует постоянное хранение данных, а тем более предсказуемое время хранения!
Про кодировки, тут вообще не понятно причем тут облачный хостинг. Их везде самому надо разруливать.
Python действительно сильно порезан, но это как бы уже сразу описано в документации.
По последнему пункту, вообще у меня такое бывало и не раз. И постоянно я видел в логе чёткие указание, что необходимо сделать чтобы исправить. И после одной команды всё приходило в норму. Прямо представляю ситуацию из параллельного мира, разработчик на php который деплоит через ftp на хостинг. И тут рвется соединение, половина прошла, а другая нет, а посетители таким образом нашли лазейки «для чего-нибудь», к примеру из-за этого создаются временные файлы. И бедный программист заново идет и руками разгребает, что наделали посетители, а потом ещё и жалуется что деплой в лайв не консистентый!
Ну и финишом, рекомендация использовать виртуалки другого облачного хостинга? Серьезно? Это даже не на одном уровне. Я понимаю, если бы вы конкретно разобрались, а так это не профессионально.
Во первых, армирование есть и если присмотреться, то можно увидеть как стержни маленькими кусочками вворачиваются постепенно.
Во вторых, если присмотреться в видео, там бетон внутри волнами, что делит все пространство на герметичные воздушные зоны. Это обеспечивает теплоизоляцию. Этот же принцип работает с остеклением окон.
В третьих, он приводил примеры для своего климата.
Нужно последовательно идти. Сначала Passive View, когда ничего не обновляется.
Что нужно сделать, чтобы обновить? Перезапустить. А значит мы имеет уже процесс обновления!
Теперь что нужно, чтобы процесс обновления был запущен? Когда он должен быть запущен? Ответы на эти вопросы и будут конечной реализацией. Самое простое, оповещать все виды при обновлении данных, чтобы они обновились. Что управляет данными и операциями над данными? Правильно модель!
Другое решение, виды должны наблюдать за моделью. Т.е. подписываться на изменения и в случае если оно происходит, обновляться. Это даже чуть элегантнее, хотя вводит процесс подписки.
А если посмотреть на проблему более глобальнее, то есть подходы более простые и элегантные. Но для этого стоит погрузится в обучение функциональным программированием. Чтобы не быть голословным, вот ссылка.
То, что из-за синтаксической ошибки в question, вся Section будет «скомпрометирована» скорее всего так решил автор. Если такая синтаксическая ошибка не так важна, вполне возможна другая стратегия вычисления. Можно возвращать не только ошибку, но и результат, который удалось аккумулировать, и дальше продолжать парсить. Комбинаторы на то и удобны, что должны позволить лучше управлять процессом вычисления.
Я не вникал сильно в тему, но как мне кажется нет никакой проблемы сделать так, чтобы если комбинатор не разобрал, то вернул сообщение об ошибке. В Parsec есть точно такой «способ». Или имелось в виду другие диагностические сообщения?
Это простые вложенные классы. Это просто синтаксическая конструкция. Назначение у нее простое — сокрытие и группировка функциональности. Почему Вы их считаете рекурсивными?
Пример рекурсивной вложенности должен быть таким: public class A {
private A memberA;
private A memberB;
}
Т.е. объект класса может содержать объекты своего же класса.
Да, но если использовать встроенный язык, то можно абстрагироваться от особенностей браузеров и генерировать специфичный для каждого из них код. Это сразу понизит уровень работы.
И если проект не такой большой, программист сам может применять стили оформления. Которые может сделать дизайнер. :) Дизайнер делает свою работу в своих терминах, а программист формирует стиль, который он может применить к любому коду.
В любом случае завязываться на дизайнера не стоит. Лучше сразу делать все лаконично и с наименьшим дублированием.
Естественно нужно всё это отдельно от основного кода хранить. :) Разве дизайнеры не понимают встроенного языка? Вообще можно сделать дизайнерам утилиту, которая позволит делать всё на лету. :)
Если прикинуть, то в замен шаблонов будет пару layout, и виджеты (меню, баннеры). Остальное это непосредственно входные данные (запрос), и функция, которая возвращает результат, которые и соединяется со всем остальным. Все эти сущности можно сделать стандартными и просто описывать также. В итоге легче следить за дублированием, потому то компоненты пере используются, легче понимается код. Но это в теории. :) Возможно, что в реальном проекте это будет жутким нагромождением. :)
Большинство проблем у вас возникало, только потому что вы в один присест хотели освоить целый стек технологий. Причем постоянно прослеживается мысль, что вы толком не изучали документацию.
Чего только стоит ваше: Логики? Какой логики вы ожидали? Кэш, он на то и кэш, что не гарантирует постоянное хранение данных, а тем более предсказуемое время хранения!
Про кодировки, тут вообще не понятно причем тут облачный хостинг. Их везде самому надо разруливать.
Python действительно сильно порезан, но это как бы уже сразу описано в документации.
По последнему пункту, вообще у меня такое бывало и не раз. И постоянно я видел в логе чёткие указание, что необходимо сделать чтобы исправить. И после одной команды всё приходило в норму. Прямо представляю ситуацию из параллельного мира, разработчик на php который деплоит через ftp на хостинг. И тут рвется соединение, половина прошла, а другая нет, а посетители таким образом нашли лазейки «для чего-нибудь», к примеру из-за этого создаются временные файлы. И бедный программист заново идет и руками разгребает, что наделали посетители, а потом ещё и жалуется что деплой в лайв не консистентый!
Ну и финишом, рекомендация использовать виртуалки другого облачного хостинга? Серьезно? Это даже не на одном уровне. Я понимаю, если бы вы конкретно разобрались, а так это не профессионально.
site, даже странно что я про него ничего не знал. Позор мне! =)Во вторых, если присмотреться в видео, там бетон внутри волнами, что делит все пространство на герметичные воздушные зоны. Это обеспечивает теплоизоляцию. Этот же принцип работает с остеклением окон.
В третьих, он приводил примеры для своего климата.
Что нужно сделать, чтобы обновить? Перезапустить. А значит мы имеет уже процесс обновления!
Теперь что нужно, чтобы процесс обновления был запущен? Когда он должен быть запущен? Ответы на эти вопросы и будут конечной реализацией. Самое простое, оповещать все виды при обновлении данных, чтобы они обновились. Что управляет данными и операциями над данными? Правильно модель!
Другое решение, виды должны наблюдать за моделью. Т.е. подписываться на изменения и в случае если оно происходит, обновляться. Это даже чуть элегантнее, хотя вводит процесс подписки.
А если посмотреть на проблему более глобальнее, то есть подходы более простые и элегантные. Но для этого стоит погрузится в обучение функциональным программированием. Чтобы не быть голословным, вот ссылка.
А так это даже не обзор.
Пример рекурсивной вложенности должен быть таким:
public class A {
private A memberA;
private A memberB;
}
Т.е. объект класса может содержать объекты своего же класса.
И если проект не такой большой, программист сам может применять стили оформления. Которые может сделать дизайнер. :) Дизайнер делает свою работу в своих терминах, а программист формирует стиль, который он может применить к любому коду.
В любом случае завязываться на дизайнера не стоит. Лучше сразу делать все лаконично и с наименьшим дублированием.