Медкарта

Надо вести что-то вроде дневника по работе с клиентом. Вот продали мы прибор, с нами связывается клиент, чего-то хочет. У нас нет выделенной службы техподдержки, поэтому в зависимости от типа проблемы клиента переводят то к одному, то к другому сотруднику.

Вот звонит мне клиент, что-то рассказывает, а я вообще не понимаю, что там у него происходит. Он рассказывает, что провёл с прибором сложную манипуляцию, но он не должен был проводить её сам. А кто ему помог? Или это самодеятельность? Я начинаю ходить по отделу, спрашивать, кто ещё работал с этим клиентом. Что они с ним делали. В результате, я выясняю, что там случилось. Но на это уходят силы и время. Ну и перед клиентом нехорошо получается, когда ты не можешь понять, что у него творится.

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

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

---

Untitled [0711]

Мама: Это что ты делал?
Я: Это я куру с картошкой запекал в пергаменте.
Мама: А почему не в папирусе?

---

Новое блюдо

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

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

Почему пахнет палёным пластиком?!

Срочно убираю планшет -- и понимаю, что я включил не ту конфорку.

Удивительно, но планшет продолжал работать. Однако задняя крышка, увы, оплавилась.

---

Конный кринж

Долгое время я скрывал это от всех, и ещё некоторое -- от многих. Но настало время совершить небольшой каминг-аут.

С осени прошлого года я занялся верховой ездой. Езжу по полям, в компании других таких же чуваков.

В верховой езде много неожиданностей, а также моментов, связанных с самопознанием. Это всё надо записывать, но здесь я про это писать не буду.

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

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

Вот сам канал: t.me/horseswtf

***

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

---

Гренадин

Гренадин -- это сладкий ягодный сироп. Он не стандартизован, т.е. если на двух бутылках написано "гренадин", то вы обнаружите очень разные вкусы.

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

Когда гренадин подходил к концу, я купил ещё одну точно такую же бутылку. Уже после покупки я обнаружил на ней вмятину, но это ладно. Она же запаяна!

Когда я распечатал бутылку, я обнаружил, что запах сильно различается. Дегустация дала однозначный ответ: новая бутылка была заплесневелой сразу!

*пингвин кланяется*

---

Быстрый и мёртвый

После получения запроса микроконтроллеру нужно сделать две вещи:
1. Ответить на запрос
2. Заняться сложными математическими расчётами

В каком порядке делать эти два действия?

Можно поставить целью наибольшую скорость ответа. Тогда мы отвечаем сразу, а потом начинаем считать. Однако это приводит к неожиданным последствиям.

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

Поэтому надо наоборот -- сначала доделать вычисления, а потом уже отправлять ответ.

---

Плакала половина маршрутки

В алкогольном отделе пятилетний мальчик спросил у мамы:
-- Мама, а водку можно пить?
Мама замялась. После двух повторений вопроса она ответила:
-- Можно, но не нужно.
Тогда мальчик спросил:
-- А можно пить водку каждый день?

---

Кёнигсбергский мост, который я хотел перейти

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

Однако вот какие задачи встают периодически перед каждым:
1. Выйти на улицу
2. Зайти в магазины А, Б, В
3. Посетить учреждения Г, Д, Е
4. Выгрузить/загрузить машину
5. Зайти к знакомым на районе
6. Вернуться домой

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

---

Когда оптимизация предусмотрена стандартом

Оптимизация при компиляции часто представляет собой не благо, а проблему. Компилятор на своё усмотрение может выкинуть кусок кода, который счёл ненужным. Да, от этого есть некоторые методы защиты, типа использования volatile, но во многих случаях проще оптимизацию отключить, чем разбираться с её последствиями. Если у вас есть годный гайд по работе с оптимизацией в компиляторах си/си++, сообщите мне, пожалуйста.

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

Один чувак отлаживал программу, и обнаружил странное поведение. Если написать:

if(var||func())//...

то программа работала неправильно. А если написать:

if(func()||var)//...

то программа работала как положено.

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

И это не оптимизация компилятора. Такое поведение предписывается стандартом. Например ISO/IEC 9899:TC3, пункт 6.5.14 (похоже, это какой-то черновик, но данный пункт одинаков во всех версиях) гласит:

... If the first operand compares unequal to 0, the second operand is not evaluated.

Про "или" я не знал, но я давно знал про такое поведение для оператора "и", поэтому для меня оказалось ожидаемо, что с "или" ситуация аналогична. Что же там говорится про "и"? Пункт 6.5.13:

... If the first operand compares equal to 0, the second operand is not evaluated.

То есть, для оператора "и" второй операнд не вычисляется, если первый оказался ложным. Такой вот подводный камень.

UPD. мне сообщили, что в си-шарп и питоне поведение такое же.

---

Система ниппель

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

И есть один момент, от которого я испытываю неудобство. ОКАЗЫВАЕТСЯ, рамки различают, в какую сторону идёт человек. И если человек заходит в магазин, то рамки либо молчат, либо моргают красным -- и всё равно молчат. А вот когда выходишь -- начинают пищать.

Ну вот зачем так делать, а? Если клиент пищит, охрана должна быть предупреждена уже при входе, а не при выходе. Да и клиенту, вообще-то, лучше знать это заранее.

---

Познание разработчика игроком

Все поставили себе Elden Ring, поэтому я наконец сел играть в Dark Souls 3.

Когда я только начинал первый дарк соулс, в него приходилось учиться играть. Навык этот оказался перманентным. Запустив дарк соулс 2, я понял, что уже умею в это играть. В дарк соулс 3 ощущения ещё сильнее, потому что третья часть по геймплею очень близка к первой.

Таким образом, я играю не новую игру, в которой надо разбираться, а как бы продолжение той самой первой игры. И имеющийся у меня опыт -- это не только тактический навык, наличие которого ускоряет прогресс и сокращает число смертей. Это ещё и "чувство уровня".

Уровень может выглядеть как угодно, и может быть устроен как угодно. Но я, заходя на уровень, понимаю, куда надо идти, и что там примерно будет. Потому что я уже таких уровней видел десятки. Они все разные, но у них есть общая концепция. Да, вторую часть делал не Миядзаки, но концепция уровней всё равно достаточно похожа. Таким образом я, как игрок, изучаю разработчика через его игру. Поскольку у меня есть статистика, я уже знаю, как и что он делает.

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

Знание этого позволяет либо подготовиться к неожиданности, либо вообще обнаружить её заранее и устранить.

---

Turing Compete! (игра)

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

Начинаете вы с одного элемента типа NAND (И-НЕ). Далее вам предложат десятки (!) миссий, в ходе которых вам предстоит собрать:
-- другие логические элементы
-- триггер
-- регистр
-- сумматор
-- АЛУ
-- процессор целиком.

А после того, как процессор будет собран, вам придётся его, сука, программировать. Сначала в машинных кодах, а потом на ассемблере.

Это первая половина игры. Во второй половине вам предстоит собрать более крутой процессор и решать на нём более сложные задачи.

Архитектура второго процессора названа авторами игры LEG. Это почти наверняка является отсылкой к архитектуре ARM, поскольку у них есть определённые сходства. А вот почему первый процессор называется OVERTURE я не догадался. Если у вас есть идеи -- сообщите, пожалуйста. Вот, кстати, что я собрал (кликабельно).
Здесь:
DEST_SEL -- селектор целевого регистра операции
BUS_MUXER_v2 -- определяет, откудать брать входные операнды для операции: из памяти, из регистра, или трактовать номер регистра как константу.
REG_MUXER -- на вход получает все регистры, на выход выдаёт тот, который просят.
INP_SW_v2 -- фактически, является УУ (устройство управления). Подаёт команды чтения/записи в память, в стек, или "внешний вход"
ALU_LEG, ALU_LEG_S -- два АЛУ, один для двухоперандных операций, другой для однооперандных
COND_LEG -- блок условных переходов
STACK_CTL -- блок маршрутизации данных стека

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

А кто ещё может в неё играть, кроме айтишников, близких к железу? Не знаю. На эту игру мало отрицательных отзывов, но те, которые есть, сходятся в одном: эта игра ничему не учит. Вы должны либо догадаться о решении миссии самостоятельно, либо загуглить стандартный метод. Либо вы должны ЗНАТЬ решение, как знал решение для большинства задач я.

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


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

