3 речі, які роблять програміста кращим

Які 3 речі дозволять стати тобі кращим програмістом? Спробуємо не говорити штуки типу софт-скіллз, а про щось більше конкретне.
Книги про DDD, які згадував у відео :
1. "Domain-Driven Design: Tackling Complexity in the Heart of Software", Eric Evans
2. "Implementing Domain-Driven Design", Vaughn Vernon
3. "Domain-Driven Design Distilled", Vaughn Vernon (як попередня, тільки коротко для рев'ю)
4. "Domain Driven Design Quickly", Abel Avram. 100 сторінок, є онлайн PDF безкоштовно, рекомендую!
Станьте спонсором цього каналу: / @aboutprogramming
Допоможіть каналу розвиватися й отримуйте доступ до ексклюзивного контенту.
Зміст відео:
0:00 - Вступ
1:08 - Перше
7:25 - Друге
17:24 - Третє
🏠 Мої соцмережі:
Жабаскрипт в телеграмі - t.me/jabascript
Я в Твітер - / viktorturskyi
#programming #javascript #програмування #українською

[@JavaScriptNinja]

Велкам ту юкрейніан ютуб! Глорі ту контент :)

[@AboutProgramming]

Дякую! :)

[@Epic0n]

Так звістно потрібно копати, але можу сказати з власного досвіду що знання які не використовуються дуже швидко забуваються на жаль, а якщо до цого додати правило Паретто то виходить копання в глубину після якоїсь межі дуже дороге в плані часу, і якщо ти розуміеш що тобі це потрібно щоб вирішити проблему одноразово то дуже не хоченьться цього роботи. Наприклад банально регулярки, мені щось таке спеціфічне потрібно раз в 2 роки, і кожен раз як перший раз. Так легше повторяти чим вчити але з ходу не виходить вирішувати задачу. Тому хотілося б почути вашу думку як не тільки набути нові знання, а і критерії вибору, а також як їх не впратити в подальшому.

[@AboutProgramming]

З одного боку є такий момент й потрібне повторення. З другого боку, тут головне зрозуміти, як воно влаштувано всередені, а не знати на пам'ять публічний API (хоча часом й це корисно). Наприклад, я постійно підглядаю в інтернеті синтаксис SQL, команди Git й вивчити все на пам'ять особливо користі не дасть, якщо я це рідко використовую. А от розуміти принципи, й як воно відпрацює всередені, вже дає більше користі (але теж не завжди). Й з часом одні знання чипляються за інші. Наприклад, взяти той самий SQL: 1. SELECT * FROM users WHERE email like '%john' - звичайний індекс може спрацювати 2. SELECT * FROM users WHERE email like '%john%' - звичайний індекс не буде працювати Також колись в Linux в ext2 була проблема с перформансом, коли в одній папці забагато файлів - наприклад, сессії користувача. Й ніби зовсім різні проблеми, але все зводиться до базових структур даних й алгоритмів. Й одні знання підтримують інші. Але звісно, що будуть якісь штуки (навіть супер корисні), які будуть забуватися в будь-якому випадку. Про критерії відбору, дуже гарне запитання. Зроблю відео, як я підхожу до цього, але тут у кожного може бути свій підхід

[@olegnovitskiy1098]

Віктор, вітаю з першим цікавим та корисним відео на цьому каналі! Дуже класно, що поступово потужні експерти з Software Development підключаються до розвитку україномовного KZbin, наповнюючи його дуже гідним контентом. Бажаю успіхів у розвитку каналу, ділитись драйвом та натхненням із комьюніті!

[@AboutProgramming]

Дякую! 🙂

[@borozenniy4561]

Випадково потратив на ваше інтервью на ДОУ, був дуже приємно вражений вами. Сидів в парку до самої ночі і слухав, звісно потім, потратив до вас на канал. Так, думка: .) Систематизована та послідовна погляд на загально важливі речі в становленні тебе як майбутнього інженера. .) Важливість розуміння 'підкапотних' справ для початку на базомову рівні, які допоможуть тобі бути гарним спеціалістом. .) Чудово допомогає краще систематизувати 'кашу' в голові та зрозуміти приблизну послідовність в процесі розвитку. Дякую за контент, та й ще українською.

[@AboutProgramming]

