masterspammer

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

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

Вероятно стоит деталь приварить. Едва ли кто это мне сделает, придётся самому.

Думаю, разрядить конденсатор в стык (по два раза с каждой стороны) будет достаточно. Какой, от скольки вольт заряжать и какое делать остриё - предмет изысканий.

Естественно, деталь сначала сниму. Скорее всего потом отнесу часы на чистку и регулировку - уже пора.

Вот как я в давние времена проверял редакторы во славу Бахуса на удобство и тормознутость: lib.ru, текст побольше (Стругацкие, Толстой - в общем чтоб томик изрядный был), скопировать, редактор, вставить раза два-три. Потом смотреть:

• при печати - с какой скоростью появляются буквы - отдельно при работе в начале, середине и конце текста;


• насколько тормозит форматирование; отдельно - в разных частях и отдельно - для всего текста или его значительной части;


• как работает история правок; насколько быстро и корректно отменяется вставка ещё такого же текста в середину;

Удивительно, но 12 лет назад редакторы (здесь - только web) часто были непригодны для работы с большими текстами. Дело не в мощности процессора (ну вставлю я Войну и Мир не два раза, а пять), а в попытке делать всё синхронно. JavaScript вообще асинхронности любит и умеет, но некоторые программисты - не очень. Или не проверяли ни на чём кроме скромного поста в блоге - там-то конечно, ничего не тормозит!

Из удобства ввода смотрел, насколько помню, сюда:

• работа с кнопкой ENTER - что она делает - абзац или перевод строки, а с шифтом? В идеале просто так - абзац, с шифтом - перевод строки. А в заголовке?


• ввод вперемешку с форматированием, особенно нестандартным (которое не умеет execCommand) - всё ли попадает в историю, всё ли отменяется и возвращается.


• автоформатировани и автозамена - тут редактор для текста, а не для кода (TODO - в кодовых вставках - отключасть) - вообще-то должны быть, чтоб типографские раскладки не насиловать.


• можно ли "убежать" курсором куда-то не туда, где ввод будет ломаться.


• всё ли можно сделать с клавиатуры - слепой десятипальцевый метод нифига не работает, если одна рука на мыши;


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

Из вот этого всего складывается удобство работы с редактором. Подход "писать в офисе, в онлайне только форматировать по минимуму" не на ровном месте вырос; но и онлайн-редакторы не имманентно говно, а вполне закономерно в силу разных своих "особенностей", часть которых я перечислил выше.

Так-то что, бери, разработчик, свой редактор и пиши в нём ВСЁ, попутно исправляя найденные неудобства, но, похоже, двенадцать лет назад так не делали...

Про редактор я писал, что там многое легче с нуля написать, чем поправить.
Для примера - ввод текста.
При вводе пробела и ещё некоторых символов выполняется проверка на автозамену. Например, ввели вы traditionalyl (пальцы запутались), значит нужно заменить на traditionally; аналогично - поправить кавычки, длинное тире, выполнить преобразование markdown-разметки в форматирование. А иногда ввод символа ведёт к удалению - если выделено что-то. Иногда - к большому удалению.
Удаление символа может вообще перелопатить изрядный кусок документа - склеить элементы, удалить внешний контейнер - удалили последний элемент списка - весь список долой.
тоже весело - в зависимости от предпочтений (для чего у DocumentManipulator настройки) или делает перевод строки или новый абзац или ещё один такой же элемент, (пункт списка) или вообще какой-то другой элемент (например, в списке определений после элемента заголовка будет элемент описания). Тут же, хотя и не только тут, возможно полезно следить, чтобы в документе не было текста на верхнем уровне вне абзацев.

По мере написания (вот это всё выше уже написано) становится понятно, что обработать все нажатия клавиш самому во славу Бахуса в общем-то не сложно. От contenteditable остаётся всего-то пользы, что мигающий курсор. Что же даёт "самодельный" ввод? Например, поддержку языка, которого в системе нет и/или экранную клавиатуру - актуально для чужих и общественных компьютеров.

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

1. под 45 град. пилить как бы не легче, чем под 90;


2. нужны какие-то направляющие и подставки, чтоб не на весу;


3. нужны новые диски - просто уже износились;


4. видно хуже, чем под 90, нужна лампа.

В субботу займусь.

Фоток нет, пыльно было и не до того.

Во славу Бахуса начинаю писать то, во что хочу превратить кучу функций редактора. Про UI - потом.

Здесь под документом понимается DOM-дерево, возможно как документ, открытый в iframe, а возможно - фрагмент документа.

• DocumentCursor - указатель на конкретное место в документе.


