Node.JS *

Продолжение публикации «Сервер push сообщений»

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



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

Аналогично можно изменить ширину списка контактов и списка сообщений.

Отправка сообщений анимирована, какой либо анимации при отправке сообщений в других программах не было.

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

Эта история началась примерно 1.5 года назад. Связана она с проигрыванием музыки в различных браузерах и платформах, на которых они запускаются. Путь полный “боли и страдания” осознания того, что легкая на первый взгляд задача может оказаться не такой уж и легкой, а “незначительные” детали, которым не придаешь значения в самом начале, могут повлиять на всё.

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

Многие разработчики Node.js для связывания модулей используют исключительно создание жёсткой зависимости с помощью require(), однако существуют и другие подходы, со своими плюсами и минусами. О них я в этой статье и расскажу. Будут рассмотрены четыре подхода:

• Жёсткие зависимости (require())
• Внедрение зависимостей (Dependency Injection)
• Локаторы служб (Service Locator)
• Контейнеры внедряемых зависимостей (DI Container)

Таким образом я описал строение системы управляемых программных аксессуаров.

Упрощенная модель включает в себя главный процесс(bobaoskit.worker) и скрипты аксессуаров(использующие объекты bobaoskit.sdk и bobaoskit.accessory). От главного процесса идет запрос к аксессуару для контроля некоторых полей. От аксессуара, в свою очередь, идет запрос к главному на обновление статуса.

В качестве примера возьмем обычное реле.

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

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

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

В любом современном интернет сервисе можно выделить всего две основные функции:

• Первая — это авторизация пользователей.
• Вторая — это моментальная отправка некоего события с сервера на клиент.

Первый пункт, думаю, в пояснении не нуждается.

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

Для лучшего понимания сервис не некий сферичный в вакууме. Сервис можно представить как:

• Папка с файлами в облаке. Информация о изменении, добавлении и удалении пересылается другим пользователям или текущему пользователю, но на другие устройства.
• Компьютерная программа чтения логов сервера, при появлении записей «error» отсылающая содержимое записи пользователю на мобильный телефон.
• Видео-глазок (камера), делающий снимки при движении около двери квартиры.
• Сервис получающий телеметрию из приложения android-auto.
• Похожий на предыдущий пункт сервис, позволяющий узнать дошел ли ребенок до школы или пришел из школы домой.

Список можно расширять до бесконечности, приведены, как пример, лишь наиболее известные варианты использования.

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

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

Код скриптов сервера открыт и бесплатен

18 января было объявлено о выходе платформы Node.js версии 11.7.0. Среди заметных изменений этой версии можно отметить вывод из разряда экспериментальных модуля worker_threads, который появился в Node.js 10.5.0. Теперь для его использования не нужен флаг --experimental-worker. Этот модуль, с момента появления, оставался достаточно стабильным, поэтому и было принято решение, отражённое в Node.js 11.7.0.

Автор материала, перевод которого мы публикуем, предлагает обсудить возможности модуля worker_threads, в частности, он хочет рассказать о том, зачем нужен этот модуль, и о том, как в JavaScript и в Node.js, по историческим причинам, реализована многопоточность. Здесь же речь пойдёт и о том, какие проблемы сопряжены с написанием многопоточных JS-приложений, о существующих способах их решения, и о будущем параллельной обработки данных с использованием так называемых «потоков воркеров» (worker threads), которые иногда называют «рабочими потоками» или просто «воркерами».

В этой статье я расскажу про одну малоизвестную технологию, которая нашла ключевое применение в нашей онлайн-игре для программистов. Чтобы долго не тянуть резину, сразу спойлер: кажется, что такого шаманства в нативном коде Node.js, к которому мы пришли после нескольких лет разработки, до нас еще никто не делал. Движок изолированных виртуальных машин (опенсорсный), который работает под капотом проекта, был написан специально для его нужд, и на данный момент используется в продакшене нами и еще одним стартапом. А возможности изоляции, которые он дает, не имеют аналогов и заслуживают, чтобы о них рассказали.

Но давайте обо всем по порядку.

Предыстория

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

Жаль лишь, что совсем немного реальных проектов, связанных с каждодневным заработком, могут предложить своим разработчикам такие чувства. Чаще всего для того, чтобы не терять страсть к программированию, энтузиастам приходится затевать интрижку на стороне: программистское хобби, пет-проект, модный open-source, просто скрипт на питоне по автоматизации своего умного дома… или поведения персонажа в какой-нибудь популярной онлайн-игре.

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

