Предлагаю сегодня собраться! Пообсуждать наболевшее и просто интересное. Часиков в 16 по МСК
Anonymous Poll
73%
Да я приду поболтать) 👍
9%
Не, не интересно 🗿
18%
Как я оказался в этой группе? 😱
👍1
Трекер времени: кандалы или инструмент свободы?
Условия которые мне предложили
Самый важный вопрос на котором девушка с милым голосом решила остановиться - а готов ли я вообще работать с трекером.
И это оказалось наверно самым сложным.
Я конечно безапелляционно соврал, что да. Но внутри все вопило - "БЕЖИМ, бл" 😂. Все таки интересно послушать условия.
Итак, что такое трекер:
- На Вашу или выданную компанией машину, устанавливается приложение в котором Вы при начале работы запускаете и при окончании отключаете трекинг.
- Руководитель и заинтересованные лица имеет к нему доступ.
- Кроме того оно в рандомном режиме делает скриншоты вашего экрана (тут от HR последовал рассказ о пойманных работников - обманщиков, но не тех кто писал код с LLM😂 )
- Включать и выключать трекинг рабочего времени можно в любое удобное для Вас время, главное чтобы по итогу в месяц набралось необходимое количество часов.
Трекает и скриншотит ли все остальное время это приложения - история умалчивает.
Затравка для размышлений
На мой взгляд, программист — не кассир и не водитель такси. Его работа творческая, её практически невозможно измерить только часами. Как будет считаться время на поиск "красивого", а не быстрого решения?
Ведь это окажется субъективной оценкой руководителя, на основе которой могут и уволить.
А что если я включил трекер и читаю книгу, к примеру по Спрингу? Работаю? - работаю. Видно результаты? - нет🤣 . Докажите обратное? Но в трудовом кодексе нет презумпции невиновности. Решит руководитель, что ты бездельничал - и здравствуй HH.
И понятно, что "Кампания" требует цифр: менеджеру нужны отчёты, заказчику — бюджеты, компании — предсказуемость и возможность рассчитать время на ту или иную фичу. И тотальный контроль по сути может это значительно ускорить.
Отсюда вопросы которые у меня возникли:
🔜 трекинг времени - это инструмент контроля или инструмент развития?
🔜 насколько законно увольнение на основе трекера?
🔜 и кто вообще согласен на такое?
HR конечно пыталась убедить меня, что к этому быстро привыкаешь, что еще никого не уволили за бездельничество и в целом никто не смотрит на результаты трекера, а важны лишь результаты работы.
Но отчего-то я ей не поверил...
Плюсы и минусы работы с трекером для разработчика
➕
Осознанность: видишь, куда реально утекает твой день. Иногда полдня жрут встречи и попытка понять документацию.
Фокус: легче отслеживать прокрастинацию и возвращать себя в работу, потому, что помнишь о надзоре.
Данные для переговоров: если лид говорит почему так долго - у тебя есть история: вот 12 часов тестов и багфиксов.
➖
Давление и стресс: ощущение, что за тобой следят каждую минуту. Убивает.
Фальшивая эффективность: начинаешь набивать часы, а не реально решать задачи.
Творчество под рубильник: сложно засечь, сколько времени ушло на придумку архитектуры или рефакторинг.
Неформальные задачи теряются: созвоны, менторство, обсуждения коллег — вроде бы работа, а в трекере пустота.
В целом для себя я решил, что пойду работать с трекером только если совсем прижмет.
И для каждого на самом деле это наверно личный выбор.
Кому - то не страшны скриншоты рабочего экрана, так как он честный и трудолюбивый😏
А кто-то (как сказала HR) - "привык работать по 3 часа и нам такие не нужны!". Вот же негодник какой😄
А что касается законности, читайте договор, должностную инструкцию или внутренний регламент:
Если компания документально закрепила за вами обязанность фиксировать время и его не нарушать, ознакомила под подпись, то в этом случае уволить могут за систематическое неисполнение обязанностей (ст. 81 ТК РФ).
А что вы думаете об этом?
Понравилась статья - поделись с другом, позови его на канал и будет тебе моя благодарность 🤝
😎
#motivation
Сегодня будет наверно не мотивационная статья, а больше статья - размышление...
Намедни в одном из созвонов с HR, мне предложили работу с трекером времени.
Скажу сразу, опыта работы с подобным у меня не было и я глубоко задумался, а каково это вообще?
Конечно, те кто вкусил этой организации работы могут в пух и прах разбить мои доводы, но я пожалуй поразмышляю.
Условия которые мне предложили
Самый важный вопрос на котором девушка с милым голосом решила остановиться - а готов ли я вообще работать с трекером.
И это оказалось наверно самым сложным.
Я конечно безапелляционно соврал, что да. Но внутри все вопило - "БЕЖИМ, бл" 😂. Все таки интересно послушать условия.
Итак, что такое трекер:
- На Вашу или выданную компанией машину, устанавливается приложение в котором Вы при начале работы запускаете и при окончании отключаете трекинг.
- Руководитель и заинтересованные лица имеет к нему доступ.
- Кроме того оно в рандомном режиме делает скриншоты вашего экрана (тут от HR последовал рассказ о пойманных работников - обманщиков, но не тех кто писал код с LLM
- Включать и выключать трекинг рабочего времени можно в любое удобное для Вас время, главное чтобы по итогу в месяц набралось необходимое количество часов.
Трекает и скриншотит ли все остальное время это приложения - история умалчивает.
Затравка для размышлений
На мой взгляд, программист — не кассир и не водитель такси. Его работа творческая, её практически невозможно измерить только часами. Как будет считаться время на поиск "красивого", а не быстрого решения?
Ведь это окажется субъективной оценкой руководителя, на основе которой могут и уволить.
А что если я включил трекер и читаю книгу, к примеру по Спрингу? Работаю? - работаю. Видно результаты? - нет
И понятно, что "Кампания" требует цифр: менеджеру нужны отчёты, заказчику — бюджеты, компании — предсказуемость и возможность рассчитать время на ту или иную фичу. И тотальный контроль по сути может это значительно ускорить.
Отсюда вопросы которые у меня возникли:
HR конечно пыталась убедить меня, что к этому быстро привыкаешь, что еще никого не уволили за бездельничество и в целом никто не смотрит на результаты трекера, а важны лишь результаты работы.
Но отчего-то я ей не поверил...
Плюсы и минусы работы с трекером для разработчика
Осознанность: видишь, куда реально утекает твой день. Иногда полдня жрут встречи и попытка понять документацию.
Фокус: легче отслеживать прокрастинацию и возвращать себя в работу, потому, что помнишь о надзоре.
Данные для переговоров: если лид говорит почему так долго - у тебя есть история: вот 12 часов тестов и багфиксов.
Давление и стресс: ощущение, что за тобой следят каждую минуту. Убивает.
Фальшивая эффективность: начинаешь набивать часы, а не реально решать задачи.
Творчество под рубильник: сложно засечь, сколько времени ушло на придумку архитектуры или рефакторинг.
Неформальные задачи теряются: созвоны, менторство, обсуждения коллег — вроде бы работа, а в трекере пустота.
В целом для себя я решил, что пойду работать с трекером только если совсем прижмет.
И для каждого на самом деле это наверно личный выбор.
Кому - то не страшны скриншоты рабочего экрана, так как он честный и трудолюбивый
А кто-то (как сказала HR) - "привык работать по 3 часа и нам такие не нужны!". Вот же негодник какой
А что касается законности, читайте договор, должностную инструкцию или внутренний регламент:
Если компания документально закрепила за вами обязанность фиксировать время и его не нарушать, ознакомила под подпись, то в этом случае уволить могут за систематическое неисполнение обязанностей (ст. 81 ТК РФ).
А что вы думаете об этом?
#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2👎1
Я́ков Леони́дович Шра́йберг (род. 1 сентября 1952, Житомир, УССР) — российский специалист по библиотечно-информационным технологиям, один из драйверов цифровых библиотек и ИТ-инфраструктур для науки и образования.
Майкл Озер Рабин ( иврит : מִיכָאֵל עוזר רַבִּין ; родился 1 сентября 1931 года) — лауреат премии Тьюринга; внес фундаментальный вклад в теорию автоматов, вероятностные алгоритмы и криптографию.
1982 — запуск Commodore 64. Легендарный домашний компьютер, сыгравший ключевую роль в популяризации домашних ПК и программирования.
1992 — релиз Super Mario Kart в Северной Америке (SNES). Культовая гоночная игра, которая стала одной из самых продаваемых на SNES и штурмовала жанр аркадных гонок.
1994 — «Virtual Library» (Библиотека Конгресса США). Библиотека Конгресса США начинает проект виртуальной библиотеки — один из первых в мире масштабных цифровых архивов онлайн, важная веха в развитии электронных библиотек и доступа к знаниям.
#Biography #Birth_Date #Events #01Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Основы ООП в Java
Глава 4. Полиморфизм
Поведение через суперкласс и интерфейс
Полиморфизм (от греч. "много форм") — это способность объектов разных классов отвечать на один и тот же вызов метода по-разному. Это ключевой принцип ООП, который делает код гибким и расширяемым: вы можете работать с объектами через общий тип, не зная их конкретного класса.
Типы полиморфизма в Java:
Compile-time (статический): Через перегрузку методов (overloading) — выбор метода на этапе компиляции.
Runtime (динамический): Через переопределение методов (overriding) — выбор на этапе выполнения, основан на типе объекта.
Поведение через суперкласс: Наследование и overriding
Через суперкласс полиморфизм достигается, когда подкласс переопределяет методы суперкласса. Ссылка суперкласса может указывать на объект подкласса, и вызов метода выполнит версию подкласса (динамическая диспетчеризация).
Пример
Теперь полиморфизм в действии:
Нюанс: Если метод не переопределен, вызовется версия суперкласса.
Это позволяет писать общий код:
например, массив Animal[] animals = {new Dog(), new Cat()}; и цикл for (Animal a : animals) a.makeSound(); — каждый издаст свой звук.
Поведение через интерфейс: Implements и полиморфизм
Интерфейс — это контракт, определяющий методы без реализации. Полиморфизм через интерфейсы достигается, когда классы реализуют (implements) интерфейс, предоставляя свою реализацию. Ссылка интерфейса может указывать на любой реализующий объект.
Синтаксис:
Класс:
Пример интерфейса SoundMaker:
Теперь классы реализуют его:
Полиморфизм:
Интерфейс обеспечивает полиморфизм без наследования: классы не связаны иерархией, но объединены контрактом.
#Java #для_новичков #beginner #poliphormizm
Глава 4. Полиморфизм
Поведение через суперкласс и интерфейс
Полиморфизм (от греч. "много форм") — это способность объектов разных классов отвечать на один и тот же вызов метода по-разному. Это ключевой принцип ООП, который делает код гибким и расширяемым: вы можете работать с объектами через общий тип, не зная их конкретного класса.
Типы полиморфизма в Java:
Compile-time (статический): Через перегрузку методов (overloading) — выбор метода на этапе компиляции.
Runtime (динамический): Через переопределение методов (overriding) — выбор на этапе выполнения, основан на типе объекта.
Поведение через суперкласс: Наследование и overriding
Через суперкласс полиморфизм достигается, когда подкласс переопределяет методы суперкласса. Ссылка суперкласса может указывать на объект подкласса, и вызов метода выполнит версию подкласса (динамическая диспетчеризация).
Пример
// Animal.java
public class Animal {
protected String name;
public Animal(String name) {
this.name = name;
}
public void makeSound() {
System.out.println(name + " издает звук.");
}
}
// Dog.java
public class Dog extends Animal {
public Dog(String name) {
super(name);
}
@Override
public void makeSound() {
System.out.println(name + " лает: Гав!");
}
}
// Cat.java (еще один подкласс)
public class Cat extends Animal {
public Cat(String name) {
super(name);
}
@Override
public void makeSound() {
System.out.println(name + " мяукает: Мяу!");
}
}
Теперь полиморфизм в действии:
public class Main {
public static void main(String[] args) {
Animal animal1 = new Dog("Шарик"); // Ссылка Animal на объект Dog
Animal animal2 = new Cat("Мурка"); // Ссылка Animal на объект Cat
animal1.makeSound(); // Вывод: Шарик лает: Гав! (версия Dog)
animal2.makeSound(); // Вывод: Мурка мяукает: Мяу! (версия Cat)
}
}
Здесь Animal animal1 = new Dog("Шарик"); Тип ссылки — Animal (статический тип), тип объекта — Dog (динамический тип).
Вызов makeSound(): JVM смотрит на динамический тип и вызывает переопределенную версию.
Нюанс: Если метод не переопределен, вызовется версия суперкласса.
Это позволяет писать общий код:
например, массив Animal[] animals = {new Dog(), new Cat()}; и цикл for (Animal a : animals) a.makeSound(); — каждый издаст свой звук.
Поведение через интерфейс: Implements и полиморфизм
Интерфейс — это контракт, определяющий методы без реализации. Полиморфизм через интерфейсы достигается, когда классы реализуют (implements) интерфейс, предоставляя свою реализацию. Ссылка интерфейса может указывать на любой реализующий объект.
Синтаксис:
public interface InterfaceName { void method(); }
Класс:
public class ClassName implements InterfaceName { @Override public void method() { ... } }
Пример интерфейса SoundMaker:
public interface SoundMaker {
void makeSound(); // Абстрактный метод
}
Теперь классы реализуют его:
// Dog.java (теперь implements SoundMaker, без extends для простоты)
public class Dog implements SoundMaker {
private String name;
public Dog(String name) {
this.name = name;
}
@Override
public void makeSound() {
System.out.println(name + " лает: Гав!");
}
}
// Cat.java
public class Cat implements SoundMaker {
private String name;
public Cat(String name) {
this.name = name;
}
@Override
public void makeSound() {
System.out.println(name + " мяукает: Мяу!");
}
}
Полиморфизм:
public class Main {
public static void main(String[] args) {
SoundMaker sound1 = new Dog("Шарик"); // Ссылка интерфейса на Dog
SoundMaker sound2 = new Cat("Мурка");
sound1.makeSound(); // Шарик лает: Гав!
sound2.makeSound(); // Мурка мяукает: Мяу!
}
}
Интерфейс обеспечивает полиморфизм без наследования: классы не связаны иерархией, но объединены контрактом.
#Java #для_новичков #beginner #poliphormizm
👍6
Нюансы полиморфизма через суперкласс и интерфейс
Статический vs динамический тип:
Статический: Тип ссылки (Animal a) — проверяется на компиляции.
Динамический: Тип объекта (new Dog()) — определяет метод на runtime.
Нюанс: Для полей — статический тип (field hiding), для методов — динамический.
Перегрузка vs переопределение:
Перегрузка: Compile-time, разные сигнатуры.
Переопределение: Runtime, одинаковые сигнатуры.
Интерфейсы vs абстрактные классы:
Интерфейсы: Только абстрактные методы (до Java 8), множественная реализация.
Суперклассы: Могут иметь реализацию, состояние, одиночное наследование.
Ошибки:
Если метод не переопределен: Вызов супер/интерфейс версии (или ошибка, если abstract).
Несовместимая сигнатура: Не overriding, а новый метод.
@Override помогает ловить ошибки.
Полиморфизм в коллекциях:
List list = new ArrayList<>(); list.add(new Dog()); — затем цикл по list с вызовом makeSound().
Ограничения:
Private/final/static методы: Не участвуют в полиморфизме.
Конструкторы: Не полиморфны.
Как создать это в IntelliJ IDEA
Создайте интерфейс: New → Interface → SoundMaker.
Implements: В классе Dog: extends/implements, IDE подскажет override.
Полиморфизм: В Main создайте ссылки и протестируйте.
Полезные советы для новичков
Используйте полиморфизм для обобщения: Пишите код для супер/интерфейса, добавляйте подклассы без изменений.
@Override всегда: Избегайте ошибок.
Интерфейсы для контрактов: Когда нужно поведение без состояния.
Ресурсы: Oracle Tutorials on Polymorphism.
#Java #для_новичков #beginner #poliphormizm
Статический vs динамический тип:
Статический: Тип ссылки (Animal a) — проверяется на компиляции.
Динамический: Тип объекта (new Dog()) — определяет метод на runtime.
Нюанс: Для полей — статический тип (field hiding), для методов — динамический.
Перегрузка vs переопределение:
Перегрузка: Compile-time, разные сигнатуры.
Переопределение: Runtime, одинаковые сигнатуры.
Интерфейсы vs абстрактные классы:
Интерфейсы: Только абстрактные методы (до Java 8), множественная реализация.
Суперклассы: Могут иметь реализацию, состояние, одиночное наследование.
Ошибки:
Если метод не переопределен: Вызов супер/интерфейс версии (или ошибка, если abstract).
Несовместимая сигнатура: Не overriding, а новый метод.
@Override помогает ловить ошибки.
Полиморфизм в коллекциях:
List list = new ArrayList<>(); list.add(new Dog()); — затем цикл по list с вызовом makeSound().
Ограничения:
Private/final/static методы: Не участвуют в полиморфизме.
Конструкторы: Не полиморфны.
Как создать это в IntelliJ IDEA
Создайте интерфейс: New → Interface → SoundMaker.
Implements: В классе Dog: extends/implements, IDE подскажет override.
Полиморфизм: В Main создайте ссылки и протестируйте.
Полезные советы для новичков
Используйте полиморфизм для обобщения: Пишите код для супер/интерфейса, добавляйте подклассы без изменений.
@Override всегда: Избегайте ошибок.
Интерфейсы для контрактов: Когда нужно поведение без состояния.
Ресурсы: Oracle Tutorials on Polymorphism.
#Java #для_новичков #beginner #poliphormizm
👍3🔥2
Как долго вы учите Java? 🤓
Anonymous Poll
4%
Уже более 5 лет 😭
7%
От 3х до 5и 💃
54%
От 1 года до 3х 💪
35%
Меньше года, но меня не остановить ✈️
🔥1
Что выведет код?
#Tasks
class A010925 {
public void print() {
System.out.println("A");
}
}
class B010925 extends A010925 {
public void print() {
System.out.println("B");
}
public void print(String s) {
System.out.println("B" + s);
}
}
public class Task010925 {
public static void main(String[] args) {
A010925 obj = new B010925();
obj.print("test");
}
}
#Tasks
🔥4
👍6🆒1
Please open Telegram to view this post
VIEW IN TELEGRAM
Сетка
Java for Beginner. Канал в Сетке
Канал для новичков в Java
🔥2🗿1🆒1
Вопрос с собеседований
Что такое ClassCastException?🤓
Ответ:
ClassCastException возникает при попытке привести объект к несовместимому типу.
Пример:
Object obj = "string";
Integer num = (Integer) obj; // ClassCastException
Избегайте через instanceof или generics.
#собеседование
Что такое ClassCastException?
Ответ:
Пример:
Object obj = "string";
Integer num = (Integer) obj; // ClassCastException
Избегайте через instanceof или generics.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Александр Семёнович Хо́лево (род. 2 сентября 1943) — один из основателей квантовой теории информации, граница (теорема) Холево — базовый результат области.
Ивар Ялмар Якобсон (швед. Ivar Hjalmar Jacobson; 2 сентября 1939 года) — соавтор UML и RUP; внёс систематизацию объектно-ориентированного анализа и проектирования.
Эрик Пол Оллман (англ. Eric Paul Allman, родился 2 сентября, 1955, Эль-Серрито) — автор sendmail; ключевая фигура раннего e-mail-интернета.
1969 — один из «дней рождения Интернета». В лаборатории Калифорнийского университета состоялась первая успешная передача данных между соседними компьютерами.
1969 — первый банкомат в США. Впервые автоматизированно выдают наличные — химический банк Rockville Centre, NY, начало эпохи ATM банков.
1997 — IBM анонсирует обновленный "шахматный суперкомпьютер" (RS/6000 SP), на 58% быстрее. Апгрейд Deep Blue спустя несколько месяцев после победы над Г. Каспаровым.
2008 — вышла первая публичная бета-версия браузера Google Chrome.
#Biography #Birth_Date #Events #02Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Dockerfile и образы для Java
Основы: ключевые инструкции в Dockerfile
Dockerfile — декларативный файл: вы пишете, что нужно, а Docker строит образ слой за слоем. Каждый слой — это изменение файловой системы, как кирпичик в стене.
FROM: Это основа — базовый образ, от которого вы строите.
Например, FROM openjdk:21-jre — берет официальный образ с Java Runtime Environment (JRE, среда выполнения без компилятора).
Термин "образ" — это архив с файлами, конфигурацией и инструкциями.
FROM определяет родительский слой; используйте official-образы из Docker Hub для безопасности (они сканируются на уязвимости).
Нюанс: тег (как :21-jre) фиксирует версию — избегайте :latest для воспроизводимости, иначе обновления сломают билд.
RUN: Выполняет команду внутри образа, создавая новый слой.
Например, RUN apt-get update && apt-get install -y curl — обновляет пакеты и ставит curl.
Это как запуск терминала в контейнере.
RUN запускает временный контейнер, выполняет команду и фиксирует изменения (copy-on-write в overlayfs).
Объединяйте команды в один RUN с &&, чтобы минимизировать слои — много слоев замедляют поиск файлов (overhead до 10% на I/O). Избегайте RUN для часто меняющихся частей, иначе кэш сломается (об этом позже).
COPY: Копирует файлы с хоста (вашей машины) в образ.
Например, COPY target/myapp.jar /app/myapp.jar — переносит JAR-файл (скомпилированное Java-приложение) в директорию /app. Альтернатива ADD — то же, но с распаковкой архивов.
COPY предпочитается для простоты; оно сохраняет ownership и permissions. Нюанс: если файлы меняются, слои ниже инвалидируются — ставьте COPY после стабильных RUN.
ENTRYPOINT: Фиксированная команда запуска контейнера, как "java -jar /app/myapp.jar". Она не переопределяется аргументами в docker run. Это "главный вход" — контейнер всегда стартует с этого.
CMD: Дефолтные аргументы для ENTRYPOINT или самостоятельная команда.
Например, CMD ["-Dserver.port=8080"]. Переопределяется в run.
ENTRYPOINT + CMD — для гибкости; используйте ENTRYPOINT для скрипта-обертки (проверки env, graceful shutdown). В JSON-формате (["java", "-jar"]) избегайте shell-обработки; shell-форм (java -jar) — для переменных.
Эти инструкции строят слои последовательно: FROM — база, RUN/COPY — изменения, ENTRYPOINT/CMD — запуск.
Как собрать свой первый образ с Java-приложением
Представьте, что вы готовите блюдо по рецепту — Dockerfile это рецепт, docker build — процесс приготовления, а образ — готовый продукт, который можно "запускать" сколько угодно раз.
Возьмем за основу готовый JAR-файл (это скомпилированное Java-приложение, как архив с кодом и зависимостями, созданный с помощью инструментов вроде Maven или Gradle). Если у вас нет JAR, вы можете создать простое Hello World-приложение в Java и скомпилировать его.
Предположим, ваша директория проекта выглядит так:
есть папка target с myapp.jar (результат компиляции).
Создайте в корне файл Dockerfile (без расширения, с большой D).
Вот содержимое Dockerfile для минимального примера:
Разберем, что здесь происходит:
FROM eclipse-temurin:21-jre: Базовый образ от Eclipse Temurin — это официальная дистрибуция OpenJDK, оптимизированная для контейнеров.
:21-jre значит версия Java 21 с только runtime-окружением (JRE), без компилятора (JDK). Это делает образ легче — около 200-300 МБ.
Temurin предпочтительнее openjdk, потому что он включает патчи для контейнеров (container-aware) и лучше поддерживается Adoptium. Если вы на ARM (как Mac M1), тег :21-jre-arm64, но с Buildx это автоматически.
COPY target/myapp.jar /app/myapp.jar: Копируем JAR с хоста в образ. /app — директория внутри контейнера. Нюанс: Путь target/ относительный к контексту build (текущей папке). Если JAR в другом месте, скорректируйте.
WORKDIR /app: Устанавливает рабочую директорию, как команда cd в терминале. Все последующие команды (RUN, CMD) будут оттуда. Это упрощает пути и делает образ чище.
#Java #middle #Docker #Dockerfile
Основы: ключевые инструкции в Dockerfile
Dockerfile — декларативный файл: вы пишете, что нужно, а Docker строит образ слой за слоем. Каждый слой — это изменение файловой системы, как кирпичик в стене.
FROM: Это основа — базовый образ, от которого вы строите.
Например, FROM openjdk:21-jre — берет официальный образ с Java Runtime Environment (JRE, среда выполнения без компилятора).
Термин "образ" — это архив с файлами, конфигурацией и инструкциями.
FROM определяет родительский слой; используйте official-образы из Docker Hub для безопасности (они сканируются на уязвимости).
Нюанс: тег (как :21-jre) фиксирует версию — избегайте :latest для воспроизводимости, иначе обновления сломают билд.
RUN: Выполняет команду внутри образа, создавая новый слой.
Например, RUN apt-get update && apt-get install -y curl — обновляет пакеты и ставит curl.
Это как запуск терминала в контейнере.
RUN запускает временный контейнер, выполняет команду и фиксирует изменения (copy-on-write в overlayfs).
Объединяйте команды в один RUN с &&, чтобы минимизировать слои — много слоев замедляют поиск файлов (overhead до 10% на I/O). Избегайте RUN для часто меняющихся частей, иначе кэш сломается (об этом позже).
COPY: Копирует файлы с хоста (вашей машины) в образ.
Например, COPY target/myapp.jar /app/myapp.jar — переносит JAR-файл (скомпилированное Java-приложение) в директорию /app. Альтернатива ADD — то же, но с распаковкой архивов.
COPY предпочитается для простоты; оно сохраняет ownership и permissions. Нюанс: если файлы меняются, слои ниже инвалидируются — ставьте COPY после стабильных RUN.
ENTRYPOINT: Фиксированная команда запуска контейнера, как "java -jar /app/myapp.jar". Она не переопределяется аргументами в docker run. Это "главный вход" — контейнер всегда стартует с этого.
CMD: Дефолтные аргументы для ENTRYPOINT или самостоятельная команда.
Например, CMD ["-Dserver.port=8080"]. Переопределяется в run.
ENTRYPOINT + CMD — для гибкости; используйте ENTRYPOINT для скрипта-обертки (проверки env, graceful shutdown). В JSON-формате (["java", "-jar"]) избегайте shell-обработки; shell-форм (java -jar) — для переменных.
Эти инструкции строят слои последовательно: FROM — база, RUN/COPY — изменения, ENTRYPOINT/CMD — запуск.
Как собрать свой первый образ с Java-приложением
Представьте, что вы готовите блюдо по рецепту — Dockerfile это рецепт, docker build — процесс приготовления, а образ — готовый продукт, который можно "запускать" сколько угодно раз.
Возьмем за основу готовый JAR-файл (это скомпилированное Java-приложение, как архив с кодом и зависимостями, созданный с помощью инструментов вроде Maven или Gradle). Если у вас нет JAR, вы можете создать простое Hello World-приложение в Java и скомпилировать его.
Предположим, ваша директория проекта выглядит так:
есть папка target с myapp.jar (результат компиляции).
Создайте в корне файл Dockerfile (без расширения, с большой D).
Вот содержимое Dockerfile для минимального примера:
textFROM eclipse-temurin:21-jre
COPY target/myapp.jar /app/myapp.jar
WORKDIR /app
ENTRYPOINT ["java", "-jar", "myapp.jar"]
Разберем, что здесь происходит:
FROM eclipse-temurin:21-jre: Базовый образ от Eclipse Temurin — это официальная дистрибуция OpenJDK, оптимизированная для контейнеров.
:21-jre значит версия Java 21 с только runtime-окружением (JRE), без компилятора (JDK). Это делает образ легче — около 200-300 МБ.
Temurin предпочтительнее openjdk, потому что он включает патчи для контейнеров (container-aware) и лучше поддерживается Adoptium. Если вы на ARM (как Mac M1), тег :21-jre-arm64, но с Buildx это автоматически.
COPY target/myapp.jar /app/myapp.jar: Копируем JAR с хоста в образ. /app — директория внутри контейнера. Нюанс: Путь target/ относительный к контексту build (текущей папке). Если JAR в другом месте, скорректируйте.
WORKDIR /app: Устанавливает рабочую директорию, как команда cd в терминале. Все последующие команды (RUN, CMD) будут оттуда. Это упрощает пути и делает образ чище.
#Java #middle #Docker #Dockerfile
👍3
ENTRYPOINT ["java", "-jar", "myapp.jar"]: Фиксированная команда запуска. Формат в скобках — exec-форма, без shell — быстрее и безопаснее (нет интерпретации переменных). При запуске контейнера Docker выполнит java -jar myapp.jar из /app.
Чтобы собрать образ, откройте терминал в директории с Dockerfile и выполните:
docker build: Команда для сборки.
-t myjavaapp:1.0: Тег (метка) для образа — имя:версия. Без тега — random ID.
.: Контекст — текущая директория, откуда берутся файлы для COPY.
Что происходит под капотом во время сборки?
Docker daemon читает Dockerfile строку за строкой, создавая промежуточные контейнеры для каждого слоя.
Для FROM — pull базового образа (если нет локально).
Затем RUN/COPY — запускает temp-контейнер, применяет изменения и commit'ит слой (как git commit). Каждый слой — delta (изменения) в overlayfs; кэш проверяется по хэшу (инструкция + файлы). Если все гладко, сборка занимает секунды. Вывод в терминале покажет шаги: "Step 1/4 : FROM...", с хэшами слоев.
После сборки проверьте: docker images — увидите myjavaapp:1.0 с размером. Используйте docker history myjavaapp:1.0 — покажет слои в обратном порядке, с размерами и командами. Это поможет оптимизировать: если слой большой (из-за RUN install), объедините.
Теперь запустите:
Контейнер стартует, выполнит JAR и выйдет (если app не daemon). Добавьте -d для фона, -p 8080:8080 для портов (если app сервер).
Логи:
Распространенные ошибки и как фиксить:
"No such file": JAR не найден — проверьте путь в COPY; добавьте .dockerignore для игнора лишнего (как .gitignore).
Pull failed: Нет интернета или registry down — используйте локальные образы.
Build краш в RUN: Добавьте --no-cache в build для полной перестройки (игнор кэша).
Если secrets нужны (пароли в build), используйте --secret id=mysecret,source=.env; в RUN echo $mysecret. В CI (GitHub Actions) интегрируйте с caching для ускорения.
Это базовый образ — для dev. В production добавьте healthcheck: HEALTHCHECK CMD curl -f http://localhost:8080/health.
Усложняем: многоэтапная сборка
Multi-stage build — это продвинутый подход, где вы разделяете процесс на этапы: один для компиляции кода (с полным JDK и build-tools вроде Maven), а другой — только для запуска (минимальный JRE). Это делает финальный образ компактным, без лишних инструментов, что снижает размер, ускоряет deploy и повышает безопасность (меньше vuln в production).
Пример с Maven (предполагаем, у вас есть src/ и pom.xml — файл конфигурации Maven):
AS build: Имя первого этапа — можно ссылаться в COPY --from.
RUN mvn clean package: Компилирует JAR, пропуская тесты для скорости (-DskipTests). В памяти: Maven кэширует deps в /root/.m2, но в multi-stage это не сохраняется в финале.
COPY --from=build: Берет только JAR из первого этапа — остальное (JDK, Maven) отбрасывается.
Сборка:
Финальный образ ~150-300 МБ vs 1ГБ+ с JDK. В BuildKit (дефолт) этапы могут параллелизоваться, если нет зависимостей; используйте --target=build для остановки на первом этапе (тесты).
Нюанс: Если deps меняются редко, копируйте pom.xml первым, затем RUN mvn dependency:go-offline — кэш deps сохранится. В CI добавьте cache-from для reuse.
Подводные камни: Если тесты нужны, уберите -DskipTests; для Gradle замените на FROM gradle:8.10-jdk21 и RUN gradle build.
#Java #middle #Docker #Dockerfile
Чтобы собрать образ, откройте терминал в директории с Dockerfile и выполните:
docker build -t myjavaapp:1.0 .
docker build: Команда для сборки.
-t myjavaapp:1.0: Тег (метка) для образа — имя:версия. Без тега — random ID.
.: Контекст — текущая директория, откуда берутся файлы для COPY.
Что происходит под капотом во время сборки?
Docker daemon читает Dockerfile строку за строкой, создавая промежуточные контейнеры для каждого слоя.
Для FROM — pull базового образа (если нет локально).
Затем RUN/COPY — запускает temp-контейнер, применяет изменения и commit'ит слой (как git commit). Каждый слой — delta (изменения) в overlayfs; кэш проверяется по хэшу (инструкция + файлы). Если все гладко, сборка занимает секунды. Вывод в терминале покажет шаги: "Step 1/4 : FROM...", с хэшами слоев.
После сборки проверьте: docker images — увидите myjavaapp:1.0 с размером. Используйте docker history myjavaapp:1.0 — покажет слои в обратном порядке, с размерами и командами. Это поможет оптимизировать: если слой большой (из-за RUN install), объедините.
Теперь запустите:
docker run myjavaapp:1.0
Контейнер стартует, выполнит JAR и выйдет (если app не daemon). Добавьте -d для фона, -p 8080:8080 для портов (если app сервер).
Логи:
docker logs <container-id>.</container-id>
Распространенные ошибки и как фиксить:
"No such file": JAR не найден — проверьте путь в COPY; добавьте .dockerignore для игнора лишнего (как .gitignore).
Pull failed: Нет интернета или registry down — используйте локальные образы.
Build краш в RUN: Добавьте --no-cache в build для полной перестройки (игнор кэша).
Если secrets нужны (пароли в build), используйте --secret id=mysecret,source=.env; в RUN echo $mysecret. В CI (GitHub Actions) интегрируйте с caching для ускорения.
Это базовый образ — для dev. В production добавьте healthcheck: HEALTHCHECK CMD curl -f http://localhost:8080/health.
Усложняем: многоэтапная сборка
Multi-stage build — это продвинутый подход, где вы разделяете процесс на этапы: один для компиляции кода (с полным JDK и build-tools вроде Maven), а другой — только для запуска (минимальный JRE). Это делает финальный образ компактным, без лишних инструментов, что снижает размер, ускоряет deploy и повышает безопасность (меньше vuln в production).
Пример с Maven (предполагаем, у вас есть src/ и pom.xml — файл конфигурации Maven):
text# Этап 1: Сборка приложения
FROM maven:3.9.6-eclipse-temurin-21 AS build
COPY src /app/src
COPY pom.xml /app
WORKDIR /app
RUN mvn clean package -DskipTests
# Этап 2: Runtime-окружение
FROM eclipse-temurin:21-jre
COPY --from=build /app/target/myapp.jar /app/myapp.jar
WORKDIR /app
ENTRYPOINT ["java", "-jar", "myapp.jar"]
AS build: Имя первого этапа — можно ссылаться в COPY --from.
RUN mvn clean package: Компилирует JAR, пропуская тесты для скорости (-DskipTests). В памяти: Maven кэширует deps в /root/.m2, но в multi-stage это не сохраняется в финале.
COPY --from=build: Берет только JAR из первого этапа — остальное (JDK, Maven) отбрасывается.
Сборка:
docker build -t myjavaapp:prod .
Финальный образ ~150-300 МБ vs 1ГБ+ с JDK. В BuildKit (дефолт) этапы могут параллелизоваться, если нет зависимостей; используйте --target=build для остановки на первом этапе (тесты).
Нюанс: Если deps меняются редко, копируйте pom.xml первым, затем RUN mvn dependency:go-offline — кэш deps сохранится. В CI добавьте cache-from для reuse.
Подводные камни: Если тесты нужны, уберите -DskipTests; для Gradle замените на FROM gradle:8.10-jdk21 и RUN gradle build.
#Java #middle #Docker #Dockerfile
👍5
Alpine vs Slim vs Distroless: плюсы и минусы
Выбор базового образа влияет на размер, производительность и совместимость. Давайте сравним варианты для Java.
Alpine (eclipse-temurin:21-jre-alpine):
Основан на легком Linux-дистрибутиве с musl libc (библиотека C). Плюсы: Очень маленький (~70-100 МБ), быстро загружается, экономит диск/сеть.
Минусы: Musl не полностью совместим с glibc (стандарт в Java) — проблемы с нативными библиотеками (JNI), шрифтами, локалями или DNS. Чревато крашами в enterprise-apps.
Когда использовать: Простые сервисы без native-кода; тестируйте entropy (-Djava.security.egd=file:/dev/./urandom для random). Musl легче в памяти (меньше overhead), но glibc стабильнее для legacy.
Slim (eclipse-temurin:21-jre-slim):
На базе Debian slim (урезанный).
Плюсы: Glibc-совместимость, размер ~150-250 МБ, включает базовые утилиты.
Минусы: Больше Alpine, но все равно минимален по сравнению с full. Когда: Баланс — для apps с зависимостями (шрифты, crypto). Senior: Добавьте RUN apt-get install -y fontconfig для fonts; лучше для multi-platform.
Distroless (gcr.io/distroless/java21:nonroot):
Сверхминимальный, без ОС-утилит. Плюсы: ~50-100 МБ, высокая безопасность (нет shell — хакеры не запустят команды), immutable.
Минусы: Нет инструментов для debug (bash, jcmd); вручную добавляйте CA-certs (COPY /etc/ssl/certs).
Чревато: Нет tzdata — env TZ=UTC; signals ok, но shutdown-hooks в коде. Когда: Production, где security > удобство. В Kubernetes — идеал для scaling; используйте debug-sidecar для отладки.
Выбор: Начните с Slim для dev, перейдите на Distroless для prod. Всегда тестируйте под load — проверьте java -version в run.
Как работает кэширование слоёв и почему важен порядок инструкций
Кэширование слоёв — это один из самых мощных механизмов Docker, который делает повторные сборки образов быстрыми и эффективными. Без него каждая сборка начиналась бы с нуля, что занимало бы много времени, особенно для сложных приложений с установкой зависимостей. Представьте кэш как "память" Docker — если ничего не изменилось в части рецепта (Dockerfile), он использует готовый результат из предыдущей сборки, вместо того чтобы готовить заново.
Каждый слой в образе — это результат выполнения одной инструкции в Dockerfile (FROM, RUN, COPY и т.д.). Docker присваивает каждому слою уникальный идентификатор на основе хэша (обычно SHA256). Хэш рассчитывается не только от самой инструкции, но и от её контекста: для RUN — это текст команды, для COPY — checksum (контрольная сумма) копируемых файлов, для FROM — тег базового образа. Если при следующей сборке хэш совпадает с кэшированным, Docker пропускает выполнение и берет готовый слой из локального хранилища.
Процесс кэширования шаг за шагом:
Проверка кэша при старте сборки: Когда вы запускаете docker build, Docker daemon (фоновый процесс, управляющий сборками) сканирует Dockerfile сверху вниз. Для первой инструкции (обычно FROM) он проверяет, есть ли в локальном кэше слой с таким же хэшем. Если базовый образ изменился (например, обновился в registry), кэш инвалидируется, и Docker pull'нет свежую версию.
#Java #middle #Docker #Dockerfile
Выбор базового образа влияет на размер, производительность и совместимость. Давайте сравним варианты для Java.
Alpine (eclipse-temurin:21-jre-alpine):
Основан на легком Linux-дистрибутиве с musl libc (библиотека C). Плюсы: Очень маленький (~70-100 МБ), быстро загружается, экономит диск/сеть.
Минусы: Musl не полностью совместим с glibc (стандарт в Java) — проблемы с нативными библиотеками (JNI), шрифтами, локалями или DNS. Чревато крашами в enterprise-apps.
Когда использовать: Простые сервисы без native-кода; тестируйте entropy (-Djava.security.egd=file:/dev/./urandom для random). Musl легче в памяти (меньше overhead), но glibc стабильнее для legacy.
Slim (eclipse-temurin:21-jre-slim):
На базе Debian slim (урезанный).
Плюсы: Glibc-совместимость, размер ~150-250 МБ, включает базовые утилиты.
Минусы: Больше Alpine, но все равно минимален по сравнению с full. Когда: Баланс — для apps с зависимостями (шрифты, crypto). Senior: Добавьте RUN apt-get install -y fontconfig для fonts; лучше для multi-platform.
Distroless (gcr.io/distroless/java21:nonroot):
Сверхминимальный, без ОС-утилит. Плюсы: ~50-100 МБ, высокая безопасность (нет shell — хакеры не запустят команды), immutable.
Минусы: Нет инструментов для debug (bash, jcmd); вручную добавляйте CA-certs (COPY /etc/ssl/certs).
Чревато: Нет tzdata — env TZ=UTC; signals ok, но shutdown-hooks в коде. Когда: Production, где security > удобство. В Kubernetes — идеал для scaling; используйте debug-sidecar для отладки.
Выбор: Начните с Slim для dev, перейдите на Distroless для prod. Всегда тестируйте под load — проверьте java -version в run.
Как работает кэширование слоёв и почему важен порядок инструкций
Кэширование слоёв — это один из самых мощных механизмов Docker, который делает повторные сборки образов быстрыми и эффективными. Без него каждая сборка начиналась бы с нуля, что занимало бы много времени, особенно для сложных приложений с установкой зависимостей. Представьте кэш как "память" Docker — если ничего не изменилось в части рецепта (Dockerfile), он использует готовый результат из предыдущей сборки, вместо того чтобы готовить заново.
Каждый слой в образе — это результат выполнения одной инструкции в Dockerfile (FROM, RUN, COPY и т.д.). Docker присваивает каждому слою уникальный идентификатор на основе хэша (обычно SHA256). Хэш рассчитывается не только от самой инструкции, но и от её контекста: для RUN — это текст команды, для COPY — checksum (контрольная сумма) копируемых файлов, для FROM — тег базового образа. Если при следующей сборке хэш совпадает с кэшированным, Docker пропускает выполнение и берет готовый слой из локального хранилища.
Процесс кэширования шаг за шагом:
Проверка кэша при старте сборки: Когда вы запускаете docker build, Docker daemon (фоновый процесс, управляющий сборками) сканирует Dockerfile сверху вниз. Для первой инструкции (обычно FROM) он проверяет, есть ли в локальном кэше слой с таким же хэшем. Если базовый образ изменился (например, обновился в registry), кэш инвалидируется, и Docker pull'нет свежую версию.
#Java #middle #Docker #Dockerfile
👍3