Дякую за такий структурований відгук 🙂

[@dmytrokucheriavyi605]

Дякую! Подарунок на Різдво!

[@Olexandr_Yatsykovych]

Дякую, за такий крутий шейринг🔥 Як на мене дуже доступно і валідно пояснив ці 3 моменти 👍 Успіхів в подальшому, буду чекати більше таких відео🙂

[@atsybulsky]

Дуже суттєво ! 👍 Повністю погоджуюсь, що саме мислення над питаннями "чому" призводять до кращої якості (а всі 3 питання озвучені Віктором по суті саме про "чому")

[@diegoavenger7702]

Класний і структурований контент, дякую 👍

[@rickbacker1]

Дякую за відео! У Вас гарно виходить і Вас цікаво слухати 👍

[@alexanonymous5823]

дуже дуже дякую! круто і дуже інформативно!!! супер

[@svitoch_blockchain]

Дуже якісний контент, дякую!

[@andrewsquest628]

дякую, дуже пізнавально!

[@detroit7213]

Контент просто ТОП! Дякую за відео!

[@SKiPER210397]

Дуже цікаво, дякую. Навчаюсь на фронта десь біля півтора року, дописую проект(правда там фул стак...) і шукатиму роботу. Такі відео як це допомагають зрозуміти "що робити далі", особисто мені.

[@orestborovets2140]

Контент бомба, дуже дякую, було б цікаво почути про фундаментальні знання в фронтенді , що дійсно важливо знати для фронтендера і чи потрібно вчити різні фреймворки чи достатньо одного, дякую )

[@limbocats9130]

доволі універсальні поради як на мене) дякую за відео

[@Victoria_Sk]

Мені чомусь здається що челенджі то для юних техніків 😅 а дорослі люди обирають второвані шляхи котрі закінчуються хлібом на столі і чимось смачненьким на хліб 😊 Дякую за відео 👍

[@VolodymyrStishkovskyi]

Ви дуже крутий, дякую вам! Чекаю більше відео по юсфул книжкам!!!

[@AboutProgramming]

Дякую за відгук) Давно про книжки не розповідав. Можливо треба робити окремий огляд під кожну книгу

[@dariahromyk4004]

Класну тему обрав для першого випуску)) Вже хочеться подивитись нові

[@AboutProgramming]

Дякую! Стільки коментарів, що дуже мотивує робити нові відео! )

[@Jen13022]

дуже хотів би побільше відео про базові якісь речі по темі computer science

[@niklu4038]

дякую за відео!

[@slavabilaz]

Дякую за круте відео!

[@Roman-oi9el]

Дуже цікаво

[@Natalicha1234]

Дуже корисні поради! Взагалі мега крутий канал, дивлюсь відео за відео!

[@McKleeM]

Вітаю з першим відео та дякую за україномовний контент 🎉 Цікава для мене тема: покращення якості код-рев‘ю у команді

[@AboutProgramming]

Дякую! Відносно code review, то цікавий процес в Google - розповім в окремому відео

[@romkalily]

Топ відос! Де взяти цих 13 тем?)) Крута ідея для відео, круто було б і далі чути як може покращити свій лвл))

[@ASDjonok]

Дякую

[@taraslife3028]

дякую за відео, надихає читати більше книжок :)

[@4opper1]

Відос супер, дякую. Було б цікаво побачити ці 13+ тем, матеріали і задачі до них

[@AboutProgramming]

t.me/jabascript/125

[@pytniktov]

Дякую. Контент - топ. Дуже корисна порада при проєктуванні модуля починати з того як його використовувати. Якщо є можливість, хотілось би почути якісь поради(та що почитати по темі) по А/Б тестуванню. Працюю в продукті, часто маркетинг приходить з ідеями різних банерів чи попапів, деякі з них показують + в конверсії, та лишаються висіти на сайті. З часом сайт стає схожим на жахіття) Дуже болить за користувачів)) Можливо, є якісь поради як правильно вимірювати довгостроковий ефект від фіч etc. Про подачу інформації - все ж краще записати відео одним дублем та випустити його, ніж витрачати час на монтаж та переписування. Суть важливіша за форму. Хоча і з формою тут все гуд. Імхо.

[@ihorbond6019]

Випадково натрапив на відео. Чудова робота! Вподобайка та підписка від мене!💪

