Рубрика «здравый смысл» - 5

Так получилось, что мы играем в игры на высокой сложности. Причина вовсе не в том, что мы упорные обдолбанные гики, а в простой рациональности — желании получить от игры удовольствие.

Дело ведь в чём: раньше все игры были достаточно сложными, потому что были рассчитаны на куда более хардкорных геймеров. Когда у тебя нет интернета, картриджей всего 5 штук, а делать нечего — ты играешь в то, что есть. И пройти игру для ребёнка в 90-х означало вовсе не то, что сегодня.

image

Сегодня «пройти» — это потратить какое-то время на то, чтобы «просмотреть» сюжет и сделать 200 save-load. А раньше «пройти» — это целый подвиг. Вспомните хотя бы советскую «Ну, погоди!». Я до сих пор помню, как зашёл на долгожданный финал… и увидел, что игра циклична как тетрис. Мультфильм тоже не показали.

Но вернёмся к тому, почему только hard или hardcore. И какое это имеет отношение к GameDev и бизнесу. Читать полностью »

Что такое маркетинг, и почему эти люди пытаются обмануть вас в большинстве случаев — ликбез

Зацепил меня один кусок дискуссии про маркетинг сегодня на Хабре. Что это, как это, как оно для IT. Всё там хорошо кроме одного — нет понимания, что маркетинг — это не специальный шаман в проекте, который что-то там крутит, а фиговина, в которой должен живо принимать участие каждый. В IT, не в IT — не важно. Поэтому расскажу, почему.

Представьте себе небольшую парикмахерскую на первом этаже жилого дома. Наверняка у вас есть такие рядом. У неё очень ограничен круг потенциальных клиентов – это жители ближайших домов. Маркетинг – это сделать так, чтобы большинство из них стриглись именно там. Каждый косяк – это потерянный клиент (а новому взяться негде, помните?). Каждый успех – это клиент на 5-6 лет минимум, то есть не одна стрижка, а сразу много.

С другой стороны, мы чаще наблюдаем ситуацию ресторана на потоке туристов. Турист поест и не вернётся. Главное – чтобы он зашел и сел. Можно готовить почти баланду, можно хамить, можно терять клиентов направо и налево. Турист не вернётся. Вам плевать на него.

Так вот, маркетинг – это сделать так, чтобы продукт и клиент сошлись. В моём понимании – пройти всю цепочку от разработки и производства продукта до его продажи и использования в течение нескольких лет. Найти все места этой цепочки, где можно сделать лучше – и сделать это. Поработать с людьми внутри компании, чтобы они понимали, зачем всё это и почему.Читать полностью »

IT-интерфейсы часто растут из физических. Например, вот аппаратные чекбоксы:

Интерфейсы в реальном мире

Вообще, лучший же пример правильного инженерного интерфейса – это гранёный стакан.

Почему? Очень просто. С одной стороны, он дружелюбен к советским роботам: круглая верхняя полоса позволяет автоматической мойке нащупать его ещё с 40-х годов. С другой стороны, он прощает человеческие ошибки: ребра останавливают скатывание стакана со стола при падении. Плюс он просто красивый.

Сейчас покажу ещё несколько интерфейсов, которые облегчают жизнь. Общий смысл – попробовать понять, как думал разработчик, чтобы сделать что-то удобнее. Читать полностью »

Вот наш старый чек, который печатается практически по всей сети. Если присмотреться, на нём много полезной информации, но совершенно нет духа дружелюбия и хоть какой-то минимальной эстетики.

Дизайн кассового чека

При этом чек уносит с собой каждый наш покупатель, и это попросту глупо не использовать. Равно как стоит добавить бумажке немного полезности. Читать полностью »

Мы все знаем, что при росте организации решения руководства обычно становятся все более и более неоптимальными, все дальше отходят от здравого смысла. Это связано с общим законом сложных иерархических систем, в которых руководство не выбирается, а назначается (в результате назначаются люди, худшие, чем назначающий руководитель).

Это все понятно, но почему руководство в больших организациях зачастую принимает не просто неоптимальные, но абсурдные решения? Почему не руководствоваться ну хотя бы здравым смыслом?
Под катом несколько примеров из трудовой биографии старого опытного программиста.
Читать полностью »

The Good, the Bad and the Ugly code
Хороший код или плохой? Лично для меня хороший код обладает следующими качествами:

  • Код легко понятен разработчикам разной квалификации и хорошо структурирован
  • Код легко изменять и поддерживать
  • Приложение выполняет свои функции и обладает достаточной, для выполняемого круга задач, отказоустойчивостью

Несмотря на короткое описание, о том, как добиться выполнения трех этих условий, написано много толстых книг.

Почему именно эти критерии? Сразу оговорюсь, речь сейчас идет о разработке ПО для бизнеса (enterprise application). Критерии оценки кода для систем реального времени, самолетов, систем жизнеобеспечения и МКС отличаются.
Читать полностью »

Существует много модных современных концепций: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. Все они хороши. Вникание, а тем более использование, сильно расширяет горизонты. Но надо понимать, что это всё довольно общие вещи. Нужно не забывать использовать голову и чётко осознавать применимость в собственном проекте.

Фанатичное следование методологии напоминает восторг от осознания какой-то возможности в языке программирования. Я сам поддавался такому не раз: «Круто, в Python есть метаклассы — срочно используем в проекте» — несмотря на то, что того же самого можно было добиться обычными атрибутами класса. «Вау, макросы Lisp — это супер, накодим их побольше» — хотя можно было обойтись функциями высшего порядка. Сначала делаешь так, а со временем свыкаешься и уже не суёшь эту мощную возможность куда попало, а используешь, только если она действительно нужна.

Все теории когда-то были молодыми. Даже те, что сейчас считаются немодными и устаревшими когда-то были прорывом. Просто сейчас они утратили былой блеск, так же, как утрачивают блеск мощные возможности в языке программирования.

Где тот момент, когда они устаревают? Где те условия, в которых они работают, и в которых уже нет? Может быть, новый тренд уже стал устойчивым стереотипом и необходимо движение дальше? Эти вопросы нужно всегда задавать себе и пользоваться/не пользоваться концепцией не потому что она прогрессивна/устарела, а потому что она подходит/не подходит лично вам в конкретном деле.
Читать полностью »

Ответ на статью.

Если вы не разрабатываете ПО для машин или систем автоматического поддержания жизни и тд — нижесказанное работает для вас при грамотном применении

Во-первых, говнокод на первом этапе обязателен. Причин куча. Раз — вы ничего не знаете о реальных условиях работы приложения, все ваши домыслы фигня. Пока реальный опыт не получен, пока не занесены первые живые данные реальным пользователем — у вас нет обратной связи. Если вы не согласны, почитайте Макконнелла, миф о стабильных требованиях, и получите левелап.
Читать полностью »

Ответ на статью.

Если вы не разрабатываете ПО для машин или систем автоматического поддержания жизни и тд — нижесказанное работает для вас при грамотном применении.

Сразу скажу — не моя идея, в статье «Проектирования больше нет?» сам Мартин Фаулер писал об эволюционном рефакторинге. А Боб Мартин даже целую книгу запилил с примером поэтапного развития приложения (и не одним), назвав «Быстрая разработка ПО» и продемонстрировав умение виртуозно материться на Java и C++.

Во-первых, говнокод на первом этапе обязателен. Причин куча. Раз — вы ничего не знаете о реальных условиях работы приложения, все ваши домыслы фигня. Пока реальный опыт не получен, пока не занесены первые живые данные реальным пользователем — у вас нет обратной связи. Если вы не согласны, почитайте Макконнелла, миф о стабильных требованиях, и получите левелап.
Читать полностью »

Товарищи читатели, а вы рассматривали всю шумиху, где слово Samsung соседствует со словом Apple, как осознанную (и куда как эффективную!) маркетинговую политику первой? В которой основная роль отводится как раз всем нам, «технически подкованным» крикунам, которых хлебом не корми — дай похоливарить?
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js