1. Может, не закрыл файл после записи или он был где-то ещё открыт. С MS-DOS не работал, тонкостей не знаю. Или предполагается, что в других условиях всё работало?
2. А данные на вывод подавались те же самые? И другие программы с этим принтером работали? А то так-то и тонер мог закончится, в старых моделях этого могло не быть индикатора.
Видимо, непонятно написал, но да, именно это я и предлагаю.
Это — как загадки. Их условий достаточно, чтобы предполагать ответы и оценивать, насколько они подходят. И хоть на первый взгляд кажется, что ответов может быть много, есть только один, который подходит очень хорошо. Придумав такой, у вас не останется сомнений в его правильности.
Дипломом об экспертизе похвастаться не могу, но на бытовом уровне разбираюсь и считаю, что не совсем так.
Придурок — это человек, который делает гадость из-за «дурости».
Jerk, real jerk, asshole — градации человека, совершающего гадость из эгоизма. В русском к этому ближе слова «хам» или «козёл». Интеллектуальное развитие это никак не характеризует.
Например, если коллега позвонил вам и устроил истерику из-за ошибки в коде, которую сам же и внёс, то он просто придурок.
Если же ошибка и в самом деле ваша, но вместо того, чтобы подсказать исправление, позвонивший вам коллега говорит «разберись сам в своём говнокоде», то он просто jerk.
А по-моему, есть и куда более простое, но менее приятное объяснение, как минимум недавнему всплеску.
Видите красную точку на графике? Это 12 октября (сделал так, чтобы дата график не перекрывала).
Что случилось 12 октября? Один из самых больших западных обменников (без рекламы) объявил об отмене 3-5 дневного срока рассмотрения заявок по банковским переводам — теперь доллары с американских счетов в биткоины стало возможно выводить мгновенно. Лимит — до 25к долларов в неделю.
Почему раньше 3-5 дней останавливало «владельцев» и почему это вызвало всплеск переводов, предлагаю догадаться самостоятельно.
Да. У Apple на сайте для иконок слегка не так, там накладывают скругления поверх квадратной картинки. itunes.apple.com/us/app/candy-crush-saga/id553834731?mt=8&ign-mpt=uo%3D4
Можно для сравнения понакладывать на неё, например, border-radius самый близкий (40px на моём экране) — разница есть, но нужно очень пристально вглядываться.
По такой логике — а если продукт провалился и принёс убытки, депремировать всю команду? Даже если они все заранее знали, что он рискованный и имеет лишь 10% шанса «выстрелить» — и в итоге, закономерно, «не выстрелил», хотя и был технически выполнен на отлично и в срок — просто рынок был уже занят. Это ж было не их решение, начинать проект — такие решения принимаются куда выше по цепи.
Так все просто будут идти только в многообещающие проекты, раз уж там премируют даже за срыв сроков и бюджетов. И избегать всего остального.
Конечно, с точки зрения программиста я бы сказал, что команду программистов следует премировать и за работу, и за результат, и за энтузиазм, и просто за позитивное отношение к работе. Вообще нельзя не премировать (разве что совсем невезучих лентяев-злодеев, не попавших ни в одну категорию). Лично мне было бы только лучше, если бы так было, но я понимаю, почему может быть и не так.
Заметьте, я не говорю, что премировать ни в коем случае нельзя. Для мотивации можно и уборщице премию выписать по случаю продажи миллионной лицензии на продукт (даже плохо работающей). Просто это вряд ли сильно повлияет на продажи следующего миллиона лицензий.
А фрилансер встречно будет мне уделять 8 часов рабочего времени в день, не отвлекаясь на стопицот других заказчиков? Если так — то я готов платить ему как постоянщику
Отвлекаются на другие заказы потому, что заранее предполагается, что вы этого фрилансера по окончани проекта «уволите». Причём не постепенно, как постоянщика по КЗОТ, а сразу.
Никто не хочет по 20 раз в год превращаться в безработного с туманной перспективой, потому и ведут параллельно несколько проектов. К очень долгим проектам это, естественно, не относится.
Или как Factory Idle, которая отсекает все возможности выбора и размещения зданий строительных игр, оставляя только дерево апгрейдов и развивающийся город:
Абсолютная неправда. В Factory Idle нужно именно строить фабрику и оптимизировать размещение строений и конвейерные линии. Если кто-то из читателей хоть раз испытывал удовольствие, пытаясь красиво развести печатную плату или оптимизировать низкоуровневый код — не упустите шанс попробовать, она браузерная всё равно.
А вообще, лично мне такие игры, как ни странно, помогают оставаться продуктивным. Вместо ожидания очередного апгрейда, можно просто поработать, на время забыв про игру и вернуться, когда уже снова начнётся интересная часть.
Плюс, там и для любителей подумать есть где применить мозги. Помимо строительных Reactor Idle, Reactor Incremental и Factory Idle, почти в любой игре прогресс полностью зависит от решений игрока. У вас есть 100к денег, стоит ли купить несколько дешёвых апгрейдов или один дорогой? Или «перезапустить» игру сейчас с бонусом к скорости, потому что так через 8 часов получится больше прогресса?
Ну и просто приятно наблюдать за прогрессом чего-то, к чему приложил руку. Кто-то для этого заводит комнатные растения, кто-то — дачу, кого-то радует количество перепостов его картинки-мема, а кого-то — успехи сына-первокласника. Каждому своё.
Почему лишним? Почему человек вообще должен работать? Я считаю, что человек должен творчески и интеллектуально самореализовываться.
Я так тоже считал, лет 12 назад, когда учился в школе, жил с родителями и играл в ММО-шки весь день. А когда начал «жить на свои» и кормить не только себя, само пришло понимание «почему человек должен работать». Тут даже не то, чтобы должен, а просто почему так происходит.
Но вообще, «лишнее», это то, что человек сам определяет таковым.
Ну, чтобы не умереть с голоду можно и унылые задачи иногда поделать вполсилы. Но при этом ты понимаешь ради чего ты их делаешь, сделал по-быстрому, что требуется, чтобы получить зарплату, а всё остальное время тратишь на интересное.
Зарплата зарплате рознь. Кому-то и 10к — зарплата, а кому-то и 50к — нет.
Подумать о том, чем ты действительно хотел бы заняться. Очень сомневаюсь, что это будет просмотр сериалов. Наверняка хочется заняться изучением чего-то, созданием какого-то своего проекта.
Если бы изучение и свои проекты были интереснее сериалов и компьютерных игр, то сериалов и игр бы не существовало. Практика показывает, что это не так, и большинству людей свои проекты не интересны (особенно если пару раз уже на этом обожглись).
Видимо, недостаточно явно описал в статье, попробую пояснить ещё раз.
Если введя новую фичу в проект, программист не поломал всё подряд, а фича работает — значит, это уже достаточно качественный код.
Иногда к коду также есть дополнительные требования — переиспользуемость, понятность, соблюдение стайл-гайдов. Чаще всего этих требований нет.
Но дело в том, что даже «чтобы ничего не поломать» и «чтобы скомпилилось, не тормозило и в целом работало» — уже требует сосредоточенности. Представлять себе это «минное поле» проекта, вспоминать, где и что может пойти не так.
Зависит от проекта и задачи, конечно. Ту же валидацию е-мейла можно допилить к полю ввода и не просыпаясь, а вот, например, «добавить новый тип пользователей с ограниченными правами» уже так просто не получится, даже если говнокодить.
Нужно вспоминать, где в проекте уже есть проверки на тип пользователя; как они себя поведут, если он новый; где вообще есть список типов пользователей, или оно всё в хардкоде; а если в хардкоде, то может пора переписать по-нормальному, ведь на неделе ещё 5 типов добавлять собираются; а может и так оставить, вдруг быстрее будет. Вот с такими задачами и бывает, что человек просто не может заставить себя начать неделями.
Короче, если вы не используете формальные методы для доказательства корректности кода, то о какой безошибочности вообще можно говорить.
«Безошибочный код» в данном случае — код, который работает и, в общем, выполняет требования заказчика, а не в смысле идеальный. Если у вас функция выдаёт фигню, когда пользователь указал нулевое или отрицательное значение физической величины (вес, длина) — это не так страшно, по крайней мере для большинства проектов. Но если у вас 20 + 20 = 2020 (привет, JS), то это уже ошибка, которая перечёркивает собой всю остальную работу.
А насчет прокрастинации — может её вообще не существует? Если вам не хочется заниматься какими-то задачами, ну, значит они не достаточно важные и интересные? Значит, то чем вы занимаетесь в данный момент более важно?
Работа «в данный момент» никогда не бывает важна, потому что положительный результат от неё приходит намного позже — после того, как выплатят зарплату и после того, как эти деньги на что-то понадобятся.
А прокрастинация существует, если человек занимается чем-то явно лишним вместо работы. Если этот конкретный час он всё равно не смог бы работать, это уже не прокрастинация, даже если дело с виду бесполезное. Статья о том, что некоторые «бесполезные дела» важнее других.
В случае непонятных багов — это другая ситуация, тут не возникает такого состояния, когда «точно известно, что делать дальше». А вот, например, когда баг найден и исправлен, и следующее действие — просто скопировать то же самое исправление ещё в 3 похожих участка кода, то тут я бы как раз и остановился (если, конечно, это не критичный баг в продакшене и подождёт до завтра).
На мой взгляд, в этом отношении программирование ни на йоту не отличается от многих других областей деятельности. Вот менеджеры в ходе почтовой переписки какое-то решение выработали, потом в протоколе его зафиксировали, и оно стало обязательным к исполнению. Сколько будет стоить их ошибка? Вот технический писатель готовит комплект документации и допускает ошибку. Сколько она будет стоить, учитывая тысячи возможных пользователей?
Примеры, которые вы приводите, тоже относятся к системному решению задач (для решения задачи создаётся и продумывается система) и, да, в них отчасти справедливы те же принципы.
Разница тут, на мой взгляд, не в цене ошибки, а в «дискретности» результата. Т.е. например менеджеры решили, что для замены сломанного компьютера работники должны писать заявку, а соответствующий отдел должен её регистрировать и высылать ответ. Если они не оговорили точный формат заявки и ответа, то люди на месте разберутся, «что-нибудь придумают». Программа же без чёткого формата просто не отработает.
И если менеджерам просто укажут на недоработку, то программисту ещё нужно будет доказать, что он вообще что-то делал, а не просто так сидел. И это не всегда возможно.
Поэтому, с точки зрения прокрастинации, менеджер и может себе позволить ответить на email-переписку невыспавшимся и прочитавшим по-диагонали, он не будет перед этим часами сидеть и приходить в нужное состояние.
Было бы также интересно почитать, как вы справляетесь с частой проблемой low-cost разработки — капризными клиентами, которые выбирают малобюджетные варианты, а потом пытаются «выжать все соки» из заказа, потому что денег на доработку не предвидится.
Меня всегда в таких задачках напрягает их оторванность от реальности. Они, конечно, неплохо подойдут как «тема для разговора» на собеседовании, но делать прямое соответствие «кол-во правильных ответов — шанс на приём» я бы крайне не рекомендовал. Потому что в реальности многие эти «решения» неприменимы и ущербны.
Поясню мысль.
Первая задачка (с последовательностью без числа) в реальности может встретиться, например, при работе с БД. Есть список каких-то записей (юзеры, товары, транзакции — не важно), у них есть ID от 1 до N (autoincrement), есть некая функция, которая их удаляет, нам нужно узнать, что было удалено.
Тут стоит заметить, что во-первых, обычно используется не удаление, а установка какого-нибудь status: disabled (или установка null в поле, если прямо так необходимо избавится от информации). Удаление может вызвать кучу проблем и головной боли в последствии, не надо так.
Во-вторых, обычно всё-таки не должно возникать ситуации «у нас в БД что-то пропало, неизвестно что». ID удалённого объекта должен записываться в момент удаления и обрабатываться сразу же.
Но ок, допустим, какое-то вероисповедание нам не позволяет исключить возникновение такой ситуации. Тогда в-третьих: даже если мы делаем проверку суммы сразу после удаления чего-то, никогда нет гарантии, что в самом деле что-то было удалено, или что была удалена только одна запись. Даже если сегодня это так, завтра функцию могут переписать.
В итоге, человек, который считает, что ответ с суммой — окончательный и достаточный для продакшена будет просто не прав. Тут либо переделка структуры, либо полный перебор ID'ов.
Вторая задачка (кувшины) — ну ок, лёгкая, математическая, чтобы решающий почувствовал себя увереннее. К IT отношения не имеет от слова «совсем».
Но вообще в реальных задачах такого типа (когда есть возможность что-то решить, нестандартно используя существующие объекты), нужно в первую очередь начать задавать вопросы.
Почему такая задача вообще возникла и к ней не готовы? Может, в ТЗ опечатка и нужно всё-таки 3 литра?
Почему у нас нет кувшина на 4 литра? Может, он всё-таки есть и стоит его поискать? Чтобы не занимать те два кувшина, которые явно уже предназначены для других целей и могут понадобиться остальным.
А если скоро опять возникнет такая задача? А если в следующий раз — 1/4 литра? Может, стоит озаботиться покупкой кувшина с литровыми отметками, а не тратить своё время на «костыльные» переливания?
Третья задачка (поменять переменные местами) — да, задачка интересная. В реальности встречается, но крайне редко. Тут только нужно пояснить, в этой самой реальности для решения используют встроенную функцию (обычно называется Swap), либо (на худой конец) третью переменную. А за неожиданный уход в побитовые операции пускают лучи неневисти (те, кому потом придётся поддерживать такой код).
А стоило оно того? Такие деньги можно и на обычной IT-работе заработать (возможно, не за такое же время, но всё же).
Зато теперь достоверно известно, что есть люди, которые финансово заинтересованы вас вычислить, найти и привести в РОВД. Как минимум, они точно смогут в суде оспорить сделку (сложно будет доказать, что вы выполнили «свою часть» сделки) и обязать вернуть деньги. Как максимум (как уже указали выше), тут может быть достаточно на статью. Да и налоговой тоже будет интересно.
Тратить значительную часть денег на комиссии, переводы и мини-аккаунты для вывода? Постоянно ограничивать себя в тратах, чтобы не светиться? Ворочаться, вспоминая, не забыл ли включить тор, когда в последний раз заходил на аккаунт? Вздрагивать от каждого стука в дверь?
Так себе, честно говоря.
Вычислить можно по тому, куда идут деньги, кто владеет сайтом/доменом, кто оплачивает его рекламу и хостинг. «Можно» тут в смысле «теоретически возможно», а не что каждый это может сам.
У кого в итоге оседают деньги? У рекламщиков. Такие сайты не выходят по поисковым запросам, поэтому существуют по принципу, грубо «вкинул 1к в рекламу, повезёт — вернётся 2к, не повезёт — 500». Рекламой могут быть баннеры, всплывающие окна, спам. Можете сами провести аналогию с казино и кто в этом случае является его «владельцем».
Мне уже страшно от того, что через пару лет придётся разгребать код людей, вдохновившихся этой статьёй. Особенно при доведении этих принципов до абсолюта.
function getMapValues(map) {
return [...map.values()];
}
Вот это вообще гениально. На ровном месте создаётся обёртка для синтаксиса языка, которая не несёт вообще никакой пользы.
Просто представьте, что через пару лет после написания этого кода у вас возникла ошибка — вы захотели вывести несколько коллекций в порядке возрастания суммы, но результат вас удивил — порядок явно не тот. В чём проблема — неправильные исходные данные ('null' вместо null), ошибка в сортировке или в функции определения веса?
Вы начинаете копать функцию определения веса и видите этот спагетти-код из микро-функций, которые разбросаны по разным местам разных файлов вашего проекта (код-то «переиспользуемый»). И каждый раз, встретив функцию, вам нужно её индивидуально искать, разбираться, что она делает, и потом возвращаться к тому месту, где остановились.
Не забывайте, мы лишь рассматривали простую функцию подсчёта веса коллекций. Примитив. А теперь представьте, что у нас что-то сложнее и ближе к реальному миру — например, функция, которая определяет, сколько нужно коробок, чтобы переслать N предметов разных габаритов (с учётом всех нюансов — габаритов, ограничений по весу, требований не класть в одну коробку тяжёлое с хрупким, таможенных особенностей). Сколько там можно написать микро-функций? Сколько времени у вас займёт найти среди них ошибку округления?
От статьи как-то веет маркетологической «игрой в слова», без всякой чёткой теории.
Если блок со скидкой 90% и таймером повысил продажи — так естественно, это же M — мотивация.
Если тот же самый блок понизил продажи — так чего ж вы хотели, это же T — доверие, кто же в здравом уме будет доверять скидке в 90%?
Если нужно повысить продажи, как определить, чего именно из S T M не хватает на сайте? Есть ли примеры «golden ratio»? Кейсы «было-стало» с цифрами повышения конверсии? «На глаз»-то и без всякой теории можно что-нибудь придумать.
Просто если брать изначальные вопросы как «стоит ли вносить правку Х? повысит ли она конверсию? насколько? это оправдает затрату человеко-часов?», то теория вообще не может дать уверенного ответа, даже в примере с «игрой со шрифтами».
Если задав себе вопрос: повлияет ли эта правка на удовлетворенность пользователя, его доверие к нам или мотивацию к покупке? — не получается дать определенного ответа, её вносить не следует. Это относится к игре со шрифтами, цветами, «сделать красным жирным телефоном в шапке» и прочему. Только конверсия и максимальная эффективность.
Привлекательность — приятное графическое оформление, соответствующее идеи бренда, вызывает у пользователя доверие и желание изучить сайт более глубоко. [+ S, + T]
2. А данные на вывод подавались те же самые? И другие программы с этим принтером работали? А то так-то и тонер мог закончится, в старых моделях этого могло не быть индикатора.
2. Бумага закончилась. Либо принтер сломался / отключился.
Это — как загадки. Их условий достаточно, чтобы предполагать ответы и оценивать, насколько они подходят. И хоть на первый взгляд кажется, что ответов может быть много, есть только один, который подходит очень хорошо. Придумав такой, у вас не останется сомнений в его правильности.
Придурок — это человек, который делает гадость из-за «дурости».
Jerk, real jerk, asshole — градации человека, совершающего гадость из эгоизма. В русском к этому ближе слова «хам» или «козёл». Интеллектуальное развитие это никак не характеризует.
Например, если коллега позвонил вам и устроил истерику из-за ошибки в коде, которую сам же и внёс, то он просто придурок.
Если же ошибка и в самом деле ваша, но вместо того, чтобы подсказать исправление, позвонивший вам коллега говорит «разберись сам в своём говнокоде», то он просто jerk.
Видите красную точку на графике? Это 12 октября (сделал так, чтобы дата график не перекрывала).
Что случилось 12 октября? Один из самых больших западных обменников (без рекламы) объявил об отмене 3-5 дневного срока рассмотрения заявок по банковским переводам — теперь доллары с американских счетов в биткоины стало возможно выводить мгновенно. Лимит — до 25к долларов в неделю.
Почему раньше 3-5 дней останавливало «владельцев» и почему это вызвало всплеск переводов, предлагаю догадаться самостоятельно.
itunes.apple.com/us/app/candy-crush-saga/id553834731?mt=8&ign-mpt=uo%3D4
Можно для сравнения понакладывать на неё, например, border-radius самый близкий (40px на моём экране) — разница есть, но нужно очень пристально вглядываться.
Так все просто будут идти только в многообещающие проекты, раз уж там премируют даже за срыв сроков и бюджетов. И избегать всего остального.
Конечно, с точки зрения программиста я бы сказал, что команду программистов следует премировать и за работу, и за результат, и за энтузиазм, и просто за позитивное отношение к работе. Вообще нельзя не премировать (разве что совсем невезучих лентяев-злодеев, не попавших ни в одну категорию). Лично мне было бы только лучше, если бы так было, но я понимаю, почему может быть и не так.
Заметьте, я не говорю, что премировать ни в коем случае нельзя. Для мотивации можно и уборщице премию выписать по случаю продажи миллионной лицензии на продукт (даже плохо работающей). Просто это вряд ли сильно повлияет на продажи следующего миллиона лицензий.
Отвлекаются на другие заказы потому, что заранее предполагается, что вы этого фрилансера по окончани проекта «уволите». Причём не постепенно, как постоянщика по КЗОТ, а сразу.
Никто не хочет по 20 раз в год превращаться в безработного с туманной перспективой, потому и ведут параллельно несколько проектов. К очень долгим проектам это, естественно, не относится.
Абсолютная неправда. В Factory Idle нужно именно строить фабрику и оптимизировать размещение строений и конвейерные линии. Если кто-то из читателей хоть раз испытывал удовольствие, пытаясь красиво развести печатную плату или оптимизировать низкоуровневый код — не упустите шанс попробовать, она браузерная всё равно.
А вообще, лично мне такие игры, как ни странно, помогают оставаться продуктивным. Вместо ожидания очередного апгрейда, можно просто поработать, на время забыв про игру и вернуться, когда уже снова начнётся интересная часть.
Плюс, там и для любителей подумать есть где применить мозги. Помимо строительных Reactor Idle, Reactor Incremental и Factory Idle, почти в любой игре прогресс полностью зависит от решений игрока. У вас есть 100к денег, стоит ли купить несколько дешёвых апгрейдов или один дорогой? Или «перезапустить» игру сейчас с бонусом к скорости, потому что так через 8 часов получится больше прогресса?
Ну и просто приятно наблюдать за прогрессом чего-то, к чему приложил руку. Кто-то для этого заводит комнатные растения, кто-то — дачу, кого-то радует количество перепостов его картинки-мема, а кого-то — успехи сына-первокласника. Каждому своё.
Я так тоже считал, лет 12 назад, когда учился в школе, жил с родителями и играл в ММО-шки весь день. А когда начал «жить на свои» и кормить не только себя, само пришло понимание «почему человек должен работать». Тут даже не то, чтобы должен, а просто почему так происходит.
Но вообще, «лишнее», это то, что человек сам определяет таковым.
Зарплата зарплате рознь. Кому-то и 10к — зарплата, а кому-то и 50к — нет.
Если бы изучение и свои проекты были интереснее сериалов и компьютерных игр, то сериалов и игр бы не существовало. Практика показывает, что это не так, и большинству людей свои проекты не интересны (особенно если пару раз уже на этом обожглись).
Если введя новую фичу в проект, программист не поломал всё подряд, а фича работает — значит, это уже достаточно качественный код.
Иногда к коду также есть дополнительные требования — переиспользуемость, понятность, соблюдение стайл-гайдов. Чаще всего этих требований нет.
Но дело в том, что даже «чтобы ничего не поломать» и «чтобы скомпилилось, не тормозило и в целом работало» — уже требует сосредоточенности. Представлять себе это «минное поле» проекта, вспоминать, где и что может пойти не так.
Зависит от проекта и задачи, конечно. Ту же валидацию е-мейла можно допилить к полю ввода и не просыпаясь, а вот, например, «добавить новый тип пользователей с ограниченными правами» уже так просто не получится, даже если говнокодить.
Нужно вспоминать, где в проекте уже есть проверки на тип пользователя; как они себя поведут, если он новый; где вообще есть список типов пользователей, или оно всё в хардкоде; а если в хардкоде, то может пора переписать по-нормальному, ведь на неделе ещё 5 типов добавлять собираются; а может и так оставить, вдруг быстрее будет. Вот с такими задачами и бывает, что человек просто не может заставить себя начать неделями.
«Безошибочный код» в данном случае — код, который работает и, в общем, выполняет требования заказчика, а не в смысле идеальный. Если у вас функция выдаёт фигню, когда пользователь указал нулевое или отрицательное значение физической величины (вес, длина) — это не так страшно, по крайней мере для большинства проектов. Но если у вас 20 + 20 = 2020 (привет, JS), то это уже ошибка, которая перечёркивает собой всю остальную работу.
Работа «в данный момент» никогда не бывает важна, потому что положительный результат от неё приходит намного позже — после того, как выплатят зарплату и после того, как эти деньги на что-то понадобятся.
А прокрастинация существует, если человек занимается чем-то явно лишним вместо работы. Если этот конкретный час он всё равно не смог бы работать, это уже не прокрастинация, даже если дело с виду бесполезное. Статья о том, что некоторые «бесполезные дела» важнее других.
Примеры, которые вы приводите, тоже относятся к системному решению задач (для решения задачи создаётся и продумывается система) и, да, в них отчасти справедливы те же принципы.
Разница тут, на мой взгляд, не в цене ошибки, а в «дискретности» результата. Т.е. например менеджеры решили, что для замены сломанного компьютера работники должны писать заявку, а соответствующий отдел должен её регистрировать и высылать ответ. Если они не оговорили точный формат заявки и ответа, то люди на месте разберутся, «что-нибудь придумают». Программа же без чёткого формата просто не отработает.
И если менеджерам просто укажут на недоработку, то программисту ещё нужно будет доказать, что он вообще что-то делал, а не просто так сидел. И это не всегда возможно.
Поэтому, с точки зрения прокрастинации, менеджер и может себе позволить ответить на email-переписку невыспавшимся и прочитавшим по-диагонали, он не будет перед этим часами сидеть и приходить в нужное состояние.
Было бы также интересно почитать, как вы справляетесь с частой проблемой low-cost разработки — капризными клиентами, которые выбирают малобюджетные варианты, а потом пытаются «выжать все соки» из заказа, потому что денег на доработку не предвидится.
Поясню мысль.
Первая задачка (с последовательностью без числа) в реальности может встретиться, например, при работе с БД. Есть список каких-то записей (юзеры, товары, транзакции — не важно), у них есть ID от 1 до N (autoincrement), есть некая функция, которая их удаляет, нам нужно узнать, что было удалено.
Тут стоит заметить, что во-первых, обычно используется не удаление, а установка какого-нибудь status: disabled (или установка null в поле, если прямо так необходимо избавится от информации). Удаление может вызвать кучу проблем и головной боли в последствии, не надо так.
Во-вторых, обычно всё-таки не должно возникать ситуации «у нас в БД что-то пропало, неизвестно что». ID удалённого объекта должен записываться в момент удаления и обрабатываться сразу же.
Но ок, допустим, какое-то вероисповедание нам не позволяет исключить возникновение такой ситуации. Тогда в-третьих: даже если мы делаем проверку суммы сразу после удаления чего-то, никогда нет гарантии, что в самом деле что-то было удалено, или что была удалена только одна запись. Даже если сегодня это так, завтра функцию могут переписать.
В итоге, человек, который считает, что ответ с суммой — окончательный и достаточный для продакшена будет просто не прав. Тут либо переделка структуры, либо полный перебор ID'ов.
Вторая задачка (кувшины) — ну ок, лёгкая, математическая, чтобы решающий почувствовал себя увереннее. К IT отношения не имеет от слова «совсем».
Но вообще в реальных задачах такого типа (когда есть возможность что-то решить, нестандартно используя существующие объекты), нужно в первую очередь начать задавать вопросы.
Почему такая задача вообще возникла и к ней не готовы? Может, в ТЗ опечатка и нужно всё-таки 3 литра?
Почему у нас нет кувшина на 4 литра? Может, он всё-таки есть и стоит его поискать? Чтобы не занимать те два кувшина, которые явно уже предназначены для других целей и могут понадобиться остальным.
А если скоро опять возникнет такая задача? А если в следующий раз — 1/4 литра? Может, стоит озаботиться покупкой кувшина с литровыми отметками, а не тратить своё время на «костыльные» переливания?
Третья задачка (поменять переменные местами) — да, задачка интересная. В реальности встречается, но крайне редко. Тут только нужно пояснить, в этой самой реальности для решения используют встроенную функцию (обычно называется Swap), либо (на худой конец) третью переменную. А за неожиданный уход в побитовые операции пускают лучи неневисти (те, кому потом придётся поддерживать такой код).
Зато теперь достоверно известно, что есть люди, которые финансово заинтересованы вас вычислить, найти и привести в РОВД. Как минимум, они точно смогут в суде оспорить сделку (сложно будет доказать, что вы выполнили «свою часть» сделки) и обязать вернуть деньги. Как максимум (как уже указали выше), тут может быть достаточно на статью. Да и налоговой тоже будет интересно.
Тратить значительную часть денег на комиссии, переводы и мини-аккаунты для вывода? Постоянно ограничивать себя в тратах, чтобы не светиться? Ворочаться, вспоминая, не забыл ли включить тор, когда в последний раз заходил на аккаунт? Вздрагивать от каждого стука в дверь?
Так себе, честно говоря.
Вычислить можно по тому, куда идут деньги, кто владеет сайтом/доменом, кто оплачивает его рекламу и хостинг. «Можно» тут в смысле «теоретически возможно», а не что каждый это может сам.
У кого в итоге оседают деньги? У рекламщиков. Такие сайты не выходят по поисковым запросам, поэтому существуют по принципу, грубо «вкинул 1к в рекламу, повезёт — вернётся 2к, не повезёт — 500». Рекламой могут быть баннеры, всплывающие окна, спам. Можете сами провести аналогию с казино и кто в этом случае является его «владельцем».
Вот это вообще гениально. На ровном месте создаётся обёртка для синтаксиса языка, которая не несёт вообще никакой пользы.
Просто представьте, что через пару лет после написания этого кода у вас возникла ошибка — вы захотели вывести несколько коллекций в порядке возрастания суммы, но результат вас удивил — порядок явно не тот. В чём проблема — неправильные исходные данные ('null' вместо null), ошибка в сортировке или в функции определения веса?
Вы начинаете копать функцию определения веса и видите этот спагетти-код из микро-функций, которые разбросаны по разным местам разных файлов вашего проекта (код-то «переиспользуемый»). И каждый раз, встретив функцию, вам нужно её индивидуально искать, разбираться, что она делает, и потом возвращаться к тому месту, где остановились.
Не забывайте, мы лишь рассматривали простую функцию подсчёта веса коллекций. Примитив. А теперь представьте, что у нас что-то сложнее и ближе к реальному миру — например, функция, которая определяет, сколько нужно коробок, чтобы переслать N предметов разных габаритов (с учётом всех нюансов — габаритов, ограничений по весу, требований не класть в одну коробку тяжёлое с хрупким, таможенных особенностей). Сколько там можно написать микро-функций? Сколько времени у вас займёт найти среди них ошибку округления?
Если блок со скидкой 90% и таймером повысил продажи — так естественно, это же M — мотивация.
Если тот же самый блок понизил продажи — так чего ж вы хотели, это же T — доверие, кто же в здравом уме будет доверять скидке в 90%?
Если нужно повысить продажи, как определить, чего именно из S T M не хватает на сайте? Есть ли примеры «golden ratio»? Кейсы «было-стало» с цифрами повышения конверсии? «На глаз»-то и без всякой теории можно что-нибудь придумать.
Просто если брать изначальные вопросы как «стоит ли вносить правку Х? повысит ли она конверсию? насколько? это оправдает затрату человеко-часов?», то теория вообще не может дать уверенного ответа, даже в примере с «игрой со шрифтами».