Да, простите, душню. Понимаю что поздновато пришел, просто меня сама тема зацепила. изначально сел с квестом "а как бы сделать все покомпактнее", сделал, а потом решил погуглить кто еще таким занимался.
В обоих случаях ленивость не нужна. Wsgi можно просто убрать вообще, и вызвать get_wsgi_application сразу из gunicorn. А в urlpatterns ленивость в данном случае тоже не нужна. У него тут одно ограничение - он должен быть hashable( as_view без сайдэффектов), так что если список заменить на кортеж, все заработает без ленивости.
Однако, конечно если захочется админку завести, то тут ленивость придется добавить, но этот способ уже не подойдет.
Полагаю это просто бардак, или собесы в разные команды/по разным стекам. Или и то и то Я собеседовался в Т, тоже было прошел штук 10-15 собеседований. Сначала на архитектора 3 штуки. Не мое, но предложили, чего бы не попробовать. Не сложилось - тогда на разраба 3 штуки, оверквалифайд, на тимлида 1-2, снова оверквалифайд, на юнит лида вроде одно и дальше знакомство с командами штук 5 разных. Развлечение на несколько месяцев, и впустую. Но я не жалуюсь лучше так, чем попасть в команду в которую ты не подходишь, или не ту позицию. Но в итоге вот те самые штук 15 собесов - пока к позиции примерились, пока к команде, вот и набежало.
Был опыт в не очень известную компанию, больше 30 часов собеседований на руководящую должность. Но это уже история про собеседования переходящие в онбординг, и это прямо идеально. А вот рассказы про "о боже два этапа на руководителя" это ну прямо смешно.
Выхолащивание подразумевает, что их стало меньше. Как менеджер, скажу что все же, компетенций стало несколько больше. Однако, все еще драматически мало.
Что изменилось, так это потихоньку приходит понимание это факта. Лет 10 назад о таком даже не думали.
Это не вопрос личного мнения. Качается тот навык, который вы практикуете. Читая книги вы практикуете навык чтения книг. Информация - да, ее из книг подчерпнуть можно. Но это знания, а не навыки. Они могут улучшить навыки, но только при условии, если они тут же применяются на практике, к которой прилагается эффективная обратная связь. Потому что, спойлер, когда они будут применены, они будут применены неправильно - ведь нет достаточного навыка, а значит должен быть механизм коррекции. Другими словами, чтение книг поможет, только если оно прилагается к эффективному обучению. А просто читать книги - это абсолютно нерабочий совет. Приблизительно как "вы голодны? Почитайте книгу по кулинарии".
А "среднестатистический работник" это кто? Разработчик, тестировщик, менеджер? На каком стеке? В какой отрасли? С каким опытом работы в какой компании? С какой квалификацией? Хард-софт скилы? Удаленка/офис? Регион/Столица? Все же очень отличается - кто-то хайлоад делает, кто-то круды перекладывает, а кто-то вообще на 1С пишет. Кто-то в отрасли 20 лет, а кто-то 1 год. Вот например есть такое мнение о среднестатистическом разработчике (прямиком из бигтеха) https://t.me/ITBizRadio_chat/3830 А для меня вот наоборот - потому что вокруг меня другие люди. А так в отрасли всякие есть, биоразнообразие.
Сам нанимаю в данный момент, в том самом топе айти контор. И могу сказать, что многие кто работают лидами в итоге на собеседовании показывают посредственные результаты, и как следствие - соответствующие офферы. Хорошие офферы есть, в том числе и в указанные выше суммы. Но получают их не только лишь все. Кто-то получает офферы из диапазона, который вы указали. Оба имеют место быть. Зависит от квалификации... и интервьювера. С наймом все не простт :)
Так что я бы, исходя из своего опыта, из того что человеку стабильно больше 350 за лида не дают, сделал бы вывод, что стоит, видимо, что-то подтянуть, а не на рынок пенять. Больше получить можно совершенно точно. Но не просто - такой запрос должен быть соответственно подкреплен.
Подход замечательный, но тут, как водится есть много нюансов. И с массивами их прямо много. Для того чтобы это работало быстро, нужны следующие, не указанные в статье условия:
1. Данных должно быть немного, либо вам не нужно делать по ним поиск. Почему - для списков кликхаус не строит файл засечек, и не имеет встроенных механизмов поддержания упорядоченности и алгоритма бинарного поиска по массиву. Переход на массивы поднимает сложность поиска до линейной (перебор массива в лоб). При малых выборках это не страшно, и может работать эффективнее, но если у вас в массиве хотя бы десятки тысяч записей, это будет проблемой (засечки работают обычно от 8к).
2. У вас должна быть возможность хранить такой массив в MergeTree или ReplacingMergeTree, т.е. вы записываете его один раз и не дополняете, либо перезаписываете целиком, и при этом его сортируете (руками). Дело в том, что данные хранятся на диске сжато, а сортированные данные сжимаются гораздо лучше. Поэтому плоские таблицы без массивов всегда упорядочены и хорошо жмуться. Если ваш массив будет неупорядочен, он будет занимать существенно больше места на диске. А чтение с диска самая медленная операция. Что вместе с предыдущим (нет засечек, и массив всегда читается весь) может оказать драматически негативный эффект на производительность. Т.е. эффективно будет работать, только если вы этот массив руками записываете - если использовать AggregatingMergeTree, то в нем нет simple аггрегации массивов с сортировкой и/или дедупликацией. И там варианты либо не сортированный массив(который плохо жмется), либо аггрегационный тип хранилища, который еще больше занимает места и требует дообработки (и будет еще медленнее). Могут еще и дубликаты пробегать.
3. Данных в массиве не больше 1млн штук. Это вроде бы по документации лимит массива. Для большинства задач этого достаточно, но стоит всегда об этом помнить, чтобы внезапно не упереться, и не обнаружить что массивы совсем не подходят и все надо переделывать. В статье об этом сказано, но не указано число.
При этом, если вы ни под одно из этих ограничений не попадаете, можно действительно получить существенный прирост к производительности (я вроде бы до x2 выжимал) и потреблению ресурсов (CPU и память). Но если они у вас есть - эффект будет противоположный.
К сожалению даже когда подвезут - ее надо довольно круто допиливать напильником, чтобы асинхронность в ней не тормозила. Реализовали ее весьма так себе.
Например задавать уточняющие вопросы. Пока вы задаете вопросы исключено в формате, почему мы делаем ту дичь, что из вашей собственной головы вылезает. Если вы будете задавать уточняющие вопросы по оригинальным вводным, а не по тем, которые вы сами придумали, получится совсем другой разговор.
Теперь вы придумали, что мы разговаривали с peer коллегами. И что интересно, в обоих сценариях, которые вы сами придумываете, мы всегда творим какую то дичь.
Знаете такую штуку на собеседованиях, как проекционные вопросы?
Во-первых, вы не ответили на мои вопросы, и уже задаете свои. Если вы потрудитесь дать на них ответы, возможно поймете что ваши новые - просто лишены смысла. Вы меня расспрашиваете о звонке руководителю, который сами придумали.
Да, простите, душню. Понимаю что поздновато пришел, просто меня сама тема зацепила. изначально сел с квестом "а как бы сделать все покомпактнее", сделал, а потом решил погуглить кто еще таким занимался.
Я про эти части
wsgi =lambdaargs,*kwargs: get_wsgi_application()(*args, **kwargs)urlpatterns = SimpleLazyObject(lambda:[path('users/<pk>/',view.as_view()])В обоих случаях ленивость не нужна.
Wsgi можно просто убрать вообще, и вызвать get_wsgi_application сразу из gunicorn.
А в urlpatterns ленивость в данном случае тоже не нужна. У него тут одно ограничение - он должен быть hashable( as_view без сайдэффектов), так что если список заменить на кортеж, все заработает без ленивости.
Однако, конечно если захочется админку завести, то тут ленивость придется добавить, но этот способ уже не подойдет.
На самом деле можно еще короче и лаконичнее. Все эти ленивые загрузки и лямбды на самом деле не нужны.
И
Ненавязчивый смолл толк!
Похоже вы изобрели gunicorn.
Полагаю это просто бардак, или собесы в разные команды/по разным стекам. Или и то и то
Я собеседовался в Т, тоже было прошел штук 10-15 собеседований.
Сначала на архитектора 3 штуки. Не мое, но предложили, чего бы не попробовать. Не сложилось - тогда на разраба 3 штуки, оверквалифайд, на тимлида 1-2, снова оверквалифайд, на юнит лида вроде одно и дальше знакомство с командами штук 5 разных. Развлечение на несколько месяцев, и впустую. Но я не жалуюсь лучше так, чем попасть в команду в которую ты не подходишь, или не ту позицию. Но в итоге вот те самые штук 15 собесов -
пока к позиции примерились, пока к команде, вот и набежало.
Был опыт в не очень известную компанию, больше 30 часов собеседований на руководящую должность. Но это уже история про собеседования переходящие в онбординг, и это прямо идеально.
А вот рассказы про "о боже два этапа на руководителя" это ну прямо смешно.
https://habr.com/ru/articles/882030/#comment_27919474
Вот тут пишут про 15, и в сабже про то, что добавили еще одну. 15, видимо, мало.
И аж целых два этапа собеседований! Кошмар, отдельное техническое собеседование, а потом аж общение с менеджером!
Стало слишком много этапов, потому что это рынок работодателя.
Где то в это время нервно курит в стороне собеседование на разраба в Яндекс.
Выхолащивание подразумевает, что их стало меньше. Как менеджер, скажу что все же, компетенций стало несколько больше. Однако, все еще драматически мало.
Что изменилось, так это потихоньку приходит понимание это факта. Лет 10 назад о таком даже не думали.
Это не вопрос личного мнения.
Качается тот навык, который вы практикуете. Читая книги вы практикуете навык чтения книг.
Информация - да, ее из книг подчерпнуть можно. Но это знания, а не навыки. Они могут улучшить навыки, но только при условии, если они тут же применяются на практике, к которой прилагается эффективная обратная связь. Потому что, спойлер, когда они будут применены, они будут применены неправильно - ведь нет достаточного навыка, а значит должен быть механизм коррекции.
Другими словами, чтение книг поможет, только если оно прилагается к эффективному обучению. А просто читать книги - это абсолютно нерабочий совет. Приблизительно как "вы голодны? Почитайте книгу по кулинарии".
Вот только проблема, чтение книг по психологии(как и любых других) развивает только один навык - навык чтения, а не того, что предполагается в статье.
А "среднестатистический работник" это кто? Разработчик, тестировщик, менеджер? На каком стеке? В какой отрасли? С каким опытом работы в какой компании? С какой квалификацией? Хард-софт скилы? Удаленка/офис? Регион/Столица? Все же очень отличается - кто-то хайлоад делает, кто-то круды перекладывает, а кто-то вообще на 1С пишет. Кто-то в отрасли 20 лет, а кто-то 1 год.
Вот например есть такое мнение о среднестатистическом разработчике (прямиком из бигтеха) https://t.me/ITBizRadio_chat/3830
А для меня вот наоборот - потому что вокруг меня другие люди. А так в отрасли всякие есть, биоразнообразие.
Сам нанимаю в данный момент, в том самом топе айти контор. И могу сказать, что многие кто работают лидами в итоге на собеседовании показывают посредственные результаты, и как следствие - соответствующие офферы. Хорошие офферы есть, в том числе и в указанные выше суммы. Но получают их не только лишь все. Кто-то получает офферы из диапазона, который вы указали. Оба имеют место быть. Зависит от квалификации... и интервьювера. С наймом все не простт :)
Так что я бы, исходя из своего опыта, из того что человеку стабильно больше 350 за лида не дают, сделал бы вывод, что стоит, видимо, что-то подтянуть, а не на рынок пенять. Больше получить можно совершенно точно. Но не просто - такой запрос должен быть соответственно подкреплен.
Подход замечательный, но тут, как водится есть много нюансов. И с массивами их прямо много.
Для того чтобы это работало быстро, нужны следующие, не указанные в статье условия:
1. Данных должно быть немного, либо вам не нужно делать по ним поиск.
Почему - для списков кликхаус не строит файл засечек, и не имеет встроенных механизмов поддержания упорядоченности и алгоритма бинарного поиска по массиву. Переход на массивы поднимает сложность поиска до линейной (перебор массива в лоб). При малых выборках это не страшно, и может работать эффективнее, но если у вас в массиве хотя бы десятки тысяч записей, это будет проблемой (засечки работают обычно от 8к).
2. У вас должна быть возможность хранить такой массив в MergeTree или ReplacingMergeTree, т.е. вы записываете его один раз и не дополняете, либо перезаписываете целиком, и при этом его сортируете (руками). Дело в том, что данные хранятся на диске сжато, а сортированные данные сжимаются гораздо лучше. Поэтому плоские таблицы без массивов всегда упорядочены и хорошо жмуться. Если ваш массив будет неупорядочен, он будет занимать существенно больше места на диске. А чтение с диска самая медленная операция. Что вместе с предыдущим (нет засечек, и массив всегда читается весь) может оказать драматически негативный эффект на производительность. Т.е. эффективно будет работать, только если вы этот массив руками записываете - если использовать AggregatingMergeTree, то в нем нет simple аггрегации массивов с сортировкой и/или дедупликацией. И там варианты либо не сортированный массив(который плохо жмется), либо аггрегационный тип хранилища, который еще больше занимает места и требует дообработки (и будет еще медленнее). Могут еще и дубликаты пробегать.
3. Данных в массиве не больше 1млн штук. Это вроде бы по документации лимит массива. Для большинства задач этого достаточно, но стоит всегда об этом помнить, чтобы внезапно не упереться, и не обнаружить что массивы совсем не подходят и все надо переделывать. В статье об этом сказано, но не указано число.
При этом, если вы ни под одно из этих ограничений не попадаете, можно действительно получить существенный прирост к производительности (я вроде бы до x2 выжимал) и потреблению ресурсов (CPU и память). Но если они у вас есть - эффект будет противоположный.
Ну, допустим, ква.
К сожалению даже когда подвезут - ее надо довольно круто допиливать напильником, чтобы асинхронность в ней не тормозила. Реализовали ее весьма так себе.
Интересно у вас происходят zoom созвоны однако.
Например задавать уточняющие вопросы. Пока вы задаете вопросы исключено в формате, почему мы делаем ту дичь, что из вашей собственной головы вылезает.
Если вы будете задавать уточняющие вопросы по оригинальным вводным, а не по тем, которые вы сами придумали, получится совсем другой разговор.
Теперь вы придумали, что мы разговаривали с peer коллегами. И что интересно, в обоих сценариях, которые вы сами придумываете, мы всегда творим какую то дичь.
Знаете такую штуку на собеседованиях, как проекционные вопросы?
Во-первых, вы не ответили на мои вопросы, и уже задаете свои. Если вы потрудитесь дать на них ответы, возможно поймете что ваши новые - просто лишены смысла. Вы меня расспрашиваете о звонке руководителю, который сами придумали.