The Design of Everyday Things

The Design of Everyday Things

Любопытная книга The Design of Everyday Things, автор Donald Norman. Дизайн это сложная дисциплина, которая отвечает за то, как люди взаимодействуют с материальным и нематериальным (внешний вид — это только один небольшой аспект дизайна). Эта книга покрывает многие (все?) стороны дизайна, начиная с того, что подсознательно происходит в головах у людей, и кончая местом дизайна в мире бизнеса.

Объясняется, почему мы путаем ручки конфорок на плитах и почему в очередной гостинице бывает трудно разобраться с душем. Отдельная большая глава посвящена человеческим ошибкам (автор разбирается в психологии). Я был рад получить из неё подтверждение своим мыслям по поводу человеческого фактора: поскольку всем известно, что людям свойственно ошибаться, нельзя ссылаться на эти ошибки как на причину техногенных аварий. Если человеческая погрешность привела к беде, виноват дизайн.

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

Getting Things Done

Прочитал «Getting Things Done: The Art of Stress-Free Productivity» — знаменитую книгу Дэвида Аллена о персональной продуктивности, «доведении дел до конца». Я её купил больше из интереса, чем из надобности, всё-таки я не очень уж и занятой человек (а когда и если стану очень занятым, будет уже не до книг). Впрочем, даже так книга вполне оправдала себя.

Getting Things Done: The Art of Stress-Free Productivity

Одна из главных идей, которую приводит автор, в том, что все дела, поручения, проекты, списки и подобное не надо держать в голове: так они будут забываться, не вовремя всплывать и отнимать внимание, мешая сосредоточиться. Их нужно «выгружать» на внешние «носители» — компьютер, ежедневник, диктофон, крестик на руке. Автор приводит хорошую аналогию с оперативной памятью и жёстким диском компьютера. Ваш мозг — это ваша ограниченная объёмом оперативная память. Вам не нужно всегда держать в ней всё, а только нужное в данный момент. Остальное можно выгрузить на жёсткий диск.

Другая важная идея — для каждой задачи должно быть ясно и чётко определено следующее физическое действие, которое нужно выполнить. Звучит как излишество, но автор утверждает, что это архиважно. Иногда определить следующее видимое физическое действие сложнее, чем кажется: например, нужно сначала что-то спланировать, или получить какую-нибудь дополнительую информацию о задаче. Тут я и сам замечал, что попытки решить сложную абстрактную задачу, которая притворяется простой задачей вида «сесть и сделать», чаще приводят к прокрастинации.

Автор предлагает одноимённую систему Getting Things Done для ведения дел. Она умеренно сложна и состоит из нескольких процессов: сбор, обработка, организация, выполнение, обзор. Утверждается, что система хорошо масштабируется для любого количества задач и проектов.

Кстати, речь в Getting Things Done идёт не только о продуктивности на работе: все советы вполне применимы и для личной жизни, ведь бытовые задачи ничем принципиально не отличаются от рабочих.

Теперь немного о том, что не понравилось. Во-первых, там есть главы про планирование проектов, мозговое штурмование, выработку идей. Эта информация вызвала мало интереса, и вообще её полезность лично для меня сомнительна. Во-вторых, книга писалась во времена бумажных ежедневников, липких заметок и Palm PDA на вершине эволюции карманных компьютеров, задолго до смартфонов, хорошего мобильного интернета и облачных сервисов. Поэтому в ней много внимания уделяется именно выбору инструментов. Я думаю, что если в этом году автор решил бы переиздать книгу, вместо многих слов про картонные папки и бумажные файлы он бы просто предлагал взять смартфон и компьютер, подключить их к любому из множества имеющихся сервисов для ведения дел (Remember the Milk, Wunderlist, Evernote, Things — это малая их часть), многие из которых, кстати, вдохновлены именно системой GTD.

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

Eloquent JavaScript: A Modern Introduction to Programming

Eloquent JavaScript: A Modern Introduction to Programming

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

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

Но есть в ней и некоторые странности. Книга вроде как рассчитана на начинающих программистов, поэтому, с одной стороны, там описаны некоторые основные концепты, хорошо знакомые каждому разработчику, но с другой стороны, такого объёма знаний начинающему программисту явно не хватит. По той же, видимо, причине, в книге есть отдельная глава про алгоритмы поиска в графах и ещё одна про бинарные кучи (binary heaps). Зачем автор охватил эти темы, и почему именно их, для меня загадка. Эти главы я пропустил.

