Всем привет. На связи Омельницкий Сергей. Не так давно я вел стрим по реактивному программированию, где рассказывал про асинхронность в JavaScript. Сегодня я бы хотел законспектировать этот материал.

Но перед тем как начать основной материал нам нужно сделать вводную. Итак, давайте начнем с определений: что такое стек и очередь?

Стек — это коллекция, элементы которой получают по принципу «последний вошел, первый вышел» LIFO

Очередь — это коллекция, элементы которой получают по принципу («первый вошел, первый вышел» FIFO

Окей, продолжим.

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

Согласно статистике, на июль 2019 года наивысшая ставка по банковским депозитам в России не превышает 9,5% годовых, что не очень много. Других «пассивных» способов сохранения и приумножения денег тоже не так много – например, стоимость квадратного метра недвижимости в столице фактически не растет уже много лет.

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

Исследование, проведенное Google, имело два ключевых вывода:

• Пользователю нужно всего 1/50 до 1/20 секунды, чтобы оценить, красивый сайт или нет.
• «Визуально сложные» сайты оцениваются как менее красивые, чем их простые аналоги.

Другими словами, исследование показало — чем проще дизайн, тем лучше.

Но почему?

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

Приступим!

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

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

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

• TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
• BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
• TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
• DDD — bound contexts, ubiquitous language, domain...
• FDD — да сколько можно?
• MDD — cерьезно, на основе диаграмм?
• PDD — ...

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

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

Стремление уйти от ручного регрессионого тестирования — хороший повод внедрить автотесты. Вопрос, какие именно? Разработчики интерфейсов Наталья Стусь и Алексей Андросов вспомнили, как их команда прошла несколько итераций и построила тестирование фронтенда в Авто.ру на базе Jest и Puppeteer: юнит-тесты, тесты на отдельные React-компоненты, интеграционные тесты. Самое интересное из этого опыта — изолированное тестирование React-компонентов в браузере без Selenium Grid, Java и прочего.



Алексей:
— Для начала надо немного рассказать, что такое Авто.ру. Это сайт по продаже машинок. Там есть поиск, личный кабинет, автосервисы, запчасти, отзывы, кабинеты дилеров и многое другое. Авто.ру — очень большой проект, очень много кода. Весь код мы пишем в большой монорепе, потому что это все перемешивается. Одни и те же люди делают схожие задачи, например, для мобильных и десктопа. Получается много кода, и монорепа нам жизненно необходима. Вопрос — как ее тестировать?

Вольный перевод публикации How React Hooks can replace React Router.
Автор Peter Ekene Eze.

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

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

С этой целью мы сравним React Router и hooksrouter на наглядных примерах. Для начала давайте поближе посмотрим на React Router.

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

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

Если дефолтный порядок не устраивает, то разработчики прибегают к свойству z-index: оно даёт контроль над виртуальной осью z (глубиной), которая концептуально проходит «сквозь» страницу. Таким образом, элемент с более высоким z-index отображается «ближе» к пользователю, то есть рисуется поверх элементов с более низкими индексами.

Введение в микросервисную архитектуру

Часть 1 из 10

Адаптация статей Ewan Valentine.

Это серия из десяти частей, я постараюсь раз в месяц писать про построение микросервисов на Golang. Я буду использовать protobuf и gRPC в качестве основного транспортного протокола.

Стек, который я использовал: golang, mongodb, grpc, docker, Google Cloud, Kubernetes, NATS, CircleCI, Terraform и go-micro.

Зачем мне это? Поскольку мне потребовалось много времени, чтобы разобраться в этом и решить накопившиеся проблемы. Так же я хотел поделиться с вами тем, что я узнал о создании, тестировании и развертывании микросервисов на Go и другие новые технологии.

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

• грузы
• инвентарь
• суда
• пользователи
• роли
• аутентификация

В этой статье я постараюсь подробно разобрать механизм реализации замыканий в JavaScript. Для этого я буду использовать браузер Chrome.

Начнем с определения:

Замыкания  - это функции, ссылающиеся на независимые (свободные) переменные. Другими словами, функция, определённая в замыкании, 'запоминает' окружение, в котором она была создана.

MDN

Если вам что-то не понятно в этом определении, это не страшно. Просто читайте дальше.

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

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

Итак, приступим:


Рисунок 1

В июне на конференции РИТ++ мы с коллегой Игорем Должиковым делились опытом автоматизации процесса разработки сервисов на Go — от первого коммита и до релиза в продакшн-окружение Kubernetes (да-да, видео начинается с 07:16, и нам тоже это не нравится). С момента публикации мастер-класса время от времени я получаю вопросы по тем или иным темам, затронутым в нем. Пожалуй, самые горячие вопросы достойны отдельного рассмотрения, и сегодня я хотела бы поговорить о процессе сборки приложения. Затрагиваемые темы актуальны не только при подготовке сервисов, но и вообще для любых приложений, написанных на Go.

Всё, что описано в этой статье, актуально для текущей версии Go — 1.9.

Введение

Некоторое время назад мне потребовалось решить задачу сегментации точек в Point Cloud (облака точек — данные, полученные с лидаров).

Пример данных и решаемой задачи:

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

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

Анимация в приложениях React — популярная и обсуждаемая тема. Дело в том, что способов ее создания очень много. Некоторые разработчики используют CSS, добавляя теги в HTML-классы. Отличный способ, его стоит применять. Но, если вы хотите работать со сложными видами анимаций, стоит уделить время изучению GreenSock, это популярная и мощная платформа. Также для создания анимаций существует масса библиотек и компонентов. Давайте поговорим о них.

Почти 60% посетителей сайта покидают его в том случае, если его загрузка занимает более 3 секунд. 80% таких посетителей на сайт уже не возвращается. Это говорит о том, что успех веб-проекта не в последнюю очередь зависит от его скорости. Автор материала, перевод которого мы сегодня публикуем, хочет рассказать о методиках повышения производительности React-приложений.

Результаты оптимизации приложения

Agile дает реальные и действенные ответы на вопрос, который не дает спокойно спать руководителям: «Как оставаться успешным в быстро меняющемся и непредсказуемом мире?» Эта методология уже завоевала рынок, доказав, что является одним из лучших подходов для создания и доставки программного обеспечения. «Agile для всех» адресован практикам, из этой книги вы узнаете, как целые организации — от менеджеров по продукту и разработчиков до маркетологов и руководителей — могут использовать «гибкий» подход.

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

Мы это сделали!

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2588 в закладки, 429k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Мы ее переводим, ведь мужик дело говорит.

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

За перевод спасибо Андрею Пахомову.

Теория Информации была разработана К. Э. Шенноном в конце 1940х годов. Руководство Лабораторий Белла настаивало, чтобы он назвал ее «Теория Связи», т.к. это намного более точное название. По очевидным причинам, название «Теория Информации» обладает значительно большим воздействием на публику, поэтому Шеннон выбрал именно его, и именно оно известно нам по сей день. Само название предполагает, что теория имеет дело с информацией, это и делает ее важной, поскольку мы все глубже проникаем в информационную эпоху. В этой главе я затрону несколько основных выводов из этой теории, приведу не строгие, а скорее интуитивно понятные доказательства некоторых отдельных положений этой теории, чтобы вы поняли, чем на самом деле является «Теория Информации», где вы можете ее применять, а где нет.

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

Так получилось, что о тестировании верстки мы задумались не сразу. Ну съедет какая-нибудь рамка на пару пикселей, ну поправим. В конце концов, есть же тестировщики — мимо них и муха не пролетит. Но человеческий фактор все-таки не обманешь — обнаружить незначительные изменения в пользовательском интерфейсе далеко не всегда физически возможно даже тестировщику. Вопрос встал ребром, когда была затеяна серьезная оптимизация верстки и переход на БЭМ. Тут без потерь бы точно не обошлось и нам позарез стал нужен автоматизированный способ обнаружения ситуаций, когда в результате правок что-то в UI начинает меняться не так, как было задумано, или не там, где было задумано.

В большом проекте может возникнуть задача идентификации изменений для конечного пользователя по отличиям в коде фронтенда приложения. Разработчик из Яндекс.Маркета Никита Сидоров @nickshevr рассказал, как мы решали эту проблему при помощи библиотеки Diffector, о построении и анализе графа модулей в Node.js-приложениях и о поиске дефектов в коде до его запуска.



— Сегодня я постараюсь быть с вами максимально откровенным.

СДСМ закончился, а бесконтрольное желание писать — осталось.



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

Этой статьёй я начну серию о том, как мне видится автоматизация.
По ходу дела разберёмся с этапами автоматизации, хранением переменных, формализацией дизайна, с RestAPI, NETCONF, YANG, YDK и будем очень много программировать.
Мне означает, что а) это не объективная истина, б) не безоговорочно лучший подход в) мой взгляд даже в ходе движения от первой к последней статье может поменяться — честно говоря, от стадии черновика до публикации я переписывал всё полностью дважды.

Рассмотрим реализацию запроса данных к API c помощью нового друга React Hooks и старых добрых товарищей Render Prop и HOC (Higher Order Component). Выясним, действительно ли новый друг лучше старых двух.