Интересно смотреть, как компьютер учится решать те или иные задачи.
Отличный видос для пятничного вечера, как обучали AI проходить старый добрый Pokemon Red:

https://youtube.com/watch?v=DcYLT37ImBY

В комплекте — увлекательная борьба за правильную модель подкрепления, травматический опыт, метрики и даже исходники.

Приколитесь: немцы снифали и расшифровывали зашифрованный трафик на серверах jabber.ru в датацентре Hetzner.

Выпустили отдельный SSL сертификат и проксировали коннекты к TCP:5222. Ого! Вскрылось случайно из-за ошибки их админов. Если бы не эта ошибка, скорее всего, так никто бы и не заметил.

Скорее всего это правительственная атака и хостеров просто обязали накручивать эти редиректы. Интересно сколько таких джаббер серверов прослушивается в данный момент. Ведь кулхацкеры скамеры чаще всего используют именно джаббер. Еще один эпизод оправдывающий параною красноглазых криптоманьяков.

Мораль:

1. Проверяйте фингерпринты сертификатов даже если лень.

2. Безопаснее E2E шифрования ничего не придумали, но и там всем лень проверять отпечатки ключей.

Лично мне больше все нравится подход Телеграм с 4 эмоджи в качестве отпечатка ключа, это не сложно сверить при звонке.

Пост на HN: https://news.ycombinator.com/item?id=37955264

Само расследование https://notes.valdikss.org.ru/jabber.ru-mitm/

Дейлики.
Ну — те самые дейлики, где один говорит, а несколько человек изображают что внимательно его слушают, но неизбежно занимаются другими делами.
По идее мы обсуждаем, что сделали, с какими преградами столкнулись, что будем делать, какая помощь нужна.

И разумный человек задаётся вопросом: “А нафига мне вот это всё слушать?”.

Мол, понадобится.

Но позвольте, а что если я верю, что если бы мне это действительно было нужно, я бы и сам вник?
Если мне банально скучно и я достаточно самоуверен?

А ничего, упущу что-то важное как пить дать 🙂

Думаю, именно здесь и кроется одна из тайн успешных дейликов: акцентирование внимания. Вместо того чтобы рассказывать все подряд, нужно явно указывать, кого это касается. "Вася, послушай, это про твой следующий спринт", или "Маша, это твой компонент, будь внимательна".

Когда сообщение напрямую связано с конкретным участником команды, дейлики перестают быть рутиной. Они становятся мостом, который соединяет задачи и ресурсы. Они действительно становятся инструментом, а не просто обязательной процедурой.

Давайте делать статус-встречи осмысленными!

Многие знают, что числа с плавающей запятой нельзя сравнивать простым равенством.
То есть если есть условно


b=0.3-0.1


Нельзя потом делать


if (0.2 == b)


и надеяться на адекватный результат.

Нужно делать


if ((0.199<b) and (b<0.201))


Это связано с тем, как хранятся такие числа в памяти.

А как правильно производить сравнение дат?
(говорим про языки без строгой типизации)

Вариант №2, в котором мы пишем ДД.ММ.ГГГГ — он для наркоманов. Верю, что все, кто ткнул в него просто хотели рандомно во что-то ткнуть, чтобы посмотреть ответы. Или пошутили.
Ну пожалуйста.

Фактически, выбор есть только между вариантами №3 и №4.
Теоретически (раз в условии сказано "сравнение дат") мог бы подойти вариант №3. Не сказано же "дата и время". И вообще у нас параметр строкой передаётся, должны же быть какие-то валидаторы, ну я не знаю.

Но на практике, даже если вы обмазались всеми возможными соглашениями, рано или поздно там, где дата — её сравнят с датой-временем. И если вы используете вариант №3 — все mydate вида 2023-01-31 15:55:00 пролетят мимо вашего условия.
"До конца января" — это всегда 2023-01-31 23:59:59.

Ну и в комментах к посту есть интересные заходы. В частности, конечно, про таймзоны 🙂 Ведь если вам сказали "выбери записи, которые сделаны до конца января 2023" нужно очень чётко понимать — в какой таймзоне этот конец января наступает.

Скоро выступаю на конференции KnowledgeConf 2023, которая пройдёт в рамках TeamLeadConf 2023. Если тоже будете там — давайте встретимся!

Когда-то я столкнулся с задачей создания базы знаний по DevOps с нуля. Начальник хотел превратить ее в коммерческий продукт, но предоставил примерно ноль ресурсов и поддержки.

Подход компании был странным: они начали фокусироваться на структуре и оформлении, но не на содержании. Прям скажем, я был взволнован, когда увидел пустой репозиторий с "правилами оформления", но без, собственно, содержательных статей.

Для успешного создания базы знаний сначала определите ее цели и задачи. Начните с написания статей по частым проблемам, начинайте внедрять и реально использовать и развивайте их, опираясь на обратную связь. Начните с написания статей.

Базу знаний создать мне удалось. И даже структура была, какую хотело видеть начальство, однако, ее качество и полнота оставляли желать лучшего. Совпадение? Не думаю. Ни о каком коммерческом продукте речь, конечно, уже не шла.

Я пришёл к выводу, что для качественной базы знаний необходимо РЕГУЛЯРНОЕ интервьюирование экспертов и выделение ресурсов. Рассуждать о создании продукта без ресурсов — офигенная, но бессмысленная тема.

Чему я научился? Больше общаться с коллегами по цеху, посещать конференции, чтобы видеть дальше того “как тут принято”. Фокусироваться на скором получении выигрыша вместо строительства идеализированных баз знаний. Не лезть в истории, которые не имеют внятных целей и задач, или если лезть — то хотя бы не расчитывать на результат 🙂

