Привет, это снова Катя из Яндекс.Денег. Продолжаю свою историю о том, как я перестала верстать и начала жить. В первой части я рассказала, как меня сюда занесло и чем занимаются наши фронтендеры. Сегодня — про фронтовый стек, откуда там React и куда делся БЭМ.

Спойлер: БЭМ пока никуда не делся ¯\_(ツ)_/¯. Погнали!



Внимание: высокая концентрация фронтенда. Много текста, картинок и кода, как обещала.

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

Авторы статьи: Юрий Ветров, Артём Гладков, Евгений Долгов и Андрей Сундиев

Несколько лет портальная дизайн-команда Mail.Ru Group занимается обновлением и унификацией продуктов. У нас сформировалась дизайн-система, на которой работают медиа-проекты, мобильный веб и частично productivity-сервисы (постепенно подключаются и другие продукты), сформировался стиль пиктограмм и иллюстраций, стандартизируются промо-письма и промо-сайты. Конечно, ещё не во всех сервисах всё хорошо, а где-то первый редизайн не решил всех проблем, но огромный рывок за прошедшие годы трудно не заметить. Чтобы ускорить процесс обновления и сделать нашу работу публичной, мы открываем наружу часть нашей дизайн-системы Paradigm.

Недавно мне довелось побывать на встрече участников проекта FreeCodeCamp в Сан-Франциско. Если кто не знает, Free Code Camp — это сообщество, нацеленное на изучение JavaScript и веб-программирования. Там один человек, который готовился к собеседованиям на позицию фронтенд-разработчика, попросил меня подсказать, какие вопросы по JavaScript стоит проработать. Я немного погуглил, но не смог найти подходящего списка вопросов, на который я бы мог дать ссылку и сказать: «Разбери эти вопросы и работа твоя». Некоторые списки были близки к тому, что мне хотелось найти, некоторые выглядели очень уж простыми, но все они были либо неполными, либо содержали вопросы, которые вряд ли кто станет задавать на реальном собеседовании.

Все мы играли в потрясающие изометрические игры, будь то первые Diablo, Age of Empires или Commandos. При первой встрече с изометрической игрой можно задаться вопросом: двухмерная она, трёхмерная или нечто совершенно другое. Сам мир изометрических игр обладает волшебной притягательностью для разработчиков. Давайте попробуем раскрыть тайну изометрической проекции и создадим простой изометрический уровень.

Для этого я решил использовать Phaser с кодом на JS. В результате у нас получится интерактивное приложение HTML5.

Учтите, что это не туториал по разработке на Phaser, мы просто используем его для удобного ознакомления с базовыми концепциями создания изометрической сцены. Кроме того, в Phaser есть простые способы создания изометрического контента, например, Phaser Isometric Plugin.

Для упрощения при создании сцены мы будем использовать тайлы.

Доброго времени суток, дорогие хабрахабровцы!

Всегда хочется, что бы твой сайт выглядел одинаково хорошо на разных устройствах, включая и мобильные. Но, если поведение в браузерах Android во многом предсказуемо, то с iOS возникает ряд «сюрпризов». О них сегодня и поговорим!

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

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

В последнее время очень мне часто приходится использовать всем известный паттерн «Visitor» (он же Посетитель, далее — визитор). Раньше же я им пренебрегал, считал костылём, лишним усложнением кода. В данной статье я поделюсь своими мыслями о том, что в этом паттерне, на мой взгляд, хорошо, что плохо, какие задачи он помогает решить и как упростить его использование. Код будет на C#. Если интересно – прошу под кат.

В прошлый раз мы, в качестве подготовки к разговору об ArrayBuffer и SharedArrayBuffer, рассмотрели разные подходы к управлению памятью. Как вы, должно быть, помните, JS-движок играет роль посредника при работе с памятью, однако, новые объекты дают программисту некоторые ручные инструменты. Для чего это может понадобиться?

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

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

В начале описывается сам процесс автоматизации со схемами и диаграммами. После описания процесса рассмотрены инструменты, которые предназначены для автоматизации тестирования OpenStack.

В феврале мы запустили бесплатный онлайн-курс программирования на С++, рассчитанный на продвинутых разработчиков. Цели было в основном две — сделать так, чтобы в мире было больше хороших программистов, а заодно набрать себе пополнение в команду. Идея взлетела: участвовать в первом наборе захотело 185 человек из 57 городов и 8 стран. В курсанты попало 30 из них, но со словами «неинтересно» ушёл только 1. Остальные по итогам курса сообщили, что было в целом круто и они с пользой провели время.



Обкатав всю затею и учебный процесс на начальном бета-наборе, мы решили повторить курс ещё раз. Набор уже во всю идёт, подать заявку можно до понедельника, 26 июня. Чему, как и кто учит — рассказываем внутри.

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



Декораторы обрели популярность благодаря их применению в Angular 2+. В Angular этот функционал реализуется средствами TypeScript. Сейчас предложение по введению декораторов в JavaScript находится в состоянии Stage 2 Draft. Это означает, что работа над ними, в основном, завершена, но они всё ещё могут подвергаться изменениям. Декораторы должны стать частью следующего обновления языка.

Объектное Реактивное Программирование

Дмитрий Карловский из SAPRUN представляет… ммм...

Это — текстовая версия одноимённого выступления на FrontendConf'17. Вы можете читать её как статью, либо открыть в интерфейсе проведения презентаций, либо посмотреть видео.

Многие считают, что микросервисы — это очень сложно. На самом же деле, при правильном подходе, это совсем не так.

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

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

Два подхода к разработке через тестирование вызывают особенно много споров — из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. Старшие инженеры по автоматизации тестирования «Альфа-Лаборатории» Юлия Ковалева и Анна Чернышева рассказывают базовые вещи о сходстве и различиях двух популярных методик и то, какой подход у них используется в самой компании.

Если вы наслышаны о так называемых «трансдьюсерах», но до сих пор не применяете их в JavaScript-разработке, сегодня у вас есть шанс найти ответы на вопросы: «Что такое трансдьюсеры?» и «Как ими пользоваться?». Это позволит вам понять, нужны ли они в ваших проектах, и, если нужны — поможет приступить к их использованию.



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

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

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

Ах да, еще одно: в прошлой статье меня упрекали за портрет Сталина. Мне казалось, что лучше Сталин, чем все вот эти вот котики, но вы сами попросили.


P.S. Так как эта публикация вводная — в футере будут публиковаться ссылки на все опубликованные статьи из этого цикла.
P.P.S. Под катом много картинок.

Есть такая конференция ADD (Application Developer Days) на которой любят всякие архитектурные штуки для разработки ПО обсуждать, обычно эти штуки заканчиваются тоже на xDD — DDD, TDD, MDD и т.д.

Вот к примеру на прошлой конференции задались вопросом, а что такое DDD (Domain Driven Design)?
А Николай Гребнев из CUSTIS — встал и ответил.

Видео доклада: