Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Co-Founder в Artellence
  • Чому вам НЕ потрібен ReactiveX

    RxJavaPlugins.setErrorHandler()

    Це обробник останньої надії — глобальне налаштування — і, як наслідок, антипаттерн. Тобто, його ставити і логувати — то необхідно. Але якусь логіку туди дописувати — то дуже «таке собі» рішення.

    стабільність гнучкість та лаконічність pipeline-iв основна перевага RxJava.

    В нас, напевно, дуже різний досвід ... з мого досвіду, воно НЕ стабільне, НЕ гнучке і НЕ лаконічне :)
    Не стабільне — в тому сенсі, що легко попасти в OOM, легко зловити непотрібний unsubscribe при onError, якого «бути не могло».
    Не гнучке та не лаконічне — для роботи в режимі promise — виключно лінійний workflow. Будь-яка нелінійна логіка, робить pipeline таким, що складно читати.

    Я розумію, що оператори там круті, і, якщо робити pipeline подій, то оператори можуть «зробити магію» — і це виглядає лаконічно — тут згоден з вами. Але ж воно розвалиться на першому ж onError, який ви не чекаєте, а той самий retry розчистить всі буфери і викине дані і спрацює лише на частині pipeline-у. ... не хочу повторювати всі тези з статті :)

    -----

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

    Можливо, ви могли б поділитись своїм досвідом, коли це круто спрацювало? Можливо, у вас є свої підходи до особливостей, згаданих в статті?

  • Чому вам НЕ потрібен ReactiveX

    Як раз керує ... Немає блокуючого виклику.

    Знову ж, мова про ресурс у вигляді потоку. Я це не намагаюсь заперечити. Але стверджую, що kotlin coroutines з цим впорається значно краще. Саме в частині, що з корутинами логіка може бути нелінійною і код стає виглядати як «звичайний». Тобто ви пишете код, що дуже схожий на звичайний, а він при цьому скаче по різним pool-ам і чекає зовнішні «сигнали» в non-blocking режимі (але код виглядає так саме як і в blocking)

    Kotlin не завжди підтримує останню JVM

    Не зіштовхувався з цим, проте, якщо навіть в compile-time не використовуються останні фічі, то в runtime запускається на останній (як мінімум, проблем не пригадую з цим). Єдине що з котліном потрібно білд скрипти адаптовувати — що не зручно.

    Т. Нуркевича

    Проглянув цю книгу по діагоналі. Ви знаєте, дуже шкода, що я її не бачив тоді, коли сам з цим розбирався. Ця книга — мала б бути частиною документації :) Реально круто.

    Зверніть увагу, я НЕ кажу, що проблемою є поріг входу. Поріг входу багато де високий. Я стверджую, по суті, дві тези:
    — Rx архітектурно схильний до неочікуваної поведінки.
    — Для будь-яких випадків, де корисним може бути Rx, вже є кращі альтерантиви.

  • Чому вам НЕ потрібен ReactiveX

    переглядаючи реалізації операторів, я відкриваю для себе щось нове.

    Розумію вас ... але кожен раз, коли доводилось це робити, виникала думка: «випилювати це все треба з цього проекту, а то буде біда» :)

    легко реалізувати за допомогою Coroutines + Flows.

    Якщо я вірно зрозумів, про що ви, то тут Rx дуже погано справлявся. Звісно, закинути задачу в scheduler — це не проблема. Але тут ми натягуєм «послідовне виконання коду» на Rx. А там, де послідовне виконання, дуже швидко треба обробити помилку, дописати if, а то і взагалі цикл — і тут Rx повністю капітулює перед Coroutines.

    combineLatest + flatMap + replay + zip + debounce,

    Оператори в Rx — прекрасні, хоч і не ідеальні :) Але, як на мене, лише з точки зору ідеї.

    Rx дозволяє лаконічно реалізувати складну бізнес-логіку, таку як послідовність combineLatest + flatMap + replay + zip + debounce,

    Якщо я вірно зрозумів, це можна віднести до класу «стабільних pipeline-ів» зі статті.
    Могли б ви поділитись досвідом що ви робите з помилками? Адже все ж розвалюється при першій ж проблемі.

  • Чому вам НЕ потрібен ReactiveX

    Дві речі яуі вирішує ця технологія.

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

    1. Це підхід до ресурсів.
    2. Це конкаренсі.

    Не впевнений, що ви маєте на увазі у випадку ресурсів, адже RX ними не керує ... хіба за потоки мова, але про це ви написали другий пункт :)
    В другому ж, ... якщо я вас вірно зрозумів ... то корутини в kotlin вирішують, практично, все, що тут можна зробити, ... навіть краще. Якщо масова обробка, то overhead самого rx буде суттєвий (бачив випадки, коли overhead ArrayBlockingQueue вже суттєвий).

    Spring теж має — Reactor

    Не користувався цим ... бачу, що в основі Reactive Streams — конденсована специфікація на основі ReactiveX. Скоріше за все, там успадковані ті ж граблі.

    У Java світі, коли не було ні kotlin coroutine, ні project loom, цей Reactive Streams виглядав значно притомніше (адже альтернативи не було). Станом на сьгодні ж — то переускладнено все і не ефективне (ні по часу на розробку, ні по використанню ресурсів).

    Доречі, про сам підхід ... в певному сенсі, Netty був зроблений на схожому (з натяжкою) підході, і працює там все просто казково. Вони почали ще раніше — з 2004го: про асинхронність (у вузькому сенсі) тоді ще мало хто чув (хіба, автори epool), а Netty вже використовували ці ідеї. Використали б вони RX (хоча його тоді ще не існувало) — нічого доброго не вийшло б.

  • Чому вам НЕ потрібен ReactiveX

    Оператори — чудові — я їх перелік, інколи, використовую як «довідник ідей» :)
    Реалізація — «таке».

    Трохи дописаний код з документації:

    import { fromEvent, auditTime } from 'rxjs';
    
    const clicks = fromEvent(document, 'click');
    const result = clicks.pipe(auditTime(1000));
    result.subscribe((x) => {
      console.log(x);
      throw Error();
    });
    
    Перший клік і відписка :(
    Можливо, в js це не такий частий випадок, але exception-и трапляються.
  • Чому вам НЕ потрібен ReactiveX

    Якась сумнівна порада.

    Скоріше всього, ця порада — то дуже особисте враження. Коли я переходив з Java/Android на Flutter — це був як ковток свіжого повітря: перестаєш думати за життєвий цикл Activity, про Fragment забуваєш як про сутність, корутини інтегровані з коробки в gui thread — не треба винаходити «свою» асинхронщину, та й gui стає єдиним signle thread середовищем — як і має бути ... схопити race практично неможливо, Null Safety — окрема плюшка, тощо.

    Єдине, що якщо потрібно, дійсно, робити якийсь background compute — то трохи складніше ... але якщо хочеться, це можна і на Java написати — інтегрується досить просто ... єдине, що під iOS теж доведеться це писати на Swift.

    В контексті статті ж ... думка була в тому, що RX там впроваджувати не варто. Flutter — це одна з альтернатив. Якщо щось менш кардинальне, то як в сусідньому коментарі згадували, що Kotlin з корутинами — теж гуд.

    використовувати RX для обробки натискань на кнопку у 2023 це нездорова історія.

    Rx, взагалі, то нездорова історія ))

    Підтримав: Ihor Kozar
  • Чому вам НЕ потрібен ReactiveX

    Згоден з вами, mvvm + coroutines — це гарний підхід. По великому рахунку, той самий Flutter на цьому побудований. Та і React теж. Здавалося б ... наче близнюки фреймворки, але відчуваються вони якось зовсім по різному, наче спільного й нічого немає.

    Щодо Jetpack Compose ... я на нього не дивився, але підхід, бачу, схожий. Відносно нова штука ... я так зрозумів 2021 появились перші версії. Flutter — теж новий відносно, але появився десь 2018 року.

    Підтримали: Ihor Kozar, Dmytro Horenetskyi
  • Чи потрібно знати CS теорію для роботи?

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

    Якщо ж хочеться працювати — то працювати паралельно. Всі так роблять :) Тут проблеми немає.

    До CS можна багато чого віднести, але базові знання — must have.

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

  • Модерація Форуму: нововведення для видалених коментарів та гайд щодо топіків

  • П’ять причин, з яких вам варто використати Kotlin

    Я, власне, це і мав на увазі, що null safety — там проблема.

    Про оператори — це я про про те, що їх додати легко, і хоч null safety це не зробить, але код стане значно чистішим.

  • П’ять причин, з яких вам варто використати Kotlin

    Друге не вважаю скільки-небудь критичним.

    Я б з вами погодився ... але тут є до певної міри справа звички. Зараз якийсь час вже працюю з Dart. Там відносно нещодавно впровадили null safety схожим чином як в котліні. Міграція там була дууже масштабна (це трохи біль). Але після досвіду використання такого підходу, коли повертаєшся до проекту на Java, відсутність такого механізму «дуже чешиться».

    В цілому, я слабо собі уявляю nullable типи в Java (занадто багато міняти). З іншої сторони, не бачу жодної проблеми зробити оператори ?? та ?. — це легко зробити, і значно спростило б життя.

  • П’ять причин, з яких вам варто використати Kotlin

    Ми використовуємо kotlin на server side.

    І для цього є єдина причина: корутини.
    Це дуже велика killing feature. Яка в Java відсутня. Project Loom обіцяє альтернативу. Але це трохи інше і ще не пробували його в проектах.

    Далі я б вказав null safety, string interpolation та equals в String.

    Решта фіч теж цікаві ... але тут я б почав перераховувати недоліки.

    1. Погана підтримка java modules. Ця штука вже є з java 9. І я, якщо чесно, очікував, що всі великі важливі бібліотеки це будуть підтримувати. Не впевнений що там зараз, але коли я останній раз дивився ktor — він не працював з java modules. Чому? Хз ... напевно, тому що ліньки порефакторити і випустити для цього мажорний реліз.

    2. Той самий ktor ... давайте подивимось приклад:
    github.com/...​FileListingApplication.kt
    Подивіться стрічки 30-40 та 45-161. З моєї суб’єктивної точки зору, навіть якщо мова програмування дозволяє таке писати — то це точно антипаттерн і йому не місце в офіційних семплах. Такий стиль дуже схожий на зловживання define-ами в C, C++. Воно виглядає гарно. І можна навіть здогадатись що воно робить. Але що конкретно відбувається (в якого об’єкту і що викликається) — абсолютно не ясно. Тобто щоб зрозуміти що тут написано треба не просто знати котлін. Потрібно вивчати також «псевдомову» кожного конкретного фреймворку.

    3. Чомусь Kotlin позиціонуть як щось для розробки під Android. Це трохи дивно. Це те ж саме, що сказати, що Java — це розробка під Android )) Це я до того, що Kotlin не зав’язаний на мобілках і може використовуватись кругом де і Java.

    4. Статичні методи як companion object — це відверто дивне рішення.

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

  • Як ми переклали українською одну з найкращих у світі книжок про алгоритми

    не лише в розділі, де його введено (максимум тричі), а в усіх розділах, які його вживають?

    Так, вашу схему я б прийняв більше як «план мінімум». Ідея в тому, щоб у людини, яка хоче прочитати розділ про той чи інший алгоритм, не виникало потреби шукати термін.

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

    Хіба що з кепкуванням над рідковживаними словами не згоден

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

  • Як ми переклали українською одну з найкращих у світі книжок про алгоритми

    1. Щодо англомовних термінів ... Можливо, я вас не вірно зрозумів, але починаючи з розділу 1.1.1, у визначенні алгоритму не дається англійський термін. Чи, наприклад, на сторінці 31, insertion sort та merge sort. Якщо перша назва не є популярною (оскільки толку з того сортування немає), то merge sort — це частина професійного словника — цю назву треба знати саме англійською.

    З приводу схеми ... згоден з вами щодо не всюди. Я б до вашого підходу додав би «перше вживання терміну в розділі» або «не частіше, ніж раз на 3 сторінки».

    Причина проста: книга позиціонується не лише як посібник (який можна читати послідовно), а й як довідник (коли ти читаєш окремо якийсь розділ вибірково).

    2, 3, 4. Щодо термінології... я, чесно, розумію ваш біль ... мені як читачу легко видрати один термін і сказати «не так». Значно важче зробити несуперечливий переклад.

    Якщо я вірно вас зрозумів, то дилема з вихідний код (source code) та вихідні дані (output data vs source data). Якщо чесно, я б тут не заморочувався і залишив би вхідні/вихідні дані (input/output data) та початковий код (source code).

    Відсилка до ДСТУ — потужний аргумент ... якби я був би під час прийняття рішення, я б тут, можливо, здався і погодився. Хоча не факт, що це вірне рішення.

    Щодо останнього і в цілому ... хочу донести наступну думку ... згадайте україномовні фільми в 90-х і зараз. Ще досі пригадую як якось по телевізору щось крутили, а там діалоги такі, наче Шевченка читають. Звучало дуже не доречно, не гарно та не природньо (здається, це зараз називають «шароварщина»). На противагу цьому, зараз український дубляж часто значно кращий за оригінал. В чому різниця?

    Розумію, що в академічному світі це не може бути аж так ... але ж, напевно, можна перекласти так, щоб від читач отримував від перекладу «кайф», а не «біль». Читати то будуть студенти, а не філологи ... «fluency» тут дуже важливий аргумент до мотивації читати далі.

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

    Тобто, умовно, якщо «розроблення програмного забезпечення» в гуглі має 14200 результатів (зненацька, багато), а «розробка програмного забезпечення» 133000 (зненацька, мало), то в ДСТУ, можливо, треба зробити виняток на користь «розробка».

    Доречі, розроблювання, розробляння, розроблення — це те, що дозволяє український словотвір, але це не робить ці буквосполучення словами (привіт, фемінітиви :)). Словами вони стануть лише, якщо їх почнуть застосовувати.

  • Як ми переклали українською одну з найкращих у світі книжок про алгоритми

    Ви зробили дуже важливу роботу.
    В свій час, я цю книгу читав в 10-11 класах. І англійською, боюсь, я б її не потягнув тоді. Читав, нажаль, російською.

    Дозвольте трохи критики :)

    1. Попри все, в російській версії була дуже крута фіча: всі терміни дублювались англійським варіантом. Це дуууже зручно: вивчаєш матеріал і заодно вчиш терміни англійською.

    2. Входові/виходові дані ... краще вхідні/вихідні дані — це усталені терміни ще з часів олімпіадного руху.

    3. Розроблення алгоритмів — розробка алгоритмів

    4. Я б не старався уникати англіцизмів. Не бачу особливого сенсу використовувати «започаткування» замість «ініціалізація»
    4.1. Увипадковлені алгоритми vs рандомізовані алгоритми (хоча тут, як на мене, спірний момент ... «увипадковлені» — крутий переклад, хоч і «рандомізовані» — як на мене, усталена назва)

    Це так ... з того, що вдалося побачити з першого погляду.

    Про переклади можна вести дискусії, але більшість термінів дійсно важко перекласти усталеним способом. І, якщо ведеться робота над 4м виданням, дуже вас прошу все-таки вказувати англомовний термін при означенні.

  • Чому Україні потрібен факультет продакт-менеджерів

    Я не дуже хочу коментувати кожну тезу ... мені здається ми говорим десь про одне і те ж ... але в розрізі «склянка напівпуста чи напівповна»

    Коли ви задаєте конкретне питання (яке LTV у Netflix) і очікуєте ± конкретну відповідь в умовах невизначеності і повної відсутності інформації ... це дорівнює «накинути на вентилятор рандомних відповідей» і не залежить від освіти і досвіду кандидата.

    знання існуючих патернів вирішення певних проблем

    Стандартні підходи, розібрані реальні та гіпотетичні кейси та подібне — це, поки, єдине з ваших тез чим «крутий продакт» буде відрізнятись від «крутого Lead SE».
    Тільки от Lead SE буде більш занурений в предметну область (хоч і biased) і буде краще бачити продукт як цілісну річ.

  • Чому Україні потрібен факультет продакт-менеджерів

    — Яке LTV у Netflix ?
    — Скільки вони заробляють ? (тільки не гуглити а розрахунками)
    — Як нетфліксу підняти LTV на 30% ?

    Доречі, цікаво ... LTV — абревіатура, що має як мінімум два різних значення, що підходять в контекст цих питаннь: loan to value та lifetime value.

    Без детальних знаннь про Netflix адекватно відповісти на жодне з цих питаннь не вийде.

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

    «Як нетфліксу підняти LTV на 30» — якщо мова про lifetime value — то відповідь — ніяк :) ... інакше вони б це вже зробили б.

    .... я до того, що Lead SE, який має голову на плечах (повинен ж мати, lead ж та й engineer ж, математична освіта і все таке), відносно легко нагенерить по 2-3 відповіді на кожне питання. І наврядчи вони будуть гірші порівняно з продактом, який детально НЕ вивчав netfix ... зі звітами, статистикою, оцінкою моделей поведінки, детальними костами, тощо.

  • Чому Україні потрібен факультет продакт-менеджерів

    Юзери вам платять значно пізніше ... ці продажі ще зробити треба.

    Ваша теза має місце, коли продукт на етапі підтримки чи оновлення.

    Коли ж продукт в розробці — ви платите за роботу ... більше немає кому. Є, звісно, різні механізми інвестування, але суть це міняє не сильно.

  • Чому Україні потрібен факультет продакт-менеджерів

    якщо проще — бабки інвесторам, зарплати розробникам.

    Мені здається, що люди які первинно дивляться на гроші, приречені робити маячню.
    Гроші, витрати та способи монетизації — це важливо, але це лише один з параметрів.

    Коли ви робите аутсорс — вам платять за роботу.
    Коли ви робите продукт — ви платите за роботу.

  • Чому Україні потрібен факультет продакт-менеджерів

    Продакту не було.

    Не було людини, яка б взяла на себе персональну відповідальність за те, щоб зробити щось цінне. Це проблема. Це помилка. Так робити не треба. Але до чого тут «факультет»?

    Те, що не готують це не значить, що це не окремий серйозний напрямок.

    Можливо, в мене досить специфічний погляд на речі ... але, як на мене це не так працює.
    Коли появляється нова область знаннь, то порядок може бути приблизно такий:
    — Спочатку створюється експертне середовище — люди, які шарять і круто роблять свою роботу.
    — Потім створюються платформи для обміну досвідом. Зазвичай це конференції. Часто ініційовані компаніями чи спільнотами. По нормальному, тут мали б підключитись університети і зайнятись організацією networking-у на себе.
    — Потім появляються якісь common knowledge — перелік влучних статей, виступів, про які всі знають, на які посилаються, які обговорюють.
    — Потім появляються невеликі курси, треннінги, книги, онлайн курси, спецкурси в університетах (аля 1-2 семестрових курси)
    — Коли об’єм матеріалу переганяє за курсів так 5-10. До цього всього додаються необхідні базові предмети і організовується група у ВУЗі зі спеціалізацією.
    — Коли на цей напрям набирається стабільна група, а краще 2-3 — робиться кафедра.
    — Коли таких груп стає штук 10 — можна думати про факультет.

    Цей перелік не те щоб точний і не те щоб повний. І на цьому шляху ми ледве десь на 2-3 кроці знаходимось ... і то це не точно. Як на мене, починати з кінця — це як у вашому прикладі — коли проект є, а продукта немає.

    Спробуйте подивитись на питання створення освітнього середовища для продукт менеджерів як на проект і уявіть себе в ролі продукт менеджера цього проекту :)

← Сtrl 123456...29 Ctrl →