Да, правильная схема.
У дипхоста кошерные настройки, раз даже 64 метра дают для PHP, у sweb.ru хуже 32 метра дают, причем не только на PHP, но и на PERL скрипты в CGI.
У nichost.ru недавно видел управление виртуальным хостингом, сделано удобно в плане, что можно модули Apache включать, управлять и ставить прямо из панели, так вот если включить mod_perl, то выполняться прийдется в пространстве 128 мб. Ну и следовательно «неаккуратные» или не предназначенные скрипты для запуска кроме как в CGI пожирают там хостинг с радостью :)
Прямой эфир
0
Подробно на хабре расписывали как все устроено у diphost.ru. Каждому пользователю свой Апач, но по прежнему за Nginx:
Наверное, сейчас и у других примерно также. По PHP сейчас там конфиг такой:
safe_mode Off
memory_limit 64M
max_execution_time 180
upload_max_filesize 16M
Наверное, сейчас и у других примерно также. По PHP сейчас там конфиг такой:
safe_mode Off
memory_limit 64M
max_execution_time 180
upload_max_filesize 16M
0
Ох, да, больная тема. У всего свои плюсы и минусы, но общая проблема это диски. Увы, массивы общие и пока нет технологий заставляющих обычный HDD диск отдавать всё асинхронно и параллельно.
Использую хостинг sweb.ru, там немного странный shared хостинг. Я пока даже полностью не смог понять их реализацию, но что-то подсказывает, что даже apache там от себя запускается, для каждого клиента. Хотя совсем недавно столкнулся с рядом проблем и ограничений например памяти (32 мб на процесс скрипта дают), что в принцип понял радость их VDS на базе XEN, пока нет нагрузки всё хорошо, но с возрастанием нагрузки виртуализация лажает по полной, особенно с памятью :(
Использую хостинг sweb.ru, там немного странный shared хостинг. Я пока даже полностью не смог понять их реализацию, но что-то подсказывает, что даже apache там от себя запускается, для каждого клиента. Хотя совсем недавно столкнулся с рядом проблем и ограничений например памяти (32 мб на процесс скрипта дают), что в принцип понял радость их VDS на базе XEN, пока нет нагрузки всё хорошо, но с возрастанием нагрузки виртуализация лажает по полной, особенно с памятью :(
+1
Дальше будет хуже :)))
0
Ну как бы идея-то разрушена, когда текущее состояние не зависит от предыдущего, зависит, он тебе или отдаст твиты или не отдаст :)
0
Я не смогу забыть этого ужаса.
0
В принципе, косвенно токен можно считать за логин пользователя.
В АПИ Яндекс.Фоток, например, тоже передается токен, но там и без него есть логин пользователя. Более красиво.
Но я считаю, нарушало бы тогда, когда для получения результата существовала необходимость узнавать текущее состояние.
В АПИ Яндекс.Фоток, например, тоже передается токен, но там и без него есть логин пользователя. Более красиво.
Но я считаю, нарушало бы тогда, когда для получения результата существовала необходимость узнавать текущее состояние.
0
«Завидую тем, кто будет разрабатывать во времена HTML5.»
как-то ты пессимистично :) меняешь деятельность или думаешь на нашем веку этого не случится?
как-то ты пессимистично :) меняешь деятельность или думаешь на нашем веку этого не случится?
+1
Тут проблемы с памятью на каждое подключение, префорками, но главное, как этим всем балансировать???
0
кстати, забавная штука получается с этим OAuth, которая чуток как раз нарушает идеологию Stateless ведь после первой авторизации и подтверждения, для следующих REST запросов например в Twitter всё же нужно передавать сгенерированный токен.
0
Flash можно не любить, но до некоторых пор иначе никак нельзя было сделать:
— Хранение данных на стороне пользователя до 100кб. Cookies только 4кб и каждый раз передаются в заголовках.
— Копирование в буфер обмена. Средствами JS только для IE.
— Нестандартные шрифты (sIFR). Cufon (Canvas/VML) появился значительно позже.
— Настоящие постоянные соединения (XMLSocket).
— Проигрывание видео с ускорением.
— Проигрывание звука.
Завидую тем, кто будет разрабатывать во времена HTML5.
— Хранение данных на стороне пользователя до 100кб. Cookies только 4кб и каждый раз передаются в заголовках.
— Копирование в буфер обмена. Средствами JS только для IE.
— Нестандартные шрифты (sIFR). Cufon (Canvas/VML) появился значительно позже.
— Настоящие постоянные соединения (XMLSocket).
— Проигрывание видео с ускорением.
— Проигрывание звука.
Завидую тем, кто будет разрабатывать во времена HTML5.
0
Все равно это не полноценная замена установленному TCP соединению. Лучше уж эмулировать WebSockets через Flash.
0
Realplexor хуже чем Ape, чем конкретно уже не помню, но когда экспериментировал ape дал лучшие результаты и проще установился.
А по поводу обычного хостинга — так редко когда такие проекты, где реально нужен push ставят не на vds.
А по поводу обычного хостинга — так редко когда такие проекты, где реально нужен push ставят не на vds.
0
0
Прикручивание = переделывание инфраструктуры. Обычный хостинг Nginx + Apache уже не подходит.
P.S. Протокол на это не рассчитан, вот и начались костыли.
P.S. Протокол на это не рассчитан, вот и начались костыли.
0
'А второй вариант — сервер не закрывает соединение с клиентом пока не получит данные, что вызывает необходимость переделывать инфраструктуру на сервере.'
Почему? Тот же Ape легко прикручивается к любому unix-серверу и вот тебе готовый push.
Почему? Тот же Ape легко прикручивается к любому unix-серверу и вот тебе готовый push.
0
Короче, не люблю я их. Я люблю REST. Stateless это его основа :)
0
Один флаг в конфиге и они уже зашифрованы :)
Ну, то что сессии охранять надо это да, если данные есть которые своруют, а просто так зря дергать их из базы наверное смысла нет, это конечно.
Ну, то что сессии охранять надо это да, если данные есть которые своруют, а просто так зря дергать их из базы наверное смысла нет, это конечно.
0
Небезопасно хранить важные данные в Cookies ) А для меня все данные, которые влияют на логику приложения — важные )
Что в Rails, что в CodeIgniter, по-умолчанию, данные хранятся в незашифрованном виде + хэш. И оба руководства рекомендуют для важных данных использовать БД + ключ в Cookies.
А защита от Replay-attacks напрочь убирает преймущества хранилища в Cookies: guides.rubyonrails.org/security.html#replay-attacks-for-cookiestore-sessions
Вроде так.
Что в Rails, что в CodeIgniter, по-умолчанию, данные хранятся в незашифрованном виде + хэш. И оба руководства рекомендуют для важных данных использовать БД + ключ в Cookies.
А защита от Replay-attacks напрочь убирает преймущества хранилища в Cookies: guides.rubyonrails.org/security.html#replay-attacks-for-cookiestore-sessions
Вроде так.
+1
Ух ты как всё и вся ужал в маленьком тексте. Для совсем начинающих наверное как-то не совсем тема раскрыта покажется.
Я даже всё понял, надеюсь остальные тоже ;-)
Кстати, по 5. и 8. пункту на примере mod_perl можно показать, что не так, а живут скрипты в памяти до перегруза Апач сервера и могут хранить общее состояние и обмены.
«Лучше избегать сессий.» как-то кардинально. Нагрузка да дикая при сессиях если хранить в базе, файлах или памяти, но отличный способ хранить в Cookies, Rails и CodeIgniter это пропагандируют и вполне успешно.
Я даже всё понял, надеюсь остальные тоже ;-)
Кстати, по 5. и 8. пункту на примере mod_perl можно показать, что не так, а живут скрипты в памяти до перегруза Апач сервера и могут хранить общее состояние и обмены.
«Лучше избегать сессий.» как-то кардинально. Нагрузка да дикая при сессиях если хранить в базе, файлах или памяти, но отличный способ хранить в Cookies, Rails и CodeIgniter это пропагандируют и вполне успешно.
+2
Тыком-то да, почти все начинали изучать. Но в какой-то момент понимаешь, что надо изучать базис, потому как с ним удобнее, быстрее и понятнее, что твориться вокруг и внутри
0
Server-Side программирование начал десять лет назад с попытки записать данные на сервер скриптом на VBScript в теге <script></script> ))) Изучение неизвестной области научным методом, скажем так, довольно занимательный процесс )
0
По з/п я озвучить не могу, оклад только если, да и то зависеть будет от человека, его желания работать и развиваться.
0
А джуниорам порядок з/п, если не секрет?
0
Создаются альтруистами-студентами, которые думают, что это всё так легко и просто. Обычно это как побочный от нормальной работы увлечение 2-3х человек, но долго и серьезно это несуществует.
Вливаться если только на проект-два…
Вливаться если только на проект-два…
0
самое интересное тут — про «мелкие студии-однодневки». для чего они вообще создаются? влиться в них — реально или неразумно?
0
Вариантов много :)
1. Влиться в коллективы уже имеющихся студий
2. Фрилансить так же на Уфу, знаю многие мелкие студии-однодневки пользуются услугами местных фрилансеров, ниче зазорного
3. Найти хорошего спонсора, который готов «ждать» долгий возврат денег и создавать свою студию, при хорошей финансовой поддержки первое время, светлой голове и крепких ногах это реально
4. Фрилансить вообще не на Уфу, аха
1. Влиться в коллективы уже имеющихся студий
2. Фрилансить так же на Уфу, знаю многие мелкие студии-однодневки пользуются услугами местных фрилансеров, ниче зазорного
3. Найти хорошего спонсора, который готов «ждать» долгий возврат денег и создавать свою студию, при хорошей финансовой поддержки первое время, светлой голове и крепких ногах это реально
4. Фрилансить вообще не на Уфу, аха
MpaK