Дизайнер учит код

Зачем нужно тестовое задание для дизайнера и почему его нельзя делать до знакомства с командой

2022-11-07T09:48:24.367Z

Зачем нужно тестовые задания для дизайнера?

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

В каких случаях дают тестовые задания?

Если человек не сталкивался с определённой спецификой, а она нужна в работе. Например, кандидат проектировал интерфейсы для web, а работать предстоит над мобильным приложением. Тут нужно проверить, как человек справится и это оправдано.

Также, тестовое задание могут дать, если у кандидата мало опыта. Как правило, это касается начальных позиций: стажёров или junior-дизайнеров. Опять же, нужна проверка навыков и она оправдана.

Иногда, тестовое задание дают, потому, что «так принято в компании», лично у руководителя или нанимающего менеджера. Даже если с кандидатом и всё понятно. Подобная риторика — плохой знак по целому ряду причин и лучше от сотрудничества сразу отказаться.

В остальных случаях, считаю, что тестовое задание давать нецелесообразно. После просмотра портфолио и общения с кандидатом, с вероятностью в 90% всё будет понятно.

Как выглядит плохое тестовое задание?

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

Во-первых, это был реальный проект и результат моей работы компания могла бы использовать не заплатив мне.

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

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

Вот ещё несколько моментов, на которые стоит обратить внимание. Размытые критерии задачи (непонятно, как будут оценивать результат), сжатые сроки (компания торопится) или ещё хуже, когда компания сама устанавливает сроки для выполнения тестового задания. Это всё повод задуматься и отказаться от сотрудничества. Вполне возможно, что подбор происходит «на потоке».

Как выглядит хорошее тестовое задание?

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

Какие альтернативы бывают у тестовых заданий?

Техническое интервью

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

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

Тестовый день

С тестовым днём дела обстоят иначе. Он полностью должен исключать тестовое задание. Суть в том, что кандидат «устраивается» в компанию на один день и выполняет свои обязанности так, если бы он уже работал по-настоящему.

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

Что даёт знакомство с командой?

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

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

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

Что плохого в том, чтобы сделать тестовое задание до знакомства с командой?

Если резюмировать всё, что я сказал выше, то получается следующее.

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

Во-вторых, кандидата могут обмануть.

В-третьих, можно банально быстро «выгореть», если кандидат активно ищет работу.

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

А если кандидата торопят или для начала общения нужно сделать тестовое — скорее всего подбор на вакансию происходит «на потоке» и компания не заинтересована в конкретном человеке.

Вывод

Конечно, политика «сперва общение — потом тестовое» тоже не страхует от всего, что я написал выше. Но по крайней мере она кратно снижает риски.

Домашняя метеостанция. Часть 2

2020-10-31T21:03:49.898Z

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

💫 Вдохновлено мечтой.

Название

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

Zarya Meteostation — это метеостанция на базе Iskra JS, которая собирает погодные данные и передаёт их на сервер. Подробнее про неё написано в первой части цикла.

Zarya API — это API, который принимает погодные данные от Zarya Meteostation. В данном материале речь пойдёт о Zarya API.

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

Кажется, это звучит лучше, чем безликая «домашняя метеостанция».

Общее описание API

Zarya API — это небольшой API, написанный на Node JS, позволяющий принимать данные с Zarya Meteostation (метеостанция на основе Iskra JS) и записывать их в MongoDB. Обладает методами GET (получение), POST (добавление), PUT (изменение) и DELETE (удаление). Имеет Basic-авторизацию через HTTP.

Как работает API

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

Клиент (в моём случае, это Iskra JS) по специальному URL отправляет запрос на сервер. Чтобы сервер принял запрос, на нём нужно авторизоваться. В противном случае, сервер отклонит его.

Затем, происходит проверка передаваемых данных с помощью схемы валидации. Если с данными всё хорошо, они записываются в базу.

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

Например, чтобы Zarya Assistant получил текущую погоду, нужно выполнить запрос и вернуть данные.

Это несколько упрощённое описание работы API. Можно самостоятельно ознакомиться с репозиторием на GitHub и вникнуть в код.

Stack технологий

Сервер

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