[@user-ke2on2ju8m]

ну топчик, реально на рідінй мові не вистачає такого контенту, тому дякую і буду ставати краще завдяки вашим порадам!

[@artemtrush]

Вогонь 🔥 Теми: - Читабельність коду - Процес code review - Робота хмарних сервісів (GCP під капотом 👀) - Досвід з open-source

[@AboutProgramming]

О, дякую за теми!

[@alexandr0id]

Сумбурне відео, але тема важлива. Я погоджуюся що треба вміти "розбиратися вглиб", але важко це радити початківцям - все наперед не вивчиш, ці знання краще за все здобуваються за потребою. Зламав щось - розібрався і вивчив. Головне не боятися "зазирнути під капот", у код бібліотеки, фреймворка, і т.д. Звісно в ідеалі краще пірнати під час розробки, до того як щось зламав, але тут теж є баланс - час у всіх обмежений. Особисто для мене великим уроком було розуміння того, про що ви говорили на початку - немає "гарного дизайну", "гарної архітектури системи" у вакуумі. Це ілюзія, що деякі дизайни нам здаються кращими самі по собі. Все має йти від вимог бізнесу і технічних обмежень. Що оптимізуємо. Коли хтось каже, що якийсь дизайн "кращий" вони просто мають якісь критерії оптимізації у голові, які їм подобаються. Важливо це явно визначити і узгодити на папері із усіма, щоб не розводити "дизайн" на пустому місці.

[@alexandr0id]

І про доменні область правильно наголосили. Не можливо бути програмістом без прикладної спеціалізації (ФІОТ?). Пишете софт для бухгалтерії - маєте розбиратися у бухгалтерії. Те саме із фінансовими транзакціями, безпекою, торгівлею. Тому варто не цуратися і вивчати бізнес деталі того, що ви пишете. Якщо не подобається предметна область - міняйте роботу, бо на самому "АйТі" ви далеко не виростите. І ще момент - багато знань про архітектуру і системний дизайн здобуваються лише тоді, коли програміст працює над своєю системою довго, підтримує її і бачить наслідки минулих рішень. Тому знову ці знання стають прямо пропорційними досвіду, але за умови що людина не міняє роботу кожні два роки.

[@AboutProgramming]

Тут й немає задачі все вивчити наперед, а скоріше розуміти ті речі з якими доводиться працювати. Практично будь-який бекендер починає відразу працювати з базою, навіть новачок. Й тут вже бажано знати про індекси й їх властивості та вплив на систему. Ну й обсяг всього досить великий, тому можна почати будучі початківцем, а не закінчити й через 10 років) але бути через 10 років значно потужнішим інженером, ніж більшість тих, хто не задає собі питання як й чому щось працює певним чином

[@stabben]

дивлюсь, і впізнаю себе - також, коли щось пояснюю, постійно збиваюсь, перескаую з теми на тему, думка летить далеко по переду того, що зараз кажу...) також програмую біля 20 років, але працюю далеко не в гуглі) дякую за відео!

[@AboutProgramming]

Це коли багато досвіду накопичується, то хочеться про все розповісти відразу 🙈😀

[@dmytro-busyhin]

Дякую за відео, дізнався про канал з інтервʼю на DOU, впевнений що буду переглядати всі відео не одноразово

[@dmytriibasov2425]

Дякую за чудовий контент! Прохання, чи можеш описати якийсь практичний роудмап (задачок, як з JWT парсером) який на твою думку є базовим?

[@AboutProgramming]

Ось був колись пост про бейзлайн в каналі - t.me/jabascript/125

[@avazart614]

Комент для просування.

[@anndroidek]

Дякую за відео, чудовий початок! ❤ Момент з TDD: здається, якоїсь великої різниці між тим, щоб написати інтерфейс і приклад використання і тим, щоб зробити те ж саме і зафейлити тест (ред грін цикл), немає. Просто на початковому етапі ще додається крок з назвою тесту, який має відображати бізнес вимогу, що також не є зайвим зафіксувати перед початком розробки реалізації. Чи я щось не до кінця зрозумів?

[@AboutProgramming]

В цілому так. Просто часто в TDD роблять акцент, що спочатку має бути тест, який падає, а потім код. Для мене важливо просто, що й тести й код в одному пул реквесті, а в якому порядку додавався тест, то вже вторинне

