Ну правильно. А как по вашему производится сортировка, например, текстовых значений? У строки текста вообще невозможно вычислить значение. Однако, у нас есть "функция оракул", которая может сравнить две строки и сказать какая больше. Благодаря этому мы можем и произвести оптимизацю в виде поиска наименьшего значения, и отсортировать список.
Кстати, это очень распространённый базовый принцип в программировании, из которого дальше выросли и другие, например Inversion of Control и Interface Segregation Principle.
Погодите-погодите. Это кто это раньше рисовал блок схему по коду? Это называется reverse engineering. В нормальных учебных заведениях учат сначала составлять алгоритм в виде блок схемы (пусть то на бумаге или в голове), а затем писать код. Многие умельцы делали это наоборот, но в таком виде это не имеет смысла, разве что для того чтобы написать отчёт. Но концептуально блок схема всегда первична, и уже из неё пишется код. И правильность логики также проверяется на блок схеме.
Так что прогресс свернул очень даже туда! Отдавая процесс написания кода в руки ИИ, следует вспомнить незаслуженно забытые блок схемы, как абстрактный и пригодный именно для человека формат описания алгоритмов и логики. Недаром визуальное представление всё чаще всплывает в современных системах, особенно для workflows и автоматизаций.
Вот это я понимаю, популярная тема. Все кому не лень написали своё мнение. Теперь моя очередь, хотя вряд-ли кто-то его вообще прочитает среди такого количества.
А вот согласитесь, все таки здорово что все эти SOLID, DRY, KISS, YAGNI принципы существуют, так же как и шаблоны проектирования. Мы все их знаем, понимаем, где-то что-то используем, распознаём в коде, и вообще обсуждаем структуру решений в этих терминах. Как-то сложнее было бы на пальцах всегда без них. Но что сейчас особенно важно и актуально, так это то что эти принципы теперь понимает и использует ИИ для генерации кода. Тем самым мы можем быть немного более уверены в качестве кода, если он следует этим принципам. Вместо бремени на реализацию это превращается в контроль над качеством.
А теперь представьте, что вы разрабатываете не маленькую фичу, а очень большое корпоративное приложение чужими руками (будь то люди или ИИ) и у вас есть возможность либо принудить всех следовать тому же SOLID, либо разрешить всем "решать на месте индивидуально". Что бы вы выбрали, согласованность или зоопарк? В обоих вариантах будут где-то менее где-то более удачные реализации. Но согласитесь, что следование общим принципам будет намного более выйгрышным в глобальном плане для проекта.
(Ну а если вы сами девелопите свой стартап, небольшой интернет магазин, или пет проект - городите что хотите. Нет смысла во всех этих выкрутасах с перспективой на будущее. Не будет там никакой перспективы. Нечего и планировать, что хобби проект перерастёт в энтерпрайз решение. А у стартапа будет ещё много возможностей всё переделать, если вдруг что-то выгорит.)
"С недавним появлением концепции порядковых оракулов исследователи начали изменять подходы к оптимизации"
То есть в математике концепция "порядковых оракулов" появилась недавно? А вот в программировании такая концепция существует уже много десятилетий. Все классические алгоритмы сортировки основаны на этой концепции, бинарный поиск, дерево поиска, а затем по цепочке притягиваются базы данных и вообще весь IT. Потому что эти алгоритмы определены для любых объектов, и необходимо только задать функцию оракула сравнения, которая попарно может сравнивать эти объекты и выдавать результат больше, меньше или равно. В точности как описано в этой статье.
Значит, раньше программирование брало всё из математики. Теперь пришло время математики заимствовать что-то обратно.
Никто не отрицает, что могут попадаться персонажи с сертификатом или дипломом, но заметно не дотягивают до заявленных знаний. Но ведь речь идёт не об этом. Вот если у вас 100 кандидатов на должность и вы хотите найти наиболее подходящего, то вы замучаетесь выбирать. А если вы заявите необходимость сертификата, то внезапно кандидатов станет в 4 раза меньше. Причём вероятность, что вы найдёте кого вам надо среди оставшихся будет очень высока. Просто дворник не пойдёт заморачиваться сдавать Amazon сертификат. Соответственно, наличие сертификата - это значимый показатель. Далее, при необходимости можно проверить, достаточно ли реальных знаний.
Так что, это не филькина грамота, а очень полезный инструмент как для работодателя, так и для специалиста. И это становится намного очевидней, если смотреть на них через вероятности применительно к множеству кандидатов.
Ну и пускай это будет ритуальная пляска. Зато толпа кандидатов готовится, читает умные книжки, учится конструктивно вести обсуждение. Если человек способен выполнить ритуал как положено, значит и работать сможет как необходимо для компании. Кругом одни плюсы, разве не так?
Статья описывпет очень явно висящую в воздухе тему. Только рассуждение на тему "как должно быть" немного неправильно. Тут нет центра принятия решений, которой сделает как хотелось бы. Тут есть многотонный самосвал, который разогнался до огромной скорости и выехал на лёд. Вся система набрала большую инэрцию и у нас довольно мало рычагов влияния. ЖЕЛАЕМАЯ траектория движения и конечный пункт скрее всего вообще не достижимы. Надо надеяться, что впереди нет бетонной стены, и стараться хоть как-то влиять на процесс.
Вобщем, я к тому что более ценно сейчас говорить не как должно быть, а рассуждать какие реальные действия и меры стоит пробовать применять, чтобы влиять на всю систему для движения в предпочтительную сторону.
Чтобы разметка не разьезжалась при добавлении цены за единицу, я бы рассчитанную цену отображал как всплывающий tooltip при неведении мыши. Таким образом мы не перегружаем интерфейс множеством цифр, не меняем визуально дизайн вообще, но даём возможность легко узнать цену за единицу, когда этого желает пользователь.
Вот так почитаешь, что надо знать и сходу уметь делать, чтобы пройти собеседование, и становится немного не по себе. Даже не смотря на многолетний опыт и хорошую должность. Уверен, много специалистов сходу не пройдут такое интервью без подготовки. А те кто пройдут, вряд-ли будут все эти знания на рабочем месте каждый день использовать. Так что получается скил прохождения интервью для того чтобы пойти интервью (как наука ради науки). Компании по сути выбирают кто лучше подготовился.
Мне кажется заголовок статьи привлекает определённую аудиторию - тех кто хочет, но ещё не умеет. Однако, статья очень искусно обходит стороной все делали, которые были бы очень важны для этой аудитории.
Вроде бы и пример какой-то рассмотрен, но совершенно не понятно что, как, куда, с чего начать... Вообще не понятно "как стать AI-разработчиком" после прочтения этой статьи. Таким образом, либо заголовок не соответствует содержанию, либо в статье не хватает множества подробностей, и какого-то внятного заключения с ответом на вопрос, как же всё таки стать AI-разработчиком.
Первый раз услышал про СкрамБан, и приятно удивился. Значит мы не единственные, кто берет известные практики, но не следует им. Потом это всё перемешивается, и получившийся монстр, который не имеет названия. Но ведь главное, чтобы все были счасливы, правда?!
Кстати, когда пытались строго следовать скраму, жизнь в проекте была очень изнурительной. Всё время казалось, что что-то висит над головой, а мы постоянно опаздываем. Потом вспоминая этот опыт я даже увидел наглядное объяснение почему мне не нравится этот подход. Спринт - это очень быстрый бег, когда тебе надо пробежать короткую дистанцию. Но ведь разработать программный продукт - это не короткая дистанция. Попробуйте пробежать марафон, нарезав его на стометровки, и бежать каждую как спринт... А потом удивляются, почему все айтишники говорят про выгорание.
Да! Я тоже был студентом, хотел получить опыт, мечтал о таких проектах... Но мне повезло видимо чуть больше. Залог успеха в моём случае был в том, что "проект" был очень ограничен по времени (кажется 2 недели), в командах было по 10 студентов, и мы соревновались между универами. При этом, на период проекта мы не просто не ходили на лекции, а мы вообще уехали в другой город. Полное погружение, и мотивация зашкаливала. И конечно в конце это можно было зачесть за подобный предмет.
Много лет спустя я вспоминаю тот свой опыт, и понимаю, что студентов нельзя наверное мерить уровнем работника предприятия. Если есть Junior/Middle/Senior, то студент это pre-Junior. И по знаниями, и по ответственности (как много раз было упомянуто в статье), и по умению работать в команде. Однако, я всё равно верю, что правило "спрос рождает предложение" применимо и здесь. Студенты хотят и могут участвовать в таких проектах. Надо только создать правильные условия, и не ждать больших результатов, ведь для многих это будет первый опыт.
По моему, автор молодец! Он добился своей цели. Написал короткую статью про очень важную и полезную вещь. Пусть его изложение и далеко от идеала, но помогает начинающим в этой теме. А хабр, и всё сообщество неравнодушных комментаторов, в данном случае, продолжает тему в виде дискуссий и покрывает многие пробелы, сглаживает шероховатости. Читатель имеет возможность посмотреть на ошибки и их обсуждения, как те что были описаны в самой статье, так и те, о которых говорится в комментариях. Особенно приятно видеть философские примечания о целесообразности некоторых принцыпов в разных ситуациях!
А никто не заметил, что несмотря на присутствие ссылок на трёх гигантов: Amazon, Microsoft, Google, все примеры и описания говорят только про AWS? Хотелось уже увидеть какое-то обобщение, или разнообразие примеров - статья выглядела бы заметно лучше.
В последнем примере как-то явно в тексте не говорится, что речь идёт про удаление несуществующего элемента "response", и именно из-за этого и возникает проблема, о которой идёт речь. Приходится догадываться об этом из строк кода.
Ну правильно. А как по вашему производится сортировка, например, текстовых значений? У строки текста вообще невозможно вычислить значение. Однако, у нас есть "функция оракул", которая может сравнить две строки и сказать какая больше. Благодаря этому мы можем и произвести оптимизацю в виде поиска наименьшего значения, и отсортировать список.
Кстати, это очень распространённый базовый принцип в программировании, из которого дальше выросли и другие, например Inversion of Control и Interface Segregation Principle.
Хмм... , а вы тоже заметили, что под каждой статьёй обязательно есть комментарий, который утверждает что статью написал ИИ?
Раньше это ещё выглядело забавно, но теперь как-то уже не очень. В чем полезность комментария?
Тогда программист это демон Максвелла!
(Если кто не помнит, демон Максвелла стремится уменьшать энтропию в замкнутой системе.)
Погодите-погодите. Это кто это раньше рисовал блок схему по коду? Это называется reverse engineering. В нормальных учебных заведениях учат сначала составлять алгоритм в виде блок схемы (пусть то на бумаге или в голове), а затем писать код. Многие умельцы делали это наоборот, но в таком виде это не имеет смысла, разве что для того чтобы написать отчёт. Но концептуально блок схема всегда первична, и уже из неё пишется код. И правильность логики также проверяется на блок схеме.
Так что прогресс свернул очень даже туда! Отдавая процесс написания кода в руки ИИ, следует вспомнить незаслуженно забытые блок схемы, как абстрактный и пригодный именно для человека формат описания алгоритмов и логики. Недаром визуальное представление всё чаще всплывает в современных системах, особенно для workflows и автоматизаций.
Вот это я понимаю, популярная тема. Все кому не лень написали своё мнение. Теперь моя очередь, хотя вряд-ли кто-то его вообще прочитает среди такого количества.
А вот согласитесь, все таки здорово что все эти SOLID, DRY, KISS, YAGNI принципы существуют, так же как и шаблоны проектирования. Мы все их знаем, понимаем, где-то что-то используем, распознаём в коде, и вообще обсуждаем структуру решений в этих терминах. Как-то сложнее было бы на пальцах всегда без них. Но что сейчас особенно важно и актуально, так это то что эти принципы теперь понимает и использует ИИ для генерации кода. Тем самым мы можем быть немного более уверены в качестве кода, если он следует этим принципам. Вместо бремени на реализацию это превращается в контроль над качеством.
А теперь представьте, что вы разрабатываете не маленькую фичу, а очень большое корпоративное приложение чужими руками (будь то люди или ИИ) и у вас есть возможность либо принудить всех следовать тому же SOLID, либо разрешить всем "решать на месте индивидуально". Что бы вы выбрали, согласованность или зоопарк? В обоих вариантах будут где-то менее где-то более удачные реализации. Но согласитесь, что следование общим принципам будет намного более выйгрышным в глобальном плане для проекта.
(Ну а если вы сами девелопите свой стартап, небольшой интернет магазин, или пет проект - городите что хотите. Нет смысла во всех этих выкрутасах с перспективой на будущее. Не будет там никакой перспективы. Нечего и планировать, что хобби проект перерастёт в энтерпрайз решение. А у стартапа будет ещё много возможностей всё переделать, если вдруг что-то выгорит.)
Как интересно...
"С недавним появлением концепции порядковых оракулов исследователи начали изменять подходы к оптимизации"
То есть в математике концепция "порядковых оракулов" появилась недавно? А вот в программировании такая концепция существует уже много десятилетий. Все классические алгоритмы сортировки основаны на этой концепции, бинарный поиск, дерево поиска, а затем по цепочке притягиваются базы данных и вообще весь IT. Потому что эти алгоритмы определены для любых объектов, и необходимо только задать функцию оракула сравнения, которая попарно может сравнивать эти объекты и выдавать результат больше, меньше или равно. В точности как описано в этой статье.
Значит, раньше программирование брало всё из математики. Теперь пришло время математики заимствовать что-то обратно.
Прочитал первую букву вашего комментария и сразу могу сказать...
Вы же понимаете, что после такого вступления ценность следующих слов близится к нулю.
Ну не правда!
Никто не отрицает, что могут попадаться персонажи с сертификатом или дипломом, но заметно не дотягивают до заявленных знаний. Но ведь речь идёт не об этом. Вот если у вас 100 кандидатов на должность и вы хотите найти наиболее подходящего, то вы замучаетесь выбирать. А если вы заявите необходимость сертификата, то внезапно кандидатов станет в 4 раза меньше. Причём вероятность, что вы найдёте кого вам надо среди оставшихся будет очень высока. Просто дворник не пойдёт заморачиваться сдавать Amazon сертификат. Соответственно, наличие сертификата - это значимый показатель. Далее, при необходимости можно проверить, достаточно ли реальных знаний.
Так что, это не филькина грамота, а очень полезный инструмент как для работодателя, так и для специалиста. И это становится намного очевидней, если смотреть на них через вероятности применительно к множеству кандидатов.
Ну и пускай это будет ритуальная пляска. Зато толпа кандидатов готовится, читает умные книжки, учится конструктивно вести обсуждение. Если человек способен выполнить ритуал как положено, значит и работать сможет как необходимо для компании. Кругом одни плюсы, разве не так?
Статья описывпет очень явно висящую в воздухе тему. Только рассуждение на тему "как должно быть" немного неправильно. Тут нет центра принятия решений, которой сделает как хотелось бы. Тут есть многотонный самосвал, который разогнался до огромной скорости и выехал на лёд. Вся система набрала большую инэрцию и у нас довольно мало рычагов влияния. ЖЕЛАЕМАЯ траектория движения и конечный пункт скрее всего вообще не достижимы. Надо надеяться, что впереди нет бетонной стены, и стараться хоть как-то влиять на процесс.
Вобщем, я к тому что более ценно сейчас говорить не как должно быть, а рассуждать какие реальные действия и меры стоит пробовать применять, чтобы влиять на всю систему для движения в предпочтительную сторону.
Чтобы разметка не разьезжалась при добавлении цены за единицу, я бы рассчитанную цену отображал как всплывающий tooltip при неведении мыши. Таким образом мы не перегружаем интерфейс множеством цифр, не меняем визуально дизайн вообще, но даём возможность легко узнать цену за единицу, когда этого желает пользователь.
Спасибо за перевод.
Вот так почитаешь, что надо знать и сходу уметь делать, чтобы пройти собеседование, и становится немного не по себе. Даже не смотря на многолетний опыт и хорошую должность. Уверен, много специалистов сходу не пройдут такое интервью без подготовки. А те кто пройдут, вряд-ли будут все эти знания на рабочем месте каждый день использовать. Так что получается скил прохождения интервью для того чтобы пойти интервью (как наука ради науки). Компании по сути выбирают кто лучше подготовился.
Мне кажется заголовок статьи привлекает определённую аудиторию - тех кто хочет, но ещё не умеет. Однако, статья очень искусно обходит стороной все делали, которые были бы очень важны для этой аудитории.
Вроде бы и пример какой-то рассмотрен, но совершенно не понятно что, как, куда, с чего начать... Вообще не понятно "как стать AI-разработчиком" после прочтения этой статьи. Таким образом, либо заголовок не соответствует содержанию, либо в статье не хватает множества подробностей, и какого-то внятного заключения с ответом на вопрос, как же всё таки стать AI-разработчиком.
Первый раз услышал про СкрамБан, и приятно удивился. Значит мы не единственные, кто берет известные практики, но не следует им. Потом это всё перемешивается, и получившийся монстр, который не имеет названия. Но ведь главное, чтобы все были счасливы, правда?!
Кстати, когда пытались строго следовать скраму, жизнь в проекте была очень изнурительной. Всё время казалось, что что-то висит над головой, а мы постоянно опаздываем. Потом вспоминая этот опыт я даже увидел наглядное объяснение почему мне не нравится этот подход. Спринт - это очень быстрый бег, когда тебе надо пробежать короткую дистанцию. Но ведь разработать программный продукт - это не короткая дистанция. Попробуйте пробежать марафон, нарезав его на стометровки, и бежать каждую как спринт... А потом удивляются, почему все айтишники говорят про выгорание.
Да! Я тоже был студентом, хотел получить опыт, мечтал о таких проектах... Но мне повезло видимо чуть больше. Залог успеха в моём случае был в том, что "проект" был очень ограничен по времени (кажется 2 недели), в командах было по 10 студентов, и мы соревновались между универами. При этом, на период проекта мы не просто не ходили на лекции, а мы вообще уехали в другой город. Полное погружение, и мотивация зашкаливала. И конечно в конце это можно было зачесть за подобный предмет.
Много лет спустя я вспоминаю тот свой опыт, и понимаю, что студентов нельзя наверное мерить уровнем работника предприятия. Если есть Junior/Middle/Senior, то студент это pre-Junior. И по знаниями, и по ответственности (как много раз было упомянуто в статье), и по умению работать в команде. Однако, я всё равно верю, что правило "спрос рождает предложение" применимо и здесь. Студенты хотят и могут участвовать в таких проектах. Надо только создать правильные условия, и не ждать больших результатов, ведь для многих это будет первый опыт.
По моему, автор молодец! Он добился своей цели. Написал короткую статью про очень важную и полезную вещь. Пусть его изложение и далеко от идеала, но помогает начинающим в этой теме. А хабр, и всё сообщество неравнодушных комментаторов, в данном случае, продолжает тему в виде дискуссий и покрывает многие пробелы, сглаживает шероховатости. Читатель имеет возможность посмотреть на ошибки и их обсуждения, как те что были описаны в самой статье, так и те, о которых говорится в комментариях. Особенно приятно видеть философские примечания о целесообразности некоторых принцыпов в разных ситуациях!
Приятно почитать, спасибо!
А никто не заметил, что несмотря на присутствие ссылок на трёх гигантов: Amazon, Microsoft, Google, все примеры и описания говорят только про AWS? Хотелось уже увидеть какое-то обобщение, или разнообразие примеров - статья выглядела бы заметно лучше.
В последнем примере как-то явно в тексте не говорится, что речь идёт про удаление несуществующего элемента "response", и именно из-за этого и возникает проблема, о которой идёт речь. Приходится догадываться об этом из строк кода.