Вообще кажется, что Л. следовал API гайдлайнам, принятым у них на проекте для бэкенда, поэтому и переписал говнокод автора, заодно выбросив неправильно использованные HTTP коды. Автор статьи просто докопался до Л., потому что испытывал личную неприязнь к Л. на почве расизма, и вообще выглядит полным дурачком, а не взрослым адекватным разработчиком. В этой истории автор выглядит антигероем, если честно.
Автор не шарит в юнит-тестировании и доказывает свою точку зрения на примере завязанного на лапшу говнокода. Если юнит-тестирование делается правильно, то оно прекрасно работает, в том числе позволяя улучшать архитектуру кода и упрощать развязывать зависимости при сохранении адекватных публичных интерфейсов, и почти не требует поддержки. Или, конечно же, можно и дальше писать говнокод, придумывать отмазки и жаловаться, что на него сложно писать юнит-тесты.
«They» — это по сути замена обычных местоимений «she» и «he». То есть, таким способом отмечают человека, который определяет себя иначе чем «мужчина» или «женщина».
Неправда – просто в этом контексте пол неизвестен (и по сути, не имеет значения). Это не связано с гендерными ролями, транссекксуализмом и т.д., и встречается также и в классической литературе.
Мой мозг так сильно отличался, что человек, который его анализировал, не мог сравнить стандартные визуальные маркеры на глаз (выше привожу более техническое объяснение).
Так же пока сложно понять, что привело к таким разительным изменениям. Между сканами прошло четыре с половиной года, я значительно поменял многие аспекты жизни… перестал принимать героин.
Но я сам вижу, что преображение мозга стало следствием того, что я развил чуткость к моменту здесь и сейчас.
Нет никаких доказательств этого – чувак слез с хмурого, и эти изменения в мозге за четыре с половиной года могли произойти и без медитаций. Чел просто выдаёт свои убеждения за факты.
Композиция функций в функциональных языках — это бинарный оператор на множестве функций. Т.е. он также порождает функцию.
Пусть f и g – функции, например:
f :: Int -> Int
f x = x + 1
g :: Int -> Int
g x = x * 2
Тогда оператор композиции функций (.) порождает значение на множестве функцию, т.е. новую функцию:
g . f -- Точка — бинарный оператор, порождающий новую функцию
Это значит, мы можем объявить новую функцию, являющуюся композицией функций:
h x = g . f $ x
В итоге имеем функцию h:
h :: Int -> Int -- Объявление типа здесь для ясности
h x = g . f $ x
Вызов которой равноценен вызову g(f(x)).
Вот простой пример:
f :: Int -> Int
f x = x + 1
g :: Int -> Int
g x = x * 2
h x = g . f $ x
main = do
print (h 10) -- Печатает 22
Представьте следующий пример на TypeScript (для ясности, поскольку он типизирован):
const f = (x: number): number => x + 1;
const g = (x: number): number => x * 2;
Как бы мы могли реализовать функцию compose, чтобы она была похожа на оператор композиции функций?
// Опрередим тип для функции, принимающей параметр типа P и возвращающая результат типа R
type F<P, R> = (value: P) => R;
const compose = <P, R, O>(f1: F<R, O>, f2: F<P, R>) => (x: P): O => f1(f2(x));
// Мы можем применить эту функцию создания новой функции:
const h = compose(g, f);
h(10); // Возвращает 22
// Теперь представьте, что в языке есть оператор (.) для записи compose:
const h = g . f;
// Поскольку этот оператор определён на множестве функций и он правоассоциативен, допустимо использовать несколько функций:
const m = h . g . f;
// Это эквивалентно следующему коду:
const m = h . (g . f);
// Или следующему, если переписать с использованием функции compose:
const m = compose(h, compose(g, f));
Соответственно, отличие пайп-оператора в том, что он не возвращает новую функцию, а просто применяет функцию к параметру.
const pipe = <P, R>(x: P, f: F<P, R>): R => f(x);
pipe(10, f); // Возвращает 11
// Теперь представьте, что в языке есть оператор (|>) для записи pipe:
const result = 10 |> f;
// Поскольку этот оператор левоассоциативен, допустимо использовать его с несколькими значениями:
const result = 10 |> f |> g;
// Это эквивалентно следующему коду:
const result = (10 |> f) |> g;
// Или следующему, если переписать с использованием функции pipe:
const result = pipe(pipe(10, f), g); // Возвращает 22
Согласен. Самое убогое — невозможность переиспользовать функцию-результат, т.е. в отличие от оператора композиции функций, этот оператор не порождает новую функцию на множестве функций, а просто тупо пайпит вызовы.
Блин, при всём уважении, вся статья высосана из пальца. Автор бросается громкими словами вроде "проблемы с производительностью!!!", а по факту приведены банальные ошибки программиста, который зачем-то написал код, выполняющий последовательно вещи, которые можно делать параллельно. Проблема с забывчивостью при использовании await — не проблема синтаксической конструкции async/await, а проблема дизайна языка, которая тоже решается довольно просто — используйте TypeScript или другой компилируемый в JavaScript статически типизированный язык.
Считаю, что алгоритмы знать полезно и решать такие задачи нужно уметь, но после прочтения статьи возник вопрос — зачем человеку, который всё это знает, идти в типичную шарагу шлёпать формы? Иными словами, имеет смысл всё это спрашивать, если компания может предложить задачи, которые заинтересуют такого человека, иначе он же отупеет к херам или уйдёт.
Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Это очень странно, поскольку по-хорошему надо бы делить разработчиков на команды с областью ответственности за определённые проекты/проект/части проекта, да и у «менеджеров», как вы их тут назвали, должно быть то же самое – каждый должен быть ответственен за какую-то часть и должен работать с определённой командой, привязанной к этой части.
у них обязательства перед заказчиками и никого не волнует занятость разработчиков
Разработчики сами по себе заняты? Или их опять-таки занимают все менеджеры подряд? Почему менеджеры не ставят перед заказчиками реальные сроки, исходящие от разработчиков?
Судя по всему, вся проблема всё-таки в гнилых эффективных говноменеджерах, которых понабрали хрен знает откуда, а не в методологии. Не нужно винить молоток в том, что строитель разбил им ваше стекло.
*аллокатора
Как насчёт написания мелкого аллигатора и использования
placement new
на статически выделенном массиве?https://onlinelibrary.wiley.com/doi/10.1111/phpp.12660
https://onlinelibrary.wiley.com/doi/pdf/10.1111/dth.14740
Вообще кажется, что Л. следовал API гайдлайнам, принятым у них на проекте для бэкенда, поэтому и переписал
говнокод автора, заодно выбросив неправильно использованные HTTP коды. Автор статьи просто докопался до Л., потому что испытывал личную неприязнь к Л. на почве расизма, и вообще выглядит полным дурачком, а не взрослым адекватным разработчиком. В этой истории автор выглядит антигероем, если честно.Сработает ли картинка с таким урлом на веб-странице?
Спасибо за классную статью, Гусейн! Написано прекрасно и очень наглядно
Увидев заголовок про масштабирование, как-то ожидал увидеть что-то поинтереснее, чем пару параграфов по базовым возможностям языка
Видимо, нанять 50 мидлов и джунов и назвать их синьорами
Автор не шарит в юнит-тестировании и доказывает свою точку зрения на примере завязанного на лапшу говнокода. Если юнит-тестирование делается правильно, то оно прекрасно работает, в том числе позволяя улучшать архитектуру кода и упрощать развязывать зависимости при сохранении адекватных публичных интерфейсов, и почти не требует поддержки. Или, конечно же, можно и дальше писать говнокод, придумывать отмазки и жаловаться, что на него сложно писать юнит-тесты.
Неправда – просто в этом контексте пол неизвестен (и по сути, не имеет значения). Это не связано с гендерными ролями, транссекксуализмом и т.д., и встречается также и в классической литературе.
Нет никаких доказательств этого – чувак слез с хмурого, и эти изменения в мозге за четыре с половиной года могли произойти и без медитаций. Чел просто выдаёт свои убеждения за факты.
Перевод местами, конечно, адовый!
Тайпскрипт с жадностью ищет! Вот жадина-то! :)
Может, всё-таки "жадно"? Всё-таки же имеется в виду жадный алгоритм.
stackoverflow.com/questions/29878545/why-does-the-dot-compose-from-right-to-left-in-haskell
Пусть f и g – функции, например:
Тогда оператор композиции функций (.) порождает значение на множестве функцию, т.е. новую функцию:
Это значит, мы можем объявить новую функцию, являющуюся композицией функций:
В итоге имеем функцию h:
Вызов которой равноценен вызову g(f(x)).
Вот простой пример:
Представьте следующий пример на TypeScript (для ясности, поскольку он типизирован):
Как бы мы могли реализовать функцию compose, чтобы она была похожа на оператор композиции функций?
Соответственно, отличие пайп-оператора в том, что он не возвращает новую функцию, а просто применяет функцию к параметру.
Разница, думаю, очевидна :)
Считаю, что алгоритмы знать полезно и решать такие задачи нужно уметь, но после прочтения статьи возник вопрос — зачем человеку, который всё это знает, идти в типичную шарагу шлёпать формы? Иными словами, имеет смысл всё это спрашивать, если компания может предложить задачи, которые заинтересуют такого человека, иначе он же отупеет к херам или уйдёт.
Это очень странно, поскольку по-хорошему надо бы делить разработчиков на команды с областью ответственности за определённые проекты/проект/части проекта, да и у «менеджеров», как вы их тут назвали, должно быть то же самое – каждый должен быть ответственен за какую-то часть и должен работать с определённой командой, привязанной к этой части.
Разработчики сами по себе заняты? Или их опять-таки занимают все менеджеры подряд? Почему менеджеры не ставят перед заказчиками реальные сроки, исходящие от разработчиков?
Судя по всему, вся проблема всё-таки в гнилых эффективных говноменеджерах, которых понабрали хрен знает откуда, а не в методологии. Не нужно винить молоток в том, что строитель разбил им ваше стекло.