Поки японці зайняті розущільненнями реакторів, а лівійці — розущільненням Каддафі, продовжимо наші гентушні дослідження.
Ми закінчили на тому, що зібрали потріні пакети вручну. Тепер робимо діффи з усіма нашими змінами, внесеними до пакетів, окремо на кожний пакет. Розпаковуємо пакети знову, щоб мати непропатчений варіант:
( Read more... )Потрапило мені на очі на просторах інтернетів magnet-посилання на торент, і я вирішив перевірити, наскільки з ним дружить мій торент-клієнт. Стоїть він у мене на доманшьому сервері, зібраному з залишків старого десктопа, крутиться під gentoo linux. З’ясувалось, що мій rtorrent сам по собі взагалі не підтримує маґнет-лінків, але є патч, який дає можливість перезібрати його з такою підтримкою. Оскільки під gentoo всі програми і без того повністю збираються з вихідних кодів, я вирішив погратися з цим патчем і включити його в систему portage у себе на сервері, а заразом навчитися писати до неї ebuild’и. Отже:
( Read more... )В наступній серії нашої передачі ви довідаєтесь, як з цього діла зібрати ebuild-файл і включити цей патч до дерева portage.
Почитав у ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
noddeat про «тупих клієнтів», які задовбали нетупих офісних робітників, і згадав, що у мене за кілька днів до того виникала аналогічна думка з приводу іншої історії.
От що я скажу: клієнт правий стовідсотково, до останнього слова. Єдине, його претензія дещо не за адресою — він не знає (та і не зобов’язаний знати) особливостей внутрішньоайтішного розподілу праці. Проблема, насправді, дуже глибока і пов’язана з відсутністю на ринку комплексного продукту для користувача. Є окремі продукти під окремі завдання, а разом подружити їх до потрібної міри, щоб вони складали одну систему, ще не вдалося. (Можливо, щось подібне реалізоване в Маках, не знаю. З Маками я стикався рівно один раз, в Бельгії, і більшість зусиль пішло на війну з бельгійскою розкладкою клавіатури та незвичною плутаниною між запуском програми та переключеннями між програмами. Розібратися я так толком і не розібрався, хоча те, що мені треба було — зробив, а от ставити оцінку макам я не візьмусь). Антивірус не ставиться в комплекті з налаштуванням доступу до Інтернету. Централізована реєстрація на сайтах в зародковому стані. Автоматично поставити аддон до браузера, який би зв’язувався з біллинг-центром провайдера і відображав стан рахунку зараз не можна — провайдери не роблять таких аддонів, справедливо вважаючи, що мороки з цією затією буде більше, ніж толку від неї.
Але це все не проблеми клієнта — це проблеми айтішників. Проблеми, які поки що не можуть бути вирішені через неймовірну складність сучасних комп’ютерних систем, яка не йде ні в яке порівняння зі складністю інших систем, створених людиною. Ну що ж, електроніка теж колись була немислимо складною, а зараз 30000 транзисторів процессора 8086 виглядають просто смішно — люди навчилися добиватися стабільної та ефективної роботи значно більш складних електронних систем. Тому залишається сподіватися, що з ринком програмного забезпечення рано чи пізно відбудеться те саме, і людині не потрібно буде компонувати щось своє з окремих продуктів, а можна буде просто купити пакет софту для домашнього вжитку.
В процесі обговорення єдино вірного способу організації ієрархії каталогів файлової системи сформулював таку думку.
Файл — взагалі зайве поняття. Якщо точніше, то воно зайве для користувача і навіть, найчастіше, для системного адміністратора. Максимум, кому може знадобитися працювати з файлами, це програмісту, і то не факт. Для всіх інших робота з файлами є суррогатом інших потрібних їм операцій.
Тепер трохи детальніше. Теорія підказує нам, що файл — це іменована область дискової пам’яті. Однак, як і в випадку будь-якої комп’ютерної пам’яті, дуже часто трапляється так, що ізольований фрагмент пам’яті сам цінності не має, для роботи з ним потрібно звертатися до інших фрагментів. Скажімо, будь-який документ має нульову цінність без програми, що здатна з ним працювати; поштове повідомлення містить вкладені документи; відеоряд пов’язаний з кількома звуковими доріжками; для відображення мапи потрібно також прочитати піктограми; креслення генплану потрібно підкладати як тло під креслення комунікацій, і т.д. Отже, можемо сказати, що чіткого поділу на ізольовані частини дискової інформації бути не може. Це означає, що спроба розмістити цю інформацію в файлах призводить або до дублювання інформації в багатьох файлах (напр., шаблон документа копіюється в новостворений документ), або до неавтономності файла (напр., виконуваний модуль програми не може сам по собі бути перенесений на іншу систему). Обидва варіанти призводять до того, що при виконанні дискових операцій людині доводиться враховувати деякі неочевидні речі — наприклад, що встановлену програму перенести на іншу машину простим копіюванням навряд чи вийде.
З іншого боку, користувачу і не потрібно зазвичай переносити «файли». Йому треба перенести документ, налаштування, програму. Іменовані фрагменти пам’яті його мало цікавлять. В тому числі, незрозуміло, навіщо користувачу вникати в те, що, скажімо, AutoCAD растрову основу креслення зберігає в окремому файлі, а Photoshop всі шари зберігає в одному. Що довідка може зберігатися у вигляді каталогу з .html-файлами, а може в одному .chm-файлі. Якщо користувач перенесе файл на інший комп’ютер, а той не відкриється через брак другого файла, він буде лаятися на розробників програми і буде, що характерно, правий. Тому що йому не треба переносити файл — йому треба перенести документ.
Для тих, хто трохи орієнтуєтся в програмуванні, приведу просту аналогію для прояснення абсурдності нинішної «файлової» парадигми зберігання інформації. Аналогом дискового файла в оперативній пам’яті є виділений блок цієї пам’яті. Роботу з цими блоками проводить операційна система і низькорівнева система керування пам’яттю програми, т.зв. memory manager. Можна написати програму на мільйон строк і ні разу не заморочитись прямою роботою з цими блоками. Така пряма робота потрібна тільки для дуже специфічних застосувань — антивірусів, програм діагностики апаратного забезпечення, високонавантажених обчислювальних завдань. Більшість програмістів без проблем обходяться без цього.
Крім того, я не знаю жодної програми, яка дозволила б користувачу безпосередньо оперувати блоками пам’яті. Такі операції завжди виконуються опосередковано: користувач повідомляє програму, яку операцію необхідно виконати з даними, і ця операція виконується, але зі специфічною для кожного типу даних обробкою. У випадку дискової ж пам’яті чомусь безпосередня робота користувача з блоками пам’яті вважається нормою.
Насамкінець не можу не відмітити, що деякий поступ в цьому питанні все ж помітний. Скажімо, дуже великим кроком в напрямку від файлів є package manager'и різних дистрибутивів linux та інших unix-систем. З їх допомогою практично відпадає потреба морочитися з файлами програм: установка програми полягає не в копіюванні файлів, а в прямій директиві пакет-менеджеру — «встановити такий-то пакет». Коли аналогічні системи стануть стандартами de facto також в області керування налаштуваннями та документами, можна буде сказати, що більше половини шляху пройдено.
З подачі Фріца Моргена, а також для перепочинку від навчання написав бота для видалення жж-спаму. Від початку бот був зроблений скриптом, що прикручувався до поштового клієнта і реагував на повідомлення про нові коментарі. Власне, цей скрипт у мене зараз і працює. Потім я доробив його до повноцінного бота, який сканує журнал і самостійно шукає спам-коментарі. Ось вони обидва:
Поштовий бот: delcomment.pl
Автономний бот: scancomments.pl
Все ж таки я б рекомендував користуватися поштовою версією бота, вона проста і гарно відлагоджена.
Як користуватися.
Найперше, знадобиться perl.
Поштовий бот:
Налаштовуєте у своєму поштовому клієнті фільтр, котрий всі спам-повідомлення передає на вхід скрипта. УВАГА! Скрипту слід передавати лише спам-коментарі. Всі коментарі, що попадуть до скрипта, будуть видалені, а їх автор забанений. Скрипт викликається наступною командою:
Для Linux:
perl delcomment.pl <логін> <пароль>
Для Windows, скоріше за все, знадобиться вказати повний шлях:
"c:\Program Files\Perl\bin\perl.exe" "c:\Documents and Settings\YYY\delcomment.pl" <логін> <пароль>
(звісно, треба підставити свої шляхи - до установки perl'a та до скрипта).
Автономний бот:
(На всякий випадок ще раз попереджаю: автор не несе ніякої відповідальності за наслідки використання бота і не дає ніяких гарантій щодо його використання. Якщо в результаті неправильних дій бота ви влаштуєте тотальний френдоцид і повидаляєте всі до одного коментарі зі свого журналу, то так вже і буде).
Найперше, в поточному каталозі має знаходитися файл під назвою "patterns.txt", в якому мають знаходитися зразки текстів зі спам-повідомлень - по одному зразку на строку. Зразки задаються регулярними виразами, тому перед символами [].\^$() треба ставити додатково знак "\" (або, щоб не морочитися, просто вибирати фрагменти спам-текстів без пунктуації). Після цього виконайте
Для Linux:
perl scancomments.pl <логін> <пароль>
Для Windows:
"c:\Program Files\Perl\bin\perl.exe" "c:\Documents and Settings\YYY\scancomment.pl" <логін> <пароль>
Ні, все-таки краще перед цим допишіть в 38 строці команду "return;" (без лапок) і запустіть скрипт "вхолосту", щоб побачити, що він надумав видаляти.
Реліз нотес:
delcomment.pl реагує на строку виду
http://www.livejournal.com/delcomment.bml?journal=3Dusername&id=3D######
, де ###### - ідентифікатор коментаря, який потрібно видалити. Зверніть увагу: строка закодована (замість "=" стоїть "=3D"), тож, якщо захочете запустити скрипт вручну, без поштового повідомленні, строку слід передавати саме в такому вигляді.
scancomments.pl відкриває головну сторінку журналу, знаходить на ній всі посилання на пости цього ж журналу і сканує всі коментарі з цих постів на предмет спаму. Коментарі парсяться досить примітивним чином, тому в аналізатор також потрапляє супутній html-код. Тому потрібно уважно слідкувати, щоб зразки спам-коментарів із файла patterns.txt не були схожі на html-розмітку. В тому числі вкрай небажано використовувати як маркери спаму числа, а також строки, які використовуються в оформленні журналу (напр., Link, оставить комментарий etc).
PS Для відладки створив жж-аккаунт imaspammer, пароль TWisE3Ey , може, кому знадобиться.
Джентльменський набір мов сьогоднішнього веб-дизайнера виглядає так: html, php, sql, javascript. Відкладемо поки що питання цілісної технології і поговоримо про ці мови.
HTML. Призначення: гіпертекст, верстка, оформлення. Про деякі проблеми HTML я вже згадував: гарно пристосований для гіпертексту, погано пристосований до верстки, особливо до верстки форм. В результаті народжуються п’ятиповерхові таблиці, плаваючі div’и в три шари та інші маленькі радощі веб-дизайнера. До всього в html, на відміну від xml, погано структуруються дані, тому робота з ними на стороні клієнта ускладнена.
PHP. Призначення: серверне програмування. Перша і головна моя претензія до php: скриптові мови взагалі не призначені для серйозного програмування. Скрипти — для сисадміна, програмісту потрібна мова зі строгою типізацією, здебільшого без автоматичного приведення типів, з компіляцією (принаймі, в байт-код). Простий тест: спитайте у знайомого веб-дизайнера, чи заважала б йому строга типізація в PHP. Якщо заважала б — то він не програміст, тому що кожен програміст знає, що насправді значно простіше слідкувати за перетвореннями типів, ніж потім розгрібати таємничі помилки, що виникают в результаті некоректного приведення.
Взагалі в php купа деталей, які ніби спеціально придумані, щоб сприяти неякісному написанню коду: перемішаність програмної логіки та інтерфейсного коду (html), поділ на файли по критерію результуючої сторінки, що, крім усього, часто розносить код, який працює з одним і тим самим набором даних, по декількох файлах; навіть така дрібниця, як директива include, що приймає аргументом шлях відносно основного скрипта, що сильно ускладнює дворівневе включення у тому випадку, коли проміжний файл включається в два скрипти, розташовані в різних каталогах. Я вже не кажу про такі речі, як відсутність послідовності в іменуванні функцій, вимогах до назв функція та змінних, дивна поведінка з глобальними змінними. Це все викладено в, НМД, трохи експресивному, але по суті вірному записі nuclight. Остаточно мене вбив ось цей приклад з документації розробника. Гірше такої мішанини з напівстатичних методів мені навіть важко щось уявити. Якщо програміст на момент написання функції ще не визначився, відноситься вона до об’єкту чи до класу, то йому терміново треба відійти від комп’ютера години на півтори і ще раз гарно все обдумати.
PHP, виходить, орієнтований не просто на початківця, а на початківця, який усіма силами намагається уникнути того, щоб бути змушеним писати нормальний код. В результаті маємо те, що маємо: ледве не на кожному сайті можна знайти численні серйозні уразливості.
Мабуть, найменше претензій у мене до мови SQL. Окрім таких завдань, як вибір строки з найменшим значенням одного з полів, я практично не стикався з завданням отримання або модифікації даних, яке не можна було б красиво реалізувати на sql.
З JavaScript’ом я, на жаль, знайомий досить поверхово. Мушу сказати, що, змушений функціонувати в рамках DOM, javascript не є достатньо зручним засобом для модифікації як контенту, так і інтерфейсу. Хоча сама мова влаштована досить красиво.
Далі буде...
Давно збирався викласти свої думки з приводу сучасного стану речей в веб-програмуванні. Ну що ж, поїхали.
Сучасний стан речей в веб-програмуванні мені категорично не подобається. Точніше буде сказати, що мені категорично не подобається сучасне веб-програмування в цілому. Чому — розповідь довга.
Почну, мабуть, з історичного аспекту.
З самого початку веб призначався для розміщення гіпертексту (тексту з лінками, малюнками та ін.) в Інтернеті. Тобто, скажімо, можна розмістити книжку з ілюстраціями і перехресними посиланнями всередині книги та на зовнішні джерела. Мова, яка під ці потреби була розроблена — html — для цих завдань була гарно пристосована. При цьому вона зовсім не була пристосована ні для більш-менш пристойної верстки, ні для динамічної побудови. З часом програмісти зметикували, що, раз віддає клієнту файли програма (веб-сервер), то можна цю саму програму заставити віддавати не лише статичний файл, а і динамічно згенерований контент. Така динаміка була додатковою примочкою, дрібною автоматизацією ручної зміни даних, і використовувалася для таких речей, як лічильник відвідувань, мітки часу на сторінках та ін. Арсенал засобів, які використовувалися, був досить широким, але цілком характерним саме для задач дрібної автоматизації — скажімо, скриптові мови, технологія CGI, яка для кожного веб-запиту утворювала окремий процес операційної системи.
Потім динаміку придумали використовувати для побудови серйозних фрагментів контенту, скажімо, для розділу новин. Це утворило зразу дві проблеми: по-перше, замість вставки в готову html-структуру окремих строк, засоби динамічної генерації контенту почали самостійно будувати структуру html-розмітки. По-друге, обчислювальні потужності, які стали витрачатися на генерацію контенту, стали порівнянні з рештою витрат на роботу веб-сервера. Ця проблема з часом все більше наростала, з неї почали викручуватися різними кривими способами, такими як Fast CGI.
Потім хтось здогадався розробити веб-сервіси. Це було початком кінця.
По-перше, це вимагало все більш віртуозної верстки, складність якої наростала разом з вимогами дизайнерів і клієнтів «зробити красиво». Це поставило проблему динамічної побудови структурованого html-коду у повен зріст: якщо просто побудувати таблицю зі змінною кількістю строк, в залежності від кількості останніх новин — це ще завдання мислиме, то динамічно зверстати сторінку, яка містить верхнє меню, бічне меню, список рубрик, мапу сайту, тексти з коментарями та ще й прогноз погоди в кутку — це вже за гранню.
По-друге, навіть незалежно від складності верстки, html виявився малопридатним для передачі графічного інтерфейсу. Зверніть увагу: якщо зараз вікно деякої програми промальовується більше 1-2 секунд, користувач скаже, що програма гальмує. Виключенням з цього правила є веб-інтерфейс — мало у кого є достатьно широкосмуговий доступ до Інтернету, щоб за 1 секунду відображався будь-який сайт. Це пов’язано з великою кількістю запитів, необхідних для відображення однієї сторінки.
По-третьє, веб виявився абсолютно непристосованим до обробки окремих команд користувача. Фактично, протокол HTTP передбачає повну видачу готової до відображення сторінки у відповідь на кожен запит. Це є нормальним доти, доки запит справді є запитом. Коли ж запит перетворюється на команду, складається безглузда ситуація: у відповідь на додавання, скажімо, коментаря до тексту браузер вимушений перезчитувати повністю весь текст, коментарі і графічні файли оформлення. При тому, що насправді йому не потрібно отримувати інформації більше, ніж просто відповідь, прийнятий коментар чи ні. Клієнт сам може додати коментар до списку.
По-четверте, будь-який сервіс передбачає поняття сеансу — пов'язаної між собою серії віконних форм, які разом складають одну послідовність дій одного користувача. Від початку протокол HTTP не передбачав нічого подібного взагалі. Запити в межах цього протоколу є повністю ізольованими. Сессію доводилось емулювати додаванням фіксованого ідентифікатора сессії в кожен запит. Потім протокол розширили, узаконивши таку емуляцію у трохи іншому вигляді — у вигляді куків.
На цьому проблеми не закінчуються, але залишаються в основному проблеми спеціальні, їх я детальніше розберу в наступних частинах.
Продовжу про онлайн-спілкування.
IRL прийнято перед початком розмови здороватися, у випадку паузи в розмові вибачатися, а при закінченні — прощатися. Спробуємо розібратися в тому, звідки ростуть ноги в цих правил і як можна їх з розумом перенести на онлайн-спілкування.
Привітання. Ставить на меті:
1) при зустрічі — показати, що ми помітили і впізнали співбесідника
2) звернути його увагу на себе
3) показати, що ми хочемо щось йому сказати
Слід зазначити, що не обов’язково це досягається привітанням у прямому значенні слова — в ролі «привітання» може бути і вибачення, і звертання. Однак мета при цьому не міняється.
Вибачення. Застосовується для повідомлення, що розмову треба призупинити і для моральної компенсації співбесіднику, якому це може створити незручності.
Прощання. Як правило, складається з двох фаз — спочатку ми повідомляємо людині, що розмова закінчується («Ну, я тоді побіжу», «У мене, здається, все», «Ну що ж, буду збиратися»), потім відбувається власне прощання. Перша фаза потрібна для того, щоб не трапилось так, що людина ще має що сказати, а ми вже пішли кудись. Власне ж прощання, як правило, відбувається після того, як нам самим нема чого сказати і коли ми переконалися, що співбесідник свою думку також закінчив. «Прощання» може обмежуватися першою фазою, якщо, скажімо, людина йде в сусідню кімнату — тут варто лише переконатися, що людина закінчила свою думку.
Тепер про аську.
Привітання. Коротко — зазвичай воно в асьці непотрібне і навіть шкідливе.
Непотрібне — тому що клієнт нашого співбесідника з першим же нашим повідомленням виконає всі три пункти, які вимагаються від привітання: напише, від кого прийшло повідомлення, голосно співатиме і яскраво блиматиме на екрані, щоб привернути його увагу і дасть знати, що ми щось бажаємо сказати. Якщо так важливо дотриматись ритуалу, можна включити привітання в перше повідомлення разом з інформацією по суті питання. Ще як варіант — поздороватися «заднім числом», другим повідомленням. Такий варіант створить деяку динаміку спілкування, покаже, що Ви активно зайняті даною розмовою.
Шкідливе — тому що, на відміну від живого спілкування, коли ми можемо відразу після привітання пререйти до суті розмови, в Інтернет-пейджерах людина зможе почати читати наше друге повідомлення лише тоді, коли ми наберемо його повністю і відправимо. Увесь проміжок часу між приходженням привітання і власне повідомлення «по суті» людина, ймовірно, проведе в тупому спогляданні порожнього вікна чату. Якщо це буде 5-10 секунд, то, в принципі, це цілком прийнятно. Якщо ж людина написала «привіт» і на хвилину застрягла в глибокому «typing», то мене це, чесно скажу, дратує.
Є, щоправда, виключення: коли є деяка запланована розмова і про це пам’ятають обоє, то привітання дозволить нашому співбесіднику почати готувати відповідь на наше питання ще до того, як ми його напишемо.
Вибачення. Тут все просто — якщо ми активно спілкуємось, то перед тим, як відійти від комп’ютера, слід вибачитися і повідомити про це. Якщо в спілкування сама собою виникла пауза, і посеред неї виникла потреба відійти, то у випадку, якщо не очікується якась важлива розмова, то можна обмежитись зміною статусу. Хоча якщо відійти треба надовго і людина може не дочекатися Вашого повернення, то повідимити про це буде не зайве.
Ну і прощання. Тут ситуація ускладнена тим, що ми не можемо по співбесіднику побачити, бажає він ще щось сказати чи ні, і навіть чи присутній він за комп’ютером. Зазвичай я прощаюсь в два повідомлення, що відповідають фазам прощання — першим повідомляю про причину, чому я іду, і, якщо мені нічого не пишуть або просто прощаються, то я теж прощаюсь. У випадку, якщо від людини немає відповіді, я витримую деякий тайм-аут, в залежності від того, наскільки поспішаю, зазвичай це 1-3 хвилини. Це дозволить людині зупинити мене, якщо вона хотіла щось сказати.
Ну і наостанок. Якщо відключаєшся ненадовго (в межах години), наприклад, щоб доїхати з роботи додому, і ніяких важливих розмов не передбачається, то можна і взагалі не прощатися — це буде такий собі своєрідний аналог статусу «відійшов».
Ми живемо в епоху дикого Інтернету. Фактично, на даний момент правового поля, яке б регулювало життя мережі, не існує. Те, що існує, толком не працює. Кожен в Інтернеті має захищатися від всіх загроз самостійно. І наскільки він це здатний зробити, настільки ж безпечним і буде його життя в Інтернеті. З іншого боку, кожен вільний робити в мережі все, що забажає. Хтось користується цим з добрими намірами, хтось — зі злочинними. Але зараз можна користуватися мережею, не озираючись через плече, не хвилюючись, що хтось може схопити тебе за рукав і не боячись говорити те, що думаєш. Не знаю, як вам, а мені Інтернет подобається таким, яким він є. Але він таким не залишиться.
В будь-якій боротьбі без правил зловмисники завжди на півкроку випереджають тих, хто від них захищається. І в Інтернеті це правило підтверджується. 15 років назад в книжках писали, що в текстовому документі віруса бути не може, і слово «спам» чув мало хто. 10 років назад люди не знали, що таке поштові віруси і IM-реклама. 5 років назад P2P-ботнет був річчю виключно теоретичною. Спамери перейшли від відправки повідомлень через відкриті релеї до використання комп’ютерів-зомбі і ботнетів. Не встигли люди звикнути до веб-сервісів, як уже з’явились стандартні, майже конвейрні методи злому веб-додатків, такі, як SQL-ін’єкція. Кібер-гопники знайшли для ботнетів «достойне» застосування — DDOS-атаки.
Суспільство, щоб не бути на півкроку позаду від зловмисників, змушене буде захиститися формально — законодавчим шляхом, регламентацією діяльності в мережі, постійним наглядом за нею, судовим арбітражем, забороною деяких таких зручних нам, але ще більш зручних зловмисникам особливостей мережі. Тільки так вдасться більш-менш остаточно припинити спам, ботнети, торгівлю зламаними шелками і дедиками, дефейси, вірусні епідемії та інші радості сучасного життя в мережі. До цього з часом приходять всі дикі утворення.
Звичайно, така формалізація потребує сильної координації законодавців з багатьох країн. Тому найближчим часом це все зроблено не буде. Почнеться це нескоро, а прийде в більш-менш прийнятний вигляд дуже нескоро. Але «нескоро» в ІТ — це дуже недовго. Тому наші діти ще, можливо, побачать дикий Інтернет, де ніхто за тобою не слідкує, а внукам ми будемо на ніч розказувати байки про те, як в XX столітті, ще при Кучмі (був такий президент) ми висіли он-лайн на модемі, Інтернет коштував $1 за годину і там були відкриті всі порти, пошта не фільтрувалася сервером, а злом сайта міг залишатися непоміченим місяцями і безкарним взагалі.
Старий добрий Інтернет відійде. І мені з цього приводу дуже жаль.
Я не злой, просто я пишу без смайлов
Мені тут популярно пояснили, навіщо потрібні смайли. Пояснили мені наступне: в живій розмові є багато виразних засобів (міміка, інтонація та ін.), які доповнюють собою мовлення. В текстовому ж онлайн-спілкуванні ці засоби відсутні, тому заміна їх певними значками є цілком нормальним явищем.
Я чекав цього пояснення. Воно було би все саме так, якби стояла мета замінити живе спілкування. Мета ж стоїть зовсім інша — спілкуватися он-лайн.
У кожного виду спілкування є свої засоби передачі нюансів. В живого спілкування вони, безперечно, багатші: інтонація, міміка, жестикуляція. В текстового спілкування — скромніші: різноманітні прийоми на кшталт регістру, курсиву, ну і, звісно, усі літературні засоби, вироблені за багато століть. Однак, як казав один політик, маємо те, що маємо. Якщо вибираєш текстове спілкування, то варто освоїти характерні для нього виразні засоби, а не застосовувати костилі засобів усного мовлення.
Уявімо, наприклад, що в людей на лобі була б лампочка, яка могла змінювати колір і яскравість за бажанням людини. Можна не сумніватися, що вона поряд з голосовим мовленням могла бути застосовувана для спілкування. Також можна не сумніватися, що люди при цьому вважали б телефонне спілкування сильно обмеженим у порівнянні з живим у зв’язку з відсутністю можливості поблимати лампочкою. Зараз ми бачимо, що насправді спілкування без лампочки цілком достатньо насичене усіма необхідними засобами для передачі настрою, відтінків змісту та ін. Однак якби люди придумали спеціальні звуки-замінники для різних кольорів лампочки і стали б використовувати їх у телефонних розмовах, то це уже було би деяким збоченням. І як їм пояснити у цьому випадку, що такі замінники насправді не потрібні абсолютно?
Я, загалом, погоджусь, що зрідка трапляються випадки, коли смайл був би доречний. Але такі випадки доволі рідкі.
Якщо, до речі, комусь цікаво, можу проілюструвати на конкретних прикладах, як можна замінювати смайли.
От, скажімо, смайли. Типографський прийом, покликаний передавати емоційну складову текстового повідомлення. Я їх сам часто вживаю. Але я їх вживати не люблю. Чому? Дуже просто: смайли — це спрощений варіант передачі того, що можна передати і без смайлів. Нормальною мовою. Таке спрощення і сплощення може бути виправдане інтерактивністю спілкування і коротким часом на відповідь, однак навіщо виправдовуватися?
Або, скажімо, аватарки. Їх ще називають юзерпиками, від чого мені дуже смішно. Я довго не розумів, нащо ж вони потрібні. Тобто я розумів, що самовиразитися можна у візуальному образі, однак ні найменшої потреби у такому самовираженні у мене не було. Збагнув тоді, коли почав читати онлайн-журнали — аватарки дозволяють більш-менш орієнтуватися у діалозі, хто що говорить і яку позицію захищає. Тобто відіграють піктографічну роль. Користуватися підпорами в онлайн-спілкуванні буває необхідно, аватарки в журналах — саме той випадок.
Чи от, наприклад, статуси в асьці. Я довго сприймав custom статуси як ознаку, що людина викаблучується. Тепер можу погодитися, що це цілком нормальний спосіб подолати проблему невидимості співрозмовника, коли не можна сказати, в якому настрої зараз людина, чи варто лізти до неї зі своєю розмовою. Хоча сам статуси використовую лише для повідомлення про відсутність. Мабуть, тому, що у всіх інших випадках я готовий відповісти людині.
Можливо, я зануда і консерватор, але я намагаюсь використовувати подібні підпорки мінімально. Тобто з міркувань ввічливості — повідомлення про відсутність, щоб людина не говорила з /dev/null, аватарка в ЖЖ (обов’язково зроблю), щоб зручніше було читати мої бійки в коментарях. А для всього іншого вистачить чистого тексту.
ЗІ englishman, прохання не вбивати за «статус». alexuol, прохання не вбивати за «custom».
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
timeasmymeasure
