Ну во-первых, у меня лично пока вообще таких проблем (с прослушкой) нет :)
Во-вторых, на множестве корпоративных файрволов открыт не-HTTP-трафик по порту 443 (по вполне понятным причинам), чего вполне достаточно (просто VPN-сервер надо настроить на прослушку именно этого порта).
В-третьих, речь не идет о «проблемах SSL». Я к этому протоколу тоже претензий не имею :) Речь идет о том, с какими проблемами могут сталкнуться пользователи, даже при использовании HTTPS :)
Забываете, что пользователь может хотеть скрыть свой личный траф от начальства. Т.е. третья сторона («человек по средине») в этом случае как раз начальство и их «защитное» ПО.
Вот в том-то и дело, что сертификат будет подложный, это будет видно, НО у вас останется два варианта: либо принять подложный (согласиться, что вас будут прослушивать), либо не работать с этим сайтом вообще. Только одно из двух.
Если же HTTPS будет идти внутри VPN-тоннеля, то тут уже подложить левый сертификать просто не выйдет. А ключи для VPN можно принести безопасными путями. Главное чтобы бинарный SSL-трафик не был закрыт на файрволе как таковой, хотябы на одном порте (а обычно именно так и происходит — по 443 порту разрешают гонять SSL-трафик всем юзерам корпоративного файрвола).
> > 'это не разные контроллеры, это разные View.'
>
> На практике, то и другое, как правило, так как в зависимости типа приложения будет
> меняться его поведение. Банальный пример — фронтенд и бэкенд приложения, если
> рассматривать в рамках только веба.
А вот это уже зависит строго от того, как делать. Например, разделять фронтэнд и бэкэнд вовсе не обязательно. Правда я и сам так делаю, но только потому что так проще, но нельзя сказать, что так лучше. Но в любом случае, на практике легко можно сделать так, что контроллеры фронт- и бэкэнда будут одинаковыми. Опять таки, View разный, контроллеры одни и те же. (Но я не говорю, что они не могут быть разными, — могут).
Если делать все _правильно_, то проблемы «разные» контроллеры быть не должно. Если такая проблема возникает, наверное опять недопонимание чего-то…
Каталог application включает в себя все то, что касается данного сайта — приложения.
Каталог library включает в себя фреймворки (Zend, ваш собственный, другие фреймворки и библиотеки), которые используются в самых разных приложениях. Если у вас есть несколько различных систем, работающих с одной подсистемой, то логично вынести эту подсистему в library (в качестве примера — собственная реализация captcha).
В вакууме (в идеале) в репозитории кода каждый подкаталог library должен представлять собой связь с другим репозиторием, в котором ведется разработка данного фреймворка/библиотеки.
При создании сайта (не хомпэйдж, не блог, не визитка, а что-то по-сложнее и уникальнее) наверное 70—80% кода годятся только для данного сайта, значит это application, а не library.
Что касается `веб-фронтенд, консольный клиент, сервис-приложения, GTK в конце-концов`, так это не разные контроллеры, это разные View. И тут вы как раз опять грубо нарушаете идеологию MVC.
Впрочем, ваша философия тоже имеет право на жизнь. И я не переубеждаю вас (наверное это бесполезно, так же как переубеждать меня), но сам с ней не согласен. Подозреваю, что на практике ваш подход иногда будет оптимален, но это будет лишь исключение из правил. Для основной массы сайтов ваши аргументы можно рассматривать только как философию, не имеющую практических предпосылок.
Вообще написано хорошо, старательно. НО! Model помещать в library нельзя — это грубое нарушение. Автору стоит почитать, зачем нужен каталог library в ZF. Да, самое место им действительно в /application/models, или где-то в другом месте, но в пределах каталога /application
Есть такой нюанс, если сходу ошибиться с паролем, то система обратиться к гуглу с неправильным паролем столько раз, сколько отчетов экспортируется. В дефалтном варианте это 8 раз. После этого гугл естественно будет ребовать от вас ввода каптчи, чтобы убедиться, что вы не подбираете пароли. А возвращать в этом случае он будет временный редирект (Temporary redirect). Его вы в логе и увидите, при этот stat.php будет вывалить нутисы про Undefined index'ы. В этом случае, надо подождать минут 20, а потом повторно запросить статистику, и все будет хорошо :)
Карма — средство выражения своего отношения к пользователю. Я крайне редко прибегаю к минусованию кармы, очень крайне редко. Но вот это сообщение как итог беседы натолкнуло на минус. Делайте выводы…
Я переголосовал в карме, когда остыли эмоции и вижу, что человек вы вменяемый. Может в других топиках общение с вами окажется более толковым и соответствующем теме.
Зато у меня есть вопрос, а точнее замечание. Хочу обратить ваше внимание на суть моих сообщений, которую вы, похоже, не уловили.
Все вышенаписанное касается повествований в PHP-темах о достоиниствах Питона и пр. Но никто не мешает вам писать свои топики на эти темы, и «учить» в них новичков. Собственно для этого хабр и создавался. Вот учитывая это, ваша ирония выше совсем не уместна.
Столько букв написано о том, что всякие лезут со своими «умными» советами куда не просят, а потом удивляются, что с кармой плохо.
Все, даже самые новые новички, знают, что есть другие языки, кроме PHP. И вот если им надо будет совета по другим языкам, они его спросят. В данной ветке идет обсуждение PHP и нечего вообще упомянать что-то, что не имеет к PHP отношения.
Да, питонисты — тихие спокойные ребята, а пхп-шники — агрессивные дурачки, потому что:
1) Питонисты и Рубироиды при каждом удобном случае лезут в топики про php и кричат, что php — гавно, а руби/питон — круто!
2) На форумах и в IRC-чатах, когда кто-то задает вопрос `как это сделать в php/java/с++/c#` тут же находятся рубироиды и питонщики, которые кричат, что это не надо делать на данном языке, а надо делать на руби или питоне! А автор вопроса — мудак!
3) Когда дается ответ на вопрос `как это сделать в php/java/с++/c#` в несколько строк кода, тут же находится довольный рубироид и пишет все в одну только ему понятную строчку и кричит `вот как все просто на руби, а вы мудаки все еще пишете на ХХХ`!
Как же это уже раздражает…
Ребята, если сидит компания из нескольких человек с пивом и обсуждает, как они хорошо съездили в Крым, не надо влазить в их беседу, объясняя, что Крым гавно, а Египет жжот. Есть большая вероятность, что вы получите в морду.
Мы с вами говорим немного о разных вещах. Я говорю про отладку кода, а вы про логирование ошибок, частично профилирование, нагрузочное тестирование и другие виды опять же тестирования.
Дело не в переходах вперед-назад. Это лишь удобства. Главное — то, что во время останова вы имеете перед глазами «состояние» программы. Т. е. вы можете посмотреть значения всех переменных, стек функций, ходя по шагам можете найти ошибку. При отладке через dump (или log, что вобщем-то тоже самое, только еще хуже) для этого придется каждый раз править код перегружать страницу, что не сильно удобно (а познается это лишь в практическом сравнении) и очень утомительно.
На счет `решение для реалтайм сервиса`, может я неправильно вас понял, но вы отлаживаете на серверах в инете? Здесь речь идет об отладке на локальной машине или корпоратичном тест-сервере, но никак не в сети. В сети-то как раз и уместен лог. Но там уже не уместна отладка как таковая. Там строго логирование ошибок.
Во-вторых, на множестве корпоративных файрволов открыт не-HTTP-трафик по порту 443 (по вполне понятным причинам), чего вполне достаточно (просто VPN-сервер надо настроить на прослушку именно этого порта).
В-третьих, речь не идет о «проблемах SSL». Я к этому протоколу тоже претензий не имею :) Речь идет о том, с какими проблемами могут сталкнуться пользователи, даже при использовании HTTPS :)
Если же HTTPS будет идти внутри VPN-тоннеля, то тут уже подложить левый сертификать просто не выйдет. А ключи для VPN можно принести безопасными путями. Главное чтобы бинарный SSL-трафик не был закрыт на файрволе как таковой, хотябы на одном порте (а обычно именно так и происходит — по 443 порту разрешают гонять SSL-трафик всем юзерам корпоративного файрвола).
>
> На практике, то и другое, как правило, так как в зависимости типа приложения будет
> меняться его поведение. Банальный пример — фронтенд и бэкенд приложения, если
> рассматривать в рамках только веба.
А вот это уже зависит строго от того, как делать. Например, разделять фронтэнд и бэкэнд вовсе не обязательно. Правда я и сам так делаю, но только потому что так проще, но нельзя сказать, что так лучше. Но в любом случае, на практике легко можно сделать так, что контроллеры фронт- и бэкэнда будут одинаковыми. Опять таки, View разный, контроллеры одни и те же. (Но я не говорю, что они не могут быть разными, — могут).
Если делать все _правильно_, то проблемы «разные» контроллеры быть не должно. Если такая проблема возникает, наверное опять недопонимание чего-то…
Каталог library включает в себя фреймворки (Zend, ваш собственный, другие фреймворки и библиотеки), которые используются в самых разных приложениях. Если у вас есть несколько различных систем, работающих с одной подсистемой, то логично вынести эту подсистему в library (в качестве примера — собственная реализация captcha).
В вакууме (в идеале) в репозитории кода каждый подкаталог library должен представлять собой связь с другим репозиторием, в котором ведется разработка данного фреймворка/библиотеки.
При создании сайта (не хомпэйдж, не блог, не визитка, а что-то по-сложнее и уникальнее) наверное 70—80% кода годятся только для данного сайта, значит это application, а не library.
Что касается `веб-фронтенд, консольный клиент, сервис-приложения, GTK в конце-концов`, так это не разные контроллеры, это разные View. И тут вы как раз опять грубо нарушаете идеологию MVC.
Впрочем, ваша философия тоже имеет право на жизнь. И я не переубеждаю вас (наверное это бесполезно, так же как переубеждать меня), но сам с ней не согласен. Подозреваю, что на практике ваш подход иногда будет оптимален, но это будет лишь исключение из правил. Для основной массы сайтов ваши аргументы можно рассматривать только как философию, не имеющую практических предпосылок.
Выглядеть это будет так:
rapidshare.com/files/159054213/W7.part01.rar
rapidshare.com/files/159044102/W7.part02.rar
rapidshare.com/files/159054210/W7.part03.rar
rapidshare.com/files/159054216/W7.part04.rar
rapidshare.com/files/159056003/W7.part05.rar
rapidshare.com/files/159056235/W7.part06.rar
rapidshare.com/files/159056270/W7.part07.rar
rapidshare.com/files/159056334/W7.part08.rar
rapidshare.com/files/159067562/W7.part09.rar
rapidshare.com/files/159058677/W7.part10.rar
rapidshare.com/files/159068218/W7.part11.rar
rapidshare.com/files/159068139/W7.part12.rar
rapidshare.com/files/159069887/W7.part13.rar
rapidshare.com/files/159067944/W7.part14.rar
Я переголосовал в карме, когда остыли эмоции и вижу, что человек вы вменяемый. Может в других топиках общение с вами окажется более толковым и соответствующем теме.
Все вышенаписанное касается повествований в PHP-темах о достоиниствах Питона и пр. Но никто не мешает вам писать свои топики на эти темы, и «учить» в них новичков. Собственно для этого хабр и создавался. Вот учитывая это, ваша ирония выше совсем не уместна.
Столько букв написано о том, что всякие лезут со своими «умными» советами куда не просят, а потом удивляются, что с кармой плохо.
Все, даже самые новые новички, знают, что есть другие языки, кроме PHP. И вот если им надо будет совета по другим языкам, они его спросят. В данной ветке идет обсуждение PHP и нечего вообще упомянать что-то, что не имеет к PHP отношения.
1) Питонисты и Рубироиды при каждом удобном случае лезут в топики про php и кричат, что php — гавно, а руби/питон — круто!
2) На форумах и в IRC-чатах, когда кто-то задает вопрос `как это сделать в php/java/с++/c#` тут же находятся рубироиды и питонщики, которые кричат, что это не надо делать на данном языке, а надо делать на руби или питоне! А автор вопроса — мудак!
3) Когда дается ответ на вопрос `как это сделать в php/java/с++/c#` в несколько строк кода, тут же находится довольный рубироид и пишет все в одну только ему понятную строчку и кричит `вот как все просто на руби, а вы мудаки все еще пишете на ХХХ`!
Как же это уже раздражает…
Ребята, если сидит компания из нескольких человек с пивом и обсуждает, как они хорошо съездили в Крым, не надо влазить в их беседу, объясняя, что Крым гавно, а Египет жжот. Есть большая вероятность, что вы получите в морду.
На счет `решение для реалтайм сервиса`, может я неправильно вас понял, но вы отлаживаете на серверах в инете? Здесь речь идет об отладке на локальной машине или корпоратичном тест-сервере, но никак не в сети. В сети-то как раз и уместен лог. Но там уже не уместна отладка как таковая. Там строго логирование ошибок.