Меняю стек. Пока Java, привет Go

https://youtu.be/KH-5CP9Dyng

https://vkvideo.ru/video298358674_456239275

https://rutube.ru/video/47ae89a52da95b05860887029be93814/

Лингво-тренер | График частотности

Добавили график частотности для словарного запаса.

У меня сейчас 2200 уникальных слов, но по графику видно, что реально активно использую всего лишь около 200–300 слов.

Чуть-чуть обогнал Эллочку Людоедку :)

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

Пробуйте @talksharp_bot

Вайб кодинг на Go

Недавно смотрел ролик, который назывался *The Video Coding*. Оказалось, что это новый стиль программирования — программирование через AI.

Когда ролик закончился, я решил, что стоит попробовать. Я уже пробовал так делать с Python, но свой снобизм относительно нового синтаксиса я не смог побороть, поэтому в этот раз решил попробовать с Go.

Я ничего не знал о Go до этого момента.

Идея была такая. Когда мы собираемся на праздник в семейном кругу, то часто играем в игру "Шпион". Смысл игры простой. Запускаем приложение на телефоне, выбираем количество игроков. Приложение генерирует случайное место, например, школа или спортзал. Далее каждый игрок берет телефон и читает это место. Один человек, вместо загаданного места, получает слово "шпион". А потом начинается игра. Каждый игрок по очереди спрашивает других игроков вопросы. Например, если это школа, то можно спросить у бабушки: "А ты давно там была?" А вы знаете, что она там давно не была? Если у нее выпал шпион, то она начинает выдумывать. "Да, я туда хожу каждый день". Когда прошел круг, то игроки голосуют за шпиона.

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

Часа два я просидел над решением этой задачи. Это было тяжело. GPT старался помочь мне сделать эту программу изо всех сил, но каждый раз мне приходилось поправлять или уточнять моменты. В целом вышло так.

Что я кучу времени объяснял AI, что у меня не запустилось и что мне делать, а он радостно накидывал мне варианты, которые тоже не работали.

Итог: чтобы программировать в стиле "вайб кодинга", вы все равно должны владеть темой. Для проектов по Java или Kotlin я использую AI, но больше как генератор начального кода. То есть полученный код я потом допиливаю под свои задачи. В случае с Go я так не смог сделать, потому что его не знаю.

Однако из этого эксперимента я вынес прекрасную возможность немного попробовать Go, что дало мне импульс прочитать *The Tour of Go*.

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

Go, где мое ООП?

В этой статье хотел бы продолжить тему Go.

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

Начну с того, что команда Kotlin решала задачу упрощения синтаксиса языка за счет оберток. Это было необходимое решение, так как им нужно было интегрировать новый язык в экосистему своих Java проектов. Поэтому основной упор они делали на выразительность и гибкость конструкций.

С другой стороны, команда Go не была привязана к поддержанию своих проектов. Я не читал истории создания Go, но это не так важно. Главное, что они пошли другим путем. Они отрезали всё, что можно было отрезать, чтобы язык стал максимально простым.

Например, в Java есть 4 цикла: for, foreach, while, do-while. Добавим сюда .forEach — и получается куча вариативности. В Go есть один цикл for, да ещё и без скобок:

for i <= 10 {
}

Таким образом, они убрали вариативность, а с ней упростили понимание кода. Код во всех проектах будет похожим.

Что же с ООП? Проблема ООП в том, что код получается запутанным. Мы создаём объект контроллера, чтобы в нём хранить объект сервиса, чтобы в нём хранить объект коннектов к базе данных. По сути, это не объекты, а классы-утилиты.

Поэтому Go сразу решили отрезать этот механизм. Они убрали объекты. Есть функции и есть кортежи данных.

