Пост опубликован по просьбе одного хорошего человека.

Как создать максимально оптимизированную веб-страницу?

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

Интересный сервис ninite.com позволяет с легкостью создавать пакетный инсталлятор для ваших приложений. Сервис подойдет тем, кто не хочет бродить по сайтам в поисках множества повседневных программ, допустим, после переустановки системы, а так же кто не хочет заморачиваться со сложными приложениями для создания пакетных инсталяторов.
Надеюсь многим пригодится. Подробности под катом.

Если вы ведете блог, то, возможно, вам знакомо чувство, когда взлелеянную, родившуюся в тяжелом труде статью никто не читает. И вы не можете понять причины. Кажется, и тема выбрана правильно. И стиль подобран адекватно. И слова использованы именно те, которые нужно! Статья написана интересно, и, бесспорно, должна быть полезной значительной части вашей ключевой аудитории…



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

Продуктивность у одного и того же человека может отличаться в зависимости от времени суток, настроения, коллектива, фазы луны, а иногда и от политической ситуации в Гондурасе. Понятно, что на некоторые факторы вы не в силах повлиять, но сделать жизнь программиста проще, а как следствие — продуктивнее, вам вполне по силам. Итак, что же для этого нужно?

Не устанавливайте рамки

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

Рассмотрим один из вариантов создания нескольких страниц или вкладок (в том числе вложенных) на html и css без скриптов, списков и таблиц, на одной html странице. Только дивы, только хардкор. Подходит для небольших портфолио и элементов интерфейса. Не будьте буратинами используя это везде подряд.
Суть:

Всем привет.

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

Хоть на самом деле конвертеров уже появилось великое множество, не все могут превращать otf\ttf в woff\eot\svg. Существуют специализированные сервисы, которые работают с другими форматами(.pfb, .dfont и др.).

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

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

В каждом из пунктов будут живые примеры и ссылки на полезные, бесплатные инструменты.

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

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

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

Вспомните такие игры, как Mario Bros, Streets of Rage, Mortal Kombat, Turtles in Time или оригинальную игру Moon Patrol. В этих играх техника параллакса наблюдается в тот момент, когда несколько фоновых слоев с различными текстурами двигаются с разной скоростью, что создает эффект трехмерного пространства.

Почему я начал говорить о ретро-играх в статье о веб-разработке? Самым простым ответом мог бы быть «потому что они клевые», но нет. Параллакс-скроллинг является классным дизайнерским концептом, который прокладывает свой путь в мир веб-дизайна. Nike были одними из первых, кто использовал эту технику с большим успехом, когда они наняли маркетинговых гигантов Weiden and Kennedy для разработки их оригинального сайта Nike Better World. Сайт Nike Better World с того времени был обновлен и заменен на новый, однако есть другой сайт, довольно похожий на то, как выглядел первый параллакс-дизайн от Nike — сайт о спортивных напитках Activate.

Здравствуй, Хабр!

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

• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая, шестая и седьмая
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• Подкаст в iTunes
• Плейлист на YouTube
• Форум курса

Первая лекция: Введение в JavaScript, немного истории, числа (тут есть ошибка: функция toFixed округляет значения).



Остальное – под катом.

Пару месяцев назад я случайно наткнулся на массу положительных отзывов о текстовом редакторе Sublime Text 2. Попробовав его в деле, я не разочаровался. Теперь это мой основной рабочий инструмент.

Sublime Text 2 — это платный текстовый редактор, написанный на C++, который:

• Работает в Linux, OS X и Windows
• Обладает приличной скоростью работы
• Приятным интерфейсом (включая всевозможные анимации)
• Гибко настраиваем (правда, не в GUI, а в json-конфигах)
• Имеет множество плагинов, число которых растёт как на дрожжах
• Поддерживает VIM-режим
• Использует fuzzy-поиск

