Как стать автором
Обновить
12
0

Разработчик

Отправить сообщение

Тенденция идёт к замещению хард скилов так называемыми "софт скилами" -- а рынок за это активно топит

средний балл по опроснику — 3.3 по шкале 0-9

Таки а шо вы хотели? Последние годы из всех утюгов вещают "качайте софт-скилы". Сейчас чтобы работать программистом, уровень английского хотят C1 -- рынок требует софтскиловых 3.14-здунков

Есть ещё один момент. Я некоторое время наблюдаю оду анскилу (раз, два, дальше лень, но такого навалом). Статьи об этой тенденции я ещё не видел

Короче, дальше лучше не будет. Может, пора писать статьи "Как выйти из айти"?

Я немного ранее тоже с Enum в SQLAlchemy игрался, но пошёл по пути уникальных целочисленных Enum

Хорошо, но мало. Хорошо, что тема того, как оно работает под капотом, поднимается в принципе. Может, подобная статья была про React? Интересно было бы почитать.

Сравнение с id в БД не совсем корректно, но идея сравнить с с БД как таковыми классная. За фасадом API прячется реализация, со своими сильными и слабыми сторонами, как то undo сегмент или autovacuum

А вот это правда. Я помню, какую революцию поднял RoR -- я всерьёз тогда думал учить Ruby

Я про Laravel ничего не говорил. Вы пробовали читать то, что написано, а не то, что вы сами себе придумали?

Джанга -- это такой маленький PHP в мире питона. А вообще есть много инструментов сильно лучше

Следует отметить, что в обоих случаях был применён метод ректотермального криптоанализа. Для прочих методов необходимо, чтобы IQ криптоаналитика было выше комнатной температуры

А мне тогда повезло

Удалось при задержании включить достаточно убедительно включить дурочку. Сегодня бы уже не сработало

Какой Кип? Публикуя статью в хабе `MySQL`, вы обрекаете себя на то, что к вам придут питонщики, джаваскриптизёры, пэхапэшники и прочие. И, оказывается, никто из них почему-то не шарит за эликсир.

Поэтому вопрос о нативных типах БД от @Source -- максимально логичный в данном контексте -- всё начинается и заканчивается внутри БД. Вместо ответа -- "Прастити?" и отсылка к авторитету.

Давайте всё же будем профессионалами. Я присоединяюсь к вопросу -- как оно работает внутри БД? Меня интересует DML, но не нюансы вашей ORM

для меня было важным критерием 500+ звёзд

Вы так говорите, словно миллионы мух не могут ошибаться </шутка>. Звёзды значат только популярность, и ничего более. "Сырость" версии библиотеки также мало что значит -- надо в сорцы смотреть

Хорошая замена Celery

На самом деле не очень. Посмотрите в сторону https://taskiq-python.github.io/

Вспоминается цитата с сайта-которого-больше-нет (почему-то):

#: Всего пара `make install`, и ваша бубунта превращается

#: превращается

#: в сраку!

:# *слаку

Давайте не будем превращать системы в пакетным менеджером в слаку или что похуже :)

На одной моей железяке дикие проблемы с wifi модулем (mediatek), который на старых ядрах работает примерно никак (соответственно, никакой установки невозможно провести). Поэтому пытаюсь bookwork ставить. RC2 был полной тыквой, RC3 загрузил только вчера и ещё не тестировал

И ни одного `async def` в тасках селери. Следствия:

1) Два драйвера для БД -- синхронный и асинхронный

2) Невозможность переиспользования собственного асинхронного кода

Не самая разумная интеграция. Слезте с селери

Справедливости ради отмечу, что сказано, как любят говорить математики, "необходимо и достаточно"

Поясню автору, по какой причине этот комментарий собирает минусы

При наличии глаз можно открыть скриншот и понять, что пакет оказался в `sid`. Также можно вспомнить, что пакеты debian перед релизом проходят стадии мягкой и жёсткой заморозок, когда завершается приём новых пакетов

Отсюда вопрос -- как пакет, добавленный в sid, мог оказаться в замороженном stable? Логика, ты где?

Продолжайте убеждать себя в собственной крутости 3 раза на дню =)

Мне казалось, я общаюсь с инженером, способным в объективные метрики.

И что в итоге? Тезис о длине (следовательно, сложности) инструкции вы проигнорировали. Тезис об универсальности вы проигнорировали. Оказывается, это "объекты почёсывания ЧСВ"

Вообще переход на личности -- верный признак неспособности оппонента вести дискуссию. За сим тоже откланиваюсь

Когда я сосредоточен на разработке мне не очень хочется вспоминать что и
как запускать, какие команды стартовать и прочее - я хочу открыть IDE и
получить все плюшки сразу же, не задумываясь о том, как их в очередной
раз запустить.

Я про алиасы кому говорил? Про автодополнения по табу кому расписывал?

А ещё, оказывается, у нас IDE много разных. Мой подход сожрёт любая -- универсальность вашего же меня огорчает

Я могу хранить настройки проекта в гите, и он будет одинаковый везде.
Если мне надо будет что-то добавить/убавить - это автоматом уедет всем
разработчикам в проекте, причем самым простым для них способом - через
гит

И заведётся во всех IDE и на всех платформах. Правда, всё так. Даже не смешно кстати.

Ваш подход требует определенного уровня понимания как это все работает. В описанном мною подходе порог входа ниже, так как можно просто положить все в репу и дать короткую инструкцию по запуску проекта в контейнере.

Я уже не в первый раз сталкиваюсь, когда невежество возносится в благодетель. Это странная тенденция.

Вообще при любом раскладе надо писать инструкцию. Именно длина инструкции определяет сложность того или иного подхода. Ваша заняла несколько экранов -- моя уместилась в комментарий. Уместите статью в размер комментария -- тогда я вам поверю.

А если вы считаете что разработчики все поголовно хорошо разбираются в администрировании - то вы заблуждаетесь.

Неужели 1 комментарий, который можно прочитать за 20 секунд -- это такая адская сложноть "администрирования" (лол. Уровень детского сада кстати). То ли дело -- 16 минут на чтение, рабочий день на настройку

А в чем именно конфликтует если не секрет?

Ваш вопрос завёл меня в некоторый тупик. Видите ли, вот всём. И когда на серьёзных щах такой вопрос задают -- зреют встречные вопросы

Однако mode собака-подозревака: off. Неужели всё описанное проще, чем:

  1. Запуск контейнеров через docker compose run --rm --service_ports? Смысл в том, что:

    1. Мы получаем интерактивную консоль, в которой без бубнов работает pdb

    2. Время запуска / остановки контейнера на глаз не отличается от локального запуска процесса

    Если вас пугает длинная команда и большое число аргументов -- вы же программист, не? Я алиасы в своё время создал в проекте, скрыв кучу аргументов и подковёрной дичи (если не знаете, докеры на разных платформах имеют свои нюансы), и с автодополнениями по табу

  2. Для remote pdb / rdb пробрасываем изнутри наружу одинаковые порты. Тогда они даже команду правильную пишут -- копипастим не включая мозг

Описанное выше нахожу на порядок более простым и идентичным локальному запуску, со всеми преимуществами локального запуска и при этом всеми преимуществами докера

Обратите внимание -- мой подход уместил в один комментарий -- настолько всё просто

1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Fullstack Developer
Senior
Git
Linux
SQL
Python
OOP
MySQL
PostgreSQL
Docker
Nginx
High-loaded systems