лучше использовать реализацию через curl или fopen. Так как можно указать больше отправляемых параметров. Допустим некоторые сайты не отдают контент если не получен заголовок «User-Agent».
Согласен. Ну тогда может методом от противного?: при регистрации можно просто спросить «Любите сложные пароли?»(да|нет). И наградить это поле тултипом с подробным объяснением. Секретарша не будет читать тултип и просто выберет «нет», а гик прочитает и будет проинформирован.
Абсолютно верно, я имел ввиду «Привет». А ошибку я сделал специально. Гугл вместо «Привет» советует «Превед». Что меня и удивило. По видимому «превед» используется чаще в электронных просторах
То что вы описали это некоторые пункты «Белого СЕО». И вы абсолютно правы — белое сео приносит больше репутации, постоянных посетителей, больше рекламодателей и т. д.
Но не стоит так категорично относится к «Черному СЕО».
Черному СЕО — как правило нужно на начальном этапе. Конечно имеет меньшую стабильность, но разовый приход денег в большинстве случаев больше.
Можно дать пользователю самому выбрать, так как пользователю виднее будут взламывать его аккаунт или нет. Допустим при регистрации или в настройках пользователя поставить галочки «использовать регистро-независимый ввод пароля», «языково-независимый ввод пароля».
Странно что фреймворк высокого уровня реализовал джоины таким образом. Зачем менять простенькую строку «INNER JOIN markers_tags MarkersTag ON (MarkersTag.marker_id = Marker.id) » на довольно объемную конструкцию типа
array('joins' => array(
array(
'table' => 'markers_tags',
'alias' => 'MarkersTag',
'type' => 'inner',
'foreignKey' => false,
'conditions'=> array('MarkersTag.marker_id = Marker.id')
)…
Если уж ООП пытаемся использовать — то какого хрена используются массивы? — можно же через объекты реализовать, и phpdoc поможет с подсказками.
Например как то так:
array('joins' => DB_Joins_Helper::Add('markers_tags')
->Alias('MarkersTag')
->Type('inner')
->foreignKey(false)
->Conditions( array('MarkersTag.marker_id = Marker.id')),
…
Желание изучить есть. Но вот беда — пока нет реальной задачи, изучить ту или иную либу/фреймворк досканально(на практике) не представляется возможным. Изучать приходится только в том случае когда в команде принято решение использовать определенный фреймворк. Но вот переход на новый фреймворк — проблема/не выгодно, риск/трата времени на изучение. Именно эти причины и не позволяют изучить досконально эти все проекты.
Изучил в свое время ExtJs(было решено командой) — все хорошо, но на практике пришлось отказаться потому что делать изменения в дизайне компонентов превращалось из 3-5 часовой в 1-2 дневную работу. ExtJs — идеально подходит для организации админки или проектов где дизайн предполагается менять не часто. После этого мы не используем мощные либы, ибо jQuery и его набор расширений хватает с головой.
имхо: тягать либу шаблонизатора от проекта к проекту нет смысла. при использования шаблонизатора приходится переживать чтобы ничего не накрылось при очередном апдейте шаблонизатора. Пользуюсь встроенным php шаблонизатором.
разве вы не знакомы с извращениями как верстальщики пытаются прикрепить footer к нижнему краю окна. Надеюсь извращениями такого рода не придется больше заниматься при использовании блока footer
ну конечно, и будет вызываться стандартное убогое алерт-окно. имхо здесь они должны дополнительно внедрить способ перегрузки функций валидации или способ назначения существующего дива/блока вместо стандартного окна. Ну в идеальном случае должен появиться тег <alert-window> со всеми нужными под-блоками типа header>title|right|left, content>right|left,footer>right/left, и чтобы это все добро можно было управлять из css…
мысль пошла дальше…
имхо: в html5 не помешало бы внедрить систему переопределения вида этих стандартных диалоговых окошек и перегрузки функция для их обслуживания.
www.google.ru/search?hl=ru&newwindow=1&q=%D0%BF%D1%80%D0%B8%D0%B2%D0%B5%D0%B4&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=&aq=f&oq=
Но не стоит так категорично относится к «Черному СЕО».
Черному СЕО — как правило нужно на начальном этапе. Конечно имеет меньшую стабильность, но разовый приход денег в большинстве случаев больше.
array('joins' => array(
array(
'table' => 'markers_tags',
'alias' => 'MarkersTag',
'type' => 'inner',
'foreignKey' => false,
'conditions'=> array('MarkersTag.marker_id = Marker.id')
)…
Если уж ООП пытаемся использовать — то какого хрена используются массивы? — можно же через объекты реализовать, и phpdoc поможет с подсказками.
Например как то так:
array('joins' => DB_Joins_Helper::Add('markers_tags')
->Alias('MarkersTag')
->Type('inner')
->foreignKey(false)
->Conditions( array('MarkersTag.marker_id = Marker.id')),
…
другими словами: «говорите ли вы „спасибо“ тем кто отправил к вам клиента?». вот тогда и офлайникам станет ясно.
ну а «спасибо» каждый делает по своему — тоже своего рода плата.
Изучил в свое время ExtJs(было решено командой) — все хорошо, но на практике пришлось отказаться потому что делать изменения в дизайне компонентов превращалось из 3-5 часовой в 1-2 дневную работу. ExtJs — идеально подходит для организации админки или проектов где дизайн предполагается менять не часто. После этого мы не используем мощные либы, ибо jQuery и его набор расширений хватает с головой.
мысль пошла дальше…
имхо: в html5 не помешало бы внедрить систему переопределения вида этих стандартных диалоговых окошек и перегрузки функция для их обслуживания.