[@anndroidek]

@@AboutProgramming ага. З моєї практики якщо цікаво: ми у себе використовуємо скафолдинг, і при створенні нового компоненту (частіше за все реалізація ендпойнту), автогенерується відразу тест з викликом цього компоненту (SUT), який і буде зазвичай червоним) Таким чином і розробнику швидше тест написати, і грубо кажучи ред грін цикл закривається. Ну і ментально видаляти файл з тестом у девів менше бажання через карму, тому кавередж тримається)

[@IhorKazmin]

Дякую за відео. Таке питання - як обирати глибину, на яку вивчату ту чи іншу технологію та як розуміти достатній рівень глубини. Приклад nodejs, вивчили базис (тут просто можна навічно як по меня заритися, якщо вивчити спочатку роботу з файловою системою - потім окремо поглибити знання роботи з самою файловою системою без ноди і так по кожному напрямку: як працює з npm, crypto, buffer etc), стежимо за оновленнями, оновлення відносно часто і для того щоб розібратися що змінилося - треба, як на мій погляд, досить не мало часу. А це тільки одна з технологій у стеку який використовується.

[@AboutProgramming]

Так, все це вимагає роки або десятиріччя. Тому ключова ідея - накопичувати фундаментальні знання, які не втрачають актуальності й спільні для багатьох технологій

[@kondolovskiy]

Дякую за цікавий контент. Хотілося б більше прикладів практичного використання глибини знань. Наприклад тих самих мережевих протоколів - як то може допомогти в розробці. Бо зі свого досвіду можу сказати, що як почув про них багато років тому в університеті, так і жодного разу ті знання і не пригодилися. Також з майбутніх тем було б цікаво почути вашу думку на наступну тему: що краще взяти неоптимальну, але знайому технологію чи краще працюати з підходящими інстуреметами, але перед тим потративши час на їх вивчення або пошук відповідних спеців на ринку.

[@AboutProgramming]

Дякую! Є що розповісти з обох питань. Додам в план

[@ivansepp7928]

Де ти був раніше? чому аж у кінці 2022 року почав. Молодець.!

[@AboutProgramming]

Дякую! Вже цілий рік планував й зрозумів, що треба запускатися хоч у простому форматі, а не чекати кінця 2023 :)

[@oksanakhortytsia]

Все по суті)

[@Myjlan1]

Дякую за відею, вийшло цікаво! Щодо ідей або думки про відео, то мені було б цікаво почути про свписок літератури, яку б Ви рекомендували. Ви декілька разів озвучували авторів та назви книжок, але хотілося б побачити конкретний список Ваших улюблюлених авторів аба книжок! Якщо це не актуальна для вас тема для відео, то напишіть , будь ласка, у відповіді до мого коментаря. Дякую!

[@AboutProgramming]

Дякую! Обов'язково зроблю відео про книги! 🙂

[@romeo4022]

Знаючи Віктора особисто можу з впевненістю сказати, що попереду буде багато цікавого і корисного. Щодо теми відео - підписуюсь під всім сказаним. Особливо під першими двома. Зі своєї практики знаю, що глибоке розуміння домену і всяких "підкапотних" нюансів робить вас крутим і цінним програмістом. Писати код можуть всі, а от розуміти що там коїться - це вже інша справа. Успіхів у розвитку каналу!

[@AboutProgramming]

Рома, дякую за відгук й підписку! 🙂

[@v.ilchenko]

Дякую, це дуже корисний контент. Успіхів в розвитку каналу 🎉 +1 до знань доменної області. Задача програміста - вирішити проблему, а не просто писати код. Це викривається і при взаємодії з тими ж дизайнерами (можна пояснити, чому це рішення краще, ніж інше), і при створенні фічі можна додавати «плюшки», які роблять життя юзерів краще Про глибину знань. Імхо, корисно занурюватись, коли вже є знання «в ширину». Тяжко буде зрозуміти, що робити з jwt токеном чи базою даних, коли ти джунік і вмієш малювати кнопочки і рендерити масив айтемів. Далі важливо заглиблюватись, але спочатку потрібно зрозуміти як воно працює на хайлевелі. ps але ми почали питати на співбесіді різницю між кодуванням шифруванням і хешуванням навіть початківців 😂

