igrishaev

Вскоре после этой истории Никита нас покинул. Это было ожидаемо: после истории с медведем он уже не мог повысить накала. Никита примкнул к другой компании, средней возраст которой тоже был младше его. Как-то раз, проходя мимо, я издали увидел его в окружении новых поклонников. Знакомая картина: взгляды прикованы к нему одному; Никита картинно растопырил руки, изображая то ли гопника, то ли милиционера из своих похождений. Интересно, они уже дошли до медведя? Вряд ли, но все еще впереди. Иногда я вспоминаю эту историю. Интересно, какая все же истинная причина этих шрамов? Случай с медведем, скажем прямо, маловероятен, зато отлично подходит для пьяных выступлений. Может быть, все гораздо прозаичнее: либо на Никиту напала бешеная собака, либо ее натравили на него за какую-то провинность, например кражу. Такие обстоятельства не тянут на рассказ, поэтому пришлось сочинить про медведя, кровь и кишки. Вот так. Эх, Никита! Каким колоритным и харизматичным ты был, как врезался в мою память! Где бы ты ни был, желаю тебе уберечься от невзгод, прожить долгую и счастливую жизнь. Храни тебя бог, случай, фортуна – во что там веришь. Надеюсь, так и случится – несмотря на твое упорное желание добиться обратного.

Сюжет истории закручивался даже с несвойственной Никите лихвой. Перепившись сверх всякой меры, компания пошла смотреть на зверей. К тому времени была поздняя ночь. Никита потерял сознание, и заботливые приятели воспользовались этим, чтобы пошутить. Никиту втащили в вольер с медведицей, решив, что ему будет забавно проснуться рядом с ней, и ушли. Пробуждение Никиты было кульминацией рассказа. Трудно выразить всю ту театральность, что он вложил в речь, жесты, мимику. Передать его старания может лишь картина Перова "Охотники на привале": тот же взгляд, глаза на выкате, растопыренные пальцы, изображающие зверя. Все взгляды прикованы к рассказчику, и у него абсолютная власть над аудиторией. Никита вещал следующее: "Просыпаюсь я такой, короче, башка болит, перед глазами круги. На каких-то, короче, досках, все мокрое. И какая-то туша передо мной в шубе. Кто это и что это – не понимаю. Тут я привстал и присмотрелся, а это, сука, медведь! Огромный как диван, рядом лежит, чуть ли не обнимает. Наверное, думал, что я мертвый. Тут он увидел, что я очнулся, и морду ко мне придвинул. Я такой как заору! Встать не могу, тело не слушается, так я начал от него ногами отталкиваться и все ору! А он, короче, тоже заревет да как полоснет меня когтями по животу! Продрал майку и весь живот! Пошла кровь, чую – из меня кишки вываливаются! Кругом чьи-то крики, топот. Сторож вбежал в вольер, отбил меня от медведя, выволок из вольера. Из живота кровища, сука, льет как из крана. Потащили они меня в машину и отвезли в больницу. Там я и пролежал три месяца, пока лечили живот." Закончив историю, рассказчик сплюнул, закурил которую по счету сигарету – за час он выкуривал больше, чем мы за день – и приготовился ждать вердикта. А мы, обалдевшие от такого развития, молча сидели с открытыми ртами. Всякое рассказывал нам Никита, но чтобы медведь и кишки… это был новый уровень. Нужно было время, чтобы прийти в себя. А Никита курил, сплевывал и спокойно ждал. Мало помалу мы вернулись в реальность и стали робко высказывать мнение, что хотя рассказ и поразительный, но он мало похож на правду и вообще, может быть, ты что-то выдумываешь… Никита ждал. Не дождавшись его возражений, мы вконец осмелели и сказали, что все-таки не верим: этого быть не могло. Получив такой вердикт (на который, впрочем, он и рассчитывал), Никита не просто нас уничтожил, а втоптал в грязь и растер каблуком. Отложив полторашку пива, которую он, словно младенца, нянчил на коленях, Никита встал и задрал майку до подбородка. Под ней обнаружилось когда-то мощное тело (байки про рестлинг могли быть правдой), заплывшее пивным жиром. А сверху вниз через весь живот, от груди до паха, шли восемь глубоких шрамов: четыре слева и четыре справа. Без сомнения, эти шрамы были оставлены хищником – получить такие в быту невозможно. Шрамы были неровные; те, что посередине, были шире и глубже. Особенно меня поразила их глубина: словно канавки, они вдавались в тело на полсантиметра, а где и глубже. Какой же глубины тогда была рана? Полагаю, сантиметра два, не меньше. Разглядывая шрамы, я смутно подумал, что пивной жир спас Никите жизнь. Будь он тощим как я в пятнадцать лет, когти обязательно задели бы внутренности. И не доехал бы Никита до больницы, а если бы и доехал, оказался бы в отделении, которое чаще всего устроено в подвале. Да, эффект быть просто уничтожительным. Если до этого мы были ошарашены рассказом, то демонстрация "пруфов" просто лишила нас слов. Шрамы были, и оспорить их было невозможно. Очевидно, Никита тщательно планировал свое выступление и, скорее всего, уже не раз исполнял его. Но даже не смотря на постановку и театральность, я не мог не оценить его мастерства.

