Спасибо, интересно! Любопытно будет почитать вторую часть про алгоритмы бота, который играет в тетрис, потому что в строгом смысле эта задача NP-полная. Подозреваю, что там будет просто разумное приближение с допущениями, и ИИ всё-таки будет в конце концов проигрывать.
Кстати, жалко, что статья об этом NES-тетрисе, а не от Tengen. Лично мне тот сильно больше нравится.
должна была проверять разрешённость именно чтения. Хотя комментарий нам и говорит явно про «read-only», он мог писаться постфактум и быть просто навеян названием константы O_RDONLY. Тут без остального контекста сложно понять. Хотя, конечно, Ваше предположение выглядит проще.
Хм, так причём тут STL? Эдак можно и минимум пытаться с помощью std::sort искать. Виновата не STL и не сортировка, просто в данном случае приоритет отдаётся уже реализованным алгоритмам, а не подходящим для задачи, что есть плохой подход (хотя и не всегда, кстати). По названию статьи подумал, что какой-то стандартный алгоритм над std::set работает хуже, чем велосипед, который будет приведён, хех.
По поводу результативности не скажу, но комментарии к статьям про собеседования в IT — это для меня, пожалуй, самый весёлый из «развлекательного контента» на хабре. Всегда узнаю для себя что-то новое в плане поведения собеседующих и собеседующихся, и всегда есть истории дичь-собеседований из опыта хаброжителей, с которых можно посмеяться. В какой-то мере мне оно помогает потом не относиться к собеседованиям и их результатам серьёзнее, чем они того заслуживают.
Гугл он весь такой. Не удивляйтесь, если внезапно не сможете залогиниться в каком-нибудь из их сервисов из-за «подозрительной активности», которая заключается, например, в том, что вы использовали другой браузер, находитесь в другом месте или сменился динамический IP. Будете при этом читать устаревшие инструкции и доказывать, что не верблюд, исключительно роботам, которые будут отмахиваться шаблонами «извините, нам очень жаль, но мы всё-таки оставим своё решение в силе».
do {} while(false)
А разве нельзя заменить эту конструкцию на просто {}
? Она тоже выполнится ровно один раз и ограничит область видимости. Или это делается для того, чтобы потребовать у пользующего кода точку с запятой в конце?
Сталкивался в легаси с верхним вариантом, он там был, в том числе, чтобы использовать break для выхода из границ.
Из самого запоминающегося: будучи школьником-радиолюбителем проводил какие-то свои безумные эксперименты. Точно не помню, как так вышло, но одной рукой взялся за батарею отопления, а другой за фазу 220 через большой советский электролитический кондёр. Отпустил практически сразу, но до сих пор помню это чувство, когда рука на фазе будто затекла по плечо, но при этом в каждую «мурашку» словно воткнули иглу. Считаю, что очень повезло, т.к. анлокнул тогда все ачивки для того, чтобы откинуться.
Введение с явным обозначением проблематики, которую должен решать данный материал, с обозначением состояния на начальном этапе и обозначением ожидаемого состояния на момент исполнения читателем действий описанных в материале. В случае с тикетом это — обязательное описание ожидаемого поведения программного обеспечения и фактического. По возможности должна быть отсылка на источник с описанием корректного поведения.
Ох. Мой мозг на автомате начинает скипать такие тексты. Может, конечно, это я такой тупой, но это же всё-таки инструкция.
Напишите в вашем тикете/багрепорте:
0. Заголовок — краткое описание проблемы.
1. Окружение, на котором она происходит (продукт, локально/транк/тест/прод, учётка).
2. Начальное состояние продукта (залогинился/запустил программу, программа работала 3 часа простаивая).
3. Что было сделано, конкретно, по шагам (нажал эту кнопку, вбил в это поле «12345»).
4. Что получили в итоге (неправильный ответ «123», ошибка «неверный дескриптор 1234», зависание).
5. Что хотели получить (правильный ответ «333», отсутствие ошибки, отсутствие зависания).
6. Ссылки на ТЗ/согласования, почему хотели бы получить именно это (если не очевидно).
7. Скриншоты, логи, дампы, исходные файлы, полученные файлы и т.п., если есть.
Нет. Так просто сказать нельзя. И про иррациональные числа тоже так просто сказать нельзя. Всё нужно доказывать. И доказательство существования иррациональных чисел есть. А доказательство существования этого номера — нет. Есть только попытки итерационного приближения.
Число существует не потому что мы дали ему имя/обозначение. Я тоже могу ввести число Гладина, которое в поле действительных чисел при делении на единицу не равно себе. От этого оно существовать не станет.
Ну, если рассуждать в ключе, что иррациональных чисел не существует, то и доказывать ничего не нужно дополнительно: нумеруем рациональные и всё. Что, как я понял, и было сделано. Вот только иррациональные числа существуют сами по себе, и это доказано строго математически. А то, что мы можем «пощупать» только их приближения — это не проблема иррациональных чисел и уж никак не опровержение их существования.
А что является результатом работы алгоритма, который не завершится никогда? Рассуждая на пальцах: либо «ничего» (или другой определённый конкретный ответ), и тогда все иррациональные числа имеют «одинаковый номер» — нет однозначности, либо «не определено», и тогда мы не можем сравнить номера, как следствие, не можем проверить однозначность соответствия.
Или, например, так: вот для двух разных «конечных рациональных» чисел при грамотно построенной нумерации (например, по квадрату) всегда будет два конечных номера, которые можно сравнить и убедиться, что номера разные. А как сравнить между собой два бесконечных номера?
Ну гнать-то вроде не за что, айтишник просто неравнодушен и своё мнение доносит, но работу при этом делает со всеми хотелками. А работа тут такая, что без обсуждений с заказчиком нельзя. В частности, и сам заказчик может до конца не знать, что он реально хочет.
Но с остальным соглашусь. Тебе платят за цифры — даёшь цифры. Как с этими цифрами обращаться и что с ними делать — это пускай у других людей голова болит, тебе за это не платят.
Цифры – это просто инструмент, как молоток или дрель.
Вот даже исходя из этой аналогии: производитель моего молотка мне не будет доказывать, что молоток мне не нужен, т.к. я его купил и положил пылиться на полку. Его дело — сделать молоток. А на полку я его положу, буду им гвозди забивать или в носу им ковырять — его это вообще не должно волновать.
Это всё до первого бага или первого изменения требований. Тогда-то и придётся залезть в реализацию объекта и схватиться за голову.
Если программист (1)выдаёт идеально работающий продукт, который (2)не нужно будет дорабатывать, тогда конечно не так важно, как оно написано. Первое происходит обычно никогда, а второе — обычно когда продукт никому не нужен.
Ну, это, конечно, да. Согласен с тем, что это боль. Но вот лично у меня эта боль не основная. С огромным методом хотя бы понятно что делать — анализировать и разбивать. Т.е. есть конкретный файл, в нём конкретный ком грязи, конкретно его чистишь в несколько заходов — и понимание приходит, что оно делает, и мелкие баги сразу под пристальным взглядом всплывают и фиксятся. Если время есть, то это даже какого-то рода медитативное дело. Даже настроение улучшается: вроде как какой-то дурак намусорил, а ты всё прибрал и почистил, молодец. (Даже если намусоривший дурак — это я полгода назад, лол)
Моя основная боль начинается от ООПшного комка грязи, разбросанного по разным файлам, между которыми нужно скакать, пытаясь угадать зависимости. Когда непонятно даже, куда в принципе стоит смотреть. А усиливается боль от пучка зависимостей между огромными модулями (пускай даже не слишком плохими внутри), с которыми уже вообще фиг знает, что можно сделать, и любая правка подобна магии. А ещё больнее, когда все остальные модули — не твоя зона ответственности, и ничего менять в них по регламенту тебе не положено. Ещё хлеще, если часть этих модулей вообще проприетарное ПО с закрытым кодом, и ничего там нельзя изменить в принципе.
Работал с программистом, который очень любил «не писать лишнего». В его коде как раз были методы-простыни на тысячи строк. Спорил с ним на ревью по поводу выделения в отдельный метод, его рассуждения были примерно такие:
— Этот метод будет вызываться один раз, значит в коде будут плюс две-четыре лишние строки на сигнатуру функции, скобки, разделяющую пустую строку и т.п., зачем мне лишние строки?
Ну и, несмотря на то, что я считаю это ужасным подходом с точки зрения качества кода, стоит признать, что формально-то он прав, кода действительно становится больше. Поэтому я удивился, когда увидел в статье
Код заслуживает быть вынесенным в отдельную функцию не только тогда, когда его планируется переиспользовать, но и в целях улучшения читаемости.
Так что я не понял посыл. С чем предлагается бороться: с количеством или низким качеством? Или под словом «код» здесь понимается только содержание методов?
Нужно просто не использовать прямые ответы на секретные вопросы. И они должны быть сопоставимы по сложности с паролями, т.к. общая защищённость равна защищённости самого слабого звена. Помню, ещё в 2009-2012 злоумышленники массово угоняли мыла на мейлру, перебирая стандартные ответы. У них даже целые списки были в публичном доступе, вроде:
Популярные клички: Барсик, Васька, Мурка, Мухтар, Барбос;
Популярные любимые блюда: мороженое, мороженное, шашлык;
и т.д.
Музыку из первой группы любят «сложные» люди, которые склонны к рефлексии.
Вторую группу предпочитают «напористые и бунтующие» натуры[...] они более спортивны и не любят казаться умнее всех.
В третьей группе — оптимисты и экстраверты, более добросовестные и склонные соглашаться с другими
Музыку из четвертой группы предпочитают энергичные и ритмичные люди [...] отличаются отсутствием консерватизма, более высоким уровнем дохода и IQ.
1. А реально ли нужно запретить проезд? Может его разрешить и не заморачиваться?
2. Или может запретить въезд вообще всем? Тогда хорошо подойдёт стена.
3. Перевести все автомобили на автопилот с картой и условиями въезда.
4. Поставить знак-экран (условный кирпич) и камеру, нарушителей автоматически штрафовать по номеру.
5. Металлические шипы.
6. Ров с водой и крокодилами и автоматический опускающийся мост на цепях.
7. Хорошая парковка вне огороженной территории.
8. Просто знак запрета проезда, но если человек, которому показали этот знак, не едет, разворачивается и уезжает, то на выезде ему в автомате рядом выдаётся бесплатная газировка (попытка перевести с кнута на пряник).
9. Знак запрета проезда, муляж автоматического огнемёта и два поджаренных корпуса авто рядом.
Кстати, жалко, что статья об этом NES-тетрисе, а не от Tengen. Лично мне тот сильно больше нравится.
скорее на
и проверка
должна была проверять разрешённость именно чтения. Хотя комментарий нам и говорит явно про «read-only», он мог писаться постфактум и быть просто навеян названием константы O_RDONLY. Тут без остального контекста сложно понять. Хотя, конечно, Ваше предположение выглядит проще.
do {} while(false)А разве нельзя заменить эту конструкцию на просто
{}? Она тоже выполнится ровно один раз и ограничит область видимости. Или это делается для того, чтобы потребовать у пользующего кода точку с запятой в конце?
Сталкивался в легаси с верхним вариантом, он там был, в том числе, чтобы использовать break для выхода из границ.
Ох. Мой мозг на автомате начинает скипать такие тексты. Может, конечно, это я такой тупой, но это же всё-таки инструкция.
Напишите в вашем тикете/багрепорте:
0. Заголовок — краткое описание проблемы.
1. Окружение, на котором она происходит (продукт, локально/транк/тест/прод, учётка).
2. Начальное состояние продукта (залогинился/запустил программу, программа работала 3 часа простаивая).
3. Что было сделано, конкретно, по шагам (нажал эту кнопку, вбил в это поле «12345»).
4. Что получили в итоге (неправильный ответ «123», ошибка «неверный дескриптор 1234», зависание).
5. Что хотели получить (правильный ответ «333», отсутствие ошибки, отсутствие зависания).
6. Ссылки на ТЗ/согласования, почему хотели бы получить именно это (если не очевидно).
7. Скриншоты, логи, дампы, исходные файлы, полученные файлы и т.п., если есть.
Число существует не потому что мы дали ему имя/обозначение. Я тоже могу ввести число Гладина, которое в поле действительных чисел при делении на единицу не равно себе. От этого оно существовать не станет.
А что является результатом работы алгоритма, который не завершится никогда? Рассуждая на пальцах: либо «ничего» (или другой определённый конкретный ответ), и тогда все иррациональные числа имеют «одинаковый номер» — нет однозначности, либо «не определено», и тогда мы не можем сравнить номера, как следствие, не можем проверить однозначность соответствия.
Или, например, так: вот для двух разных «конечных рациональных» чисел при грамотно построенной нумерации (например, по квадрату) всегда будет два конечных номера, которые можно сравнить и убедиться, что номера разные. А как сравнить между собой два бесконечных номера?
Но с остальным соглашусь. Тебе платят за цифры — даёшь цифры. Как с этими цифрами обращаться и что с ними делать — это пускай у других людей голова болит, тебе за это не платят.
Вот даже исходя из этой аналогии: производитель моего молотка мне не будет доказывать, что молоток мне не нужен, т.к. я его купил и положил пылиться на полку. Его дело — сделать молоток. А на полку я его положу, буду им гвозди забивать или в носу им ковырять — его это вообще не должно волновать.
Если программист (1)выдаёт идеально работающий продукт, который (2)не нужно будет дорабатывать, тогда конечно не так важно, как оно написано. Первое происходит обычно никогда, а второе — обычно когда продукт никому не нужен.
Моя основная боль начинается от ООПшного комка грязи, разбросанного по разным файлам, между которыми нужно скакать, пытаясь угадать зависимости. Когда непонятно даже, куда в принципе стоит смотреть. А усиливается боль от пучка зависимостей между огромными модулями (пускай даже не слишком плохими внутри), с которыми уже вообще фиг знает, что можно сделать, и любая правка подобна магии. А ещё больнее, когда все остальные модули — не твоя зона ответственности, и ничего менять в них по регламенту тебе не положено. Ещё хлеще, если часть этих модулей вообще проприетарное ПО с закрытым кодом, и ничего там нельзя изменить в принципе.
— Этот метод будет вызываться один раз, значит в коде будут плюс две-четыре лишние строки на сигнатуру функции, скобки, разделяющую пустую строку и т.п., зачем мне лишние строки?
Ну и, несмотря на то, что я считаю это ужасным подходом с точки зрения качества кода, стоит признать, что формально-то он прав, кода действительно становится больше. Поэтому я удивился, когда увидел в статье
Так что я не понял посыл. С чем предлагается бороться: с количеством или низким качеством? Или под словом «код» здесь понимается только содержание методов?
Популярные клички: Барсик, Васька, Мурка, Мухтар, Барбос;
Популярные любимые блюда: мороженое, мороженное, шашлык;
и т.д.
Звучит как гороскоп.
2. Или может запретить въезд вообще всем? Тогда хорошо подойдёт стена.
3. Перевести все автомобили на автопилот с картой и условиями въезда.
4. Поставить знак-экран (условный кирпич) и камеру, нарушителей автоматически штрафовать по номеру.
5. Металлические шипы.
6. Ров с водой и крокодилами и автоматический опускающийся мост на цепях.
7. Хорошая парковка вне огороженной территории.
8. Просто знак запрета проезда, но если человек, которому показали этот знак, не едет, разворачивается и уезжает, то на выезде ему в автомате рядом выдаётся бесплатная газировка (попытка перевести с кнута на пряник).
9. Знак запрета проезда, муляж автоматического огнемёта и два поджаренных корпуса авто рядом.