Видимо, автор вспомнил про 3proxy. Там действительно по дефолту стоит 3128. Но это самый нестабильный прокси сервер, который я когда-либо использовал. Сейчас нашел божественный докер-контейнер со сконфигурированным прокси сервером, изменяющимся через обычные environment переменные. Http завелось без танцев с бубном, с socks не было надобности, но подключаться не хотело. Он в первых строках поиска, так что кому надо - пользуйтесь. Бнз остановок крутится более 2х месяцев
Автор хотел сказать, что микросервисы - не антоним монолиту. Что под монолитом можно подразумевать разное. И если код разделён на слои, то, наверное, не очень корректно называть его монолитом. Но, очевидно, это - не микросервисы
Но тут автор не совсем прав, так как нужно всего лишь учитывать контекст. В контексте архитектуры сервиса вместо монолита правильнее употребить слова легаси код. А в контексте архитектуры всей системы - монолит и микросервисы
Не думаю, что рейтинги Хабра повысились бы от того, что он будет на собственном поддомене размещать рекламу уже чужого сервиса, и тем более делать на него редирект :) продать домен - одно, продать поддомен своего основного домена - принципиально другое. Не думаю, что Хабр хотел бы связать себя каким-либо образом с именем другой компании
Есть куча других вариантов. Но Хабр делает упор на конфиденциальность. Понятное дело, что нельзя угодить всем, поэтому передать данные конкретной компании довольно трудно и небезопасно. Поэтому их решение действительно универсальное и показывает заинтересованность в сохранении репутации. Лично я одобряю
Почему же. Взаимодействуют. У меня всё же не только скрейперы в проекте, помимо этого есть и другая логика. Но микросервисы по хорошему должны быть максимально изолированными друг от друга, так что я не понимаю, почему в случае отсутствия взаимодействия они станут "микромонолитами"
Меня очень расстраивает, что многие люди столь категоричны. Ничего просто так не бывает, у всего есть причина. Даже если что-то не нравится, это не значит, что это -- бесполезно. Не нравится -- не используйте, отдавайте предпочтение другим методам, но зачем ставить на этом крест?
Простейший пример, когда за счёт ООП можно очень хорошо сэкономить время:
Есть некая конфигурация некого процесса, сохранённая в словаре и в нескольких дополнительных переменных. Есть коннэкшн к БД. Практически все функции, представленные в данном процессе, используют подключение к БД. Во многих функциях дёргается конфигурация. Вопрос к автору: Вы правда собираетесь КАЖДОЙ функции передавать в качестве аргументов инстанс коннэкшна к БД? Или собираетесь следовать антипаттерну использования глобальных переменных? Да, можно весь конфиг объединить в структуру. В C без этого не обойтись. Но согласитесь, с ООП это банально удобнее. Один раз передали всё в конструкторе -- используем сколько угодно раз.
Это самый базовый пример. Давайте пробежимся по всем аргументам автора:
1) Собеседование. Давайте будем правдивы: то, что встречается на собеседовании, в жизни встречается очень редко. На собесах даются экзотические примеры на знание базовых особенностей языка и на знание основных алгоритмов. Поскольку в мире существует море библиотек, и поначалу мы пишем не самый сложный код, мы достаточно редко применяем эти знания. Поэтому, аргумент, который приведён самым первым, я считаю некорректным.
2) Из моего примера: допустим, у нас есть множество методов, подобных getDisplayName. Пусть это будет getFirstName, getLastName, getAbbr, getMiddleName, etc. Согласитесь, удобнее один раз создать объект, и далее вызывать у него методы, не передавая в них ничего. Но. Это не самый весомый контр-аргумент. Посмотрите на реализацию 1-й функции. Что вы видите? if (!user) return undefined. Ничего не смущает? Мы неоправданно используем совершенно лишний if. И это не всегда можно исправить статической типизацией: например, при использовании pointer мы должны проверять, не является ли он nullptr. Во втором примере мы просто должны передавать все параметры, что ОЧЕНЬ усложняет жизнь. Мы должны знать абсолютно все данные, хранящиеся в структуре, чтобы корректно это передать. Ошибку null pointer exception в данном контексте считаю неуместной. Уж лучше мы ОДИН раз проверим на null объект ВНЕ функции, чем КАЖДЫЙ раз будем проверять это внутри
3) Переопределение методов -- действительно добавляет возможностей выстрелить себе в ногу даже при большом опыте использования ООП. Банально по невнимательности. Но тем не менее это помогает избегать дополнительных проверок. В функциональном переопределении мы будем использовать if/switch. Это минус производительность. В ООП полиморфизм происходит как бы "неявно" засчёт как раз таки наследования
4) Наследование. Очевидно, не бывает универсальных решений. Для исправления описанных проблем есть соответствующие паттерны. Автор называет паттерны "костылями", но я бы назвал эти решения просто... решениями. В них нет ничего, бьющего по производительности и удобству
5) Полиморфизм: см. пункт 5
6) Шаблоны/паттерны: в жизни довольно редко используется большое количество шаблонов и паттернов. Существуют основы основ. Никто не говорил, что ООП -- просто)) Разумеется, есть свои сложности. Но тем не менее, это даёт множество бонусов. Никто не будет просто так создавать фабрики в обязательном порядке на все классы или BuilderOfBuilderOfBuilder. Нет. Это делается только при необходимости. Применение любого паттерна должно быть обосновано. Синглтон, как и многие другие паттерны, насколько я знаю, в последнее время не особо приветствуется. И вообще, чрезмерное использование паттернов влечёт за собой множество проблем. Всё зависит от задачи, всегда помните это
7) конструкторы: отчасти соглашусь, отчасти нет. Здесь всё зависит от задачи. Как впрочем, и в остальных случаях
8) Могу привести в пример прекрасную реализацию dependency injection в роутинге Laravel (попрошу не материться по этому поводу: PHP -- первый язык, с которого я начал свой долгий путь в IT)
9) сериализация. полностью согласен, хотя иногда бывают случаи, когда это помогает (например, не нужно добавлять в сериализацию некоторые поля)
10) в примере ООП, на мой взгляд, изначально не очень правильная архитектура. Логичнее было бы вынести логику обновления из класса User. Или же сделать что-то вроде метода save, который не вызывает метод класса, в котором хранится этот самый объект
11) несколько моделей. не вижу проблем
12) Конкурентность. Соглашусь, здесь могут возникнуть трудности или баги. Но всего этого помогает избежать опыт написания таких программ. Колоссальных проблем здесь не будет
Почему ООП зачастую не всегда именно "крутые инженеры"? Ответ прост: они более сосредоточены на удобстве написания кода, чем на тонкой технической реализации. На самом деле, с использованием большого количества абстракций действительно сложно написать код, который работает также быстро, как без их использования. Однако, с другой стороны, без использования большого количества абстракций, сложно написать одновременно большой и легкоподдерживаемый читабельный проект.
UPD: понял, о чём Вы. А разве нельзя использовать HTTP/1 только для одного запроса? Для установки соединения, очевидно, нет особого резона переходить на HTTP/2, так что вряд-ли вебсокеты будут работать с ним
Ну полно вам писать гневные комментарии. Человек попытался предложить нечто оригинальное, высказал своё мнение
Такой подход в изучении ЯП довольно спорный. Всё же в паре с sql следовало бы изучать скриптовый язык, например, python. Тогда проще воспринимать, где и когда изученнве запросы можно применить. А для этого, естественно, нужно знать базу языка
Я пробовал себя в роли "преподавателя", и со 2-3 занятия понял, что я не тяну это от соова совсем. Я не мог ответить на простой вопрос: "зачем?". Зачем мы выводим Hello, world? Зачем мы делаем вывод ста последовательных чисел в цикле? Ради примера? А где мы дальше будем такое применять? После попыток объяснить, что пока не могу дать реальный пример использования этих конструкций, мои ученики просто теряли интерес. Я понял, что для изучения языка нужны живые примеры, которые можно "пощупать" и "прочувствовать". В случае с изучением sql в самом начале будет очень трудно объяснить человеку, зачем мы храним данные в "коробочке под названием БД" на каком-то сервере и потом делаем сложные непонятные запросы, чтобы их оттуда достать.
Так что точку зрения автора я не могу разделить. Если человек начинает изучение с абсолютного нуля - нужно изучать что-то проще и нагляднее, а потом углубляться в дебри (я сам вообще начинал с php, и это было наглядно настолько, что в свои 11 лет я прекрасно понимал суть)
Entrypoint = точка входа, а то, что передаётся в CMD, "добавляется" к entrypoint. Так что корректное завершение работы контейнера будет (exit with 0 status). Вы, возможно, путаете с RUN - вот это действительно предварительная настройка. Точнее, каждая команда RUN создаёт новый слой собираемого образа
Я понимаю негодование юных программистов. Они только открывают для себя истину: мир несправедлив. Поверьте, такое происходит не только в айти. Такое происходит везде. Hr физически не может просмотреть все вакансии. Поэтому, как в статье и писалось, он использует фильтры. Все кандидаты, не подходящие под заданны фильтр, он просто не видит. Разумеется, отказ на них не приходит. Виноваты разработчики hh.ru, а не hr'ы) разумеется, у людей, не подошедших под фильтры, резюме они также не смотрят. И я почти уверен, что обо всех применённых фильтрах мы даже не догадываемся. Это печально, но это факт
Отдельно хотелось бы спросить про пункт, в котором говорится о неправильном порядке абзацев в резюме. Это что за дикость такая?) Я понимаю, что резюме должно быть оформлено по шаблону, но если hr чего-то в резюме не увидит - он скорее всего просто откажет со стандартным сообщением. Я никак не могу представить ситуацию, в которой hr применил фильтры, открыл профиль, посмотрел резюме, и такой: "фу, неправильно написано, не буду смотреть", но при этом он очень принципиальный, и обязательно хочет сообщить об этом неудачливому кандидату)) мне просто интересно, реально такая ситуация возникла, или я что-то не так понял?
Про навыки джунов. Боюсь разочаровать, но в современном IT-мире в большинстве случаев джуны - исполнители. Они не должны и не могут думать про общую структуру, не могут сами интерпретировать задачи. Джунам говорят: отредактируй такую-то функцию, исправь такую-то ошибку в таком-то модуле, добавь такую-то функцию вот сюда. И так далее. Они не смотрят логи на проде (в большинстве случаев), не мониторт состояние системы. Поэтому от него требуют знания базы программирования. Он должен знать алгоритмы, обязательно. Потому что именно их он поначалу и будет писать. Если он возьмёт и создаст функцию с асимптотической сложностью О(n^3), в то время, как модно сделать за O(nlogn), то это создаст проблемы. Но это не критично - можно сказать, что тут сделано не очень качественно, нужно переделать с использованием такого-то алгоритма и подучить эту часть. Но если джун будет говорить, что это вообще что-то непонятное, почему вы от меня такое требуете - скажите, хороший кандидат будет? Чтобы таких проблем не возникало, да, у всех джунов спрашивают алгоритмы, самую базу, и её важно и нужно знать. Не для собесов - для себя.
Но собес - не зубрёжка. От зубрежки здесь только знание алгоритмов (да и то, их мало зазубрить - их надо понять и осознать, почему сделано именно так и когда их нужно применять). Все остальные вопросы - на рассуждение. Я читал прекрасный пост на хабре, в котором hr вырвжал глубочайшее сожаление по поводу того, что к нему приходят люди, которые просто заучили ответы на все вопросы. HR смотрит на то, как вы рассуждаете. Это самый важный навык в жизни, во всех профессиях. Если вы не умеете рассуждать, как сделать ту или иную задачу - не важно, знаете ли вы решение или нет - вы не готовы к подобным задачам
P.S. ни в коем случае не хочу никого обидеть. Если в чем-то не прав - пишите, поправляйте, самому интересно
Как раз таки с alpine бывает много нюансов. В основном из-за того, что в нём сильно порезаны библиотеки и используется своя реализация стандартной библиотеки C - musl. Я, например, знаком с тем, что при установке python-пакетов они не компилировались в байт-код из-за отсутствия glibc, как на других дистрибутивах, из-за чего производительность сильно проседала (на эту тему на хабре есть статья; сейчас такое поведение вроде пофиксили, но всё равно будьте осторожны). Уверен, есть ещё множество нюансов. Но реальность такова, что для большинства проектов полный функционал не требуется, и alpine будет вполне достаточно.
Если берёте уже нужным образом упакованный образ, например, nginx:alpine, или php:X.X-fpm-alpine, я считаю, что им можно пользоваться в большинстве случаев, если не собираетесь устанавливать туда что-то специфическое. А вот для python-проектов, где критически важна производительность, лучше проверить, скомпилировались ли установленные пакеты. Пока это единственное, с чем я сталкивался
P.S. ну вот, только это написал, попробовал mongo-driver через pecl установить на php-fpm-alpine. Результат - ошибка автосборки в следствие отсутствия пакетов build-essential, в комплекте с которым идёт gcc... Думаю, это всё можно пофиксить, но тогда итоговый размер alpine будет не сильно меньше аналогичного deb-образа
Могу предложить, что комментатор ввиду, например, картинки/видео и др. В python backend реально почти не сталкивался с этим) но из опыта разработки на Java и php могу сказать, что папка res/ обычно располагается в корне проекта, а ресурсы в ней разделены либо по типам (res/documents, res/images), либо по тематике (например, res/pages/contact, res/uploads/hdjdjehhd.pdf) в зависимости от приложения. Если это игра, то проще разделять по типам. Если проект большой - по тематике. Это из личного опыта, если кто не согласен, или в питоне другие правила - пишите, самому интересно
Но не все же вопросы можно отдавать AI, верно?) я занимался разработкой подобных систем без искусственного интеллекта. то есть составление заказа через telegram: просмотр списка услуг, списка цен, выбор, просмотр описания, заказ, оплата и т.д. в ТГ можно легко составить очень красивое презентабельное меню с использованием красивых символов (я, честно, был поражен до глубины души тем, НАСКОЛЬКО красиво это можно оформить; будет интересно - скину пару примеров). Всё. В таком варианте безо всякого AI это уже полноценный сервис. Минималистичный, понятный. Может не идеально-наглядный. Но удобный. Зачем здесь AI? Честно - не знаю. Мне кажется, здесь это излишне. Разве что для имитации бармена. Типа для ответа на вопросы: "посоветуйте мне что-то не сильно крепкое", или "есть ли у вас что-то без кедровых орехов? У меня на них аллергия". Или же в качестве менеджера ("где мой заказ? Я жду уже 20 минут!"). Всё. Это закрывает все потребности, в том числе и потребность в постоянной поддержке по поводу заказов. И да, если нужны сложные визуализации, можно просто прислать красивую ссылку на сайт
Спасибо, статья интересная) Подскажите пожалуйста, а можно ли с использованием Vue установить обработчики событий на все элементы с некоторым классом? Почему-то нигде не могу найти информацию по этому поводу
Аналог в JQuery:
$('.classA').click(() => { /* Do something... */ });
Не, возможно, в далёком-далеком будущем, лет через 100, у всех приложений на любые устройства будет единый апи взаимодействия с системой, при котором приложения могут взаимодействовать друг с другом (я имею ввиду например то, что нельзя из одного приложения нажать кнопочку в окошке другого без автокликера, или, как было сказано выше, нельзя получить из условного приложения кошелек карту пятерочки), а ИИ научится отправлять запросы на эндпоинты по заданным схемам, и вот тогда может появиться суперприложение-менеджер других приложений с искусственным интеллектом. Но не раньше
На всякий случай - uvicorn с опцией --reload потребляет очень много ресурсов и может тормозить, о чём говорится прям в документации) поэтому использовать на проде крайне не рекомендуется (можно в том случае, если ресурсов предостаточно, или высокая производительность не требуется)
Видимо, автор вспомнил про 3proxy. Там действительно по дефолту стоит 3128. Но это самый нестабильный прокси сервер, который я когда-либо использовал. Сейчас нашел божественный докер-контейнер со сконфигурированным прокси сервером, изменяющимся через обычные environment переменные. Http завелось без танцев с бубном, с socks не было надобности, но подключаться не хотело. Он в первых строках поиска, так что кому надо - пользуйтесь. Бнз остановок крутится более 2х месяцев
Автор хотел сказать, что микросервисы - не антоним монолиту. Что под монолитом можно подразумевать разное. И если код разделён на слои, то, наверное, не очень корректно называть его монолитом. Но, очевидно, это - не микросервисы
Но тут автор не совсем прав, так как нужно всего лишь учитывать контекст. В контексте архитектуры сервиса вместо монолита правильнее употребить слова легаси код. А в контексте архитектуры всей системы - монолит и микросервисы
Не думаю, что рейтинги Хабра повысились бы от того, что он будет на собственном поддомене размещать рекламу уже чужого сервиса, и тем более делать на него редирект :) продать домен - одно, продать поддомен своего основного домена - принципиально другое. Не думаю, что Хабр хотел бы связать себя каким-либо образом с именем другой компании
Есть куча других вариантов. Но Хабр делает упор на конфиденциальность. Понятное дело, что нельзя угодить всем, поэтому передать данные конкретной компании довольно трудно и небезопасно. Поэтому их решение действительно универсальное и показывает заинтересованность в сохранении репутации. Лично я одобряю
Почему же. Взаимодействуют. У меня всё же не только скрейперы в проекте, помимо этого есть и другая логика. Но микросервисы по хорошему должны быть максимально изолированными друг от друга, так что я не понимаю, почему в случае отсутствия взаимодействия они станут "микромонолитами"
Меня очень расстраивает, что многие люди столь категоричны. Ничего просто так не бывает, у всего есть причина. Даже если что-то не нравится, это не значит, что это -- бесполезно. Не нравится -- не используйте, отдавайте предпочтение другим методам, но зачем ставить на этом крест?
Простейший пример, когда за счёт ООП можно очень хорошо сэкономить время:
Есть некая конфигурация некого процесса, сохранённая в словаре и в нескольких дополнительных переменных. Есть коннэкшн к БД. Практически все функции, представленные в данном процессе, используют подключение к БД. Во многих функциях дёргается конфигурация.
Вопрос к автору: Вы правда собираетесь КАЖДОЙ функции передавать в качестве аргументов инстанс коннэкшна к БД? Или собираетесь следовать антипаттерну использования глобальных переменных? Да, можно весь конфиг объединить в структуру. В C без этого не обойтись. Но согласитесь, с ООП это банально удобнее. Один раз передали всё в конструкторе -- используем сколько угодно раз.
Это самый базовый пример. Давайте пробежимся по всем аргументам автора:
1) Собеседование. Давайте будем правдивы: то, что встречается на собеседовании, в жизни встречается очень редко. На собесах даются экзотические примеры на знание базовых особенностей языка и на знание основных алгоритмов. Поскольку в мире существует море библиотек, и поначалу мы пишем не самый сложный код, мы достаточно редко применяем эти знания. Поэтому, аргумент, который приведён самым первым, я считаю некорректным.
2) Из моего примера: допустим, у нас есть множество методов, подобных getDisplayName. Пусть это будет getFirstName, getLastName, getAbbr, getMiddleName, etc. Согласитесь, удобнее один раз создать объект, и далее вызывать у него методы, не передавая в них ничего. Но. Это не самый весомый контр-аргумент. Посмотрите на реализацию 1-й функции. Что вы видите? if (!user) return undefined. Ничего не смущает? Мы неоправданно используем совершенно лишний if. И это не всегда можно исправить статической типизацией: например, при использовании pointer мы должны проверять, не является ли он nullptr. Во втором примере мы просто должны передавать все параметры, что ОЧЕНЬ усложняет жизнь. Мы должны знать абсолютно все данные, хранящиеся в структуре, чтобы корректно это передать.
Ошибку null pointer exception в данном контексте считаю неуместной. Уж лучше мы ОДИН раз проверим на null объект ВНЕ функции, чем КАЖДЫЙ раз будем проверять это внутри
3) Переопределение методов -- действительно добавляет возможностей выстрелить себе в ногу даже при большом опыте использования ООП. Банально по невнимательности. Но тем не менее это помогает избегать дополнительных проверок. В функциональном переопределении мы будем использовать if/switch. Это минус производительность. В ООП полиморфизм происходит как бы "неявно" засчёт как раз таки наследования
4) Наследование. Очевидно, не бывает универсальных решений. Для исправления описанных проблем есть соответствующие паттерны. Автор называет паттерны "костылями", но я бы назвал эти решения просто... решениями. В них нет ничего, бьющего по производительности и удобству
5) Полиморфизм: см. пункт 5
6) Шаблоны/паттерны: в жизни довольно редко используется большое количество шаблонов и паттернов. Существуют основы основ. Никто не говорил, что ООП -- просто)) Разумеется, есть свои сложности. Но тем не менее, это даёт множество бонусов. Никто не будет просто так создавать фабрики в обязательном порядке на все классы или BuilderOfBuilderOfBuilder. Нет. Это делается только при необходимости. Применение любого паттерна должно быть обосновано. Синглтон, как и многие другие паттерны, насколько я знаю, в последнее время не особо приветствуется. И вообще, чрезмерное использование паттернов влечёт за собой множество проблем. Всё зависит от задачи, всегда помните это
7) конструкторы: отчасти соглашусь, отчасти нет. Здесь всё зависит от задачи. Как впрочем, и в остальных случаях
8) Могу привести в пример прекрасную реализацию dependency injection в роутинге Laravel (попрошу не материться по этому поводу: PHP -- первый язык, с которого я начал свой долгий путь в IT)
9) сериализация. полностью согласен, хотя иногда бывают случаи, когда это помогает (например, не нужно добавлять в сериализацию некоторые поля)
10) в примере ООП, на мой взгляд, изначально не очень правильная архитектура. Логичнее было бы вынести логику обновления из класса User. Или же сделать что-то вроде метода save, который не вызывает метод класса, в котором хранится этот самый объект
11) несколько моделей. не вижу проблем
12) Конкурентность. Соглашусь, здесь могут возникнуть трудности или баги. Но всего этого помогает избежать опыт написания таких программ. Колоссальных проблем здесь не будет
Почему ООП зачастую не всегда именно "крутые инженеры"? Ответ прост: они более сосредоточены на удобстве написания кода, чем на тонкой технической реализации. На самом деле, с использованием большого количества абстракций действительно сложно написать код, который работает также быстро, как без их использования. Однако, с другой стороны, без использования большого количества абстракций, сложно написать одновременно большой и легкоподдерживаемый читабельный проект.
Итог: всё зависит от конкретных задач)
Думаю, дело в apache...
UPD: понял, о чём Вы. А разве нельзя использовать HTTP/1 только для одного запроса? Для установки соединения, очевидно, нет особого резона переходить на HTTP/2, так что вряд-ли вебсокеты будут работать с ним
Ну полно вам писать гневные комментарии. Человек попытался предложить нечто оригинальное, высказал своё мнение
Такой подход в изучении ЯП довольно спорный. Всё же в паре с sql следовало бы изучать скриптовый язык, например, python. Тогда проще воспринимать, где и когда изученнве запросы можно применить. А для этого, естественно, нужно знать базу языка
Я пробовал себя в роли "преподавателя", и со 2-3 занятия понял, что я не тяну это от соова совсем. Я не мог ответить на простой вопрос: "зачем?". Зачем мы выводим Hello, world? Зачем мы делаем вывод ста последовательных чисел в цикле? Ради примера? А где мы дальше будем такое применять? После попыток объяснить, что пока не могу дать реальный пример использования этих конструкций, мои ученики просто теряли интерес. Я понял, что для изучения языка нужны живые примеры, которые можно "пощупать" и "прочувствовать". В случае с изучением sql в самом начале будет очень трудно объяснить человеку, зачем мы храним данные в "коробочке под названием БД" на каком-то сервере и потом делаем сложные непонятные запросы, чтобы их оттуда достать.
Так что точку зрения автора я не могу разделить. Если человек начинает изучение с абсолютного нуля - нужно изучать что-то проще и нагляднее, а потом углубляться в дебри (я сам вообще начинал с php, и это было наглядно настолько, что в свои 11 лет я прекрасно понимал суть)
Entrypoint = точка входа, а то, что передаётся в CMD, "добавляется" к entrypoint. Так что корректное завершение работы контейнера будет (exit with 0 status). Вы, возможно, путаете с RUN - вот это действительно предварительная настройка. Точнее, каждая команда RUN создаёт новый слой собираемого образа
Я понимаю негодование юных программистов. Они только открывают для себя истину: мир несправедлив. Поверьте, такое происходит не только в айти. Такое происходит везде. Hr физически не может просмотреть все вакансии. Поэтому, как в статье и писалось, он использует фильтры. Все кандидаты, не подходящие под заданны фильтр, он просто не видит. Разумеется, отказ на них не приходит. Виноваты разработчики hh.ru, а не hr'ы) разумеется, у людей, не подошедших под фильтры, резюме они также не смотрят. И я почти уверен, что обо всех применённых фильтрах мы даже не догадываемся. Это печально, но это факт
Отдельно хотелось бы спросить про пункт, в котором говорится о неправильном порядке абзацев в резюме. Это что за дикость такая?) Я понимаю, что резюме должно быть оформлено по шаблону, но если hr чего-то в резюме не увидит - он скорее всего просто откажет со стандартным сообщением. Я никак не могу представить ситуацию, в которой hr применил фильтры, открыл профиль, посмотрел резюме, и такой: "фу, неправильно написано, не буду смотреть", но при этом он очень принципиальный, и обязательно хочет сообщить об этом неудачливому кандидату)) мне просто интересно, реально такая ситуация возникла, или я что-то не так понял?
Про навыки джунов. Боюсь разочаровать, но в современном IT-мире в большинстве случаев джуны - исполнители. Они не должны и не могут думать про общую структуру, не могут сами интерпретировать задачи. Джунам говорят: отредактируй такую-то функцию, исправь такую-то ошибку в таком-то модуле, добавь такую-то функцию вот сюда. И так далее. Они не смотрят логи на проде (в большинстве случаев), не мониторт состояние системы. Поэтому от него требуют знания базы программирования. Он должен знать алгоритмы, обязательно. Потому что именно их он поначалу и будет писать. Если он возьмёт и создаст функцию с асимптотической сложностью О(n^3), в то время, как модно сделать за O(nlogn), то это создаст проблемы. Но это не критично - можно сказать, что тут сделано не очень качественно, нужно переделать с использованием такого-то алгоритма и подучить эту часть. Но если джун будет говорить, что это вообще что-то непонятное, почему вы от меня такое требуете - скажите, хороший кандидат будет? Чтобы таких проблем не возникало, да, у всех джунов спрашивают алгоритмы, самую базу, и её важно и нужно знать. Не для собесов - для себя.
Но собес - не зубрёжка. От зубрежки здесь только знание алгоритмов (да и то, их мало зазубрить - их надо понять и осознать, почему сделано именно так и когда их нужно применять). Все остальные вопросы - на рассуждение. Я читал прекрасный пост на хабре, в котором hr вырвжал глубочайшее сожаление по поводу того, что к нему приходят люди, которые просто заучили ответы на все вопросы. HR смотрит на то, как вы рассуждаете. Это самый важный навык в жизни, во всех профессиях. Если вы не умеете рассуждать, как сделать ту или иную задачу - не важно, знаете ли вы решение или нет - вы не готовы к подобным задачам
P.S. ни в коем случае не хочу никого обидеть. Если в чем-то не прав - пишите, поправляйте, самому интересно
Пойду тимлиду скажу про это правило. Будем внедрять его вместо недельных спринтов
Как раз таки с alpine бывает много нюансов. В основном из-за того, что в нём сильно порезаны библиотеки и используется своя реализация стандартной библиотеки C - musl. Я, например, знаком с тем, что при установке python-пакетов они не компилировались в байт-код из-за отсутствия glibc, как на других дистрибутивах, из-за чего производительность сильно проседала (на эту тему на хабре есть статья; сейчас такое поведение вроде пофиксили, но всё равно будьте осторожны). Уверен, есть ещё множество нюансов. Но реальность такова, что для большинства проектов полный функционал не требуется, и alpine будет вполне достаточно.
Если берёте уже нужным образом упакованный образ, например, nginx:alpine, или php:X.X-fpm-alpine, я считаю, что им можно пользоваться в большинстве случаев, если не собираетесь устанавливать туда что-то специфическое. А вот для python-проектов, где критически важна производительность, лучше проверить, скомпилировались ли установленные пакеты. Пока это единственное, с чем я сталкивался
P.S. ну вот, только это написал, попробовал mongo-driver через pecl установить на php-fpm-alpine. Результат - ошибка автосборки в следствие отсутствия пакетов build-essential, в комплекте с которым идёт gcc... Думаю, это всё можно пофиксить, но тогда итоговый размер alpine будет не сильно меньше аналогичного deb-образа
Говорите, "25"+10=30 - это хорошо, а потом советуете python?) Ха!
P.S. не путайте строгую и статическую типизации
Могу предложить, что комментатор ввиду, например, картинки/видео и др. В python backend реально почти не сталкивался с этим) но из опыта разработки на Java и php могу сказать, что папка res/ обычно располагается в корне проекта, а ресурсы в ней разделены либо по типам (res/documents, res/images), либо по тематике (например, res/pages/contact, res/uploads/hdjdjehhd.pdf) в зависимости от приложения. Если это игра, то проще разделять по типам. Если проект большой - по тематике. Это из личного опыта, если кто не согласен, или в питоне другие правила - пишите, самому интересно
Но не все же вопросы можно отдавать AI, верно?) я занимался разработкой подобных систем без искусственного интеллекта. то есть составление заказа через telegram: просмотр списка услуг, списка цен, выбор, просмотр описания, заказ, оплата и т.д. в ТГ можно легко составить очень красивое презентабельное меню с использованием красивых символов (я, честно, был поражен до глубины души тем, НАСКОЛЬКО красиво это можно оформить; будет интересно - скину пару примеров). Всё. В таком варианте безо всякого AI это уже полноценный сервис. Минималистичный, понятный. Может не идеально-наглядный. Но удобный. Зачем здесь AI? Честно - не знаю. Мне кажется, здесь это излишне. Разве что для имитации бармена. Типа для ответа на вопросы: "посоветуйте мне что-то не сильно крепкое", или "есть ли у вас что-то без кедровых орехов? У меня на них аллергия". Или же в качестве менеджера ("где мой заказ? Я жду уже 20 минут!"). Всё. Это закрывает все потребности, в том числе и потребность в постоянной поддержке по поводу заказов. И да, если нужны сложные визуализации, можно просто прислать красивую ссылку на сайт
Спасибо, статья интересная) Подскажите пожалуйста, а можно ли с использованием Vue установить обработчики событий на все элементы с некоторым классом? Почему-то нигде не могу найти информацию по этому поводу
Аналог в JQuery:
Не, возможно, в далёком-далеком будущем, лет через 100, у всех приложений на любые устройства будет единый апи взаимодействия с системой, при котором приложения могут взаимодействовать друг с другом (я имею ввиду например то, что нельзя из одного приложения нажать кнопочку в окошке другого без автокликера, или, как было сказано выше, нельзя получить из условного приложения кошелек карту пятерочки), а ИИ научится отправлять запросы на эндпоинты по заданным схемам, и вот тогда может появиться суперприложение-менеджер других приложений с искусственным интеллектом. Но не раньше
На всякий случай - uvicorn с опцией --reload потребляет очень много ресурсов и может тормозить, о чём говорится прям в документации) поэтому использовать на проде крайне не рекомендуется (можно в том случае, если ресурсов предостаточно, или высокая производительность не требуется)
Неужели мой коммент к предыдущей статье прочитали?)
Теперь давайте прокинем в docker образ X-11 сервер, и будет вообще конфетка
UPD: простите за дизинфу, на самом деле мне помогла команда xhost +local:
С ней всё работает на ура и без редактирования YML конфига))