T-строки позволяют сделать структурный логгинг фактически бесплатным
Ага, и получить накладные расходы на формирование шаблонов на каждое сообщение логгера, они же не ленивые! Лучше бы в logging добавили форматирование через {}. такое же как сейчас ленивое с аргументами, но с современным языком форматирования. Как в loguru. Сейчас все лепят logger.debug(f'Bla bla bla {super_heavy_object_to_format}') вместо ленивого форматирования, а теперь ещё и t-strings лепить начнут.
Структурированное логгирование делается просто через JSON-форматтер (python-json-logger) и фильтры/extra, благо стандартный логгер очень гибко конфигурируется. А structlog/loguru ни с чём не совместимые библиотеки.
В конце концов должно быть абсолютное право потерять свои данные под личную ответственность дееспособного человека, а не считаться недоумком по умолчанию.
Эти самые "много 0.x версий, которые работали мегастабильно и очень хорошо поддерживали обратную совместимость", они с нами в одной комнате? Никакой конкретики.
Вы, наверное, шутите? Это же "software's most popular versioning scheme". Их "миллион". https://0ver.org
Столько места, а они не могут сделать нормальную клавиатуру. Идиотизм просто. Хотя понятно почему, им так дешевле в производстве. Но этим же невозможно пользоваться!
Проблема в том, что нужно писать чёртов бойлерплейт, если обрабатывать не нужно, а нужно протащить куда-то наверх. И писать эти проверки на каждом уровне по всему коду. Код просто замусоривается. В Rust тоже нет исключений, но то же самое по сути делается одним символом ?. Почему в Go так же сделать нельзя? Что принципиально мешает?
Из-за этого не люблю писать на Go и когда читаю исходники чего-нибудь, меня просто корёжит от этих бесконечных проверок на nil. Я терпеть не могу бойлерплейт, и это задевает моё чувство прекрасного. Я не понимаю как это может устраивать, для современного языка, у которого не было груза обратной совместимости можно было подумать и сделать нормально изначально. Ну или хотя бы не отклонять так ревностно любые предложения на эту тему, а запланировать что-то с этим сделать хотя бы в версии 2.
Да, пожалуй, FastAPI - это лучшее, что случилось в backend/web разработке в экосистеме Python. Это как озарение. Когда человек по сути в одиночку может взять и сделать лучше на порядок чем куча неглупых людей до него. Максимум простоты, максимум свободы и в то же время контроля над кодом, никакой магии, чистый, надёжный, самодокументируемый код за счёт аннотаций типов и простой понятной архитектуры без глупостей и непродуманных решений (как в starlite/litestar, например) и заложенными правильными светлыми идеями (вроде генерации OpenAPI схемы из кода сервера, а не, чёрт возьми, наоборот).
Я не понимаю, как можно что-то писать на каком-нибудь насквозь магическом и монстроузном DRF после FastAPI. Да, это разные весовые категории, но это же как будто две огромные гири к рукам привязать и программировать с ними, или пересесть с профессионального велосипеда на ашанбайк и поехать на нем велогонку, так же медленно, мучительно и неудобно.
Что за столяр, который не может без станков и проф. инструмента сделать качественную мебель/дверь/оконную раму. Вот тебе ручная дрель, кривая пила, ржавая тупая стамеска и молоток, иди делай. Можно, но очень долго? А ты быстро сделай, как будто станками пользуешься, медленно любой дурак может.
IDE - это профессиональный инструмент профессионального программиста, в котором он профессионально работает. Он потом на работе тоже будет в notepad код писать?
Мои соболезнования, раз в вашем мире стеб - самоутверждение и превосходство
Это не в моём мире так, это в принципе так.
Дополнительным признаком стёба является наличие «антинормы» в речевом поведении, провокативность (склонность к издевательству, высмеиванию, юродствованию); в стёбе широко используются гротеск, сатира, ирония, гипербола.
За стёбом, интонацией напора и превосходства часто скрывается сознание собственной некомпетентности и несостоятельности. Честолюбие, возвышение над другими, желание чувствовать себя лучше других может быть одной из целей стёба.
Я не понял как вы перешли от "коллектива профессионалов", которые стебут друг друга за косяки (потому что косяки бывают у всех) к коллективу, в котором профессионалы стебут пока ещё не профессионалов, т. е. вынуждены возиться с "брёвнами, не способными гуглить".
3х миньонов с окладами 150 000 которых надо учить, это потери 700 000 в месяц
Откуда берутся люди, которых не надо учить? Сразу рождаются такими?
Вы работали в компании паразитом, жрали время других людей и деньги компании.
Не понятно к кому это относится. В любом случае, где-то кто-то когда-то должен заниматься выращиванием специалистов, люди не рождаются с багажом знаний, опытом и профессией.
Я не знаю, гениален ли автор, но побывав в разных проектах и командах, я повидал всякое дерьмо, как говорится. Но возьмём такую гипотезу:
Например, есть у людей какой-то ML, какие-то модели на коленке собранные, запущенные, кое-как обученные. Сделали как смогли, как умели, поленились, не укладывались в сроки/дедлайны и т.д. Как-то работает, но не супер и надо улучшать. И вот они ищут ML инженера, настоящего, с хорошим опытом и бэкграундом, чтобы как раз пришёл, провел ревизию всего хозяйства и улучшил всё что можно улучшить, чтобы их бизнес денег больше генерировал.
Находят они такого человека, он приходит, смотрит на пайплайн, на всё их добро своим свежим опытным взглядом. Он такое 100 раз видел, ничего нового, ничего уникального, ему не надо быть гением, чтобы понять где можно быстро улучшить, переписать, как пайплайн оптимизировать, как с данными правильно работать, какие гиперпараметры подкрутить и т. д. Он просто говорит, что и где можно изменить, улучшить прямо сейчас без "переписывания всего на Rust". А дальше начинается то, что в статье описано.
Вроде человека специально наняли для такой работы, сверху понимают, что не всё хорошо в проекте, но внезапно появляется сопротивление снизу, потому что люди не могут принять конструктивную критику, особенно от новичка в коллективе, кто-то боится потерять теплые места, у кого-то ЧСВ, кто-то ассоциирует код/проект со своей личностью и воспринимает как нападки на себя, а кто-то просто токсичный мудак.
И вот в таком коллективе реально сложно что-то сделать, даже если бизнесу позарез надо, даже если ты уже не новичок там. Ты попадаешь в это болото, и оно затягивает, если ты сразу оттуда не выбрался.
гораздо приятнее в токсичном коллективе профессионалов, когда за косяки тебя стебут
В чём нормальный? Я работал в коллективах нетоксичных профессионалов, где никого не стебали за косяки, а просто решали проблемы и объясняли, что не так, что не нужно было делать и как нужно было делать. Профессионально и доброжелательно. И работать в такой атмосфере сильно приятнее чем в коллективе, где агрессивные мудаки друг друга стебут. Зачем профессионалам вообще кого-то стебать и унижать? Им не нужно самоутверждаться и показывать своё превосходство ни перед кем, они профессионалы и заняты своей профессиональной деятельностью.
Припёрся какой-то хер невесть откуда и в первую же неделю начал предлагать улучшение моделей? Ну, тут да, тут надо было немедленно реагировать, обязательно.
То есть не важно, что человек пришел в компанию работу работать и мог предложить дельное улучшение в рамках своих должностных обязанностей? Вообще не важно, что он там предлагал по существу. Главное, что этот выскочка, "какой-то хер невесть откуда" в первую же неделю начал тут баламутить наше уютное тёплое болото и умного из себя строить.
чтобы узнать как работает сегодня распознавание можно взять любой телефон в руки и убедиться что этот юмор уже не актуален
Ахаха. Ещё как актуален. Я работаю несколько лет в этой области и каждый день мы с этим сталкиваемся и решаем очередные проблемы Speech-to-Text от злых клиентов, которых не поняли, поняли не так, проигнорировали и т. д. Большинство наших клиентов как раз пытаются сделать что-то голосом из машины, и как же они злятся, когда ничего не работает. И эти проблемы абсолютно у всех именитых и не очень STT движков. Абсолютно у всех без исключений, особенно в условиях шума, низкого качества микрофона и т. д. Google Speech кстати один из самых худших по метрикам.
В каком-то из сезонов "Only Murders in the Building" тоже есть сцена с кривым распознаванием речи.
И чтобы убедиться как ужасно работает распознавание, возьмите любой телефон в руки и попробуйте пообщаться с кем-то в режиме синхронного переводчика.
. Но пора уже заметить что у машин теперь миллион функций
Пора им уже остановиться и перестать пихать "миллион" ненужных функций. Хотя они конечно не перестанут, ведь надо же постоянно что-то выдумывать, чтобы поддерживать спрос.
Ролику 10 лет, но проблема всё ещё актуальна. :) Это абсурд - делать голосовое управление там, где прекрасно работает одна физическая кнопка с крутилкой.
Вспоминаю как недавно ехали в тесле (за рулём не я). Водитель пытался настроить обогрев, тыкая в экран пальцем. Проблема была в том, что ехали мы по узкой европейской улочке с брусчаткой, машину дико трясло, палец у водителя постоянно дрожал и съезжал, и он долго не мог попасть в нужные кнопки на экране и отрегулировать слайдер, который там регулирует поток воздуха. Ещё ему надо было смотреть на дорогу.
Машины с экранами вместо кнопок - это безумие и зло ради повышения прибыли автопроизводителей, которое должно отмереть. И это пройдёт, вот увидите.
Вы про t-strings?
Я про f-strings, что их пихают в логгер. И там ничего не откладывается. Всё форматируется в момент создания f-строки.
Простой пример для проверки:
В итоге код тормозит даже с выключенными логами из-за бесполезного создания f-строк.
Ага, и получить накладные расходы на формирование шаблонов на каждое сообщение логгера, они же не ленивые! Лучше бы в logging добавили форматирование через
{}. такое же как сейчас ленивое с аргументами, но с современным языком форматирования. Как в loguru. Сейчас все лепятlogger.debug(f'Bla bla bla {super_heavy_object_to_format}')вместо ленивого форматирования, а теперь ещё и t-strings лепить начнут.Структурированное логгирование делается просто через JSON-форматтер (python-json-logger) и фильтры/extra, благо стандартный логгер очень гибко конфигурируется. А structlog/loguru ни с чём не совместимые библиотеки.
В конце концов должно быть абсолютное право потерять свои данные под личную ответственность дееспособного человека, а не считаться недоумком по умолчанию.
Увидел эту статью и вспомнил, что уже читал про то, что не стоит делать игры на Rust.
И действительно. Вот аж в 4 частях.
https://habr.com/ru/articles/811163/
https://habr.com/ru/articles/812661/
https://habr.com/ru/articles/813139/
https://habr.com/ru/articles/813597/
Вы, наверное, шутите? Это же "software's most popular versioning scheme". Их "миллион".
https://0ver.org
У многих моделей Lenovo Legion нет звука из встроенных динамиков. И его нигде нет где используется Realtek ALC3306.
https://bugzilla.kernel.org/show_bug.cgi?id=213159
А вот это чинили тоже много лет.
https://bugzilla.kernel.org/show_bug.cgi?id=208555
Вообще постоянно проблемы со звуком и Realtek. Неужели не сталкивались ни разу?
Столько места, а они не могут сделать нормальную клавиатуру. Идиотизм просто. Хотя понятно почему, им так дешевле в производстве. Но этим же невозможно пользоваться!
Проблема в том, что нужно писать чёртов бойлерплейт, если обрабатывать не нужно, а нужно протащить куда-то наверх. И писать эти проверки на каждом уровне по всему коду. Код просто замусоривается. В Rust тоже нет исключений, но то же самое по сути делается одним символом
?. Почему в Go так же сделать нельзя? Что принципиально мешает?Из-за этого не люблю писать на Go и когда читаю исходники чего-нибудь, меня просто корёжит от этих бесконечных проверок на nil. Я терпеть не могу бойлерплейт, и это задевает моё чувство прекрасного. Я не понимаю как это может устраивать, для современного языка, у которого не было груза обратной совместимости можно было подумать и сделать нормально изначально. Ну или хотя бы не отклонять так ревностно любые предложения на эту тему, а запланировать что-то с этим сделать хотя бы в версии 2.
Например:
https://github.com/qdrant/qdrant
https://github.com/vectordotdev/vector
https://github.com/rustdesk/rustdesk
https://github.com/zed-industries/zed
https://github.com/dani-garcia/vaultwarden
Ну и Servo, конечно, если рассматривать Big Tech
https://github.com/servo/servo
И Fuchsia
https://fuchsia.googlesource.com/fuchsia/
Это из каких лохматых годов утверждение?
Да, пожалуй, FastAPI - это лучшее, что случилось в backend/web разработке в экосистеме Python. Это как озарение. Когда человек по сути в одиночку может взять и сделать лучше на порядок чем куча неглупых людей до него. Максимум простоты, максимум свободы и в то же время контроля над кодом, никакой магии, чистый, надёжный, самодокументируемый код за счёт аннотаций типов и простой понятной архитектуры без глупостей и непродуманных решений (как в starlite/litestar, например) и заложенными правильными светлыми идеями (вроде генерации OpenAPI схемы из кода сервера, а не, чёрт возьми, наоборот).
Я не понимаю, как можно что-то писать на каком-нибудь насквозь магическом и монстроузном DRF после FastAPI. Да, это разные весовые категории, но это же как будто две огромные гири к рукам привязать и программировать с ними, или пересесть с профессионального велосипеда на ашанбайк и поехать на нем велогонку, так же медленно, мучительно и неудобно.
Что за столяр, который не может без станков и проф. инструмента сделать качественную мебель/дверь/оконную раму. Вот тебе ручная дрель, кривая пила, ржавая тупая стамеска и молоток, иди делай. Можно, но очень долго? А ты быстро сделай, как будто станками пользуешься, медленно любой дурак может.
IDE - это профессиональный инструмент профессионального программиста, в котором он профессионально работает. Он потом на работе тоже будет в notepad код писать?
Это не в моём мире так, это в принципе так.
https://ru.wikipedia.org/wiki/Стёб
Я не понял как вы перешли от "коллектива профессионалов", которые стебут друг друга за косяки (потому что косяки бывают у всех) к коллективу, в котором профессионалы стебут пока ещё не профессионалов, т. е. вынуждены возиться с "брёвнами, не способными гуглить".
Откуда берутся люди, которых не надо учить? Сразу рождаются такими?
Не понятно к кому это относится. В любом случае, где-то кто-то когда-то должен заниматься выращиванием специалистов, люди не рождаются с багажом знаний, опытом и профессией.
Я не знаю, гениален ли автор, но побывав в разных проектах и командах, я повидал всякое дерьмо, как говорится. Но возьмём такую гипотезу:
Например, есть у людей какой-то ML, какие-то модели на коленке собранные, запущенные, кое-как обученные. Сделали как смогли, как умели, поленились, не укладывались в сроки/дедлайны и т.д. Как-то работает, но не супер и надо улучшать. И вот они ищут ML инженера, настоящего, с хорошим опытом и бэкграундом, чтобы как раз пришёл, провел ревизию всего хозяйства и улучшил всё что можно улучшить, чтобы их бизнес денег больше генерировал.
Находят они такого человека, он приходит, смотрит на пайплайн, на всё их добро своим свежим опытным взглядом. Он такое 100 раз видел, ничего нового, ничего уникального, ему не надо быть гением, чтобы понять где можно быстро улучшить, переписать, как пайплайн оптимизировать, как с данными правильно работать, какие гиперпараметры подкрутить и т. д. Он просто говорит, что и где можно изменить, улучшить прямо сейчас без "переписывания всего на Rust". А дальше начинается то, что в статье описано.
Вроде человека специально наняли для такой работы, сверху понимают, что не всё хорошо в проекте, но внезапно появляется сопротивление снизу, потому что люди не могут принять конструктивную критику, особенно от новичка в коллективе, кто-то боится потерять теплые места, у кого-то ЧСВ, кто-то ассоциирует код/проект со своей личностью и воспринимает как нападки на себя, а кто-то просто токсичный мудак.
И вот в таком коллективе реально сложно что-то сделать, даже если бизнесу позарез надо, даже если ты уже не новичок там. Ты попадаешь в это болото, и оно затягивает, если ты сразу оттуда не выбрался.
В чём нормальный? Я работал в коллективах нетоксичных профессионалов, где никого не стебали за косяки, а просто решали проблемы и объясняли, что не так, что не нужно было делать и как нужно было делать. Профессионально и доброжелательно. И работать в такой атмосфере сильно приятнее чем в коллективе, где агрессивные мудаки друг друга стебут. Зачем профессионалам вообще кого-то стебать и унижать? Им не нужно самоутверждаться и показывать своё превосходство ни перед кем, они профессионалы и заняты своей профессиональной деятельностью.
То есть не важно, что человек пришел в компанию работу работать и мог предложить дельное улучшение в рамках своих должностных обязанностей? Вообще не важно, что он там предлагал по существу. Главное, что этот выскочка, "какой-то хер невесть откуда" в первую же неделю начал тут баламутить наше уютное тёплое болото и умного из себя строить.
Ты самый умный что ли?
Тебе больше всех надо?
Знакомые вопросы?
Ахаха. Ещё как актуален. Я работаю несколько лет в этой области и каждый день мы с этим сталкиваемся и решаем очередные проблемы Speech-to-Text от злых клиентов, которых не поняли, поняли не так, проигнорировали и т. д. Большинство наших клиентов как раз пытаются сделать что-то голосом из машины, и как же они злятся, когда ничего не работает. И эти проблемы абсолютно у всех именитых и не очень STT движков. Абсолютно у всех без исключений, особенно в условиях шума, низкого качества микрофона и т. д. Google Speech кстати один из самых худших по метрикам.
В каком-то из сезонов "Only Murders in the Building" тоже есть сцена с кривым распознаванием речи.
И чтобы убедиться как ужасно работает распознавание, возьмите любой телефон в руки и попробуйте пообщаться с кем-то в режиме синхронного переводчика.
Пора им уже остановиться и перестать пихать "миллион" ненужных функций. Хотя они конечно не перестанут, ведь надо же постоянно что-то выдумывать, чтобы поддерживать спрос.
Вместо тысячи слов про голосовое управление: Elevator Recognition
Ролику 10 лет, но проблема всё ещё актуальна. :)
Это абсурд - делать голосовое управление там, где прекрасно работает одна физическая кнопка с крутилкой.
Вспоминаю как недавно ехали в тесле (за рулём не я). Водитель пытался настроить обогрев, тыкая в экран пальцем. Проблема была в том, что ехали мы по узкой европейской улочке с брусчаткой, машину дико трясло, палец у водителя постоянно дрожал и съезжал, и он долго не мог попасть в нужные кнопки на экране и отрегулировать слайдер, который там регулирует поток воздуха. Ещё ему надо было смотреть на дорогу.
Машины с экранами вместо кнопок - это безумие и зло ради повышения прибыли автопроизводителей, которое должно отмереть. И это пройдёт, вот увидите.
https://www.autocar.co.uk/car-news/new-cars/volkswagen-reintroducing-physical-controls-vital-functions
https://vc.ru/money/1866684-vsya-pravda-pro-realnuyu-inflyaciyu-v-rossii
1 комментарий. Вы всё ещё уверены, что VC жив?