Моноколесо Ninebot One S2: Ремонт прокола камеры своими руками

01/11/2017

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

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

 

Для доступа к камере прийдется полностью снять:

 

Вся работа заняла около 1-1,5 часа, а в следующий раз, думаю уйдет на всю процедуру не более 30-40 минут.

 

Со снятой полностью крышкой.

Впечатления от внутренностей после разборки и сборки:

 

 

На этой фотографии видна моя заплатка на камере снизу.

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

Что почистить на вашем Mac?

28/07/2017

То, что раньше делал прекрасный Daisy Disk, сейчас вполне неплохо выполняет встроенная в Mac OS Sierra утилита.

Разработка фронтенда на веб катится не туда.

22/07/2017

«Спасибо скажем мы Аллаху,
за то, что он наполнил мир глупцами,
Иначе не увидели бы мы мудрецов»

Омар Хайям.

Потребовалось мне на днях запилить динамический веб на стеке React + Redux. Полез посмотреть, чем нынче пользуется уважаемая общественность. Оказывается, стандартно используют Javascript ES-2015, он же ES6. Чтобы запустить это счастье нужно, следите за руками: туго перевязанная упаковка с npm + nodejs, Webpack, Babel. npm доставит вам различные пакаджи, библиотеки типа react, redux, webpack нужен для динамической сборки и предкомпиляции приложения, babel позволит вам писать код на модных стандартах джаваскрипта не особо заботясь о совместимости с предыдущими браузерами.

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

Теперь про боль.
Окунулся по локоть в Джаваскрипт. Синтаксис. Сахар. Синтаксический сахар. Больше сахара. Еще больше сахара. Ожирение.

Я вот сейчас даже статью с Хабра процитирую про новый синтаксис для вызова функций.

○ p1 => expr отлично подходит, если параметр один;
○ p1 => expr имеет неявный оператор return для выражения expr;
○ чтобы неявно вернуть объект, нужно обернуть его в круглые скобки () => ({ foo: ‘bar’ }), иначе получите ошибку;
○ круглые скобки необходимы, когда у вас 0, 2 или больше параметров () => expr or (p1, p2) => expr;
○ фигурные скобки в правой части представляют блок кода, в котором может содержаться несколько инструкций () => {};
○ при использовании такого синтаксиса неявного return нет, его нужно писать () => { return ‘foo’ }.

Что? Что это было?

После чего, конечно, начинают появляться статьи из серии «Почему я все еще использую слово function вместо модного синтаксиса». И это естественно, потому что еще после Perl люди поняли, что злоупотребление уличной магией в разработке до добра не доводит. Но, похоже, уже подросло новое поколение программистов, которым нужно заново пройтись по тем же граблям.

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

Мой ответ такой: потому что Javascript идет не туда. Потому что асинхронность + мутабельный стейт = проблемы. Именно с этим пытается бороться React. Но React это библиотека, а не язык. Библиотека может только упрашивать и рекомендовать, но не заставлять.

Так получилось, что я довольно сильно два года назад погрузился в Clojure и ClojureScript. Вот про что мне сегодня хочется рассказать, так это про то приятное ощущение, когда понимаешь, что люди очень сильно думали, чтобы сделать правильно и красиво.

Все, о чем могли мечтать большевики, в Clojure/ClojureScript есть – структуры данных иммутабельные по-умолчанию, синтаксис языка НЕ ИЗМЕНЯЕТСЯ, просто потому что незачем это делать, есть прекрасный интероп с Java/Javascript, что открывает обширные возможности использования достояния человечества в виде maven, npm инфраструктуры, при чем активно поощряется использование библиотеки Google Closure, а это, я вам скажу, наверное более правильный путь сохранять совместимость со старыми браузерами, чем Babel. Плюс из коробки отличная минификация через вычисление и отрезание неиспользуемых участков кода при сборке большого js. Все вот эти modular-css пытаются решить проблему code as data и data as code, всунуть в JS возможность использовать CSS как код, при том, что для любого lisp, которым является также и Clojure это нативное свойство языка. Модульность и разделение кода на куски в Clojure вообще сделана гениально: namespace + имя сущности однозначно адресует нужную сущность. Про clojure.spec я вообще промолчу, недооцененная многими библиотека, которая решает фундаментальную проблему несовместимости зависимостей. Что такое правильный подход: основу языка оставлять по-максимуму без изменений, а новые фишки добавлять через библиотеки, так как это сделали, например, с core.async для добавления coroutines как в go. И правильно, если это будут использовать 2% пользователей, то зачем это догружать остальным 98%?

В общем, жаль, что коммьюнити не так активно делает маркетинг Clojure/ClojureScript и в целом порог для входа остается очень и очень высоким для среднего разработчика с одной стороны из-за недостаточного количества примеров, которые бы давали быстрый результат, а с другой стороны понимание функционального подхода требует определенных умственных усилий. Нужна новая кровь в такие проекты. Чтобы начать послушайте бесплатные онлайн курсы по Clojure. Может и понравится, %username%.

