У меня прошла капча только когда я отключил AdMuncher (блокиратор рекламы, баннеров и т.п.). Видимо, он что-то напортачил в коде страницы, из-за чего мне постоянно выдавался текст о неправильном вводе кода с картинки.
ИМХО в этом и соль. Он просто хотел сказать что писать по-русски "Гугль" это бОльший идиотизм, чем писать по-русски "Микрософт".
А цвета Гугла и засечка и майкрософтовский шрифт - чтобы было понятно что речь идет об официальных логотипах всем известных компаний.
формально - да. неформально - так и любой другой курьер тоже никакой ответственности не несет. дай бог если фирма, которая курьером рулит несла ответственность хотя бы юридически. на практике же все понимают - важный документ - доставь его сам лично в руки или через коммерческие службы доставок. а если ты отдаешь документ непонятному курьеру - риск уже есть независимо от возраста курьера.
это конечно ненормально, но пока это так.
Тоже не вижу никаких проблем с дитем. Сам работаю с 12 лет, причем занимались мы всякой работой - и по тайге бревна по снегу таскали, и елки в лесу рубили по городскому заказу, и на лесопосадках лиственницей болотистые участки засаживали. Платили нам честно, первая зарплата была как щас помню - 141 рубль (очень приличные бабки). Но работали же не из-под палки. Просто было интересно. И мне кажется что к труду как раз в этом возрасте нужно приучаться. Пылесос и швабра - само собой, но этого не всегда достаточно, тем более что лично мне дома пылесосить в этом возрасте всегда было неинтересно (потому что заставляли), а вот когда мы пол мыли в огромной оранжерее с утра - совсем другое дело было.
А насчет уважения к клиенту - не думаю, что малый бизнес, да и средний зачастую тоже может себе позволить разборчивость в курьерах. Про презентабельность вообще не говорю. К нам кто только документы не приносит - и с перегаром за 3 метра бывали, и скандалисты, обвиняющие нас в том что мы неудачно расположены и добраться тяжело. Разве что коммерческие службы типа ПониХпресс или СПСР (с ДХЛ не сталкивался) приличных людей присылают. Но от них тоже нет никаких особенных положительных эмоций если честно. Жалко здоровых мужиков видеть в роли разносчиков почты.
В общем, детская активность - есть хорошо. Пусть учатся работать, даже если ножками. Кто позже, кто раньше.
SQLite тоже в свое время смотрел, ходил вокруг да около. Но его ж нужно ставить на хостинге отдельно, он обычно у хостеров не присутствует, и это с точки зрения распространенности решения - проблема. Подскажите, что в нем интересного, пожалуйста, если есть опыт практической работы?
Yurecm, "Twilight CMS" не использует MySQL, в ней свой механизм работы с данными. Она не бесплатная (for free только для некоммерческих проектов), поэтому вряд ли вам подойдет.
Самые распространенные претензии к системам без СУБД - низкое быстродействие, низкая надежность и что на них нельзя делать большие сайты или интернет-проекты. На самом деле это на 99% зависит от реализации слоя, который работает с данными.
Исходя из реального опыта работы с такими CMS вот вам мои аргументы за и против такого класса систем (кто может - пусть дополняет, я не все написал):
Плюсы использования CMS без СУБД типа MySQL:
- проще установка сайта на хостинг
- проще перенос данных с сервера разработки на боевой и обратно
- проще и быстрее бэкап данных
- кроссплатформенность (будет работать и на виртуальном NT хостинге где как правило нет MySQL)
- при определенных технических решениях сайт можно править непосредственно по FTP (если данные в файлах имеют "текстовый" а не "бинарный" вид и не зашифрованы)
- на хостингах с большим количеством сайтов и разделяемым MySQL система будет обыгрывать по скорости все остальные сайты если СУБД будет перегружена, т.к. сайт будет от независим от СУБД
- разработчик CMS может более гибко делить уровень данных на подуровни и организовывать кэширование обработанных данных в памяти или на диске, что в целом повышает производительность системы.
- в ряде случаев разработчик CMS может применять более точно соответствующие задаче алгоритмы обработки данных, не используя обязательный при работе с MySQL механизм реляционных запросов. то есть возможно только за счет применения частных специализированных решений многократно превосходить по быстродействию систему на MySQL
- системы без MySQL более безопасны в плане взлома школьниками, поскольку в них нет возможности произвести SQL-injection - бич современных SQL-based сайтов.
Идеологический плюс состоит в том, что реляционные СУБД изначально не предназначены для хранения HTML кода страниц или древовидных структур, поэтому в большинстве случаев система попросту не обязана использовать MySQL для хранения веб данных и не обязана использовать "навязанные" разработчику реляционные механизмы для любой простейшей операции.
Спорные, или малозначимые плюсы систем без СУБД:
- Во ряде случаев более высокая скорость работы генератора страницы - открыть файл и прочитать его быстрее чем обратиться к таблице и выбрать запись. Разница с MySQL вариантом сводится на нет использованием нормального механизма кэширования готовых страниц.
- Низкие требования к хостингу. Хотя сейчас мало UNIX хостеров не предлагают MySQL.
Минусы систем управления сайтом без СУБД типа MySQL:
- как правило запись данных в CMS без СУБД медленнее чем в системах с СУБД.
- система при работе на виртуальном хостинге при операциях с данными будет есть память из основного блока, отведенного приложению, а не из блока отведенного движку MySQL, который все время сидит в своей памяти. При низких лимитах памяти это может привести к ограничениям на максимальный размер данных с которыми может работать такой сайт "быстрее" чем для системы с СУБД.
- при прочих равных система без СУБД будет проигрывать системе с СУБД по ограничениям при работе с огромными количествами данных, поскольку СУБД может выполнять некоторые операции в фоне, в промежутках между запросами к сайту, а системы без СУБД могут делать их либо в течение CGI запроса. либо нужно настраивать некий внешний процесс типа CRON, что излишне усложняет систему и снижает надежность.
- несколько сложнее организовать взаимодействие с внешними системами (обмен данными), поскольку требуется описывать формат данных не в устоявщихся терминах таблиц, записей и полей. либо требуется писать свой слой абстракции данных.
- практически очень сложно чистить базу в автоматическом режиме от разного мусора, либо приходится тратить драгоценное время запроса на сервисные операции (что негативно может сказаться на производительности).
В целом если подытожить, то система без СУБД должна быть очень хорошо спроектирована и написана, чтобы учитывать блокировки файлов при одновременной работе нескольких пользователей, иметь скоростной механизм использования индексов, потреблять мало памяти при апдейтах данных и больших выборках из базы и делать еще много чего. Иначе есть вероятность потери данных и/или низкой производительности. Если все сделано на промышленном уровне - CMS без СУБД не во многом уступит системе с СУБД, а в части вещей её и превзойдет. Но конечно, написание такого движка работы с данными - по сути написание своей СУБД, что само по себе высший пилотаж.
Но это возможно.
PR4 с одной ссылкой на сайт? Дураков нет.
Скорее всего ТС что-то недоговаривает. Ни один нормальный работодатель не будет строить бывшему сотруднику подобные козни и пытаться его развести на какие-то смешные 1000 баксов с риском попасть на уголовную ответственность за вымогательство. Запись в трудовой про увольнение за прогулы должна быть подкреплена соответствующими документами, что тоже геморрой совершенно для работодателя лишний. Даже если сотрудник совсем не устраивает - от него тихо мирно избавляются.
Следовательно, либо сотрудник так всех достал или так всем нагадил + босс конторы был полный идиот и решил ему отомстить, либо вся эта история вообще вымышленная. Да и вообще, рассказы про то, что оптимизатор сидел в офисе с утра до вечера больше сказки венского леса напоминает.
ИМХО поисковики наоборот будут немного реже обходить страницы с URL второго вида, поскольку это страницы 3, 4, 5 уровня вложенности с точки зрения директорий на диске. А URL первого типа - первый уровень вложенности.
Но точных данных не имею, поэтому это только на уровне предположения.
Для этого у профессиональных тестировщиков сайтов обычно установлена нестандартная цветовая гамма для цвета элементов интерфейса винды, чтобы ловить такие ошибки. И работать это будет на любом браузере, не только под ИЕ7.
