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

Источник: 1877 Harpers Weekly November 24-MA barely saves GOP [1]

Многие игры специально создают (или провоцируют) такие ситуации, чтобы встряхнуть своих игроков. Конечно, об использовании таких методик в пресс релизах не говорят. А особенно талантливые разработчики умело прячут эти свои «грязные хаки» даже от опытных игроков.
Далее я перечислю известные мне примеры таких хаков, чтобы разработчики смогли взять из них самое хорошее, а игроки научились распознавать самое плохое и коварное.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Вопреки провокационному заголовку, это никакая не новая архитектура, а попытка перевода простых и проверенных временем практик на новояз, на котором говорит современное Android-комьюнити

Введение

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

Айтишные сайты заполонили туториалы по модным фреймворкам и переусложненным архитектурам, но при этом даже нет best practice для REST-клиентов под Android. Хотя это один из самых частых кейсов приложений. Хочется чтобы нормальный подход к разработке тоже пошел в массы. Поэтому и пишу эту статью

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

В небольшой команде тимлид может попытаться судить обо всем происходящем на основе субъективных ощущений, но, чем больше компания, тем важнее использовать объективные данные и метрики. Александр Киселев (AleksandrKiselev) и Сергей Семенов в своем докладе на TeamLead Conf показали, как использовать данные, которые вы уже накопили, где взять дополнительные, и что они все вместе могут помочь определить неочевидные проблемы. И даже, аккумулировав опыт многих коллег, предложили варианты решения.


О спикерах: Александр Киселев и Сергей Семенов в IT мы уже больше 8 лет. Оба прошли путь от разработчика до тимлида и далее до product-менеджера. Сейчас работают над аналитическим сервисом GitLean, который автоматически собирает аналитику у команд разработки для тимлидов и CTO. Задача этого сервиса в том, чтобы технические менеджеры могли принимать свои решения на основе объективных данных.

Если вы программист (или чего хуже архитектор), то можете ли вы ответить на такой простой вопрос: как писать НЕ тестируемый код? Призадумались? Если с трудом можете назвать хотя бы 3 способа добиться не тестируемого кода, то статья для вас.

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Одним из параметров оценки кода служит его чистота. Создатель языка моделирования UML Гради Буч (Grady Booch) писал:

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

Сегодня мы собрали для вас список книг и статей по этой теме, которые рекомендуют к прочтению резиденты Hacker News, Stack Exchange и других профильных платформ.

После 10 лет работы в качестве ИТ руководителя, когда за плечами уже достаточно выполненных проектов и компаний, а также опыт создания проектного офиса, видишь все вокруг немного иначе. Любую уникальную задачу хочется декомпозировать на подзадачи, расположить их на scrum-доске или на временной шкале, оценить приоритеты, риски, трудозатраты. К сожалению, в реальности, даже элементарные практики из проектного управления соблюдаются не всегда.

Именно о том, что всегда должно быть сделано при выполнении проекта мы и поговорим на неожиданном примере трансатлантического яхтенного перехода.

Продолжаем серию заметок о налогах при монетизации мобильных приложений на зарубежных площадках.

В прошлой статье Какие налоги нужно платить при выводе доходов от приложений в Apple iTunes мы кратко изложили алгоритм расчета налогов при получении дохода в iTunes Apple. Теперь предлагаем обсудить налоги с продаж приложений Google Play и рекламы Google AdSense.

Руководствоваться будем следующими договорами с Гугл, которые есть в официальном русском переводе на сайте корпорации:

• Соглашение Google Play о распространении программных продуктов
• Условия использования Google Play
• Условия использования Google AdSense

Подробности под катом.

Пару лет назад я заходил к родственнику. Моему бедному кузену (а он генеральный директор страховой компании) продали «серебряную пулю Agile» — но она не сработала, и его это очень расстроило:

Чушь всё это! Мы начали делать всё совершенно иначе. Мы пригласили консультантов. Мы наняли специальных руководителей проектов. Не сработало! Ничего не изменилось. Никто ни за что не отвечает. Я слышу только оправдания.

Не помню, что я ответил тогда, но знаю, как ответил бы сегодня. Я бы набросал несколько рисунков, словом не упомянув Agile. Пришлось бы объяснить кузену несколько основных понятий…

Переведено в Alconost

1. КПД процесса

Цель данной статьи — вместе с читателем написать окружение для разработки современных веб-приложений, последовательно добавляя и настраивая необходимые инструменты и библиотеки. По аналогии с многочисленными starter-kit / boilerplate репозиториями, но наш, собственный.

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

Автор полностью открыт для доработки и исправления текущей статьи, и надеется на превращение итогового материала в актуальный и удобный справочник, интересный и для профессионалов, и для желающих опробовать новые для них технологии.

Вы читаете эту статью потому, что, как и я, с горячим интересом наблюдаете за возрастающей популярностью криптовалюты. И вам хочется понять, как работает блокчейн — технология, которая лежит в ее основе.

Но разобраться в блокчейне не так-то просто, по крайней мере, по моему опыту. Я корпел над заумными видео, продирался через туториалы и с нарастающей досадой отмечал недостаток иллюстрирующих примеров.

Я предпочитаю учиться в процессе работы. При таком раскладе мне приходится отрабатывать тему сразу на уровне кода, что помогает закрепить навык. Если вы последуете моему примеру, то к концу статьи у вас будет функционирующий блокчейн и ясное понимание, как это все работает.

Небольшое вступление

Spark — это просто чудесный микрофреймворк для создания веб-приложений на джаве без особых усилий.  Spark стремится к простоте и обеспечивает только минимальный набор функций. Тем не менее он предоставляет все необходимое для создания веб-приложения, которые поместятся в несколько строк кода. С синтаксисом, вдохновленным Sinatra, код выглядит очень чистым.

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

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

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

Привет Хабр! Летом мы переводили цикл статей про Bash-скрипты — судя по отклику, статьи оказались для вас полезными. И, по многочисленным просьбам, мы решили сделать PDF-версию перевода.



Подробности под катом.

За свои 12 лет работы в сфере разработки ПО, мне посчастливилось поработать в команде только два раза. Хотя я сменил порядка десяти мест работы. Но попробовав раз, ем и сейчас… Т.к. я не жадный, и готов своими достижениями делиться с сообществом, то решил я предпринять попытку вывести из равновесия неумных руководителей, которые до сих пор не осознали важность команды, а также тех руководителей, которые профессионально занимаются самообманом — мол, они строят команду, а на деле — тьфу, а не команда.

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

Некоторые из DevTools функций вы возможно не знали. Я буду очень счастлив, если хотя бы одну из них вы найдете для себя полезной.

(В статье ниже присутствуют анимированные гифги, которые начинают раздражать после первого цикла. Поэтому я советую открыть dev tools и удалить DOM ноды, которые отвечают за изображения.)

Итак, поехали:

Копируем переменную в буфер обмена

Об этой возможности я узнал из комментариев, и считаю ее достаточно полезной чтобы быть описанной в начале. Иногда бывает нужно скопировать содержимое переменной в буфер обмена. Например html код или json объект. Для этого можно использовать copy функцию.

copy (someVariable)

Теперь текстовое представление переменной скопировано в буфер обмена.

Перейдем к самому интересному — подборке самых полезных и интересных, на наш взгляд, трюков и скрытых возможностей Chrome DevTools.

Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.

Сервис omg-img позволяет вставлять иконки вот так:

<img src="https://png.icons8.com/search">

Чувствуете, к чему я клоню? Сделали вставление иконок не выходя из IDE. Просто пишете URL, параметры вроде цвета и стиля — мы отрендерим иконку и отдадим через хороший, годный CDN.

Вместо search можно написать любое название иконки:

• home
• sheep-on-bike
• trump