Музей Мерседес-Бенц в Штуттгарте

01/06/2017

Музей Мерседес-Бенц в Штутгарте произвел на меня неизгладимое впечатление. Легко можно потратить на его посещение целый день и даже этого будет мало. Пожалуй, начну с развенчания некоторых мифов.  У нас в сознании Мерседес-Бенц представляется одной торговой маркой, но дело в том, что Мерседес был только одной из марок автомобилей компании Даймлер, а компания Карла Бенца была основным конкурентом Даймлер вплоть до объединения в 1926г. Впрочем, все по порядку.

read more …

Как я запускал интернет-магазин. Часть 4. Переезд.

22/03/2017

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

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

Второе по важности качество, это удобство заказа и оплаты, возможность выполнить заказ «в один клик»™. И здесь Хорошоп был хорош, интеграция с всевозможными инструментами, такими как Liqpay для оплаты через Приват24, интеграция с API Новой Почты, которая позволяет делать экспресс-накладную (!) и интеграция с смс-сервисом. Все это очень и очень позитивно сказывается на воронке продаж и конверсии.

Третье, аналитика. Интеграция с Google Analytics и Yandex.Metrika работают просто отлично, с пошаговой конверсией, через dataLayer

 

 

Четвертое, управление товаром. Отлично продуманная навигация, удобный парсинг прайса из XLS, все это в сильно лучшую сторону отличает Хорошоп от Opencart. Гибкая фильтрация каталога, там где нужно удобное обновление информации без перезагрузки страницы. Например, установка новой цены на товар может выполняться прямо в таблице товара, как в екселе!

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

Подрезюмирую. По-моему желание сэкономить затраты на старте и пройти всю боль, отрицание и принятие настройки и интеграции модулей и тем оформления Opencart следует каждому начинающему интернет-предпринимателю. Иначе как он сможет сразу оценить все то, что изначально сделано правильно и хорошо и все то, на что НЕ ПОТРАТИТСЯ уйма времени и сил и будет работать сразу как надо из коробки в хорошем продукте, в таком как Хорошоп.

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

Отличные иллюстрации работы известных алгоритмов

15/02/2017

Приятные и понятные анимации иллюстрирующие работу алгоритмов Quicksort, Binary Search, BFS.

https://illustrated-algorithms.now.sh/

Вот я и стал коммитить в Clojure опенсорц

30/12/2016

Я уже как-то признавался в любви языку программирования Clojure, но все руки не доходили до чего-то более-менее серьезного. Всем интересующимся программистам рекомендую почитать Out of the tar pit про растущую сложность создания и поддержки современных программ, и как с этим бороться.

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

LightTable, конечно, редактор с характером, но, пожалуй, лучшее из того что есть на сегодняшний день для интерактивной разработки, почитайте и посмотрите видео у Никиты Прокопова про это. Да-да, не смотря на весь мой опыт с Vim, Emacs, Spacemacs.

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

И вот, работая над Clojure прототипом JSON API нашей админки я незаметно для себя стал контрибьютором в Open Source, чему, конечно, очень рад.

Вот моя первая clojure библиотека для работы с бизнес-временем при расчетах различных SLA. Значительно более элегантное функциональное и гибкое решение, нежели то, которое я запилил когда-то на Ruby. Тестирование в Clojure делается во много раз приятнее, чем рельсовым rspec. Гораздо меньше фрикций на подготовку тестового окружения, да и при желании написание тестов можно проводить прямо в редакторе в том же файле что и само код при интерактивной разработке! А затем переместить все тесты в отдельный выделенный для этого неймспейс.

Собственно вот линк на мою первую библиотеку https://github.com/mprokopov/business-time. Пришлось окунуться в недружелюбный мир Java и разобраться с могучей joda-time и почему у всех реализаций joda-time для clojure отсутствуют то тут то там обертки (wrappers) методов для объектов типа Duration и многого другого.

Также закоммитил pull-request в Korma для лечения JDBC MySQL timezone issues, про наличие которых вообще не подозревал, пока не стал разбираться с business time.
https://github.com/korma/Korma/pull/374. Вообще Korma это такой почти рельсовый ORM, который выглядит очень удобно для работы с SQL при помощи абстракций, так близких всем рельсовикам. Но что действительно хочется попробовать это мигрировать от MySQL/Postgres в сторону Datomic. Datomic выглядит той самой «серебрянной пулей» баз данных, которая обладает просто таки уникальными свойствами.

