Выглядит мой GameShell так. Собран на коленке (которая тоже в кадре)

А ещё у консольки задник покрыт LEGO-совместимыми пупырышками - к ним удобно цеплять периферию, для подключения которой доступны (выведены на разъем) GPIO процессорной платы и порты Arduino-совместимого блока с кнопками. Так что эта штука ещё и на "процессор" Lego Mindstorm похожа (особенно - в бело-сером варианте).

Вчера собирал RetroArch из сорцов прямо на GameShell - сборка прошла довольно быстро, надо отметить! И процесс был вполне себе классический - git clone, configure, make, make install, т.е. всё как у больших. Даже apt-get build-dep делал - Debian же :)

Сейчас всё делается сильно проще, чем делалось в своё время для Dingoo A320 - там и SDK был сильно более экзотичный, и компилировать на железке возможности не было. Так что с точки зрения открытости для экспериментов, GameShell прекрасен ;)

Вчера разобрал и частично утилизировал свой старый, и уже к сожалению, нерабочий Kindle Keyboard.

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

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

А ещё на моей читалке наличествовал то самый "бесплатный мобильный интернет по всему миру навсегда" - он и правда работал много где и бесплатно! Поэтому теперь у меня есть GSM-модуль. Т.к. оный опционален, то и сделан отчуждаемым, но часть обвеса располагается на основной плате, в т.ч. и кроватка для SIM-карты, поэтому я не уверен, что смогу модуль нормально использовать. Ну да лажно, если криворукость мне помешает, кому-нибудь пряморукому подарю :)

P.S. Ещё у меня есть живой экран (при неживой "тушке" - редкое сочетание!), который я могу задонатить в качестве запчасти. Это Pearl размера 6", если что.

#hardware #electronics

В своё время для Kindle с бесплатным интернетом выходил SDK, позволяющий разрабатывать приложения с бесплатным же пакетом для connectivity features. Скажем, можно было написать монитор курсов валют, и получать обновления данных по всему миру бесплатно - трафик довольно сильно лимитировался, но для подобных задач (пару раз в день сходить за небольшим JSON или двадцать раз сходить за маленьким JSON) хватало и бесплатного пакета. Сам я, правда, так и не сподобился что-то такое написать, а теперь, вот, жалею...

BoldPort - интересный прокет для тех, кто любит попаять ради самого процесса (как я, например).

Суть: платим за подписку, получаем раз в месяц (пишут, что шлют по всему миру и доставка включена) маленький красиво упакованный набор деталей и плат для сборки некоторого устройства. Устройства обычно достаточно просты и ценны в основном с эстетической точки зрения - сувениры, экспонаты для коллекции (все наборы разные и не повторяются), источник вдохновения.

Эстетика присутствует, например, в разводке плат: оные разведены в Inkscape - да-да, в векторном графическом редакторе, а не в программе-трассировщике. Разводка выполнена вручную под руководством чувства прекрасного, поэтому изобилует завитками и бедна на прямые линии :)

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

Чем-то этот проект мне напомнил Circuit Classics - тоже сувенирные схемки для самостоятельной сборки и последующего показа всем подряд :)

#diy #electronics

Прекрасный тестер для светодиодов прекрасен! (тоже kit)

Прелесть!

Сохряню тут, раз уж старался, писал. Это из чата про #elm.

--
Хаскелисты Rust ругают частенько за недофункциональность - изначально императивный язык, да-да! Но в Rust есть многое, что присутствует в больших ФП-языках, и это не "эти ваши академические штучки", а исключительно полезные вещи - я про traits и ограниченный параметрический полиморфизм говорю. Да, в Rust нет HKT и не будет никогда, скорее всего. Но даже то, что есть, очень сильно помогает управлять сложностью через абстракцию.

И именно средства для управления сложностью кода делают язык пригодным для реализации на нём действительно больших проектов!

