Как вы помните из моих предыдущих постов, мы плавно движемся в сторону возможности собирать интересные штуки самостоятельно. Для тренировки мы уже собрали робота из конструктора DIY, увлекательно спаяли пару схем, и впереди у меня запланированы ещё пара интересных постов для таких же совсем-совсем начинающих. А сегодня немного отдохнём и посмотрим, достаточно ли будет 3D ручки для прототипирования наших идей?

Дождливым полднем 1968 года молодой австралийский выпускник Бойд Рэйворд зашёл в заброшенный офис в здании Парк Леопольд в Брюсселе. Внутри был «захламлённый, затхлый, весь в паутине офис, который заливало дождём». Кипы бумаг, книг и рукописей высились до потолка – интеллектуальные «остатки кораблекрушения» от, на первый взгляд неорганизованного, учёного.

Предыдущий хозяин офиса, Поль Отле, был к тому времени мёртв уже 25 лет. Библиограф, пацифист и предприниматель, в своё время он был признанным гением, наслаждался компанией нобелевских лауреатов и принимал участие в создании Лиги Наций. Ко времени смерти в 1944 году он увидел, как закатилась его репутация, как разрушились его планы и как нацисты растащили и уничтожили крупную часть его работы. Когда он умер, незадолго до конца войны, вряд ли кто-нибудь это заметил.

Кто же такой был Поль Отле? Встречайте забытого отца информационной архитектуры.

Веб, которого не было

В 1934 году, годами ранее изобретения Вэниваром Бушем концепции «мемекса» (прообраза гипертекстового устройства), десятилетиями до изобретения Тэдом Нельсоном термина «гипертекст», Поль Отле придумал новый вид рабочей станции учёного – движущийся стол в форме колеса, работающий с набором спиц на шарнирах, расположенных под несколькими движущимися поверхностями. Машина позволяла бы пользователю искать, читать и вносить новые записи в огромную механическую базу данных, хранящую сведения на индексных карточках размера 3х5.

Система позволяла бы не только получать документы – можно было бы также обозначать связи между ними, «связи, который каждый документ имеет со всеми другими, и который бы создавали нечто, что можно было бы назвать Универсальной Книгой».

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

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

Основные проблемы, которые встречаются в библиотеках валидации данных

Проблема №1. Многие валидаторы проверяют только те данные, для которых описаны правила проверки. Для меня важно, чтобы любой пользовательский ввод, который явно не разрешен, был проигнорирован. То есть, валидатор должен вырезать все данные для которых не описаны правила валидации. Это просто фундаментально требование.

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

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

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

Оригинал: 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
  • Массивы
  • Числа
  • Экранирование спецсимволов
  
  

• Заключение