В блоге для веб-мастеров инженеры Google подготовили и выложили два руководства разной степени сложности для тех, кто еще не знаком с базовыми методами оптимизации под поисковую машину Google.

Надо сразу сказать, что первое руководство действительно для новичков — профессионалы вряд ли обнаружат там нечто секретное и таинственное. Любопытно только то, что в Google не поленились и подготовили соответствующий одностраничный PDF-документ сразу в 13 языковых редакциях, включая и русский (английская версия). При этом документ (А4) выглядит визуально привлекательно и информативно, так что его можно распечатать и повесить в офисе, если вдруг возникнет необходимость в напоминании банальностей.

Второй документ более серьезного уровня и уже только на английском языке. Он довольно подробно и с примерами описывает различные «best practices» вроде создания уникальных заголовков веб-страниц, заполнения мета-тегов или улучшения структуры URL. Забрать документ можно отсюда.

«Что? Стивен Кинг „Как писать программный код“ ?! Нет такой книги! Да он вообще не программист ни разу!».
Да, так и есть. Тем не менее — книга с таким содержанием у него есть. Хотя он и не думал, что пишет её об этом. Хотя в результате написал. Хотя, наверное, и не знает об этом. О чём же я тут рассуждаю? О недавно прочитанной мною прекрасной книге «Как писать книги» (англ. — «On Writing»).

Кинг писал её как опытный писатель для писателей начинающих. Однако в результате у него получилась книга, рассказывающая не только как писать именно фантастическую литературу, но и том как писать вообще что угодно — в том числе и программный код. Прочитав за последние пару лет два десятка основных книг-икон современной программной индустрии (ну знаете, все эти «рефакторинги», «паттерны», «чистые и совершенные коды» и т.д.) я могу утверждать, что этой книге Кинга вполне себе место среди них, причём не на последнем месте. Дальше будет пару примеров (и как результат — спойлеров), поэтому самым правильным будет не продолжать читать статью, а пойти и прочитать саму книгу. Потом можете вернуться и сравнить свои выводы с моими. Ну а если времени на книгу у вас нет — под катом выдержки и выводы.

Когда весь интернет пестрит холиварами на тему «SSD ненадежны» и «SSD настолько быстрые, что я больше никогда не буду работать с HDD», думаю самое время внести немного ясности в то море противоречевой информации о самих SSD и о настройке Windows для работы с ними.

Кто заинтересовался, прошу под кат.

^{Cравните: популярный новостной сайт на Западе и в Китае}

Я уже неоднократно писал на Хабре о специфике китайского интернета, так в прошлой статье мы затронули покупку хостинга в Китае, а сегодня предлагаю рассмотреть особенности китайского веб-дизайна и их истоки.

Итак, как же можно связаться с ровером, находящимся на Марсе? Вдумайтесь — даже когда Марс находится на наименьшем расстоянии от Земли, сигналу нужно преодолеть пятьдесят пять миллионов километров! Это действительно огромное расстояние. Но как же маленькому, одинокому марсоходу удается передавать свои научные данные и прекрасные полноцветные изображения так далеко и в таком количестве? В самом первом приближении, это выглядит примерно вот так (я очень старался, правда):

Уважаемые коллеги,
в особенности те, кто занимается рекламным бизнесом в Интернете. Все чаще стал возникать вопрос об ответственности рекламных сетей за сотрудничество с сайтами, нарушающими авторские права. Этот вопрос инициирован крупнейшими правообладателями и площадками типа Google, а также аффилированными с ними правозащитными организациями и преследует цель убрать с рынка конкурентов, которые мало того, что приводят к недополученным прибылям для кино-и аудиостудий, так и привлекают к себе значительное количество трафика.
В стремлении лишить площадки, размещающие контрафактный контент прибылей, защитники авторского права решили выбить из-под них финансовый базис.
Первой крупной ласточкой (не считая дела megaupload) считает решение PayPal об отказе в работе с пиратами.
В настоящее время тенденция повернулась в сторону борьбы с иным источником благосостояния торрентов и файлхостингов — рекламные агентства. Об этом чуть подробнее я расскажу ниже, а также приведу небольшой обзор судебной практики.