Рассказ "Никита и медведь" Это было в Чите, когда мне стукнуло пятнадцать или около. Летними вечерами я несколько ребят собирались в условленном месте. Обычно мы курили сигареты и пили пиво – то и другое дешевое, максимально низкого качества. В то время купить табак и алкоголь несовершеннолетним не представляло труда: магазины никто не проверял, а предупреждения на дверях были фикцией. Под курево и алкоголь шли беседы: сплетни, душевные разговоры и похвальба всех мастей. Мы не были бунтарями или несчастными подростками: по большей части мы притворялись, играли роль. Ребята происходили из хороших семей, посещали школу и хорошо учились. У всех были карманные деньги. Редко кто приходил домой после полуночи, чтобы не ссориться с родителями (телефонов тогда не было, только пейджеры). Такие темы, как тяжелые наркотики или уход из дома или бродяжничество, были для нас табу. Как-то раз мы столкнулись с настоящим бездомным подростком, и это было жутко: все равно что встретить африканского аборигена-людоеда. Его неразвитость и бедная речь контрастировали с резкими, воровскими повадками, когда речь шла о каких-то грошах. После общения с ним мы все были подавлены. Поэтому, потребляя сигареты и пиво, мы делали это по-детски, оставаясь цивилизованными детьми, пусть даже с дурью в голове. Со временем в нашей компании появился новый участник. Звали его Никита, а уж фамилию я не вспомню. Никита был старше нас лет на пять, высокий и здоровый, с бородой. Вся его наружность говорила, что он – первый парень на деревне. Характер не уступал внешности: он говорил быстро и громко, много смеялся, на каждый случай знал анекдот. Он театрально играл голосом, отчего эффект шутки, пусть даже не смешной, усиливался многократно. Мир Никиты была эгоцентричным. В центре, как столп, был Никита, а остальные участники вращались вокруг него. Когда Никита приходил, вопрос о том, чем заняться, автоматически снимался. Все рассаживались как малые дети, а Никита восседал в центре и рассказывал истории – разумеется, о себе. Рассказывал Никита много и красочно. О том, как путешествовал автостопом. О том, как был ударником в группе (в рюкзаке у него были барабанные палочки, и он эффектно крутил их пальцами). Как занимался рестлингом, где и с кем пил. Как прятался в поезде от милиции, тусил с байкерами, укладывал в постель замужних женщин и многое другое. В каждой истории на него, казалось, ополчился весь белый свет: милиционеры, бабушки, гопники, ревнивые мужья – но Никита неизменно выходил сухим из воды. Шли дни. Новый гость часто посещал наши встречи. На тот момент мне не казалось странным, что Никита был в нашей компании. Однако совсем скоро, буквально через год, сама идея об этом стала неприятной. Предположим, хотя бы часть из рассказанного была правдой. Разве стал бы человек, бывавший в стольких ситуациях, просиживать штаны с малолетками? Как-то не вяжется: милиция, байкеры, женщины, а слушатели – пятнадцатилетняя шпана. Много позже, когда я повзрослел и стал разбираться в типажах, стало ясно: у Никиты были проблемы со сверстниками и, судя по всему, сверстницами. Не смотря на обилие женщин в его рассказах, нашего героя никогда не видели с девушкой – хотя, казалось бы, от желающих не должно быть отбоя. Недостаток внимания от сверстников Никита компенсировал тем, что понизил уровень окружающих – другими словами, предпочел нас. В какой-то момент Никита решил, про уже достаточно прогрел публику, и она готова для финальной – ультимативной! – истории. Дождавшись дня, когда пришли все, герой уселся в центр, закурил и поведал нам ее. Начиналась история весьма невинно: Никита опять с кем-то пил. Сменив то и другое место, компания оказалась в ночном зоопарке – один из участников работал в нем сторожем. На мой взгляд, зоопарк и вправду подходит для распития алкоголя. Территория огорожена и, так сказать, близка к природе. А тот факт, что где-то рядом спит лев или тигр, приятно щекочет нервы.

