Я бы не стал так критично относиться к микросервисам. В моём случае, например, так получилось, что я - единственный человек в команде по разработке системы скрейпинга, но при этом скрейперы очень разные, и их много, а контрольная панель одна. Логично, что каждый скрейпер я выделю в микросервис, который обрабатывает очередь постоянных задач и который я в любой момент могу остановить, чтобы улучшить, и запустить вновь. Так что случай с большой командой - не единственный возможный)
По-моему, смысл данных запросов довольно очевиден) к тому же, результат может сильно разниться в зависимости от кода и задачи. Тут лучше просто попробовать
В вакансиях требуется опыт коммерческой разработки. Но обратите внимание - не сказано, на каком конкретно языке)) потому что в коммерческой разработке у вас очень редко будет только 1 язык. Поэтому советую подучить что-то попроще и пойти поработаль по этому направлению, а уже после - в С++. В плюсы действительно берут только матёрых программистов, а вот куда-нибудь в веб - легко вообще без опыта. Я в свои 15 за 2 дня нашёл аж 3 вакансии, на которые меня пригласили без опыта в коммерческой разработке. Думаю, это самый легкий старт
Кроме того, есть путь через конкурсы, хакатоны и олимпиады. Если займешь призовое место - во-первых, выплачивают вознаграждение, а во-вторых, могут предложить контракт на развитие того, что ты сделал. Это второй путь, тоже довольно удачный и более интерксный, чем первый, но без гарантий
А может быть, у вас будет свой путь. В любом случае - желаю удачи!
О БОЖЕ вы спасли меня от переустановки linux :) совет: если у Вас не работает созданное кем-то графическое приложение в докере (например, эмулятор), посмотрите YML конфиг: возможно, в разделе devices они написали /dev/snd:/dev/snd. Замените это на подключение устройств, как описано в данной статье -- возможно, это поможет!
Примечательно, что на Ubuntu 22.04 и ниже подключение через /dev/snd работает, но на 24.04 уже нет
Ну вот автор статьи к этому и призывает) судя по его высказываниям и примерам, многие как раз таки и пытаются эту отвертку от швейцарского ножа использовать, чтобы починить автомобиль
Ну вы прям через чур категоричны) пвтор призывает не отказаться от среднего, а не принимать среднее как идеал. Статистический показатель - это хорошо, но ровно до того момента, в котором люди станут принимать это как то, к чему стоит стремиться. Что такое "средний человек"? Если рассчитать как "среднее арифметическое", то получится, что он будет уметь всё по чуть-чуть, и нигде не сможет достичь успеха. В этом такое представление губительно. Если на работу не взяли из-за того, что ты не знаешь, что такое Fossil, но знаешь, что такое Git, и при этом у тебя огромный опыт в разработке программ, которой занимается компания, это хорошо? Взяли вместо тебя человека с точно подходящим набором скиллов, но никак не разбирающимся в теме работы. Это плохое решение. Пример конечно утрированный, и HR закидали бы меня тухлыми помидорами. Почему? Потому что они как раз избегают применение общих шаблонов для собеседования и стараются подойти к человеку максимально индивидуально, оценивая его на основе его успехов в различных областях
У этого фреймворка рендеринг настолько виртуальный, что он явно происходит где-то за пределами моего устройства, от чего я на их сайте вижу только белый экран. Но это такая фича, не волнуйтесь. Новейшая оптимизация, так сказать
Почему же, в данном утверждении автор прав. Иначе как объяснить пояаление монструозных серверных процессоров интел и АМД? Не проще разве натыкать кучу старых?) Конечно нет, ведь если связь между компонентами располагается на одном чипе, это НАМНОГО более производительно, чем связь отдельных чипов между собой. КПД как раз таки вырастет. Разумеется, есть ряд технических нюансов, и такое сравнение не совсем корректно из-за разных архитектур, но в общем случае всё так
Люди, вы забываете, насколько трудно внедрить новые технологии в большие компании. Чтобы перестроить все бизнес-процессы, нужно огромное количество временных и финансовых трат. А потом команда нейронок просто не сможет решить поставленную задачу, и всё))
Такие технологии скорее будут распространены среди стартапов или небольших компаний. Но мир пока совершенно не готов к такому
Сильно и резко спрос на айтишников не упадёт) чтобы перестроить все технологические процессы, потребуются годы, или даже десятилетия. Даже если бы сейчас уже была готова нейронка, которая способна выдать план разработки огромного сервиса, подобного гугл поиску, с возможностью интеграции с другими готовыми сервисами, как внутренними, так и внешними, проанализировать все зависимости, а также определить, какие команды нейронок ей нужны (включая нейронок-программистов, нейронок-дизайнеров, нейронок-тестировщиков и т.д.) и наладить всю коммуникацию, потребуется ОЧЕНЬ много времени для их настройки, отладки, сравнения с моделями-конкурентами. А ещё необходимо сформировать команду, которая будет ставить нейронкам (или главной нейронке) задачи, мониторить процесс разработки и проверять результаты тестирования и сам продукт
Это всё требует поистине гигантских финансовых трат. А потом найдётся задача, которую нейронки ещё не могут решить)) и всё это коту под хвост. Такие технологии будут использовать скорее стартапы, которые также без проблем смогут воспользоваться разработкой на аутсорсе
Предполагаю, vldF имел ввиду, что при операции list=tuple полное имя функции, которое видит компилятор, меняется. На деле это не так, т.к. list - ссылка. Это действительно нельзя так просто проверить
Самый большой недостаток чата гпт в том, что он не сможет реализовать по-настоящему большие проекты. Например, где куча микросервисов. Штук 20. Сделать под это клиентские приложения, которые состоят не из 2-3 скриптов, а с обширной файловой структурой. Написать для этого всего тесты. Сделать все микросервисы в виде докер контейнеров и развернуть это на сервере. Я вот не поедставляю, как такое через нейронку сделать. Можете попробовать)
Я искренне надеюсь, что автор не разочаруется в написании статей из-за бестактных комментаторов, вытащит всю необходимую информацию из фидбека, и продолжит развиваться и писать статьи. Желаю удачи!)
P.S. главная ошибка в том, что автор не указала, что это суперупрощённая схема, и что на самом деле механизм намного сложнее, особенно в плане взаимодействия с различными компонентами ОС. Так как для каждой ОС детали процесса могут отличаться, стоит абстрагироваться от этого взаимодействия и рассказать только о базовых процессах, происходящих в браузере. Ну и лучше сразу указать, что эта статья не для специалистов, которые и так всё знают)
Обсуждая Линукс, очень часто затрагивают тему его GUI, в том числе оболочки gnome. Но я имел ввиду другое: Майкрософт сама выпустила свой фреймворк и сама сделала его важнейшим компонентом. В то время, как qt и python - языки, на которых хоть и написаны некоторые компоненты Линукс, они не созданы Линусом Торвальдсом и не сделаны главными компонентами линукса
switch - не процедурное наследие. Процедурное наследие - goto. Вот этот оператор реально может похерить code style) после него и появилось структурное программирование, в основе которого лежит утверждение: любую программу можно написать с помощью линейных переходов, условий и циклов. switch работает немного иначе, нежели goto с метками. И мне казалось, что switch появился позже, но тут могу ошибаться.
switch действительно можно избежать, но главный вопрос - целесообразность. Если это увеличит количество кода в разы, ещё и убавляя производительность (например, заменив его на какой-то класс), то сколько методов open/close не придерживайся, а код будет куда менее читабельным и его будет труднее редачить. Так что предлагаю сделать вывод: большие конструкции в switch действительно не стоит пихать, потому что это смотрится дико. Но для простых задач switch прекрасно подходит
Я вроде осознал главную мысль спора. WieRuindl считает, что switch - лишняя обёртка над вызовом соответствующего метода. Но это далеко не во всех случаях так. Например, есть метод получения количества дней в месяце, представленный GreyN. Этот код невозможно улучшить, switch идеально вписывается сюда. Так что предлагаю закончить дискуссию и принять, что бывают случаи, когда switch упрощает жизнь, но использовать его где попало - нельзя
Всегда нужно ставить вопрос целесообразности. Если класс выполняет одну единственную функцию и его не планируется расширять, а любое применение каких-то принципов усложняет код и увеличивает его количество в разы, то я считаю, что настольное применение каких-либо принципов - плохо. Принципы разработаны для общих случаев. Ну и безусловно, код должен быть красивым и читаемым
Я бы не стал так критично относиться к микросервисам. В моём случае, например, так получилось, что я - единственный человек в команде по разработке системы скрейпинга, но при этом скрейперы очень разные, и их много, а контрольная панель одна. Логично, что каждый скрейпер я выделю в микросервис, который обрабатывает очередь постоянных задач и который я в любой момент могу остановить, чтобы улучшить, и запустить вновь. Так что случай с большой командой - не единственный возможный)
По-моему, смысл данных запросов довольно очевиден) к тому же, результат может сильно разниться в зависимости от кода и задачи. Тут лучше просто попробовать
В вакансиях требуется опыт коммерческой разработки. Но обратите внимание - не сказано, на каком конкретно языке)) потому что в коммерческой разработке у вас очень редко будет только 1 язык. Поэтому советую подучить что-то попроще и пойти поработаль по этому направлению, а уже после - в С++. В плюсы действительно берут только матёрых программистов, а вот куда-нибудь в веб - легко вообще без опыта. Я в свои 15 за 2 дня нашёл аж 3 вакансии, на которые меня пригласили без опыта в коммерческой разработке. Думаю, это самый легкий старт
Кроме того, есть путь через конкурсы, хакатоны и олимпиады. Если займешь призовое место - во-первых, выплачивают вознаграждение, а во-вторых, могут предложить контракт на развитие того, что ты сделал. Это второй путь, тоже довольно удачный и более интерксный, чем первый, но без гарантий
А может быть, у вас будет свой путь. В любом случае - желаю удачи!
О БОЖЕ вы спасли меня от переустановки linux :) совет: если у Вас не работает созданное кем-то графическое приложение в докере (например, эмулятор), посмотрите YML конфиг: возможно, в разделе devices они написали /dev/snd:/dev/snd. Замените это на подключение устройств, как описано в данной статье -- возможно, это поможет!
Примечательно, что на Ubuntu 22.04 и ниже подключение через /dev/snd работает, но на 24.04 уже нет
Ну вот автор статьи к этому и призывает) судя по его высказываниям и примерам, многие как раз таки и пытаются эту отвертку от швейцарского ножа использовать, чтобы починить автомобиль
Ну вы прям через чур категоричны) пвтор призывает не отказаться от среднего, а не принимать среднее как идеал. Статистический показатель - это хорошо, но ровно до того момента, в котором люди станут принимать это как то, к чему стоит стремиться. Что такое "средний человек"? Если рассчитать как "среднее арифметическое", то получится, что он будет уметь всё по чуть-чуть, и нигде не сможет достичь успеха. В этом такое представление губительно. Если на работу не взяли из-за того, что ты не знаешь, что такое Fossil, но знаешь, что такое Git, и при этом у тебя огромный опыт в разработке программ, которой занимается компания, это хорошо? Взяли вместо тебя человека с точно подходящим набором скиллов, но никак не разбирающимся в теме работы. Это плохое решение. Пример конечно утрированный, и HR закидали бы меня тухлыми помидорами. Почему? Потому что они как раз избегают применение общих шаблонов для собеседования и стараются подойти к человеку максимально индивидуально, оценивая его на основе его успехов в различных областях
Если сбер это обнаружат, знаете, какое будет решение бага? Новая акция: округляем баланс бонусов!
У этого фреймворка рендеринг настолько виртуальный, что он явно происходит где-то за пределами моего устройства, от чего я на их сайте вижу только белый экран. Но это такая фича, не волнуйтесь. Новейшая оптимизация, так сказать
Почему же, в данном утверждении автор прав. Иначе как объяснить пояаление монструозных серверных процессоров интел и АМД? Не проще разве натыкать кучу старых?) Конечно нет, ведь если связь между компонентами располагается на одном чипе, это НАМНОГО более производительно, чем связь отдельных чипов между собой. КПД как раз таки вырастет. Разумеется, есть ряд технических нюансов, и такое сравнение не совсем корректно из-за разных архитектур, но в общем случае всё так
Люди, вы забываете, насколько трудно внедрить новые технологии в большие компании. Чтобы перестроить все бизнес-процессы, нужно огромное количество временных и финансовых трат. А потом команда нейронок просто не сможет решить поставленную задачу, и всё))
Такие технологии скорее будут распространены среди стартапов или небольших компаний. Но мир пока совершенно не готов к такому
Сильно и резко спрос на айтишников не упадёт) чтобы перестроить все технологические процессы, потребуются годы, или даже десятилетия. Даже если бы сейчас уже была готова нейронка, которая способна выдать план разработки огромного сервиса, подобного гугл поиску, с возможностью интеграции с другими готовыми сервисами, как внутренними, так и внешними, проанализировать все зависимости, а также определить, какие команды нейронок ей нужны (включая нейронок-программистов, нейронок-дизайнеров, нейронок-тестировщиков и т.д.) и наладить всю коммуникацию, потребуется ОЧЕНЬ много времени для их настройки, отладки, сравнения с моделями-конкурентами. А ещё необходимо сформировать команду, которая будет ставить нейронкам (или главной нейронке) задачи, мониторить процесс разработки и проверять результаты тестирования и сам продукт
Это всё требует поистине гигантских финансовых трат. А потом найдётся задача, которую нейронки ещё не могут решить)) и всё это коту под хвост. Такие технологии будут использовать скорее стартапы, которые также без проблем смогут воспользоваться разработкой на аутсорсе
Могу поинтересоваться, какая конфигурация компьютера?
Предполагаю, vldF имел ввиду, что при операции list=tuple полное имя функции, которое видит компилятор, меняется. На деле это не так, т.к. list - ссылка. Это действительно нельзя так просто проверить
Самый большой недостаток чата гпт в том, что он не сможет реализовать по-настоящему большие проекты. Например, где куча микросервисов. Штук 20. Сделать под это клиентские приложения, которые состоят не из 2-3 скриптов, а с обширной файловой структурой. Написать для этого всего тесты. Сделать все микросервисы в виде докер контейнеров и развернуть это на сервере. Я вот не поедставляю, как такое через нейронку сделать. Можете попробовать)
Разве при appendElement перекомпоновка не происходит автоматом? Или добавлена оптимизация на такой случай?
Я искренне надеюсь, что автор не разочаруется в написании статей из-за бестактных комментаторов, вытащит всю необходимую информацию из фидбека, и продолжит развиваться и писать статьи. Желаю удачи!)
P.S. главная ошибка в том, что автор не указала, что это суперупрощённая схема, и что на самом деле механизм намного сложнее, особенно в плане взаимодействия с различными компонентами ОС. Так как для каждой ОС детали процесса могут отличаться, стоит абстрагироваться от этого взаимодействия и рассказать только о базовых процессах, происходящих в браузере. Ну и лучше сразу указать, что эта статья не для специалистов, которые и так всё знают)
А когда АМД разделяла бизнес? Я что-то пропустил?)
Обсуждая Линукс, очень часто затрагивают тему его GUI, в том числе оболочки gnome. Но я имел ввиду другое: Майкрософт сама выпустила свой фреймворк и сама сделала его важнейшим компонентом. В то время, как qt и python - языки, на которых хоть и написаны некоторые компоненты Линукс, они не созданы Линусом Торвальдсом и не сделаны главными компонентами линукса
switch - не процедурное наследие. Процедурное наследие - goto. Вот этот оператор реально может похерить code style) после него и появилось структурное программирование, в основе которого лежит утверждение: любую программу можно написать с помощью линейных переходов, условий и циклов. switch работает немного иначе, нежели goto с метками. И мне казалось, что switch появился позже, но тут могу ошибаться.
switch действительно можно избежать, но главный вопрос - целесообразность. Если это увеличит количество кода в разы, ещё и убавляя производительность (например, заменив его на какой-то класс), то сколько методов open/close не придерживайся, а код будет куда менее читабельным и его будет труднее редачить. Так что предлагаю сделать вывод: большие конструкции в switch действительно не стоит пихать, потому что это смотрится дико. Но для простых задач switch прекрасно подходит
Я вроде осознал главную мысль спора. WieRuindl считает, что switch - лишняя обёртка над вызовом соответствующего метода. Но это далеко не во всех случаях так. Например, есть метод получения количества дней в месяце, представленный GreyN. Этот код невозможно улучшить, switch идеально вписывается сюда. Так что предлагаю закончить дискуссию и принять, что бывают случаи, когда switch упрощает жизнь, но использовать его где попало - нельзя
Всегда нужно ставить вопрос целесообразности. Если класс выполняет одну единственную функцию и его не планируется расширять, а любое применение каких-то принципов усложняет код и увеличивает его количество в разы, то я считаю, что настольное применение каких-либо принципов - плохо. Принципы разработаны для общих случаев. Ну и безусловно, код должен быть красивым и читаемым