ну тогда, когда опера начнет поддерживать кроме html стандартов, еще и http, например, запрашивать страницу с Cache-Control: no-store в случае с нажатием кнопки back, она будет интересным браузером.
может, у вас другие задачи и другие данные, но мне с постгресом намного удобнее работать, чем с mysql хотя бы даже из perl.
чтобы не быть голословным — простите, но что мешало разработчикам mysql написать нормальный парсер sql, который бы не требовал чудовищных
delimiter $$$
без которых очень сложно представить себе триггеры и хранимые процедуры.
или, допустим кодировку клиента. почему–то нельзя было сделать это менее мудацким образом, чем set names или DBI:mysql:database=db;mysql_read_default_group=perl;mysql_read_default_file={$root}/etc/my.cnf
а давайте еще посмотрим на то, что происходит с dbh после возникновения ошибки в mysql…
не буду холиварить, но как–то немного необъективно
да, согласен, что ошибся. но ответить самому себе я не смог, так как хабр мне предложил подождать пять минут, прежде я смогу отправить еще один комментарий.
тем не менее, проверять файлы таким образом — все равно ужасно. потому что на каждую генерацию страницы с ссылками на внешние ресурсы будет затрачено очень большое количество синхронных соединений. и времени тоже. в качестве примера можно привести пример такого рода: проверяется наличие файла на сервере, у которого очередь на i/o очень велика. тогда пока вы не исчерпаете таймаут, ваш скрипт не отработает. а в силу того, что таймауты по умолчанию зачастую стоят одинаковые, пользователь тоже не увидит страницу
вы для проверки существования файла открываете два сокета, один настороне клиента, другой — на стороне сервера. при большом количестве таких запросов вы рискуете упереться во множество интересных ограничений.
кроме того, для проверки файла без его открытия есть команда stat. которая будет работать ощутимо быстрее любого из ваших способов. учите матчасть!
делите покрытие на регионы, по комнатам/подразделениям/отделам. в каждый отдел кабель своего цвета. потом каждую комнату, например, по тому же принципу (но можно и не заморачиваться так уже). в результате достигается полное цветовое дифференцирование штанов: рыжие — бухгалтерия, синие — разработка, зеленые — менеджмент. если каждый подраздел тоже отличается внутри по цветам, то можно вообще все шоколадно сделать — вася петров из тестирования у розетки рядом со стеной — синий (разработка), зеленый (тестирование), IV (номер розетки).
а для маркировки проводов к розеткам применяете уже ваши методы.
разницы в цене между серой витой парой и разноцветной почти нет. зато вам не пришлось бы заморачиваться с большей частью маркировки, если бы вы использовали просто цветной кабель. телефонный тоже можно разноцветный купить.
все операции с классами/объектами в ооп в большинстве языков являются просто надстройкой над указателями и структурами. и нет совершенно никакой разницы, реализуются классы через прототипы или структуры. нет никакой разницы между явными и неявными конструкторами. и замыкания просто и весело можно реализовывать в C, просто придется дополнительные параметры передавать.
если вы не будете заморачиваться с «парадигмами», то поймете, что между языками программирования в большинстве вообще нет никакой разницы. просто местами отличаются реализации алгоритмов, а сами алгоритмы не меняются.
письмо — это набор заголовков и текста, который идет после них. если вы замените заголовок «To:» на локальный адрес, а дополнительно создадите еще один заголовок, например «XXX-To:», куда запишете тестируемое поле, то вы решите вашу задачу. и вместо копания в гугле и терминале, вы просто добавите пару строк кода.
6 лет уже пользуюсь мастерхостом для colocation. каждое лето кроме прошлого аварийно тушили сервер из–за перегрева. после исчерпания денег на счету могут отключить не сервер, а dns записи и пока кэш не обновится — несколько дней простоя из–з посетителей, которые никак не могут зайти. очередной российский говнохостинг
неприятно эстетически — после установки определенного количества софта, макпортс подрался сам с собой — пришлось деактивировать руками им же дополнительно установленный perl 5.10 чтобы заменить на 5.8.8. ну и принцип «каждой твари по паре» давно изжил себя. когда система была 10.3 и очень многие вещи не собирались из–за старых и глючных libiconv, libxml, libssl — это было понятно, но с тех пор тащить в макпорты все dependency стало модным, что не добавляет проекту привлекательности.
что же до практики — он не интегрируется в систему вообще. если собрать некую библиотеку (например gd) под macports, потом поставить GD модуль для perl и попытаться использовать GD под mod_perl2 (читай: встроенный апач2), то гарантирован SEGFAULT.
есть еще другая неприятность с апачем. по умолчанию в 10.5 это universal binary для 4 архитектур. в моей системе он выполняется в режиме 64bit. а большинство библиотек в macports собирается только для 32bit. дальше рассказывать?
у меня фаллаут 3 выставил разрешение 1320х1080 для монитора 1440х900 (а я что–то это вовремя не заметил) и поэтому у меня не было указателя пути. посему в попытках найти это гребаное радио я провел три выходных в поисках нужного выхода из метро. ну и потом было уже просто обидно не найти все локации на карте. так что неделя геймплея вполне себе.
соглашусь, про тесты не совсем внимательно прочитал
«Говорите какие-то глупости, о чем вообще не было написано.»
«Релиз-кандидат – это конечный монолитный продукт, в который нельзя вносить изменения. Если необходимо исправить ошибки, доработать функционал – необходимо начинать с начала и делать нового кандидата.»
«Чтобы делать quick-fix, нужно еще найти корень зла, на что уйдет больше времени, чем сделать мгновенный откат до предыдущей версии — переключить контекст веб-сервера на предыдущий релиз.»
всегда есть ситуации, когда типографическая ошибка или неверное условие работают правильно до тех пор, пока не встретится условие, вскрывающее проблему. по этому принципу работают же и sql инъекции. для множества таких ситуаций есть возможность быстро исправить ситуацию. и нужно иметь возможность быстро ее исправить.
«Гораздо круче все застопить, запустить новый процесс и посмотреть что получится — заведется или не заведется?»
если мы говорим о небольшом проекте с кучей обновляемых зависимостей — да. такое делать с большими проектами просто невозможно — они изначально сегментированы. ну и создателям и разработчикам больших проектов неинтересен ваш пост — они уже столкнулись со всем.
«Расскажите об этом ребятам из любого высоконагруженного проекта (Яндекс, Рамблер, РБК). Подсчитывать бабло и смеятся будем все вместе.»
да, давайте посмеемся. я работал в яндексе и выкладывал код на главную страницу яндекса. яндекс, рбк, фотофайл и тому подобные сервисы сильно вырождены и сегментированы — они выполняют одну функцию и на нее заточены. большинство сетевых мультисервисов имеют в своем основании сразу множество функций. и до тех пор, пока сервис не вырождается в функцию, имеет смысл позаботиться о сохранности (и копировании) данных.
чтобы не быть голословным — простите, но что мешало разработчикам mysql написать нормальный парсер sql, который бы не требовал чудовищных
delimiter $$$
без которых очень сложно представить себе триггеры и хранимые процедуры.
или, допустим кодировку клиента. почему–то нельзя было сделать это менее мудацким образом, чем set names или DBI:mysql:database=db;mysql_read_default_group=perl;mysql_read_default_file={$root}/etc/my.cnf
а давайте еще посмотрим на то, что происходит с dbh после возникновения ошибки в mysql…
не буду холиварить, но как–то немного необъективно
тем не менее, проверять файлы таким образом — все равно ужасно. потому что на каждую генерацию страницы с ссылками на внешние ресурсы будет затрачено очень большое количество синхронных соединений. и времени тоже. в качестве примера можно привести пример такого рода: проверяется наличие файла на сервере, у которого очередь на i/o очень велика. тогда пока вы не исчерпаете таймаут, ваш скрипт не отработает. а в силу того, что таймауты по умолчанию зачастую стоят одинаковые, пользователь тоже не увидит страницу
вы для проверки существования файла открываете два сокета, один настороне клиента, другой — на стороне сервера. при большом количестве таких запросов вы рискуете упереться во множество интересных ограничений.
кроме того, для проверки файла без его открытия есть команда stat. которая будет работать ощутимо быстрее любого из ваших способов. учите матчасть!
а для маркировки проводов к розеткам применяете уже ваши методы.
если вы не будете заморачиваться с «парадигмами», то поймете, что между языками программирования в большинстве вообще нет никакой разницы. просто местами отличаются реализации алгоритмов, а сами алгоритмы не меняются.
что же до практики — он не интегрируется в систему вообще. если собрать некую библиотеку (например gd) под macports, потом поставить GD модуль для perl и попытаться использовать GD под mod_perl2 (читай: встроенный апач2), то гарантирован SEGFAULT.
есть еще другая неприятность с апачем. по умолчанию в 10.5 это universal binary для 4 архитектур. в моей системе он выполняется в режиме 64bit. а большинство библиотек в macports собирается только для 32bit. дальше рассказывать?
«Говорите какие-то глупости, о чем вообще не было написано.»
«Релиз-кандидат – это конечный монолитный продукт, в который нельзя вносить изменения. Если необходимо исправить ошибки, доработать функционал – необходимо начинать с начала и делать нового кандидата.»
«Чтобы делать quick-fix, нужно еще найти корень зла, на что уйдет больше времени, чем сделать мгновенный откат до предыдущей версии — переключить контекст веб-сервера на предыдущий релиз.»
всегда есть ситуации, когда типографическая ошибка или неверное условие работают правильно до тех пор, пока не встретится условие, вскрывающее проблему. по этому принципу работают же и sql инъекции. для множества таких ситуаций есть возможность быстро исправить ситуацию. и нужно иметь возможность быстро ее исправить.
«Гораздо круче все застопить, запустить новый процесс и посмотреть что получится — заведется или не заведется?»
если мы говорим о небольшом проекте с кучей обновляемых зависимостей — да. такое делать с большими проектами просто невозможно — они изначально сегментированы. ну и создателям и разработчикам больших проектов неинтересен ваш пост — они уже столкнулись со всем.
«Расскажите об этом ребятам из любого высоконагруженного проекта (Яндекс, Рамблер, РБК). Подсчитывать бабло и смеятся будем все вместе.»
да, давайте посмеемся. я работал в яндексе и выкладывал код на главную страницу яндекса. яндекс, рбк, фотофайл и тому подобные сервисы сильно вырождены и сегментированы — они выполняют одну функцию и на нее заточены. большинство сетевых мультисервисов имеют в своем основании сразу множество функций. и до тех пор, пока сервис не вырождается в функцию, имеет смысл позаботиться о сохранности (и копировании) данных.