Для большинства из нас восьмибитные игры сводятся к танчикам, тетрису и всяким аркадам. Но бывало ли, чтобы вы наигрывали в восьмибитную игру дни и недели? Чтобы было погружение как фильм или книгу? У меня – да. В 1988 году (мне тогда было три) вышла игра The Guardian Legend. В "российском прокате" – то есть пиратских версиях Денди – ее почему-то назвали Chi Day Story, так что игра известна под двумя именами. The Guardian Legend интересна во многих направлениях. Это был мультижанровый микс: летающий экшен и ролевая игра. В целом она опередила время и позже была признана эталоном. TGL была сложной и многообразной; я не мог оценить ее в детстве, не говоря уж о том, чтобы пройти. Будущее, к Земле приближается огромная космическая станция. Мы управляем девушкой-киборгом, способной превращаться в звездолет. Игра начинается с пролога: нужно подлететь к станции, пробить ее защиту и попасть внутрь. Здесь игра переходит в ролевой режим. Станция представляет собой целый мир, и мы начинаем его исследовать. Мир делится на экраны-комнаты, где нужно побеждать врагов, сражаться с мини-боссами, искать усилители и так далее. Цель – найти специальный портал в туннель. Прыгнув в него, девушка превращается в звездолет, и мы переходим в режим экшена. В конце туннеля ждет босс, а за победу дают ключ к новой части карты. По ходу игры мир расширяется, героиня открывает все больший арсенал, появляются различные механики, туннели и боссы становятся все более жуткими. Попадаются миролюбивые аборигены, с которыми можно торговать. Некоторые дают подсказки, как открыть туннели, запечатанные загадками. Игра затягивает, и немало счастливых часов я провел в детстве, исследуя The Guardian Legend. Трудно передать словами, что же особого игре и чем она опередила время, но все же я попытаюсь. Пожалуй, главная находка разработчиков – это поощрение исследовать игровой мир. Дело в том, что сложность игры растет очень быстро, и особенно это заметно в туннелях. Если первые два игрок еще осилит, то соваться в следующие без прокачки не имеет смысла – проиграешь. Поэтому перед тем как открывать туннель, нужно побродить по округе в поисках усилителей. И вообще – всячески прокачивать девушку. По своим меркам игра масштабна. Она предлагает большой мир, отличную графику, разнообразие врагов, оружия, механик. В каждой зоне разный ландшафт. Также в игре прекрасная музыка! Темы главного экрана и подводных туннелей я запомнил, видимо, уже на всю жизнь. Игра хранит довольно большое состояние, поэтому пароли в ней очень длинные. Представьте, каково было мне, ребенку, переписывать с телевизора 32 символа [a-zA-Z0-9], чтобы сохраниться? Тогда ведь нельзя было сфотать экран. Сколько раз я терял листочек или переписывал с ошибками, из-за чего приходилось откатываться на старые пароли… В игре не было всяких справок и уведомлений, как принято сейчас. Приходилось записывать, что находится в какой комнате, чтобы позже туда вернуться. У каждой комнаты были координаты X и Y; всего их было несколько сотен. Игра была слишком сложна для меня: замысел разработчиков просто не помещался в голове. Я прошел The Guardian Legend на эмуляторе, когда уже был взрослым. Даже тогда я поразился, насколько сложна игра… и вместе с тем – прекрасна. Чит: если ввести пароль TGL, включится экшен-режим. В нем полностью убрана ролевая часть, оставлены только туннели. Специально для тех, кто хочет зарубиться с боссами. Вряд ли вы кинетесь играть в восьмибитку 1988 года. Но знайте – есть такая жемчужина в мире игр, и есть те, кто ее любят и вспоминают с самыми теплыми чувствами. А если вы думаете, что я один такой чудик, то почитайте комментарии к прохождению на Ютубе. https://www.youtube.com/watch?v=ky6CtLVo8nM

