Давно работаем с раббитом… топлю теперь на работе за ввод кафки в некоторые процессы. В раббите мне не хватает шардинга из коробки, ну и остальные плюшки. Иногда когда все упало нужно риплей сделать, и приходится танцевать с бубном и вытаскивать данные с тяжелых хранилищ типа snowflake. А так как кафка это аппенд онли лог, восстановление системы должно стать намного легче.
Роутинга там как в кролике нет конечно нет, но думаю это можно пережить…
Так паб саб вроде же не хранит сообщения если нет консюмеров… Все таки это больше для fire and forget. Раббит же будет держать месседжи пока ваши сервисы которые возможно лежат из за бага или еще чего не поднимутся, и вы не потеряете данные.
Ну я так думаю ошибка в том, что инвалидация токена это совсем другая проблема и решается она по другому. Так что в брать роль с токена это нормально. А ваше решение возвращает нас назад к сессиям…
Practical engineer
(הנדסאי)
A practical engineer is a professional degree awarded by technological colleges in Israel and validated by the National Institute for Technological Training of the Ministry of Industry, Trade & Labor. Wikipedia.
Вместо 4х лет бакалавриата, тут за 2-3 года в зависимости от программы готовят как вы сказали «готовых рабочих для рынка». Менее престижно конечно, чем инженер, но в принципе если мозги есть то работы всем хватает. Там основной упор идет именно на практику. Вот есть язык, есть фреймоворк, делай так и так. А как оно там устроено, что такое машина тьюринга и O(n) мало кого волнует.
И хоть я 80% знаний получивший от инженерного образования вряд-ли смогу где-то применить, мой потолок роста гораздо выше чем у самоучки (кем я был до учебы) и у таких рабочих. Но, как говорится, кто то пишет калькуляторы, а кто-то компилятору. Что бы вордпресс херачить и делать хттп реквесты, совсем не обязательно учить линейную алгебру, алгоритмы, и вообще знать что такое NP-полные задачи.
Мы с 3х часов дня как белки в колесе. Вот начали немного восстанавливаться. Все вернулось минут на 30, а сейчас опять с перебоями работают. Автоскейлинга нет. Джобы бегут когда им вздумается. Или не бегут вообще.
Вот вот. Идея была хорошая потому что руби он рейлс и джанго хорошие… а вышла какашка с магией, конвенциями и мать его глобальными переменными боже спаси и сохрани… я рад что оно умерло.
Я люблю смарт тв потому что подключил к ви фи, установил нетфликс, эпл тв, картина тв ну или что еще, и не надо заказывать отдельные коробки. Удобно.
Но, UI/UX это сущий ад. Причем почти у всех брендов. Убогий браузер, перенасыщение опциями. Мой LG у меня уже год… и мне до сих пор берет 5 минут найти функцию апдейта апликации или кнопку рестарта апликации. Ну и без клавиатуры это то еще удовольствие, если реально хочешь поиском воспользоваться… а ее не так-то просто подключить.
async function fetchDogs(id) {
let result
if (typeof id === 'string') {
result = await api.fetchDogs(id)
} else if (typeof id === 'array') {
result = await Promise.all(id.map((str) => api.fetchDogs(id)))
} else {
throw new TypeError(
'callSomeApi only accepts a string or an array of strings',
)
}
return result
}
const params = { id: 'doggie123' }
let dogs
fetchDogs(params)
.then((dogs) => {
dogs = dogs
})
.catch((err) => {
if (err instanceof TypeError) {
dogs = Promise.resolve(fetchDogs(params.id))
} else {
throw err
}
})
Как я ненавижу функции которые могут принимать различные типы параметров. А тут в придачу оно еще и возвращает разные структуры. Тестировать такое просто одно удовольствие. И баги ловить когда этот код уже заюзали в десятках мест, и рефакторить… Мы такое на ревью не пропускаем. Ну сделай ты общую функцию которая работает с массивами, и оберни ее аккуратно функцией которая принимает один параметр. И чище, и без магии, и тестов меньше писать нужно.
Ну и на бэкенде далеко с этим не уедешь. Почти всегда нужно знать root cause, поэтому либо error chaining, либо копируем нужные данные с оригинальной ошибки. Ну и ошибки хттп клиентов ловим как можно раньше и оборачиваем в доменные ошибки, и обрабатываем их уже как можно позже, по возможности (как там у жавистов, кидай рано, обрабатывай поздно?).
Есть еще фишки с пробрасыванием контекста внутри ошибки, который помогают понять какой реквест был причиной (если говорим о веб сервере) или меседж (если воркер) если вдруг ошибка не обработалась и получили ексепшен.
Ну а в принципе работа с ошибками без тайп скрипта, то еще удовольствие… мы как те йожики с кактусом =)
Давно давно, после 2 лет работа с ангуляром первым, реакт был как глоток свежего воздуха. И не смотря на то что 90% времени я занимаюсь бэкендом уже долгое время, все таки открыть и подправить что то в реакте намного приятнее чем в том же ангуляре (а у нас есть легаси с первым ангуляром).
Но вот когда сам баловался с реактом на пет проджекте, я как-то огорчился при работе с формами, а конкретно чекбоксами, радио… было чувство что слишком много боилерплейта нужно писать вроде бы для простых вещей типа отмечен чекбокс или нет :/
Вот это вот переименование и замена переменных, с точки зрения фп и чистых функций, я правильно понимаю что дерево должно копироваться полностью от функции к функции? И копируется ли?
Ну у вас это жаба… у нас nodejs. Возможных настроек минимум. На пиковых нагрузках GC заметно тормозит когда создается очень много short-lived объектов. Можно конечно расти вертикально пока не упрешься в потолок или бюджет… и все же, просто игнорировать GC и другие накладные расходы в статьях про ФП это как-то не правильно.
У вас никогда не было задержек в 15-30 секунд когда gc останавливает все что бы очистить память? Задача задаче рознь. Одно дело в воркере что то делать, с этим еще можно жить. А вот в веб сервере, когда это напрочь убивает весь перформанс, уже другое.
Самое простое например у нас, это работа с календарем. 365 дней в году.
Разная метадата на каждый день, потом накидываем всякие бизнес рулы на каждый день в отдельности, вот уже память и скачет.
Нет, конечно по возможности делаем прекалькулейшен и храним где-то, но по большому счету очень много операций синхронных, когда ответ нужно дать asap, бывает один такой вот тяжелый ендпоинт не дает спать по ночам, когда алерты приходят =))
Конечно создание всегда новых объектов избавляет от неприятных багов в многопоточном программировании. Или даже в JS где один поток, можно намудрить так что объект будет изменен кем-то другим по ссылке, это как бы здорово… если бы не GC который будет забирать у вас 80% CPU тупо на очистку памяти…
А в остальном, сколько не пытаются преподнести фп как спасение от всех бед, на практике, как я вижу, используется в очень узких кругах… и в очень специфических задачах.
Я лично использую только для простенькой фильтрации или трансформации небольших объектов когда знаю что их количество ограничено числом N, и это число меня устраивает.
Роутинга там как в кролике нет конечно нет, но думаю это можно пережить…
Вместо 4х лет бакалавриата, тут за 2-3 года в зависимости от программы готовят как вы сказали «готовых рабочих для рынка». Менее престижно конечно, чем инженер, но в принципе если мозги есть то работы всем хватает. Там основной упор идет именно на практику. Вот есть язык, есть фреймоворк, делай так и так. А как оно там устроено, что такое машина тьюринга и O(n) мало кого волнует.
И хоть я 80% знаний получивший от инженерного образования вряд-ли смогу где-то применить, мой потолок роста гораздо выше чем у самоучки (кем я был до учебы) и у таких рабочих. Но, как говорится, кто то пишет калькуляторы, а кто-то компилятору. Что бы вордпресс херачить и делать хттп реквесты, совсем не обязательно учить линейную алгебру, алгоритмы, и вообще знать что такое NP-полные задачи.
И до утра еще далеко :(
Но, UI/UX это сущий ад. Причем почти у всех брендов. Убогий браузер, перенасыщение опциями. Мой LG у меня уже год… и мне до сих пор берет 5 минут найти функцию апдейта апликации или кнопку рестарта апликации. Ну и без клавиатуры это то еще удовольствие, если реально хочешь поиском воспользоваться… а ее не так-то просто подключить.
Как я ненавижу функции которые могут принимать различные типы параметров. А тут в придачу оно еще и возвращает разные структуры. Тестировать такое просто одно удовольствие. И баги ловить когда этот код уже заюзали в десятках мест, и рефакторить… Мы такое на ревью не пропускаем. Ну сделай ты общую функцию которая работает с массивами, и оберни ее аккуратно функцией которая принимает один параметр. И чище, и без магии, и тестов меньше писать нужно.
Ну и на бэкенде далеко с этим не уедешь. Почти всегда нужно знать root cause, поэтому либо error chaining, либо копируем нужные данные с оригинальной ошибки. Ну и ошибки хттп клиентов ловим как можно раньше и оборачиваем в доменные ошибки, и обрабатываем их уже как можно позже, по возможности (как там у жавистов, кидай рано, обрабатывай поздно?).
Есть еще фишки с пробрасыванием контекста внутри ошибки, который помогают понять какой реквест был причиной (если говорим о веб сервере) или меседж (если воркер) если вдруг ошибка не обработалась и получили ексепшен.
Ну а в принципе работа с ошибками без тайп скрипта, то еще удовольствие… мы как те йожики с кактусом =)
Но вот когда сам баловался с реактом на пет проджекте, я как-то огорчился при работе с формами, а конкретно чекбоксами, радио… было чувство что слишком много боилерплейта нужно писать вроде бы для простых вещей типа отмечен чекбокс или нет :/
У вас никогда не было задержек в 15-30 секунд когда gc останавливает все что бы очистить память? Задача задаче рознь. Одно дело в воркере что то делать, с этим еще можно жить. А вот в веб сервере, когда это напрочь убивает весь перформанс, уже другое.
Самое простое например у нас, это работа с календарем. 365 дней в году.
Разная метадата на каждый день, потом накидываем всякие бизнес рулы на каждый день в отдельности, вот уже память и скачет.
Нет, конечно по возможности делаем прекалькулейшен и храним где-то, но по большому счету очень много операций синхронных, когда ответ нужно дать asap, бывает один такой вот тяжелый ендпоинт не дает спать по ночам, когда алерты приходят =))
А в остальном, сколько не пытаются преподнести фп как спасение от всех бед, на практике, как я вижу, используется в очень узких кругах… и в очень специфических задачах.
Я лично использую только для простенькой фильтрации или трансформации небольших объектов когда знаю что их количество ограничено числом N, и это число меня устраивает.