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

1. Деньги.

Первым вариантом ставлю деньги, завлечение деньгами. Это, наверно, самый логичный но наименее распространенный вариант. Во-первых, не каждый «зеленый» проект сможет платить нормальные деньги, ибо нужен не плохой буфер. Зачастую владельцы проектов — свободные разработчики, у которых нет лишних 2-3 тыщ зеленых в месяц на свой зеленый проект. Во-вторых, я лично не видел еще ни одной нормальной компенсационной программы, точнее её реализации для сети. Идеальная — установка AdSense от гугля. В идеале — пользователь ставит свой AdSense код в свой контент (блог, новости) и получает 100%, оставляет AdSense проекта и получает 50% (скажите, стали бы вы больше писать, если бы за каждый просмотр вашей новости на хабре вам капала копеечка?)

Примечание: ниже приведен перевод статьи «Replace GIF with PNG Images» о том, в каких случаях стоит использовать PNG-формат вместо GIF. Мои комментарии далее курсивом.

Введение

Переносимый сетевой графический формат (Portable Network Graphics, PNG) разрабатывается как более эффективная, гибкая и свободная от патентов замена GIF-формату. PNG был задуман для хранения отдельных растровых изображений для дальнейшего распространения по компьютерным сетям (1). PNG был создан в 1995 в ответ на давление со стороны Unisys и их патента на алгоритм LZW-сжатия, используемый в GIF. Хотя срок действия патента Unisys уже закончился, причины на переход от GIF к PNG остались, практически, прежними (2). Заменив ваши GIF-изображения теми же самыми, но в формате PNG, вы можете ускорить загрузку ваших страниц и сэкономить трафик ваших пользователей.

PNG против GIF: алгоритмы сжатия

PNG использует алгоритм deflate-сжатия обычно с 32Кб скользящим (sliding) окном. Deflate является улучшенной версией алгоритма сжатия Lempel-Ziv (LZ77), который используется в ZIP- и GZIP-файлах (3, 4). Созданный Phil Katz для второй версии PKZip, deflate совмещает LZ77 с кодированием Huffman и является от 10% до 30% более эффективным, чем LZW при сжатии без потери информации. Так же, как и GZIP, некоторые инструменты по PNG-сжатию предполагают опциональный параметр «степень сжатия», которая варьируется от 1 до 9. По умолчанию выставляется 6. 9 является практически всегда лучшим выбором для максимального сжатия.

Не удивительно, что изображения, сохраненные как PNG, обычно от 10% до 30% меньше, чем GIF, хотя в некоторых редких случаях они могут быть больше по размеру (5, 6). В нашем тестировании мы обнаружили, что часть картинок могут быть сжаты от 40% до 50% или даже больше (до 85% для одного примера), в зависимости от изображения. По большей части изображения с большими однотонными областями сжимаются лучше, чем градиентные с большим количеством переходов между цветами.

читать дальше на webo.in →

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


Два варианта superscript'а: «мой» и стандартный.

Самое интересное, что такое поведение можно легко исправить, достаточно добавить глобальный стиль навроде этого:

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

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

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

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

Мы также не будем касаться вопросов проверки смысловой точности цитирования, правильного использования купюр, сокращений и дополнений — всех интересующихся ждёт «Справочник издателя и автора» А. Э. Мильчина и Л. К. Чельцовой.

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

После прохождения собеседования (ох и бурное обсуждение получилось), для разработчика наступает испытательный срок. Это один из самых тяжелых этапов для человека на новой работе — идет адаптации с новым коллективом, нескончаемый поток новых знаний, которые с трудом успеваешь усваивать, да еще и тестовое задания, и оно не из простых…

Поискал ссылки поиском по хабру, не нашел.

Итак, прежде чем изобретать велосипед, у разработчика часто возникает необходимость посмотреть, какие же продукты уже были реализованы.
Кто-то начинает гуглить — что же, наверное, это правильно.

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

Итак, вот они:
www.hotscripts.com
www.planet-source-code.com
php.resourceindex.com
cgi.resourceindex.com
www.scripts.com/php-scripts
www.phpclasses.org
mymans.org/category/php

Эта небольшая статья поможет новичкам (и не только) оценить удобство собственного сайта и укажет основные недочёты, присущие многим сайтам. Ваши пользователи скажут вам спасибо =)

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

Представьте такую ситуацию.

Приходите вы на работу, садитесь проверить почту, рассчитывая увидеть ответ от партнёра, немного спама, а вместо этого видите вот такое: Входящие (164 532).

Примечание: ниже находится перевод статьи с MSDN «Building High Performance HTML Pages», в которой приводится ряд советов от экспертов из Microsoft по оптимизации времени загрузки страниц. Очень интересно сравнить их подход с аналогичным для Yahoo!. На мой взгляд, большая часть советов уже не является такой актуальной (спасибо Zeroglif, все приведенные советы, скорее всего, десятилетней давности), но в свое время все они были весьма действенны. Мои комментарии далее курсивом.