Давайте покажу на примере нашего проекта из блока ООП [ссылка на проект](https://job4j.ru/profile/courses/2).

Модель данных Item:

type Item struct {  
    Id   int  
    Name string  
}

Объект Tracker. Опишу его в Java, а затем объясню, как его переделать в Go.

class Tracker {
   private Item[] items;
   
   public void create(Item)
   
   public Item findById(it)
}

В Go переменная и функция привязаны к пакету. Поэтому всё, что нужно — это объявить закрытую переменную в пакете и такие же функции, которые будут работать с этим пакетом.

package tracker  
  
import "errors"  
  
var items []Item  
  
func Add(item Item) {  
    items = append(items, item)  
}  
  
func FindById(id int) (Item, error) {  
    for _, it := range items {  
       if it.Id == id {  
          return it, nil  
       }  
    }  
    return Item{}, errors.New("item not found")  
}

Забавно, что в Kotlin можно так же описать, но я таких проектов не видел.

Интересно, что когда используешь эти функции, нужно обратиться к пакету. А это, по сути, и есть создание объекта tracker.

package main  
  
import (  
    "fmt"  
    "go_tracker/tracker")  
  
func main() {  
    tracker.Add(tracker.Item{Id: 1, Name: "First item"})  
    for _, it := range tracker.FindAll() {  
       fmt.Println(it)  
    }  
}

То есть, ООП тут есть, но в своём первоначальном виде, как это предполагал Алан Кертис. Объекты — это сообщения между функциями, а не данные с методами.

Go кровный брат Kotlin или сестра ))

Честно скажу, что меня зацепил Go своей скоростью компиляции, запуска и независимыми исполняемыми артефактами, которые весят кроху.

Поэтому продолжу тему изучения Go. В предыдущем примере был код:

var items []Item

func Add(item Item) {
    items = append(items, item)
}

У нас есть глобальная переменная items. В чем тут проблема? В том, что теперь я жестко привязан к этому состоянию.

Покажу на примере.

Допустим, у нас есть функция, которая реализует поведение ввода новой задачи.

func createItem() {
    item := Item{}
    fmt.Println("Enter name:")
    fmt.Scanln(&item.Name)
    Add(item)
    fmt.Println("Saved")
}

В данном случае у меня нет возможности как-то повлиять на способ хранения данных. Я жестко завязан на глобальную переменную items.

То есть я не могу изолированно протестировать эту функцию. Какое есть решение?

Принимать объект хранилища как параметр? Но тут же нет объектов! Оказывается, есть)).

Но через синтаксический сахар. В Go есть функции-приемники. Узнаете? Функции расширения в Kotlin.

Сначала нужно описать интерфейс:

type Store interface {
    Add(item Item)
    FindById(id int) (Item, error)
    FindAll() []Item
}

Далее нужно реализовать все эти функции с указанием приемника:

type MemStore struct {
    items []Item
}

func (store *MemStore) Add(item Item) {
    item.Id = len(store.items) + 1
    store.items = append(store.items, item)
}

func (store *MemStore) FindById(id int) (Item, error) {
    for _, it := range store.items {
       if it.Id == id {
          return it, nil
       }
    }
    return Item{}, errors.New("item not found")
}

func (store *MemStore) FindAll() []Item {
    return store.items
}

И осталось поправить функцию создания задачи:

func CreateItem(store Store) {
    item := Item{}
    fmt.Println("Enter name:")
    fmt.Scanln(&item.Name)
    store.Add(item)
    fmt.Println("Saved")
}

Опять же, команда Go отрезала все лишнее. Вам не нужно писать Implement или ставить двоеточие, как в Kotlin.

store := &tracker.MemStore{}

То есть Go поддерживает мультипарадигменность, но с крайне ограниченным набором синтаксиса. То есть нет такого зоопарка, как в Kotlin, и код чище, чем в Java.

Вы также можете наслаждаться TDD, OOD и всеми плюшками ООП, а не страдать от процедурного стиля.

Курс DevOps | Финишная пряма

Добавил уроки по версионированию.

