Изначально была идея реализация парсинга вакансий с пагинацией, поэтому и была реализована многопоточность. Статей про парсинг на python много на Хабре, а на другом ЯП встречаются редко, поэтому и было реализовано.
В РФ Scala умирает(исходя из вакансий). Его как бэкенд язык меньше рассматривают. Единственное, где сейчас он актуален - Apache Spark в Data Engineering.
Один из ботов - это получение статистики из leetcode. А второй - система онбординга для проектов. Из плюсов, что у меня есть конфигурационный файл, который я могу изменять и будет меняться контент в боте - без перезапуска бота
Добрый вечер. Прошу не что стоит принижать статью до "галочки", а также, что автор "плавает" в теме. Вам не понравилось, что было не рассмотрено exists/in/join на достойном уровне. Я сделаю выводы и в дальнейшем будут тут более качественные статьи.
То, что вы ниже стали писать. Это необъективщина. Вам не понравился блок скрытый, кому-то нравится. Насчёт case, вы также не правы. Прошу использовать при проверке оператор is, а не равенство. Если мы за достойные примеры, то прошу писать принятые практики.
Добрый вечер. В статье сказано про рефакторинг запроса. Про индексы не сказано. Сейчас вы предъявляете, что можно создать индексы для ускорения. По мнению автора - создание индекса описано в других статьях по оптимизации запроса. В этой про рефакторинг. Например антипаттерн кореллирующий подзапрос и обычный join.
Если мы возьмём Greenplum, то индексация там лучше не делать.
По поводу скрытого кода. Для удобства чтения сделано. Если читателю неинтересен код, то он дополнительно не скролит вниз.
По поводу case. Проверка на null и bool значения принято через оператор is. К тому же в PostgreSQL подефолту проверка на true, если указаны операторы and/or.
По поводу не представленных тестовых данных. Если прикреплю ссылку - найдутся пользователи, которые задизлайкают и напишут не для забора. Уже проходили.
По поводу индексов. Индексы не всегда ускоряют. Сводить в статье, что используйте правильно индексы - везде написано. Смысл статьи был как рефакторинг может ускорить запрос. В начале описано, о чем будет статья. Про индексы не было сказано.
Добрый вечер, не согласен с вами. С критикой, которая написана соглашусь, есть погрешности. Статья про как переписать запросы с ускорением. На Greenplum данные аспекты хорошо показываются.
Добрый день, нет в Apache Airflow DAGи не сохраняются в базе данных напрямую. Вместо этого, информация о DAGах (имена, расписания, зависимости и т. д.) хранится в базе данных Metastore, а код самого DAG хранится в файлах Python на сервере Airflow.
Хотел бы сказать, что выбор языка - дело вкуса. В данной статье нигде не осуждали использования Python, наоборот было подчеркнуто, что является популярным ЯП для разработки ботов.
По поводу вывода:
При работе с API необходимо уметь эффективно обрабатывать и анализировать большие объемы данных, полученных от сервера. Это требует навыков работы с различными структурами данных, такими как массивы, хеш-таблицы и т. д., что способствует улучшению навыков структур данных. В данной статье - массивы.
При использовании API важно оптимизировать запросы и обработку данных для улучшения производительности и эффективности приложения. Это позволяет разработчикам применять оптимальные алгоритмы и подходы для выполнения запросов и получения данных, что улучшает навыки оптимизации алгоритмов.
Изначально была идея реализация парсинга вакансий с пагинацией, поэтому и была реализована многопоточность. Статей про парсинг на python много на Хабре, а на другом ЯП встречаются редко, поэтому и было реализовано.
Когда работал на Nissan часто употреблялось в команде спарсить данные
В РФ Scala умирает(исходя из вакансий). Его как бэкенд язык меньше рассматривают. Единственное, где сейчас он актуален - Apache Spark в Data Engineering.
Один из ботов - это получение статистики из leetcode. А второй - система онбординга для проектов. Из плюсов, что у меня есть конфигурационный файл, который я могу изменять и будет меняться контент в боте - без перезапуска бота
Добрый вечер. Прошу не что стоит принижать статью до "галочки", а также, что автор "плавает" в теме. Вам не понравилось, что было не рассмотрено exists/in/join на достойном уровне. Я сделаю выводы и в дальнейшем будут тут более качественные статьи.
То, что вы ниже стали писать. Это необъективщина. Вам не понравился блок скрытый, кому-то нравится. Насчёт case, вы также не правы. Прошу использовать при проверке оператор is, а не равенство. Если мы за достойные примеры, то прошу писать принятые практики.
Добрый вечер. В статье сказано про рефакторинг запроса. Про индексы не сказано. Сейчас вы предъявляете, что можно создать индексы для ускорения. По мнению автора - создание индекса описано в других статьях по оптимизации запроса. В этой про рефакторинг. Например антипаттерн кореллирующий подзапрос и обычный join.
Если мы возьмём Greenplum, то индексация там лучше не делать.
Добрый вечер.
По поводу скрытого кода. Для удобства чтения сделано. Если читателю неинтересен код, то он дополнительно не скролит вниз.
По поводу case. Проверка на null и bool значения принято через оператор is. К тому же в PostgreSQL подефолту проверка на true, если указаны операторы and/or.
По поводу не представленных тестовых данных. Если прикреплю ссылку - найдутся пользователи, которые задизлайкают и напишут не для забора. Уже проходили.
По поводу индексов. Индексы не всегда ускоряют. Сводить в статье, что используйте правильно индексы - везде написано. Смысл статьи был как рефакторинг может ускорить запрос. В начале описано, о чем будет статья. Про индексы не было сказано.
Добрый вечер, не согласен с вами. С критикой, которая написана соглашусь, есть погрешности. Статья про как переписать запросы с ускорением. На Greenplum данные аспекты хорошо показываются.
Понимаю, учту на будущее
Добрый день, в блоке пред оптимизационные шаги описана CTE
Спасибо огромное, будем стараться
Спасибо большое, старались.
Спасибо за мнение. Старались
Добрый день, нет в Apache Airflow DAGи не сохраняются в базе данных напрямую. Вместо этого, информация о DAGах (имена, расписания, зависимости и т. д.) хранится в базе данных Metastore, а код самого DAG хранится в файлах Python на сервере Airflow.
Спасибо за комментарий.
Хотел бы сказать, что выбор языка - дело вкуса. В данной статье нигде не осуждали использования Python, наоборот было подчеркнуто, что является популярным ЯП для разработки ботов.
По поводу вывода:
При работе с API необходимо уметь эффективно обрабатывать и анализировать большие объемы данных, полученных от сервера. Это требует навыков работы с различными структурами данных, такими как массивы, хеш-таблицы и т. д., что способствует улучшению навыков структур данных. В данной статье - массивы.
При использовании API важно оптимизировать запросы и обработку данных для улучшения производительности и эффективности приложения. Это позволяет разработчикам применять оптимальные алгоритмы и подходы для выполнения запросов и получения данных, что улучшает навыки оптимизации алгоритмов.
Спасибо, буду и дальше стараться
Спасибо прислушаюсь