inv2004 Dev Blog

Podlodka #404 – Системы эффектов в языках программирования - краткий пересказ @bravit на протяжении двух часов делает вид, что рассказывает _не_ про Haskell и разновидности Control.Monad: IO и Exception. Даже применили хитрость "давайте не называть конкретные языки" Видимо, то, что на картинке он с дудкой, имеет завуалированный посыл, что он играет всё ту же мелодию как и большинство "функциональных" подкастов https://music.yandex.ru/album/7570122/track/134382774 Кстати, в Nim есть контроль эффектов

Накидал по-быстрому PoC https://go.dev/play/p/GBWen9_0UQI Наверное для возврата error вообще канал не нужен - сразу в структуру ставить просто, заодно танцы с закрытием каналов убирает ... посмотрел x/sync/errgroup - там так и есть — added — через поле https://go.dev/play/p/1wTm8hCoy5s , но, конечно, 5 раз надо подумать, что тут может сломаться — added — Из примера не очевидно, что .Go вызывается только один раз и, что канал может быть буферизированным #golang

Концепт, который пока не удалось дотащить до логического конца: errchan Есть запрос к базе, но который не выполняется мгновенно, а возвращает данные постепенно, по мере обработки. Вопрос: как это запихнуть в чистейший код? Как оказалось, каналы для этого не считаются чем-то нормальным. Хотя, я никогда сильно разделял то, что возвращает функция: []int или int, или лямбду, или канал - всё это first-class citizens (как перевести?) в golang. Решение, которое сразу пришло в голову: - Самописный итератор. Минусы: 1) самописные итераторы в go не то чтобы такая простая для использования конструкция, как хотел бы чистый код. 2) исчезает _бесплатная_ буферизация, которую дают каналы — буферизацию надо писать отдельно в сервисном слое. Плюсы: 1) легко ловить ошибки из repo-слоя. - Передавать замыкание в repo. По сути, разновидность итератора, но более гибкая. Получается, repo не оперирует каналом, а просто вызывает замыкание, которое само уже может писать в канал. В целом показалось, что решение хорошее, но, опять же, repo работает не самым очевидным способом. Использует ли repo канал, если его использует лямбда — наверное, больше философский вопрос. - Итератор iter. В чате подсказали, что, оказывается, в go всё же есть итераторы https://pkg.go.dev/iter, хотя в реальном мире я их не встречал. Решение ок: формально, как в 1 и 2 — мы оберегли repo от использования канала, избежали самописного итератора что тоже хорошо. Но проблема (2) осталась. Логика того, как этот итератор прокидывает ошибку наверх — не самая прямолинейная. https://go.dev/play/p/7V7631Mr0yB - Решение без чистого кода. https://go.dev/play/-YdPQ1ufQpV- Плюсы: бесплатная буферизация. Функция repo, возвращающая канал, что, имхо, сразу показывает, что данные надо обрабатывать по мере прихода. Минусы. Не ясно, как прокидывать ошибку, хотя и можно накостылить чуть более сложный тип у канала или передавать errgroup, что опять не приветствуется в чистейшем. Для себя я пришёл к выводу, что всё же без чистого кода решение лучше, дополню то, что это не всегда канал, это может быть io.Writer или что-то подобное между сервисным и api слоем. А попытка избежать этого приведёт к ещё одной порции костылей в каждом слое, который с этим взаимодействует. Но, при этом, мне почему-то кажется, что в go не хватает конструкции, которая бы объединила errgroup + chan. Ведь когда-то сделали errgroup и считают её достаточно стандартной. Предположим, назвать её errchan. Будь такая конструкция и repo могла бы её возвращать — это было бы самым понятным решением, которое, в то же время, не теряет своей эффективности. Но, не исключаю, что я, вероятно, не до конца понимаю, зачем так рьяно оберегать repo на предмет возврата только простых типов, особенно если это вредит и простоте, и даже производительности. Кстати, может, такое уже есть? #golang

Самое скучное go-сообщество генерирует максимально увлекательный контент 🎥 @ntuzov нащупал блоггерскую жилу и продолжил развивать ранее упомянутую тему https://t.me/inv2004_dev_blog/131 На этот раз свёл жабу 🐸 с гадюкой 🐍 в прямом эфире. Если в двух словах, то собеседующих менеджеров, «представляющих сообщество», отсобеседовали с применением типично менеджерских приёмов. Даже отчасти стресс-интервью, судя по странному хамоватому поведению одной из сторон с самого начала (не одобряю). В конце Николай даже добавил контента, оттоптавшись на проигравших, но, справедливости ради, вовремя опомнился. Как обычно, воспринимать это, кроме как развлечение, серьёзно не стоит, по причине, что, как это часто бывает, стороны говорили, не понимая, что оппонент разговаривает про что-то другое. Сторона «нанимающих» рассуждает о материях, которых не существует на начальных уровнях ИТ. #golang https://www.youtube.com/live/nkcUzameNtY