Интернет, интранеты (внутренние корпоративные порталы) и экстранеты (все то, что находится в свободном доступе) содержат уйму информации. Сейчас значительная часть этой информации являет собой HTML в том или ином виде.

Коммуникационные возможности, обеспечиваемые Microsoft Internet Explorer 4.0 и более поздними версиями, помогли превратит Веб в мощное пространство, где можно как работать, так и играть. Число HTML-страниц и их сложность вместе с общим количеством потребителей конечных продуктов существенно увеличили общий интернет-трафик. Вместе со всеми выгодами, которые получили разработчики приложений, это привело и к ряду проблем. Среди этих проблем можно выделить:

• Доставка содержания через интернет (across the wire).
• Будучи доставленным, содержание должно быстро отобразиться на экране.

В этой статьи предлагается несколько советов, как добиться максимальной производительности ваших страниц.
читать дальше на webo.in →

Большинство дизайнов ориентировано на использование фиксированных значений при верстке: ширина и высота блоков, размер шрифта. Это позволяет сверстанному шаблону «не разваливаться» при изменении масштабов просмотра и сохранять свойство кроссбраузерности. Однако в этом есть один большой минус – при большом разрешении экрана маленькие фиксированные блоки теряются на большой площади и остаются незамеченными. Тут даже не спасет «резиновая» верстка, т.к. сайт будет выглядеть еще более нечитабельным, например на 19'' мониторах при разрешении большем 1280 по ширине. Для меня это актуально, т.к. на ноутбуке 17'' с разрешением 1400х800 просматривать «резиновый» сайт очень неудобно. И желание оставаться на таком сайте отпадает быстро. Существует ли способ, позволяющий управлять масштабами не только текста, но и всего сайта?

Блуждая по сети, я не раз видела самые удивительные решения, основанные на применении CSS. И с каждым разом все больше верится, что возможности CSS безграничны :)
Сегодня я увидела вот такую картинку:

Правда интересный эффект? Давайте попробуем раскрыть секрет его реализации.

Навеяно этим: habrahabr.ru/blog/css/36860.html

Для начала напомню, что для создания двойной/нестандартной рамки для изображений нужно {...cut...}, либо положить картинку в контейнер и задать для контейнера отступ и фоновое изображение.

И так далее. There is a better way!

Однажды вечером я почувствовал, что пришло время расширить 97‐ й параграф «Ководства» Артемия Лебедева.

На клавиатуре одна чёрточка, она обычно правее нуля и повыше букв «З» и «Х». Неосведомлённые люди называют её попеременно то дефисом, то минусом, то тире. Лебедев объясняет нам, что это четыре (учитывая две разновидности тире) различных символа. На самом деле их как минимум девять, и об этом я и расскажу вам сейчас.

Примерно три недели назад стартовал проект, посвященный методам оптимизации времени загрузки веб-страницы на клиенте.

Почему оптимизация?

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

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

Почему клиентской части?

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

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

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

Чтобы дать разработчикам более гибкий, совместимый продукт, а также позволяющий делать проекты более интерактивными и интересными, HTML 5 внедряет и расширяет спектр функций, включая формы управления, API, мультимедиа, структуру и семантику.

Работа над HTML 5 была начата в 2004 году. В настоящее время разработки осуществляются в рамках совместных усилий W3C HTML WG и WHATWG. Многие известные компании принимают участие в разработках, в том числе: Apple, Mozilla, Opera, а Microsoft, и ряд других организаций и частных лиц с различными интересами и опытом.

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

Начало статьи

В последние годы размещение аудио и видео ресурсов на страницах веб-сайтов становится все более популярным, и такие проекты как: YouTube, Viddler, Revver, MySpace сделали возможность размещения этих элементов еще более доступным для пользователей. Однако поскольку в настоящее время формат HTML не обладает широкими возможностями внерения аудио и видео, разработчики стараются реализовать это с помощью Flash. Хотя можно воспользоваться и внедрением различных плагинов, таких как QuickTime, Windows Media и т.п. Но реализация на Flash на данный момент является наиболее распространненным способом, а также наиболее совместимым с различными браузерами.

Нужно отметить, что разработчики в процесее создания flash-плейеров, заинтересованы, прежде всего, в создании собственных пользовательских интерфейсов, которые будут обладать основными функциями: «воспроизведение», «пауза», «стоп» и настройка громкости. Задумка состоит в том, чтобы представить эти функциии в браузерах, добавив поддержку внедрения видео и аудио и осуществлять управление воспроизведением с помощью DOM API.

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

Когда верстаешь (X)HTML, порой не знаешь или забываешь о многих фичах, которые стоит использовать. Перечислю те, о которых вечно забываю сам, а зря :)