На мой взгляд, TMNT 3 – лучшая игра про черепах. Есть множество других, но эта удачней всего сочетает сложность, аркаду, юмор и приключение. А еще в игре собраны почти все персонажи оригинального мультика 1987 года. Горячо вам ее рекомендую.

Игры 1 #games Давненько я не делал подборок по принципу чисел или постгреса. В этот раз я бы хотел поговорить об играх. В детстве я много играл; увидев в первый раз приставку денди, я понял, что это мое. Тогда я не знал, что стану программистом, но какая-то химия возникла. Увы, у меня не было Спектрума или других программируемых платформ; это были обычные денди, сега, первая плойка, комп. Переход на следующую приставку случался редко, примерно раз в пять лет. Жили мы небогато, и я годами копил за заветную железку. Я не избегал книг, однако игры развивали меня не меньше. Я запоминал сюжеты, персонажей, рисовал уровни по памяти, придумывал другие концовки. Обожал искать игровые механики, секретные уровни. О персонажах различных RPG мы с приятелем говорили часами, примерно как наша учительница – о персонажах "Войны и мира". А уж сколько было эмоций, когда мы собирались вчетвером, подключали к первой плойке четыре геймапада и рубились на одном телевизоре! В этой подборке я хочу рассказать об играх, которые мне запомнились. Уточню: это не обязательно хиты, в которые играли все. Скорее всего, о многих играх вы узнаете впервые, и я этому рад. Получив столько удовольствия в детстве, я в своем роде в долгу перед разработчиками. Мы, нищие дворовые пацаны, покупали пиратки: лицензионного контента не было в принципе. Едва ли разработчики получили хоть что-то с дисков и картриджей, что прошли через меня. Буду публиковать игры по нарастанию мощности платформы: денди, сега, плойка, писюк. В первом выпуске – замечательная игра для денди под названием Teenage Mutant Ninja Turtles 3: Manhattan Project. В народе – просто "третьи черепашки". Злой Шреддер поднял остров Манхэттен в небо, и надо идти выручать жителей. Игра начинается с пляжа, продолжается в море, затем мост, город, канализация, технодром, пещеры, небоскребы и другие локации. На каждом уровне два босса: промежуточный и финальный. Нам предстоит спасти Эйприл, победить обычного Крэнга и его супер-версию, а в финале сразиться с супер-Шреддером. В игре много юмора, враги появляются так, чтобы было не скучно их валить: выходят из-за края экрана, лезут из люков, телепортируются или даже собираются на конвейере. Игра довольно сложна: в детстве мне было трудно играть в нее. Она рассчитана на двоих игроков, и нет логики, которая определяет, сколько врагов выпускать: все захардкожено. Так что одному игроку приходится тяжеловато. Каждый, кто играл в третьих черепах, знает, что пройти ее можно только только за Леонардо – черепашку с мечами. Дело в том, что боссы в игре очень сильные, и приходится бить их суперударами. И здесь одна тонкость: суперудары других черепах работают по прямой. У Леонардо суперудар объемный: он задевает тех, кто немного выше и ниже на плоскости. Из-за этого можно стоять чуть ниже босса и не ловить его удары, зато наши суперудары будут проходить по нему. Кроме хорошего геймплея в игре была особенность: борьба с пираством, которую устроил разработчик. В оригинальном картридже была специальная перемычка между двумя пинами. Игра проверяла, что между ними проходит электричество, и если нет, значит, картридж пиратский. Самое интересное: проверка случалась не в начале игры, а на середине во время битвы со Шреддером за Эйприл. И нет бы написать: дружище, у тебя пиратский картридж, купи лицензию. Нет – Шреддер становился неуязвимым! Я доходил до него дюжину раз без смертей, лупил по полчаса – и все без толку. Настоящее издевательство над ребенком! Так что пройти игру в детстве не удалось. Но лет пять назад я включил эмулятор на Маке, достал с полки геймпад. Качнул ROM, завел черепах – и прошел с первой попытки! Оказалось, я помню порядок уровней, как валить врагов и где они появляются, где лежит пицца для восстановления здоровья и многое другое. Спас Эйприл, победил Шреддера и наконец-то увидел все то, что не удалось тридцать лет назад.

