Как стать автором
Обновить
10
0
Алексей Скробот @Scrobot

Пользователь

Отправить сообщение
Канеш мертва. А некроманты 3ую версию тут релизят
www.scala-lang.org/blog/2021/05/14/scala3-is-here.html

Ну и lightbend контора некрофилов тоже. Да и тинькофф туда же. Полностью согласен.
Да и сравнение с COBOL в точку прост. На рынке аж 1 вакансия в самом прогрессивном банке на рынке страны. да что там страны!
spb.hh.ru/vacancy/43083989?query=cobol
Долгожданный ресерч от на тему микро-сервисов в андроиде) Огромное спасибо за статью) Однозначно плюсую, но у меня есть пару вопросов:
1. Как мульти-модульная архитектура ведет себя при тестировании? Нужно же, помимо обычных юнит-тестов в каждом модуле, писать интеграционные тесты на стыке 2,3,N модулей. Насколько сильно это может мешать или помогать?
2. CleanArch сегодня рекомендуют использовать практически в каждом проекте, вне зависимости от масштаба. Что скажешь по поводу много-модульности? Стоит ли ее юзать в ентерпрайзе или даже в небольшом аутсорсе от нее можно получить свои бенефиты?
3. А что насчет оверхеда? Размер .apk, путаница с повторным подключением библиотек? Насколько это может быть опасно и какие моменты надо продумать, прежде чем решить переводить свой проект на мульти-модульную архитектуру. Усложняет ли это разработку в команде или упрощает? Ведь придется наверное немного пересмотреть воркфлоу под такую архитектуру, имхо.
4. В данном контексте удачно вписывается Dagger. Что насчет других DI фреймворков? Toothpick, Koin, Kodein? Мне вот например очень сложным представляется тут возможность юзануть Koin…

Ну и под конец: Где-то на рэдите как-то прочитал постик, про то, что связь мульти-модульных архитектур можно реализовать по аналогии с бэкендом — посредством вызова удаленных процедур. Тогда каждый модуль является автономным, а его функции цепляются по RPC вызовам. Мне показалось это как-то оверхедно, но интересно. Хотелось бы услышать и ваше мнение)
Ну, вы возможно забыли упомянуть, что у Java и Kotlin 100% обратная совместимость. Тут я проблем не вижу. Вы даже сами можете взять эту библиотеку и использовать ее в Java коде. Поэтому проблем нет.
А вот касаемо вопроса «кто в чем привык». Есть один немаловажный момент. Не стоит относится к 1 языку как всеобъемному инструменту. Языков лучше знать несколько. Рекомендую ознакомится с ним в книге Роберта Мартина(Дядюшка боб, думаю имя должно быть знакомо) «Идеальный программист» ))
Тут я за автора могу сказать так: с google i/o 2k17 kotlin стал оффициально поддерживаться гуглом в качестве языка разработки. Поэтому это полное право теперь авторов библиотек делать их на котлине. Да и Java андроидовская сильно ущербная. На Java 9/10 писать можно, но это в основном всякие бэк-сервисы и прочее, а андроидовский форк 6ой версии, ИМХО, не особо хорош.
Котлин не серебрянная пуля, но во многом куда удобнее. Имеет свои плюсы и свои минусы. Как впрочем и любой другой язык)
Кстати, ты предусмотрел не все кейсы ActionView) А что насчет LocationDisabled?) Тоже довольно распрастранненый) Да и в целом, всегда может быть что-то такое, чего ты не видишь. Поэтому, как я и сказал, нужен общий механизм
Я безусловно плюсанул, спасибо за статью! Но мне показалось на первый взгляд, что это попытка спрятать бойлер-плейт под другой бойлер-плейт.
Зачем выносить все в набор ActionView, когда лучше это сделать ввиде сборного паттерна, прикрутив к твоей концепции Компоновщик и строитель какой-нить, и пусть человек сам бахает нужные ему ActionView. А также, на самом деле, при кейсе, когда нужно в зависимости от внешнего стейта обновить ActionView, при вашей реализации мне показалось на первый взгляд, что реактивность может пропасть. Этим ActionView нужно наблюдаемое состояние, чего я не увидел(мож проглядел). В любом случае, я поизучаю исходники повнимательнее и выскажу свой более подробный фидбэк) Может даже пул-реквест кину)
Присоеднюсь к BFS, не стоит использовать Subject, он существует только для 1 цели: соединять императивный стиль с реактивным. По сути, он только для легаси подходит. Поэтому, да, лучше Observable.create(). Для подробностей посмотрите доклад Матвея Малькова — Art Of Rx, учитывая что вы андроид разработчик, вам это будет полезно)
И второй момент, поиск это ровно тот кейс, когда нужно думать о Backpressure, а поскольку практически все сегодня используют Rx2, то там эта проблема решена с помощью Flowable, и лучше этот кейс зарефакторить на него.
Да, спасибо) Я немного неверно описал этот раздел. Лучше вместо того чтобы по быстрому впихивать эту тему, которая получилась неверно раскрыта, написать отдельный материал. Спасибо большое за фидбек)
Подскажите, если не секрет, на каком технологическом стеке вы реализовали блокчейн?
Ща внесу нотку пессимизма, ну или реализма(эт как расценивать), но был у меня в практике случай, когда у «не самых умных личностей», которые довольно «плохо» писали приложение, нашелся 1 умный товарищ и вынес защиту в нативную библиотеку. Это было конечно не ИДА, но все равно, попытка реверса оказалось провальной, хотя бы потому что никто не захотел лезть в дебри натива…
Спасибо за статью, комментарии честно признаюсь, не прочитал, может быть, кто-то что-то подобное уже высказал, поэтому выскажу субъективное пожелание.
Хотел бы увидеть более полную версию статьи, основанную на дополнительных данных, ввиде:
1. Дополнить данные схемы языками Ruby и Python, хотя бы потому-то что они тоже довольно популярны в виде бэкенда
2. И добавить еще одну ветку сравнений, в виде использования фреймворков. Т.е. как бы было на нативе и на ФВ. Не знаю как вы, но я ооочень редко встречал поддерживаемые велосипедные проекты)) Обычно(самые распрастранненые варианты)
when(lang) {
  Java -> Spring
  PHP -> Laravel
  Python -> Django
  Ruby -> Ruby on Rails
  NodeJs -> Express.js
}


Было бы любопытно посмотреть на цифры и объективное исследование)
Возможно проглядел, и кто-то упомянул, но еще помимо всего прочего котлин может еще в и жабаскрипт фигачить =)
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
Так что он идеально подходить не только в андроиде, где он прост бесподобен, но и в веб-отрасли.
Kotlin + Anko хорош, но тоже не серебряная пуля. Пойдет для небольших «гуешных» элементов — кастомные вьюхи для диалогов, лейауты с 1-3 элементами. В андроиде сейчас constraint layout наконец-то релизнулась, и, на мой взгляд, обещает быть лучше, чем тот же strory board в xcode. Поэтому тут я за него всеми руками ))
И только тельцы молчат… ведь их засунули в пхпшники XD
ИМХО, механизм сигналов и слотов сам по себе хорош, но что касаемо данного примера… я не могу сказать, что меня это вдохновило, извините. Сигнатура
ConnectionManager::connect($logger, 'somethingIsLogged', $receiver, 'slotReactOnSignal');

Меня немного смущает… Довольно простой пример, и в нем уже такая простыня… а если задачи усложнятся по тем вариантам, которые вы привели?
  • Один сигнал к нескольким слотам
  • Несколько сигналов к нескольким слотам
  • Несколько сигналов к одному слоту

И как мне установить в одном соединении несколько ресиверов? К примеру я создал 3 класса Receiver1. Receiver2, Receiver3 и заимлиментился от Receiveable который реализовал slotReactOnSignal(). Далее, я хочу сделать так:
ConnectionManager::connect($logger, 'somethingIsLogged', [$receiver1, $receiver2, $receiver3], 'slotReactOnSignal');

А если добавить в эту логику внутреннее общение между слотами…
Как мне видится, я полностью согласен с webmasterx все придет к тому, что нужен Rx.
Не хочу сказать, что она бесполезная, я просто не вижу область применений) А не можете дополнить статью еще какими-либо примерами? )) Чтобы ощутить полезность вашей библиотеки) Хотелось бы ее использовать, но где ее юзануть так, чтобы она была прям полезной…
Привет. спасибо за статьи, познавательно. Мне только не хватило информации как Rx обкладывается тестами. На андроиде в том числе.
Ну, тут я не согласен. Это попахивает каким-то, извините меня за сравнение, «фашизмом».
Если разделять людей на классы и касты, вешать на них ярлыки и оценивать по возможностям — можно прийти к гитлеровскому подходу — «оставить одних правильных, а всех остальных фтопку!!! ЗИГ ХАЙЛЬ!!!» ))
Все люди разные, у каждого разные возможности и разное мышление. Ровно как и направлений в разработке множество, так почему говорить, что те кто не знает C++ конченные?
Я бы согласился, если бы вы написали именно с таким мнением, что не все могут работать с С\С++, равно как и с ассемблером и вообще даже с аппараткой. Но это не делает их конченными программистами, они просто другие. У меня есть парочку примеров людей, которые виртуозно работают с C++, но как-то решились попробовать себя в веб-разработке и потерпели фиаско, только потому что тут подходы разные. И я думаю многие могут такие примеры привести. Так что называть людей псевдопрограммерами и тем более указывать им на то, что если они не разобрались в указаниях данного «майн кампфа» им надо выйти вон — очень не этично, я бы даже сказал бестактно.
А вот сказать им в таком ключе «Ну вот не получается у вас делать качественные приложения на C\C++, может стоить попробовать себя в другом? Есть много вариантов и альтернатив. И честно говоря, не каждый кто будет прилагать тонну усилий в течение 20 лет станет гуру.» — было бы намного тактичнее, и как сейчас модно говорить, толерантно. У всех разные возможности и способности. Но это не значит что один убогий и его надо сжечь на костре, а другой — опора мира разработки.
Вроде все сказал))
P.S. Извините, пожалуйста, за сравнение с фашизмом и за все, что с ним связано, но я просто не смог найти другого сравнения. Очень мне напомнило именно расистский подход.
Спасибо конечно за статью, но уж сильно жестко и абстрактно вы завернули )) Если целью было напугать юнных дарований, чтобы проверить их желание — думаю у вас получилось )) в остальном — очень абстрактно и субьективно. Больше примеров и полезных советов — и было бы норм ))) не учитывая провакиционный характер статьи, который так и тянет начать холивар ^_^
Что правда, то правда. В последнее время, Fl.ru знатно пополнился крохоборами. А в качестве исполнителей — школота, да голодные студенты. 5 лет назад еще было сносно, хотя тож не особо. Единственный плюс от него был — это периодически относительно нормальные заказы от заков, которые находили меня по каталогу и напрямую выходили на разговор. А по основным заявкам — предложения за доширак.
Ловите) github.com/veryEvilMan/fl-ru-damp
Какой-то чудак уже успел загрузить на гитхаб)) Думаю долго там оно не продержится — скоро забанят))
1

Информация

В рейтинге
Не участвует
Откуда
Новосибирск, Новосибирская обл., Россия
Дата рождения
Зарегистрирован
Активность