[@AboutProgramming]

Дякую за відгук! Відносно "в ширину", то так й є - треба й в "ширину" й в "глибину". Але зазвичай воно чередується й чипляє один одного. Та й часто спроба розібратися "в глибину" потягне за собою необхідність двитися в ширину. Як той самий JWT потягне за собою base64. Далі варто подумати для чого існує base64, то вже можна згадати, що я картинки для веб можуть кодуватися в base64. А потім виявиться, що base64 в http basic auth це практично плейн текст. Мені нещодавно треба було кидати в логі бінарні дані, то base64 підійшов ідеально :). Якщо далі копати з JWT, то виявиться, що там можна вказати алгоритм підпису й тут вже дійшли до асиметричної криптографії й так далі :) >почали питати на співбесіді різницю між кодуванням шифруванням і хешуванням навіть початківців ніби й прості концепції, а якщо людина плутає, то можна таких проблем з сек'юріті отримати :) Та навіть, якщо не знає, то після співбесіди розбереться, що вже корисно для всіх

[@BelladonGameDeverUA]

Третій пункт найбільше сподобався

[@jf7sm53]

стосовно «як це працює»: можна піти ще далі, і розібратись нащо хтось те зробив і чого він захотів зробити те саме так, а не якось по-іншому. таким чином ви занурюєтесь у майндсет, і користуєтесь інструментом на повну. і розумієте розвиток проекту, які фічі чекати в наступному оновленні і тд. про тдд хочу додати що інколи самі тести стають спрощеним середовищем виконання. наприклад при розробці смарт контрактів для evm з hardhat. перевірка функціоналу вручну займає більше часу, ніж написання тестів

[@AboutProgramming]

Звісно автоматизовані тести дуже допомагають. Я більше про те, що я зазвичай пишу код й тести й не слідую постійно Red Green Loop. TDD рекомендує ж спочатку написати тест, який падає (бо ще немає робочого коду), а потім вже писати код. Я такий підхід використовую, коли фікшу баги, тоді легчше спочатку додати тест для репродюсу. А якщо нова фіча, то майже завжди код, а потім тест

[@AboutProgramming]

Цікавий момент про зануритися в майндсет й про розуміння розвитку проекту. Це не завжди можливо в контексті стороніх бібліотек чи фреймворків, але на проекті на якому працює безпеосередньо сам інженер це актуально. Бо, коли приходять нові люди на проект, то часто хочуть переписати все, а потім виявляється, що їх ідея це те, що було напочатку й від чого вже відмовилися :)

[@jf7sm53]

@@AboutProgramming я зараз більше і більше дивлюсь на використання сторонніх фреймворків і інструментів як на cross-team collaboration, наче це все відбувається в одній компанії. на щастя сучасна опен-сорс культура це дозволяє

[@AdminAdmin-sl2qf]

❤❤❤❤❤❤❤❤❤❤

[@caffeinejavacode1475]

18:17 є вже відео з прикладами? :)

[@AboutProgramming]

Є в плані зробити багато відео по проектуванню й там точно будуть приклади🙂

[@donutWiggum]

З побажань на наступні відео, було б цікаво про Докер і контейнери, то що ви частково тут зачепили. Особливо з Віндовс імеджами на Лінуксі

[@AboutProgramming]

Колись робив про докер доповідь kzbin.info/www/bejne/eZjFmp2eeap0ndU (правда доповідь російською), але в планах є детально це розкрити й на цьому каналі. Тому все буде 🙂

[@xandrop]

У симфонії життя ти танцюєш в ритмі своєї мрії, крокуючи все ближче і ближче до бажаної мети, залишаючи за собою слід натхнення. Не знаю чи достатньо тут абстракції. Набиваю руку тільки, вибачте

[@AboutProgramming]

Уявляю замовника, який бачить такі абстракції в коді))

[@aleksandrsavvopulo4510]

по третьем пункту читайте GRASP паттерны. там и будет про cohesion and coupling. .

[@AboutProgramming]

Окрім читати я раджу завжди практикуватись. Нажаль навички проектування це така штука, яка вимагає часу. Мені здається, що всі багато разів чули про coupling й cohesion, але усвідомлення проходить тільки через практику

