А потом на выходных опять бекенд, фронтенд

Новые новости из мира микросервисов.

Владельцы сервиса не могут понять, как называется их сервис. В одном конфиге так, в глоб реестре сервисов так, на деплоях по другому.

Уже 5 человек пытаются распутать эту #саксес_сториз

Давно не было, сегодня #полезняшки о КАФКЕ

https://github.com/edenhill/kafkacat - Generic command line non-JVM Apache Kafka producer and consumer - эту штуку даже на недавнем Kafka Summit в Лондоне рекламировали

https://github.com/fede1024/kafka-view - Kafka web UI да еще и на расте

https://github.com/linkedin/Burrow - тулза от авторов(или уже нет) для мониторинга лага. Правда порой баги и алёрты с неё ловили :(

https://github.com/birdayz/kaf и альтернатива первому, но уже на го, а не си

Сегодня на еженедельное демо позвали ХРшу(тимлид позвал), посмотреть как мы работаем, чем занимаемся.

В течении часа ей пришлось смотреть на WireShark, непонятные диаграмммы Service Mesh, слушать про миграцию сервисом на новые VM и делать вид, что понимает шутки на ответ из curl-a.

Боюсь теперь знать, какой фидбек она напишет о нас.

Как остаться видимым на мастере с 2016, пособие.

Достаточно закомитить лишнюю строку и с большой доле вероятности всем будет пофиг :D

Сегодня с автором @golangdigest разгорелся диалог, когда нужно давать интерфейс для логгера? (Речь о го, но офкорс применимо к остальным)

И вот итог:
- если у вас приложение(консольное, десктопное), то тут передача логгера ни к чему(кэп). Хватит параметра для файлика куда писать
- вебсервис почти тоже самое, либо пишите локально, а потом другой инструмент собирает, либо по сети куда-то туда(опять кэп). Тут только вопрос - жсон или тхт. Тут одного верного ответа не будет, зависит от фирмы/команды/требований. Но я бы начинал с тхт.
- но если у вас либа, вот тут интересно.

Если судьба дала вам сделать простенькую библиотеку с коротким жизненным циклом(какая-то математика, парсилка или клиент к бд), то обвешиваться логгером и продумыванием его методов нет смысла, пользователю либы лог ничего не даст(в большом большинстве случаев).

А вот если срок жизни больше(читай как клиент Consul, агрегатор событий, и все в таком духе), тот тут уже стоит дать возможность логгировать так, как захочет страдалец/ваш пользователь. Лишний раз узнать, что соединение с консулом отпало про причине ххх никому лишней не будет.

Такие дела, готов спорить до вашего посинения.

А что такое песок? да этож silicon dioxide (диоксид кремния), а кремний это...правильно, процессоры!

Красиво-то как. Да и пикча справедливая.

История почти повторилась. Пришел в столовку поесть(общая для бизнес центра), сел за рандомный столик, ко мне подсела парочка топманагеров из нашей фирмы.

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

Кстати по этой причине коупные фирмы аля гугл, мс, интел и тд делают столовые внутри, чтобы языкастые сотрудники лишний раз не сливали годноту.

Все таки social engineering это неубиваемая ветвь дыр в безопасности.

Вроде и пятница, а утром начинается с алертов, потому что кафка на тестовом окружение шлёпнулась, а тима отвечающая за её работоспособность не реагировала.

*Click* noice

Самое весёлое, что разница в количестве прикладных(бизнес) программистов и тех, кто строит экосистему неразумно большое. Что очевидно и грустно одновременно.

Хм, это получается сегодня-вчера-позавчера полгода с момента создания блога, о как время флашнулось 🎉

Как это прекрасно. Можно получить курловую команду прям из хрома. Будь здоров тот человек, что решил добавить эту фичу <3

У меня уже пару недель крутится назойливая мысль, и сейчас появился еще один повод её озвучить.

Надо делать чаще 'kill -9'-like по своим сервисам. Все.

В чем соль? Конечно же не надо убивать БД, кеши(?), очереди и ЛБ, ну давайте честно, не каждый согласится на такой chaos testing (хотя вещь полезная и нужная).
Но в большинстве случаев/сервисов их надо не бояться дропать и рестартовать.
Многие это делают неохотно, часто даже с паникой в глазах это выслушивают, но на самом деле, все важные данные уже лежат в других (желательно) неубиванмых местах (бд, очередь, и иногда кеш).

Любой сервис, которые занимается только обработкой не имеет аргумента быть долгоживучим.
Если есть graceful restart, нет супер требований на низкий латенси и кеш-хит (го честно, не все пишут такие вещи), то убить и запустить сервис вопрос желания.

В одном проекте текут файлдескрипторы, и проще сделать рестарт раз в неделю, чем разбираться что там (хотя и написано хорошо все).
У одного из друзей течет память, не сильно, но за пару дней заметно боявляется +50 мб. Бах и проблемы нет, pagetduty молчит, а тасочка на будущее висит.
Или тот же гуру хайлоада на жаве Martin Thompson, они свои сервисы биржи убивают вечером и запускают по новой. Сомневаться в качестве его кода я не решусь, но это практику они применяют.

Короч в личных проектах, перед выходом на рид прод, я определенно потрачу полтора дня, чтобы можно было кильнуть любой компонент продукта.
Должно будет когда-то помочь. Change my mind.

По поводу private[this]. Это 'access qualifiers' в скалочке.

То есть можно дать доступ к полю, только для самого инстанса объекта. Эдакий ООП на максималках:

class Foo {
    private[this] def isFoo = true

    def doFoo(other: Foo) {
        if (other.isFoo) {  // this line won't compile
            // ...
        }
    }
}

Больше примеров https://www.jesperdj.com/2016/01/08/scala-access-modifiers-and-qualifiers-in-detail/

Кстати, в каких языках еще такое есть? 🤔

ААААААААА
Я ПРОПУСТИЛ НОВЫЕ СИНГЛЫ BLACK KEYS

Оказывается еще и новый альбом в конце июня!

И да, уже 5 лет пролетело с последнего альбома, боюсь ретроспективу своей жизни делать за этот период.

Хм, а поскидывайте музыку, которая вам нравится, чего таить -> @olegkovalov

(название песни и мое вероисповедание - чистое совпадение, я не троль)
https://www.youtube.com/watch?v=TCYsY5B8hcQ