Оригинал: React To The Future With Isomorphic Apps

Изоморфные приложения. Взгляд в будущее с React

В разработке программного обеспечения все часто возвращается на круги своя. Так, например, на заре развития Интернета серверы подгружали контент сразу же на сторону клиента. В последнее же время, с разработкой современных веб-фреймворков, таких как AngularJS и Ember, мы видим тенденцию к обработке запросов на стороне клиента и использованию сервера только для API. Однако, это далеко не единственная тенденция. Сейчас происходит медленное возвращение или, скорее, слияние этих двух архитектур.

Сильно удивился, когда выяснил, что под STM32 нет такого разнообразия готовых драйверов под разного рода i2c сенсоры, как под Arduino. Те, которые мне удалось найти, были частью какой либо ОС (например, ChubiOS, FreeRTOS, NuttX) и были более POSIX-like. А хотелось писать под HAL :(

Arduino комюнити использует библиотеку i2cdevlib для абстракции от железа при написании драйверов сенсоров. Собственно, делюсь своей работой — порт i2cdevlib на STM32 HAL (pull-request уже отправил), а под катом я расскажу о камушках, которые собрал по пути. Ну и примеры кода будут.

«KISS (keep it short and simple — «делай короче и проще») — процесс и принцип проектирования, при котором простота системы декларируется в качестве основной цели и/или ценности.» Wikipedia

Введение

Именно так в последнее время я все больше склоняюсь трактовать аббревиатуру KISS и писать программные компоненты для различного рода продуктов. Именно по этому принципу написана предлагаемая в данном обзоре библиотека. И именно поэтому она будет развиваться в заданном ключе в будущем.

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

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



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

На прошлой неделе я обновил свои мониторы. Выбросил Apple Cinema Display и на их место взял 4К-мониторы от Dell. Как печатнику, мне понравился предыдущий апгрейд с чёрно-белых до grayscale-мониторов в 90-х годах. Но 4К – ещё лучше. Дисплеи высокого разрешения уже пришли на смартфоны и планшеты. Приятно, что они появляются и у ноутбуков и декстопов. Шрифты выглядят чудесно.

Хотя – хорошие шрифты выглядят чудесно. Плохие выглядят хуже – они уже не спрячутся за плохо различимыми гранями грубых пикселей. Если вы работаете с текстом – читаете, пишете, программируете, рисуете (а это охватывает чуть ли не все профессии), то апгрейд на 4К стоит того.



Но что есть «4К»? С лёгкой руки маркетологов, это экран размера 3840 на 2160 пикселей (3840 – это ну почти 4000). По каждой из сторон разрешение в два раза больше, чем у HDTV, то есть 1920х1080.

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

И, что характерно, на этом останавливаться никто не собирается, на горизонте уже дисплеи 7680 х 4320, известные как 8К. С другой стороны, разрешение, воспринимаемое человеческим глазом, имеет границы. Переход на 4К заметен. На 8К – менее заметен. В какой-то момент нужно будет перестать делить пиксели.

Но что, если они не перестанут? Что, если они будут делить пиксели бесконечно? Сколько тогда пикселей будет на экране?

а) по количеству положительных целых чисел
б) меньше
в) больше

Если вам не интересна математика, тогда итог статьи такой: купите 4К-монитор. Не стоит благодарности.

Эксперимент с прикручиванию к дешевым микроконтроллерам ATTiny загрузчика и среды разработки Arduino был достаточно удачным. Конечно, с AVR неплохо живется и без Arduino. Но хорошо, когда есть возможность выбора. А потом я вляпался в STM32 и заковырялся в библиотеках и громоздких конструкциях инициализации портов. Спасением ARM-«чайника» стал проект ARM mbed. Лично мне он позволил просто взять и начать работать с STM32.

Но мигать светодиодом на плате Nucleo надоело очень быстро. Отложил я ее, ибо слишком много ножек и наворотов, и взялся за Maple Mini (STM32F103CBT6 с минимальной обвязкой). Тоже все довольно легко и просто — сервоприводы крутятся, датчики работают, экранчики показывают — все популярные библиотеки, знакомые ардуинщикам, в mbed имеются.

А третий заход отчасти повторял «Arduino за 1$». О нем я и расскажу подробно. Идея такая: хочу ARM за копейки. Открываю Aliexpress и нахожу STM32F030F4P6 за 55 центов за штучку при покупке пучка (10 чипов).

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

В посте на своем блоге «gdal_translate и gdalwarp для перепроицирования изображений» описывался процесс получения картинок под разные проекции с помощью утилит GDAL. Полученные изображения я использовал как подложки для карт в примерах проекта dbCartajs. Позже, работая над портированием канвасной версии своего планетария на WebGL, описанной в статье «Звездное небо на WebGL с использованием Three.js» на Хабре, у меня возникла мысль со временем перенести не только глобус, но и плоские на карты на WebGL, используя вместо фона текстуры. То есть для создания карты обойтись только использованием браузера и JavaScript без использования серверных компонентов.

