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

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

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

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

Наши боты:

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

Работа | Java Dev | Узбекистана(Ташкент)

У нас большое сообщество и мы помогаем друг другу и в знаниях и в трудоустройстве.
Сейчас есть позиция в Узбекистане (Ташкент). Без опыт, только с курсом.

Пишите кому интересно.

Философия Go | ООП | Инкапсуляция

Я продолжаю свое путешествие в мир Go.

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

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

Давайте я покажу это на примере инкапсуляции.

У себя в курсе я изначально ввел правило: все методы должны быть либо public, либо private, хотя в Java есть еще default и protected.
Бывают ученики, которым это не нравится, и они заставляют меня всякий раз объяснять.
Основной довод: сложно найти случаи, где вам нужны другие варианты.

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

А в Go понимали эту проблему, поэтому сразу обозначили, что доступ может быть только двух типов: внешний и внутренний, или открытый и закрытый.
Можно провести аналогию с public и private, но лучше это не связывать, потому что вы тянете синтаксические особенности другого языка.

И главный момент: как они это реализовали? Мне хотелось бы, чтобы кода было меньше, но он был бы понятным.

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

Пример с Kotlin:

kotlin
private fun runJavaCode(source: String) {
}

go
func runJavaCode(source string) {
}

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

kotlin
fun exec(commands: List<String>) {
}

go
func Exec(commands []string) {
}

То есть философию Go в этом аспекте можно использовать и для других языков, например, для Kotlin.

Может ли Go заменить Java?

В этой статье я хотел бы объяснить мое понимание того, какое место займет Go в мире IT.

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

Обычно в книгах пишут благодарности, а тут я решил поблагодарить подписчика @capo_80 за наводку на другую сторону Go. Он указал мне на другие источники о Go.

Почитайте оригинал, чтобы потренироваться в английском:
https://0x46.net/thoughts/2024/12/03/go-a-fractal-of-bad-design/

Автор статьи имеет огромный опыт работы с Go, но в начале статьи описывает свои первые эмоции, которые полностью соответствуют моим.


### Чем зацепил Go в начале пути?

1. Горутины, каналы и т.д. Многопоточные программы можно писать как последовательный код.
2. Упакованные инструменты сразу с языком: менеджер пакетов, тесты, сборка, покрытие тестами, бенчмарки.
3. Скорость компиляции и запуска.
4. Компактные исполняемые файлы.
5. Статическая типизация.

Я еще не дошел до горутин, но все остальные пункты точно создают мое окрыленное ощущение, что язык потрясающий. Хотел бы отдельно отметить момент со статической типизацией – если ее нет в языке, это ужас. Иногда я пишу код на JS, и это странное явление.

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


### Пример кода

Слайс – это динамический массив в Go. Но он реализован так же, как в C: вам дают кусок памяти и указатели на эту память.

Задача с собеседования:

go
package main
import "fmt"

func main() {
    slice := [6]int{0, 1, 2, 3, 4}
    frame := slice[1:2]
    fmt.Println(frame)
    frame = append(frame, 10)
    fmt.Println(frame)
    fmt.Println(slice)
}

Объяснение: Что выведет этот код?
Дело в том, что frame получает указатели на память. Функция append добавляет число 10 в конец этой памяти. В результате исходный слайс будет выглядеть так: [0, 1, 10, 3, 4, 0]. То есть число 2 будет затерто.


### Анализ

Такие методы вызывают подозрения. Мы видим, что Java упростила жизнь программистам C++, а теперь появился Go, который упрощает жизнь программистам C. Что в итоге остается?

- Горутины? В Java есть корутины, не хуже. Даже Virtual Threads, хотя с ними пока есть проблемы.
- Инструменты? Они не идут в установочном пакете, но это критично только на фазе знакомства с языком. У меня есть каркасы проектов с настроенными инструментами, и создание проекта ни на Java, ни на Kotlin не вызывает проблем.
- Статическая типизация? Она есть и там, и там. Языки без статической типизации вызывают у меня отвращение.
- Скорость компиляции и запуска? Да, здесь Go остается лидером, как и компактные исполняемые файлы.

Но сколько будут стоить эти плюсы по сравнению со стоимостью программистов? Программирование на Go похоже на низкоуровневое программирование на C. Чтобы написать даже небольшое бизнес-приложение, нужно написать кучу кода, тогда как в Java можно сразу писать бизнес-логику.

### Итог

Java так и останется основным языком для бизнес-приложений. Однако инфраструктурные элементы будут оптимизированы с помощью решений на Go. Мы уже видим это: Docker и Kubernetes написаны на Go.

То есть два языка будут существовать совместно, и речи о замене одного другим нет. Но они будут решать разные потребности бизнеса:

- Java продолжит решать задачи бизнес-логики.
- Go будет использоваться для оптимизации инфраструктуры.

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

Кафка для линейного программиста

За этот месяц уже несколько человек жаловались, что застряли на уровне мидл. На самом деле это распространённая ситуация. Как говорится, под лежачий камень вода не течёт.

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

Поэтому не забывается чирикать с нашим Лингво-тренером @talksharp_bot ))

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

Это хорошо видно на примере Apache Kafka. Для линейного программиста – Apache Кафка – это очередь сообщений, в которую мы либо пишем, либо читаем. Бизнес на самом деле тоже хотел бы, чтобы все технологии были максимально устойчивыми, но это не так.

Если мы переключим своё внимание только на технологию, то поймём, что у нас есть куча вопросов, которые стоит учитывать, когда мы работаем с Кафкой. Например, дойдёт ли сообщение или нет, будет ли оно дублировано, а если сервер отключить и включить через некоторое время, то что будет с сообщениями? А что, если несколько реплик?

Целая куча вопросов, которыми мидл-программист не занимается. Это не его обязанность.

Для тренировки перечислю эти вопросы здесь. Их же будем разбирать в нашем новом курсе по Kafka: https://job4j.ru/profile/courses/21

1. Как работает Kafka Consumer при нескольких репликах одного микросервиса?
2. Что такое Consumer Group и как она распределяет партиции между инстансами?
3. Что происходит при масштабировании микросервиса (добавлении реплик)?
4. Что произойдёт, если количество партиций меньше, чем количество реплик?
5. Как обеспечить идемпотентность при повторной доставке сообщений?
6. Как избежать повторной обработки одного и того же сообщения в случае сбоя?
7. Как правильно обрабатывать оффсеты при ручном подтверждении?
8. Как настроить стратегии ретраев (retry) и Dead Letter Queue (DLQ)?
9. Как Kafka работает с autoscaling в Kubernetes?
10. Как отслеживать производительность и лаг консюмеров в многорепликах?
11. Как правильно настроить health-check и readiness-check для консюмеров в Kubernetes?
12. Как бороться с out-of-order delivery в микросервисах?
13. Как обеспечивать exactly-once семантику в распределённой среде?
14. Что делать, если один из брокеров Kafka выходит из строя?
15. Как настроить балансировку нагрузки Kafka в Kubernetes через NodePort, LoadBalancer или Ingress?
16. Как использовать Kafka вместе с сервисами типа Istio или Linkerd (Service Mesh)?
17. Как управлять схемами сообщений с помощью Schema Registry в среде с множеством микросервисов?
18. Как организовать миграции схем без даунтайма?
19. Как настроить secure Kafka (TLS/SASL) в Kubernetes?
20. Как деплоить Kafka-кластер в Kubernetes (через Helm, Strimzi, Bitnami)?
21. Как тестировать Kafka в микросервисной архитектуре (тесты для продюсеров и консюмеров)?
22. Как деплоить обновления микросервисов, работающих с Kafka, без потери сообщений?
23. Как обрабатывать события с задержкой (event delay, scheduling via Kafka)?
24. Как организовать аудит событий, если каждый микросервис слушает один и тот же топик?
25. Как работать с Kafka при использовании событийной схемы типа event sourcing?

Осознал Kotlin спустя 7 лет

Когда я начинал изучать Kotlin, то первое, что было написано в книге, — что Kotlin – это выразительный и лаконичный язык.
Слушая эти заветы, я старательно пытался реализовать DSL. Код самого DSL получался коротким, но реализация этого DSL вызывала сомнения.

Пример:

fun <E> select(pool: BasicDataSource, sql: String,
               ext: (ResultSet) -> E,
               params: ArgStatement.() -> Unit): List<E> {
    val rsl = ArrayList<E>()
    pool.connection.use { cn ->
        cn.prepareStatement(sql).use { st ->
            val args = ArgStatement(st)
            params(args)
            val set = st.executeQuery()
            while (set.next()) {
                rsl.add(ext.invoke(set))
            }
        }
    }
    return rsl
}

// Использование
fun findByListId(levIds: Set<Int>): List<Level> =
        select(pool, "SELECT * FROM level WHERE id = ANY(?)") {
            arg(levIds)
        }

И в SQL всё понятно: SQL – это декларативный язык, то есть мы описываем результат работы, а не саму работу.
Но когда дело доходило до того, что нужно мне (а это бизнес-процесс), я не знал, что делать.

Дело в том, что сама идея DSL сомнительная. Мне нужно сначала создать конструктор, а только потом писать проект. Я не хочу так. Я хочу сразу писать код, а ещё лучше – писать его меньше.
Как оказалось, всё упиралось в класс. Ответьте на вопрос: что является главным элементом языка Java? Объекты, методы? Нет, главный элемент – это класс. Всё живёт в нём. Парадигмы программирования – это не о классе, но в Java всё крутится вокруг класса, и из-за этого возникают проблемы многословности и многослойности.

Точно так же я и стал писать код на Kotlin: везде должен быть класс, даже если у него нет состояния. Причём такие примеры есть в самом языке Kotlin, например библиотека KoTest, DSL для тестирования.

Я сейчас дочитал только половину книги по микросервисам на Go, но мне сразу бросилось в глаза, что они не думают в рамках класса. Их там вовсе нет.
Я решил попробовать сделать так же.

У меня есть эталонное задание в курсе job4j ToDo-лист.
Для тех, кто не учился у меня, я опишу здесь архитектуру в рамках классов:
- StartUI – класс, который занимается графикой;
- Menu – класс, отвечает за управление меню;
- Action – классы, реализующие поведение меню;
- Store – хранилище для задач;
- Task – задачи.

И в Java-курсе, и в Kotlin-курсе я описывал эту задачу через классы.
И вроде бы всё логично.
StartUI зависит от Menu, Menu зависит от Action, Action от Task. Внедряй зависимости и полетел.

Если мы оценим код с позиции состояний, то поймём, что кроме Store и Task у нас нет реальных объектов.
StartUI, Menu, Action – это просто линейные операции без состояний.
То есть мне не надо писать лишний код, а только сфокусироваться на бизнес-процессе.

Ниже я опишу, как я его переделал.

Классы, которые действительно содержат состояния и от которых нельзя уйти:

data class Task(
    val ID: Int,
    val name: String
)

class Store {
    private val mem = ArrayList<Task>()

    fun add(task: Task) {
        mem.add(task)
    }

    fun findById(ID: Int): Task? =
        mem.find { it.ID == ID }
}

А теперь то, что не классы и объекты, я описал функциями:

fun startUI(input: (String) -> String, menu: Map<Int, () -> Boolean>) {
    var selected = 0
    do {
        selected = input("Select: ").toInt()
        val act = menu[selected] ?: continue
        if (!act()) {
            println("Error")
        }
    } while (selected != 0)
}

Обратите внимание, что эта функция не зависит от пользовательского кода или объектов. То есть весь код – это core. Я могу его протестировать, как угодно.

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

Опишем элементы меню:

fun createTask(input: (String) -> String, store: Store): () -> Boolean = {
    store.add(Task(
        ID = 0,
        name = input("Enter name: ")
    ))
    true
}

fun findTask(input: (String) -> String, store: Store): () -> Boolean = {
    val task = store.findById(
        input("Enter ID: ").toInt()
    )
    if (task != null) {
        println(task)
    } else {
        println("Not found")
    }
    task != null
}

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

В Java я передавал туда параметры execute(input, store)?, а сейчас я имею только вызов функции без зависимостей.

И теперь main:

fun main() {
    val store = Store()
    val sc = Scanner(System.`in`)
    val input: (String) -> String = {
        print(it)
        sc.nextLine()
    }
    val menu = mapOf(
        1 to createTask(input, store),
        2 to findTask(input, store)
    )
    startUI(input, menu)
}

Весь код уместился в один файл main.kt на 65 строк, где каждую функцию я могу протестировать.

