На прошлой неделе на Vue.js London я рассказал, что произойдет в следующей мажорной версии Vue. Этот пост содержит подробный обзор плана.

Всем привет!

За время моей работы с вебпаком у меня накопилась пара интересных советов, которые помогут вам приготовить отлично оптимизированное приложение. Приступим!

Сегодня, в девятой части перевода руководства по Node.js, мы поговорим о работе с файлами. В частности, речь пойдёт о модулях fs и path — о файловых дескрипторах, о путях к файлам, о получении информации о файлах, об их чтении и записи, о работе с директориями.

Node.js — это серверная платформа. Основная задача сервера — как можно быстрее и эффективнее обрабатывать запросы, поступающие от клиентов, в частности — от браузеров. Восьмая часть перевода руководства по Node.js, которую мы публикуем сегодня, посвящена протоколам HTTP и WebSocket.

Если вы интересуетесь программированием, то возможно слышали фразу:

«Каждый должен учиться программированию, потому что оно учит думать.»

— Стив Джобс

Наверное вы тоже задавались вопросом, что значит думать как программист?

По сути, речь идет о более эффективном способе решения задач.

Данный пост ставит целью научить вас этому.

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

Вы применяете React для создания пользовательских интерфейсов? Автор материала, перевод которого мы публикуем, говорит, что он тоже работает с React. Здесь он хочет рассказать о том, почему для написания React-приложений стоит использовать ReasonML.



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

Меня зовут Дима, я работаю в офисе Яндекса в Санкт-Петербурге и занимаюсь внутренними сервисами в команде разработки интерфейсов Толоки. В этом году я подготовил лекцию для Школы разработки интерфейсов. Ниже — её расшифровка.

Что такое доступность интерфейсов? Для кого она важна и зачем к ней нужно стремиться? Каковы основные приемы, которые делают интерфейс доступным? Кроме этих вопросов, лекция проясняет принципы, которые лежат в основе ассистивных технологий. Я постарался разобрать теорию и большое количество практических примеров, а также показать процесс работы скринридера.


— Что скрывается под модным нынче термином accessibility? Какие у вас есть варианты? Для слепых, чтение с экрана, с ограниченными возможностями, координация движений… Все верно. Доступность — возможность использования интерфейса всеми, независимо от физических или технических ограничений.

Сегодня, в переводе седьмой части руководства по Node.js, мы поговорим об асинхронном программировании, рассмотрим такие вопросы, как использование коллбэков, промисов и конструкции async/await, обсудим работу с событиями.

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

Материал, перевод которого мы публикуем сегодня, посвящён рассказу о внутренних механизмах замыканий и о том, как они работают в JavaScript-программах.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.3 RC2, Codeception 2.5 и другие релизы, типизированные свойства в PHP 7.4, концепт предзагрузки кода от Дмитрия Стогова, порция полезных инструментов, и многое другое.
Приятного чтения!

Есть множество типов архитектур ПО со своими плюсами и минусами. Далее поговорим об особенностях наиболее популярных из них и расскажем о своем переходе на микросервисы.

Честно говоря, мне уже неловко в очередной раз говорить об Атомарном дизайне. Про концепции дизайн-систем сказано практически все и, казалось бы, добавить уже нечего. Но постойте! Ведь атомы в реальном мире из чего-то состоят: протоны, нейтроны, электроны… Можно ли сопоставить со структурой атома дизайн-функционал, с котором мы работаем? Я уверен, что ответ положительный и вот почему…

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

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

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

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

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

С этим определились, осталось только разобраться, и как же теперь все сделать круто. Где тут в интернете про это пишут? — Да везде! И вот, чтобы разобраться со всем многообразием современных технологий, фреймворков и библиотек, мы проводим профессиональную конференцию Frontend Conf. Отбирая для неё темы мы сделали упор не на хайповость, а на полезность докладов. Любой профессиональный фронтендер придя на конференцию может быть уверен, что найдёт для себя много полезных докладов соответствующих его уровню знаний. Какие именно доклады в итоге вошли в программу, расскажу под катом.

В этом году мы уже писали на Хабре про наш проект SmartCalls.io – визуальный конструктор звонков, созданный для бизнес-пользователей. Проект решает задачу бизнеса по массовым обзвонам клиентов: создается визуальный сценарий звонка, загружается Excel-файл с номерами телефонов и далее создается кампания по обзвону. Запускается кампания – начинается обзвон клиентов; в любой момент можно смотреть статистику, приостанавливать кампанию, подкручивать настройки. Клиенты были довольны, пока не выяснилось, что иногда надо обзванивать не просто много людей, а ОЧЕНЬ, ОЧЕНЬ много. Под катом – суть проблемы и как мы ее победили с помощью хайпового (не безосновательно) языка программирования.

Привет, Хабр! Представляю вашему вниманию перевод статьи Julie Marchant Fix or Kill Automatically Installed JavaScript?

В эссе Ричарда Столлмана "Ловушка JavaScript" отмечается, что люди запускают несвободные программы, которые автоматически незаметно устанавливаются в их браузеры каждый день. На самом деле он сильно преуменьшил проблему. Мало того, что большинство пользователей ежедневно запускают несвободные программы просто просматривая веб-страницы, они запускают десятки или даже сотни таких программ каждый день. Ловушка JavaScript чрезвычайно реальна и плодовита. Считается, что работа с сайтами будет нарушена без этих нестандартных, обычно проприетарных, расширений HTML, что веб-браузеры даже не предлагают очевидной возможности отключить JavaScript. Утверждается, что отключение JavaScript приведет только к путанице.

Очевидно, что нам нужно решить эту проблему. Однако, сосредоточив внимание на том являются ли скрипты "тривиальными" или свободными, г-н Столлман упускает важный момент: автоматическая незаметная установка программного обеспечения сама по себе является главной проблемой. То, что по большей части программное обеспечение оказывается несвободным, является лишь побочным эффектом.

Сегодня Гуглу официально исполнилось 20 лет! Двадцать лет, как в наш язык прочно вошло слово "гуглить".

Вот так Google выглядел два десятилетия назад:


На самом деле, дата основания компании — 4 сентября 1998 года. Но технология PageRank, легшая в основу поиска Google, родилась еще в январе 1996 года как научно-исследовательский проект Ларри Пейджа и Сергея Брина, которые тогда учились в Стэнфордском университете в Калифорнии.

Основной домен поисковика google.com был зарегистрирован 15 сентября. Но в самой компании день рождения празднуется именно 27 сентября. Примечательно, что Пейдж и Брин первоначально назвали свою поисковую систему BackRub, потому что система проверяла обратные ссылки для оценки важности сайта

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

Хотел бы поделиться своим опытом использования redux в enterprise приложении. Говоря о корпоративном ПО в рамках статьи, я акцентирую внимание на следующих особенностях:

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

Первые два пункта накладывают ограничения по запасу производительности. Об этом чуть позже. А сейчас, предлагаю обсудить проблемы, с которыми сталкиваешься, используя классический redux – workflow, разрабатывая что либо, сложнее чем TODO – list.

MVC + Scenario Против Толстых Контроллеров

Современные PHP фреймворки (Symphony, Laravel, далее везде) убедительно показывают, что реализовать паттерн Model-View-Controller не так уж просто. Все реализации почему-то склонны к Толстым Контроллерам (fat controllers), осуждаемыми всеми, и разработчиками, и самими фреймворками.

Почему все так? И можно ли с этим как-то справиться? Давайте разбираться.