Суффиксное дерево – мощная структура, позволяющая неожиданно эффективно решать мириады сложных поисковых задач на неструктурированных массивах данных. К сожалению, известные алгоритмы построения суффиксного дерева (главным образом алгоритм, предложенный Эско Укконеном (Esko Ukkonen)) достаточно сложны для понимания и трудоёмки в реализации. Лишь относительно недавно, в 2011 году, стараниями Дэни Бреслауэра (Dany Breslauer) и Джузеппе Италиано (Giuseppe Italiano) был придуман сравнительно несложный метод построения, который фактически является упрощённым вариантом алгоритма Питера Вейнера (Peter Weiner) – человека, придумавшего суффиксные деревья в 1973 году. Если вы не знаете, что такое суффиксное дерево или всегда его боялись, то это ваш шанс изучить его и заодно овладеть относительно простым способом построения.

Это был довольно интересный проект. Я пытался создать арифметический калькулятор чисто на CSS3 (а не JavaScript). Используя такие элементы, как calc(), attr(), counter() и пр. это казалось не таким уж сложным заданием, но все оказалось не так просто.

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

Стабильно работает только в Firefox 4 и IE 9

Одним из ключевых компонентов любого калькулятора является возможность преобразовывать ввод. Используя только CSS, мы имеем очень ограниченные варианты фиксации ввода. Таким образом, для регистрации всех вводов используются чекбоксы. Для применения изменений к другим элементам можно использовать состояние «:checked» и селектор «~», а так как они довольно прямолинейны, я не буду вдаваться в подробности, а вместо этого акцентирую внимание на логике вычисления значений.

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

Начиная с версии 35 (35.0.1916.114 m), как известно (англ.), браузер Google Chrome для ОС Windows перестал поддерживать установку новых и работу прежде установленных расширений, размещённых не в магазине Chrome WebStore. Это же касается и всех юзерскриптов, не размещённых в этом магазине. Группа Windows-пользователей — обширна, поэтому требуются новые инструкции о том, как с этим бороться. Линуксоидам и маководам это, к счастью, пока не грозит.

Введение

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

К этому моменту уже как несколько месяцев изучал работу микроконтроллеров STM32F100 и STM32F103, применяя их на практике в презентационном устройстве. От таких гигантов, как STM32F429, мне пришлось отказаться. Так как стоимость в 1800 рублей за корпус является заоблачной для «бюджетного» устройства, функционал которого только начал превосходить возможности AVR Atmega32.

Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
— С просторов интернета

К чему это я? Занятная штука — JavaScript. Основа современного web и на фронтэнде альтернатив как таковых не имеет.

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

Ванильная стандартная библиотека JavaScript, в целом, неплоха. Это не только стандартная библиотека по спецификации языка ECMA-262 актуальных версий — от 3 до черновика 6. Часть API вынесена в отдельные спецификации, например, API интернационализации ECMA-402. Многие возможности, без которых сложно представить JavaScript, например, setTimeout, относятся к web-стандартам. Консоль не стандартизована вовсе — приходится полагаться на стандарт де-факто.

Вот только не такая уж она и стандартная — везде разная. Есть старые IE, в которых из коробки мы получаем стандартную библиотеку ES3 90-бородатого года даже без Array#forEach, Function#bind, Object.create и консоли, и есть, например, Node.js, на которой многие уже вовсю используют возможности грядущего ES6.

Хочется иметь универсальную, действительно стандартную библиотеку, как на сервере, так и в любом браузере, максимально соответствующую современным стандартам, а также реализующую необходимый функционал, что (пока?) не стандартизован. Статья посвящена библиотеке core.js — реализация моих соображений по поводу стандартной библиотеки JavaScript. Кроме того, эта статья еще и шпаргалка по современной стандартизованной стандартной библиотеке JavaScript и заметки о её перспективах.

Содержание, или что получим на выходе:

• Подходы

• Часть первая: Костыли

  
  
  • ECMAScript 5
  • ECMAScript 6
  • ECMAScript 6: Символы
  • ECMAScript 6: Коллекции
  • ECMAScript 6: Итераторы
  • ECMAScript 6: Обещания
  • Mozilla JavaScript: Статические версии методов массива
  • Отложенное исполнение: setTimeout, setInterval, setImmediate
  • Консоль
  
  

• Часть вторая: Велосипеды

  
  
  • Классификация данных
  • Словари
  • Частичное применение
  • Форматирование даты
  • Объектное API
  • Массивы
  • Числа
  • Экранирование спецсимволов
  
  

• Заключение