Жаль мало времени смотреть ваши видео, темы очень крутые и практичные, больше нигде на ютубе не находил такого крутого контента, даже в англоязычном ютубе
37:30 array.find(e => !!e) - первым аргументом передается элемент, не индекс. Функция будет работать только в случае когда приведенное к булевому значение первого элемента будет true. В противном случае ("", 0, undefined, null, NaN, false) функция возвращает первый найденный элемент приводимый к true.
Timur Shemsedinov спасибо за отличное видео! Хотелось бы ещё узнать про Императивный и Декларативные подходы к написанию кода. Какой и когда лучше использовать один или другой. Что лучше читается и легче поддерживается.
Будут отдельные лекции про антипаттерны разных парадигм, а пока это посмотрите: ruclips.net/video/Yk1sxLVHfjs/видео.html ruclips.net/video/0JxSs_GcvbQ/видео.html
По поводу Антипаттерна "Assumptions". На самом деле код проверки допущений зашумливает код (даже если его вынести в отдельные функции). Для того, чтобы код был "почище", явной проверки допущений лучше избегать -- давая возможность приложению просто упасть. Критически важно проверять допущения, когда результат такой проверки поможет "пользователю" приложения исправить ситуацию: выбрать правильный файл, заполнить нужное поле и т.п. Реже, для отладки.
Уважаемый @Timur и Господа, о каком "курсоре" идёт речь на 1:16:32 ? Я не знаю как загуглить это понятие. Что означает "цепочка преобразований вернёт курсор". Спасибо.
Это пример кода, тут может быть любой другой способ доступа к базе, но курсоры я делал в другой лекции можно поискать по индексу лекций на гитхабе но для понимания этой темы это вообще не важно github.com/HowProgrammingWorks/Index
@@TimurShemsedinov спасибо за скорый ответ. Да, для понимания темы это не важно абсолютно. Просто это моя дотошность к целостному пониманию всего и вся. :) Мне просто непонятно является ли слово "курсор" тем же словом "вывод" или "результат" например. Может это какое-то математический или cs термин. Мне например понравилось наконец понять разницу между процедурой и функцией в первых ваших видео из плейлиста. Тут та же история для меня. Терминология хромает сильно.)
Тимур спасибо за видео, только вопрос по функции ```async id => await application``` , насколько я знаю это плохая практика, так как любая async функция оборачивается в Promise.resolve, получается что ми ждем результат и только потом возвращаем его, но можем просто вернуть промис который будем ожидать (await) как результат функции ...
Да, спасибо, вы в правильном направлении сделали замечание, но у меня есть уточнения. Если мы пишем const fn = async id => await promiseReturning('arg1', 'arg2', id); то это лучше переписать как const fn = id => promiseReturning('arg1', 'arg2', id); или даже const fn = promiseReturning.bind(null, 'arg1', 'arg2'); Но первая запись не приводит к вложенному разрешению промисов из-за оптимизации (это не так давно начали оптимизировать), т.е. const fn = async id => await ... нам нужен только для того, чтобы функция была AsyncFunction а не Function (это может быть требованием контракта, предъявляемыми другими частями программы к интерфейсу экспортируемой функции). В данном случае можно конечно написать async без await, вот так: const fn = async id => promiseReturning('arg1', 'arg2', id); Потому, что return из асинхронных функций все равно упаковывается в промис. Такое поведение тоже оптимизируется, это тот же промис в промисе, который заменяется на один промис. У меня в коде, на самом деле, это осталось от того кода, когда у нас в функции несколько последовательных асинхронных операции, а значит нужны await, я его просто сократил и забыл убрать await.
Есть мнение, что, если в функцию передается больше 3-х аргументов, то это плохо читаемо, можно ошибиться с порядком передачи аргументов и так далее, нужно их передавать через {arg1, arg2, arg3....}. Насколько это правильное мнение?
Не согласен, с примером антипаттерна "серебряная пуля", а именно что "циклом прогнать" в 5 строчек более читаемо или производительнее, чем через split или через регулярные выражения. (P.S. Вроде проверил, и через циклы медленнее вышло) Выглядит аккуратно и понятно: const getWordCount = (str) => str.split(' ').length; // не работает с лишними пробелами const getWordCount = (str) => str.match(/\w+/g).length; // не работает с кириллицей const getWordCount = (str) => str.match(/[а-яА-ЯёЁ\w]+/g).length; // работает
@@TimurShemsedinov я не к тому, что "ай-ай-ай". Я тоже очень долго говорил "паш" (вместо "пуш"). Просто, если не смотреть на экран, можно утратить линию разговора ;)
В примерах были обработчики, это не мидлвары, сргласен, но и контроллепами их называть нельзя. Паттерн контроллер должен реализовывать единую точку входа.
00:00:00 Введение
00:01:32 Плохое наименование (bad names)
00:10:31 Магические штуки (magic things)
00:20:13 Жесткое кодирование (hard-code)
00:26:42 Дубликаты (dublicate)
00:29:49 Непонятный код (cryptic code)
00:32:42 Копирование кода (copy-paste)
00:39:13 Допустимый код (improbability)
00:43:05 Защита от дурака (foolproof)
00:48:59 Плохо спроектированный код (spaghetti code)
00:54:04 Комментарии (comments)
00:58:20 Серебренная пуля (silver-bullet)
01:02:17 Синдром неприятия чужой разработки (not invented here)
01:08:39 Сильная сложность (complexity)
01:20:04 Заключение
Слушал когда лежал в психушке, просто бомба для ума
Жаль мало времени смотреть ваши видео, темы очень крутые и практичные, больше нигде на ютубе не находил такого крутого контента, даже в англоязычном ютубе
Может универв видео-лекции где-то не на ютюбе выкладывают? Я не в курсе
ruclips.net/channel/UC0YHNueF-3Nh3uQT0P4YQZw
о таком знали?)
Время есть всегда. Вам, просто, лень:)
Чудова лекція, з чудовими прикладами та коментарями. Дякую!
инфа золото. конвертирует интуитивно накопленный опыт в упорядоченные знания.
и такой коммент актуален под каждым видосом из серии по основам))
, спасибо за очередную полезную лекцию !!!
Спасибо большое за знаний и опыт которым поделились!
Крута лекція, дякую! Чекаю на нові. Успіхів!
Спасибо большое за полезный материал!😃
Очень интересно, спасибо большое))
Тимур - вы лучший!!!
Замечательный урок, жаль, что я его не посмотрела, когда начинала программировать.
37:30 array.find(e => !!e) - первым аргументом передается элемент, не индекс. Функция будет работать только в случае когда приведенное к булевому значение первого элемента будет true. В противном случае ("", 0, undefined, null, NaN, false) функция возвращает первый найденный элемент приводимый к true.
Спасибо!!!
Timur Shemsedinov спасибо за отличное видео! Хотелось бы ещё узнать про Императивный и Декларативные подходы к написанию кода. Какой и когда лучше использовать один или другой. Что лучше читается и легче поддерживается.
Будут отдельные лекции про антипаттерны разных парадигм, а пока это посмотрите:
ruclips.net/video/Yk1sxLVHfjs/видео.html
ruclips.net/video/0JxSs_GcvbQ/видео.html
Thanks, useful as usual
Спасибо!
По поводу Антипаттерна "Assumptions". На самом деле код проверки допущений зашумливает код (даже если его вынести в отдельные функции).
Для того, чтобы код был "почище", явной проверки допущений лучше избегать -- давая возможность приложению просто упасть.
Критически важно проверять допущения, когда результат такой проверки поможет "пользователю" приложения исправить ситуацию: выбрать правильный файл, заполнить нужное поле и т.п. Реже, для отладки.
Тем не менее, в случае коллбека вставить строку if (err) throw err; намного лучше какого-то падения в духи split of undefined.
Анекдот для тех кому лень гуглить :
- Штурман, приборы!
- Двести.
Летят дальше.
- Бл#ть, что "двести"?!
- А что "приборы"?
(new Number(5)).valueOf(); - метод .valueOf() вернет число
Уважаемый @Timur и Господа, о каком "курсоре" идёт речь на 1:16:32 ? Я не знаю как загуглить это понятие. Что означает "цепочка преобразований вернёт курсор". Спасибо.
Это пример кода, тут может быть любой другой способ доступа к базе, но курсоры я делал в другой лекции можно поискать по индексу лекций на гитхабе но для понимания этой темы это вообще не важно github.com/HowProgrammingWorks/Index
@@TimurShemsedinov спасибо за скорый ответ. Да, для понимания темы это не важно абсолютно. Просто это моя дотошность к целостному пониманию всего и вся. :) Мне просто непонятно является ли слово "курсор" тем же словом "вывод" или "результат" например. Может это какое-то математический или cs термин. Мне например понравилось наконец понять разницу между процедурой и функцией в первых ваших видео из плейлиста. Тут та же история для меня. Терминология хромает сильно.)
@@thisnameisnotavailable вот эта лекция с курсорами, и еще где-то есть в связке с постгресом ruclips.net/video/CRcSWtWVvrA/видео.html
Тимур спасибо за видео, только вопрос по функции ```async id => await application``` , насколько я знаю это плохая практика, так как любая async функция оборачивается в Promise.resolve, получается что ми ждем результат и только потом возвращаем его, но можем просто вернуть промис который будем ожидать (await) как результат функции ...
Да, спасибо, вы в правильном направлении сделали замечание, но у меня есть уточнения. Если мы пишем const fn = async id => await promiseReturning('arg1', 'arg2', id); то это лучше переписать как const fn = id => promiseReturning('arg1', 'arg2', id); или даже const fn = promiseReturning.bind(null, 'arg1', 'arg2'); Но первая запись не приводит к вложенному разрешению промисов из-за оптимизации (это не так давно начали оптимизировать), т.е. const fn = async id => await ... нам нужен только для того, чтобы функция была AsyncFunction а не Function (это может быть требованием контракта, предъявляемыми другими частями программы к интерфейсу экспортируемой функции). В данном случае можно конечно написать async без await, вот так: const fn = async id => promiseReturning('arg1', 'arg2', id); Потому, что return из асинхронных функций все равно упаковывается в промис. Такое поведение тоже оптимизируется, это тот же промис в промисе, который заменяется на один промис. У меня в коде, на самом деле, это осталось от того кода, когда у нас в функции несколько последовательных асинхронных операции, а значит нужны await, я его просто сократил и забыл убрать await.
@@TimurShemsedinov спасибо за ответ, так и подумал.
Есть мнение, что, если в функцию передается больше 3-х аргументов, то это плохо читаемо, можно ошибиться с порядком передачи аргументов и так далее, нужно их передавать через {arg1, arg2, arg3....}. Насколько это правильное мнение?
Не согласен, с примером антипаттерна "серебряная пуля", а именно что "циклом прогнать" в 5 строчек более читаемо или производительнее, чем через split или через регулярные выражения. (P.S. Вроде проверил, и через циклы медленнее вышло)
Выглядит аккуратно и понятно:
const getWordCount = (str) => str.split(' ').length;
// не работает с лишними пробелами
const getWordCount = (str) => str.match(/\w+/g).length;
// не работает с кириллицей
const getWordCount = (str) => str.match(/[а-яА-ЯёЁ\w]+/g).length;
// работает
Интересно, вот такие приемы это не какой-нибудь антипатерн?
!0 -> true
!!0 -> false
Array.prototype.find = function find(item, index, array) {...};
Ну какой "Инкладс"? ) includes читается, как "инкльудс"
Ай кен спик эни лангваге бикоз ай юз гугле транслейт
@@TimurShemsedinov я не к тому, что "ай-ай-ай". Я тоже очень долго говорил "паш" (вместо "пуш"). Просто, если не смотреть на экран, можно утратить линию разговора ;)
Про мидллвары. В примерах были контроллеры, а не миддлвары.
В примерах были обработчики, это не мидлвары, сргласен, но и контроллепами их называть нельзя. Паттерн контроллер должен реализовывать единую точку входа.
@@TimurShemsedinov согласен, "обработчик" подходит лучше.