Для разработки JSON API есть подход от использования самого «ничего», то есть голого Compojure, так и более высокоуровневые Liberator и Pedestal, которые уже больше похожи на фреймворки, нежели библиотеки. Кстати, с Clojure очень хорошо доходит разница между библиотеками и фреймворками, но следует все же помнить, что с большей мощью приходит и большая ответственность.

Делать open source мир вокруг себя богаче легко и приятно, присоединяйтесь, друзья!

Дайджест находок вебмастера 2016-10-27

27/10/2016

Полезно иногда заглядывать в исходники интересных сайтов, вот некоторые из моих находок.

Такой же вебвизор как и в Яндекс Метрике. Бесплатный чуть более чем полностью. https://www.smartlook.com/

%d1%81%d0%ba%d1%80%d0%b8%d0%bd%d1%88%d0%be%d1%82-2016-10-27-13-31-42

Наблюдать за пользователями сайта realtime? Да еще и кликать за них мышью? Да, такое возможно.

https://peekin.io/ Сам сервис хоть и бесплатен, но в стадии alpha.

Stay tuned.

Блеск и нищета OpenCart как движка для интернет-магазина

13/10/2016

Это продолжение серии статей «Как я запускал интернет-магазин«. Часть 1 (Аналитика спроса перед запуском). Часть 2 (Выбор движка для интернет-магазина).

opencart1-500x500

А еще я в некотором роде разработчик. Для меня HTML, CSS, JS не пустые аббревиатуры, в 1999 году я сделал первый PHP+MySQL сайт за деньги. Сейчас у меня другое занятие, которое приносит деньги, но хотелось окунуться в чудесный мир e-commerce за небольшие деньги и сжатые сроки. По опросам знакомых веб-студий я сошелся на мнении, что нужно ставить OpenCart. Модулей ведь много, на все случаи жизни практически. Да и в базе движок выглядит достаточно приличным. И мой давний приятель, у которого довольно раскрученный магазин с хорошим трафиком, сказал «только Opencart есть движок с православно правильной архитектурой».

Ну, думаю, буду экономить свое дорогое время разработчика, буду покупать модули, это же дешевле стоимости часов разработчика. Забегая вперед, в итоге пришлось мне тратить ОЧЕНЬ МНОГО своего времени разработчика после установки модулей чтобы их просто подружить друг с другом да и просто устранить проблемы, не говоря уже о том, что многие модули работают мягко говоря не так, как ожидалось. А некоторые модули вообще оказались несовместимыми друг с другом 🙁 .

Итак, закатал я рукава и полез по колено в OpenCart, думал, всего-то, установить пару модулей и вперед к вершинам электронной коммерции и маркетинга.

Первым делом нужно выбрать нужную шкурку. Ну ок, магазин ведь ручного инструмента, поэтому поехали искать по ключевому слову «Tools». И вот она, черная тема в зеленой палитре на вьетнамском сайте. Купил за $25. Ставлю. И сразу же — оппа! Оказалось, что при достаточно большом описании категории оно неправильно позиционируется и текст прячется под фиксированным размером «бокса» ну и много всего по мелочи. Ушел редактировать стили темы, разбираться что где хранится, какова структура. Так что «сели и поехали» это скорее всего не про нас.

Открытие №1. Выяснилось, что модули любят ПЕРЕЗАТИРАТЬ код движка. Это значит, однажды установив подобный модуль вы лишитесь совместимости с новыми версиями OpenCart. Для решения этой проблемы придумали систему VQMOD или же ее реинкарнацию OPMOD, механизм, который стал частью Opencart. Суть ее в том, чтобы описывать изменения кода в специальном формате в файле XML, который потом достаточно загрузить через FTP или встроенный механизм загрузки и у вас будет установленный модуль. То есть сам функционал модуля описывается текстом, который нужно найти через Regexp в исходном файле и кодом, который нужно добавить или заменить в нужном месте. Таким образом выполняется эдакая прекомпиляция модулей в итоговый файл, который затем хранится где-то в кеше. Нужно ли говорить, c какой болью выходит отладка модуля? А взаимодействие одного модуля с другим?

Впрочем, вы и так не сможете без крови и соплей переехать на новую версию OpenCart потому что разработчики НЕ ЗАБОТЯТСЯ ОБ ОБРАТНОЙ СОВМЕСТИМОСТИ. То есть так и сказали, релиз OpenCart 2.2 не используйте, что-то он вышел у нас слишком сырым.

Открытие №2. Модулей ОЧЕНЬ много, и из модулей нужно уметь ВЫБИРАТЬ, потому что количество модулей только интеграции с Новой Почтой много-много. Вот, например, простыня статьи с выбором из ШЕСТИ модулей которые делают примерно одно и то же. Так я приобрел модуль Microformats Pro, функционал которого в последствии был продублирован функционалом модуля CompleteSEO. И теперь мне не очень понятно, не случится ли что-то с поисковой выдачей, если я выключу модуль Microformats Pro и перейду на поддержку микроформатов через CompleteSEO и полная ли в CompleteSEO поддержка этих самых микроформатов.