Первый касается ассемблера. Не просто так в руководстве написано, что в командах можно использовать логические (побитовые) операции. Байты команд содержат битовые поля, поэтому если вы соберётесь самостоятельно создавать мнемонические команды (а это вам придётся делать), то если не использовать логические операции, то вам придётся создавать по одной мнемонике на каждую команду. Допустим:
mov_r1_r2 (00-001-010)
mov_r2_r3 (00-010-011)
и так далее. Это крайне неудобно, но на первый взгляд с этим ничего не сделаешь, потому что если поставить пробел, то ассемблер начнёт следующий байт, а указания на регистры расположены в том же байте. Вот для этого-то и пригодится операция "или" (труба, "|").
Назначаем коды:
mov = 00-000-000
from_r1 = 00-001-000
from_r2 = 00-010-000
to_r2 = 00-000-010
to_r3 = 00-000-011

После этого становится можно комбинировать поля в одном байте:
mov|from_r1|to_r2 (00-001-010)

Второй совет касается блоков. Не стесняйтесь выделять отдельные функции процессора в блоки. Это сильно упрощает понимание того, что где расположено. Более того, в задаче The Maze, например, я реализовал поворот робота в лабиринте как отдельный блок, чем сильно сократил программу. Есть, однако, минус: блоки сложнее отлаживать. Если вы обнаружили ошибку, то вам придётся вручную запомнить состояние входов блока, потом открыть редактор и их выставить. Это следовало бы автоматизировать.

---

Наказуема не только инициатива

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

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

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

:-О

---

Незнакомый потолок

Пусть надо передать пакет по физическому каналу связи от устройства А до устройства Б. Длина пакета известна. Устройство Б принимает байты, пока буфер не заполнится, а потом начинает разбор пакета.

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

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

---

Почему вырос расход?

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

Однако на практике ОКАЗЫВАЕТСЯ, что в машине всё начинает отваливаться по весне.

Еду -- чувствую, что-то в салоне бензином пахнет, особенно когда включена вентиляция. Да, это отечественная машина, в ней всегда пахнет, но не настолько же!

Доехал. Открываю капот -- вижу картину маслом. С топливного фильтра капает бензин. Прямо кап, кап. Хорошо, что он не капал ни на что раскалённое, иначе бы эти строки я не писал. Беру гаечный ключ, пытаюсь затянуть гайку, которой прикручена топливная трубка. Не помогает. Тогда я наоборот -- откручиваю гайку. Обнаруживаю, что резиновая прокладка разрушена.

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

---

Untitled [0710]

Специалистам по алкоголю надо дарить не то, что им нравится, а то, чего у них нет.

---

Ну что ещё?

Обнаружил, что когда мне звонят на сотовый, я с надеждой думаю, хоть бы спам!

А то вдруг на работе что-то случилось или что-то хотят. Или какая-нибудь ещё ситуация от родственников, например.

А если спам -- можно немного послушать, отключиться, и продолжить заниматься текущим делом.

---

Роджер Желязны // Ночь в тоскливом октябре

Мне досталось иллюстрированное издание с картинками Via Estelar, Эксмо, 2021 год, перевод Ибрагимовой. Картинки красивые, издание качественное, подойдёт и для чтения, и для подарка. Единственное, что мне в таких изданиях не нравится -- мелованная бумага. С ней гораздо красивее, но она очень легко заляпывается. Читайте в перчатках, что называется.

По поводу этой книги мне сестра уже давно плешь проела, но руки не доходили. Её тезисное изложение напоминало мне кое-о-чём. Судите сами:
-- Игроки собираются раз в сколько-то лет, чтобы играть в Игру;
-- Если победят, то исполнится их желание;
-- Игроки -- какие-то архетипические герои;
-- У каждого игрока есть волшебный помощник.

Это же -- Fate/Stay Night. Так я думал.

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

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

Скажу честно, книга мне не показалась похожей на другие желязновские книги, которые я читал (а читал я: Девять принцев Амбера, Ружья Авалона и Создания света, создания тьмы). Создания света -- сюрреализм (насколько я помню; читал очень давно), а это -- магический реализм. Амбер -- тоже магический реализм, но он какой-то... более прямолинейный, что ли. В этой же книжке приходится всё время самому разбираться вместе с персонажами, чтобы понять, что же всё-таки, блин, тут происходит. Это можно было бы назвать детективом, если бы тут были явные загадки и явные отгадки. Но это скорее напоминает познание реальности, или выяснение правил по ходу игры. Разбираться в этом интересно.

