ну так пользователи с едва живым 2g принесут прибыли скорее всего меньше (в десятки раз?) чем зарплата за N часов работы программистам за их работу по оптимизацию
Зря вас минусуют, ЗП это один из самых реальных способов отличить градации.
Если кто-то с вами не согласен, и считает что синьер это тот кто владеет навыками X,Y,Z…
То подумайте над ситуацией когда разработчик A владеет X,Y,Z но получает 1 000 долларов, а разработчик B не владеет X,Y,Z но получает 4 000 долларов. И как по мне в такой ситуации очевидно кто синьер, а кто нет.
Пусть вы начали писать новый проект, понадобился map по объектам, но вы не взяли лодаш, вы написали Object.values(arrayLikeObject).map
Через несколько дней вам понадобился последний элемент массива и вы написали numbers[numbers.length — 1], зачем тут лодаш?
Еще через несколько дней вам понадобился debounce, вы либо написали свой, либо поставили другую(не лодаш) библиотеку где есть debounce
Еще через несколько дней вам понадобился initial, но вы написали array.slice (и десять раз подумали не перепутали ли вы splice и slice)
Еще через пару дней вам понадобилось отфильтровать что-то из массива, и вы написали array.filter(function(value) {
return value !== filteredValue;
}) и потеряли скорость выполнения кода, ибо вам пришлось заюзать фильтр чтоб получить иммутабельность там где лодаш дает и мутабельные и иммутабельные варианты типа without, pull и так далее
Еще через какое-то время вам понадобился этот ужасный groupBy который нативным методов выглядит жутко. И воооот тут вы ставите лодаш.
А теперь вопрос, через сколько дней (или строк линий кода) в среднем наступит этот момент что лодаш уже можно ставить, и сколько человеко-часов вы потеряли в поисках как нативно сделать простые вещи типа Object.values(obj).map ?
Сколько человеко-QA-часов вы потеряете из-за того что перепутали slice и splice, или случайно мутировали данные там где не нужно, или наоборот?
Сколько времени ушло на ревью вашего самописного debounce, сколько времени для написания unit тестов для debounce (а это слегка сложнее чем обычные pure функции, изо задействовано время)
А вдруг с вашим debounce все норм, вы его используете в разных местах по проекту и получаете новую задачу, где вам нужно воспользоваться тем что в lodash debounce есть (к примеру maxTime) а в вашей ПРОСТОЙ реализации по аналогии с сайта you-dont-need- нет?
Надо ли мне ради такого кода влеплять lodash в зависимости, или его всё-таки можно самому написать, как вы считаете?
Я считаю что на любом проекте будет несколько таких "однострочников" которые лодаш заменяет лучше. Ради одного раза разумеется не стоит.
Более того, представьте что вам нужно глубокое, а не поверхностное сравнение, что тогда?
В TS IDE будет рефакторить по типам TS — так что там, да, всё будет отрефакторено правильно
окей, в любом случае лодаш позволяет, но не заставляет использовать _.map(filter, 'string'). Кому-то это нравится, кому-то нет. Где-то это удобное, где-то нет.
В случае Object.entries нам придется массив потом обратно в объект превращать, а я не уверен что для этого есть просто способ в js
Или например такие функции как intersection, take, uniq (только не надо мне скидывать ужас с [...Set()] это на конкурс ребусов по разгадке древнегреческого), countBy, groupBy, partition, sampleSize, shuffle, curry, memoize, throttle, cloneDeep, meanBy, minBy (тут конечно есть около адекватный Math.min(...arr.map(it => it.something)))
и много других функций.
Это достаточно бессмысленный сахар, который только затрудняет чтение кода, экономя максимум десяток-другой букв
Дело не в буквах, дело в том что код становится более легким для восприятия. Ну согласитесь что вот это user => user.name === 'Alex' && user.age === 12 сложнее чем {name: 'Alex', age: 12}
А что делать если интересует ключей больше? user.name === 'Alex' && user.age === 12 && user.role === 'admin && user.signinDate === someDate
против
lodash умеет работать с объектами там где js только с массивами. .map, .filter и так далее.
Современный стандарт языка делает lodash на 90% не нужным вообще
Откройте документацию лодаша и посмотрите что скорее наоборот, es6 может только 10% функций lodash реализовать в такое же количество строк. Я выделил жирным важную часть
Также лодаш "умнее / гибче" и может во многие функции принимать в качестве предиката строки, например _.filter(users, 'isActive') аналог users.filter(user => user.isActive)
Что согласитесь слегка удобнее. А еще удобнее передать туда объект
_.filter(users, {name: 'Alex', age: 12}) вместо users.filter(user => user.name === 'Alex' && user.age === 12)
Всё это очень заманчиво, но есть клинические данные, которые говорят о том, что подобные эксперименты могут быть опасны. Участки мозга, активные при фазе осознанного сна, существенно отличаются от участков мозга, активных при фазе «нормального» быстрого сна.
Хмм, кажется очевидным же, это должно быть связано с той частью мозга которая отвечает за сознание. Или я не прав, и "сознание" и при "нормальном" быстром сне активно?
Думаю, что эта область исследована отлично, и все исследования закончились на одном — вебстраница должна молчать до тех пор, пока её не попросят зазвучать
Вообще в их демо кликать чекбокс кайфово. Реально с приятным звуком это делать лучше.
Если вариант с теорвером по какой-то причине вас не устраивает, я нашел еще один способ. Цитирую вас
Важно помнить, что в этом проекте есть элементы случайности: при определении типа удара с задействованием функции randint. Неоднократно проводя тесты, я заметил, что при повторении сессий с одними и теми же входными данными топ-5 подборок может различаться. Это не очень обрадовало, и взялся решать проблему.
Подменяем это нашей функцией рандома. Фиксируем сколько раз за бой она вызывалась
(Если я правильно понимаю она будет вызываться 3 раза
1) попадание да/нет
2) скользящий да/нет
3) крит да/нет
Предположим вероятность этих событий X,Y,Z
всего у нас может быть 8 вариантов (да да да, да да нет, да нет да, да нет нет, нет да да, нет да нет, нет нет да, нет нет нет)
мы считаем урон в каждом из этих 8 случаем, а дальше суммируем этот урон по формуле в
damageForCase = damage * P(X)*P(Y)*P(Z)
Чтоб проще было осознать почему это работает можно рассмотреть упрощенную игру когда у нас только один параметр — крит в 10 процентов с уроном в 100, или обычная атака с уроном в 50
= 100 * 0.1 + 50 * 0.9 = 55
П.C.C разумеется результат подсчитаный этим способом, либо как я сказал выше через теорвер будут одинаковые, этот способ по сути перекладываем часть наших(человевеческих) расчетов на компьютер
Например когда в городах смертность уменьшилась, сразу уменьшилась и рождаемость.
положительная и отрицательная обратная связь. Никакого "чуда" или "магия" или "Никто не знает как именно работает эволюция" тут нет.
Пример отрицательной обратной связи (не факт что было именно так, это лишь пример) — уменьшилась смертность -> увеличилось население -> меньше еды / хуже условия -> не до детей сейчас.
пример положительной
уменьшилась смертность -> теперь ребенка можно родить в 18 (как раньше) плюс в 50 лет (не как раньше) -> больше детей.
положительные и отрицательные связи существуют одновременно, но с разной силой работают и скорее всего не дадут процессу упасть до нуля, или вырости до бесконечности
Работодатель предлагает зарплату, если потенциального сотрудника она не устраивает, то он и так отваливается.
Ну потому что за 3000 условных долларов в условном США будет джун, а в России синьер. И Смысл им тратить время на проверку разработчика из США если в 99% случаев это таки будет джун?
ну так пользователи с едва живым 2g принесут прибыли скорее всего меньше (в десятки раз?) чем зарплата за N часов работы программистам за их работу по оптимизацию
Я его взял с сайта you-dont-need-lodash который в самом начале этой ветки упоминался.
Спорно, увидев такое в коде мне понадобится наверное в 2-10 раз больше времени чтоб прочитать/осознать чем на _.groupBy(arr, 'length')
А уж если будет баг в функции в которой это используется внутри, то мне еще и придется потратить время чтоб дебажить внутренность этой функции
Зря вас минусуют, ЗП это один из самых реальных способов отличить градации.
Если кто-то с вами не согласен, и считает что синьер это тот кто владеет навыками X,Y,Z…
То подумайте над ситуацией когда разработчик A владеет X,Y,Z но получает 1 000 долларов, а разработчик B не владеет X,Y,Z но получает 4 000 долларов. И как по мне в такой ситуации очевидно кто синьер, а кто нет.
Пусть вы начали писать новый проект, понадобился map по объектам, но вы не взяли лодаш, вы написали Object.values(arrayLikeObject).map
Через несколько дней вам понадобился последний элемент массива и вы написали numbers[numbers.length — 1], зачем тут лодаш?
Еще через несколько дней вам понадобился debounce, вы либо написали свой, либо поставили другую(не лодаш) библиотеку где есть debounce
Еще через несколько дней вам понадобился initial, но вы написали array.slice (и десять раз подумали не перепутали ли вы splice и slice)
Еще через пару дней вам понадобилось отфильтровать что-то из массива, и вы написали array.filter(function(value) {
return value !== filteredValue;
}) и потеряли скорость выполнения кода, ибо вам пришлось заюзать фильтр чтоб получить иммутабельность там где лодаш дает и мутабельные и иммутабельные варианты типа without, pull и так далее
Еще через какое-то время вам понадобился этот ужасный groupBy который нативным методов выглядит жутко. И воооот тут вы ставите лодаш.
А теперь вопрос, через сколько дней (или строк линий кода) в среднем наступит этот момент что лодаш уже можно ставить, и сколько человеко-часов вы потеряли в поисках как нативно сделать простые вещи типа Object.values(obj).map ?
Сколько человеко-QA-часов вы потеряете из-за того что перепутали slice и splice, или случайно мутировали данные там где не нужно, или наоборот?
Сколько времени ушло на ревью вашего самописного debounce, сколько времени для написания unit тестов для debounce (а это слегка сложнее чем обычные pure функции, изо задействовано время)
А вдруг с вашим debounce все норм, вы его используете в разных местах по проекту и получаете новую задачу, где вам нужно воспользоваться тем что в lodash debounce есть (к примеру maxTime) а в вашей ПРОСТОЙ реализации по аналогии с сайта you-dont-need- нет?
Иногда действительно есть адекватные замены в несколько ПОНЯТНЫХ строк, а иногда:
Я бы на код ревью эту кашу из магических r,v,i,a,k не пропустил
Ok, boomer
Спасибо, не знал.
Но все равно, то что лодаш делает в один этап
_.mapValues(users, user => user.age)без лодаша будет делатся в три этапа, из объекта в массив, мап, из массива в объект.
Object.fromEntries(Object.entries(users).map((userKey, user) => [userKey, user.age]))согласитесь, это выглядит жутко.
Я считаю что на любом проекте будет несколько таких "однострочников" которые лодаш заменяет лучше. Ради одного раза разумеется не стоит.
Более того, представьте что вам нужно глубокое, а не поверхностное сравнение, что тогда?
окей, в любом случае лодаш позволяет, но не заставляет использовать _.map(filter, 'string'). Кому-то это нравится, кому-то нет. Где-то это удобное, где-то нет.
Или вот что насчет _.mapValues?
В случае Object.entries нам придется массив потом обратно в объект превращать, а я не уверен что для этого есть просто способ в js
Или например такие функции как intersection, take, uniq (только не надо мне скидывать ужас с [...Set()] это на конкурс ребусов по разгадке древнегреческого), countBy, groupBy, partition, sampleSize, shuffle, curry, memoize, throttle, cloneDeep, meanBy, minBy (тут конечно есть около адекватный Math.min(...arr.map(it => it.something)))
и много других функций.
Дело не в буквах, дело в том что код становится более легким для восприятия. Ну согласитесь что вот это
user => user.name === 'Alex' && user.age === 12сложнее чем{name: 'Alex', age: 12}А что делать если интересует ключей больше?
user.name === 'Alex' && user.age === 12 && user.role === 'admin && user.signinDate === someDateпротив
{name: Alex, age: 12, role: 'admin', signinDate: someDate}
Частично согласен, но разве IDE понимает что в стрелочных функциях свойства относятся к кому-то?
Я имею в виду, будет ли работать рефакторинг в IDE если у нас есть две разные сущности с одинаковым свойством
users = [{isActive: true}, ...]
accounts = [{isActive: true},...]
И где-то есть стрелочная функция которая работает с этим свойством
users.map(user => user.isActive ...)
accounts.map(account => account.isActive ...)
То если мы изменим isActive только в юзере, но не к аккаунте, разве IDE сможет изменить стрелочную фунцкию user => user.isActive ?
то есть скажем вот это
Object.values(users).filter(user => user.name === 'Alex' && user.age === 12)удобнее чем
_.filter(users, {name: 'Alex', age: 12})?
Ложь!
lodash умеет работать с объектами там где js только с массивами.
.map, .filter и так далее.
Откройте документацию лодаша и посмотрите что скорее наоборот, es6 может только 10% функций lodash реализовать в такое же количество строк. Я выделил жирным важную часть
Также лодаш "умнее / гибче" и может во многие функции принимать в качестве предиката строки, например _.filter(users, 'isActive') аналог users.filter(user => user.isActive)
Что согласитесь слегка удобнее. А еще удобнее передать туда объект
_.filter(users, {name: 'Alex', age: 12}) вместо users.filter(user => user.name === 'Alex' && user.age === 12)
Хмм, кажется очевидным же, это должно быть связано с той частью мозга которая отвечает за сознание. Или я не прав, и "сознание" и при "нормальном" быстром сне активно?
Вообще в их демо кликать чекбокс кайфово. Реально с приятным звуком это делать лучше.
Если вариант с теорвером по какой-то причине вас не устраивает, я нашел еще один способ. Цитирую вас
Подменяем это нашей функцией рандома. Фиксируем сколько раз за бой она вызывалась
(Если я правильно понимаю она будет вызываться 3 раза
1) попадание да/нет
2) скользящий да/нет
3) крит да/нет
Предположим вероятность этих событий X,Y,Z
всего у нас может быть 8 вариантов (да да да, да да нет, да нет да, да нет нет, нет да да, нет да нет, нет нет да, нет нет нет)
мы считаем урон в каждом из этих 8 случаем, а дальше суммируем этот урон по формуле в
damageForCase = damage * P(X)*P(Y)*P(Z)Чтоб проще было осознать почему это работает можно рассмотреть упрощенную игру когда у нас только один параметр — крит в 10 процентов с уроном в 100, или обычная атака с уроном в 50
П.C.C разумеется результат подсчитаный этим способом, либо как я сказал выше через теорвер будут одинаковые, этот способ по сути перекладываем часть наших(человевеческих) расчетов на компьютер
Я может чего-то не понимаю, но для всего этого достаточно применить теорвер, и не понадобится проводить кучу симуляций.
Я даже щас формулу набросаю, если не ошибаюсь это мат ожидание
Ожидания Модификатора = P(попадания) * (P(скользящий) * 0.7 + P(не скользящий) * (P(крит) * 2 + P(не крит) * 1)Ожадание финального урона = Ожидания модификатора * Урон
Где P это вероятность
А не делается ли в таком случае более громкое проговаривание he IS(!) smart?
либо небольшая пауза he is (пауза) smart ?
Но компьютер уже тоже в какой-то степени анархизм. А ноутбуки (их зарядки) потребляют ~40-100 Вт
положительная и отрицательная обратная связь. Никакого "чуда" или "магия" или "Никто не знает как именно работает эволюция" тут нет.
Пример отрицательной обратной связи (не факт что было именно так, это лишь пример) — уменьшилась смертность -> увеличилось население -> меньше еды / хуже условия -> не до детей сейчас.
пример положительной
уменьшилась смертность -> теперь ребенка можно родить в 18 (как раньше) плюс в 50 лет (не как раньше) -> больше детей.
положительные и отрицательные связи существуют одновременно, но с разной силой работают и скорее всего не дадут процессу упасть до нуля, или вырости до бесконечности
Ну потому что за 3000 условных долларов в условном США будет джун, а в России синьер. И Смысл им тратить время на проверку разработчика из США если в 99% случаев это таки будет джун?
А что, таких групп сейчас нет???
Ну разумеется, потому чтоб получить промежуточный кадр между 1 и 2 — нужно дождатся второго.