Хостинг я выбрал давно — это Digital Ocean. В качестве ОС для сервера я выбирал между Debian и Ubuntu. На первый взгляд, особой разницы нет. После небольшого исследования, я выяснил, что Debian более стабильный, потому и выбрал его.

За Node JS на сервере отвечает NVM (Node Version Manager) — это небольшой скрипт, который позволяет легко контролировать версии Node JS.

Следить за процессами Node JS мне помогает менеджер процессов pm2. Он может автоматически перезапускать приложения, если они прекращают работу.

Чтобы мой API был доступен не только по IP-адресу, но и по URL, нужен веб-сервер и домен. Домен у меня есть, а веб-сервера не было. Сначала я установил и настроил Nginx. Выбрал его только из-за того, что он наиболее популярный. Но затем, по совету моего бывшего коллеги Саши Купоросова, я обратил внимание на Caddy.

Caddy оказалось гораздо легче настраивать, чем Nginx. К тому же он автоматически запрашивает SSL-сертификаты для доменов через Let’s Encrypt и поддерживает HTTP 2. Nginx тоже может автоматически получать сертификаты и поддерживает HTTP 2, но для этого нужно устанавливать Certbot, настраивать его через Cron, и конфигурировать каждый файл каждого сайта. В Caddy один конфигурационный файл на всё.

В качестве защиты работает UFW (Uncomplicated Firewall) — это довольно простой firewall, но обращаться с ним нужно аккуратно. Иначе можно остаться без доступа по SSH.

Мой комплект Raspberry Pi 3 Model B+, который несколько раз спасал меня от потери доступа по SSH к основному серверу

У меня почти не было опыта взаимодействия с UNIX-системами (кроме macOS) и чтобы потренироваться, я купил себе Raspberry Pi 3 Model B+. Мой основной страх в тот момент — это то, что я что-нибудь сделаю не так и потеряю удалённый доступ по SSH. А если я всё испытаю локально на Raspberry Pi и что-то пойдёт не так, то я всегда смогу всё исправить. И сейчас я могу уверенно сказать, что это было стратегически верным решением. После того как я несколько раз терял доступ по SSH, мне удалось избежать допущенных ошибок на основном сервере.

API

API построен на ряде библиотек, каждая из которых отвечает за свою функцию.

Express JS — фреймворк для написания веб-приложений. С его помощью API создаёт веб-сервер и маршрутизацию.

Express Basic Auth — простая библиотека для Express JS, которая позволяет производить авторизацию в приложении по HTTP. Это не самый надёжный вариант для авторизации, но пока и такого хватит.

Body Parser — библиотека для парсинга запросов.

MongoDB — не реляционная (NoSQL) база данных. В ней хранятся все данные, которые получает метеостанция.

Основное отличие от реляционных баз данных в том, что MongoDB хранит в себе BSON — это JSON-подобные документы. В то время как реляционные базы используют табличный тип хранения данных.

Возможно, позже MongoDB будет заменена на time series базу данных.

MongoDB Driver — официальная библиотека MongoDB для Node JS. Используется для подключения API к базе данных.

Mongoose — библиотека для MongoDB, которая позволяет API производить валидацию получаемых данных по заранее заданной схеме.

Развитие

На данный момент этой функциональности API хватает для того, чтобы доделать до конца MVP. Но у меня уже есть backlog задач, который поможет сделать проект более гибким в будущем. Вы можете написать мне (@boboshko), если хотите присоединиться к разработке.

Благодарности

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

Я хочу поблагодарить: Сашу Купоросова, Вову Артамонова, Влада Самойлова, Стаса Понаморёва, Вадима Репина, Диму Гуденкова и Женю Кочеткова.

Отдельно хочу отметить своих товарищей Сашу Катина (помог с переводом репозитория) и Илью Лыткина (он помогал с документацией).

Если я кого-то упустил, напишите мне и я всё исправлю.

Если у вас остались вопросы, вы можете их задать в чате канала: @codeque.

Подписывайтесь на мой канал, Twitter и Instagram.

Как я научился собирать front-end, чтобы публиковать фотографии

2020-09-21T22:54:59.445Z

