Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Tech Lead/Architect в IT Company
  • Хочу свічнутись з iOS в Java

    Насправді бекенд він різний буває. Тут головне зрозуміти, що яку саме мову обирати.
    C#, Java, NjdeJS чи ще щось.
    С# - простіше, тому що все в одному місці (.Net, документація і тулкіт) у Microsft, плюс іх екосистема з Cloud, тобто Azure.
    Java — скоріше за все це Spring і все інше, повʼязане з цим.
    Свою нішу також має Scala — після Swift взагалі, що майже теж саме, але на JVM. Я б більше акцентував, що ця мова більше зараз націлена на Data Science, як і Python.
    Власне про Python — тут свої фреймворки.
    Що тут головне, так це на мікросервіси.
    Якщо відверто є досвід хоча б з однією екосистемою, то переходити багато часу не забирає. Як уже сказано було, головне розібратися, як будуються мікросервіси, як в них побудована взаємодія, які брокери застосовуються. Відомі — Kafka (в більшості випадків для Java, іноді RabbitMQ), .Net віддають перевагу RabbitMQ.
    І все як це працює у кластері/ах. Перевагу тут має Kubernetes, ніж у Docker Swarm.
    Kubernetes — тому що усі Cloud вже мають під це окремі сервіси на кшталт EKS.
    Що можна сказати про них, то це якщо людина опановую будь яку Cloud інфраструктуру, то майже всі інші мають подібні сервіси, просто з іншими назвами.
    І ще одна складова — це робота з базами даних. Але знов таки, всі мають ту чи іншу реалізацію ORM (Java — Spring Data/Hibenate, .Net — Entity Framework). Щоб розуміти іх, краще опанувати ANSI SQL. Якщо був досвід з SQLite, то це навіть краще. Плюс дрібниця — розуміння, як працювати в скоупі цих речей з міграціями.
    І на останок — то це як працювати з CI/СD, мабуть тут перевагу має Jenkins через свою універсальність. Є варіанти, коли будують на базі Git.
    Головне обрати правильні джерела інформаціі — книги Manning та курси від Udemy.
    Тільки відео не вистачить.

    Підтримали: Bot Bot, Roman Sheremeta
  • Чому вам НЕ потрібен ReactiveX

    Не впевнений, що ви маєте на увазі у випадку ресурсів, адже RX ними не керує ... хіба за потоки мова, але про це ви написали другий пункт :)

    Як раз керує через підхід обсервера — юзер підписався і пішов далі займатися своїми справами. Немає блокуючого виклику.
    Стосовно

    kotlin coroutine,

    це якщо було прийнято рішення писати бек на Kotlin, то це має сенс. Є як завжди свої pros і cons. Основний недолік, все ж таки Kotlin не завжди підтримує останню JVM.
    Для Android — то тут вже інше питання, скоріш за все таки буде Kotlin. І тут RxJava може використовуватися, як база (депенденсі) для RxKotlin.
    Щоб багато не писати, раджу прочитати Т. Нуркевича (це якщо про RxJava) — там як раз про всі підходи і про scheduler і про бекпреже і про все інше (до речі це теж про ресурси).
    Якщо для беку на Java — то «Hands-On Reactive Programming in Spring 5» — тут на початку про різне, потім вже про Reactor.
    Для Android — то вже є що почитати на kodeco (взагалі про світ мобайлу). Але якщо цікаво, як це працює в інших мовах, то можна і по ним знайти і для C++ і для .Net.
    І вже на останок — Rx — це функціональний підхід, замішаний на класичних патернах плюс конкаренсі.

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

    Насправді в свій час був популярний підхід Event Bus в Android, але його мало хто застосовував, тому що йшли на багато простішим шляхом через колбеки. Той же Event Bus перекочував і в бекенд (Spring цей підхід є і в .Net навіть окремі сутності зробили — event). Просто треба розбиратись у підходах, а у нас як... Просто взяли відео продивились і все. Нема глибоко і продуманого підходу. На простих проєктах — це працює. На великих — потім все приводить до втрати часу (тут попрацював і далі пішов). Це відомі проблеми і добре все описано у Р. Мартіна.
    Щодо coroutines — ідея не нова і має імплементацію і в С++, як власне будь які інші підходи, які кочують між мовами і фреймворками.
    Як висновок — як би це був поганий підхід, його не намагалися б застосовувати і інших мовах.

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

    Дві речі яуі вирішує ця технологія.
    1. Це підхід до ресурсів.
    2. Це конкаренсі.
    Якщо складно розуміти технололгію, то не треба писати, що вона вам не потрібна.
    Я десь вже писав. Але Angular на цьому побудован та SwiftUI на це перейшов. Android в багатьох фреймоворках це підтримує (і Rx і coroutines).
    Якщо вам треба щось швидко — то це не про Rx.
    І ще раз — це не про швидкість — це про ресурси.
    Усі мови цю технологію підтримують і навіть Spring теж має — Reactor.
    Ще одна цікава технологія існує, але її теж рідко використовують, це модель актор.
    Є дуже багато компаній, які викорустивують Akka і Tesla там теж. Але нікому з їх інженерів не йде в голову писати про те, що ця технологія не потрібна.
    Як приклад — вона є базою в Erlang, завдяки цьому продукти мають дуже великий процент стійкості до відмови — 99,99999%.
    Все, що маю додати.

  • Чому Flutter ідеально підходить для кросплатформенної розробки

    Так...
    відкриваємо пейдж з переліком ішус
    github.com/flutter/flutter/issues
    і вперед.
    А потім не можуть зрозуміти, чому на одній платформі праює, а на іншій — ні. І виходить як завжди «прекрасний» Франкенштейн, до того ж треба буде ще витратити час, щоб з’ясувати причину — і замовник спитає, а чому, друже, ти про це не розповідав, і чому тепер я маю за це платити.
    Тому для чогось простого — то може і ок.

  • Сучасний IT-ринок: тенденції, рівень зарплат, поради новачкам і досвідченим розробникам

    Ви не праві. Junior — це не Trainee, ця людина як мінімум має добре розуміти мову програмування, але не має чіткого розуміння який фреймворк застосувати і як. Для робітників такого рівня треба витрачати більше часу (на менторство і на кодревʼю) і розписувати таски дуже ретельно. І звісно, що Junior не зможе зробити складний проєкт з нуля (це навіть і мідл нормально не зробить). Але є деякі — хто дуже швидко навчається. І з таких за рік-півтора при нормальному вкладанні зусиль можна зробити хорошего мідла.
    На справді в нормальні часи деякі великі аутсорсінгові компанії мали внутрішні курси, які набирали на горячі напрямки як раз Trainee — ця ситуація власне є win-win.

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

    Що стосується PalmOS — то тут я вже не памʼятаю в чому була трабла. А ось Symbian — просто закрили через те, що Microsoft викупив Nokia і вони перейшли на WinPhone з підтримкою .Net, для того часу була норм система, деякі компанії ії ставили, але все ж таки Android і iOS переграли. Що стосується розробки софта — ось на мобайлі намагаються зробити певні гібриди, які в дійсності більш нагадують Франкенштейнів. А все потому — що не має стандарта і його не буде, тому що... ведучі компанії розвивають свої мовb і фреймворки. Колись був єдиним C++, але Apple все рівно застосовував Objective-C (як на мене простіша і потужна мова) на той час поховали Carbon, пізніше — подивившись, що коїться зі стандартом С++ — так і продовжили, склепав Swift та вже поховали той Objective-C. Щодо беку — все впирається в розподіленість і підходи. Раніше достатньо було написати аплікацію і розгорнути на премісис сервері. Зараз — це ціле діло. Kubernetes, AWS, GCP, Azure — і всі зі своіми підходами, DevOps, плюс більш менш належне тестування.

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

    За док дякую, почитаю. У функціонального підходу є два дробека, це скейлінг і власне — нема бескінцевої памʼяті, тобто треба розглядати комбінований підхід. І все ж таки Rx — не вважається чистим функціональних підходом.
    Про добре і швидко — знову, залежить від певних обставин. Для стартапа — так, важливіше швидше написати, навіть якщо мати потім посередньої якості код. Але якщо вже більш менш зрозуміло, то тут як раз важливіше правильні підходи. Я бачив деякі проєкти, які були швидко зроблені та продані. Але потім їх сапорт виходив для замовника дуже дорого, і власне — в деяких просто відмовлялись його якось розвивати.

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

    Можете написати тести і привести результати, може тоді у вас буде можливість опублікувати і довести всім іншим, що праві саме ви.
    Я ж поки що скажу ось що.
    Mobile — SwiftUI, Combine — Rx підхід,
    Android — на приклад Retrifit — підтримує і Rx і Coroutines плюс багато інших фреймворків, рекомендовано Rx,
    Angular — RxJS — це вже саме за себе говорить.
    Back — Java — для навантажень рекомендується теж саме — Rx, нарешті допрацьований для відповідальної підтримки, тобто драйвер баз даних — асинхроний, сервлет теж саме.
    Тобто західні інженери виглядають, як недолугі? :) Ага :)

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

    Я б вам рекомендував ще раз переглянути базові патерни проєетування і спробувати зрозуміти, на базі пари яких вся ця ідея побудована. До того що вмре. Проблема в тому, що рективність — це не про швидкість, а про ресурси і систему обміну даними між потоками. Вже проведені певні дослідження і доказано, що рективна система краще тримає навантаження. Як джерело — достатньо відкрити першу главу RxJava Т. Нуркевича, де є чіткі графіки. Стосовно віртуальних тредів — які б вони не було, все рівно вони не є сферичним конем в вакуумі, а це значить, що будуть використувувати певний ресурс, як памʼять. Так, не мапяться на системні потоки OS (які все ж таки обменжені), але... все рівно буде привʼязка — потік — реквест, це означає, що якась I/O операція його заблокує до моменту отримання результату. В реактивній системі — нічого не блокується, а просто очікується результат. Система піша далі виконувати свої задачі.

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

    Дивіться, тут все дуже просто — перша вправа, треба просто відкрити сторінку з багами Flutter, Відразу все стане на свої місця. Друга вправа — подивитись, як і що працює на певних платформах. Як приклад — iOS. SwiftUI out of the box підтримую відразу всю екосистему. Від iPhone і закінчуючи Apple Watch. Теж саме і з Android Kotlin/Compose. Можна розписати по леєрам і фремворкам — але то зайве. І все це має підтримувати Flutter.
    Єдине, де має сенс таких гибридів — це показати швидко бізнес ідею потенційним інвесторам. Потім все викинути. Бо як ви можете бачити — технології змінюються.
    Apple поступово відходить від UIkit, Google — від старого управляння UI.

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

    Все норм там працює, якщо розуміти, що робиш. Проблема раніше була в тому, що не всі леєра підтримували асинхронність. Тобто, якщо сервлет блокуючий, чи драйвер DB, то тут нема що казати. Тому всі йшли старим шляхом. Але, коли все вже підтримую починаючи від Netty ф асихронним драйвером — все має працювати. Стосовно блокуючих викликів — це говорить про помилки в архітектурі. Тому і був розроблений Rector (WebFlux), звісно, що і Security був допрацьований для підтримки цього стеку.

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

    Optinal — це все ж таки не на рівні мови :) На приклад — мені так, достатньо саме цього.
    Зараз я б сказав, що більше навіть все залежить не від PL, а від тулінгу для асінхроного процесингу даних. Саме це було слабким мцсцем у С++. Зараз усі більш менш відомі мови вже мають Rx імплемнтації. Java навіть ще має мачурний Reactor.

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

    Все що ви перечислили — то треш і угар. Стосовно Flutter та інших ненативних підходів — це працює з чимось простим. Якщо щось більш менш складне — то ви отримаєту жахливий Франкенштейн. Це ж саме стосується і iOS :)

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

    «Це вже було» © :) На справді вже проходили теж саме десь років 8 тому зі Scala. Власне від чого і пішли Swift та Kotlin.
    Як там не було, а все ж таки Kotlin трішки інакше компілюжться у байткод. Конкаренсі має інший (Coroutines). Якщо правильно використувати Lombok — то нічого і виграється.
    Мабуть, що nullable тип у Kotlin — це його добра риса, чого не має у самій Java. В решту решт — є анотації та валідації.
    Як на мене — то якщо буде якийсь стандарт, тоді це буде мати сенс — але його не буде. Тому що кожна компанія розвиває свій тулкіт і PL.

    Підтримали: Dmitry Bugay, Andrew Petrenko
  • Шукаю курс з iOS-розробки, а саме на Swift

    Читайте книги, якщо щось не зрозуміло — модно подивитись на youtuve. В більшості курси — то така собі штука. Краще знайти когось, хто розумію певну платформу і що порадить. Ніколи не витрачав на курси час.
    Стосовно web — manning видавництво, зокрема серія in action.
    Apple — іх книга Swift, далі іх tutorials саме.
    Самий крутий ресурс по mobile сайт kodeco.com. Деяки книги в них є вдалими, в деяких дуже багато води. Там і статі і туторіали.

    Підтримав: Shemendyik Anastasia
  • З’явилась петиція до Президента України про механізм блокування російського контенту в Україні

    Знаєте в чому проблема? Я вже писав до одного посту з цього приводу, але в іншій соціальній мережі. Що ви намагаєтесь зробити — це знайти на складні питання чи процеси, прості відповіді. Якщо я просто хочу — і ось, воно пивинно тут же спрацювати. Але... воно так не працює і так, ми воюємо за свободу вибора, а ви його навʼязуєте. Бесперечно певний контент треба банити і не давати йом ходу, це стосується пропоганди. Але — все ж таки кожен повинен просто переходити поступово. До того ж — для цього треба мати стратегію і кошти.

    Підтримав: Yurii Koz
  • ІТ-спільното, купимо армії «літачок»? Збираємо $ 1 000 000 на сучасний комплекс PD-2

  • Вырос с $3500 до $8000 за год. Зарплатные эксперименты Java-разработчика

    Тут все достаточно просто. Люди, которые относятся предвзято:
    а) сидят годами на одной технологии, читай не пробовали что-то другое
    б) из пункта а) вытекает суждение (совершенно ошибочное), что члеовеку, который свитчится так же надо будет проходить все заново.
    Скажу по своему опыту, кто сменил 4 технологии, что это не соответствует действительности.
    Потому как ни один язык на ровном месте не рождается (как и в любой сфере человеческой деятельности), всегда что-то берется за основу. Отсюда следует, что не нужно будет все изучать заново. На счет языка — если язык изначально ООП, то просто достаточно пробежаться по основныму синтаксису. Больше всего времени занимают фреймворки, но тут опять же, все зависит от опыта их использования. Тем более, что если это одна эрия, где просто идет конкуренция Java/.Net — то в таких случаях вообще будет достаточно два-трои месяца, чтобы спокойно перейти на парраллельную технологию (как пример JPA/Entity Framework). И так далее.
    Знаю примеры, когда люди спокойно за такой промежуток времени переходили на Go.

  • Розкажіть де у вас починається або закінчується ваша власна «зона комфорту»

    отличная идея, и что вам ответили на ваш фича-реквест? :)

← Сtrl 123456 Ctrl →