Господин Архитектор

"Ребята, хватит заниматься ерундой. Персонального компьютера не может быть. Могут быть персональный автомобиль, персональная пенсия, персональная дача. Вы вообще знаете, что такое ЭВМ? ЭВМ — это 100 квадратных метров площади, 25 человек обслуживающего персонала и 30 литров спирта ежемесячно!" (Заместитель министра радиопромышленности СССР Николай Горшков) Эту цитату приводят как демонстрацию косности, отсталости мышления, и из нашего времени она действительно так выглядит и таковой является. Но была ли эта точка зрения уникальной, свидетельствовала ли о том, что автор - дремучий самодур? В качестве аргумента тут принято вспоминать расцвет и скорое признание кибернетики на условном Западе. Однако стоит посмотреть еще на кое-что: Я думаю, что мировои‌ спрос на компьютеры составит примерно пять-десять штук. (Президент IBM, 1943 г. ) Я изъездил эту страну вдоль и попере‌к, общался с умнеи‌шими людьми. И я могу ручаться, что обработка данных на компьютере является лишь причудои‌, мода на которую продержится не более года. (Редактор издательства Prentice Hall, 1957 г.) Никому в голову не приде‌т забавная идея иметь компьютер в свое‌м доме. (Основатель и президент Digital Equipment Corp., 1977 г.) Как видно, позиция замминистра была не уникальной, а вполне сообразной точкам зрения руководителям DEC и IBM и другим "умнейшим людям из США" из разных отраслей – даже непосредственно занятых компьютерами. ... Но потом в США в какой-то момент всё изменилось. А в СССР не случилось; важное отличие. Кто был этот "тот", кто заставил думать иначе – Пентагон? остается только догадываться. Ну а в продожение предлагаю почитать и подумать над неплохой статьей.

О блин, прикол. Я чуть было девственности не лишился через линедин. Пишет рекрутер: 150-250к вилка, блокчейн криптостартап, вот сайтик,в о вакансия. После короткого разговора: "готов сделать оплачиваемое ТЗ перед звонком?". Мне тут стало интересно как и в какой момент меня хотят поиметь. Ну всё выглядело как скам: и предложение ТЗ, и зарплатная вилка в крипте которая на дне, и сайт компании. Взял ТЗ: зип архитв гит репозитория. Код внутри обычная, внение зависимости все понятные: std, chi router, pg. Чтобы начать делать ТЗ надо переключиться из main бранча в другой бранч. Додумался проверить гит хуки. А там пост-чекаут хук - скачать скрипт, запустить, он установит ноджс, скачает жс скрипт, который скачает бинарник и засунет его в автозагрузки

Очень сильно поразило (прямая речь с разрешения автора)👇

Об привычки разработки Забавно, как"незыблемые" приемы разработки из книжек меняются прямо на глазах. Спустя некоторое время возникнет новая норма, а про старую забудут. Например, посмотрим на конфигурационные файлы. Они были нужны, когда сборка отдавалась отдельным людям, не разработчикам, которые и отвечали за конкретный облик средств развертывания, и могли бы настроить имена серверов, строки подключений, тайминги, ретраи и прочее. Т.к. типичная современная картина это ci/cd и деплой в корпортивное "облако" в режиме dev & ops, то смысл конфиг-файлов пропадает -- лучший конфиг это просто и незамысловато написанный код на основном языке приложения, а если нужно поменять настройки, меняем код в репозитории и передеплоиваем. Или возьмем asserts. Теперь отладочный стенд тоже находится в облаке, смотреть на ассерты некому, все смотрят на прошедшие/упавшие тесты, так что контрольные утверждения в коде никто не расставляет. По этой же причине никто не собирает дампы упавшего сервиса, как и отладку неживую обычно не ведет: отлаживать удаленные микросервисы в пошаговом режиме неудобно, дампы из облака тащить неудобно, так что -- заливаем на стейдж, кидаем туда контрольные примеры, смотрим логи и тесты, да и только. В комментариях можно дополнить подмеченным

Почему Excel не может одновременно открыть два файла с одинаковыми названиями? Когда-то давно, когда первая бета-версия Excel называлась Incel, запись дискет с дистрибутивом планировалось осуществлять на бывшем авиазаводе, где для прокладки кабельных трасс…

Почему Excel не может одновременно открыть два файла с одинаковыми названиями? Когда-то давно, когда первая бета-версия Excel называлась Incel, запись дискет с дистрибутивом планировалось осуществлять на бывшем авиазаводе, где для прокладки кабельных трасс при сборке сверхсекретных бомбардировщиков F-19 использовали хорьков (потому что сборщик пролезть в некоторые места не мог). Кроме того, на заводе была узкоколейная железная дорога на той же хорьковой тяге, которую решили оставить и использовать для доставки дискет к месту упаковки. Тележка узкоколейки, сделанная под габариты хорька, была по ширине чуть больше пятидюймовой дискеты, а две трехдюймовые уже не влезали. Когда было принято стратегическое решение выпустить продукт на трехдюймовых дискетах, оказалось, что из-за габаритов узкоколейки дистрибутив должен помещаться ровно на одной дискете - и тогда начали резать уже реализованные фичи. Когда до целевого объема дистрибутива в одну дискету оставалась какая-то сотня байт, возможности оптимизации почти исчерпались - и вот тогда было принято решение идентифицировать файлы только по названию, что сэкономило 98 байт из ста. Последние два байта удалось отжать сменой названия продукта с Incel на EXCEL - второй вариант чуть лучше сжимается с помощью run-length encoding. Под нож пошел проект рекламной кампании In cell, где зеки в камере строят офис с колл-центром, пронося продукцию Microsoft на зону в трехдюймовом воровском кармане, но это уже совсем другая история. Вот так ширина хорьковой жопы определила функциональность одного из ключевых продуктов Microsoft - а в следующих версиях оказалось, что некоторые пользователи из-за невозможности открыть два файла с одинаковыми названиями проверяют с помощью этой недофичи существование файлов. Именно поэтому это решили оставить - потому что обратная совместимость решает все! С вами был Redmond Chlen, штатный сказочник M$!

