TypeScript web developer
  • mblog.dev: перша ітерація «українського хабра»

    Опублікував новий пост: Передача метаданих з TypeScript-коду у JavaScript-код за допомогою декораторів для Dependency Injection. Він може бути цікавим для користувачів Angular, tsyringe, InversifyJS...

  • Як покращити DOU? Пропонуйте та голосуйте за ідеї

    Є ще варіант сходити на поки що непопулярні сайти, які підтримують і Markdown, і формули, і навіть обраховують репутацію користувачів. Вони у першу чергу призначені для технічного контенту. Якщо цікаво глянути на один із таких сайтів, гляньте мої топіки.

  • Волонтери задумуються над месенджером «Дія. Канали». А ви б користувалися таким?

    Обов’язково офіційний, бо приблизно 99.99999% людей ставлять собі саме офіційний клієнт на телефон. Неофіційний клієнт, який використовує API телеграму ми тут не обговорювали.

  • Волонтери задумуються над месенджером «Дія. Канали». А ви б користувалися таким?

    О! Нібурбеков, давно з вами вже не сперичались на ДОУ. Ви мабуть можете дати лінк на офіційний репозиторій github мобільної версії для телеграм, якщо він відкритий, так же?

  • Волонтери задумуються над месенджером «Дія. Канали». А ви б користувалися таким?

    яка різниця в донесенні публічної інформації

    Ви, як програміст, мабуть же знаєте, що якщо ви ставите певну програму на свій телефон, то ця програма має доступ до цього телефону. Можна сказати що взагалі не важливо що саме декларує ця програма у якості своєї спеціалізації (робота з текстовим контентом, з музикою чи відео і т.д.). Якщо програмісти цієї програми надумають додати функції, характерні для віруса, то у них є шанс зробити це обходячи стандартні механізми дозволів на телефоні. Дірки у системі безпеки постійно з’являються, хоча старі дірки часто закриваються.

    Залишається сподіватись лише на добре ім’я тих, чиї програми ви ставите. Ви прирівняли практично розробників телеграму до розробників Дії, говорячи що немає між ними різниці. Але різниця таки є гігантська.

    Підтримав: Юра
  • Волонтери задумуються над месенджером «Дія. Канали». А ви б користувалися таким?

    Мега корисно було б надати можливість авторизуватись через OAuth 2 через API Дії. Типу того, як це робить Google Login, Facebook Login і т.д.

    Підтримав: Dmytro Kopaev
  • Волонтери задумуються над месенджером «Дія. Канали». А ви б користувалися таким?

    немає різниці, з якого джерела їх читати

    Ну да, ну да. Що ви ставите програму на свій телефон від офіційного українського виробника, що ви довіряєте росіянину, який задовільнив потреби російської влади. Какая разница?!

  • Волонтери задумуються над месенджером «Дія. Канали». А ви б користувалися таким?

    Навряд чи цікаво комусь буде читати повного аноніма. В такому разі з технічної точки зору сам анонім матиме дуже обрізані можливості редагувати, видаляти свій пост, чи шукати попередні свої повідомлення... В даному разі анонімність буде для користувачів каналів, і неанонімним для технічної системи цих каналів.

  • Вийшла нова версія Ditsmod — 2.0 (із RealWorld прикладами)

    Хм, тільки зараз звернув увагу, що по бенчмарку з апдейтами, Ditsmod + PostgreSQL є найшвидшим, причому найшвидшим серед абсолютно усіх фреймворків на TechEmpower, включаючи фреймворки на базі C, C++ і т.д.

    Композитна оцінка у Ditsmod залишається найкращою серед усіх фреймворків на базі NodeJS, випиреджаючи на 1204 балів найближчого конкурента — Hono (не знаю що воно таке, але схоже на обрізаний до мінімуму NodeJS-фреймворк).

  • У Міноборони розʼяснили, які саме дані треба буде оновити військовозобовʼязаним до 16 липня (UPD)

    Через застосунок ви оновите свої дані без черг, на відміну від походу до ТЦК. Оце і уся різниця. А ВЛК справді прийдеться проходити усім обмежено придатним. Разом з тим, на ВЛК будуть викликати не усіх одразу, а групами, скільки зможе обробляти конкретна ВЛК за день.

  • Чи варто довіряти Telegram?

  • Вийшла нова версія Ditsmod — 2.0 (із RealWorld прикладами)

    На TechEmpower оновили сервера для бенчмарків, і Ditsmod ще більше відірвався вперед відносно Fastify (який зараз вважається чи не найшвидшим фреймворком на базі NodeJS). Зараз Ditsmod на 40% швидший за Fastify по тесту «plain text» і майже на 60% швидший по тесту JSON.

    Шо ти зробиш? Прийдеться тримати пальму першості серед фреймворків на базі NodeJS =). Це, звичайно ж, мається на увазі серед повноцінних фреймворків, а не огризків, типу polkadot чи аналогів.

  • Вийшла нова версія Ditsmod — 2.0 (із RealWorld прикладами)

    Спробував використати AsyncLocalStorage для передачі контексту запиту чисто за ради експерименту, але не побачив помітних переваг. Можливо я ще глибоко не розібрався, але на скільки я зрозумів, головна вигода від використання asyncLocalStorage.run(requestContext, callback) у тому, що ми контекст запиту не передаємо явно як аргумент до middleware чи методу контролера. Разом з тим, нам все ще потрібно передавати інстанс asyncLocalStorage. Тобто ми можемо безпечно використовувати контролер-сінглтон для роботи з контекстом запиту, але нам потрібен інстанс asyncLocalStorage щоб отримати цей контекст запиту.

    Виявилось що працює цей варіант майже так само за швидко, як і варіант передачі контексту в контролер, інстанс якого створюється за кожним запитом. Тому цю фічу я не залишив. Можливо вигоду від неї можуть отримати фреймворки, які не мають Dependency Injection...

  • Вийшла нова версія Ditsmod — 2.0 (із RealWorld прикладами)

    До речі, ще забув сказати, що починаючи з v2.50, Ditsmod йде у форматі ESM, завдяки чому холодний старт «Hello, World» скоротився до 20-30 ms, а також стали доступними нативні subpath-аліаси NodeJS.

  • Вийшла нова версія Ditsmod — 2.0 (із RealWorld прикладами)

    У статистиці скачувань Ditsmod з’явилась позитивна динаміка. Його почали стабільно скачувати у середньому 40-50 разів за тиждень. Після релізів завжди кількість скачувань збільшується десь на 60 разів за тиждень для кожного релізу. Але на даний момент, останній реліз v2.51.2 був місяць назад, тобто 40-50 разів скачувань — це вже «чистими».

    На github Ditsmod вже має 66 зірочок. На даний момент я його, можна сказати, стабілізую. Тобто збільшую покриття тестами, рефакторю без breaking changes, додаю більше документації.

  • Перехід на мікросервіси: власний досвід, переваги та недоліки

    1. Якщо нема конкретного овнершіпа конкретного репозиторію (а якщо кілька команд комітять в одне репо то саме так і буде) — завжди буде бардак і кожен буде тягнутиме ковдру на себе з часто взаємовиключними цілями (бо одній тімі треба оптимізувати перфоменс, а іншій чимпошвидше релізнути новий функціонал, незважаючи на створення технічного боргу і потенційних проблем). Також неясно що робити з edge cases, коли проблема виникає не через конкретний модуль/команду, але афектить аппку загалом — ресурси на «пошук крайнього» і зайва комунікація.

    У модульному моноліті можна досягти високого рівня автономності кожного модуля, приблизно як у мікросервісів. Це означає, що розробникам інколи краще, наприклад, продублювати певний інтерфейс «низького рівня», ніж тягнути його з іншого модуля, щоб не створювати зайвої залежності. За таких умов, кожна команда відповідає строго за свій модуль, аналогічно як це відбувається з мікросервісами.

    Не знаю про який саме бардак ви кажете, наведіть конкретні приклади. Бо коли ви кажете «одній тімі треба оптимізувати перфоменс, а іншій чимпошвидше релізнути новий функціонал, незважаючи на створення технічного боргу і потенційних проблем», то не зрозуміло на якому рівні будуть проблеми. Я собі уявляю що дві команди працюють в окремих гіт-гілках і роблять мерджі в головну гілку, коли їм треба. Чому раптом виникають проблеми?

    2. Реліз процес, який вимагає погодження не лише від ПМ/ПО, а організаційно на рівень вище зажди буде гальмувати делівері фіч всім командам.

    Знову ж таки, коли команди працюють в різних гіт-гілках, ніхто нікого не блокує. Кожна команда погоджує мердж у головну гілку впливаючи на залежні модулі не більше, ніж один мікросервіс впливає на інший мікросервіс, який від нього залежить.

    3. Один пакетний менеджер на весь продукт — через кілька років девелопменту виявиться, що певний легасі модуль хоче бібліотеку 1.x.x , а команда почала девелопити новий модуль і хоче 2.х.х, який ламає легасі модуль — або витрачаєте час на рефакторінг легасі (який і так працює і рефакторінг не має жодного бізнес велю), або розробка нового компоненту починається на застарілому стеку.

    Ось це вже справді суттєвий плюс на користь мікросервісів, погоджуюсь. Але на скільки часто таке буває?

    4. Раптово в продакшені починають зявлятись проблеми з перфоменсом або непередбачувані падіння апки — додаткові ресурси на локалізацію проблемного модуля.

    Ну якщо саме апка гальмує, то ресурси для локалізації, який мікросервіс винен в цьому, також потрібні.

    5. Час онбордінгу нового колеги в девелопмент моноліта завжди буде більшим, чим онбордінг в простіший мікросервіс

    Думаю що ви це говорите в теорії, а не зі своєї практики. Я так само про мікросервіси говорю в теорії, але на усіх ресурсах, які я читав, кажуть протилежне. Тобто навпаки розібратись в моноліті значно легше, ніж у мікросервісах, якщо брати аналогічний функціонал і там, і там. Це якщо говорите за весь проект загалом. Якщо говорити про окремий мікросервіс, то окремий модуль в моноліті точно не буде складніший, бо перевага модульного моноліту якраз в тому, що окремі модулі можуть бути на стільки автономними, що їм не треба знати що робиться в інших модулях.

  • Перехід на мікросервіси: власний досвід, переваги та недоліки

    Так, я пішов поїв, і тепер бачу, що я погарячився з останньою перевагою стосовно мікросервісів =). Конфігураційні файли пакетних менеджерів можна використовувати тільки для монолітів.

    Припустимо, якщо б сьогодні був реліз v2 певного мікросервіса, який має новий інтерфейс, і разом з ним одночасно працювала v1 цього мікросервіса зі старим інтерфейсом, то залежні сервіси б не змогли використовувати стандарний конфігураційний файл пакетних менеджерів. Таки потрібен окремий механізм, який слідкує за сумісністю.

    Підтримав: Denys Poltorak
  • Перехід на мікросервіси: власний досвід, переваги та недоліки

    Інший аспект — щоб змінити інтерфейс центрального модулю в моноліті з прямими викликами треба переписати усе, що його використовує. Отут буде трешачок та конфлікти. Сервіси можуть підтримувати кілька версій інтерфейсу одночасно, і перехід поступовий.

    Так і модульний моноліт без проблем може надати різні версії певних інтерфейсів. Тобто якщо змінюється певний інтерфейс, що знаходиться в якомусь модулі, від якого залежать інші модулі, причому ці інші модулі ще не готові робити міграцію на новий інтерфейс, то вони будуть користуватись старим інтерфейсом.

    Точно так само як і мікросервіси, модулі можуть мати свої окремі версії, причому не обов’язково весь застосунок повинен змінювати версію, якщо зміна відбулась лише в окремому модулі. Щоправда в такому разі треба буде додатково придумувати якийсь механізм контролю сумісних версій різних модулів, але мікросервісам цей самий механізм також потрібний... ах, он воно що! =) Мікросерсіси тут справді мають перевагу, бо вони можуть використовувати стандартний механізм конфігураційних файлів для різних пакетних менеджерів (наприклад, npm, yarn і т.д. в разі роботи з NodeJS), які їх будуть ставити.

    Останній аспект справді має суттєву перевагу на користь мікросервісів.

    А от щодо

    перезаливати весь движок на сервері — чи навіть на машинах клієнта — бо хтось десь умовно «галочку пересунув» — не завжди файно

    то для скриптових мов це не проблема, бо вони можуть перезалити строго змінені файли.

    Підтримав: Denys Poltorak
  • Перехід на мікросервіси: власний досвід, переваги та недоліки

    Наприклад, хтось має щодня релізитись, а хтось інший потребує тиждень тестування через критичність задачі.

    Не бачу тут проблем. Різні команди працюють в різних гіт-гілках і, що найважливіше, у різних модулях, які знаходяться у різних каталогах. Потім ті, кому треба часто релізитись, роблять мердж у головну гілку, а ті, кому треба не так часто релізитись, працюють собі в окремій гілці скільки їм треба, і коли прийшов час їхнього релізу без жодних гіт-конфліктів роблять мердж у головну гілку. Гіт-конфліктів ніколи не буде, якщо різні команди працюють з різними модулями, причому їм навіть не обов’язково підтягувати зміни «чужої» команди.

  • Перехід на мікросервіси: власний досвід, переваги та недоліки

    Хоча цікавлюсь мікросервісами, і у загальних рисах знаю їхню архітектуру, але не бачу у них потреби, якщо не розробляється проект масштабу інтернет магазина Розетка. Якщо використовується модульний моноліт, то він вирішує майже усі проблеми, які можуть вирішити мікросервіси. У таких монолітах:
    1. і домени можна поділити;
    2. і багато команд можуть працювати строго над своїми модулями без гіт-конфліктів;
    3. і деплой від окремих команд проходить без проблем. Щоправда тут у мікросервісів є хоча й несуттєва, але все ж перевага, бо якщо новий код завалить процес, то упаде весь застосунок, а не окремий сервіс (не знаю як у Java + Spring, а на NodeJS таке може статись). Але якщо код тестується і ловляться помилки, то таке може статись вкрай рідко.

    Моноліт не може забезпечити хіба що написання різних сервісів на різних мовах програмування, але то теж навряд чи часто використовується, тому в такому разі можна використовувати просто декілька монолітів.

    Щодо «моноліт вижирає гігабайти пам’яті», то використовуйте моноліт на базі NodeJS, який буде споживати мегабайти а не гігабайти.

← Сtrl 123456...56 Ctrl →