Давай-давай, пиши документацию
На всех проектах мы стараемся адекватно подходить к документированию. "Адекватно" означает не кидаться в крайности, когда к каждой строчке начинается писанина, или, наоборот, смотришь на проект и не понимаешь, куда коней запрягать.
Для нас хорошо задукоментированный проект, с которым приятно работать, включает три части: докстринги, ридми и тесты.
Считаем, что в докстрингах должно быть описано назначение функций с пояснением каких-то особо хитрых моментов, описаны принимаемые и возвращаемые параметры. Мы используем гугл нотацию. Также в комплекте с докстрингами неразрывно идет аннотация типов. Это особенно важно, когда на входе какие-то сложные структуры данных. Целью является облегчение чтения кода.
Теперь о ридми. У нас на проектах ридми состоит из следующих блоков:
— Вводная часть, где тезисно указываем общее назначение сервиса. Если у сервиса чётко выраженное назначение, то описываем общий алгоритм работы.
— Установка и запуск. В этой части указываем набор команд, которые необходимо выполнить, чтобы запустить проект.
Подробность описания должна быть такая, чтобы при первом знакомстве с проектом разработчик скопировал из ридми команды и без матерных выражений запустил проект.
И, конечно, мы всё запускаем в докере. О важности докера у нас есть отдельный пост.
В этом же разделе также важно описать, как запускать тесты. Очень важно.
— Переменные окружения и опции. Сложный проект требует настройки, поэтому обязательно указываем набор переменных окружения, которые нужны в проекте, с описанием их назначения и дефолтными значениями.
— В разделе "другое" пишем о каких-то специфичных для проекта моментах. К таким особенностям может относится, например, накатывание миграций.
Последнее в нашем списке хорошо задокументированного проекта — тесты. Тесты являются самой актуальной документацией. В ридми можно забыть что-то поправить, а запуск тестов всегда показывает реальное поведение программы. Именно поэтому в ридми важно указывать, как запускать тесты.
Резюмируя, чем больше вы дадите информации о том, как запускать, как управлять проектом, какие у него есть особенности, тем лучше. Это облегчит вход любому разработчику. С увеличением числа проектов качественная документация становится критически важной. Во время разработки кажется: да всё понятно, как запускать эту штуку. А через пол года написанный вами проект будет выглядеть чужим и непонятным.
И ещё мысль по поводу документации:
Считаем вредным советом или требованием писать документацию в каких-то сторонних системах, таких как конфлюенс (да, порой и такое требуют). Практика показала, что поддержание документации в актуальном виде в стороннем сервисе, мягко говоря, не работает. Очень сложно убедить и даже заставить разработчика поддерживать доку где-то в сторонней приблуде. С ридми проще — можно писать, не отходя от кассы. И контролировать легче, проверяя изменение доки в merge request.
#devfm #procode
На всех проектах мы стараемся адекватно подходить к документированию. "Адекватно" означает не кидаться в крайности, когда к каждой строчке начинается писанина, или, наоборот, смотришь на проект и не понимаешь, куда коней запрягать.
Для нас хорошо задукоментированный проект, с которым приятно работать, включает три части: докстринги, ридми и тесты.
Считаем, что в докстрингах должно быть описано назначение функций с пояснением каких-то особо хитрых моментов, описаны принимаемые и возвращаемые параметры. Мы используем гугл нотацию. Также в комплекте с докстрингами неразрывно идет аннотация типов. Это особенно важно, когда на входе какие-то сложные структуры данных. Целью является облегчение чтения кода.
Теперь о ридми. У нас на проектах ридми состоит из следующих блоков:
— Вводная часть, где тезисно указываем общее назначение сервиса. Если у сервиса чётко выраженное назначение, то описываем общий алгоритм работы.
— Установка и запуск. В этой части указываем набор команд, которые необходимо выполнить, чтобы запустить проект.
Подробность описания должна быть такая, чтобы при первом знакомстве с проектом разработчик скопировал из ридми команды и без матерных выражений запустил проект.
И, конечно, мы всё запускаем в докере. О важности докера у нас есть отдельный пост.
В этом же разделе также важно описать, как запускать тесты. Очень важно.
— Переменные окружения и опции. Сложный проект требует настройки, поэтому обязательно указываем набор переменных окружения, которые нужны в проекте, с описанием их назначения и дефолтными значениями.
— В разделе "другое" пишем о каких-то специфичных для проекта моментах. К таким особенностям может относится, например, накатывание миграций.
Последнее в нашем списке хорошо задокументированного проекта — тесты. Тесты являются самой актуальной документацией. В ридми можно забыть что-то поправить, а запуск тестов всегда показывает реальное поведение программы. Именно поэтому в ридми важно указывать, как запускать тесты.
Резюмируя, чем больше вы дадите информации о том, как запускать, как управлять проектом, какие у него есть особенности, тем лучше. Это облегчит вход любому разработчику. С увеличением числа проектов качественная документация становится критически важной. Во время разработки кажется: да всё понятно, как запускать эту штуку. А через пол года написанный вами проект будет выглядеть чужим и непонятным.
И ещё мысль по поводу документации:
Считаем вредным советом или требованием писать документацию в каких-то сторонних системах, таких как конфлюенс (да, порой и такое требуют). Практика показала, что поддержание документации в актуальном виде в стороннем сервисе, мягко говоря, не работает. Очень сложно убедить и даже заставить разработчика поддерживать доку где-то в сторонней приблуде. С ридми проще — можно писать, не отходя от кассы. И контролировать легче, проверяя изменение доки в merge request.
#devfm #procode
Telegram
DevFM
Зачем вам нужен докер?
Встретили тут в бизнесе мысль: "мы недостаточно большие, чтобы использовать Docker". Не можем согласиться с таким тезисом. В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые…
Встретили тут в бизнесе мысль: "мы недостаточно большие, чтобы использовать Docker". Не можем согласиться с таким тезисом. В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые…
❤6👍6🌭4🔥3
Понимание джойнов сломано
Если в гугле ввести "join sql" и перейти в раздел картинок, можно увидеть повсеместные диаграммы Венна, цель которых – визуально пояснить суть разных видов join-ов.
В своей статье автор делает сенсационное заявление и идёт против системы. Он пытается объяснить, почему использование таких понятных всем кружочков неправильно объясняет работу join-ов.
Считаем эту статья важной, так как, одной стороны, да, действительно, привычные кружочки дают наглядное представление о join-ах, но на практике важны детали, которые в кружочках опускаются.
Как говорится, критикуешь — предлагай, поэтому в следующей статье автор предлагает свой вариант визуализации join-ов. Не сказал бы, что предложенный вариант прям сильно наглядный, однако более точный.
#skills #database
Если в гугле ввести "join sql" и перейти в раздел картинок, можно увидеть повсеместные диаграммы Венна, цель которых – визуально пояснить суть разных видов join-ов.
В своей статье автор делает сенсационное заявление и идёт против системы. Он пытается объяснить, почему использование таких понятных всем кружочков неправильно объясняет работу join-ов.
Считаем эту статья важной, так как, одной стороны, да, действительно, привычные кружочки дают наглядное представление о join-ах, но на практике важны детали, которые в кружочках опускаются.
Как говорится, критикуешь — предлагай, поэтому в следующей статье автор предлагает свой вариант визуализации join-ов. Не сказал бы, что предложенный вариант прям сильно наглядный, однако более точный.
#skills #database
🔥10👍3🌭3❤1👎1
Backup: декабрь. Топ постов за месяц
1. Читаем документацию на примере FastAPI
2. Подборка базовых материалов для python-разработчиков на 2022 год
3. Kubernetes в небольших проектах
4. Регулярные выражения в Python от простого к сложному
5. Ищем свой пароль в файле размером 37 Гб на Python. В комментариях разгорелась дискуссия, заменит ли ChatGPT джунов
6. Хватит пересылать пароли в открытом виде
7. FastAPI best practices
8. Идемпо… что? Улучшаем API
9. Зелёные потоки в Python
10. Давай-давай, пиши документацию
#backup
1. Читаем документацию на примере FastAPI
2. Подборка базовых материалов для python-разработчиков на 2022 год
3. Kubernetes в небольших проектах
4. Регулярные выражения в Python от простого к сложному
5. Ищем свой пароль в файле размером 37 Гб на Python. В комментариях разгорелась дискуссия, заменит ли ChatGPT джунов
6. Хватит пересылать пароли в открытом виде
7. FastAPI best practices
8. Идемпо… что? Улучшаем API
9. Зелёные потоки в Python
10. Давай-давай, пиши документацию
#backup
Telegram
DevFM
Читаем документацию на примере FastAPI
В жизни каждого разработчика наступает такой момент, когда найденного мануала или статьи не хватает для решения вашей задачи. Вам нужны будут какие-то хитрости, про которые в мануале ни слова. Именно в этот момент придётся…
В жизни каждого разработчика наступает такой момент, когда найденного мануала или статьи не хватает для решения вашей задачи. Вам нужны будут какие-то хитрости, про которые в мануале ни слова. Именно в этот момент придётся…
❤9🔥7⚡2👍2🌭1
Топ постов за год 🔝
1. Делаем код мягким и шелковистым
2. Преодолеваем постоянное откладывание дел
3. Стрим по созданию небольшого проекта на gitlab с тестами
4. Зачем вам нужен докер?
5. Завышать ли опыт в резюме?
6. Как я научился воспринимать английский на слух
7. Что я увидел в своих собеседованиях
8. Корчеватель ломает науку
9. Какие знания нужны разработчику?
10. Вопросы для junior python developer
11. Зачем WSGI в Python?
12. Проектируем сервис: поиск организаций по картам
#backup
1. Делаем код мягким и шелковистым
2. Преодолеваем постоянное откладывание дел
3. Стрим по созданию небольшого проекта на gitlab с тестами
4. Зачем вам нужен докер?
5. Завышать ли опыт в резюме?
6. Как я научился воспринимать английский на слух
7. Что я увидел в своих собеседованиях
8. Корчеватель ломает науку
9. Какие знания нужны разработчику?
10. Вопросы для junior python developer
11. Зачем WSGI в Python?
12. Проектируем сервис: поиск организаций по картам
#backup
Telegram
DevFM
Делаем код мягким и шелковистым
Мы уже говорили об утилите pre-commit, которая автоматизирует рутинный запуск анализаторов кода и не позволяет сделать коммит, пока проблемы не будут исправлены.
Теперь расскажем о тех утилитах, которые применяются в каждом…
Мы уже говорили об утилите pre-commit, которая автоматизирует рутинный запуск анализаторов кода и не позволяет сделать коммит, пока проблемы не будут исправлены.
Теперь расскажем о тех утилитах, которые применяются в каждом…
👍11❤3🔥3⚡1🌭1
Вспоминая git
В статье Top 30 Git Commands You Should Know To Master Git CLI собран набор часто используемых команд для работы с гитом. Некоторые из них достаточно очевидные, но со списком точно стоит ознакомиться.
Мы на практике часто используем команды:
7. посмотреть лог коммитов с изменениями
9. просмотреть изменения перед коммитом
11. переименовать файлы
13. внести изменения в последний коммит
15. откатить произвольный коммит
20. просмотреть лог коммитов в виде графа
24. просмотреть подробности об удаленном репозитории: push url, fetch url, какие ветки есть, какая ветка head
29. удалить ветку в удалённом репозитории
Хочется обратить внимание на вредность второго пункта. Автор рассказывает о способе сохранения своих учетных данных. Но это неправильный путь. Правильный путь — работать с удаленным репозиторием, применяя ssh-ключи. Не парольный способ. И если вдруг не настроена двухфакторка — её тоже стоит прикрутить.
От себя хочется добавить ещё одну полезную команду git stash. А если столкнулись со сложным случаем, то мы рекомендуем использовать sublime merge.
В копилку часто используемых команд добавим создание локальной ветки из удалённой
#skills
В статье Top 30 Git Commands You Should Know To Master Git CLI собран набор часто используемых команд для работы с гитом. Некоторые из них достаточно очевидные, но со списком точно стоит ознакомиться.
Мы на практике часто используем команды:
7. посмотреть лог коммитов с изменениями
9. просмотреть изменения перед коммитом
11. переименовать файлы
13. внести изменения в последний коммит
15. откатить произвольный коммит
20. просмотреть лог коммитов в виде графа
24. просмотреть подробности об удаленном репозитории: push url, fetch url, какие ветки есть, какая ветка head
29. удалить ветку в удалённом репозитории
Хочется обратить внимание на вредность второго пункта. Автор рассказывает о способе сохранения своих учетных данных. Но это неправильный путь. Правильный путь — работать с удаленным репозиторием, применяя ssh-ключи. Не парольный способ. И если вдруг не настроена двухфакторка — её тоже стоит прикрутить.
От себя хочется добавить ещё одну полезную команду git stash. А если столкнулись со сложным случаем, то мы рекомендуем использовать sublime merge.
В копилку часто используемых команд добавим создание локальной ветки из удалённой
git checkout -t origin/some-branch#skills
Medium
Top 30 Git Commands You Should Know To Master Git CLI
Learn the most essential Git commands to boost your productivity, and become a master in managing the GitHub repositories.
👍8❤2⚡2🌭2🔥1
Кажется, ваше приложение сейчас пятисотит
Как только приложение выкатывается в продакшн, становится важно мониторить его работоспособность и оперативно реагировать на возникающие проблемы.
Работает ли само приложение?
Не упала ли база?
А все ли странички в веб-приложении доступны?
Не просрочился ли сертификат?
Особенно актуальной задача становится, когда используется микросервисная архитектура. Мы на своих проектах для этих целей используем Gatus.
Простая, как дверь и достаточно многофункциональная штука для проверки статуса ваших приложений, то есть классический health check.
Можно реализовать специальные health check-ручки, а можно проверять любые доступные endpoints на возвращаемый статус, время ответа или конкретное содержимое body. Есть возможность следить в онлайне в дашбоарде, как на картинке. Можно складывать в базу и потом анализировать. Обо всех происшествиях можно настроить нотификации в телеграм и много куда ещё.
Функционал, конечно, намного шире, чем в нашем коротком описании. Поэтому стоит ознакомиться с документацией в ридми проекта. Читается легко и сразу становится понятно, как работать с этой махарайкой.
#skills
Как только приложение выкатывается в продакшн, становится важно мониторить его работоспособность и оперативно реагировать на возникающие проблемы.
Работает ли само приложение?
Не упала ли база?
А все ли странички в веб-приложении доступны?
Не просрочился ли сертификат?
Особенно актуальной задача становится, когда используется микросервисная архитектура. Мы на своих проектах для этих целей используем Gatus.
Простая, как дверь и достаточно многофункциональная штука для проверки статуса ваших приложений, то есть классический health check.
Можно реализовать специальные health check-ручки, а можно проверять любые доступные endpoints на возвращаемый статус, время ответа или конкретное содержимое body. Есть возможность следить в онлайне в дашбоарде, как на картинке. Можно складывать в базу и потом анализировать. Обо всех происшествиях можно настроить нотификации в телеграм и много куда ещё.
Функционал, конечно, намного шире, чем в нашем коротком описании. Поэтому стоит ознакомиться с документацией в ридми проекта. Читается легко и сразу становится понятно, как работать с этой махарайкой.
#skills
👍8🔥4🌭3⚡1
Принципы, которыми стоит руководствоваться
Сегодня предлагаем обсудить статью с принципами, которых стоит придерживаться, приступая к очередной задаче.
Эти принципы даются с высоты Solution Architect. Мы выделили принципы, применимые для любого специалиста и которые сами постоянно применяем на практике.
Идти нужно от проблемы
Если для проблемы есть типовое решение — применяйте его. Не нужно пытаться что-то изобретать и применять какую-то новомодную штуку.
Наш совет — всегда осторожно относиться к внедрению новых технологий. Про внедрение новой технологии был отличный пост. Есть исключение — пет-проекты, где мы рекомендуем брать всё самое новое и интересное.
Решайте конкретную проблему
Всегда старайтесь узнать цель разрабатываемой системы, максимально дотошно допытывайтесь до требований. В статье хорошо проиллюстрирован этот тезис.
Мы добавим, что не нужно пытаться продумать на 100 шагов вперед. Это внесёт излишнюю и ненужную сложность в систему, а когда требования кардинально поменяются (а они точно поменяются) окажется, что сложность накручена не там.
Такая проблема часто встречается у разработчиков, когда хочется сразу изобрести классные абстракции и применить все известные паттерны. В итоге получается чрезмерно сложная штука, не понятная никому, даже автору.
Бойтесь готовых решений
Будьте осторожны, когда к вам приходят сразу с решением. Выясняйте проблему! Зачастую оказывается, что проблему можно решить проще или окажется, что проблемы вовсе нет.
Постоянно расширяйте профессиональный кругозор
Очень радуемся, когда встречаем подобный совет. Нам он кажется важным и отличающим хорошего специалиста от среднего. Про широкий кругозор у нас был отдельный пост.
Многое, о чём говорит автор — знакомо и понятно. В статье есть еще несколько советов, а приятное изложение благоволит к прочтению :)
#sudo #edu
Сегодня предлагаем обсудить статью с принципами, которых стоит придерживаться, приступая к очередной задаче.
Эти принципы даются с высоты Solution Architect. Мы выделили принципы, применимые для любого специалиста и которые сами постоянно применяем на практике.
Идти нужно от проблемы
Если для проблемы есть типовое решение — применяйте его. Не нужно пытаться что-то изобретать и применять какую-то новомодную штуку.
Наш совет — всегда осторожно относиться к внедрению новых технологий. Про внедрение новой технологии был отличный пост. Есть исключение — пет-проекты, где мы рекомендуем брать всё самое новое и интересное.
Решайте конкретную проблему
Всегда старайтесь узнать цель разрабатываемой системы, максимально дотошно допытывайтесь до требований. В статье хорошо проиллюстрирован этот тезис.
Мы добавим, что не нужно пытаться продумать на 100 шагов вперед. Это внесёт излишнюю и ненужную сложность в систему, а когда требования кардинально поменяются (а они точно поменяются) окажется, что сложность накручена не там.
Такая проблема часто встречается у разработчиков, когда хочется сразу изобрести классные абстракции и применить все известные паттерны. В итоге получается чрезмерно сложная штука, не понятная никому, даже автору.
Бойтесь готовых решений
Будьте осторожны, когда к вам приходят сразу с решением. Выясняйте проблему! Зачастую оказывается, что проблему можно решить проще или окажется, что проблемы вовсе нет.
Постоянно расширяйте профессиональный кругозор
Очень радуемся, когда встречаем подобный совет. Нам он кажется важным и отличающим хорошего специалиста от среднего. Про широкий кругозор у нас был отдельный пост.
Многое, о чём говорит автор — знакомо и понятно. В статье есть еще несколько советов, а приятное изложение благоволит к прочтению :)
#sudo #edu
Хабр
Памятка архитектору
Я работаю архитектором (Solution Architect если быть точным) в аутсорсинговой компании. В ходе работы я занимаюсь такими активностями как: дизайн и внедрение архитектурных решений, аудит систем...
👍11⚡3🔥3❤1
Авторизация через OAuth и OIDC
Мы постоянно сталкиваемся с авторизацией через сторонние сервисы, и эти сервисы запрашивают доступ к нашим контактам, фото и другим чувствительным данным.
Иногда возникает необходимость самому реализовать авторизацию через сторонние сервисы (single sign-on). В каких-то случаях подобную функциональность из коробки предоставляет фреймворк, а вам нужно только правильно всё настроить. Но в задачах, связанных с безопасностью, важно знать, что происходит под капотом, и ничего не должно делаться на ощупь.
В замечательной статье An Illustrated Guide to OAuth and OpenID Connect по полочкам раскладывается эта тема. OAuth, OpenID Connect, кто на ком стоял, из каких шагов состоит и для чего каждый используется.
Также есть видео на понятном, неспешном английском.
Статья дает базовые знания, чтобы в голове появилась чёткая картинка об этих технологиях. Если необходимо погрузиться в тему, то в конце приводятся ссылки на другие, более глубокие статьи.
Мы считаем, что если разрабатываемая система позволяет не накручивать свою авторизацию, то не нужно этого делать. Не потому, что своё сложнее, а чтобы избавиться от проблемы и беспокойства хранения чувствительной информации пользователей, логинов, паролей в своем сервисе. Вспомните о десятках крупных утечек данных этого года и подумайте.
#skills #security
Мы постоянно сталкиваемся с авторизацией через сторонние сервисы, и эти сервисы запрашивают доступ к нашим контактам, фото и другим чувствительным данным.
Иногда возникает необходимость самому реализовать авторизацию через сторонние сервисы (single sign-on). В каких-то случаях подобную функциональность из коробки предоставляет фреймворк, а вам нужно только правильно всё настроить. Но в задачах, связанных с безопасностью, важно знать, что происходит под капотом, и ничего не должно делаться на ощупь.
В замечательной статье An Illustrated Guide to OAuth and OpenID Connect по полочкам раскладывается эта тема. OAuth, OpenID Connect, кто на ком стоял, из каких шагов состоит и для чего каждый используется.
Также есть видео на понятном, неспешном английском.
Статья дает базовые знания, чтобы в голове появилась чёткая картинка об этих технологиях. Если необходимо погрузиться в тему, то в конце приводятся ссылки на другие, более глубокие статьи.
Мы считаем, что если разрабатываемая система позволяет не накручивать свою авторизацию, то не нужно этого делать. Не потому, что своё сложнее, а чтобы избавиться от проблемы и беспокойства хранения чувствительной информации пользователей, логинов, паролей в своем сервисе. Вспомните о десятках крупных утечек данных этого года и подумайте.
#skills #security
Okta Developer
An Illustrated Guide to OAuth and OpenID Connect
An illustrated guide to explain OAuth and OpenID Connect!
🔥6❤3👍3🌭2⚡1
This media is not supported in your browser
VIEW IN TELEGRAM
Пятничное развлекательное
Один день в неделю у нас "культурный код". Мы делимся интересным вне технических постов. Сегодня у нас "Жизнь" Конвея.
Это игра без игроков, созданная в 1970 году. Задаёшь начальное состояние и наблюдаешь. Правила просты:
— в каждой клетке либо есть жизнь, либо нет
— в пустой (мёртвой) клетке, с которой соседствуют три живые клетки, зарождается жизнь
— клетка живёт в компании 2-3 живых соседок. Если соседей меньше 2, то клетка умирает от одиночества. Если соседей больше 3, то клетка умирает от перенаселённости
Такие правила позволяют создавать удивительные вещи. Например, планер (glider) неизменно движется. Выше вы видите ружьё Госпера — это бесконечно растущая конфигурация, которая создаёт новые планеры, двигающиеся вниз-вправо. Есть неизменные фигуры — Райский сад и другие.
Эрик Реймонд (автор Собор и базар) предложил сделать планер эмблемой хакеров.
Игра жизнь встречается даже в пасхалках Google, о чём мы писали. Симулятор смотрите тут.
#fun
Один день в неделю у нас "культурный код". Мы делимся интересным вне технических постов. Сегодня у нас "Жизнь" Конвея.
Это игра без игроков, созданная в 1970 году. Задаёшь начальное состояние и наблюдаешь. Правила просты:
— в каждой клетке либо есть жизнь, либо нет
— в пустой (мёртвой) клетке, с которой соседствуют три живые клетки, зарождается жизнь
— клетка живёт в компании 2-3 живых соседок. Если соседей меньше 2, то клетка умирает от одиночества. Если соседей больше 3, то клетка умирает от перенаселённости
Такие правила позволяют создавать удивительные вещи. Например, планер (glider) неизменно движется. Выше вы видите ружьё Госпера — это бесконечно растущая конфигурация, которая создаёт новые планеры, двигающиеся вниз-вправо. Есть неизменные фигуры — Райский сад и другие.
Эрик Реймонд (автор Собор и базар) предложил сделать планер эмблемой хакеров.
Игра жизнь встречается даже в пасхалках Google, о чём мы писали. Симулятор смотрите тут.
#fun
❤7👍4🌭4🔥2⚡1
Кино на выходные
Посмотрел тут Не беспокойся, дорогая (2022) с Оливией Уайлд в качестве актёра и режиссёра. Что же, рейтинг в 6.6 на кинопоиске и 5.9 на imdb — это ещё завышенная оценка. Абсолютно бездарный фильм с кучей ружей Бондарчука, когда показывают деталь типа зомби-танцовщиц, которая никак дальше не используется и не развивается. После просмотра совершенно не о чем подумать и нечего обсудить. Смотреть не рекомендую.
С теплом вспоминал Тринадцатый этаж (1999), о котором мы давненько писали в подборке интересных фильмов. Фильм не очень динамичный по современным меркам, но в нём схожие вопросы поднимаются куда глубже, чем в поделке 2022 года. Блин, по ощущениям, треть хронометража в "Не беспокойся" показывают процесс уборки дома. Увлекательнее смотреть, как растёт трава.
Посмотрите Тринадцатый этаж, он того стоит. Или те фильмы подборки, что ещё не видели.
#fun #films
Посмотрел тут Не беспокойся, дорогая (2022) с Оливией Уайлд в качестве актёра и режиссёра. Что же, рейтинг в 6.6 на кинопоиске и 5.9 на imdb — это ещё завышенная оценка. Абсолютно бездарный фильм с кучей ружей Бондарчука, когда показывают деталь типа зомби-танцовщиц, которая никак дальше не используется и не развивается. После просмотра совершенно не о чем подумать и нечего обсудить. Смотреть не рекомендую.
С теплом вспоминал Тринадцатый этаж (1999), о котором мы давненько писали в подборке интересных фильмов. Фильм не очень динамичный по современным меркам, но в нём схожие вопросы поднимаются куда глубже, чем в поделке 2022 года. Блин, по ощущениям, треть хронометража в "Не беспокойся" показывают процесс уборки дома. Увлекательнее смотреть, как растёт трава.
Посмотрите Тринадцатый этаж, он того стоит. Или те фильмы подборки, что ещё не видели.
#fun #films
Кинопоиск
«Не беспокойся, дорогая» (Don't Worry, Darling, 2021)
🎬 1950-е. Джек и Элис живут в идеальном корпоративном городке, состоящем сплошь из дизайнерских домов. Пока мужчины работают над секретным проектом «Победа», их жёны занимаются хозяйством, балетом и шопингом — делают всё, чтобы угодить мужьям. Однако со временем…
❤5🌭3⚡2
ООП на простых примерах
В 40-минутном видео аккуратно объясняют три кита объектно-ориентированного программирования. Примеры даны на TypeScript, но понятны любому разработчику. Автор аккуратно иллюстрирует необходимость ООП, рассказывает про инкапсуляцию, наследование и полиморфизм. Покрыты даже относительно сложные вещи вроде параметрического и ad-hoc полиморфизма.
На трёх китах ООП автор не заканчивает. Вторая половина ролика повествует о композиции и агрегации на примере автомобиля с двигателем и колёсами, об абстрактных классах и интерфейсах, и даже немного о дженериках. Завершает изложение реализация паттернов Dependency Injection и Singleton. При этом Singleton во многих случаях является антипаттерном и мы не рекомендуем его применять.
Обратите внимание, как автор умело использует IDE для автогенерации сеттеров и геттеров. Не забывайте, что IDE — ваш добрый друг, который много чего умеет.
Про нюансы getattr и setattr в питоне мы делали отдельные посты.
#sudo #youtube #procode
В 40-минутном видео аккуратно объясняют три кита объектно-ориентированного программирования. Примеры даны на TypeScript, но понятны любому разработчику. Автор аккуратно иллюстрирует необходимость ООП, рассказывает про инкапсуляцию, наследование и полиморфизм. Покрыты даже относительно сложные вещи вроде параметрического и ad-hoc полиморфизма.
На трёх китах ООП автор не заканчивает. Вторая половина ролика повествует о композиции и агрегации на примере автомобиля с двигателем и колёсами, об абстрактных классах и интерфейсах, и даже немного о дженериках. Завершает изложение реализация паттернов Dependency Injection и Singleton. При этом Singleton во многих случаях является антипаттерном и мы не рекомендуем его применять.
Обратите внимание, как автор умело использует IDE для автогенерации сеттеров и геттеров. Не забывайте, что IDE — ваш добрый друг, который много чего умеет.
Про нюансы getattr и setattr в питоне мы делали отдельные посты.
#sudo #youtube #procode
YouTube
ООП на простых примерах. Объектно-ориентированное программирование
ООП простым языком. Основные концепции объектно ориентированного программирования. Объекты, классы, инкапсуляция, полиморфизм, наследование, композиция, агрегация, интерфейсы, паттерны, solid, dependency injection.
Мой курс "Продвинутый Frontend. В production…
Мой курс "Продвинутый Frontend. В production…
👍10🔥3❤2⚡1🌭1
Индексы в PostgreSQL
До поры, до времени базами данных можно просто пользоваться, не особо вникая в детали работы. Но однажды что-то где-то начинает подтупливать. Тут-то и приходится разбираться.
У нас уже был заход про EXPLAIN. Теперь перейдем к более серьезным вещам, которые нужны при работе с реляционными базами, в частности, PostgreSQL — индексы.
Первая статья из цикла знакомит с особенностями применения индексов в PostgreSQL. Эти знания помогут лучше понимать и обосновывать, для чего и когда использовать индексы.
Статья освещает следующие моменты:
— какие есть способы сканирования — индексное, по битовой карте, последовательное
— как селективность данных влияет на способ сканирования
— почему индекс работает тем лучше, чем меньше строк удовлетворяют условию поиска
— покрывающие индексы и как они позволяют почти не обращаться к таблице
— как проиндексировать только часть строк таблицы для случая неравномерного распределения значений
— параллельное построение индексов, чтобы избежать блокировок при активных вставках и удалениях
Для освоения статьи требуется полная сосредоточенность и погружение, понадобится неоднократно гуглить. В общем, чтиво как раз на воскресный денек :)
На этой статье можно не останавливаться. Далее в цикле нас знакомят с нюансами использования конкретных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.
Многие практически значимые детали, приведенные в статьях часто спрашиваются на собеседовании разработчиков уровня middle.
#skills #database
До поры, до времени базами данных можно просто пользоваться, не особо вникая в детали работы. Но однажды что-то где-то начинает подтупливать. Тут-то и приходится разбираться.
У нас уже был заход про EXPLAIN. Теперь перейдем к более серьезным вещам, которые нужны при работе с реляционными базами, в частности, PostgreSQL — индексы.
Первая статья из цикла знакомит с особенностями применения индексов в PostgreSQL. Эти знания помогут лучше понимать и обосновывать, для чего и когда использовать индексы.
Статья освещает следующие моменты:
— какие есть способы сканирования — индексное, по битовой карте, последовательное
— как селективность данных влияет на способ сканирования
— почему индекс работает тем лучше, чем меньше строк удовлетворяют условию поиска
— покрывающие индексы и как они позволяют почти не обращаться к таблице
— как проиндексировать только часть строк таблицы для случая неравномерного распределения значений
— параллельное построение индексов, чтобы избежать блокировок при активных вставках и удалениях
Для освоения статьи требуется полная сосредоточенность и погружение, понадобится неоднократно гуглить. В общем, чтиво как раз на воскресный денек :)
На этой статье можно не останавливаться. Далее в цикле нас знакомят с нюансами использования конкретных типов индексов: Hash, B-tree, GiST, SP-GiST, GIN и RUM, BRIN и Bloom.
Многие практически значимые детали, приведенные в статьях часто спрашиваются на собеседовании разработчиков уровня middle.
#skills #database
Хабр
Индексы в PostgreSQL — 1
Предисловие В этой серии статей речь пойдет об индексах в PostgreSQL. Любой вопрос можно рассматривать с разных точек зрения. Мы будем говорить о том, что должно интересовать прикладного разработчика,...
👍7❤4🔥2⚡1🌭1
БезТЗатый программист
В 24-минутном видео Михаил Флёнов (автор книги Linux глазами хакера и других) рассуждает о важности технического задания (ТЗ) в разработке. В видео полно занятных примеров из его карьеры. Особый интерес представляют истории о выкидывании ненужных фич — лучше кода может быть только его отсутствие. Самым дорогим в разработке оказывается функционал, которым никто не пользуется. Время и ресурсы потрачены, а проблемы бизнеса не решены.
По нашему опыту, техническое задание позволяет прийти к однозначному пониманию того, что нужно сделать разработчику и что получит в результате заказчик. Фрилансеру ТЗ позволяет оценить трудозатраты и соориентировать по срокам и стоимости. Кстати, сам процесс декомпозиции задач положительно влияет на точность оценки сроков разработки. Мы писали о нашем опыте отслеживания рабочего времени.
Не требуется делать ТЗ по ГОСТ или фиксировать его на годы вперёд. Можно прописывать user story и фиксировать их. Можно итеративно дополнять или корректировать ТЗ. Но важно, чтобы у всех сторон процесса создания продукта было общее понимание планов на разработку. С увеличением размера системы важность ТЗ возрастает.
#youtube #edu
В 24-минутном видео Михаил Флёнов (автор книги Linux глазами хакера и других) рассуждает о важности технического задания (ТЗ) в разработке. В видео полно занятных примеров из его карьеры. Особый интерес представляют истории о выкидывании ненужных фич — лучше кода может быть только его отсутствие. Самым дорогим в разработке оказывается функционал, которым никто не пользуется. Время и ресурсы потрачены, а проблемы бизнеса не решены.
По нашему опыту, техническое задание позволяет прийти к однозначному пониманию того, что нужно сделать разработчику и что получит в результате заказчик. Фрилансеру ТЗ позволяет оценить трудозатраты и соориентировать по срокам и стоимости. Кстати, сам процесс декомпозиции задач положительно влияет на точность оценки сроков разработки. Мы писали о нашем опыте отслеживания рабочего времени.
Не требуется делать ТЗ по ГОСТ или фиксировать его на годы вперёд. Можно прописывать user story и фиксировать их. Можно итеративно дополнять или корректировать ТЗ. Но важно, чтобы у всех сторон процесса создания продукта было общее понимание планов на разработку. С увеличением размера системы важность ТЗ возрастает.
#youtube #edu
YouTube
БезТЗатый программист
ТЗ - это зло или все же необходимое зло, с которым программистам придется жить? Все зависит от ситуации и доверия. Если есть доверие со стороны бизнеса и договоренность, то можно и без него работать и быть Agile, но чаще все же нужен документ.
Поддержать…
Поддержать…
👍9⚡3❤2🌭1
Практика распила монолита
Несколько лет в индустрии шли жаркие споры "микросервисы против монолитов". У каждой из сторон было множество адептов. Однозначного решения нет.
Нам, как разработчикам, интересна статья про переход от монолитной архитектуры к микросервисной. Своё повествование автор ведет в разрезе высокоуровневых задач, которые приходится решать при использовании микросервисной архитектуры:
— оркестрация, управление множеством сервисов, их масштабированием и распределением нагрузки между разными серверами
— контейнеризация и хранение контейнеров
— применение API Gateway, настоящего швейцарского ножа в мире микросервисов для решения сотни инфраструктурных задач
— организация межсервисного взаимодействия. Вопрос организации остро встаёт с ростом числа команд, занимающихся разными сервисами. Без выстроенного взаимодействия уровень энтропии быстро нарастает, а проект превращается в хаос
— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование
— шаблоны сервисов — не совсем очевидный пункт, но очень важный. Всё, что приведено выше, обычно решается в процессе расширения системы. Шаблонами же следует заняться с самого начала. В будущем сэкономит много времени и позволит избежать зоопарка таких похожих, но таких разных сервисов :)
В статье приводятся не только теоретические выкладки, но и конкретные инструменты. Отдельно можно порекомендовать сервис, которым пользуется автор для выбора инструментов — Cloud Native Computing Foundation. Очень классная интерактивная и наглядная карта, где для различных задач собраны сервисы, решающие эти задачи.
В заключении автор напоминает: прежде чем внедрять — подумайте, какие задачи и проблемы вы этим решаете. Эта истина применима к любой технологии
#skills
Несколько лет в индустрии шли жаркие споры "микросервисы против монолитов". У каждой из сторон было множество адептов. Однозначного решения нет.
Нам, как разработчикам, интересна статья про переход от монолитной архитектуры к микросервисной. Своё повествование автор ведет в разрезе высокоуровневых задач, которые приходится решать при использовании микросервисной архитектуры:
— оркестрация, управление множеством сервисов, их масштабированием и распределением нагрузки между разными серверами
— контейнеризация и хранение контейнеров
— применение API Gateway, настоящего швейцарского ножа в мире микросервисов для решения сотни инфраструктурных задач
— организация межсервисного взаимодействия. Вопрос организации остро встаёт с ростом числа команд, занимающихся разными сервисами. Без выстроенного взаимодействия уровень энтропии быстро нарастает, а проект превращается в хаос
— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование
— шаблоны сервисов — не совсем очевидный пункт, но очень важный. Всё, что приведено выше, обычно решается в процессе расширения системы. Шаблонами же следует заняться с самого начала. В будущем сэкономит много времени и позволит избежать зоопарка таких похожих, но таких разных сервисов :)
В статье приводятся не только теоретические выкладки, но и конкретные инструменты. Отдельно можно порекомендовать сервис, которым пользуется автор для выбора инструментов — Cloud Native Computing Foundation. Очень классная интерактивная и наглядная карта, где для различных задач собраны сервисы, решающие эти задачи.
В заключении автор напоминает: прежде чем внедрять — подумайте, какие задачи и проблемы вы этим решаете. Эта истина применима к любой технологии
#skills
Хабр
Микросервисы для чайников: как на них перейти с монолита с нуля
Меня зовут Семен Катаев , я работаю в Авито над процессом перехода от монолитной архитектуры к микросервисам. Переход у нас все еще продолжается, но мне уже есть чем с вами поделиться. Это краткий...
👍5❤3⚡3🔥1
Покоряем большие CSV
Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.
В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра
— разбиение большого файла на части, с которыми дальше удобнее работать
— перемешивание строк в файле. Такое бывает нужно, когда данные используются для обучения модельки машинного обучения
— хранение в виде столбцов ускорит выполнение запросов путём ограничения данных, среди которых идет поиск. Этот пункт достаточно хардкорный, рекомендуем пройтись отладчиком по коду — иначе не разобраться в нюансах
Мы на практике неоднократно сталкивались с гигабайтными CSV, которые иногда даже не умещались в оперативную память.
Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python
Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.
В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра
— разбиение большого файла на части, с которыми дальше удобнее работать
— перемешивание строк в файле. Такое бывает нужно, когда данные используются для обучения модельки машинного обучения
— хранение в виде столбцов ускорит выполнение запросов путём ограничения данных, среди которых идет поиск. Этот пункт достаточно хардкорный, рекомендуем пройтись отладчиком по коду — иначе не разобраться в нюансах
Мы на практике неоднократно сталкивались с гигабайтными CSV, которые иногда даже не умещались в оперативную память.
Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python
Medium
Working with large CSV files in Python from Scratch
5 Techniques
👍7🔥4⚡3🌭2❤1
Составляем документацию разработчика пошагово без диет и тренировок
Мы уже писали о своём опыте документирования проектов.
Теперь заход от больших ребят, в несколько другой плоскости.
Начинается статья с интересной блок-схемы, где отображены типичные вопросы по документации:
— Есть ли у вас документация?
— Актуальна ли она?
— Легко ли её найти?
— Читает ли её кто-то?
— В одном ли месте всё собрано?
В зависимости от ваших ответов на эти вопросы, автор рекомендует посмотреть те или иные пункты статьи. В них даются конкретные практические советы.
Часто полезная информация разбросана по разным источникам. Как подключиться к инфре писали в общем чате, нюансы работы с сервисом написали в личку, R&D таки зафиксировали в конфлюенс. Поэтому на первом шаге рекомендуется собрать всё вместе.
Далее из всего собранного зоопарка нужно выбрать актуальную инфомацию, а всё остальное беспощадно отправить в архив. По нашему опыту, после удаления лишнего руки перестают опускаться и работать становится значительно комфортнее.
Чтобы понять, о чём реально стоит писать, соберите обратную связь. Прошерстите чатики, комменты под инструкциями. Если часто спрашивают, как поменять конфиги там-то — отлично, именно об этом и стоит писать.
Неочевидный, но важный момент. Вход в документацию начинается с поиска. Если где-то будет написано: кронджоба, джоба, cron, то нужный материал не найдётся. Поэтому договоритесь о единой терминологии и стиле написания. У нас, например, простое правило: любые термины пишем в их каноническом виде на английском языке.
Стоит позаботиться также о читабельности. Тут все банально — на текст должно быть приятно смотреть. В статье на этот счёт есть конкретный набор советов.
Чтобы документация читалась, и активно поддерживалась — её нужно распространять, чтобы каждый знал, куда смотреть и где искать. Недостаточно один раз скинуть ссылку в чатик и думать, что все теперь оповещены. Сообщайте о ней из всех утюгов: сделайте закрепы в общих чатах, в личных сообщениях и везде, где у вас тусуется народ.
И в заключение: с документацией, как с тестами. Не стоит думать, что, если проект не покрыт тестами, то и смысла писать их нет. Нужно просто начать покрывать тестами новый код и это уже будет хорошо. Если документация устаревшая или её вообще нет, начните с малого — начните писать её к новым разработкам.
#sudo #skills
Мы уже писали о своём опыте документирования проектов.
Теперь заход от больших ребят, в несколько другой плоскости.
Начинается статья с интересной блок-схемы, где отображены типичные вопросы по документации:
— Есть ли у вас документация?
— Актуальна ли она?
— Легко ли её найти?
— Читает ли её кто-то?
— В одном ли месте всё собрано?
В зависимости от ваших ответов на эти вопросы, автор рекомендует посмотреть те или иные пункты статьи. В них даются конкретные практические советы.
Часто полезная информация разбросана по разным источникам. Как подключиться к инфре писали в общем чате, нюансы работы с сервисом написали в личку, R&D таки зафиксировали в конфлюенс. Поэтому на первом шаге рекомендуется собрать всё вместе.
Далее из всего собранного зоопарка нужно выбрать актуальную инфомацию, а всё остальное беспощадно отправить в архив. По нашему опыту, после удаления лишнего руки перестают опускаться и работать становится значительно комфортнее.
Чтобы понять, о чём реально стоит писать, соберите обратную связь. Прошерстите чатики, комменты под инструкциями. Если часто спрашивают, как поменять конфиги там-то — отлично, именно об этом и стоит писать.
Неочевидный, но важный момент. Вход в документацию начинается с поиска. Если где-то будет написано: кронджоба, джоба, cron, то нужный материал не найдётся. Поэтому договоритесь о единой терминологии и стиле написания. У нас, например, простое правило: любые термины пишем в их каноническом виде на английском языке.
Стоит позаботиться также о читабельности. Тут все банально — на текст должно быть приятно смотреть. В статье на этот счёт есть конкретный набор советов.
Чтобы документация читалась, и активно поддерживалась — её нужно распространять, чтобы каждый знал, куда смотреть и где искать. Недостаточно один раз скинуть ссылку в чатик и думать, что все теперь оповещены. Сообщайте о ней из всех утюгов: сделайте закрепы в общих чатах, в личных сообщениях и везде, где у вас тусуется народ.
И в заключение: с документацией, как с тестами. Не стоит думать, что, если проект не покрыт тестами, то и смысла писать их нет. Нужно просто начать покрывать тестами новый код и это уже будет хорошо. Если документация устаревшая или её вообще нет, начните с малого — начните писать её к новым разработкам.
#sudo #skills
Хабр
Составляем документацию разработчика пошагово без диет и тренировок
Недостаточно просто написать инструкции — важно, как, в каком порядке и где вы их разместите. Привет! Это Теодора — технический писатель Платформы, жизненно важного департамента Ozon....
👍7🔥3⚡2🌭2❤1
Кино на выходные
Думаю, вы слышали о Стивене Хокинге. В 21 год ему поставили диагноз "боковой амиотрофический склероз" и предположили, что жить ему осталось 2.5 года. Болезнь прогрессировала, он перестал ходить, потом утратил возможность двигать руками. После воспаления лёгких он утратил способность говорить.
...В 2018 году он умер в возрасте 76 лет. Практически не имея возможности контактировать с окружающим миром, он вёл исследования, писал книги, выступал и даже летал в невесомости.
К просмотру рекомендуется фильм Вселенная Стивена Хокинга (2014) и одна из его книг, Краткая история времени.
#fun #films #books
Думаю, вы слышали о Стивене Хокинге. В 21 год ему поставили диагноз "боковой амиотрофический склероз" и предположили, что жить ему осталось 2.5 года. Болезнь прогрессировала, он перестал ходить, потом утратил возможность двигать руками. После воспаления лёгких он утратил способность говорить.
...В 2018 году он умер в возрасте 76 лет. Практически не имея возможности контактировать с окружающим миром, он вёл исследования, писал книги, выступал и даже летал в невесомости.
К просмотру рекомендуется фильм Вселенная Стивена Хокинга (2014) и одна из его книг, Краткая история времени.
#fun #films #books
Кинопоиск
«Вселенная Стивена Хокинга» (The Theory of Everything, 2014)
🎬 История большой любви и больших открытий. Молодой студент-физик Стивен Хокинг знакомится с будущим искусствоведом Джейн Уайльд. Стивен подает большие надежды, профессора видят в нем будущее английской космологии. Веселые свидания, прогулки с друзьями, танцы…
👍6❤5🔥3🌭3⚡1
Проектируем систему — System Design
От разработчика уровня middle и выше часто требуются знания в области проектирования. Речь про высокоуровневое понимание того, как сложить готовые кубики в цельный проект. Надо быть в курсе существования различных технологий и способов их соединения для решения задачи.
Для изучения проектирования есть классный репозиторий аж на 200к звезд, в котором собраны различные типовые архитектуры с прицелом на подготовку к интервью. Обычно эта важная часть интервью называется system design.
При первом прочтении глаза разбегаются от количества информации, поэтому ребята подготовили study guide. В зависимости от ваших целей и имеющегося времени советуют изучить те или иные разделы с различной степенью погружения. А если переходить по ссылкам, то можно вообще залипнуть на полдня, изучая заинтересовавшую концепцию.
О типовых решениях разных задач обязательно нужно знать, чтобы не городить очередной велосипед при решении новой проблемы. На эту тему у нас был отдельный пост.
#skills #резюме
От разработчика уровня middle и выше часто требуются знания в области проектирования. Речь про высокоуровневое понимание того, как сложить готовые кубики в цельный проект. Надо быть в курсе существования различных технологий и способов их соединения для решения задачи.
Для изучения проектирования есть классный репозиторий аж на 200к звезд, в котором собраны различные типовые архитектуры с прицелом на подготовку к интервью. Обычно эта важная часть интервью называется system design.
При первом прочтении глаза разбегаются от количества информации, поэтому ребята подготовили study guide. В зависимости от ваших целей и имеющегося времени советуют изучить те или иные разделы с различной степенью погружения. А если переходить по ссылкам, то можно вообще залипнуть на полдня, изучая заинтересовавшую концепцию.
О типовых решениях разных задач обязательно нужно знать, чтобы не городить очередной велосипед при решении новой проблемы. На эту тему у нас был отдельный пост.
#skills #резюме
GitHub
GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes…
Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards. - donnemartin/system-design-primer
👍13❤3⚡3🌭2🔥1
Этапы выполнения запросов в PostgreSQL
Очередная фундаментальная статья на тему PostgreSQL для вдумчивого чтения. На этот раз также супер важная тема — этапы выполнения запросов. В прошлый раз мы писали об индексах.
Из статьи узнаете, как происходит разбор запроса, из каких стадий он состоит. И, если это скорее теоретические знания, то дальше автор переходит к более важному для прикладного программиста — планированию запроса.
И тут уже сложно без понимания EXPLAIN. Ведь анализатор строит дерево плана. Тот или иной запрос можно выполнить по-разному, поэтому и план запроса не один. Для выбора наилучшего оптимизатор применяет хитрые алгоритмы и оценивает стоимость запроса.
Как итог: чтиво направлено больше на понимание кишочков, но менее захватывающим от этого не становится.
Статья является первой из цикла. Далее автор освещает использование статистики, индексное и последовательное сканирования, соединение вложенным циклом или хешированием. Всё это приблизит к глубокому пониманию того, как выполняются запросы в PostgreSQL.
#skills #database
Очередная фундаментальная статья на тему PostgreSQL для вдумчивого чтения. На этот раз также супер важная тема — этапы выполнения запросов. В прошлый раз мы писали об индексах.
Из статьи узнаете, как происходит разбор запроса, из каких стадий он состоит. И, если это скорее теоретические знания, то дальше автор переходит к более важному для прикладного программиста — планированию запроса.
И тут уже сложно без понимания EXPLAIN. Ведь анализатор строит дерево плана. Тот или иной запрос можно выполнить по-разному, поэтому и план запроса не один. Для выбора наилучшего оптимизатор применяет хитрые алгоритмы и оценивает стоимость запроса.
Как итог: чтиво направлено больше на понимание кишочков, но менее захватывающим от этого не становится.
Статья является первой из цикла. Далее автор освещает использование статистики, индексное и последовательное сканирования, соединение вложенным циклом или хешированием. Всё это приблизит к глубокому пониманию того, как выполняются запросы в PostgreSQL.
#skills #database
Хабр
Запросы в PostgreSQL: 1. Этапы выполнения
Привет, Хабр! Начинаю еще один цикл статей об устройстве PostgreSQL, на этот раз о том, как планируются и выполняются запросы. Предыдущие циклы были посвящены индексам , изоляции и многоверсионности ,...
🔥7⚡3❤3🌭3
Python import: Advanced Techniques and Tips
Импорты в питоне могут стать головной болью начинающего разработчика, особенно при переходе от запуска в IDE разработчика на чужую машину. Полезно один раз детально разобраться в этой теме. В статье рассматриваются разные вопросы работы с пакетами в питоне. Доступен перевод в двух частях: часть 1, часть 2.
Начинается статья с базового описания модуля как пространства имён и применения dir для его исследования. Далее объединение модулей в пакет и разные варианты импорта.
В статье также подробно освещаются следующие темы:
— абсолютные и относительные импорты. На практике относительные импорты — зло, PEP8 рекомендует применять абсолютные импорты в большинстве ситуаций
— import path и порядок поиска модулей
— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения
— динамические импорты, которые позволяют перезагружать модули во время работы приложения. Такой способ позволяет реализовать плагинную структуру путём подключения произвольных модулей с кодом на лету
— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте
— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать
— использование профилировщика для импортов. На нашей практике, импорты не становились узким местом приложения. Но если важна скорость старта скрипта, знание о профилировании импортов будет полезным
Заход на правильную организацию импортов был в посте об анализаторах кода.
#python
Импорты в питоне могут стать головной болью начинающего разработчика, особенно при переходе от запуска в IDE разработчика на чужую машину. Полезно один раз детально разобраться в этой теме. В статье рассматриваются разные вопросы работы с пакетами в питоне. Доступен перевод в двух частях: часть 1, часть 2.
Начинается статья с базового описания модуля как пространства имён и применения dir для его исследования. Далее объединение модулей в пакет и разные варианты импорта.
В статье также подробно освещаются следующие темы:
— абсолютные и относительные импорты. На практике относительные импорты — зло, PEP8 рекомендует применять абсолютные импорты в большинстве ситуаций
— import path и порядок поиска модулей
— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения
— динамические импорты, которые позволяют перезагружать модули во время работы приложения. Такой способ позволяет реализовать плагинную структуру путём подключения произвольных модулей с кодом на лету
— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте
— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать
— использование профилировщика для импортов. На нашей практике, импорты не становились узким местом приложения. Но если важна скорость старта скрипта, знание о профилировании импортов будет полезным
Заход на правильную организацию импортов был в посте об анализаторах кода.
#python
Realpython
Python import: Advanced Techniques and Tips – Real Python
The Python import system is as powerful as it is useful. In this in-depth tutorial, you'll learn how to harness this power to improve the structure and maintainability of your code.
❤5👍4🌭2⚡1🔥1
Жизненная история
Мы часто видим на конференциях доклады об изящных технических решениях сложных проблем. Каждый второй изобретает вундервафлю, у каждого первого хайлоад и всё красиво.
Но в реальности всё не так радужно. Бизнесу нужны решения здесь и сейчас, и продукт нередко растёт стихийно, функционируя на костылях и подпорках.
Лёгкая и жизненная статья о достаточно крупной фирме, где всё было буднично. Чтобы выдержать нагрузку — накидывали железа вручную, тестирование — только на локальной машине разработчика, деплой проводили с помощью наколеночного решения.
А дальше автор описывает путь, как можно выбраться из этого болота. Статья сильно перекликается с нашим опытом, аж сжимается сердечко. Из-за постоянно меняющихся требований реального мира нельзя построить идеальную систему. Многие принимаемые решения являются компромиссами. Описанный в статье переход — это путь плавной трансформации, которая позволяет двигаться к светлому будущему в реальных условиях.
Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.
Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills
Мы часто видим на конференциях доклады об изящных технических решениях сложных проблем. Каждый второй изобретает вундервафлю, у каждого первого хайлоад и всё красиво.
Но в реальности всё не так радужно. Бизнесу нужны решения здесь и сейчас, и продукт нередко растёт стихийно, функционируя на костылях и подпорках.
Лёгкая и жизненная статья о достаточно крупной фирме, где всё было буднично. Чтобы выдержать нагрузку — накидывали железа вручную, тестирование — только на локальной машине разработчика, деплой проводили с помощью наколеночного решения.
А дальше автор описывает путь, как можно выбраться из этого болота. Статья сильно перекликается с нашим опытом, аж сжимается сердечко. Из-за постоянно меняющихся требований реального мира нельзя построить идеальную систему. Многие принимаемые решения являются компромиссами. Описанный в статье переход — это путь плавной трансформации, которая позволяет двигаться к светлому будущему в реальных условиях.
Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.
Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills
Хабр
Наши 5 лет с инфраструктурой «ВсеИнструменты.ру»: от нескольких ВМ до отказоустойчивого решения в трёх дата-центрах
Cтатья посвящена проекту «ВсеИнструменты.ру» — крупнейшему интернет-магазину DIY-товаров и нашему клиенту по совместительству. Расскажем, с чего начинали сотрудничество более пяти лет назад, как...
👍6🔥4⚡3❤2🌭2