На Хабре уже давно не было статей по Метеору, поэтому хотелось бы поделиться нашей историей.



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

Сегодняшние занятия учебного курса по React, перевод которого мы публикуем, посвящены продолжению работы над TODO-приложением и свойствам компонентов.



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

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

Этот пост представляет собой описание того, как я узнал больше о веб-разработке на стороне сервера с помощью Node.js, и краткое сравнение написания простого HTTP-сервера с использованием 3 разных сред, Express, Koa.js и Hapi.js.

Примечание: если вы опытный разработчик Node.js, вы, вероятно, подумаете о том, что это все элементарно/просто. ¯\_(ツ)_/¯.

Любой клиент-серверный проект подразумевает четкое разделение кодовой базы на 2 части (иногда больше) — клиентскую и серверную. Зачастую, каждая такая часть оформляется в виде отдельного независимого проекта, поддерживаемого своей командой девелоперов.

В этой статье я предлагаю критически посмотреть на стандартное жесткое разделение кода на бэкенд и фронтенд. И рассмотрим альтернативу, где в коде нет четкой грани между клиентом и сервером.

→ Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов

Сегодня, во второй части перевода материала, посвящённого тестированию Node.js-проектов, мы поговорим об оценке эффективности тестов и об анализе качества кода.

Автор материала, первую часть перевода которого мы сегодня публикуем, говорит, что он, как независимый консультант по Node.js, каждый год анализирует более 10 проектов. Его клиенты, что вполне оправданно, просят его обратить особое внимание на тестирование. Несколько месяцев назад он начал делать заметки, касающиеся ценных приёмов тестирования и встречающихся ему ошибок. В результате получился материал, содержащий три десятка рекомендаций по тестированию.



В частности, речь здесь пойдёт о выборе подходящих в конкретной ситуации типов тестов, об их правильном оформлении, об оценке их эффективности, и о том, где именно в CI/CD-цепочках нужно их размещать. Некоторые из приведённых здесь примеров проиллюстрированы с использованием Jest, некоторые — с использованием Mocha. Этот материал, в основном ориентирован не на инструменты, а на методологии тестирования.

→ Тестирование Node.js-проектов. Часть 2. Оценка эффективности тестов, непрерывная интеграция и анализ качества кода

Аннотация

В данной статье я бы хотел поделиться общими впечатлениями от использования BaaS – решения под названием Parse для разработки бэкэнда Android-приложения, рассказать о всех «подводных камнях», с которыми мне пришлось столкнуться в период разработки. Впервые эту платформу мне посоветовали коллеги по работе, когда я был юниором, и за плечами был всего 1 коммерческий проект. Мотивацией к написанию данной статьи послужили нервы и время, которые я потратил для поиска совместимых версий библиотек и обдумывание странных решений разработчиков платформы, ну или просто потому, что я до сих пор не нашел статей по этому поводу. Так же я ничего не буду рассказывать о том, что такое Parse и как его подключить и настроить, но на всякий случай я оставлю все необходимые ссылки, где можно почитать об этом.

Товарищи инженеры, как и было обещано в анонсе, половина лекций (а это 51) уже доступны для просмотра на ютюбе и я продолжу их записывать в 2019 году. Часть из нужно будет перезаписать, потому, что в первых лекциях не самый лучший звук и потому, что очень простые темы у меня пока не очень хорошо получаются. Лучше вышли сложные и актуальные темы, которые мне и самому более интересно рассказывать. Я бы не сказал, что это курс для начинающих, скорее, это курс для тех, кто уже знает синтаксис. За это время поступило множество предложений, как улучшить способ подачи материала: делить на более короткие лекции, подготовить задачи для практического освоения, записывать семинары и ответы на вопросы студентов, добавить в программу разбор целого ряда спорных и холиварных тем. Но не все сразу, я и так посвящаю этому треть жизни.

Об альтернативах Express, где и почему стоит отказаться от Express'a и небольшие замеры в переводе под катом

Автор материала, перевод которого мы публикуем, собрал 19 идей, которые могут оказаться полезными для тех Node.js-разработчиков, которые хотят повысить свой профессиональный уровень в 2019 году. Мир JavaScript огромен, поэтому освоить всё то, о чём пойдёт здесь речь, попросту нереально. Вряд ли найдётся кто-то, кто владеет всем этим в совершенстве. Однако кое-что в этом обзоре вполне может пригодиться именно вам.

Всем привет!

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