Pull to refresh
22
0
Денис @devlato

Software Engineer

Send message

Как насчёт написания мелкого аллигатора и использования placement new на статически выделенном массиве?

Вообще кажется, что Л. следовал API гайдлайнам, принятым у них на проекте для бэкенда, поэтому и переписал говнокод автора, заодно выбросив неправильно использованные HTTP коды. Автор статьи просто докопался до Л., потому что испытывал личную неприязнь к Л. на почве расизма, и вообще выглядит полным дурачком, а не взрослым адекватным разработчиком. В этой истории автор выглядит антигероем, если честно.

Спасибо за классную статью, Гусейн! Написано прекрасно и очень наглядно

Увидев заголовок про масштабирование, как-то ожидал увидеть что-то поинтереснее, чем пару параграфов по базовым возможностям языка

Как нанять 50 синьоров за 43 дня

Видимо, нанять 50 мидлов и джунов и назвать их синьорами

Автор не шарит в юнит-тестировании и доказывает свою точку зрения на примере завязанного на лапшу говнокода. Если юнит-тестирование делается правильно, то оно прекрасно работает, в том числе позволяя улучшать архитектуру кода и упрощать развязывать зависимости при сохранении адекватных публичных интерфейсов, и почти не требует поддержки. Или, конечно же, можно и дальше писать говнокод, придумывать отмазки и жаловаться, что на него сложно писать юнит-тесты.

We have a new teacher. They will come tomorrow.

«They» — это по сути замена обычных местоимений «she» и «he». То есть, таким способом отмечают человека, который определяет себя иначе чем «мужчина» или «женщина».

Неправда – просто в этом контексте пол неизвестен (и по сути, не имеет значения). Это не связано с гендерными ролями, транссекксуализмом и т.д., и встречается также и в классической литературе.
Мой мозг так сильно отличался, что человек, который его анализировал, не мог сравнить стандартные визуальные маркеры на глаз (выше привожу более техническое объяснение).
Так же пока сложно понять, что привело к таким разительным изменениям. Между сканами прошло четыре с половиной года, я значительно поменял многие аспекты жизни… перестал принимать героин.
Но я сам вижу, что преображение мозга стало следствием того, что я развил чуткость к моменту здесь и сейчас.

Нет никаких доказательств этого – чувак слез с хмурого, и эти изменения в мозге за четыре с половиной года могли произойти и без медитаций. Чел просто выдаёт свои убеждения за факты.
Эрик Эллиот часто пишет очень спорные и иногда абсурдные, категоричные, а то и даже глупые вещи под видом непреложной истины

Перевод местами, конечно, адовый!


Проблема состоит в том, что TypeScript с жадностью ищет файлы .ts и пытается включить их в данную компиляцию.

Тайпскрипт с жадностью ищет! Вот жадина-то! :)
Может, всё-таки "жадно"? Всё-таки же имеется в виду жадный алгоритм.

Композиция функций в функциональных языках — это бинарный оператор на множестве функций. Т.е. он также порождает функцию.
Пусть 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 статически типизированный язык.

Считаю, что алгоритмы знать полезно и решать такие задачи нужно уметь, но после прочтения статьи возник вопрос — зачем человеку, который всё это знает, идти в типичную шарагу шлёпать формы? Иными словами, имеет смысл всё это спрашивать, если компания может предложить задачи, которые заинтересуют такого человека, иначе он же отупеет к херам или уйдёт.

Вот во втором халф-лайфе вроде уже слаженно действовали, т.е был некий общий AI, управляющий врагами.
Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.

Это очень странно, поскольку по-хорошему надо бы делить разработчиков на команды с областью ответственности за определённые проекты/проект/части проекта, да и у «менеджеров», как вы их тут назвали, должно быть то же самое – каждый должен быть ответственен за какую-то часть и должен работать с определённой командой, привязанной к этой части.

у них обязательства перед заказчиками и никого не волнует занятость разработчиков

Разработчики сами по себе заняты? Или их опять-таки занимают все менеджеры подряд? Почему менеджеры не ставят перед заказчиками реальные сроки, исходящие от разработчиков?

Судя по всему, вся проблема всё-таки в гнилых эффективных говноменеджерах, которых понабрали хрен знает откуда, а не в методологии. Не нужно винить молоток в том, что строитель разбил им ваше стекло.
1

Information

Rating
Does not participate
Location
Sydney, New South Wales, Австралия
Registered
Activity