Подробнее
Сказать программисту, что для того, чтобы делать X, уже есть библиотека, это все равно что сказать певцу, что о любви уже есть песня
приколы для даунов,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
приколы для даунов it-юмор geek
Подробнее
Сказать программисту, что для того, чтобы делать X, уже есть библиотека, это все равно что сказать певцу, что о любви уже есть песня
приколы для даунов,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Подробнее
Сказать программисту, что для того, чтобы делать X, уже есть библиотека, это все равно что сказать певцу, что о любви уже есть песня
приколы для даунов,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Уж лучше не тянуть всю библиотеку, а перетащить к себе в проект нужную её часть. Самим же проще будет потом.
Пока у тебя простое - скорее всего либа тебе подойдёт. Но всё равно есть вероятность притащить вместе с либой целый фреймворк, который тебе и нахуй не всрался, потому
что либа самостоятельно не существует.
Что-то специфичное - и адаптация легко может быть на порядок труднее самописного. Неисправимые баги либы - в подарок.
То на маке эта библиотека не линкуется из-за конфликта версий.
То когда все же собрал под мак, выясняется, что библиотека использует сервис который идет в комплекте какойго то проекта, который стоит денег, больше не продается и последний раз работал на версии мака 2014 года и на новых системках уже не стартует.
То на том самом виндовс ноутбуке крашится вся система при старте в момент загрузки этой библиотеки.
То библиотека кушает 77 петабайт ОЗУ, а без неё прога ест всего 2МБ.
Лучше б сам написал
Лучше б сам написал, чем либу юзал.
А в остальном, прекрасная маркиза, все CSV, всё цэээ эс ве.
Руками это относительно легко парсится, а сторонней либой - это будет болью в жопе.
А это так, повод достать свою виртуальную медальку грандмастера легаси и костылестроения, и написать парсер.
Есть несколько игр с собственным велосипедом, и как же я рад, что решил написать это решение. Несколько раз испытывал боль с обновлением популярного аналога в области разогретого стула либо из за прекращения разработки, либо из за очень сильного изменения библиотеки, делающего его обновление болезненным. "Своя" же библиотека не заточена на красоту, ошибок ака deprecated не будет, интерфейс не меняется, только дополняется.
Из минусов: да, однажды я поменяю место работы и для того, кто придет на смену - моя самописная библиотека станет таким же шитбургером с датой последнего обновления репозитория на дату ухода из кампании. В прочем есу ничег оне помешает продолжить её дописывать по мере необходимости.
"Внутренняя либа", разрабатываемая одним чуваком\маленькой командой как побочный продукт в процессе работы над основным проектом, без полировки большим комьюнити - всегда говно.
Тут ппц сложно все. Надо естественно сесть и оценить плюсы и минусы. В любой непонятной ситуации брать 3rd решение - такой же говноподход как и всегда писать велосипеды.
У нас был случай на фирме: чуваки почти два года пилили сериализатор, чтобы по сети передавать координаты игроков и прочие данные. Клиент все это время платил зарплату целой команде.
Кто не знает, что такое сериализатор, то это то, что сжимает данные. Пример с конем в вакууме:
"вася пупкин одетый в доспех Пиздобола сидит в локации Новокукуево с бафом Проперженный диван"
в
"usr:100500;loc:13;arm:PZD;buf:-pd"
и эти данные можно быстрее передать через сеть. А на другой стороне происходит обратная операция, называемая десериализация, когда сжатая строка превращается обратно в "вася пупкин...".
Надо ли говорить, что на такую крайне необходимую функцию уже давно есть масса библиотек и решений. Я, если честно, даже не знаю как им удалось уговорить клиента писать свой сериализатор, и почему не подходили другие варианты.
Подушню, сериализация -- перевод в формат, позволяющий записывать в битовую последовательность, которую уже можно отсылать по сети или в файл.
>>уже давно есть масса библиотек
Ага, например в json, который весит как мамонт. Или как пример дефолтная бинарная сериализация в .net не является секьюрной, что не рекомендуется использовать с сетях с недовереным подключением (игровые клиенты из них). Какой-нибудь protobuff не умеет во все стандарты языка. В итоге свой говнокод в целом может иметь смысл, правда при условии что там все же действительно нечто бинарное, а не как пример выше (подозреваю что это для общего понимания).
Ну и сериализатор это не то чтобы прям что-то мега жирное для написания, особенно если ты делаешь "для себя" и можно забить на обратную совместимость.
Вам надо втащить в проект либу номер один. Она вроде решает задачу, всё збс.
Втащили, накатали тонну кода, который её использует.
Потом - то же самое, но с либой номер два.
А потом вы сталкиваетесь с ситуацией, когда в либе номер один (или два, не важно), вам надо сделать мааааленкий фикс, который вам просто блокер на данный момент.
И есть превосходная новость: этот фикс за вас сделали авторы либы! Замечательно, обновляем версию, и полетели!
Ой, а чо это оно не собирается? А, ну у второй либы с этой есть общие зависимости, хули, говно вопрос, обновляем и вторую, чтобы сравнять версии либы 3, которая у обоих в дереве.
Что? Обновление до нужной версии либы 3 обновляет 3 мажорных версии либы один, и у них полностью переписано апи(вариант: нет совместимых обновлений)? Аааааааааа, сууууука.
Добро пожаловать в ад.
Либа 2, делающая нужное, зависит от либы 3 5.0.5+
Либа 1 вашей версии зависит от либы 3 до 2.0.0.
Либа 1 с зависимостью от 3 5.0.6 несовиестима с вашим кодом, и требует переписывания всего.
Добро пожаловать в ад.
Я там был.
Благо исходники автор предоставляет
Для начала в го 100% обратная совместимость. Я дом труба шатал с питоном, хоть он мне и нравится. Не надо надеятся, что импорт с этим разобрался - всё будет норм по умолчанию.
Почти всё опенсорс. Может это лично моя болевая точка, но черный ящик - самое злое.
Все зависимости нужные можно указать вплоть до хэша конкретного коммита, в том числе можно и указать те, что прям точно не нужны, если очень хочется, либо ренж какой-то. Контролируется это ещё при компиляции, затраты времени на которую стремятся к нулю (несколько сотен тысяч строк кода обычно компилится секунд за 10-30). Не будет такого, что поднимаемая инстанция гитлаба через 10 минут вдруг скажет, что чет не работает. Я конечно люблю кофе попить, но это такое себе.
Отсутствуют как класс цикличные зависимости - компилятор объявляет ещё при сборке, что херню натворил. Казалось бы, это и есть проблема, но когда все пакеты такую проверку проходят, то становится легче дышать, но неизбежно появляется и ситуация ниже.
Проблема того, что пакет А1 использует версию Б1 0.42, а импортируемый пакет С1 использует версию Б1 0.421 решается на уровне разных (а иногда и одного при нормальном объявлении подходящей версии) го.мод и го.сам. Решается простым декларированием такого пакета как самостоятельного модуля и пусть он использует что ему нужно. И всё вместе со всеми непрямыми зависимостями тестируется встроенным в компилятор инструментом где-то за пару секунд.
Если зависимостей чёт много и хрен разберешься, то тот же компилятор может сам вычистить всё ненужное. Исключением будет это: https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-indirect-and-test-dependencies-in-my-gomod
Ну это если вкратце то, что мне заходит и что вспомнил так сразу. Пока проблема с зависимостью если и появлялась, то решалась за такое смехотворное время, что даже упоминать её не стоит.
https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell
Или на днях нужно было считать скользящие средние, всё хорошо библиотечка популярная, куча всего, скользящие средние на любой вкус. Но проблема в том, что обрабатывать мне нужно было десятки гигов данных, и как можно скорее. Решил глянуть внутренности библиотечки. И там такие перлы, к примеру, сумма 1+2+3+n считается тупо в цикле, хотя достаточно простой формулы n * (n+1) / 2.
В итоге, переписывание 2 функций по 5-6 строчек из библиотечки дало ускорение в 70 раз.
оставлю ремарку, что тут, скорей всего, имеются ввиду "известные мне попсовые решения", а не "правильные юникс-вей"
Правильный юникс-вей - использовать, например, find + delete, который не разворачивает * в список аргументов.
Когда либа, вместо того, чтобы делать всё в цикле, обрабатывая поток, пытается загрузить всё сразу, посчитать результаты, и выдает тебе эти результаты.
Вот только данные у тебя на терабайты, потому никак иначе, чем перемалывать постепенно поток, немедленно сбрасывая результаты в другой поток(ибо они не особо меньше), вариантов просто нет. Это медленнее, чем посчитать по датасету в памяти, но когда датасет не лезет ни в какую память...