В мае 2019-го Саша Катин одолжил мне «Зенит» своего отца в путешествие во Вьетнам. Это был чуть ли не первый раз, когда мне довелось пользоваться подобным плёночным фотоаппаратом. Несмотря на отсутствие опыта, процесс съёмки мне понравился и дело быстро пошло.

Тот самый «Зенит», который Саша одолжил мне в путешествие. В конечном итоге, я выкупил этот фотоаппарат.

Помимо Вьетнама, «Зенит» успел съездить со мной в Индию и прокатиться по некоторым городам России. Количество фотографий росло и встал вопрос о том, где и в каком виде их публиковать.

9 102,42 ₽ — столько я потратил в 2019-м году на покупку, проявку и сканирование фотоплёнок

Решение

https://boboshko.me/photos/

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

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

Шаблон не имел никакого оформления, не умел адаптироваться под разные разрешения экранов (не было CSS) и отсутствовал lazy load. Так продолжалось около года.

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

Готовый результат можно посмотреть: https://boboshko.me/photos/.

Stack технологий

На самом деле, тут всё просто. Сетка реализована на CSS Grid. Ещё я смотрел на Flexbox, но мне показалось, что оно того не стоит.

Никаких препроцессоров CSS на начальном этапе я не использовал.

Во время эксплуатации шаблона, я понял, что новые фотографии в таком виде добавлять сложно. Из-за этого я решил сильно упростить процесс с помощью шаблонизатора Pug, препроцессора SASS и таск-менеджера Gulp с набором плагинов. За lazy load фотографий отвечает небольшой скрипт — lazysizes.

Теперь, если мне нужно внести какие-то изменения в дизайне, я делаю это в одном месте. А не в десяти, как раньше. И Gulp соберёт весь front-end за меня, используя Pug и SASS. Дополнительные плагины оптимизируют все изображения, HTML и CSS. Всё автоматически.

В качестве веб-сервера я использую Caddy. Он умеет автоматически получать SSL-сертификаты от Let’s Encrypt. К тому же, он очень прост в настройке.

Остаётся подключить какую-нибудь систему CI / CD, чтобы можно было делать автоматические сборки на сервере.

В общем, теперь я могу говорить заветное «сбилдилось»!

Если у вас остались вопросы, вы можете их задать в чате канала: @codeque.

Подписывайтесь на мой канал, Twitter и Instagram.

Стенд Avito для фестиваля 404 в Самаре

2020-09-10T19:13:17.465Z

Весной 2019-го я попал в Avito по рекомендации Саши Катина. Несмотря на то, что мы находились в разных юнитах, вместе с Сашей мы иногда занимались совместными проектами.

Один из них — стенд Avito для фестиваля 404 в Самаре, который прошёл в том же году.

Как работал стенд

Саша Катин и Дима Сергутов демонстрируют работу стенда

Человек пришедший на стенд, видел перед собой два экрана: один большой (для информации) и поменьше (для взаимодействия).

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

Если у фразы в конце была звёздочка (вот такая *), человек получал приз и стикер. Если звёздочки не было, получал только стикер.

Это были абсурдные фразы в духе «Аварийный кастет со смазкой» или «Безвкусное кольцо 80-го уровня». Предполагалось, что люди будут их клеить на телефоны и ноутбуки.

Процесс разработки

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

Через iPad посетители взаимодействовали со стендом

Как я уже сказал выше, в системе было задействовано два экрана (телевизор и iPad), ноутбук и специальный принтер для печати этикеток.

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

За проектирование и монтаж стенда отвечал подрядчик.

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

Так выглядел стенд в разобранном состоянии

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

Чтобы начать работу, нужно было выгрузить всё из таблиц и подготовить данные. В итоге, у меня получилось 4 разных файла: he.js, she.js, it.js и together.js. Внутри файлов было по два массива с подлежащим и сказуемым (в together.js было только местоимение).

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

Сборка рабочего прототипа на моём рабочем месте (офис Avito в Москве)

Статистику и все сгенерированные фразы мы записывали в local storageбраузера. В нём же хранили количество оставшихся подарков. Каждый раз, при срабатывании скрипта, если выпадал приз, то из числа в local storageвычитался 1.

