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

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

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

Сложность здесь в том, что разное окружение (доступ к БД, расположение файлов и проч.), будучи «жестко» прописанным в файле конфигурации, заставляет нас постоянно этот файл править. Кроме того, файлы настроек часто заливаются в репозиторий, и после очередного обновления кода у вас всё перестаёт работать.

Для решения проблемы я использовал два метода.

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

Это происходит потому, что все «специалисты» знают: дизайн — это красивая картинка.

Дизайн лишь на 20% искусство, на 80% — это точная наука. И вы будете удивлены, когда узнаете, из чего на самом деле состоит каждая картинка.

Собственно сегодня наткнулся на ссылку http://lists.mysql.com/announce/565 и сразу спешу поделиться с хабро-сообществом.

Здесь говорится, что сегодня вышел первый релиз MySQL Server 5.1.30 Generally Available (GA), который является первым релизом, рекомендованным для использования на продакшн серверах.

Основные нововведения в версии 5.1. представлены по этой ссылке http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html

А также описаны в статье tuta_larson — Что нового в MySQL 5.1

Также немаловажно будет ознакомится со списком открытых багов для версии 5.1. — http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html


Ну и собственно ссылка на скачивание — http://dev.mysql.com/downloads/

Это вторая часть перевода интересного исследования, которое проводили авторы популярного интернет сайта Smashing Magazine. Первую часть вы пожете прочитать здесь. В этот раз авторы затрагивают вопросы капчи, сообщения «Спасибо за регистрацию», кнопки «Отмена» на формах и некоторые другие интересные вопросы.

3. Функциональность форм

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

Предыстория

Как известно, перед тем, как выложить сайт в нет, мы его разрабатываем. И делаем мы это, как ни странно, на машине разработчика. И давно замечено, что javascript, а в некоторых случаях и css удобнее при разработке держать в нескольких файлах.Проблема в том, что, согласно принципам, описанным в статье Best Practices for Speeding Up Your Web Site (перевод доступен на сайте webo.in), для ускорения загрузки сайта нам нужно произвести следующие манипуляции над javascript и css файлами:

1. Слить весь javascript в один файл, причем, желательно так, чтобы сохранился нужный порядок — т.е., скажем, библиотека jQuery — была ближе к началу, а функции и объекты, которые ее используют — после нее.
2. Слить весь css в один файл
3. Сжать эти большие файлы с помощью какой-нибудь утилиты вроде yui-compressor (за исключением css-файлов, название которых начинается, скажем, с префикса ie_, которые содержат data:URL, и поэтому критично относятся к переходам со строки на строку, так что их для собственного спокойствия лучше не сжимать)
4. Расположить их в таком порядке — css-файл как можно ближе к открывающему тэгу head, а js-файл — как можно ближе к закрывающему тэгу body.
5. Выставить HTTP-заголовок expires на подольше, чтобы браузер пользователя их закешировал. Ну а для того, чтобы при следующем билде у пользователя обновился js и css надо этим файлам дать какое-нибудь уникальное имя.
6. Перед отдачей файлов клиенту сжимать их с помощью gzip

К чему это я?

Пункты 5 и 6 уже подробно расписаны в других местах.
Я же хочу рассмотреть в этой статье вопрос автоматизации пунктов 1,2,3,4. А точнее, я хочу предложить инструмент, с помощью которого одним (ну, максимум — двумя-тремя :) нажатием кнопки можно выполнить пункты 1, 2, 3, 4 настоящего списка и получить готовые к заливке на сервер javascript и css файлы.

Некоторое время я занимался (и занимаюсь до сих пор) веб-проектом, где необходимо было добавить фичу для загрузки пользовательских видео-роликов. Собственно, какие могут быть пользовательские видео? Очень разного качества и разнообразных форматов. Начиная от обычных flash файлов, которые представляют наименьшую проблему, до различных записей с телефонов. Встала задача — сделать демона, который бы занимался обработкой очереди загруженных файлов и выполнял следующие функции:
— Конвертирование видео в flash формат (FLV), ипользуя VP6 кодек
— Обновление метаинформации видеофайла
— Создание thumbnails из видео
— Дальнейшии манипуляции с БД

