Andyceo's Words

StyleWorks: Premium-стили для Photoshop (Учебный пример)

andyceo — Tue, 14 Sep 2010 17:36:05 +0000

Приветствую, дорогие читатели! Меня впечатлила одна недавняя статья на drupal.org о разработке сайта по продаже кое-каких примочек к фотошопу. (На самом деле, меня впечатлило несколько статей, но об остальных я напишу позже, если вообще смогу выделить для этого время.) Вроде бы, ничего необычного в ней нет. Просто один человек, John Forsythe, решил, что "пришло время приложить свои навыки, как Drupal-разработчика, в запуске нового бизнеса в Интернете". Разумеется, своего бизнеса. И это правильно, я считаю! Пусть каждый Drupal-разработчик, будет иметь свой приносящий доход бизнес. А может, даже не один. Кого заинтересовал - читаем мой перевод этой статьи. Также хочу добавить, что перевел и некоторые показавшиеся мне толковыми комментарии к статье, что добавило статье живости и полезных сведений.

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

Спустя несколько месяцев разработки, родился StyleWorks. Сайт работает на Drupal 6, а также интегрируется с FastSpring для реализации электронной коммерции.

Проектирование сайта: Zen или не Дзен?

После сотен итераций дизайна в Photoshop, я, наконец, получил представление о том, чего хотел, и пришло время, чтобы оно ожило в Drupal. Но сперва нужно было сделать ключевое решение: начать с нуля, или использовать Zen?

Традиционно, я всегда делал свои дизайны "с нуля". Я что-то вроде наркомана по оптимизации, и люблю писать действительно легкий код (Раньше я был более категоричен в этом, чем сейчас. Правда, когда я писал DrupalModules.com, я избегал использования вещей вроде CCK, предпочитая вместо этого писать собственные модули). Поэтому, когда я впервые посмотрел на тему Zen несколько лет назад, мое первое впечатление было "блин, ты только посмотри на весь этот лишний код! Почему здесь так много стилей"? *Удалил*

С тех пор, Zen стала дико популярной, став темой № 1 на Drupal.org. Я всегда объяснял эту популярность растущей аудиторией не-разработчиков Drupal, но, услышав несколько положительных отзывов на недавней встрече Drupal-разработчиков, я решил дать Zen еще одну попытку.

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

Что я имею в виду под гибкостью? Вот пример:

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

Ясно, что я недооценил Zen.

Однако, гибкость Zen приходит благодаря нескольким компромиссам.

Если вы привыкли все стили класть в один длинный CSS файл, дзенский шквал в 30+ стилей может поначалу вас немного расстроить. Там отдельные CSS-файлы для практически всего (фоны, страницы, вкладки, формы, поля и т.д.). К счастью, для большинства из этих файлов редко возникает необходимость редактирования, так что фактическое количество стилей, которые вы будете править одновременно, ближе к 6, чем к 30.

