Последний месяц научпоп на Ютубе смотрю только по теме квантовой физики. Много всего стало понятнее, но как перенести эти принципы на кубиты и полезные на практике вычисления пока не удалось понять. ИИ тоже помучил, одна вода по теме, как и во всех статьях , что встречались. Решил попробовать через комменты на Хабре, посмотрим, вдруг магия сработает :)
Господа, может кто-то просто объяснить то, как кубиты в суперпозиции состояний в итоге "схлопываются" в нужное решение? Почему поиск решения должен быть условно мгновенным и как физическая природа частиц "поймет" когда "нашла"?
отечественные провайдеры цены взвинтили, хостинг Таймвеб - плачу 550 в месяц
С одной стороны цены подросли, а с другой - много ли 550р. в эти дни? При цене 100р. на Сникерс (который кстати на 20% меньше весит сейчас) и на кофе ~250р. как будто и не особо много.
Когда-то делал самописную реализацию поиска по маске (wildcard): GitHub
Возможно Вам будет интересно. Тоже NFA с состояниями на битах, поддерживаются ? и *, работает за O(MN) (цикл по длине строки и по длине паттерна). Зато любая длина поддерживается за счет того, хранилищем битов выступает массив байт конфигурируемой длины.
Полистал комментарии, не нашел однозначного ответа - что с играми на таком мониторе? Нужно искать способ на половину экрана их запускать или как это работает? Интересуют как новые, так и старые игрушки (которые даже просто на 16:9 капризничают)
Более того, сам по себе FastAPI это своего рода "сборка" из Starlette и Pydantic, определенный способ их использовать вместе. Добавочных фичей в библиотеке немного.
Зашёл написать/увидеть этот комментарий. GUI это возможно лучший домен для применения ООП. В свое время поработал с Qt, Windows Forms, Swing, Delphi - везде ООП чувствовался очень уместным, а опыт с одной технологии переносимым в другую. Как минимум из-за этого не хочется называть ООП скамом, ибо каждому инструменту свое применение 🙂
LINQ в C# правда очень удачно спроектирован, больше нигде такого удобства не встречалось. Однако сам язык после Go теперь кажется громоздким, например в части "наследных" от Java модификаторов. Начинать писать функцию с "public static void" и выбирать для неё класс теперь как-то лениво 🙂
P.S. Если бы надо было оставить только один ЯП для всего, то C# пожалуй все ещё лучший кандидат по моему мнению ввиду универсальности
Кмк чем больше однообразного опыта в карьере, чем тяжелее переключаться. Переход в тимлидскую роль это вообще не легкая прогулка, особенно после ~20 лет в роли individual contributor'а. Я делал переход давно, и сейчас все описанное в статье, конечно, читается как минимальная база. Но наверняка новоиспеченные тимлиды смогут что-то полезное почерпнуть. Хороший материал!
Чтобы язык стал популярным он должен статьи интересным бизнесу, не обязательно за то что он хороший и плевать хотел бизнес какое-там у инженеров к чему доверие
Фундаментально не согласен с этим утверждением. Бизнесу интересно заработать деньги, часто для этого нужно решить ряд инженерных проблем. За решение проблем отвечают инженеры. Выбор подходящего инструмента на 90% лежит в плоскости инженерной работы (с запасом оставлю 10% на логистику, правовые аспекты и т.д.)
Если бы бизнес выбирал инструменты разработки... страшно представить! Сразу оговорюсь, что есть IT-сферы бизнеса, где многие руководители являются бывшими инженерами. Влияние такого бизнеса на инженерные решения сомнению не подвергаю. А вот условная строительная фирма, сеть медицинских клиник, ритейлер - разве они как заказчики должны знать что-то о преимуществах или недостатках Go? В требованиях бывают слова про актуальный и распространенный стек разработки, реже про конкретный стек, например совместимый с текущим. Но и это все либо со слов, либо с аппрува инженеров обычно делается. Что они сами смогут сказать? "Где-то когда-то слышали, что PHP не очень, давайте делать на Go"? Или "у конкурента все на Java и они преуспевают, значит и нам надо Java"?
переманивать разрабов с других стеков и отчасти закрывать проблему кадров
А как тогда появились другие стеки, если за всем стоит бизнес? :) Вряд ли они породили бы текущий зоопарк технологий. В общем, есть в этом топике "проблема курицы и яйца", но как будто сначала язык занимает нишу и хорошо решает проблемы, а потом он начинает привлекать бизнес тем, что инженеры на нем быстро и качественно решат проблему. Не язык не решает проблему, а владеющие им инженеры.
Вам и @Metotron0, скромный совет или мнение, как угодно: не стоит делать из Go то, чем он не является. Было множество подходов к созданию аналогов Linq, каких-то своих удобных строк, хэлперов для горутин и так далее. В основном это бесполезное движение против ключевых концепций языка, которое только отдаляет приобретение мастерства и накопление релевантного опыта. Идиоматический код на Go пишется с циклами, с len, с громоздким select и т.д., ибо эта семантика понятна и привычна разработчикам на этом языке. Ее успешно и быстро считывает натренированный взгляд. И на условном собеседовании будут спрашивать именно про тонкости работы append, а не про обертки и кастомные библиотеки. Потому что как минимум нужно уметь читать код, который уже написан в рекомендованном официальными и неофициальным гайдами стиле.
Дзен понимания языка приходит, когда пишешь на нем, а не воссоздаешь парадигмы Java/C++/Rust, используя другие ключевые слова. Есть альтернативное мнение, что мы как зомбированные повторяем одно и то же, мол не надо изобретать, не нужны фреймворки и не надо использовать ORM. Возможно в нем есть доля истины. Но языку правда не нужна "команда по спасению", которая все исправит, понатащив концепций из других языков.
Объективно, если бы язык был плох, то он не сыскал бы такой популярности. Да, можно сказать, что за ним стоит Google, но так ли они его пушат?.. Кмк здесь больше все строится на доверии инженеров и сарафанном радио.
Наш день начинается с утреннего созвона, где обсуждаются текущие задачи и приоритеты. Основные задачи включают автоматизацию, решение инцидентов, консультирование коллег и работу с документацией. Важна командная работа и взаимодействие с другими отделами.
Звучит как созвон на созвоне и созвоном погоняет :) не предел мечтаний для инженера, но хотя бы честно...
Последний месяц научпоп на Ютубе смотрю только по теме квантовой физики. Много всего стало понятнее, но как перенести эти принципы на кубиты и полезные на практике вычисления пока не удалось понять. ИИ тоже помучил, одна вода по теме, как и во всех статьях , что встречались. Решил попробовать через комменты на Хабре, посмотрим, вдруг магия сработает :)
Господа, может кто-то просто объяснить то, как кубиты в суперпозиции состояний в итоге "схлопываются" в нужное решение? Почему поиск решения должен быть условно мгновенным и как физическая природа частиц "поймет" когда "нашла"?
Отличная работа! Это лучшее сопроводительное письмо при трудоустройстве, что я видел 😅
ITSumma, у вас вроде неплохой блог, какая мотивация начинать клепать нейрокакашки?
Опять неприкрытый вывод нейронки под видом статьи...
Ну здорово, ИИ пишет статьи про ИИ. Осталось и читать ИИ, и люди не нужны...
С одной стороны цены подросли, а с другой - много ли 550р. в эти дни? При цене 100р. на Сникерс (который кстати на 20% меньше весит сейчас) и на кофе ~250р. как будто и не особо много.
Когда-то делал самописную реализацию поиска по маске (wildcard): GitHub
Возможно Вам будет интересно. Тоже NFA с состояниями на битах, поддерживаются
?и*, работает заO(MN)(цикл по длине строки и по длине паттерна). Зато любая длина поддерживается за счет того, хранилищем битов выступает массив байт конфигурируемой длины.Полистал комментарии, не нашел однозначного ответа - что с играми на таком мониторе? Нужно искать способ на половину экрана их запускать или как это работает? Интересуют как новые, так и старые игрушки (которые даже просто на 16:9 капризничают)
Более того, сам по себе FastAPI это своего рода "сборка" из Starlette и Pydantic, определенный способ их использовать вместе. Добавочных фичей в библиотеке немного.
Зашёл написать/увидеть этот комментарий. GUI это возможно лучший домен для применения ООП. В свое время поработал с Qt, Windows Forms, Swing, Delphi - везде ООП чувствовался очень уместным, а опыт с одной технологии переносимым в другую. Как минимум из-за этого не хочется называть ООП скамом, ибо каждому инструменту свое применение 🙂
Внезапно, может быть! Я вот например игнорировал книжки по Дюне, и с удовольствием пережил все сюжетные повороты в кинотеатре, впервые.
P.S. Помнится пару лет назад попадался мемный тред про то, как распятие Иисуса было для кого-то спойлером 😅
Warcraft 3
Grubby недавно пару турниров провел, онлайн зрителей на стримах был выше, чем в WoW
LINQ в C# правда очень удачно спроектирован, больше нигде такого удобства не встречалось. Однако сам язык после Go теперь кажется громоздким, например в части "наследных" от Java модификаторов. Начинать писать функцию с "public static void" и выбирать для неё класс теперь как-то лениво 🙂
P.S. Если бы надо было оставить только один ЯП для всего, то C# пожалуй все ещё лучший кандидат по моему мнению ввиду универсальности
Здорово у Вас получилось! 👍
Кмк чем больше однообразного опыта в карьере, чем тяжелее переключаться. Переход в тимлидскую роль это вообще не легкая прогулка, особенно после ~20 лет в роли individual contributor'а. Я делал переход давно, и сейчас все описанное в статье, конечно, читается как минимальная база. Но наверняка новоиспеченные тимлиды смогут что-то полезное почерпнуть. Хороший материал!
В моем мире не только "мамкины" инженеры 😅
Фундаментально не согласен с этим утверждением. Бизнесу интересно заработать деньги, часто для этого нужно решить ряд инженерных проблем. За решение проблем отвечают инженеры. Выбор подходящего инструмента на 90% лежит в плоскости инженерной работы (с запасом оставлю 10% на логистику, правовые аспекты и т.д.)
Если бы бизнес выбирал инструменты разработки... страшно представить! Сразу оговорюсь, что есть IT-сферы бизнеса, где многие руководители являются бывшими инженерами. Влияние такого бизнеса на инженерные решения сомнению не подвергаю. А вот условная строительная фирма, сеть медицинских клиник, ритейлер - разве они как заказчики должны знать что-то о преимуществах или недостатках Go? В требованиях бывают слова про актуальный и распространенный стек разработки, реже про конкретный стек, например совместимый с текущим. Но и это все либо со слов, либо с аппрува инженеров обычно делается. Что они сами смогут сказать? "Где-то когда-то слышали, что PHP не очень, давайте делать на Go"? Или "у конкурента все на Java и они преуспевают, значит и нам надо Java"?
А как тогда появились другие стеки, если за всем стоит бизнес? :) Вряд ли они породили бы текущий зоопарк технологий. В общем, есть в этом топике "проблема курицы и яйца", но как будто сначала язык занимает нишу и хорошо решает проблемы, а потом он начинает привлекать бизнес тем, что инженеры на нем быстро и качественно решат проблему. Не язык не решает проблему, а владеющие им инженеры.
Вам и @Metotron0, скромный совет или мнение, как угодно: не стоит делать из Go то, чем он не является. Было множество подходов к созданию аналогов Linq, каких-то своих удобных строк, хэлперов для горутин и так далее. В основном это бесполезное движение против ключевых концепций языка, которое только отдаляет приобретение мастерства и накопление релевантного опыта. Идиоматический код на Go пишется с циклами, с len, с громоздким select и т.д., ибо эта семантика понятна и привычна разработчикам на этом языке. Ее успешно и быстро считывает натренированный взгляд. И на условном собеседовании будут спрашивать именно про тонкости работы append, а не про обертки и кастомные библиотеки. Потому что как минимум нужно уметь читать код, который уже написан в рекомендованном официальными и неофициальным гайдами стиле.
Дзен понимания языка приходит, когда пишешь на нем, а не воссоздаешь парадигмы Java/C++/Rust, используя другие ключевые слова. Есть альтернативное мнение, что мы как зомбированные повторяем одно и то же, мол не надо изобретать, не нужны фреймворки и не надо использовать ORM. Возможно в нем есть доля истины. Но языку правда не нужна "команда по спасению", которая все исправит, понатащив концепций из других языков.
Объективно, если бы язык был плох, то он не сыскал бы такой популярности. Да, можно сказать, что за ним стоит Google, но так ли они его пушат?.. Кмк здесь больше все строится на доверии инженеров и сарафанном радио.
Как это зачем? Чтобы построить там дата-центр, с которым не сможет нарушить связанность экскаватор ^^
Звучит как созвон на созвоне и созвоном погоняет :) не предел мечтаний для инженера, но хотя бы честно...