Когда начинающие (или продолжающие) «радиолюбители» наигрались со светодиодами и устали поворачивать сервы в различные положения, некоторые из них начинают прикладывать полученные знания к обычной бытовой сфере.
Как правило, это применение находится в двух областях — автомобиль или дом.
«Тюнить» авто лично мне как-то не интересно, а вот сделать собственное жилье чуточку «умнее» и комфортнее — достойный выбор.

Не смотря на развитие, внедрение новых стандартов и плюшек в браузерах, у нет единых стандартов, как отображать элемент /> по умолчанию. Более того, у этого элемента нет атрибутов, позволяющих его в какой-то мере стилизовать.
Из-за необходимости привести это поле формы к единому виду во всех браузерах и «вписать» в разработанный дизайн, после поисков и анализа материалов в интернете был разработан метод замены вида поля формы на html+css, и js для расширения функциональности.

Как по умолчанию выглядит это поле?

Раньше я как-то не стремился глубоко изучать jQuery, поскольку работаю в основном с back-end. Однако самоучитель TRYjQuery, ссылка на который пришла в недавнем письме от CodeSchool, вызвал интерес с первых кадров.

На днях получили письмо из РОСКОМНАДЗОРа с сообщением о незаконности выполнения требований компании Спамхаус (SPAMHAUS) в России. Как правило они требуют отключать веб сайты, снять делигирование доменов, блокировать IP адрес или отключить сети IP адресов, т.е всячески нарушать условия предоставления услуг связи в РФ. Данные требования обычно выполняются провайдером под угрозой добавления всех его IP-адресов в черные списки.

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

Для разработчиков мобильных приложений существует много сервисов и веб-инструментов. Продвинутые компании и разработчики-одиночки знакомы со всеми этими сервисами не понаслышке. А вот новичок может запутаться и сделать неправильный выбор. Перейти на другой сервис можно без проблем, но ведь классно с самого начала пользоваться лучшим и удобным.

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

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

Не так уж и давно наличие адаптивного или мобильного сайта стало не трендом, а реальной необходимостью — трафик с устройств продолжает расти, а пользователи уже начинают отказываться от больших компьютеров в пользу смартфонов и планшетов. Для создания таких сайтов сейчас, в основном, используются три метода: адаптивная верстка, разработка отдельной мобильной версии и RESS. Johan Johansson опубликовал сравнение этих методов, перевод которого мы и представляем вашему вниманию. Под катом много текста и картинок.

Потребность

Как вы относитесь к бюрократии? Мне кажется, что почти у каждого из нас сразу возникает ассоциативный ряд «дороги», «дураки» и прочие исконно русские беды. И я был не исключением, пока не стал кем-то вроде завхоза в нашем небольшом коллективе.
Вдруг внезапно оказалось, что с увеличением числа «инвентарных единиц», будь то системный блок, монитор, принтер или кофемашина, потребность в учёте возникает сама собой. А если есть потребность, нужно искать максимально эффективное решение. Своим решением я хотел бы поделиться с вами.

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

Когда-то я собрала набор простых правил, которые помогают избежать 80% самых распространенных ошибок, касающихся построения интерфейсов. Решила расшарить их для хабрасообщества.
Кому интересно — добро пожаловать под кат.

Плагин Chosen создан для оформления красивых и удобных выпадающих списков с помощью jQuery и Prototype. Для установки плагина достаточно просто скачать файлы и прописать одну строчку:

$(".chzn-select").chosen()

(версия для jQuery)

По умолчанию в Chosen вместо длинного текстового списка предлагается поле, по нажатию на которое появляется список. Поддерживается автодополнение ввода, выбор нескольких пунктов меню, элемент optgroup и др. Выглядит вполне нативно. В общем, лучше один раз увидеть.