Если вы работали с JDBC (интерфейс к базам данных в Джаве), то наверняка видели свойство autoCommit. Точное его описание – камень в ботинке: вроде маленький, но вымотает всю душу. Поведение его следующее. Когда autoCommit — истина, запросы выполняются без явных транзакций. Например, вызываешь UPDATE, и он тут же вступает в силу. Если нужна транзакция, явно прописываешь begin и commit. Когда autoCommit ложь, то все интересней. Если в текущий момент транзакции нет, то любой запрос откроет ее. Далее все запросы будут выполняться в транзакции, пока мы не вызовем commit. Спрашивается, какое значение у autoCommit по умолчанию? Ответ — ложь. Тысяча людей погорели на том, что вызывают UPDATE, смотрят в базу – а там фига с маслом. Оказывается, autoCommit был ложь, и перед вызовом UPDATE сработал неявный BEGIN. В конце мы не вызвали commit, транзакция не закрылась, изменения откатились. Многие джависты думают, что autoCommit – часть базы данных. И очень удивляются, узнав, что это не так. База данных ничего не знает ни о каком autoCommit. Этого свойства нет в протоколе Postgres, нет его и протоколах других баз. Во всех случаях он имитируется логическом флагом и бородой if-else. Причем если вы думаете, что все просто, то ошибаетесь: на уровне драйвера проверка на autoCommit случается часто. Скажем, при входе в транзакцию нужно запоминать его прошлое значение, восстанавливать. При смене autoCommit надо проверять, находимся ли мы в транзакции и если да, завершать ее. И все это – ради чего? Я согласен, что возможно, какая-то бородатая база вроде IBM DB2 на мейнфреймах поддерживала autoCommit на уровне протокола. Но сегодня это атавизм вроде лишнего позвонка, который когда-то был хвостом. В современных драйверах autoCommit имитируется программно, при этом нет способа избежать его вообще. К тысяче людей, погоревших на autoCommit, присоединился и я. При этом дело было не на Джаве, а Питоне с библиотекой psycopg2. Все по классике: скрипт подключается к базе, делает UPDATE. В базе изменений нет. Оказалось, в psycopg2 принят autoCommit, слизанный с JDBC, и по умолчанию он выключен. Слушайте, хватит уже! Перестаньте тянуть в библиотеки это старье. Опирайтесь на естественное поведение базы: либо каждый запрос выполняется в неявной транзакции, либо их несколько заключаются в транзакцию. В современных библиотеках к базам данных никаких autoCommit нет, и слава богу. AutoCommit – это древнейший атавизм из пещерных времен. И в отличие от лишнего позвонка, он колоссально мешает жить.

Посмотрел PR коллеги хочу спросить его, сам ли он писал или сгенерил. Как вы думаете, он обидится? Вы бы обиделись, если бы первый вопрос был бы такой?

