Вы 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 на сайте.

Эта статья адресована тем, кто имеет отношение к разработке программного продукта. Понимание принципов управление процессом разработки не менее важно, чем фактические знания технологий программирования. Статья не адресована только тем, кто хочет стать или работает руководителем проекта (Project Manager), Понимание принципов управления принесет пользу на любой должности и в любой команде.

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)линк)

Первая статья данного цикла была воспринята тепло, вследствие чего затягивать с продолжением не имело никакого смысла, но, увы – это произошло. Зимнее наступление захлебнулось и плавно переросло в летнюю кампанию. В конце статьи я объясню почему, не хотелось бы вас огорчать с самых первых строк. Итак. Публика выразила желание ознакомиться с предметом глубже, чем предполагалось изначально. Большое количество писем пришло на почту, наряду с регулярными тычками в социальных сетях. В этом месте мне вспоминается одна фраза – «будьте осторожны в своих желаниях».

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

Не будем мешкать. Возьмем наши пиксельные лопатки и двинемся на врага сплоченной группой. Быть может, нам повезет, и кто-нибудь, выжив, расскажет потомкам о ещё одной битве Теоретического войска возле местечка, вошедшего в историю сети как Хаброва падь.

Известный провайдер heroku поддерживает манифест, который называется «12-факторное приложение» (Twelve-Factor App). Это набор лучших практик для разработки современных веб приложений на любой платформе. Практики описывают приложения, которые готовы:

• к горизонтальному масштабированию;
• к непрерывному развертыванию;
• к современным облачным хостингам.

Можно считать, что манифест отчасти рекламный — 12-факторные приложения удобней всего разворачивать на heroku. Но поскольку, манифест становиться все популярней, то часть облачных провайдеров включают лучшие практики в свое окружение, и эти практики будут полезны как разработчикам, так и тем, кто разворачивает и администрирует приложения.

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

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

Но это только на первый взгляд, и на самом деле выполнение требований того же стандарта СТО БР РФ не обеспечит никакой антивирусной безопасности — разработчики стандарта находятся в плену традиционных представлений об антивирусах и антивирусной системе защиты. С другой стороны, наличие возможностей свободного толкования положений законов и стандартов позволяет недобросовестным поставщикам обосновывать свое «соответствие» букве требований.

На что же нужно обращать внимание при реализации антивирусной защиты в банковской сфере?

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

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

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

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

Предпочтения пользователей меняются в зависимости от страны и устройства, с которого они заходят на сайт. Очень близки к идеалу оказались банковские карты, популярность которых растет из года в год, в том числе и в России. Это не только один из самых распространенных способов оплаты, но и самый прибыльный из всех доступных на сайте Badoo, а их более 20.

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

JIRA широко используется в Mail.Ru Group. Сейчас мы применяем эту систему не только для управления проектами и отслеживания ошибок, но и для организации самых разнообразных операционных процессов — рекрутинга, согласования договоров, командировок и так далее. Это с одной стороны очень удобно, так как многие бизнес-процессы отлично ложатся на модель Issue в JIRA. Однако часто требуются также и специфичные функции, реализуемые с помощью специально написанных нами плагинов.

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

Сейчас многие JIRA-плагины сторонних разработчиков не могут похвастаться качественным интерфейсом. Это касается даже некоторых платных плагинов. Однако все средства для быстрой разработки удобных и красивых интерфейсов есть. В статье рассматривается одно из них — AUI Framework (Atlassian User Interface Framework).

Предполагается, что читатель знаком с тем, как можно сделать плагин в принципе. Если нет, то об этом можно почитать, например, здесь.

Сделать веб-сайт доходным можно двумя способами. Первый – привлекать больше трафика, второй – повышать конверсию, т.е. побуждать большее количество посетителей становиться покупателями. Скорее всего, вы уже слышали о том, что трафик можно просто купить – сотни интернет-ресурсов предлагают эту услугу. А не лучше ли оптимизировать конверсию? Как узнать, что именно нужно проверить, и как провести A/B тестирование?