Строгое разделение правил CSS в Zen является немного неэффективным для меня. Я не уверен, что есть реальная польза в разделении стилей фона и границ для одного DIV`а в два различных файла. С таким количеством файлов, может быть сложно отслеживать, какие правила в каком файле (я нашел, что Firebug будет очень полезным в этом отношении).

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

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

Выбор разметки

Так как стили слоев для Photoshop − это в первую очередь визуальный продукт, мне нужен макет, который может вместить большое количество изображений, в то же время оставляя место для описания продукта. Итак, я решил работать с простым двухколоночным макетом: изображения продуктов слева, описательный текст справа.

Вопрос только в том, как получить текст и изображения в отдельных столбцах. Я посмотрел на целый ряд различных решений для работы с разметкой, в том числе Panels и Composite Layout, но ни один из них не счел достаточно подходящим.

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

Вот тогда я и обнаружил модуль Nodes in Block.

Nodes in Block позволяет создавать специальные блоки, которые динамически отображают контент на основе текущего пути. Например, можно настроить один и тот же блок, чтобы он показывал опрос или рекламу, в зависимости от того, где пользователь находится на сайте. Контроль того, что проявляется в блоке, осуществляется с помощью настроек видимости для ноды (это очень похоже на стандартную настройку видимости блока).

Так что я создал тип контента для изображений продуктов, а другой тип контента для описания продуктов, и использовал Nodes in Block, чтобы получить их оба на одной странице (изображения в основной области контента, описания в боковой панели через блок). Это работало, но разделение продукта на две различных ноды далеко от идеала.

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

Заставить ноду отображаться два раза было достигнуто путем установки в ноде настройки видимости модуля "Nodes in Block" на свой собственный путь.

Структура нод

Благодаря решению использовать модуль Nodes in Block, я был в состоянии объединить изображения и описания продукта в общий тип содержания, названного "демо-версия продукта". Сам по себе этот тип контента является достаточно простым, опирается только на текст и файлы.

Текстовые поля:

Полное наименование
Краткое наименование
Подзаголовок
Короткое описание
Полное описание
Характеристики продукта
Цена
Ссылка на корзину

Файловые поля:

Изображение для краткого описания (файл)
Демо-изображения (файл)
Изображения текстур (файл)

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

Переопределение строк

При создании сайта, я заметил, что некоторые фрагменты текста необходимо будет повторить в нескольких различных местах по всему сайту. Описание того, что происходит после покупки, например, нужно будет показать в середине каждой странице продукта. Фраза "Загрузить сейчас" также повторяется во многих местах, но что, если я захочу изменить ее в дальнейшем?

Как правило, эти кусочки текста в конце разработки можно жестко запрограммировать в шаблонах, но я действительно хотел, чтобы они оставались редактируемыми в Drupal. Моим решением было использовать функцию Drupal t(), а также приятный маленький модуль, который называется String Overrides.

Теперь я просто включаю этот небольшой фрагмент кода, в мой шаблон ноды...

<?php t('after_purchase'); ?>

... и у меня есть описание, которое может быть мгновенное обновлено на всем сайте, непосредственно из Drupal.

Я подозреваю, что могут быть и другие (лучшие?) способы сделать это, но метод String Overrides был элегантен и его было быстро реализовать.

Установка системы электронной коммерции

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

Просматривая несколько малых бизнес-форумов, я все видел рекомендации по FastSpring, платформе электронной коммерции, которая обрабатывает все от приема кредитных карт к предоставлению загрузки файлов. Они даже позаботяться о сборе соответствующих налогов.

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

Интеграция корзины FastSpring с моим сайтом было легким. Я добавил ссылку "просмотреть корзину" в меню Primary Links и создал новое текстовое поле CCK для моих продуктов "ссылка на корзину". Поле "Ссылка на корзину" есть просто URL, которое контролирует, куда передается форма "добавить в корзину" (каждый продукт имеет различный целевой URL). Когда пользователь нажимает кнопку "Добавить в корзину", он направляется непосредственно на защищенный сервер FastSpring, где он может осуществить заказ, или продолжить покупки (в этом случае, они возвращаются на мой сайт).

Я все же еще новичок в FastSpring, но первый опыт прошел на удивление гладко.

Производительность: Жизнь с 512 МБ памяти

Поскольку это был сайт электронной торговли, я чувствовал, что важно, чтобы он работал на своей собственной (виртуальной) машине. В настоящее время сайт размещается на 512MB VPS, работает под Ubuntu 9.10.

512MB является довольно небольшим объемом памяти на сервере, так что правильно настроить систему было очень важно. Если серверу не хватает памяти, она начинает обращаться к файлу подкачки, эффективно убивая всю производительность.

Первым шагом было остановить Apache от создания слишком многих процессов. Вот ключевые настройки (я использую режим Prefork):

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 13
MaxRequestsPerChild 0
KeepAlive Off

С максимумом в 13 одновременных подключений, важно отключить поддержку подключения (KeepAlive), иначе посетители надолго застрянут в ожидании свободного слота во время пикового трафика.

Далее, я оптимизировал файл настроек MySQL, используя рекомендации от отличного скрипта-тюнера MySQL (отредактировано: Далин предлагает эту переделанную версию). Вот самое важное:

key_buffer = 32M
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 4M
query_cache_limit = 1M
query_cache_size = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
max_connections = 20
table_cache = 1024
skip-innodb

И наконец, я установил XCache, кешер байткода PHP, и настроил его так:

xcache.size = 16M
xcache.count = 1
xcache.slots = 8K

Кроме того, я включил агрессивное кэширование страниц в Drupal, кэширование блоков, сжатие страниц, CSS-оптимизацию, и JS-минификацию через модуль JavaScript Aggregator.

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

Список модулей

Из-за ограничений памяти 512MB, я старался держать количество установленных модулей как можно ниже. В конце концов, мне удалось получить список до 17 именно этих (некоторые из которых в настоящее время отключены, такие, как Devel).

Связанные с содержанием:

Content (CCK)
FileField
ImageField
Text (Part of CCK)
Nodes in Block
String Overrides
Insert
Token

SEO и производительность:

Global Redirect
Page Title
JavaScript Aggregator
Google Analytics

Средства разработчика:

Administration menu
Devel
Backup and Migrate
Database Logging
Update status

КОММЕНТАРИИ К СТАТЬЕ

adrianmak - 14 августа 2010 - 6:52: Можете ли вы рассказать больше о том, как использовать Nodes in Block, для разделения вывода различных полей ноды, в разные части страницы (это связано с регионами?)

JohnForsythe - 14 августа 2010 - 7:06: Главное, установить оператор if в вашем шаблоне ноды node-type.tpl.php. Мой код выглядит примерно так:

<?php // ### normal output ### ?>
<?php if (!$teaser && !isset($node->nodesinblock)): ?>
    <div class="content">
      <?php
        foreach($node->field_demoimages as $images) {
          print $images['view'];
        }
      ?>
      <div class="links">
        <?php print $node->field_demonode[0]['nid']; ?>
      </div>
    </div>
<?php // ### node-in-block output ### ?>
<?php elseif (!$teaser && isset($node->nodesinblock)): ?>
    <div class="content">
      <h1 class="title"><?php print l($node->field_shorttitle[0]['safe'], 'node/'.$nid);?></h1>
      <h2 class="subtitle"><?php print $node->field_subtitle[0]['safe']; ?></h2>
 
      <?php print $node->field_longtext[0]['view']; ?>
      <?php // (etc...) ?>
    </div>
<?php endif; ?>

Таким образом, в зависимости от того, установлена ли переменная $node->nodesinblock, мы печатаем различные поля CCK.

patcon - 15 августа 2010 - 1:04: Отличное учебное пособие, Джон! Не представлял, что модуль Nodes in Block может быть настолько универсален!

Есть одна мысль, однако: не рассматривал ли ты возможность использования модуля Display Suite, для избежания необходимости пользовательской переделки шаблонов? Nodes in Block интегрируется с Display Suite так, что он обеспечивает новый "режим построения" ("build mode") в разделе "Показать поля" ("Display fields") конкретного типа контента (в дополнение к стандартным RSS, Basic, Search и Token). Таким образом, вместо создания шаблона с условным отображением полей, проверяя $node->nodesinblock, вы можете просто скрыть некоторые поля в Content type > Display fields > Basic > Full node, и скрыть альтернативный набор полей в режиме построения Nodes in Block.

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

Эй, вы же упомянули, что любите простоту, так что я пойму, если вы намеренно избегали добавления нового модуля к проекту! Все же я думаю, это может помочь кому-то с другими потребностями :)

Diegen - 29 августа 2010 - 13:20: Привет.

Представления (Views) и несколько tpl смогли бы сделать это для вас? Я вовсе не говорю что мое решение лучше, я только любопытствую.

JohnForsythe - August 29, 2010 - 13:53: Есть много способов сделать это.

Конечно. Представления (Views), Панели (Panels), Composite Layout, Contemplates... Они все работают, с некоторыми небольшими доработками. Я смотрел на множество решений, но Nodes in Block поразил меня своей простотой. На самом деле, все это может быть сделано вообще только через CSS, не требуя каких-либо модулей. Каждое решение имеет свои преимущества и недостатки, компромиссы между мощностью, сложностью и гибкостью.

chx - August 14, 2010 - 07:05: Почему модуль Nodes in Block?

Свой модуль (с очень малым) количеством строк кода, мог бы это сделать, не так ли? Также, если уж вы хотите хорошо сэкономить память, отключите Devel и включайте только когда вы действительно нуждаетесь в нем, что на продакшене должно случаться редко.

JohnForsythe - August 14, 2010 - 07:17:

Свой модуль (с очень малым) количеством строк кода, мог бы это сделать, не так ли?

Nodes in Block небольшой модуль по сравнению с большинством других. Он требует всего несколько строк кода в шаблона с моей стороны, чтобы получить результат, который я хочу, и это экономит мне время написания и отладки своего собственного решения. В старое время, я бы, наверное, написал новый модуль просто чтобы увидеть, что я могу сделать в 70 строк то, что Nodes in Block делает в 700, но сейчас я доволен, оставляя работающее решение нетронутым.

Также, если уж вы хотите хорошо экономить памяти, отключите Devel и включайте только когда вы действительно нуждаетесь в нем, что на продакшене должно случаться редко.

Devel отключен, как я уже говорил:

(некоторые из которых в настоящее время отключены, такие, как Devel)

jurgenhaas - 15 августа 2010 - 6:49:

Спасибо John Forsythe за статью, действительно есть пара вещей, чему поучиться. Превосходно.

Все же есть один вопрос: рассматривали ли вы возможность использования модуля Boost? Я сам так сделал несколько месяцев назад и получил выдающееся повышение производительности. Это выглядит как очень надежное решение и делает потрясающую работу.

JohnForsythe - 16 августа 2010 - 21:57: Вот мой опыт работы с Boost:

Измеряя производительность сайта локально, Boost дал более чем вдвое высокую производительность, с 1100 запросов в секунду до 2700 запросов в секунду.

Однако, когда тестирование проходило с удаленного компьютера, производительность оставалась неизменной на уровне около 260 запросов в секунду.

Причина? При включенном агрессивном кэшировании в Drupal, время генерации страницы отлично держится около 10 мс. Даже если Boost будет в 10 раз быстрее, он сможет срезать лишь 9 мс от общего времени запроса.

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

themegarden.org - 16 августа 2010 - 9:13: Привет Джон, большая работа, поздравляем!

Каким провайдером VPS вы пользуетесь? Linode?

JohnForsythe - 16 августа 2010 - 20:27: Да, я начал с Linode 512, это хороший выбором для проектов, которые не очень подходят для виртуального хостинга. VPS.net также выглядит неплохо, но у меня еще не было времени для их изучения.

Stevo_0 - 24 августа 2010 - 4:05: Мне интересно узнать, почему вы не используете Ubercart, довольно простой в использовании, особенно для чего-то вроде продажи загружаемых файлов, и вы могли бы принимать заказы, используя только Paypal, чтобы не напрягать себя нахождением платежных шлюзов и т.д. Интересно посмотреть в сторону этой альтернативы. Каковы издержки выбора FastSpring?

JohnForsythe - 24 августа 2010 - 4:40: Я не люблю полагаться на PayPal, особенно для цифровых товаров. Я слышал слишком много ужасных историй. Они огромная компания, и у меня нет никаких рычагов влияния, если они решат вдруг заморозить мой аккаунт.

Основным бизнесом FastSpring является продажа цифровых товаров. Они работают с корзиной, биллингом, налогами, выполнением и т.д. Есть даже интеграция с Google Analytics E-commerce! Мне не нужно беспокоиться обо всем этом. Я просто загружаю свою продукцию, и все сделано. Чувствуется, что там гораздо меньше того, что может пойти не так. Но это всего лишь несколько недель, поэтому мы посмотрим.

Об экономии, они берут 5,9% плюс $1, или 8,9% (на выбор). Там нет платы за регистрацию, за наличие магазина и т.д.

altrugon - 24 августа 2010 - 19:35: О Zen

Zen это замечательная тема для использования в качестве основы, и это факт, что в настоящее время Zen 2.0 использует несколько CSS-файлов, чтобы сделать тему более гибкой и понятной.

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

Если никто не делает так при работе с PHP или HTML, почему мы должны позволять такое в CSS?

Во всяком случае, поздравляю вас с проектом, и вы можете быть уверены, что будете чувствовать себя все более комфортно с Zen, больше используя ее.

Оригинал: Case Study: StyleWorks Premium Photoshop Styles

Автор перевода: andyceo

PS: В FastSpring можно загрузить пользовательские CSS/XHTML шаблоны, чтобы сделать корзину более похожей на ваш сайт.

Мои доклады на несостоявшийся апрельский DrupalCamp 2010

andyceo — Thu, 15 Apr 2010 13:04:58 +0000

Всем привет. Жаль, конечно, что DrupalCamp перенесся. Но ничего не поделаешь. Вашему вниманию я представляю тезисы докладов, которые я мог бы прочитать на кемпе. Интересно было бы знать ваше мнение, что осветить подробнее, что - убрать (что неинтересно), что хотелось бы вам услышать.

По темам кратко:

Что такое корпоративный сайт: его цели, задачи, структура
Инсталляционные профили в Drupal 6.x
Недостатки Drupal 6.x. Баги и ошибки

Доклад на тему "Разработка корпоративных сайтов на Drupal 6.x"

Автор: Андреев Андрей Андреевич, andyceo@yandex.ru

Тезисы:

1. Что такое корпоративный сайт: его цели, задачи, структура.
1.1 Цели корпоративного сайта
1.2 Задачи, решаемые корпоративным сайтом
1.3 Возможная структура корпоративного сайта
2. Отображение структуры корпоративного сайта на архитектуру Drupal.
2.1 Архитектура Drupal
2.2 "Как сделать то или это в Drupal"
2.3 Выбор архитектурных решений для разработки сайта на Drupal (типовые решения часто встречающихся задач)
3. Разработка сайта
3.1 Из каких этапов будет состоять разработка сайта?
3.2 О чем надо помнить при разработке "работающего" решения (SEO-модули, разрешения для пользователей)
3.3 Программирование? Ну разве что совсем чуть-чуть :)
4. Заключение. Инсталляционные профили (тема следующего доклада).

Доклад на тему "Инсталляционные профили в Drupal 6.x"

Автор: Андреев Андрей Андреевич, andyceo@yandex.ru

Тезисы:

1. Введение. Обзор системы инсталляционных профилей
1.1 Структура и архитектура профилей. Хуки.
1.2 Drush Make
2. Недостатки текущей системы инсталляционных профилей.
2.1 Недостатки (большой объем кода, негибкость)
2.2 Недостатки модулей, используемых при установке (Devel Generate, Install Profile API, drupal_execute()). Описание недостатков и багов
2.3 Как настраивать сайт (модули) в текущей системе профилей?
3. Дальнейшее развитие системы инсталляционных профилей
3.1 Было бы здорово иметь предустановки, типов материалов, представлений, etc
3.2 Было бы здорово реализовать механизм наследования, как в темах
3.3 Объект? Да! Объект для инсталляционных профилей
4. Демонстрация работы объекта в инсталляционном профиле. (пока не уверен в этом пункте, т.к. объект находится в разработке. Непонятно, успею ли я его дописать до конференции)

Доклад на тему "Недостатки Drupal 6.x. Баги и ошибки"

(Название не окончательное, нужно будет заменить. Возможно, это блиц-доклад.)
Автор: Андреев Андрей Андреевич, andyceo@yandex.ru

Тезисы:

1. Обзор архитектуры Drupal и других систем
1.1 Архитектура Drupal
1.2 Альтернативные архитектуры CMS
1.3 Берем лучшее, избавляемся от худшего
2. Баги Drupal
2.1 Подробные описания багов пришлю несколько позже, они у меня выписаны, но сейчас листочка перед глазами нет.

Google Developer Day - 2009

andyceo — Thu, 12 Nov 2009 21:50:06 +0000

Дорогие друзья, 10 ноября 2009 года я побывал на Google Developer Day - 2009. Да, было очень интересно, множество прекрасных докладов (жаль, не на всех секциях удалось побывать), общение с разработчиками и с ведущими инженерами Google!

О впечатлениях напишу позже, и так, едва-едва нашел время черкнуть эту пару слов.

Дождались :) Наконец-то я разобрал свои записи и привел все в более-менее читабельный вид. С удовольствием предлагаю вашему вниманию свой отчет о посещении конференции Google Developer Day 2009, 10.11.2009, Moscow!

Итак, поехали. Вот фотография разворота моего бейджика:

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

Вот моя хронология:

09:20 - 11:00 Открытие конференции
11:00 - 12:00 HTML 5 и будущее Интернета (Tech Talk), Марк Пилгрим
12:00 - 13:00 Инструменты для вебмастеров, Елена Ковакина
12:30 - 14:30 ОБЕД (кормили вкусно)
14:00 - 15:00 Как заинтересовать посетителя, Чуи Трюэлла
15:00 - 16:00 Жадные алгоритмы и оптимизация ранжирования, Павел Карпович (Яндекс)
16:00 - 16:30 ПЕРЕРЫВ
16:30 - 17:30 Google Wave API, Вадим Герасимов
17:30 - 18:30 Венчурный капитал и инвестиции в стартапы
18:30 - 21:00 Общение :)

Открытие конференции

Замечательное и живое открытие. :)

Открытие вел Эрик Толоме, директор по менеджменту и маркетингу Google. Сначала он представил Марка Пилгрима, с докладом о HTML 5: Canvas, Video, GPS, Местоположение (показывали Firefox Share Location).

Затем говорилось о разработке веб-ориентированных приложений, о том, что каждое такое приложение должно иметь Database + AppCache для своей успешной работы как в онлайне, так и в оффлайне.

Очень интересный, но к сожалению, малопонятный мне доклад о Google Web Toolkit, Google App Engine с примерами работающего кода, написанного прямо за трибуной. Python я только планирую начать изучать, и крупных проектов с использованием этих технологий пока не делаю, поэтому была понятна только суть.

Рассказ о браузерах вообще, и Google Chrome в частности, операционной системе Chrome OS и мобильных устройствах, также запал мне в душу, благодаря одной фразе о том, что 2009 год - революционный для мобильных устройств, т.к. именно в этом году число людей, впервые пришедших в интернет с мобильных устройств, превысило число таковых на десктоп-системах. Есть о чем задуматься и куда направлять стопы бизнесу.

Затем Ларс Расмуссен и Стефани Хэннон презентовали Google Wave, замечательное Real-Time шоу, с показом работающей технологии, с видеодемонстрацией и шутками :)

А Чуи Трюэлла все о своем, о разного сорта API от Google: GeoAPI, Analytic API и прочие, прочие, прочие )

Затем выступил Евгений Савельев, основатель сервиса Wikimapia. Ему ассистировал его напарник, к сожалению имя его забыл. Коротко перескажу их историю, т.к. выглядит она интересно. Сначала им пришла идея, после того как на Flickr они увидели фотографию с высоты птичьего полета, с характерными для фоток "рамками" - отмеченными и подписанными зданиями и площадями, знаете, как порой выделяют человека на фото. Несколько дней ребята потратили на составление ТЗ, обратились к одному фрилансеру, ожидая, что он что-то сделает. Однако тот их продинамил, и они обратились к второму фрилансеру. Тот уже что-то смог написать, но это было далеко от того, что видели основатели будущего проекта ценой в миллионы долларов :). Они начали работать над проектом самостоятельно (причем не зная JavaScript, изучая его походу), и параллельно поставили на сайт (в тот момент уже начавший набирать популярность) рекламу Google AdSense и стали искать инвесторов. Но пока искали, реклама стала приносить ощутимую прибыль, и они смогли нанять дополнительный штат программистов для развития проекта.

Сейчас проект посещают 600 тыс. человек в сутки, а команда проекта состоит из 6 человек.

Вот такая история о том, как использование бесплатных API от Google помогает делать деньги буквально из ничего, подытожил Эрик Толоме.

Закрывал открытие (да-да, именно так) Алексей Шелестенко, директор по маркетингу Google Россия.

Замечательное и живое открытие. :) Хочу сразу ханжески заметить, что зарубежные гугловцы гораздо более профессиональны в части публичных выступлений, чем наши соотечественники. Речь наших англоговорящих "братьев по разуму" лилась плавно, были уместные шутки и взаимодействие с аудиторией, а из презентации Google Wave Ларс Расмуссен и Стефани Хэннон умудрились сделать целое шоу :) Вступительное слово Дмитрия Полухина, технического инженера Московского офиса Google, выступление Евгения Савельева, основателя Wikimapia, были неуверенными. Ну ничего, лихая беда начало.

HTML 5 и будущее Интернета (Tech Talk), Марк Пилгрим

Эту тему достаточно полно осветил Goga в своем отчете про GDD 2009. Кратко от себя скажу, что доклад больше напоминал зачитывание тегов, и после каждого тега докладчик делал паузу и аудитория задавала вопросы, в результате чего рассказать ему удалось только про теги , , . Также, для более полной картины могу посоветовать спецификации HTML 5 и хорошую статью об использовании Canvas.

Инструменты для вебмастеров, Елена Ковакина

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

Основной вопрос, поднятый в докладе - как повысить "понятность" вашего сайта в глазах поискового робота Google?

Использовать браузер Lynx для просмотра того, как страница будет выглядеть для поискового бота.
Работать с изображениями нужно так: название файла самого изображения должно быть говорящим, например, google_developer_day_2009.jpg, вместо DSCN6187.JPG. Файл можно назвать и по-русски, однако, лучше всего использовать транслитерацию. Обязательно нужно прописывать ALT атрибут для тега , где располагается краткое описание фото. И в конце концов, сам текст нужно окружать релевантным текстом.
Работа с видео примерно аналогична работе с изображениями. Нужно размещать одно видео на страницу, выбирать в качестве скриншота к видео говорящую картинку (и обрабатывать ее так, как написано выше для картинок)

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

Для замены шрифтов хорошим решением является технология sIFR (ссылка 1, ссылка 2), вместо сохранения текста картинкой, т.к. она оставляет исходный текст для поискового робота. Если уж пришлось на сайте сохранять текст в виде картинки, из-за нестандартного шрифта или его оформления (градиентный цвет, сглаживание), то нужно хотя бы прописать атрибут alt.

При работе с Flash хорошо использовать решение SWFObject.

При использовании Ajax, для ссылок лучше использовать ? вместо # - чтобы робот по этим ссылкам мог переходить.

Для дублирующегося контента неплохо бы использовать канонические ссылки:

URL должен содержать в себе основные ключевые слова (можно использовать транслит).

Также докладчица посоветовала использовать новый сервис Google Alerts и инструменты для вебмастеров, правда в связи с чем - я уже не помню.

Как заинтересовать посетителя, Чуи Трюэлла

Чуи рассказывал о различных API Google, и различных не менее интересных вещах. (немного отступлюсь и дам ссылку на статью с небольшим списком Google APIs.) Много о каждом API говорить не буду, всю необходимую исчерпывающую информацию о них можно найти по приведенным ссылкам.

Analytic API, документация, объявка на Хабре.

Website Optimizer, статья о том, как его использовать, блог разработчиков. Сплит-тестирование при помощи Google Website Optimizer. Я этой штукой весьма загорелся, и уже приобрел себе русскоязычную книгу про нее.

Maps API: Store Locator на PHP, MySQL.

Web Elements - небольшие блоки-виджеты на сайт от Google. Раз статья, два статья.

Youtube Data API
Старая новость об этом API.
Справка по API на русском.

Google File System. Статья 1, статья 2, статья 3.

Ajax Feed API
Документация на русском.
Небольшой пример.

Ajax Search API
Документация на русском.
Упоминание на хабре с кучей полезных ссылок в комментах и посте.
Блог проекта.
Сравнение Yahoo и Google Search APIs.
Пример.
Пример от IBM.

Custom Search - без комментариев, настолько старая тема, что должна быть известна всем IT-шникам.

Language API
Документация
Короткий пример на английском.
Короткий пример на русском.
Пример побольше на русском.
Блог.

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

Жадные алгоритмы и оптимизация ранжирования, Павел Карпович (Яндекс)

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

Google Wave API, Вадим Герасимов

Такой достаточно обзорный доклад о новой технологии Wave и новом продукте Google Wave. На этом Вадим заострял внимание, объясняя, что Wave - это новая технология связи, а Google Wave - это уже конкретный продукт от Google. Точно также, как есть электронная почта вообще (email) и GMail.

Вначале было рассказано об устройстве волны, из чего она состоит, что в ней есть: волны, вейвлеты (всплески), роботы, виджеты, федерация. Это были базовые понятия, без которых нет возможности вести разговор об этом новом и перспективном виде телекоммуникаций. Гугловцы обещают поднять общедоступный Wave-сервер уже в 2010 году, стало быть, возможен быстрый рост интереса к данной теме в недалеком будущем.

Когда я в кулуарах общался с Ларсем Расмуссеном, который сейчас является ведущим инженером Google Wave, я спросил его: как считает Google, будет ли волна новым и современным способом общаться, и не похоронит ли она почту и IP-телефонию (скайп, ага). На что Ларс с очаровательной улыбкой ответил, что Google работает над этим.)

Ларс Расмуссен пытается обратить русскоязычных Друпалеров в Гугл-веру.

Венчурный капитал и инвестиции в стартапы

Под конец мы уже устали, и воспринимать этот доклад было достаточно трудно. Однако докладчики (их было трое, один - автор стартапа, другой - инвестор, который инвестировал деньги в этот стартап, и сотрудник Google. К сожалению, по именам я их не помню.)

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

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

Интересные ссылки:
Хороший Отчет о GDD2009
Отчет от devclub.eu
Google Developer Day 2009 — хабра-отчет
Анонс конференции
Отчет от самого Google Россия
Список выступавших
Программа мероприятия

Youtube ссылки:
Канал Google Developers
Канал Google Россия

Отзывы друпалеров: Ромка, Goga

Ларс Расмуссен успешно обратил русскоязычных Друпалеров в Гугл-веру.

Мультиязычный сайт на Drupal и модуль WebForm

andyceo — Mon, 05 Oct 2009 19:59:04 +0000

Столкнулся я как-то по работе с довольно популярным модулем для Drupal Webform. Делали мы мультиязычный сайт, и требовалось создать мультиязычную форму - на русском и английском языках.

Модуль Webform сам по себе мультиязычность не поддерживает (см. Make Webform multilingual (i18n) aware). Однако, есть-таки возможность создать полностью мультиязычную форму, правда, для этого вам понадобится бубен и навыки программирования под Drupal.

Здесь давайте немного остановимся и дадим определение "полной мультиязычности". Под полной мультиязычностью, в случае формы (webform`ы) нужно понимать, что при разных языках будут переведены:

Заголовок страницы с формой
Описание формы
Заголовки полей
Описания полей
Сообщение об успешной отправке
Сообщения о неправильно заполненных полях (неуспешая отправка формы)

В Drupal вся поддержка мультиязычности делиться на три основных слоя:

Перевод интерфейса (модуль ядра Locale)
Перевод контента (модуль ядра Content Translation)
Модуль i18n для полного перевода сайта

Что такое есть эти модули (слои), я надеюсь, читатель знает, и поэтому их описание останется за рамками статьи.

Если бы мы делали нашу форму программно, т.е. написали бы модуль и создали бы там форму через Drupal Form API, то мы имели бы возможность перевести через слой "Перевод интерфейса" заголовки и описания полей формы, а также перевести заголовок страницы, на которой эта форма появляется (используя в нужных местах функцию t()).

WebForm тоже так делает - он пропускает заголовки и описания полей формы через t(). Т.е. казалось бы, мы решили проблему перевода формы! Но... почти решили. Вот первый подводный камень.

WebForm сохраняет параметры полей в том виде, в каком вы их вводите. Т.е., если вы вводите поле

Тип: "textfield"
Заголовок: "Ваше имя"
Описание: "Пожалуйста, введите Ваше имя."

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

Второе. WebForm`а является нодой, т.е. единицей контента. А для перевода контента у нас предназначен совсем другой слой переводов - "Перевод контента".

Строго говоря, как нужно было бы сделать правильно, с точки зрения философии Drupal? Нужно было бы создать свою форму для каждого конкретного языка, при создании забивать все поля на том языке, для которого делается эта форма, и затем... нужно было бы создать некую интересную ссылку (например в меню сайта), при которой у нас на русском языке, например, она вела бы на node/25, а на английском - на node/26. Как известно, в админке через стандартный интерфейс работы с меню этого сделать нельзя. (Забегая немного вперед, скажу, что при помощи модуля i18n (а точнее его подмодуля Menu translation, или, если меню - это primary links, путем еще больших хитростей - читайте мануал к i18n) эту задачу можно решить, путем создания разных меню - каждое на ту или иную языковую версию сайта. Но хотелось бы чего попроще.)

Более того, хотелось бы, чтобы при переключении языка, показывалась соответствующая версия нашей ноды-webform`ы. Т.е. находимся мы, например, на этой самой форме, в английском варианте - node/26. Потом - хоп! - переключились на русский, нажав соответствующий флажок. Как поведет себя друпал? Он сразу же переведет интерфейс (все служебные сообщения, пункты меню и прочая), и отобразит эту же ноду - node/26, отобразив внизу малоприметную ссылочку на перевод. А как надо? Чтобы он перенаправил нас на русскую версию этой ноды - node/25, чего не произойдет. А еще лучше - что в блоке переключения языков, на слове "Русский" (или там на флажке), при просмотре английской версии, был адрес не текущей, английской, ноды, а уже ссылка на форму-перевод.

