From A | Все про IT
前往频道在 Telegram
Привіт. Я Артур — Software Architect, Head of Engineering, Ph.D. Пишу про програмування, тестування, автоматизацію, архітектуру та айтішку. По питанням пишіть @ar2r_s
显示更多5 304
订阅者
+2224 小时
+167 天
+330 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
九月 '26
九月 '26
+48
在0个频道中
八月 '26
+64
在1个频道中
Get PRO
七月 '26
+125
在3个频道中
Get PRO
六月 '26
+50
在1个频道中
Get PRO
五月 '26
+100
在7个频道中
Get PRO
四月 '26
+56
在0个频道中
Get PRO
三月 '26
+94
在2个频道中
Get PRO
二月 '26
+104
在4个频道中
Get PRO
一月 '26
+78
在0个频道中
Get PRO
十二月 '25
+81
在2个频道中
Get PRO
十一月 '25
+115
在2个频道中
Get PRO
十月 '25
+87
在4个频道中
Get PRO
九月 '25
+80
在1个频道中
Get PRO
八月 '25
+105
在2个频道中
Get PRO
七月 '25
+113
在1个频道中
Get PRO
六月 '25
+67
在2个频道中
Get PRO
五月 '25
+85
在2个频道中
Get PRO
四月 '25
+151
在6个频道中
Get PRO
三月 '25
+167
在1个频道中
Get PRO
二月 '25
+172
在1个频道中
Get PRO
一月 '25
+129
在1个频道中
Get PRO
十二月 '24
+150
在6个频道中
Get PRO
十一月 '24
+274
在3个频道中
Get PRO
十月 '24
+104
在1个频道中
Get PRO
九月 '24
+96
在3个频道中
Get PRO
八月 '24
+95
在0个频道中
Get PRO
七月 '24
+163
在1个频道中
Get PRO
六月 '24
+104
在3个频道中
Get PRO
五月 '24
+169
在3个频道中
Get PRO
四月 '24
+175
在1个频道中
Get PRO
三月 '24
+177
在1个频道中
Get PRO
二月 '24
+152
在1个频道中
Get PRO
一月 '24
+173
在0个频道中
Get PRO
十二月 '23
+173
在1个频道中
Get PRO
十一月 '23
+190
在2个频道中
Get PRO
十月 '23
+187
在0个频道中
Get PRO
九月 '23
+385
在0个频道中
Get PRO
八月 '23
+64
在0个频道中
Get PRO
七月 '23
+101
在0个频道中
Get PRO
六月 '23
+107
在0个频道中
Get PRO
五月 '23
+862
在0个频道中
Get PRO
四月 '23
+134
在0个频道中
Get PRO
三月 '23
+1 306
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 05 九月 | 0 | |||
| 04 九月 | +42 | |||
| 03 九月 | +3 | |||
| 02 九月 | +1 | |||
| 01 九月 | +2 |
频道帖子
| 2 | думки про які не питали:
знаєте, з всім цим несущімся поєздом АІшки я вчора вночі помітив одну штуку яка мене дуже сильно засмутила.
стан потоку.
коли останній раз ви відчували себе у саме цьому стані потоку? памʼятаєте оце от? навіть коли АІшка була ще тіки на стадії автокомпліту, ми часто входили в стан-потоку. коли ти настільки сфокусован над задачею, рішенням, думками шо у тебе образується певний корідор зору навіть і ти під улюблену музику робив вальс з клавішами і кайфуешь від процесу...
ось цей стан покинув чат.
останній час це все перетворилось у - дав задачу, описав, чекаєш поки клавдія над нею працює 15-20-30хв і втикаєш в монік в цей час(або переключився на іншу задачу і так само втикаєш), ADHD-розробка якась, бляха. дав таск-переключвся-дав паралельний таск - переключився - дав інший таск - переключився. і в тебе в паралеллі 3-5-7 задач а мозок після 5 годин таке враження шо відпахав три зміни. тіпа сам стан потоку у тебе зараз взагалі не присутній. бо ти по суті дав шось і далі в режимі очікування стаєш. як оргазм який ось ось прийде і тут міняють тем чи зупиняються 😄 короч розробка перетворилась в якесь проксі-простітутсво де ми ублажаєм АІ.
шо з цим робити? понятно шо адаптуватись або здохнеш.
але цікаво чи це тіки в мене так чи ви теж відчуваєєте шо кайфу від такого операторства стає все менше ? | 966 |
| 3 |  👀 Linux, RTOS та Bare Metal: де використовуються, як обрати та як тестувати?
9 вересня на єТЕМІ команда SQUAD вже традиційно ділитиметься своїми знаннями та інсайтами, але вперше — офлайн у Львові!
Приєднуйтеся до мітапу, щоб:
— обговорити особливості Linux, RTOS та Bare Metal і сфери їх використання,
— визначити, коли обирати RTOS, а коли Embedded Linux,
— дізнатися, як тестувати обрану систему,
— поставити запитання спікерам і почути відповіді напряму.
📅 9 вересня, 19:00
📍 Львів, безпечний простір SQUAD
💻 Онлайн-трансляція для тих, хто не може долучитися фізично
🙌 Участь безкоштовна
Реєструйтеся на подію 👈🏻 | 1 010 |
| 4 | шановне паньство. маю 2 круті ваки для вас.
контора велика хароша денег дають багато.
• senior python backend
• senior fullstach (python+react)
маякніть в пріваточку ребюзме. мені рефералочка - вам хороша работа 🙂 | 1 204 |
| 5 |  没有文字... | 1 320 |
| 6 |  Актуальні пропозиції від UPSTARS ⭐️
UPSTARS – продуктова IT-компанія, з якою злітають і люди, і бренди. Запускаємо технологічні рішення та B2B-сервіси для міжнародних клієнтів у сфері iGaming. Бренди, які використовують наші рішення, здобувають топові галузеві премії та найвищі оцінки у профільних міжнародних рейтингах.
↳ Junior Account Farmer
↳ Middle Marketing Data Analyst
↳ Middle Atlassian Cloud Administrator
↳ Senior SEO Specialist
↳ Product Team Lead
Ждем твій відгук. Або зроби репост другу, який ідеально сюди метчиться 😉
Більше відкритих ролей – за посиланням або Career bot
Talent Network | Career | Карʼєрний сайт | 1 400 |
| 7 |  WAWTech повертається!
26-27 листопада DOU організовує другу конференцію для 5000 айтівців у Варшаві!
🔥 50+ спікерів з Netflix, Zendesk, Superhuman, Agoda та ще багато інших!
⚡ 4 сцени, 6 технічних треків
🛠️ Зона воркшопів
🤝 Job Speed Dating
👥 Окремий день мітапів
🎉 Afterparty та багато нетворкінгу
Попереду ще багато гучних анонсів!
📍Варшава, EXPO XXI
Забирайте квиток за найнижчою ціною — від €78: https://dou.ua/goto/wawtech26
ДОРЕЧІ ЗАВТРА (1 вересня) ціна підіймається
Побачимось на конфі <3 | 1 281 |
| 8 | Підписники стало цікаво от. Зараз про АІшку талдичуть з усіх кутків у контексті розробки. Але я шось мало чую про АІшку у машинах.
Уявіть шо у вас є авто вашої мрії. Які б АІ фічі ви б хотіли в ній мати. Цікаво послухати почитати б було. Го в коментарі 🙂 | 1 447 |
| 9 |  Простими словами про патерни. Сьогодні про Claim Check.
На вокзалі здаєш важку валізу у сховище а натомість береш крихітний номерок - і гасаєш по місте без вантажу. Claim Check - той самий номерок: важкі дані лежать у сховищі, а листом їде лише малесенький ключ.
Велике тіло повідомлення (файл, зображення, важкий JSON) впирається в ліміти брокера й гальмує його. Тягати таке через чергу - погана ідея.
Рішення: кладемо навантаження в зовнішнє сховище (S3, БД), а в повідомлення лише "квиток", тобто ключ-посилання. Отримувач за потреби "виколупує" дані за ключем. Через брокер їде тільки малий ключ.
• великі дані рухаються повз брокер
• малі повідомлення - вищий throughput
• дані тягнемо лише коли вони справді потрібні
• сховище чистимо за TTL
#мікросервіси #архітектура #systemdesign #microservices #патерни | 1 675 |
| 10 |  З Днем Незалежності України! 🇺🇦
Нехай наша країна має надійну архітектуру, де фундамент - це свобода, гідність і єдність, а кожен українець - важливий компонент великої системи.
Щоб майбутнє України ми програмували власноруч - без багів, чужих залежностей і deprecated-рішень. Щоб усі виклики проходили unit, integration та stress testing, а незалежність завжди мала статус Passed ✅
Нехай наш спільний код буде чистим, архітектура стійкою, тести зеленими, а головний реліз - Перемога та мирна, сильна Україна - успішно вийде в production! 💙💛
Слава Україні! 🇺🇦 | 1 628 |
| 11 |  Простими словами про патерни. Сьогодні про Dead Letter Queue (DLQ).
У тебе є дублікат ключа. Намагаєшся відкрити двері а воно все не відкриває - і так і сяк а воно не піддається. Кидаєш цей ключ в коробку "розберуся потім" і спокійно відкриваєш іншим який відкривав до цього, щоб не застрягнути в проході. Dead Letter Queue - та сама коробка для повідомлень, які вперто не обробляються.
«Галіме» (poison) повідомлення - з поганими даними чи стійкою помилкою - падає раз за разом. Воно не має ні блокувати чергу, ні губитися.
Рішення: даємо повідомленню обмежену кількість спроб (retry). Вичерпали - перекладаємо його в окрему чергу, Dead Letter Queue. Основна черга рухається далі, а "мертве" повідомлення збережене для розбору й повторного оброблення.
• обмежені retry, далі - у DLQ
• основна черга не блокується
• проблема лишається видимою для аналізу
• повтор із DLQ має бути ідемпотентним
DLQ без моніторингу - це смітник, тому думаємо про алертінг.
#мікросервіси #архітектура #systemdesign #microservices | 1 727 |
| 12 |  🟣 Цікаві пропозиції від UPSTARS 🟣
UPSTARS – продуктова IT-компанія, з якою злітають і люди, і бренди. Команда створює технологічні рішення та B2B-сервіси для міжнародних клієнтів.
Ваша наступна роль може починатися з цього допису:
🔸 Senior Backend Developer
🔸 Senior Security Engineer (SecOps)
🔸 Senior Ruby Engineer
🔸 SRE Team Lead (GameDev)
🔸 Senior Site Reliability Engineer
Відчуваєш метч? Нумо знайомитися ✨
Talent Network | Career | Карʼєрний сайт | 1 635 |
| 13 |  Простими словами про патерни. Сьогодні про Service Discovery.
В онлайн-грі список кентів показує, хто зараз онлайн - хтось зайшов, вийшов, список оновлюється сам. Service Discovery - такий же живий реєстр: знає, які сервіси працюють і за якою адресою.
У хмарі чи кубіку адреси сервісів(IP/порт) постійно змінюються - сервіси стартують, падають, масштабуються. Статичний список адрес не варік: клієнт має щоразу знайти живий екземпляр.
Робимо реєстр сервісів - живу базу екземплярів та їх адрес. Екземпляри реєструються самі і шлють heartbeat-и; реєстр кікає мертвих. Клієнт питає реєстр і дістає лише здорові екземпляриі і балансує між ними.
Тіки-но з'являються нові репліки, клієнти бачать їх автоматично, без зміни конфігурації. Існує два стилі:
• client-side - клієнт запитує реєстр і балансує;
• server-side - за нього це робить балансувальник або DNS.
Реєстр - критична інфраструктура: без HA(хай евейлабіліті) його падіння зупиняє все виявлення. | 2 122 |
| 14 | Ітак откриваю нову рубріку : айтішні кошмари. Сьогодні наснилось шо здаю екзамен по структурам даних і жостка фейлю на самих тупих питаннях.
А чи снились вам айтішні кошмари? Цікаво стало | 1 968 |
| 15 |  Простими словами про патерни. Сьогодні про API Gateway.
Заходиш у лікарню - не бігаєш сотнею кабінетів, а йдеш до реєстратури, і вона скеровує куди треба. API Gateway - ті самі єдині двері: клієнт стукає раз, а шлюз розкидає запит по сервісах.
Різні клієнти без АРІ гейтвею вони будуть викликати десятки дрібних сервісів. Клієнт мусить знати їхні адреси, робити купу мережевих ходів і зшивати відповіді сам.
Ставимо перед сервісами API Gateway - єдину точку входу. Він:
• маршрутизує запити до потрібних сервісів;
• агрегує кілька відповідей в одну;
• транслює протоколи (REST → gRPC);
• бере на себе: автентифікацію, TLS, ліміти, логування.
Клієнт робить один виклик - внутрішня декомпозиція лишається невидимою за стабільним контрактом. Варіант BFF: окремий шлюз під кожен тип клієнта.
Не кладемо в шлюз бізнес-логіку - стане новим монолітом. І тримаємо його stateless у N репліках: він на критичному шляху кожного запиту.
#мікросервіси #архітектура #systemdesign #microservices #apigateway #api #патерни | 2 392 |
| 16 | Мені інколи здається шо люди які пишуть спагетті код, без патернів де треба, з купою дублікатів, без думок про розширення просто таким чином виражають якийсь протест. Фізично больно таке читати прям | 2 352 |
| 17 | У мене часто вживалось слово - компенсаторна подія
Уявіть, що банк помилково зняв з вашого рахунку 30 грн: у журналі вже є подія ЗНЯТЬ_БАБЛО(30). У звичайній базі ви б просто виправили число або видалили рядок. В event sourcing так робити не можна - журнал append-only, історію не переписують. Тож помилку виправляють так само, як у бухгалтерії - дописують у кінець журналу нову подію, яка скасовує попередню. Наприклад, ПОВЕРНУТИ_БАБЛО(30) (повернення помилково знятих 30 грн). Після згортки баланс знову вірний, але в історії видно і помилку, і її виправлення - хто, коли і чому. Саме це і є компенсаторна подія: "виправлення" записане як ще один факт, а не як редагування минулого.
Це та сама ідея, що й компенсаційні транзакції в Saga - не "відкотити", а "зробити протилежну дію". | 2 374 |
| 18 | Простими словами про патерни. Сьогодні про Event Sourcing.
Інколи хотілось би відмотати час назад та деякі речі відтворити знову. Наприклад купити біткоїни. Event Sourcing — саме про це: сервіс тримає не «як зараз», а весь список подій і щоразу вираховує стан із них.
Класичне сховище зберігає лише поточний стан і затирає, як ми до нього дійшли. Історія, аудит, "а що було у минулий вівторок?" - усе втрачено назавжди.
Рішення: зберігаємо не стан, а послідовність подій, що його змінюють. Сховище подій - append-only: події незмінні, їх лише дописують. Поточний стан обчислюють, згортаючи (fold) події агрегату; Ну і для оптимізації робимо знімки (snapshots) які пришвидшують відтворення.
Події - це наше єдине джерело істини. Тож будь-яку модель для читання можна перебудувати, просто відтворивши журнал. Бонус - запити по часу: відтворити стан на будь-який момент у минулому.
"Виправлення" - це нова компенсаторна подія, а не редагування старої. І звінсо плануємо еволюцію схеми: старі події треба вміти читати завжди (версіонування/upcasting).
#мікросервіси #архітектура #systemdesign #microservices #data #eventsourcing #патерни | 2 055 |
| 19 |  які часи такі і подарунки | 2 092 |
| 20 |  Простими словами про патерни. Сьогодні про CQRS.
На екзамен ти маєш товстий зошит, де все записано ретельно і окрему шпаргалку з готовими відповідями. Шпаргалку не редагуєш напряму. CQRS це приблизно так само: одна модель для запису, окрема швидка модель для читання.
Чому? Бо одна модель даних рідко добре служить і записам, і читанням. Запис хоче нормалізації та інваріантів; читання — інколи денормалізованих форм під конкретний екран. А крос-сервісні запити через JOIN за приватними базами взагалі неможливі.
Рішення: розділити відповідальність.
- Командна сторона обробляє CUD, дотримується інваріантів і публікує події.
- Запитна сторона тримає одну чи кілька читальних моделей - денормалізованих вьюшок, зібраних із цих подій саме під потрібні запити.
Читальну модель ніколи не змінюють напряму.
Головний виграш - читання й запис масштабуються незалежно, а читальна модель відповідає навіть на крос-сервісні запити.
Оновлення асинхронне(eventual consistency): читання можуть відставати.
#патерни | 2 507 |