Конкретно в этой статье я рассмотрю варианты обработки уже сконвертированного в формат flash видео-ролика. Итак приступим.

Данная статья — первая из цикла на тему укрощения CSS. Сегодня мы рассмотрим технологию CSS Reset.

Зачем это нужно?

Каждый браузер устанавливает свои значения стилей по умолчанию для различных HTML-элементов. С помощью CSS Reset мы можем нивелировать эту разницу для обеспечения кроссбраузерности стилей.

Например, вы используете элемент a в вашем документе. Большинство браузеров, как Internet Explorer и Firefox, добавляют ссылке синий цвет и подчёркивание. Однако представьте, что через пять лет кто-то решил создать новый браузер (назовём его UltraBrowser). Разработчикам браузера не нравился синий цвет и раздражало подчёркивание, поэтому они решили выделять ссылки красным цветом и полужирным шрифтом. Именно исходя из этого, если вы установите базовое значение стилей для элемента a, то он гарантированно будет таким, каким вы хотите его видеть, а не как предпочитают его отображать разработчики UltraBrowser.

В одном из проектов возникла необходимость использования сложных математических формул в тексте. Вариант использования редакторов формул наподобие Microsoft Equation с последующим сохранением в виде картинки не подходит, так как необходима возможность легкого редактирования существующих формул.
Решение нашлось в виде PhpMathPublisher.

Раз уж сегодня на хабре день РНР шаблонизаторов, то не могу не рассказать о MACRO — наиболее гибком шаблонизаторе с читаемыми шаблонами, среди известных мне.

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

содержание:
— переход со Смарти, на Quicky
— — чем Quicky лучше Smarty?
— Quicky быстрее PHP-native?
— Quicky темная сторона силы.
— Комьюнити Quicky. (теперь все тут http://code.google.com/p/quicky/)
— Богатые возможности Quicky.
— Вместо заключения. Личное мнение.

Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

Решил поделиться файликом, который я использую каждый раз, когда рисую макет или проектирую интерфейс.
Экономит мне кучу времени.



Скачать архив с пээсдэшником (49 kb)

UPD:
Ссылка от saltommeister
Контролы для Эксплорера, Файрфокса, Оперы и Сафари

Ссылка от niker
designerstoolbox.com/designresources/elements/

Ссылка от fatal
456bereastreet.com/archive/200409/styling_form_controls/

Ссылка от AlmeZ
Free Photoshop browser templates for webdesigners and screendesigners

Ссылка от 3fonov
Yahoo Design Stencil Kit

Проблема

На многих сайтах я наблюдаю следующий процесс:

1. Пользователь заходит на сайт
2. Пользователь находит что-то, что он хочет купить/скачать/сохранить
3. Пользователь переходит на страницу регистрации
4. Пользователь вводит свою информацию и ждёт письма с ссылкой активации
5. Пользователь получает письмо и переходит по ссылке
6. Пользователь попадает либо на страницу активации, либо на страницу логина, либо на страницу, откуда он начал регистрацию
7. Пользователь снова находит то что он хотел купить/скачать/сохранить
8. Пользователь покупает/скачивает/сохраняет

Суть проблемы: пользователь теряет контекст своего действия. После регистрации он вынужден снова искать то, что он изначально хотел купить/скачать/сохранить.

Решение

Сегодня я смотрела видео с презентации одного из мемберов команды 37 signals о том, как они, оставаясь маленькой компанией (из 12 человек), не привлекая венчурные инвестиции, умудряются успешно продавать свой продукт и быть чертовски прибыльными.

Обобщая идею презентации могу сказать следующее:

1. Создайте хороший продукт
2. Установите разумную цену
3. Попросите ваших пользователей заплатить за него

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

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

Несмотря на то, что некоторыми это может рассматриваться как инсайдерская информация – нам нечего скрывать:

//2500 пользователей пользуются нашими платными услугами

2500 пользователей платной услуги получаются при допущениях:
V нашего рынка = 1000 000 пользователей (согласно проведенному нами
исследованию)
Мы занимаем 5% рынка = 50 000 пользователей
5% из них пользуется нашими услугами = 2500 пользователей. (это 25% от 1% ;))