Если вы вдруг не знали — в диалоге с chatgpt можно создавать, например, свободные от лицензий картинки для презентаций.

Можно просить сделать картинки по мотивам вашего примера, переспрашивать, менять стилистику и просить усовершенствовать детали.

Вау, вы посмотрите
https://www.brainboard.co/
Визуальный редактор для terraform!
Сразу и схема, и код! 🧡

Прямо сейчас ваш покорный слуга будет рассказывать в главном зале TeamLeadConf про корпоративный поиск на коленке. Можно бесплатно посмотреть трансляцию главного зала, записываться тут: https://docs.google.com/forms/d/e/1FAIpQLSf24FGEMaXlpHysQKZqVKVxE6-hvKPHgqjKgPCouPfePG726w/viewform

С чего начать расследование инцидента? Приходит к вам коллега и говорит, мол, 502-ые летят, давай, мол, давай, чини скорее!
Может быть с логов? Или с метрик? Может быть найти документацию? Или открыть базу знаний “самые частые обращения”?

Начать надо с того, чтобы проверить слова коллеги. Так уж получается, что все врут.
Пусть покажет, почему он решил, что летят 502-ые. Хоть в режиме шаринга экрана. Может быть он один раз браузером открыл страничку и запаниковал.
Нужно сверить это с имеющимися у тебя инструментами мониторинга. Может быть его инструменты не так хороши, как твои и дадут новый взгляд на ситуацию.
И крайне нужно проверить то, что человек как бы подразумевает, но не проговаривает явно — а какое влияние? Встали продажи? Не работают регистрации? Пользователям-то что с этого?

Люди плохо выражают свои мысли. В кризисные моменты — выражают отвратительно. Кто-то начинает верещать как чайка по любой незначительной фигне. Кто-то просто не знает, что нужно отличать “инцидент на проде” от “расследования в спокойном режиме”. Кто-то говорит одно, а подразумевает другое.

Не сжигайте свои нервы на каждое обращение и формулировку, помните, что на другой стороне тоже живые люди, они бывает ошибаются, но с ними можно поговорить, и их можно научить. Чтобы ваша совместная работа была лучше, спокойнее, эффективнее.

Нет ничего более бесполезного, чем делать с большой эффективностью то, что вообще не следует делать.

#Понравилось

Кстати, видео поспело:
https://www.youtube.com/watch?v=RliDj4kWUa8

Мы тут с chatgpt сделали новогодний фон для зум-созвонов. Атмосферненький.
С неизбежно наступающим, коллеги :)

🎄✨ Новый Год на носу, и кажется мы заслужили передышку! 🌟 🎄

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

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

Желаю вам найти идеальный баланс: чтобы строки кода гармонировали с мелодиями жизни, чтобы каждый "коммит" в вашу профессиональную жизнь сопровождался "коммитом" в личное счастье и удовлетворение.

Пусть 2024 год будет как чудом прошедший успешный деплой: никакого стресса, никаких горящих задниц и всё работает! Да будет здоровье как железо, а энергия как бесконечный поток данных.

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

🌟 От всей души желаю вам счастливого Нового Года! Давайте встречать его с радостью и надеждой! 🌟

Возможно как-то так будет выглядеть поиск в новой эпохе
https://www.perplexity.ai/

Отвечает текстом, даёт ссылки на источники, подсказывает связанные вопросы, позволяет чатиться по теме.

Сегодня хочется поговорить о чём-то действительно важном: о получении обратной связи по развитию продукта как можно быстрее.

Как-то раз я познакомился с командой, которая уже 5 лет пилила внутренние проекты силами 4 человек. У них был довольно уютный технический мир, в котором разработчики занимались исключительно кодом, без погружения в цели и "бизнес"-составляющую. И надо сказать, очень много правильных вещей делали: классная архитектура, вылизанный код, подробные тикеты!
Вот только все критичные знания о проекте были в голове овнера и тимлида, а фидбэк от пользователей был максимум в ключе "какого фига не работает?".

Как водится, были и розовые очки: на всём этом висел лейбл "девопс" (ведь ci и iac есть!), а рабочий процесс назывался "гибкой методологией". Гибкая методология в понимании овнера — это когда все его слушаются.

Вот только почему-то когда раз в месяц релизился огромный релиз — пользователи тупо игнорировали нововведения.

Как? Почему? Может пользователи плохие?

Я думаю, что кроме того, чтобы сделать софт — его неплохо бы внедрить. А если же разрыв уже слишком большой, кажется имеет смысл:

- Подтолкнуть команду больше общаться с пользователями, помогать решать прикладные проблемы и отвечать на крики о помощи. Можно даже ввести "дежурства по ответам на вопросы". Команда сделает много открытий для себя ("они что, НАСТОЛЬКО не понимают проекта?") и каждый из разработчиков сам по себе начнёт глубже понимать продукт.
- Вовлекать команду в обсуждения с овнером, чтобы хоть капелька информации попадала в поле их внимания.
- Попытаться договориться с овнером и командой, о том, что надо сместить фокус внимания с доставки новых фич на внедрение этих фич. И вместе сформулировать, как именно это можно сделать.
- В идеале, конечно, добиться от овнера, чтобы он сам начал общаться с пользователями — сначала "продавал" идею будущих изменений, чтобы было ожидание, а затем трекал внедрение.

Я думаю, что если замыкать на себя экспертизу — ни к чему удивляться, что тебя и твои задумки не понимают и не принимают.