Открытие №3. Разнообразная (хорошая и не очень) техподдержка модулей.
Я купил модуль для интеграции с Google Tag Manager, который сразу же (!) не смог установиться на Opencart 2.1.0.1. Индус-разработчик по началу никак не реагировал на запросы, и только после запроса на возврат денег сразу же отписался и признал проблему с установкой, выпустил обновление.

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

Открытие №4. Модули бывают несовместимыми.
Например, есть модуль, который собирает все шаги заказа на одной странице, чтобы не проводить покупателя через 6 страниц-шагов проведения заказа на одной странице и выполняет сам заказ при помощи AJAX. И это правильно и хорошо, но делает модуль Google Tag Manager чуть менее чем полностью бесполезным, поскольку перестает считать сумму заказа в аналитике Google Analytics через механизм dataLayer, поскольку сам механизм заказа стал работать по-другому. И здесь без программиста тоже уже никак не обойтись.

Открытие №5. К работе с SSL готов? Не совсем.
Скорее всего вы слышали, что сайты с SSL гугл любит больше, чем сайты без поддержки SSL, да и в Opencart это должно поддерживаться «одной галкой», но нет, не все так просто. Механизм админки перестает корректно работать с заказами, поскольку он делает AJAX запрос к API из HTTPS на HTTP, а это уже небезопасная операция, что также отобрало на отладку порядочно моего времени.

Мультимагазин. Хм. У нас есть отдельная категория товаров, таких как уровни и нивелиры, и хорошей идеей было запустить интернет-магазин отдельно, с отдельным дизайном. И да, сделать это оказалось просто и легко, с той же «шкуркой», по тем же правилам обработки заказов и единой базой клиентов. Но вот незадача, нет способа прикрутить Google Analytics к отдельному магазину. Да, вот так.

Фильтры. Это такая штука, которая нужна, пожалуй, каждому магазину. Это когда помимо категорий товары хорошо бы показывать «для мужчин», «для женщин», «для детей», «для строителей», «для детей строителей» и так далее. Очень полезно с точки зрения удобства использования. Внутренним функционалом OpenCart они представлены не очень хорошо, и следует использовать сторонний плагин типа MegaFilter. Но к этому плагину мне делать подход пока страшно O_o.

Резюме. Не смотря на то, что в базовой поставке Opencart достаточно неплох, я все еще не представляю, как быть с обновлениями версий движка магазина и что делать с несовместимостью модулей и как влиять на поставщиков модулей и их качество. Использовать OpenCart как есть, без каких-либо модулей не представляется возможным. Мы же хотим и различные оплаты принимать и доставки и гибко управлять SEO настройками, а это неизбежно потребует от нас влезания в ад модулей и поиска ответов на различных форумах и группах вконтакта.

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

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

Дайджест моих находок

20/09/2016

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

 

Фреймворк Grid Style Sheets — https://gridstylesheets.org/ или Constraints Cascaded Style Sheets.

Это не очередной bootstrap, это способ сделать хороший динамичный лейаут через JS + CSS используя идеи верстки с ограничениями (я не знаю как лучше перевести constraints layout). Использует алгоритм Cassowary для управления органичениями (constraints) при вычислении лейаута, тот же самый что и Apple в Cocoa верстке. Позволяет делать фантастические вещи, в том числе и очень респонсив верстку. Возможно, это то, каким должен быть CSS в будущем.

 

Язык ELM — http://elm-lang.org/.

Язык, который тесно связан с фреймворком, компилируемый в Javascript диалект Хаскеля. Я бы его рассматривал как альтернативу AngularJS, так как его область применения – только фронтенд. На него обязательно стоит посмотреть уже хотя бы потому, что он служит примером хорошей расширяемой архитектуры веб-приложений с функциональным подходом.

 

Playlist from ClojureTRE 2016 conference. Отметитил для себя отличные выступления Никиты Прокопова про Rum и Девида Нолана про ClojureScript.

 

Книгу, которую рекомендует как обязательную к прочтению Рич Хики How To Solve it и его PDF copy. И, конечно, не могу не порекомендовать его знаменитый доклад Hammok Driven Development. Если кратко изложить суть, то она будет следующей: прежде чем что-то кодить отойдите в сторону, подумайте, решите проблему сначала в голове. Решение проблем это навык, и как любой навык его можно и нужно качать так же как мы качаем мышцу.

Parinfer — великолепный способ indent + paredit в одном флаконе. Очень удобно для разработки Clojure(Script) приложений, выравнивание будет автоматически устанавливать нужные скобочки. Для суперленивых. Есть плагины для всех популярных редакторов.

TODO: прочитать Tools for thought.