А/В тестированию и оптимизации уровня конверсии посвящено бесчисленное количество ресурсов. Однако, очень редко на сайтах подробно разбирается весь этот процесс целиком от самого начала («Что и как тестировать?») и до конца («Как улучшить конверсию?»).

Дефицит регулярных мероприятий для менеджеров проектов не дает нам покоя. Мы решили опробовать свой подход (назвав его PM-Weekend) и запустить регулярные бесплатные и полезные онлайн мероприятия.

Идея: по выходным раз в 3-4 недели проводить разбор практических тем (в формате мини-семинара) + выступление приглашенных спикеров + интервью с признанными гуру профессии.

Официальный сайт PM-Weekend >>

Первую встречу мы собираемся провести в субботу 16 августа 2014 года, 12:00-14:00 МСК.

Приглашенным гостем выступит Теймураз Орагвелидзе, Head Of Development & Architecture интернет-банка в OTP Group, в прошлом — руководитель проектного офиса «Лаборатории Касперского», директор крупных аккаунтов в аутсорсинге и консалтинге.

Основным ведущим выступит Иван Селиховкин (PMP, заместитель директора по проектам ЗАО НИПК «Электрон», вице-президент Санкт-Петербургского филиала PMI).



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

Что такое гибридное облако?
Гибридное или конвергентное облако — это сочетание минимум одного публичного облака с не менее чем одним частным облаком. Например, это связка вашего ЦОДа в офисе и облака Amazon. Виртуальные машины Amazon при этом могут быть видны в одной подсети с вашими физическими.



Для чего это делается?
Основная причина – экономия и скорость. Можно выделить себе любое количество ресурсов из публичного облака на любое время, а потом просто отключить ненужную мощность. С учётом всех деталей стоимость аренды мощностей в публичном облаке получается примерно такой же, как при покупке реального оборудования – но в первом случае все расходы операционные, а квантование не по трем годам (с заделом на амортизацию), а по секунде.

В странах СНГ не менее 75-80% заказов приходятся на cash-and-delivery (оплата заказа при доставке). Это отличие российского и западного потребителя легло в основу редизайна оформления заказа Сотмаркета еще в 2012 году. Тогда впервые в России интернет-магазин перестал требовать авторизации или регистрации клиента перед совершением покупки.

Фоновая регистрация и авторизация пользователей

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

Это наблюдение легло в основу концепции фоновой регистрации и авторизации пользователей.

Когда говорят, что инновации Made in Russia — это только спорные проекты вроде «Ё-мобиля» паровоза Черепановых, однозначно неоспоримые вроде космических ракет и прочих полу- и совсем неполу-военных изделий, или голые идеи на экспорт — не верьте. У нас есть чем похвастать, и мне за это гордо.

За прошедшие XX-надцать лет моя компания выросла из мелкого местечкового мухомора в топы рейтингов IDC и верхне-правильный угол «магического квадрата» Гартнера. Красивый офис на главной улице страны, Слон Дали на ресепшене, почти 3 тысячи человек в штате, 30+ офисов по всему миру… и прочие хвалилки. Но здесь не про это.

Почему это получилось? Много причин. Например, мой неизменный принцип: пробовать, пытаться и не бояться ошибок. А еще ― партнёрская программа, работа с ритейлерами, онлайнерами, столицами и провинциями ― там много чего было, но и это не по данной теме.

Все перечисленное — вторично (да простят меня те, кто несёт эту службу). Первично — наши технологии и продукты (в смысле, просто софт, а не «софт+всё остальное»). Поскольку если есть софт — всё остальное можно настроить. Если же нет главного — товара, — то всё остальное нет смысла строить. Иначе бизнес (продажи) будет либо одноразовым, либо коррумпированным, что мне претит категорически и фатально.



Итак, софт. Чем здесь можно гордиться? Есть чем! Расскажу вам, уважаемые хабравчане, про «Шестёрку».

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

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

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

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

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

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

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

Иногда скорость роста проекта несколько выше чем скорость оптимизации веб-приложения или приобретение более мощного оборудования под backend.

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.