Да если и множественные, кому это реально будет интересно? Интересным приложением для тестирования было бы приложение, понимающее если не произвольный текст на естественном языке, то хотя бы формальные языки типа языков программирования - и способное оценить адекватность ответа на вопрос, который предполагает написание кода либо текста.
И я бы сказал, что на сегодня такую систему уже наверное написать можно, применив API условного ChatGPT. А все остальные варианты - они для реальных применений достаточно убоги, как правило. И их реально вагон готовых.
Ну, осталось определить одну мелочь - все по чуть-чуть должно же на сегодня включать умение решать задачи по математике? Если таки да, то не вижу особых причин, почему не должно включать и умение немного попрограммировать? Профессионально программировать? Скорее нет, чем да. Написать макрос для Excel, Blender, AutoCAD? Cкорее да, чем нет. Написать SQL запрос? Может и не помешало бы. Хорошо бы иметь тот самый широкий кругозор, который позволяет понять, что вот эту операцию можно запрограммировать, если изучить некий API или язык - кругозор, который дает понимание сложности изучения нового языка, понимание что это вовсе не что-то запредельное, и языки можно знать десятками, на уровне пригодном для применения.
А дальше возникает простой вопрос, не имеющий ответа - сколько времени мы готовы уделить обучению этим вещам, и кто будет учить?
Ну может даже не проблемы, а проблема - непонятно какова цель. Мы таки хотим получить программиста после школы? А оно точно нам нужно (джунов после курсов уже и так девать некуда)? Или нужно чтобы школьник умел использовать компьютер для решения задач (в том числе по другим предметам), и не обязательно при этом программируя? И в общем-то, и подходы к обучению, и к экзаменам, в этих двух случаях должны вроде бы быть разными.
Ну, с практической точки зрения я с вами согласен. Если перед нами стоит такая цель, как сдать этот экзамен - то надо и готовиться к этой цели, в идеале - чтобы сдача была самой простой. То есть, идем по самому типичному пути.
Но тут изначально началось с утверждения:
Хорошо бы, конечно, что-то современное типизированное вроде C# или Java,
потому я и спросил, раз уж кто-то готов учить C# и Java, то почему вместо них не учить более простым и удобным языкам на тех же платформах, которые вполне имеются? Причем в тоже время это ведь и языки, широко применяемые практически - котлин это на сегодня вообще весь андроид, а груви - это много разного девопса. Я согласен, что этот подход не совсем укладывается в идеологию ЕГЭ, но это как по мне, проблемы ЕГЭ, а не подхода.
Вы хотите сказать, что для питона все это есть? Что методички нужны - я согласен. Просто вы же сами завели разговор про Java или C# - так с ними будет та же картина, и при этом синтаксис для груви и котлина намного, намного лаконичнее.
Учитель? А сам-то он откуда знает, как автопоилку подключать к умному дому? Может я ошибаюсь, но я исхожу из того, что учителя в массе никогда сами не программировали, и соответственно научить этому не могут. То есть, чтобы вести такие факультативные проекты, нужны люди несколько другого уровня. А откуда они возьмутся в массовом количестве - мне непонятно.
Впрочем, доказать я этого конечно не могу, ну просто я смотрю на это скорее с пессимизмом.
Совершенно не понимаю, что вам мешает использовать груви или котлин? Там есть все тоже самое, и там нет тех заморочек с синтаксисом, т.е. простейшая программа выглядит как:
Если восьмиклассник хочет сделать автоматизированную поилку для хомячка и подключить ее к умному дому
Это практически не укладывается в формат школы. Ну даже если он сделает и подключит, то во-первых, кто ему будет помогать? Сам изучит? А школа тут при чем? А экзамены как сдавать будет, если учитель не сможет понять уровень результата?
То что вы предлагаете - это скорее формат для кружка. И не для всех.
Так а где тут критика? Мы скорее высказались в том духе, что полезность этой деятельности - она плохо измеряется. И для меня лично, если нету циферок - то нет и пользы. Вы говорите что это полезно? Ну так я верю - но сам пока так делать не буду. Это просто такой практический подход. Возможно основанный на том, что я никогда не набираю людей на уровне компании, а только в проект, причем мои проекты - они довольно маленькие. Как вы догадываетесь, создать имидж мелкому проекту, где набирают в лучшем случае трех разработчиков в год - ну это такое, не стоит выделки такая овчинка.
Ну может вы явно и не агитируете, но представить по тексту статьи что вы против - ну очень сложно :)
Компании точно умеют считать затраты на одного нанятого сотрудника. Сколько стоит нанять человека, когда он 1) ничего не знает о вашей компании и 2) когда весь рынок в курсе кто вы, чем занимаетесь и какие проекты для разработчиков у вас есть.
Ну вот если про первое (знают затраты на найм) я скажу, что скорее да, то про второе (знают, от чего они зависят) - практически уверен, что нет. Потому что каждая конкретная компания - она в одной позиции, либо про нее никто не знает, либо у нее есть статус на рынке. А у конкретного проекта, где могут работать скажем человек десять, и именно от этих десяти человек и будет зависеть, хорошо ли вам будет работаться - у проекта на рынке вообще нет никакого статуса. И нанимая людей вот в такой маленький проект, я никогда не слышал, чтобы они сказали: "О, это тот самый знаменитый проект ..., как-же как-же, я столько о вас наслышан". Ну выж понимаете, что такого не бывает. Даже если мы берем человека по знакомству - он наслышан не о нашем проекте, а о ком-то, кто его лично рекомендует.
И даже большой проект, у которого точно есть узнаваемость на рынке труда, совсем не факт что эта узнаваемость будет играть в плюс при попытке нанять кого-то.
Впрочем, не собираюсь никого переубеждать. Пусть это будет мое мнение, с точки зрения разработчика с опытом. Не исключаю, что это именно мое частное такое мнение и есть.
Ну вообще говоря, вы агитируете за деврел - так что вам бы следовало ее и предоставить.
Потому что по тому, что я вижу -- всё совсем наоборот.
И вы это можете померять? Ой вот не верю я...Причем знаете почему? Не потому что эффекта нет - может он и есть, а потому что на вот это вот все влияет так много факторов, что выделить и измерять влияние одного - ну очень сложно.
А тот факт, что вы апеллируете к опыту Эппл, он скорее ослабляет вашу позицию, нежели наоборот. Как бы ни относиться к этой компании, но она очевидно незаурядная. То что они могут себе позволить - многим не подойдет.
Ну если вы реально что-то нашли, стоило бы сослаться, и описать, чем ваше решение лучше. Потому что скажем шаги типа копирования на сервер (по разным протоколам) - они совершенно штатные, и есть везде. Ну т.е. грубо говоря - берете maven, и находите плагин, берете gradle - тоже самое. Ну т.е. оно еще и в процесс сборки интегрируется как правило.
Я классический вкатун с полного нуля; Java первый и на момент написания статьи единственный язык программирования, который я знаю; это моя первая статья; в этой статье нет рекламы; я не проходил платных курсов; у меня нет регулярного ментора.
Конец дисклеймера.
Хм. Простите, а кого это вот все волнует? Ну то что рекламы нет - и на том спасибо конечно. но по-хорошему, в такой ситуации следовало бы поступить примерно так: открыть Хабр, и в поиске попробовать найти статьи на похожую тему. Я более чем уверен, что их тут было в достатке, потому что вы не первый, кому надо свое приложение куда-то установить. Если владеете языками - то повторить в интернете. Если нет - начать изучение английского ASAP :)
Потом их надо прочитать, и хотя бы понять, какие рецепты решения вашей проблемы там предложены. И понять, отличается ли чем-то в лучшую сторону ваш рецепт. Понятно, что для этого надо хотя бы суметь оценить уровень чужих статей и сравнить со своим. И только потом уже публиковаться, когда вы понимаете, что можете предложить хоть что-то новое и интересное.
Ну если погрепать - это будет исследование. И более-менее объективный результат (хотя реализация этого паттерна совсем не факт что содержит такое слово, BTW). Но я почему-то уверен, что ни вы, ни автор такого исследования не проводили.
Я все равно ведь не про это. Автор с парой лет опыта скорее всего никогда не использовала например Chain of Responsibility, или стратегию. Следует ли из этого, что они тоже не нужны?
Ведь по-хорошему, зачем вообще в курсах давать паттерны? Ведь явно совершенно не для того, чтобы ученики сразу начали их использовать на практике, все подряд. Ничего хорошего из этого не получается.
По крайней мере на мой взгляд, давать их стоит в такой форме, чтобы ученики понимали, что есть вот такая книга рецептов ("о вкусной и здоровой пище"), где описаны типовые решения типовых задач. А точнее - книги. Причем сразу отметить, что выглядеть эти решения (и сами задачи) будут сильно по-разному, если вы возьмете другой язык, другой фреймворк, и другие задачи наконец. Потому что для других задач есть например набор EIP (Enterprise Integration Patterns), с совсем другим набором паттернов.
И в такой постановке вполне можно рассказать классификацию паттернов, упомянуть любые из них, какие преподавателю в голову взбредет, просто чтобы проиллюстрировать, что такое типовая проблема, и из чего состоит типовое решение. И memento в этом смысле ничуть не хуже любого другого паттерна, и участвует в нем всего три класса (что даже совсем не много).
С точки зрения игры со сменой мячей поменялось очень многое. Поэтому продаваться оно конечно может, только вот этот вот TORRES - это товары, "напоминающие по виду настольный теннис". В магазинах которые профессионально торгуют товарами для тенниса, даже самые дешевые мячи из ABS. Хотя формально, по правилам, мяч может быть сделан из целлулоида, это правда. Размеры и вес нормированы, а к материалу никаких конкретных требований не предъявляется.
Ну, коммуникабельность - это слишком узкий термин, как по мне. Ну или не очень точный.
Ну вот например, разве вас никогда не звали на встречу для обсуждения какой-то темы, куда приглашены скажем 10 человек, и при этом ни цели встречи, ни постановка проблемы, ни программа - не озвучены? Ну т.е. предлагается потратить скажем час рабочего времени 10 человек непонятно на что. Я такое вижу регулярно. И это именно что недостаток навыков общения. Только не просто общения - а эффективного общения. Причем, обратное тоже верное - иногда вместо того чтобы собраться и обсудить вживую на 10 минут, устраивается переписка на 10 дней.
Я бы это назвал способностью выстраивать эффективные коммуникации. И да, очень многие этого не умеют.
Зато (если я вас правильно понял), упоминание модели OSI в тексте такого рода сразу позволяет вам понять ценность(?), которую несет подобная статья, разве нет?
А вот ASN.1 я не понимаю, чем вам не угодила. Она просто работает. Скажем, мне недавно было нужно найти описание формата файлов кербероса (а конкретно keytab). Я был бы просто счастлив, если бы нашел ASN.1 нотацию - это означало бы, что я могу взять инструмент, и написать парсер. Но я ее не нашел - и в итоге, я имею три разных парсера, которые по разному парсят один и тот же файл.
Ну да, она возможно сто раз неудобная, и инструментарий для ее поддержки архаичный, что правда, то правда.
Мой опыт мне говорит, что паттерны очень сильно зависят от области разработки
Я говорю лишь о том, что этот паттерн в iOS разработке не часто применимый
Ваш опыт вам вполне правильно подсказывает. От языка еще. Потому что в функциональном языке будут совсем другие типовые задачи и другие паттерны их решения (и их даже возможно так называть не будут).
Я скорее о том, что имея небольшой опыт, не стоит делать далеко идущие выводы о том, что нужно а что нет. Ведь все что вы знаете (реально знаете, а не думаете что знаете), это то, что вы какие-то паттерны не применяли. И не знаете, куда и зачем применить. Понимание того, насколько типовую проблему они решают, дает только опыт, ну или исследование.
Опять же, как по мне, я бы вообще начинающим про паттерны рассказывал только то, что они есть. И для чего нужны. Потому что осознанное их применение - оно за пределами имеющегося опыта. И как правило, попытки применить делают код только хуже.
Да если и множественные, кому это реально будет интересно? Интересным приложением для тестирования было бы приложение, понимающее если не произвольный текст на естественном языке, то хотя бы формальные языки типа языков программирования - и способное оценить адекватность ответа на вопрос, который предполагает написание кода либо текста.
И я бы сказал, что на сегодня такую систему уже наверное написать можно, применив API условного ChatGPT. А все остальные варианты - они для реальных применений достаточно убоги, как правило. И их реально вагон готовых.
Ну, осталось определить одну мелочь - все по чуть-чуть должно же на сегодня включать умение решать задачи по математике? Если таки да, то не вижу особых причин, почему не должно включать и умение немного попрограммировать? Профессионально программировать? Скорее нет, чем да. Написать макрос для Excel, Blender, AutoCAD? Cкорее да, чем нет. Написать SQL запрос? Может и не помешало бы. Хорошо бы иметь тот самый широкий кругозор, который позволяет понять, что вот эту операцию можно запрограммировать, если изучить некий API или язык - кругозор, который дает понимание сложности изучения нового языка, понимание что это вовсе не что-то запредельное, и языки можно знать десятками, на уровне пригодном для применения.
А дальше возникает простой вопрос, не имеющий ответа - сколько времени мы готовы уделить обучению этим вещам, и кто будет учить?
Ну может даже не проблемы, а проблема - непонятно какова цель. Мы таки хотим получить программиста после школы? А оно точно нам нужно (джунов после курсов уже и так девать некуда)? Или нужно чтобы школьник умел использовать компьютер для решения задач (в том числе по другим предметам), и не обязательно при этом программируя? И в общем-то, и подходы к обучению, и к экзаменам, в этих двух случаях должны вроде бы быть разными.
Ну, с практической точки зрения я с вами согласен. Если перед нами стоит такая цель, как сдать этот экзамен - то надо и готовиться к этой цели, в идеале - чтобы сдача была самой простой. То есть, идем по самому типичному пути.
Но тут изначально началось с утверждения:
потому я и спросил, раз уж кто-то готов учить C# и Java, то почему вместо них не учить более простым и удобным языкам на тех же платформах, которые вполне имеются? Причем в тоже время это ведь и языки, широко применяемые практически - котлин это на сегодня вообще весь андроид, а груви - это много разного девопса. Я согласен, что этот подход не совсем укладывается в идеологию ЕГЭ, но это как по мне, проблемы ЕГЭ, а не подхода.
Вы хотите сказать, что для питона все это есть? Что методички нужны - я согласен. Просто вы же сами завели разговор про Java или C# - так с ними будет та же картина, и при этом синтаксис для груви и котлина намного, намного лаконичнее.
Учитель? А сам-то он откуда знает, как автопоилку подключать к умному дому? Может я ошибаюсь, но я исхожу из того, что учителя в массе никогда сами не программировали, и соответственно научить этому не могут. То есть, чтобы вести такие факультативные проекты, нужны люди несколько другого уровня. А откуда они возьмутся в массовом количестве - мне непонятно.
Впрочем, доказать я этого конечно не могу, ну просто я смотрю на это скорее с пессимизмом.
Совершенно не понимаю, что вам мешает использовать груви или котлин? Там есть все тоже самое, и там нет тех заморочек с синтаксисом, т.е. простейшая программа выглядит как:
println("Hello, world")
и все.
Это практически не укладывается в формат школы. Ну даже если он сделает и подключит, то во-первых, кто ему будет помогать? Сам изучит? А школа тут при чем? А экзамены как сдавать будет, если учитель не сможет понять уровень результата?
То что вы предлагаете - это скорее формат для кружка. И не для всех.
Так а где тут критика? Мы скорее высказались в том духе, что полезность этой деятельности - она плохо измеряется. И для меня лично, если нету циферок - то нет и пользы. Вы говорите что это полезно? Ну так я верю - но сам пока так делать не буду. Это просто такой практический подход. Возможно основанный на том, что я никогда не набираю людей на уровне компании, а только в проект, причем мои проекты - они довольно маленькие. Как вы догадываетесь, создать имидж мелкому проекту, где набирают в лучшем случае трех разработчиков в год - ну это такое, не стоит выделки такая овчинка.
Ну может вы явно и не агитируете, но представить по тексту статьи что вы против - ну очень сложно :)
Ну вот если про первое (знают затраты на найм) я скажу, что скорее да, то про второе (знают, от чего они зависят) - практически уверен, что нет. Потому что каждая конкретная компания - она в одной позиции, либо про нее никто не знает, либо у нее есть статус на рынке. А у конкретного проекта, где могут работать скажем человек десять, и именно от этих десяти человек и будет зависеть, хорошо ли вам будет работаться - у проекта на рынке вообще нет никакого статуса. И нанимая людей вот в такой маленький проект, я никогда не слышал, чтобы они сказали: "О, это тот самый знаменитый проект ..., как-же как-же, я столько о вас наслышан". Ну выж понимаете, что такого не бывает. Даже если мы берем человека по знакомству - он наслышан не о нашем проекте, а о ком-то, кто его лично рекомендует.
И даже большой проект, у которого точно есть узнаваемость на рынке труда, совсем не факт что эта узнаваемость будет играть в плюс при попытке нанять кого-то.
Впрочем, не собираюсь никого переубеждать. Пусть это будет мое мнение, с точки зрения разработчика с опытом. Не исключаю, что это именно мое частное такое мнение и есть.
И вы это можете померять? Ой вот не верю я...Причем знаете почему? Не потому что эффекта нет - может он и есть, а потому что на вот это вот все влияет так много факторов, что выделить и измерять влияние одного - ну очень сложно.
А тот факт, что вы апеллируете к опыту Эппл, он скорее ослабляет вашу позицию, нежели наоборот. Как бы ни относиться к этой компании, но она очевидно незаурядная. То что они могут себе позволить - многим не подойдет.
Ну если вы реально что-то нашли, стоило бы сослаться, и описать, чем ваше решение лучше. Потому что скажем шаги типа копирования на сервер (по разным протоколам) - они совершенно штатные, и есть везде. Ну т.е. грубо говоря - берете maven, и находите плагин, берете gradle - тоже самое. Ну т.е. оно еще и в процесс сборки интегрируется как правило.
Хм. Простите, а кого это вот все волнует? Ну то что рекламы нет - и на том спасибо конечно. но по-хорошему, в такой ситуации следовало бы поступить примерно так: открыть Хабр, и в поиске попробовать найти статьи на похожую тему. Я более чем уверен, что их тут было в достатке, потому что вы не первый, кому надо свое приложение куда-то установить. Если владеете языками - то повторить в интернете. Если нет - начать изучение английского ASAP :)
Потом их надо прочитать, и хотя бы понять, какие рецепты решения вашей проблемы там предложены. И понять, отличается ли чем-то в лучшую сторону ваш рецепт. Понятно, что для этого надо хотя бы суметь оценить уровень чужих статей и сравнить со своим. И только потом уже публиковаться, когда вы понимаете, что можете предложить хоть что-то новое и интересное.
Ну если погрепать - это будет исследование. И более-менее объективный результат (хотя реализация этого паттерна совсем не факт что содержит такое слово, BTW). Но я почему-то уверен, что ни вы, ни автор такого исследования не проводили.
Я все равно ведь не про это. Автор с парой лет опыта скорее всего никогда не использовала например Chain of Responsibility, или стратегию. Следует ли из этого, что они тоже не нужны?
Ведь по-хорошему, зачем вообще в курсах давать паттерны? Ведь явно совершенно не для того, чтобы ученики сразу начали их использовать на практике, все подряд. Ничего хорошего из этого не получается.
По крайней мере на мой взгляд, давать их стоит в такой форме, чтобы ученики понимали, что есть вот такая книга рецептов ("о вкусной и здоровой пище"), где описаны типовые решения типовых задач. А точнее - книги. Причем сразу отметить, что выглядеть эти решения (и сами задачи) будут сильно по-разному, если вы возьмете другой язык, другой фреймворк, и другие задачи наконец. Потому что для других задач есть например набор EIP (Enterprise Integration Patterns), с совсем другим набором паттернов.
И в такой постановке вполне можно рассказать классификацию паттернов, упомянуть любые из них, какие преподавателю в голову взбредет, просто чтобы проиллюстрировать, что такое типовая проблема, и из чего состоит типовое решение. И memento в этом смысле ничуть не хуже любого другого паттерна, и участвует в нем всего три класса (что даже совсем не много).
Ну как... пару поколений игроков уже сменилось. Хотя конечно, понятие давно - субъективное.
С точки зрения игры со сменой мячей поменялось очень многое. Поэтому продаваться оно конечно может, только вот этот вот TORRES - это товары, "напоминающие по виду настольный теннис". В магазинах которые профессионально торгуют товарами для тенниса, даже самые дешевые мячи из ABS. Хотя формально, по правилам, мяч может быть сделан из целлулоида, это правда. Размеры и вес нормированы, а к материалу никаких конкретных требований не предъявляется.
уже давно нет
Ну, коммуникабельность - это слишком узкий термин, как по мне. Ну или не очень точный.
Ну вот например, разве вас никогда не звали на встречу для обсуждения какой-то темы, куда приглашены скажем 10 человек, и при этом ни цели встречи, ни постановка проблемы, ни программа - не озвучены? Ну т.е. предлагается потратить скажем час рабочего времени 10 человек непонятно на что. Я такое вижу регулярно. И это именно что недостаток навыков общения. Только не просто общения - а эффективного общения. Причем, обратное тоже верное - иногда вместо того чтобы собраться и обсудить вживую на 10 минут, устраивается переписка на 10 дней.
Я бы это назвал способностью выстраивать эффективные коммуникации. И да, очень многие этого не умеют.
Зато (если я вас правильно понял), упоминание модели OSI в тексте такого рода сразу позволяет вам понять ценность(?), которую несет подобная статья, разве нет?
А вот ASN.1 я не понимаю, чем вам не угодила. Она просто работает. Скажем, мне недавно было нужно найти описание формата файлов кербероса (а конкретно keytab). Я был бы просто счастлив, если бы нашел ASN.1 нотацию - это означало бы, что я могу взять инструмент, и написать парсер. Но я ее не нашел - и в итоге, я имею три разных парсера, которые по разному парсят один и тот же файл.
Ну да, она возможно сто раз неудобная, и инструментарий для ее поддержки архаичный, что правда, то правда.
Ваш опыт вам вполне правильно подсказывает. От языка еще. Потому что в функциональном языке будут совсем другие типовые задачи и другие паттерны их решения (и их даже возможно так называть не будут).
Я скорее о том, что имея небольшой опыт, не стоит делать далеко идущие выводы о том, что нужно а что нет. Ведь все что вы знаете (реально знаете, а не думаете что знаете), это то, что вы какие-то паттерны не применяли. И не знаете, куда и зачем применить. Понимание того, насколько типовую проблему они решают, дает только опыт, ну или исследование.
Опять же, как по мне, я бы вообще начинающим про паттерны рассказывал только то, что они есть. И для чего нужны. Потому что осознанное их применение - оно за пределами имеющегося опыта. И как правило, попытки применить делают код только хуже.