И как это сделать (стандартными средствами или сторонними модулями), совершенно непонятно. Если кто знает - отпишитесь в комментах как.

И это я уже и не вспоминаю "удобство" администрирования, при таком подходе: в случае двух языков, будет две вебформы, и за результатами их заполнения нужно следить уже в двух местах. А если языков не два, а три или четыре (а так бывает)? А форм на сайте не одна, а 3-4-5-более? Тогда это все превратиться в АДминистрирование. :)

Итак, не буду долго томить и предлагаю решение. Чтобы создать мультиязычную вебформу, нужно создать ее всего лишь одну, но при этом потребуются навыки программирования и небольшое знание API Drupal. Начинаем:

Переведем текст описания самой формы (еще его могут называть пояснение к форме) и ее заголовок. В поле Описание ставим фильтр ввода php и вводим примерно следующее:
```
  drupal_set_title(t(drupal_get_title())); //меняем заголовок ноды
  print t('My WebForm description.'); //текст пояснения пропускаем через t()
```
Задаем сообщение об успешной отправке формы, примерно так:
```
  echo t('Your request has been sent. Thank you!');
```
Поскольку заголовки и описания полей у нас пройдут через функцию t(), т.к. WebForm строит формы, используя FormAPI Drupal, то нам следует забивать их на английском языке. Да, я тоже так подумал сначала. Но WebForm еще умнее. ;) Когда вы нажмете кнопку "Сохранить", WebForm зачем-то прогонит ваши строки через t() и в своей базе данных сохранит именно переводы, а не исходные английские тексты. То ли это фича, то ли это баг, но делать нечего - придется пойти в базу (в таблицу webform_component), найти там ваши только что введенные поля и перебить их параметры английскими значениями. Сделать это нужно непосредственно в базе данных, т.к. при сохранении формы WebForm вновь переведет измененные строки. Именно поэтому этот шаг - последняя правка самой ноды-формы. Имейте ввиду, что при любом обновлении ноды через стандартный интерфейс, названия полей будут перезаписаны, и придется повторять трюк с базой снова. Зато теперь, при построении формы, WebForm пропустит эти строки через t() и если найдет в системе перевод, переведет их.
В админке в разделе Администрирование - Конструкция - Перевод интерфейса, нужно сделать поиск по англоязычным текстам ваших полей, и перевести их там, на нужные языки. Вуаля, на этом шаге мы перевели заголовки полей и их описания.
Для перевода всяческих сообщений об ошибках, о неверно заполненных полях и прочее, просто залейте файл перевода модуля WebForm.