Если в языкомодельном ИИ все будет идти так, как идёт, то в ближайшем будущем мы получим картину, аналогичную распространению MS Excel: - стоит у каждой домохозяйки на компьютере - используется на 0.1% и не каждый день.

Об апдейты В качестве текстового редактора я довольно давно использую VS Code. Обратил внимание, что в последнее время он просто озверел в смысле апдейтов. Типичный день выглядит так: 1. Открываешь редактор 2. Предлагаю скачать апдейт 3. Отказываешься 4. Все равно качает апдейт, устанавливает, переустанавливает, опять качает, показывает информацию, что обновился. 5. Предлагает еще что-нибудь новенькое скачать. Иногда качает не с первого раза, но всегда развертывается, к счастью. Если установлены плагины, то такое происходит еще чаще. Уже не представляю себе, что можно просто открыть проект и начать работать, а не ждать, когда приедут опять обновления. Гонка по кругу за новыми фичами-фичулями становится невыносимой. Единственное, что останавливает этих мразей от того, чтобы публиковать апдейты каждые несколько минут — необходимость, чтобы мясные мешки написали и протестировали новый код. С ужасом жду, когда с широким распространением ИИ мы придем и в эту ситуацию.

Чтобы перевести компанию на рельсы AI, достаточно везде надписи Loading.. поменять на Thinking..

Переводчик для менеджеров Работая с людьми, вы могли слышать эти выражения. Вот перевод их на доступный для всех язык: "Мы начали работать/разбираемся": никто не знает, будет ли результат и когда "Нам надо вернуться к этому": мы не станем этим заниматься никогда "Я не лезу в процессы": я понятия не имею, что там происходит. "У нас выстроена система": у нас есть общая табличка (чат), мы всё в неё пишем "Мы проанализировали": работа не начата, и её начало скорее всего, и не запланировано "Нам осталось": см. "мы начали работать" + "нам надо вернуться к" "Можно повторить, я прослушал": давайте проедем этот вопрос

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

Как отсортировать отложенное информационное сырье, не читая его. Называется НАВЕСТИ ПОРЯДОК В ЗАМЕТКАХ. Как человек, немного повернутый на заметках, совершенно не рекомендовал бы так делать: система должна идти "от сердца" и быть в центре, а инструмент - на периферии. В данной статье автор всё с ног на голову переворачивает - я видел такое много раз, и почти всегда люди забрасывали ведение заметок. И я их понимаю — это не заметки, это бесполезное скопидомство. https://habr.com/ru/articles/936946/ Большинство статей об Obsidian говорят о настройке инструмента: какие плагины, какая тема, как синхронизировать. Это интересно. Это затягивает. Но это отвлекает от сути, от содержания, от созидания. Более того - настройка Obsidian не особо отличается по полезности и удовольствию от просмотра сериалов или компьютерных игр (где размышлений и логики надо применять ничуть не меньше). Всё.

Познавательное про tty и ptty: 💻 https://wandrien.github.io/articles/tty/

Завалишин (DZ) написал на Хабре кое-что, и среди этих букв я нашел очень интересное - как LLM похоронит Protobuf: Если вы очень хотите двоичный протокол и я не смог вас остановить – [чем опираться на Protobuf,] лучше опишите его в хорошей спецификации, и любой ИИ напишет вам по этой спеке реализацию за минуты на любом ЯП. Это займёт даже меньше времени, чем интеграция protobuf, и код будет вам подвластен.

Как быстро оборудовать дрон цифровой видеосвязью на базе OpenIPC? Не очень сложно, даже длинный пост не получится. Понадобится: 1. Камера как на картинке ниже (на картинке ssc338q, но есть и другие) 2. Беспроводной wifi-модуль 3. Понижающий преобразователь на 5В для питания модуля 4. 2 pigtails, антенны, термоусадка, опционально маленький радиатор-кулер, провода и прочая монтировка 5. Четыре напечатанных детали из пластика - две одинаковых крышки и два донышка (stl файлы приложу) Детали печатаем, из камеры выкручиваем шпильки и собираем донышки жеппкой к жеппке, в одной крышке собираем камеру, в другой модуль питания и wifi к нему. Для использования на улице достаточно небольшого радиатора или вообще без него, для больших дальностей или в помещении лучше поставить активное охлаждение. Соединяем, через ssh прошиваем прошивкой OpenIPC с одноименного сайта, как это сделать - все написано. Там же настраиваем на желаемые параметры кодек, мощность передачи и так далее. Закрываем крышки, монтируем на дрон, наслаждаемся FulHD картинкой без единого разрыва и латенси в районе 40-70мс. Реализация наземной станции остается читателю в качестве самостоятельного упражнения на уик-энд.