#1 вариант#
базовый: от 5 у.е. — 50% пользователей
средний: от 10 у.е. 40% пользователей
продвинутый: от 15 у.е. — 10% пользователей
1250 * 5 + 1000 * 10 + 250 * 15=
6250 + 10 000 + 3750 = 20 000 у.е. месяц
***дальше по тексту без расшифровки

#2 вариант#
базовый: от 5 60%
средний: от 10 30%
продвинутый: от 15 — 10%
7500 + 7500 + 3750 = 18 750 месяц

#3 вариант#
базовый: от 5 70%
средний: от 10 20%
продвинутый: от 15 — 10%
8750 + 5000 + 3750 = 17 750 месяц

#4 вариант#
базовый: от 5 75%
средний: от 10 20%
продвинутый: от 15 — 5%
9375 + 5000 + 1875 = 16 250

Как видите, при любом раскладе получается весьма неплохо. Это не сотни миллионов, которыми воротят ключевые игроки рынка, но это неплохие деньги для начала.

Возвращаясь к идее 37 signals: у вас есть оооочень маленькие шансы стать еще одним facebook’ом, myspace или google. Они есть, но совсем небольшие. Кроме того, даже эти компании не стали «звездами за 1 ночь», а развивали свою базу пользователей постепенно, пусть и очень большими шагами.

А теперь спросите себя: готовы ли вы переработать свою стратегию таким образом, чтобы ваш бизнес действительно приносил деньги, а не имел виртуальную стоимость (как происходит со многими стартапами, которые потом покупают)? Если да, то вперед!
Я думаю, что мы свой выбор уже сделали.

sspp маленький парсер написанный на php для сортировки и анализа server-status

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

1. VIERA (телевизоры Panasonic) от ADV/web-engineering



2. Lexus RX350 от Brand Studio



Расскажем немного о самой технологии. Появилась она достаточно давно, и ее «идеологической базой» стал ресурс http://dontclick.it/, на котором подробно изложена суть технологии, примеры, а также эмоциональная подоплека.

Много было про то написано, да не суть…

Озадачился следующей задумкой: перетаскиваемый слой с фиксированным положением на экране, страница скролица — слой остаётся на месте. Как известно данная задумка на ура воплощается в FF, Opera, Google Chrome, но вот IE интеллигентно послал мою задумку в свою мусорную корзинку — при скролинге передвинутый слой сползал вместе со страницей.

Дружественная компания Тематические Медиа поручила нам нарисовать макеты для сайта сообщества любителей футбола Дрибблер. На сайте пользователь может публиковать мультимедийный контент, участвовать в комментировании матчей, обсуждать и рейтинговать профили игроков любимой команды, делать прогнозы на матчи и многое другое.

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

Такой подход, насколько я понимаю, широко применяется в мире Java, там для этого есть стандарт Java Message Service (JMS) и применяются брокеры сообщений и на этом базируется архитектура Enterprise service bus (ESB), например, Apache ServiceMix. Но для нас это пока высокая сфера крупных проектов, а в специфике веба и веб-ориентированных приложений я бы хотел рассмотреть, можно ли что-то сделать подобное, но с меньшими затратами и обеспечить приложению отказоустойчивость, распределение нагрузки и асинхронную обработку. И конечно, очень желательно, чтобы это было реализовано на РНР как основном языке реализации всех компонентов сервера.