Вторая часть статьи из цикла «Продающий дизайн интернет-магазина». Для тех, кто пропустил первую, её можно прочитать тут: «Продающий дизайн интернет-магазина. Часть 1. Аналитика». Сегодня я расскажу про разные части интерфейсов магазинов, которые важны для конверсии и продаж. Постараюсь обозначить какие элементы должны быть в шапке и футере сайта, на главной странице, на странице каталога и многое другое.

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

Это первая статья. Всего их будет 3.

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

• Приходит на какую-то отдельную небольшую задачу, выполняет ее и уходит.
• Работает над несколькими мелкими проектами одновременно. Либо имеет постоянную работу, а фрилансером просто подрабатывает в оставшееся время.
• Его не беспокоит проект в целом. Только то, за что он отвечает.
• Огораживает себя техническими заданиями. И из-за каждой новой плюшки может возникнуть конфликт.
• Работает когда хочет. С ним сложно связаться.

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

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

Я видел всё, что только бывает. Я видел пафосных московских менеджеров, к которым надо было приезжать раз в неделю, потому что говорить по телефону – это западло, и видел простого американского парня, который взял и прилетел на месяц к нам в Сибирь под новый год, чтобы лично объяснить разработчикам, чего он хочет.

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

Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.

Я работал с заказчиками, которые «я вообще-то тоже программист» и пытались учить нас делать свою работу. Я знаю, что такое переделывать всё с нуля по три раза за проект.

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

В общем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.

Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.

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

И вот, однажды я решил портировать библиотеку на PHP, и теперь хочу поделиться ею с народом и очень надеюсь на помощь в ее улучшении: буду рад советам, баг-репортам и особенно pull-реквестам. Библиотека находится на GitHub'е: github.com/Andre-487/php_rutils

UPD от 26.10.2013: теперь библиотека так же доступна через Composer: packagist.org/packages/andre_487/php_rutils
Так же хочу сказать спасибо всем, кто помог улучшить библиотеку и довести ее до стабильного релиза.

Возможности библиотеки

PHP RUtils — порт Pytils на PHP. Это утилиты для работы с русским текстом. Утилиты разделены на следующие модули (классы):

• Numeral — работа с числами: склонение существительных в зависимости от количества, числа прописью, суммы денег в рублях и копейках прописью.
• Dt — работа с датами: расширение формата дат PHP русскими именами месяцев, дней недели; временные периоды (например, 24 976 дней назад).
• Translit — транслитерация, подготовка строк для использования в URL'ях, именах файлов.
• Typo — небольшой набор правил типографики простого текста.

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

Структуры данных или Абстрактный Тип Данных (ADT) — это модель, определенная как некий набор операций, которые могут быть применены к самой себе и ограничена тем, какой результат дают эти операции.
Большинство из нас сталкиваются со стеком и очередью в повседневной жизни, но что общего между очередью в супермакете и структурой данных? В этом мы и попробуем разобраться в данной статье, где также будут описаны деревья.

UPD: s01e02

JavaScript, the winning style

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

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

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

• Google JavaScript Style Guide
• npm’s coding style
• Felix’s Node.js Style Guide
• Idiomatic JavaScript
• jQuery JavaScript Style Guide
• Douglas Crockford’s JavaScript coding style

Помимо гайдов, не стоит так же забывать об автоматических анализаторах кода, таких, например, как JSLint и JSHint. И в них уже заложены свои настройки. Вопрос в том, какой же все-таки максимально правильный способ писать код на JavaScript, который был бы актуален и максимально соответствовал бы большинству рекомендаций? Давайте попробуем объединить большинство рекомендаций в этой статье и подумаем как можно оптимизировать процесс проверки качества кода.

Разные люди могут по-разному представлять один и тот же цвет по его названию. Например голубой цвет может на самом деле быть цветом морской волны или небесным. Гораздо точнее цвет определяется шестнадцатеричным кодом, всего существует 16777216 комбинаций. Поэтому дизайнеру может быть полезно распознавать цвет, просто взглянув на его hex-код.

Основы

Начнем с простого: рассмотрим обычный hex-код, где каждая из трех пар цифр контролирует один из цветов RGB — красный, зеленый, синий. Числа могут принимать значения цифр от 0 до 9 и букв от A до F.