csvq - SQL-like query language for csv
Продолжаем тему работы с данными в терминале. CSV - удобный формат, но еще удобнее работать с ним написав SQL запрос

https://github.com/mithrandie/csvq

Философия и технологии

Ядерная реакция может дать энергию и быть во благо, но может уничтожить планету.

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

И т.д.

Даже эти вопросы до конца не дорешали, хотя им сто лет в обед.

И ведь опять происходит какая-то такая херня, причем очень быстро.

Этот год, например, прям богат на прорывы в области нейросетей.

ChatGPT поддерживает беседу, сочиняет стихи и сценарии, переводит и пишет простые программы.

Dalle2, midjourney и тд уменьшили порог входа в графический дизайн почти до нуля

Copilot помогает писать код всё лучше и лучше

Даже на войне, говорят, используются интеллектуальные помощники по оптимальному управлению войсками.

И всё это проявилось за какой-то сраный год.

Опять философия отстаёт от технологий. Человечество наступает на все грабли, и лишь после этого думает о том, что будет дальше.

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

Сейчас: сначала сделаем, а там посмотрим, что будет.

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

Если, предположим, какие-то ИИ-подходы радикально упростят или заменят сложные профессии ( программирование, бизнес, копирайтинг и тд), то что будут делать люди? Торговать пивом? Для чего?

Что смогут напрограммировать автоматические программисты с бесконечными ресурсами, какой пиздец это готовит миру?

Сейчас некому взвесить "за" и "против", а скорость изобретений зашкаливает.

Философы, где вы?

Чему учить детей сейчас, и какой в этом смысл?

Является ли человек венцом эволюции или же он лишь промежуточная ступень для алгоритмов?

Где общественная дискуссия на этот счет?

Может, эти вопросы надо задавать сразу боту chatGPT? :)

Если юзаете Gitlab, чекните бекапы, некотрые репозитории при бекапе помечаются как Empty и не попадают в бекап, хотя они не пустые. Можно неприятно удивиться.
Баг еще жив в версии 14 как минимум: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28854#note_24652059

Не моё (хз откуда оригинал), но гениально ))))

Хотелоь бы подискутировать, провалидировать мысли.

Имхо ORM в целом работают плохо. В веб-приложениях, интенсивно работающих с базой, часть бизнес-логики (условия, джойны, группировки) неизбежно встроена в SQL-запросы (а не только существует в коде приложения), поэтому в случае ORM происходит автогенерация сложных SQL, которая по любому работает через жопу, неоптимально, да еще и плохо дебажится. DBAшники не менее чем в 50% своих выступлений упомянают примеры SQL, порожденных ORM-ками (там обычно зло ацкой сотоны из чорного ада).

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

С другой стороны, query builderы (не ORM, а просто построители запросов) часто помогают в случае, когда есть форма с миллионом необязательных галочек и инпутов, и строить сырой запрос конкатенацией - можно тронуться умом и допустить секьюрити проблемы.

Поэтому лично я для себя пришел к такому выводу: везде стоит писать сырые запросы, кроме тех случаев, когда надо запрос собирать из частей. Но и в этом случае использвать условный Squirrel (query builder для Go), а не условный Gorm (ORM для Go). Да, писанины немного больше, но код становится при этом более понятный и поддерживаемый.

В мире Go вообще не оч принято использовать ORM, фреймворки и т.д., пара лишних строк кода - это всего лишь хорошее медитативное занятие (c)

Дженерики в Go в действии

Наконец-то заапрувили proposal по включению универсальных функций для работы со слайсами https://pkg.go.dev/golang.org/x/exp/slices в стандартную библиотеку. Насколько я понимаю, это будет уже в GO 1.21.

Господи боже мой, теперь можно будет поискать элемент в слайсе через стандартную библиотеку!!!!11111одинодинодин
Отсортировать слайс любого ordered типа одним вызовом без костылей
Сравнить два слайса

и т.д.

Я джва года ждал! Да что там, джесять лет! Кто там говорил, что дженерики в го не нужны?

продолжаю учить английский, записывая видосы
https://www.youtube.com/watch?v=Q7gncqWvJW4

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

Если кто еще не видел, на что способен GPT4: https://www.youtube.com/watch?v=outcGtbnMuQ

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

Нейросеть пытается текстом нарисовать "девятый вал" Айвазовского. Получается что-то очень странное )))

​​Уважаемая аудитория, у нас апдейт

Добры молодцы и девицы, у нас новина!
Из-за частых челобитных от вас об использовании в наших писаньях да лубочных представленьях басурманских словес, над писарями пестун наказал выписать толмача и впредь баять токмо на родном языке.

Челом бьём, вече NEWHR (Новый вербовщик)

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

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

Статья от моего камарада Анатолия. Вот это заморочился мужик!! А-хре-неть!!!

https://vc.ru/life/671075-pol-eto-lava-istoriya-razrabotki-prototipa-interaktivnoy-svetodiodnoy-igrovoy-platformy

МОСКВА, 27 апреля. /ТАСС/. Президент РФ Владимир Путин согласился с необходимостью развивать собственные протоколы связи взамен зарубежных TCP/IP для обеспечения технологического суверенитета и независимости страны.
https://tass.ru/politika/17633161

Принципы S.O.L.I.D. - говно, потому что невнятные, и требуют толкователя.

