А как вы искали вакансии на языке Си? В ручном поиске в результат попадаются 1С и С#, и даже те результаты в загловке которых просто попадается английская буква C, например, "Разработчик CRM". И если посмотреть описание этой вакансии, то там про Си вообще ничего, но за то есть C#.
Короче говоря, HH отдает не адекватные результаты на Си, даже если пытаться использовать их фильтры, количество вакансия на Си все равно меньше на порядок, чем для JavaScript.
Подписка от Oracle, по моему это уже не про РФ. Инструменты сборки проектов Java почти не развиваются, появился разве что Gradle. Но в Gradle ощущение, что настроек не уменьшилось, хоть и код там проще воспринимать чем в maven. Пытаются сделать Amper, это штука как раз и будет равняться на современные сборщики, но она я так понял чисто под Kotlin.
Короче говоря, порог входа в сборку и ведения проекта на Java до сих пор останется очень сложным, по сравнению со многими современными языками.
В случае с Командой, это не инкапсуляция, а завуалирование. Например в dry-rb команда в ruby, реализована так, что классы превращаются по сути в методы, из "Камел Кейс" в "Снейк Кейс", и ни что не ограничивает, автора кода, назвать этот метод вообще как угодно, и потом вы фиг что найдете в этом коде даже через ручной поиск, а IDE и подавно не поймет откуда уши растут.
Таким образом, в проекте добавляется лишня библиотека, лишний код, который нисколько не помогает избавится от дублирования - вместо этого появляется завуалирование, а инкапсуляцией это уже нельзя называть.
Я считаю, что нужно соблюдать баланс, и не стремится все впихать в одно место, в кучу. Данный паттерн по моему, нарушает баланс, и усложняет понимание кода гораздо сильнее чем всякие интерфейсы, а по моему, его сравнивать даже нельзя с интерфейсами, по крайней мере не на всех языках точно.
По моему паттерн command, этот антипаттерн, потому что скрывает за командами реальные классы и модули, это усложняет поиск класса которы привязан к команде. И в таком приложении реально добавляет неудобства поддержки.
По моему лучше смотреть в сторону Ампер и уходить от градл. Особых преимуществ и удобств по сравнению с мавен, этот градл не дал, кроме изменения языка конфигурации(вместо xml стал котлин) удобнее и понятнее не стало, а то и хуже стало.
В Мультиплатформах тоже всегда будут баги. Давно уже пытаются придумать альтернативы, которые должны объять необъятное, словно "фуллстек" только на изнанку. React Native, что-то не сильно зашел, раз пытаются придумать альтернативы. Flutter, хотя я считаю это зрелой технологией и лучшим выбором чем KMP, но судя по тому, что все пытаются создавать новые альтернативы, всегда будут не довольные и KMP тем более не будет исключением. Мультиплатформы, сами по себе не дадут погрузится разработчику в особенности и тонкости платформы и не будут успевать за новыми фичами платформы.
И как ни крути, но нативная разработка будет позволять быстрее выкатить фикс под конкретную платформу, чем MP.
Напрашивается мысль, что лучше учить просто Kotlin и Swift, что бы один разработчик поддерживал обе версии приложения, вместо того, что бы мучаться с этими мультиплатформами.
Я думаю, знает тот, кто понимает куда ему нужен человек и на что конкретно. Обычно это тимлиды с опытом не меньше 10 лет, которые понимают, какие конкретно задачи предстоит выполнять и какой опыт требуются от кандидата.
Иначе катают шаблонно, как большинство - алгоритмы, тестовые здачи и тп.
Главное не забывай, что в оригинале можно было пробраться на базу Наварро еще почти в самом начале и украсть там крутое оружие а потом раздавать всем люлей ну или просто для прикола.
Для бренда я бы предпочел использовать сайт-визитку, на котором постил бы мысли, IT-философию и ссылки на свои на репозитории которые заслуживают внимания работодателя.
Вы, наверное, до сих пор храните свои наработки на флешках и древних жестких дисках и постоянно их теряете. А, может, вы еще придете на мою страницу в соцсетях, чтобы посмотреть там на мой бренд?
За 10 лет на GitHub у меня скопилось огромное количество кода. И почему я вдруг, следуя какой-то новой моде, должен разбирать, какой код мне нужен, а какой - нет? Мой GitHub - это история моего пути, он помогает увидеть, как я рос и совершенствовал свои навыки.
А теперь находится какой-то чел, который решил, что я должен навести там порядок по его личным стандартам.
Если вы замените людей, то ваш бизнес людям не нужен будет. Ваши клиенты это люди - мне кажется, этим все сказано.
Представьте картину. Два бизнеса, которые продают друг другу что, так как клиентами являются сотрудники из противоположных компаний. Если обе компании начнут заменять своих людей на ИИ, то что будет? У компаний будут убытки в продажах.
Сейчас на собесах требут, что бы ты знал все на юзусть, все термины, названия всех паттернов, алгоритмов. На практике больше 90 процентов, из того что спрашиваю на собесах, в этих конторах не используют. И если в самом начале программист все это зазурбил и прошел собес, то все это он потом забывает. И по моему, собесят люди, у которых мало опыта, которые стали сеньерами за 5 лет общего опыта в ИТ вообще.
А как вы искали вакансии на языке Си?
В ручном поиске в результат попадаются 1С и С#, и даже те результаты в загловке которых просто попадается английская буква C, например, "Разработчик CRM".
И если посмотреть описание этой вакансии, то там про Си вообще ничего, но за то есть C#.
Короче говоря, HH отдает не адекватные результаты на Си, даже если пытаться использовать их фильтры, количество вакансия на Си все равно меньше на порядок, чем для JavaScript.
Эти нюансы надо учитывать.
Статистику загрузок брать имхо не стоит, потому что качать от туда может кто угодно чисто ради учебного интереса и потом забросить.
Подписка от Oracle, по моему это уже не про РФ. Инструменты сборки проектов Java почти не развиваются, появился разве что Gradle. Но в Gradle ощущение, что настроек не уменьшилось, хоть и код там проще воспринимать чем в maven. Пытаются сделать Amper, это штука как раз и будет равняться на современные сборщики, но она я так понял чисто под Kotlin.
Короче говоря, порог входа в сборку и ведения проекта на Java до сих пор останется очень сложным, по сравнению со многими современными языками.
Меня смутило «лучшие разработчики». Какого же стремно понимать, что там есть и не лучшие. В такой атмосфере и места для скрытой токсичности найдется.
В случае с Командой, это не инкапсуляция, а завуалирование. Например в dry-rb команда в ruby, реализована так, что классы превращаются по сути в методы, из "Камел Кейс" в "Снейк Кейс", и ни что не ограничивает, автора кода, назвать этот метод вообще как угодно, и потом вы фиг что найдете в этом коде даже через ручной поиск, а IDE и подавно не поймет откуда уши растут.
Таким образом, в проекте добавляется лишня библиотека, лишний код, который нисколько не помогает избавится от дублирования - вместо этого появляется завуалирование, а инкапсуляцией это уже нельзя называть.
Я считаю, что нужно соблюдать баланс, и не стремится все впихать в одно место, в кучу.
Данный паттерн по моему, нарушает баланс, и усложняет понимание кода гораздо сильнее чем всякие интерфейсы, а по моему, его сравнивать даже нельзя с интерфейсами, по крайней мере не на всех языках точно.
По моему паттерн command, этот антипаттерн, потому что скрывает за командами реальные классы и модули, это усложняет поиск класса которы привязан к команде. И в таком приложении реально добавляет неудобства поддержки.
Что за жесть? У питонистов 3.10 это устаревшая версия? Я понимаю если бы это был 2.7.
Догнали ruby ;)
По моему лучше смотреть в сторону Ампер и уходить от градл. Особых преимуществ и удобств по сравнению с мавен, этот градл не дал, кроме изменения языка конфигурации(вместо xml стал котлин) удобнее и понятнее не стало, а то и хуже стало.
В Мультиплатформах тоже всегда будут баги. Давно уже пытаются придумать альтернативы, которые должны объять необъятное, словно "фуллстек" только на изнанку. React Native, что-то не сильно зашел, раз пытаются придумать альтернативы.
Flutter, хотя я считаю это зрелой технологией и лучшим выбором чем KMP, но судя по тому, что все пытаются создавать новые альтернативы, всегда будут не довольные и KMP тем более не будет исключением.
Мультиплатформы, сами по себе не дадут погрузится разработчику в особенности и тонкости платформы и не будут успевать за новыми фичами платформы.
И как ни крути, но нативная разработка будет позволять быстрее выкатить фикс под конкретную платформу, чем MP.
Самое хреновое в этом то, что ИИ не редко ошибаются. Особенно вот такие большие модели.
Напрашивается мысль, что лучше учить просто Kotlin и Swift, что бы один разработчик поддерживал обе версии приложения, вместо того, что бы мучаться с этими мультиплатформами.
Я думаю, знает тот, кто понимает куда ему нужен человек и на что конкретно. Обычно это тимлиды с опытом не меньше 10 лет, которые понимают, какие конкретно задачи предстоит выполнять и какой опыт требуются от кандидата.
Иначе катают шаблонно, как большинство - алгоритмы, тестовые здачи и тп.
Главное не забывай, что в оригинале можно было пробраться на базу Наварро еще почти в самом начале и украсть там крутое оружие а потом раздавать всем люлей ну или просто для прикола.
А в ruby смогли сделать сокращения для именованных аргументов ;)
Все эти требования говорят лишь о том, что интервьюеры на самом деле не знают как оценивать кандидата.
Для бренда я бы предпочел использовать сайт-визитку, на котором постил бы мысли, IT-философию и ссылки на свои на репозитории которые заслуживают внимания работодателя.
Вы, наверное, до сих пор храните свои наработки на флешках и древних жестких дисках и постоянно их теряете. А, может, вы еще придете на мою страницу в соцсетях, чтобы посмотреть там на мой бренд?
За 10 лет на GitHub у меня скопилось огромное количество кода. И почему я вдруг, следуя какой-то новой моде, должен разбирать, какой код мне нужен, а какой - нет? Мой GitHub - это история моего пути, он помогает увидеть, как я рос и совершенствовал свои навыки.
А теперь находится какой-то чел, который решил, что я должен навести там порядок по его личным стандартам.
Если вы замените людей, то ваш бизнес людям не нужен будет. Ваши клиенты это люди - мне кажется, этим все сказано.
Представьте картину. Два бизнеса, которые продают друг другу что, так как клиентами являются сотрудники из противоположных компаний. Если обе компании начнут заменять своих людей на ИИ, то что будет? У компаний будут убытки в продажах.
В больших масштабах это не будет заметно сразу.
Сейчас на собесах требут, что бы ты знал все на юзусть, все термины, названия всех паттернов, алгоритмов. На практике больше 90 процентов, из того что спрашиваю на собесах, в этих конторах не используют. И если в самом начале программист все это зазурбил и прошел собес, то все это он потом забывает. И по моему, собесят люди, у которых мало опыта, которые стали сеньерами за 5 лет общего опыта в ИТ вообще.