• DocumentRange - по факту два курсора - "от" и "до", задающие диапазон. Буду ли реализовывать как класс, включающий два курсора или как частный случай DocumentCursor - не думал пока.


• DocumentCursorPickle - сохранённое состояние курсора, независимое от документа - документ сохранён, после загружен, а курсор на то же месте. Вот для этого и нужен DocumentCursorPickle. Может выродится в строку, кстати, но пока это массив.


• DocumentManipulator - класс, меняющий документ; сам по себе никакого документа не содержит и может работать то с одним, то с другим документом - что на вход подали, то и обрабатывается. Подаётся как правило DocumentCursor.


• DocumentEditor - редактор конкретного документа, сам по себе содержит документ и курсор(ы). Неинтерактивен, но пригоден для автоматизации вида найти/заменить.


• DocumentManualEditor - то же, но изменение курсора и редактирование может происходить и "извне" кода, пользователем - путём нажатия кнопок, тыкания мышью/пальцем и т.д... Эти действия могут перехватываться и как-то дообрабатываться. Нажатия экранных кнопок, события от меню и прочие ненепосредственные действия - вызывают обычные методы DocumentEditor. В принципе можно явно затребовать все действия выполнимыми неинтерактивно - легче будет обрабатывать историю - и так их сначала перехватывать и блокировать, а потом вызывать, но это не обязательно.

Про DocumentEditor и зачем он нужен - использовать execCommand не хочется совершенно, а часто ещё и не можется - видите в списке по ссылке formatInline? Вот и я не вижу. И визуальные тэги превалируют над структурными. И по-разному работает в разных браузерах и их версиях. А если сначала вызывать, а потом поправлять, то ломается история отмены и курсор ведёт себя... странно. Не надо так делать, а то до shadow DOM дойдёте :-) Ну и вообще никто не сказал, что всё это счастье видно пользователю - загрузить документ, найти/заменить в нём что-то и сохранить - довольно типовая автоматика.

Интересно, что немалая часть реализована давным-давно и работает начиная с 6-го IE (гыыы!)

Не пишу про историю и отмену, пока обдумываю как лучше реализовать, чтоб с одной стороны не прибивать гвоздями к редактору (для автоматизации оно не нужно), а с другой - не затачивать только под него (штука полезная сама по себе); где-то тут же нужна связь истории с командами и событиями, порождаемыми UI. Не пишу про работу со списками, таблицам и прочим - она архитектурно тривиальна, хотя те же списки в execCommand намертво связаны с blockquote и их пришлось писать почти с нуля.

Когда я в воскресенье вошёл "в личную зону" компьютера (сделал удобно за ним сидеть и сел так на час-полтора), я раскопал свои эксперименты по JS.

Что там - оконный интерфейс на JS и довольно удобный текстовый редактор в нём (картинка - отсюда). Основная идея интерфейса - пишется код, а не разметка (примерно как SWING на Java или там AWT), разметка спрятана глубоко и не факт, что она есть (почему бы просто не рисовать на Canvas с тем же интерфейсом или вообще на аппаратном экранчике). Основная идея редактора - редактируется структура текста, а не внешний вид, внешний вид делается стилями и часто вообще другим человеком. Средства работы со структурой и (готовыми) стилями прилагаются; также в комплекте удобные фишечки типа автозамены, автоформата и древовидной отмены (привет, nabbla1).

1. эта штука работает спустя почти 12 лет после написания, несмотря на местами нетривиальный код.
2. подобного мало, а в совокупности свойств - я не нашёл
3. чего-то подобного от интерфейса мне хочется (утилитарно) часто, в итоге я отказываюсь от того, чтоб выложить ну например мои эксперименты с картинками или другие штуки, требующие GUI.
4. внутри лютый говнокод (на 50% из-за IE, см. ниже, а другим 50 нет прощения), так что даже показывать "как есть" не хочется;

Начал разбираться и переписывать на ООП со стороны редактора, запнулся об отладочный костыль двенадцатилетней давности для редкого случая, делающий этот случай принудительно всегда.

--
Про IE - когда-то давно у него, насколько помню, было два сборщика мусора - для кода JS и для DOMа. Пара ссылок туда-обратно (что более чем просто сделать) и память течёт. Популярность метода - самому создать элемент, самому назначить ему id и самому же по id обращаться, вместо того, чтобы сохранить ссылку и работать с ней - как мне кажется, из-за этого. У меня был другой подход - ссылки из DOM на js лежали в небольшом числе элементов в прогнозируемых местах и при удалении элемента очищались. Тем не менее, сделать объект, например, редактор, который сам знал, где у него что лежит, не получалось, в итоге объектов я не делал и там просто большая куча функций, которые сам знают, где что смотреть - вот это было зря. Правильнее было доступ к элементу обернуть, чтоб там внутри была шняга с getElementBySomeShit или поиск вот тех "прогнозируемых место" в контейнерах и использовать сомнительные прелести прототипного ООП, а теперь бы я исправил эту обёртку и всё.