Я в этой индустрии десятилетия, и регулярно натыкаюсь на очередное объяснение или, наоборот, уточняющий вопрос. Недавно опять в твиттере наткнулся на "а что для вас SRP?".
На Хабре наверно уже 100 статей, одна другой хуже. Всегда по одному сценарию: кто-то пишет, как он понял, а ему суют в панамку, что на самом-то деле подразумевалось совсем другое. Очень похоже на толкование Библии, прям один в один.

Пользуюсь ли я SOLID? Не знаю. Я пользуюсь опытом. Уж точно не сверяюсь после каждой строчки кода, а удовлетворяет ли это, например, букве O.

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

Даже наоборот, как начнут паттерны везде пихать на ровном месте - код вообще не понять.
2+2 складывают через три пизды и 10 абстракций.

Понимание того, где гибкость нужна, где нет - имхо не особо формализуемо.

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

Просили покритиковать какой-нибудь язык. А я не хочу, хочу посравнивать Angular и Go. Да, я знаю, что ангуляр - не язык, а фреймворк, да еще и фронтенд, и сравнивать их тупо, но я все равно буду :) Ну, я же испытываю эмоции при использовании, значит их можно сравнить.

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

Однако время шло, и судьба меня закинула сначала писать бекенд на Go, а потом, что ещё страннее, параллельно писать фронтенд на Ангуляре.

И вот мои наблюдения. То, что ты пишешь на Go, ты понимаешь полностью. Взял полено, выточил перочинным ножиком из него Буратино. Максимально просто. На ангуляре же ты машешь волшебной палочкой в надежде, что случайно всё сработает, и потом пытаешься понять, почему всё так странно выходит. То носа нет, то руки из жопы.

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

В Ангуляре это жесть. Компонент может молча не отрисоваться, потому что ты в модуле в магическом месте не подключил другие магические модули. Или подключаешь к компоненту свой scss файл, и ошибся в пути. Получшь ошибку типа "include не сработал" (не помню точный текст) без указания строки кода или хоть какого-то намёка на причину проблемы.

Вообще, концепция конфигурации вместо программирования я теперь считаю сомнительной. Явное всё же лучше неявного.

Модули ангуляра придумал враг людей, ацкая сотона. Зато простейшая программа выглядит солидно: ты там что-то вечно декларируешь, импортируешь, компонуешь и тд., сразу видно, что умный. В го наоборот, чувствуешь себя тупым, код выглядит так себе, но всё, блять, понятно и работает.

Ну так вот, если Ангуляр и соизволит выдать ошибку, то это будет стектрейс на 100 строк, состоящий на 99% из магических обёрток.

В Go же ты сам явно определяешь, где как и что выводить. А магия и обертки там не приняты.


Скорость компиляции.

Go компилирует код мгновенно. Я хз, как это работает, но это волшебство. ×10 к скорости разработки.

Ангуляр же - пока переведёт из тайпскрипта в js, пока разберётся в своей магии, пока разогреет компьютер до состояния сковородки - пройдёт вечность.

Кстати, в go много бессмысленной писанины, и это раздражает, но с появлением copilot это всё за тебя пишет робот. Ты только пишешь if, а он уже добавляет err != nil, пишет в лог или там возвращает ошибку дальше. Магия, какой она должна быть.

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

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

У меня всё. Подписывайтесь на наш канал, в следующей серии буду сравнивать jQuery и Haskell

В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.
Вот примеры.


DRY
Например, DRY - don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.


«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY - хороший принцип, но бывают исключения.

KISS
Keep it simple, stupid. Всем хотелось бы держать программу простой, но иногда приходится всё усложнить, чтобы добиться ускорения разработки, уменьшения количества ошибок и т.д. Например, KISS может войти в прямое противоречие с тем же DRY: код с дублированием зачастую проще понимать (меньше абстракций и зависимостей), зато это огромное поле для ошибок (забыл поправить в третьем файле) и замедление добавления новых фич.


В фунции не должно быть более чем X строк, длина строки должна быть не более чем Y и т.д. (правила линтера)
Обычно этот X придумывается от балды. В таких случаях хочется спросить, почему именно столько, а не на одну больше или на две меньше. И обычно время от времени появляется вполне валидный код, который по каким-то причинам не влезает, и люди извращаются как могут, переписывают через дичь, чтобы как-то пайплайн протащить.

Мы пишем только на таком-то языке
И начинаются пляски с бубном вокруг PHP, на котором пытаются завести highload-решения. Это выливается в интереснейшие инженерные задачи, как из говна и палок сделать самолёт. Бесконечные темы для докладов на конференциях.

и тысячи таких

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

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

Есть два момента в собеседовании
1. Когда ты рассказываешь о своем опыте. У тебя банально не хватит времени. Каков бы твой опыт не был, какие бы задачи ты не решал, у интервьюера нет столько времени в собеседовании что бы тебя полноценно выслушать

2. Вопросы интервьюера которые по тысячу раз встречаться на других собеседованиях и объективной оценки они конечно же не несут

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

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

Они не дадут вам понимания сможет ли кандидат что то написать самостоятельно с пониманием того что ему нужно на условном webpack и сможет ли вообще понять сделал он это хорошо или нет

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

Они не дадут вам понимания будет ли кандидат соблюдать существующие принципы проекта, а не придумывать свои правила на код ревью, а ведь из-за этого идет потеря нервов и время на урегулирования ситуации

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

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

И много всего другого

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

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