И так VeniVidi запустил систему рекомендаций. В основе алгоритма — оценки которые выставляют пользователи. Сейчас вы можете оценить любую страну, город, область или отель по 17ти параметрам. Для оценок не нужно регистрироваться и их выставление я постарался сделать максимально ненавязчивым.

Прочитав статью 7 критических ошибок при приеме заказа на изготовление сайта, не могу не ответить на явные перекосы.

Ответ на первый пункт:

Согласен, заказчик почти никогда не бывает компетентен в вопросах написания ТЗ, определения целей и задач и т.п. При этом потенциальный клиент обычно очень удивляется, когда за ТЗ надо платить. «Как, вы не хотите инвестировать в наше сотрудничество?» — заявил один несостоявшийся заказчик. На что я заметил, что ROI таких инвестиций будет неадекватно низким. Человек хотел интернет-магазин по смешной цене (сам позвонил, сам назвал цену), а еще хотел «подробное ТЗ» бесплатно. Ага, так вот разбежался и «проинвестировал» минимум две недели работы.

В сети доступно масса документации по языку XSL. Данный раздел не претендует на роль документации по языку, а лишь кратко, по шагам объясняет, как создать свой XSLT-шаблон.

Описанная ниже схема успешно мною используется уже более 3 лет. По началу я к XSLT относился с большой опаской (особенно, когда разбирал чужие исходники), однако однажды поняв, что к чему, уже не представляю, как без него можно работать.

Когда вы принимаете решение создать сайт, перед вами возникает ряд проблем, связанных обычно с вопросом — а что именно нужно делать, как и в каком порядке?

Если у вас уже есть функционирующий сайт, который вас чем-то не устраивает, можно считать, что вам повезло — у вас есть бесценный опыт, который можно проанализировать, оценить достоинства и недостатки старого сайта и сформулировать пожелания к новому. Если же вы заказываете сайт впервые, вам будет немного сложнее. Однако в любом случае лучше иметь под рукой определенный план действий, действуя по которому вы сможете получить действительно тот результат, который вам нужен.

Приветствую вас, уважаемые читатели! Возможно, несколько нескромно, но позволю себе обьявить, что далее будет самый первый в Рунете обзор и описание практического применения недавно открытого Google AJAX Language API для доступа с приложений на JavaScript к сервису переводов. Везде я видел пока только анонсы и попытки проанализировать, чем же это может обернутся для разработчиков и пользователей, но именно руководства по встраиванию в свой сайт или проект еще не читал, поэтому решил самостоятельно разобраться и написать.

И так, сначала общая информация. Как известно, у компании Google есть сервис переводов, который умеет переводить тексты на более чем десятке языков. Всего пар переводов есть намного больше, но для некоторых языков доступны только переводы на один-два языка, для других, например, английского — на множество. Раньше вы могли использовать этот сервис для переводов веб-страниц на лету, или перевода отдельных слов и предложений в браузере, но вот дистанционный доступ к сервису при помощи AJAX-а — это стало возможно только на днях с открытием соответствующего API и размещения примеров кода.

API включает в себя функции автоматического определения языка исходного текста, и, собственно сам перевод. Поддерживается пока тринадцать разных языков и двадцать девять вариантов перевода. К сожалению, русский поддерживается только в виде пары Russian <> English, то есть, перевод с русского на английский и обратно, а самое большое число переводов конечно же, для английского. Впрочем, обещают в дальнейшем пополнять возможности переводов, так что не отчаивайтесь.

Суть проблемы

Возможность пользователя ввести оооочень длинное слово без пробелов, и тем самым «взорвать» layout — это старая проблема. Вот так она решается на Хабре.

Гуглил, нашел много разных вариантов, но ни один не удовлетворял простым условиям:
— Легкость установки. Простота настройки (не более 4х часов с момента начала чтения документации).
— Поддержка русской морфологии. Как плюс — английской.
— Возможность индексации по Веб.
— Выдача результатов по релевантности. Хорошая ранжировка по релевантности

Risearch.org — хорошая, полная версия на Перле и платая. MnogoSearch — очень громоздкая в настройке, мне столько опций не нужно. В ряде других вариантов — простые стеммеры, либо вообще отсутсвие любой поддержки русского языка. Ладно, пусть будет даже стеммер, но у результатов должна быть высокая релевантность.

Как дать пользователю возможность проверить свой пароль на строгость и взломоустойчивость?

Такой вопрос возникает в последнее время всё чаще, потому нарыл немного вариантов решения вопроса.

Для начала представлюсь. Зовут меня Евгений (Eugene Spearance) — автор небезызвестного сайта и технологии Типограф.
Просиживая вечера в сладком безделии решил написать несколько статей посвящённых теме компьютерной вёрстки, раскрыть секреты собственного Типографа, а так же поделиться кое-какими соображениями о будущем развитии типографики.

Многие из нас собирали компьютер сами, из комплектующих. Дело не сложное, соединить с десяток шлейфов, да завинтить столько же винтиков. Но мало кто сталкивался с самостоятельной сборкой серверов, причем не обычных а в промышленном формате под стойку 19 дюймов. В этом небольшом обзоре я опишу свой опыт сборки такого сервера, постараюсь показать что это не сложно, и остановлюсь на главных моментах, на что нужно смотреть. На написание этого обзора меня толкнуло то, что информации о сборке rack 19’ серверов в рунете очень мало, и приходилось её искать буквально по крупицам.

Сегодня очень долго выяснял причину, почему после того как я делаю MySQL запрос, в котором обращаюсь к хранимой процедуре (stored procedure) (PHP 5, MySQL 5, mysqli driver)

CALL procedureName()

то следующий за ним запрос не выполняется, а mysqli_error возвращает ошибку

В попытках создать что-то инновационное в интернет-проектах мы вынуждены отходить от стандартов, которые долгое время формировали привычки пользователей. Тут будет не лишним подумать над свежим решением и этой проблемы.

Возникла идея написать статью по разработке веб-приложений на основе собственного (небольшой команды меньше 10 человек) опыта. Тезисы:

1. Набросок интерфейса
— что такое набросок интерфейса и зачем он нужен;
— блокнот и ручка против Visio и InDesign;
— участие заказчика в проектировании интерфейса;
2. Интерфейс
— интерфейс определяет модель;
— где заканчивается интерфейс и начинается дизайн;
— разработка: от важного — к более общему;
— почему мы перестали бояться изменений;
3. Программирование
— программирование с готовым интерфейсом;
— зачем нужен настоящий контент;
4. Дизайн
— почему макулатуры стало меньше;
— почему работать с дизайнером стало проще;
5. Готовый проект

Интересна ли кому-нибудь подобного рода публикация? Каким образом лучше подавать информацию: по частям (проще обсуждать) либо всю статью целиком (удобней читать и проще воспринимать)?

P.S. «Наша методика» значит «мы ее используем», а не «мы ее придумали» :)

bendingunit22 и HabraCurillo