[@aleksandrsavvopulo4510]

@@AboutProgramming Поддерживаю. Я лишь указал источник где можно найти инфо. По солиду тоже сделайте видосы, если сочтете нужным конечно.

[@nickstruk562]

Головні поради із відео: 1) Необхідно вивчати не тільки технологічний та коммунікаційний стеки, але й предмету область на яку ти орієнтушся працювати. 2) Навчання програміста ніколи не завершується. Самих лише основ не достатньо аби стати професіоналом, потрібно полглиблювати свої пізнання. 3) Перш ніж розробити рішення певної задачі, його проектують. Вкрай бажано дізнаватися про вже наявне та придумане заздалегіть.

[@AboutProgramming]

1) так 2) в відео все ж таки трохи вужчий сенс. Оскільки всі розуміють, що треба вчитися, але багато хто вважає, що розуміти реалізацію не треба, а достатню знати абстракції. Для баз даних, наприклад, кажуть, що достатньо знати SQL тільки, хоча цього мало, щоб зрозуміти властивості системи. 3) Тут навпаки трохи ширше. З коментаря складається враження, що мета це перевикористати щось наявне, але мета - розвивати навички проектування

[@nickstruk562]

Дякую за конструктивну відповідь. І справді, трохи помилився в конкретизації деяких тем. Буду радий подивитися більше таких відео. Також, буде значно краще, якщо вдасться зменшити хронометраж. @@AboutProgramming

[@matash149]

а можна список цих 13тем і завдань щоб розібратись в глибину?

[@AboutProgramming]

t.me/jabascript/125

[@Epic0n]

Бачу пан полюбляє гарно послухати музику, якщо то не бекграунд :) Але дивлячись на моментуми то скоріш за все не бекграунд.

[@AboutProgramming]

Музику послухати люблю, але то просто гарний бекграунд 🙂

[@RomanApostol]

Круто, ще більше укр контенту!

[@yarosav5396]

Як на мене бажано покрити ще конкурентність, скедуляри, preemption, context switch, thread/process, race conditions, synchronizations (lock, mutex, semaphores etc), models (csp, shared memory, message/actors), математику під ними типу CSP, process calculus, history monoid і тд), всілякі файбери, футури, корутіни, треди і тд. Дуже обширна і на мою думку найбільш цікава тема в CS/TCS разом з теорією типів і формальних методів верифікації/пруфсолверів, фп.

[@AboutProgramming]

Дякую за список ідей для тем. Багато чого в плані, але не все. Є в планах розповісти про те, як працює операційна система - старт процесів (fork, clone, exec), ізоляція(vm, mmu, context switch), мультитаскінг (preemptive, cooperative й scheduling). Також багато про файлові системи та мережі. Також трохи про IPC. Але складної математики не планую. Відносно формальних методів верифікації, то не було на практиці проектів, де довелося це використовувати тому сам плаваю в цій темі 🙂

[@yarosav5396]

@@AboutProgramming дякую вам за вашу працю, підписався, а відео котре ви скинули про `Docker deep dive` обов'язково подивлюсь!

[@voltstas]

Віктор, вельми вдячний Вам! Почерпнув для себе багато цікавої інформації! Продовжуйте будь ласка

[@average-user9]

Я новачок, відносний, світчер, 2 роки у веб-розробці. Як думаєте, чи є сенс прокачувати себе у згаданих пунктах, якщо є такі штуки як ChatGPT? Вангують, що вони скоро самостійно будуть писати програми)

[@AboutProgramming]

ChatGPT може згенерувати трохи коду, але хто користувач цього кода? - програмісти 🙂 Це як шуроповерти, електропилки та інші електричні інструменти не замінили будівельників. Але от те, що під програміста вимагатимеься щось за тиждень, на що потрібен раніше був місяць - це досить реально)

[@lukalionov8169]

залишаєтья відкритим питання - чи існує життя поза роботаю? чи всеж таки треба копати кернел, а все інше після смерті? :))

[@AboutProgramming]

Кернел можна покапати, особливо концептуально. Є unix xv6 й до нього книжка на 100 сторінок. Там вони правда зараз переписали на risc v (коли я читав, то було x86), але на qemu все запускається нормально. Одного тижня після роботи достатньо 🙂

[@kostiantynivanov6875]

