#️⃣ #php #course #series
🚀 Чи знаєш ти, що PHP так вміє? 7/10
🧱 Enums
🎯 Тилькі цільові значення
📦 Додано у версії: PHP 8.1
💡 Що дає: нативний механізм для створення перелічуваних типів — із чіткими, типізованими значеннями замість "магічних рядків та чисел" і нескінченних const.
❤️ Трохи особистого
Це один із моїх найулюбленіших інструментів у PHP. З моменту їх появи я взагалі не уявляю розробки без enum’ів — вони зменшують кількість помилок, роблять код читабельним і гарантують типобезпеку.
Але спілкування з розробниками показує, що далеко не всі розділяють цей захват. Тому хочу поділитися своєю любов’ю до них і пояснити, чому це не просто "список значень", а справжній крок вперед для PHP.
🧠 Типи enum’ів
PHP має два різновиди enum’ів:
1️⃣ Backed Enum — із базовим значенням (
Кожен
📦 Для чого:
— зручно в статусах замовлень, документів, платежів, типів повідомлень, типів працівників, тощо;
— легко зберігати в базі як звичайний рядок;
— можна отримати enum через
2️⃣ Pure Enum — без бекінгу
Просто набір унікальних case без значень. Використовується тоді, коли значення не потрібне —
важливий сам факт "стану" або "режиму".
📦 Для чого:
— для внутрішніх логічних станів або режимів роботи;
— коли не треба нічого зберігати у БД;
— коли досить просто перевірити
🧩 Більше, ніж просто перелік
Більшість вважає, що
⚙️ Приклад enum із методами
🧱 Інший приклад
Статуси документів, каналів, ролей
🧭 Висновок
❤️ Я вже не уявляю розробки без enum’ів.
І якщо ти досі не використовуєш їх у своїх проєктах — просто спробуй, через тиждень без них ти вже не зможеш писати старим способом.
———
⬅️ Іменовані аргументи | readonly + accessors ➡️
🚀 Чи знаєш ти, що PHP так вміє? 7/10
🧱 Enums
🎯 Тилькі цільові значення
📦 Додано у версії: PHP 8.1
💡 Що дає: нативний механізм для створення перелічуваних типів — із чіткими, типізованими значеннями замість "магічних рядків та чисел" і нескінченних const.
❤️ Трохи особистого
Це один із моїх найулюбленіших інструментів у PHP. З моменту їх появи я взагалі не уявляю розробки без enum’ів — вони зменшують кількість помилок, роблять код читабельним і гарантують типобезпеку.
Але спілкування з розробниками показує, що далеко не всі розділяють цей захват. Тому хочу поділитися своєю любов’ю до них і пояснити, чому це не просто "список значень", а справжній крок вперед для PHP.
🧠 Типи enum’ів
PHP має два різновиди enum’ів:
1️⃣ Backed Enum — із базовим значенням (
string або int)Кожен
case має прив’язане значення, це дозволяє порівнювати його з іншими значеннями, серіалізувати, зберігати його в БД, та при цьому бути впевненним, що значення завжди буде одним з дозволених в переліченні.enum Status: string
{
case DRAFT = 'draft';
case ACTIVE = 'active';
case ARCHIVED = 'archived';
}
📦 Для чого:
— зручно в статусах замовлень, документів, платежів, типів повідомлень, типів працівників, тощо;
— легко зберігати в базі як звичайний рядок;
— можна отримати enum через
Status::from('draft') або безпечно — tryFrom('draft').2️⃣ Pure Enum — без бекінгу
Просто набір унікальних case без значень. Використовується тоді, коли значення не потрібне —
важливий сам факт "стану" або "режиму".
enum Direction
{
case NORTH;
case SOUTH;
case EAST;
case WEST;
}
📦 Для чого:
— для внутрішніх логічних станів або режимів роботи;
— коли не треба нічого зберігати у БД;
— коли досить просто перевірити
if ($direction === Direction::NORTH).🧩 Більше, ніж просто перелік
Більшість вважає, що
enum — це просто заміна const. Насправді це класоподібна конструкція, у якій можна (і треба!) додавати методи, поведінку, статичні методи та перетворення значень.⚙️ Приклад enum із методами
enum Status: string
{
case DRAFT = 'draft';
case ACTIVE = 'active';
case ARCHIVED = 'archived';
// 🔹 Нестатичний метод — для конкретного значення
public function label(): string
{
return match($this) {
self::DRAFT => 'Чернетка',
self::ACTIVE => 'Активна',
self::ARCHIVED => 'Архівована',
};
}
// 🔹 Статичний метод — спільний для всіх
public static function visible(): array
{
return [self::DRAFT, self::ACTIVE];
}
}
echo Status::ACTIVE->label(); // Активна
print_r(Status::visible()); // [Status::DRAFT, Status::ACTIVE]
🧱 Інший приклад
Статуси документів, каналів, ролей
enum Channel: string
{
case EMAIL = 'email';
case SMS = 'sms';
case TELEGRAM = 'telegram';
public function icon(): string
{
return match($this) {
self::EMAIL => '✉️',
self::SMS => '📱',
self::TELEGRAM => '💬',
};
}
public function getSenderFQCN(): string
{
return match($this) {
self::EMAIL => EmailSender::class,
self::SMS => SMSSender::class,
self::TELEGRAM => TelegramSender::class,
};
}
public static function fromString(string $value): ?self
{
return self::tryFrom($value);
}
}
🧭 Висновок
Enum’и — це одне із найвдаліших оновлень в PHP за останні роки.
Вони дисциплінують код, роблять модель даних передбачуваною й забезпечують реальну типобезпеку.
❤️ Я вже не уявляю розробки без enum’ів.
І якщо ти досі не використовуєш їх у своїх проєктах — просто спробуй, через тиждень без них ти вже не зможеш писати старим способом.
———
⬅️ Іменовані аргументи | readonly + accessors ➡️
❤2👍1
#️⃣ #php #doctrine #enum #4students #tips #tools
🧩 Doctrine + Enum
Я так люблю enum’и, що зробив навіть власний пакет — ufo-tech/doctrine-helper, який навчає
1️⃣ Створи свій PHP Enum для поля сутності
2️⃣ Створи власний DBAL-тип і наслідуй Ufo\DoctrineHelper\DBAL\AbstractEnumType
3️⃣ Зареєструй новий тип у Doctrine
4️⃣ Використовуй PHP Enum для зберігання й зміни значення
💡 Таким чином MySQL ENUM поводиться як повноцінний PHP Enum — із типобезпекою, автопідказками IDE та без ручного кастингу.
🧩 Doctrine + Enum
Я так люблю enum’и, що зробив навіть власний пакет — ufo-tech/doctrine-helper, який навчає
Doctrine розуміти enum у типізованих полях сутності і створювати під них ENUM() тип поля в MySQL.1️⃣ Створи свій PHP Enum для поля сутності
<?php
namespace App;
enum MyEnum: string
{
case CASE_1 = 'Мій варіант 1';
case CASE_2 = 'Мій варіант 2';
}
2️⃣ Створи власний DBAL-тип і наслідуй Ufo\DoctrineHelper\DBAL\AbstractEnumType
<?php
namespace App\DBAL;
use BackedEnum;
use App\MyEnum;
class MyEnumType extends AbstractEnumType
{
protected string|BackedEnum $enum = MyEnum::class;
}
3️⃣ Зареєструй новий тип у Doctrine
doctrine:
dbal:
types:
App\MyEnum: 'App\DBAL\MyEnumType'
mapping_types:
enum: string
4️⃣ Використовуй PHP Enum для зберігання й зміни значення
<?php
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
use App\MyEnum;
#[ORM\Entity]
#[ORM\Table(name: 'demo')]
class Demo
{
#[ORM\Column(type: MyEnum::class, nullable: false)]
protected string $case;
public function __construct(MyEnum $case)
{
$this->case = $case->value;
}
public function changeCase(MyEnum $case): void
{
$this->case = $case->value;
}
public function getCase(): string
{
return $this->case;
}
}
💡 Таким чином MySQL ENUM поводиться як повноцінний PHP Enum — із типобезпекою, автопідказками IDE та без ручного кастингу.
👍3❤1
#holywar #4students #architecture #php
📤 Відповідаю на питання
1. Чи можна використовувати try/catch для управління логікою?
Так, можна, і це цілком робочий підхід. Питання тут не в "правильно/неправильно", а в тому, яка філософія тобі ближча і що підходить під конкретну архітектуру.
Насправді, це дуже холіварна тема.
Є табір, який каже "винятки тільки для виняткових ситуацій", а є табір, який спокійно використовує їх як механізм flow control. І обидва підходи живуть собі нормально.
Я особисто вважаю, що це питання зручності, а не абсолютна істина, мені зручніше обʼєктно-орієнтований підхід, ІМХО якщо код читається краще — значить підхід має право на життя.
Приклад:
У такій ситуації це працює природно і зрозуміло: "немає? створи". Немає нічого поганого в тому, щоб ловити конкретний виняток і робити fallback-логіку.
Проблеми починаються тільки тоді, коли exception використовується замість звичайного if у найпростіших місцях, або коли репозиторій починає кидати винятки там, де очікувано повертати null. Але то вже питання дизайну коду.
2. Чи дійсно throw дорогий?
Так, це правда.
try/catch сам по собі майже нічого не коштує. Їх можна хоч вкладати — накладні витрати мізерні, але throw — дорогий, бо PHP генерує backtrace і створює повноцінний Exception-об’єкт, що виїдає процесор.
Тому:
— Якщо
— Якщо "not found" стає нормальним шляхом виконання (часто), тоді варто задуматись, чи не простіше повертати null або Result-об’єкт — чисто з точки зору продуктивності.
Але й тут все залежить від контексту. Якщо загрузка невелика — різниця взагалі не має сенсу.
Підсумую мою позицію
— Використовувати try/catch для логіки можна. Це не є поганою практикою само по собі, це питання смаку, стилю і команди.
— Якщо код читається краще — я завжди за.
— try/catch дешевий, throw дорожчий, але в реальних проєктах це рідко стає bottleneck’ом.
Якщо тобі це зручно і воно вписується в архітектуру — продовжуй використовувати.
———
Чекаю холіварників у коментах
📤 Відповідаю на питання
Саша привіт! Потрібна твоя консультація. Скажи, будь ласка:
1. чи можна використовувати try catch для управління логікою? Я досі використовував, але сьогодні натрапив на твердження, що це не є хороша практика.
2. Наскільки ресурсозатратне використання вкладених try catch? Прочитав, що сам try catch сам по собі "дешевий", а от throw вимагає багато ресурсів. Це так?
Наперед дякую
1. Чи можна використовувати try/catch для управління логікою?
Так, можна, і це цілком робочий підхід. Питання тут не в "правильно/неправильно", а в тому, яка філософія тобі ближча і що підходить під конкретну архітектуру.
Насправді, це дуже холіварна тема.
Є табір, який каже "винятки тільки для виняткових ситуацій", а є табір, який спокійно використовує їх як механізм flow control. І обидва підходи живуть собі нормально.
Я особисто вважаю, що це питання зручності, а не абсолютна істина, мені зручніше обʼєктно-орієнтований підхід, ІМХО якщо код читається краще — значить підхід має право на життя.
Приклад:
try {
$code = $repo->getByUrl($url);
} catch (NotFoundException) {
$code = $this->generateAndSave($url);
}У такій ситуації це працює природно і зрозуміло: "немає? створи". Немає нічого поганого в тому, щоб ловити конкретний виняток і робити fallback-логіку.
Проблеми починаються тільки тоді, коли exception використовується замість звичайного if у найпростіших місцях, або коли репозиторій починає кидати винятки там, де очікувано повертати null. Але то вже питання дизайну коду.
2. Чи дійсно throw дорогий?
Так, це правда.
try/catch сам по собі майже нічого не коштує. Їх можна хоч вкладати — накладні витрати мізерні, але throw — дорогий, бо PHP генерує backtrace і створює повноцінний Exception-об’єкт, що виїдає процесор.
Тому:
— Якщо
throw трапляється рідко — взагалі не проблема.— Якщо "not found" стає нормальним шляхом виконання (часто), тоді варто задуматись, чи не простіше повертати null або Result-об’єкт — чисто з точки зору продуктивності.
Але й тут все залежить від контексту. Якщо загрузка невелика — різниця взагалі не має сенсу.
Підсумую мою позицію
— Використовувати try/catch для логіки можна. Це не є поганою практикою само по собі, це питання смаку, стилю і команди.
— Якщо код читається краще — я завжди за.
— try/catch дешевий, throw дорожчий, але в реальних проєктах це рідко стає bottleneck’ом.
Якщо тобі це зручно і воно вписується в архітектуру — продовжуй використовувати.
———
Чекаю холіварників у коментах
👍11🔥2👎1
Про продовження циклу "Чи знаєш ти, що PHP так вміє?" не забув, просто наразі не маю часу 😒
👌9❤1
🎉 DOU PHP Meetup — Чорна пʼятниця на DOU
Цього року мене запрошували доповідати на DOU PHP Meetup, але, на жаль, не вийшло поїхати — домовилися перенести мій виступ на наступний рік.
А поки — ловіть знижку, якщо хочете приєднатись цього року.
💥 Акція 1+1: купуєш квиток — другий прилітає на пошту безкоштовно.
🕺 Акція діє з 27.11 до 30.11
🎫 Якщо йдеш сам — тримай -15%:
👉 https://dou.ua/goto/RK7i
Хто піде — напишіть в коментах, цікаво хто там буде ✌️
Цього року мене запрошували доповідати на DOU PHP Meetup, але, на жаль, не вийшло поїхати — домовилися перенести мій виступ на наступний рік.
А поки — ловіть знижку, якщо хочете приєднатись цього року.
💥 Акція 1+1: купуєш квиток — другий прилітає на пошту безкоштовно.
🕺 Акція діє з 27.11 до 30.11
🎫 Якщо йдеш сам — тримай -15%:
FROM_DOCTOR_15 (акції не комбінуються)👉 https://dou.ua/goto/RK7i
Хто піде — напишіть в коментах, цікаво хто там буде ✌️
🔥3
#sql #course #4students
Обіцяю, це останній пост про Чорну пʼятницю 😅
Але гріх не поділитись, якщо вже зробили -50% на мій курс по MySQL для Hillel Max.
Курс короткий, без води, лише практичні речі, які реально потрібні девелоперам.
Чорна пʼятниця — нормальний момент почати те, що відкладали місяцями 😉
А якщо ще вагаєшся, то спробуй безкоштовні пробні заняття:
— на Hillel Max
— на моєму YouTube
Хто проходив — можете відписати, чи було корисно 🖤
Обіцяю, це останній пост про Чорну пʼятницю 😅
Але гріх не поділитись, якщо вже зробили -50% на мій курс по MySQL для Hillel Max.
Курс короткий, без води, лише практичні речі, які реально потрібні девелоперам.
Чорна пʼятниця — нормальний момент почати те, що відкладали місяцями 😉
А якщо ще вагаєшся, то спробуй безкоштовні пробні заняття:
— на Hillel Max
— на моєму YouTube
Хто проходив — можете відписати, чи було корисно 🖤
#️⃣ #php #course #series
🚀 Чи знаєш ти, що PHP так вміє? 8/10
🔒 readonly + accessors
🧱 Стабільні DTO і Value Object без бойлерплейту
📦 Додано у версіях:
readonly — PHP 8.1
accessors — PHP 8.4
💡 Що це дає: можливість створювати об’єкти, дані в яких неможливо змінити випадково,
та новий синтаксис контролю доступу до властивостей через get / set без окремих методів.
🧠 В чому суть:
значення можна встановити лише один раз (зазвичай у конструкторі).
без класичних геттерів і сеттерів — прямо в тілі класу.
Разом вони створюють ідеальну комбінацію для DTO, VO і конфігураційних класів:
дані незмінні, а доступ контрольований.
🧱 Приклад класичного підходу
✅ працює, але більша частина коду тут тільки заради забезпечення базової інкапсуляції.
⚡️ Тепер те саме — сучасно
Ще приклад — Value Object
👌 Ніяких змін після створення, тільки контрольований доступ при читанні.
⚙️ Де це реально корисно
🔹
🔹
🧭 Висновок
🔥 Сьогодні кожен мій DTO — readonly.
———
⬅️ Enums | Атрибути ➡️
🚀 Чи знаєш ти, що PHP так вміє? 8/10
🔒 readonly + accessors
🧱 Стабільні DTO і Value Object без бойлерплейту
📦 Додано у версіях:
readonly — PHP 8.1
accessors — PHP 8.4
💡 Що це дає: можливість створювати об’єкти, дані в яких неможливо змінити випадково,
та новий синтаксис контролю доступу до властивостей через get / set без окремих методів.
🧠 В чому суть:
readonly робить властивість незмінною після ініціалізації —значення можна встановити лише один раз (зазвичай у конструкторі).
accessors дозволяють додати контроль при читанні та записі властивостейбез класичних геттерів і сеттерів — прямо в тілі класу.
Разом вони створюють ідеальну комбінацію для DTO, VO і конфігураційних класів:
дані незмінні, а доступ контрольований.
🧱 Приклад класичного підходу
class Product {
private string $name;
private float $price;
public function __construct(string $name, float $price)
{
$this->name = $name;
$this->price = $price;
}
public function getPrice(): float {
return $this->price;
}
public function setPrice(float $price): void {
if ($price < 0) {
throw new InvalidArgumentException('Price must be positive');
}
$this->price = $price;
}
}✅ працює, але більша частина коду тут тільки заради забезпечення базової інкапсуляції.
⚡️ Тепер те саме — сучасно
class Product {
public readonly string $name;
private float $price {
get => $this->price;
set => $this->price = max(0, $value);
}
public function __construct(string $name, float $price)
{
$this->name = $name;
$this->price = $price;
}
}readonly гарантує незмінність імені,accessors автоматично перевіряють ціну при записі.Ще приклад — Value Object
class Coordinates {
public readonly float $lat {
get => round($this->lat, 6);
}
public readonly float $lng {
get => round($this->lng, 6);
}
public function __construct(float $lat, float $lng)
{
$this->lat = $lat;
$this->lng = $lng;
}
}👌 Ніяких змін після створення, тільки контрольований доступ при читанні.
⚙️ Де це реально корисно
🔹DTO: запити й відповіді в API;🔹
Value Object: Money, Price, GeoPoint, Range;🔹
Immutable конфігурації: параметри сервісів, константні стани.🧭 Висновок
readonly і accessors — це крок до справжніх record-класів у PHP.
Вони дозволяють писати чисті, передбачувані структури без тонни бойлерплейту.
🔥 Сьогодні кожен мій DTO — readonly.
———
⬅️ Enums | Атрибути ➡️
👍1
#️⃣ #php #course #series
🚀 Чи знаєш ти, що PHP так вміє? 9/10
🏷 Атрибути
✨ Метапрограмування без DocBlock-хаків
📦 Додано у версії: PHP 8.0
💡 Що дає: нативний, типобезпечний механізм додавання метаданих до класів, методів, властивостей та параметрів — без необхідності при їх читанні парсити DocBlock-и та встановлювати сторонні бібліотеки.
❤️ Трохи особистого
До PHP 8.0 в мене був один технічний “біль”, про який знають тільки ті, хто коли-небудь пробував будувати API-документацію чи SDK на основі читання коду.
Скажу лише одне: парсинг DocBlock-ів — це дуже невдячна робота.
Атрибути стали тією фічею, після якої мої бібліотеки буквально отримали "вдих свіжого повітря".
Код став чистішим, простішим, а метадані — нарешті передбачуваними.
🧩 Навіщо вони взагалі потрібні?
До PHP 8 метадані доводилося писати так:
Це був просто коментар, який не розбирається стандартними засобами PHP такими як рефлексія. Для аналізу потрібна ще одна бібліотека-парсер, яка мала вгадати, що розробник мав на увазі.
Атрибути роблять метакоментарі типізованими, тепер вони обʼєктні:
Це буквально декларація єкземпляру класів Route та SomeFlag і IDE точно знає, що всередині. Це дає:
— нативне використання
— розуміння які параметри треба передати
— легке читання коду
— легке використання цих даних
🧱 Приклади застосування
1️⃣ Доктрина
2️⃣ Symfony Routing
3️⃣ Валідація
4️⃣ Кастомні аттрибути
🧠 А що можна робити з атрибутами?
Майже все, що роблять Java/Spring- або C#-атрибути:
🔹позначати класи й методи
🔹додавати метадані
🔹створювати власні декларативні правила
🔹будувати роутинг
🔹маркувати серіалізацію/десеріалізацію
🔹автоматизувати DI/автовіринг
🔹вказувати, як працює кешування чи логування
🔹створювати декларативні контракти для DTO
Фактично — інструмент, щоб писати менше імперативного коду та більше декларативного.
✨ Як створити власний атрибут
Використання:
🔍 Як прочитати атрибут через Reflection
📌 Особливо важливо
🔹атрибути це повноцінний об’єкт, а не просто рядок в коментарі
🔹вони мають простір імен
🔹можна типізувати параметри
🔹можна використовувати передові конструкції (enum, readonly, VO)
🔹ідеально комбінуються з DI-контейнерами
🧭 Висновок
———
⬅️ readonly + accessors
🚀 Чи знаєш ти, що PHP так вміє? 9/10
🏷 Атрибути
✨ Метапрограмування без DocBlock-хаків
📦 Додано у версії: PHP 8.0
💡 Що дає: нативний, типобезпечний механізм додавання метаданих до класів, методів, властивостей та параметрів — без необхідності при їх читанні парсити DocBlock-и та встановлювати сторонні бібліотеки.
❤️ Трохи особистого
До PHP 8.0 в мене був один технічний “біль”, про який знають тільки ті, хто коли-небудь пробував будувати API-документацію чи SDK на основі читання коду.
Скажу лише одне: парсинг DocBlock-ів — це дуже невдячна робота.
Атрибути стали тією фічею, після якої мої бібліотеки буквально отримали "вдих свіжого повітря".
Код став чистішим, простішим, а метадані — нарешті передбачуваними.
🧩 Навіщо вони взагалі потрібні?
До PHP 8 метадані доводилося писати так:
/**
* @Route("/users")
* @SomeFlag(true)
*/
class UserController {}
Це був просто коментар, який не розбирається стандартними засобами PHP такими як рефлексія. Для аналізу потрібна ще одна бібліотека-парсер, яка мала вгадати, що розробник мав на увазі.
Атрибути роблять метакоментарі типізованими, тепер вони обʼєктні:
#[Route('/users')]
#[SomeFlag(true)]
class UserController {}Це буквально декларація єкземпляру класів Route та SomeFlag і IDE точно знає, що всередині. Це дає:
— нативне використання
— розуміння які параметри треба передати
— легке читання коду
— легке використання цих даних
🧱 Приклади застосування
1️⃣ Доктрина
#[ORM\Entity]
class Product
{
#[ORM\Id]
#[ORM\GeneratedValue]
#[ORM\Column]
public int $id;
#[ORM\Column(length: 255)]
public string $name;
}
2️⃣ Symfony Routing
#[Route('/orders/{id}', methods: ['GET'])]
public function show(int $id) { ... }3️⃣ Валідація
class RegistrationDTO
{
#[Assert\Email]
#[Assert\NotBlank]
public string $email;
#[Assert\Length(min: 8)]
public string $password;
}
4️⃣ Кастомні аттрибути
#[API\Method('user.create')]
class CreateUserRequest
{
#[API\Param]
public string $email;
#[API\Param]
public string $password;
}🧠 А що можна робити з атрибутами?
Майже все, що роблять Java/Spring- або C#-атрибути:
🔹позначати класи й методи
🔹додавати метадані
🔹створювати власні декларативні правила
🔹будувати роутинг
🔹маркувати серіалізацію/десеріалізацію
🔹автоматизувати DI/автовіринг
🔹вказувати, як працює кешування чи логування
🔹створювати декларативні контракти для DTO
Фактично — інструмент, щоб писати менше імперативного коду та більше декларативного.
✨ Як створити власний атрибут
#[Attribute(Attribute::TARGET_CLASS | Attribute::TARGET_METHOD)]
class Loggable
{
public function __construct(
public string $message = 'default',
public bool $enabled = true,
) {}
}
Використання:
#[Loggable(message: 'Auth attempt')]
class AuthService {}
🔍 Як прочитати атрибут через Reflection
$ref = new ReflectionClass(AuthService::class);
$attrs = $ref->getAttributes(Loggable::class);
$instance = $attrs[0]->newInstance();
echo $instance->message;
📌 Особливо важливо
🔹атрибути це повноцінний об’єкт, а не просто рядок в коментарі
🔹вони мають простір імен
🔹можна типізувати параметри
🔹можна використовувати передові конструкції (enum, readonly, VO)
🔹ідеально комбінуються з DI-контейнерами
🧭 Висновок
Атрибути — це одна з тих фіч, після яких старий PHP здається архаїчним.
Типобезпека, декларативність, прозора робота через Reflection, відсутність DocBlock-магії — це все робить їх інструментом, який я обожнюю використовувати у власних бібліотеках.
Це настільки природно, що важко повірити, що колись ми писали метадані в коментарях.
———
⬅️ readonly + accessors
👍14
Друзі, з Новим роком 🎄
Нехай цей рік принесе спокій, ясність у голові та відчуття, що ти робиш правильні речі в правильному місці.
Бажаю сил доводити справи до кінця, часу на себе і близьких, і щоб робота не виїдала мозок, а давала результат і задоволення. Без метушні, зайвого шуму і постійного «треба ще вчора»
Дякую, що ви читаєте цей канал. Ціную кожного, хто залишається поруч 🥂
Окрема, глибока і безмежна подяка Збройним Силам України. Саме завдяки вам ми маємо змогу жити, працювати, планувати і зустрічати Новий рік. Низький уклін і шана 🇺🇦🫡
Нехай цей рік принесе спокій, ясність у голові та відчуття, що ти робиш правильні речі в правильному місці.
Бажаю сил доводити справи до кінця, часу на себе і близьких, і щоб робота не виїдала мозок, а давала результат і задоволення. Без метушні, зайвого шуму і постійного «треба ще вчора»
Дякую, що ви читаєте цей канал. Ціную кожного, хто залишається поруч 🥂
Окрема, глибока і безмежна подяка Збройним Силам України. Саме завдяки вам ми маємо змогу жити, працювати, планувати і зустрічати Новий рік. Низький уклін і шана 🇺🇦🫡
🎄13🤝9❤7
This media is not supported in your browser
VIEW IN TELEGRAM
#humor
Поділюся гарним настроєм
Я кожен день перед переглядом чату підтримки переглядаю це відео, щоб підняти собі настрій і згадати хто наші клієнти )))
Це відеозапис при зверненні в сапорт зі скаргою, що додаток не дає доступу до камери
Поділюся гарним настроєм
Я кожен день перед переглядом чату підтримки переглядаю це відео, щоб підняти собі настрій і згадати хто наші клієнти )))
Це відеозапис при зверненні в сапорт зі скаргою, що додаток не дає доступу до камери
🤣13😭1
#humor
В ІТ забагато англіцизмів, в яких недосвідчена людина може легко заплутатися, пропоную навести порядок і чіткі німецькі назви.
Тепер одразу ясно, хто відповідальний 😈
Standup завтра о 11:00, точніше Stehbesprechung → Штейбешпрехунґ
В ІТ забагато англіцизмів, в яких недосвідчена людина може легко заплутатися, пропоную навести порядок і чіткі німецькі назви.
— Team Lead → Gruppenführer → Групенфюрер
— Tech Lead → Technikführer → Технікфюрер
— CEO → Geschäftsführer → Ґешефтсфюрер
— CTO → Obertechnikdirektor → Обер-технік-директор
— Project Manager → Projektleiter → Проєктляйтер
— Scrum Master → Zeremonienleiter → Церемонієнляйтер
— Backend Developer → Anwendungsentwickler → Анвендунґс-ентвіклер
— Frontend Developer → Oberflächen-Entwickler → Оберфлехен-ентвіклер
— Fullstack Developer → Universal-Entwickler → Універсаль-ентвіклер
— DevOps Engineer → Betriebsingenieur → Бетрібс-інженер
— Manual QA → Prüfer → Прюфер
— BI Analyst → Berichtsanalytiker → Беріхтс-аналітікер
— UX/UI Designer → Benutzeroberflächen-Gestalter → Бенуцероберфлехен-ґештальтер
Тепер одразу ясно, хто відповідальний 😈
Standup завтра о 11:00, точніше Stehbesprechung → Штейбешпрехунґ
😁10🫡3🔥2
#course #4students
Ще перед Новим роком я завершив розробку відеокурсу по MongoDB, і тепер він повністю готовий 🎬
Колись казали, що найкращий подарунок — це книга. Я ж переконаний, що найкращий подарунок — це знання.
Зараз на платформі вже діє –25% на всі курси, але напередодні Дня святого Валентина я домовився про додаткову персональну знижку для вас: на мої курси зробили промокод, який дає ще –25% додатково, тобто з ним ви можете придбати один з моїх курсів зі знижкою 50%.
Мої курси:
• Бази даних: SQL (6 годин відео, 24 заняття, 24 тести, 3 практичні завдання)
• MongoDB: Глибинне занурення в управління нереляційною базою даних (3 години відео, 19 занять, 19 тестів, 18 практичних завдань)
Промокод:
Зробіть подарунок своїй половинці! Або собі 😉
Ще перед Новим роком я завершив розробку відеокурсу по MongoDB, і тепер він повністю готовий 🎬
Колись казали, що найкращий подарунок — це книга. Я ж переконаний, що найкращий подарунок — це знання.
Зараз на платформі вже діє –25% на всі курси, але напередодні Дня святого Валентина я домовився про додаткову персональну знижку для вас: на мої курси зробили промокод, який дає ще –25% додатково, тобто з ним ви можете придбати один з моїх курсів зі знижкою 50%.
Мої курси:
• Бази даних: SQL (6 годин відео, 24 заняття, 24 тести, 3 практичні завдання)
• MongoDB: Глибинне занурення в управління нереляційною базою даних (3 години відео, 19 занять, 19 тестів, 18 практичних завдань)
Промокод:
DOCTOR_LOVEЗробіть подарунок своїй половинці! Або собі 😉
❤4🔥3