วีดีโอ

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

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

З одного боку так, але з іншого це як сказати білки+жири+вуглеводи=їжа. Тобто, це знання не зробить людину кухарем, хоча кухар має це знати. Хоча людина може готувати й без цього знання (як програмісти писати код). Але так, алгоритми й структури даних це важлива складова. Я би як мінімум додав ще requirements (problem definition)

@@AboutProgramming то просто цитата , вірніше назва книги Ніклауса Вірта, там хоч і на Паскалі, і трохи застаріло, але добре описані алгоритми :) Ну як фраза теж цілком заслуговує на життя, але я на 1000 % погоджуюсь що у SDLC сучасного програміста робота з доменом та верифікація та уточнення вимог, а також вміння працювати з людьми - це ключові скіли, які просто унеможливлюють якісну роботу. Requirements elicitation присвячено багато книг, я маю Карла Вігерса ( розробка вимог до програмного забезпечення), чим є досить задоволений та всім раджу до прочитання :)

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

Можливо, проблема в тому, що під час навчання студенти не до кінця розуміють важливість цих знань, бо дуже рідко суміщують роботу та навчання. Як говорив мій наставник "что нужно нам - не знаем мы, что знаем мы- не нужно нам", добре що вивчення будь чого є процесом ітеративним і щоб краще щось зрозуміти- треба повертатись знову і знову, щоб осягти все необхідне з висоти набутого досвіду та вже осмислених знань

@@vitaliivostotskyi9855 Так. Знання чипляються за інші знання й за досвід. Я помічав, як я читав якусь книгу, а потім через пару років знову ту саму книгу й знаходив в ній багато нового, бо вже більше досвіду було й відповідно інформація в книзі ставала більш релевантною й чиплялася вже на новий досвід

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

На жаль, не тільки програміста

Не розумію про зростання деревра швирину. Було б цікаво більш детальне пояснення. btree завжди збалансоване й по ідеї, після запису вже буде дуже близький перформанс при пошуку по індексу, що при послідовному, що при рандомному UUID. Для мене зрозуміло, що послідовний uuid підвищує cache hit при записі, коли індекс вже не влазить в пам'ять (оскільки потрібний блок може бути вже в кеші), а от відносно читання глибина дерева буде дуже близька за рахунок автобалансування

Але рекомендація використовувати послідовний UUID гарна, бо на запис це впливає суттуєво, коли кеш повний. Єдине, тут можуть бути нюанси від сценарій використання. Якщо це для токенів чи для генерації session id, то треба зважати на те, наскільки випадковим буде згенерованим UUID. Це впирається в кількість випадкових бітів й в те, чи генератор випадкових чисел є криптографічно безпечним

www.dbvis.com/thetable/sql-or-sequel/#:~:text=SQL%20can%20be%20pronounced%20as,(Structured%20English%20Query%20Language).

Так, на жаль, поки немає

Схоже, що ви навіть не подивилися відео. Але буду радий почути, що конкретно "максимально некоректно" й до чого тут мережева маршрутизація 😉

Дякую, що додали пункти. Раджу подивитися відео повністю, а не закривати, бо в другій половині показано на практиці, як це все працює. Але давайте по пунктам: 1. У відео я говорю про публічні мережі на прикладі мережі кафе. Тобто можна просто взяти й зловмисник може підключитися до вайфай мережі так само, як й будь-який інший клієнт кафе. 2. Не зрозумів про forward local. Це до чого? 3. Ви кажете "arp запит покаже вас і шлюз", але тут у вас плутанина, оскільки arp запит це широкомовний запит для того, щоб отримати мак адресу з айпі адреси. Тобто вже треба знати айпі адресу шлюза й мати налаштування мережі, а налаштування якраз видає dhcp сервер ще до arp запитів.

@@AboutProgramming а чим відрізняється "відкритий wifi" від "закритого"? P2P не працює, FWD to Local також. Як при такому налаштуванні Ви пропхнете ваш броадкаст? Куда ви його будете посилати в шлюз?

@@АнПл Я про публічний вайфай в кафе говорю, до якого може підключитися будь-який клієнт кафе (але він може бути відкритим чи за паролем, без різниці). Відносно механізмів захисту, то професійний адмін зможе налаштувати правильно мережу в кафе, але це стається дуже дуже рідко. Можете розкрити до чого тут arp й мережева маршрутизація? Й що "максимально некоректно" в відео?

​@@AboutProgrammingнавіть самі примітивні роутери зараз вміють 2 мережі: 1. локальна мережа - основна 2. гостьова мережа - вона як правило і є мережею для клієнтів, ця мережа на всіх роутерах, крім ну зовсім китайского китаю з ізольованими клієнтами без доступа до мережі та один до одного. Як буде працювати бродкаст в такому разі? Те що ви описуєте було актуально 10-15 років назад. P.s. Про арп я написав, вказуючи на те, що в гостьовій мережі (читайте мережі для клієнтів) НІКОГО не буде поряд, Ви ІЗОЛЬОВАНІ від всього крім шлюзу і це реалізовано галочками в налаштуваннях і ті як правило по замовченню зняті і якщо відкрити розширені налаштування, тоді їх можна поставити, туди люди з слабкими знаннями не лізуть.