Версии асинхронного API | AsyncAPI [#505396]
Управление конфигурациями | Ansible [#505392]
Работа с бинарными артефактами | Nexus [#505393]
Управление бекапами [#505391]
Интеграция версионирования, бекапов и конфигураций в Jenkins [#505394]

Осталось сделать.
Введение в GitOps [#505397]
Основные принципы и архитектура GitOps [#505398]
ArgoCD [#505399]
Flux [#505400]
Введение в мониторинг и логирование [#505401]
Основы Prometheus [#505402]
Введение в Grafana [#505403]
Введение в ELK (Elasticsearch, Logstash, Kibana) [#505404]
Установка и настройка Elasticsearch [#505405]
Установка и настройка Logstash [#505406]
Установка и настройка Kibana [#505407]
Интеграция Prometheus с ELK [#505408]

12 уроков.

Ребята, кто его брал вижу, что вы проседаете в активности.

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

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

👉 https://job4j.ru/profile/courses/35

Лингво-тренер | С зубрежки в разговор

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

Изначально я использовал классическую схему обучения "Зазубривание слов".
Такой подход отлично применим для коротких целей. Например, сдачи экзамена или подготовки к собеседованию. Но для долговременных задач он не годится. Это связано с тем, что вы не ассоциируете зазубренный материал со своим опытом.

Поэтому я перестал что-либо заучивать и теперь фокусируюсь только на задаче объяснения, то есть на разговорной стороне языка.
Например, если я не могу выразить свою мысль, потому что не знаю, как сказать о событии, которое было в прошлом, но которое продолжается до сих пор, то я иду в грамматический справочник и ищу, как это можно выразить. И теперь я могу выразить свою мысль:
I have been learning for as long as I can remember.

Я добавил в бота @talksharp_bot разделы, чтобы не ломать голову, о чём можно поговорить. Но я стал замечать, что использую один и тот же словарный запас.

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

А значит, нужно подкорректировать и этот подход.
Я наткнулся на канал "Бородатый лингвист" в YouTube (кстати, он сегодня работает без блокировок), и он крайне советовал взять за основу серию книг *English File*.
Я решил взять одну, причем чтобы не торопиться, выбрал уровень А2.

Сразу скажу, что покупать её не нужно, мой посыл — заниматься регулярно.

Вчера я проходил тему про путешествия. Приведу тут нужный материал.


3 ADJECTIVES

a) Match the questions and answers.

1. What was the weather like? It was …
2. What was the hotel like? It was …
3. What was the beach like? It was …
4. What were the people like? They were …

- comfortable, luxurious
- friendly, helpful
- beautiful, lovely
- warm, sunny
- noisy, dirty, uncomfortable
- unfriendly, impolite
- boring, crowded
- very windy, foggy, cloudy

b) 2.8 Positive and negative adjectives

- great, lovely, wonderful, fantastic
- not bad, all right
- awful, horrible, terrible

ACTIVATION
Talk to a partner. Which do you prefer? Why?

1. going on holiday in your own country or going abroad
2. going by car, bus, plane, or train
3. going to the beach or going to a city
4. staying in a hotel (or apartment) or going camping
5. going sightseeing or going skiing
6. going on holiday with friends or going with your family

Блок Activation я проделал через бота @talksharp_bot. Заняло не больше 5 минут. А главное, мне было интересно это делать.

По рейтингу бота я вижу, что пользователи пробуют его использовать, но крайне мало. 50- 100 слов в день. Я занимаюсь регулярно по 5 минут в день - это около 1500 слов, чтобы вам было с чем сравнить.

Попробуйте в этот раз ответить на 6 вопросов из блока Activation. Старайтесь только выразить свои мысли, а не фокусироваться на правильности грамматики.

👉 Пробуйте @talksharp_bot

ITTalkBot | Раздел Go

В целом я планирую добавить все актуальные направления в IT. Сегодня решил накидать вопросы по Go, как раз его сейчас изучаю.

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

👉 Пробуйте @ITTalkBot

GoLang | Лучшие книги

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

Сегодня слушал о книгах по Go от господина Михаила. Классный дядька.
Рекомендую.
https://www.youtube.com/watch?v=a-lYYYr-5a8

Мне нравится, что автор видео разговаривает крайне быстро и эмоционально. Иногда я не понимаю, что он сказал, но зато он часто повторяет такие фразы, и они начинают запоминаться, а из контекста становится понятно, что они значат.

К тому же, к такой скорости языка начинаешь привыкать. И самый кайф — что начинаешь понимать шутки в языке.

Мысли, которые изложил автор видео, совпадают с моим видением изучения программирования.
Кратко изложу:
1. Основы языка. Синтаксис и конструкции легко выучить самостоятельно.
Например, в Go вам хватит 2–3 часов, чтобы пройтись по [Go Tour](https://go.dev/tour/welcome/1).
Поэтому в моем курсе я старался сразу уйти от простого изложения синтаксиса. А что нужно? Нужны принципы: как лучше, как не надо делать, что стоит использовать, а что нет. Это еще по-модному называют идиомами.
2. Effective Go. Аналог Effective Java. Эта книга — о идиомах языка, о том, как нужно и как не нужно. Отличная книга; у меня есть Effective Java, и я приобрету Effective Go.
3. Go 101. Похожая книга на предыдущую, в которой собраны ещё 101 правило о том, как нужно и как не нужно.
4. Concurrency in Go. Тут всё понятно — как в Go работать с многопоточным окружением.
У меня есть аналогичная книга для Java.

Интересно, что он считает, что Go — отличный язык, если вы уже пишете на Java. Вернее, он так и говорит: переход с Java на Go выглядит очень логичным. А куда еще — Rust? Не всем он зайдет, а Go имеет урезанный синтаксис с очевидными конструкциями. Да, там есть свои нюансы, например, с error. Я могу сказать, что в одной из своих статей по проекту [Code Quality Principles](https://github.com/peterarsentev/code_quality_principles) я хотел передавать исключение как объект (Result<T, Exception>), но получилось громоздко. А тут они сами встроили это в язык.

Нет try-catch, нет неожиданных исключений, как в Kotlin; Kotlin не заставляет вас обрабатывать исключения. Понятно, что есть best practices, но всё же.

А тут они сделали всё по-своему:

func ReadFile(path string) (string error)

func main() {
    context, error := ReadFile("application.properties")
    if (error) {
      // TODO
    }
}

Хочешь — обрабатывай, хочешь — отправляй в Kafka, делай что хочешь. Можешь отправить их своей жене.

Или, если вам не нравится JS, то Go — отличный вариант для бэкенд-разработчика.

Подведу итог. Посмотрите видео, добавленное выше. Не ставьте на паузу, посмотрите его целиком. Что-то вы всё равно поймёте. Попробуйте его пересказать нашему боту @talksharp_bot.

GoLang, как первый язык?

Про Go я услышал еще в 2019 году. Я решил посмотреть, почему все трубят о том, что это супер-мега язык.

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

Изначально мы использовали платформу TrackStudio, потом написали всё с нуля на Kotlin. Причем без фреймворков. Проект запускается моментально, но кода приходится писать больше, нежели если бы мы стали использовать Spring. Я к тому, что Kotlin — это отличное решение. Поэтому я решил, что нужно добавить блок о Kotlin в курс тоже.

После этого я задумался, а может стоит брать Kotlin как первый язык? Я стал оценивать, что мне нужно будет переписать: основы синтаксиса, ООП, коллекции, IO, Thread. И вышло, что мне нужно будет рассказать то же самое, плюс добавить объяснение нюансов работы с Kotlin: мультипарадигменность, безопасные типы и т.д. То есть это приводит к усложнению.

Поэтому я отказался от этой идеи. Блок Kotlin я всё же планирую переписать, но с позиции, что хорошо делать, а что не нужно делать. Список таких "почему-чеков" у меня есть. То есть Kotlin с этой позиции выглядит как расширение навыков Java-программиста, не как самостоятельный язык.

В целом, вы уже поняли, какую задачу я пытаюсь решить? Первую версию курса Java я сделал в 2015 году. Она состояла из 25 уроков. Уроки в том же виде, как и сейчас: теория, демонстрация, задания. И это работало. Курс занимал максимум полгода. Сейчас, в 2025 году, в нем 800+ уроков, и время прохождения растянулось на 1-2 года.

Из-за чего так вышло? Во-первых, сам язык Java развивается, а это значит, что мы должны добавлять новые уроки. Во-вторых, в первой версии курса я описывал только то, что необходимо для работы, а не весь синтаксис языка. Например, не было блока IO. Почему? Да потому что его редко используют. Почему нельзя было оставить как есть? Связано это с тем, что нет культуры собеседования. Собеседование превращается в сдачу сертификата по языку, а не в поиск сотрудника, который может решать технические задачи.

Это первый момент. А второй момент — это усложнение архитектуры Enterprise-проектов. Микросервисная архитектура вносит огромное влияние в процесс обучения.

Поэтому, когда я второй раз попробовал Go, то подумал, что это и есть решение моей проблемы. С момента "Hello, World!" до первой версии игры "Шпион" прошло пару часов. То есть за это время я понял, как писать на Go, подключить библиотеку для Telegram, подключить базу данных, подключить Rest API — и это всё заработало. Запускается мгновенно. А что самое главное — в итоге я имею уютный исполняемый файл.

Далее я стал оценивать, что нужно переписать, чтобы с нуля можно было выучить необходимый минимум по Go, чтобы найти работу.

Я буду идти по своему курсу по Java и оценивать, нужен ли этот блок в Go.

Уровень Стажер:
1. Базовый синтаксис. Безусловно нужен.
2. ООП. В Go нет объектов, наследования, но есть интерфейсы и модификаторы доступа, кортежи данных, функции с приемниками. То есть тоже нужно.
3. Коллекции. Есть слайсы и карты.
4. Lambda, Stream API. Go — мультипарадигменный язык, а это значит, что нужно описать, как работать с функциями. То есть тоже нужно.
5. Spring Core. Это не нужно.

Уровень Джуниор:
1. Структуры данных и алгоритмы. Этот блок не относится к языку, поэтому он нужен для любого языка.
2. IO — тоже есть в Go, и он нужен, так как Go часто используют в DevOps.
3. SQL — без вопросов нужен.
4. OOD, TDD, SOLID — универсальные принципы. Остаются.
5. GC. Конечно, оставляем.
6. Алгоритмическая секция. Оставляем, так как её спрашивают на собеседовании.

Уровень Мидл:
1. Git. Безусловно.
2. Thread. Крайне важно. Оставляем.
3. Web. Нужно, так как без этого объяснить, как работают микросервисы с Rest API, нельзя.
4. Hibernate. В топку. Хотя у Go есть решение GORM, но я думаю, что это не важно.
5. Spring Rest API. Безусловно. Echo.
6. Микросервисы. Да, конечно.

Уровень Сеньор:
1. DevOps. Да. Конечно, 100%.

Итого, из курса я убрал два блока: Spring Core, AOP и Hibernate. То есть по времени ничего не поменяется. Зато изменится конъюнктура входа на рынок.

Дело в том, что с языка Go начинают свою карьеру единицы, а 99% — это свитчеры с других языков. А значит, порог входа там будет жестким. Проекты, где в общем котле варятся фронтендеры, бекендеры, девопсы. Каждый, кстати, будет оценивать вас по тем знаниям, в которых он силен.

Итог.

Вначале итога хотел бы уточнить, что все мои рассуждения касаются только тех, кто переходит в профессию программиста из других специальностей. Если вы студент профильного ВУЗа, то смело берите Go и программируйте на нем. Вас возьмут на работу 100%, потому что вы не будете требовать полляма в месяц, а хотите только писать код. Это то, что нужно бизнесу.

Для всех остальных подчеркну, что хоть и Go имеет простой синтаксис, но объем сопутствующих знаний к нему ничуть не меньше, чем в проверенной Java. А рынок найма на Go жестче из-за достойной конкуренции свитчеров с других языков.

Принципы наследования Go VS Java

Вам скажут, что в Go нет наследования. Они решили его не делать, потому что это плохо.
Почему плохо? Никто уже и не помнит, почему плохо, но так лучше не делать.

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

А что же сделали в Go? Они оставили лазейки для реализации подобных трюков.

Покажу на примере. У нас в курсе https://job4j.ru/profile/courses есть урок - кэш [1. Реализация кэша на SoftReference [#1592].

Реализуем подобное. В Go есть механизм struct embed. Дословно из описания "он позволяет безпроблемно сделать композицию картежей".

Создадим struct, который содержит карту значений:

type MemCache struct {  
    cache map[string]string  
}

Реализуем у struct два метода:

func (mem *MemCache) get(path string) string {  
    text := mem.cache[path]  
    if text == "" {  
       mem.load(path)  
    }  
    return mem.cache[path]  
}  
  
func (mem *MemCache) load(path string) {  
    fmt.Printf("Load from IO %s\n", path)  
    dat, err := os.ReadFile(path)  
    if err != nil {  
       panic(err)  
    }  
    mem.cache[path] = string(dat)  
}

Напомню, в Go есть функции-приемники, которые позволяют к struct прилепить функции.
По сути, сделать объект с методами.

А теперь создадим еще одну реализацию хранилища:

type JdbcCache struct {  
    MemCache  
}

Теперь JdbcCache ссылается на struct MemCache, то есть это не поле, а struct. Теперь все, что есть у MemCache, есть и у JdbcCache.

jdbcIO := &JdbcCache{MemCache{make(map[string]string)}}  
jdbcIO.load("go.mod")

Функция load вызывается у struct MemCache. Переопределим её?

func (mem *JdbcCache) load(path string) {  
    fmt.Printf("Load from DB %s\n", path)  
}

Без проблем. Создаем еще один метод с другим приемником.

Что же в многословной Java? Так как старушка повидала уже все, и ей ваши "письки" уже не страшны, то там для таких случаев придумали механизмы, ограничивающие неустойчивую психику адептов ООП.

На самом деле проблема не в ООП или языках, а в уровне программирования. Роб Пайк дал наставление — пиши, как вам удобно. Вот народ и пишет не как удобно, конечно, а как может. А может вот так криво и сложно.

Вернемся к Java. В Java есть негласные правила по поводу наследования:
1. Неабстрактные классы должны быть final. Это правило избавит вас от проблем множественного переопределения методов.
2. Неабстрактные методы должны быть final. Это избавит от проблем наследования. Теперь, если у вас нет возможности сделать глубокую вложенность с наследованием.

Вернусь к примеру выше.

public abstract class MemCache {  
    private final Map<String, String> cache = new HashMap<>();  
  
    public final String get(String path) {  
        var text = cache.get(path);  
        if (text == null) {  
            load(path);  
        }  
        return cache.get(path);  
    }  
  
    public abstract void load(String path);  
}

Реализация:

public final class JdbcCache extends MemCache {  
    @Override  
    public void load(String path) {  
        System.out.printf("Load from DB: %s/n", path);  
    }  
}

То есть в многословной Java я описал кодом то, что я хотел донести до других программистов. Программист любого уровня поймёт этот код, а вот в Go культура команды должна быть на высоте.
А так как туда переходят со всех направлений: PHP, JS, DevOps, то тимлиду нужно будет ходить с плеткой, чтобы объяснять, что там делать нельзя.

Повторяюсь, что проблема не в парадигмах, а в опыте.

Prometheus | Grafana

Подбиваю уроки по курсу DevOps

Введение в мониторинг и логирование [#505401]
Основы Prometheus [#505402]
Введение в Grafana [#505403]

Еще по скидки 7990 рублей. И это не шутка. Всех с праздником 1 апреля.

😀 https://job4j.ru/profile/courses/35

Что будет вместо ELK на курсе DevOps?

Вначале разберемся, что такое ELK.

Начнем с Logstash — в чем проблема многопоточных и, к тому же, микросервисных приложений?
Рассмотрим монолитное однопоточное приложение. Пользователь зашел в систему и выполняет свои задачи. В логе вы можете последовательно видеть его действия. То есть трассировать его события по логу. Но такое бывает только в учебных проектах.
Обычно у нас многопоточное окружение. Теперь вам нужно решить задачу по отслеживанию поведения пользователя в многопоточном окружении, но хотя бы в одном приложении.
А в конце мы имеем микросервисы, где поведение пользователя растекается на сервисы.

Logstash позволяет агрегировать разные источники логов.

Собрать их вместе — только часть задачи. Вам нужен анализ этих логов. Можно, конечно, сделать LIKE %%, но такое решение будет работать медленно.

На собеседовании по системному дизайну вам может попасться такой вопрос, как искать по тексту. Ответ — использовать движки полнотекстового поиска. Самый популярный — Lucene.
На его основе написан сервис Elasticsearch.

Теперь мы собрали логи и отправили их в движок полнотекстового поиска.

Осталось только иметь удобный механизм визуализации — Kibana.

ELK — платное решение. Поэтому в курсе DevOps мы будем использовать альтернативные решения.

Logstash заменим на Graylog.
Elasticsearch на Sphinx.
Kibana на Grafana.

https://job4j.ru/profile/courses/35

Черный рынок найма или БДСМ HR

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

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

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

Раз уж начал говорить о нравственно-моральных принципах, то продолжу. Почему возникает необходимость приписывать опыт? Дело в том, что древний принцип спекуляции работает и в найме: найди программиста и продай его дороже. Но чтобы продать дороже, его нужно натренировать, чтобы он отвечал правильно.

Этим и занимаются аутсорсы и инфоцыгане. То есть они продают фейковых сотрудников, которые в процессе работы оказываются пустышками.
Причём вы скажете: "Да их уволят." Да, их уволят через 3–4 месяца, а потом они пройдут ещё одно собеседование — и уже продержатся дольше.
Но "кабанчику" это не нравится, поэтому на рынке взвинтили требования и опыт. Но это ничего не изменило. Проблема в другом. В конце статьи — об этом.

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

Теперь расскажу о схемах найма.

Разделим их на две группы. Первая — со стороны кандидата. Это либо аутсорс-компании, либо инфоцыгане, которые предлагают устроить вас на работу и требуют 50% от вашего дохода на протяжении двух лет.

### 1. Заучивание вопросов
Классическая схема, которую используют все. В ней нет ничего зазорного. Мы повторяем или изучаем материал, который может быть использован в новом проекте. В целом я сам сторонник идеологии *continuous learning*, так что процесс обучения никогда не прекращается.

### 2. «Паровозик» кандидатов
Эту схему используют аутсорсы или инфоцыгане.
Причём я даже знаю курс, где этим хвастаются: «Они хакнули рынок IT». Циркачи, да и только. Схема работает так: собирается группа кандидатов с похожими резюме. Они отправляют их в одну и ту же компанию, обычно это Сбер 🙂. Далее по очереди проходят собеседования, передавая вопросы и задания следующему. То есть каждый новый кандидат отвечает лучше предыдущего.

### 3. «Дуплет»
Собеседование проходит с помощником. Рядом сидит человек (или группа), которая помогает отвечать на вопросы. Сейчас преобладает удалённый формат, поэтому работодатель может даже не подозревать, что проверяет коллективные знания. А может и с ИИ вместе.

### 4. Нарисованное резюме
Это не просто приписать 1–2 года к опыту. Это прямо нарисовать путь от джуна до сеньора. Если вы скажете, что не вытянете такую работу, вам ответят: «Мы поможем. Вы же за это платите». Аутсорс живёт на разнице между тем, за сколько он вас продал, и вашей реальной зарплатой — и эта разница может быть в разы.

---

Со стороны работодателя всё попроще.

### 1. Стажировки
Я уже писал об этом. Кандидату кажется, что на стажировке его научат работать, а потом он будет зарабатывать свои кровные. Но рынок IT живёт по капиталистическим законам, и о ваших потребностях подумают в последнюю очередь. Цель стажировки — выбрать лучших, послушных и самостоятельных джунов, которых можно будет эксплуатировать за скромную, но "достойную" зарплату. Потому что они прошли стажировку.

### 2. Стажировка в аутсорсе
Интересная схема. Поскольку у компании нет собственных проектов, они боятся, что обученные сотрудники сбегут. Поэтому подписывают хитрые контракты: если сотрудник не доучится — штраф. Если доучится и сбежит — тоже штраф. Получается крепостной раб, но с дипломом.

---

Я никого не осуждаю — ни кандидатов, ни работодателей. Проблема не в найме, а в отборе.

Дело в том, что отбор часто проводят не самые сильные сотрудники. Те, кто хорошо программирует, не любят общаться. А те, кто любит общаться, не всегда хорошо программируют. Поэтому одним приходится работать с теми, кого отобрали другие.

---

### Если вы проводите технические собеседования, возьмите на вооружение несколько правил:

1. Просите кандидата писать код. Если он только выучил теорию, но не писал код — это сразу видно.
2. Просите писать SQL-запросы.
3. Просите писать команды Git. Не спрашивайте, что такое *index* — лучше спросите, как удалить данные из индекса.
4. Задавайте связанные вопросы: реши задачу, объясни сложность, предложи варианты расширения.
5. Попросите описать действия в реальной ситуации. Например: *приложение падает с OutOfMemory — куда смотреть, что делать?*

Покажите, как вы работаете у себя — и просите кандидата сделать то же самое. Теория — это не то, что вы делаете каждый день. Вы пишете код — так пусть и он пишет код на собеседовании.

---

### Что не нужно делать:

1. Давать задачи с *Leetcode*. Они не показывают ничего, кроме того, что кандидат нашёл время решать задачки.
2. Спрашивать сухую теорию. Вместо «Что такое HashMap?» — попросите использовать её в коде.
3. Давать тестовые задания. Никто никогда не выполнит их идеально. Даже вы.

Игра «Шпион» для весёлой компании

Попробуйте игру через нашего бота: @SpyGoGameBot

Игра-шпион для весёлой компании

Сделал первую версию игры «Шпион».
Разрабатывал на Go. Исходники доступны по ссылке: https://github.com/peterarsentev/spy_go_game

Впечатления от языка Go

1. Безумная скорость компиляции, запуска и сборки артефактов.
2. Синтаксис языка в стиле C, а поклонникам Java он покажется привычным. Мне сразу стало удобнее писать по сравнению с Python.
3. Встроенные инструменты сборки, тестирования, проверки покрытия тестами и даже benchmark.

Но язык не для всех. Точно не для начинающих.

В чём проблема Java-проектов? В них куча зависимостей, что делает проект медленным. Про эту проблему ещё Антон Кекс рассказывал в далёком 2013 году: https://www.youtube.com/watch?v=TSAlj04_tkA

Но чтобы писать без фреймворков, вы должны быть хотя бы поклонником Егора Бугаенко.
То есть то, что вы делаете не задумываясь в Java, нужно осмысленно переписывать в Go.

Посмотрите в коде моего проекта. Я бездумно влепил log.Fatal везде. А когда приложение падало, я не понимал, что делать, потому что эти ошибки не содержали трейса. А в Java я бы не задумываясь писал log.error("message", error) и получал бы и ошибку, и трейс.

То есть язык для тех, кто хочет копнуть вглубь того, что использует, не задумываясь в Java.

В целом, если посмотреть на использование Go в микросервисах, то там тот же стек, что и в Java, что логично, так как цель микросервисов — быть не зависимыми от выбранного языка. Всё то же самое: Docker, K8s, JWT, Prometheus, Grafana, ELK, REST API, gRPC, Protocol Buffers.

Я оценивал Go как первый язык. Из той статьи я сделал вывод, что изучение Go в качестве первого языка с точки зрения поиска работы — неудачное решение. Но с позиции опытного программиста, работающего с микросервисами, переход на Go с точки зрения скорости и глубокого понимания технологий — отличный шаг вперёд.

По этой причине, совместно с Михаилом Епатько (https://t.me/liferefactoring) мы планируем сделать небольшой курс по теме Go: от нуля до микросервисов, рассчитанный на программистов уровня мидл и сеньор.

Я понимаю, что в этой идее есть сомнительный момент: лично я начал изучать Go всего несколько недель назад, и выглядит странным учить кого-то, не зная самого языка.

Смысл в том, что мы понимаем, как работает тот или иной фреймворк в Java — не до мельчайших деталей, но достаточно. А значит, мы сможем объяснить, как всё сделать с нуля, и, вместо Java, использовать Go.

Также в качестве основных источников знаний мы будем использовать книги, написанные ребятами, которые уже давно пишут на Go.
Например, «Microservices with Go» от Александра Шуйскова. Автор работает в Uber, где активно используют Go.

Бот: @SpyGoGameBot

Потерянные боты

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

Бота из телеграмм можно сделать иконкой в телефоне. То есть по сути отдельное приложение.

Откройте профиль бота. В правом верхнем углу нажмите на три точки. У вас появиться меню. Выберите Add to Home Screen.

Наши боты:

@talksharp_bot - лингво-тренер
@ITTalkBot - подготовка к собеседованиям
@SpyGoGameBot - игры для компаний