Довольно много клавиатур умеют подключаться по 2.4 ГГц. Если китай не пугает и готовы ждать, то можете посмотреть на Akko и FL Esports, например. У них и для самостоятельной сборки были отдельные компоненты. Подсветки всякие разные - отключаются естественно.
Нет одного какого-то языка на все случаи жизни. Что-то удобнее делать на одном, что-то на другом. И упираться в "я пишу только на С/С++" непродуктивно. Разработчик - это прежде всего подходы к решению задач. А язык - инструмент. Знаешь несколько языков - можешь выбирать наиболее подходящий инструмент для решения конкретной задачи.
В целом, я согласен с этим утверждением.
Но, для некоторых задач может быть несколько оптимальных инструментов достижения поставленной цели. И здесь необходимо следовать регламентам и правилам, установленным в команде, в том числе и по стеку.
Специфика в том, что "будет работать быстрее" здесь является абсолютным приоритетом.
Технологический стек жестко определен. Кроме того, есть достаточно объемные "нефункциональные требования" - что можно что нельзя. На самом деле правил очень много.
Так в этом и суть - у вас есть правила и ограничения на стек, которые необходимы именно вашей команде. Эти правила были обоснованы, а не придуманы с потолка. Они призваны решать множество вопросов связанных с разработкой продукта, его приоритетов, кодовой базой и т.д. И если кто-то решит написать кусок проекта на Python, даже если он будет работать быстрее аналогичного кода на IBM RPG и С/С++ - это будет порицаться, надо будет переделывать на имеющийся стек, потому что есть ограничения.
В статье же прямо говорится, что подобное ограничение - "неразумно" и нуждается в переосмыслении. Прочитайте пункт 4 ("Мы пишем только натаком-то языке") в статье.
Дальше идет не менее важный кусок:
Если это опытный программист, и в большинстве случаев поступает разумно, то может и не надо его ограничивать всякой фигнёй — это уменьшение эффективности, да еще и снижение мотивации
И ежу понятно, что вникнуть в суть вашего стека и сделать задачу, в сравнении с реализацией этой задачи на известном кандидату стеке - менее эффективно по скорости разработки и меньше мотивирует кандидата, т.к. вместо написания кода и получения плюшек за сделанную задачу - придется потратить больше времени, лазить по документации в поисках нужных функций и только когда-то потом сделать задачу. Но несмотря на это, ограничения стека разумны и необходимы, чтобы итоговый продукт не превращался во франкенштейна.
У вас есть четко установленные рамки. Это разумный подход, без них - проект превратился бы именно в такую мешанину технологий в разных модулях.
Вы определились с ядром системы (IBM RPG, как я понял). Применение С/С++ - обосновано удобством разработки и быстродействием, а значит у вас в команде все (или какая-то часть) понимают и умеют писать на этих языках. И т.д. У вас все равно установлены определенные рамки по разработке, по допустимым технологиям и т.д.
Давайте просто допустим что в вашей команде я новенький и единственный знаю Python, в добавок к текущему стеку. Получаю задачу сделать какую-то фишку и я ее уже делал на Python в другом проекте, и хочу применить его здесь - это будет более эффективно, с точки зрения времени разработки, и более мотивированно, т.к. я смогу закрыть задачу. Правильно? Но что будет если никто не знает Python, или на условном С++ модуль будет работать быстрее?
Вы не можете по своему желанию или просто потому что знаете как что-то сделать на условном Python, использовать именно его для разработки какого-то модуля. Вам так же необходимо, как минимум, обосновать необходимость его применения перед командой и убедиться что есть другие разработчики, которые "умеют в Python". Это и есть те самые "ограничения всякой фигней", которые просто необходимы, дабы кодовая база оставалась в более-менее адекватном виде.
Если нет вообще никаких ограничений, то разработка очень быстро может скатиться в "Повелителя мух"
Если DRY, KISS и иже с ними доведено именно до непреложных правил и заповедей, то тут явно что-то не так. Если все еще и утрируется, как в примерах, то это уже надо звать людей в белых халатах. Можно же и SRP интерпретировать как необходимость создавать отдельное DTO для каждой операции над основным объектом...
Если это опытный программист, и в большинстве случаев поступает разумно, то может и не надо его ограничивать всякой фигнёй — это уменьшение эффективности, да еще и снижение мотивации
Ядро проекта пишем на Java, добавляем кусок на Python, пара кусков на Go, еще один прям микро-микросервис на PHP, обработку данных делаем на С++ и немного макросов в Excel.... Зато все очень эффективно и замотивировано было сделано. А потом разработчик, который был ответственен за вот эти все языковые "причуды", увольняется и вам приходится искать такого "многофункционального", эффективного и замотивированного разработчика на проект с непонятным стеком. Нормальная идея, да.
По факту же, DRY & KISS & другие заголовки - это скорее принципы, концепция, если хотите, которые позволяют держаться в некоторых рамках и с большей вероятностью получить на выходе качественный код, с которым будет удобно дальше работать, независимо от смены состава команды. И их нужно не просто прочитать и запомнить, а именно обдумать почему, что, как, где можно отойти, где нельзя и т.д. Все это приходит только с опытом.
И какие-то минимальные строгие рамки должны быть, иначе есть немалая вероятность, что на выходе получите кусок "продукта", с которым дальше никто не захочет работать, ибо разгребать авгиевы конюшни - неблагодарное дело.
Основная опасность в том, что компилятор не может корректно проверить ошибки при работе с dynamic объектом (вызов несуществующего метода и т.п.), они будут выявлены только во время выполнения программы. В dynamic можно записать все что угодно. Ну а когда тебе возвращается такое аморфное нечто - вероятность ошибки существенно возрастает. Какой бы не была нужда, в типизированных языках программирования - лучше всего возвращать объект конкретного типа или интерфейса.
чтобы в публикации работ не было больших пробелов. GitHub тоже показывает активность кандидата: в какие дни и где кандидат работал.
Большинство компаний запрещает публиковать рабочий код в открытые источники, для этого есть внутренняя система контроля версий. Другие причины даже называть не имеет смысла. Соответственно "пустой GitHub" или "большие пробелы" - никак не характеризуют кандидата.
умеет ли кратко презентовать себя как специалиста
И никаких общих критериев для этого нет. Для одного работодателя ты умеешь в самопрезентацию, рассказав про свой любимый мультфильм детства, для другого - не хватит и подробного описания всех рабочих проектов.
Если я публикую вакансию в этом месте, значит, мои взгляды совпадают с ценностями создателя канала и его аудитории.
А как работодатель смотрит на то, что HR ищет кандидата "под свои взгляды", а не взгляды компании? Одобряет ли тот факт, что HR отрезает добрую часть кандидатов, которые либо не знают про блогера/канал, либо не сходятся с ним во "взглядах"? На мой взгляд, это скорее "звоночек", что с компанией что-то не так. Как минимум, она не заботится о том, что бы сотрудники разделяли рабочие и личные моменты.
Как минимум не хватает третьего типа разработчика, который сочетает в себе черты первого и второго типов. Ибо из первого примера Тип 1 - прав, т.к. большинство людей поймет, если их просто попросить. Но если не понимают, или просто игнорируют, то плавно переходим к рассуждениями Типа 2. А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.
Довольно много клавиатур умеют подключаться по 2.4 ГГц. Если китай не пугает и готовы ждать, то можете посмотреть на Akko и FL Esports, например. У них и для самостоятельной сборки были отдельные компоненты. Подсветки всякие разные - отключаются естественно.
Так тут в комплекте идет возможность подключать по проводу, BLE и 2.4 Гц (usb приемник в комплекте). Да и у многих есть подобные возможности.
В целом, я согласен с этим утверждением.
Но, для некоторых задач может быть несколько оптимальных инструментов достижения поставленной цели. И здесь необходимо следовать регламентам и правилам, установленным в команде, в том числе и по стеку.
Так в этом и суть - у вас есть правила и ограничения на стек, которые необходимы именно вашей команде. Эти правила были обоснованы, а не придуманы с потолка. Они призваны решать множество вопросов связанных с разработкой продукта, его приоритетов, кодовой базой и т.д. И если кто-то решит написать кусок проекта на Python, даже если он будет работать быстрее аналогичного кода на IBM RPG и С/С++ - это будет порицаться, надо будет переделывать на имеющийся стек, потому что есть ограничения.
В статье же прямо говорится, что подобное ограничение - "неразумно" и нуждается в переосмыслении. Прочитайте пункт 4 ("Мы пишем только на таком-то языке") в статье.
Дальше идет не менее важный кусок:
И ежу понятно, что вникнуть в суть вашего стека и сделать задачу, в сравнении с реализацией этой задачи на известном кандидату стеке - менее эффективно по скорости разработки и меньше мотивирует кандидата, т.к. вместо написания кода и получения плюшек за сделанную задачу - придется потратить больше времени, лазить по документации в поисках нужных функций и только когда-то потом сделать задачу.
Но несмотря на это, ограничения стека разумны и необходимы, чтобы итоговый продукт не превращался во франкенштейна.
У вас есть четко установленные рамки. Это разумный подход, без них - проект превратился бы именно в такую мешанину технологий в разных модулях.
Вы определились с ядром системы (IBM RPG, как я понял). Применение С/С++ - обосновано удобством разработки и быстродействием, а значит у вас в команде все (или какая-то часть) понимают и умеют писать на этих языках. И т.д. У вас все равно установлены определенные рамки по разработке, по допустимым технологиям и т.д.
Давайте просто допустим что в вашей команде я новенький и единственный знаю Python, в добавок к текущему стеку. Получаю задачу сделать какую-то фишку и я ее уже делал на Python в другом проекте, и хочу применить его здесь - это будет более эффективно, с точки зрения времени разработки, и более мотивированно, т.к. я смогу закрыть задачу. Правильно? Но что будет если никто не знает Python, или на условном С++ модуль будет работать быстрее?
Вы не можете по своему желанию или просто потому что знаете как что-то сделать на условном Python, использовать именно его для разработки какого-то модуля. Вам так же необходимо, как минимум, обосновать необходимость его применения перед командой и убедиться что есть другие разработчики, которые "умеют в Python". Это и есть те самые "ограничения всякой фигней", которые просто необходимы, дабы кодовая база оставалась в более-менее адекватном виде.
Если нет вообще никаких ограничений, то разработка очень быстро может скатиться в "Повелителя мух"
Если DRY, KISS и иже с ними доведено именно до непреложных правил и заповедей, то тут явно что-то не так. Если все еще и утрируется, как в примерах, то это уже надо звать людей в белых халатах. Можно же и SRP интерпретировать как необходимость создавать отдельное DTO для каждой операции над основным объектом...
Ядро проекта пишем на Java, добавляем кусок на Python, пара кусков на Go, еще один прям микро-микросервис на PHP, обработку данных делаем на С++ и немного макросов в Excel.... Зато все очень эффективно и замотивировано было сделано. А потом разработчик, который был ответственен за вот эти все языковые "причуды", увольняется и вам приходится искать такого "многофункционального", эффективного и замотивированного разработчика на проект с непонятным стеком. Нормальная идея, да.
По факту же, DRY & KISS & другие заголовки - это скорее принципы, концепция, если хотите, которые позволяют держаться в некоторых рамках и с большей вероятностью получить на выходе качественный код, с которым будет удобно дальше работать, независимо от смены состава команды. И их нужно не просто прочитать и запомнить, а именно обдумать почему, что, как, где можно отойти, где нельзя и т.д. Все это приходит только с опытом.
И какие-то минимальные строгие рамки должны быть, иначе есть немалая вероятность, что на выходе получите кусок "продукта", с которым дальше никто не захочет работать, ибо разгребать авгиевы конюшни - неблагодарное дело.
Основная опасность в том, что компилятор не может корректно проверить ошибки при работе с dynamic объектом (вызов несуществующего метода и т.п.), они будут выявлены только во время выполнения программы.
В dynamic можно записать все что угодно. Ну а когда тебе возвращается такое аморфное нечто - вероятность ошибки существенно возрастает.
Какой бы не была нужда, в типизированных языках программирования - лучше всего возвращать объект конкретного типа или интерфейса.
Большинство компаний запрещает публиковать рабочий код в открытые источники, для этого есть внутренняя система контроля версий. Другие причины даже называть не имеет смысла.
Соответственно "пустой GitHub" или "большие пробелы" - никак не характеризуют кандидата.
И никаких общих критериев для этого нет. Для одного работодателя ты умеешь в самопрезентацию, рассказав про свой любимый мультфильм детства, для другого - не хватит и подробного описания всех рабочих проектов.
А как работодатель смотрит на то, что HR ищет кандидата "под свои взгляды", а не взгляды компании? Одобряет ли тот факт, что HR отрезает добрую часть кандидатов, которые либо не знают про блогера/канал, либо не сходятся с ним во "взглядах"?
На мой взгляд, это скорее "звоночек", что с компанией что-то не так. Как минимум, она не заботится о том, что бы сотрудники разделяли рабочие и личные моменты.
А на IOS разве можно использовать что-то кроме WebKit для браузеров?
Как минимум не хватает третьего типа разработчика, который сочетает в себе черты первого и второго типов.
Ибо из первого примера Тип 1 - прав, т.к. большинство людей поймет, если их просто попросить. Но если не понимают, или просто игнорируют, то плавно переходим к рассуждениями Типа 2.
А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.