Больше всего сложностей было с балансировкой шансов выпадения приза. Мне показалось, что проще всего это будет сделать через подбрасывание монетки. Монетка, конечно, не настоящая и выдаёт 0 или 1. Всё это привязывалось к датам проведения фестиваля и было сбалансировано так, чтобы в первый день мы раздали 2 / 3 подарков, а во второй 1 / 3.

Результат

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

За 2 дня фестиваля, стендом воспользовалось более 1 000 человек. Были розданы все подарки.

Довольный посетитель и стенд

К сожалению, я не попал на сам фестиваль и не видел, как люди пользуются стендом. По отзывам ребят, многим из посетителей он понравился.

За фотографии и видео я хочу поблагодарить Сашу Катина. Если у вас остались вопросы, вы можете их задать в чате канала: @codeque.

Подписывайтесь на мой канал, Twitter и Instagram.

Бот с расписанием шаттлов

2020-08-06T19:22:38.501Z

Иллюстрация — Илья Казаков

После Avito, я перешёл в «Ренессанс здоровье» по приглашению своего давнего товарища Лёши Кожевникова.

У «Ренессанса» ходят собственные автобусы от метро до офиса и обратно. Это шаттлы, которые не отображаются в приложениях типа «Яндекс.Транспорт». А расписание их движения присылает HR в виде JPEG.

Такой формат показался мне неудобным и я решил упростить процесс восприятия информации.

Так появился Telegram-бот Shuttles (@ShuttlesRobot), о котором пойдёт рассказ.

Что умеет бот

Демонстрация работы бота

Сначала нужно понять, почему бот полезнее, чем JPEG.

Бот умеет показывать время прибытия ближайшего автобуса и минуты до него. Например, «Через 30 минут в 7:30».

Он также умеет склонять слово «минут». Например, «Через 30 минут» или «Через 32 минуты».

Ещё бот определяет текущий день недели. Это нужно для того, чтобы напоминать, что в пятницу сокращённое расписание движения. А по выходным автобусы не ходят вовсе.

Текущая функциональность — MVP. И у меня в backlog уже есть идеи, как сделать бота удобнее и дружелюбнее.

Реализация

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

Если у вас есть замечания или предложения, вы смело можете их мне озвучить (@boboshko).

Репозиторий проекта.

Бот

Основой для бота служит Telegraf. На данный момент, это единственная подключаемая библиотека в проекте. Чтобы понимать, как с ней работать, можно почитать документацию или посмотреть примеры.

Расчёт времени

Все операции со временем и определение текущего дня недели происходят в файле timeCalculation.js. Я не буду полностью рассказывать о том, как происходят вычисления (в коде есть комментарии), а только затрону способ решения главной проблемы — получении массива с нужными значениями timestamp.

Расписание хранится файле schedule.json в формате матрицы. Каждый массив представляет из себя последовательность чисел. Например, [21, 25, 0, 0] — это 21:25:00:00. Такой формат времени обусловлен тем, что функция setHours для объекта Date принимает аргументы в таком формате и помогает сохранить читаемость расписания для человека в schedule.json.

Чтобы дальше было удобнее работать со временем, его нужно перевести в timestamp. И setHours помогает с этим справиться, возвращая timestamp в часовом поясе UTC (минус три часа по Москве). В дальнейшем, для корректного отображения времени в интерфейсе пользователя, эту разницу нужно будет компенсировать вручную.

Но не всё так просто с timestamp. Например, 21:25 UTC текущего дня — это 1591478700. А следующего — 1591565100. Следовательно, нужно рассчитывать значения timestamp для всего расписания, каждый раз, когда нужно произвести остальные вычисления.

За это отвечает функция convertTime. Результатом её работы будет массив outArray, в котором хранится всё расписание на день в timestamp.

Скорее всего, это не самый элегантный способ хранения времени. Расскажите мне, если знаете, как лучше (@boboshko).

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

Принцип разработки

Влад Самойлов, с которым я познакомился в Avito, рассказал мне об атомарном подходе в разработке.

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

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

Хочу поблагодарить Влада за совет и то, что он помогает мне с кодом, время от времени. Спасибо!

Что бы хотелось