Говорят – такая архитектура, сякая архитектура. Масштабируется, учитывает то, другое. Но мне кажется, чаще всего у архитектуры одно оправдание – любопытство разработчика. Все мы люди, и хочется попробовать новенького. Интернет и блоги только разогревают интерес. Кажется, что другие строят идеальные архитектуры, а ты — неудачник. Поэтому делается CQRS на очередях с Монгой и микросервисами в Кубернетисе. Рисуются диаграммы с адским числом стрелочек. Начальство ничего не понимает, но вроде бы выглядит солидно. Хорошо, делайте. Время и сложность расшатывают архитектуры. В начальный момент схема статична, и кажется, что все идет по плану. Но, судя по всему, нарастающая сложность – это базовый закон мира: она прибывает и расшатывает все подряд. Читали книгу "Цель"? Там на примере игры со спичками показано, как ошибка в одном узле завода сказывается на всем производстве. Базовый принцип! Вот и здесь что-то подобное: сложность нарастает и все расшатывает. Выясняется, что гениальная архитектура не любит, когда ее шатают: она не учитывает то, другое, третье. Переделывать поздно, потому что выяснится, что Акелла промахнулся, а это чревато вопросами. Архитектуру подпирают костылями, делая вид, что это минорчики, и беспокоиться не о чем. Половина всех моих действий уходит на то, чтобы преодолеть проблемы "удачных" архитектур. Все они были кем-то составлены, представлены, защищены перед руководством. И вот я иду в базу не прямым путем, а через три микросервиса; пишу экраны кода, когда при ином подходе понадобилась бы строчка. Поддержка таких архитектур – это расплата за неудачное решение, за праздное любопыство. Своего рода дань, которую взимает сложность. Архитектура должна быть простой – это ее ключевое свойство. Архитектура должна умещаться в голове целиком, не вымещая других вещей. Простые вещи легко наращивать: даже если вы начали с монолита и одной базы, позже из них легко получить несколько сервисов и баз, а между ними очередь. Если вы начали с дюжины сервисов, баз и очередей, этот зоопарк вам не вывезти. Сложность не должна опережать удобство. Как у Кнута: предварительное усложнение душит систему. Архитектуры могут казаться сложными, но иной раз за ними стоит банальное любопытство: желание экспериментировать или строить что-то свое. Иной раз поражаешься: боже, это следы доклада с Ютуба, который был популярен десять лет назад! Вот откуда дровишки! Решайте задачи максимально простым способом, и вопрос архитектуры решится сам собой.

На этом месте говорят: если база упадет, перестанут работать все сервисы. Решение – делать так, чтобы не упала! Проверяйте запросы перед вводом в эксплуатацию, смотрите планы, гоняйте на тестовых данных. Мониторьте базу, наказывайте тех, кто шлет кривые запросы. Введите общие стандарты, примеры, документацию, чтобы было куда направлять людей. Сюда же относятся резервные копии и горячее переключение, но Управление данными на уровне базы намного проще, чем в коде. База данных – это данные плюс метод доступа к ним. Удивляюсь, столь прозрачная схема до сих пор кому-то не понятна.