Поскольку Chosen заменяет стандартный элемент HTML, то не нужно беспокоиться, как он работает с браузерами без поддержки JavaScript. Также не нужно ничего менять в бэкенде: формы сабмиттятся как обычно, изменения только в пользовательском интерфейсе.

Некоторые форки:
Chosen для MooTools
Модуль Chosen для Drupal 7

Кто виноват?

Одна из часто встающих задач при разработке web-проектов — пустить пользователя на сайт без ввода логина и пароля, при этом авторизовав его.

Вот некоторые примеры таких ситуаций:

• Ссылка на активацию аккаунта только что зарегистрированным пользователем.
• Ссылка на восстановление пароля.
• Приглашение (возвращение) на сайт пользователя, который давно не заходил.

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

Здравствуй, мой любознательный %username%!

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

Привет, хабр. Сегодня я хочу поговорить о проблеме, с которой сталкивается абсолютное большинство молодых студий и агентств (и не только молодых, на самом деле) – про оправдание стоимости разработки интернет-проекта перед заказчиком и защиту от демпинга со стороны конкурентов. Надеюсь, эта информация найдет свое практическое применение и поможет вам создавать проекты по достойной цене.

Расчет себестоимости

Говоря о стоимости создания сайта, начать необходимо с определения его внутренней себестоимости в самой компании. До сих пор многие студии работают по фиксированным тарифам (сайт-визитка – XXX рублей, интернет-магазин – YYY и т.п.). Но, так или иначе, все агентства продают время своих сотрудников, и определение себестоимости должно отталкиваться именно от этого фактора.

Заказчик покупает время производящих сотрудников (дизайнеров, разработчиков, специалистов по вносу контента и пр.). Он не готов платить за время PR-менеджера, бухгалтера, уборщицы. Поэтому расчетная смета на проект отталкивается, как правило, именно от стоимости часов «производящих ресурсов».

Посмотрим, какую долю эти ресурсы занимают в общем пуле трат компании. Для небольшой веб-студии (специализирующейся на разработке, а не на рекламе – там закупочные бюджеты и немного другое распределение) из 15 человек распределение статей расходов, как правило, выглядит так:

• ФОТ сотрудников – 50%
• — Производящие ресурсы (30%)
• — Менеджеры, обслуживающий и административный персонал (20%)
• Условно-постоянные расходы – аренда офиса, канцелярка, расходники, еда, техника и пр. – 15%
• Налоги – 20%
• Маркетинг и реклама – 15%

О раскрутке на Facebook’е русскоязычными специалистами по SMM (или просто людьми, которые с этим столкнулись) написаны уже, пожалуй, целые талмуды. Но есть ли польза от этого? Сотни статей пересказывают одно и то же: пригласите друзей, закажите рекламу, купите пару тысяч ботов… Многие из расхожих рекомендаций совершенно неэффективны на практике. И российские компании очень редко могут похвастаться активной социальной жизнью в Facebook-сообществе.



Мы хотим рассказать о своём опыте Facebook-раскрутки. Обратите внимание на то, что мы производим мобильные приложения для детей (а не приложения для самого Facebook’а), и это накладывает определённый отпечаток на наши методы, которыми мы пользуемся.

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

Сразу скажу, что существуют такие web-приложения, которые лишены указанных ниже недостатков (например, Gmail, Хабрахабр). Но это — счастливые исключения, лишь подтверждающие правила.

1. Трудность навигации

Прежде всего, состояние. Тот, кто читал «Психбольницу в руках пациентов» Купера, знает, о чем речь. Складным ножом легко пользоваться потому, что у него всего два состояния: раскрыт и сложен. А в случае же с сайтом вы имеете очень большое количество состояний. И если к неопределенности в плане ссылок мозг еще привыкает со временем — пользователь знает, что он находится на одной странице, и всего его действия ограничены ею одной, что сказывается на относительной легкости моделировании различных состояний по страницам — то с аяксом такого не происходит.


Довольная Гаечка наконец-то нашла нормальный ajax-сайт!