Уже традиция. Субботняя йога
В 19 00. Нужен коврик и желание по потеть.
Пишите в личку @parsentev. Я добавлю в чат.
В 19 00. Нужен коврик и желание по потеть.
Пишите в личку @parsentev. Я добавлю в чат.
🔥3
Системный дизайн
В озоне у меня было два этапа с системным дизайном.
Это мой первый опыт прохождения этого блока, ранее никогда не было.
Для тех, кто тоже никогда не проходил такой блок, я советую начать с этого видео.
https://www.youtube.com/watch?v=RAMWRgt-3G0
В озоне у меня было два этапа с системным дизайном.
Это мой первый опыт прохождения этого блока, ранее никогда не было.
Для тех, кто тоже никогда не проходил такой блок, я советую начать с этого видео.
https://www.youtube.com/watch?v=RAMWRgt-3G0
YouTube
Дмитрий Волыхин — System Design-интервью для практиков
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
Скачать презентацию с сайта JPoint — https://jrg.su/SuLdn6
Как задизайнить YouTube или Dropbox за 45 минут? Представьте, что у вас System…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
Скачать презентацию с сайта JPoint — https://jrg.su/SuLdn6
Как задизайнить YouTube или Dropbox за 45 минут? Представьте, что у вас System…
🔥12👍1
Kafka | Outbox
На секциях системного дизайна в озоне использовали сервис -
https://excalidraw.com/. Мне он приглянулся. Я стал использовать его для своего курса по Kafka.
Сегодня добавил два урока:
Иденпотентность и гарантии доставки [#505524]
Outbox [#505525]
В райфе мне дали задачу, у тебя есть сервис (replica > 1), настроен outbox. Вопрос, как избежать дублирование отправки сообщений из payload таблицы?
Ответы пишите в комментарии. Свой ответ я напишу в следующем посте.
Описание курса по Kafka
👉 https://job4j.ru/courses/21
На секциях системного дизайна в озоне использовали сервис -
https://excalidraw.com/. Мне он приглянулся. Я стал использовать его для своего курса по Kafka.
Сегодня добавил два урока:
Иденпотентность и гарантии доставки [#505524]
Outbox [#505525]
В райфе мне дали задачу, у тебя есть сервис (replica > 1), настроен outbox. Вопрос, как избежать дублирование отправки сообщений из payload таблицы?
Ответы пишите в комментарии. Свой ответ я напишу в следующем посте.
Описание курса по Kafka
👉 https://job4j.ru/courses/21
👍6❤2
Субботняя йога в 19:00
Напоминаю, что мы теперь не только программируем, но и тренируемся.
Всех желающих жду завтра в 19:00 на тренировку.
Пишите в личку @parsentev.
Вход бесплатный.
Напоминаю, что мы теперь не только программируем, но и тренируемся.
Всех желающих жду завтра в 19:00 на тренировку.
Пишите в личку @parsentev.
Вход бесплатный.
❤6
Кто диктует правила фронт vs бек
В пятницу у меня было финальное собеседование в Озон.
Этот этап называется "знакомство с командой", но по факту он даже серьезнее технического интервью, потому что здесь нет правильных ответов.
Конечно, был вопрос о процессах разработки и взаимодействии с другими командами.
В своём курсе по DevOps я описывал элемент инженерной культуры — спецификации.
Один из примеров касался RPC, например, REST API или gRPC, описанных через Swagger.
Что это даёт? Самое главное — теперь команда backend и frontend может вести разработку параллельно.
В частности, один из тимлидов обратил на это особое внимание, потому что в их проектах команды чётко разделены на backend и frontend. То есть при разработке нового бизнес-процесса он сначала попадает в backend, и только потом — в интеграцию с frontend.
Почему так происходит? Обычно разработка идёт "от базы данных к клиенту" — это восходящее проектирование. Это связано с тем, что наибольшая вычислительная нагрузка ложится на реляционную базу данных, поэтому сначала проектируют схемы БД.
Однако в таком случае frontend-команда простаивает, так как им нужен сервер, чтобы писать свой код.
Есть и другой подход — нисходящее проектирование. Оно как раз начинается с описания API-спецификации, а затем — её реализации. В этом случае можно применять TDD, но есть высокая вероятность, что внешнее API будет меняться, что приведёт к лавинообразным изменениям в слоях приложения.
Зато такой подход позволяет заранее согласовать API между backend и frontend и начать параллельную разработку.
Тимлид отметил, что у многих разработчиков как раз и возникает проблема с координацией и обсуждением внешнего API.
А как у вас принято в проектах? Напиши в комментариях.
Наш курс по DevOps — https://job4j.ru/courses/35
В пятницу у меня было финальное собеседование в Озон.
Этот этап называется "знакомство с командой", но по факту он даже серьезнее технического интервью, потому что здесь нет правильных ответов.
Конечно, был вопрос о процессах разработки и взаимодействии с другими командами.
В своём курсе по DevOps я описывал элемент инженерной культуры — спецификации.
Один из примеров касался RPC, например, REST API или gRPC, описанных через Swagger.
Что это даёт? Самое главное — теперь команда backend и frontend может вести разработку параллельно.
В частности, один из тимлидов обратил на это особое внимание, потому что в их проектах команды чётко разделены на backend и frontend. То есть при разработке нового бизнес-процесса он сначала попадает в backend, и только потом — в интеграцию с frontend.
Почему так происходит? Обычно разработка идёт "от базы данных к клиенту" — это восходящее проектирование. Это связано с тем, что наибольшая вычислительная нагрузка ложится на реляционную базу данных, поэтому сначала проектируют схемы БД.
Однако в таком случае frontend-команда простаивает, так как им нужен сервер, чтобы писать свой код.
Есть и другой подход — нисходящее проектирование. Оно как раз начинается с описания API-спецификации, а затем — её реализации. В этом случае можно применять TDD, но есть высокая вероятность, что внешнее API будет меняться, что приведёт к лавинообразным изменениям в слоях приложения.
Зато такой подход позволяет заранее согласовать API между backend и frontend и начать параллельную разработку.
Тимлид отметил, что у многих разработчиков как раз и возникает проблема с координацией и обсуждением внешнего API.
А как у вас принято в проектах? Напиши в комментариях.
Наш курс по DevOps — https://job4j.ru/courses/35
👍9❤6
"Волки" или Остапы Бендеры из IT
«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.
Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.
Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.
Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.
Сами программисты этим заниматься не любят, поэтому часть обязанностей выполняет кадровик. Здесь и возникает проблема.
HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.
Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.
Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.
Какие трюки используются при найме:
1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.
А зарабатывать можно на всём и как угодно.
Перечислю основные направления:
1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.
Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.
Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.
«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.
Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.
Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.
Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.
Сами программисты этим заниматься не любят, поэтому часть обязанностей выполняет кадровик. Здесь и возникает проблема.
HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.
Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.
Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.
Какие трюки используются при найме:
1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.
А зарабатывать можно на всём и как угодно.
Перечислю основные направления:
1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.
Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.
Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.
👍17🔥6❤4🤔2🤝1
Кафка. Вопросы с собеседований: Райф, Альфа, Озон, X5, Сбер
В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.
1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например,
2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы
6. Что означает
7. Что такое идемпотентный продюсер и почему просто
8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между
10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает
12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает
14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать
18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?
Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21
В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.
1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например,
acks, retries, идемпотентность, транзакции)?2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы
acks есть у продюсера и как они влияют на задержку и надёжность доставки?6. Что означает
min.insync.replicas и как его настройка вместе с acks=all влияет на устойчивость и доступность?7. Что такое идемпотентный продюсер и почему просто
enable.idempotence=true недостаточно для полной защиты от повторной доставки в более сложных схемах?8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между
commitSync и commitAsync и когда какой использовать?10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает
auto.offset.reset?12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает
poll долгое время и превышает max.poll.interval.ms или теряет heartbeat (session.timeout.ms)? Как это отражается на группе?14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать
max.poll.records, max.poll.interval.ms, heartbeat.interval.ms и почему слишком длинный poll может вызывать проблемы?18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?
Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21
❤14🔥12👍3
Поднять Kafka | Minio | KeyCloak за $$$
Для проекта BuddyService нужно поднять инфраструктуру.
Пишите напрямую @parsentev.
Оплата почасовая с дальнейшей поддержкой сервиса
Для проекта BuddyService нужно поднять инфраструктуру.
Пишите напрямую @parsentev.
Оплата почасовая с дальнейшей поддержкой сервиса
❤2👍2
Как вы знаете, я большой фанат тестов: unit, it, e2e.
Одной из крутых особенностей языка Go является встроенный инструментарий для тестирования.
Тесты в Go оформляются в методологии table-driven test. В этом подходе тестовые данные и ожидаемые результаты формируются в виде таблицы. Такой подход позволяет избавиться от дублирования кода теста и при этом покрыть разнообразные случаи поведения вашей программы.
Про этот подход я знал давно, но не использовал его, потому что мне казалось: если у тебя 105 вариантов входных параметров, а падает 101, то тебе каждый раз нужно прогонять все 100 тестов.
Оказалось, что нет — IDEA Community Edition по умолчанию поддерживает запуск отдельной строки из табличных данных.
В нашем Java курсе я перепишу тесты на подход TDT.
А вы используете такой подход? Напишите свои мысли в комментариях.
—-
Наш курс по Go — https://job4j.ru/courses/38
Одной из крутых особенностей языка Go является встроенный инструментарий для тестирования.
Тесты в Go оформляются в методологии table-driven test. В этом подходе тестовые данные и ожидаемые результаты формируются в виде таблицы. Такой подход позволяет избавиться от дублирования кода теста и при этом покрыть разнообразные случаи поведения вашей программы.
Про этот подход я знал давно, но не использовал его, потому что мне казалось: если у тебя 105 вариантов входных параметров, а падает 101, то тебе каждый раз нужно прогонять все 100 тестов.
Оказалось, что нет — IDEA Community Edition по умолчанию поддерживает запуск отдельной строки из табличных данных.
@ParameterizedTest
@CsvSource({
"true,true,true,true",
"true,false,true,false",
"false,false,false,true",
"true,true,false,false"
})
void testMono(boolean a, boolean b, boolean c, boolean expected) {
Check check = new Check();
boolean[] input = new boolean[]{a, b, c};
boolean result = check.mono(input);
assertThat(result).isEqualTo(expected);
}
В нашем Java курсе я перепишу тесты на подход TDT.
А вы используете такой подход? Напишите свои мысли в комментариях.
—-
Наш курс по Go — https://job4j.ru/courses/38
🔥7
🎒 Акция: Снова в школу
Друзья, мой последний школьный звонок прозвенел ещё в 2003 году, но учиться я продолжаю каждый день.
Хочу поддержать вашу мотивацию и даю скидку на все учебные программы: −15%
Скидка действует до 30 сентября.
👉 http://job4j.ru/
Друзья, мой последний школьный звонок прозвенел ещё в 2003 году, но учиться я продолжаю каждый день.
Хочу поддержать вашу мотивацию и даю скидку на все учебные программы: −15%
Скидка действует до 30 сентября.
👉 http://job4j.ru/
🔥22❤9❤🔥2
Предал Java ради GoLang
Статьи буду публиковать на платформе, так как канал телеграмм для этого не подходит.
https://job4j.ru/article/view/1
Комментарии пока пишите тут. потом добавлю такую возможность на платформу.
Статьи буду публиковать на платформе, так как канал телеграмм для этого не подходит.
https://job4j.ru/article/view/1
Комментарии пока пишите тут. потом добавлю такую возможность на платформу.
👍18😭3🔥1
👍16
Разбор задания с первого этапа собеседования в Яндекс
https://job4j.ru/article/view/3
В приведенном коде есть явные ошибки. Я их добавил специально, чтобы обсудить. Например, мигающие тесты.
https://job4j.ru/article/view/3
В приведенном коде есть явные ошибки. Я их добавил специально, чтобы обсудить. Например, мигающие тесты.
👍4❤2🔥1
SLI/SLO/SLA
Сейчас на работе занимаюсь созданием нового микросервиса и впервые столкнулся с такими показателями.
SLI (Service Level Indicator) — метрика, по которой мы меряем качество сервиса.
Пример: процент успешных HTTP-запросов (2xx) к нашему платежному микросервису.
SLO (Service Level Objective) — целевое значение для метрики.
Пример: "не менее 99.9% успешных запросов за месяц".
SLA (Service Level Agreement) — формальное соглашение с клиентом, где закреплены SLO и последствия нарушения.
Пример: если платежный сервис падает чаще чем позволяет SLO, то мы возвращаем клиенту часть оплаты.
Как у вас на проектах, есть такие критерии?
Сейчас на работе занимаюсь созданием нового микросервиса и впервые столкнулся с такими показателями.
SLI (Service Level Indicator) — метрика, по которой мы меряем качество сервиса.
Пример: процент успешных HTTP-запросов (2xx) к нашему платежному микросервису.
SLO (Service Level Objective) — целевое значение для метрики.
Пример: "не менее 99.9% успешных запросов за месяц".
SLA (Service Level Agreement) — формальное соглашение с клиентом, где закреплены SLO и последствия нарушения.
Пример: если платежный сервис падает чаще чем позволяет SLO, то мы возвращаем клиенту часть оплаты.
Как у вас на проектах, есть такие критерии?
👍4❤3🤔2🤯2
ООП в Go. Проект Tracker. Часть 1.
Настало время показать, как в Go будет выглядеть уже легендарный проект Tracker.
Хотелось бы сразу написать по всем правилам:
Далее https://job4j.ru/article/view/4
Настало время показать, как в Go будет выглядеть уже легендарный проект Tracker.
Хотелось бы сразу написать по всем правилам:
Далее https://job4j.ru/article/view/4
❤10🔥2
ООП в Go. Проект Tracker. Часть 2.
Один из первых элементов, который я хотел разобрать в языке Go, был элемент внедрения зависимости.
После «магии» Spring DI внедрение зависимости в Go выглядит крайне примитивно.
Далее https://job4j.ru/article/view/5
Один из первых элементов, который я хотел разобрать в языке Go, был элемент внедрения зависимости.
После «магии» Spring DI внедрение зависимости в Go выглядит крайне примитивно.
Далее https://job4j.ru/article/view/5
❤7
ООП в Go. Проект Tracker. Часть 3.
Осталось рассмотреть последний элемент — реализацию полиморфизма за счёт интерфейсов. Когда я стал знакомиться с Go и спрашивать впечатления о языке у тех, кто на нём немного писал, первый негативный отзыв я услышал про «утиную типизацию».
Далее https://job4j.ru/article/view/6
Осталось рассмотреть последний элемент — реализацию полиморфизма за счёт интерфейсов. Когда я стал знакомиться с Go и спрашивать впечатления о языке у тех, кто на нём немного писал, первый негативный отзыв я услышал про «утиную типизацию».
Далее https://job4j.ru/article/view/6
👍4❤3
Обновление блока по микросервисам
Сейчас я занят переписыванием блока о микросервисах. Быстро закончить работу не получается, поэтому хочу кратко описать, какие изменения планируются, чтобы помочь тем ученикам, кто уже проходит этот блок.
Далее 👉 https://www.job4j.ru/article/view/7
Сейчас я занят переписыванием блока о микросервисах. Быстро закончить работу не получается, поэтому хочу кратко описать, какие изменения планируются, чтобы помочь тем ученикам, кто уже проходит этот блок.
Далее 👉 https://www.job4j.ru/article/view/7
👍6🔥5✍2
Как инфоцыгане сравнивают Java и Go
Неделю назад мне скинули статью, где сравнивают Java и Go. Почему мне? Потому что я сам начал писать на Go в этом году. Зачем? Что меня не устраивало в Java?
👉 Далее https://job4j.ru/article/view/8
Неделю назад мне скинули статью, где сравнивают Java и Go. Почему мне? Потому что я сам начал писать на Go в этом году. Зачем? Что меня не устраивало в Java?
👉 Далее https://job4j.ru/article/view/8
👍17❤7🔥3