Вот созрела и 4-ая часть моей статейки с советами стартаперам, основанной на примере развития своего проекта — сообщества автотуристов.

Предыдущие части: Часть 1, Часть 2 и Часть 3

Глава 10. Где же мои рекламодатели?



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

Позвольте представить на суд общественности проект Lime-prime.ru, над которым наша небольшая, но дружная команда работала последний год.

Суть сервиса такова:
— Формулируете и вводите вопросы для соискателей.
— Заносите в базу их контактные данные.
— Соискатели в удобное время отвечают на вопросы перед веб–камерой.
— В удобное для Вас время смотрите видео, делитесь ссылкой на него с коллегами, принимаете решение.

"

Ну и мы тут решили вот такое устроить…
Для обычных пользователей доступна возможность бесплатно отсматривать видео–резюме трех кандидатов.
Но если при регистрации в поле «телефон» указать заветное слово «хабр» (без кавычек), то пользоваться сервисом можно без ограничений намного больше. И еще, при такой регистрации доступны уже готовые вопросники IT-направленности. В настоящий момент это пакеты вопросов ориентированных на подбор на следующие вакансии:
— JS-программист
— PHP-программист
— SEO-специалист

HTML5 для веб-дизайнеров

1. Краткая история языка разметки
2. Модель HTML5
3. Мультимедиа
4. Формы 2.0
5. Семантика
6. HTML5 и современные условия

Великая Французская революция была временем радикальных политических и социальных преобразований. Времени как такового они тоже коснулись: в определенный период своего существования Французская Республика жила по новой системе — в сутках было 10 часов по сто минут каждый. Очевидно, что она была была куда логичнее и «правильнее» привычной шестидесятеричной.

Вместе с тем, она была полным провалом. Никто ей не пользовался.

То же самое можно сказать и про XHTML 2. W3C только лишний раз доказал то, чему нас научил урок послереволюционной Франции: изменить привычки людей по приказу очень-очень трудно.

Сегодня мне кинули ссылку на прикольный сервис для быстрого генерирования изображений-заглушек. Может пригодиться для html-верстки. На мой взгляд, это удобно тем, кто и так использует заглушки — экономит время при вёрстке, т.к. сами заглушки уже готовы. Можно цвета/размеры подбирать, меняя только числа/буквы в коде, не отвлекаясь на сам файл картинки — и сразу видеть эффект. И сами размеры видеть написанными, если нужно, чтоб к коду не возвращаться для проверки. Или вместо размеров можно текст добавить, чтоб всегда знать, для чего эта заглушка (типа «Бан(н)ер» или там «Лого», или «Фотография»).

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

<img src="http://placehold.it/350x50" />

и получаете:


Update. Благодаря усилиям k0rv1n, найден вариант этого сервиса, только лучше :)
Во-первых, там поддерживается кириллица. Во-вторых, там даны ссылки на исходники для разных языков.
Автор dummyimage.com — тот же Russell Heimlich, что и у placehold.it. У placehold.it есть ещё один автор, но будем считать, что он делал дизайн (дизайн там правда круче, но видимо как раз из-за понтового шрифта Unicode и не выходил).

Примеры (см. под хабракатом) я поменял с placehold.it на dummyimage.com, раз уж он функциональнее…

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

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

Каждый день на сайте выходит несколько хороших обзоров новых и интересных гаджетов. И если все особенности устройства обычно описаны «на отлично», то вот фотографии гаджета зачастую не выдерживают никакой критики. Часто приходится видеть подобное:

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

На Хабре уже публиковались интересные советы по этой теме. Я хотел бы предложить еще один способ, который позволит вам делать практически рекламные фотографии небольших объектов.

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

Я чуток увлекаюсь 3д и порендериваю порой дома всякую ерунду. Дома у меня Macbook Pro и его двухъядерного Core 2 Duo для рендера маловато, тяжёлые сцены считаются долго, на ночь оставлять жужащий вентиляторами ноут не хочется. На работе же стоит 4х-ядерный Mac Pro с Xeon'ами, подумалось мне скидывать задачи по просчёту на него, вот только как? И я за NAT'ом, и он за NAT'ом (и к тому же на стриме), сисадминского опыта у меня 0, как портфорвардинги я не пытался настроить, ни один из remote desktop'ов заставить работать не вышло. На помощь пришли Dropbox и Правила Mail'a

Так сложилось что по долгу своей службы я занимаюсь гео-поиском. И зачастую мне нужно показать на карте координаты пользователей, для того чтобы сделать какие-либо анализы. Для этой цели я, до определенного времени, успешно использовал Google Maps, пока, однажды, мне не понадобилось нанести на карту не много не мало 16 млн. координат.

Как я это сделал?

(2009 год, второе письмо старшего менеджера веб-студии — младшему)
Итак, первоначальные переговоры c клиентом проведены. Смотрим первую часть методички здесь http://habrahabr.ru/blogs/studiobusiness/45543/.
Теперь надо сориентировать клиента по цене. Если он с ней принципиально согласен — переходим к обсуждению Технического задания (ТЗ).
Делаем смету