Итог.
Свою версию курса по Kotlin считаю крайне неудачной, так как не увидел этого элемента языка сразу. Хотя считаю, что это упущение группы маркетинга языка. В новой версии курса я буду строить повествование только на идее отсутствия класса.

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

P.S.
Код на Kotlin в таком стиле выглядит в 100500 раз читаемее, чем на Go, но скорость компиляции и исполняемые маленькие артефакты всё же заставят продолжать изучать Go дальше.

Стили программирования

Вчера пытался переписать свой проект антиспам-бота в функциональном стиле. Проект изначально написан на Kotlin, но я использовал классы.

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

Есть много вариантов проектирования систем. Я в курсе показывал слоеную архитектуру (Onion). В основе её лежит база данных. Поэтому я стал переписывать код из нижнего слоя Repository.

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

Есть два пути: интеграционные тесты и модульные. Я сторонник модульных тестов. В целом мне нравится идея, что чем меньше действий ты делаешь, тем лучше. Для интеграционных тестов мне нужно тестовое окружение, а для модульных – нет.

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

fun saveFilter(insert: (query: String, args: Map<String, Any>) -> Unit, filter: Filter) {
    val query = "INSERT INTO dionea_filter (name) VALUES (:name)"
    val args = mapOf<String, Any>("name" to filter.name)
    insert(query, args)
}

insert – это функция, принимающая запрос и параметры.

fun insert(sql2o: Sql2o): (String, args: Map<String, Any>) -> Unit = { query, args ->
    val cnn = sql2o.open()
    sql2o.open().use { connection ->
        val exec = connection.createQuery(query)
        args.forEach { (t, u) -> exec.addParameter(t, u) }
        exec.executeUpdate()
    }
}

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

Что такое контейнер с функциями? Это и есть класс. То есть всё обратно упёрлось в класс. Кстати, по этой причине я и не видел проектов, написанных в чисто функциональном стиле. Чтобы писать в таком стиле, нужно написать кучу кода ради внедрения зависимостей, как функции.

Поэтому новые языки – Kotlin, Go – это языки в мультипарадигменном стиле. То есть в основу нужно брать не стиль программирования, а здравый смысл. А он нам говорит: писать меньше кода и писать тесты.

Эти два принципа должны лежать в основе хорошего кода.

Курс Apache Kafka

16 апреля 2025 года, я разговаривал с Михаилом — выпускником курса, который окончил обучение в 2022 году. После завершения курса он сразу нашел работу, а спустя три года решил сменить проект. Наши беседы всегда интересны, особенно когда речь заходит о том, как меняется процесс найма в IT.

Михаил поделился своими наблюдениями о собеседованиях в 2025 году по сравнению с 2022-м. Он отметил, что 80% вопросов на собеседовании касались Apache Kafka. Это неудивительно, ведь микросервисная архитектура принесла множество вызовов, которых не было в монолитных приложениях. Основной из них — это работа с распределенными транзакциями. В нашем курсе мы также затронем эту тему.

Описание курса https://job4j.ru/profile/courses/21

Пишите, те что хочешь начать проходить. Открою демо доступ.

Повествование решил сделать на Kotlin. Меньше кода писать. Так что сразу два зайца получается и Kafka + Kotlin, Gradle.

Необходимые шаблоны: Retry, Circuit Breaker на базе Resilience4j

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

