Продолжаем познавать доступные инструменты в Chrome Dev Tools. Workspace и Сниппеты были вчера, сегодня на очереди поддержка Sass.

16 мая на конференции YaC/m Яндекс объявил о запуске новой поисковой платформы «Острова». Уже в первые две недели после анонса вебмастера создали около 1000 островов для своих сайтов. Но новая платформа вызывает и множество вопросов. Мы уже рассказывали на Хабре о том, как Острова выглядят и почему они визуально устроены именно так.

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

От сниппетов к островам

Яндекс последовательно развивал представление поисковых результатов. С одной стороны, мы работали с результатами «органической» выдачи, с другой — делали специализированные ответы, которые назвали колдунщиками.

От переводчика: Хоть посыл статьи Najaf Ali, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.

Недавно я получил от своего знакомого вопрос примерно следующего содержания:

Добрый день Михаил! Сейчас занимаюсь одной исследовательской работой. Учитывая ваш профессиональный опыт, хотел бы вас попросить ответить на вопрос:

Вы выпустили продукт, который делали целый год, потратив на разработку все инвестиции. Из 1 000 первых пользователей 995 удалили его или перестали им пользоваться на следующий же день. Опишите ваши действия.
Заранее благодарю!!!

Я начал отвечать прямо в окне Facebook, но понял, что ответ получается очень объёмный и совершенно не того формата. Кроме того, я решил поделиться этой информацией со всеми желающими. Надеюсь, кому-то она окажется полезной.

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

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

Что посеешь, то и пожнешь
Из желудя вырастет дуб,
Из семени репейника — только репейник
Профессиональное образование —
это семена, которые мы сеем...

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 2-3 года, ведущий разработчик — плюс 2 года, архитектор решения — плюс 3–5 лет ...).

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

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Вступление

За время существования Дневник.ру (а это более 4-х лет) скопился огромный объем JavaScript кода: часть находилась в отдельном проекте в виде подключаемых файлов, часть определялась прямо на разметке контролов, а часть собиралась прямо в code-behind при помощи StringBuilder. К этому прибавлялись:

• растущее количество HTTP запросов для получения статичного контента – так, например, на всех страницах только в теге <head> загружалось 11 JavaScript файлов;
• глобальные переменные, которые иногда перекрывали друг друга;

Решив, что с этим пора что-то делать, мы поставили себе первоочередную задачу: вынести все подключаемые по отдельности файлы из тега <head> в один минифицированный пакет. При этом код делился на сторонний и «наш», который планировалось проверять каким-то синтаксическим анализатором.

В этой статье мы расскажем вам о том, как решили эту задачу.

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

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


Рассмотрим по пунктам каждый элемент структуры затрат этого бизнес-процесса.

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

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

Моя карьера стартовала в самом начале нулевых, в течение 6 лет я работал программистом и консультантом разных уровней, а примерно 5 лет назад я полностью перепрофилировался в менеджера. Решение уходить из чисто технической области, как и многие, я принимал под впечатлением иллюзий о том, что у менеджеров намного больше денег, больше возможностей принимать решения и т.д. Как и писал TheR в упомянутом выше посте, многие мои предположения о работе менеджером оказались иллюзией, но некоторое количество очевидных (и не очень) плюшек в этой профессии все же присутствует. Я надеюсь, что эти два поста про плюсы и минусы такого перепрофилирования помогут кому-нибудь из Хабровчан принять взвешенное решение о дальнейшем развитии своей карьеры.

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

Введение

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

• Описания всех страниц будут находиться в отдельном проекте, я назвал его Autotests.WebPages
• Для каждой страницы будет создан отдельный класс, располагающийся в отдельном файле
• Названия классов будут совпадать с названиями web-страниц, например описание страницы MySite/Home/Help будет храниться в классе с названием Help
• Структура расположения этих файлов иерархическая и будет повторять дерево web-страниц. Например, страница Help будет иметь путь Root\Home\Help.cs относительно проекта и располагаться в пространстве имен (namespace) Autotests.WebPages.Root.Home
• Для доступа к страницам будет разработан некоторый фасад (Facade), статический класс Pages
• На практике страницы могут иметь много общего, поэтому вполне логично использовать наследование и вынесение некоторого функционала в отдельные хелперы

От переводчика: Думаю, что статьи по архитектуре приложения и организации кода наиболее важны на начальном этапе, т. к., в отличие от всего остального, основу приложения поменять очень трудно. [Оригинал статьи]

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