Хотелось бы аналитику. В 2017-м для её сбора, я пользовался сервисом Botan от «Яндекса». Но сервис закрыли в 2018-м году. Я искал ему замену и сумел найти Chatbase. Но подключить его не вышло.

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

Расскажите мне, если можете помочь мне с этими вопросами.

Как добавить свои шаттлы

Вы можете добавить расписание своих автобусов в @ShuttlesRobot, если они курсируют между двух точек. Это бесплатно.

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

Присылать сюда (@boboshko).

Если у вас остались вопросы, вы можете их задать в чате канала: @codeque.

Подписывайтесь на мой канал, Twitter и Instagram.

Домашняя метеостанция. Часть 1

2018-08-25T21:52:16.988Z

Сегодня я не стану подробно разбирать написанный мною код (но без него не обойдётся). Сегодня я расскажу про свою мечту и её реализацию.

Мечта

Ещё в начале 2017-го я загорелся идеей окутать свой дом погодными датчиками и получать с них данные в реальном времени через бота в Telegram.

Тогда эта идея мне казалась недосягаемой и мало практичной. Я до сих пор считаю свою идею мало практичной, но если что-то хочется — надо делать.

Концепция метеостанции

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

Шаг за шагом

Вывод данных с датчиков в консоль Espruino Web IDE

Для меня эта задача очень большая и, кажется, почти неподъёмная. Я решил действовать последовательно и разбить всё на этапы:

Настройка датчиков и платформы. Вывод данных в консоль.
Настройка сервера и передача полученных данных в базу.
Написание Telegram-бота и передача в него данных из базы.

Платформа

В качестве основы для своей метеостанции я выбрал Iskra JS. Iskra JS — это, как Arduino, только производится в России и работает на JavaScript. Можно было бы остановиться на Arduino, но я не знаю C++. А с JavaScript уже хоть как-то знаком.

Все датчики, которые подходят к Arduino, можно подключить и к Iskra JS (если есть нужная библиотека). Обе платы находятся примерно в одном ценовом диапазоне. Конечно, если сравнивать Iskra JS с оригиналом Arduino, а не Китайской репликой. К слову, Китайскую реплику можно купить где-то за 200 рублей на AliExpress. Так что имейте в виду.

В остальном, отличий вроде бы нет.

Конфигурация

Слева направо: Iskra JS, Slot Shield, Wi-Fi (ESP8266), термометр (TMP36), часы реального времени (DS1307) и барометр (LPS331AP)

Для первого этапа я взял аналоговый термометр (TMP36) и барометр (LPS331AP). Ещё понадобились часы реального времени (DS1307). Данные с этих датчиков передаются с помощью Wi-Fi (ESP8266). Он работает на частоте 2.4 GHz.

Все датчики имеют специальный форм-фактор и устанавливаются без пайки на Iskra JS с помощью переходника Slot Shield.

Принципы работы

Загрузка Wi-Fi модуля и последующий запрос к API «Яндекса»

При подаче питания на плату, через 10-15 секунд Wi-Fi модуль загружается и подключается к интернету. Затем, он делает запрос к API Яндекса и получает точное Московское время. После чего, полученное значение передаётся в часы реального времени. И только после этого, начинают работать все остальные датчики.

Я немного упрощённо описал принципы работы. Можно ознакомиться с репозиторием на GitHub и самому вникнуть в код.

Проблемы

Конечно же, не всё так гладко.

Во-первых, у меня есть подозрения, что в определённый момент у Iskra JS заканчивается память и в консоль выводится что-то странное. Я пока не знаю, как это проверить и исправить.

Во-вторых, мне очень не нравится этот кусок:

var wifi = require('@amperka/wifi').setup(PrimarySerial, function(err) {
  wifi.connect(SSID, PSWD, function(err) {
    print('Connected to Wi-Fi');
    getTime();
  });
});

Но другие варианты почему-то не срабатывают и переписать эту часть у меня пока не вышло.

Благодарности

Благодарности: Диме Гуденкову и Жене Кочеткову — за помощь с кодом. Илье Лыткину — за перевод описания репозитория.

Подписывайтесь на Telegram-канал «Дизайнер учит код». Меня всегда можно найти в Instagram, Facebook или Twitter. Или напишите моему боту-резюме.