С этой точки зрения плох Go - абстрагирование там не в чести и встроенные средства для построения абстракции очень бедны (из, можно сказать, нет). А это означает, что большие проекты состоят из копипаст (в т.ч. и из копипаст ошибок!) и местных велосипедных ренеший (в Go тоже не принято переиспользовать чужой опыт, культура поощряет "скопировать к себе если уж сам не хочешь писать"). Процедурные языки имеют инструмент, созданный для управления сложностью - ООП. Да, "правильно готовить" его умеет не каждый, но инструмент очевидно работает - иначе его бы выбросили на свалку истории. В Go нет ООП но и нет альтернативы.

Теперь смотрим на ФП. Было когда-то сказано "лучше иметь один тип и сто функций для работы с ним, чем десять типов и по десять функций для работы с каждым" - сказано это было в контексте Lisp, но работает и для ФП в целом. И если "один тип на все случаи жизни", это странная идея, то вот единый вокабулярий для работы с разыми типами, это отличная вещь!

И вот тут мы подходим к Elm. Единый вокабулярий отнюдь не означает "у нас везде map, просто это List.map, Maybe.map и т.п." - это разные функции для работы с разными типами. Т.е. нет возможности писать обобщённый код. И абсолютно не важно здесь, как эти функции называются (пусть даже и понятно и "читаемо")! Нельзя написать "библиотеку, которая обобщённо работает с коллекциями" и подобные сугубо полезные в реальных проектах вещи!

И всё только осложняется тем, что в Elm типизация статическая. Потому что в динамически типизированном ЯП мы можем хотя бы ad hoc полиморфизм силами "утиной типизации" сделать или на крайний случай прямо в функции решить, как с переданным типом работать (не сильно гибко и точно не особо расширяемо, но относительно обобщённый код писать позволяет). А при старической типизации в Elm мы имеем лишь "неограниченный" параметрический полиморфизм: мы всегда всё знаем о структуре, но никогда о "содержимом" типа. А значит мы не сможем без привнесения излишней сложности написать, скажем, функцию sort : List a -> List a - мы по построению не знаем ничего об a и не можем знать при текущей модели. Да, местный ad hoc есть в виде comparable, но с чего это автор решил, что ad hoc полиморфизм нужен только в тех местах, где он сейчас есть? Примеров могу привести много - и все из реальной жизни.

Так что же хорошего в том, что мы имеем ФП, но такой, где функции (и типы) пользователя - объкты второго сорта; где автор решил, что такие-то типы comparable, а пользовательские - нет; где автор stdlib может писать обобщённый код - внутри stdlib - а пользователи не могут?! И не нужно говорить о "сложности для новичков" и "те, кому надо, пойдут в другие языки" и в этом же контексте "у нас - успешный язык для решения реальных задач!". Это лукавство. Потому что зрелый язык помогает решать проблемы, а не создаёт искуственно препятствия для решения оных.
--

P.S. Это похоже на "нытьё", но я правда так считаю. Часто бываю непонят или неуслышан.

Отличное короткое объяснение "что есть ADSR": https://www.youtube.com/watch?v=JT6rixgu4s4
Прекрасно подходит для того чтобы сослаться на него, если вдруг кто спросит. Поэтому "заложу" сюда :)

P.S. Канал, кстати, отличный, если вам нравится синтез звука (мне - нравится).

#music #synth

Внезапная минутка лёгкого красноглазия: https://lpicentral.blogspot.com/2018/08/10-useful-ncat-nc-command-examples-for.html
По ссылке набор рецептов для использования netcat так и эдак. Присутствуют и обычные сценарии вида "поднимаем чатик мужду двумя машинами", но есть и поинтереснее варианты, например двунаправленное проксирование (через fifo-девайс).

Сам я netcat пользую редко, но иногда с немалой пользой. Однажды я даже передавал по сети видео-поток (с embedded компутера формата PC104), а на принимающей стороне воспроизводил силами mplayer - стриминг, однако! Не то чтобы это было очень нужно, но работало и как минимум было забавно!

