OKR 1к до конца мая сделан, всем спасибо 🎉

Нашлась старенькая статья о том, что подсветка комментариев в коде сломана.

Конечно там берется пример джавы с её неразумно ужасными javadoc (см пикчу), но если отойти от коментов документации и использовать комментарии в разумных местах, то они должны быть как раз яркими, чтобы читатель их замечал (подразумевается, что комент не просто так написан). И там чуток про гит дифф.

Я на самом деле не знаю, я согласен с ним или нет. Либо я чаще вижу полезные коменты и у меня нет с этим проблем, либо я рефлекторно скипаю ненужное. Что в общем-то тож самое.

https://jameshfisher.com/2014/05/11/your-syntax-highlighter-is-wrong/

1024 и традиционная загонялка в чат @append_only_log (после джоина пожалуйста представьтесь с #whois)

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

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

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

Уже 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.