Когда говорят "микросервисы", мне хочется смеятся. Когда говорят, что у каждого микросервиса должна база данных, я хочу плакать. База данных сильна лишь когда хранит все данные. Целое больше суммы частей. Когда у вас пятнадцать сервисов и пятнадцать баз, их нельзя назвать базами – это ошметки. Сторонники множественных баз не понимают, что с ними невозможно наладить отчетность. А отчетность – это то, что движет бизнес вперед. Фонарь, освещающий путь в темноту. Неважно, насколько красивый у вас лендинг или сколько библиотек в js-бандле. Важно, сколько фирма продает, и как быстро, и что именно, и когда. На все эти вопросы отвечает отчетность. Момент, когда начальство ее требует, является лишь вопросом времени. Спрашивается: имея пятнадцать баз, разбитых по сервисам, как вы сделаете отчетность? Взять хотя бы такую мелочь как отчет продаж: сколько продали за последний год и кому. Это join трех-четырех таблиц. Если они раскиданы по базам, как вы его соберете? Технически можно вызвать сервис пользователей 100 раз, выгребая по 1000 записей. Потом дернуть 1000 раз сервис продаж, потом 200 раз сервис категорий и так далее. Нагрузить сеть и положить инфраструктуру ди-досом. Соединять сущности в приложении по словарям, умирая от нехватки памяти. А можно иметь одну базу и запрос, который сделает то же самое за секунду. Без консолидированной базы отчетность невозможна. Если у вас 15 баз, понадобится 15 репликаций, которые будут сливать в нее данные. А это – 15 процессов, которые нужно мониторить. Вдруг одна репликация отвалилась? Как вы об этом узнаете? В Постгресе и других базах есть схемы – аналог пространств имен в языках программирования. Две сущности в одним именем, но разных схемах не пересекаются. Таблица users в схеме accounts хранит пользователей системы (покупателей), а в схеме backoffice – членов персонала. Естественно держать сервисы в одной базе, но разных схемах. У каждого сервиса машинное имя и соответствующая схема, например accounts, sales, backoffice, management, analytics и другие. В них – таблицы, вьюхи и другие сущности. Когда мы пишем select * from users, база должна понять, какой схеме принадлежит users. Для этого используется глобальный параметр search_path – список схем, в которых ищутся сущности без явно указанной схемы. По умолчанию он равен "$user", public. Схема "$user" – особая по двум причинам. Во-первых, в ее названии есть доллар, из-за чего ее берут в двойные кавычки. Во-вторых, $user означает имя текущего пользователя, например ivan. Это значит, что сначала Postgres проверит, есть ли таблица ivan.users, затем public.users, а если ничего не найдено – кинет ошибку. Схемы дают контроль над доступом. Писать в схему может лишь сервис-владелец, например пользователь accounts пишет в accounts.user, но не в sales.products. Данные из других схем выборочно дают на чтение. Скажем, сервису accounts нужны категории товаров. В этом случае дается GRANT SELECT на таблицу sales.categories для пользователя accounts. Эту таблицу можно прочитать или приджойнить в запросе. Удобно, когда каждый сервис подключается под своим пользователем. Если это сервис accounts, база будет искать таблицу users в accounts и в public. Таблицы, которые принадлежат текущему сервису, можно писать без схемы, а для таблиц-соседей указывать их. Например в запросе ниже видно, что users – это accounts.users (подключение под пользователем accounts), а профили приходят из схемы profiles, к которой нам дали доступ на чтение. select * from users u join profiles.profiles p on u.id = p.user_id Такое решение сводит на нет ситуацию, когда вместо прямого запроса мы идем в обход: вызываем сервис и получаем результат, а затем соединяем данные в приложении. Последнее – долго, хрупко и не масштабируется.

Когда я делаю интерфейс (что случается редко, но все же), то не использую иконки. Вообще, абсолютно. Если кнопка добавляет сущность, пишу "Добавить". Если удаляет – пишу "Удалить". То же самое для редактирования, пересылки, отправки на почту, загрузки и так далее. Почему? Да потому что надоело. Иконки и пиктограммы – это игра, в которой не выиграть. Родной язык мы учим с первых месяцев жизни, а многие иконки увидели будучи взрослыми. Что проще понять: надпись "переслать" или изогнутую стрелку? Согласен, что некоторые иконки запоминаются хорошо: плюсик на добавление или мусорный бак для удаления. А дальше? Что означают часики: ввод времени или отложенное сообщение? Что означает круговая стрелка: перезагрузку? Всей страницы или виджета? Набираю текст в Гугл-доке и смотрю на тулбар. В нем человечек с облачком изо рта, часики и облачко с текстом, но уже без человечка. Понять, что это, не наведя мышь, невозможно. Да, слово "Удалить" занимает больше места, чем мусорный бак. Но ни разу не было такого, чтобы приходил пользователь и говорил: друг, замени на иконку, места не хватает. Тысячу раз было обратное: вижу иконку и не понимаю, что она делает. Подвожу мышь и читаю подсказку. Особенно забавляют ребята, которые делают два в одном: иконка и надпись. Например, сначала мусорный бачок, а потом Delete. Зачем одно, если есть другое? Ты бы еще шрифтом Брайля подписал или рунами инков! Нет смысла писать, что иконка никогда не выровнена под текст. Все эти баундинг-боксы высчитываются неправильно и не учитывают смысла содержимого. Если на кнопке только иконка, то прощай поиск по странице. Раньше в некоторых программах был выбор: использовать иконки или надписи. Из того, что запомнилось – это, внезапно, Gmail и приложения Мака вроде Preview. Скриншотов под рукой нет, но я пользовался этой опцией и клянусь, что так и было. Разумеется, с обновлениями фичу похоронили. Общий принцип таков: иконка хороша, если обозначает то, что на ней изображено. Скажем, если это графический редактор, то вместо надписей "круг" и "прямоугольник" лучше сделать кнопки с этими фигурами. Однако действия вроде импорта, экспорта, сохранения, пересылки и так далее нужно подписывать. То же самое относится к дорожным знакам. В России 8 групп дорожных знаков, а всего их около 300. Сомневаюсь, что типичный водитель распознает хотя бы треть из них. Почему бы не делать знаки текстом? Остановка запрещена. Парковка только в праздничные дни. Проезд закрыт. Напомню, что мы не читаем слова, а распознаем их. Отдельные слова — это и есть знаки. Сделайте по три ошибки в каждом слове, и вы без труда его прочтете. Текст – это просто и дешево. Не бойтесь текста!

