Сложна и непредсказуема карьерная лестница IT-шника. Иногда можно споткнуться и упасть только потому, что не поспеваешь за технологиями. Не будем впадать в панику, а будем учиться на ошибках других. Делимся.

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



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

Знакомо не только это, я уверен. Ещё есть высокий показатель отказов на этой странице. Эдак 70-80 %, если не больше. Низкая конверсия. Непонятные действия посетителей. Всё это относится к посадочным страницам… Неправильным посадочным страницам.

В этом кейсе вы узнаете как ребята из небольшого стартапа улучшали конверсию лендинга с 9 % до 52 %. Шаг за шагом. С подробным описанием проблем и изменений, которые они делали на странице и к чему это привело. Невероятно крутой кейс, который советую прочитать всем.

Кстати, конверсия 9 % — это очень даже хороший результат для лендинга. Конверсия 52 % — это исключительный случай. Один на миллион.

После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

Прошло полгода с последней новости о TARS на хабре.

Напомню, что TARS — это сборщик html-верстки, основанный на gulp, в помощь любому frontend-разработчику (или даже целой команде), для создания проектов любой сложности. За последние шесть месяцев было закрыто 88 issue, выпущено 7 версий, появился CLI, так вышло, что с yeoman’ом отношения не сложились, поэтому появилась своя версия. TARS переехал в свой новый дом на github, обзавелся командой из 4 разработчиков + небольшой армией фанатов. Кстати, огромное вам спасибо за мгновенные фидбеки после релизов и не только. TARS был внедрен в нескольких вебстудиях России и за рубежом. Сборщик научил компонентному подходу не один десяток разработчиков, привлек в ряды frontend’еров тех, кто боялся всей рутины верстки. В общем, появилось много всего нового, и об этом хотелось бы рассказать.

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

В наше время в сети достаточно легко найти «12 правил фрилансера», или «20 советов фрилансеру», а то и «библию фриланса».
У всех разное отношение к этому явлению, разный опыт или предубеждения. Немало, кстати, негативных мнений.
Мне бы не хотелось писать очередное руководство «как заработать 10000$ в месяц». Поделюсь своим небольшим, но положительным опытом в роли «Фрилансера» и кое-какими выводами. Этот опыт сделал для меня работу на фрилансе комфортной и прибыльной.

Несколько лет назад я был студентом без денег, которому учеба в университете казалась скучной и бессмысленной (и с тех пор моё мнение не изменилось). Так что, учебу я бросил и стал фрилансить. Спустя 6 лет, пишу этот текст, чтобы определить самые важные идеи, которые сделали меня сначала хорошо оплачиваемым “кадром”, а затем руководителем небольшой команды разработки веб-сервисов.

Не будьте специалистом. Учитесь действовать

Главный ресурс для развивающегося человека вовсе не знания и опыт. И даже не деньги или связи.

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

Накопление знаний и опыта есть линейный процесс, а потому не самый эффективный. У специалиста всегда есть четкий потолок зарплаты, который практически не возможно преодолеть (здесь не выйдет даже постоянного линейного роста).

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

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

В первой части мы поговорили о «фишках» на этапе поиска клиентов и заключения договора. Сегодня — о дизайне, собственно разработке (внедрении) и сдаче проекта.

Мало кто поспорит, что хорошая коммуникация с заказчиком чрезвычайно полезна для веб-студии. Поэтому хочется обсудить проблему личных отношений «заказчик-исполнитель» как одну из важнейших слагаемых успешной реализации проекта.
Прежде всего, заказчик должен понимать, что вы — профессионал. Если ваш заказчик это понимает, то проект будет успешным, вовремя завершенным, а вас будут рекомендовать другим (конечно при условии, что вы действительно хорошо выполняете свою работу). О том как добиться понимания вашего профессионализма и пойдет речь.

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

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

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

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

Расскажу об источниках заявок на разработку и продвижение на реальном примере веб-студии. Сайты мы продаем с ценником 100 тыс.+, что выше среднего на региональном уровне и ниже среднеценового сегмента по Москве. За проекты по seo беремся с бюджетом от 10 тыс рублей по Волгограду и от 17 тыс в столице.

Привет, Мегамозг! Раньше подобные материалы мы писали на Хабр, но после отселения «управленческих и маркетинговых» историй, решили попробовать здесь.

Недавно мы запустили совместно с UMI большой образовательный спецпроект про продажи и маркетинг для студий и агентств (мы уже опубликовали все 5 сезонов в 17 эпизодов). В его рамках я подготовил текст про ключевые KPI в управлении и планировании развития бизнеса агентства — и хотел поделиться им с аудиторией Хабра/Мегамозга.

1. Вводная, зачем этот материал

Наверное, любой руководитель агентства с минимальным управленческим бэкграундом будет знаком с 80% описанных в нашем материале KPI. Цель нашего материала — показать многообразие возможных показателей оценки результативности и эффективности бизнеса с учетом агентской специфики. Если вы найдете в нашем списке из более чем 50 индикаторов хотя бы пару показателей, об учете которых вы ранее не задумывались, а они важны — то мы добьемся своей цели.

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

Всем привет. Это снова «Без слайдов», и на этот раз у меня в гостях побывал легендарный Дмитрий Завалишин, известный всем как один из создателей Яндекс.Гуру (предшественник Яндекс.Маркета), основатель группы компаний DZ Systems и автор операционной системы Фантом.



О чем мы поговорили:

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

Все это — в традиционном видеоинтервью:



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

Enjoy!

Новости из мира DevOps на Highload++ представляет Александр Титов из Express 42

— Я до сих пор не понимаю, в чём отличие DevOps от системного администрирования, в чём? Зачем DevOps, прекрасно же справлялись?

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

