Telegram Web Link
Из прекрасного мира фронт-енда

Клиент: жалуется что его приложение работает везде, кроме случаев, если приложение в девелопмент-режиме (как выяснилось, только если бек платформы на localhost)
Мы: не верим. После долгих переговоров получаем все данные

Оказывается
- наше API поднимает вебсокет на /ws
- клиент ставит какой-то очередной ебнутый девелопмент-плагин под webpack, который этот /ws на локалхосте перехватывает
- веб-приложение от всего этого тихо охуевает
- плагин свой /ws конфигурировать не дает

Трясутся руки, кружится голова. Бегу обратно в Rust, а потом на пиво. Много пива.
👍20😁16👎1
.
😁37👍2💩1
Наши капчи
😁42👍11
Наши типичные клиенты

- а вот такой софт знаете?
- вообще мы продаём и интегрируем свой... ну ещё некоторые от партнёров
- я хочу тот
- тогда обратитесь к их интеграторам
- я хочу к вам
- это будет поставить дороже
- я не хочу дороже! я хочу как за ваш. кстати, вы же допишете недостающие фичи?...
😁44💩5👍1
.
😁38👍5💩3
Когда протоколы пишут не программисты, а эффективные менеджеры от энергетики.

В IEC 60870-5 значения регистров устройств могут иметь время, когда это значение было выставлено или замеряно. Чтобы передать время, предполагая что часы синхронизированы с клиентом, обычно используется три байта (формат CP24Time2a).

u16 для передачи миллисекунд (как раз 60к влазит) и u8 для передачи минут. Далее клиент берет свое системное время и заменяет минуты, секунды на полученное значение. Если значение получилось в будущем - значит это на грани конца-начала нового часа и отнимите час.

Поскольку минут 60, а в u8 бит 8 - старшие два бита используются для дела следующим образом: один зарезервирован, а второй показывает что время invalid, потому что давно не было синхронизации часов, например.
😁31👍3🔥1
Насчёт времени. Одной из самых моих интересных задач, на моё огромное удивление, стала задача по чтению логов с плк и прочего ембеда, где время сбито просто наглухо, без возможности синхронизации или с синхронизацией в непредсказуемые моменты.

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

Записи скидывать с устройства на устройство с нормальными часами, само собой нельзя.
👍11🔥1
Вот эти люди, которые программируют на вебсайтах формы, в которые запрещено копи-пастать емейлы, номера кредиток и пароли, только набирать от руки.

Вы понимаете, что вас рано или поздно найдут?
😁76👍28🔥2
Продолжаем про забавные форматы времени. И как трезвому это вывозить?
😁24👍3🔥1
- сначала вас не замечают
- потом над вами смеются
- потом с вами спорят
- потом перестают понимать, что вы говорите

Делал доклад по компонентам синхронизации в Rust, тема сложная, аудитория молчала. Чтобы разрядить обстановку, сказал что Axum лучше чем Actix.

Сразу стало веселее. Будьте ближе к народу.
👍30😁25🔥5
Чем не люблю рабочие дни - в рабочие никогда не дадут спокойно поработать.
👍50😁28🔥4
Ну что, свершилось, я докатился по наклонной до того что сделал свой Mutex.

Конечно для реалтайм-систем. Меня в целом устраивал мой клон parking-lot с частично убранными busy-loops, но коллеги периодически ныли про пресловутую priority inversion problem. Сказать чтобы я этот problem имел в проде - это соврать, потому что не имел, мне при всём опыте ее даже смоделировать нужно пол-часа, как минимум (подтверждено экспериментом). Тем не менее, мне понравилась идея решать priority inversion через priority inheritance, которая уже встроена в Linux-ядро, как опция для futex.

Идея использовать pi-futex для Mutex не нова, даже не нова в Расте, но я пошел чуть дальше и имплементировал для него и Condvar. Тоже исключительно на futex-функционале.

Вообще, futex-функционал в Linux очень неплохой и использовать его только для парковки тредов - это как купить микроскоп, чтобы только забивать гвозди. Но не хватает очевидных вещей. Но об этом в другой раз.

p.s. весь мой RTSC-пак уже на новом мьютексе. Тестировал долго, пока не дохнет. Но при паниках отсутствие яда не гарантирую (сам я, если паникую, то это всегда завершение процесса).
🔥22👍11😁1💩1
Для нормальных игр с фьютексами нужно ядро 5.14+. Но у меня проблема на ноуте - 465й драйвер NVidia собирается только на 5.13 и ниже, а в старших убили backlight (рукожопые "оптимизаторы" выносили его из основного модуля в nvidia-modeset и в процессе немного сломали). Проблема решена в unstable 555, но там сломали suspend.

Пришлось портировать 465й на старшие ядра вручную. Так вот. После того, что я там увидел внутри, пожалуй NVidia я больше не куплю...
😁43👍5💩2🔥1
Вообще тот средний тоже не смотрит. Он легасню под виндой тянет.
😁12👍4
В общем впервые за 3 года поднял на ноуте ядро с 5.13 до 5.14. Пробовал Убунту 22ю - не зашла, какая-то еще глючная...
😁17👍4🔥1
Forwarded from Install Wizard
Invidious создали антизумерскую капчу
😁63🔥7👍6
После вставки зубного импланта под общим наркозом, доктор сутки запретил использовать в коде unsafe blocks.
😁35💩5👍4🔥1
Я (к счастью) не настоящий async-програмер и недавно попал на то, что Future::poll в Rust вызывается не только вейкером. Не смотря на то, что вы явно сказали рантайму, что ушли в Pending и положили свой waker куда следует, поскольку рантаймы пишутся как и все остальное, тоесть через жопу, в некоторых случаях вашу фьючу будут дёргать просто так.

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

Логика здравого смысла подсказывает, что если фьюча ушла спать, то её дёргать не надо, но стандарт говорит чётко - не надо, но не запрещено. Поэтому стандарты лучше помнить, чтобы понимать где и почему.

Даже если оно нелогично.
👍27👎3
Диды помнят
😁64🔥14👍11
это я
😁50🔥11
2025/07/10 06:45:27
Back to Top
HTML Embed Code: