Віктор, вітаю з першим цікавим та корисним відео на цьому каналі! Дуже класно, що поступово потужні експерти з Software Development підключаються до розвитку україномовного RUclips, наповнюючи його дуже гідним контентом. Бажаю успіхів у розвитку каналу, ділитись драйвом та натхненням із комьюніті!
Сумбурне відео, але тема важлива. Я погоджуюся що треба вміти "розбиратися вглиб", але важко це радити початківцям - все наперед не вивчиш, ці знання краще за все здобуваються за потребою. Зламав щось - розібрався і вивчив. Головне не боятися "зазирнути під капот", у код бібліотеки, фреймворка, і т.д. Звісно в ідеалі краще пірнати під час розробки, до того як щось зламав, але тут теж є баланс - час у всіх обмежений. Особисто для мене великим уроком було розуміння того, про що ви говорили на початку - немає "гарного дизайну", "гарної архітектури системи" у вакуумі. Це ілюзія, що деякі дизайни нам здаються кращими самі по собі. Все має йти від вимог бізнесу і технічних обмежень. Що оптимізуємо. Коли хтось каже, що якийсь дизайн "кращий" вони просто мають якісь критерії оптимізації у голові, які їм подобаються. Важливо це явно визначити і узгодити на папері із усіма, щоб не розводити "дизайн" на пустому місці.
І про доменні область правильно наголосили. Не можливо бути програмістом без прикладної спеціалізації (ФІОТ?). Пишете софт для бухгалтерії - маєте розбиратися у бухгалтерії. Те саме із фінансовими транзакціями, безпекою, торгівлею. Тому варто не цуратися і вивчати бізнес деталі того, що ви пишете. Якщо не подобається предметна область - міняйте роботу, бо на самому "АйТі" ви далеко не виростите. І ще момент - багато знань про архітектуру і системний дизайн здобуваються лише тоді, коли програміст працює над своєю системою довго, підтримує її і бачить наслідки минулих рішень. Тому знову ці знання стають прямо пропорційними досвіду, але за умови що людина не міняє роботу кожні два роки.
Тут й немає задачі все вивчити наперед, а скоріше розуміти ті речі з якими доводиться працювати. Практично будь-який бекендер починає відразу працювати з базою, навіть новачок. Й тут вже бажано знати про індекси й їх властивості та вплив на систему. Ну й обсяг всього досить великий, тому можна почати будучі початківцем, а не закінчити й через 10 років) але бути через 10 років значно потужнішим інженером, ніж більшість тих, хто не задає собі питання як й чому щось працює певним чином
Так звістно потрібно копати, але можу сказати з власного досвіду що знання які не використовуються дуже швидко забуваються на жаль, а якщо до цого додати правило Паретто то виходить копання в глубину після якоїсь межі дуже дороге в плані часу, і якщо ти розуміеш що тобі це потрібно щоб вирішити проблему одноразово то дуже не хоченьться цього роботи. Наприклад банально регулярки, мені щось таке спеціфічне потрібно раз в 2 роки, і кожен раз як перший раз. Так легше повторяти чим вчити але з ходу не виходить вирішувати задачу. Тому хотілося б почути вашу думку як не тільки набути нові знання, а і критерії вибору, а також як їх не впратити в подальшому.
З одного боку є такий момент й потрібне повторення. З другого боку, тут головне зрозуміти, як воно влаштувано всередені, а не знати на пам'ять публічний API (хоча часом й це корисно). Наприклад, я постійно підглядаю в інтернеті синтаксис SQL, команди Git й вивчити все на пам'ять особливо користі не дасть, якщо я це рідко використовую. А от розуміти принципи, й як воно відпрацює всередені, вже дає більше користі (але теж не завжди). Й з часом одні знання чипляються за інші. Наприклад, взяти той самий SQL: 1. SELECT * FROM users WHERE email like '%john' - звичайний індекс може спрацювати 2. SELECT * FROM users WHERE email like '%john%' - звичайний індекс не буде працювати Також колись в Linux в ext2 була проблема с перформансом, коли в одній папці забагато файлів - наприклад, сессії користувача. Й ніби зовсім різні проблеми, але все зводиться до базових структур даних й алгоритмів. Й одні знання підтримують інші. Але звісно, що будуть якісь штуки (навіть супер корисні), які будуть забуватися в будь-якому випадку. Про критерії відбору, дуже гарне запитання. Зроблю відео, як я підхожу до цього, але тут у кожного може бути свій підхід
Випадково потратив на ваше інтервью на ДОУ, був дуже приємно вражений вами. Сидів в парку до самої ночі і слухав, звісно потім, потратив до вас на канал. Так, думка: .) Систематизована та послідовна погляд на загально важливі речі в становленні тебе як майбутнього інженера. .) Важливість розуміння 'підкапотних' справ для початку на базомову рівні, які допоможуть тобі бути гарним спеціалістом. .) Чудово допомогає краще систематизувати 'кашу' в голові та зрозуміти приблизну послідовність в процесі розвитку. Дякую за контент, та й ще українською.
Дуже цікаво, дякую. Навчаюсь на фронта десь біля півтора року, дописую проект(правда там фул стак...) і шукатиму роботу. Такі відео як це допомагають зрозуміти "що робити далі", особисто мені.
Дуже суттєво ! 👍 Повністю погоджуюсь, що саме мислення над питаннями "чому" призводять до кращої якості (а всі 3 питання озвучені Віктором по суті саме про "чому")
дивлюсь, і впізнаю себе - також, коли щось пояснюю, постійно збиваюсь, перескаую з теми на тему, думка летить далеко по переду того, що зараз кажу...) також програмую біля 20 років, але працюю далеко не в гуглі) дякую за відео!
Мені чомусь здається що челенджі то для юних техніків 😅 а дорослі люди обирають второвані шляхи котрі закінчуються хлібом на столі і чимось смачненьким на хліб 😊 Дякую за відео 👍
Контент бомба, дуже дякую, було б цікаво почути про фундаментальні знання в фронтенді , що дійсно важливо знати для фронтендера і чи потрібно вчити різні фреймворки чи достатньо одного, дякую )
Знаючи Віктора особисто можу з впевненістю сказати, що попереду буде багато цікавого і корисного. Щодо теми відео - підписуюсь під всім сказаним. Особливо під першими двома. Зі своєї практики знаю, що глибоке розуміння домену і всяких "підкапотних" нюансів робить вас крутим і цінним програмістом. Писати код можуть всі, а от розуміти що там коїться - це вже інша справа. Успіхів у розвитку каналу!
Дякую за цікавий контент. Хотілося б більше прикладів практичного використання глибини знань. Наприклад тих самих мережевих протоколів - як то може допомогти в розробці. Бо зі свого досвіду можу сказати, що як почув про них багато років тому в університеті, так і жодного разу ті знання і не пригодилися. Також з майбутніх тем було б цікаво почути вашу думку на наступну тему: що краще взяти неоптимальну, але знайому технологію чи краще працюати з підходящими інстуреметами, але перед тим потративши час на їх вивчення або пошук відповідних спеців на ринку.
У симфонії життя ти танцюєш в ритмі своєї мрії, крокуючи все ближче і ближче до бажаної мети, залишаючи за собою слід натхнення. Не знаю чи достатньо тут абстракції. Набиваю руку тільки, вибачте
Дякую. Контент - топ. Дуже корисна порада при проєктуванні модуля починати з того як його використовувати. Якщо є можливість, хотілось би почути якісь поради(та що почитати по темі) по А/Б тестуванню. Працюю в продукті, часто маркетинг приходить з ідеями різних банерів чи попапів, деякі з них показують + в конверсії, та лишаються висіти на сайті. З часом сайт стає схожим на жахіття) Дуже болить за користувачів)) Можливо, є якісь поради як правильно вимірювати довгостроковий ефект від фіч etc. Про подачу інформації - все ж краще записати відео одним дублем та випустити його, ніж витрачати час на монтаж та переписування. Суть важливіша за форму. Хоча і з формою тут все гуд. Імхо.
Дякую за відео. Таке питання - як обирати глибину, на яку вивчату ту чи іншу технологію та як розуміти достатній рівень глубини. Приклад nodejs, вивчили базис (тут просто можна навічно як по меня заритися, якщо вивчити спочатку роботу з файловою системою - потім окремо поглибити знання роботи з самою файловою системою без ноди і так по кожному напрямку: як працює з npm, crypto, buffer etc), стежимо за оновленнями, оновлення відносно часто і для того щоб розібратися що змінилося - треба, як на мій погляд, досить не мало часу. А це тільки одна з технологій у стеку який використовується.
Так, все це вимагає роки або десятиріччя. Тому ключова ідея - накопичувати фундаментальні знання, які не втрачають актуальності й спільні для багатьох технологій
Це, скоріше, ті речі які взагалі із фахівця роблять програміста як такого. Про дані момнети багато говорять, але ж це стандартні речі для студентів наших ВНЗів на профільних факультетах, наприклад, курс Основи програмної інженерії, або Конструювання ПЗ. Дивно, що потім чути голоси про те, що університет "нічого не дав"
Так, але вміння проектувати приходить з досвідом. Навіть студенти найкращих вузів світу все ще мають складнощі з цим, як це не дивно. Побачив це в Гугл, що джуни можуть знати алгоритми й структури даних, але проектувати ще не вміють, на відміну від сеніорів.
@@AboutProgramming так, студент буде зазвичай фіскисти некритичні баги і аж ніяк не працювати над розробкою архітектури. Я дещо інше мав на увазі, а саме те, що дже часто чомусь для фахівців вже, навіть, з певним досвідом фундаментальні речі програмної інженерії постають як відкриття
Колись робив про докер доповідь ruclips.net/video/CgbijhDEAgs/видео.html (правда доповідь російською), але в планах є детально це розкрити й на цьому каналі. Тому все буде 🙂
Дякую за відео, чудовий початок! ❤ Момент з TDD: здається, якоїсь великої різниці між тим, щоб написати інтерфейс і приклад використання і тим, щоб зробити те ж саме і зафейлити тест (ред грін цикл), немає. Просто на початковому етапі ще додається крок з назвою тесту, який має відображати бізнес вимогу, що також не є зайвим зафіксувати перед початком розробки реалізації. Чи я щось не до кінця зрозумів?
В цілому так. Просто часто в TDD роблять акцент, що спочатку має бути тест, який падає, а потім код. Для мене важливо просто, що й тести й код в одному пул реквесті, а в якому порядку додавався тест, то вже вторинне
@@AboutProgramming ага. З моєї практики якщо цікаво: ми у себе використовуємо скафолдинг, і при створенні нового компоненту (частіше за все реалізація ендпойнту), автогенерується відразу тест з викликом цього компоненту (SUT), який і буде зазвичай червоним) Таким чином і розробнику швидше тест написати, і грубо кажучи ред грін цикл закривається. Ну і ментально видаляти файл з тестом у девів менше бажання через карму, тому кавередж тримається)
стосовно «як це працює»: можна піти ще далі, і розібратись нащо хтось те зробив і чого він захотів зробити те саме так, а не якось по-іншому. таким чином ви занурюєтесь у майндсет, і користуєтесь інструментом на повну. і розумієте розвиток проекту, які фічі чекати в наступному оновленні і тд. про тдд хочу додати що інколи самі тести стають спрощеним середовищем виконання. наприклад при розробці смарт контрактів для evm з hardhat. перевірка функціоналу вручну займає більше часу, ніж написання тестів
Звісно автоматизовані тести дуже допомагають. Я більше про те, що я зазвичай пишу код й тести й не слідую постійно Red Green Loop. TDD рекомендує ж спочатку написати тест, який падає (бо ще немає робочого коду), а потім вже писати код. Я такий підхід використовую, коли фікшу баги, тоді легчше спочатку додати тест для репродюсу. А якщо нова фіча, то майже завжди код, а потім тест
Цікавий момент про зануритися в майндсет й про розуміння розвитку проекту. Це не завжди можливо в контексті стороніх бібліотек чи фреймворків, але на проекті на якому працює безпеосередньо сам інженер це актуально. Бо, коли приходять нові люди на проект, то часто хочуть переписати все, а потім виявляється, що їх ідея це те, що було напочатку й від чого вже відмовилися :)
@@AboutProgramming я зараз більше і більше дивлюсь на використання сторонніх фреймворків і інструментів як на cross-team collaboration, наче це все відбувається в одній компанії. на щастя сучасна опен-сорс культура це дозволяє
Дякую, це дуже корисний контент. Успіхів в розвитку каналу 🎉 +1 до знань доменної області. Задача програміста - вирішити проблему, а не просто писати код. Це викривається і при взаємодії з тими ж дизайнерами (можна пояснити, чому це рішення краще, ніж інше), і при створенні фічі можна додавати «плюшки», які роблять життя юзерів краще Про глибину знань. Імхо, корисно занурюватись, коли вже є знання «в ширину». Тяжко буде зрозуміти, що робити з jwt токеном чи базою даних, коли ти джунік і вмієш малювати кнопочки і рендерити масив айтемів. Далі важливо заглиблюватись, але спочатку потрібно зрозуміти як воно працює на хайлевелі. ps але ми почали питати на співбесіді різницю між кодуванням шифруванням і хешуванням навіть початківців 😂
Дякую за відгук! Відносно "в ширину", то так й є - треба й в "ширину" й в "глибину". Але зазвичай воно чередується й чипляє один одного. Та й часто спроба розібратися "в глибину" потягне за собою необхідність двитися в ширину. Як той самий JWT потягне за собою base64. Далі варто подумати для чого існує base64, то вже можна згадати, що я картинки для веб можуть кодуватися в base64. А потім виявиться, що base64 в http basic auth це практично плейн текст. Мені нещодавно треба було кидати в логі бінарні дані, то base64 підійшов ідеально :). Якщо далі копати з JWT, то виявиться, що там можна вказати алгоритм підпису й тут вже дійшли до асиметричної криптографії й так далі :) >почали питати на співбесіді різницю між кодуванням шифруванням і хешуванням навіть початківців ніби й прості концепції, а якщо людина плутає, то можна таких проблем з сек'юріті отримати :) Та навіть, якщо не знає, то після співбесіди розбереться, що вже корисно для всіх
Як на мене бажано покрити ще конкурентність, скедуляри, 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 разом з теорією типів і формальних методів верифікації/пруфсолверів, фп.
Дякую за список ідей для тем. Багато чого в плані, але не все. Є в планах розповісти про те, як працює операційна система - старт процесів (fork, clone, exec), ізоляція(vm, mmu, context switch), мультитаскінг (preemptive, cooperative й scheduling). Також багато про файлові системи та мережі. Також трохи про IPC. Але складної математики не планую. Відносно формальних методів верифікації, то не було на практиці проектів, де довелося це використовувати тому сам плаваю в цій темі 🙂
Дякую за відею, вийшло цікаво! Щодо ідей або думки про відео, то мені було б цікаво почути про свписок літератури, яку б Ви рекомендували. Ви декілька разів озвучували авторів та назви книжок, але хотілося б побачити конкретний список Ваших улюблюлених авторів аба книжок! Якщо це не актуальна для вас тема для відео, то напишіть , будь ласка, у відповіді до мого коментаря. Дякую!
Кернел можна покапати, особливо концептуально. Є unix xv6 й до нього книжка на 100 сторінок. Там вони правда зараз переписали на risc v (коли я читав, то було x86), але на qemu все запускається нормально. Одного тижня після роботи достатньо 🙂
Головні поради із відео: 1) Необхідно вивчати не тільки технологічний та коммунікаційний стеки, але й предмету область на яку ти орієнтушся працювати. 2) Навчання програміста ніколи не завершується. Самих лише основ не достатньо аби стати професіоналом, потрібно полглиблювати свої пізнання. 3) Перш ніж розробити рішення певної задачі, його проектують. Вкрай бажано дізнаватися про вже наявне та придумане заздалегіть.
1) так 2) в відео все ж таки трохи вужчий сенс. Оскільки всі розуміють, що треба вчитися, але багато хто вважає, що розуміти реалізацію не треба, а достатню знати абстракції. Для баз даних, наприклад, кажуть, що достатньо знати SQL тільки, хоча цього мало, щоб зрозуміти властивості системи. 3) Тут навпаки трохи ширше. З коментаря складається враження, що мета це перевикористати щось наявне, але мета - розвивати навички проектування
Дякую за конструктивну відповідь. І справді, трохи помилився в конкретизації деяких тем. Буду радий подивитися більше таких відео. Також, буде значно краще, якщо вдасться зменшити хронометраж. @@AboutProgramming
Я новачок, відносний, світчер, 2 роки у веб-розробці. Як думаєте, чи є сенс прокачувати себе у згаданих пунктах, якщо є такі штуки як ChatGPT? Вангують, що вони скоро самостійно будуть писати програми)
ChatGPT може згенерувати трохи коду, але хто користувач цього кода? - програмісти 🙂 Це як шуроповерти, електропилки та інші електричні інструменти не замінили будівельників. Але от те, що під програміста вимагатимеься щось за тиждень, на що потрібен раніше був місяць - це досить реально)
ні, поняття контейнера є чітко в лінуксі, є LVM і LXC, там реалізований контейнер не просто як описова абстракція ще ходів би додати, що докео не дав ізоляції справжньої звісно ж, її надає LXC
LXC це просто user space програма, яка спирається на певні підсистеми ядра. Так само як й докер спирається на ці самі підсистеми. Так само й деякі пакетні менеджери типу snap, flatpak спираються на ці самі підсистеми. На рівні ядра Linux немає окремого контейнеру в якому запускається процес. Контейнер це й є наш процес, якому просто заборонили бачити інші процеси або ще щось (реалізується через namespaces) й обмежили доступ до ресурсів через cgroups. Хоча cgroups можна використовувати з будь-яким іншим процесом. Робив детальну доповідь колись на цю тему (з демками використання namespaces, cgroups, chroot) ruclips.net/video/CgbijhDEAgs/видео.htmlsi=-Vj1E_quXCQ5MFyY Відносно LVM, то це не про контейнери. Якщо мова про KVM, то це теж вже про повноцінну віртулізацію
@@AboutProgramming вони ж спираються не те що на підсистему ядра, а на linux namespaces, котрі і є так званими контейнерами, і namespaces якраз є на рівні ядра. upd: бачу, зрозумів, дякую за пояснення
@@AboutProgramming я чого притягую за вуха з LVM, що типу це logical volume поверх диску, і він створює через кернел /dev/mapper поверх фізичного диску, і виходить logical volume, котрий чисто теоретично можна назватии контейнером, чи все таки теж ні і це дурниці?)
Дякую. Можливо є якійсь конкретні приклади? Типу моменти з відео де має сенс змінити інтонацію з якої й на яку. Щоб було зрозуміло де виникає проблема сприйняття
частично не соглашусь с первым пунктом - да, конечно понимать предметную область это хорошо но это не задача разраба, глубоко понимать как правильно должно быть по бизнесу, а как не правивльно - это должны бизнес аналитики, либо люди выполняющие эту функцию на проекте программист должен знать как оптимально (с технической точки зрения) реализовать правильную бизнес логику а иначе получается что у тебя программист работает за двоих, а потом ещё кто-то скажет что программист должен взять на себя часть ответственности менеджера, и т.д. и в итоге получается универсальный солдат, который может всё - не может быть так - поэтому у нас и есть разные специальности и профессии имхо надо быть спецом в своём деле, и минимально знать соседние области (T-shape)
Програміст не має бути експертом в бізнес домені, але якщо він не буде розуміти бізнес-логіку, то він не зможе оптимально реалізувати її в коді. Наприклад, коли ми писали бухгалтерську систему, то нам приходили й постійно робили лекції по бухгалтерії, інакше ми би просто не спроектували правильні реюзабельні абстракції (й звісно ми навіть близько не стали бухгалтерами, тут так й виходить такий собі T-shape). Аналогічно приклад з чатом - недостатньо знати, що це чат, треба знати для чого й хто буде використовувати, в яких процесах й як називаються правильно з точки зору бізнес логіки суб'єкти й об'єкти та інше. Дуже гарно про це в Еванса в його DDD. Якщо ж взяти ситуацію на ринку, то в 2/3 випадків програмісти мають недостатнє рузуміння домену
З боку ще не дуже досвідченого розробника, це відео наштовхнуло на думку про тему масштабованого коду при потребі бізнесу в швидкості розробки, можливо буде цікаво висвітлити
@@AboutProgramming Це щоб зберігався контекст без довгого переключення на щось інше та доведення думки до кінця, було просто відчуття що говорив але в моменті різко "відрубав", чисто моє особисте відчуття
@@serhiibaranovskyi9131 Зрозумів, дякую. Це недоліки мого лінивого підходу, коли пишеш одним дублем й без монтажу. Часом краще, а часом трохи гірше. Зазвичай на конфах є опорні слайди й тоді норм навіть без підготовки робити доповідь (в 90% випадків працює без проблем). Треба щось таке саме спробувати й для ютуб відео
Велкам ту юкрейніан ютуб! Глорі ту контент :)
Дякую! :)
Віктор, вітаю з першим цікавим та корисним відео на цьому каналі!
Дуже класно, що поступово потужні експерти з Software Development підключаються до розвитку україномовного RUclips, наповнюючи його дуже гідним контентом.
Бажаю успіхів у розвитку каналу, ділитись драйвом та натхненням із комьюніті!
Дякую! 🙂
Сумбурне відео, але тема важлива. Я погоджуюся що треба вміти "розбиратися вглиб", але важко це радити початківцям - все наперед не вивчиш, ці знання краще за все здобуваються за потребою. Зламав щось - розібрався і вивчив. Головне не боятися "зазирнути під капот", у код бібліотеки, фреймворка, і т.д. Звісно в ідеалі краще пірнати під час розробки, до того як щось зламав, але тут теж є баланс - час у всіх обмежений.
Особисто для мене великим уроком було розуміння того, про що ви говорили на початку - немає "гарного дизайну", "гарної архітектури системи" у вакуумі. Це ілюзія, що деякі дизайни нам здаються кращими самі по собі. Все має йти від вимог бізнесу і технічних обмежень. Що оптимізуємо. Коли хтось каже, що якийсь дизайн "кращий" вони просто мають якісь критерії оптимізації у голові, які їм подобаються. Важливо це явно визначити і узгодити на папері із усіма, щоб не розводити "дизайн" на пустому місці.
І про доменні область правильно наголосили. Не можливо бути програмістом без прикладної спеціалізації (ФІОТ?). Пишете софт для бухгалтерії - маєте розбиратися у бухгалтерії. Те саме із фінансовими транзакціями, безпекою, торгівлею. Тому варто не цуратися і вивчати бізнес деталі того, що ви пишете. Якщо не подобається предметна область - міняйте роботу, бо на самому "АйТі" ви далеко не виростите. І ще момент - багато знань про архітектуру і системний дизайн здобуваються лише тоді, коли програміст працює над своєю системою довго, підтримує її і бачить наслідки минулих рішень. Тому знову ці знання стають прямо пропорційними досвіду, але за умови що людина не міняє роботу кожні два роки.
Тут й немає задачі все вивчити наперед, а скоріше розуміти ті речі з якими доводиться працювати. Практично будь-який бекендер починає відразу працювати з базою, навіть новачок. Й тут вже бажано знати про індекси й їх властивості та вплив на систему. Ну й обсяг всього досить великий, тому можна почати будучі початківцем, а не закінчити й через 10 років) але бути через 10 років значно потужнішим інженером, ніж більшість тих, хто не задає собі питання як й чому щось працює певним чином
Так звістно потрібно копати, але можу сказати з власного досвіду що знання які не використовуються дуже швидко забуваються на жаль, а якщо до цого додати правило Паретто то виходить копання в глубину після якоїсь межі дуже дороге в плані часу, і якщо ти розуміеш що тобі це потрібно щоб вирішити проблему одноразово то дуже не хоченьться цього роботи. Наприклад банально регулярки, мені щось таке спеціфічне потрібно раз в 2 роки, і кожен раз як перший раз. Так легше повторяти чим вчити але з ходу не виходить вирішувати задачу. Тому хотілося б почути вашу думку як не тільки набути нові знання, а і критерії вибору, а також як їх не впратити в подальшому.
З одного боку є такий момент й потрібне повторення. З другого боку, тут головне зрозуміти, як воно влаштувано всередені, а не знати на пам'ять публічний API (хоча часом й це корисно). Наприклад, я постійно підглядаю в інтернеті синтаксис SQL, команди Git й вивчити все на пам'ять особливо користі не дасть, якщо я це рідко використовую. А от розуміти принципи, й як воно відпрацює всередені, вже дає більше користі (але теж не завжди). Й з часом одні знання чипляються за інші. Наприклад, взяти той самий SQL:
1. SELECT * FROM users WHERE email like '%john' - звичайний індекс може спрацювати
2. SELECT * FROM users WHERE email like '%john%' - звичайний індекс не буде працювати
Також колись в Linux в ext2 була проблема с перформансом, коли в одній папці забагато файлів - наприклад, сессії користувача. Й ніби зовсім різні проблеми, але все зводиться до базових структур даних й алгоритмів. Й одні знання підтримують інші.
Але звісно, що будуть якісь штуки (навіть супер корисні), які будуть забуватися в будь-якому випадку.
Про критерії відбору, дуже гарне запитання. Зроблю відео, як я підхожу до цього, але тут у кожного може бути свій підхід
Дякую, за такий крутий шейринг🔥 Як на мене дуже доступно і валідно пояснив ці 3 моменти 👍 Успіхів в подальшому, буду чекати більше таких відео🙂
Випадково потратив на ваше інтервью на ДОУ, був дуже приємно вражений вами.
Сидів в парку до самої ночі і слухав, звісно потім, потратив до вас на канал.
Так, думка:
.) Систематизована та послідовна погляд на загально важливі речі в становленні тебе як майбутнього інженера.
.) Важливість розуміння 'підкапотних' справ для початку на базомову рівні, які допоможуть тобі бути гарним спеціалістом.
.) Чудово допомогає краще систематизувати 'кашу' в голові та зрозуміти приблизну послідовність в процесі розвитку.
Дякую за контент, та й ще українською.
Дякую за такий структурований відгук 🙂
Дуже цікаво, дякую.
Навчаюсь на фронта десь біля півтора року, дописую проект(правда там фул стак...) і шукатиму роботу. Такі відео як це допомагають зрозуміти "що робити далі", особисто мені.
Дуже суттєво ! 👍 Повністю погоджуюсь, що саме мислення над питаннями "чому" призводять до кращої якості (а всі 3 питання озвучені Віктором по суті саме про "чому")
ну топчик, реально на рідінй мові не вистачає такого контенту, тому дякую і буду ставати краще завдяки вашим порадам!
дивлюсь, і впізнаю себе - також, коли щось пояснюю, постійно збиваюсь, перескаую з теми на тему, думка летить далеко по переду того, що зараз кажу...) також програмую біля 20 років, але працюю далеко не в гуглі) дякую за відео!
Це коли багато досвіду накопичується, то хочеться про все розповісти відразу 🙈😀
Дякую за відео! У Вас гарно виходить і Вас цікаво слухати 👍
Який крутий канал, ось би чаще відео були.
Мені чомусь здається що челенджі то для юних техніків 😅 а дорослі люди обирають второвані шляхи котрі закінчуються хлібом на столі і чимось смачненьким на хліб 😊
Дякую за відео 👍
Дуже корисні поради! Взагалі мега крутий канал, дивлюсь відео за відео!
дуже хотів би побільше відео про базові якісь речі по темі computer science
Ви дуже крутий, дякую вам! Чекаю більше відео по юсфул книжкам!!!
Дякую за відгук) Давно про книжки не розповідав. Можливо треба робити окремий огляд під кожну книгу
Випадково натрапив на відео. Чудова робота! Вподобайка та підписка від мене!💪
доволі універсальні поради як на мене) дякую за відео
Дякую!
Подарунок на Різдво!
Дякую за відео, дізнався про канал з інтервʼю на DOU, впевнений що буду переглядати всі відео не одноразово
Контент бомба, дуже дякую, було б цікаво почути про фундаментальні знання в фронтенді , що дійсно важливо знати для фронтендера і чи потрібно вчити різні фреймворки чи достатньо одного, дякую )
Контент просто ТОП! Дякую за відео!
Топ відос!
Де взяти цих 13 тем?))
Крута ідея для відео, круто було б і далі чути як може покращити свій лвл))
дякую за відео, надихає читати більше книжок :)
Класну тему обрав для першого випуску))
Вже хочеться подивитись нові
Дякую! Стільки коментарів, що дуже мотивує робити нові відео! )
Дякую за круте відео!
Вогонь 🔥
Теми:
- Читабельність коду
- Процес code review
- Робота хмарних сервісів (GCP під капотом 👀)
- Досвід з open-source
О, дякую за теми!
Дуже якісний контент, дякую!
Знаючи Віктора особисто можу з впевненістю сказати, що попереду буде багато цікавого і корисного.
Щодо теми відео - підписуюсь під всім сказаним. Особливо під першими двома. Зі своєї практики знаю, що глибоке розуміння домену і всяких "підкапотних" нюансів робить вас крутим і цінним програмістом.
Писати код можуть всі, а от розуміти що там коїться - це вже інша справа.
Успіхів у розвитку каналу!
Рома, дякую за відгук й підписку! 🙂
Дякую за чудовий контент! Прохання, чи можеш описати якийсь практичний роудмап (задачок, як з JWT парсером) який на твою думку є базовим?
Ось був колись пост про бейзлайн в каналі - t.me/jabascript/125
Вітаю з першим відео та дякую за україномовний контент 🎉
Цікава для мене тема: покращення якості код-рев‘ю у команді
Дякую! Відносно code review, то цікавий процес в Google - розповім в окремому відео
Відос супер, дякую. Було б цікаво побачити ці 13+ тем, матеріали і задачі до них
t.me/jabascript/125
дякую, дуже пізнавально!
Дякую за цікавий контент. Хотілося б більше прикладів практичного використання глибини знань. Наприклад тих самих мережевих протоколів - як то може допомогти в розробці. Бо зі свого досвіду можу сказати, що як почув про них багато років тому в університеті, так і жодного разу ті знання і не пригодилися.
Також з майбутніх тем було б цікаво почути вашу думку на наступну тему: що краще взяти неоптимальну, але знайому технологію чи краще працюати з підходящими інстуреметами, але перед тим потративши час на їх вивчення або пошук відповідних спеців на ринку.
Дякую! Є що розповісти з обох питань. Додам в план
У симфонії життя ти танцюєш в ритмі своєї мрії, крокуючи все ближче і ближче до бажаної мети, залишаючи за собою слід натхнення.
Не знаю чи достатньо тут абстракції. Набиваю руку тільки, вибачте
Уявляю замовника, який бачить такі абстракції в коді))
дякую за відео!
Класний і структурований контент, дякую 👍
дуже дуже дякую! круто і дуже інформативно!!! супер
Віктор, вельми вдячний Вам! Почерпнув для себе багато цікавої інформації! Продовжуйте будь ласка
Де ти був раніше? чому аж у кінці 2022 року почав. Молодець.!
Дякую! Вже цілий рік планував й зрозумів, що треба запускатися хоч у простому форматі, а не чекати кінця 2023 :)
❤❤❤❤❤❤❤❤❤❤
Дякую. Контент - топ. Дуже корисна порада при проєктуванні модуля починати з того як його використовувати.
Якщо є можливість, хотілось би почути якісь поради(та що почитати по темі) по А/Б тестуванню. Працюю в продукті, часто маркетинг приходить з ідеями різних банерів чи попапів, деякі з них показують + в конверсії, та лишаються висіти на сайті. З часом сайт стає схожим на жахіття) Дуже болить за користувачів)) Можливо, є якісь поради як правильно вимірювати довгостроковий ефект від фіч etc.
Про подачу інформації - все ж краще записати відео одним дублем та випустити його, ніж витрачати час на монтаж та переписування. Суть важливіша за форму. Хоча і з формою тут все гуд. Імхо.
Комент для просування.
Дякую за відео.
Таке питання - як обирати глибину, на яку вивчату ту чи іншу технологію та як розуміти достатній рівень глубини. Приклад nodejs, вивчили базис (тут просто можна навічно як по меня заритися, якщо вивчити спочатку роботу з файловою системою - потім окремо поглибити знання роботи з самою файловою системою без ноди і так по кожному напрямку: як працює з npm, crypto, buffer etc), стежимо за оновленнями, оновлення відносно часто і для того щоб розібратися що змінилося - треба, як на мій погляд, досить не мало часу. А це тільки одна з технологій у стеку який використовується.
Так, все це вимагає роки або десятиріччя. Тому ключова ідея - накопичувати фундаментальні знання, які не втрачають актуальності й спільні для багатьох технологій
Дуже цікаво
а можна список цих 13тем і завдань щоб розібратись в глибину?
t.me/jabascript/125
Дякую
Це, скоріше, ті речі які взагалі із фахівця роблять програміста як такого. Про дані момнети багато говорять, але ж це стандартні речі для студентів наших ВНЗів на профільних факультетах, наприклад, курс Основи програмної інженерії, або Конструювання ПЗ. Дивно, що потім чути голоси про те, що університет "нічого не дав"
Так, але вміння проектувати приходить з досвідом. Навіть студенти найкращих вузів світу все ще мають складнощі з цим, як це не дивно. Побачив це в Гугл, що джуни можуть знати алгоритми й структури даних, але проектувати ще не вміють, на відміну від сеніорів.
@@AboutProgramming так, студент буде зазвичай фіскисти некритичні баги і аж ніяк не працювати над розробкою архітектури. Я дещо інше мав на увазі, а саме те, що дже часто чомусь для фахівців вже, навіть, з певним досвідом фундаментальні речі програмної інженерії постають як відкриття
З побажань на наступні відео, було б цікаво про Докер і контейнери, то що ви частково тут зачепили. Особливо з Віндовс імеджами на Лінуксі
Колись робив про докер доповідь ruclips.net/video/CgbijhDEAgs/видео.html (правда доповідь російською), але в планах є детально це розкрити й на цьому каналі. Тому все буде 🙂
Дякую за відео, чудовий початок! ❤
Момент з TDD: здається, якоїсь великої різниці між тим, щоб написати інтерфейс і приклад використання і тим, щоб зробити те ж саме і зафейлити тест (ред грін цикл), немає. Просто на початковому етапі ще додається крок з назвою тесту, який має відображати бізнес вимогу, що також не є зайвим зафіксувати перед початком розробки реалізації.
Чи я щось не до кінця зрозумів?
В цілому так. Просто часто в TDD роблять акцент, що спочатку має бути тест, який падає, а потім код. Для мене важливо просто, що й тести й код в одному пул реквесті, а в якому порядку додавався тест, то вже вторинне
@@AboutProgramming ага. З моєї практики якщо цікаво: ми у себе використовуємо скафолдинг, і при створенні нового компоненту (частіше за все реалізація ендпойнту), автогенерується відразу тест з викликом цього компоненту (SUT), який і буде зазвичай червоним) Таким чином і розробнику швидше тест написати, і грубо кажучи ред грін цикл закривається. Ну і ментально видаляти файл з тестом у девів менше бажання через карму, тому кавередж тримається)
стосовно «як це працює»: можна піти ще далі, і розібратись нащо хтось те зробив і чого він захотів зробити те саме так, а не якось по-іншому. таким чином ви занурюєтесь у майндсет, і користуєтесь інструментом на повну. і розумієте розвиток проекту, які фічі чекати в наступному оновленні і тд.
про тдд хочу додати що інколи самі тести стають спрощеним середовищем виконання. наприклад при розробці смарт контрактів для evm з hardhat. перевірка функціоналу вручну займає більше часу, ніж написання тестів
Звісно автоматизовані тести дуже допомагають. Я більше про те, що я зазвичай пишу код й тести й не слідую постійно Red Green Loop. TDD рекомендує ж спочатку написати тест, який падає (бо ще немає робочого коду), а потім вже писати код. Я такий підхід використовую, коли фікшу баги, тоді легчше спочатку додати тест для репродюсу. А якщо нова фіча, то майже завжди код, а потім тест
Цікавий момент про зануритися в майндсет й про розуміння розвитку проекту. Це не завжди можливо в контексті стороніх бібліотек чи фреймворків, але на проекті на якому працює безпеосередньо сам інженер це актуально. Бо, коли приходять нові люди на проект, то часто хочуть переписати все, а потім виявляється, що їх ідея це те, що було напочатку й від чого вже відмовилися :)
@@AboutProgramming я зараз більше і більше дивлюсь на використання сторонніх фреймворків і інструментів як на cross-team collaboration, наче це все відбувається в одній компанії. на щастя сучасна опен-сорс культура це дозволяє
Все по суті)
Дякую за корисний контент українською, навіть достатнім бекграундом допомагає стуруктурувати інформацію в голові
Дякую, це дуже корисний контент. Успіхів в розвитку каналу 🎉
+1 до знань доменної області. Задача програміста - вирішити проблему, а не просто писати код. Це викривається і при взаємодії з тими ж дизайнерами (можна пояснити, чому це рішення краще, ніж інше), і при створенні фічі можна додавати «плюшки», які роблять життя юзерів краще
Про глибину знань. Імхо, корисно занурюватись, коли вже є знання «в ширину». Тяжко буде зрозуміти, що робити з jwt токеном чи базою даних, коли ти джунік і вмієш малювати кнопочки і рендерити масив айтемів. Далі важливо заглиблюватись, але спочатку потрібно зрозуміти як воно працює на хайлевелі. ps але ми почали питати на співбесіді різницю між кодуванням шифруванням і хешуванням навіть початківців 😂
Дякую за відгук!
Відносно "в ширину", то так й є - треба й в "ширину" й в "глибину". Але зазвичай воно чередується й чипляє один одного. Та й часто спроба розібратися "в глибину" потягне за собою необхідність двитися в ширину. Як той самий JWT потягне за собою base64. Далі варто подумати для чого існує base64, то вже можна згадати, що я картинки для веб можуть кодуватися в base64. А потім виявиться, що base64 в http basic auth це практично плейн текст. Мені нещодавно треба було кидати в логі бінарні дані, то base64 підійшов ідеально :). Якщо далі копати з JWT, то виявиться, що там можна вказати алгоритм підпису й тут вже дійшли до асиметричної криптографії й так далі :)
>почали питати на співбесіді різницю між кодуванням шифруванням і хешуванням навіть початківців
ніби й прості концепції, а якщо людина плутає, то можна таких проблем з сек'юріті отримати :) Та навіть, якщо не знає, то після співбесіди розбереться, що вже корисно для всіх
Як на мене бажано покрити ще конкурентність, скедуляри, 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 разом з теорією типів і формальних методів верифікації/пруфсолверів, фп.
Дякую за список ідей для тем. Багато чого в плані, але не все. Є в планах розповісти про те, як працює операційна система - старт процесів (fork, clone, exec), ізоляція(vm, mmu, context switch), мультитаскінг (preemptive, cooperative й scheduling). Також багато про файлові системи та мережі. Також трохи про IPC. Але складної математики не планую. Відносно формальних методів верифікації, то не було на практиці проектів, де довелося це використовувати тому сам плаваю в цій темі 🙂
@@AboutProgramming дякую вам за вашу працю, підписався, а відео котре ви скинули про `Docker deep dive` обов'язково подивлюсь!
Третій пункт найбільше сподобався
18:17 є вже відео з прикладами? :)
Є в плані зробити багато відео по проектуванню й там точно будуть приклади🙂
Дякую за відею, вийшло цікаво!
Щодо ідей або думки про відео, то мені було б цікаво почути про свписок літератури, яку б Ви рекомендували. Ви декілька разів озвучували авторів та назви книжок, але хотілося б побачити конкретний список Ваших улюблюлених авторів аба книжок! Якщо це не актуальна для вас тема для відео, то напишіть , будь ласка, у відповіді до мого коментаря. Дякую!
Дякую! Обов'язково зроблю відео про книги! 🙂
залишаєтья відкритим питання - чи існує життя поза роботаю?
чи всеж таки треба копати кернел, а все інше після смерті? :))
Кернел можна покапати, особливо концептуально. Є unix xv6 й до нього книжка на 100 сторінок. Там вони правда зараз переписали на risc v (коли я читав, то було x86), але на qemu все запускається нормально. Одного тижня після роботи достатньо 🙂
Бачу пан полюбляє гарно послухати музику, якщо то не бекграунд :) Але дивлячись на моментуми то скоріш за все не бекграунд.
Музику послухати люблю, але то просто гарний бекграунд 🙂
Головні поради із відео:
1) Необхідно вивчати не тільки технологічний та коммунікаційний стеки, але й предмету область на яку ти орієнтушся працювати.
2) Навчання програміста ніколи не завершується. Самих лише основ не достатньо аби стати професіоналом, потрібно полглиблювати свої пізнання.
3) Перш ніж розробити рішення певної задачі, його проектують. Вкрай бажано дізнаватися про вже наявне та придумане заздалегіть.
1) так
2) в відео все ж таки трохи вужчий сенс. Оскільки всі розуміють, що треба вчитися, але багато хто вважає, що розуміти реалізацію не треба, а достатню знати абстракції. Для баз даних, наприклад, кажуть, що достатньо знати SQL тільки, хоча цього мало, щоб зрозуміти властивості системи.
3) Тут навпаки трохи ширше. З коментаря складається враження, що мета це перевикористати щось наявне, але мета - розвивати навички проектування
Дякую за конструктивну відповідь.
І справді, трохи помилився в конкретизації деяких тем.
Буду радий подивитися більше таких відео. Також, буде значно краще, якщо вдасться зменшити хронометраж. @@AboutProgramming
Напишіть щось складне на фукц. мові.
Нажаль, тут я не експерт
Я новачок, відносний, світчер, 2 роки у веб-розробці. Як думаєте, чи є сенс прокачувати себе у згаданих пунктах, якщо є такі штуки як ChatGPT? Вангують, що вони скоро самостійно будуть писати програми)
ChatGPT може згенерувати трохи коду, але хто користувач цього кода? - програмісти 🙂 Це як шуроповерти, електропилки та інші електричні інструменти не замінили будівельників. Але от те, що під програміста вимагатимеься щось за тиждень, на що потрібен раніше був місяць - це досить реально)
Так що ж там з храмом, це він сам чи делегує?
З яким храмом?
@@AboutProgramming хромом, то гугл виправив, сам відправляє запит на сервер?
Я тільки вивчаю технології, дякую за контент
@@ПервыйПользователь-ю9й якраз наступне відео буде про DNS :)
ні, поняття контейнера є чітко в лінуксі, є LVM і LXC, там реалізований контейнер не просто як описова абстракція
ще ходів би додати, що докео не дав ізоляції справжньої звісно ж, її надає LXC
LXC це просто user space програма, яка спирається на певні підсистеми ядра. Так само як й докер спирається на ці самі підсистеми. Так само й деякі пакетні менеджери типу snap, flatpak спираються на ці самі підсистеми.
На рівні ядра Linux немає окремого контейнеру в якому запускається процес. Контейнер це й є наш процес, якому просто заборонили бачити інші процеси або ще щось (реалізується через namespaces) й обмежили доступ до ресурсів через cgroups. Хоча cgroups можна використовувати з будь-яким іншим процесом.
Робив детальну доповідь колись на цю тему (з демками використання namespaces, cgroups, chroot) ruclips.net/video/CgbijhDEAgs/видео.htmlsi=-Vj1E_quXCQ5MFyY
Відносно LVM, то це не про контейнери. Якщо мова про KVM, то це теж вже про повноцінну віртулізацію
@@AboutProgramming вони ж спираються не те що на підсистему ядра, а на linux namespaces, котрі і є так званими контейнерами, і namespaces якраз є на рівні ядра.
upd: бачу, зрозумів, дякую за пояснення
@@AboutProgramming я чого притягую за вуха з LVM, що типу це logical volume поверх диску, і він створює через кернел /dev/mapper поверх фізичного диску, і виходить logical volume, котрий чисто теоретично можна назватии контейнером, чи все таки теж ні і це дурниці?)
Гарний формат, але раджу змінити інтонацію
Дякую. Можливо є якійсь конкретні приклади? Типу моменти з відео де має сенс змінити інтонацію з якої й на яку. Щоб було зрозуміло де виникає проблема сприйняття
Ну й можливо в останньому відео вже краще? Бо перші відео були одним дублем, а нові вже трохи по інакшому роблю
частично не соглашусь с первым пунктом - да, конечно понимать предметную область это хорошо
но это не задача разраба, глубоко понимать как правильно должно быть по бизнесу, а как не правивльно - это должны бизнес аналитики, либо люди выполняющие эту функцию на проекте
программист должен знать как оптимально (с технической точки зрения) реализовать правильную бизнес логику
а иначе получается что у тебя программист работает за двоих, а потом ещё кто-то скажет что программист должен взять на себя часть ответственности менеджера, и т.д. и в итоге получается универсальный солдат, который может всё - не может быть так - поэтому у нас и есть разные специальности и профессии
имхо надо быть спецом в своём деле, и минимально знать соседние области (T-shape)
Програміст не має бути експертом в бізнес домені, але якщо він не буде розуміти бізнес-логіку, то він не зможе оптимально реалізувати її в коді. Наприклад, коли ми писали бухгалтерську систему, то нам приходили й постійно робили лекції по бухгалтерії, інакше ми би просто не спроектували правильні реюзабельні абстракції (й звісно ми навіть близько не стали бухгалтерами, тут так й виходить такий собі T-shape). Аналогічно приклад з чатом - недостатньо знати, що це чат, треба знати для чого й хто буде використовувати, в яких процесах й як називаються правильно з точки зору бізнес логіки суб'єкти й об'єкти та інше. Дуже гарно про це в Еванса в його DDD. Якщо ж взяти ситуацію на ринку, то в 2/3 випадків програмісти мають недостатнє рузуміння домену
З боку ще не дуже досвідченого розробника, це відео наштовхнуло на думку про тему масштабованого коду при потребі бізнесу в швидкості розробки, можливо буде цікаво висвітлити
Це цікавий аспект. Є про що розповісти. Дякую за ідею для теми!
Круто, ще більше укр контенту!
На співбесідах говорив із людьми, які писали код на java, а запустити із команд лайна програму не могли і не розуміли як.
Так, такого повно)
Якісний і корисний контент та ще й українською! Так тримати
"код який демонструє використання" вибач не зрозумів
Це про публічний API й приклад його використання для рішення задачі
@@AboutProgramming дякую за приклад! Дуже радий що знайшов твій канал
у вас невелика помилка. якщо в конторі 100 людей, це не 100 чатів. це 4950 чатів :)
+
Якщо вось так відверто, без обід, то над подачею інформації потрібно попрацювати
А що бажано змінити в контексті подачі, щоб полегшити сприйняття інформації? Це перше відео, тому впевнений, що є куди покращувати)
@@AboutProgramming Це щоб зберігався контекст без довгого переключення на щось інше та доведення думки до кінця, було просто відчуття що говорив але в моменті різко "відрубав", чисто моє особисте відчуття
@@serhiibaranovskyi9131 Зрозумів, дякую. Це недоліки мого лінивого підходу, коли пишеш одним дублем й без монтажу. Часом краще, а часом трохи гірше. Зазвичай на конфах є опорні слайди й тоді норм навіть без підготовки робити доповідь (в 90% випадків працює без проблем). Треба щось таке саме спробувати й для ютуб відео
Не "краще" ,а ""кращим""!