Тот факт, что iPhone предлагает наиболее развитый мобильный браузер среди мобильных платформ, пожалуй, ни у кого не вызовет сомнений. Однако не все знают, что довольно небольшими усилиями можно сайт сделать еще более дружественным к тем, кто смотрят его на iPhone или iPod Touch.

Ниже предлагаются простые 5 шагов, с которых можно начать, на примере сайта WHOIS Digger.

Шаг 1. Аналог favicon.ico

Когда пользователь создает ссылку на ваш сайт в виде иконки в SpringBoard, iPhone автоматически формирует картинку из скриншота страницы. В результате почти всегда получается неразборчивая каша, которая на гордое звание «иконки для iPhone» никак не тянет. Пропишите этот тег в заголовке страницы:

<link rel="apple-touch-icon" href="res/iphone_icon.png" />

и добавьте соответствующую картинку res/iphone_icon.png размером 57х57 пикселов. iPhone сам добавит скругленные углы и полукруглый блик, сделав вашу иконку похожей на остальные.

Вот так выглядит исходная картинка и иконка на рабочем столе iPhone:

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

Поэтому сел как-то на выходных и сделал для себя «WHOIS Digger», который теперь вынес в онлайн.

Вот как он выглядит:



Чем же он удобен?

(От перев. Данная статья не претендует на полноту и непротиворечивость, потому мы не будем строить на ее основании никаких теорий. Это всего лишь практическое пособие для разработчиков, немного исправленное и дополненное мной под реалии Рунета.)

Одним из самых странных статистических фактов, связанных с использованием браузеров, является широкая распространенность Internet Explorer версии 6, 7 и 8. На сегодняшний день все версии Internet Explorer вместе занимают примерно 65% рынка используемых в настоящее время браузеров. Среди веб-разработчиков эта цифра ниже, здесь доля пользователей IE составляет лишь 40% рынка.
(От перев. Надеюсь, эти 40% составляют лишь несчастные верстальщики, проверяющие свои сайты на предмет кроссбраузерности. Статистика по Рунету доступна, например, здесь. Заметьте, в сентябре у всех браузеров IE-семьи график без видимых причин подскочил — это вернулись за свои компьютеры офисные пользователи, самые преданные почитатели наших героев.)

Интересно, что популярность браузеров семейства IE примерно одинакова, нельзя выделить один доменирующий браузер, как это было ранее. (От перев. Конечно, нельзя. Вот смотрю и ну никак не могу выделить доминирующий браузер. =) ) Таким образом, сейчас веб-разработчики обязаны проверять работоспособность своего проекта в различных браузерах, разрабатывая как сайты для своих заказчиков, так и персональные странички.

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

Эта статья является попыткой дать исчерпывающую, легкую в восприятии информацию для веб-разработчиков, пытающихся понять различия в обработке CSS между IE6, IE7 и IE8. Здесь собраны краткие описания для свойств, поддерживаемых одним или двумя браузерами, но не всеми тремя сразу. Здесь не рассматриваются свойства, не выполняемые ни одним из IE, а также специфичные только им. Таким образом, акцент стоит именно на различиях между браузерами, а не на недостатке поддержки ими тех или иных CSS-свойств.

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

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

Несколько месяцев назад, говоря о рынке плагинов для коммерческих CMS, я мимоходом упомянул про “сборки” открытых систем управления сайтами. При том, что работал я со многими (за спиной большое число проектов различного масштаба на SharePoint, Битриксе, Юми, Wordpress, Drupal, нескольких “студийных” и просто самописных системах), больше всего, несмотря на свою прожорливость, мне нравится именно Друпал. Поэтому просто перечислю несколько интересных сборок на нём, предназначенных для различных задач.

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

1. Часть ЧПУ (человекопонятный URL)

По сути, слово с дефисами.

Паттерн: /^[a-z0-9-]+$/

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

Безусловно, реализовать что-то похожее можно даже за счет только лишь того, что функции в JS являются объектами первого уровня, но мне бы хотелось поделиться реализацией весьма близкой к ГОСТу GoF'у.

UPD: ссылка на рабочий пример, спасибо Barttos.

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

Прелюдия

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

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

Алгоритм возможно не новый, и не является идеалом, но, на удивление, работает. Никаких графов и корелляции.

Для начала, стоит отметить, что сравнение очень приблизительно (по крайней мере, на данном этапе), временами две совершенно разные фотографии оказываются похожими процентов на 60%, так же не учитываются жесткие модификации (повороты, инверсия, обрезка) – для этого нужно доводить и доводить. Лично для меня самым главным оказались два параметра: скорость, независимость от разрешения изображения и возможность сравнивать «изображения» прямо в базе данных.

Многим JavaScript-разработчикам приходилось сталкиваться с объектами, перечисленными в заголовке, например, при решении следующих задач:
— создание визуальных редакторов (wysiwyg),
— поиск в окне браузера,
— выставление BB-кода,
и т.д.

В этой статье автором предпринята попытка собрать перевод документации об этих объектах в одном месте + написать небольшие сопроводительные примеры. Перевод вольный, не дословный, так что если встретите неточность или корявую формулировку — пишите в комментариях.

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