Вот а я пишу код. Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
Обе проблемы важны, требуют решения, но обычно в грамотно организованных командах они решаются через фиксацию промежуточных результатов. Это важно еще и с другой стороны, что "недоделанное" решение, имеющее полезные артефакты (ту же конфигурацию, где проблема повторяется) можно перенести на другого программиста, если у изначально ее решавшего, появляется более срочный кейс.
Даже менее консистентные промежуточные результаты в большинстве компаний фиксировались, если это тикет на плавающий баг, то ежедневно обновляется план дальнейшего исследования, и фиксируются попытки, которые не привели к результатам. Поначалу, там, где не было так принято, некоторые носы ворочали, а потом сами убедились, что очень удобно придти в понедельник "с пустой головой" и понять с чего надо продолжить. А тикет всегда добавляется в 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;
}
Отличное исследование-расследование, хорошо, что проблему удалось найти. Глядя на isEncodingSafeStartLineToken()я бы сразу проблему не обнаружил, вроде все красиво делается, и пакетная обработка, и отсутствие лишних if, а использование битовых масок. Трюк когда long chars = ... | ... | ... | ... мне тоже понравился, хотя несколько лишних секунд на подумать "почему это работает" он съедает. Но есть стойкое ощущение, что его написала ИИ, потому что человек, освоивший все остальное, вряд ли бы "забыл", как работает битовый сдвиг. Признаться, это дает какое-то такое ощущение, пугающее, что ли; сколько еще подобных багов, где они еще могут быть...
В 2018 я делал подобное. Тоже изначально брал базу rockyou (но даже не "чистил" ее), и несколько более актуальных небольших утечек + комбинации пар слов из обычного словаря и они же с мутациями. За основу генератора адресов брал vanitygen, и у меня уже тогда скорости были примерно в 10 раз выше, чем то, что в статье. Базы адресов не было, поэтому пришлось немного модифицировать клиент биткоина, чтобы он создавал список адресов, на которых хоть когда-то был баланс (генерируется это в процессе парсинга блокчейна). Все в формате U_P2PKH. Построил блум-таблицу по этим адресам, и спокойно гонял свой форк vanity пока мне не надоело.
Исследование вышло интереснее немного, потому что более десятка тысяч уже опустошенных адресов я нашел. Нашел более сотни на тот момент не пустых кошельков. На абсолютном большинстве меньше сатош, чем нужно для вывода. Но на четырех адресах суммы до 2 BTC.
Долго терзался соблазном забрать их балансы себе (изначально я думал что таких адресов просто не будет), по принципу "не я так кто-то другой это сделает", но решился просто перевести с каждого из этих адресов себе по 5$. Так владельцы увидят, что кошельки компрометированы, но сильно не пострадают. Повторял подобный эксперимент в 2020, уже с несколько более недобрым умыслом, подгрести с этих адресов монеты форков биткоина, но к тому моменту уже все было вычищено.
Я бы сказал, что не стоит по навыкам играть в игру судить о чем-либо, кроме самого навыка играть в игру.
Скрытый текст
СК2 мне никогда не нравился, но как-то после покупки 240Гц монитора зашло переосмыслить игру в Fortnite, где до этого я просто "по фану бегал" и был признаться очень слабым игроком, который в целом не перерос понимание фортнайта как некий гибрид Q3 и CS. Потом потихонечку стал замечать, что какие-то buildfight связки стали даваться сами собой легче, и в игре появился новый интерес. Положительная обратная связь из-за постепенного продвижения в рейтинговых матчах дала мотивацию научиться "включать мозг" в игре, которую раньше считал "что-то для отдохнуть от мыслей". Про игру в частностях не буду расписывать, думаю мало кому это будет интересно, но потом через пару месяцев я пришел к такому состоянию восприятия, что ровно каждый проигранный мной матч содержал для меня явную видимую ошибку, причем не ретроспективно, а именно в моменте. И это всегда была комбинация ранее непредусмотренных, но предусматриваемых (казалось бы в игре с таким уровнем хаоса) недочетов. Стало еще интереснее играть. И вот, спустя время появилось ощущение, что я "научился играть!", что в принципе и рейтинговые матчи подтверждали.
...И мне казалось, что теперь я способен держать идеальную концентрацию в игре на протяжении 20-30 минут (время матча), микроменеджить всё необходимое время без ошибок (это не СК2, где весь матч по сути из этого, а где-то 10% времени игры), и никакой фрагментации сознания не происходило. Это, несомненно меня радовало (ибо ранее испытывал проблемы с концентрацией), но при всем желании перенести что-то из этих навыков или состояний на реальный мир, я получил (думаю это было понятно сразу):
Ничего. Ничего полезного, плюс более обостренное восприятие, что в игре за минуту времени я мог делать более тысячи осознанных так или иначе действий, а в любом рабочем процессе не изменилось ничего. Восприятие это неприятное, само собой.
Потому что обычно эти рабочие процессы выглядят так: нужно поменять одну строчку в конфиге на одном из серверов...
Скрытый текст
Ну окей, мозг говорит, это должно быть на полминуты. Но первое, я не помню ip этого сервера, а по доменному имени он почему-то не резолвится. Хорошо, идем ищем доку с его ip. Ну она вроде была в внутренней вики в этом разделе. А ее нет. Идем в поиск, первый запрос - ничего. Вспоминаю примерное название документа, ура, есть, нашлось. Смотрим на часы, прошло 10 минут (!). Да, документ недавно переносили, что ж, ладно, теперь он в более логичном месте, на самом деле. Дальше. Лезем подключаться. Неправильный пароль. Ну окей, может я его криво скопировал, еще разок. Неправильный пароль. Конечно, его кто-то успел заменить. Идем на дэшборд с серверами, вот же он, а где кнопка скопировать пароль? А ее уже нет. Изучаем обнову дэшборда, оказывается менеджмент паролей перенесли в отдельную страницу, ну окей, так даже логичнее, но пароль я посмотреть не могу, нет прав у меня. Ну вот и точка, время звонить админу. "Да, да, хорошо, добавил в группу доступа, обнови страницу". Обновил, получил пароль, подцепился к серверу. Ищем там конфиг, смотрим, упс, а его уже поменяли в возможно конфликтующем месте. Скидываем вопрос в чатик, завариваем чай, заодно отвечаем на пару вопросов коллег, смотрим на часы, прошло уже полтора часа. Получаем ответ "да, давай, ничего не сломает". Обновляем конфиг, сервер глубоко тестовый, так что даже отсутствие полной уверенности не пугает, но правда и не радует. Перезапускаем, да, окей, у меня все работает. Но остается еще помнить, что надо будет поглядывать в чатик активнее, чтобы точно никому ничего не сломать.
Прошло два часа. Усталость, некое чувство беспомощности, некое чувство неуверенности. Начинать что-то значимое уже не хочется, может посвятить остатки дня еще паре микрозадач? И вот бывает вторая из них так же растянется, вот и все, день закончен, сделано чуть больше чем нифига, настроение подавленное, а со временем отторжение к таким микрозадачам только растет.
Больше всего крадет время остутствие систематизации части рабочих процессов. Но чтобы процесс появился вообще, нужно вообще понять что он есть (и какой он есть в сущности) и он нужен. А пока не очень понятно, так ли он нужен, чтобы его автоматизировать, концентрация расходуется.
В общем да, в остатке остается одно, - себя не самобичевать, и на других не злиться.
Так вот и вопрос, что мы вообще оптимизируем и каким инструментарием оптимизации обладаем? Кому-то, наверное важно принципиально дожить до 80 лет более-менее самодостаточным, но потом то все равно будет что-то другое. Вопрос глубокий, что именно что.
Я кучу лет раньше мечтал о телефоне с дуалбутом в Windows, правда в идеале не на ARM, а на x86 процессоре. А потом, после работы с аналогами Desktop Mode (на Motorola и на Huawei свои аналоги) немного забыл зачем. То есть правда, как предполагается такой телефон использовать?
Я бы отправился где-то под конец 1946 года лучше всего в Ленинград, и у меня было бы достаточное время для публикации, а главное популяризации алгоритма Быстрого Преобразования Фурье. Тогда обнаруживать скрытые испытания ядерного оружия можно было бы значительно раньше. Ну правда пришлось бы с собой грузовик тушенки из будущего захватить на всякий случай.
Мне кажется, минусуют, потому что Вы используете какое-то свое понятие об игре, как будто достаточно открыть книгу по геймдизайну, научиться поворачивать матрицы, добавить "press E to interact", и вуаля, игра готова. Формально да, но это все максимум уровень пет-проектов школьников.
Вот какие у Вас любимые игры, в разных жанрах? И какие из них Вы проходили хотя бы два раза?
Потому что чтобы преодолеть горку - иногда надо отойти чуть назад для разгона или спустится еще ниже чтобы по инерции ее преодолеть или чтобы выйти из пике надо ускорится вниз, чтобы потом иметь возможность полететь вверх.
Да не нужно этих метафор. Я верю, что кому-то они могут помогать, допустим, но в среднем достаточно просто научиться декомпозировать цели на задачи, оценивать возможности решения этих подзадач, и решать по возможности. Какой-нибудь базовый GTD, без каких-то эмоциональных или метафорических прекрас будет точно так же работать.
Так Вы в своем комментарии до сих пор бинарное мышление демонстрируете. Мол если зона комфорта неприятная, то нельзя ее ухудшать. Если приятная, то не надо. А вариант того, что зона комфорта немного неприятная и сделав ее еще немного неприятнее можно в итоге перейти в более приятную - Вы не рассматриваете.
Так это послание себе в прошлое. Начинать анализ мира с продвинутого небинарного мышления это спорная идея, оно очень много ресурсов жрет, если стремиться использовать его для создания каких-то выводов. Это типа для мудрых штука.
Проблема в обратной связи, если схема "сделать немного неприятнее => изменение" заработает, то почти все вокруг рано или поздно становится немного неприятнее, чем есть.
Так если нет никаких четких неизменяемых правил, механик и целей (а если это 3д игра - то и сеттинга, лора соединяющего сеттинг и задачи, у которых вообще-то должен быть еще и смысл в этом виртуальном мирке), то это не игра, а абсолютно буквально разновидность сна при температуре 38.
Я в том же фортнайте с мелких багов ору (кто-то бы и не заметил даже, вот баг одного непопулярного дробовика, который без прицеливания 50 на 50 попадет в цель которая находится в гарантированной зоне поражения, вплоть до point-blank, извините, но дробь так не работает, а пушка не претендует по сеттингу на что-то фантастическое), потому что это подрывает доверие к игровому процессу, а тут вся игра целиком из этого. Кому это нужно?
Максимально спорное утверждение. Люди-то отношение других игроков к игре именно что видят, видят и ощущают, а ИИ такую информацию обрабатывать не умеет, но кроме того, все тонкие нюансы этих наблюдений даже формализовать до невозможности сложно. Так что его удел (до появления ASI, причем уровня возможности полной виртуализации человеческих сознаний, ага конечно) просто комбинировать популярные механики, чем люди прекрасно и без него занимаются, прекрасно, но давно уже без каких-то значимых прорывов.
Впрочем, для многих людей разница между игрой и интерактивным кинцом действительно пренебрежимо мала, их ИИ еще как "накормит". Но это все из историй "пакман лучше шахмат", "банан лучше киви".
Вот а я пишу код. Так что мне не понятна идея, чью боль мы хотим решить. Программиста, когда его промежуточные этапы работы уходят в мусорное ведро, он страдает от ощущения, "что возможно сделал мало", и болеет потом синдромом самозванца. Или руководства, которое видит очень нестабильный перформанс программистов и теряет возможность предсказать скорости процессов.
Обе проблемы важны, требуют решения, но обычно в грамотно организованных командах они решаются через фиксацию промежуточных результатов. Это важно еще и с другой стороны, что "недоделанное" решение, имеющее полезные артефакты (ту же конфигурацию, где проблема повторяется) можно перенести на другого программиста, если у изначально ее решавшего, появляется более срочный кейс.
Даже менее консистентные промежуточные результаты в большинстве компаний фиксировались, если это тикет на плавающий баг, то ежедневно обновляется план дальнейшего исследования, и фиксируются попытки, которые не привели к результатам. Поначалу, там, где не было так принято, некоторые носы ворочали, а потом сами убедились, что очень удобно придти в понедельник "с пустой головой" и понять с чего надо продолжить. А тикет всегда добавляется в 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 рулит.
А если что, просто еще один сервер купим (за счет моей зарплаты в общем-то, вот и вся проблема).Но это в общем плане. А конкретно про эту функцию, ну хз. У меня вот есть подозрения, что она вообще не нужна, как минимум название у нее странное, и самодостаточно она не выглядит полезной. Просто цикломатическую сложность хотели понизить и сделали первое, что пришло на ум.
Причем фикс говорящий за себя. Такое ощущение, что за дело взялся человек, но либо у него совсем не хватало времени, либо квалификации, потому что все красивые идеи изначального подхода упустили, "как будто испугались". Я бы предложил так:
Скрытый текст
Но на бенчмарки пока времени нет.
Отличное исследование-расследование, хорошо, что проблему удалось найти. Глядя на
isEncodingSafeStartLineToken()я бы сразу проблему не обнаружил, вроде все красиво делается, и пакетная обработка, и отсутствие лишних if, а использование битовых масок. Трюк когда long chars = ... | ... | ... | ... мне тоже понравился, хотя несколько лишних секунд на подумать "почему это работает" он съедает. Но есть стойкое ощущение, что его написала ИИ, потому что человек, освоивший все остальное, вряд ли бы "забыл", как работает битовый сдвиг. Признаться, это дает какое-то такое ощущение, пугающее, что ли; сколько еще подобных багов, где они еще могут быть...В 2018 я делал подобное. Тоже изначально брал базу rockyou (но даже не "чистил" ее), и несколько более актуальных небольших утечек + комбинации пар слов из обычного словаря и они же с мутациями. За основу генератора адресов брал vanitygen, и у меня уже тогда скорости были примерно в 10 раз выше, чем то, что в статье. Базы адресов не было, поэтому пришлось немного модифицировать клиент биткоина, чтобы он создавал список адресов, на которых хоть когда-то был баланс (генерируется это в процессе парсинга блокчейна). Все в формате U_P2PKH. Построил блум-таблицу по этим адресам, и спокойно гонял свой форк vanity пока мне не надоело.
Исследование вышло интереснее немного, потому что более десятка тысяч уже опустошенных адресов я нашел. Нашел более сотни на тот момент не пустых кошельков. На абсолютном большинстве меньше сатош, чем нужно для вывода. Но на четырех адресах суммы до 2 BTC.
Долго терзался соблазном забрать их балансы себе (изначально я думал что таких адресов просто не будет), по принципу "не я так кто-то другой это сделает", но решился просто перевести с каждого из этих адресов себе по 5$. Так владельцы увидят, что кошельки компрометированы, но сильно не пострадают. Повторял подобный эксперимент в 2020, уже с несколько более недобрым умыслом, подгрести с этих адресов монеты форков биткоина, но к тому моменту уже все было вычищено.
Я бы сказал, что не стоит по навыкам играть в игру судить о чем-либо, кроме самого навыка играть в игру.
Скрытый текст
СК2 мне никогда не нравился, но как-то после покупки 240Гц монитора зашло переосмыслить игру в Fortnite, где до этого я просто "по фану бегал" и был признаться очень слабым игроком, который в целом не перерос понимание фортнайта как некий гибрид Q3 и CS. Потом потихонечку стал замечать, что какие-то buildfight связки стали даваться сами собой легче, и в игре появился новый интерес. Положительная обратная связь из-за постепенного продвижения в рейтинговых матчах дала мотивацию научиться "включать мозг" в игре, которую раньше считал "что-то для отдохнуть от мыслей". Про игру в частностях не буду расписывать, думаю мало кому это будет интересно, но потом через пару месяцев я пришел к такому состоянию восприятия, что ровно каждый проигранный мной матч содержал для меня явную видимую ошибку, причем не ретроспективно, а именно в моменте. И это всегда была комбинация ранее непредусмотренных, но предусматриваемых (казалось бы в игре с таким уровнем хаоса) недочетов. Стало еще интереснее играть. И вот, спустя время появилось ощущение, что я "научился играть!", что в принципе и рейтинговые матчи подтверждали.
...И мне казалось, что теперь я способен держать идеальную концентрацию в игре на протяжении 20-30 минут (время матча), микроменеджить всё необходимое время без ошибок (это не СК2, где весь матч по сути из этого, а где-то 10% времени игры), и никакой фрагментации сознания не происходило. Это, несомненно меня радовало (ибо ранее испытывал проблемы с концентрацией), но при всем желании перенести что-то из этих навыков или состояний на реальный мир, я получил (думаю это было понятно сразу):
Ничего. Ничего полезного, плюс более обостренное восприятие, что в игре за минуту времени я мог делать более тысячи осознанных так или иначе действий, а в любом рабочем процессе не изменилось ничего. Восприятие это неприятное, само собой.
Потому что обычно эти рабочие процессы выглядят так: нужно поменять одну строчку в конфиге на одном из серверов...
Скрытый текст
Ну окей, мозг говорит, это должно быть на полминуты. Но первое, я не помню ip этого сервера, а по доменному имени он почему-то не резолвится. Хорошо, идем ищем доку с его ip. Ну она вроде была в внутренней вики в этом разделе. А ее нет. Идем в поиск, первый запрос - ничего. Вспоминаю примерное название документа, ура, есть, нашлось. Смотрим на часы, прошло 10 минут (!). Да, документ недавно переносили, что ж, ладно, теперь он в более логичном месте, на самом деле. Дальше. Лезем подключаться. Неправильный пароль. Ну окей, может я его криво скопировал, еще разок. Неправильный пароль. Конечно, его кто-то успел заменить. Идем на дэшборд с серверами, вот же он, а где кнопка скопировать пароль? А ее уже нет. Изучаем обнову дэшборда, оказывается менеджмент паролей перенесли в отдельную страницу, ну окей, так даже логичнее, но пароль я посмотреть не могу, нет прав у меня. Ну вот и точка, время звонить админу. "Да, да, хорошо, добавил в группу доступа, обнови страницу". Обновил, получил пароль, подцепился к серверу. Ищем там конфиг, смотрим, упс, а его уже поменяли в возможно конфликтующем месте. Скидываем вопрос в чатик, завариваем чай, заодно отвечаем на пару вопросов коллег, смотрим на часы, прошло уже полтора часа. Получаем ответ "да, давай, ничего не сломает". Обновляем конфиг, сервер глубоко тестовый, так что даже отсутствие полной уверенности не пугает, но правда и не радует. Перезапускаем, да, окей, у меня все работает. Но остается еще помнить, что надо будет поглядывать в чатик активнее, чтобы точно никому ничего не сломать.
Прошло два часа. Усталость, некое чувство беспомощности, некое чувство неуверенности. Начинать что-то значимое уже не хочется, может посвятить остатки дня еще паре микрозадач? И вот бывает вторая из них так же растянется, вот и все, день закончен, сделано чуть больше чем нифига, настроение подавленное, а со временем отторжение к таким микрозадачам только растет.
Больше всего крадет время остутствие систематизации части
рабочихпроцессов. Но чтобы процесс появился вообще, нужно вообще понять что он есть (и какой он есть в сущности) и он нужен. А пока не очень понятно, так ли он нужен, чтобы его автоматизировать, концентрация расходуется.В общем да, в остатке остается одно, - себя не самобичевать, и на других не злиться.
Я открою форточку, и послушаю Kenny Rogers - The Gambler. Это, думаю, лучше, чем если я закрою форточку и что-то прям такое напишу в ответ.
Так вот и вопрос, что мы вообще оптимизируем и каким инструментарием оптимизации обладаем? Кому-то, наверное важно принципиально дожить до 80 лет более-менее самодостаточным, но потом то все равно будет что-то другое. Вопрос глубокий, что именно что.
Все-таки что-то не так с маркетингом ИИ. Заголовок прочитал первый раз так: марсоход "перевернулся" впервые, проехав по маршруту, спланированному ИИ.
Я кучу лет раньше мечтал о телефоне с дуалбутом в Windows, правда в идеале не на ARM, а на x86 процессоре. А потом, после работы с аналогами Desktop Mode (на Motorola и на Huawei свои аналоги) немного забыл зачем. То есть правда, как предполагается такой телефон использовать?
Я бы отправился где-то под конец 1946 года лучше всего в Ленинград, и у меня было бы достаточное время для публикации, а главное популяризации алгоритма Быстрого Преобразования Фурье. Тогда обнаруживать скрытые испытания ядерного оружия можно было бы значительно раньше. Ну правда пришлось бы с собой грузовик тушенки из будущего захватить на всякий случай.
Мне кажется, минусуют, потому что Вы используете какое-то свое понятие об игре, как будто достаточно открыть книгу по геймдизайну, научиться поворачивать матрицы, добавить "press E to interact", и вуаля, игра готова. Формально да, но это все максимум уровень пет-проектов школьников.
Вот какие у Вас любимые игры, в разных жанрах? И какие из них Вы проходили хотя бы два раза?
Да не нужно этих метафор. Я верю, что кому-то они могут помогать, допустим, но в среднем достаточно просто научиться декомпозировать цели на задачи, оценивать возможности решения этих подзадач, и решать по возможности. Какой-нибудь базовый GTD, без каких-то эмоциональных или метафорических прекрас будет точно так же работать.
Так это послание себе в прошлое. Начинать анализ мира с продвинутого небинарного мышления это спорная идея, оно очень много ресурсов жрет, если стремиться использовать его для создания каких-то выводов. Это типа для мудрых штука.
Проблема в обратной связи, если схема "сделать немного неприятнее => изменение" заработает, то почти все вокруг рано или поздно становится немного неприятнее, чем есть.
Главное знать "зачем". А остальное приложится :)
Так если нет никаких четких неизменяемых правил, механик и целей (а если это 3д игра - то и сеттинга, лора соединяющего сеттинг и задачи, у которых вообще-то должен быть еще и смысл в этом виртуальном мирке), то это не игра, а абсолютно буквально разновидность сна при температуре 38.
Я в том же фортнайте с мелких багов ору (кто-то бы и не заметил даже, вот баг одного непопулярного дробовика, который без прицеливания 50 на 50 попадет в цель которая находится в гарантированной зоне поражения, вплоть до point-blank, извините, но дробь так не работает, а пушка не претендует по сеттингу на что-то фантастическое), потому что это подрывает доверие к игровому процессу, а тут вся игра целиком из этого. Кому это нужно?
Максимально спорное утверждение. Люди-то отношение других игроков к игре именно что видят, видят и ощущают, а ИИ такую информацию обрабатывать не умеет, но кроме того, все тонкие нюансы этих наблюдений даже формализовать до невозможности сложно. Так что его удел (до появления ASI, причем уровня возможности полной виртуализации человеческих сознаний,
ага конечно) просто комбинировать популярные механики, чем люди прекрасно и без него занимаются, прекрасно, но давно уже без каких-то значимых прорывов.Впрочем, для многих людей разница между игрой и интерактивным кинцом действительно пренебрежимо мала, их ИИ еще как "накормит". Но это все из историй "пакман лучше шахмат", "банан лучше киви".