Forwarded from Записки админа
📝 Коротко о том, что такое path юниты, и как с помощью systemd можно мониторить файлы в системе. https://www.redhat.com/sysadmin/introduction-path-units
#systemd #будничное #напочитать
#systemd #будничное #напочитать
Есть ли у вас DDD на проде
Anonymous Poll
18%
Да, на POCO/POJO/еще каком-то Plain old ...
7%
Да, на специальном фреймворке
68%
Нет и не пробовали
7%
Пробовали, не зашло
Forwarded from Записки админа
⚙️ Любители sed'а, тут для вас интересное принесли - sed дебаггер - https://aurelio.net/projects/sedsed/ Занятная штука, попробуйте надосуге. 🙂
#bash #sed #фидбечат
#bash #sed #фидбечат
Forwarded from Хекслет
Есть что-то в программировании красивое и завораживающее. Особенно, когда это круто визуализировано.
50+ алгоритмов сортировки за полчаса: https://youtu.be/FZ8FaztJGEo
50+ алгоритмов сортировки за полчаса: https://youtu.be/FZ8FaztJGEo
YouTube
50+ Sorts, Visualized - Linked Disparity Dots
Visit our community Discord: https://discord.gg/thestudio
Okay, I know I said I would be done with sorting for a while, but I did have a couple of extra videos lying around. Why not upload them? These are some upgraded visuals from my original sorting videos.…
Okay, I know I said I would be done with sorting for a while, but I did have a couple of extra videos lying around. Why not upload them? These are some upgraded visuals from my original sorting videos.…
Forwarded from Defront — про фронтенд-разработку и не только
Анкита Масанд написала статью про использование API для интернационализации приложений в JS — "New Intl APIs in JavaScript".
API интернационализации живёт в глобальном объекте Intl. В статье рассматривается несколько кейсов, где оно может быть полезно. Например, можно использовать
Intl доступен во всех актуальных браузерах, но полнота имплементации от браузера к браузеру отличается. Например,
Не могу сказать, что в статье содержится исчерпывающая информация по Intl, тем не менее в ней есть хорошие кейсы его использования.
#js #i18n
https://blog.bitsrc.io/new-intl-apis-in-javanoscript-c50dc89d2cf3
API интернационализации живёт в глобальном объекте Intl. В статье рассматривается несколько кейсов, где оно может быть полезно. Например, можно использовать
Intl.RelativeTimeFormat для форматирования относительных дат ("минуту назад", "день назад", "через 10 дней" и т.п.). Intl.ListFormat для форматирования списков (можно использовать списки с конъюнкцией, дизъюнкцией или с обычным перечислением через запятую). Intl.NumberFormat используется для форматирования больших целых чисел (между разрядами числа в русскоязычном формате добавляются пробелы, в англоязычном — запятые). Для форматирования времени и дат используется Intl.DateTimeFormat.Intl доступен во всех актуальных браузерах, но полнота имплементации от браузера к браузеру отличается. Например,
Intl.RelativeTimeFormat не поддерживается в IE11 и Edge.Не могу сказать, что в статье содержится исчерпывающая информация по Intl, тем не менее в ней есть хорошие кейсы его использования.
#js #i18n
https://blog.bitsrc.io/new-intl-apis-in-javanoscript-c50dc89d2cf3
Medium
New Intl APIs in JavaScript
Learn how to use the new Intl object to format data into a specific locale
Forwarded from oleg_log (Oleg Kovalov)
Elements of Programming by Alexander Stepanov and Paul McJones is now free.
Книга чуток математичная, но вдруг кому-то надо. Кстати 2019, то есть самая новенькая.
http://elementsofprogramming.com/
Книга чуток математичная, но вдруг кому-то надо. Кстати 2019, то есть самая новенькая.
http://elementsofprogramming.com/
Ох, люблю я такие блеймы: https://m.habr.com/ru/post/459992/ и все вроде бы по делу и правильно(хоть и не очень своевременно, все уже "сотку" сто лет как обхаяли), но чет все равно смешно
Хабр
ГОСТ Р 57100-2016. Что это было?
В сентябре 2017 года был введён Национальный стандарт Российской Федерации, получивший обозначение ГОСТ Р 57100-2016 (статус указан здесь, текст можно посмотреть тут) (я по простоте буду называть...
I hate overtime
Ох, люблю я такие блеймы: https://m.habr.com/ru/post/459992/ и все вроде бы по делу и правильно(хоть и не очень своевременно, все уже "сотку" сто лет как обхаяли), но чет все равно смешно
Если кто не в курсе, то предистория такая:
во времена позднего палеолита дяденьки задумались как бы описать ландшафт сложных IT систем, что бы понимать что от чего зависит, какие данные откуда куда текут, что где развернуто и т.д. Было много попыток, но щас канонической считается модель Кручтена(ну и куча других, построенных на ее основе). Упомянутый на хабре ISO — адаптация трудов Кручтена, а пресловутая "сотка" — вольный перевод этой адаптации.
ИМХО, сложно было ожидать качества от такого глухого телефона, но тем не менее.
во времена позднего палеолита дяденьки задумались как бы описать ландшафт сложных IT систем, что бы понимать что от чего зависит, какие данные откуда куда текут, что где развернуто и т.д. Было много попыток, но щас канонической считается модель Кручтена(ну и куча других, построенных на ее основе). Упомянутый на хабре ISO — адаптация трудов Кручтена, а пресловутая "сотка" — вольный перевод этой адаптации.
ИМХО, сложно было ожидать качества от такого глухого телефона, но тем не менее.
#azure
У Azure в Azure SQL Database есть такая неприятная вещь как DTU: это некий попугай, измеряющий нагрузку на базу. Самое неприятное, что при прайс-модели в DTU(есть еще нормальный vCore, но за конский ценник) при привышении DTU-лимита ваши запросы к базе просто не будут обрабатываться.
Что такое DTU и как это посчитать\сконвертировать в обычные mcpu\iops'ы инфы тащем-то нету, но опытным путем было установлено, что огибающая DTU-графика совпадает с наиболее загруженной подсистемой базы. Т.е. если вы насилуете CPU, то DTU будет вести себя как CPU, а если диски в полке, то в полке будет и DTU.
Замониторить этот ад можно только ажуровскими средствами(как ажуровский мониторнг подружить с промом мы чет так и не разобрались)
Вобщем боль, ужас и бесперспективняк.
И вот тут дядя, наконец-то более-менее адекватно описал что и как с Azure'вским, прости господи, DBaaS'ом
У Azure в Azure SQL Database есть такая неприятная вещь как DTU: это некий попугай, измеряющий нагрузку на базу. Самое неприятное, что при прайс-модели в DTU(есть еще нормальный vCore, но за конский ценник) при привышении DTU-лимита ваши запросы к базе просто не будут обрабатываться.
Что такое DTU и как это посчитать\сконвертировать в обычные mcpu\iops'ы инфы тащем-то нету, но опытным путем было установлено, что огибающая DTU-графика совпадает с наиболее загруженной подсистемой базы. Т.е. если вы насилуете CPU, то DTU будет вести себя как CPU, а если диски в полке, то в полке будет и DTU.
Замониторить этот ад можно только ажуровскими средствами(как ажуровский мониторнг подружить с промом мы чет так и не разобрались)
Вобщем боль, ужас и бесперспективняк.
И вот тут дядя, наконец-то более-менее адекватно описал что и как с Azure'вским, прости господи, DBaaS'ом
Ballard Chalmers
Azure SQL Database DTU Versus vCore - Ballard Chalmers
This article by Microsoft MVP Arun Sirpal will compare at a high level the very different options of Azure SQL DTU versus vCore.
#database
Для тех кто как и я долго пытается найти тулзы для рисования схем базенок, расскажу про свой топ тулзов:
1. Очень долго пользовался штукой, которая называется vertabelo Из плюсов: красивые диаграмки, генерит норм скуль. Из минусов: коооонский ценник и небольшие проблемы с экспортом уже имеющихся базенок
2. Новая штука, которую еще не успел толком попробовать, но первые впечатления хорошие! Умеет все что и предыдущая, но есть Free-план и нормальный экспорт(правда не всех диалектов, но ребята работают над этим)
3. SSMS(великий и ужастный). Из плюсов: очень тесно связан с базой, так что все отрисованное моментально отображается на схему и обратно. Из минусов: жуткий UX и только SQLServer
Для тех кто как и я долго пытается найти тулзы для рисования схем базенок, расскажу про свой топ тулзов:
1. Очень долго пользовался штукой, которая называется vertabelo Из плюсов: красивые диаграмки, генерит норм скуль. Из минусов: коооонский ценник и небольшие проблемы с экспортом уже имеющихся базенок
2. Новая штука, которую еще не успел толком попробовать, но первые впечатления хорошие! Умеет все что и предыдущая, но есть Free-план и нормальный экспорт(правда не всех диалектов, но ребята работают над этим)
3. SSMS(великий и ужастный). Из плюсов: очень тесно связан с базой, так что все отрисованное моментально отображается на схему и обратно. Из минусов: жуткий UX и только SQLServer
Forwarded from Записки админа
ℹ️ Очень крутой, и регулярно обновляемый FAQ по Fedora. Всех, кто с этим дистрибутивом начинает знакомиться, можно смело отправлять по ссылке: https://russianfedora.github.io/FAQ/
#fedora #будничное #линк
#fedora #будничное #линк
Forwarded from dd if=/dev/stuff of=/dev/tg
Финальная компиляция #monadicmonday за июль на dev.to:
https://dev.to/ybogomolov/monadicmonday-compilation-july-4pal
https://dev.to/ybogomolov/monadicmonday-compilation-july-4pal
DEV Community
#MonadicMonday compilation: July
Recently I started a small activity in Twitter called #monadicmonday – each Monday I post a thread ab...
Forwarded from Dmitry Sh
Очередной доклад нашего техдира про Kubernetes, а если точнее — про управление ресурсами и автомасштабирование — в нашем блоге (https://habr.com/ru/company/flant/blog/459326) и на YouTube (https://www.youtube.com/watch?v=10ZR-fbyuSY).
Хабр
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)
27 апреля на конференции Стачка-2019, в рамках секции «DevOps», прозвучал доклад «Автомасштабирование и управление ресурсами в Kubernetes». В нём рассказывается о том, как с помощью K8s обеспечить...
#ux
Очень полезная штука https://m.habr.com/ru/post/459054/ при анализе UX(разумеется, если все детские проблемы уже порешали)
Очень полезная штука https://m.habr.com/ru/post/459054/ при анализе UX(разумеется, если все детские проблемы уже порешали)
Хабр
Тепловая карта кликов — как пользователи ведут себя на сайте
Сегодня у нас в руках множество инструментов, исследований и статей по ux/ui и том как сайт будут читать и идентифицировать. Но главный вопрос остаётся открытым. А знаете ли именно вы, куда...
#frontend
Как-то пропустил очередной пост от Фаулера про микрофронтенд(фронтендовые микросервисы) https://martinfowler.com/articles/micro-frontends.html#TheExampleInDetail
Как по мне очень не однозначная идея. Ваще не понятно в чем бенефит по сравнению с feature slices + atomic design, зато вопрос "как это интегрировать" встает очень остро. Да, там предложены несколько вариантов, но что-то ни один не впечатлил
Как-то пропустил очередной пост от Фаулера про микрофронтенд(фронтендовые микросервисы) https://martinfowler.com/articles/micro-frontends.html#TheExampleInDetail
Как по мне очень не однозначная идея. Ваще не понятно в чем бенефит по сравнению с feature slices + atomic design, зато вопрос "как это интегрировать" встает очень остро. Да, там предложены несколько вариантов, но что-то ни один не впечатлил
martinfowler.com
Micro Frontends
How to split up your large, complex, frontend codebases into simple, composable, independently deliverable apps.
Forwarded from DevOps Deflope News
Стали доступны видео с SREcon19 Asia/Pacific 🎉
http://amp.gs/rlc5
И саммари по конференции в трех частях
http://amp.gs/rl6I http://amp.gs/rl6z http://amp.gs/rl6Y
P.S. А еще появились видео с ContainerDays 2019 🐳 http://amp.gs/rlc6
#srecon #videos
http://amp.gs/rlc5
И саммари по конференции в трех частях
http://amp.gs/rl6I http://amp.gs/rl6z http://amp.gs/rl6Y
P.S. А еще появились видео с ContainerDays 2019 🐳 http://amp.gs/rlc6
#srecon #videos
USENIX
SREcon19 Asia/Pacific Conference Program
Forwarded from AvitoTech
This media is not supported in your browser
VIEW IN TELEGRAM
Что такое Zero Bug Policy и зачем эту политику стоит внедрять у себя?
Короткий ответ — в нашем видео. Подробнее о Zero Bug Policy — в нашем блоге на Хабре: bit.ly/z0bpc
Короткий ответ — в нашем видео. Подробнее о Zero Bug Policy — в нашем блоге на Хабре: bit.ly/z0bpc
#messaging #arch
CAP vs exactly once
Как-то так получается, что на каждой галере приходится объяснять коллегам почему ни один message broker не умеет в exactly once и что не стоит ждать чуда от магической очереди, которая придет и подарит все те же гарантии, что и in-proc, при этом размазав нагрузку и сделав всё остальное, что мы там ждем от мессаджинга. Оставлю кэп-пост тут, если кому пригодится -- велкам
Ок, поехали, если нет exactly once, то что есть? Есть at most once, когда нам ок потерять сообщеньку, но дубли не допустимы и at least once, когда, наоборот, ок задублировать, но не ок потерять.
Как это работает: есть 2 стула push и pull, при первом сообщенька заталкивается консьюмеру и консьюмер рапортует, что он ее получил. На втором стуле консьюмер сам читает батчами и иногда говорит, что вот до сюда я отработал. Суть на самом деле в том, что брокер всегда ждет от консьюмера(ов) отмашки о том, запроцессил ли он сообщения или нет, и если нет, то принимается решение на основании установленной at * once политики.
Вернемся к exactly once. Какие же брокеры мы любим? Правильно, персистентные! Поэтому систему брокер-консьюмер можно представить в виде 2 хранилищ, которые надо держать строго консистентными при политике exactly once. А вот тут и всплывает CAP, который говорит, что в распределенных системах мы можем всегда расчитывать либо на доступность, либо на строгую консистентность. Недоступный брокер нам вряд-ли подходит(очередь останавливается, если какая-то сообщенька не обработана консьюмером), так что останавливаемся на AP-схеме. Что это значит применительно к гарантиям доставки: пусть сообщенька была успешно обработана подписчиком, но, по какой-то причине, сообщение о успешной обработке не было получено брокером. Что в этом случае будет делать брокер? Можно либо понадеяться, что сообщение доставлено, либо перепослать. Если перепослали, то нарушаем exactly once и получаем at least once, если оставляем, то теряем сообщение на аналогичном кейсе, где консьюмер все-таки не смог обработать сообщение, но получаем at most once.
На закуску, увлекательное чтиво про разные типы консистентности на примере бейсбола(правила знать не надо, там объяснят)
CAP vs exactly once
Как-то так получается, что на каждой галере приходится объяснять коллегам почему ни один message broker не умеет в exactly once и что не стоит ждать чуда от магической очереди, которая придет и подарит все те же гарантии, что и in-proc, при этом размазав нагрузку и сделав всё остальное, что мы там ждем от мессаджинга. Оставлю кэп-пост тут, если кому пригодится -- велкам
Ок, поехали, если нет exactly once, то что есть? Есть at most once, когда нам ок потерять сообщеньку, но дубли не допустимы и at least once, когда, наоборот, ок задублировать, но не ок потерять.
Как это работает: есть 2 стула push и pull, при первом сообщенька заталкивается консьюмеру и консьюмер рапортует, что он ее получил. На втором стуле консьюмер сам читает батчами и иногда говорит, что вот до сюда я отработал. Суть на самом деле в том, что брокер всегда ждет от консьюмера(ов) отмашки о том, запроцессил ли он сообщения или нет, и если нет, то принимается решение на основании установленной at * once политики.
Вернемся к exactly once. Какие же брокеры мы любим? Правильно, персистентные! Поэтому систему брокер-консьюмер можно представить в виде 2 хранилищ, которые надо держать строго консистентными при политике exactly once. А вот тут и всплывает CAP, который говорит, что в распределенных системах мы можем всегда расчитывать либо на доступность, либо на строгую консистентность. Недоступный брокер нам вряд-ли подходит(очередь останавливается, если какая-то сообщенька не обработана консьюмером), так что останавливаемся на AP-схеме. Что это значит применительно к гарантиям доставки: пусть сообщенька была успешно обработана подписчиком, но, по какой-то причине, сообщение о успешной обработке не было получено брокером. Что в этом случае будет делать брокер? Можно либо понадеяться, что сообщение доставлено, либо перепослать. Если перепослали, то нарушаем exactly once и получаем at least once, если оставляем, то теряем сообщение на аналогичном кейсе, где консьюмер все-таки не смог обработать сообщение, но получаем at most once.
На закуску, увлекательное чтиво про разные типы консистентности на примере бейсбола(правила знать не надо, там объяснят)
Forwarded from AvitoTech
Как использовать стендбай в PostgreSQL
Константин Евтеев рассказывает в нашем англоязычном блоге на Медиуме о различных вариантах использования и конфигурации standby сервера.
В статье:
1️⃣ горизонтальное масштабирование с помощью репликации;
2️⃣ как использовать реплику для чтения и избежать stale reads;
3️⃣ возможные проблемы и решения при использовании стендбая с большим количеством запросов, применение DDL, отправка большого количества WAL-файлов в архив и восстановление из архива;
4️⃣ использование пула стендбаев и переключения запросов между ними;
5️⃣ восстановление после аварий с приведением в согласованное состояние мастера, стендбаев и архива.
Почитайте, если интересуетесь темой: http://bit.ly/2JO2sGW
Константин Евтеев рассказывает в нашем англоязычном блоге на Медиуме о различных вариантах использования и конфигурации standby сервера.
В статье:
1️⃣ горизонтальное масштабирование с помощью репликации;
2️⃣ как использовать реплику для чтения и избежать stale reads;
3️⃣ возможные проблемы и решения при использовании стендбая с большим количеством запросов, применение DDL, отправка большого количества WAL-файлов в архив и восстановление из архива;
4️⃣ использование пула стендбаев и переключения запросов между ними;
5️⃣ восстановление после аварий с приведением в согласованное состояние мастера, стендбаев и архива.
Почитайте, если интересуетесь темой: http://bit.ly/2JO2sGW
I hate overtime
Котаны, со времен первой версии SUnit и изобретения юнит-тестирования как такового(а это конец 80х годов, на секундочку) не утихают холивары из серии "TDD-only vs юнит-тесты нинужны". И вот, пока ничего интересного не происходит, я тоже слегка наброшу на вентилятор.…
#testing
Нашел тут очень сочный, но, походу, мертвый блог царя тестирования. И сразу же статья про unit vs integration testing: http://barancev.github.io/why-unit-tests-dont-catch-bugs/
Нашел тут очень сочный, но, походу, мертвый блог царя тестирования. И сразу же статья про unit vs integration testing: http://barancev.github.io/why-unit-tests-dont-catch-bugs/
А хотите, я расскажу вам...
...почему модульные тесты пропускают баги?
Потому что покрытие кода это слишком грубая метрика, а из правильно работающих модулей можно собрать неправильно работающую систему.