Радостно болеем всей семьёй... то-то думаю, что сил маловато было - а оно догнало. Делаю всё только наполовину.

В старом компе (в который не жалко тыкать паяльником и пихать полусамодельные платы) не заменил видюшку, но обнаружил, что имеющаяся (какая-то Vanta) работает при немаксимальном разрешении. Пока будет так.

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

Разобрал полстола (место за компьютером). Поработал немного. На оставшейся половине тоже уже можно паять (см. далее).

Нашёл-таки отложенный новый старый телефон (Simens ME-45) и почти заковырял ему новый аккумулятор - осталось только сделать красиво.

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

Вспомнил старый JS - если через 12 лет оно работает, то написано достаточно future-proof, чтобы реинкарнировать.

Если есть Beach Boys, то должны быть и Bitchy Girls, наверное...

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

На днях (как раз за час-полтора до получения уровня плиточника) поковырял драйвера. Взял простое тело с радиусом 30мм (самодельное, однощелевое, латунное, предрупорная камера стремится к нулю). Играет или с 700 Гц до 7 кГц ровно или с 500, но с горбом примерно на 600... Горб появлялся от объёма задней камеры и удлинения рупора (они поднимают эффективность НЧ). Натурально - удлиняю канал, закрываю крышечкой - растёт эффективность в нижней части.

На "родном" же теле выходило ровно 500-5000 (или 6000?)... получается мне в колонки надо скорее всего "родное" тело, потому как если с 500 выйдет, то как раз самое то. Максимум подпилю малость "вершинку" купола тела, чтоб ход увеличить чуток и предрупорную камеру немного уменьшить; но совсем немного.И, насколько помню, при одновременным поднятии эффективности и на НЧ (задняя камера нужного объёма и удлинение рупора) и на ВЧ (предрупорная камера поднимает эффективность... ну до тех частот, где валить начинает) получалось просто ровнее.

Другими словами - если и снизу и снизу - ничего (ни упругого объёма за мембраной, ни под), то кривее. Если же снизу и длинный рупор и маленький объём... то ещё предстоит выяснить и как раз тогда же я законопатил щели под выводы термоклеем - теперь можно закрывать мембрану колпачком (что нетривиально) и измерять, нагрузив на трубу.

--

По цифровым делам - лежат разные ЦАПы (и мультибитные и нет), ЦФ, трансформаторы, которые могут стать послеЦАПовыми при ламповом или каком другом линейным (без ОС) выходе, торы на питание всего этого дела, разные фольговые конденсаторы (WIMA FKP); шустрых операционников нет, увы, но есть TDA1542 :-)

Для вывода есть разные карточки на VT172X, в том числе и на pci-e, готовые платки для i2s через RS485 без гальванической развязки и запчасти чтоб сделать с развязкой. Есть задумка для обратной синхронизации чего угодно через PLL над PLL, но это скорее познавательный интерес. Для SPDIF нет ничего, оптики тоже нет.

Всё вот это я раз собирал "из стекла и клея" и оно работало на всех потребных частотах (44100, 48000, 96000 и с некоторыми усилиями - 192000), переключаясь между ними прозрачно для плеера, но не было никакой гальванической развязки и аналоговая часть... ну какая была. Теперь можно пересобирать и пытаться превзойти сидюк.

Что касается же сидюка - ему бы новый лазер когда-нибудь, да биполярные ключи заменить на реле, а так там всё хорошо, даже лезть жалко. Есть компьютерный на TC9450F - экспериментировать буду с ним. Вот как раз тут и есть корень того, что с "некоторыми усилиями - 192000" - 768fs легко делится до 384fs и 192fs как любят сидюки и до 256fs для компа, но reclock для 192000 из 768fs получается странный, так что попробовать сделать геренатор на 512fs а для сидюка - умножать на три (и делить на 2, 4, 8) - учитывая фиксированность частоты, это очень просто.

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

Как вариант отдыха обдумывается водка с котлетками. Это квест, хотя и очень простой после пельменных марафонов, а мыть мясорубку - мелочи после того, как вчера пришлось отскрЕБАТЬ цементные ведро и мешалку.