2100й год, у каждого на столе квантовый компьютер на 1000кубов, который уже умеет большую часть обычных алгоритмов. Golang умееет quantum-goroutines => теперь не стесняясь запускают 10^16 воркеров, но, почему-то оно не сильно быстрее, видимо в диск базы в квантовом облаке упирается, так как там ещё квантовые репликации в фоне. Фронт, браузер и редактор всё так же лагают, так как прорисовка происходит перебором квантовых состояний VDOM, но, для работы квантового-GC, надо делать stop-the-world. Надо купить новый комп в 10000 кубов - тогда пару лет можно не думать об обновлении В k8s-сервисе крутятся сразу 10^9 квантовых подов, полученных из 10^9 PR которые послал quantum-copilot В Linux-сообществе раскол относительно использования проприетарного quantum-драйвера, а открытая реализация переодически подвешивает систему

Раскладки 2/2 Попытка использовать курсора как Ctrl|Alt+IJKL провалена Причины: - навигация по коду занимает большу'ю часть времени - зажимать левой рукой не выйдет - делать это одной рукой, а в другой держать чашку чая - нормально - зажимать модификатор правой рукой, а это надо делать практически постоянно - утомляет - вообще другое расположение рук, когда используешь ноут лёжа Но, зато, стало понятно, что, вроде как, эти проблемы решаются подходом когда у тебя есть переключатель режимов. Т.е. по сути - разделение режимов редактирования и навигации, привет Vim, так что, в качестве эксперимента, я опять пытаюсь использовать Vim как IDE (на этот раз www.lazyvim.org) на рабочей кодовой базе, пока оно не слишком в горячей стадии. И, пока, Lazyvim вроде справляется. Но, тут тоже есть вопросы, например telescope - т.е. ты можешь набирать буквы для поиска, но бегать по списку найденных файлов, с помощью JK уже не можешь, надо использовать Ctrl+NP. А обычные курсорные клавиши работают всегда и везде - удобно. Так, что пока, перестаю продолжать себя мучить TouchCursor, но начинаю (снова) мучать Vim, хотя я всегда был небольшой его поклонник, скорее даже противник, хотя из-за linux-специфики, использовал довольно много. Посмотрим что из этого получится. Из плюсов - на старом ноуте vim выглядит заметно легче чем VSCode, но это чисто на эстетическом уровне. Потому как, когда-то, на этом же ноуте я фрилансил в VSCode, параллельно собирая докер в докере и не особо страдал. https://t.me/inv2004_dev_blog/120 https://t.me/inv2004_dev_blog/128 #layout

Так-то, на самом деле, не выглядит слишком заумным, кроме специфичного растовского Pin<>, при попытке сделать websocket в actix было куда страшнее:

Хотел было переехать на web-sockets, и тут, actix-web, казавшийся нормальным в качестве http показал, что структура для ws должна делаться так: Client<SinkWrite<Message, SplitSink<Framed<T, Codec>, Message>>>

https://t.me/inv2004_dev_blog/28 #rust #компьютерный_юмор

Как я проходил стресс собеседование в Агава 20 лет назад В плюсах ещё только появлялись smart-pointers, а я был студент и одновременно работал. Основной стек тогда был Web: Perl+CGI+базы. Появилась вакансия на что-то подобие тим-лида (тогда такого понятия, кажется, даже и не было). Отпросившись с основной работы поехал отсобеседоваться в их офис куда-то под Москву на электричке, что уже было утомительно. На месте оказалось, что они позвали более 12 человек. Вот тут и началось. Нас позвали в комнату с компьютерами, они даже включались, но, клавиатуры выглядели настолько грязными, что прикасаться к ним казалось даже опасно. В итоге удалось достать клавиатуру, которую не было страшно хотя бы касаться. Дальше предложили несколько заданий по мере нарастания сложности, где последнее - написать подобие простого файлообменника с логином. HR озвучили, что у нас 6 часов на решение всего. Мы начали делать, повезло, и первые задания я проскочил довольно быстро, когда я завершал задачу, то ко мне подходили какие-то их сотрудники, мы общались о решении и я переходил к следующему. В плане задач - в тот момент я был настолько прогрет по этому стеку - так как на работе занимался ровно тем же, что первая часть прошла очень легко и даже с отрывом от окружающих. Дальше было интереснее - прошло заметно времени, и логично, что кто-то из людей захотел выйти покурить или в туалет, на что HR начала категорически возражать против этого, аж до того, что сказала, что может только проводить их в туалет по одному или типа того, я наблюдал за этим краем глаза, но уже это вызвало сомнения в желании работать тут. Конечно, начался скандал, и, человека 4 просто ушли. Постепенно кто-то отваливался в процессе. В итоге, к финишу, я догрёб первый и практически один. Так как начали мы ~ в обед, то и закончилось уже вечером (но, почти, на час раньше чем давалось). И, оказалось, что их работники уже разошлись и подвести итоги особо некому. Удивившись такому раскладу я предупредил (и даже говорил это ещё до приезда), что я не смогу отпрашиваться ещё на один день. Я поговорил с кем-то, кого всё же нашли в офисе и уехал. На следующий день мне утром прислали email, а потом начали активно звонить чтобы я сегодня, максимум завтра, приехал в офис повторно для продолжения собеседования, я сказал что не смогу. После обеда опять начались звонки - сначала от HR, которая _категорически_ сообщила, что вакансия очень почётная и мне надо приехать, отказался ещё раз, и тут мне уже начал звонить кто-то из техдиректоров толи того офиса, толи Агавы и, нервным голосом, говорил что приехать нужно _мне_, потом подключилась HR и началось многоголосье, из чего я понял, что не особо совместим с данной компанией и отказался. На отказ я услышал, что могу не приезжать, так как я всё равно не прошёл собеседование. PS: А к Perl'у я до сих пор тепло отношусь, не смотря на хейт его синтаксиса. Даже на Perl-6 хочется что-то написать в качестве развлечения