#unix #cli #networks

Меллотрон в деталях: https://www.youtube.com/watch?v=ByD8gH7kYxs
Именно такой The Beatles использовали в "Strawberry Fields Forever"
Очень своеобразная железка, люблю такое.

#music #synth

Захотелось недавно #generative_art потворить.

Сначала взял #elm. Наткнулся на проблему с фатальным недостатком подхода к генерации случайных значений в стандартной библиотеке (которую можно решить сторонней либой, но я тогда про неё ещё не знал). Потом ещё и 0.19 вышла, где "всё сломали". И на package.elm-lang.org теперь меня не пускает без проксирования.

Решил, "хватит с меня Elm, слишком сложно для простой задачи погенерировать картинки".

Вспомнил про Quil - это такая надстройка над Processing/ProcessingJS, которые как раз и предназначены для generative art. Подумал, "Пусть без типов, но и результат сразу виден, так что проживу как-нибудь". "Расчехлил" lein, создал проект из шаблона, запускаю REPL. Внутренняя ошибка внутри либы.

Пошел смотреть в Issues. Оказалось, что проблема с #processing: оный не работает на Java 9+. Что-то у них сломалось из-за изменений в рантайме. Но чинить совместимость с Java 9 смысла нет, потому как она уже не поодерживается. А в последующих версиях уберут (убрали уже?) средства для работы с GUI - по крайней мере те, которые используются в Processing. Авторы Processing не знают, когда получится сделать поддержку какой-то из более поздних версий рентайма. Вот такая вот стабильная платформа с долгим сроком поддержки...

Может быть я ещё вернусь к Quil - #clojurescript-версия использует ProcessingJS. Но эта библиотека отстаёт по фичам от "старшего брата". ClJS не умеет макросы в рантайме. Есть и пачка других ограничений. Да и toolchain вокруг ClJS не вызывает у меня приятных воспоминаний. А когда хочется "быстренько покреативить", то отвлекаться на настройку инструментария не хочется совершенно...

В итоге я взял #racket. И там просто всё работает :) Да, есть своя специфика и язык менее красив, чем #clojure. Но графическая библиотека 2htdp/image - отличная. В JS не скомпилить, поэтому в браузер генераторы картинок уже не экспортируешь. Но жажду творчества утоляет :)

Обычно #racket я пользую через DrDacket - родную среду разработки с отличным REPL и возможностью "копипастить картинки из интернета" :)

Выглядит этот REPL так (котика я скопипастил из интернетов - это маскот языка Scratch)

В моём любимом #emacs тоже есть поддержка #racket, и даже картинки в #repl можно выводить (копировать-вставлять нельзя, увы). И как редактор кода, Emacs значительно мощнее чем редактор, встроенный в DrRacket (тот прекрасен, но в области интергированности в среду и язык).

Теперь я креативлю на Racket в Emacs :)

Вот вам #daily_art (минут 20 экспериментов в REPL, четыре строки кода (в отформатированом виде побольше, конечно)) :)

Ещё #daily_art на #racket (исходник) :) (наверняка в какой-то момент мне надоесть это постить)

Самоповтор с самоповторяющимся #daily_art (исходник) :)

Сделал на своём #web сайтике-долгострое раздел для #daily_art.

Индекс и странички генерируются с помощью shake-скрипта из mustache-шаблонов (это всё на #haskell). Подсветка синтаксиса для Racket-кода делается вызовом CLI-утилитки из пакета pygments (это уже #python). А картинки рендерятся непосредственно вызовом #racket. Вот такой вот монстр Франкенштейна :)

Загружал первую версию контента через web interface редактора сайтов прямо на NeoCites (на нём сайтик хостится). Но в будущем воспользуюсь из API - или сам реализую клиентскую часть, или официальный CLI-tool возьму (который на Ruby написан - ещё один зверь в зоопарк). А в конце это всё можно будет упаковать в Docker-контейнер для красоты и модности :)