Пожалуй, стоит дополнить последний пост. Смотрите: нет никаких проблем в том, чтобы показать на экране много элемнтов. Вообще никаких. Их может быть пять, пятнадцать или двадцать пять. Вопрос в том, насколько элементы однородны. Если однообразие выполняется, вы легко уместите множество элементов, и они не будут конфликтовать. В прошлом примере элементы неоднородны. Казалось бы, есть заголовок, но вокруг него, словно мухи, роятся второстепенные элементы: аватар, имя автора, дата, уровень сложности, время на прочтение, тип публикации, подтип, число плюсов, закладок, комментариев. Вдобавок они разного цвета и с иконками. Понятно, что если сжать все это, элементам будет тесно. Посмотрите, как выглядят новости Хабра в RSS-клиенте. Оставлены только заголовки и минимальные данные вроде даты и кнопки "в закладки". Остальное появляется либо по ховеру, либо клику. Видим, что двадцать с лишним заголовков прекрасно уместились. Если присмотреться, станет ясно, в чем разница между версткой Хабра и RSS. Если RSS — это честная таблица, то Хабр — набор карточек. В свою очередь карточка — это контейнер или скорее клетка; в ней, как в жидкости, плавают органеллы — элементы. Заголовок, теги, лайки, превьюшка и так далее. Для себя я заметил, что никогда не выбираю карточный режим просмотра. Либо полный (заголовок, картинка, текст), либо только заголовок. На мой взгляд, карточка — очень странная форма дизайна. Как правило, она плохо подчиняется какой-то логике: в ней все намешано, она излишне велика и ее пучит изнутри. Пожалуй, единственный оправданный случай карточки, который я могу припомнить — это если она отталкивается от картинки. Например, серия карточек с видео — в данном случае превьюшка несет пользу. И наоборот: забавно, когда сайт показывает карточки с превьюшками, а там — заглушка с заголовком статьи. Поэтому я стараюсь не использовать карточки. И расстраиваюсь, когда вижу их там, где они не кстати.

Меня просто убивает современный слоеный дизайн. Каждый раз, когда нужно добавить надпись, иконку, кнопку, дизайнер такой — хоп, добавляет слой и пихает туда элемент. И вот дизайнеры Миша, Коля, Вася надобавляли каждый своих слоев. Это мой, я сюда свои кнопки ставлю, а ты не лезь. Заведи свой и ставь туда свои. На картинке ниже — главная Хабра на ноуте 14 дюймов. Масштаб 100%, я ничего не уменьшал. Видим, что на экране помещается три с половиной новости. Три с половиной! Это при том, что кроме заголовка нет вообще никакого текста, даже тизера. Единственное, что мне нужно — это заголовок, чтобы прочитать и нажать на него. Итого четыре заголовка на весь экран. Посмотрите, как неэффективно занято место. Правая часть плашек пустует. В каждом слое буквально два-три элемента. Метки "Статья" и "Ретроспектива" сидят в отдельных слоях! На каждое слово — сантиметровый слой! После перестановки элементов экран вмещает в два с лишним раза больше информации. При этом я не старался, а просто двигал картинки. Вдогонку: темная тема плохо сочетается с цветами. Если вы делаете темную тему, то фактически она должна стать черно-белой. Синий, зеленый и другие цвета, которые хорошо смотрятся на белом, должны стать градациями серого. Акценты выделять фоном, обводкой, болдом. Словом, все как всегда. Хабр, который зарос рекламой по самые уши и гребет деньги лопатой, не может нанять толковых дизайнеров. Под "толковыми" я имею в виду тех, у которых на экран влезает не четыре заголовка, а хотя бы десять. Но увы.