Нет противоречий. В моем конструкторе создается абстрактный класс (лямбда в данном случае), в котором и есть код, выполняющий действие. Это нельзя назвать "код в конструкторе", так как он не выполняется при инстанцировании объекта
Для него нет пояснения, он взят из официальной документации JakartaMail. Получается, что по официальной документации нет нормального подхода для выуживания текста из электронного письма
Спасибо! Это следующий этап после тестирования с помощью Composite builds :) Выглядит элегантно и позволяет делать более гибкие проверки результата тестирования. Обязательно попробую в своих проектах.
"Негр" — это просто метка, чтобы как-то отличать человека с темной кожей от человека со светлой кожей.
Лучше бы было X, чем "проблемный", ведь там есть слово с заранее негативным контекстом, что меня бы, к примеру, могло оскорбить) да, суть я понял, вы тоже по своему правы, но все ж таки, чтобы статья казалась более объективной, стоило использовать другие метки.
Расизм называть в этой ситуации инженера проблемным. Это вся команда проблемная) а инженеру надо искать другую работу, раз за спиной его "проблемным" обзывают. Плюс в команде нормально перерабатывать (как я понял по прямым намекам на то, что "проблемный" не перерабатывает и ценит свое личное время) — это не проблема? В общем я за то, чтобы уволить менеджера, ну то есть того, кто в этой статье руководитель разработки.
Просто хочу написать, что ты, парень, не один такой :) я тут в свободное от работы время пишу чат-бот с использованием инструментов, которые написал самостоятельно и которые являются велосипедами, потому что на рынке уже полно подобных вещей. И я не могу открыть код своего чат бота только потому, что пацаны скажут "Велосипед же используешь, сделал бы лучше на <всем известная библиотека>". Даже больше того, я переживаю и не могу просто так взять и пригласить в проект нового разработчика, потому что он с порога скажет мне, что в проекте одни велосипеды и он не будет с этим работать. Поэтому я и дальше буду изобретать велосипеды, чтобы удобства этих велосипедов хватило поддерживать и развивать этот продукт без потерей для бизнеса.
Вобщем я полностью согласен и поддерживаю мысли автора в этой статье!
А если у меня, допустим, семья, (или, упаси бог, я в свободное время не хочу писать код, а хочу заниматься своими хобби)?
Да, свободное время — это личное для каждого. Естественно, что не все программеры тратят свободное время на OpenSource. Но давайте на секундочку вспомним, когда последний раз мы использовали OpenSource в своем коде на работе? Кажется, каждый день, потому что доля открытого кода в большинстве проектов на ваше удивление — гигантская. Неужели ни разу не было случая, когда нужно было создать issue в гитхаб или подправить код вашей любимой OpenSource библиотеки? И ни разу не надо было вопросы на SO создавать? Во многих компаниях есть культура OpenSource, то есть вы можете в рабочее время коммитить в открытый репозиторий GitHub — ну так покажите, какой вклад вы там внесли. Неужели ни разу вы не разбирались в какой-то теме так хорошо, что могли бы рассказать о ней всем в виде доклада на конференции или технической статьи? Пусть после работы вам некогда, но потратьте рабочее время на это, объясните своему руководству, что вы занимаетесь документированием вашего крутого алгоритма, и выложите этот документ на habr, или еще лучше вместе с исходниками в GitHub. Что, GDPR? Ну так просто не выкладывайте данные клиентов компании. Ваш код скорее всего не нужен никому, он решает какую-то конкретную проблему, и скорее всего договориться с руководством о его открытии будет очень просто.
Дело не в отсутствии свободного времени на эти задачи, а в общем понимании того, как работает IT рынок, и как вам в нем двигаться как профессионалу.
А как проверить, что этот код на гитхабе написал именно этот человек, и он не скопипащщен откуда-то? Блоги, выступления и статьи — это слишком нишевая область, чтобы всех массово по этому оценивать.
Если вы работали над этим проектом, то никакой проблемы не возникнет посмотреть в историю git. Историю git можно подделать? Ну камон, кто-то серьезно будет этим заниматься? Ну вас на беседе спросят об особенностях этого проекта, и вот тут вы ничего подделать не сможете. Вот представьте год работы над собственным открытым проектом на GitHub. Представили? Так вот, там будет около 500 коммитов или больше, за это время, если вы сделали что-то интересное, у проекта появятся пользователи, они будут создавать вам issue, вам придется на них реагировать, писать пулреквесты чтобы закрыть эти issue. Это не подделать. Проект либо ваш, либо вы над ним еще мало трудились.
Но если кандидат — такая звезда, неужели он так и не смог прочитать одну книжку типа "Cracking code interview"? Голова у такого гения варит — ему и времени на подготовку тратить-то почти не надо.
Не в звездах дело. Если вы занимаетесь своей работой инженера — вы звезда? Вот вы пишете каждый день, скажем, чат бот для телеги, например на java на протяжении двух лет. Java SDK для бота телеги — не совершенное, за два года вы словите там не один десяток багов, вам будет не хватать его функциональности, и вам, если вы понимаете, что такое разработка, прийдется создавать issue и пулреквесты в Java SDK для бота. И вот через два года — вы уже активный контрибьютор в этой библиотеке. Что, вы звездой стали? Да нет, это обычная работа. За эти два года вам прийдется задавать вопросы на SO, потому что вы будете искать ответы, чтобы решить какую-то адски-сложную задачу, поставленную бизнесом, а там, внезапно, версия джавы не позволяет использовать последние сертификаты безопасности, и вы об этом узнали только благодаря вопросу, заданному на SO — и вот они, шаги к контрибьюту в SO в рабочее время (без отнимания этого времени от жены/мужа и детей). А дальше за два года работы над одним проектом вы по-любому сделали надстройку над той Java SDK для ботов, и она вся такая абстрактная гибкая и удобная, что вы захотите поделиться ей с соседом, или со всем миром, если уговорите своего босса выложить ее в GitHub, и потом еще статью напишете в habr. И что, вы звезда? Нет, вы простой инженер, вам дело нет до звезд ИТ индустрии, вы выполняете свою работу, и делаете себя дороже на рынке программистов, потому что хотите Range Rover.
Ух, слишком долго я веду к мысли — то, что делает программиста дороже (делает "звездой", как вы выразились) не означает, что он хорошо шарит в алгоритмах. Он хорошо шарит в разработке ПО, он знает, кто пишет код, к кому обратиться за помощью, где найти готовую реализацию известного алгоритма, он знает, как общаться с людьми при разработке продуктов. Он не звезда, он просто делает свою работу, и алгоритмы в ней — это такая капля в море, которую и замечать не всегда надо. Есть люди, которые пишут сайтики за $80 в час на RubyOnRails и не знают сколько будет 2^8. Вы думаете они плохие программисты? Нет, рынок их оценил в $80 в час за их умение вести разработку веб сайтов, потому что у них есть профиль на GitHub с готовыми примерами их работ.
Проверять программиста по алгоритмам на листочке (ну или не на листочке, а в браузере в специальном сервисе, которой так далек от IDE) — это самое последнее средство, которым нужно пользоваться, если и только если, на рынке об этом программисте ничего не видно/не слышно. Я имею ввиду код на GitHub, ответы на SO, выступления на конференциях, участие в OpenSource, технический блог, статьи в технических/научных изданиях — вот это все оценивает программиста лучше, чем онлайн решение стандартного алгоритма на собеседовании. Более того, те способы, которые я указал, при проверке кандидата не требуют участия самого кандидата, то есть можно отбирать программистов не по резюме, не по беседе (это все важно, но на следующем этапе), а по реально сделанным им делам (написанному коду, если хотите быть ближе к алгоритмам), которые свободно доступны на рынке. Эти способы дадут о программисте многообразную информацию: командная работа, знание git-flow, умение работать с трекинговой системой, умение общаться с другими разработчиками (ваши любимые SOFT SKILLS), знание основных библиотек, применение паттенрнов, понимание фреймворков, чистоту кода.
Думаю, в подобном стиле можно было бы написать статью про важность unit-тестов, про неотъемлемый статический анализ, про необходимость CI/CD, про обеспечение качества с помощью команды QA. И в 99% знание подобных процессов важнее знания написать бинарный поиск без ошибки (может, потому что стандартные алгоритмы обработки данных уже реализованы?...).
Но на собеседованиях все равно продолжают просить написать очередной абстракный fizz-buzz (а на работе в таких компаниях просят еще писать код без ошибок).
Остановитесь! Вы спрашиваете алгоритмы не потому что они действительно требуются инженерам в ежедневных задачах, а потому что вы по-другому не научились отбирать кандидатов! Я не хочу работать в команде, где разработчиков нанимают по зазубренным стандартным наборам алгоритмов/вопросов, к которым нужно еще и готовиться (видимо, чтобы угодить собеседующим, лицемерие), потому что в таких командах о разработке, как о процессе, не знают ровным счетом ничего.
Эм, а как связана "пытливость ума" и "красивый код, который не стыдно показать"? Человек может быть пытливым, но не пишет Unit-тесты. Знаете, почему? Потому что когда есть пытливый ум — не нужны Unit-тесты :) Это все смешочки, конечно, но очень часто я вижу "пытливые умы", которые пишут нетестируемый код.
В свою очередь, часто бывают и другие (хотя таких меньше), которые пишут хороший код, тестируют его, оформляют для пацанов, не забывают про CI/CD, следуют процессам, но решать сложные задачи у них не получается, не хватает "пытливости ума".
Это я все к чему. "Пытливый ум" — это хорошо, но чтобы быть хорошим инженером — нужно еще и следовать процессам и соблюдать подходы в программировании.
Большинство программистов при обнаружении проблем используют другой инструмент для поиска решений. Чаще всего это google, или stackoverflow. Очень малая часть программистов (я бы даже сказал, что это исключение из правила) использует git log --grep, когда у них произошла ошибка кодировки при выполнении скриптов в проекте.
Я — автор комментария. Там в проекте 27к коммитов в проекте, а именно этот коммит был сделан на изменение одного символа. Вся информация в сообщении этого коммита без сомнения ценна и полезна, с деталями, с историей, однако она ничего не стоит, поскольку найти эту информацию будет невозможно, так как сообщение в коммите к изменению одного символа является труднодоступной информацией. Проект когда-то заплатил за эту информацию, но теперь она не стоит ничего, поскольку бесполезно барахтается в море из 27к коммитов. Сможет ли найти эту информацию будущий участник проекта, если столкнется с той же ошибкой? Сообщения к коммитам не гуглятся. А если воспользоваться поиском по гитхабу — то будет слишком много информации на выходе, можете попробовать. Вместо того, чтобы писать такое длинное труднодоступное сообщение (файла, к которому был сделан этот "мой любимый git-коммит" уже нет в проекте — modules/router/templates/, поэтому найти этот коммит еще сложнее), можно было бы написать тест, который проверит кодировку в проекте. Можно было бы написать где-то в readme топик с информацией о используемой кодировке и почему.
Потому что глобальная переменная противоречит DI (dependency injection). Использование глобальные переменных снижает возможность переиспользования кода. dl.acm.org/citation.cfm?id=953355 — вот классная статья, почитайте!
2) Почему глобальные переменные это не процедурное программирование? Есть доказательство?
3) Да, я ошибочно ответил, просто когда я отвечал, это был последний комментарий, и я по ошибке нажал на ответить, а не добавил новый комментарий. Классно, что нашли ошибку в статье, но она никак не связана с огромным неконструктивным негативом в других комментариях.
4) В статье каждое утверждение доказывается каким-либо образом, примерами, логическими связями
Тот способ, на который вы указали, является эмоциональным выражением и больше ничем. Предполагаю, что слово «фанатик» в этом контексте больше негативное, и, точно уверен, ничего конструктивного в нем нет.
T9 :) который превращается в T900 :)
Спасибо! Поправил ссылку.
Нет противоречий. В моем конструкторе создается абстрактный класс (лямбда в данном случае), в котором и есть код, выполняющий действие. Это нельзя назвать "код в конструкторе", так как он не выполняется при инстанцировании объекта
Для него нет пояснения, он взят из официальной документации JakartaMail. Получается, что по официальной документации нет нормального подхода для выуживания текста из электронного письма
Спасибо! Это следующий этап после тестирования с помощью Composite builds :) Выглядит элегантно и позволяет делать более гибкие проверки результата тестирования. Обязательно попробую в своих проектах.
"Негр" — это просто метка, чтобы как-то отличать человека с темной кожей от человека со светлой кожей.
Лучше бы было X, чем "проблемный", ведь там есть слово с заранее негативным контекстом, что меня бы, к примеру, могло оскорбить) да, суть я понял, вы тоже по своему правы, но все ж таки, чтобы статья казалась более объективной, стоило использовать другие метки.
Расизм называть в этой ситуации инженера проблемным. Это вся команда проблемная) а инженеру надо искать другую работу, раз за спиной его "проблемным" обзывают. Плюс в команде нормально перерабатывать (как я понял по прямым намекам на то, что "проблемный" не перерабатывает и ценит свое личное время) — это не проблема? В общем я за то, чтобы уволить менеджера, ну то есть того, кто в этой статье руководитель разработки.
Просто хочу написать, что ты, парень, не один такой :) я тут в свободное от работы время пишу чат-бот с использованием инструментов, которые написал самостоятельно и которые являются велосипедами, потому что на рынке уже полно подобных вещей. И я не могу открыть код своего чат бота только потому, что пацаны скажут "Велосипед же используешь, сделал бы лучше на <всем известная библиотека>". Даже больше того, я переживаю и не могу просто так взять и пригласить в проект нового разработчика, потому что он с порога скажет мне, что в проекте одни велосипеды и он не будет с этим работать. Поэтому я и дальше буду изобретать велосипеды, чтобы удобства этих велосипедов хватило поддерживать и развивать этот продукт без потерей для бизнеса.
Вобщем я полностью согласен и поддерживаю мысли автора в этой статье!
Да, свободное время — это личное для каждого. Естественно, что не все программеры тратят свободное время на OpenSource. Но давайте на секундочку вспомним, когда последний раз мы использовали OpenSource в своем коде на работе? Кажется, каждый день, потому что доля открытого кода в большинстве проектов на ваше удивление — гигантская. Неужели ни разу не было случая, когда нужно было создать issue в гитхаб или подправить код вашей любимой OpenSource библиотеки? И ни разу не надо было вопросы на SO создавать? Во многих компаниях есть культура OpenSource, то есть вы можете в рабочее время коммитить в открытый репозиторий GitHub — ну так покажите, какой вклад вы там внесли. Неужели ни разу вы не разбирались в какой-то теме так хорошо, что могли бы рассказать о ней всем в виде доклада на конференции или технической статьи? Пусть после работы вам некогда, но потратьте рабочее время на это, объясните своему руководству, что вы занимаетесь документированием вашего крутого алгоритма, и выложите этот документ на habr, или еще лучше вместе с исходниками в GitHub. Что, GDPR? Ну так просто не выкладывайте данные клиентов компании. Ваш код скорее всего не нужен никому, он решает какую-то конкретную проблему, и скорее всего договориться с руководством о его открытии будет очень просто.
Дело не в отсутствии свободного времени на эти задачи, а в общем понимании того, как работает IT рынок, и как вам в нем двигаться как профессионалу.
Если вы работали над этим проектом, то никакой проблемы не возникнет посмотреть в историю git. Историю git можно подделать? Ну камон, кто-то серьезно будет этим заниматься? Ну вас на беседе спросят об особенностях этого проекта, и вот тут вы ничего подделать не сможете. Вот представьте год работы над собственным открытым проектом на GitHub. Представили? Так вот, там будет около 500 коммитов или больше, за это время, если вы сделали что-то интересное, у проекта появятся пользователи, они будут создавать вам issue, вам придется на них реагировать, писать пулреквесты чтобы закрыть эти issue. Это не подделать. Проект либо ваш, либо вы над ним еще мало трудились.
Не в звездах дело. Если вы занимаетесь своей работой инженера — вы звезда? Вот вы пишете каждый день, скажем, чат бот для телеги, например на java на протяжении двух лет. Java SDK для бота телеги — не совершенное, за два года вы словите там не один десяток багов, вам будет не хватать его функциональности, и вам, если вы понимаете, что такое разработка, прийдется создавать issue и пулреквесты в Java SDK для бота. И вот через два года — вы уже активный контрибьютор в этой библиотеке. Что, вы звездой стали? Да нет, это обычная работа. За эти два года вам прийдется задавать вопросы на SO, потому что вы будете искать ответы, чтобы решить какую-то адски-сложную задачу, поставленную бизнесом, а там, внезапно, версия джавы не позволяет использовать последние сертификаты безопасности, и вы об этом узнали только благодаря вопросу, заданному на SO — и вот они, шаги к контрибьюту в SO в рабочее время (без отнимания этого времени от жены/мужа и детей). А дальше за два года работы над одним проектом вы по-любому сделали надстройку над той Java SDK для ботов, и она вся такая абстрактная гибкая и удобная, что вы захотите поделиться ей с соседом, или со всем миром, если уговорите своего босса выложить ее в GitHub, и потом еще статью напишете в habr. И что, вы звезда? Нет, вы простой инженер, вам дело нет до звезд ИТ индустрии, вы выполняете свою работу, и делаете себя дороже на рынке программистов, потому что хотите Range Rover.
Ух, слишком долго я веду к мысли — то, что делает программиста дороже (делает "звездой", как вы выразились) не означает, что он хорошо шарит в алгоритмах. Он хорошо шарит в разработке ПО, он знает, кто пишет код, к кому обратиться за помощью, где найти готовую реализацию известного алгоритма, он знает, как общаться с людьми при разработке продуктов. Он не звезда, он просто делает свою работу, и алгоритмы в ней — это такая капля в море, которую и замечать не всегда надо. Есть люди, которые пишут сайтики за $80 в час на RubyOnRails и не знают сколько будет 2^8. Вы думаете они плохие программисты? Нет, рынок их оценил в $80 в час за их умение вести разработку веб сайтов, потому что у них есть профиль на GitHub с готовыми примерами их работ.
Проверять программиста по алгоритмам на листочке (ну или не на листочке, а в браузере в специальном сервисе, которой так далек от IDE) — это самое последнее средство, которым нужно пользоваться, если и только если, на рынке об этом программисте ничего не видно/не слышно. Я имею ввиду код на GitHub, ответы на SO, выступления на конференциях, участие в OpenSource, технический блог, статьи в технических/научных изданиях — вот это все оценивает программиста лучше, чем онлайн решение стандартного алгоритма на собеседовании. Более того, те способы, которые я указал, при проверке кандидата не требуют участия самого кандидата, то есть можно отбирать программистов не по резюме, не по беседе (это все важно, но на следующем этапе), а по реально сделанным им делам (написанному коду, если хотите быть ближе к алгоритмам), которые свободно доступны на рынке. Эти способы дадут о программисте многообразную информацию: командная работа, знание git-flow, умение работать с трекинговой системой, умение общаться с другими разработчиками (ваши любимые SOFT SKILLS), знание основных библиотек, применение паттенрнов, понимание фреймворков, чистоту кода.
Думаю, в подобном стиле можно было бы написать статью про важность unit-тестов, про неотъемлемый статический анализ, про необходимость CI/CD, про обеспечение качества с помощью команды QA. И в 99% знание подобных процессов важнее знания написать бинарный поиск без ошибки (может, потому что стандартные алгоритмы обработки данных уже реализованы?...).
Но на собеседованиях все равно продолжают просить написать очередной абстракный fizz-buzz (а на работе в таких компаниях просят еще писать код без ошибок).
Остановитесь! Вы спрашиваете алгоритмы не потому что они действительно требуются инженерам в ежедневных задачах, а потому что вы по-другому не научились отбирать кандидатов! Я не хочу работать в команде, где разработчиков нанимают по зазубренным стандартным наборам алгоритмов/вопросов, к которым нужно еще и готовиться (видимо, чтобы угодить собеседующим, лицемерие), потому что в таких командах о разработке, как о процессе, не знают ровным счетом ничего.
Эм, а как связана "пытливость ума" и "красивый код, который не стыдно показать"? Человек может быть пытливым, но не пишет Unit-тесты. Знаете, почему? Потому что когда есть пытливый ум — не нужны Unit-тесты :) Это все смешочки, конечно, но очень часто я вижу "пытливые умы", которые пишут нетестируемый код.
В свою очередь, часто бывают и другие (хотя таких меньше), которые пишут хороший код, тестируют его, оформляют для пацанов, не забывают про CI/CD, следуют процессам, но решать сложные задачи у них не получается, не хватает "пытливости ума".
Это я все к чему. "Пытливый ум" — это хорошо, но чтобы быть хорошим инженером — нужно еще и следовать процессам и соблюдать подходы в программировании.
Большинство программистов при обнаружении проблем используют другой инструмент для поиска решений. Чаще всего это google, или stackoverflow. Очень малая часть программистов (я бы даже сказал, что это исключение из правила) использует
git log --grep, когда у них произошла ошибка кодировки при выполнении скриптов в проекте.Я — автор комментария. Там в проекте 27к коммитов в проекте, а именно этот коммит был сделан на изменение одного символа. Вся информация в сообщении этого коммита без сомнения ценна и полезна, с деталями, с историей, однако она ничего не стоит, поскольку найти эту информацию будет невозможно, так как сообщение в коммите к изменению одного символа является труднодоступной информацией. Проект когда-то заплатил за эту информацию, но теперь она не стоит ничего, поскольку бесполезно барахтается в море из 27к коммитов. Сможет ли найти эту информацию будущий участник проекта, если столкнется с той же ошибкой? Сообщения к коммитам не гуглятся. А если воспользоваться поиском по гитхабу — то будет слишком много информации на выходе, можете попробовать. Вместо того, чтобы писать такое длинное труднодоступное сообщение (файла, к которому был сделан этот "мой любимый git-коммит" уже нет в проекте — modules/router/templates/, поэтому найти этот коммит еще сложнее), можно было бы написать тест, который проверит кодировку в проекте. Можно было бы написать где-то в readme топик с информацией о используемой кодировке и почему.
3) Да, я ошибочно ответил, просто когда я отвечал, это был последний комментарий, и я по ошибке нажал на ответить, а не добавил новый комментарий. Классно, что нашли ошибку в статье, но она никак не связана с огромным неконструктивным негативом в других комментариях.
4) В статье каждое утверждение доказывается каким-либо образом, примерами, логическими связями
Тот способ, на который вы указали, является эмоциональным выражением и больше ничем. Предполагаю, что слово «фанатик» в этом контексте больше негативное, и, точно уверен, ничего конструктивного в нем нет.