Это очень круто, то, что вы делаете, однажды был опыт использования бота для отправки информации о скрученном перед нами парне, для себя, к счастью, не пришось. Понимаю, что в НКО идут не за деньгами, но всё же, без них никуда, а особенно, если есть семья, а возможно, у многих теперь повышенные траты в связи с адаптацией в другой стране. И всё же, можно узнать хотя бы примерные вилки зп?
Я бы предложил сравнить капитализацию microsoft'а и вашей компании, чтобы понять насколько они идиоты. Естественно, любая компания может принимать идиотские решения, но всё-таки ОС и офис это одни из их ключевых продуктов по сей день
Protected в Python? Первый раз услышал, пошёл в гугл, оказывается методы с одним нижним подчёркиванием считаются protected, но по факту они ни разу не protected, в чём смысл тогда? Обычно сколько встречаю, считается нормой как раз приватные объявлять с одним нижним подчёркиванием, что является просто согласием в python сообществае, т.к. два нижних всё равно по факту приватности не дают, а тут вдруг protected...
Мы искали мидла на питоне, за неделю 41 отклик на хабр карьере, примерно треть вполне релевантные (2 и более лет работы, не курсы, не 50 языков в резюме). Не госы, не банк, не другой крупняк — зарубежный стартап, может в этом дело.
Вполне нормальное поведение возвращать итерируемый объект, делая само вычисление ленивым, чтоб экономить память. Не знаю за все языки, но в дарте практически такая же реализация.
Что-то исправляет, а что-то добавляет. Некоторые странные баги висят годами, пайдантик часто не может сказать в каком конкретном поле ошибка, отдавая просто "422 unprocessable entity", документации по апи так и нет. Но с другой стороны, над ним по сути и работает то только 1 человек...
Динамическая типизация (соглашусь, тут можно поспорить, сейчас почти везде есть инференс типов, но всё же), упрощённое ООП (не нужно даже писать геттеры/сеттеры по факту, не говоря уже о разных паттернах), огромное количество готовых/полуготовых решений для чего угодно - генерация файлов от изображений до пдф, аутентификации через сторонние сервисы, работу с геоданными в той же джанге подключить на раз два, достаточно заюзать геоджанго и постгис, легко делать простые дашборды с тем же dash или хотя бы фласком и тд и тп
>Вон, для приёма на стажировку по жава надо уметь наколотить вэб-круд на Спринге с бд и фронтэндом. Т.е. это достаточно просто даже для новичка. А может, дело как раз в этом?) В случае питона, зачастую, этого достаточно для мидла. А для собеса на джаву пойди выучи всю теорию работы jvm, ооп, разницу между версиями и в какой версии какие фичи можно юзать, а потом ещё будь добр уметь в круды (спринг, работа с бд и минимальный фронт, что на самом деле тоже огромная нагрузка).
Если вы имеете ввиду что брать в дополнение к вашему стеку для узких задач, то ответ классический - it depends. Недостатки будут в любом случае, вопрос в том, с какими из них вы можете позволить себе жить дальше с минимумом проблем. Например, в случае питона можно писать код на cython, который позволит убрать какие-то боттлнеки по скорости. В случае, если вам нужно написать сервис для вашего приложения, обрабатывающий огромное количество сетевых соединений, например чатик на вебсокетах, то, возможно, неплохим решением будет найти разработчика на том же go, если текущий стек имеет проблемы с этим. Всё зависит от задачи, от бюджетов, от штата разработчиков. Какие-то задачи уже вполне решены и оптимизированы на тех же сях или плюсах и имеют высокоуровневые интерфейсы - например, задачи машинного обучения или просто матлибы, которыми куда проще пользоваться из того же питона. Если у вас есть задача сверхбыстрого оптимизированного запроса для бд и штат из разрабов, умеющих в запросы, но не умеющих в бэк на вашем стэке - мб даже будет оптимальным решением решить этот вопрос на стороне бд в условных хранимках, кто знает, тут нет универсальных решений.
Сочетание "низкоуровневое программирование + отсутствие ГЦ + популярный ЯП + бизнес-логика" порождает противоречия и в дело вступают трейдоффы. Тут примерно такая же история, как и в случае CAP-теоремы для бд. Будет не лучшим выбором изначально писать бизнес-логику на плюсах (особенно, когда у нас есть выбор, а он у нас на самом деле есть, я объясню далее), потому что это низкоуровневый язык и мы имеем дело с массой объектов, которые мы всегда должны держать в уме помимо бизнес-логики. Что не так с бизнес-логикой? Условия меняются буквально каждый день и, соответственно, код будет меняться тоже практически каждый день. Например, код на плюсах будет окей для условного ядра новой базы данных, потому что там да - важна скорость и логика будет меняться не так быстро, потому что ядру базы данных плевать на изменения в обществе, плевать на какие-то новые законы, плевать на решения менеджмента, желания разработчиков/пользователей/кота и тд и тп. И вот помимо всего этого вам нужно думать о памяти, о синтаксических/семантических особенностях плюсов, что только увеличивает и время разработки и количество ошибок в коде. Почему же у нас есть выбор писать на других языках и что же мы такого важного забыли? Фреймворк для микросервисов (как постулируется в статье). Ещё раз, микросервисов. Не монолит, микросервисы. Что же нивелирует все профиты плюсов в контексте микросервисов? Правильно, сеть! Суть микросервисов - работа по сети и тут встаёт, соответственно, вопрос - а даст ли фреймворк на плюсах вообще хоть какой-то профит, когда большая часть ожидания уходит на сеть?
Это очень круто, то, что вы делаете, однажды был опыт использования бота для отправки информации о скрученном перед нами парне, для себя, к счастью, не пришось.
Понимаю, что в НКО идут не за деньгами, но всё же, без них никуда, а особенно, если есть семья, а возможно, у многих теперь повышенные траты в связи с адаптацией в другой стране. И всё же, можно узнать хотя бы примерные вилки зп?
Хабр.карьера на мой взгляд более релевантен для поста
Звучит как угроза
А это, кстати, многое объясняет =)
Я бы предложил сравнить капитализацию microsoft'а и вашей компании, чтобы понять насколько они идиоты. Естественно, любая компания может принимать идиотские решения, но всё-таки ОС и офис это одни из их ключевых продуктов по сей день
__new__(если такой метод используется в классе);__init__;Остальные магические методы;
Public-методы;
Protected-методы;
Private-методы.
Protected в Python? Первый раз услышал, пошёл в гугл, оказывается методы с одним нижним подчёркиванием считаются protected, но по факту они ни разу не protected, в чём смысл тогда? Обычно сколько встречаю, считается нормой как раз приватные объявлять с одним нижним подчёркиванием, что является просто согласием в python сообществае, т.к. два нижних всё равно по факту приватности не дают, а тут вдруг protected...
Про возраст можно было не писать, понятно по тексту =)
Draft (Черновик)
Разве можно асинхронный queryset обернуть в Response из DRF? Или я что-то не так понял?)
Случайно в подарок к 4 млн ничего не прилагалось? Ну там, бутылка, например?)
тыжпрограммист
не могут, код не запустится
Вполне нормальное поведение возвращать итерируемый объект, делая само вычисление ленивым, чтоб экономить память. Не знаю за все языки, но в дарте практически такая же реализация.
Что-то исправляет, а что-то добавляет. Некоторые странные баги висят годами, пайдантик часто не может сказать в каком конкретном поле ошибка, отдавая просто "422 unprocessable entity", документации по апи так и нет. Но с другой стороны, над ним по сути и работает то только 1 человек...
главное бассейн в яму не забыть
В кашу
Динамическая типизация (соглашусь, тут можно поспорить, сейчас почти везде есть инференс типов, но всё же), упрощённое ООП (не нужно даже писать геттеры/сеттеры по факту, не говоря уже о разных паттернах), огромное количество готовых/полуготовых решений для чего угодно - генерация файлов от изображений до пдф, аутентификации через сторонние сервисы, работу с геоданными в той же джанге подключить на раз два, достаточно заюзать геоджанго и постгис, легко делать простые дашборды с тем же dash или хотя бы фласком и тд и тп
>Вон, для приёма на стажировку по жава надо уметь наколотить вэб-круд на Спринге с бд и фронтэндом. Т.е. это достаточно просто даже для новичка.
А может, дело как раз в этом?) В случае питона, зачастую, этого достаточно для мидла. А для собеса на джаву пойди выучи всю теорию работы jvm, ооп, разницу между версиями и в какой версии какие фичи можно юзать, а потом ещё будь добр уметь в круды (спринг, работа с бд и минимальный фронт, что на самом деле тоже огромная нагрузка).
Если вы имеете ввиду что брать в дополнение к вашему стеку для узких задач, то ответ классический - it depends. Недостатки будут в любом случае, вопрос в том, с какими из них вы можете позволить себе жить дальше с минимумом проблем. Например, в случае питона можно писать код на cython, который позволит убрать какие-то боттлнеки по скорости. В случае, если вам нужно написать сервис для вашего приложения, обрабатывающий огромное количество сетевых соединений, например чатик на вебсокетах, то, возможно, неплохим решением будет найти разработчика на том же go, если текущий стек имеет проблемы с этим. Всё зависит от задачи, от бюджетов, от штата разработчиков. Какие-то задачи уже вполне решены и оптимизированы на тех же сях или плюсах и имеют высокоуровневые интерфейсы - например, задачи машинного обучения или просто матлибы, которыми куда проще пользоваться из того же питона. Если у вас есть задача сверхбыстрого оптимизированного запроса для бд и штат из разрабов, умеющих в запросы, но не умеющих в бэк на вашем стэке - мб даже будет оптимальным решением решить этот вопрос на стороне бд в условных хранимках, кто знает, тут нет универсальных решений.
Сочетание "низкоуровневое программирование + отсутствие ГЦ + популярный ЯП + бизнес-логика" порождает противоречия и в дело вступают трейдоффы. Тут примерно такая же история, как и в случае CAP-теоремы для бд. Будет не лучшим выбором изначально писать бизнес-логику на плюсах (особенно, когда у нас есть выбор, а он у нас на самом деле есть, я объясню далее), потому что это низкоуровневый язык и мы имеем дело с массой объектов, которые мы всегда должны держать в уме помимо бизнес-логики. Что не так с бизнес-логикой? Условия меняются буквально каждый день и, соответственно, код будет меняться тоже практически каждый день. Например, код на плюсах будет окей для условного ядра новой базы данных, потому что там да - важна скорость и логика будет меняться не так быстро, потому что ядру базы данных плевать на изменения в обществе, плевать на какие-то новые законы, плевать на решения менеджмента, желания разработчиков/пользователей/кота и тд и тп. И вот помимо всего этого вам нужно думать о памяти, о синтаксических/семантических особенностях плюсов, что только увеличивает и время разработки и количество ошибок в коде.
Почему же у нас есть выбор писать на других языках и что же мы такого важного забыли? Фреймворк для микросервисов (как постулируется в статье). Ещё раз, микросервисов. Не монолит, микросервисы. Что же нивелирует все профиты плюсов в контексте микросервисов? Правильно, сеть! Суть микросервисов - работа по сети и тут встаёт, соответственно, вопрос - а даст ли фреймворк на плюсах вообще хоть какой-то профит, когда большая часть ожидания уходит на сеть?