Продолжение цикла переводов полезных советов для веб-разработчика. Другие части: 1-16, 33-48.

Содержание:
   17.  Быстрое редактирование названия HTML-тега в панели «Elements»
   18.  Разворачивание всех дочерних узлов выбранного элемента
   19.  Переключение состояния вкладки DevTools при помощи горячих клавиш
   20.  Переключение на DOM-элемент из DevTools консоли
   21.  Подсветка выполняемого выражения
   22.  Улучшения в работе инструмента Color Picker
   23.  Включение точки останова и навигация по стеку вызовов при помощи горячих клавиш
   24.  Просмотр определения функции, зарегистрированной как обработчик события на DOM-элементе
   25.  Нотификация о JS-ошибке во время написания кода
   26.  Персистентность настроек отображения для режима «Инкогнито»
   27.  Визуализация выбранного режима сглаживания анимации
   28.  Просмотр и изменения точек останова DOM-дерева при помощи панели «Breakpoints»
   29.  Пять интересных возможностей панели «Console»
   30.  Автодополнение свойств и методов объекта в панели «Console»
   31.  Просмотр и отладка обработчиков событий
   32.  Автоматическая остановка выполнения программы при возникновении любых исключений

Команда браузера Google Chrome проделывает огромную работу для того, чтобы разработчикам жилось лучше. Chrome DevTools — пример замечательного инструмента, сильно упрощающего отладку вашего веб-приложения. Но подчас не весь функционал этой системы виден с первого взгляда, поэтому Umar Hansa — программист из Лондона — описывает его на своем сайте, причем в весьма удобном формате: немного текста и короткий скринкаст. А мы, в свою очередь, решили сделать эти советы более доступными русскоязычной аудитории.

Содержание:

1. Перенаправление порта позволит вам открывать локальные ссылки на мобильном устройстве
2. Активация псевдо-классов DOM-элемента
3. Повтор сетевого запроса при помощи cURL
4. Запуск сохранённых блоков кода (сниппетов) на любой веб-странице
5. Отслеживание изменений файлов через DevTools
6. Простая запись действий страницы
7. Поиск элементов DOM-дерева при помощи CSS-селекторов
8. Копирование изображения в формате Data URI
9. Переход к нужной строке при открытии файла
10. Упрощенная навигация между правками
11. Копирование ответа на сетевой запрос
12. Работа с несколькими курсорами при редактировании скриптов
13. Блочное выделение
14. Быстрый мониторинг событий в консоли
15. Доступ к выбранному DOM-узлу в консоли
16. Отслеживание незавершенных сетевых запросов при помощи фильтра is:running

Продолжение: 17-32, 33-48.

Рынок электронной коммерции и в мире и в рунете очень активно развивается, не смотря на кризисы и другие негативные явления. В мире в год средние темпы роста по данным eMarketer составляют около 18-20% в год, в России и Украине темпы роста доходят до 17-18%. Это примерно 3-4% от общего ритейла в России (в Украине чуть меньше, рынок развит меньше и сейчас глубокий кризис) и до 10-12% в США и других развитых странах. Средний уровень в мире составляет примерно 6%. Единственное исключение, в прошлом году в Украине из-за глубокого экономического кризиса рынок не вырос в долларовом эквиваленте, но для местных компаний это шанс нагнать упущенное раньше. Самое интересное, что мы все еще находимся в стадии зарождения рынка. По многим прогнозам доля электронной коммерции в общем ритейле достигнет 20% в ближайшие несколько лет. Для компаний данного сектора игнорирование этого рынка сегодня равносильно смерти завтра.



Интересен также и тот факт, что многие крупнейшие игроки электронной коммерции в США имеют оффлайн-корни, а США – это некая лакмусовая бумажка, катализатор рынка, который нам показывает, что произойдет на наших рынках в этом же сегменте через 3-5 лет. Этому уже есть подтверждение: в России ряд крупных интернет-магазинов уже давно принадлежат крупным оффлайн-сетям и поглощения продолжаются. В Украине с этим сложнее, хотя это процесс активно идет, так несколько месяцев назад компания «Фокстрот» выкупила 100% интернет-магазина Sokol.ua

Mobile commerce

БЭМ набирает популярность и становится актуальнее — например, недавно Google выпустил новую библиотеку блоков под названием Material Design Lite, реализованную по БЭМ-методологии. Команда БЭМ тоже не сидела без дела — мы выпустили новую версию библиотеки bem-components, на базе которой построены сайты и проекты не только Яндекса, но и других разработчиков.

Эти события натолкнули нас на мысль ещё раз вспомнить и рассказать вам, как сформировались принципы разработки библиотек в БЭМ-методологии. Надеемся, что многим это будет интересно и полезно. Итак, поехали.



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

Если вы хотите узнать на примерах, как мы пришли к нашим принципам разработки, добро пожаловать под кат.

Всем привет! Меня зовут Дмитрий Беляев, я работаю frontend-разработчиком в отделе медиапроектов Mail.Ru Group. Вместе с нашей командой мы занимаемся разработкой и поддержкой 13-ти вертикальных проектов различной тематики. До недавнего времени каждый из них довольно сильно отличался от остальных как в плане дизайна, так и в плане используемых технологий. Поскольку сейчас они развиваются в схожих направлениях, к нам все чаще стали приходить менеджеры с вопросом: «На одном из проектов недавно выкатили фичу N, можем ли запустить аналог для нашего проекта на следующей неделе / завтра / вчера?», после которого мы начинали копаться в особенностях верстки очередного проекта, натыкаться на новые подводные камни, не считая того, что мы повторно решали одни и те же задачи. Подобные ситуации начали наталкивать всех на мысль об унификации, что позволило бы не только повысить узнаваемость проектов, но и сократить время на решение рабочих задач.