Пятничное развлекательное
Настало время моего любимого фильма Город грехов (2005). Четыре новеллы с интересными переплетениями между собой. Каждый фрагмент захватывает своими персонажами, вызывая сопереживание.
Старик умирает... Девочка остается жить. Честный обмен
Фильм в жарне нуара, где во главе угла атмосфера пессимизма, недоверия, разочарования и цинизма. Мы говорили про игру Max Payne и фильм Бегущий по лезвию в этой стилистике.
Рекомендую к просмотру. Продолжение 2014 кода мне нравится куда меньше, но атмосферу фильм смог сохранить. Рад был видеть Кристофера Ллойда, хоть и в эпизоде. Кто не знает, это Док из трилогии Назад в будущее.
#films
Настало время моего любимого фильма Город грехов (2005). Четыре новеллы с интересными переплетениями между собой. Каждый фрагмент захватывает своими персонажами, вызывая сопереживание.
Старик умирает... Девочка остается жить. Честный обмен
Фильм в жарне нуара, где во главе угла атмосфера пессимизма, недоверия, разочарования и цинизма. Мы говорили про игру Max Payne и фильм Бегущий по лезвию в этой стилистике.
Рекомендую к просмотру. Продолжение 2014 кода мне нравится куда меньше, но атмосферу фильм смог сохранить. Рад был видеть Кристофера Ллойда, хоть и в эпизоде. Кто не знает, это Док из трилогии Назад в будущее.
#films
Кинопоиск
«Город грехов» (Sin City, 2005)
🎬 Город грехов — это бездна преступлений. Здесь полиция коррумпирована, а улицы смертельно опасны. Тем не менее один из жителей пытается найти убийцу своей подруги. Другой, фотограф, случайно становится свидетелем убийства полицейского и старается скрыть…
🔥6👍2🌭2❤1
Zero-Downtime Deployments with Docker Compose
У нас был пост, посвященный стратегиям деплоя приложений. Но во всех практических примерах использовался кубер. Для многих задач это стрельба из пушки по воробьям, и в комментах спрашивали, есть ли что-то подобное, только без использования кубера.
Нашли свеженькую статью, где автор реализует blue-green деплоймент без даунтайма с применением docker compose.
Из приятного – автор пользуется полюбившимся многим traefik вместо nginx. Также в процессе знакомства можно кое-что новое узнать о композе. Из не очень приятного – bash всё ещё активно применяется.
Всё описанное можно потрогать, исходники выложены на github.
#skills
У нас был пост, посвященный стратегиям деплоя приложений. Но во всех практических примерах использовался кубер. Для многих задач это стрельба из пушки по воробьям, и в комментах спрашивали, есть ли что-то подобное, только без использования кубера.
Нашли свеженькую статью, где автор реализует blue-green деплоймент без даунтайма с применением docker compose.
Из приятного – автор пользуется полюбившимся многим traefik вместо nginx. Также в процессе знакомства можно кое-что новое узнать о композе. Из не очень приятного – bash всё ещё активно применяется.
Всё описанное можно потрогать, исходники выложены на github.
#skills
🔥8❤2👍2🌭2
Пагинируем по-всякому
Занимательная статья, посвящённая способам реализации пагинации.
Достаточно частая задача – отдавать что-то порционно. В зависимости от потребностей, нужно применять разные способы пагинации.
Помимо классического page-based pagination автор рассматривает KeySet-based pagination и Cursor-based pagination. Также рассматриваются плюсы и минусы каждого из способов.
В конце приводятся примеры, как реализована пагинация у больших ребят: Stripe, Shopify, Github.
#skills
Занимательная статья, посвящённая способам реализации пагинации.
Достаточно частая задача – отдавать что-то порционно. В зависимости от потребностей, нужно применять разные способы пагинации.
Помимо классического page-based pagination автор рассматривает KeySet-based pagination и Cursor-based pagination. Также рассматриваются плюсы и минусы каждого из способов.
В конце приводятся примеры, как реализована пагинация у больших ребят: Stripe, Shopify, Github.
#skills
Medium
Paginating Requests in APIs
When exposing large data sets through APIs, it needs to provide a mechanism to paginate the list of resources. There are multiple…
🔥6👍5❤2🌭1
О производительности Postgres
Кто о чём, а мы о postgres. Небольшая, но полезная заметка о некоторых базовых настройках, которые помогут, когда дело дойдёт до исследования производительности базы.
– использовать расширение pg_stat_statements – такая штука, которая собирает полезную информацию о запросах к БД. Например, можно узнать, какие запросы самые долгие, какие в сумме по времени дольше всего выполнялись, какие выполнялись чаще всего
– логировать медленные запросы – можно настроить логирование запросов, которые выполнялись дольше заданного времени. В ту же сторону – логировать EXPLAIN-планы медленных запросов
– автоматически убивать запросы, которые очень долго выполняются
#database
Кто о чём, а мы о postgres. Небольшая, но полезная заметка о некоторых базовых настройках, которые помогут, когда дело дойдёт до исследования производительности базы.
– использовать расширение pg_stat_statements – такая штука, которая собирает полезную информацию о запросах к БД. Например, можно узнать, какие запросы самые долгие, какие в сумме по времени дольше всего выполнялись, какие выполнялись чаще всего
– логировать медленные запросы – можно настроить логирование запросов, которые выполнялись дольше заданного времени. В ту же сторону – логировать EXPLAIN-планы медленных запросов
– автоматически убивать запросы, которые очень долго выполняются
#database
Crunchy Data
Exposing Postgres Performance Secrets | Crunchy Data Blog
Craig lays out four basic things to set up today to make finding and fixing performance faster in the future.
👍8⚡2❤2🌭2
Пятничное развлекательное
Не очень профильно, но очень полезно. Неоднократно бывало такое, что нужно выбрать лампочку, а какую конкретно непонятно. Вроде смотришь на всякие показатели, вроде даже что-то понятно, но что выбрать из сотни лампочек – хз.
Есть прекрасный проверенный ресурс для этих целей – lamptest. Ребята конкретно заморачиваются, проверяют множество показателей и даже ведут блог на хабре.
У них еще есть похожий проект batterytest, где они тестируют элементы питания.
UPD: оказывается и в тг есть канальчик.
#edu
Не очень профильно, но очень полезно. Неоднократно бывало такое, что нужно выбрать лампочку, а какую конкретно непонятно. Вроде смотришь на всякие показатели, вроде даже что-то понятно, но что выбрать из сотни лампочек – хз.
Есть прекрасный проверенный ресурс для этих целей – lamptest. Ребята конкретно заморачиваются, проверяют множество показателей и даже ведут блог на хабре.
У них еще есть похожий проект batterytest, где они тестируют элементы питания.
UPD: оказывается и в тг есть канальчик.
#edu
lamptest.ru
Результаты тестирования светодиодных ламп
Выбор лучших светодиодных ламп: обзоры, тестирование и сравнение харакретистик LED ламп
👍10❤2🌭2
Как работает ChatGPT
Несколько лёгких статей, посвященных языковым моделям.
В первой ребята рассказывают историю языковых моделей, и как мы дошли от T9 до чатЖПТ.
Вторая статья посвящена исключительно GPT4. В чём отличия от предшественников, где применять на практике, как добавили работу с картинками. И ещё много всего интересного.
На фоне всех переживаний: абы чего плохого не вышло — третья статья, где размышляют и пытаются разобраться, стоит ли напрягаться и ожидать восстания машин.
Все статьи читаются на одном дыхании. Для особо любопытствующих в тексте много ссылок на другие исследования.
Ещё хочется поделиться одной статьей What Is ChatGPT Doing … and Why Does It Work? от Стивена Вольфрама. Более вдумчивое чтиво, с примерами и объяснениями, как оно устроено изнутри. Из приятного — все примеры можно позапускать.
О доступе к ChatGPT и наших примерах применения мы писали.
#skills
Несколько лёгких статей, посвященных языковым моделям.
В первой ребята рассказывают историю языковых моделей, и как мы дошли от T9 до чатЖПТ.
Вторая статья посвящена исключительно GPT4. В чём отличия от предшественников, где применять на практике, как добавили работу с картинками. И ещё много всего интересного.
На фоне всех переживаний: абы чего плохого не вышло — третья статья, где размышляют и пытаются разобраться, стоит ли напрягаться и ожидать восстания машин.
Все статьи читаются на одном дыхании. Для особо любопытствующих в тексте много ссылок на другие исследования.
Ещё хочется поделиться одной статьей What Is ChatGPT Doing … and Why Does It Work? от Стивена Вольфрама. Более вдумчивое чтиво, с примерами и объяснениями, как оно устроено изнутри. Из приятного — все примеры можно позапускать.
О доступе к ChatGPT и наших примерах применения мы писали.
#skills
❤11🔥3👍2
Как проектировать микросервисы
Нет универсального алгоритма, где сказано как проектировать микросервисы и правильно разделять зоны ответственности. Обычно этот навык нарабатывается с опытом и всё равно каждый раз думаешь, сомневаешься.
Когда только начинаешь смотреть в эту сторону хочется иметь хотя бы вектор. В статье автор даёт вполне адекватный алгоритм действия, который можно использовать при проектировании.
Важно, что в своих размышлениях автор старается учитывать изменчивость или неточность бизнес требований. Например, сразу неизвестно, какие способы авторизации будут нужны в будущем, или какой способ приёма платежей будет использоваться, кроме заявленного заказчиком на данный момент.
В целом, стоит критически смотреть на подобные статьи. Автор действительно даёт некий алгоритм, но опускает многие детали и вопросы, которые предстоит решать после такой декомпозиции. А именно в деталях обычно скрываются самые большие сложности и нежданчики.
И ещё небольшое примечание от нашей редакции. Когда что-то изучаете на тему микросервисной архитектуры, не цепляйтесь за "микро". Сервисы могут быть абсолютно разного размера в зависимости от конкретной задачи. Не нужно плодить сущности только потому, что в каноническом названии архитектуры есть приписка "микро".
#skills
Нет универсального алгоритма, где сказано как проектировать микросервисы и правильно разделять зоны ответственности. Обычно этот навык нарабатывается с опытом и всё равно каждый раз думаешь, сомневаешься.
Когда только начинаешь смотреть в эту сторону хочется иметь хотя бы вектор. В статье автор даёт вполне адекватный алгоритм действия, который можно использовать при проектировании.
Важно, что в своих размышлениях автор старается учитывать изменчивость или неточность бизнес требований. Например, сразу неизвестно, какие способы авторизации будут нужны в будущем, или какой способ приёма платежей будет использоваться, кроме заявленного заказчиком на данный момент.
В целом, стоит критически смотреть на подобные статьи. Автор действительно даёт некий алгоритм, но опускает многие детали и вопросы, которые предстоит решать после такой декомпозиции. А именно в деталях обычно скрываются самые большие сложности и нежданчики.
И ещё небольшое примечание от нашей редакции. Когда что-то изучаете на тему микросервисной архитектуры, не цепляйтесь за "микро". Сервисы могут быть абсолютно разного размера в зависимости от конкретной задачи. Не нужно плодить сущности только потому, что в каноническом названии архитектуры есть приписка "микро".
#skills
Wayne Clifford Barker - Software development done right. #DoITRight, #DoITOnce
Volatility based decomposition for Microservices - Wayne Clifford Barker
The following method of decomposing a system I learned back in 2013 while being employed at my previous employer and I saw the immense benefits it had on the organization, it is called volatility based decomposition, it is way to break a system up into components…
👍9🔥3❤2
Кеширование на бекенде
Вводная статья, посвященная кешированию на бекенде, затрагивающая много интересных моментов.
Автор проходится по основным концептам:
– Для чего нужно кеширование, что нужно кешировать, по каким метрикам оценивать работу кеша
– Стратегии работы с кешем. Сквозное кеширование, когда все запросы проходят через кеш. Кеширование на стороне, когда само приложение координирует запросы в кеш или бд. Опережающее кеширование (только для чтения), когда приложение работает только с кешом, и кеш периодически синхронизируется с бд
– Всегда актуальный вопрос – стратегии инвалидации кеша. Jitter, чтобы не протухало всё разом. Схлопывание запросов в один, когда протухла запись, которую очень интенсивно используют
– Кеширование ошибок – полезный прием. Если знаем, что в бд нет определенных данных, так зачем каждый раз продолжать долбиться в бд. Можно закеширвать ошибку. Есть даже специальная схема атаки – cache miss attack
О кешировании у нас уже был пост Design distributed cache.
#skills
Вводная статья, посвященная кешированию на бекенде, затрагивающая много интересных моментов.
Автор проходится по основным концептам:
– Для чего нужно кеширование, что нужно кешировать, по каким метрикам оценивать работу кеша
– Стратегии работы с кешем. Сквозное кеширование, когда все запросы проходят через кеш. Кеширование на стороне, когда само приложение координирует запросы в кеш или бд. Опережающее кеширование (только для чтения), когда приложение работает только с кешом, и кеш периодически синхронизируется с бд
– Всегда актуальный вопрос – стратегии инвалидации кеша. Jitter, чтобы не протухало всё разом. Схлопывание запросов в один, когда протухла запись, которую очень интенсивно используют
– Кеширование ошибок – полезный прием. Если знаем, что в бд нет определенных данных, так зачем каждый раз продолжать долбиться в бд. Можно закеширвать ошибку. Есть даже специальная схема атаки – cache miss attack
О кешировании у нас уже был пост Design distributed cache.
#skills
👍14🔥2⚡1
Пятничное развлекательное
Нашёл тут в своих давних заметках лёгкую, но полезную статью от Сергея Абдульманова. Статья небольшая, но даже сейчас помню своё ощущение после прочтения: ого, сколько интересностей!
Название статьи говорящее — Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло, но там не только об этом.
После прочтения вы наверняка не начнете проводить "офигенно длинные собрания", но точно почерпнёте набор того, что важно для полезной, качественной встречи. Мне очень понравилась мысль, что на встрече должно быть минимально достаточное количество людей для принятия решения. Чтобы не приходилось с ним бегать наверх для одобрения. Кстати, о том как этого добиться, есть отдельная статья.
В статье хорошо демонстрируется важность единой терминологии. По сути — один из аспектов DDD, о котором писали раньше. Простой термин, но как он может по-разному интерпретироваться. Например, "наличие". Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов.
И ещё один вроде простой, но супер важный практический совет — никогда не нужно начинать сразу с решения. Всегда начинайте с проблемы. В статье этот тезис объясняется на двух запоминающихся примерах. Из опыта скажу, что легко скатиться сразу к обсуждению решения, не выяснив толком проблему. Поэтому с тех пор тщательно отслеживаю этот момент.
#edu
Нашёл тут в своих давних заметках лёгкую, но полезную статью от Сергея Абдульманова. Статья небольшая, но даже сейчас помню своё ощущение после прочтения: ого, сколько интересностей!
Название статьи говорящее — Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло, но там не только об этом.
После прочтения вы наверняка не начнете проводить "офигенно длинные собрания", но точно почерпнёте набор того, что важно для полезной, качественной встречи. Мне очень понравилась мысль, что на встрече должно быть минимально достаточное количество людей для принятия решения. Чтобы не приходилось с ним бегать наверх для одобрения. Кстати, о том как этого добиться, есть отдельная статья.
В статье хорошо демонстрируется важность единой терминологии. По сути — один из аспектов DDD, о котором писали раньше. Простой термин, но как он может по-разному интерпретироваться. Например, "наличие". Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов.
И ещё один вроде простой, но супер важный практический совет — никогда не нужно начинать сразу с решения. Всегда начинайте с проблемы. В статье этот тезис объясняется на двух запоминающихся примерах. Из опыта скажу, что легко скатиться сразу к обсуждению решения, не выяснив толком проблему. Поэтому с тех пор тщательно отслеживаю этот момент.
#edu
Хабр
Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло
Наш идеал почти 9 лет был такой: собрание стоя, 15 минут максимум, минимум людей. И лучше вообще в коридоре. Не можешь решить за 15 минут — значит, что-то пошло не так. Звучит круто, правда?...
❤7👍3🔥2
Попробуйте HTMX
Если у вас несложный фронтенд и не хочется погружаться в дебри развесистых фронтенд фреймворков – посмотрите на htmx. Очень интересная штуковина. Никакого javanoscript и сложной логики на фронте. Берем в руки html и вперёд.
Обзорная статья, где автор делится позитивным опытом использования htmx.
А тут можно посмотреть примеры использования htmx с вашим любимым языком программирования. Питонистам будет интересен вот такой свежий проектик.
Всё думал, где об этом написать. Но раз уж пост почти про фронтенд, то вот интересный материал, в котором собраны базовые правила по дизайну интерфейсов. На понятных примерах автор показывает, как делать правильно и почему именно так.
#skills #frontend
Если у вас несложный фронтенд и не хочется погружаться в дебри развесистых фронтенд фреймворков – посмотрите на htmx. Очень интересная штуковина. Никакого javanoscript и сложной логики на фронте. Берем в руки html и вперёд.
Обзорная статья, где автор делится позитивным опытом использования htmx.
А тут можно посмотреть примеры использования htmx с вашим любимым языком программирования. Питонистам будет интересен вот такой свежий проектик.
Всё думал, где об этом написать. Но раз уж пост почти про фронтенд, то вот интересный материал, в котором собраны базовые правила по дизайну интерфейсов. На понятных примерах автор показывает, как делать правильно и почему именно так.
#skills #frontend
quii.dev
Chris James - Some nice feedback on LGWT
Chris James, London - Software Engineer
👍9⚡3🔥2❤1
Нужен совет сообщества. У нас всё острее встаёт вопрос документирования сервисов. Конечно, у каждого сервиса есть свой сваггер, к методам написаны докстринги, в ридми есть описание работы сервиса и его архитектуры. Но всё это лежит в разных местах. Хочется красивенько и удобненько собрать всё вместе.
Из хотелок:
– для всего многообразия единый веб-интерфейс: архитектурные описания сервисов из readme, openapi спецификация, общее описание архитектуры из конфлюенса.
– было бы классно понимать пересечения http-ручек, когда в случае вызова одной по цепочке вызывается другая
Есть концептуальное понимание, что должно быть что-то, что периодически собирает всю информацию из разных источников, приводит к единому виду и строит статическую веб-страницу.
Расскажите, как решаете вопрос с документацией, что документируете? Какие технологии стоит использовать?
Из хотелок:
– для всего многообразия единый веб-интерфейс: архитектурные описания сервисов из readme, openapi спецификация, общее описание архитектуры из конфлюенса.
– было бы классно понимать пересечения http-ручек, когда в случае вызова одной по цепочке вызывается другая
Есть концептуальное понимание, что должно быть что-то, что периодически собирает всю информацию из разных источников, приводит к единому виду и строит статическую веб-страницу.
Расскажите, как решаете вопрос с документацией, что документируете? Какие технологии стоит использовать?
👍8⚡2🔥2❤1
Асинхронное взаимодействие сервисов с применением Kafka
Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.
У нас были посты для более глубокого погружения в Kafka. Например, тут в одной статье рассказывают самые основы, в другой разбирают неочевидные проблемы, возникающие на практике.
#python #procode
Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.
У нас были посты для более глубокого погружения в Kafka. Например, тут в одной статье рассказывают самые основы, в другой разбирают неочевидные проблемы, возникающие на практике.
#python #procode
Medium
Event-Driven Apps Using Kafka and Python
In this blog post, we will design and implement an event-driven application using Kafka in Python. In this post, we take an example of…
❤3👍3🔥2
Пятничное развлекательное
Наверно, почти все слышали о замечательной книге "Вы, конечно, шутите, мистер Фейнман!", но она точно заслуживает ещё одного упоминания.
Увлекательная автобиография известного физика, лауреата Нобелевской премии – Ричарда Фейнмана. Как думал, как работал этот выдающийся человек. Помимо этого в книге рассказывается множество интересных историй и смешных случаев из жизни.
Эта книга вдохновляет и мотивирует на новые свершения.
Если еще не читали – обязательно прочтите.
#fun #books
Наверно, почти все слышали о замечательной книге "Вы, конечно, шутите, мистер Фейнман!", но она точно заслуживает ещё одного упоминания.
Увлекательная автобиография известного физика, лауреата Нобелевской премии – Ричарда Фейнмана. Как думал, как работал этот выдающийся человек. Помимо этого в книге рассказывается множество интересных историй и смешных случаев из жизни.
Эта книга вдохновляет и мотивирует на новые свершения.
Если еще не читали – обязательно прочтите.
#fun #books
❤12👍3🌭2
TOAST – проблемы откуда не ждали
Для хранения длинных записей в Postgres используется механизм TOAST.
Колонки с длинными значениями не хранятся в самой таблице. Если значение больше 2 Кб, то данные разбиваются на чанки и отправляются в связные тост-таблицы, скрытые от пользователя. А в исходной таблице хранится специальный указатель на чанки в тост-таблице.
И нам этом можно было бы и закончить. Просто интересный факт, связанный с особенностью хранения данных.
Но есть нюансы. Отметим практически значимые.
– В тост-таблице не может быть больше, чем 2^32 значений, то есть можно просто упереться в верхнее значение
– TOAST не поддерживает UPDATE. То есть каждая операция обновления вашего большого JSON приводит к INSERT в тост-таблицу и её распуханию.
– Независимо сколько в вашей таблице колонок, тост-таблица всегда одна.
Но дело не только в количестве значений в тост-таблице. Сам механизм накладывает определенные издержки.
JSON в Postgres уже давно не в новинку и активно используется. И, как правило, обсуждения проблем TOAST крутятся именно вокруг JSON полей.
В первой части статьи на конкретных примерах показывают, как резко и, на первый взгляд, беспричинно может упасть производительность и увеличиться WAL из-за TOAST.
Во второй же рассказывают, как оптимизировали JSON, чтобы повысить его производительность и уменьшить влияние TOAST. Также дают пару советов: всегда использовать JSONB и никогда не хранить в нём ID.
А для желающих по хардкору погрузиться в кишочки ещё одна статья. Автор закатывает рукава и лезет вглубь TOAST, рассказывает алгоритм его работы и предлагает конкретный подход с бенчмарками для улучшения самого TOAST.
#skills #database
Для хранения длинных записей в Postgres используется механизм TOAST.
Колонки с длинными значениями не хранятся в самой таблице. Если значение больше 2 Кб, то данные разбиваются на чанки и отправляются в связные тост-таблицы, скрытые от пользователя. А в исходной таблице хранится специальный указатель на чанки в тост-таблице.
И нам этом можно было бы и закончить. Просто интересный факт, связанный с особенностью хранения данных.
Но есть нюансы. Отметим практически значимые.
– В тост-таблице не может быть больше, чем 2^32 значений, то есть можно просто упереться в верхнее значение
– TOAST не поддерживает UPDATE. То есть каждая операция обновления вашего большого JSON приводит к INSERT в тост-таблицу и её распуханию.
– Независимо сколько в вашей таблице колонок, тост-таблица всегда одна.
Но дело не только в количестве значений в тост-таблице. Сам механизм накладывает определенные издержки.
JSON в Postgres уже давно не в новинку и активно используется. И, как правило, обсуждения проблем TOAST крутятся именно вокруг JSON полей.
В первой части статьи на конкретных примерах показывают, как резко и, на первый взгляд, беспричинно может упасть производительность и увеличиться WAL из-за TOAST.
Во второй же рассказывают, как оптимизировали JSON, чтобы повысить его производительность и уменьшить влияние TOAST. Также дают пару советов: всегда использовать JSONB и никогда не хранить в нём ID.
А для желающих по хардкору погрузиться в кишочки ещё одна статья. Автор закатывает рукава и лезет вглубь TOAST, рассказывает алгоритм его работы и предлагает конкретный подход с бенчмарками для улучшения самого TOAST.
#skills #database
Хабр
Проклятье TOAST и с каким маслом его ест JSONB
О роли формата JSON в эволюции реляционных баз данных я недавно рассказал на двух конференциях — HighLoad++ и Saint HighLoad++ 2021. А также о том, что мешает эффективно использовать JSONB (бинарный...
🔥8👍4❤3⚡1😁1
Работа с памятью
На практике редко приходится работать с памятью напрямую, но под капотом компьютер шуршит шестерёнками — выделяет и освобождает память.
Познавательная статья с очень качественной визуализацией, посвящённая основам работы с памятью.
Автор рассказывает базовые концепции, как выделяется и как освобождается память, затрагивает проблему фрагментации, утечки памяти, и другие причины полнейших крахов, от которых мы не защищены.
#skills
На практике редко приходится работать с памятью напрямую, но под капотом компьютер шуршит шестерёнками — выделяет и освобождает память.
Познавательная статья с очень качественной визуализацией, посвящённая основам работы с памятью.
Автор рассказывает базовые концепции, как выделяется и как освобождается память, затрагивает проблему фрагментации, утечки памяти, и другие причины полнейших крахов, от которых мы не защищены.
#skills
❤10👍3🌭2
Сам читаю недавно, но уже хочется посоветовать живой и приятный канал Николая Хитрова о разработке на python.
Автор пишет много практических постов о разработке, например, пост о логировании или какие нюансики стоит знать, внедряя loguru. Периодически поток информации разбавляется юмором. А ещё узнал из этого канала об интересной такой утилите deptry.
Автор пишет много практических постов о разработке, например, пост о логировании или какие нюансики стоит знать, внедряя loguru. Периодически поток информации разбавляется юмором. А ещё узнал из этого канала об интересной такой утилите deptry.
Telegram
Николай Хитров | Блог
Личный бложик про IT новости, инструменты из мира python и различные методологии по типу DDD, TDD, OOP vs FP и прочие модные абревиатуры
Tg: @nkhitrov
Github: https://github.com/nkhitrov
Tg: @nkhitrov
Github: https://github.com/nkhitrov
👍6❤5🔥2
Пятничное развлекательное
Мы уже говорили о Роберте Сапольски. Хочется порекомендовать ещё одну захватывающую лекцию. На этот раз о религии. Просто послушайте и делайте выводы сами.
А кто хочет лёгкого и интересного чтения обратите внимание на его книгу о жизни и работе в Африке – Записки примата. Необычайная жизнь ученого среди павианов. Путешествия по континенту, исследование влияния стресса на другие биологические показатели, быт местных племен.
#fun #books
Мы уже говорили о Роберте Сапольски. Хочется порекомендовать ещё одну захватывающую лекцию. На этот раз о религии. Просто послушайте и делайте выводы сами.
А кто хочет лёгкого и интересного чтения обратите внимание на его книгу о жизни и работе в Африке – Записки примата. Необычайная жизнь ученого среди павианов. Путешествия по континенту, исследование влияния стресса на другие биологические показатели, быт местных племен.
#fun #books
Telegram
DevFM
Пятничное развлекательное
Хочется порекомендовать замечательный курс для небиологов от Стэнфордского университета Биология поведения человека, который ведет Роберт Сапольски. Курс аж на 27 лекций будет интересен увлекающимся подобной тематикой.
И абсолютно…
Хочется порекомендовать замечательный курс для небиологов от Стэнфордского университета Биология поведения человека, который ведет Роберт Сапольски. Курс аж на 27 лекций будет интересен увлекающимся подобной тематикой.
И абсолютно…
👍8❤2🌭2
Backup: май
Архитектура проекта
1. Load balancing
2. Zero-Downtime Deployments with Docker Compose
3. Как проектировать микросервисы
4. Кеширование на бекенде
5. Асинхронное взаимодействие сервисов с применением Kafka
Копаем вглубь
1. Пагинируем по-всякому
2. Как работает ChatGPT
3. Попробуйте HTMX
4. Работа с памятью
Базы данных
1. О производительности Postgres
2. TOAST – проблемы откуда не ждали
Разное
1. Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло
2. Роберт Сапольски — Биология религиозности
3. Вы, конечно, шутите, мистер Фейнман!
4. Сравниваем лампы и батарейки
Если пропустили, то подборка за апрель.
#backup
Архитектура проекта
1. Load balancing
2. Zero-Downtime Deployments with Docker Compose
3. Как проектировать микросервисы
4. Кеширование на бекенде
5. Асинхронное взаимодействие сервисов с применением Kafka
Копаем вглубь
1. Пагинируем по-всякому
2. Как работает ChatGPT
3. Попробуйте HTMX
4. Работа с памятью
Базы данных
1. О производительности Postgres
2. TOAST – проблемы откуда не ждали
Разное
1. Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло
2. Роберт Сапольски — Биология религиозности
3. Вы, конечно, шутите, мистер Фейнман!
4. Сравниваем лампы и батарейки
Если пропустили, то подборка за апрель.
#backup
🔥7❤2👍2
Попробуйте ruff
Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.
Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.
Мы уже сделали для себя конфиг и испробовали его на одном из сервисов. Полёт нормальный, ощущения только положительные.
Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff
Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.
#python
Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.
Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.
Мы уже сделали для себя конфиг и испробовали его на одном из сервисов. Полёт нормальный, ощущения только положительные.
Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff
Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.
#python
Telegram
DevFM
Делаем код мягким и шелковистым
Мы уже говорили об утилите pre-commit, которая автоматизирует рутинный запуск анализаторов кода и не позволяет сделать коммит, пока проблемы не будут исправлены.
Теперь расскажем о тех утилитах, которые применяются в каждом…
Мы уже говорили об утилите pre-commit, которая автоматизирует рутинный запуск анализаторов кода и не позволяет сделать коммит, пока проблемы не будут исправлены.
Теперь расскажем о тех утилитах, которые применяются в каждом…
👍9🔥6❤3
Управление данными в микросервисах
В микросервисной архитектуре у каждого сервиса обычно своя база данных. Для организации доступа одного сервиса к данным другого сервиса нужно либо каждый раз делать запрос к сервису, ответственному за данные, либо иметь копию нужных данных. И тут важен баланс.
Например, у нас есть сервис, который хранит и обслуживает актуальный справочник городов. А навигационный сервис предоставляет информацию о маршрутах общественного транспорта в выбранном городе. Как правильно организовать доступ навигационного сервиса к справочнику городов?
В статье автор рассказывает о способах управления данными в микросервисной архитектуре:
– Дублирование мастер-систем. Каждый сервис хранит и поддерживает данные независимо друг от друга
– API. Сервис, ответственный за данные, предоставляет доступ к данным по API другим сервисам
– DWH. Сервис, ответственный за данные, сливает их в единое хранилище, а другие сервисы имеют доступ к хранилищу
– Очереди. Сервис, ответственный за данные, публикует информацию обо всех изменениях в очередь. А другие сервисы, считывая данные из очереди, хранят на своей стороне и актуализируют.
По каждому способу автор рассказывает о достоинствах и недостатках. Подробнее останавливается на последнем, как на наиболее интересном, и рассказывает о нюансах реализации.
Способ через очереди мне особенно нравится тем, что позволяет делать сервисы более независимыми, хотя он, конечно, более трудозатратный.
#systemdesign
В микросервисной архитектуре у каждого сервиса обычно своя база данных. Для организации доступа одного сервиса к данным другого сервиса нужно либо каждый раз делать запрос к сервису, ответственному за данные, либо иметь копию нужных данных. И тут важен баланс.
Например, у нас есть сервис, который хранит и обслуживает актуальный справочник городов. А навигационный сервис предоставляет информацию о маршрутах общественного транспорта в выбранном городе. Как правильно организовать доступ навигационного сервиса к справочнику городов?
В статье автор рассказывает о способах управления данными в микросервисной архитектуре:
– Дублирование мастер-систем. Каждый сервис хранит и поддерживает данные независимо друг от друга
– API. Сервис, ответственный за данные, предоставляет доступ к данным по API другим сервисам
– DWH. Сервис, ответственный за данные, сливает их в единое хранилище, а другие сервисы имеют доступ к хранилищу
– Очереди. Сервис, ответственный за данные, публикует информацию обо всех изменениях в очередь. А другие сервисы, считывая данные из очереди, хранят на своей стороне и актуализируют.
По каждому способу автор рассказывает о достоинствах и недостатках. Подробнее останавливается на последнем, как на наиболее интересном, и рассказывает о нюансах реализации.
Способ через очереди мне особенно нравится тем, что позволяет делать сервисы более независимыми, хотя он, конечно, более трудозатратный.
#systemdesign
👍6🔥3🌭3
За что мы любим командную строку
В повседневной деятельности мы активно применяем командную строку. Иногда слышим вопросы о том, зачем это вообще нужно, вроде и без неё все хорошо? Этот вопрос вполне логичен, если не погружался в эту тему, не пытался решать реальные задачи.
На хабре мы написали лёгкую статью, где на примерах рассказали, за что мы любим командную строку. Профессиональный навык работы с командной строкой – один из шагов к 10х программисту.
В повседневной деятельности мы активно применяем командную строку. Иногда слышим вопросы о том, зачем это вообще нужно, вроде и без неё все хорошо? Этот вопрос вполне логичен, если не погружался в эту тему, не пытался решать реальные задачи.
На хабре мы написали лёгкую статью, где на примерах рассказали, за что мы любим командную строку. Профессиональный навык работы с командной строкой – один из шагов к 10х программисту.
❤7🌭5🔥3