Напоследок скажу про отсылки. Часто пишут, что книга пестрит отсылками к старым фильмам, некоторым книжкам и мифологии. Так вот, отсылок МАЛО (не считая двух страниц прямых цитат из Лавкрафта). Есть авторы, добавляющие оммажи не только в образы персонажей, но и в реплики, сцены, сюжетные ходы. Здесь этого либо нет, либо я настоящий невежда. Да, в пояснениях в конце книги разобраны некоторые отсылки, и там действительно есть персонажи, с которыми я не знаком. Возможно, когда я с ними познакомлюсь, я увижу больше (а так почти всегда бывает), и пойму, что был неправ. Но пока вот так.

---

Нет, но да

Работали мы с определённым датчиком, который получал значения с частотой, которую можно было выбрать из значений 1, 10, 50 и 100 герц. По нашим задачам мы измеряли с частотой 100 герц. Мы пользовались такими датчиками постоянно, поэтому закупали их небольшими партиями.

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

-- А вот раньше у вас была частота 100 герц, а теперь нет.
-- Да, теперь только 1 и 10.
-- А почему?
-- Ну... мы так решили.
-- А нам вот нужна 100 герц.
-- Хорошо, сейчас мы вам пришлём альтернативную прошивку.

И прислали. И мы прошили этой прошивкой, и всё заработало.

С одной стороны, я, конечно, хочу отметить клиентоориентированность. А с другой -- блин! Вы чего делаете! Вы спецификацию у серийного изделия, которое выпускается годами, мало того что меняете, так ещё и ухудшаете? Причём, видимо, без особо серьёзных причин.

---

Genjitsu Shugi Yuusha no Oukoku Saikenki 01-13 END

Итак, сегодня я тестирую новый хостинг изображений!

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

А препод говорит -- стрелять-колотить! Сколько лет преподаю -- обязательно кто-нибудь из аспирантов берёт тему про Макиавелли! Однажды все аспиранты прошли, остался последний. Я думаю -- ну, может в этом году не будет? Он вышел и сказал -- "Тема доклада -- Макиавелли".

О чём

Юный любитель Макиавелли неожиданно попадает в мир, где получает возможность реализовать прочитанное на практике.

Что думаю

Бывают произведения, типа "твёрдая" фантастика. Если же речь идёт о политике или экономике, то может получиться "твёрдый" исторический роман. Если помните "Волчицу и специи", то вот там как раз всё очень хитрО показано.

А здесь не совсем так. Герой-рационал -- действительно рационал, но больно хорошо у него всё получается. Все только восхищаются -- вау, ты и это предусмотрел! Схемы не такие сложные, как, скажем, в No Game No Life, но всё же достаточно сложные, чтобы можно было удивляться вместе с его гаремом тому, что он такой предусмотрительный. А вот чему другие персонажи не удивляются (а следовало бы!) -- так это такому малому числу просчётов. Чем план сложнее, тем больше точек, где что-то может пойти не так. И если пройти план пошагово может быть относительно легко, то как себя вести, если план нарушается? Мне было бы как раз интересно посмотреть не на то, какой герой умный в "статике", а какой он умный в "динамике", когда приходится думать на ходу.

Есть другой, немного похожий сериал: Hyakuren no Haou to Seiyaku no Valkyria.

Рекомендации

Очень актуальный сериал, смотреть всем прямо сейчас. Второй сезон сейчас онгоинг, кстати.

Скриншоты

(скриншоты)

Король отрёкся -- и теперь наконец может развлечься со своей женой.


Очень интересный подход в этом сеттинге к двигательной установке военных кораблей.


:3


Это называется "Нусрет Гёкче" (загуглите)


Такова жизнь при экономическом кризисе.


Метаморфозы?


С летающего дракона падать -- это вам не с коня! Нужна какая-то страховка, наверное.


Няшная лисичка.


Как выглядит осада в мире, где есть магия.


Прям Наполеон.

[конец]