На мой взгляд, директивы являются основной изюминкой декларативного стиля Angularjs. Однако, если открыть комментарии пользователей в разделе официальной документации Angularjs, посвященной директивам, то вы увидите, что самый популярный из них: «Пожалуйста, перепишите документацию, сделайте ее более доступной и структурированной. Начинающему разработчику на Angularjs сложно в ней разобраться» («Please rewrite a clearer well structured documentation of directives., this is not friendly to first time angular developers»). С этим трудно не согласится, документация пока еще сыровата и в некоторых моментах приходится прилагать большие усилия, чтобы разобраться в логике и сути функционала. Поэтому я предлагаю вам свой вольный пересказ данной главы в надежде, что кому-то это позволит сэкономить время, а так же рассчитываю на вашу поддержку и участие в комментариях. Итак, поехали!
Часть 1

Для нас, как и для большинства социальных сетей, очень важны email-рассылки. Одной из интересных и сложных технических задач является корректное отображение писем на мобильных устройствах. Сейчас около 23% писем Badoo открывается именно на них, и это число постоянно увеличивается. А возможно, кто-то прямо сейчас читает наше письмо на своем интернет-холодильнике.
Сегодня мы расскажем, каких правил придерживаться в разработке электронных писем, как сохранить их юзабилити на мобильных устройствах, а также поделимся своими хитростями, накопленными в процессе работы.

Требования

С какими проблемами мы столкнулись и какие требования предъявляются к нашим письмам:

• письма должны корректно отображаться в множестве разных почтовых клиентов и браузеров;
• они должны быть оптимизированы под различные устройства на платформах iOS и Andriod (смартфоны с большим, средним и малым разрешением экрана; планшетные компьютеры);
• нужна обязательная поддержка Outlook 2003/2007/2010, т.к. он занимает большой сегмент использования;
• редактирование компонентов, которые применяются еще в 50 шаблонах писем;
• необходимо создавать универсальные блоки, которые будут подстраиваться под ситуацию, т.к. в письмах данные имеют динамическую структуру (например, письма переводят на 44 языка, в них меняются размеры блоков, изображений, размер текста).

За последние месяцы мы подготовили немало инфографики и объединили ее в общую серию под названием «Рунет в картинках». Сегодня мы рады представить Вашему вниманию несколько интересных фактов о российском рынке электронной коммерции.

Под катом — еще одна инфографика «Как россияне делают покупки в Интернете».

Четыре месяца назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

Масштабируемая Веб-архитектура и распределенные системы zip, ~1 mb.
Если кто-либо заинтересован в улучшении качества перевода — пишите в PM, открою доступ к колаборативному переводу на translatedby.com

Введение

Привет! В предыдущей части я описал основные проблемы, возникающие при работе с Selenium WebDriver, а так же привел пример обертки Browser. Вроде было не сложно, да?) Ну что ж, идем дальше. Надо разобраться с оставшимися проблемами:

• Описание элемента происходит одновременно с его поиском, т.е. на момент определения элемента он должен существовать в браузере. Очень часто решается путем написания getter для каждого элемента. Это накладно и плохо с точки зрения производительности
• ISearchContext.FindElements принимает только один параметр типа OpenQA.Selenium.By, т.е. мы не можем искать сразу по нескольким свойствам. Обычно элемент ищется по первому критерию, а затем начинается отсеивание по остальным
• Отсутствие многих, казалось бы, очевидных методов и свойств. Например: Exist, SetText, Select, SetCheck, InnerHtml и т.д. Вместо этого мы вынуждены довольствоваться Click, SendKeys и Text
• Множество проблем на различных браузерах, например на Firefox и Chrome элемент кликается, а на IE — нет. Приходится писать special cases, «костыли»
• Производительность. Да, драйвера работают не быстро. Впереди планеты всей как обычно IE — поиск может занимать секунды, иногда и десятки секунд

В этой части мы будем писать wrapper WebElement, который целиком направлен на пользователя, т.е. на разработчиков автотестов. Признаюсь, что в момент его написания моя задача заключалась в создании «фреймворка», которым должны пользоваться инженеры по ручному тестированию для написания автотестов. Естественно предполагалось, что они имеют весьма скромные познания в программировании. Поэтому было совершенно не важно, сколько тонн кода будет в самом фреймворке и насколько он будет сложным внутри. Главное, чтобы снаружи он был прост как три буквы. Предупреждаю, будет много кода и мало картинок =)

Некоторое время назад я публиковал статью «Эффект слайдов на сайте. Через грабли на собственном велосипеде».
Статья справедливо набрала множество замечаний, в основном, касающихся отсутствия практической части и примеров кода.
Предлагаю вашему вниманию переработанную статью, снабженную живыми примерами.