Интересно, чем автор оригинала заслужил такое уважение, чтобы переводить его труды.
Периодически при поиске нужной информации сталкиваюсь с англоязычными публикациями, в которых написана откровенная чушь. Когда видно, что автор публикации не владеет темой достаточно глубоко.
В то же время у некоторых людей есть стойкое ощущение, что если статья написана на английском, значит она заслуживает особого внимания.
Лучше бы починили журнал буфера обмена. На 10ке было удобно перемещаться в нем стрелками, удалять ненужные записи по delete. В 11 мало того, что это больше не работает, так ещё и при работе мышью оно подлагивает и забагованное. Оставил заявку на фикс ещё когда 11 вышла, но всем пофиг.
Статические свойства для регистрации выглядят некрасиво, имхо.
Стандартный способ для подобных целей - атрибут. Нужные кассы декорируются атрибутом, который содержит данные необходимые для регистрации. Рефлексией выбираются все типы, декорированные нужным атрибутом и спокойно регистрируются.
В итоге у нас нет лишних статических свойств, интерфейс не замусорен непонятно чем.
А в остальном - идея хорошая. Встречал несколько реализаций ботов, написаны были гораздо хуже.
Я работал с ЯП, который хранит сорцы в бинарниках - CAVO. И это крайне не удобно, что ты завязан на свою IDE и её ограничения.
Элементарный кейс - когда нужно перенести код между проектами. Там это называется модуль. В одном модуле расположено множество типов. Единственный способ это сделать - сделать импорт/экспорт модуля.
И таких кейсов было много.
То есть если уж так делать, то нужно как минимум все их делательно продумать, чтобы этим не больно было пользоваться.
Судя по всему у автора мало опыта взаимодействия с LLM. Мой опыт показывает вполне логичную вещь - чем точнее запрос, тем точнее ответ. Поэтому ему необходимо сразу предоставить весь набор требований, чтобы не пришлось каждый раз просить его что-то исправить. Чем меньше ему дано информации, тем больше он её "додумывает".
Поэтому свои запросы в новом чате я всегда начинаю с указания языка программирования перечисления библиотек, которые используются в проекте и должны использоваться для решения задачи. А так же я стараюсь как можно точнее указать, что именно я ожидаю получить. И в большинстве случаев ответы такого уровня качества, что достаточно скопировать и вставить. Я ему прямо в запросе указываю типы и апи и он понимает как их нужно использовать.
Высока вероятность, что именно продавцы торгуют данными клиентов и заказов.
Приведу пример из жизни, пусть и отдалённо связанный с вашей ситуацией.
При покупке в магазинах часто предлагают завести бонусную карту. Для оформления обычно просят номер телефона, имя и дату рождения. Заметил закономерность, что после оформления подобных карт мне именно на следующий день начинают названивать мошенники. Ну и, конечно же, реклама. Недавно сменил симку, и какое-то время жил только с рекламой, пока не оформил новую бонусную карту.
Вот интересно получается. Некоторые люди вечно ноют, что вот где-то хорошо, а у нас ничего нет. И те же люди под любой новостью об отечественных разработках пишут море хейта и сарказма.
Так вы определитесь, вам нужно что-то своё или хорошо там, где нас нет?
Забавно, что ни один из примеров в статье не относится конкретно к Java. Разве что пример с кешем, хотя не уверен, что больше нет ЯП имеющих подобный кеш и аналог рефлексии.
Человек, который любит заниматься электроникой и программированием собственных устройств всегда ищет идеи, которые интересно было бы воплотить в жизнь. По себе знаю.
Иногда у этой идеи есть готовая альтернатива или аналог, но все же хочется создать это самому.
Иногда идея уникальна, но на самом деле полезна она только для автора и вероятно, небольшой группы людей.
И очень редко идея полезна широкому кругу людей и при этом коммерчески выгодна. Некоторые из таких со временем превращаются в бизнес.
Поэтому вопрос к DIY проектам типа "зачем" так часто возникает :)
Я не встречал, чтобы на собеседовании просили повторить реализацию паттерна. Но перечислить их и описать, какой для чего нужен, мне кажется, вполне нормально. Дело в том, что чтобы распознать ситуацию, когда можно применить какой-то паттерн, их в любом случае нужно помнить, хотя бы условно.
Я немного о другом. Довольно часто требуется создать механизм, задачи которого выходят за рамки классических паттернов. Иногда можно собрать его из 4+ паттернов, но результат получается сложным и запутанным. Вот как раз в таких ситуациях эффективнее спроектировать уникальный механизм под конкретную задачу. И сами идеи, которые стоят за паттернами, помогли мне создавать такие механизмы, которые обладают нужными свойствами.
Самое ценное в книгах дядюшки Боба – это ход его мыслей. Да, безусловно, неокрепший разум сразу пытается следовать его идеям точь в точь. Но это не проблема книги или автора.
Лично начал знакомиться с его книгами на третьем году коммерческого опыта разработки. И для меня стало открытием то, как автор рассуждает о каждой строке кода.
Если до этого я писал код, чтобы он работал (ну и выглядел симпатично), то после я начал прорабатывать множество вариантов реализации в попытках достичь определённых свойств написанного кода.
И вот, спустя 6 лет я могу детально объяснить почему конкретную строку или выражение написал именно так. Да, я не следую его рекомендациям. Я даже смутно помню их. Но способ мыслить оказался бесценен.
P. S. То же самое с паттернами проектирования. Знакомство с ними объяснило саму суть ООП и для чего все это нужно. Я вряд ли смогу по памяти повторить один в один какой-либо паттерн, кроме простейших. Но я понимаю идеи, которые за ними стоят. И реализую решения, которые нужны для конкретной ситуации со всеми её нюансами.
Зачастую, весь процесс от запроса до размещения креатива на сайте должен занимать не более 150 мс, т.е. то время за которое у пользователя с хорошим интернетом загружается web-страница. Чтобы отвечать этому требованию бэк платформ, как правило, пишется на языках под JVM (встречал на своей практике на Java, Scala) или еще на Rust.
Звучит, мягко говоря, странно. Поставить Java и Rust в одну категорию? Если Java справляется за 150 мс, то, скорее всего, за это время справится любой ЯП, кроме Python.
Поэтому лучше было написать так:
Поэтому Python здесь не подходит.
А вообще, то, что JVM часто используется скорее всего не связано с 150 мс. Вывод притянутый за уши.
Грандиозная работа! Моё почтение.
Интересно, чем автор оригинала заслужил такое уважение, чтобы переводить его труды.
Периодически при поиске нужной информации сталкиваюсь с англоязычными публикациями, в которых написана откровенная чушь. Когда видно, что автор публикации не владеет темой достаточно глубоко.
В то же время у некоторых людей есть стойкое ощущение, что если статья написана на английском, значит она заслуживает особого внимания.
Лучше бы починили журнал буфера обмена. На 10ке было удобно перемещаться в нем стрелками, удалять ненужные записи по delete. В 11 мало того, что это больше не работает, так ещё и при работе мышью оно подлагивает и забагованное. Оставил заявку на фикс ещё когда 11 вышла, но всем пофиг.
Множество раз пользовался данной библиотекой, но даже не подозревал, что среди её создателей столько земляков. Молодцы ребята!
Статические свойства для регистрации выглядят некрасиво, имхо.
Стандартный способ для подобных целей - атрибут. Нужные кассы декорируются атрибутом, который содержит данные необходимые для регистрации. Рефлексией выбираются все типы, декорированные нужным атрибутом и спокойно регистрируются.
В итоге у нас нет лишних статических свойств, интерфейс не замусорен непонятно чем.
А в остальном - идея хорошая. Встречал несколько реализаций ботов, написаны были гораздо хуже.
Я работал с ЯП, который хранит сорцы в бинарниках - CAVO. И это крайне не удобно, что ты завязан на свою IDE и её ограничения.
Элементарный кейс - когда нужно перенести код между проектами. Там это называется модуль. В одном модуле расположено множество типов. Единственный способ это сделать - сделать импорт/экспорт модуля.
И таких кейсов было много.
То есть если уж так делать, то нужно как минимум все их делательно продумать, чтобы этим не больно было пользоваться.
Молодцы, ребята!
Но сделайте грозы золотыми, а не темно-синими. Я три раза пересматривал видео чтобы заметить о каких грозах идёт речь.
Судя по всему у автора мало опыта взаимодействия с LLM. Мой опыт показывает вполне логичную вещь - чем точнее запрос, тем точнее ответ. Поэтому ему необходимо сразу предоставить весь набор требований, чтобы не пришлось каждый раз просить его что-то исправить. Чем меньше ему дано информации, тем больше он её "додумывает".
Поэтому свои запросы в новом чате я всегда начинаю с указания языка программирования перечисления библиотек, которые используются в проекте и должны использоваться для решения задачи. А так же я стараюсь как можно точнее указать, что именно я ожидаю получить. И в большинстве случаев ответы такого уровня качества, что достаточно скопировать и вставить. Я ему прямо в запросе указываю типы и апи и он понимает как их нужно использовать.
Высока вероятность, что именно продавцы торгуют данными клиентов и заказов.
Приведу пример из жизни, пусть и отдалённо связанный с вашей ситуацией.
При покупке в магазинах часто предлагают завести бонусную карту. Для оформления обычно просят номер телефона, имя и дату рождения. Заметил закономерность, что после оформления подобных карт мне именно на следующий день начинают названивать мошенники. Ну и, конечно же, реклама. Недавно сменил симку, и какое-то время жил только с рекламой, пока не оформил новую бонусную карту.
Потому что адекватные люди пишут компиляторы только на нативных языках. Ничего странного здесь нет.
C# one love ❤️
Вот интересно получается. Некоторые люди вечно ноют, что вот где-то хорошо, а у нас ничего нет. И те же люди под любой новостью об отечественных разработках пишут море хейта и сарказма.
Так вы определитесь, вам нужно что-то своё или хорошо там, где нас нет?
Боже упаси оказаться в одной команде с автором данной статьи. Или же работать с его наследием.
Забавно, что ни один из примеров в статье не относится конкретно к Java. Разве что пример с кешем, хотя не уверен, что больше нет ЯП имеющих подобный кеш и аналог рефлексии.
Человек, который любит заниматься электроникой и программированием собственных устройств всегда ищет идеи, которые интересно было бы воплотить в жизнь. По себе знаю.
Иногда у этой идеи есть готовая альтернатива или аналог, но все же хочется создать это самому.
Иногда идея уникальна, но на самом деле полезна она только для автора и вероятно, небольшой группы людей.
И очень редко идея полезна широкому кругу людей и при этом коммерчески выгодна. Некоторые из таких со временем превращаются в бизнес.
Поэтому вопрос к DIY проектам типа "зачем" так часто возникает :)
Очень интересно, но нибуя не понятно.
Я не встречал, чтобы на собеседовании просили повторить реализацию паттерна. Но перечислить их и описать, какой для чего нужен, мне кажется, вполне нормально. Дело в том, что чтобы распознать ситуацию, когда можно применить какой-то паттерн, их в любом случае нужно помнить, хотя бы условно.
Я немного о другом. Довольно часто требуется создать механизм, задачи которого выходят за рамки классических паттернов. Иногда можно собрать его из 4+ паттернов, но результат получается сложным и запутанным. Вот как раз в таких ситуациях эффективнее спроектировать уникальный механизм под конкретную задачу. И сами идеи, которые стоят за паттернами, помогли мне создавать такие механизмы, которые обладают нужными свойствами.
Самое ценное в книгах дядюшки Боба – это ход его мыслей. Да, безусловно, неокрепший разум сразу пытается следовать его идеям точь в точь. Но это не проблема книги или автора.
Лично начал знакомиться с его книгами на третьем году коммерческого опыта разработки. И для меня стало открытием то, как автор рассуждает о каждой строке кода.
Если до этого я писал код, чтобы он работал (ну и выглядел симпатично), то после я начал прорабатывать множество вариантов реализации в попытках достичь определённых свойств написанного кода.
И вот, спустя 6 лет я могу детально объяснить почему конкретную строку или выражение написал именно так. Да, я не следую его рекомендациям. Я даже смутно помню их. Но способ мыслить оказался бесценен.
P. S. То же самое с паттернами проектирования. Знакомство с ними объяснило саму суть ООП и для чего все это нужно. Я вряд ли смогу по памяти повторить один в один какой-либо паттерн, кроме простейших. Но я понимаю идеи, которые за ними стоят. И реализую решения, которые нужны для конкретной ситуации со всеми её нюансами.
Не знаю сколько времени займёт сбор команды QT разработчиков. Но, как десктоп разработчик скажу следующее.
Сейчас 99% вакансий – веб. И лишь 1% десктоп. И, вероятно, во многом, это заслуга таких фреймворков как Electron.
И это прискорбно.
Зачастую, весь процесс от запроса до размещения креатива на сайте должен занимать не более 150 мс, т.е. то время за которое у пользователя с хорошим интернетом загружается web-страница. Чтобы отвечать этому требованию бэк платформ, как правило, пишется на языках под JVM (встречал на своей практике на Java, Scala) или еще на Rust.Звучит, мягко говоря, странно. Поставить Java и Rust в одну категорию? Если Java справляется за 150 мс, то, скорее всего, за это время справится любой ЯП, кроме Python.
Поэтому лучше было написать так:
Поэтому Python здесь не подходит.А вообще, то, что JVM часто используется скорее всего не связано с 150 мс. Вывод притянутый за уши.