Но в целом я доволен. Ещё раз ссылка: Eloquent JavaScript: A Modern Introduction to Programming.

Сам язык, кстати, создал похожее впечатление. Он вроде как задумывался «для домохозяек», а получился, наоборот, довольно нетривиальным.

Дальше мне по плану надо ознакомиться с jQuery, но вместо него я займусь ПДД Калифорнии, а то дальше их откладывать уже некуда.

Как люди думают?

Книгу Дмитрия Чернышева «Как люди думают?» прочитал на одном дыхании. Пожалуй, самая интересная идея, которую я там вычитал, о том, что все люди мыслят более не менее одинаково. Отличия обусловлены только тем, что мы читали разные книги и общались с разными людьми. Ну и случайностями. Не существует таких вещей как гениальность, талант, божья искра и подобных. «Вы можете достать из своей головы только то, что когда-то в нее положили. Немного перегруппировав и видоизменив.» Об этом же, кстати, говорил и Жак Фреско.

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

Далее некоторые цитаты из книги, которые я себе отметил.

Continue reading “Как люди думают?”

Как избегать deadlock’и

Этот вопрос мне задали года полтора назад на первом телефонном собеседовании в Майкрософт. Я ответил что-то невнятное типа «ну концентрировать весь concurrency-related код в как можно меньшем числе классов, чтобы удобнее было разбираться в проблеме». Это собеседование я не прошёл.

Java Concurrency in Practice для решения проблемы дедлоков предлагает, по крайней мере в главе про дедлоки, следующее решение:
If you must acquire multiple locks, lock ordering must be a part of your design: try to minimize the number of potential locking interactions, and follow and document a lock ordering protocol for locks that may be acquired together.

Однако более полный ответ на этот вопрос я увидел, как ни странно, в Чистом коде Боба Мартина, в той главе, которая там вроде как ни к месту. Там приводятся следующие обязательные условия возникновения дедлока:

  • Mutual Exclusion
  • Lock and Wait
  • No Preemption
  • Circular Wait

И предлагаются способы исключить каждое условие:

Mutual Exclusion:

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

От Lock and Wait избавиться можно так: проверяем ресурс перед захватом; если он занят, то освобождаем все захваченные ресурсы. Этот подход может привести к новым проблемам: Livelock и Starvation.

No Preemption: разрешаем потокам запрашивать ресурсы друг у друга. Я никогда в жизни такого не видел и не представляю, как это хорошо реализовать. Пишут, что это непросто.

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

* * *

Особые юмористы могут отметить при ответе на вопрос, что переход на один лок или один поток также решает проблему.

Чистый код

Дочитал наконец «Чистый код» Роберта Мартина (Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin). Книга является сборником советов и правил написания хорошего и улучшения плохого кода. Она может быть интересна в первую очередь программистам на Java.

Миша про эту книгу говорил, что она какая-то капитанская (то есть в ней написаны очевидные вещи — от Капитана Очевидность). Так оно на самом деле и есть, но это не делает её плохой или бесполезной. По мере прочтения я несколько раз осознавал, что некоторые правила хорошего кода я нарушал и продолжаю нарушать. Поэтому считаю, что, несмотря на малость полученных знаний, перечитывать что-нибудь подобное время от времени очень даже полезно.

Ещё хотел заметить, что Appendix A: Concurrency II совсем не раскрывает темы чистого многопоточного кода. Такое ощущение, что это выдранная глава про concurrency из учебника Java для начинающих.

Понравилось заключение к одной из глав:

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don’t have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a develop- ment project than bad code. Bad schedules can be redone, bad requirements can be rede- fined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down. Time and time again I have seen teams grind to a crawl because, in their haste, they created a malignant morass of code that forever thereafter dominated their destiny.

Of course bad code can be cleaned up. But it’s very expensive. As code rots, the mod- ules insinuate themselves into each other, creating lots of hidden and tangled dependen- cies. Finding and breaking old dependencies is a long and arduous task. On the other hand, keeping code clean is relatively easy. If you made a mess in a module in the morning, it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it’s very easy to clean it up right now.

So the solution is to continuously keep your code as clean and simple as it can be. Never let the rot get started.