Так, проблема карти захоплення була. Купив вже нову

Ну, половину справи я зробив - зацікавив. Залишатися друга половина)

Звичайний індекс може працювати, але це має бути ще один індекс по reverse(column) ну й відповідно треба робити reverse на запит. Відносно зворотнього сортування, то можна зробити через desc в описі індексу, але це не про перевертання строк й відповідно не допоможе для цього кейсу

@@AboutProgramming ну я саме про це і питав, що той індекс який в нас створений на поле name він не працює для такого запиту (зворотнім сортуванням назвав саме сортування по реверсу), просто з відео чогось зрозумів, що він має працювати і що не можна шукати лише по %word%. Тепер зрозумів, що треба створити інший індекс для цього.

Ще такий нюанс, я ото вчора вас слухав і щось в мене в голові був якийсь смутний спогад, що це не так для мускуля (тобто не зберігається pk в індексах). Сьогодні до мені дійшло чого так. Те що Ви розповідаєте стосується innodb, а в нас до сих пір myisam :) на production, і ось там воно в індексах не зберігає pk, якщо пам'ять мене не підводить..

Так, все вірно, це innodb, він зараз по дефолту. myisam я зараз практично не використовую) без транзакцій, блокування всієї таблиці при записі, немає підтримки foreign keys, кораптиться значно частіше. Цікаво чому myisam обрали для себе?

@@AboutProgramming ну обирали ще до мене в 2010-му :) бо тоді щось був у хлопців поганий досвід з innodb, продукт старенький, поміняти рушій все руки не доходять (таблички великі, їх багато, конвертація на декілька днів, а сервіс тушити не хочеться та й зламати теж), так і живемо До речі, взагалі жодного разу не кораптнулось за 14 років, а ось повний лок таблиць це так, є така проблема

Здається, що myisam було тоді ще дефолтом в MySQL, хоча я на innodb ще з 2007)

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

Про випадкові та псевдовипадкові числа: Числа згенеровані math.random() не можна використовувати для шифрування не тому, що вони псевдовипадкові. В псевдовипадкових числах загалом немає нічого поганого, і більшість криптографічних ключів в сучасних системах згенеровані саме з *псевдовипадкових* чисел. Чому ж їх називають *псевдо*-випадковими? Створення випадкових чисел - насправді дуже глибока тема, але спробуємо спростити. Справді випадкові числа (True Random Numbers) - це числа які жодним чином неможливо передбачити і які не відповідають жодному закону чи алгоритму. Скільки б випадкових бітів ви не отримували, ви ніколи не зможете передбачити наступний біт, або віднайти біти що передували їм. Зазвичай такі числа можна отримати лише шляхом спостереження недетермінованих хаотичних фізичних процесів (як Cloudflare це робить з лавалампами: www.cloudflare.com/learning/ssl/lava-lamp-encryption ). Але по-перше, для генерування таких чисел потрібне спеціалізоване апаратне забезпечення, по-друге - інколи нам *потрібно* мати змогу відновити послідовність або детерміновано згенерувати її (інакше для узгодження ключів нам завжди доводилося б передавати розмір ключів що дорівнює розміру повідомлення!). Для цього використовуються *криптографічно стійкі генератори псевдовипадкових чисел* і їх задача - згенерувати числа детермінованим алгоритмом, проте які б в практичному застосуванні ніяк не відрізнялись би від справді випадкових (indistinguishable from true random). Вони не є справді випадковими (бо згенеровані за певним алгоритмом), але виглядають випадковими за всіма ознаками які ми можемо спостерігати, тому вони "псевдовипадкові". Для якісних псевдовипадкових чисел ми так само не можемо ні передбачити майбутні згенеровані числа, ні відновити попередні, скільки б згенерованих чисел ми не спостерігали (лише в практичному сенсі; теоретично для псевдовипадкових чисел насправді завжди є певна кількість, отримавши яку ми змогли б передбачити наступні, та про це далі). Але є одне "але" - звичайно ж псевдовипадкові числа мають якось відрізнятись від "трушних" випадкових, інакше ми б не називали їх "псевдо"-випадковими. І ця відмінність - наявність скінченного періода. Коли ми спостерігаємо за непередбачуваним фізичним процесом - отримані (true) випадкові числа НІКОЛИ не повторяться. Але генератор *псевдо*-випадкових чисел завжди рано чи пізно почне повторювати згенеровану послідовність. Кожний генератор випадкових чисел починає роботу з якогось початкового значення (seed) і теоретичний максимум періоду напряму залежить від нього: для початкового значення розміром в n біт максимальний період згенерованої послідовності буде 2^n, після цього послідовність гарантовано повториться. Цим і відрізняються псевдовипадкові числа від "справді" випадкових. Звичайно для криптографічних застосувань нам потрібно мати великий період щоб впевнитись, що на практиці згенеровані псевдовипадкові числа не повторювались.
 Але що ж тоді не так з math.random() та іншими генераторами випадкових чисел що не є криптографічно стійкими? Такі генератори зазвичай забезпечують лише одну єдину властивість випадкових чисел - рівномірний розподіл. І цього вистачає для більшості застосувань, як то симуляції чи неазартні ігри. Проте такі генератори часто є лінійними, і отримавши певну кількість згенерованих ними чисел ви зможете передбачити всі майбутні та відновити минулі числа, згенеровані з даного початкового значення. Наприклад у випадку генератора Mersenne Twister достатньо отримати 624 значення щоб зуміти передбачити усі наступні згенеровані числа. Також мушу виправити, що ChaCha20 розробив все ж не Google, а незалежний криптограф Деніел Бернштейн. Можливо малося на увазі що Google його застосовує :) Проте цей шифр один з двох, що підтримується в TLS 1.3, тож користується ним насправді багато хто :) Для розробників яким цікаво більше дізнатися про криптографію рекомендую книгу "Serious Cryptography" " від Жана Аумассона, якраз нещодавно вийшла оновлена друга редакція: nostarch.com/serious-cryptography-2nd-edition

