{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Блог Ильи Бирмана: заметки с тегом классификация",
    "_rss_description": "Блог Ильи Бирмана о дизайне, городах, музыке и жизни.",
    "_rss_language": "ru",
    "_itunes_email": "ilyabirman@ilyabirman.ru",
    "_itunes_categories_xml": "<itunes:category text=\"Arts\"><itunes:category text=\"Design\" \/><\/itunes:category>\r\n<itunes:category text=\"Society &amp; Culture\"><itunes:category text=\"Personal Journals\" \/><\/itunes:category>\r\n<itunes:category text=\"Technology\" \/>\r\n",
    "_itunes_image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic-square@2x.jpg?1573933764",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/klassifikatsiya\/",
    "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/klassifikatsiya\/json\/",
    "icon": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764",
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
            "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
        }
    ],
    "items": [
        {
            "id": "6103",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/klassifikaciya-v-golove-dizaynera\/",
            "title": "Классификация в голове дизайнера",
            "content_html": "<p>Вот вам пример улучшения из Ай-ОСа 17. Кадр <a href=\"https:\/\/www.youtube.com\/watch?v=zmgdiyLqfQM\">из видоса Брендона Бутча<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/ios-16-17-automation.jpg\" width=\"1166\" height=\"674\" alt=\"\" \/>\n<\/div>\n<p>Когда создаёшь автоматизацию, раньше спрашивало, хочешь ли ты «персональную» или «домашнюю». Я дальше этого экрана никогда не проходил, потому что хрен знает, что это значит. Эплы по одним им известному принципу разделили триггеры на две категории.<\/p>\n<p>В новой версии экран выбора убрали, сразу показывают весь список триггеров. Вместо абстракций сразу видишь конкретные события: время, прибытие куда-то, подключение Карплея, получение сообщения и так далее.<\/p>\n<p>Эта картинка отправляется в папку «Навигация» <a href=\"http:\/\/bureau.ru\/courses\/ui-online\/\">моего курса<\/a>. Каждый раз, когда что-то классифицируете или делите на категории, задайте себе вопрос: а у пользователя в голове откуда эта классификация возьмётся? Она общепринятая или это только вы придумали?<\/p>\n<p>Вот пример из эпловского же доклада как раз на эту тему:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/apple-hierarchy-1.jpg\" width=\"1280\" height=\"960\" alt=\"\" \/>\n<\/div>\n<p>Пусть надо выбрать вид транспорта. Деление на первом шаге на воздушный и наземный — понятное. А вот с топливом — засада. Если я хочу поезд, очевидно ли мне, в какой из категорий искать? Не факт, так что такое деление лучше убрать.<\/p>\n",
            "summary": "Вот вам пример улучшения из Ай-ОСа 17. Кадр из видоса Брендона Бутча...",
            "date_published": "2023-09-27T10:30:02+02:00",
            "date_modified": "2023-09-27T10:29:37+02:00",
            "tags": [
                "Айфон",
                "классификация",
                "навигация",
                "пользовательский интерфейс",
                "Эпл"
            ],
            "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/ios-16-17-automation.jpg",
            "_date_published_rfc2822": "Wed, 27 Sep 2023 10:30:02 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "6103",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/ios-16-17-automation.jpg",
                    "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/apple-hierarchy-1.jpg"
                ]
            }
        },
        {
            "id": "3828",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/oglavleniya-po-tegam\/",
            "title": "Оглавления по тегам",
            "content_html": "<p>Начал наводить порядок в тегах, делаю там некие оглавления со ссылками на важные заметки по теме. Пока прошерстил теги:<\/p>\n<ul>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/design\/\">дизайн<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/ui\/\">пользовательский интерфейс<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/economy\/\">экономика<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/logic\/\">логика<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/negotiations\/\">переговоры<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/books\/\">книги<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/talks\/\">доклады<\/a>,<\/li>\n  <li><a href=\"http:\/\/ilyabirman.ru\/meanwhile\/tags\/podcast\/\">подкаст<\/a>.<\/li>\n<\/ul>\n<p>В самих заметках по этим тегам появились сверху ссылки на эти оглавления. Пока коряво и не очень последовательно, но это 5% усилий для получения 95% пользы.<\/p>\n<p>Вообще, формат блога требует серьёзного переосмысления. Таймлайн как основное средство организации материалов почти бесполезен.<\/p>\n",
            "summary": "Начал наводить порядок в тегах, делаю там некие оглавления со ссылками на важные заметки по теме. Пока прошерстил теги",
            "date_published": "2015-02-03T13:40:50+02:00",
            "date_modified": "2015-02-03T13:40:35+02:00",
            "tags": [
                "блоги",
                "классификация",
                "этот сайт"
            ],
            "_date_published_rfc2822": "Tue, 03 Feb 2015 13:40:50 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "3828",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "3027",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/als-website-navigation\/",
            "title": "Навигация на сайте Студии Лебедева",
            "content_html": "<p>Изучал устройство необъятного портфолио Студии Лебедева и обнаружил любопытную вещь. Вот, например, недавняя работа — <a href=\"http:\/\/www.artlebedev.ru\/everything\/als\/gift-bag\/\">пакет для кафе<\/a>. Где в структуре сайта лежит эта страница? Смотрим на верхнее меню:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/als-navigation-1.png\" width=\"216\" height=\"105\" alt=\"\" \/>\n<\/div>\n<p>В разделе «Наше всё» есть подраздел «Графдизайн», в нём — «Проекты студии», и уже внутри него лежит наш пакет. Так?<\/p>\n<p>Нет, не так. Посмотрим, куда ведут ссылки в меню, и на адрес страницы пакетов:<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n  <tr>\n    <td style=\"text-align: left\">Наше всё<\/td>\n    <td style=\"text-align: left\">\/everything\/<\/td>\n  <\/tr>\n  <tr>\n    <td style=\"text-align: left\">Графдизайн<\/td>\n    <td style=\"text-align: left\">\/everything\/graphic\/<\/td>\n  <\/tr>\n  <tr>\n    <td style=\"text-align: left\">Проекты студии<\/td>\n    <td style=\"text-align: left\">\/everything\/als\/<\/td>\n  <\/tr>\n  <tr>\n    <td style=\"text-align: left\">Пакеты для кафе<\/td>\n    <td style=\"text-align: left\">\/everything\/als\/gift-bag\/<\/td>\n  <\/tr>\n<\/table>\n<p>Как видим, никакого «Графдизайна» в урле страницы пакетов и в помине нет, и в раздел «Графдизайн» она попадает благодаря какому-то волшебству. Ну просто захотелось, чтобы была такая ссылка в меню, вот она там и есть.<\/p>\n<p>Берём приём на вооружение.<\/p>\n",
            "summary": "Изучал устройство необъятного портфолио Студии Лебедева и обнаружил любопытную вещь. Вот, например, недавняя работа — пакет для кафе",
            "date_published": "2012-08-02T17:30:46+02:00",
            "date_modified": "2015-02-03T09:34:30+02:00",
            "tags": [
                "веб-дизайн",
                "дизайн сайтов",
                "классификация",
                "Лебедев",
                "пользовательский интерфейс"
            ],
            "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/als-navigation-1.png",
            "_date_published_rfc2822": "Thu, 02 Aug 2012 17:30:46 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "3027",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/als-navigation-1.png"
                ]
            }
        },
        {
            "id": "2834",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/inbox-everywhere\/",
            "title": "Инбокс везде",
            "content_html": "<p>Очень много приложений, в которых нужно как-то <a href=\"http:\/\/zachholman.com\/posts\/shit-work\/\">организовывать объекты<\/a>, чтобы не заблудиться: письма в почте, заметки в Эверноуте, песни в Айтюнсе, тудушки в тудулисте, закладки в браузере.<\/p>\n<p>Во всех этих местах я использую <i>инбокс<\/i>. Смысл его в том, что это место, куда объекты попадают изначально, до «обработки». В почте это так устроено само собой, и это очень удобно — представьте себе, если бы при получении каждого письма почтовик бы просил вас выбрать папку, в которую его нужно положить. В других приложениях инбокс нужно создать самостоятельно.<\/p>\n<p>В Айтюнсе, например, у меня есть такой плейлист, и любые новые песни я добавляю туда. Если у них не прописаны теги или они прописаны неправильно, я их не потеряю. Кроме того, я никогда не забуду, что нужно послушать новый альбом, который я только что скачал. Когда теги прописаны, обложки добавлены и песня рассована по другим <a href=\"http:\/\/ilyabirman.ru\/meanwhile\/2009\/11\/07\/1\/\">плейлистам-тегам<\/a>, из инбокса её можно убить.<\/p>\n<p>В Эверноуте у меня есть блокнот-инбокс, и в него попадают все новые заметки. Когда заметка написана, её можно перенести в другой блокнот, добавить ей теги по вкусу или удалить, если она была совсем временная. Ясно, что как и в почте, инбокс далеко не всегда пуст, и некоторые вещи подолгу остаются в нём висеть, но за счёт того, что они перед глазами, я их не теряю.<\/p>\n<p>Сегодня, разбирая залежи букмарок в браузере, я догадался, что там тоже нужно сделать инбокс, чтобы все новые закладки добавлять именно в него:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/bookmarks-inbox.jpg\" width=\"196\" height=\"299\" alt=\"Инбокс везде\" \/>\n<\/div>\n<p>Короче, видите, то есть это не просто я так делаю, а это аж целая моя <i>методология<\/i>, и поэтому этому посвящается аж целая заметка.<\/p>\n",
            "summary": "Очень много приложений, в которых нужно как-то организовывать объекты, чтобы не заблудиться: письма в почте, заметки в Эверноуте, песни в Айтюнсе, тудушки в тудулисте",
            "date_published": "2011-11-07T19:04:39+02:00",
            "date_modified": "2015-06-25T14:25:36+02:00",
            "tags": [
                "Айтюнс",
                "жизнь",
                "классификация",
                "рабочее место",
                "решения",
                "софт"
            ],
            "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/bookmarks-inbox.jpg",
            "_date_published_rfc2822": "Mon, 07 Nov 2011 19:04:39 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "2834",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/bookmarks-inbox.jpg"
                ]
            }
        },
        {
            "id": "2520",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/2009\/11\/07\/1\/",
            "title": "Плейлисты в Айтюнсе",
            "content_html": "<p>Я всегда <a href=\"http:\/\/ilyabirman.ru\/meanwhile\/2006\/10\/21\/1\/\">говорил<\/a> о том, что плейлисты — это хрень собачья и чушь, и бред. Я не мог понять, как людям пришло в голову сделать такую функцию. Составлять плейлист, заранее предугадав, что тебе захочется слушать через полчаса — зачем это, когда можно взять да и включить через полчаса то, что нужно?<\/p>\n<p>Музыка у меня всегда лежала в папках Исполнитель — Альбом (Год) в одном бесконечном списке, безо всякого разделения по жанрам или ещё какой-нибудь фигне, и ещё была папка (In), куда скидывалось всё новое, чтобы не забыть про него за то время, пока ещё не выучил.<\/p>\n<p>Когда я перешёл на Мак, как раз вышел восьмой Айтюнс, позволяющий организовать библиотеку так, как я привык, то есть по альбомам, дополняя это приятной красотой в виде обложек. Меня это очень порадовало. Дело в том, что меня, как любого пользователя (тогда) Виндоуса, совершенно бесил Айтюнс, а одним из главных поводов для переживаний в связи с переходом на Мак было именно практически неизбежное использование Айтюнса. Поэтому мне было приятно, что новый Айтюнс может показывать мне музыку так или примерно так, как я привык её видеть. Жизнь показала, однако, что этим режимом с альбомами-обложками я почти не пользуюсь.<\/p>\n<p>Оказалось, что самое главное средство организации музыки в Айтюнсе — это плейлисты (в сто раз полезнее <a href=\"http:\/\/ilyabirman.ru\/meanwhile\/2009\/07\/24\/1\/\">рейтингов<\/a>). Плейлист в Айтюнсе не имеет никакого отношения к тому, что сохраняют виндовые плейеры в файл с расширением m3u. Плейлист — это по сути просто папка, куда можно накидать песен. Да, он помнит, в каком порядке ты их накидал, но это совершенно не важно в большинстве случаев: песни в плейлисте можно отсортировать как угодно, организовать по исполнителям или жанрам.<\/p>\n<p>То есть плейлист — это способ взять какое-то подмножество музыки и поименовать его. Это «надо будет поиграть в „Гараже“», это «записал мне Петя», а это «возможно подойдёт для следующего выпуска подкаста». Никто не имеет в виду, что ты будешь слушать плейлист по порядку или целиком.<\/p>\n<p>Поскольку трек может входить в несколько плейлистов, то их можно использовать ещё и как теги: грустный медленный трек с женским вокалом можно закинуть в плейлисты «грустное», «медленное», «женский вокал». Треков-то тысяч десять, так что если забыл назвние чего-то (что со мной бывает крайне редко, но всё же), фиг найдёшь. Так что я стараюсь добавить трек  в максимально возможное количество плейлистов, чтобы потом я мог найти его по любым признакам. Допустим, плейлисты всех мои <a href=\"http:\/\/ilyabirman.ru\/live\/\">миксов<\/a> у меня есть в Айтюнсе, а значит я могу найти трек, помня, что я его, скажем, играл на «Эль-радио».<\/p>\n<p>Есть плейлист Shazam — там лежат все треки, которые я нашёл после распознавания «Шазамом». Есть плейлист Dad’s Shelf — там лежат все пластинки «с папиной полки», то есть то, что я сграбил с его дисков (в основном джаз). Есть плейлист Find better — там лежат треки, которые у меня есть в плохом качестве или в обрезанном виде. Есть даже плейлист Nice Covers, где лежат альбомы, у которых крутые обложки (очень удачный плейлист для просмотра в кавер-флоу). Ну, и так далее.<\/p>\n<p>А ещё плейлисты можно сами организовать по папкам (прямо внутри Айтюнса), что добавляет всей конструкции ещё больше гибкости. В папке Podcast лежат плейлисты, связанные с подкастом, папке Tags — плейлисты, которые я использую как теги, а в папке CDs — плейлисты моих нарезанных дисков.<\/p>\n<p>В следующий раз расскажу про одну фичу плейлистов, которая имеет фундаментальную важность.<\/p>\n",
            "summary": "Я всегда говорил о том, что плейлисты — это хрень собачья и чушь, и бред. Я не мог понять, как людям пришло в голову сделать такую функцию",
            "date_published": "2009-11-07T09:31:38+02:00",
            "date_modified": "2011-11-08T11:21:25+02:00",
            "tags": [
                "Айтюнс",
                "классификация",
                "музыка"
            ],
            "_date_published_rfc2822": "Sat, 07 Nov 2009 09:31:38 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "2520",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "965",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/2004\/12\/05\/2\/",
            "title": "Что же делать с кейвордами?",
            "content_html": "<p>Будет очень интересно почитать планирующуюся культовую смирновскую книжку <a href=\"http:\/\/nudnik.ru\/entry\/3096\" class=\"nu\">«<u>Как перестать классифицировать записи и начать писать<\/u>»<\/a>, потому, что без книжки этого понять невозможно. Вот пишет, <a href=\"http:\/\/artreal.exler.ru\/readme\/05.12.2004\/data_link\">например<\/a>, Вадим про нити. Ну как не высказать своё мнение на этот счёт? Обязательно надо высказать. Высказываю.<\/p>\n<ol start=\"1\">\n  <li>Нити и кейворды — это одно и то же;<\/li>\n  <li>Не нужно плодить лишние сущности без надобности.<\/li>\n<\/ol>\n<p>Вот есть у тебя цепочка заметок по поводу одной задачи, типа «поставлена задача» — «возможные пути решения» — «решена вот так», ну и что мешает создать кейворд «задача»? Просто сделай кейворд, зачем его называть словом «нить»? Тут есть два варианта: или Вадим не дописал о каких-то потайных функциях нитей, или он просто не понял, что это то же самое, что и кейворды. Разумеется, я склоняюсь к первому. Точнее, даже, надеюсь на первое; а также на то, что он напишет что-нибудь на эту тему.<\/p>\n<p>Тем не менее, хоть функционально кейворды и нити — это одно и то же, семантически это всё-таки разные вещи, поэтому нужно придумать и функциональность какую-нибудь, которая была бы связана как-то с этой разницей. Например:<\/p>\n<ul>\n  <li>в любой заметке, участвующей в нити, должна быть ссылка на предыдущую и следующую заметки именно этой нити;<\/li>\n  <li>когда мы открываем страницу кейворда-нити, то заметки должны выводиться в режиме «новые снизу», чтобы за темой можно было нормально следить.<\/li>\n<\/ul>\n<p>По этому поводу у меня уже давно есть, например, мысль ввести синтаксис prevkey и nextkey для вставки ссылок на предыдущую и следующую заметки, содержащие хотя бы один из кейвордов данной. Возможность отображать «новые снизу» реализовать вообще не трудно. Можно даже просто сделать, чтобы по \/keywords\/path\/to\/key выдавались новые сверху, а по \/threads\/path\/to\/key — снизу.<\/p>\n<p>В конце концов, ничего не мешает сделать в таблице Keywords столбец IsThread, чтобы формально отделить кейворды от нитей. Но я лично в этом не вижу смысла.<\/p>\n<p>Что ещё? А, вот что. Кейворды, в отличие от нитей, не теряют актуальности. То есть, задачу ты поставил и решил, а про идиотов, например, можно писать всегда — тема неисчерпаема. Благодаря Юлии Шабунио в e2 можно сортировать кейворды по дате последнего использования. В этом случае, неактуальные нити постепенно будут сдвигаться вниз.<\/p>\n<p>В e2 Release 1.02 <i>предположительно<\/i> будет очень крутая штука, которая позволит ориентироваться в бесконечных кейвордах и нитях, а также отличать те кейворды, которые по сути кейворды от тех, которые по сути — нити. Причём, без IsThread.<\/p>\n<p>Теперь немного о том, какая же всё-таки структура кейвордов является самой правильной? Линейная, древовидная или в стиле R2?<\/p>\n<p>Проблема линейной структуры том, что кейворды (сюрприз!) никак не связаны друг с другом. Получается, что «программирование» и «PHP» настолько же самостоятельные темы, насколько «снукер» и «toki pona». Но это не так, программирование и PHP — близкие темы. И это хочется как-то обозначить в структуре, потому, что нужно как-то связать соответствующие заметки друг с другом. Программирование — это более общая тема, чем PHP, Delphi и mySQL. Исходя из этой посылки возникают древовидные кейворды.<\/p>\n<p>Однако, у древовидных кейвордов тоже полно проблем: в половине случаев непонятно, какая тема является общей для двух других. Мой случай, например: я не знаю, «комментатор Саша» должен быть субкейвордом «снукера» или «идиотов»? По идее, и того и другого. В результате этих рассуждений возникают кейворды в стиле R2 (aka «паутинообразные»)<\/p>\n<p>Но и тут не всё гладко. Новая проблема состоит в том, что нам обязательно нужно определиться с тем, какой из двух связываемых кейвордов является более общим. А это не всегда легко\/возможно. То, что «fight club» по отношению к «кино» кейворд дочерний — сомнений не вызывает; но вот я, например, не знаю, как бы я связал «Лебедева» и «дизайн». Однако, связать бы их хотел.<\/p>\n<p>Поэтому теперь я думаю, что самая правильная система — это <i>ассоциативная<\/i> система кейвордов. Всё как у Смирнова, только вместо связей «содержит в себе» и «входит в» мы делаем просто «связан с». Ага?<\/p>\n<p>Дальше, на странице любого кейворда мы пишем «См. также» и перечисляем ссылки на связанные кейворды. По-моему, вот так и надо делать.<\/p>\n<p>Разумеется, кейворды «PHP 5» и «программирование» связаны сильнее, чем «PHP5» и «web-строительство». Поэтому, по кейворду «PHP 5» хотелось бы видеть:<\/p>\n<blockquote>\n<p>Cм. также: PHP, программирование, web-строительство<\/p>\n<\/blockquote>\n<p>То есть, именно в таком порядке, а не, скажем, по алфавиту. Для этого можно ввести необязательный параметр «сила связи» и дать возможность задавать его при связывании.<\/p>\n<p>Вот такие мысли.<\/p>\n",
            "summary": "Будет очень интересно почитать планирующуюся культовую смирновскую книжку «Как перестать классифицировать записи и начать писать», потому, что без книжки этого понять невозможно",
            "date_published": "2004-12-05T16:41:33+02:00",
            "date_modified": "2022-01-24T13:52:30+02:00",
            "tags": [
                "классификация"
            ],
            "_date_published_rfc2822": "Sun, 05 Dec 2004 16:41:33 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "965",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "955",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/2004\/12\/02\/1\/",
            "title": "One step further — 2",
            "content_html": "<p>В своём желании подколоть Смирнова я оказался прав отнюдь не <a href=\"http:\/\/nudnik.ru\/entry\/3095\">случайно<\/a>. Я прекрасно понимаю, что вся эта фигня про N-местные отношения будет работать, и в каких случаях она удобна. Хотя, замечу, сам Смирнов всё-таки говорит про бинарные. Я придумал CMS на базе этого ещё год назад, просто не реализовывал, потому, что у меня нет задач, где бы это могло понадобиться.<\/p>\n<p>Но, во-первых, я всё-таки говорил про кейворды, а не про записи, а это разные вещи. Подкол заключался в том, что усложнение системы <i>кейвордов<\/i> вряд ли полезно. Связывать друг с другом записи — это очень хорошо, но тут другая проблема. В блоге это вряд ли будет работать, потому, что блог хочется писать, а не связи в нём настраивать. Кейворды, они тем и полезны, что позволяют мало напрягаться. А представим, что нам вместо кейвордов нужно вручную перечислять все заметки, которые мы считаем близкими по теме к данной. Ну и что, кто бы этим пользовался? Ноль человек.<\/p>\n<p>А во-вторых, я пошёл ещё дальше, предложив выстроить древовидную систему самих отношений. Смайлик. Поэтому подкол всё-таки удался, не нужно этого отрицать!<\/p>\n<p>См. заметку <a href=\"\/meanwhile\/2004\/12\/01\/2\">One step further<\/a>.<\/p>\n",
            "summary": "В своём желании подколоть Смирнова я оказался прав отнюдь не случайно. Я прекрасно понимаю, что вся эта фигня про N-местные отношения будет работать, и в каких случаях она удобна",
            "date_published": "2004-12-02T09:52:58+02:00",
            "date_modified": "2010-01-23T17:52:07+02:00",
            "tags": [
                "идеи",
                "классификация"
            ],
            "_date_published_rfc2822": "Thu, 02 Dec 2004 09:52:58 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "955",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "952",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/2004\/12\/01\/1\/",
            "title": "One step further",
            "content_html": "<p>Исторический экскурс: как развивались кейворды.<\/p>\n<ul>\n  <li>сначала кейвордов не было (с точки зрения структуры это была точка, один кейворд на всех);<\/li>\n  <li>потом появились линейные кейворды;<\/li>\n  <li>потом появились древовидные кейворды (кейворды могут иметь одного родителя и сколько угодно детей);<\/li>\n  <li>теперь вот новые, паутинообразные кейворды (кейворды могут иметь сколько угодно родителей и сколько угодно детей).<\/li>\n<\/ul>\n<p>На самом деле, <i>если честно<\/i>, то даже переход с линейных на древовидные большого прироста <i>хоть чего-нибудь<\/i> не дал. Новые паутинообразные кейворды вызывают у меня ещё больший скептицизм, хотя, признаюсь, тыкаться в них — одно удовольствие, красиво Смирнов нарисовал.<\/p>\n<p>Для того, чтобы не держать прогресс на месте, я предлагаю новую, ещё более запутанную, но совсем крутую концепцию <i>гиперпаутинообразных<\/i> кейвордов. Деревянность паутинообразных кейвордов заключается в том, что кейворды могут находиться только в отношении «родительский-дочерний» друг с другом. Гиперпаутинообразные кейворды лишены этой проблемы, так как любые два кейворда могут находится в <i>любом<\/i> отношении друг с другом, например, можно указать, что кейворд «торт» <i>слаще<\/i> кейворда «каша». Впрочем, зачем ограничиваться только бинарными отношениями? Лучше вот так: любые N кейвордов могут находиться в любом N-местном отношении друг с другом! Вот теперь — полноценная система.<\/p>\n<p>Хотя... нет, не полноценная. Теперь у нас есть неогранизованная куча новых сущностей — отношений. Их ведь нужно тоже как-то классифицировать. Думаю, для начала можно и по-старинке, древовидно. Например, «субъективные > вкус > слаще» или «объективные > физические > острее». Теперь добавляем возможность к каждому отношению привязать свой аватар — и one step further сделан.<\/p>\n",
            "summary": "Исторический экскурс: как развивались кейворды",
            "date_published": "2004-12-01T10:42:47+02:00",
            "date_modified": "2011-02-19T01:35:56+02:00",
            "tags": [
                "классификация",
                "странный юмор"
            ],
            "_date_published_rfc2822": "Wed, 01 Dec 2004 10:42:47 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "952",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "596",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/2004\/04\/10\/1\/",
            "title": "Помогите разобраться",
            "content_html": "<p>Если у вас нет блога, — представьте обратное. А то у меня тут есть несколько вопросов:<\/p>\n<ol start=\"1\">\n  <li><b>Нужна ли блогу древовидная система кейвордов?<\/b><\/li>\n<\/ol>\n<p>Аргумент «за»: когда по некоторому кейворду (например, «идиоты») накапливается очень много заметок, то поиск по нему перестаёт быть хоть сколько-нибудь эффективным — нужно разделить «идиотов» на подкатегории «комментатор Саша», «Ээльмаа», и т. д. Через несколько месяцев плоская система кейвордов <i>абсолютно<\/i> перестаёт работать.<\/p>\n<p>Аргумент «против»: если кейворды становятся самостоятельными объектами, которые нужно создавать, выстраивать отношения между ними и т. д., то блогер просто не будет ими пользоваться — это становится слишком сложно. Если же сделать, что кейворды создаются автоматически при их «упоминании», то тогда, по мнению Смирнова, просто никто не будет утруждать себя созданием дерева, — кейворды, несмотря на возможности движка, так и останутся плоскими.<\/p>\n<p>А вы что думаете?<\/p>\n<ol start=\"2\">\n  <li>Кстати, в моём представлении, каждый кейворд должен быть уникальным, то есть не может быть «программирование\/web» и «дизайн\/web» одновременно. <b>Кто считает иначе и почему?<\/b><\/li>\n<\/ol>\n<p>Я считаю <i>так<\/i>, потому, что если бывает «программирование\/web» и «дизайн\/web», то, значит, web — самостоятельное явление, и, следовательно, он должен быть корневым кейвордом, а заметки должны маркироваться как «программирование; web» и «дизайн; web».<\/p>\n<ol start=\"3\">\n  <li>Допустим, древовидная система кейвордов есть. <b>Как сделать максимально удобным её использование?<\/b>. Что должно быть в форме «написать новую заметку»?<\/li>\n<\/ol>\n<p>Вариант. Рядом со строкой ввода «Keywords» отображается список всех уже существующих кейвордов (по алфавиту? в виде дерева?). Если кликнуть на кейворд, он добавляется в<br \/>\nстроку ввода (в виде «php» или «программирование\/web\/php»?). Можно вручную дописать новые кейворды (если указано в виде «php», то кейворд создаётся в корне, а если в виде<br \/>\n«программирование\/web\/php», то где указано? а если такой кейворд уже есть в другой категории?).<\/p>\n<p>Какие еще мысли по этому поводу у кого возникают — делитесь, интересно.<\/p>\n<p>Кстати, какой (какие?) кейворд должен быть у этой заметки?<\/p>\n",
            "summary": "Если у вас нет блога, — представьте обратное. А то у меня тут есть несколько вопросов...",
            "date_published": "2004-04-10T11:18:19+02:00",
            "date_modified": "2010-01-23T17:55:42+02:00",
            "tags": [
                "вопрос",
                "классификация"
            ],
            "_date_published_rfc2822": "Sat, 10 Apr 2004 11:18:19 +0200",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "596",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4259,
    "_e2_ua_string": "Aegea 12.0a (v4259e)"
}