частично не соглашусь с первым пунктом - да, конечно понимать предметную область это хорошо но это не задача разраба, глубоко понимать как правильно должно быть по бизнесу, а как не правивльно - это должны бизнес аналитики, либо люди выполняющие эту функцию на проекте программист должен знать как оптимально (с технической точки зрения) реализовать правильную бизнес логику а иначе получается что у тебя программист работает за двоих, а потом ещё кто-то скажет что программист должен взять на себя часть ответственности менеджера, и т.д. и в итоге получается универсальный солдат, который может всё - не может быть так - поэтому у нас и есть разные специальности и профессии имхо надо быть спецом в своём деле, и минимально знать соседние области (T-shape)

[@AboutProgramming]

Програміст не має бути експертом в бізнес домені, але якщо він не буде розуміти бізнес-логіку, то він не зможе оптимально реалізувати її в коді. Наприклад, коли ми писали бухгалтерську систему, то нам приходили й постійно робили лекції по бухгалтерії, інакше ми би просто не спроектували правильні реюзабельні абстракції (й звісно ми навіть близько не стали бухгалтерами, тут так й виходить такий собі T-shape). Аналогічно приклад з чатом - недостатньо знати, що це чат, треба знати для чого й хто буде використовувати, в яких процесах й як називаються правильно з точки зору бізнес логіки суб'єкти й об'єкти та інше. Дуже гарно про це в Еванса в його DDD. Якщо ж взяти ситуацію на ринку, то в 2/3 випадків програмісти мають недостатнє рузуміння домену

[@eolit1o]

Напишіть щось складне на фукц. мові.

[@AboutProgramming]

Нажаль, тут я не експерт

[@rem2764]

З боку ще не дуже досвідченого розробника, це відео наштовхнуло на думку про тему масштабованого коду при потребі бізнесу в швидкості розробки, можливо буде цікаво висвітлити

[@AboutProgramming]

Це цікавий аспект. Є про що розповісти. Дякую за ідею для теми!

[@volodymyrherasymchuk5003]

Дякую за корисний контент українською, навіть достатнім бекграундом допомагає стуруктурувати інформацію в голові

[@Mafftor]

Гарний формат, але раджу змінити інтонацію

[@AboutProgramming]

Дякую. Можливо є якійсь конкретні приклади? Типу моменти з відео де має сенс змінити інтонацію з якої й на яку. Щоб було зрозуміло де виникає проблема сприйняття

[@AboutProgramming]

Ну й можливо в останньому відео вже краще? Бо перші відео були одним дублем, а нові вже трохи по інакшому роблю

[@TheSokilV]

На співбесідах говорив із людьми, які писали код на java, а запустити із команд лайна програму не могли і не розуміли як.

[@AboutProgramming]

Так, такого повно)

[@ihorbond6019]

+

[@yarosav5396]

ні, поняття контейнера є чітко в лінуксі, є LVM і LXC, там реалізований контейнер не просто як описова абстракція ще ходів би додати, що докео не дав ізоляції справжньої звісно ж, її надає LXC

[@AboutProgramming]

LXC це просто user space програма, яка спирається на певні підсистеми ядра. Так само як й докер спирається на ці самі підсистеми. Так само й деякі пакетні менеджери типу snap, flatpak спираються на ці самі підсистеми. На рівні ядра Linux немає окремого контейнеру в якому запускається процес. Контейнер це й є наш процес, якому просто заборонили бачити інші процеси або ще щось (реалізується через namespaces) й обмежили доступ до ресурсів через cgroups. Хоча cgroups можна використовувати з будь-яким іншим процесом. Робив детальну доповідь колись на цю тему (з демками використання namespaces, cgroups, chroot) kzbin.info/www/bejne/eZjFmp2eeap0ndUsi=-Vj1E_quXCQ5MFyY Відносно LVM, то це не про контейнери. Якщо мова про KVM, то це теж вже про повноцінну віртулізацію

[@yarosav5396]

@@AboutProgramming вони ж спираються не те що на підсистему ядра, а на linux namespaces, котрі і є так званими контейнерами, і namespaces якраз є на рівні ядра. upd: бачу, зрозумів, дякую за пояснення

[@yarosav5396]

@@AboutProgramming я чого притягую за вуха з LVM, що типу це logical volume поверх диску, і він створює через кернел /dev/mapper поверх фізичного диску, і виходить logical volume, котрий чисто теоретично можна назватии контейнером, чи все таки теж ні і це дурниці?)

[@aleksandrsavvopulo4510]

По пункту 2: при всем уважении но вы описываете крайность. Вы не сможете настолько глубоко изучить вопрос даже по упомянутым двум бд чтоб понимать всю разницу в таких деталях. Это займет месяцы и месяцы только на изучение. Там ведь помимо вставки записи есть разные индексы, хранимые процедуры, свои языковые конструкции типа CTE и тд и тп. Пожелаю удачи тому кто решится идти по такому пути. А кроме бд есть еще стек других важных технологий. Там тоже в крайности вдаваться? пока вы закончите изучать одно, другое сменит движок в новой мажорной версии и ваши старые знания потеряли актуальность. Как надо делать: надо хорошо понимать теоретическую базу основных принципов которые используются в используемых вами технологиях. Например знать как работают индексы на основе B-Tree. Как именно они реализованы в коде - не важно. Принципы и понятия будут общими. Знать как работает коннекшен пул - а какой именно и какие у него детали - дело второстепенное. Так как принципы меняются значительно медленнее и реже чем их конкретные реализации - знания будут актуальны.

[@AboutProgramming]

Тут я не мав на увазі, що треба знати сам код бази даних. Кожну особливість рідко є сенс знати, бо маємо спадну граничну корисність. Про розуміти глибоко, це я про те, що варто знати на рівні, щоб могти реалізувати/спроектувати аналогічну систему (чи як до цього підійти). Відносно індексів, то якраз робив декілька відео на каналі. Такого рівня зазвичай вистачає, якщо бази даних не є спеціалізацією інженера

[@aleksandrsavvopulo4510]

@@AboutProgrammingОкей, но вот вы снова описываете крайность: "Про розуміти глибоко, це я про те, що варто знати на рівні, щоб могти реалізувати/спроектувати аналогічну систему " Я боюсь представить сколько всего нужно знать чтоб спроектировать бд отдаленно похожую хотя бы на мускуль 4.0 не говоря уже о современных системах. Учитывая что современному бэкендеру в среднем еще надо знать язык, пару фреймворков и пачку сопутствующих технологий, сети, системные штуки и тд, простите, но то о чем вы говорите физически невозможно для одного человека.

[@user-jd8tb9ew8n]

Так що ж там з храмом, це він сам чи делегує?

[@AboutProgramming]

З яким храмом?

[@user-jd8tb9ew8n]

@@AboutProgramming хромом, то гугл виправив, сам відправляє запит на сервер?

[@user-jd8tb9ew8n]

Я тільки вивчаю технології, дякую за контент

[@AboutProgramming]

@@user-jd8tb9ew8n якраз наступне відео буде про DNS :)

[@niklu4038]

"код який демонструє використання" вибач не зрозумів

[@AboutProgramming]

Це про публічний API й приклад його використання для рішення задачі

[@niklu4038]

@@AboutProgramming дякую за приклад! Дуже радий що знайшов твій канал

[@serhiibaranovskyi9131]

Якщо вось так відверто, без обід, то над подачею інформації потрібно попрацювати

[@AboutProgramming]

А що бажано змінити в контексті подачі, щоб полегшити сприйняття інформації? Це перше відео, тому впевнений, що є куди покращувати)

[@serhiibaranovskyi9131]

​@@AboutProgramming Це щоб зберігався контекст без довгого переключення на щось інше та доведення думки до кінця, було просто відчуття що говорив але в моменті різко "відрубав", чисто моє особисте відчуття

[@AboutProgramming]

@@serhiibaranovskyi9131 Зрозумів, дякую. Це недоліки мого лінивого підходу, коли пишеш одним дублем й без монтажу. Часом краще, а часом трохи гірше. Зазвичай на конфах є опорні слайди й тоді норм навіть без підготовки робити доповідь (в 90% випадків працює без проблем). Треба щось таке саме спробувати й для ютуб відео

[@romankrut7038]

Якісний і корисний контент та ще й українською! Так тримати

[@yuwolfuswithout-any-bosssh2420]

Не "краще" ,а ""кращим""!