Да ведь вкусовщина. На первом не сыграет, да, а на втором-третьем, если с головой на плечах - сыграет и проиграет наверняка. Было бы интересно, правда, посмотреть, где с FOL начинают. Все-таки относительно SOL + топологии это редукция, что несомненно полезно для формализации, но дает свои минусы для познания. А вот реально качественные формализации всем (без малого) студентам по жизни никак не пригодятся.
И тот же диагональный метод вполне описывается прозой и на интуитивном уровне понимания ∀ и ∃.
Тут на хабре, в среднем пару раз в год пишут "статьи" вот такие вот интуитивно понимающие, о том, что вообще континуума не существует и они могут это доказать.
Ну и продолжая вкусовщину, я благодарен за то как меня учили и с чего начинали, потому что матан я, кажется, даже в припадке не забуду. Во многом базовый, конечно, но, главное, для меня все предельно просто, и все что забыл легко выводится.
В FOL уже буквально с диагональным методом Кантора возникнут такие проблемы, которые младшекурсникам не по зубам, а ведь надо как-то пределы вводить. Непрерывность определить. Ну да, выше Вы писали про ZFC, но пока уже другие будут спокойно интегралы по контуру считать, придется сидеть на парадоксе Банаха-Тарского. Мне не кажется, что это может быть проще.
не знаю, как надо относиться к работе и к своему профессиональному развитию <...>
Так мир программистов на C++ он очень разный, чуть ли не полярный. Куча проектов еще живут, которые стартовали на c++03 из соображений производительности, но не той, где наносекунды считают, а где джава рантайм таскать с собой никто не будет а дотнет тогда еле шевелился. Всякий десктоп, локальный энтерпрайз, какие-то модули-числомолотилки, в которых аллокаций вообще нет, специализированная техника, и так далее. Там сидят люди и во всем этом варятся и никакой необходимости в новых компиляторах у них нет, а уж тем более и в новых стандартах. Все равно целиком проект переписать никто не даст, а исправлять по частям смысла мало. Ну и железо все время становилось быстрее, так что если не используешь квадрат, там где n log n хватает - уже большой молодец, а даже если используешь, ну когда (скорее если вдруг) тесно станет, то кто-нибудь починит.
Я как-то на таком работал, например, так вот на работе только палки в колеса ставили, а дома... а дома я выучил C#, меня этот язык реально радует. А часть бывших коллег вообще на эту ерунду еще и дома время не тратили.
И смотря насколько глубоко понимать. О Pointer Provenance как по мне любой недавний джун имеет представление, когда по ручкам настучали за reinterpret_cast везде где хочется и нельзя. std::launder на фоне этого вообще не должен никаких проблем вызывать (только решать), но есть тонкость, что его в C++17 ввели и есть прекрасный шанс ни в одном проекте его не увидеть. Я, пожалуй, чаще видел людей, которые про Strict Aliasing не слышали. Сложно ли это? Да не особо, было бы желание.
Именно так. Это у Вас еще хорошие цифры. Я не понимаю как люди легко "выбивают" белые айпишники за 1500рублей, у меня ничего не получилось. Плюс EU vds-ки за 300 и дешевле либо нельзя оплатить, либо они умудряются не вытягивать даже 100Мбит/с. Наверное есть исключения, я не знаю. А входные РФ узлы улетают в бан быстрее чем подписка на месяц заканчивается (и она еще дороже, конечно).
Согласен. А 30 минут (и это еще быстро?) кода на доске это вообще какая-то пытка, так или иначе. Доска для архитектуры (совсем простенькой) и, ну максимум, FizzBuzz, если любите немного поиздеваться (но зачем?).
Ну я бы тоже подзавис. Кто-то ждет ответа, ну это просто "syntactic sugar", а кто-то будет ждать, что "указатель это отдельная переменная, сама имеющая адрес в памяти". Такой вопрос гарантированно попадает в "вопросы с ожидаемым подвохом". Отличий, как по мне, больше чем сходства. Больше в сторону, чем std::string отличается от int.
Впрочем, да, это не повод молчать и чего-то ждать.
Очень смелое заявление. Я слышал, что 80% сеньоров не могу за пять минут написать работающий FizzBuzz и это может и гиперболизированная, но похожая на правду вещь. А тут... хочешь - не хочешь при изучении C++ с указателями ты столкнешься, и если мы про raw pointers, а не про более новомодные штуки как weak_ptr, то каких-то тонких, но рядовых особенностей, которые можно не понимать или как-то неправильно интерпретировать в них просто нет. Ошибаться легко, но не по причине непонимания, а по причине их неудобства и не безопасности.
Унижать так-то можно любым достаточно известным, но мало полезным знанием, было бы желание (и хоть какой-то смысл).
Но аналогия с таблицей умножения неверная, пусть у человека "от зубов и не отскакивает", сколько будет шестью восемь, но он сможет дать правильный ответ спустя какое-то время, а значит считать все же умеет.
Аксиомы планиметрии... а почему тогда не список персонажей "Войны и Мира"? Примерные размеры планет солнечной системы? Правила игры в шахматы?
Мне, несмотря на оконченный математический ВУЗ, аксиомы планиметрии пригодились ровно чтобы сдать экзамен в школе по аксиомам планиметрии, не больше не меньше. Это не матан, который сплошь и рядом всплывает, и не теория вероятности, без которой вообще сложно себя считать человеком рассудительным.
И, казалось бы это несложное знание, но я изначально не склоняюсь считать простым то, что кажется лишь интуитивно просто; вот про аксиому принадлежности я не только не вспомнил без википедии, но и не вспомнил бы ее вообще, если бы мне нужно было самому создать аксиоматику. Меняет ли это хоть что-то в мире? Да вообще ничего. Это даже в геймдеве не нужно, и когда дачу строишь тоже как-то безразлично на то, что каждый отрезок имеет длину, большую нуля, потому что нулевыми отрезками как-то даже в голову не приходит крышу крепить.
Вот те же аксиомы Пеано еще попробуй забудь, если узнал. Но их почему-то даже обычно не проходят в школе. Но раз уж без этого жить можно, то что уж говорить.
Кажется для заморозки старых монет это все и затевается. Не очень понятно, что так радикально изменилось с 20 года относительно квантовых компьютеров, но опасающиеся квантовой угрозы пользователи вполне могут сами первести свои средства на SegWit/Taproot кошельки и это должно сработать.
Как для пользователя, одна из основных проблем в неприличном разнообразии дистрибутивов Linux, и на всех из них есть свои особенности. Разные пакетные менеджеры, разные фаерволы, и что конкретно более неприятно, разный UI. Даже если десктопных менеджеров в принципе обозримое количество (но их много), шрифты почти везде немного разные, иконки разные, дефолтные настройки немного отличаются, и в этом разнообразии, хоть кто-то и находит определенную свободу, я нахожу определенное стеснение. Это все бросается в глаза без полезной нагрузки; привыкать к одному дистрибутиву непозволительная роскошь, ибо мало где тебе переставят Ubuntu на твой любимый, например, Linux Mint, а настраивать UI чтобы было точь-в-точь, это далеко не один конфигурационный файл (и это не та работа, за которую платят). В итоге пользуешься и немного страдаешь. Ubuntu вроде бы самый популярный дистрибутив, но там дефолтные настройки UI как по мне вырвиглазные.
Майкрософт тоже не порадовал с Windows 11, но с десяткой было все так хорошо, что это просто не замечалось.
И пусть сами в это играют. Пока задач, которые требуют больше 16GB DDR4 исчезающе мало (кроме собственно LLM). И если такая задача вдруг появляется, то докупить памяти как бы не невозможно :) Но, скорее всего, их в обозримое время просто не будет. А комфорт, ну вот у меня остался мини-пк с 4 GB DDR4, вот на нем работать уже не комфортно. Не невозможно, не сильно сложно, но не комфортно. А так, в основной комп напихал где-то десять лет назад 64 GB, просто потому что она стоила совсем не дорого, относительно других компонентов. С тех пор было ровно две задачи, где "чем больше памяти, тем лучше" и то разовых, тут проще было бы арендовать VPS. А в остальное время, повторюсь, изчезающе редко больше 16 используется, с учетом системных кешей, которые по максимуму выставлены.
Было такое короткое окно, когда типовая конфигурация пред-топовой машины это много памяти, маленький SATA SSD и большой HDD, там в ряде сценариев память давала серьезное ускорение. Тогда же я игрался с RAM-дисками, но это проще как кошмарный сон забыть, потому что они "всегда маленькие", не персистентные, и опять же, в абсолютном большинстве сценариев, хоть и выигрываешь машинное время, но теряешь свое личное, размышляя, что туда надо загонять, а что не надо. Потом появились доступные NVME SSD и все это шаманство потеряло смысл.
Но и огромный NVME тоже не нужен. Конечно хочется, чтобы игры запускались на 20 секунд быстрее, хочется не покупать HDD, хранить на SSD и фотки, и музыку, и все приложения, но когда он посыпется, будет уже не так весело.
Вот а я пишу код. Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
Обе проблемы важны, требуют решения, но обычно в грамотно организованных командах они решаются через фиксацию промежуточных результатов. Это важно еще и с другой стороны, что "недоделанное" решение, имеющее полезные артефакты (ту же конфигурацию, где проблема повторяется) можно перенести на другого программиста, если у изначально ее решавшего, появляется более срочный кейс.
Даже менее консистентные промежуточные результаты в большинстве компаний фиксировались, если это тикет на плавающий баг, то ежедневно обновляется план дальнейшего исследования, и фиксируются попытки, которые не привели к результатам. Поначалу, там, где не было так принято, некоторые носы ворочали, а потом сами убедились, что очень удобно придти в понедельник "с пустой головой" и понять с чего надо продолжить. А тикет всегда добавляется в PR.
Может изначально я как-то слишком прямолинейно начал, но, хоть и не отрицаю проблем, описанных в статье, утверждаю, что решение уже есть, и оно в организации работы команды. Для хаба "управление разработкой" это как бы довольно очевидно.
Но я видел массу примеров в весьма крупных финтехах, когда разраб пофиксил багу и никаких тестов не появилось, а ручник даже не удосужился сделать несколько скринов о том, что он это протестил. Вы скажете, что это проблема команды и процессов. Нужно повесить техлида и разогнать сеньора QA. Возможно. Но идеального мира не существует. Косяков полно везде.
Вот именно. Я бы это бы и сказал, может помягче, но суть та же. Не надо позволять работникам даже играть в Генри Форда. Если не ставить документирование о выполненной работе в процессы команды, то очень быстро команда фрагментируется до тех кто использует отсутствие лишней вербозности себе в плюс, и на тех, кто от этого "молча" страдает.
Это сломанный процесс, который раньше решали либо глупыми и формальными KPI, либо ежедневными собраниями по полчаса, где все отчитываются друг перед другом что делают (но слово не воробей), либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает).
А проблему "старается"/"не старается" не нужно решать. Вот допутим некий Коля берет некую "сложную задачу" (потому что либо плавающая, либо описание неполное, либо ранее ее уже кто-то брал, но не справился, или она снова всплыла). Оценивает ее в две недели. Открывает отладчик, и начинает там рандомные какие-то пути гонять, в код поглядывая, надеясь что проблема на глаз найдется. А что, времени еще уйма, если он ждет решения в три строчки, то он хоть в последний момент его может разродить.
Прошла неделя, проблему Коля не смог воспроизвести, но уже в принципе придумал решение в 5 строчек, как ее вообще закостылить. Сидит дальше в отладчике ковряет. Вот уже два дня осталось, Коля уже коммитит свой workaround в 5 строчек, в тикете пишет, "проблема не воспроизвелась, но теперь она точно не вылезет". Надеется на чудо в пятиницу, но если что готов, сделать PR того что есть. Старался? Ну да, наверное. Или просто фрустрировал. Но дело не в этом, дело в том, что проблема решена хреново. И это выстрелит при первом же существенном рефакторинге. И Коля это знает. И теперь, чтобы не встрять еще долго он не будет брать задачи связанные с рефакторингом.
Допустим я беру такую задачу. Первым делом пытаюсь уточнить подробности о проблеме, чаще всего они исходят от клиентов продукта/сервиса, параллельно добавляю логирование всех хоть как-то связанных с проблемой мест. Логи естественно отключаемые. Сразу добавляю несколько тестов, которые хоть на моей машине и будут зелененькими, но есть шанс, что где-то, хоть на CI мигнут. Мигнут тесты, будут логи, будет понимание проблемного стейта. Если проблема еще более редкая, то уже буду просить клиентов, понятно через службу поддержки, развернуть апдейт, который якобы чинит баг, ну и здесь понятно что можно и дальше рабочий процесс рассказывать, но да, это не игра в одни ворота. "Коля, отладчик, код, и тишина". Здесь нужна организация. Часто люди за этим и идут работать в команду.
И так у них и складывается понимание, что есть хорошая команда, а что слабая, что есть удобная организация, а что бардак. Хорошие практики закрепляются, эволюционируют...
И тут Вы правы, дело не в 2005 году. В принципе это просто часть моего опыта. Но где-то с тех пор, ни в каких других командах (а не все из них были прям супер) такой практики как "две недели - три строчки кода" ни в прямом ни в менее строгом значении уже не существовало.
А когда нет юниттестов, логов, билдсервера, CI, автотестов, специалиста поддержки пользователей, таск трекера, гита, - хотя бы чего-то из этого, то путь может быть сложнее.
Когда одна из бирж отваливается вы что делаете? Свой коннектор открыл и поправил, а тут что делать? обновление библиотеки ждать?
В общем случае, да, либо исправляю библиотеку, либо пишу workaround. Другое дело, что API бирж категорически редко меняется, и даже при изменениях, уважающие себя биржи, просто дают эндпоинт /v2 .. /vN и все продолжает работать у тех, кто не желает обновляться. С ccxt проблем не было. Это своего рода стандарт в области.
Когда пилишь чтото в одно лицо - я за готовую субд. Но это, естественно, зависит от крутости и вовлеченности программера.
Если на определенном этапе мы еще не знаем, как конкретно будем обрабатывать данные, то все же БД преждевременна. А бинарные файлы даже без команды штука простая, их логику любой ИИ может запрограммировать на худой конец. Просто так мы сможем позволить себе выбор БД в последствии, исходя из конкретных задач, ничего не потеряем, и сохраним исходный интерфейс. Что у биржи мы могли спросить какая была цена актива/объемы торгов aaa на время xxx, что у бинарного файла. Это чуть лучшее решение, чем когда мы поняли, что в БД нам не достает данных, судорожно запускать догрузку этих данных напрямую с бирж (это может быть очень небыстрым процессом).
Ну и БД мы на самом деле не обязаны писать курс каждого тикера на каждый момент времени, можно группировать все тикеры с одной биржи на момент времени, и записей будет в 200-500 раз меньше. Ценой правда некого дополнительного неудобства работы с ними. В любом случае, не та задача, где нужно как-то обходить проблемы производительности жертвами.
О том 2005, где в небольшой компании живет жесткий водопад, репозиторий cvs (это хорошо, если так) и файлики. Там же в этих файликах выкидывались какие-то progress_module1.txt, какие-то сборочные артефакты, какие-то тестовые бинари и у кого как. Тогда да, работа это то, что попадает в репозиторий, а остальное раз в месяц сносил админ (на самом деле эникей, которого пнули, что место на шаре мол кончается). В тех же файликах еще нередко валялись фотки с новогоднего корпоратива, ppt презентации для заказчиков, какие-то небольшие игрухи. Замечательные были врема, спору нет...
И если Вы продолжаете в них жить, да при текущем уровне зарплат, то ничуть не сострадаю вашей проблеме, скорее просто завидую.
Но какие багфиксы на три строчки в этом мире? Говорите, плавающая проблема? Так первое с чего начинают, строят образ проблемной конфигурации (даже в самом унылом случае, это виртуалка с специально сконфигурированной средой, которая попадает потом в бинарные артефакты), а чаще это отдельный бранч, где плавающий баг специально доталкивается до повторяющегося отдельным кодом. И это еще до непосредственно исследования бага и его исправления. Потом отладка, и исправление. Да даже если непосредственно обход проблемы занимает три строчки, нужно всегда смотреть на окружение этого кода, постараться рефакторить то, что этот баг скрывало. Ну и в конце концов тесты. Чтобы вот четенько было видно, что до фикса тест был красненьким (да-да, этого не обязательно можно добиться юнит-тестами, и тогда проблемные конфиги надо включать уже в интеграционные тесты, в общем тут еще больше вариантов), но вот эти тесты точно никак нигде и никогда не будут тремя строчками.
С моим опытом скажу, что любые PR в три строчки без других артефактов (обозначено выше) можно сначала отклонить, а потом уже изучить. Потому что это не будут фиксы, в 98% это просто костыли. В 1%, ой-бой, это исправление безобидного недосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.
А дальше все просто, если у сотрудника эти 1% превращаются в хотя бы 20% его работы, то вывод даже без теоремы Байеса понятен, он халтурит.
Про оптимизации еще смешнее. Вот тут хочу любой пример. Да, в три строчки где-то можно поменять под задачу коллекцию вроде дерева, на хэш-мапу. Или убрать лишний запрос к БД, потому что в соседнем поле эти данные и так болтаются. Но остаются два вопроса, как в эти три строчки уместить еще и доказательство того, что оптимизация полезна в принципе (то есть как "у себя локально потестил", вроде в 2 раза быстрее, а вам зачем знать, что и как я тестил), и что там можно две недели оптимизировать, когда профайлеры всего и везде есть.
Все когда-то халтурили, все иногда выгорали, изредка можно встретить реально противную проблемку, но что бы три строчки кода за две недели без других артефактов было хоть чем-то похожим на норму говорить смешно. А если это превращается в 6 строчек за месяц, то грустно, и пора с человеком прощаться.
Давайте не будем придумывать, какими способами можно еще греть планету через инференс. Всегда же можно рендерить котиков!
А по сути, эта статья как будто из года 2005. Ностальгия есть, к этим замечательным временам "неделя мучения, и вот они заветные три строки". Но сейчас нет. Если это багфикс, то хоть и сам фикс может занимать даже одну строку, или один символ, как артефакты работы нужны еще тесты, которые не проходятся старым кодом, и скорее всего, очевидно, небольшое изменение архитектуры, чтобы эти тесты подключить к проблемному коду (и если "не повезет" очень как дофига придется замокать). Если это архитектурное изменение, то хорошо, редко, но возможно, что все изменение в API это три строки. Но это еще пачка вики-док с описанием как мигрировать, чем лучше новое решение, как минимум. И опять же тесты. Ну а фичи на три строчки маловероятны. Тут наоборот, в каком-нибудь легаси, кажется что фича на три строки, а в реальности пришлось перелопатить полтысячи.
А в 2005 да, бывало такое, что эти три строки достались сутками ковыряния бинарей в дизассемблере и отладчике. Но обычно это когда что-то сделать "нельзя, не надо, но очень хочется". Но сейчас такие практики, мб, только у вирусописателей и остались.
Надеюсь, не сильно расстрою. Но во-первых, для унифицированного доступа к биржам, перечисленным и многим другим, есть библиотека ccxt. Минус куча кода и костыли с verify=False.
Во-вторых, каждая из этих бирж дает более одного запроса в секунду, что абсолютно достаточно для этой задачи. Но есть нюанс, в общем-то гарантируется это только если использовать свой личный API-ключ, достаточно read-only. И тогда не надо будет замедляться до "раз в 5 секунд". Это очень медленно! За эти 5 секунд, другие боты, которые имеют объемы на биржах из связки уже полностью реализуют курсовую разницу. (Кстати, не заметил в статье, есть ли какая-то синхронизация этих интервалов? Потому что, вот сдвинем на 2.5 секунды график растущего актива с одной бижри относительно другой и будем постоянно видеть арбитражную разницу, но на деле ее не будет.)
В-третьих, зачем в этой задаче Postgres? Открываете набор бинарных файлов в append only, следите за seed (при перезапуске программы) и доливаете туда полученную инфу. Так даже 320К записей в секунду не будут проблемой от слова вообще. Зависит от того, что конкретно нужно сохранять, но это буквально десятки (менее сотни) строк кода. Очень хочется перелить это в бд? Пишем отдельный сервис, который делает это в фоне, но тут сильно зависит от того как мы в бд хотим с этими данными работать.
У вас и так очень редкий поллинг, раз в 5 секунд, еще и терять из этой инфы половину? Ну и вот это наводит уже больше на вопрос, а не "в-четвертых, ...". А какую задачу Вы надеетесь решить? Увидеть какое-то долгосрочное и существенное расхождение курсов? Я тоже с этим игрался, отмечу что так бывает, только если либо ввод/вывод актива временно отключен, либо есть существенно проблемный новостной фон. Никакие тогда выдуманные коэффициенты 0.3 и 0.7 не дадут в будущее заглянуть.
Для 0.5 RPS систем вполне приемлемый подход. А я почему-то всегда оказывался в местах, где 90% работы это и есть написание не наивных решений, тестирования их производительности, и, конечно же, нетривиальных тестов, которые не дают этим 99% багов оказаться в проде. Фигней какой-то в общем. Да, KISS рулит. А если что, просто еще один сервер купим (за счет моей зарплаты в общем-то, вот и вся проблема).
Но это в общем плане. А конкретно про эту функцию, ну хз. У меня вот есть подозрения, что она вообще не нужна, как минимум название у нее странное, и самодостаточно она не выглядит полезной. Просто цикломатическую сложность хотели понизить и сделали первое, что пришло на ум.
Причем фикс говорящий за себя. Такое ощущение, что за дело взялся человек, но либо у него совсем не хватало времени, либо квалификации, потому что все красивые идеи изначального подхода упустили, "как будто испугались". Я бы предложил так:
Скрытый текст
private static final long ILLEGAL_REQUEST_LINE_TOKEN_OCTET_MASK =
(1L << '\n') | (1L << '\r') | (1L << ' ');
public static boolean isEncodingSafeStartLineToken(CharSequence token) {
int i = 0;
int lenBytes = token.length();
int lenInts = lenBytes - (lenBytes % 4);
for (; i < lenInts; i += 4) {
char c0 = token.charAt(i);
char c1 = token.charAt(i + 1);
char c2 = token.charAt(i + 2);
char c3 = token.charAt(i + 3);
// All chars >= 64 means the whole group is safe
// Only one switch per 4 bytes in most cases
if ((c0 & c1 & c2 & c3) >= 64) {
continue;
}
// Avoid bitshift overflow. Still one switch per character
if (c0 < 64 && ((1L << c0) & ILLEGAL_REQUEST_LINE_TOKEN_OCTET_MASK) != 0) return false;
if (c1 < 64 && ((1L << c1) & ILLEGAL_REQUEST_LINE_TOKEN_OCTET_MASK) != 0) return false;
if (c2 < 64 && ((1L << c2) & ILLEGAL_REQUEST_LINE_TOKEN_OCTET_MASK) != 0) return false;
if (c3 < 64 && ((1L << c3) & ILLEGAL_REQUEST_LINE_TOKEN_OCTET_MASK) != 0) return false;
}
for (; i < lenBytes; i++) {
char ch = token.charAt(i);
if (ch < 64 && ((1L << ch) & ILLEGAL_REQUEST_LINE_TOKEN_OCTET_MASK) != 0) {
return false;
}
}
return true;
}
Да ведь вкусовщина. На первом не сыграет, да, а на втором-третьем, если с головой на плечах - сыграет и проиграет наверняка. Было бы интересно, правда, посмотреть, где с FOL начинают. Все-таки относительно SOL + топологии это редукция, что несомненно полезно для формализации, но дает свои минусы для познания. А вот реально качественные формализации всем (без малого) студентам по жизни никак не пригодятся.
Тут на хабре, в среднем пару раз в год пишут "статьи" вот такие вот интуитивно понимающие, о том, что вообще континуума не существует и они могут это доказать.
Ну и продолжая вкусовщину, я благодарен за то как меня учили и с чего начинали, потому что матан я, кажется, даже в припадке не забуду. Во многом базовый, конечно, но, главное, для меня все предельно просто, и все что забыл легко выводится.
В FOL уже буквально с диагональным методом Кантора возникнут такие проблемы, которые младшекурсникам не по зубам, а ведь надо как-то пределы вводить. Непрерывность определить. Ну да, выше Вы писали про ZFC, но пока уже другие будут спокойно интегралы по контуру считать, придется сидеть на парадоксе Банаха-Тарского. Мне не кажется, что это может быть проще.
Ну мне кажется, шансов начать не с определений в логике второго порядка маловато. Даже интересно, где бы могли так преподавать.
Так мир программистов на C++ он очень разный, чуть ли не полярный. Куча проектов еще живут, которые стартовали на c++03 из соображений производительности, но не той, где наносекунды считают, а где джава рантайм таскать с собой никто не будет а дотнет тогда еле шевелился. Всякий десктоп, локальный энтерпрайз, какие-то модули-числомолотилки, в которых аллокаций вообще нет, специализированная техника, и так далее. Там сидят люди и во всем этом варятся и никакой необходимости в новых компиляторах у них нет, а уж тем более и в новых стандартах. Все равно целиком проект переписать никто не даст, а исправлять по частям смысла мало. Ну и железо все время становилось быстрее, так что если не используешь квадрат, там где n log n хватает - уже большой молодец, а даже если используешь, ну когда (скорее если вдруг) тесно станет, то кто-нибудь починит.
Я как-то на таком работал, например, так вот на работе только палки в колеса ставили, а дома... а дома я выучил C#, меня этот язык реально радует. А часть бывших коллег вообще на эту ерунду еще и дома время не тратили.
И смотря насколько глубоко понимать. О Pointer Provenance как по мне любой недавний джун имеет представление, когда по ручкам настучали за reinterpret_cast везде где хочется и нельзя. std::launder на фоне этого вообще не должен никаких проблем вызывать (только решать), но есть тонкость, что его в C++17 ввели и есть прекрасный шанс ни в одном проекте его не увидеть. Я, пожалуй, чаще видел людей, которые про Strict Aliasing не слышали. Сложно ли это? Да не особо, было бы желание.
Именно так. Это у Вас еще хорошие цифры. Я не понимаю как люди легко "выбивают" белые айпишники за 1500рублей, у меня ничего не получилось. Плюс EU vds-ки за 300 и дешевле либо нельзя оплатить, либо они умудряются не вытягивать даже 100Мбит/с. Наверное есть исключения, я не знаю. А входные РФ узлы улетают в бан быстрее чем подписка на месяц заканчивается (и она еще дороже, конечно).
Согласен. А 30 минут (и это еще быстро?) кода на доске это вообще какая-то пытка, так или иначе. Доска для архитектуры (совсем простенькой) и, ну максимум, FizzBuzz, если любите немного поиздеваться (но зачем?).
Ну я бы тоже подзавис. Кто-то ждет ответа, ну это просто "syntactic sugar", а кто-то будет ждать, что "указатель это отдельная переменная, сама имеющая адрес в памяти". Такой вопрос гарантированно попадает в "вопросы с ожидаемым подвохом". Отличий, как по мне, больше чем сходства. Больше в сторону, чем std::string отличается от int.
Впрочем, да, это не повод молчать и чего-то ждать.
Очень смелое заявление. Я слышал, что 80% сеньоров не могу за пять минут написать работающий FizzBuzz и это может и гиперболизированная, но похожая на правду вещь. А тут... хочешь - не хочешь при изучении C++ с указателями ты столкнешься, и если мы про raw pointers, а не про более новомодные штуки как weak_ptr, то каких-то тонких, но рядовых особенностей, которые можно не понимать или как-то неправильно интерпретировать в них просто нет. Ошибаться легко, но не по причине непонимания, а по причине их неудобства и не безопасности.
Унижать так-то можно любым достаточно известным, но мало полезным знанием, было бы желание (и хоть какой-то смысл).
Но аналогия с таблицей умножения неверная, пусть у человека "от зубов и не отскакивает", сколько будет шестью восемь, но он сможет дать правильный ответ спустя какое-то время, а значит считать все же умеет.
Аксиомы планиметрии... а почему тогда не список персонажей "Войны и Мира"? Примерные размеры планет солнечной системы? Правила игры в шахматы?
Мне, несмотря на оконченный математический ВУЗ, аксиомы планиметрии пригодились ровно чтобы сдать экзамен в школе по аксиомам планиметрии, не больше не меньше. Это не матан, который сплошь и рядом всплывает, и не теория вероятности, без которой вообще сложно себя считать человеком рассудительным.
И, казалось бы это несложное знание, но я изначально не склоняюсь считать простым то, что кажется лишь интуитивно просто; вот про аксиому принадлежности я не только не вспомнил без википедии, но и не вспомнил бы ее вообще, если бы мне нужно было самому создать аксиоматику. Меняет ли это хоть что-то в мире? Да вообще ничего. Это даже в геймдеве не нужно, и когда дачу строишь тоже как-то безразлично на то, что каждый отрезок имеет длину, большую нуля, потому что нулевыми отрезками как-то даже в голову не приходит крышу крепить.
Вот те же аксиомы Пеано еще попробуй забудь, если узнал. Но их почему-то даже обычно не проходят в школе. Но раз уж без этого жить можно, то что уж говорить.
Кажется для заморозки старых монет это все и затевается. Не очень понятно, что так радикально изменилось с 20 года относительно квантовых компьютеров, но опасающиеся квантовой угрозы пользователи вполне могут сами первести свои средства на SegWit/Taproot кошельки и это должно сработать.
Как для пользователя, одна из основных проблем в неприличном разнообразии дистрибутивов Linux, и на всех из них есть свои особенности. Разные пакетные менеджеры, разные фаерволы, и что конкретно более неприятно, разный UI. Даже если десктопных менеджеров в принципе обозримое количество (но их много), шрифты почти везде немного разные, иконки разные, дефолтные настройки немного отличаются, и в этом разнообразии, хоть кто-то и находит определенную свободу, я нахожу определенное стеснение. Это все бросается в глаза без полезной нагрузки; привыкать к одному дистрибутиву непозволительная роскошь, ибо мало где тебе переставят Ubuntu на твой любимый, например, Linux Mint, а настраивать UI чтобы было точь-в-точь, это далеко не один конфигурационный файл (и это не та работа, за которую платят). В итоге пользуешься и немного страдаешь. Ubuntu вроде бы самый популярный дистрибутив, но там дефолтные настройки UI как по мне вырвиглазные.
Майкрософт тоже не порадовал с Windows 11, но с десяткой было все так хорошо, что это просто не замечалось.
И пусть сами в это играют. Пока задач, которые требуют больше 16GB DDR4 исчезающе мало (кроме собственно LLM). И если такая задача вдруг появляется, то докупить памяти как бы не невозможно :) Но, скорее всего, их в обозримое время просто не будет. А комфорт, ну вот у меня остался мини-пк с 4 GB DDR4, вот на нем работать уже не комфортно. Не невозможно, не сильно сложно, но не комфортно. А так, в основной комп напихал где-то десять лет назад 64 GB, просто потому что она стоила совсем не дорого, относительно других компонентов. С тех пор было ровно две задачи, где "чем больше памяти, тем лучше" и то разовых, тут проще было бы арендовать VPS. А в остальное время, повторюсь, изчезающе редко больше 16 используется, с учетом системных кешей, которые по максимуму выставлены.
Было такое короткое окно, когда типовая конфигурация пред-топовой машины это много памяти, маленький SATA SSD и большой HDD, там в ряде сценариев память давала серьезное ускорение. Тогда же я игрался с RAM-дисками, но это проще как кошмарный сон забыть, потому что они "всегда маленькие", не персистентные, и опять же, в абсолютном большинстве сценариев, хоть и выигрываешь машинное время, но теряешь свое личное, размышляя, что туда надо загонять, а что не надо. Потом появились доступные NVME SSD и все это шаманство потеряло смысл.
Но и огромный NVME тоже не нужен. Конечно хочется, чтобы игры запускались на 20 секунд быстрее, хочется не покупать HDD, хранить на SSD и фотки, и музыку, и все приложения, но когда он посыпется, будет уже не так весело.
Вот а я пишу код. Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
Обе проблемы важны, требуют решения, но обычно в грамотно организованных командах они решаются через фиксацию промежуточных результатов. Это важно еще и с другой стороны, что "недоделанное" решение, имеющее полезные артефакты (ту же конфигурацию, где проблема повторяется) можно перенести на другого программиста, если у изначально ее решавшего, появляется более срочный кейс.
Даже менее консистентные промежуточные результаты в большинстве компаний фиксировались, если это тикет на плавающий баг, то ежедневно обновляется план дальнейшего исследования, и фиксируются попытки, которые не привели к результатам. Поначалу, там, где не было так принято, некоторые носы ворочали, а потом сами убедились, что очень удобно придти в понедельник "с пустой головой" и понять с чего надо продолжить. А тикет всегда добавляется в PR.
Может изначально я как-то слишком прямолинейно начал, но, хоть и не отрицаю проблем, описанных в статье, утверждаю, что решение уже есть, и оно в организации работы команды. Для хаба "управление разработкой" это как бы довольно очевидно.
Вот именно. Я бы это бы и сказал, может помягче, но суть та же. Не надо позволять работникам даже играть в Генри Форда. Если не ставить документирование о выполненной работе в процессы команды, то очень быстро команда фрагментируется до тех кто использует отсутствие лишней вербозности себе в плюс, и на тех, кто от этого "молча" страдает.
Это сломанный процесс, который раньше решали либо глупыми и формальными KPI, либо ежедневными собраниями по полчаса, где все отчитываются друг перед другом что делают (но слово не воробей), либо вообще в стримы с экрана (а их все равно никто не смотрит, или смотрят когда и так уже ясно, что человек не работает).
А проблему "старается"/"не старается" не нужно решать. Вот допутим некий Коля берет некую "сложную задачу" (потому что либо плавающая, либо описание неполное, либо ранее ее уже кто-то брал, но не справился, или она снова всплыла). Оценивает ее в две недели. Открывает отладчик, и начинает там рандомные какие-то пути гонять, в код поглядывая, надеясь что проблема на глаз найдется. А что, времени еще уйма, если он ждет решения в три строчки, то он хоть в последний момент его может разродить.
Прошла неделя, проблему Коля не смог воспроизвести, но уже в принципе придумал решение в 5 строчек, как ее вообще закостылить. Сидит дальше в отладчике ковряет. Вот уже два дня осталось, Коля уже коммитит свой workaround в 5 строчек, в тикете пишет, "проблема не воспроизвелась, но теперь она точно не вылезет". Надеется на чудо в пятиницу, но если что готов, сделать PR того что есть. Старался? Ну да, наверное. Или просто фрустрировал. Но дело не в этом, дело в том, что проблема решена хреново. И это выстрелит при первом же существенном рефакторинге. И Коля это знает. И теперь, чтобы не встрять еще долго он не будет брать задачи связанные с рефакторингом.
Допустим я беру такую задачу. Первым делом пытаюсь уточнить подробности о проблеме, чаще всего они исходят от клиентов продукта/сервиса, параллельно добавляю логирование всех хоть как-то связанных с проблемой мест. Логи естественно отключаемые. Сразу добавляю несколько тестов, которые хоть на моей машине и будут зелененькими, но есть шанс, что где-то, хоть на CI мигнут. Мигнут тесты, будут логи, будет понимание проблемного стейта. Если проблема еще более редкая, то уже буду просить клиентов, понятно через службу поддержки, развернуть апдейт, который якобы чинит баг, ну и здесь понятно что можно и дальше рабочий процесс рассказывать, но да, это не игра в одни ворота. "Коля, отладчик, код, и тишина". Здесь нужна организация. Часто люди за этим и идут работать в команду.
И так у них и складывается понимание, что есть хорошая команда, а что слабая, что есть удобная организация, а что бардак. Хорошие практики закрепляются, эволюционируют...
И тут Вы правы, дело не в 2005 году. В принципе это просто часть моего опыта. Но где-то с тех пор, ни в каких других командах (а не все из них были прям супер) такой практики как "две недели - три строчки кода" ни в прямом ни в менее строгом значении уже не существовало.
А когда нет юниттестов, логов, билдсервера, CI, автотестов, специалиста поддержки пользователей, таск трекера, гита, - хотя бы чего-то из этого, то путь может быть сложнее.
В общем случае, да, либо исправляю библиотеку, либо пишу workaround. Другое дело, что API бирж категорически редко меняется, и даже при изменениях, уважающие себя биржи, просто дают эндпоинт /v2 .. /vN и все продолжает работать у тех, кто не желает обновляться. С ccxt проблем не было. Это своего рода стандарт в области.
Если на определенном этапе мы еще не знаем, как конкретно будем обрабатывать данные, то все же БД преждевременна. А бинарные файлы даже без команды штука простая, их логику любой ИИ может запрограммировать на худой конец. Просто так мы сможем позволить себе выбор БД в последствии, исходя из конкретных задач, ничего не потеряем, и сохраним исходный интерфейс. Что у биржи мы могли спросить какая была цена актива/объемы торгов aaa на время xxx, что у бинарного файла. Это чуть лучшее решение, чем когда мы поняли, что в БД нам не достает данных, судорожно запускать догрузку этих данных напрямую с бирж (это может быть очень небыстрым процессом).
Ну и БД мы на самом деле не обязаны писать курс каждого тикера на каждый момент времени, можно группировать все тикеры с одной биржи на момент времени, и записей будет в 200-500 раз меньше. Ценой правда некого дополнительного неудобства работы с ними. В любом случае, не та задача, где нужно как-то обходить проблемы производительности жертвами.
О том 2005, где в небольшой компании живет жесткий водопад, репозиторий cvs (это хорошо, если так) и файлики. Там же в этих файликах выкидывались какие-то progress_module1.txt, какие-то сборочные артефакты, какие-то тестовые бинари и у кого как. Тогда да, работа это то, что попадает в репозиторий, а остальное раз в месяц сносил админ (на самом деле эникей, которого пнули, что место на шаре мол кончается). В тех же файликах еще нередко валялись фотки с новогоднего корпоратива, ppt презентации для заказчиков, какие-то небольшие игрухи. Замечательные были врема, спору нет...
И если Вы продолжаете в них жить, да при текущем уровне зарплат, то ничуть не сострадаю вашей проблеме, скорее просто завидую.
Но какие багфиксы на три строчки в этом мире? Говорите, плавающая проблема? Так первое с чего начинают, строят образ проблемной конфигурации (даже в самом унылом случае, это виртуалка с специально сконфигурированной средой, которая попадает потом в бинарные артефакты), а чаще это отдельный бранч, где плавающий баг специально доталкивается до повторяющегося отдельным кодом. И это еще до непосредственно исследования бага и его исправления. Потом отладка, и исправление. Да даже если непосредственно обход проблемы занимает три строчки, нужно всегда смотреть на окружение этого кода, постараться рефакторить то, что этот баг скрывало. Ну и в конце концов тесты. Чтобы вот четенько было видно, что до фикса тест был красненьким (да-да, этого не обязательно можно добиться юнит-тестами, и тогда проблемные конфиги надо включать уже в интеграционные тесты, в общем тут еще больше вариантов), но вот эти тесты точно никак нигде и никогда не будут тремя строчками.
С моим опытом скажу, что любые PR в три строчки без других артефактов (обозначено выше) можно сначала отклонить, а потом уже изучить. Потому что это не будут фиксы, в 98% это просто костыли. В 1%, ой-бой, это исправление
безобидногонедосмотра уволившегося коллеги. Еще 1% остается на то, что это валидный кейс.А дальше все просто, если у сотрудника эти 1% превращаются в хотя бы 20% его работы, то вывод даже без теоремы Байеса понятен, он халтурит.
Про оптимизации еще смешнее. Вот тут хочу любой пример. Да, в три строчки где-то можно поменять под задачу коллекцию вроде дерева, на хэш-мапу. Или убрать лишний запрос к БД, потому что в соседнем поле эти данные и так болтаются. Но остаются два вопроса, как в эти три строчки уместить еще и доказательство того, что оптимизация полезна в принципе (то есть как "у себя локально потестил", вроде в 2 раза быстрее, а вам зачем знать, что и как я тестил), и что там можно две недели оптимизировать, когда профайлеры всего и везде есть.
Все когда-то халтурили, все иногда выгорали, изредка можно встретить реально противную проблемку, но что бы три строчки кода за две недели без других артефактов было хоть чем-то похожим на норму говорить смешно. А если это превращается в 6 строчек за месяц, то грустно, и пора с человеком прощаться.
Давайте не будем придумывать, какими способами можно еще греть планету через инференс. Всегда же можно рендерить котиков!
А по сути, эта статья как будто из года 2005. Ностальгия есть, к этим замечательным временам "неделя мучения, и вот они заветные три строки". Но сейчас нет. Если это багфикс, то хоть и сам фикс может занимать даже одну строку, или один символ, как артефакты работы нужны еще тесты, которые не проходятся старым кодом, и скорее всего, очевидно, небольшое изменение архитектуры, чтобы эти тесты подключить к проблемному коду (и если "не повезет" очень как дофига придется замокать). Если это архитектурное изменение, то хорошо, редко, но возможно, что все изменение в API это три строки. Но это еще пачка вики-док с описанием как мигрировать, чем лучше новое решение, как минимум. И опять же тесты. Ну а фичи на три строчки маловероятны. Тут наоборот, в каком-нибудь легаси, кажется что фича на три строки, а в реальности пришлось перелопатить полтысячи.
А в 2005 да, бывало такое, что эти три строки достались сутками ковыряния бинарей в дизассемблере и отладчике. Но обычно это когда что-то сделать "нельзя, не надо, но очень хочется". Но сейчас такие практики, мб, только у вирусописателей и остались.
Не верю я в три строчки, не верю.
Надеюсь, не сильно расстрою. Но во-первых, для унифицированного доступа к биржам, перечисленным и многим другим, есть библиотека ccxt. Минус куча кода и костыли с verify=False.
Во-вторых, каждая из этих бирж дает более одного запроса в секунду, что абсолютно достаточно для этой задачи. Но есть нюанс, в общем-то гарантируется это только если использовать свой личный API-ключ, достаточно read-only. И тогда не надо будет замедляться до "раз в 5 секунд". Это очень медленно! За эти 5 секунд, другие боты, которые имеют объемы на биржах из связки уже полностью реализуют курсовую разницу. (Кстати, не заметил в статье, есть ли какая-то синхронизация этих интервалов? Потому что, вот сдвинем на 2.5 секунды график растущего актива с одной бижри относительно другой и будем постоянно видеть арбитражную разницу, но на деле ее не будет.)
В-третьих, зачем в этой задаче Postgres? Открываете набор бинарных файлов в append only, следите за seed (при перезапуске программы) и доливаете туда полученную инфу. Так даже 320К записей в секунду не будут проблемой от слова вообще. Зависит от того, что конкретно нужно сохранять, но это буквально десятки (менее сотни) строк кода. Очень хочется перелить это в бд? Пишем отдельный сервис, который делает это в фоне, но тут сильно зависит от того как мы в бд хотим с этими данными работать.
У вас и так очень редкий поллинг, раз в 5 секунд, еще и терять из этой инфы половину? Ну и вот это наводит уже больше на вопрос, а не "в-четвертых, ...". А какую задачу Вы надеетесь решить? Увидеть какое-то долгосрочное и существенное расхождение курсов? Я тоже с этим игрался, отмечу что так бывает, только если либо ввод/вывод актива временно отключен, либо есть существенно проблемный новостной фон. Никакие тогда выдуманные коэффициенты 0.3 и 0.7 не дадут в будущее заглянуть.
Для 0.5 RPS систем вполне приемлемый подход. А я почему-то всегда оказывался в местах, где 90% работы это и есть написание не наивных решений, тестирования их производительности, и, конечно же, нетривиальных тестов, которые не дают этим 99% багов оказаться в проде. Фигней какой-то в общем. Да, KISS рулит.
А если что, просто еще один сервер купим (за счет моей зарплаты в общем-то, вот и вся проблема).Но это в общем плане. А конкретно про эту функцию, ну хз. У меня вот есть подозрения, что она вообще не нужна, как минимум название у нее странное, и самодостаточно она не выглядит полезной. Просто цикломатическую сложность хотели понизить и сделали первое, что пришло на ум.
Причем фикс говорящий за себя. Такое ощущение, что за дело взялся человек, но либо у него совсем не хватало времени, либо квалификации, потому что все красивые идеи изначального подхода упустили, "как будто испугались". Я бы предложил так:
Скрытый текст
Но на бенчмарки пока времени нет.