Итак, свершилось: наш любимый браузер выпущен в финальном варианте 75-й версии.

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

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

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

По долгу службы мне часто нужно находить все пересечения между текстами (например, все цитаты из одного текста в другом). Я достаточно долго искал стандартное решение, которое бы позволило бы это делать, но найти его мне так и не удалось — обычно решается какая-то совсем или немного другая задача. Например, класс SequenceMatcher из difflib в стандартной библиотеке Питона находит самую длинную общую подпоследовательность в двух последовательностях hashable элементов, а потом рекурсивно повторяет поиск слева и справа от нее. Если в одном из текстов будет более короткая подпоследовательность, которая содержится внутри уже найденной (например, если кусок длинной цитаты где-то был повторен еще раз), он ее пропустит. Кроме того, когда я загнал в него «Войну и мир» и «Анну Каренину» в виде списков слов и попросил для начала найти самую длинную подпоследовательность, он задумался на семь минут; когда я попросил все совпадающие блоки, он ушел и не вернулся (в документации обещают среднее линейное время, но что-то в прозе Льва Толстого, по-видимому, вызывает к жизни worst-case квадратичное).

В конечном итоге я придумал свой алгоритм, тем самым наверняка изобретя велосипед, который надеюсь увидеть в комментариях. Алгоритм делает ровно то, что мне нужно: находит все совпадающие последовательности слов в двух текстах (за исключением тех, что в обоих текстах входят в состав более крупных совпадающих последовательностей) и сравнивает «Войну и мир» с «Анной Карениной» за минуту.

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

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

Стараюсь читать все статьи на Хабре по электронике для начинающих, DIY, Arduino. И вот только что прочитал статью «Ардуино. 6 шагов». Под впечатлением решил попробовать закинуть свои 5 копеек.

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

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

Для отрисовки веб-карт существует несколько открытых библиотек, например, OpenLayers и Leaflet. Довольно давно наш выбор пал на Leaflet и мы продолжаем его активно использовать при реализации проектов. Для редактирования геоданных хотелось бы использовать его же и, при этом, иметь возможность интегрироваться с существующими хранилищами пространственных данных.

Для достижения последней цели как правило используются ГИС-сервера (geoserver, mapserver), которые умеют публиковать большое количество разнообразных форматов данных по стандартам OGC. Так, WMS протокол прекрасно справляется с функцией визуализации готовой карты, но не предполагает функции редактирования, для которой резонно использовать WFS-протокол с возможностью изменения данных. Запросы к WMS возвращают уже отрисованные тайлы — картинки, а к WFS — сырую информацию, «исходный код» за этими тайлами. Leaflet поддерживает модули расширения, соответственно, можно поискать готовый компонент, либо написать свой. Т.к. поиск готовых модулей для Leaflet удовлетворяющих результатов не дал, мы приступили к собственной реализации.

По статистике запросов на leaflet.uservoice.com понятно, что данный модуль интересен не только нам.

Привет, Хабр!

Мы в HumanFactorLabs парсим адреса в особо крупных размерах. Наши продукты упрощают ввод контактных данных и работу с ними.

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

Недавно на Хабре нас попросили привести примеры необычных адресов, в связи с чем и написана эта статья.

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

Отдельно остановимся на попытке создать электронный конструктор для освоения азов электроники.

Вопрос вызвал формат: «полнофункциональный набор» или ещё «настольная игра». Сразу отметим, что эти вопросы были и у нас. Т.к. когда распечатана куча панелей, а выбрать окончательный вариант электрического соединения не удается, то, передвигая заготовки, получаем разные схемы, которые и подводят к мыслям о настольных играх, т.е. просто «тащат за руку»…

Куботроник активно развивается. Кроме механических деталей он обзавелся дополнительными панелями, а также мы разработали возможность соединять блоки Куботроника в электрические цепи. Напечатали много всяких условных обозначений радиоэлементов и даже запланировали сделать игру «СХЕМОТЕХНИКА» по изучению основ этой самой схемотехники.



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

Я — программист. А ещё я слеп. Слеп, как крот, как говорится. Таков я от рождения.

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

• Как же ты тогда можешь читать то, что я пишу?
• Ого. А как ты тогда можешь кодить?
• Или — самый популярный вопрос — А ты видишь сны?

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

В связи с нововведениями на сайте, решил наконец-то вылезти из подполья и написать что-нибудь полезное. Ну а поскольку я программирую разные микроконтроллеры (МК) и являюсь фанатом Eclipse, то решил про это и написать. Начну со своей истории знакомства с программированием PIC, а закончу советами тем, кто по долгу службы или в силу увлечения программирует на МК семейства PIC, хотя, впрочем, эти же советы сгодятся и для других архитектур МК.

В среду железячников я попал в 2006 году на 4-м курсе учёбы в университете, когда пошёл на производственную практику в научно-технический центр, где, собственно, и работаю по сей день. В то время в нашей компании мейнстримом было использование Keil uVision2 для МК на базе C51 и ARM. Однако мне подсовывали простые задачи под PIC, вроде контроля и управления одним сигналом (кнопка вкл-выкл), и моей первой средой разработки были блокноты — бумажный и компьютерный, плюс книжки бумажные по PIC. Выглядела моя среда разработки примерно так:



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

Рождение идеи

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

Насколько быстро можно создать устройство для Интернета вещей (IoT), которое управляется через браузер, получает и передает информацию, учитывая, что вы никогда не работали с микроконтроллерами, а только занимались высокоуровневым программированием на JavaScript?



Например, такое устройство как на фото. У него есть ЖК-экран и стрелочный указатель на сервоприводе. Рядом лежит телефон с запущенным браузером, который подключен к вебсерверу на устройстве. При нажатии стрелок в браузере, указатель поворачивается вправо, влево или устанавливается в нейтральное положение. После установки значения, оно передается обратно в браузер и показывается как значение Value. Дополнительно в браузере можно задать текстовую строку, которая после нажатия кнопки «Set text» выводится на ЖК-экране. Всё взаимодействие происходит по Wi-Fi. Как вы думаете, сколько времени уйдёт на разработку?

Как вы помните из моих предыдущих постов, мы плавно движемся в сторону возможности собирать интересные штуки самостоятельно. Для тренировки мы уже собрали робота из конструктора 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.