Кому сорци Claude Code?
https://github.com/DonutShinobu/claude-code-fork/tree/main
https://github.com/DonutShinobu/claude-code-fork/tree/main
GitHub
GitHub - DonutShinobu/claude-code-fork: Claude Code is an agentic coding tool that lives in your terminal, understands your codebase…
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflo...
👍1😁1
Forwarded from Andrey Nikishaev
Тваринам сьогодні вже немає чого їсти. Усі поставки їжі заблоковані через величезні борги. А в притулку більше 200 хворих тварин які дивляться в очі.
Кожна гривня це додатковий шанс дожити їм до завтра. Чиєсь довольне пузіко.
Борг під 180тис грн (тільки за їжу)
Благаю вас допоможіть, трати за їх життя давно перевалил за те скільки я сам можу заробити, не кажучи вже про мої персональні борги за них, які ще дуже довго віддавати(
Розумію усім важко, але ми люди ми сильні, ми можемо терпіти багато чого, а вони як діти, повністю беззахисні.
https://uah.fund/donate
Кожна гривня це додатковий шанс дожити їм до завтра. Чиєсь довольне пузіко.
Борг під 180тис грн (тільки за їжу)
Благаю вас допоможіть, трати за їх життя давно перевалил за те скільки я сам можу заробити, не кажучи вже про мої персональні борги за них, які ще дуже довго віддавати(
Розумію усім важко, але ми люди ми сильні, ми можемо терпіти багато чого, а вони як діти, повністю беззахисні.
https://uah.fund/donate
❤4
Forwarded from Andrey Nikishaev
There are plenty of recommendations around the internet that you need to use more sugar from JS, as it makes you better developer.
But the problem, that its not. On the screen you see 2 variants A and B. A variant is "better", based on internet "experts", but its not.
Lets see rewritten versions of both with most basics operations only (just for examples its not 100% same)
Problem that variant A looks more professional, but in reality produce more problems. Both variants not ideal and have problems, but the first one not only have more of them but also hide them from viewer.
So before use any sugar - I strongly recommend to read it internal code to see how it really behave and what problems have.
#js #hiload #bugs #issues #memoryusage #speed #architecture #systemprogramming
But the problem, that its not. On the screen you see 2 variants A and B. A variant is "better", based on internet "experts", but its not.
Lets see rewritten versions of both with most basics operations only (just for examples its not 100% same)
Problem that variant A looks more professional, but in reality produce more problems. Both variants not ideal and have problems, but the first one not only have more of them but also hide them from viewer.
So before use any sugar - I strongly recommend to read it internal code to see how it really behave and what problems have.
#js #hiload #bugs #issues #memoryusage #speed #architecture #systemprogramming
👍2
Forwarded from Andrey Nikishaev
Продолжение про лимиты - про разницу алгоритмов
https://www.linkedin.com/posts/creotiv_softwarearchitecture-distributedcomputing-ugcPost-7459503773598797824-IWEw?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAPl0X4BWZSqccqAVcirdBAwe5jWKVOQ9fI
https://www.linkedin.com/posts/creotiv_softwarearchitecture-distributedcomputing-ugcPost-7459503773598797824-IWEw?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAPl0X4BWZSqccqAVcirdBAwe5jWKVOQ9fI
LinkedIn
#softwarearchitecture #distributedcomputing #k8s #rest #api #ratelimiting | Andrii Nikishaiev UA
How to make Rate Limiting correctly
Token Bucket and GCRA solve the same problem - rate limiting - but they think differently.
Token Bucket is simple: tokens refill at a fixed speed, every request spends one token. If the bucket is full, you can make a…
Token Bucket and GCRA solve the same problem - rate limiting - but they think differently.
Token Bucket is simple: tokens refill at a fixed speed, every request spends one token. If the bucket is full, you can make a…
Написал книгу на базе долгого разговора вечером. О жизни о спасении животных о нашей цивилизации в целом. Буду благодарен за рецензию
❤2👍1🔥1
Forwarded from Andrey Nikishaev
Почему в персонализации резюме нет никакого смысла.
Уверен вы долго слушали людей которые говорили противоположное, но на моей стороне математика))
Итак возьмем за условия:
1) Вероятность что резюме увидят - одинаковая для обеих случаев так как канал одинаковый
2) Вероятность заинтересовать рекрутера, если он увидел резюме. Для обычного резюме давай поставим 3%, вероятность для подготовленного резюме Х - эту вероятность мы будем трекать что бы понять при каком значении она дает результат лучше рассылки
3) Время потраченое на работу:
отправить резюме - 30сек
персонализированое резюме - возьмем разбивку 5мин, 15мин, 30мин (тестируем паралельно с вероятностью Х)
4) Цена нашего часа работы - 25$
На графиках результат 4х Стратегий. Как видим даже при затрате всего 5 мин на резюме, его эффективность должна вырасти с базовых 3% до 33%, что в реальной жизни почти нереально. Но это можно взять за базис - все что требует больше 5мин времени 100% бесполезно.
Как видими вариант просто масс рассылок - самый выигрышный. А если его еще и автоматизировать дабы не тратить 30сек то и подавно.
Что еще может улучшить - качество исходного базового резюме. Ведь даже если вы его подымите с 3% до 5% эффективности - это увеличит результативность в 1.66 раза.
ДИСКЛЕЙМЕР: Все это верно при условии если вам все-равно где работать
Уверен вы долго слушали людей которые говорили противоположное, но на моей стороне математика))
Итак возьмем за условия:
1) Вероятность что резюме увидят - одинаковая для обеих случаев так как канал одинаковый
2) Вероятность заинтересовать рекрутера, если он увидел резюме. Для обычного резюме давай поставим 3%, вероятность для подготовленного резюме Х - эту вероятность мы будем трекать что бы понять при каком значении она дает результат лучше рассылки
3) Время потраченое на работу:
отправить резюме - 30сек
персонализированое резюме - возьмем разбивку 5мин, 15мин, 30мин (тестируем паралельно с вероятностью Х)
4) Цена нашего часа работы - 25$
На графиках результат 4х Стратегий. Как видим даже при затрате всего 5 мин на резюме, его эффективность должна вырасти с базовых 3% до 33%, что в реальной жизни почти нереально. Но это можно взять за базис - все что требует больше 5мин времени 100% бесполезно.
Как видими вариант просто масс рассылок - самый выигрышный. А если его еще и автоматизировать дабы не тратить 30сек то и подавно.
Что еще может улучшить - качество исходного базового резюме. Ведь даже если вы его подымите с 3% до 5% эффективности - это увеличит результативность в 1.66 раза.
ДИСКЛЕЙМЕР: Все это верно при условии если вам все-равно где работать
👍4
Друзі це всі наші збори. На оплату притулку на сьогодні треба 17тис грн. В притулку більше 200тварин.
Якщо можете допоможіть, прошу https://send.monobank.ua/jar/5risDm5QAd
Якщо можете допоможіть, прошу https://send.monobank.ua/jar/5risDm5QAd
В истории S3 есть момент, который архитекторы иногда пересказывают как "AWS придумала новый consensus algorithm". Я бы формулировал точнее: AWS не раскрывала публично новый алгоритм уровня Raft или Paxos, но в 2020 S3 получил strong read-after-write consistency для GET, PUT и LIST без заявленного ухудшения performance и без глобальной координации. И вот инженерно это намного интереснее самого названия алгоритма. ([Amazon Web Services, Inc.][1])
Представим наивную distributed storage. Есть 3 replica, запись подтверждаем после W=2, чтение делаем с R=2. Тогда:
W + R > N
2 + 2 > 3
Кворумы обязательно пересекаются хотя бы в одной replica, поэтому можно определить актуальную версию. Но за consistency платим coordination latency: если RTT до replica 1, 3 и 12 мс, запись зависит уже не от быстрейшей машины, а минимум от второй успевшей подтвердить.
Представим наивную distributed storage. Есть 3 replica, запись подтверждаем после W=2, чтение делаем с R=2. Тогда:
W + R > N
2 + 2 > 3
Кворумы обязательно пересекаются хотя бы в одной replica, поэтому можно определить актуальную версию. Но за consistency платим coordination latency: если RTT до replica 1, 3 и 12 мс, запись зависит уже не от быстрейшей машины, а минимум от второй успевшей подтвердить.
Machine Learning World
В истории S3 есть момент, который архитекторы иногда пересказывают как "AWS придумала новый consensus algorithm". Я бы формулировал точнее: AWS не раскрывала публично новый алгоритм уровня Raft или Paxos, но в 2020 S3 получил strong read-after-write consistency…
На масштабе S3 проблема становится жестче. Нельзя просто посадить миллиарды ключей на один consensus group - leader превратится в bottleneck. Значит, coordination domain надо дробить, маршрутизацию делать локальной, а metadata и версии объектов обновлять так, чтобы независимые ключи практически не мешали друг другу.
Именно здесь архитектура выигрывает у "более быстрого алгоритма". Если миллион независимых ключей распределить между 10000 coordination groups, средняя область конкуренции уменьшается примерно:
1 000 000 / 10 000 = 100 ключей на group.
Теперь consensus остается локальным, а throughput масштабируется горизонтально.
В итоге S3 получил сильную консистентность при сохранении региональной изоляции, а приложениям больше не понадобились отдельные слои вроде S3Guard только ради согласованного представления данных. Позже conditional writes позволили еще и переносить optimistic concurrency control непосредственно в S3 вместо внешних lock-сервисов. ([Amazon Web Services, Inc.][1])
Для меня это хороший пример зрелой distributed architecture: настоящий прорыв часто не в том, чтобы придумать "Raft быстрее Raft", а в том, чтобы уменьшить область, внутри которой consensus вообще необходим.
[1]: https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/?utm_source=chatgpt.com "Amazon S3 Update – Strong Read-After-Write Consistency | AWS News Blog"
#заметкиархитектора #история
Именно здесь архитектура выигрывает у "более быстрого алгоритма". Если миллион независимых ключей распределить между 10000 coordination groups, средняя область конкуренции уменьшается примерно:
1 000 000 / 10 000 = 100 ключей на group.
Теперь consensus остается локальным, а throughput масштабируется горизонтально.
В итоге S3 получил сильную консистентность при сохранении региональной изоляции, а приложениям больше не понадобились отдельные слои вроде S3Guard только ради согласованного представления данных. Позже conditional writes позволили еще и переносить optimistic concurrency control непосредственно в S3 вместо внешних lock-сервисов. ([Amazon Web Services, Inc.][1])
Для меня это хороший пример зрелой distributed architecture: настоящий прорыв часто не в том, чтобы придумать "Raft быстрее Raft", а в том, чтобы уменьшить область, внутри которой consensus вообще необходим.
[1]: https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/?utm_source=chatgpt.com "Amazon S3 Update – Strong Read-After-Write Consistency | AWS News Blog"
#заметкиархитектора #история
Amazon
Amazon S3 Update – Strong Read-After-Write Consistency | Amazon Web Services
When we launched S3 back in 2006, I discussed its virtually unlimited capacity (“…easily store any number of blocks…”), the fact that it was designed to provide 99.99% availability, and that it offered durable storage, with data transparently stored in multiple…