- Retry [#505446]
- Circuit Breaker [#505444]
- Resilience4j [#505447]

И еще один шаблон для асинхронного режима — outbox.

Курс: https://job4j.ru/profile/courses/14

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

Вот пример задания на код-ревью.

// Микросервис для обработки заказов, который взаимодействует с платежной системой и Kafka

@Service
public class OrderService {
    private final PaymentClient paymentClient;
    private final OrderRepository orderRepo;
    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    @Transactional
    public void processOrder(Order order) {
        orderRepo.save(order);

        paymentClient.charge(order.getUserId(), order.getAmount());

        kafkaTemplate.send("order_events", new OrderEvent(order));
    }
}

@FeignClient(name = "payment-service", url = "${payment.service.url}")
public interface PaymentClient {
    @Retryable(maxAttempts = 5)
    @PostMapping("/charge")
    void charge(@RequestParam String userId,
                @RequestParam BigDecimal amount);
}

@Service
@RequiredArgsConstructor
public class OrderEventConsumer {
    private final NotificationService notificationService;
    private final OrderRepository orderRepo;

    @KafkaListener(topics = "order_events")
    public void handleEvent(OrderEvent event) {
        Order order = orderRepo.findById(event.getOrderId()).orElseThrow();

        notificationService.sendEmail(order.getUserEmail(), "Order processed");

        order.markAsCompleted();
        orderRepo.save(order);
    }
}

Бойко́т переводной литературе

Часто слышу, что ребята ругают переводную техническую литературу. Ранее я к этому относился спокойно и особо проблем не замечал. В целом не с чем было сравнить.
В моей личной библиотеке есть много книг, и переводных, и оригинальных. И я обратил внимание, что все оригинальные книги я прочитываю всегда до конца. Я имею в виду и на русском, и на английском. А переводные часто оказываются отложенными. Так и случилось с книгой по Apache Kafka. Я купил её, наверное, в 2019 году и бегло полистал.
А сейчас, когда я пишу курс по Apache Kafka, мне крайне нужна эта книга. Поэтому я её взял и стал читать от начала до конца.
Первое, на что я обратил внимание, — это то, что иногда я не могу уловить смысл предложений. Это странно. Я понимаю каждое слово, но не могу понять смысл предложения. Эта книга — перевод, поэтому я нашёл оригинал и сразу понял, что проблема в переводе.

Если провести аналогию в программировании, то любой перевод — это слой абстракции.
То есть, чтобы читать переведённую книгу, мне нужно выполнить три действия:
1. Понять русский текст.
2. Адаптировать его под английские термины.
3. Понять, что хотел донести автор оригинальной статьи.

Также я обратил внимание, что книгу в оригинале я прочитаю в разы быстрее, чем перевод. Это связано и с тем, что я описал выше, а также со способом восприятия иностранного языка. Если взять классическую схему обучения чтению, то освоение чтения начинают с элементарной части — буквы. Что в целом неверно, но это уже другая история.
Если мы учим второй язык, то элементарной частью для нас будет слово. Поэтому, когда я читаю иностранную литературу, то текст воспринимается словами или даже цепочками слов (chunk). Почему этого нет с переведённой статьёй? Потому что перевод — это интерпретация. А так как в 100% случаев переводчик — это не программист, то мы получаем дословный перевод, который мозг отказывается воспринимать.

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

А как быть? Во-первых, если вы ещё не работаете в IT, то используйте любую литературу, которая вам поможет преодолеть барьер собеседования. А вот если вы уже на этой стороне, то я крайне советую начать учить английский.

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

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

Жаркий марафон - алго собес

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

Решения можете скидывать: ссылки, либо из платформы, либо с github.

Задание для этой недели: Подмассив с их максимальной суммой | Алгоритм Кадане

https://job4j.ru/profile/topics/206/task_code/566/new_task

Как решать? В описании есть раздел объяснение. Сначала в уме попробуйте найти решение. А потом сравните с предложенным в объяснении, а только после этого пишите. Я советую писать прямо на платформе, потому что так же будет и в реальном собеседовании.

Песочница для Go

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

https://job4j.ru/profile/topics/206/task_code/566/new_task

Поправил несколько неудобных моментов.
1. Нельзя запустить main. Для отладки на платформе это критично.
2. Нужно использовать мышку, чтобы запускать код.

Поэтому добавил.
1. Если в коде есть main, то можно его запустить.
2. Запустить можно через кнопку "Запустить" или сочетанием клавиш Shift+Enter.

Так же переделал реализацию песочницы. Мы готовим курс по GoLang и там тоже нужна песочница. В JDK 17< настройки можно было указать через SecurityManager, в GoLang такого нет. Поэтому все переделал на Docker.

Если кто желает попробовать наш курс по GoLang, то пишите мне @parsentev.
Будете фокус группой. Единственное условие у вас должен быть опыт работы хотя бы год, Обучение бесплатное.

https://job4j.ru/profile/topics/206/task_code/566/new_task

Завершил Курс по DevOps

Добавил важные уроки.
Сбор логов | Loki [#505404]
AlertManager | Loki | ERROR [#505405]
AlertManager | Prometheus | Health check [#505406]

Далее я соберу отзывы, пожелания и потом доработаю материал.
Например, я рассматриваю Jenkins, а ребята говорят, что лучше GitLab развернуть. В новой версии тогда на нем сделаю.
Не стал добавлять темы с GitOps, ArgoCD, Flux, потому что очень много вышло.
В целом эти решения тяжеловесные, даже не смотря на то, что я разворачивал минимальные приложения.

Так же вместо ELK, я просто взял Loki и сделал все через Prometheus + Grafana вышло в разы проще.

Описание курса тут https://job4j.ru/profile/courses/35

Немного своих впечатлений о процессе создания этого курса "Работает - не лезь". В программировании я вижу код и могу даже залезть внутрь приложения. А в DevOps я ограничен логами. Поэтому порой приходилось сидеть по нескольку часов, чтобы осознать, где я что-то прописал не так. Еще один важный момент - это совместимости версий в K8s. Все сервисы разворачиваются в кластере K8s через Helm. Часто было так, что приложение не стартовало, потому что ему не хватало настроек в этом Helm. Лезешь в лог, разбираешься для чего это нужно, потом обновляешь. Поэтому фраза "работает не лезь" - этот как раз про DevOps )).

Go, как второй язык

А вы знали, что в GoLang всего 25 ключевых слов? Это в два раза меньше, чем в Java. Предположим, что и учить там в два раза меньше. Однако одна из первых фраз в книге Go 100:
Go is simple, but not easy. Это важно понимать, если вы только на пути в IT. На собеседовании по GoLang можно встретить классическую задачу на указатели.

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

type Person struct {  
    Name string  
}  
  
func changeName(p *Person) {  
    p = &Person{  
       Name: "Alice",  
    }  
}  
  
func main() {  
    person := &Person{  
       Name: "Bob",  
    }  
    fmt.Println(person.Name)  
    changeName(person)  
    fmt.Println(person.Name)  
}

В GoLang есть настоящие указатели, как в C++. Они не такие, как в Java, то есть это реальный указатель на участок памяти. Чтобы создать указатель, нужно начать переменную с символа амперсанда (&). А чтобы записать в переменную указателя, нужно использовать звездочку (*).

Код выше выведет Bob, Bob. Почему? Потому что функция changeName записывает новый указатель в локальную переменную. Вопрос: как поправить код, чтобы вывел Bob, Alice?

Или, как в Java, обратиться к полю:

func changeName(p *Person) {  
    p.Name = "Alice"  
}

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

func changeName(p *Person) {  
    *p = Person{  
       Name: "Alice",  
    }  
}

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

Изначально я думал, что с Go решают какие-то крутые задачи по оптимизации, но на самом деле оказалось, что решают такие же задачи, как и в Java. То есть стек технологий и решений один в один как в Java: Docker, K8s, Redis и даже Kafka. Там же шаблоны отказоустойчивости, Retry, Circuit Breaker, Timeout, Outbox. Есть и другие проекты, например, по pentest и blockchain, но их крайне мало, около 40 вакансий.

С другой стороны, если посмотреть на курсы по Go, то можно увидеть корреляцию с Java: Go занимает меньше времени. Поэтому мы и решили проверить эту гипотезу с Михаилом.
Можно ли за 3-4 месяца перейти с Java на Go, при условии наличия коммерческого опыта и без потери в зарплате?

Для примера, в Go есть только слайсы и словари. Все другие структуры вам нужно реализовать самому, то есть нет необходимости учить Java Collection API.

Если у вас есть желание принять участие в нашем эксперименте по Go, пишите мне @parsentev.

Курс Apache Kafka | Задача с собеседования

Я переключился на курс по Apache Kafka.
Добавил новый урок.

Архитектура Kafka [#505452]

В нем рассмотрел настройку разделов в теме.

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

👉 Описание курса https://job4j.ru/profile/courses/21

Внутренний диалог и иностранный язык

Продолжу тему иностранного языка. Как вы знаете, я активно практикую йогу, потому что она помогает решать самые разные задачи в физическом и ментальном плане. В физическом плане всё понятно: асаны в йоге можно сравнить с любимыми спортивными упражнениями, но в спорте нет ментальных практик. Если упростить, йога — это концентрация на объекте наблюдения, например на дыхании, или, наоборот, на мыслительном процессе, но без погружения в него.

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

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

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

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

Этот же приём используется при чтении программного кода.

Посмотрите на пример кода на Rust:

struct SeaCreature {
    noise: String,
}

impl SeaCreature {
    fn get_sound(&self) -> &str {
        &self.noise
    }
}

fn main() {
    let creature = SeaCreature {
        noise: String::from("blub"),
    };
    println!("{}", creature.get_sound());
}

Я уверен на 100%, что вы смогли прочитать и понять этот код. Обратите внимание, что ваш мозг интерпретировал его по-своему, даже без знания синтаксиса Rust. Вам, конечно, не понятны все нюансы, но общий смысл вы уловили: описать структуру данных, дать ей функцию, создать объект этой структуры и вызвать функцию.

А теперь вернёмся к английскому языку. У меня появилась идея создать серию уроков, которая позволит читать английские книги и статьи в оригинале. Составить такой материал через ChatGPT несложно. Для чтения Reddit нужен словарный запас около 4000–6000 слов — это вполне реально, ведь многие IT-термины либо вовсе не переводятся (например, «commit»), либо имеют аналогичное звучание (например, «transaction»).

Однако встал вопрос: что делать с внутренним диалогом? Проблема в том, что мы будем неправильно произносить английские слова, но я пришёл к выводу, что это не так важно. Главное — отказаться от дословного перевода, как в примере с Rust-кодом, и сосредоточиться на понимании смысла предложения, а не на буквальном переводе.

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

String в Java и Go

Как вы знаете, задача на работе и задача на собеседовании — это две совершенно разные вещи.
Напомню, что с Михаилом мы решили провести эксперимент с языком Go (GoLang). Эксперимент крайне простой: за 4–5 месяцев проработать материал по Go и вкатиться в Go-разработку без потери зарплаты.

Я сразу разделил это на два процесса: реальные задачи на работе и вопросы/задачи для собеседования.

В этой статье мы поговорим о вопросах, задаваемых на собеседовании.

Вас когда-нибудь спрашивали на собеседовании по Java о том, как устроен класс String? Думаю, нет, разве что о String Pool. А вот в Go это обязательный вопрос.

Давайте разберёмся.

В Go строка (string) — это неизменяемая (immutable) последовательность байтов, обычно кодирующих UTF-8. Под капотом строка представлена простым «хэдером» из двух машинных слов:

// в пакете reflect есть аналогичная структура:
type StringHeader struct {
    Data uintptr // указатель на первый байт в памяти
    Len  int     // длина в байтах
}

Символы в кодировке UTF-8 могут занимать от 1 до 4 байтов. Поэтому в Go есть тип rune: он позволяет прочитать нужное количество байтов, чтобы получить соответствующий символ из таблицы Unicode:

name := "Hello, 世界"
for i, r := range name {
    fmt.Println(i, string(r), r)
}

Здесь i указывает на начало руны.

Если в строку попадают байты, не составляющие корректную UTF-8-последовательность, Go при разборе рун заменяет такой фрагмент на специальный символ � (U+FFFD), а длина такого «руна-элемента» считается равной 1 байту:

b := []byte{0xff, 0xfe, 0x41} // 0x41 == 'A'
s := string(b)

fmt.Printf("len(bytes) = %d, len(runes) = %d\n",
    len(b),
    utf8.RuneCountInString(s),
)

// При range по строке
for i, r := range s {
    fmt.Printf("idx %d: rune %U '%c'\n", i, r, r)
}

А как обстоят дела в Java?

В классическом варианте строки в Java представлены массивом 16-битных символов (UTF-16):

public final class String {
    private final char[] value;
    private int hash;
    // ...
}

Начиная с Java 9 появился механизм оптимизации Compact Strings:

public final class String {
    private final byte[] value;
    private final byte coder; // 0 — LATIN1, 1 — UTF16
    private int hash;
    // ...
}

- Строки, содержащие только символы из Latin-1 (U+0000…U+00FF), хранятся по 1 байту на символ.
- Как только встречается хотя бы один символ за пределами Latin-1, используется UTF-16 (2 байта на кодовую единицу).

В Java тоже есть методы для работы с кодовыми точками: String.codePointAt() и String.codePoints().