Дочь пошла в сербскую школу в сентябре, ни слова не зная и не понимая. В ноябре уже могла что-то прочитать и худо-бедно объясниться. В феврале прохожу мимо ее комнаты, а она с подругой на чистом сербском шпарит, аж в шоке был. Я к тому моменту язык уже год как учил, и говорил уже хуже чем она. Сегодня и сравнивать не стоит, после 2 лет. Язык в среде учится на ура, особенно у детей.
Имхо, да и в целом статья как-то в духе "делайте так, чтобы было хорошо, и не делайте так, чтобы было плохо". Все что описывается в статье открывается при использовании в первые 2 дня. Про работу с чатом было что-то полезное, но ожидал какие-то хаки при работе с самим копилотом. Например, как в него погружать контекст, когда фича оч сложная и затрагивает буквально всю репу. Или, я для себя до сих пор не определил, как эффективно переписывать какие-то участки в довольно больших блоках.
Побуду адвокатом дьявола. Как-будто это все так плохо? Вопрос скорее в альтернативах. Стартап - это не только освоение инвестиций, а еще поиск способа обеспечить себе сначала безубыточность, а затем и профитность. И тут есть 2 способа: рабочий и не всегда. Рабочий - это хаос. Никаких планов, делай сейчас - думай завтра. В таких условиях совершенно невозможно что-то "сделать хорошо", только как есть. Agile же приносит за собой хоть какое-то планирование и, сюрпрайз-сюрпрайз, гибкость. И вот стартануть с эджайла - не очень подход, а вот когда ты вышел в профитность - уже хочется выстроить процессы и отойти от хаоса. Потому что в хаосе - выгораешь. Лучше пока ничего не придумали. Как придумают - и эджайл вымрет.
Очередной пост из разряда "Нет диплома - не специалист". Прям не служил - не мужик. Какая, черт возьми, корреляция между образованием и мышлением? Я встречал коллег, выходцев из МГТУ, НГУ и даже MIT(чтоб международненько было), которые в принципе не способы выдать что-то рабочее, зато "изящное" и "элегантное", ведь "его так учили". Мышление никаким университетами в голову не вдолбишь. Все что показывает наличие диплома - что человек умеет учится. А остается в его голове хоть что-то, после учебы - ой далеко не факт.
И второй поинт - сбейте уже с себя спесь, все желающие написать подобную ересь, что и ТС в своей статье. Вы пишите такой же говнокод, как и все остальные, потому что понятие "хороший код" очень спорное и подразумевает огромное количество разных практик, которые противоречат друг другу, зачастую. И дополнительно, все зависит, а есть ли у вас время и необходимость, написать by design стабильное, расширяемое и поддерживаемое.
Полностью поддерживаю. Я на Андроиде уже с 2019 года не пишу, но вот кто пробовал на бэке корутины использовать для чего-то сложного, где нужно юзать каналы и мьютексы - тот в цирке не смеётся и на поворотах улыбается. Кстати, а вот и поворот)))))
Вот это уже верное утверждение)) И да, наверное, мой комментарий начинался как наброс) Сорян :) Все так, как вы говорите. Только я сказал, что "я считаю") И для меня состояние потока правда плохо работает. И занимаясь регулярно ревью, обсуждая разнообразные конструкции, у меня есть ощущение, что данное утверждение - имеет место быть. Ну и касаемо меня самого - я предоставляю более качественный код если не нахожусь в потоке. И как плюс, могу отвлекаться, и быть полезен команде в нужный момент. Правда, как у всего, есть своя цена, и в данном случае, это скорость. Задачи закрываются дольше, но меня и мою команду это устраивает.
Крайне неверное утверждение. Состояние потока скорее вводит в оверижениринг, и появляются "элегантные конструкции", которые хрен потом разберёшь, потому что "творец" так задумал.
Есть ещё позиция Software Architect, которая в иерархии часто находится выше уровня principal. Архитектор ПО разрабатывает высокоуровневую структуру системы, определяет ключевые компоненты, модули и взаимодействие между ними.
Вот из-за такого булшита, я в свое время свернул из разработки в архитектуру. Понятно дело, что индустрия разная, и у кого-то эникейщик - программист. Но архитектор - это больше в менеджмент. Крайне мало компаний, в которых архитектор пишет код. Это человек, который 50% проводит на митингах, 30% работает с документацией/диаграммами, собирает требования и ищет способ удовлетворить потребности бизнеса как можно дешевле.
Ты буквально видишь в календаре стены митингов, и думаешь на какие идти. А про выбор технологий - это вообще отдельная сказка. Ты ее выбираешь из соображений: что быстрее принесет профит, и с чем твоя команда может эффективнее работать. Зачастую, даже стек становится не важным.
Короч, если хотите остаться в разработке и видеть хотя бы изредка код - не смотрите в архитектуру.
Ну и 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?) Тоже довольно распрастранненый) Да и в целом, всегда может быть что-то такое, чего ты не видишь. Поэтому, как я и сказал, нужен общий механизм
Дочь пошла в сербскую школу в сентябре, ни слова не зная и не понимая. В ноябре уже могла что-то прочитать и худо-бедно объясниться. В феврале прохожу мимо ее комнаты, а она с подругой на чистом сербском шпарит, аж в шоке был. Я к тому моменту язык уже год как учил, и говорил уже хуже чем она. Сегодня и сравнивать не стоит, после 2 лет. Язык в среде учится на ура, особенно у детей.
Ах, да. Дочь пошла в 3ий класс.
Имхо, да и в целом статья как-то в духе "делайте так, чтобы было хорошо, и не делайте так, чтобы было плохо". Все что описывается в статье открывается при использовании в первые 2 дня. Про работу с чатом было что-то полезное, но ожидал какие-то хаки при работе с самим копилотом. Например, как в него погружать контекст, когда фича оч сложная и затрагивает буквально всю репу. Или, я для себя до сих пор не определил, как эффективно переписывать какие-то участки в довольно больших блоках.
Я тож зашел узнать кто из госкорпоратов опять зашкварился
Идиомы это тот же сленг, только выстоявший проверку временем.
Что что что??? В РФ есть стартапы? Скажите что есть еще венчурный капитал.
Пару проектов из списка, на вскидку, не кажутся совсем уж "российскими".
Не вижу, где вы тут можете быть не правы.
Побуду адвокатом дьявола. Как-будто это все так плохо? Вопрос скорее в альтернативах. Стартап - это не только освоение инвестиций, а еще поиск способа обеспечить себе сначала безубыточность, а затем и профитность. И тут есть 2 способа: рабочий и не всегда. Рабочий - это хаос. Никаких планов, делай сейчас - думай завтра. В таких условиях совершенно невозможно что-то "сделать хорошо", только как есть. Agile же приносит за собой хоть какое-то планирование и, сюрпрайз-сюрпрайз, гибкость. И вот стартануть с эджайла - не очень подход, а вот когда ты вышел в профитность - уже хочется выстроить процессы и отойти от хаоса. Потому что в хаосе - выгораешь. Лучше пока ничего не придумали. Как придумают - и эджайл вымрет.
Открестится не пытаются, но тот же большой зеленый банк своих безопасников на мороз целыми отделами выгоняет, в случае чего.
Очередной пост из разряда "Нет диплома - не специалист". Прям не служил - не мужик.
Какая, черт возьми, корреляция между образованием и мышлением? Я встречал коллег, выходцев из МГТУ, НГУ и даже MIT(чтоб международненько было), которые в принципе не способы выдать что-то рабочее, зато "изящное" и "элегантное", ведь "его так учили". Мышление никаким университетами в голову не вдолбишь. Все что показывает наличие диплома - что человек умеет учится. А остается в его голове хоть что-то, после учебы - ой далеко не факт.
И второй поинт - сбейте уже с себя спесь, все желающие написать подобную ересь, что и ТС в своей статье. Вы пишите такой же говнокод, как и все остальные, потому что понятие "хороший код" очень спорное и подразумевает огромное количество разных практик, которые противоречат друг другу, зачастую. И дополнительно, все зависит, а есть ли у вас время и необходимость, написать by design стабильное, расширяемое и поддерживаемое.
Полностью поддерживаю. Я на Андроиде уже с 2019 года не пишу, но вот кто пробовал на бэке корутины использовать для чего-то сложного, где нужно юзать каналы и мьютексы - тот в цирке не смеётся и на поворотах улыбается. Кстати, а вот и поворот)))))
Прочитал заголовок, зашел статью лайкнуть, а тут и лайкать нечего..
Вот это уже верное утверждение)) И да, наверное, мой комментарий начинался как наброс) Сорян :)
Все так, как вы говорите. Только я сказал, что "я считаю") И для меня состояние потока правда плохо работает. И занимаясь регулярно ревью, обсуждая разнообразные конструкции, у меня есть ощущение, что данное утверждение - имеет место быть. Ну и касаемо меня самого - я предоставляю более качественный код если не нахожусь в потоке. И как плюс, могу отвлекаться, и быть полезен команде в нужный момент. Правда, как у всего, есть своя цена, и в данном случае, это скорость. Задачи закрываются дольше, но меня и мою команду это устраивает.
Крайне неверное утверждение. Состояние потока скорее вводит в оверижениринг, и появляются "элегантные конструкции", которые хрен потом разберёшь, потому что "творец" так задумал.
Я считаю, что состояние потока скорее вредно, чем полезно. Детальнее об этом можно почитать у Мартина, ну и краткий реф https://www.google.com/amp/s/it.wikireading.ru/amp4697
А если я с головой и без диплома, можно мне тоже за границу?
Есть ещё позиция Software Architect, которая в иерархии часто находится выше уровня principal. Архитектор ПО разрабатывает высокоуровневую структуру системы, определяет ключевые компоненты, модули и взаимодействие между ними.
Вот из-за такого булшита, я в свое время свернул из разработки в архитектуру. Понятно дело, что индустрия разная, и у кого-то эникейщик - программист. Но архитектор - это больше в менеджмент. Крайне мало компаний, в которых архитектор пишет код. Это человек, который 50% проводит на митингах, 30% работает с документацией/диаграммами, собирает требования и ищет способ удовлетворить потребности бизнеса как можно дешевле.
Ты буквально видишь в календаре стены митингов, и думаешь на какие идти. А про выбор технологий - это вообще отдельная сказка. Ты ее выбираешь из соображений: что быстрее принесет профит, и с чем твоя команда может эффективнее работать. Зачастую, даже стек становится не важным.
Короч, если хотите остаться в разработке и видеть хотя бы изредка код - не смотрите в архитектуру.
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 вызовам. Мне показалось это как-то оверхедно, но интересно. Хотелось бы услышать и ваше мнение)
А вот касаемо вопроса «кто в чем привык». Есть один немаловажный момент. Не стоит относится к 1 языку как всеобъемному инструменту. Языков лучше знать несколько. Рекомендую ознакомится с ним в книге Роберта Мартина(Дядюшка боб, думаю имя должно быть знакомо) «Идеальный программист» ))
Котлин не серебрянная пуля, но во многом куда удобнее. Имеет свои плюсы и свои минусы. Как впрочем и любой другой язык)