Итак, на выходе у нас одна мультиязычная форма.

Желаю вам удачных проектов на Drupal!

Настройки безопасности Wi-Fi

cristobal-junta — Fri, 25 Sep 2009 20:19:59 +0000

В журнале «Компьютерра» #34 (798) от 15.09.09 опубликована любопытная статья (Бёрд Киви «Атака с воздуха. Мифы и правда о безопасности беспроводных сетей WIFI») о последних достижениях в области атаки на сети Wi-Fi. В конце материала приводятся полезные настройки безопасности, при которых «защита должна быть максимально прочной» («если маршрутизатор и сетевые адаптеры достаточно новые, то есть совместимые»). В качестве памятки я воспроизведу здесь эти настройки; кроме того, они могут пригодиться и случайному посетителю этого сайта.

В случае домашней сети или сети небольшого офиса можно рекомендовать:

в качестве «имени сети», SSID, выбрать нечто уникальное и характерное только для вас, дабы защититься от взлома сетевого ключа (куда подмешивается SSID) лобовыми методами словарного перебора;

в поле «режим безопасности» (Security Mode) выбрать WPA2;

в поле «управление ключами» (PSK/EAP) выбрать PSK («…» [и длинную скучную парольную фразу в качестве ключа — C.J.]);

в поле «тип шифра» (Cipher Type) выбрать AES.

На своем роутере ASUS W-500gl Premium в ближайшее время обязательно изменю настройки безопасности!

На текущий момент версии статьи на сайте «Компьютерры» нет, потому ссылку привести не могу.