Про Low-end IT IT делится на high-end и low-end. При этом всё low-end пытается мимикрировать под high-end. Так что, хорошим тоном считается не только предъявлять к работникам завышенные требования на входе, но и, в процессе работы, пользоваться рыхлыми аргументами из лучших практик high-end. Примеры таких аргументов: "меньше связанность", "потенциально лучше производительность", "проще поддержка". Причём, так же легко выдать аргументы ровно в противоположную сторону - "лучше связанность", "хорошая расширяемость", "более надёжное решение". Произносить их в разговоре можно в любом рандомном порядке - это мало что меняет. Причина же этого заключается в том, что важные цели и метрики, как правило, совсем другие от тех, что озвучивают - важны только сроки, отчёты об успешном внедрении, всё остальное, на самом деле, уже не особо важно. В high-end, метрики, которых надо достичь, более чёткие, например стабильность или производительность. Когда как в low-end, никто не знает в какую сторону, кроме сроков конечно, нужно тянуть - хуже но раньше, или наоборот, и какой баланс по многим остальным вопросам. Тянуть во все стороны, разумеется нельзя. Ещё один признак - хаотичное направление работы, как, например, в один день все плюют на производительность, на другой, зачем-то спорят (без проверки - на это нет времени) о микросекундах, а, на следующий, опять забывают об этом. Выводов особо никаких нет - просто не надо обманывать себя и, по возможности, трезво оценивать свою роль и положение в текущем времени и пространстве.

Теория категорий для программистов и с картинками. Чтобы, хотя бы, в разных морфизмах не путаться. https://docs.racket-lang.org/ctp/index.html #bookmark

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

#компьютерный_юмор

Ни ты и ни я не знаем, что произошло В продолжении https://t.me/inv2004_dev_blog/124 насколько нормально сообщать об ошибке теперь не важно В обновлении Win-10 на одном из ноутов прилетел MS Copilot. Перед тем как удалить, решил нажать на него и получил картинку. Строки: 1⃣ менеджерская шутка большими буквами - юмор позволяет сгладить плохие качества продукта 2⃣ боязнь написать что-то конкретное => боязнь написать что именно надо сделать 3⃣ бесполезная кнопка с надеждой, что перезапуск поможет Помню раньше смеялись над ошибками типа: error code 4294967295. Abort. Но, даже подобное, содержит на порядок больше информации чем скриншот

Хорошо, что я не слышал термина "вкатуны", когда начинал с компьютерами - врядли бы тогда захотел в ИТ

Так как люди прочитали не то, что я имел ввиду, и, в этом конечно есть моя вина, то поправляю: Николай к курсам не имеет никакого отношения и просто делает видео контент, как-то напрямую его ассоциировать с инфоцыганщиной у меня мыслей не было

Вам здесь не рады

каналов с курсами "войти в АЙТИ" => каналов про "войти в АЙТИ"

Прослушав несколько реклам курсов => Прослушав рекламу курсов и конференции

Отдельно про курсы => Отдельно про ситуацию с курсами вокруг АйТи

#интернет_драма

