Если в статье есть ссылки или превью иллюстраций, требующие клика, то их можно использовать в качестве промежуточных маркеров. Точность результатов должна заметно возрасти.
А у вас нет образа того, как должен выглядеть механизм по обмену социальными графами между сообществами?
Ничего оригинального не могу сказать по этому поводу.
Мне вообще кажется, что у идеи единого индивидуального платформонезависимого соц. графа здесь не такой большой потенциал. Ведь есть же огромное количество маленьких сообществ. Если я являюсь участником такого сообщества, то скорее всего никого из моей традиционной соц. сети там нет. Со временем у меня там формируется новый круг знакомых, и вот тут у меня может возникнуть проблема укрепления связей с какими-то отдельными людьми из этого круга, обусловленная техническими недостатками сайта. Но вообще, если желание сильное, обменяться контактами обычно удается. А дальше сто раз пережеванный вопрос: нужно ли тащить эту связь в свою соц. сеть.
Задачу прошерстить всех знакомых и друзей моих знакомых, составить список частично решил, например, гугл www.google.com/s2/search/social?hl=ru#sd. Яндекс сделал people.yandex.ru/. Не сегодня завтра, можно будет выявить неизвестные общие интересы в своем круге.
С точки зрения укрепления связей, образовавшихся в сообществе, мне нравится подход okcupid с опросниками и вычислением пересечений. Или goodreads, или last.fm. Но все они несколько однобоки, заточены под свою тематику. Если бы был какой-то инструмент, комплексно анализирующий данные по человеку из разных источников, это было бы подспорьем в укреплении связей. Но в рамках рядового сайта сообщества такой инструмент вряд ли получится разработать.
… мне кажется забавным попробовать сделать некое подобие интеграции в одностороннем порядке.
Наверное было бы хорошо, если бы сайт сам предлагал посетителю выдачу результатов поиска по пользователям по комбинации параметров. Например, пользователь из Самарской области (сайт это видит по ip), у человека есть твиттер. Сайт находит в своей базе таких же пользователей. Потом сравнивает самые часто употребляемые слова, ранжирует по степени близости. Дальше предлагает обоим обменяться контактами и вообще всячески дружить. Вот это может быть интересная задача для администрации сообщества.
Как простому участнику конкретного сообщества, мне очевидны плюсы развитых возможностей сохранения связей.
Но с точки зрения администратора сообщества плюсы не так очевидны. Если в одном сообществе сделают всё как надо, а в остальных ничего не сделают, то бонус от «циркуляции» пользователей никто не получит. При этом ресурсы на доработку сайта будут потрачены. Причем речь здесь не идет о примитивной интеграции с соцсетями. Чтобы сделать как надо, потребуется много работы, особенно организационной. Игра стоит свеч только при скоординированных действиях большого числа администраторов-сообществ. То есть заранее можно предположить, что в целом игра проигрышная.
Именно идея «циркуляции» для меня не выглядит достаточно обоснованной.
А поясните, пожалуйста, что вы подразумеваете под «компенсацией»?
Удовлетворение каких-либо материальных или идеальных потребностей: самореализации, аффиляции и др.
А ведь это и есть то, что мы называем «сильными связями». Не так ли?
Да, если в широком смысле. Я же зацепился за конкретную формулировку "… участники этих сообществ не имеют возможность сохранять установленные ими взаимоотношения. В результате, участники зачастую не хотят вкладывать своё время..."
Если понимать в том смысле, что на сайте сообщества не развиты средства установления связей, их развития и поддержания, то наверное соглашусь.
Кстати, пришел в голову пример. Часто на сайтах-сообществах можно видеть темы «обмениваемся номерами icq», «кто где живет», «наши страницы вконтакте». Как раз проявление потребности пользователей, хотя вероятно не все эту потребность осознают в достаточной степени.
Но, справедливости ради, сделать на сайте систему, поощряющую построение нормальных связей трудно. Скажем, далеко не каждый решится написать по внутренней почте человеку, который показался интересным. Как правило недостаточно данных, чтобы «комплексно» оценить человека и решиться, либо трудно найти стоящий повод.
«Сегодня, большинство людей, присоединяющихся к онлайн-сообществам, не желает сильных взаимоотношений...»
Мне кажется, наоборот, многие хотели бы большего внимания к себе, и охотно развивают отношения с другими участниками сообщества.
"… большинство платформ… и вовсе спроектировано так, что участники этих сообществ не имеют возможность сохранять установленные ими взаимоотношения. В результате, участники не хотят вкладывать своё время и энергию в построение отношений внутри этих сообществ".
По-моему основные причины не вкладывать время и энергию в конкретное сообщество другие. Например, отсутствие уверенности в получении достаточной компенсации. Про трудности с сохранением взаимоотношений вряд ли люди думают.
2. Вот этот момент:
"… препятствует циркуляции супер-пользователей между сообществами. На первый взгляд, это может показаться хорошим положением дел, ведь вы сохраняете ценных супер-пользователей. Но если мы проанализиируем эту ситуацию с помощью теории игр, то всё окажется с точностью до наоборот..."
Чтобы сообщества получили бонус от интеграции с соцсетями / построения своего внутреннего соц. слоя, с точки зрения теории игр, видимо, нужен Парето-оптимум. То есть, чтобы все администраторы сообществ поняли и реализовали возможность «уносить соц. граф с собой». И тогда будет хорошая «циркуляция пользователей». Как вы думаете, не находятся ли такие сообщества в меньшинстве и, следовательно, в невыгодном положении?
Можно так:
— написал чат на PHP + AJAX, который держит на VPS со 128 Мб памяти 200 пользователей онлайн, находится по адресу *link*
— сделал сложный поиск по базе кондиционеров, скриншот формы *link*
— внедрил на работающем комьюнити сайте с 10k хостов в сутки систему кармы (бонусы за добавление контента, рейтинг пользователей, защита от накруток)
— разработал 5 сайтов на Drupal с использованием модулей CCK, Views, Ubercart
— сделал интернет-магазин (интеграция с 1С, 20000 товарных позиций, система управления заказами), работает уже 3 года, месячный оборот 100 млн. рублей
1. Нужно писать очень много тестов. И может получиться, что их актуализация будет занимать много времени.
2. Тестами можно проверить формальные вещи. Но если я захочу более интеллектуальный контроль, то придется думать над алгоритмами тестов. И здесь уже я о некоторых вариантах могу даже не догадываться. Скажем, захочу проверить безопасность веб-формы. Это ведь нужно очень разноплановые тесты писать. Ну и опять же это небыстрое дело.
Допустим, есть магазин. Там функция загрузки и обновления товаров из CSV. То есть база товаров полностью ведется в экселе, и периодически апдейты (новые цены, исправленные ошибки в описаниях) выгружаются на сайт. В базе много разноплановых данных: числа целые и дробные, текст, привязка к разделам каталога, привязка к другим товарам и т. д.
По-простому пишется код, разбирающий csv и записывающий в базу. Делается тестовый файл с несколькими пограничными вариантами, загружаем его и смотрим во всех частях сайта, что получается.
А как с тестами? Я не могу даже охватить все сферы, которые в этой задаче нужно протестировать. Корректность вывода товаров в сокращенном и полном видах, работоспособность поиска, корректность введенных данных, корректность формата загружаемого файла, разные вопросы затирания старых данных, ошибки дублирования записей.
На такое пишут тесты? Где бы про это узнать, а то элементарных примеров много, но не понятно, как это масштабируется.
Есть интересные задачи в веб-программировании — сделать механизм расчета кармы, защиту от накруток в анонимном голосовании, красивый эффект на js, увеличить производительность тяжелого скрипта, придумать изящную архитектуру компонента. А есть не такие интересные. К ним относится конструирование двухшаговой формы.
Да с этим и спорить особо нечего. А в статье автор передергивает.
Я тут подумал, что в веб-программировании вообще много рутины. Львиная доля работы — это конструирование форм, сохранение/изменение/удаление данных и настройка вывода. Редко когда приходится подумать о производительности или использовать хитрый алгоритм.
Про «ввести абстракцию «тип данных»». Пусть из 10 полей у нас 7 требуют разной валидации. Прописать всё это на любом уровне абстракции — рутина. Правда мы рассчитываем сделать это один раз и использовать в следующих проектах. Но вот новый проект, и там добавляется еще пара полей. Еще выясняется, что в поле емейл возможен символ "+". Поправим библиотеку типов. И это тоже рутина — поддержка этой библиотеки в актуальном состоянии.
Большинству программистов так или иначе приходится залезать в область данных. Представьте веб-студию, где над сайтом работает пять человек: менеджер проекта, дизайнер, верстальщик, программист, редактор. Кто из них будет прописывать сообщения об ошибках? В маленьких и средних проектах приходится совмещать.
А взять ребят, которые занимаются 1С. Тоже программисты. Они усмехнутся на призыв «Идите со мной туда, где программирование — великое искусство и инженерное чудо эпохи, а вовсе не отстой».
«Там где программист начинает заниматься вводом данных — начинается рутина». Это правильно. Но ведь сплошь и рядом приходится заниматься вот такими вот рутинными вещами.
Тон статьи безапелляционный. Назвать можно было так: «Программирование — не отстой, но рутины хлебнете будь здоров».
Допустим, нужно сделать веб-форму с десятком разных полей. И, конечно, наш сайт делается на развитом фреймворке. Но все равно придется прописать параметры каждого чекбокса, каждого текстового поля с автозаполнением. Придется придумать к ним валидацию. Придется сочинить сообщения об ошибках.
Нет смысла отрицать, что в разработке ПО много рутины. Если поднимаемся на высокий уровень абстракции, то, значит, придется прописывать много параметров.
Программисту не проблема придумать, чем себя развлечь даже при решении стандартных задач. Но чаще всего для заказчика творческий подход разработчика выливается в удлинение сроков, и ничего больше.
Спасибо, хорошие мысли. Может быть даже интересны не как отдельные проекты, а как сервисы в рамках существующих сайтов. Видно, что идеи вынашивались. Это выгодно отличает их от аналогичных списков в стиле «вот какой я фантазер, могу за полчаса столько идей нагенерировать, что вам за полжизни не разгрести».
Небольшой фидбек:
* содержимое блоков долго грузится даже при обновлении страницы,
* разноцветные рамки блоков и прочие функциональные элементы акцентируют на себе внимание, забивая контент,
* пресеты виджетов (бизнес, развлечения, интернет) как-то неинтересно сделаны, без любви,
* у иконок на верхних табах белые пиксели по краям, а лучше бы прозрачность была.
Ничего оригинального не могу сказать по этому поводу.
Мне вообще кажется, что у идеи единого индивидуального платформонезависимого соц. графа здесь не такой большой потенциал. Ведь есть же огромное количество маленьких сообществ. Если я являюсь участником такого сообщества, то скорее всего никого из моей традиционной соц. сети там нет. Со временем у меня там формируется новый круг знакомых, и вот тут у меня может возникнуть проблема укрепления связей с какими-то отдельными людьми из этого круга, обусловленная техническими недостатками сайта. Но вообще, если желание сильное, обменяться контактами обычно удается. А дальше сто раз пережеванный вопрос: нужно ли тащить эту связь в свою соц. сеть.
Задачу прошерстить всех знакомых и друзей моих знакомых, составить список частично решил, например, гугл www.google.com/s2/search/social?hl=ru#sd. Яндекс сделал people.yandex.ru/. Не сегодня завтра, можно будет выявить неизвестные общие интересы в своем круге.
С точки зрения укрепления связей, образовавшихся в сообществе, мне нравится подход okcupid с опросниками и вычислением пересечений. Или goodreads, или last.fm. Но все они несколько однобоки, заточены под свою тематику. Если бы был какой-то инструмент, комплексно анализирующий данные по человеку из разных источников, это было бы подспорьем в укреплении связей. Но в рамках рядового сайта сообщества такой инструмент вряд ли получится разработать.
Наверное было бы хорошо, если бы сайт сам предлагал посетителю выдачу результатов поиска по пользователям по комбинации параметров. Например, пользователь из Самарской области (сайт это видит по ip), у человека есть твиттер. Сайт находит в своей базе таких же пользователей. Потом сравнивает самые часто употребляемые слова, ранжирует по степени близости. Дальше предлагает обоим обменяться контактами и вообще всячески дружить. Вот это может быть интересная задача для администрации сообщества.
Как простому участнику конкретного сообщества, мне очевидны плюсы развитых возможностей сохранения связей.
Но с точки зрения администратора сообщества плюсы не так очевидны. Если в одном сообществе сделают всё как надо, а в остальных ничего не сделают, то бонус от «циркуляции» пользователей никто не получит. При этом ресурсы на доработку сайта будут потрачены. Причем речь здесь не идет о примитивной интеграции с соцсетями. Чтобы сделать как надо, потребуется много работы, особенно организационной. Игра стоит свеч только при скоординированных действиях большого числа администраторов-сообществ. То есть заранее можно предположить, что в целом игра проигрышная.
Именно идея «циркуляции» для меня не выглядит достаточно обоснованной.
Удовлетворение каких-либо материальных или идеальных потребностей: самореализации, аффиляции и др.
Да, если в широком смысле. Я же зацепился за конкретную формулировку "… участники этих сообществ не имеют возможность сохранять установленные ими взаимоотношения. В результате, участники зачастую не хотят вкладывать своё время..."
Если понимать в том смысле, что на сайте сообщества не развиты средства установления связей, их развития и поддержания, то наверное соглашусь.
Кстати, пришел в голову пример. Часто на сайтах-сообществах можно видеть темы «обмениваемся номерами icq», «кто где живет», «наши страницы вконтакте». Как раз проявление потребности пользователей, хотя вероятно не все эту потребность осознают в достаточной степени.
Но, справедливости ради, сделать на сайте систему, поощряющую построение нормальных связей трудно. Скажем, далеко не каждый решится написать по внутренней почте человеку, который показался интересным. Как правило недостаточно данных, чтобы «комплексно» оценить человека и решиться, либо трудно найти стоящий повод.
1. Вы согласны с этими утверждениями из текста?
«Сегодня, большинство людей, присоединяющихся к онлайн-сообществам, не желает сильных взаимоотношений...»
Мне кажется, наоборот, многие хотели бы большего внимания к себе, и охотно развивают отношения с другими участниками сообщества.
"… большинство платформ… и вовсе спроектировано так, что участники этих сообществ не имеют возможность сохранять установленные ими взаимоотношения. В результате, участники не хотят вкладывать своё время и энергию в построение отношений внутри этих сообществ".
По-моему основные причины не вкладывать время и энергию в конкретное сообщество другие. Например, отсутствие уверенности в получении достаточной компенсации. Про трудности с сохранением взаимоотношений вряд ли люди думают.
2. Вот этот момент:
"… препятствует циркуляции супер-пользователей между сообществами. На первый взгляд, это может показаться хорошим положением дел, ведь вы сохраняете ценных супер-пользователей. Но если мы проанализиируем эту ситуацию с помощью теории игр, то всё окажется с точностью до наоборот..."
Чтобы сообщества получили бонус от интеграции с соцсетями / построения своего внутреннего соц. слоя, с точки зрения теории игр, видимо, нужен Парето-оптимум. То есть, чтобы все администраторы сообществ поняли и реализовали возможность «уносить соц. граф с собой». И тогда будет хорошая «циркуляция пользователей». Как вы думаете, не находятся ли такие сообщества в меньшинстве и, следовательно, в невыгодном положении?
Спасибо автору топика за интересный материал.
WCAG Contrast checker для проверки контраста текста и фона.
Multifox чтобы переключаться между аккаунтами сайта в одном окне.
Firepicker для наглядного изменения цветов в Firebug.
Да, тут есть масштаб :)
— написал чат на PHP + AJAX, который держит на VPS со 128 Мб памяти 200 пользователей онлайн, находится по адресу *link*
— сделал сложный поиск по базе кондиционеров, скриншот формы *link*
— внедрил на работающем комьюнити сайте с 10k хостов в сутки систему кармы (бонусы за добавление контента, рейтинг пользователей, защита от накруток)
— разработал 5 сайтов на Drupal с использованием модулей CCK, Views, Ubercart
— сделал интернет-магазин (интеграция с 1С, 20000 товарных позиций, система управления заказами), работает уже 3 года, месячный оборот 100 млн. рублей
1. Нужно писать очень много тестов. И может получиться, что их актуализация будет занимать много времени.
2. Тестами можно проверить формальные вещи. Но если я захочу более интеллектуальный контроль, то придется думать над алгоритмами тестов. И здесь уже я о некоторых вариантах могу даже не догадываться. Скажем, захочу проверить безопасность веб-формы. Это ведь нужно очень разноплановые тесты писать. Ну и опять же это небыстрое дело.
Допустим, есть магазин. Там функция загрузки и обновления товаров из CSV. То есть база товаров полностью ведется в экселе, и периодически апдейты (новые цены, исправленные ошибки в описаниях) выгружаются на сайт. В базе много разноплановых данных: числа целые и дробные, текст, привязка к разделам каталога, привязка к другим товарам и т. д.
По-простому пишется код, разбирающий csv и записывающий в базу. Делается тестовый файл с несколькими пограничными вариантами, загружаем его и смотрим во всех частях сайта, что получается.
А как с тестами? Я не могу даже охватить все сферы, которые в этой задаче нужно протестировать. Корректность вывода товаров в сокращенном и полном видах, работоспособность поиска, корректность введенных данных, корректность формата загружаемого файла, разные вопросы затирания старых данных, ошибки дублирования записей.
На такое пишут тесты? Где бы про это узнать, а то элементарных примеров много, но не понятно, как это масштабируется.
Да с этим и спорить особо нечего. А в статье автор передергивает.
Про «ввести абстракцию «тип данных»». Пусть из 10 полей у нас 7 требуют разной валидации. Прописать всё это на любом уровне абстракции — рутина. Правда мы рассчитываем сделать это один раз и использовать в следующих проектах. Но вот новый проект, и там добавляется еще пара полей. Еще выясняется, что в поле емейл возможен символ "+". Поправим библиотеку типов. И это тоже рутина — поддержка этой библиотеки в актуальном состоянии.
А взять ребят, которые занимаются 1С. Тоже программисты. Они усмехнутся на призыв «Идите со мной туда, где программирование — великое искусство и инженерное чудо эпохи, а вовсе не отстой».
«Там где программист начинает заниматься вводом данных — начинается рутина». Это правильно. Но ведь сплошь и рядом приходится заниматься вот такими вот рутинными вещами.
Тон статьи безапелляционный. Назвать можно было так: «Программирование — не отстой, но рутины хлебнете будь здоров».
Нет смысла отрицать, что в разработке ПО много рутины. Если поднимаемся на высокий уровень абстракции, то, значит, придется прописывать много параметров.
Программисту не проблема придумать, чем себя развлечь даже при решении стандартных задач. Но чаще всего для заказчика творческий подход разработчика выливается в удлинение сроков, и ничего больше.
* содержимое блоков долго грузится даже при обновлении страницы,
* разноцветные рамки блоков и прочие функциональные элементы акцентируют на себе внимание, забивая контент,
* пресеты виджетов (бизнес, развлечения, интернет) как-то неинтересно сделаны, без любви,
* у иконок на верхних табах белые пиксели по краям, а лучше бы прозрачность была.