Коментар - топ! Дякую! Так, коли вже виклав відео, то спробував реалізувати руками RSA алгоритм на невеликих простих числах. Так, операції комутативні й основна частина публічного ключа це N й цей модуль однаковий для операцій в обидві сторони. Тобто на практиці його не можна зробити приватним. Тобто матиматично операції шифруваня й розшифрування відбувається однаково (тільки в одному випадку e, в другому d), але зробити d публічним не вийде, бо вся складність взлому впирається не в "е" (яка є стандартизованою екпонентою), а в розкладі N на множникі p та q

@@rkiyanchuk Коментар про випадкові числа просто краса. Ніколи не думав про скічненність послідовності. Думав, що все впирається в генератор (чи можна по послідовності передбачити наступні числа) й криптографічний сід, що джерелом має бути справжеє випадкове число, що базується на якомусь зовнішньому інпуті (з фізичного світу). Відносно ChaCha20, це я наплутав. Можливо через RFC 7539, який від Гугла, й здається Гугл займався додаванням ChaCha20 в OpenSSL. Запінив коментар, має бути корисно для всіх глядачів цього відео. Круті коментарі! Дуже дякую за виправлення та доповнення!

Саме так, і тут ми логічно підходимо до загрози квантового компʼютера 😉😄

Був в NLTK наскільки пам'ятаю для англійської. Для української не пам'ятаю чи є щось (стемери точно є), для російської є mystem, який працює по морфологічним правилам. Але я так давно дивився на них, що й не пам'ятаю. В більшості випадків стемер підходить

@@AboutProgramming а є щось подивитись як для української мови стеммер зробити? Хотілось наш пошук на сайті покращити в рази. Використовуємо базу постгрес. Бо в нас пошук по назві документу і по вмісту документу. Був би дуже вдячний. Або почитати як самому його зробити

@@oleksiymiyskiy4694 знаходив таке github.com/amakukha/stemmers_ukrainian , але щоб конкретне порадити, то складно. Якщо потрібен просто пошук, то ніби є під еластік готове www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-ukrainian.html

Дякую за відгук. Радий, що вийшло корисно)

А що саме деза? Що я не криптограф чи базові концепції криптографії?) Я просто працюю з криптографію зі сторони програмної інженерії й інформаційної безпеки, ніж як криптограф математик. Але уявив собі, як можна було б з бабцями біля під'їзду робити влог для Ютубу)) Відносно мого попереднього досвіду, то трохи тут було th-cam.com/video/JE7mzAVm5bk/w-d-xo.htmlsi=QL9fuJ4bh_NpGktx

@@AboutProgramming добре прийнято,якщо шо,то я вибачаюсь...

Дякую за відгук. Відносно розбірливості, то це прям мій баг. Але я працюю на цим)

А з розумінням чого саме виникають складнощі? Можливо є конкретно якісь аспекти, де було незрозуміло?

В яку саме?

Публічний ключ шифрує, а приватний разшифровує - в іншу сторону не працює

Не зовсім так. Аби шифрували тільки публічними ключем, тоді не працював би цифровий підпис, бо будь-хто його змін би підробити (оскільки всі мають публічний ключ)

@@AboutProgramming Ага, там трошки інакше, у кожного свій приклад просто в голові з'явився У випадку з цифровим підписом приватний ключ використовується для підпису (шифрування хешу), а публічний ключ - для його розшифрування. У передачі даних (наприклад, через HTTPS) асиметричне шифрування використовується дещо по-іншому: Публічний ключ використовується для шифрування даних, Приватний ключ використовується для розшифрування цих даних

Не зовсім так. В https публічний ключ для шифрування даних не використовується, дані шифруються симетричними ключем AES або Chacha20. Раніше публічним ключем шифрували симетричний ключ, але зараз такого теж не роблять, бо це не дає perfect forward secrecy. Тому зараз DHKE для обміну симетричним ключем це стандарт в HTTPS. А от в PGP симетричний ключ шифрується публічним, але самі дані теж шифруються симетричним

Це відео знімав на Fuji X-E4 + об'єктив XC 15-45mm. Всі відео з минулого року робив на iPhone. Фон зробив через зелений екран