Вам здесь не рады Я-то думал, что IT-интернет состоит в основном из ламповых плюсовиков, которые чинят свои сегфолты, и из чатов по разным языкам. Но, неожиданностью для меня, оказалось количество каналов про "войти в АЙТИ". Наткнулся я на https://t.me/ntuzov/528 , где Николай Тузов монетирует свои знания, что я только одобряю. Тема обсуждения конечно "войти в IT". Прослушав рекламу курсов и конференции, начали обсуждать, что же делать. Не знаю как у других, но у меня монитор покрылся желчью от увиденного. Удивительно то, что генерировали её гости довольно уважаемые. Один из участников вообще ближе к концу попытался поделить людей на голубую кровь и холопов. Ключевое, что люди видят проблему в отрасли, при этом, как сами говорят, определяют отрасль, но, при этом, почему-то, не видят проблемы в себе или своём подходе. Спойлер: за два часа менеджерских (читай - довольно поверхностных) рассуждений, не смогли декомпозировать проблему и накидать хоть какие-то решения, которых, на самом деле, сильно больше чем выданные лайфхаки "через родственников попробуйте" и "купите наши курсы". Забавно также наблюдать как с одной стороны @upovod рассуждает с точки зрения, что рынок порешает, а с другой, недовольство @onokonem, что рынок порешал какие-то неправильные зарплаты. Ещё представитель менеджмента говорит о том что задачи лит-кода очень лёгкие и уметь решать их надо даже не задумываясь. Отдельно про ситуацию с курсами вокруг АйТи, хотя я и далёк, но, кажется, что продажа курсов/конференций/менторинга для пытающихся что-то освоить начинает принимать очертания инфоцыганства, так как мало кто гарантирует результат, что и показало видео. Хорошая аналогия из спорта - что условный МС, выигравший несколько соревнований, пытается тут же монетизировать свою популярность, и начинает тренировать других, но, в большинстве случаев из этого мало что получается, потому как хороший спортсмен и хороший тренер - абсолютно разные профессии

Стремимся к нулю #компьютерный_юмор

Ничего удивительного Наткнулся на подкаст подлодки про производительность приложений. Немного не ожидал, что это про андроид, но послушал. И реально - в Яндексе умнейшие люди, столько тонкостей именно про скорость загрузки. Самописные загрузчики для ускорения. Молчу уж о том, что паяльниками делают свои стенды для замеров сколько ест батарея, про всякие фермы разных телефонов для оценки производительности приложений. Послушал и нажал на значок яндекс-go чтобы почувствовать на себе все эти оптимизации. Начал считать - десять секунд оно показывало сплеш-скрин, потом пробежала анимация на нём, потом появился основной экран, но при этом бегала полоса как будто загружается контент, хотя снизу какие-то рекламные предложения маркета уже подарили мне тепло и шаурму. А потом ... эээ ... опять сплеш-экран и опять анимация. Зациклилось что ли? Потом опять экран без контента, ну а потом стал появляться - секунд 30+ я насчитал. И, в добавок, тут же закрыли всё рекламкой на 1/2 экрана. Но ведь люди там реально прямо шарят судя по подкасту, ну как так-то? Впечатление, что там куски браузера внутри. Хотя в браузере за 5 секунд открылась страница #yandex

Раскладки. 1/2. Накидал вариантов 20 раскладок. Вот один из вариантов, который отпочковался от Vim. Но, многие признают, что, в стандартных кнопках курсора HJKL дотянуться до H и, тем более до Y - довольно проблематично. Решение => сместить всё немного правее. Как только сместил - стало значительно удобнее. Проблема вторая: Почему-то это много где игнорируется, но перемещение по словам важнее перемещения по символам. Мало что удивляет так, как видео очень опытного пользователя vim/emacs в ютюбе, которой в какой-то момент начинает тыкать раз 20 H чтобы добежать до нужной позиции в строке. Отсюда вытекает следующая проблема. Проблема третья: На кастомных клавиатурах очень хвалят слои. Например мы поставили управление курсором на Caps, тогда, чтобы выделить слово правее надо нажать Caps+Ctrl+Shift+Право, что, мне кажется, сильно сложнее чем Ctrl+Shift+Право даже если надо дотянуться до курсора. Тут, приходит в голову, что слои (количество модификаторов) надо сокращать - просто всё повесить на Ctrl. Что именно - Ctrl+Стрелки и Ctrl+Страницы. И вот именно на картинке эти кнопки, довольно гармонично встают в отдельный, нижний, ряд. Ctrl+Страницы используются во многих приложения для переключения между вкладками: в терминале, в браузере, даже в telegram. Недостаток такого варианта: IJKL или OKL; Ʇ-образный курсор всё же не просто так появился, а потому, что удобнее. Но, вот тут уже к другой части - там не очень понятно как расставлять все эти дополнительные кнопки #layout

^^^ о важности оптимизации набора на клавиатуре у программистов, и о том, как много времени занимает перенос правой руки с home-row на курсор и обратно #layout