Если юзаете 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 и сможет ли вообще понять сделал он это хорошо или нет

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

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

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

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

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

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

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

Сегодня я узнал, что VK технически представляет собой один большой монолит. Монолит на KPHP, который компилируется в c++. Но ведь c++ тоже надо компилировать.

Я честно говоря не понимаю, как огромная команда может работать по такой схеме. Они же вынуждены синхронизировать процесс деплоя между бизнесовыми командами. Сколько это всё компилируется? 100500 часов?
Как тупо сделать экстренный хотфикс в такой системе? Например, чтобы закрыть уязвимость. Это прямо антидевопс подход.