Здравствуйте, ionoy, Вы писали:
I>Помнится, Влад предлагал сделать на NemerleWeb новое дерево/меню для rsdn.ru. I>Всё остальное генерируется фреймворком.
Зашёл, увидел всего два "нормальных" тега — html и body, застрелился.
Куда катится веб? Зачем нужны все эти жабоскрипты? Почему нельзя просто взять NCSA Mosaic и посмотреть RSDN?
Здравствуйте, matumba, Вы писали:
M>Зашёл, увидел всего два "нормальных" тега — html и body, застрелился. M>Куда катится веб? Зачем нужны все эти жабоскрипты? Почему нельзя просто взять NCSA Mosaic и посмотреть RSDN?
Если бы не "жабоскрипты", то меню RSDN занимало бы 60 страниц чистого текста на 1080р экране и грузилось 10 секунд. Так что тут нужно определится, либо мы хотим удобство и скорость использования, либо возможность использовать NCSA Mosaic как основной браузер.
Ну и никто не заставляет использовать наш фреймворк для чисто контентных страниц (хотя даже для них он был бы очень удобен).
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, ionoy, Вы писали:
I>>Помнится, Влад предлагал сделать на NemerleWeb новое дерево/меню для rsdn.ru. I>>Всё остальное генерируется фреймворком.
M>Зашёл, увидел всего два "нормальных" тега — html и body, застрелился. M>Куда катится веб? Зачем нужны все эти жабоскрипты? Почему нельзя просто взять NCSA Mosaic и посмотреть RSDN?
А <div> за тег не считается ?
Для нас поддержка NCSA Mosaic не приоритет.
Но если хотите помочь, милости просим.
Здравствуйте, ionoy, Вы писали:
I>Если бы не "жабоскрипты", то меню RSDN занимало бы 60 страниц чистого текста на 1080р экране и грузилось 10 секунд.
Отцы Веба смотрят на тебя с недоумением. РСДН — не самый большой и уж точно не самый активный сайт Сети. Но почему-то "большим" сайтам хватало технических возможностей навигироваться вообще без скриптов.
Сам сайт — это небольшая кучка разделов, причём настолько специализированных, что попадая в один, абсолютно фиолетово на подразделы других разделов. Другими словами, "дерево" не имеет никакого смысла (не говоря о том, что дерево с > 20 веток — адЪ и трэш). Соотв. с главной страницы при помощи новомодных метро-плиток можно уйти в раздел, а уже внутри будет достаточно десятка боковых менюшек. Дополнительный бенефит — простота ссылаемости (букмарки, ссылки из блогов), может даже индексируемости.
Про скрипты: сижу в Опере 12.15, захожу на форум, кликаю на пост. В результате треть верха — список постов, нижняя треть — сообщение, а в центре — пустое пространство, которое (спасибо жабописуну) даже невозможно перекрыть сообщением — оно возвращается в свою нижнюю треть!! Тут не то что Тёме, тут любому нормальному хочется плюнуть и сослать верстальщика на 20 лет назад, во времена трёх тегов и CGI.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, ionoy, Вы писали:
I>>Если бы не "жабоскрипты", то меню RSDN занимало бы 60 страниц чистого текста на 1080р экране и грузилось 10 секунд.
M>Отцы Веба смотрят на тебя с недоумением. РСДН — не самый большой и уж точно не самый активный сайт Сети. Но почему-то "большим" сайтам хватало технических возможностей навигироваться вообще без скриптов.
Ты так мне это рассказываешь, как будто я главный разработчик rsdn.ru. Нам предложили обновить меню, мы согласились, т.к. в любом случае надо на чём-то обкатывать фреймворк.
M>Сам сайт — это небольшая кучка разделов, причём настолько специализированных, что попадая в один, абсолютно фиолетово на подразделы других разделов.
Это уже вопрос дизайна навигации. У дерева есть как недостатки, так и преимущества, как ты и сам понимаешь.
M>Другими словами, "дерево" не имеет никакого смысла (не говоря о том, что дерево с > 20 веток — адЪ и трэш).
Имеет, хоть это и не всегда самый удобный вариант.
M>Соотв. с главной страницы при помощи новомодных метро-плиток можно уйти в раздел, а уже внутри будет достаточно десятка боковых менюшек. Дополнительный бенефит — простота ссылаемости (букмарки, ссылки из блогов), может даже индексируемости.
Это всё общие слова. Сделай прототип, покажи пацанам, авось благодаря тебе у rsdn.ru появится новая, удобная навигация. Текущее дерево тебе Влад, думаю, может выслать.
M>Про скрипты: сижу в Опере 12.15, захожу на форум, кликаю на пост. В результате треть верха — список постов, нижняя треть — сообщение, а в центре — пустое пространство, которое (спасибо жабописуну) даже невозможно перекрыть сообщением — оно возвращается в свою нижнюю треть!! Тут не то что Тёме, тут любому нормальному хочется плюнуть и сослать верстальщика на 20 лет назад, во времена трёх тегов и CGI.
Ну, наша часть только слева, так что причём тут список постов и сообщения, я
Здравствуйте, ionoy, Вы писали:
M>>... "большим" сайтам хватало технических возможностей навигироваться вообще без скриптов. I>Ты так мне это рассказываешь, как будто я главный разработчик rsdn.ru.
Если человек пишет меню для РСДН, можно предположить, что он имеет к РСДН какое-то отношение. Нет — так нет, просто считайте мои слова "мыслями вслух".
I> Сделай прототип, покажи пацанам
У меня с креативностью — беда. Я могу хорошо критиковать, могу подкидывать идеи-улучшалки, но глобальные концепции — не моё. Нужен кто-то "не от мира сего" с арт-мозгами ("настоящих буйных мало — вот и нету вожаков!" ).
Но саму идею можно и попробовать — на плитки хорошо проецируются разделы со свежей инфой.
I>Ну, наша часть только слева, так что причём тут список постов и сообщения, я
И я х/з! Может Влад прочитает и скажет кому надо — "доколе эти жабоскрипты нам мешать будут!" и кулаком так постолу — НА! Ой, чота меня прёт.....
Здравствуйте, _NN_, Вы писали:
_NN>Вы наверное и почтой в стиле gmail не пользуетесь потому что там вообще сплошной JS ?
"Для игр у меня домино есть!" (с)околов
А у меня для почты — Аутлюк + POP3.
Недавно кстати интересный маразм обнаружил: если письма с Г-мыла получать по POP3, у этих идиотов по-умолчанию стоит настройка типа "поп3 работает отдельно, а веб-ящик всё равно будет показывать копии писем", хотя в Аутлюке стоит галка "не оставлять письма на сервере". Нормал, да? Гуглу пофиг спеки, у них своя атмосфера!
Здравствуйте, ionoy, Вы писали:
M>>Про скрипты: сижу в Опере 12.15, захожу на форум, кликаю на пост. В результате треть верха — список постов, нижняя треть — сообщение, а в центре — пустое пространство, которое (спасибо жабописуну) даже невозможно перекрыть сообщением — оно возвращается в свою нижнюю треть!! Тут не то что Тёме, тут любому нормальному хочется плюнуть и сослать верстальщика на 20 лет назад, во времена трёх тегов и CGI. I>Ну, наша часть только слева, так что причём тут список постов и сообщения, я
Не принимай близко к сердцу слова matumb-ы. У него всегда свое видение, не совпадающее с общечеловеческим.
В общем, забей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
_NN>>Вы наверное и почтой в стиле gmail не пользуетесь потому что там вообще сплошной JS ?
M>"Для игр у меня домино есть!" (с)околов M>А у меня для почты — Аутлюк + POP3.
Для остальных сайтов тоже хаки ?
Не знаю как вы, но я простой человек и люблю удобства.
С фреймворком можно сделать еще один вариант дерева без JS.
Если поможете, то RSDN будет возможно просматривать в вашем любимом браузере.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, VladD2, Вы писали: VD>>Не принимай близко к сердцу слова matumb-ы. У него всегда свое видение, не совпадающее с общечеловеческим.
M>"Общечеловеческое" — это когда треть экрана пустует? Ну-ну... походу чья-то матрица безвозвратно заражена ЧСВ.
http://ya.ru/
А тут вообще 90% экрана пустует, однако это не уменьшает пользы данного ресурса.
Дабы не захламлять ветку, предлагаю высказывать более конструктивные мысли.
Делать фичи ради фич мы не можем, у нас и так ограниченные ресурсы.
А если хотите помочь , то мы только рады.
M>Зашёл, увидел всего два "нормальных" тега — html и body, застрелился. M>Куда катится веб? Зачем нужны все эти жабоскрипты? Почему нельзя просто взять NCSA Mosaic и посмотреть RSDN?
Посмотри на успех всяких jquery, kendo и прочих и закопай наконец труп мозаика. Исходная разметка годилась только для убогого статического контента, а людям этого уже давно мало. Веб катится в светлое будущее где каждый пиксель будет реагировать на события и отображать состояния.
Здравствуйте, matumba, Вы писали:
I>>Помнится, Влад предлагал сделать на NemerleWeb новое дерево/меню для rsdn.ru. I>>Всё остальное генерируется фреймворком.
M>Зашёл, увидел всего два "нормальных" тега — html и body, застрелился. M>Куда катится веб? Зачем нужны все эти жабоскрипты? Почему нельзя просто взять NCSA Mosaic и посмотреть RSDN?
Он давно уже укатился. Это уже больше не HTML. Одно название осталось. Технология совсем другая. Поэтому и тегов знакомых не видите.
Вопрос, к лучшему или к худшему произошли эти изменения? По-моему, к лучшему.
Начнем со стилей. Оформление в стилях это уничтожение копипасты, the DRY principle. Даже тупоголовые юзеры ворда справляются: у них давно оформление переведено на стили. Неужели же разработчикам веба мозга не хватит понять весь профит стилевого оформления? (Подсказка: менять можно строго в одном месте, не надо искать все вхождения).
Теперь, когда стили реабилитированы, вернемся к скриптам. Да, во многих случаях достаточно одних стилей. См., например, CSSS!, или ту же карту метро, на которую недавно давали ссылку в соответствующем форуме. Во многих, но не во всех. Взаимодействие с сервером на стилях не построить. А без взаимодействия с сервером куда? Понадобилось, скажем, товар в корзину добавить — что, перегружать весь контент? А карты? С маршрутами, с вводом информации о пробках и так далее!
Меня поражает вот что: такие говноновшества, как, цитирую, «новомодные метро-плитки», у некоторых людей проходят нормально. Вопросов не вызывают. А технологии, которые реально работают, экономят трафик и процессорные ресурсы в мировом масштабе на, я не знаю, гигаватты и гигабаксы — до этого надо доковыряться. Причем, я и лично знаю такого человека. В голове такое извращение не укладывается.
Здравствуйте, matumba, Вы писали:
_NN>>Вы наверное и почтой в стиле gmail не пользуетесь потому что там вообще сплошной JS ?
M>"Для игр у меня домино есть!" (с)околов M>А у меня для почты — Аутлюк + POP3.
Попробуй последнюю версию Outlook OWA — шикарнейший веб, гуглу до него как до луны раком. Но как то вот Микрософт такой опты не хочет распространять и реюзать.
I>Попробуй последнюю версию Outlook OWA — шикарнейший веб, гуглу до него как до луны раком. Но как то вот Микрософт такой опты не хочет распространять и реюзать.
А с какого они должны распостранять?
Может вам еще и исходнички выдать?
Жирно не будет?
Здравствуйте, dr. Acula, Вы писали:
I>>Попробуй последнюю версию Outlook OWA — шикарнейший веб, гуглу до него как до луны раком. Но как то вот Микрософт такой опты не хочет распространять и реюзать.
DA>А с какого они должны распостранять? DA>Может вам еще и исходнички выдать? DA>Жирно не будет?
Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
Здравствуйте, Ikemefula, Вы писали:
I>Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
Ничего не понимаю. Какие такие технологии вам не выдала Microsoft? В OWA секретная технология ровно одна — XmlHttpRequest, но его "невыданным" я назвать никак не могу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала. S>Ничего не понимаю. Какие такие технологии вам не выдала Microsoft? В OWA секретная технология ровно одна — XmlHttpRequest, но его "невыданным" я назвать никак не могу.
Это не технология, а просто функция. Технологию на основе этого запроса двинул в массы Гугл, а Микрософт это как технологию вообще никак не рассматривал.
Здравствуйте, Ikemefula, Вы писали:
I>Попробуй последнюю версию Outlook OWA — шикарнейший веб, гуглу до него как до луны раком. Но как то вот Микрософт такой опты не хочет распространять и реюзать.
Весьма унылая среднестатистическая штука. Что в ней шикарного? Продукты Гугл в вебе на несколько порядков выше.
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Ikemefula, Вы писали:
I>>Попробуй последнюю версию Outlook OWA — шикарнейший веб, гуглу до него как до луны раком. Но как то вот Микрософт такой опты не хочет распространять и реюзать.
__>Весьма унылая среднестатистическая штука. Что в ней шикарного? Продукты Гугл в вебе на несколько порядков выше.
Ты видел последнюю версию OWA ? gmail сосёт не нагибаясь. Только OWA прикручена к Exchange, чего у обычных юзеров никогда не бывает.
Здравствуйте, Ikemefula, Вы писали:
I>Это не технология, а просто функция. Технологию на основе этого запроса двинул в массы Гугл, а Микрософт это как технологию вообще никак не рассматривал.
Брр. Так, для справки: эту технологию (т.е. AJAX) "в массы" двинул именно Microsoft. Пока нетскейп решали, как бы половчее написать новый браузер так, чтобы он не смог корректно отрендерить даже netscape.com, Майкрософт забабахал как XmlHttpRequest, так и первое в мире AJAX-приложение на его основе. Это и была, собственно, знаменитая OWA.
Если вы имеете под "движением в массы" евангелическую деятельность — типа раздачи образовательных программ и подготовки всяческих SDK, то роль гугла здесь не видна даже в микроскоп. Евангелизацией AJAX вообще занимались какие-то отдельные личности, я не припомню ни одной стоящей за этим корпорации. Если я ошибаюсь — расскажите.
И ещё хотелось бы всё-таки получить ответ на вопрос: какую именно "технологию", использованную в OWA, MS от вас скрывает?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Ты видел последнюю версию OWA ? gmail сосёт не нагибаясь. Только OWA прикручена к Exchange, чего у обычных юзеров никогда не бывает.
Прямо сейчас смотрю на owa, внутренняя почта на ней. А внешняя на гмайле. И что же в ней такого крутого? Где gmail "сосет" не нагибаясь? На мой взгляд обычное web application. Какие мегафичи вас так поразили в самое сердце?
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, Ikemefula, Вы писали:
I>>Ты видел последнюю версию OWA ? gmail сосёт не нагибаясь. Только OWA прикручена к Exchange, чего у обычных юзеров никогда не бывает. __>Прямо сейчас смотрю на owa, внутренняя почта на ней. А внешняя на гмайле. И что же в ней такого крутого? Где gmail "сосет" не нагибаясь? На мой взгляд обычное web application. Какие мегафичи вас так поразили в самое сердце?
Для начала ответь на вопрос — ты видел ПОСЛЕДНЮЮ версию Owa ?
Owa почти полностью повторяет десктопный интерфейс, что само по себе очень и очень удобно.
Скажем, давно у гмайл появился reading pane и дерево фолдеров ? А как сделать так, что бы gmail показывал всю почту в фолдере без страничного переключения ?
Где быстрый доступ к календарю и интеграция с ним ?
Где задачи и интеграция с ними ?
Контакты в гмайл это какая то насмешка относительно аутлука.
Или ты предлагаешь сравнивать оба проложения на основе того, как они умеют принимать и отсылать почту ? Так да, они абсолютно одинаковы.
Здравствуйте, Sinclair, Вы писали:
I>>Это не технология, а просто функция. Технологию на основе этого запроса двинул в массы Гугл, а Микрософт это как технологию вообще никак не рассматривал. S>Брр. Так, для справки: эту технологию (т.е. AJAX) "в массы" двинул именно Microsoft. Пока нетскейп решали, как бы половчее написать новый браузер так, чтобы он не смог корректно отрендерить даже netscape.com, Майкрософт забабахал как XmlHttpRequest, так и первое в мире AJAX-приложение на его основе. Это и была, собственно, знаменитая OWA.
Это было просто приложение сделаное инструментами изготовлеными на коленке и никак не технология.
S>Если вы имеете под "движением в массы" евангелическую деятельность — типа раздачи образовательных программ и подготовки всяческих SDK, то роль гугла здесь не видна даже в микроскоп. Евангелизацией AJAX вообще занимались какие-то отдельные личности, я не припомню ни одной стоящей за этим корпорации. Если я ошибаюсь — расскажите.
Евангелизм это не про то. Все что нужно — сделать хороший публичный продукт и продвигать инструменты для изготовления таких продуктов за счет экономической эффективности. Микрософт сделал публичнй продукт ? нет. Инструменты сделала ? Нет. Продвигала эти инструменты ? Нет.
S>И ещё хотелось бы всё-таки получить ответ на вопрос: какую именно "технологию", использованную в OWA, MS от вас скрывает?
Ajax в массы мог прийти еще в 2001м году наверное или даже раньше, а вместо этого микрософт толкало фронтпейдж, вебформы и hta, и в то же время остановила разработку браузера. Опаньки !
К тому времени, как появился gmail, про owa никто не знал, т.к.без exсhange это никому не интересно. Соответсвнно с выходом gmail и появился интерес к Ajax, и это быстро стало технологией а не просто мулькой в одном из приложений.
За Ajax микрософт ухватился наверное в 2008м году, вот тогда повились и инструменты и продвижение и тд и тд.
I>Евангелизм это не про то. Все что нужно — сделать хороший публичный продукт и продвигать инструменты для изготовления таких продуктов за счет экономической эффективности. Микрософт сделал публичнй продукт ? нет. Инструменты сделала ? Нет. Продвигала эти инструменты ? Нет.
Публичный продукт — Exchange. Вполне себе доступен, стандарт де факто для корпоративной почты.
Инструменты — XmlHttpRequest. Кто сделал? Microsoft. До этого никакого "AJAX" не могло существовать в природе.
Продвигала? Нет, не продвигала. И Гугл не продвигал. И сейчас не продвигает.
S>>И ещё хотелось бы всё-таки получить ответ на вопрос: какую именно "технологию", использованную в OWA, MS от вас скрывает?
I>Ajax в массы мог прийти еще в 2001м году наверное или даже раньше, а вместо этого микрософт толкало фронтпейдж, вебформы и hta, и в то же время остановила разработку браузера. Опаньки ! А какое отношение разработка браузера имеет к Ajax? И по-прежнему непонятно, что такого от вас скрывают. Профессионалу глупо ссылаться на отсутствие продвижки в массы. Документация по протоколу HTTP в открытом доступе была? Была. По HTML, СSS, JavaScript была? Была. По XmlHttpRequest и его аналогам была? Была.
Ну и чего ещё надо? Чтобы вам разжевали и в рот положили способ собрать всё это вместе?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Публичный продукт — Exchange. Вполне себе доступен, стандарт де факто для корпоративной почты. S>Инструменты — XmlHttpRequest. Кто сделал? Microsoft. До этого никакого "AJAX" не могло существовать в природе.
Не просто Microsoft, а команда OWA. В контексте обсуждение — самое то.
Здравствуйте, Sinclair, Вы писали:
S>Инструменты — XmlHttpRequest. Кто сделал? Microsoft. До этого никакого "AJAX" не могло существовать в природе.
Это не инструмент, это просто функция.
S> А какое отношение разработка браузера имеет к Ajax?
Очень просто — с древним браузером никакой аджакс не поможет. Именно по этому гугл стартовал хром.
> И по-прежнему непонятно, что такого от вас скрывают. Профессионалу глупо ссылаться на отсутствие продвижки в массы.
А где ты видишь в моем тексте: "от меня скрывают" ? Я пишу о том, что у микрософта веб-технлологии говно. Вместо нормального веба они толкали фронтпейдж, hta, вебформы и остановили разработку браузера. Собственно не надо удивляться что веб они потеряли.
> Документация по протоколу HTTP в открытом доступе была? Была. По HTML, СSS, JavaScript была? Была. По XmlHttpRequest и его аналогам была? Была.
Как думаешь, можно ли набор палок, досок и гвоздей считать табуреткой ?
S>Ну и чего ещё надо? Чтобы вам разжевали и в рот положили способ собрать всё это вместе?
Сколько баттхёрта из одной лишь фразы "Попробуй последнюю версию Outlook OWA — шикарнейший веб, гуглу до него как до луны раком. Но как то вот Микрософт такой опты не хочет распространять и реюзать."
Объясняю подробно — классный веб в микрософте умеет делать только OWA. Микрософт даже в своих других продуктах не в состояни сделать чтото похожее, что очевидно, все их веб-приложения тухлое унылое говно, которые то глючит, то падает и даже куки свои поднять не может.
То есть, опыт внутри микрософта не распространяется.
Соотственно незачем делать ставку на веб стек технологий от данной конторы. Они сами не умеют применять свои технологии.
Ну ладно, офис онлайн таки смогли Но это ничего не меняет.
Здравствуйте, Ikemefula, Вы писали:
I>Очень просто — с древним браузером никакой аджакс не поможет. Именно по этому гугл стартовал хром.
Предлагаю не обсуждать мотивы гугла при разработке хрома.
I>А где ты видишь в моем тексте: "от меня скрывают" ? Я пишу о том, что у микрософта веб-технлологии говно. Вместо нормального веба они толкали фронтпейдж, hta, вебформы и остановили разработку браузера. Собственно не надо удивляться что веб они потеряли.
Да, я вижу вот такую цитату:
Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
Может, я слово "выдала" неправильно понимаю? Вы тогда расшифруйте поподробнее.
I>Как думаешь, можно ли набор палок, досок и гвоздей считать табуреткой ?
Нет. Но я, как производитель табуреток, полностью счастлив как тем, что на рынке полно гвоздей, палок, и досок, а также тем, что нет монополиста, который бы давил меня своими табуретками.
I>Объясняю подробно — классный веб в микрософте умеет делать только OWA. Микрософт даже в своих других продуктах не в состояни сделать чтото похожее, что очевидно, все их веб-приложения тухлое унылое говно, которые то глючит, то падает и даже куки свои поднять не может. I>То есть, опыт внутри микрософта не распространяется.
Полностью согласен.
I>Соотственно незачем делать ставку на веб стек технологий от данной конторы. Они сами не умеют применять свои технологии.
А вот этот вывод совершенно неожиданный. У них стек как раз очень хороший, и чем глубже — тем лучше. А то, что у них в прикладном секторе архитектурой и реализацией занимаются какие-то недоумки, это как раз хорошо. I>Ну ладно, офис онлайн таки смогли Но это ничего не меняет.
Это меняет ровно всё. Это показывает, что на платформе МС можно делать конфетки. А также то, что способных это делать — мало, значит можно очень неплохо монетизировать свой экспириенс.
Настояший профессионал везде найдёт преимущество. Мало евангелизма современных веб-технологий — прекрасно: ниже конкуренция, выше стоимость продукта. Много евангелизма современных веб-технологий — ещё лучше: больше образованных потребителей, способных отличить gmail от OWA — рост продаж.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Очень просто — с древним браузером никакой аджакс не поможет. Именно по этому гугл стартовал хром. S>Предлагаю не обсуждать мотивы гугла при разработке хрома.
А вот JS в Web вобщем требует такого обсуждения.
I>>А где ты видишь в моем тексте: "от меня скрывают" ? Я пишу о том, что у микрософта веб-технлологии говно. Вместо нормального веба они толкали фронтпейдж, hta, вебформы и остановили разработку браузера. Собственно не надо удивляться что веб они потеряли. S>Да, я вижу вот такую цитату: S>
S>Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
S>Может, я слово "выдала" неправильно понимаю? Вы тогда расшифруйте поподробнее.
Очевидно, не правильно. Представь себе, ты хочешь что бы я выдал Башара Асада. Очевидно, я этого не могу. Но при этом, отсюда не следует, что я скрываю этого Башара Асада.
I>>Соотственно незачем делать ставку на веб стек технологий от данной конторы. Они сами не умеют применять свои технологии. S>А вот этот вывод совершенно неожиданный. У них стек как раз очень хороший, и чем глубже — тем лучше. А то, что у них в прикладном секторе архитектурой и реализацией занимаются какие-то недоумки, это как раз хорошо. I>>Ну ладно, офис онлайн таки смогли Но это ничего не меняет. S>Это меняет ровно всё. Это показывает, что на платформе МС можно делать конфетки. А также то, что способных это делать — мало, значит можно очень неплохо монетизировать свой экспириенс.
Как минимум есть второй вариант — можно, но крайне сложно, настолько, что в самом Микрософте на это способны около двух команда — OWA и Office Online или как она там называется.
S>Настояший профессионал везде найдёт преимущество. Мало евангелизма современных веб-технологий — прекрасно: ниже конкуренция, выше стоимость продукта. Много евангелизма современных веб-технологий — ещё лучше: больше образованных потребителей, способных отличить gmail от OWA — рост продаж.
Выше стоимость продукта — значит многие продукты не смогут переступить этот порог. Это значит, что ты будешь инвестировать время не пойми во что и никакого выхлопа за это не получишь. Скажем, люди которые инвестировали время в SL сейчас учатся заново, потому что мобайл прошел мимо SL. Люди которые инвестировали время в webForms, учатся заново, веб прошел мимо webforms. Люди которые инвестировали время в IE снова учатся заново. Те кто инвестировал время в IIS, обратно учатся заново.
Для сравнения, люди которые 10 лет назад инвестировали время в JS,Python, Ruby, Java, Apache до сих пор накапливают опыт, опаньки !
Здравствуйте, Ikemefula, Вы писали:
I>Для начала ответь на вопрос — ты видел ПОСЛЕДНЮЮ версию Owa ?
Еще раз — видел и смотрю на нее 2-3 раза в день.
I>Owa почти полностью повторяет десктопный интерфейс, что само по себе очень и очень удобно.
Мне не удобно. Мне нужен простой удобный интерфейс под задачу работы c email вместо кучи бесполезных наваленных кнопочек и закладок.
I>Скажем, давно у гмайл появился reading pane и дерево фолдеров ? А как сделать так, что бы gmail показывал всю почту в фолдере без страничного переключения ?
Мне это все не нужно. У меня нет времени чтобы щелкать по всем этим бесконечным фолдерам в поисках чего важного. Я ценю простой последовательный интерфейс.
I>Где быстрый доступ к календарю и интеграция с ним ?
Календарь открывается одной кнопкой. По поводу интеграции не скажу, не пользовался ни разу (да и зачем, это вредно и может быть опасно).
I>Где задачи и интеграция с ними ?
На черта мне это? Мне нужно с email работать
I>Контакты в гмайл это какая то насмешка относительно аутлука.
По мне так autocomplite работает прекрасно. А большего мне и не требуется.
I>Или ты предлагаешь сравнивать оба проложения на основе того, как они умеют принимать и отсылать почту ? Так да, они абсолютно одинаковы.
Я предлагаю вам взглянуть на эти приложения с точек зрения: usability, integration with devices, технического качества web app.
Здравствуйте, a_g_99, Вы писали:
I>>Owa почти полностью повторяет десктопный интерфейс, что само по себе очень и очень удобно. __>Мне не удобно. Мне нужен простой удобный интерфейс под задачу работы c email вместо кучи бесполезных наваленных кнопочек и закладок.
Как выясняется, тебе нужны функции приём и отсылки почты.
I>>Скажем, давно у гмайл появился reading pane и дерево фолдеров ? А как сделать так, что бы gmail показывал всю почту в фолдере без страничного переключения ? __>Мне это все не нужно. У меня нет времени чтобы щелкать по всем этим бесконечным фолдерам в поисках чего важного. Я ценю простой последовательный интерфейс.
Опаньки !
I>>Где быстрый доступ к календарю и интеграция с ним ? __>Календарь открывается одной кнопкой. По поводу интеграции не скажу, не пользовался ни разу (да и зачем, это вредно и может быть опасно).
Опаньки !
I>>Где задачи и интеграция с ними ? __>На черта мне это? Мне нужно с email работать
Опаньки !
I>>Контакты в гмайл это какая то насмешка относительно аутлука. __>По мне так autocomplite работает прекрасно. А большего мне и не требуется.
Опаньки !
I>>Или ты предлагаешь сравнивать оба проложения на основе того, как они умеют принимать и отсылать почту ? Так да, они абсолютно одинаковы. __>Я предлагаю вам взглянуть на эти приложения с точек зрения: usability, integration with devices, технического качества web app.
Все это сравнивается в зависимости от потребностей. У тебя их около нуля, т.е. "ты предлагаешь сравнивать оба проложения на основе того, как они умеют принимать и отсылать почту"
...пустопорожние слова поскипаны...
SV.> Понадобилось, скажем, товар в корзину добавить — что, перегружать весь контент?
Можно и перегрузить. Разве вас кто-то тянет за хвост тащить ВЕСЬ контент магазина на одну страницу? Пусть на главной будут товары, а в отдельном (простом как тапок) окне — корзинка с товарами (занимающая от силы 2-5 кб).
Как видите, сделать приложение не составляет труда, просто хомячкам с недельным курсом HTML+JS промыли мозги и они думают, что делают хорошие программы.
SV.> А карты? С маршрутами, с вводом информации о пробках и так далее!
А зачем карты на HTML-ной странице? Совсем чтоль с ума посходили? Для карт нужна производительность + как можно более "нативный" интерактив (скажем, если у яблофилов нет ПКМ, для них нужно придумывать свой отдельный интерфейс). ЛЮБАЯ программа работает намного лучше, будучи написанной специально для конкретной ОС. То, что ленивая тварь за моником не хочет два раза писать код — это её проблемы. Но HTML+JS не победил мир, скорее наоборот — после браузерной горячки народ чешет хлюпало "чё ж мы такое писали?". Даже гугл с маньячной фобией мелкомягких технологий, и то не стал делать ведроид на хвалёных HTML/CSS/JS — там кругом Жаба. Дураки наверное, да?
Здравствуйте, matumba, Вы писали:
SV.>> Понадобилось, скажем, товар в корзину добавить — что, перегружать весь контент?
M>Можно и перегрузить. Разве вас кто-то тянет за хвост тащить ВЕСЬ контент магазина на одну страницу? Пусть на главной будут товары, а в отдельном (простом как тапок) окне — корзинка с товарами (занимающая от силы 2-5 кб). M>Как видите, сделать приложение не составляет труда, просто хомячкам с недельным курсом HTML+JS промыли мозги и они думают, что делают хорошие программы.
А вот юзеру категорически не нравится это отдельное окно. Ему нравится что бы окон было поменьше. Нажал кнопку — иконка с корзиной поменялась и это должно произойти как можно быстрее, без перегрузки страницы, без показа новых окошек и желательно чем быстрее.
M>Но HTML+JS не победил мир, скорее наоборот — после браузерной горячки народ чешет хлюпало "чё ж мы такое писали?". Даже гугл с маньячной фобией мелкомягких технологий, и то не стал делать ведроид на хвалёных HTML/CSS/JS — там кругом Жаба. Дураки наверное, да?
Операционную систему не стал делать на html/css ? И правильно. Зато целый класс приложений пишется именно на HTML/CSS/JS и ты про это даже не подозреваешь.
Здравствуйте, Ikemefula, Вы писали:
M>>Можно и перегрузить. Разве вас кто-то тянет за хвост тащить ВЕСЬ контент магазина на одну страницу? Пусть на главной будут товары, а в отдельном (простом как тапок) окне — корзинка с товарами (занимающая от силы 2-5 кб).
I>А вот юзеру категорически не нравится это отдельное окно. Ему нравится что бы окон было поменьше.
В теории — согласен. На практике в худшем случае мы имеем ДВА окна, одно из которых настолько второстепенное, что можно вообще не париться по его поводу (см. объяснение ниже).
I> Нажал кнопку — иконка с корзиной поменялась и это должно произойти как можно быстрее
Ага. И желательно с индикацией того, что после клика браузер занят отсылкой запроса из жабоскрипта, чего НИКОГДА НЕ ВИДНО и задержка ВСЁ РАВНО ЕСТЬ. Это самая раздражающая особенность браузоперделок — отсутствие ответной реакции.
I> ...без перегрузки страницы, без показа новых окошек и желательно чем быстрее.
Это видение программиста-затейника, который думает, что весь мир крутится вокруг его опупительных fade-эффектов и глубоких познаний node.js; Я делал покупки раз 30 наверное (достаточно, чтобы судить) и моё поведение на сайте далеко от той "игры", которую пытается изобразить горе-дизайнер-маркетолог. Обычно у меня уже есть представление, что я хочу купить, в 99% случаев вплоть до названия модели. Далее:
1. Рыщу по прайсам в поисках дешёвого товара. Если товаров несколько, ищу магаз, где все они есть. Захожу по прямой ссылке на страницу товара.
2. долбаная регистрация, сделаная недотумками по шаблонам других недотумков — вот здесь бы применить ваш интеллект!
3. После логина заново ищу товар, сравниваю цену с каталожной, добавляю товар в корзину. Далее, внимание:
4. МНЕ ПОФИГ, ЧТО У МЕНЯ В КОРЗИНЕ, веришь? Я не тупой, я только что положил туда один товар и я знаю — он там! Хочется верить, что ты тоже сейчас осознал всю глубину бесполезности "корзиночных красот". Особенно если браузер чётко показал смену страниц (а не скрытных жабо-пересылок) и просто уведомил меня текстом "товар добавлен" вверху страницы.
5. Ищу остальные товары, добавляю в корзину аналогично — кнопкой "add" со страницы самого товара — понял, почему выделено? Потому что см. п.4 — мне НЕ НУЖНА корзина, чтобы добавить туда товар! Как не нужна вообще при поиске товара.
6. Бывает, добавляешь товар и вдруг обращаешь внимание, что есть аналогичный товар со скидкой — ВОТ ТЕПЕРЬ я хочу посмотреть корзинку и выкинуть лишний товар. Причём мне НЕ ВАЖНО держать перед глазами каталог, рекламу и т.п. — я открываю в отдельном окне корзину, быстро удаляю товар, корзину закрываю — возвращаюсь в своё рабочее окно с другими товарами и опять п.5; Всё равно, что вызов подпрограммы — мне не нужен текст подпрограммы постоянно перед глазами — достаточно просто иметь возможность её вызвать.
7. Я завершил подборку, check out! ТОЛЬКО СЕЙЧАС мне неплохо бы взглянуть, чего я там понабрал и конечную сумму/доставку/оплату и т.п.
Другими словами, корзина нужна ОДИН ЕДИНСТВЕННЫЙ РАЗ — при выписке! (и ещё один раз ЕСЛИ решил изменить заказ)
Давай, расскажи мне теперь, какой я неблагодарный неоценитель "суперфрэйма суперкорзины на жабоскриптах и аяхах"!
M>>Но HTML+JS не победил мир, скорее наоборот — после браузерной горячки народ чешет хлюпало "чё ж мы такое писали?". Даже гугл с маньячной фобией мелкомягких технологий, и то не стал делать ведроид на хвалёных HTML/CSS/JS — там кругом Жаба. Дураки наверное, да?
I>Операционную систему не стал делать на html/css ? И правильно. Зато целый класс приложений пишется именно на HTML/CSS/JS и ты про это даже не подозреваешь.
Не умничай, видел я и HTML-ные поделки Ключевая мысль: "не стали ПОЛНОСТЬЮ ПОЛАГАТЬСЯ на гипертекстовый жабоскрипт". И я их понимаю — не только сам жабоскрипт маразматичен и анти-мэйнстримен по своей сути, но и идея натягивать гипертекст, имитируя rich GUI — ущербна. Как результат, мы имеем мириад страниц-перделок, то криво работающих, то не работающих вообще, то работающих неочевидно (см. задержки отсылки запросов), а то и до полного позорища всего веб-дизайна — "Ваша Опера не поддерживается нашим сайтом!". О как! Это _я_ оказывается виновен, что их чудо-дизайнер не умеет писать код!
Короче, без жабоскриптов ЖИЛИ и могли бы жить дальше, сохраняя функциональность ВО ВСЕХ БРАУЗЕРАХ СРАЗУ. Но одна компания, имя которой не хочу называть, раздула несовместимость, базирующуюся на жабоскрипте, чем сразу обоср**ла всю идею _стандартного_ веба. А хомячки и рады, повелись на "вау-эффекты", разучившись даже толком передавать запросы в СУБД. Поверьте, жабоскрипт — это самое тяжёлое ИТ-преступление. После похапэ, конечно.
Здравствуйте, matumba, Вы писали:
I>>А вот юзеру категорически не нравится это отдельное окно. Ему нравится что бы окон было поменьше.
M>В теории — согласен. На практике в худшем случае мы имеем ДВА окна, одно из которых настолько второстепенное, что можно вообще не париться по его поводу (см. объяснение ниже).
I>> Нажал кнопку — иконка с корзиной поменялась и это должно произойти как можно быстрее
M>Ага. И желательно с индикацией того, что после клика браузер занят отсылкой запроса из жабоскрипта, чего НИКОГДА НЕ ВИДНО и задержка ВСЁ РАВНО ЕСТЬ. Это самая раздражающая особенность браузоперделок — отсутствие ответной реакции.
Это проблема медленных сайтов. И это лучше, чем показ второго окна.
I>> ...без перегрузки страницы, без показа новых окошек и желательно чем быстрее.
M>Это видение программиста-затейника, который думает, что весь мир крутится вокруг его опупительных fade-эффектов и глубоких познаний
Это азы UI. Пользователя бесят перегрузки страницы, показы новых окошек и медленная работа.
>node.js; Я делал покупки раз 30 наверное (достаточно, чтобы судить) и моё поведение на сайте далеко от той "игры", которую пытается изобразить горе-дизайнер-маркетолог. Обычно у меня уже есть представление, что я хочу купить, в 99% случаев вплоть до названия модели.
Тебя можно вообще не рассматривать всерьез. Типичный юзер вообще мало чего понимает, что происходит, что он делает и тд. Потому он отриентируется на сайте совсем не так как ты, и для него нужен другой UI, не такой как для тебя.
Твой конкретный сценарий никому, кроме тебя, не интересен.
M>Другими словами, корзина нужна ОДИН ЕДИНСТВЕННЫЙ РАЗ — при выписке! (и ещё один раз ЕСЛИ решил изменить заказ)
Корзина должна быть видна постоянно, независимо о того, где находится юзер, и отображать хотя бы сумму товаров. Просто потому, что слишком много людей ориентируются именно исходя из этой суммы.
I>>Операционную систему не стал делать на html/css ? И правильно. Зато целый класс приложений пишется именно на HTML/CSS/JS и ты про это даже не подозреваешь.
M>Не умничай, видел я и HTML-ные поделки
Надо полагать при покупке приложения тебе дают и весь код
>Ключевая мысль: "не стали ПОЛНОСТЬЮ ПОЛАГАТЬСЯ на гипертекстовый жабоскрипт". И я их понимаю — не только сам жабоскрипт маразматичен и анти-мэйнстримен по своей сути, но и идея натягивать гипертекст, имитируя rich GUI — ущербна.
Наоборот.
M>Короче, без жабоскриптов ЖИЛИ и могли бы жить дальше, сохраняя функциональность ВО ВСЕХ БРАУЗЕРАХ СРАЗУ.
Ну да, вместо ожидания запроса ожидали в десять раз больше — перегрузку страницы и тд и тд.
У меня сильное ощущение, что ты веб видел последний раз году в 2000.
Здравствуйте, Ikemefula, Вы писали:
M>>Ага. И желательно с индикацией того, что после клика браузер занят отсылкой запроса из жабоскрипта, чего НИКОГДА НЕ ВИДНО и задержка ВСЁ РАВНО ЕСТЬ. Это самая раздражающая особенность браузоперделок — отсутствие ответной реакции.
I>Это проблема медленных сайтов.
Месье слышал что-нибудь о скорости передачи информации? Ну, там, "кибибиты", "ебибуты"... Построй сайт хоть на оптических ЦПУ, по сети всё равно надо передавать информацию, что заведомо дольше, чем реакция человека "нажал — ничего не видно".
I>И это лучше, чем показ второго окна.
Не факт, просто ваше личное мнение. Я уже объяснил ранее — корзину ВООБЩЕ НЕ НАДО ВИДЕТЬ. В крайнем случае — сойдёт и попап с беглым просмотром содержимого.
M>>Это видение программиста-затейника, который думает, что весь мир крутится вокруг его опупительных fade-эффектов и глубоких познаний
I>Это азы UI. Пользователя бесят перегрузки страницы, показы новых окошек и медленная работа.
Забавно... ВЕСЬ ТЫРНЕТ — это сплошная перезагрузка страниц, что здесь может быть раздражающего? Нажал — получил документ по ссылке, это норма. Медленная работа — увы, чаще некомпетентность веб-писакакателей, чем объективная необходимость. Вот было бы поменьше всяких "градиентиков-жабоскриптиков", тырнет стал бы намного чище и быстрее.
I>Потому он отриентируется на сайте совсем не так как ты, и для него нужен другой UI, не такой как для тебя.
Во время покупки, от того, что я знаю внутреннюю кухню, мне ни жарко, ни холодно — покупаю как все, без хаков Так что не надо тут из меня изображать изгоя, я такой же средний юзер.
M>>Другими словами, корзина нужна ОДИН ЕДИНСТВЕННЫЙ РАЗ — при выписке! (и ещё один раз ЕСЛИ решил изменить заказ)
I>Корзина должна быть видна постоянно... Просто потому, что слишком много людей ориентируются именно исходя из этой суммы.
Возможно, сейчас я слышу опыт продавца женского белья, потому что только подобная категория сначала набирает полные руки шмотья, а потом решает "купить-не купить". И ДАЖЕ В ЭТОМ случае "загляд в корзину" — не более, чем вопрос "а не много ли я набрала?". Поиск и чтение описаний товаров занимает НАМНОГО большее время, чем собственно копание в белье набраных товарах.
M>>Короче, без жабоскриптов ЖИЛИ и могли бы жить дальше, сохраняя функциональность ВО ВСЕХ БРАУЗЕРАХ СРАЗУ. I>Ну да, вместо ожидания запроса ожидали в десять раз больше — перегрузку страницы и тд и тд.
Месье полагает, что сделать запрос на сервер из жабоскрипта — это волшебным образом в 10 раз быстрее того же браузера? Спешу вас огорчить, это всё тот же самый механизм HTTP. Да, данных передаётся меньше, но оптимизация "когда-что-кому" передавать — это и есть "правильная структура сайта".
Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML, не вызывая попаболь тысяч юзеров "нестандартных" браузеров позади всяких "фильтров рекламы". И уж конечно, для меня намного приятнее "перегрузить страницу", подтверждая результат моих действий, чем ждать долбаные скрипты — то ли зависли, то ли вообще сломались, то ли сеть рухнула, то ли сервер тормозит.... я наелся ваших аяксов по самые гланды — СПАСИБО, НЕ НАДО.
I>У меня сильное ощущение, что ты веб видел последний раз году в 2000.
Не последний, но видимо раньше вас — я начинал в 93-м, когда 2 КБ/с считался "хороший коннект" и трафик не разбазаривали на "стразики". Да и дизайнеры были более профессиональные — у нас не было страниц по 500КБ только чтобы показать профайл юзера. Учитесь, господа!
Здравствуйте, matumba, Вы писали:
M>Ага. И желательно с индикацией того, что после клика браузер занят отсылкой запроса из жабоскрипта, чего НИКОГДА НЕ ВИДНО и задержка ВСЁ РАВНО ЕСТЬ. Это самая раздражающая особенность браузоперделок — отсутствие ответной реакции.
Непонятен источник ненависти. Никакого отношения к браузерности эта особенность не имеет — я видел вполне себе десктопные приложения, в которых авторы забыли сделать какую-либо индикацию прогресса сетевого обмена, который выполняется в фоновом потоке. А заодно и забили на обработку ошибок — поэтому когда их чудесный XML-RPC таймаутится, приложение это никак не обрабатывает и ничего не говорит.
Это что, как-то бросает тень на десктопные приложения? Нет, это бросает тень на криворуких программистов.
M>Это видение программиста-затейника, который думает, что весь мир крутится вокруг его опупительных fade-эффектов и глубоких познаний node.js; Я делал покупки раз 30 наверное (достаточно, чтобы судить) и моё поведение на сайте далеко от той "игры", которую пытается изобразить горе-дизайнер-маркетолог.
Фейд-эффекты совершенно ни при чём.
M>Обычно у меня уже есть представление, что я хочу купить, в 99% случаев вплоть до названия модели. Далее: M>1. Рыщу по прайсам в поисках дешёвого товара. Если товаров несколько, ищу магаз, где все они есть. Захожу по прямой ссылке на страницу товара. M>2. долбаная регистрация, сделаная недотумками по шаблонам других недотумков — вот здесь бы применить ваш интеллект!
Зачем вам здесь регистрация? M>3. После логина заново ищу товар, сравниваю цену с каталожной, добавляю товар в корзину.
Зачем вы заново ищете товар? Все приличные веб-магазины после sign-in оставляют вас на той же странице, где вы были до этого.
M>Далее, внимание: M>4. МНЕ ПОФИГ, ЧТО У МЕНЯ В КОРЗИНЕ, веришь? Я не тупой, я только что положил туда один товар и я знаю — он там!
Понятно, что вы покупаете один товар. Непонятно, почему вы думаете, что все остальные действуют также. Вот, например, моя жена обычно заказывает от 5 до 15 вещей.
M>Хочется верить, что ты тоже сейчас осознал всю глубину бесполезности "корзиночных красот". Особенно если браузер чётко показал смену страниц (а не скрытных жабо-пересылок) и просто уведомил меня текстом "товар добавлен" вверху страницы.
Непонятное желание. Ну, то есть про текст — понятно. Непонятно, зачем вместо фоновой асинхронной операции добавки в корзинку вы хотите полной перегрузки страницы, которая будет на порядок медленнее. Кроме того, добавление текста "товар добавлен" прямо в тело страницы означает, что никакого кэширования в каталоге допускать нельзя. Отлично, вы только что понизили отзывчивость сайта ещё на порядок. Кроме того, асинхронный запрос колбасит себе и колбасит, вы можете продолжать пользоваться сайтом — например, добавлять другие товары. А с вашей идеей "полной перезагрузки" придётся терпеливо ждать, пока дососётся весь контент. Который вам, естественно, уже не нужен — вы же ведь и так знаете, что за товар только что добавили. Зачем вам заново рисовать всю страницу деталей для этого товара? Все эти "отзывы" и "с этим товаром часто покупают Камасутру для Чайников", которые вы без сомнения прочитали ещё до нажатия кнопки "Add".
M>5. Ищу остальные товары, добавляю в корзину аналогично — кнопкой "add" со страницы самого товара — понял, почему выделено? Потому что см. п.4 — мне НЕ НУЖНА корзина, чтобы добавить туда товар! Как не нужна вообще при поиске товара.
Да, именно так и работают все современные ajax-магазины. Баттхёрт откуда?
M>6. Бывает, добавляешь товар и вдруг обращаешь внимание, что есть аналогичный товар со скидкой — ВОТ ТЕПЕРЬ я хочу посмотреть корзинку и выкинуть лишний товар. Причём мне НЕ ВАЖНО держать перед глазами каталог, рекламу и т.п. — я открываю в отдельном окне корзину, быстро удаляю товар, корзину закрываю — возвращаюсь в своё рабочее окно с другими товарами и опять п.5; Всё равно, что вызов подпрограммы — мне не нужен текст подпрограммы постоянно перед глазами — достаточно просто иметь возможность её вызвать.
Да, именно так и работают все современные ajax-магазины. Баттхёрт откуда?
M>7. Я завершил подборку, check out! ТОЛЬКО СЕЙЧАС мне неплохо бы взглянуть, чего я там понабрал и конечную сумму/доставку/оплату и т.п.
M>Не умничай, видел я и HTML-ные поделки Ключевая мысль: "не стали ПОЛНОСТЬЮ ПОЛАГАТЬСЯ на гипертекстовый жабоскрипт". И я их понимаю — не только сам жабоскрипт маразматичен и анти-мэйнстримен по своей сути, но и идея натягивать гипертекст, имитируя rich GUI — ущербна.
Это как раз нормальная идея. Идея строить rich GUI из "кирпичиков" окон с их Window Proc и Message Queue — вот это истинный маразм. Он подходит только для приложений, рассчитанных на фиксированное разрешение, фиксированные размеры окна, и фиксированную локализацию. Все современные rich-GUI фреймворки безуспешно пытаются воспроизвести модель layout-ов, встроенную в HTML.
M>Как результат, мы имеем мириад страниц-перделок, то криво работающих, то не работающих вообще, то работающих неочевидно
Ну, если вам хочется поговорить о плохих веб-приложениях, то почему бы не поговорить о десктопных ентерпрайз-приложениях? Вот уж где трэш, угар, и содомия. Потому, что никакая технология сама по себе не спасает мир. Обязанность спасти мир лежит на разработчике, и если в голове — бардак, то и в приложении будет бардак. Независимо от платформы.
M>Короче, без жабоскриптов ЖИЛИ и могли бы жить дальше, сохраняя функциональность ВО ВСЕХ БРАУЗЕРАХ СРАЗУ.
Хреновую, прямо скажем, функциональность. Полная перезагрузка страниц и недружелюбность к кэшированию — это не то, за что потребитель будет голосовать рублём.
Но одна компания, имя которой не хочу называть, раздула несовместимость, базирующуюся на жабоскрипте, чем сразу обоср**ла всю идею _стандартного_ веба. А хомячки и рады, повелись на "вау-эффекты", разучившись даже толком передавать запросы в СУБД. Поверьте, жабоскрипт — это самое тяжёлое ИТ-преступление. После похапэ, конечно.
Да ну. В джаваскрипте только пара мелких преступлений — авто-; и несимметричное авто-приведение типов. Идеологически он — лучшее, что случилось с вебом со времён HTTP 1.1.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Похоже у вас есть супер концепция онлайн магазинов нового поколения.
Работать будет лучше , быстрее и удобнее.
Можете попробовать сделать эскиз и узнать действительно ли всем это удобнее.
Потому как если удобно будет исключительно вам, то этот рынок слишком мал, чтобы под него прогибаться.
Здравствуйте, _NN_, Вы писали:
_NN>Похоже у вас есть супер концепция онлайн магазинов нового поколения.
Ровно наоборот — идея старше жабоскрипта, но работает для всех и работает хорошо. Достаточно посмотреть в любой магазин, созданый без JS.
_NN>Работать будет лучше , быстрее и удобнее.
Именно. Браузер — это не просто "рамки, через которые мы глядим в Сеть" — весь его интерфейс должен помогать сёрфингу. И в частности, индикатор "загрузка данных" — категорически необходимая вещь, которая прекрасно работает на "простом HTML" и просто бесполезна при жабоскриптовых подковёрных манипуляциях. И это я не говорю просто об ошибках JS-ваятелей — понять их невозможно ("variable zzyyxx doesn't contain method buy"), иногда ошибки не видно вообще (и при этом ничего не работает), какого чёрта?? На серверной стороне могут хотя бы получить под зад иксепшыном и протрэйсить его в логах, а на клиентской стороне — кто будет отлаживать весь этот жабопонос? Очевидно же, у прогера стоит тройка популярных браузеров последних версий и ему пофиг, что у тебя IE 5 — никто не будет тестировать все версии всех браузеров во всех конфигах.
_NN>Можете попробовать сделать эскиз и узнать действительно ли всем это удобнее.
"попробовать сделать" — это целая серьёзная задача, вряд ли моё свободное время стоит на неё тратить. Общий посыл прост — в зад жабоскрипты, да здравствует простой HTML.
_NN>Потому как если удобно будет исключительно вам, то этот рынок слишком мал, чтобы под него прогибаться.
Ну да, я же какую-то экзотику прошу — чтобы просто ВСЁ И ВЕЗДЕ РАБОТАЛО!
Да я вам прямо сейчас выкачу ошибку на этом же сайте RSDN: сижу в Опере 12.15, форумные сообщения вижу в виде 10 строк вверху. Ниже идёт IFRAME, в который загружаются сами сообщения. Так вот: когда какое-то сообщение загружено, его высота — ТОЛЬКО ПОЛОВИНА свободного пространства, т.е. заняты сверху треть и снизу треть. Но при этом нельзя увеличить IFRAME! Почему? Да просто кто-то глупый и ленивый впендюрил туда жабоскрипт, делающий автовысоту по каким-то неведомым калькуляциям и не протестировал это в Опере. Вопрос: зачем козе баян? Зачем вообще этот "мастер" полез жабописакать, если его контора не может себе позволить всестороннее тестирование? И ТАК ВЕЗДЕ! (я про интернет-шопы) Никто и никогда не напрягается на тщательные тесты. У шэфа в IE работает? Значит всё отлично! Будь это "простой HTML", и ошибки было бы найти намного легче, и работало бы не в "избранных" (КЕМ?) браузерах, а вообще в любых приложениях, мало-мальски работающих с гипертекстом. Кстати, бурлящий сейчас мобильный сегмент как раз тот самый случай, когда экономия на всяких жабоскриптах позволила бы писать крохотные, маложрущие браузеры с парсером уровня BBcode и его бы хватало за глаза (по кр. мере для тривиальщины типа веб-магаза).
Здравствуйте, matumba, Вы писали:
M>Ну да, я же какую-то экзотику прошу — чтобы просто ВСЁ И ВЕЗДЕ РАБОТАЛО!
С точки зрения бизнеса это совершенно неинтересно.
Если что-то не работает у 1% пользователей, а стоимость высока, то никому это не нужно.
Так везде.
M> Будь это "простой HTML", и ошибки было бы найти намного легче, и работало бы не в "избранных" (КЕМ?) браузерах, а вообще в любых приложениях, мало-мальски работающих с гипертекстом.
Да ну. Тот же HTML5 взять только теги, и уже не во всех браузерах работает.
Или CSS3.
Уже не работает везде, и заметьте никакого JS.
Юзабилити никак не связано с наличием или отсутствием JS.
Ровно как и количество данных передаваемых по сети.
Можно сделать сайт с JS который передает данных на порядок меньше чем сайт без JS.
В настольных приложениях нет JS, однако это не делает их более удобными или менее удобными.
Все зависит от приложения, а не только технологий.
P.S.
Кстати как вы без JS делаете чат ?
Заставляете перегружать страницу каждую секунду ?
Здравствуйте, _NN_, Вы писали:
_NN>Кстати как вы без JS делаете чат ? _NN>Заставляете перегружать страницу каждую секунду ?
Зачем? Что-то вроде long-polling только потихонечку льются сообщения чата, скажем во фрейм.
Другой фрейм — обычная форма. Раньше так делали. Хотя схема перегружать раз в секунду была по моему более популярна. =)
Но JS всё равно лишним не будет.
Здравствуйте, _NN_, Вы писали:
M>>Ну да, я же какую-то экзотику прошу — чтобы просто ВСЁ И ВЕЗДЕ РАБОТАЛО! _NN>С точки зрения бизнеса это совершенно неинтересно.
Согласен. Гораздо интереснее "заказать" _NN_'а и отнять у него все деньги, все 200 баксов. Только... причём тут это? Мне не интересны соображения тех, кто изображает из себя пизнесмена, мне интересна ТЕХНИЧЕСКАЯ часть, поэтому я пришёл на RSDN, а не вконтактик.
_NN>Если что-то не работает у 1% пользователей, а стоимость высока, то никому это не нужно.
Если какая-то технология используется только потому, что кто-то раздул пузырь и при этом страдают юзеры, в &^$#&$#у такую технологию.
Не надо никого специально поддерживать — для этого уже постарались дедушки из W3C — чтобы У ВСЕХ было хорошо!
_NN>Да ну. Тот же HTML5 взять только теги, и уже не во всех браузерах работает.
К чему эти передёргивания? Вы правда думаете, что этой лажей можно меня сбить с толку? HTML 3.0 — бери и юзай.
_NN>Юзабилити никак не связано с наличием или отсутствием JS.
Связано и напрямую. Невозможно огранить алмаз напильником, поэтому технологии — не единственная, но решающая вещь. Читайте внимательно коммент про "прогресс загрузки".
_NN>В настольных приложениях нет JS, однако это не делает их более удобными или менее удобными.
Зачем опять уводить разговор в сторону? А Путина не хотите обсудить? Хочется поупражняться — сходите на митинг.
_NN>Кстати как вы без JS делаете чат ?
Невнимательно читаете: "Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML".
Здравствуйте, _NN_, Вы писали:
_NN>Кстати как вы без JS делаете чат ?
Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере?
"Мобил-дебилизация" привела к тому, что сначала применяют не то и не там, подставляют костыли, а потом винят тех же браузописак, неспособных сделать всё красиво и у всех.
Вдвойне смешно смотреть на все эти прыжки в браузерах зная, что 99% людей сидят в своей вендюшечке и никуда с неё не собираются. Ну так и напиши WPF приложение, всем будет радость и главное — это будет красивое, нативное приложение с полным использованием низлежащей инфраструктуры (диск, мышь, USB-устройства и т.п.).
Одна жертва "мобилизации" уже поплатилась за свою Windows 8, ждём остальных, кому чужие грабли не урок!
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
_NN>>Кстати как вы без JS делаете чат ?
M>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере?
Потому что браузер есть везде.
Получается по вашему, браузеры как бы и не так уж нужны ?
Пусть каждая программа работает по своему протоколу и использует свой собственный язык разметки и вообще делает все что хочет.
Подозреваю, такая ситуация была изначально.
Странно что эта концепция не выжила
Здравствуйте, _NN_, Вы писали:
M>>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере? _NN>Потому что браузер есть везде.
Ответ неверный.
Выбор платформы, инструментов и прочего должен основываться на клиентах (их платформе), а так же на сложности будущего приложения.
Если большинство клиентов — вендузятники, вопрос о "гипертексте" вообще не встаёт! Но если вдруг задуман многоплатформенный хит, даже в этом случае всё ещё есть важная альтернатива — писать ХТМЛки или (при широком взаимодействии с низлежащей ОС) для каждой платформы делать своё приложение. Простой как тапок пример: графический редактор. Да, можно загемороиться с canvas, что-то там сваять уровня Paint. Но когда придёт пора расширений и недостаточного быстродействия, браузописаки сядут в лужу, т.к. сэкономили на "экзешниках", зато прокакали главный путь развития!
Итого: для того, чтобы связываться с убогой, подверженой ошибкам и нестандартам, зато "вездеплатформенной" средой, у фантазёра должны быть очень веские основания! И не только желание покрыть все компьютеры мира, но и обоснование — будет ли коммерчески рентабельно писать под те же ведропланшеты, юзеры которых жлобятся даже на доллар.
_NN>Получается по вашему, браузеры как бы и не так уж нужны ?
Я этого не говорил, я лишь подчёркиваю ограниченность браузосреды и как бы "совсем не аппликашную" природу Web'а — гипертекст. То, что поверх него наклали ещё и ужасный жабоскрипт, ступорит окончательно и хочется спросить: "Вы чё хотели сделать-то?". Здесь уместно вспомнить Java — то светлое многоплатформенное будущее, за которое сейчас рвут тельняшки. Почему не взлетело? Ведь жабу портировали подо всё мыслимое железо! Да просто потому, что в браузере жаба — ограничена, а на виндо-десктопе — нафик не нужна, есть свои нативные средства разработки.
Здравствуйте, fddima, Вы писали: F>Другой фрейм — обычная форма. Раньше так делали. Хотя схема перегружать раз в секунду была по моему более популярна. =)
О да, я прекрасно помню это "раньше". Был такой "диванчик". Пробовал я в нём сидеть с модема — бесполезное занятие. За время обновления фрейма дискуссия уезжала на пару экранов, так что даже читать это было невозможно — не то, что участвовать.
Именно поэтому меня так забавляют потрясающе некомпетентные высказывания matumba в этом топике.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, matumba, Вы писали:
M>Месье слышал что-нибудь о скорости передачи информации? Ну, там, "кибибиты", "ебибуты"... Построй сайт хоть на оптических ЦПУ, по сети всё равно надо передавать информацию, что заведомо дольше, чем реакция человека "нажал — ничего не видно".
Спасибо за ликбез про скорость передачи. Судя по применяемым терминам типа "кибибитов", вы ведёте речь о ширине полосы.
Для неё крайне важно сокращать объём передаваемых данных. AJAX занимается именно этим — когда вы добавляете товар в корзину, на сервер улетает полкилобайта и обратно полкилобайта. Для интересу прикиньте объём типичной страницы вашего любимого магазина и поделите одно на другое.
M>Забавно... ВЕСЬ ТЫРНЕТ — это сплошная перезагрузка страниц, что здесь может быть раздражающего? Нажал — получил документ по ссылке, это норма. Медленная работа — увы, чаще некомпетентность веб-писакакателей, чем объективная необходимость. Вот было бы поменьше всяких "градиентиков-жабоскриптиков", тырнет стал бы намного чище и быстрее.
Ухты. Одним абзацем выше были умные рассуждения про то, что "по сети всё равно надо передавать информацию", и что оно "заведомо дольше", и вдруг "медленная работа — это некомпетентость". Вы уж определитесь, какой фактор главнее.
M>Месье полагает, что сделать запрос на сервер из жабоскрипта — это волшебным образом в 10 раз быстрее того же браузера? Спешу вас огорчить, это всё тот же самый механизм HTTP. Да, данных передаётся меньше, но оптимизация "когда-что-кому" передавать — это и есть "правильная структура сайта".
А, вот мы и дошли до сути. Ну, расскажите нам про "правильную структуру сайта", которая волшебным образом сократит объём данных, передаваемых при полной загрузке страниц. Приоткройте, так сказать, завесу тайны.
Для AJAX я себе очень хорошо представляю, как контролировать объём данных, ездящих вверх-вниз. А также как повышать визуальную отзывчивость UI, компенсируя латентность сети при помощи асинхронной работы. Что вы собираетесь мне предложить взамен в без-JS реализации на HTML 3.0?
M>Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML, не вызывая попаболь тысяч юзеров "нестандартных" браузеров позади всяких "фильтров рекламы". И уж конечно, для меня намного приятнее "перегрузить страницу", подтверждая результат моих действий, чем ждать долбаные скрипты — то ли зависли, то ли вообще сломались, то ли сеть рухнула, то ли сервер тормозит.... я наелся ваших аяксов по самые гланды — СПАСИБО, НЕ НАДО.
Странный мазохизм. То есть ждать 10 секунд на загрузку страницы вы согласны, а не ждать совсем или ждать 100мс вы уже несогласны.
M>Не последний, но видимо раньше вас — я начинал в 93-м, когда 2 КБ/с считался "хороший коннект" и трафик не разбазаривали на "стразики".
Что характерно, все упомянутые вами "стразики" трафик экономят весьма существенно. CSS позволяет ужать HTML в разы, передавая только семантик маркап; JS и динамика позволяет ужать его ещё в разы, передавая только дельту.
M>Да и дизайнеры были более профессиональные — у нас не было страниц по 500КБ только чтобы показать профайл юзера. Учитесь, господа!
Я вас умоляю. Дело вовсе не в дизайнерах, а в увеличившихся требованиях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, matumba, Вы писали:
I>>Это проблема медленных сайтов.
M>Месье слышал что-нибудь о скорости передачи информации? Ну, там, "кибибиты", "ебибуты"... Построй сайт хоть на оптических ЦПУ, по сети всё равно надо передавать информацию, что заведомо дольше, чем реакция человека "нажал — ничего не видно".
Я — слышал. А вот ты похоже в прошлом веке застрял. Нынче пиксел на мониторе загорается позже, чем успевает прийти запрос по сети на другой континент. Вот это современное состояние дел, а то о чем ты говоришь — прошлый век.
I>>И это лучше, чем показ второго окна.
M>Не факт, просто ваше личное мнение. Я уже объяснил ранее — корзину ВООБЩЕ НЕ НАДО ВИДЕТЬ. В крайнем случае — сойдёт и попап с беглым просмотром содержимого.
Это твой конкретный сценарий. Я например совершенно по другому покупки делаю. Моя жена тоже совершенно иначе делает, при чем я вообще не могу понять, чем она руководствуется.
I>>Это азы UI. Пользователя бесят перегрузки страницы, показы новых окошек и медленная работа.
M>Забавно... ВЕСЬ ТЫРНЕТ — это сплошная перезагрузка страниц, что здесь может быть раздражающего? Нажал — получил документ по ссылке, это норма. Медленная работа — увы, чаще некомпетентность веб-писакакателей, чем объективная необходимость. Вот было бы поменьше всяких "градиентиков-жабоскриптиков", тырнет стал бы намного чище и быстрее.
Пока что большая часть инета сделана на старых технологиях.
I>>Потому он отриентируется на сайте совсем не так как ты, и для него нужен другой UI, не такой как для тебя.
M>Во время покупки, от того, что я знаю внутреннюю кухню, мне ни жарко, ни холодно — покупаю как все, без хаков Так что не надо тут из меня изображать изгоя, я такой же средний юзер.
На счет "как все" — тут я сильно сомневасюь. Тебе просто удобно по себе мерять.
M>Возможно, сейчас я слышу опыт продавца женского белья, потому что только подобная категория сначала набирает полные руки шмотья, а потом решает "купить-не купить". И ДАЖЕ В ЭТОМ случае "загляд в корзину" — не более, чем вопрос "а не много ли я набрала?". Поиск и чтение описаний товаров занимает НАМНОГО большее время, чем собственно копание в белье набраных товарах.
Ты лучше сядь на день другой рядом с таким вот юзером и запиши подробно как он пользуется сайтом.
M>>>Короче, без жабоскриптов ЖИЛИ и могли бы жить дальше, сохраняя функциональность ВО ВСЕХ БРАУЗЕРАХ СРАЗУ. I>>Ну да, вместо ожидания запроса ожидали в десять раз больше — перегрузку страницы и тд и тд.
M>Месье полагает, что сделать запрос на сервер из жабоскрипта — это волшебным образом в 10 раз быстрее того же браузера? Спешу вас огорчить, это всё тот же самый механизм HTTP. Да, данных передаётся меньше, но оптимизация "когда-что-кому" передавать — это и есть "правильная структура сайта".
В том то и дело, что быстрее. Во первых, пересылается совсем коротенький запрос и назад идет совсем короткий респонз. Во вторых, серверное приложение реагирует много быстрее. Разница примерно на порядок.
M>Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML, не вызывая попаболь тысяч юзеров "нестандартных" браузеров позади всяких "фильтров рекламы". И уж конечно, для меня намного приятнее "перегрузить страницу", подтверждая результат моих действий, чем ждать долбаные скрипты — то ли зависли, то ли вообще сломались, то ли сеть рухнула, то ли сервер тормозит.... я наелся ваших аяксов по самые гланды — СПАСИБО, НЕ НАДО.
Зайди на stackoverflow и подробно объясни, чего там зависает, сломалось, рухнуло и тд.
M>Не последний, но видимо раньше вас — я начинал в 93-м, когда 2 КБ/с считался "хороший коннект" и трафик не разбазаривали на "стразики". Да и дизайнеры были более профессиональные — у нас не было страниц по 500КБ только чтобы показать профайл юзера. Учитесь, господа!
Я ж про что и говорю. Посмотри последний аутлук OWA и сравни с тем, что было в 93м.
Здравствуйте, matumba, Вы писали:
M>2. долбаная регистрация, сделаная недотумками по шаблонам других недотумков — вот здесь бы применить ваш интеллект!
Кстати говоря, последний раз я регистрировался в магазине наверное лет 5-6 назад. Даже в амазоне как то зарегился и забыл и пароль, и емейл и всё на свете, прикинь, это не помешало мне делать покупки на амазоне
Вот типичный интернет-магазин http://sushivesla.by/ Не далее чем 5 дней назад я заказывал там килограм-другой еды.
Покажи и внятно объясни, чем тебе мешает джаваскрипт, аджакс, корзина и прочие свистелки.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
_NN>>Кстати как вы без JS делаете чат ?
M>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере?
Потому что юзерам нужно живое общение, при чем без ожидания ответа днями или неделями. Эту потребность покрывает процентов наверное 80 всех сайтов, собтвенно чат именно для этого и нужен, при том незачем открывать новое окно.
Здравствуйте, matumba, Вы писали:
M>>>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере? _NN>>Потому что браузер есть везде.
M>Ответ неверный. M>Выбор платформы, инструментов и прочего должен основываться на клиентах (их платформе), а так же на сложности будущего приложения. M>Если большинство клиентов — вендузятники, вопрос о "гипертексте" вообще не встаёт! Но если вдруг задуман многоплатформенный хит, даже в этом случае всё ещё есть важная альтернатива — писать ХТМЛки или (при широком взаимодействии с низлежащей ОС) для каждой платформы делать своё приложение. Простой как тапок пример: графический редактор. Да, можно загемороиться с canvas, что-то там сваять уровня Paint. Но когда придёт пора расширений и недостаточного быстродействия, браузописаки сядут в лужу, т.к. сэкономили на "экзешниках", зато прокакали главный путь развития!
Я написал несколько рисовалок(почти), в т.ч. одну на JS со всякими аджаксами. Нынче нет инструментов, которые позвляют сделать кроссплатформенную рисовалку при чем достаточно быструю. Просто нет.
А вот требования сделать такое есть. Тебя такая разница не смущает ?
Я говорю, что раньше делали — один фрейм — долговисящее соединение непрерывно грузящее документ (сообщения из чата).
Никакой периодической перезагрузки. Второй фрейм только постит сообщения на сервер и сам может и не перегружаться (JS).
Как раз на модемах этот подход работал отлично, т.к. паразитного трафика почти не было.
А вот с любителями перегружать фрейм полностью — да, одна перезагрузка, и привет, как минимум пол и больше экрана сообщений уже уехало. А то и вообще уехало.
Здравствуйте, Ikemefula, Вы писали:
I>Я написал несколько рисовалок(почти), в т.ч. одну на JS со всякими аджаксами. Нынче нет инструментов, которые позвляют сделать кроссплатформенную рисовалку при чем достаточно быструю.
Браво! Вы уже процитировали мой ответ, осталось выделить ту основную мысль, которую вы прочли и ... не поняли?
Но если вдруг задуман многоплатформенный хит ... для каждой платформы делать своё приложение.
Здравствуйте, Ikemefula, Вы писали:
I>А вот JS в Web вобщем требует такого обсуждения.
Это нетехнические факторы, они малоинтересны.
Вкратце, моё мнение на эту тему таково: майкрософт сделала для комьюнити в разы больше, чем гугл. Гугл — империя зла, с планом зохватить мир. Майкрософт до сих пор — пушистые зайки, которые хотят зарабатывать на партнёрстве, а не на доминировании. В последнее время МС тоже пробует примерить на себя костюм какашки, но пока что у них это не очень получается — тридцать лет образа жизни так просто не выкинешь.
S>>Да, я вижу вот такую цитату: S>>
S>>Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
S>>Может, я слово "выдала" неправильно понимаю? Вы тогда расшифруйте поподробнее. I>Очевидно, не правильно. Представь себе, ты хочешь что бы я выдал Башара Асада. Очевидно, я этого не могу. Но при этом, отсюда не следует, что я скрываю этого Башара Асада.
Не понимаю вашу аналогию. Так вы могли выдать Асада, но не выдали? Или Майкрософт всё-таки не могла выдать технологии, и упрекнуть её не в чем?
I>Выше стоимость продукта — значит многие продукты не смогут переступить этот порог. Это значит, что ты будешь инвестировать время не пойми во что и никакого выхлопа за это не получишь. Скажем, люди которые инвестировали время в SL сейчас учатся заново, потому что мобайл прошел мимо SL. Люди которые инвестировали время в webForms, учатся заново, веб прошел мимо webforms. Люди которые инвестировали время в IE снова учатся заново. Те кто инвестировал время в IIS, обратно учатся заново.
I>Для сравнения, люди которые 10 лет назад инвестировали время в JS,Python, Ruby, Java, Apache до сих пор накапливают опыт, опаньки !
Да ну, чушь какая. Что там можно инвестировать в Apache или IIS? Что там можно инвестировать в Java? Там ничего нового с 1999 года не произошло.
Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP.
Вообще, если выстроить стек технологий, то окажется, что все, кто инвестировал во что-то, "абстрагирующее" от пайплайна, огрёб.
А те, кто инвестировал в изучение самого пайплайна — выиграл.
Под пайплайном я (упрощённо) понимаю SQL->HTTP/REST->HTML/CSS/JS
Попытки сбежать от HTML/CSS/JS в Silverlight провалились. Попытки сбежать от HTML/CSS/JS в WebForms провалились. Попытки сбежать от HTML/CSS/JS в апплеты провалились (это, кстати, часть той Java, в которую инвестировали время 10 лет назад. Куда теперь девать этот чудный опыт?)
Попытки сбежать от HTTP в RPC активно проваливаются, хотя инерция мышления всё ещё велика.
Попытки сбежать от SQL в разнообразный NoSQL или ORM будут зрелищно проваливаться в ближайшие пять лет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Может, я слово "выдала" неправильно понимаю? Вы тогда расшифруйте поподробнее. I>>Очевидно, не правильно. Представь себе, ты хочешь что бы я выдал Башара Асада. Очевидно, я этого не могу. Но при этом, отсюда не следует, что я скрываю этого Башара Асада. S>Не понимаю вашу аналогию. Так вы могли выдать Асада, но не выдали? Или Майкрософт всё-таки не могла выдать технологии, и упрекнуть её не в чем?
Не мог и не выдал. И Микрософт не мог и не выдал.
I>>Для сравнения, люди которые 10 лет назад инвестировали время в JS,Python, Ruby, Java, Apache до сих пор накапливают опыт, опаньки ! S>Да ну, чушь какая. Что там можно инвестировать в Apache или IIS? Что там можно инвестировать в Java? Там ничего нового с 1999 года не произошло.
Это значит, что люди накапливали опыт все эти годы, а не перескакивали с одного на другое.
S>Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP.
Правильно. А если сегодня ты учишь одну технологию, завтра — другую, не совсем ясно, где взять время на изучение HTTP.
S>Попытки сбежать от HTML/CSS/JS в Silverlight провалились. Попытки сбежать от HTML/CSS/JS в WebForms провалились. Попытки сбежать от HTML/CSS/JS в апплеты провалились (это, кстати, часть той Java, в которую инвестировали время 10 лет назад. Куда теперь девать этот чудный опыт?)
Та версия джавы издохла более 10 лет назад.
S>Попытки сбежать от HTTP в RPC активно проваливаются, хотя инерция мышления всё ещё велика. S>Попытки сбежать от SQL в разнообразный NoSQL или ORM будут зрелищно проваливаться в ближайшие пять лет.
NoSql правильно называть co-SQL. Если ты покажешь, как легко и просто в SQL писать быстрые глубокие иерархичические запросы, я покажу тебе рынок, на котором ты озолотишься прямо со вчерашнего дня.
Вот пример, как давно SQL умеет искаропки такие запросы как "BFS", "DFS", "graph diameter" ? А между тем есть no-SQL решения, которые умеют это буквально искаропки, при чем так, что код писаный на коленке студентом запущеный на десктопном железе рвет в хлам по перформансу запросы к Oraclе которые оптимизировала целая бригада программистов.
Тут ты наверное хочешь вспомнить транзакции, ACID и тд. Ну а представь, что кастомеру сначала нужен перформанс. Нет перформанса — нет продукта. И SQL как то быстро сдулся
Здравствуйте, Ikemefula, Вы писали: I>Не мог и не выдал. И Микрософт не мог и не выдал.
Ок, ну вот теперь мы определились. А то вы обмолвились, что МС чего-то мог, но не сделал, что меня и удивило до крайности.
А так-то я согласен: мог смочь, если бы знал чего хотеть, но хотел не того, в итоге того и не смог Пытается теперь смочь. С некоторым опозданием.
I>Это значит, что люди накапливали опыт все эти годы, а не перескакивали с одного на другое.
Непонятно, какой именно опыт можно накопить с апачом (ну, кроме опыта о том, что его архитектура — это академический антипример, и что единственный способ его готовить — это ставить lighttpd или nginx в качестве реверс-прокси впереди апача).
IIS — тоже, вид сбоку. Типичный веб-девелопер с IIS сталкивается раз в полгода, когда нужно подправить site bindings. Весь "опыт с IIS" — это опыт администрирования. Разработка как таковая совершенно не изменилась с версии, грубо говоря, 4.0.
S>>Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP. I>Правильно. А если сегодня ты учишь одну технологию, завтра — другую, не совсем ясно, где взять время на изучение HTTP.
Ну, так и кто в этом виноват? Я до сих пор ежедневно наблюдаю как в живую, так и в профильном форуме людей, незнакомых с fiddlertool.com. На основании чего их допускают к разработке веб приложений, лично мне совершенно непонятно.
I>Та версия джавы издохла более 10 лет назад.
Какая версия джавы? Апплеты и сейчас есть
I>NoSql правильно называть co-SQL. Если ты покажешь, как легко и просто в SQL писать быстрые глубокие иерархичические запросы, я покажу тебе рынок, на котором ты озолотишься прямо со вчерашнего дня.
Всё зависит от вашего определения "быстрых" и "глубоких"
Потому что "иерархические запросы" на SQL мы писали ещё в 2000х, когда занимались автоматизацией MLM. Скорость устраивала — один из наших проектов в 2001 году набрал 1 миллион подписчиков. Все — в одном дереве.
I>Вот пример, как давно SQL умеет искаропки такие запросы как "BFS", "DFS", "graph diameter" ? А между тем есть no-SQL решения, которые умеют это буквально искаропки, при чем так, что код писаный на коленке студентом запущеный на десктопном железе рвет в хлам по перформансу запросы к Oraclе которые оптимизировала целая бригада программистов.
Перед тем, как я начну делать категоричные утверждения, хочу отметить, что я вполне допускаю существование таких задач, в которых быстрая изкоробочная реализация BFS/DFS/Graph diameter — это core value. Я в первую очередь против того, чтобы пытаться сбежать от SQL на поле SQL, а не на поле graph processing и прочих реальных матанов.
А теперь мне было бы интересно посмотреть на пример реальной задачи, которая типа влёт решается на co-SQL и никак не решается на SQL (ну, или точнее — на современной RDBMS, которые по факту все постреляционные)
I>Тут ты наверное хочешь вспомнить транзакции, ACID и тд. Ну а представь, что кастомеру сначала нужен перформанс. Нет перформанса — нет продукта. И SQL как то быстро сдулся
Ок, давай потренируемся на воображаемой задачке, посмотрим, насколько быстро сдуется RDBMS.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
S>>Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP.
I>Правильно. А если сегодня ты учишь одну технологию, завтра — другую, не совсем ясно, где взять время на изучение HTTP.
А, вот ещё подумал: как это высказывание соотносится с вашим
Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
?
Ровно то же и получается: те, кто не хочет разбираться с XmlHttpRequest, а вместо этого хочет "учить технологию", обречены через пару лет учить другую технологию. А опыт тех, кто разобрался с XmlHttpRequest, будет востребован и через пять лет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ровно то же и получается: те, кто не хочет разбираться с XmlHttpRequest, а вместо этого хочет "учить технологию", обречены через пару лет учить другую технологию. А опыт тех, кто разобрался с XmlHttpRequest, будет востребован и через пять лет.
Похоже, эту фичу не оценил не только микрософт, но почти поголовно все разработчики и конторы
Здравствуйте, Sinclair, Вы писали:
S>Ок, ну вот теперь мы определились. А то вы обмолвились, что МС чего-то мог, но не сделал, что меня и удивило до крайности. S>А так-то я согласен: мог смочь, если бы знал чего хотеть, но хотел не того, в итоге того и не смог Пытается теперь смочь. С некоторым опозданием.
так и есть, "мог смочь, если бы..." С Башаром Асадом тоже самое -я "мог смочь, если бы..."
S>А теперь мне было бы интересно посмотреть на пример реальной задачи, которая типа влёт решается на co-SQL и никак не решается на SQL (ну, или точнее — на современной RDBMS, которые по факту все постреляционные)
См верхнюю часть рисунка. Здесь два слоя, ам где линки синие и где красные. Синий слой один, Красных слоев может быть больше одного. Синий слой роутится через несколько красных. Красный слой роутится через несколько нижележащих красных. Один линк роутится только на один слой. По одному линку может проходить трафик нескольких других линков разных слоев.
Объем сети где то от 100К объекто, слоев около 10-15. Синих линков около 10-15К. Узлов 1К-10к тыс. Красных линков 60К.
1. Нужно по клику мышом на конкретный элемент(или группу элементов, типа узел, линк и тд) показать где идет его трафик или, наоброт, чей трафик проходит через него.
Пути, их два типа — основной и резервный. Каждый путь состоит из конкретных элементов, у каждого элемента на нижележащем слое всегда будет два типа путей, основной и резервный и тд и тд.
Основной красится одним цветом, резервный — другим.
Основной резервного будет краситься в резервный цвет, а резервный основного будет краситься в основной и тд. Часть элементов может принадлежать как основному пути, так и резервному, скажем, через два три слоя, такие красятся зеброй.
2 Самый нижний слой — физический, это волокно. Обновить длину логических линков в соответствии с роутингом для основного пути.
Здравствуйте, Ikemefula, Вы писали:
I>Похоже, эту фичу не оценил не только микрософт, но почти поголовно все разработчики и конторы
В каком смысле?
Весь AJAX построен на ней.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Похоже, эту фичу не оценил не только микрософт, но почти поголовно все разработчики и конторы S>В каком смысле? S>Весь AJAX построен на ней.
Здравствуйте, Ikemefula, Вы писали: I>так и есть, "мог смочь, если бы..." С Башаром Асадом тоже самое -я "мог смочь, если бы..."
Давайте уже про Асада прекратим. Подбирать аналогии — искусство, в данном случае вы его не проявили.
I>Мне сложновато накидать простой пример. I>http://www.lit.lnt.de/Topics/Optic/OptHomepage_Img/OpticalTransportNet.jpg
I>См верхнюю часть рисунка. Здесь два слоя, ам где линки синие и где красные. Синий слой один, Красных слоев может быть больше одного. Синий слой роутится через несколько красных. Красный слой роутится через несколько нижележащих красных. Один линк роутится только на один слой.
Вот это непонятно — что значит "один линк роутится только на один слой".
I> По одному линку может проходить трафик нескольких других линков разных слоев.
По каким правилам? I>Объем сети где то от 100К объекто, слоев около 10-15. Синих линков около 10-15К. Узлов 1К-10к тыс. Красных линков 60К.
I>1. Нужно по клику мышом на конкретный элемент(или группу элементов, типа узел, линк и тд) показать где идет его трафик или, наоброт, чей трафик проходит через него.
И это всё на одной картинке? 100K объектов, с 60K линков?
Слабо себе представляю. Впрочем, неважно — вопросы отсечения можно пока оставить. I>Пути, их два типа — основной и резервный. Каждый путь состоит из конкретных элементов, у каждого элемента на нижележащем слое всегда будет два типа путей, основной и резервный и тд и тд. I>Основной красится одним цветом, резервный — другим. I>Основной резервного будет краситься в резервный цвет, а резервный основного будет краситься в основной и тд. Часть элементов может принадлежать как основному пути, так и резервному, скажем, через два три слоя, такие красятся зеброй.
I>2 Самый нижний слой — физический, это волокно. Обновить длину логических линков в соответствии с роутингом для основного пути.
I>Хочется получать данные за "время клика".
Пока что возникает ощущение, что всё известно статически. Простые связи типа "синий линк A роутится через красные линки A1, A2, A3" достаются влёт. Связи типа "из узла Х достижимы узлы Y, Z, W" вычисляются заранее путём построения транзитивного замыкания (быть может, ограниченного).
Ну, и вообще business case для RDBMS здесь не вполне понятен. Для read-only операций DBMS вообще не нужны. DBMS нужны для совместной работы (то есть чтений и модификаций) многих пользователей (или агентов) над структурированными данными.
А в вашей задаче вообще про изменения ни слова нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я не понимаю ваших высказываний. Вы явно пользуетесь терминами в каком-то отличном от других смысле. Вместо "технология" вы говорите "функция", вместо "инструмент" вы говорите "технология", вместо "евангелизировать" говорите "выдать", вместо "популярность" говорите "появление". Странно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Ajax как технология появился примерно в 2005м S>AJAX как технология появился в OWA.
Одного применения слишком мало что бы метод считать технологией. Эдак в каждом приложении окажется технологий столько, сколько уникальных строчек кода.
S>В 2005 эта технология получила популярность — вышла пачка книг.
Метод становится технологией когда проходит некоторые процедуры, примерно как верификация и фальсификация в науке. разница только в том, что нет однозначного простого критерия типа "если звезда которая должна быть видна ровно на границе окружности солнца имеет видимое смещение ~a то законы ньютоновские, а если ~б то законы релятивистские". Соответсвенно одиночного применения недостаточно, что бы считать метод технологией.
S>Я не понимаю ваших высказываний. Вы явно пользуетесь терминами в каком-то отличном от других смысле. Вместо "технология" вы говорите "функция", вместо "инструмент" вы говорите "технология", вместо "евангелизировать" говорите "выдать", вместо "популярность" говорите "появление". Странно.
Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд.
Здравствуйте, Ikemefula, Вы писали:
S>>Я не понимаю ваших высказываний. Вы явно пользуетесь терминами в каком-то отличном от других смысле. Вместо "технология" вы говорите "функция", вместо "инструмент" вы говорите "технология", вместо "евангелизировать" говорите "выдать", вместо "популярность" говорите "появление". Странно. I>Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд.
AJAX это не только XmlHttpRequest. AJAX — это такая технология/подход, когда для взаимодейтсвия с сервером не нужно перегружать страницы web-агента, а динамически в фоне посылать запросы и производить на основании данных полученных с сервера произвольные действия, в т.ч. динамически изменять страницы/интерфейс. А XmlHttpRequest — интерфейс для фонового взаимодействия с сервером; т.е. одна из фундаментальных составляющих AJAX.
Ты же нафантазировал себе, что AJAX = XmlHttpRequest и с умным видом развёл тут пустую демагогию основываясь на неверном предположении.
Здравствуйте, nullxdth, Вы писали:
N>Ты же нафантазировал себе, что AJAX = XmlHttpRequest и с умным видом развёл тут пустую демагогию основываясь на неверном предположении.
Не я, а кое кто другой тут утверждает что AJAX = XmlHttpRequest и это де есть технология.
В любом случае единичное применение Аджакса не дает оснований считать его технологией. Технология это некоторые распространяемые, проверяемые, фальсифицируемые знания о некотором методе. Если достаточно единичного применения, то эдак любой набор функций и даже одна функция станет технологией.
Или такой пример — чай как технология появился не тогда, когда ктото стал добавлять в кипяток листья чайного дерева, а много позже, когда некто другой написал целую книгу про это.
Или другой пример, технология "рычаг" появилась не тогда, когда ктото с помощью палки сдвинул с места большой предмет, а намного позже, когда эти знания стали распространяемыми, проверяемыми, фальсифицируемыми .
Здравствуйте, Ikemefula, Вы писали: I>Одного применения слишком мало что бы метод считать технологией. Эдак в каждом приложении окажется технологий столько, сколько уникальных строчек кода.
Ваше понимание технологии противоречит общепринятому. Скажем, вот если некая страна получила технологию очистки плутония, то технология существует. Несмотря на то, что другие страны могут этой технологии не иметь.
I>Метод становится технологией когда проходит некоторые процедуры, примерно как верификация и фальсификация в науке. разница только в том, что нет однозначного простого критерия типа "если звезда которая должна быть видна ровно на границе окружности солнца имеет видимое смещение ~a то законы ньютоновские, а если ~б то законы релятивистские". Соответсвенно одиночного применения недостаточно, что бы считать метод технологией.
А по мне так вполне достаточно. Я не вижу принципиальной разницы между наличием на рынке только OWA и OWA+Gmail.
I>Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд.
Нет. Технологией является AJAX. Его основа — это DHTML (то есть набор методов по динамической модификации DOM) и XmlHttpRequest (то есть способ получать от сервера данные). Без CSS можно обойтись, без XML можно обойтись.
Технологией является способ совместного применения этих функций для получения определённой пользовательской функциональности.
Поэтому я и говорю, что с момента первой реализации XmlHttpRequest и построения на его основе примера приложения, технологию можно считать состоявшейся. Никаких дополнительных "некоторых процедур", сформулировать которые вы не можете, для этого не надо. Процедура ровно одна — построение приложения. Без этого технология остаётся умозрительной.
Если вы ухитритесь разработать метод решения некоторого класса задач на основе функции alert(), то его тоже можно будет считать технологией. Даже если никто больше не будет владеть этой технологией. Но я спокоен за функцию alert(), равно как и trim(), slice(), toString(). Кстати, на основе последней работает jQuery. Если бы не toString(), то целый фреймворк бы не удалось построить
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Одного применения слишком мало что бы метод считать технологией. Эдак в каждом приложении окажется технологий столько, сколько уникальных строчек кода. S>Ваше понимание технологии противоречит общепринятому. Скажем, вот если некая страна получила технологию очистки плутония, то технология существует. Несмотря на то, что другие страны могут этой технологии не иметь.
Получить такую технологию вовсе не значит очистить плутоний один раз
I>>Метод становится технологией когда проходит некоторые процедуры, примерно как верификация и фальсификация в науке. разница только в том, что нет однозначного простого критерия типа "если звезда которая должна быть видна ровно на границе окружности солнца имеет видимое смещение ~a то законы ньютоновские, а если ~б то законы релятивистские". Соответсвенно одиночного применения недостаточно, что бы считать метод технологией. S>А по мне так вполне достаточно. Я не вижу принципиальной разницы между наличием на рынке только OWA и OWA+Gmail.
OWA необходимо, Gmail — уже достаточно
I>>Ты лучше сам подумай чего ты говоришь. Все функции у тебя можно назвать технологиями Ну от в чем разница между alert и XmlHttpRequest ? И то и другое можно считать технологией Сюда же можно добавить Trim Slice ToString и тд и тд и тд. S>Нет. Технологией является AJAX. Его основа — это DHTML (то есть набор методов по динамической модификации DOM) и XmlHttpRequest (то есть способ получать от сервера данные). Без CSS можно обойтись, без XML можно обойтись.
Я согласен с тем что Аджакс это технология. Я всего то утверждаю, что она появилась в 2005м году.
S>Если вы ухитритесь разработать метод решения некоторого класса задач на основе функции alert(), то его тоже можно будет считать технологией. Даже если никто больше не будет владеть этой технологией.
Здравствуйте, Sinclair, Вы писали:
I>>См верхнюю часть рисунка. Здесь два слоя, ам где линки синие и где красные. Синий слой один, Красных слоев может быть больше одного. Синий слой роутится через несколько красных. Красный слой роутится через несколько нижележащих красных. Один линк роутится только на один слой. S>Вот это непонятно — что значит "один линк роутится только на один слой".
Слои собтсвенно и создают иерархию, это статически задается. Есть слои A,B,C,D. Верхний слой A может роутиться на B, C, D хоть по одному, хоть на все сразу. Но конкретный линк из A будет роутиться только на один из слоев.
I>> По одному линку может проходить трафик нескольких других линков разных слоев. S>По каким правилам?
Не ясно, зачем тебе это надо
Условно так — у линка есть капасити, сигналы верхнего уровня тоже имеют капасити, сумма капасити сигналов сверху не должна превышать капасити линка. Рельно у линка есть N каналов, у каждого канала свой капасити, один сигнал сверху занимает ровно один канал если позволяет капасити. Решение задачи распределения каналов очень похоже на решение судоку или раскраску графа.
I>>Объем сети где то от 100К объекто, слоев около 10-15. Синих линков около 10-15К. Узлов 1К-10к тыс. Красных линков 60К. I>>1. Нужно по клику мышом на конкретный элемент(или группу элементов, типа узел, линк и тд) показать где идет его трафик или, наоброт, чей трафик проходит через него. S>И это всё на одной картинке? 100K объектов, с 60K линков?
Как это рисуется, не важно, если есть желание получить кашу можно и все на один скрин кинуть От тебя требуется выдать такую вещь LinkId — Color, NodeId — Color. Color это [основной, резервный, зебра].
I>>2 Самый нижний слой — физический, это волокно. Обновить длину логических линков в соответствии с роутингом для основного пути.
I>>Хочется получать данные за "время клика". S>Пока что возникает ощущение, что всё известно статически. Простые связи типа "синий линк A роутится через красные линки A1, A2, A3" достаются влёт. Связи типа "из узла Х достижимы узлы Y, Z, W" вычисляются заранее путём построения транзитивного замыкания (быть может, ограниченного).
Именно так. Это специфика оптической сети, они работают сильно отлично от Ethernet или ATM.
S>Ну, и вообще business case для RDBMS здесь не вполне понятен. Для read-only операций DBMS вообще не нужны. DBMS нужны для совместной работы (то есть чтений и модификаций) многих пользователей (или агентов) над структурированными данными. S>А в вашей задаче вообще про изменения ни слова нет.
Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
Здравствуйте, Ikemefula, Вы писали:
I>Слои собтсвенно и создают иерархию, это статически задается. Есть слои A,B,C,D. Верхний слой A может роутиться на B, C, D хоть по одному, хоть на все сразу. Но конкретный линк из A будет роутиться только на один из слоев.
Ок. Давайте вводить хоть какую-то формализацию, потому что по картинке и словам нихрена непонятно.
Давайте будем обозначать объекты-узлы номерами и буквами — буква означает слой. То есть, например, A1, А2, А3, B1, и так далее.
Судя по картинке, между некоторыми узлами из разных слоёв есть соответствие, но не для всех. То есть мы имеем B1, B2, B3, но только A1 и A3. A2 не существует.
Линк у нас будет обозначаться как просто пара узлов. Т.к. линк бывает только в пределах одного слоя, будем его обозначать буквой и, в скобках, номера слинкованных узлов: A(1, 3), B(1, 2).
Теперь, я так понимаю, "роутиться" — это функция A(1, 3) -> {B(1, 2), B(2, 3)}?
Причём никакой задачи поиска роута в реальном времени не стоит, это просто статическая информация?
I>Не ясно, зачем тебе это надо
Надо же понять, в чём собственно задача.
I>Условно так — у линка есть капасити, сигналы верхнего уровня тоже имеют капасити, сумма капасити сигналов сверху не должна превышать капасити линка. Рельно у линка есть N каналов, у каждого канала свой капасити, один сигнал сверху занимает ровно один канал если позволяет капасити. Решение задачи распределения каналов очень похоже на решение судоку или раскраску графа.
Это та задача, которую мы решаем, или это какая-то другая задача?
I>Как это рисуется, не важно, если есть желание получить кашу можно и все на один скрин кинуть От тебя требуется выдать такую вещь LinkId — Color, NodeId — Color. Color это [основной, резервный, зебра].
Непонятно, в чём сложность.
I>>>Хочется получать данные за "время клика". S>>Пока что возникает ощущение, что всё известно статически. Простые связи типа "синий линк A роутится через красные линки A1, A2, A3" достаются влёт. Связи типа "из узла Х достижимы узлы Y, Z, W" вычисляются заранее путём построения транзитивного замыкания (быть может, ограниченного).
I>Именно так.
Ок. Давайте прикидывать. Характерная длина "красного" роута для одного синего линка, судя по статистике, от 4х до 6 линков.
Пусть будет 5. То есть для каждого из 15к синих линков мы имеем набор из 5 интов, обозначающих номера узлов в роуте, +номер слоя. И всё это — дважды, для основного и резервного роутов. Итого — 10 интов, 40 байт. Плюс сам линк — это ещё два инта. Итого, 48 байт. Умножаем на 75k, получаем 3600000 байт. Всего, в целом.
Можно легко держать это всё в памяти клиента, и выдавать ответы на запросы типа "дай мне основной и резервный роут для линка w(x, y)" за микросекунды.
Что я понял неправильно?
I>Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
Ничего не понял. Попробуйте объяснить поточнее. Что такое "редактирует", что такое "срез", какие изменения, что бесит. Что в каменном, и кому что проигрывает клиент.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Слои собтсвенно и создают иерархию, это статически задается. Есть слои A,B,C,D. Верхний слой A может роутиться на B, C, D хоть по одному, хоть на все сразу. Но конкретный линк из A будет роутиться только на один из слоев. S>Ок. Давайте вводить хоть какую-то формализацию, потому что по картинке и словам нихрена непонятно. S>Давайте будем обозначать объекты-узлы номерами и буквами — буква означает слой. То есть, например, A1, А2, А3, B1, и так далее. S>Судя по картинке, между некоторыми узлами из разных слоёв есть соответствие, но не для всех. То есть мы имеем B1, B2, B3, но только A1 и A3. A2 не существует.
Есть конечно. Узлы привязаны к географическим точкам. То есть, скажем, шкаф с оборудованием подключен к слоям A, B и D, это значит, что здесь три узла будет.
Скажем если ты гоняешь трафик на верхнем уровне между Москвой и Берлином, то на самом верхнем уровне всего два терминальных узла которые, на самом нижнем может быть пару тысяч и более транзитных узлов.
S>Линк у нас будет обозначаться как просто пара узлов. Т.к. линк бывает только в пределах одного слоя, будем его обозначать буквой и, в скобках, номера слинкованных узлов: A(1, 3), B(1, 2). S>Теперь, я так понимаю, "роутиться" — это функция A(1, 3) -> {B(1, 2), B(2, 3)}?
Еще тип пути — основной или резервный. Линков в пути может быть сколько угодно и даже могут цикл образовывать, обычно это простой цикл.
S>Причём никакой задачи поиска роута в реальном времени не стоит, это просто статическая информация?
Именно так. Это софт для проектирования, а не для симуляции.
I>>Условно так — у линка есть капасити, сигналы верхнего уровня тоже имеют капасити, сумма капасити сигналов сверху не должна превышать капасити линка. Рельно у линка есть N каналов, у каждого канала свой капасити, один сигнал сверху занимает ровно один канал если позволяет капасити. Решение задачи распределения каналов очень похоже на решение судоку или раскраску графа. S>Это та задача, которую мы решаем, или это какая-то другая задача?
Это я тебе объяснил, как сигналы верхнего уровня укладываются в нижележащие линки.
I>>Как это рисуется, не важно, если есть желание получить кашу можно и все на один скрин кинуть От тебя требуется выдать такую вещь LinkId — Color, NodeId — Color. Color это [основной, резервный, зебра]. S>Непонятно, в чём сложность.
У меня — никакой
I>>Именно так. S>Ок. Давайте прикидывать. Характерная длина "красного" роута для одного синего линка, судя по статистике, от 4х до 6 линков.
По картинке не видно, но длина роута может быть какой угодно. Реально для утилизации оборудования и всяких схем резервирования обычно алгоритмы роутинга стараются дававать длинные пути.
S>Пусть будет 5. То есть для каждого из 15к синих линков мы имеем набор из 5 интов, обозначающих номера узлов в роуте, +номер слоя.
Путь это линки, а не узлы. Между двумя узлами может быть сколько угодно линков одного типа и тд. Ну представь, никто не будет между двумя городами прокладывать оптический кабель в котором ровно один файбер, т.е. тонюсенький такой волосок Собственно логических линков тоже может быть больше одного.
>И всё это — дважды, для основного и резервного роутов. Итого — 10 интов, 40 байт. Плюс сам линк — это ещё два инта. Итого, 48 байт. Умножаем на 75k, получаем 3600000 байт. Всего, в целом. S>Можно легко держать это всё в памяти клиента, и выдавать ответы на запросы типа "дай мне основной и резервный роут для линка w(x, y)" за микросекунды. S>Что я понял неправильно?
Для одной конкретной задачи примерно так и будет, с поправкой на особенности роута, что я указал. Получить основной и резервный это частный случай. У каждого линка из любого пути будут в свою очередь так же основные и резервные пути. То есть, каждый слой роутится на нижележащие, и нужно скажем кликнув на линке верхнего уровня, получить полную картину на самом нижнем уровне, то есть, раскрутить весь роутинг по слоям.
Скажем, бывает такая ситуация — на верху всего один линк, а внизу — сотни и даже тысячи.
I>>Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
S>Ничего не понял. Попробуйте объяснить поточнее. Что такое "редактирует", что такое "срез", какие изменения, что бесит. Что в каменном, и кому что проигрывает клиент.
Кастомер хочет "потрогать" роутинг. Это для разных целей используется. Ну вот самый простой случай — хочешь сравнить два разных роутинга. Кликнул мышом в линк и посмотрел, где идет его трафик или выделил пару узлов и смотрит, какую часть сети затронет сбой узла. Т.е. ответ надо получать очень быстро, не в реальном режиме времени, но желательно успевать за кликами оператора. "Редактирует" — это значит есть N людей, которые вносят изменения в проект сети, меняют чего то, удаляют чего то, ктото роутинг создает, ктото отдельные свойсвта меняет. Срез — возможно не так выразился, это просто часть сети, выборка по определенному условию, обычно географическому , например Канада. Сервер делает выборку, отдаёт на клиент, клиент чего то смотрит, меняет и отдает обратно серверу.
Подтянуть с сервера целую кучу данных крайне сложно, а после этого нужно еще визуализировать сеть и тд. Поэтому использовать запрошеную фичу крайне сложно. А вот в десктопном, имеется ввиду стандалон, наоброт, очень легко, т.к. не надо никуда ходить за данными, все доступно практически сразу.
I>Есть конечно. Узлы привязаны к географическим точкам. То есть, скажем, шкаф с оборудованием подключен к слоям A, B и D, это значит, что здесь три узла будет. I>Скажем если ты гоняешь трафик на верхнем уровне между Москвой и Берлином, то на самом верхнем уровне всего два терминальных узла которые, на самом нижнем может быть пару тысяч и более транзитных узлов.
Не вполне понятно, что на верхнем уровне. Прямой линк москва-берлин, или роут типа Москва-Калининград-Хельсинки-Берлин?
I>Еще тип пути — основной или резервный. Линков в пути может быть сколько угодно и даже могут цикл образовывать, обычно это простой цикл.
Этот момент непонятен. Что значит "цикл", и как это работает?
I>Именно так. Это софт для проектирования, а не для симуляции.
Угу.
I>У меня — никакой
Ок. I>>>Именно так. S>>Ок. Давайте прикидывать. Характерная длина "красного" роута для одного синего линка, судя по статистике, от 4х до 6 линков.
I>По картинке не видно, но длина роута может быть какой угодно.
I>Реально для утилизации оборудования и всяких схем резервирования обычно алгоритмы роутинга стараются дававать длинные пути.
Какова средняя длина пути?
I>Путь это линки, а не узлы. Между двумя узлами может быть сколько угодно линков одного типа и тд. Ну представь, никто не будет между двумя городами прокладывать оптический кабель в котором ровно один файбер, т.е. тонюсенький такой волосок Собственно логических линков тоже может быть больше одного.
Ок, принципиальной разницы это нам не меняет. Если линк идентифицируется не только парой соединённых узлов, то мы даём ему синтетический ключ linkId, и это по-прежнему один инт.
I>Для одной конкретной задачи примерно так и будет, с поправкой на особенности роута, что я указал. Получить основной и резервный это частный случай. У каждого линка из любого пути будут в свою очередь так же основные и резервные пути. То есть, каждый слой роутится на нижележащие, и нужно скажем кликнув на линке верхнего уровня, получить полную картину на самом нижнем уровне, то есть, раскрутить весь роутинг по слоям.
Ок, мы говорим о транзитивном замыкании. Которое вычисляется по данным, полный объём которых ложится в L1 cache процессора современного лэптопа. Всё ещё не понимаю, при чём тут RDBMS.
I>Скажем, бывает такая ситуация — на верху всего один линк, а внизу — сотни и даже тысячи.
Охтыж, "даже тысячи".
I>>>Вторая задача как раз про изменения. Есть клиент-серверное приложение, где сеть редактирует целая куча людей. Там кастомер хочет видеть ровно те же самые функции — визуализацию в частности. Делается примерно так — создается некоторый срез, отсылается на клиент, от него изменения записываются в общую базу. Вот эта вещь очень сильно бесит кастомера, т.к. "глянуть" может занять несколько минут. Отсюда визуализация в клиент-серверном еще в каменном веке, а десктоп сильно проигрывает по объему хранимых данных.
S>>Ничего не понял. Попробуйте объяснить поточнее. Что такое "редактирует", что такое "срез", какие изменения, что бесит. Что в каменном, и кому что проигрывает клиент.
I>Подтянуть с сервера целую кучу данных крайне сложно, а после этого нужно еще визуализировать сеть и тд.
Не понимаю проблемы подтянуть с сервера вашу "кучу данных". Полный объём — считанные мегабайты. Дельты, значит, будут исчисляться килобайтами. Здесь всё сводится к разработке структуры, удобной для двух целей:
1. Скорость визуализации — это основное.
2. Локальность изменений — это чтобы дельты были понятными (а не как в Rational Rose, где одно изменение в связях компонентов приводило к тысячам диффов в файле).
На основе этого реализуется кэширование — и вперёд, на танки.
Технологию персистенса на серверной стороне нужно выбирать уже после того, как станет понятен протокол между клиентом и сервером. Вполне может подойти и RDBMS, но я этого понять не могу, пока нет полной постановки задачи.
На первый взгляд вполне хватает тупой таблицы
Links(
id int primary key,
originationNode int --foreign key references Nodes(id),
destinationNode int --foreign key references Nodes(id),
forwardReferences varbinary(max),
backReferences varbinary(max)
)
В forwardReferences лежат ссылки на основной и резервный роуты (собственно, список пар {LinkId, Type}), в backReferences — наоборот, список линков, которые роутятся через данный линк. Это денормализация, заменяющая отдельную таблицу LinkRelations, чтобы избежать лишних накладных расходов. Не факт, что потребуется даже она, при описываемых объёмах данных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Есть конечно. Узлы привязаны к географическим точкам. То есть, скажем, шкаф с оборудованием подключен к слоям A, B и D, это значит, что здесь три узла будет. I>>Скажем если ты гоняешь трафик на верхнем уровне между Москвой и Берлином, то на самом верхнем уровне всего два терминальных узла которые, на самом нижнем может быть пару тысяч и более транзитных узлов. S>Не вполне понятно, что на верхнем уровне. Прямой линк москва-берлин, или роут типа Москва-Калининград-Хельсинки-Берлин?
Угу.
I>>Еще тип пути — основной или резервный. Линков в пути может быть сколько угодно и даже могут цикл образовывать, обычно это простой цикл. S>Этот момент непонятен. Что значит "цикл", и как это работает?
Москва-Калининград-Хельсинки-Берлин-Варшава-Минск-Москва, как работает, это уже детали.
I>>Реально для утилизации оборудования и всяких схем резервирования обычно алгоритмы роутинга стараются дававать длинные пути. S>Какова средняя длина пути?
Это зависит от топологии, можно наверное 10-20 взять, я так навскидку не могу сказать, потому что уже ен работаю на этом проекте.
I>>Для одной конкретной задачи примерно так и будет, с поправкой на особенности роута, что я указал. Получить основной и резервный это частный случай. У каждого линка из любого пути будут в свою очередь так же основные и резервные пути. То есть, каждый слой роутится на нижележащие, и нужно скажем кликнув на линке верхнего уровня, получить полную картину на самом нижнем уровне, то есть, раскрутить весь роутинг по слоям. S>Ок, мы говорим о транзитивном замыкании. Которое вычисляется по данным, полный объём которых ложится в L1 cache процессора современного лэптопа. Всё ещё не понимаю, при чём тут RDBMS.
Ну ты же понимаешь, что приложение решает не одну эту задачу, потому данных намного больше. Один кусочек вполне может влезть в L1, но сначала надо сделать выборку. Может даже 100 байт хватит,но каким способом быстро выяснить, какие именно 100 байт тебе надо ?
I>>Подтянуть с сервера целую кучу данных крайне сложно, а после этого нужно еще визуализировать сеть и тд. S>Не понимаю проблемы подтянуть с сервера вашу "кучу данных". Полный объём — считанные мегабайты. Дельты, значит, будут исчисляться килобайтами. Здесь всё сводится к разработке структуры, удобной для двух целей:
Для одной задачи может и 100 байт быть. Но ведь приложение не решает одну единственную задачу. У линка например есть куча всяких свойств, ИД внезапно становится GUID, есть поля DateTime, есть всякие каналы, сегменты, парселы и тд и тд и тд и тд.
S>1. Скорость визуализации — это основное. S>2. Локальность изменений — это чтобы дельты были понятными (а не как в Rational Rose, где одно изменение в связях компонентов приводило к тысячам диффов в файле).
Вот обеспечить эту локальность очень трудно. Например ты захочешь удалить или изменить свойства узла. Внезапно оказывается, надо поудалять целую кучу приконнекченых к нему объектов. Например узел может присоединять только линки определенных типов. Меняешь тип узла, опаньки, все левые линки должны быть удалены, а до этого весь роутинг и тд и тд.
отдельный случай, топология все на всех — каждый узел связан со всеми остальными узлами. Как тут обеспечить локальность изменений, не ясно.
S>Технологию персистенса на серверной стороне нужно выбирать уже после того, как станет понятен протокол между клиентом и сервером. Вполне может подойти и RDBMS, но я этого понять не могу, пока нет полной постановки задачи.
Это понятно. Мне не понятно, какие еще данные тебе нужны. Реально выборка делается примерно так, если в объектной модели. Получить у узла весь генерируемый трафик, нужно по узлу получить все его линки, по каждому линку получить пути, каждого пути получить линки и все начинается заново и так до самого низа.
Или ноборотЮ посмотреть какие объекты роутятся через конкретный линк — получить все пути где есть этот линк, по ним получить все линки на верхнем уровне и тд и тд и тд.
Или такая вещь — обновить длину логических линков в соответствии с роутингом на физическом уровне. Надо раскрутить весь роутинг и пересчитать длину начиная с конца.
Типичный синдром инженегра, как я это про себя называю. Посмотрите хоть на сленговый термин «ГСМ» — увидите ту же картину. Ненависть и нежелание разбираться. Споров нет, п@#$болы с филфаков дискредитировали понятие «гуманитарий», но инженегроидность ничем не лучше. Такое же отклонение, только в другую сторону.
SV.>> Понадобилось, скажем, товар в корзину добавить — что, перегружать весь контент?
M>Можно и перегрузить. Разве вас кто-то тянет за хвост тащить ВЕСЬ контент магазина на одну страницу? Пусть на главной будут товары, а в отдельном (простом как тапок) окне — корзинка с товарами (занимающая от силы 2-5 кб). M>Как видите, сделать приложение не составляет труда, просто хомячкам с недельным курсом HTML+JS промыли мозги и они думают, что делают хорошие программы.
Как видит мир ижненегр: сидят, значит, хомячки и ваяют, как сердце прикажет. Откуда у них деньги, это инженегру неинтересно. «У тумбочке» берут, видимо.
В реальности над «хомячками» стоит менеджер и говорит, что и как должно работать. Чаще всего, им вообще приносят готовый .psd, и слава богу, если хотя бы слоевая разбивка есть. К нему дается набор комментариев, касающихся динамики (того самого AJAX'а). Откуда деньги у менеджера? А от клиентов, которые платят за все. И будьте уверены, что к ним прислушиваются, и вообще держат в фокусе внимания. Это значит, что встроенная корзина в конечном продукте появилась неспроста, а была проведена по всей цепочке от юзерских ожиданий до «хомячковой» реализации.
Теперь, что касается юзерских ожиданий. Юзеры под капот не смотрят, пока это их не затрагивает (и даже тогда многие не). Чтобы юзер открыл исходник страницы магазина, увидел там кучу Аякса, вместо топорного HTML'я и закрыл сайт — самим не смешно? Зато вот к дополнительным окнам юзер очень чувствителен. Я сам на днях понять не мог, почему у меня не открывается иллюстрация в интернет-магазине. Оказалось, открывается. Во внешнем окне. Которое я по случайности свернул, а не закрыл. А я, должен вам сказать, гораздо более многооконный, чем 98% юзеров. Вот поэтому все вменяемые магазины никогда не допустят такое решение до продакшен-сервера.
SV.>> А карты? С маршрутами, с вводом информации о пробках и так далее!
M>А зачем карты на HTML-ной странице? Совсем чтоль с ума посходили? Для карт нужна производительность + как можно более "нативный" интерактив (скажем, если у яблофилов нет ПКМ, для них нужно придумывать свой отдельный интерфейс). ЛЮБАЯ программа работает намного лучше, будучи написанной специально для конкретной ОС. То, что ленивая тварь за моником не хочет два раза писать код — это её проблемы. Но HTML+JS не победил мир, скорее наоборот — после браузерной горячки народ чешет хлюпало "чё ж мы такое писали?". Даже гугл с маньячной фобией мелкомягких технологий, и то не стал делать ведроид на хвалёных HTML/CSS/JS — там кругом Жаба. Дураки наверное, да?
Опять уши инженегра. Если бы он оторвался от студии и посмотрел по сторонам, на экономику, отношения людей, деньги, разве бы написал такое?
Картографическая информация такая ценная штука, что ее владельцы даже на возможность кэширования растрированных карт смотрели очень косо. Я не сильно в курсе, но, по-моему, еще несколько лет назад Яндекс не давал скачать кэш для мобильных аппов — владельцы карт не разрешали. Юзеры специально собирали этот кэш из кусочков и выкладывали на торренты. Что уж говорить про нативные аппы.
Другая сторона медали: до хрена юзеров никогда не запустит у себя бинарный софт рекламного агентства (коим и является Яндекс). Все же знают, что рекламные агентства собирают досье. С Пунто, например, скандальчик был, когда его прихватили на том, что он отправлял на сервер куски текстов под видом логов. Пусти козла в огорода, он неизвестно чего еще им наотправляет.
А тут оказывается, что во всем виновата ленивая тварь за моником. Она такие решения принимает по лени. Да ей такие решения и понюхать не дают. А не дают потому, что бизнес-цели она будет заменять... как там?.. «Для карт нужна производительность» — вот такими миражами.
Поскольку тут все ясно, я и отвечать не хотел. Времени жалко. Ответил потому, что кстати пришлось и ответ буду использовать в своих личных целях.
Здравствуйте, matumba, Вы писали:
M>заодно слегка так обосрал оппонента
А кто первый начал обсирать? «Хомячки с промытыми мозгами», «ленивые твари». У меня много знакомых, которые как раз описанными делами и занимаются. Корзинами, например. Отличные люди, трудолюбивые, работают по 12 часов в день, и мозги получше некоторых имеют. Кстати, без комплексов и этот бред про промытые мозги они бы прочитали с улыбкой. Близко к сердцу бы не приняли. Но они это они, а мне чего переживать о самолюбии человека, который за своим обсирательным аппаратом не следит?
Что касается использования, то уже использовал. Спасибо за предоставление портрета.
Здравствуйте, Ikemefula, Вы писали:
I>Это зависит от топологии, можно наверное 10-20 взять, я так навскидку не могу сказать, потому что уже ен работаю на этом проекте.
Ок, получаем десяток мегбайт на всё. Нафиг тут выборки? Тут клиент в айфоне будет летать.
I>Ну ты же понимаешь, что приложение решает не одну эту задачу, потому данных намного больше. Один кусочек вполне может влезть в L1, но сначала надо сделать выборку. Может даже 100 байт хватит,но каким способом быстро выяснить, какие именно 100 байт тебе надо ?
Пойти по указателю
I>Для одной задачи может и 100 байт быть. Но ведь приложение не решает одну единственную задачу. У линка например есть куча всяких свойств, ИД внезапно становится GUID, есть поля DateTime, есть всякие каналы, сегменты, парселы и тд и тд и тд и тд.
Ну и что.
I>Вот обеспечить эту локальность очень трудно. Например ты захочешь удалить или изменить свойства узла. Внезапно оказывается, надо поудалять целую кучу приконнекченых к нему объектов.
Ну и что? "Целая куча" — это около сотни объектов. Какова частота внесения изменений? Судя по описанию, тут для транзакционности достаточно глобального лока на всю систему, т.к. время модификации невелико. I>Например узел может присоединять только линки определенных типов. Меняешь тип узла, опаньки, все левые линки должны быть удалены, а до этого весь роутинг и тд и тд.
С учётом того, что полный список "приконнекченных" к узлу линков хранится в готовом виде, ничего военного получении списка нет. I>отдельный случай, топология все на всех — каждый узел связан со всеми остальными узлами. Как тут обеспечить локальность изменений, не ясно.
В этом случае с локальностью всё плохо. I>Это понятно. Мне не понятно, какие еще данные тебе нужны.
Для полного решения нужен точный список сценариев, которые нужно обеспечить, с частотами выполнения, степенью конкурентности и прочим.
Набросок я уже предоставил. Пока что получается так, что всё вполне можно хранить на сервере в RDBMS, потому что требований к производительности там считай что нет.
Весь адский перформанс достигается на клиенте, который загружает всю базу целиком в память, а изменения реплицируются по несложному протоколу.
I>Получить у узла весь генерируемый трафик, нужно по узлу получить все его линки, по каждому линку получить пути, каждого пути получить линки и все начинается заново и так до самого низа.
Совершенно непонятно, что мешает всю эту радость сделать на клиенте чисто в памяти. Благо объёмы, о которых идёт речь, сейчас ставят в наручные часы. Я бы понял, если бы у вас сеть весила десяток гигабайт. Вот тогда бы имело смысл заморачиваться вытеснением на диск или в сервер и вопросами оптимизации "запросов", чтобы ограничивать трафик между медленной и быстрой памятью. I>Или такая вещь — обновить длину логических линков в соответствии с роутингом на физическом уровне. Надо раскрутить весь роутинг и пересчитать длину начиная с конца.
Ну, как мы уже выясняли, это не нужно делать за 100мс. Поэтому особых проблем я не вижу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Это зависит от топологии, можно наверное 10-20 взять, я так навскидку не могу сказать, потому что уже ен работаю на этом проекте. S>Ок, получаем десяток мегбайт на всё. Нафиг тут выборки? Тут клиент в айфоне будет летать.
Выборки нужны по той причине что полная модель это десятки миллионов экземпляров. Скажем для дотнета это автоматически съедает около 100-200 мб если считать по восемь байт на объект
I>>Для одной задачи может и 100 байт быть. Но ведь приложение не решает одну единственную задачу. У линка например есть куча всяких свойств, ИД внезапно становится GUID, есть поля DateTime, есть всякие каналы, сегменты, парселы и тд и тд и тд и тд. S>Ну и что.
Всего десяток другой джойнов для выборки роутинга для одного слоя
I>>Вот обеспечить эту локальность очень трудно. Например ты захочешь удалить или изменить свойства узла. Внезапно оказывается, надо поудалять целую кучу приконнекченых к нему объектов. S>Ну и что? "Целая куча" — это около сотни объектов. Какова частота внесения изменений? Судя по описанию, тут для транзакционности достаточно глобального лока на всю систему, т.к. время модификации невелико.
Модификация это отдельный сценарий, его лучше не касаться. Отдельные сценарии модификации занимают минуты.
I>>Например узел может присоединять только линки определенных типов. Меняешь тип узла, опаньки, все левые линки должны быть удалены, а до этого весь роутинг и тд и тд. S>С учётом того, что полный список "приконнекченных" к узлу линков хранится в готовом виде, ничего военного получении списка нет.
А джойны куда девать? А передачу по сети? Ну предположим sql запрос будет ноль времени. На каждый клик нужно по три-десять мб гонять на клиент. Чтобы успеть за секунду это нужно 30-100 мегабит канал по самой скромной оценке. А если сервер будет пользовать десяток людей то уже оказывается что гигабита не хватит. Кастомеру нужны тысячи и десятки тысяч пользователей. Фокус в том что sql решение дохнет уже на одном. Потому возможности серверного совсем отличные от стандалона — много данных и пользователей но слабая визуализация
I>>отдельный случай, топология все на всех — каждый узел связан со всеми остальными узлами. Как тут обеспечить локальность изменений, не ясно. S>В этом случае с локальностью всё плохо.
Хуже некуда потому грузили все в память
I>>Это понятно. Мне не понятно, какие еще данные тебе нужны. S>Для полного решения нужен точный список сценариев, которые нужно обеспечить, с частотами выполнения, степенью конкурентности и прочим.
Ты же хотел упрощенную задачу а тут уже спецификация на приложение нужна
S>Набросок я уже предоставил. Пока что получается так, что всё вполне можно хранить на сервере в RDBMS, потому что требований к производительности там считай что нет. S>Весь адский перформанс достигается на клиенте, который загружает всю базу целиком в память, а изменения реплицируются по несложному протоколу.
1-2 гигабайта в памяти если грузить все. Реально нужны обьемы примерно на порядок больше. Неясно как тут добиться быстрого отклика.
I>>Получить у узла весь генерируемый трафик, нужно по узлу получить все его линки, по каждому линку получить пути, каждого пути получить линки и все начинается заново и так до самого низа. S>Совершенно непонятно, что мешает всю эту радость сделать на клиенте чисто в памяти. Благо объёмы, о которых идёт речь, сейчас ставят в наручные часы. Я бы понял, если бы у вас сеть весила десяток гигабайт. Вот тогда бы имело смысл заморачиваться вытеснением на диск или в сервер и вопросами оптимизации "запросов", чтобы ограничивать трафик между медленной и быстрой памятью.
Сделали в памяти гдето десять лет наЗад и на sql это слабо похоже
I>>Или такая вещь — обновить длину логических линков в соответствии с роутингом на физическом уровне. Надо раскрутить весь роутинг и пересчитать длину начиная с конца. S>Ну, как мы уже выясняли, это не нужно делать за 100мс. Поэтому особых проблем я не вижу.
Здравствуйте, Ikemefula, Вы писали:
I>Выборки нужны по той причине что полная модель это десятки миллионов экземпляров. Скажем для дотнета это автоматически съедает около 100-200 мб если считать по восемь байт на объект
С учётом того, что на моём ноуте 8GB оперативки, по прежнему не вижу проблемы держать в памяти 200 мегабайт.
I>Всего десяток другой джойнов для выборки роутинга для одного слоя
Это если нестерпимо хочется заниматься джойнами на лету, вместо того, чтобы предрассчитать результаты.
I>Модификация это отдельный сценарий, его лучше не касаться. Отдельные сценарии модификации занимают минуты.
Тогда вообще никаких проблем нет I>А джойны куда девать?
Какие ещё джойны? Я же вам нарисовал схему. В ней нет никаких джойнов. I>На каждый клик нужно по три-десять мб гонять на клиент. Чтобы успеть за секунду это нужно 30-100 мегабит канал по самой скромной оценке.
Зачем? К моменту клика всё уже на клиенте. Эти жалкие 200 мегабайт не стоят того, чтобы бегать за ними на сервер каждую секунду. I>А если сервер будет пользовать десяток людей то уже оказывается что гигабита не хватит. Кастомеру нужны тысячи и десятки тысяч пользователей. Фокус в том что sql решение дохнет уже на одном. Потому возможности серверного совсем отличные от стандалона — много данных и пользователей но слабая визуализация
Ничего не понимаю. Вы явно имеете в виду какое-то кривое решение достаточно простой задачи.
I>1-2 гигабайта в памяти если грузить все. Реально нужны обьемы примерно на порядок больше. Неясно как тут добиться быстрого отклика.
Откуда внезапно появились гигабайты? Начали мы со ста тысяч объектов, а теперь вы на лету меняете задачу.
I>Сделали в памяти гдето десять лет наЗад и на sql это слабо похоже
У вас тут нет задачи для SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Выборки нужны по той причине что полная модель это десятки миллионов экземпляров. Скажем для дотнета это автоматически съедает около 100-200 мб если считать по восемь байт на объект S>С учётом того, что на моём ноуте 8GB оперативки, по прежнему не вижу проблемы держать в памяти 200 мегабайт.
Объект в дотнете, если 32 бита система, занимает минимум 8 байт. десять миллионов экземпляров займут 80 мб и это вообще ничего — ни единой ссылки, ни единого свойства.
В 32х битной системе в принципе невозможно держать большую модель в памяти, там ровно один гб для дотнета, +-100-200мб на фрагментацию.
Быстрая визуализация требует больших ресурсов, кроме того, операционную систему пока еще никто не отменял. Твои 8гб это _копейки_.
Вль например далеко не самая большая сеть, в памяти занимает 30млн экземпляров. Это уже 240мб на одни только заголовки объектов.
S>Какие ещё джойны? Я же вам нарисовал схему. В ней нет никаких джойнов.
Ты лучше покажи, как ты предлагаешь хранить линки, слои, пути и тд. Как все это можно слить в одну структуру для конкретной операции объяснять не надо, это сделано 10 лет назад.
Потом покажи конкретный запрос, который сформирует эту структуру.
I>>1-2 гигабайта в памяти если грузить все. Реально нужны обьемы примерно на порядок больше. Неясно как тут добиться быстрого отклика. S>Откуда внезапно появились гигабайты? Начали мы со ста тысяч объектов, а теперь вы на лету меняете задачу.
Если говорить ровно про одну задачу, как про коня в вакууме, то ты сам убедился, что SQL не нужен.
Если говорить про один сценарий из приложения, то надо понимать, что модель намного больше чем конкретные данные для конкретной операции, минимум на два порядка.
На клиенте это уже не получается держать, а SQL решение сосёт не нагибаясь из за джойнов.
Скажем если все держать на клиенте, не совсем понятно, как будет многопользовательский доступ реализован. А если скачивать на каждый чих часть модели, то получается бедствие.
Здравствуйте, Ikemefula, Вы писали:
I>Объект в дотнете, если 32 бита система, занимает минимум 8 байт. десять миллионов экземпляров займут 80 мб и это вообще ничего — ни единой ссылки, ни единого свойства.
Это пока что рассуждения ни о чём. Потому, что совершенно не факт, что каждый элемент будет заслуживать отдельного объекта. Может быть, обойдемся структурами в массивах.
И ещё раз напомню, что задача ставилась про 100k объектов. Это в 100 раз меньше, чем новая задача.
I>Быстрая визуализация требует больших ресурсов, кроме того, операционную систему пока еще никто не отменял. Твои 8гб это _копейки_.
Это ваши 100к объектов — копейки. А 8гб пока особо и занять-то нечем. I>Вль например далеко не самая большая сеть, в памяти занимает 30млн экземпляров. Это уже 240мб на одни только заголовки объектов.
В памяти или в постановке задачи? А то я и для теоремы Пифагора 30 миллионов "экземпляров" напложу. I>Ты лучше покажи, как ты предлагаешь хранить линки, слои, пути и тд.
Я уже показал, как я их предлагаю хранить. Номера слоя нет, потому что его легко тривиально добавить. I>Потом покажи конкретный запрос, который сформирует эту структуру.
Я вижу, что-то в моём решении вам непонятно. Вы спросите, я отвечу. I>Если говорить ровно про одну задачу, как про коня в вакууме, то ты сам убедился, что SQL не нужен.
SQL нужен там, где есть одновременная многопользовательская работа над структурированными данными.
Вы начали с того, что предложили игнорировать модификации. Это сразу оставляет SQL за бортом. Потом оказалось, что данные для визуализации удобнее хранить кэшированными на клиенте, т.к. задача — квазистатическая; на сотни визуализаций приходятся единицы модификаций. Это позволяет нам иметь комфортную SQL-структуру на сервере и что угодно на клиенте. I>На клиенте это уже не получается держать, а SQL решение сосёт не нагибаясь из за джойнов. Из-за джойнов... Какая прелесть.
I>Скажем если все держать на клиенте, не совсем понятно, как будет многопользовательский доступ реализован.
Я же вам объяснил — вся многопользовательскость реализуется как два пальца. Клиент заливает изменения на сервер в транзакции, эти изменения неторопливо реплицируются всем остальным клиентам. Поскольку модификации — штука редкая, всё будет работать на ура.
Точно такую же схему использует, скажем, Outlook. Формат локальной базы данных — совершенно другой, чем на сервере.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Быстрая визуализация требует больших ресурсов, кроме того, операционную систему пока еще никто не отменял. Твои 8гб это _копейки_. S>Это ваши 100к объектов — копейки. А 8гб пока особо и занять-то нечем.
Эдак окажется что любую упрощенную задачу можно ужать в 8гб
I>>Если говорить ровно про одну задачу, как про коня в вакууме, то ты сам убедился, что SQL не нужен. S>SQL нужен там, где есть одновременная многопользовательская работа над структурированными данными.
А вот мне в очередной раз кажется, что упрощенную задачу в отрыве от приложения рассматривать смысла нет, потому что решение будет оптимизировано именно под эти требования, то есть, вообще разговор ни о чем.
I>>Скажем если все держать на клиенте, не совсем понятно, как будет многопользовательский доступ реализован. S>Я же вам объяснил — вся многопользовательскость реализуется как два пальца. Клиент заливает изменения на сервер в транзакции, эти изменения неторопливо реплицируются всем остальным клиентам. Поскольку модификации — штука редкая, всё будет работать на ура.
То есть, в упрощенную задачу надо добавить вообще все сценарии и что бы частота использования была адекватная ?
Здравствуйте, Ikemefula, Вы писали:
I>Эдак окажется что любую упрощенную задачу можно ужать в 8гб
Практически да. Это же то, чего мы хотели — мощность вчерашних мейнфреймов у пользователя на столе.
I>А вот мне в очередной раз кажется, что упрощенную задачу в отрыве от приложения рассматривать смысла нет, потому что решение будет оптимизировано именно под эти требования, то есть, вообще разговор ни о чем.
Тогда сформулируйте ту задачу, которую вы хотите решить.
I>То есть, в упрощенную задачу надо добавить вообще все сценарии и что бы частота использования была адекватная ?
Конечно. Вы странный — сами же сформулировали задачу, а теперь обижаетесь, что у неё есть решение.
Если у вас есть какая-то другая задача, то не стесняйтесь — изложите её. Но учтите, что если вы будете выкидывать "несущественные подробности", то решение опять может вас не устроить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>А вот мне в очередной раз кажется, что упрощенную задачу в отрыве от приложения рассматривать смысла нет, потому что решение будет оптимизировано именно под эти требования, то есть, вообще разговор ни о чем. S>Тогда сформулируйте ту задачу, которую вы хотите решить.
Та же самая задача, только данных столько что не вместится в твои 8гб + многопользовательский доступ, в частности, через веб-интерфейс. Можешь просто помножить количество данных, что я сообщил, на некоторый коэффициэнт. Идейка та же — по объекту верхнего уровня получить его роутинг на самом нижнем.
Здравствуйте, Ikemefula, Вы писали:
I>Та же самая задача, только данных столько что не вместится в твои 8гб + многопользовательский доступ, в частности, через веб-интерфейс.
Тут тебе таки надо определиться с реальными параметрами. Потому, что в 8 Гб не поместиться можно очень многими способами
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Та же самая задача, только данных столько что не вместится в твои 8гб + многопользовательский доступ, в частности, через веб-интерфейс. Можешь просто помножить количество данных, что я сообщил, на некоторый коэффициэнт. Идейка та же — по объекту верхнего уровня получить его роутинг на самом нижнем.
Опять фигня какая-то. Вы пытаетесь поставить performance-bound problem, но избегаете говорить о характеристиках производительности.
Данных — неизвестно сколько. Распределение длин роутов — неизвестно. Количество слоёв — неизвестно. Частота изменений — неизвестна. Типы изменений — неизвестны.
Представьте себе, что я предлагаю вам решить задачу умножения матриц. При этом я утверждаю, что ваше решение не подходит по производительности, но ни размеров матриц, ни количества множителей, ни того, насколько часто перемножаются одни и те же неизменные матрицы, я вам сказать не могу.
Зайдём с другого конца. Допустим, мы считаем полное кэширование на клиенте заведомо непрактичным.
То есть, мы строим клиент-серверный протокол взаимодействия: клиент задаёт вопрос, сервер отвечает.
Попробуем оценить, во что нам это обойдётся, хотя бы с точки зрения транспорта.
Если слоёв — 15, и на каждом уровне у нас характерная длина роута — 10, то транзитивное замыкание для одного линка будет затрагивать 10^15 линков.
Это явно какая-то чушь, т.к. столько линков нет даже в самой смелой вашей фантазии. Вы упоминали, что полный путь — "сотни, а может даже и тысячи" линков.
Давайте для определённости предположим, что заказчик хочет живенькой реакции для 10000 связанных линков.
То есть, в ответе мы передаём 10000 * (4 байта ID, 1 байт цвет) = 50 килобайт. Это я уже предполагаю, что все линки в окне просмотра были перед этим запрошены с сервера, и нам не нужно передавать все статические свойства типа координат узлов.
Время передачи у нас = 2 * Latency + Size/Bandwidth, должно быть <= MaxResponse = 1000мс (не будем ставить себе заведомо неразрешимую задачу получить 0.1сек, обеспечивающие идеальную гладкость UI).
Решая неравенство, получаем Bandwidth >= Size/(MaxResponse — 2 * Latency).
Типичная латентность для национального уровня — 50мс, для международного — 250мс. Итого, Bandwidth у нас должен быть не меньше 50kb/0.9c, если всё в пределах одной страны, или 550 килобит. Ок, базовый sanity check мы прошли, можно заниматься проектированием серверной стороны.
Надо понимать, что если условия изменятся, и нам придётся пропихивать не 50 килобайт, а 1 мегабайт за ту же секунду, то проблемы будут не на стороне сервера, а при обеспечении канала.
На сегодня всё, а в следующей серии мы попробуем разобраться, что нужно сделать на серверной стороне, чтобы успеть подготовить список из 10к раскрашенных линков за 900мс
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Та же самая задача, только данных столько что не вместится в твои 8гб + многопользовательский доступ, в частности, через веб-интерфейс. Можешь просто помножить количество данных, что я сообщил, на некоторый коэффициэнт. Идейка та же — по объекту верхнего уровня получить его роутинг на самом нижнем. S>Опять фигня какая-то. Вы пытаетесь поставить performance-bound problem, но избегаете говорить о характеристиках производительности. S>Данных — неизвестно сколько. Распределение длин роутов — неизвестно. Количество слоёв — неизвестно. Частота изменений — неизвестна. Типы изменений — неизвестны.
Да вроде как по данным все известно На счет длин роутов я даже и не могу сказать, это сильно зависит от топологии и алгоритмов/параметров роутинга. Есть роуты скажем для Слоев обычно 10-20. Про изменения пока не нужно ничего делать.
S>Время передачи у нас = 2 * Latency + Size/Bandwidth, должно быть <= MaxResponse = 1000мс (не будем ставить себе заведомо неразрешимую задачу получить 0.1сек, обеспечивающие идеальную гладкость UI). S>Решая неравенство, получаем Bandwidth >= Size/(MaxResponse — 2 * Latency). S>Типичная латентность для национального уровня — 50мс, для международного — 250мс. Итого, Bandwidth у нас должен быть не меньше 50kb/0.9c, если всё в пределах одной страны, или 550 килобит. Ок, базовый sanity check мы прошли, можно заниматься проектированием серверной стороны. S>Надо понимать, что если условия изменятся, и нам придётся пропихивать не 50 килобайт, а 1 мегабайт за ту же секунду, то проблемы будут не на стороне сервера, а при обеспечении канала.
S>На сегодня всё, а в следующей серии мы попробуем разобраться, что нужно сделать на серверной стороне, чтобы успеть подготовить список из 10к раскрашенных линков за 900мс
Собтсвенно это самое интересное. Хотелось бы увидеть как ты будешь хранить всю сеть и как будешь делать на ней запросы вроде тех, что я показал.
Здравствуйте, Ikemefula, Вы писали: S>>На сегодня всё, а в следующей серии мы попробуем разобраться, что нужно сделать на серверной стороне, чтобы успеть подготовить список из 10к раскрашенных линков за 900мс I>Собтсвенно это самое интересное. Хотелось бы увидеть как ты будешь хранить всю сеть и как будешь делать на ней запросы вроде тех, что я показал.
Спрашивайте — отвечаем.
Как хранить всю сеть?
По-умолчательный способ безо всяких денормализаций — это хранить табличку "кто через кого роутится":
create table Routes(
sourceLink int not null foreign key references Link(id),
targetLink int not null foreign key references Link(id),
isPrimaryRoute tinyint not null,
constraint RoutePK primary key clustered(sourceLink, targetLink, isPrimaryRoute)
)
Как делать к ней запросы?
Очень просто, ANSI SQL поддерживает синтаксис Common Table Expressions, на основе которого легко вычислять транзитивные замыкания на графах.
with AllRoutes(sourceLink, targetLink, isPrimaryRoute) as
( select sourceLink, targetLink, isPrimaryRoute from Routes where sourceLink = @linkID
union all
select r.sourceLink, r.targetLink, ar.isPrimaryRoute
from AllRoutes ar inner join Routes r on ar.targetLink = r.sourceLink
)
select targetLink, min(isPrimaryRoute)+2*max(isPrimaryRoute) as ColorId from AllRoutes group by targetLink
Здесь цвета определены элементарно:
0: линк входит только в резервные роуты
1, 2: линк входит и в те, и другие
3: линк входит только в основные роуты
Ой, но это же медленно!
Вот простой T-SQL код который каждый может запустить на MS SQL Server типа 2005 или новее:
set statistics time off
set nocount on
create database GraphTest;
go
use GraphTest
go
create table Node (
id int identity not null primary key clustered,
x int not null default(100),
y int not null default(100)
)
go
create table Link (
id int identity not null primary key clustered,
sourceNode int not null foreign key references Node(id),
targetNode int not null foreign key references Node(id),
layerNumber int not null default 0)
go
create table Routes(
sourceLink int not null foreign key references Link(id),
targetLink int not null foreign key references Link(id),
isPrimaryRoute bit not null,
constraint RoutePK primary key clustered(sourceLink, targetLink, isPrimaryRoute)
)
go
create function CalcRoute(@linkID int) returns table
as return
(
with AllRoutes(sourceLink, targetLink, isPrimaryRoute) as
( select sourceLink, targetLink, isPrimaryRoute from Routes where sourceLink = @linkID
union all
select r.sourceLink, r.targetLink, ar.isPrimaryRoute
from AllRoutes ar inner join Routes r on ar.targetLink = r.sourceLink
)
select * from AllRoutes
)
go
declare @i int
set @i = 0
while (@i<300)
begin
insert into Node default values
set @i = @i + 1
end
insert into Link(sourceNode, targetNode)
select sourceNode.id, targetNode.id from Node as sourceNode, Node as targetNode
select count(*) as totalLinks from Link
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 10 1 as sourceLink, id, 1 from Link where id>1 order by id; -- link #1 gets routed through 2-11;insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 100 ceiling(id/10), id, 1 from Link where id>=20 order by id; -- links #2-11 get routed through links #20-29, 30-39, 110-119, etcinsert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 ceiling(id/10), id, 1 from Link where id>=200 order by id; -- links #20-120 get routed through links #200-209, 210-219, ..., 1200-1209insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 1200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 2200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 3200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 4200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 5200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 6200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 7200 order by id
insert into Routes(sourceLink, targetLink, isPrimaryRoute)
select top 1000 id, id+1000, 1 from Link where id >= 8200 order by id
select count(*) as totalRoutes from Routes
checkpoint
dbcc dropcleanbuffers
set statistics time on
select * from CalcRoute(1)
set statistics time off
use master
drop database GraphTest
Вкратце, что делает код:
1. Создаёт новую базу с таблицами Node, Link, Route.
2. Заполняет её данными:
— 300 нод
— все попарно связаны со всеми, так что линков всего 90000 штук
— "роутов", т.е. отношений "линк A роутится через линк B" — 10110, устроенных следующим образом:
-- линк №1 первого слоя роутится через линки 2-11 второго слоя
-- линки второго слоя роутятся через 10 линков третьего слоя каждый
-- линки третьего слоя роутятся через 10 линков четвёртого слоя каждый
-- четвёртый слой и далее роутятся через 1 линк нижележащего слоя каждый
Таким образом, в транзитивное замыкание для первого линка входят вообще все известные роуты. Заметьте, что я взял более-менее невыгодный случай для SQL — ему приходится делать десять итераций, т.к. ветвистость уровней ниже четвёртого искусственно ограничена. Если бы я сделал по 10 линков на каждом уровне, то мы бы остановились на уровне 4.
Исходные данные упрощены — введены только primary роуты, резервные роуты не подсчитаны.
3. Затем код сбрасывает буфера (чтобы минимизировать эффект от кэширования) и выполняет поиск всех линков, через которых роутится линк #1, измеряя затраченное время.
На моём ноутбуке, в режиме работы от батарейки, я наблюдаю следующий результат:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
SQL Server Execution Times:
CPU time = 140 ms, elapsed time = 249 ms.
Какие ещё сомнения в дееспособности SQL вы хотите, чтобы я развеял?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Какие ещё сомнения в дееспособности SQL вы хотите, чтобы я развеял?
Мои пожалуйста. Мне почему-то кажется, что основной недостаток RDBMS, это накладные расходы на ACID. То есть там, где они не особо критичны, их можно просто избежать. К примеру это могут быть всякие социальные сети с миллионами лайков, где валовый объем высок, а точные цифры не особо критичны. Заниматься шардингом RDBMS, где ACID все равно начинает нарушаться, я смысла не вижу.
Здравствуйте, Ziaw, Вы писали:
Z>Мои пожалуйста. Мне почему-то кажется, что основной недостаток RDBMS, это накладные расходы на ACID.
Ну, для любителей есть RDBMS с отключаемым ACID — например MySQL.
Z>То есть там, где они не особо критичны, их можно просто избежать. К примеру это могут быть всякие социальные сети с миллионами лайков, где валовый объем высок, а точные цифры не особо критичны. Заниматься шардингом RDBMS, где ACID все равно начинает нарушаться, я смысла не вижу.
А я вот вижу основную проблему в том, что судя по форумам, у нас прямо все пишут социальные сети с миллионами лайков. А в жизни таких сетей — три с половиной штуки.
В итоге люди на полном серъёзе отбрасывают RDBMS по причинам перформанса в тех случаях, когда перформанса RDBMS хватает с запасом в 1000%.
Вот только что мы обсуждали "задачку на графах", где мой оппонент уверял, что вытащить 10000 связанных узлов из RDBMS за время клика невозможно, даже после привлечения "целой бригады программистов". На практике — SQL укладывается в требования на низкооборотистом винте с запасом в 3 раза. Если мы поставим серверный винт, то запас будет 8 раз. И это — решение, набросанное за 15 минут на коленке, без единой оптимизации производительности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Sinclair, Вы писали:
S>>Какие ещё сомнения в дееспособности SQL вы хотите, чтобы я развеял?
Z>Мои пожалуйста. Мне почему-то кажется, что основной недостаток RDBMS, это накладные расходы на ACID. То есть там, где они не особо критичны, их можно просто избежать. К примеру это могут быть всякие социальные сети с миллионами лайков, где валовый объем высок, а точные цифры не особо критичны. Заниматься шардингом RDBMS, где ACID все равно начинает нарушаться, я смысла не вижу.
Во-первых миллионы лайков это для RDBMS простая задача. Даже сотни миллионов. И совершенно без шардинга.
Во-вторых 99,9999% программистов такое не пишут и никогда не будут.
В-третьих влияние ACID на скорость сильно преувеличено, ибо веб-приложение с нормальным кешированием его даже не заметит.
Здравствуйте, Sinclair, Вы писали:
S> Как делать к ней запросы? S>Очень просто, ANSI SQL поддерживает синтаксис Common Table Expressions, на основе которого легко вычислять транзитивные замыкания на графах. S>
S> with AllRoutes(sourceLink, targetLink, isPrimaryRoute) as
S> ( select sourceLink, targetLink, isPrimaryRoute from Routes where sourceLink = @linkID
S> union all
S> select r.sourceLink, r.targetLink, ar.isPrimaryRoute
S> from AllRoutes ar inner join Routes r on ar.targetLink = r.sourceLink
S> )
S> select targetLink, min(isPrimaryRoute)+2*max(isPrimaryRoute) as ColorId from AllRoutes group by targetLink
S>
Я не понял фокус с цветами. Цвет линка на нижнем уровне определяется цветом самого верхнего пути, основной, резервный или смешаный. Шота не пойму как у тебя это получается.
Здравствуйте, Sinclair, Вы писали:
S>На моём ноутбуке, в режиме работы от батарейки, я наблюдаю следующий результат: S>
S>DBCC execution completed. If DBCC printed error messages, contact your system administrator.
S> SQL Server Execution Times:
S> CPU time = 140 ms, elapsed time = 249 ms.
S>
S>Какие ещё сомнения в дееспособности SQL вы хотите, чтобы я развеял?
В реальной модели роутинг раскручивается через гораздо большее количество сущностей, а именно несколько типов линков, каналы и тд и тд.
например роутинг может быть такой — клиентский линк(на самом верху только такие) имеет ровно один основной путь и несколько резервных, эти пути состоят из коннекшнов на нижний слой. Далее у каждого коннекшна есть путь из сегментов, у каждого сегмента путь из отрезков, каждому отрезку соответсвует канал в каждом из путей состоящем из простых линков. У каждого простого линка есть клиентский линк, это самый низ роутинга в слое, те здесь слой заканчивается и дальше повторяется как описано — коннекшны, сегменты, отрезки, каналы и простые линки и тд до самого низа. На самом низу клиентских уже нет.
Коннекшны, сегменты, отрезки — все пути из этих объектов могут быть как основными так и резервными.
И напоследок — клиентские линки могут быть вложеными. То есть, один клиентский линк содержит в себе несколько других клиентских,всегда два уровня. Вложенный роутится или сам или же его дочерние клиентские линки.
На самом верху только клиентские, на самом низу только все остальные.
Вся эта кухня нужна для получения например устойчивости сети к сбоям и тд и тд.
Вопрос — во сколько оценишь время работы аналогичного запроса, если скажем количество простых линков в пути будет примерно таким же, как ты посчитал в уже решенной задаче ?
Здравствуйте, Sinclair, Вы писали:
S>Вот только что мы обсуждали "задачку на графах", где мой оппонент уверял, что вытащить 10000 связанных узлов из RDBMS за время клика невозможно, даже после привлечения "целой бригады программистов".
Это ж была упрощенная задача. Теперь хочется смасштабировать подход на реальную модель и получить хотя бы оценки сверху-снизу. Собственно я говорю про факты которые довелось наблюдать, а саму серверную базу я не проектировал и даже запросов по ней не гонял, чисто замеры перформанса аналогичного функционала.
Здравствуйте, gandjustas, Вы писали:
G>В-третьих влияние ACID на скорость сильно преувеличено, ибо веб-приложение с нормальным кешированием его даже не заметит.
Q: Где взять сильного dba ?
A: Из таблицы сильных dba выбрать первого.
Здравствуйте, Ikemefula, Вы писали:
I>Это ж была упрощенная задача. Теперь хочется смасштабировать подход на реальную модель и получить хотя бы оценки сверху-снизу.
Простите, я не знаю, что такое "реальная модель". Вашу задачу я решил, даже не приступив к оптимизациям.
Чем "реальная" модель отличается от "упрощённой"? Можно покрутить параметры типа объёма данных. Но ничего интересного это не даст — картинка перестанет помещаться в экран до того, как RDBMS станет узким местом.
I>Собственно я говорю про факты которые довелось наблюдать, а саму серверную базу я не проектировал и даже запросов по ней не гонял, чисто замеры перформанса аналогичного функционала.
Вот что характерно, большинство аргументов про "проседание перформанса из-за ACID и джойнов" высказывается как раз теми, кто не проектировал и не гонял.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>В реальной модели роутинг раскручивается через гораздо большее количество сущностей, а именно несколько типов линков, каналы и тд и тд.
Ну и что?
I>Вопрос — во сколько оценишь время работы аналогичного запроса, если скажем количество простых линков в пути будет примерно таким же, как ты посчитал в уже решенной задаче ?
Всё это не имеет никакого значения. Вся задача сводится к построению транзитивного замыкания в некотором графе. Типы узлов графа нас не волнуют. Волнует только размер транзитивного замыкания. Каков он будет?
И, на всякий случай — как именно формулируется задача? Ну, кроме как "попытаться доказать, что RDBMS справляются хуже"? В том смысле, что я не очень понимаю, как и что вы хотите отобразить в клиенте. Зачем там за время клика все эти ненужные подробности?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sinclair, Вы писали:
S>> Как делать к ней запросы? S>>Очень просто, ANSI SQL поддерживает синтаксис Common Table Expressions, на основе которого легко вычислять транзитивные замыкания на графах. S>>
S>> with AllRoutes(sourceLink, targetLink, isPrimaryRoute) as
S>> ( select sourceLink, targetLink, isPrimaryRoute from Routes where sourceLink = @linkID
S>> union all
S>> select r.sourceLink, r.targetLink, ar.isPrimaryRoute
S>> from AllRoutes ar inner join Routes r on ar.targetLink = r.sourceLink
S>> )
S>> select targetLink, min(isPrimaryRoute)+2*max(isPrimaryRoute) as ColorId from AllRoutes group by targetLink
S>>
I>Я не понял фокус с цветами. Цвет линка на нижнем уровне определяется цветом самого верхнего пути, основной, резервный или смешаный. Шота не пойму как у тебя это получается.
Очень просто. isPrimaryRoute всегда берётся из самого верхнего пути — обрати внимание на то, что он взят из AllRoutes.
Затем мы выполняем свёртку — ведь один и тот же линк нижних слоёв может встречаться много раз в разных роутах. Вычисляем минимум и максимум, и комбинируем их для получения цвета. Из-за бинарности isPrimaryRoute комбинаций всего три: (min=0, max=0), (min=0, max=1), (min=1, max=1). Я в спешке протупил, и рассчитал для четырёх комбинаций. На самом деле надо их просто сложить, тогда получится 0 для резервного, 1 для смешанного, и 2 для основного.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
I>>Вопрос — во сколько оценишь время работы аналогичного запроса, если скажем количество простых линков в пути будет примерно таким же, как ты посчитал в уже решенной задаче ? S>Всё это не имеет никакого значения. Вся задача сводится к построению транзитивного замыкания в некотором графе. Типы узлов графа нас не волнуют. Волнует только размер транзитивного замыкания. Каков он будет?
В конечном итоге такой же примерно как я и говорил. Не совсем понятно,почему количество таблиц не имеет значения ?
S>И, на всякий случай — как именно формулируется задача? Ну, кроме как "попытаться доказать, что RDBMS справляются хуже"? В том смысле, что я не очень понимаю, как и что вы хотите отобразить в клиенте. Зачем там за время клика все эти ненужные подробности?
Все подробности не нужны, в итоге нужен только набор линков, если визуализация самих путей. Еще задача — нужно смотреть по какому каналу чей трафик идет. Еще можно посмотреть нет ли дыр в роутинге. Или длину логических линков обновить. Примерно так. Задач которые используют такую раскрутку роутинга очень много, все они формулируются по разному.
За время клика нужно только визуализацю делать.
Здравствуйте, gandjustas, Вы писали:
G>Во-первых миллионы лайков это для RDBMS простая задача. Даже сотни миллионов. И совершенно без шардинга.
Лайк бывает разный. Например можно хранить просмотры для каждого пользователя и давать рекомендации вроде — люди похожие на вас часто заходят еще и на страницу P. Лично я бы вынес это хозяйство в отдельную базу, чтобы не нагружать основную. Хотя бы для того, чтобы облегчить процедуру бэкапа основной БД. Теперь возникает вопрос, нужен в этой базе ACID или он будет только мешать?
G>Во-вторых 99,9999% программистов такое не пишут и никогда не будут.
Какое это имеет отношение к предмету беседы? Ну и ты не прав насчет рекомендаций, они довольно часто нужны, просто пока очень мало используются по причине сложности алгоритмов для среднего программиста. В любом случае оценка количества у тебя ошибочна, если учесть, что в мире всего миллионов десять программистов. Не получится ли так что и остальные оценки у тебя такие же?
G>В-третьих влияние ACID на скорость сильно преувеличено, ибо веб-приложение с нормальным кешированием его даже не заметит.
Я нажал лайк, количество изменилось, кеш должен сброситься. Как он тут поможет? Есть огромная таблица, которая постоянно дописывается. По этой таблице регулярно проходятся агрегатные запросы. Я вижу тут возможный ботлнек от ACID, а ты?
Здравствуйте, Ikemefula, Вы писали:
I>В конечном итоге такой же примерно как я и говорил.
Тогда и скорость будет примерно такая же. I>Не совсем понятно,почему количество таблиц не имеет значения ?
Потому, что значение имеет только объём работы. Во-первых, накладные расходы на сканирование другой таблицы не шибко отличаются от расходов на сканирование той же самой.
Во-вторых, если эти расходы начнут иметь значение, то мы легко перенесём весь граф в одну таблицу, оставив специфичные для типов узлов данные за её пределами.
I>Все подробности не нужны, в итоге нужен только набор линков, если визуализация самих путей.
Тогда задача полностью решена. I>Еще задача — нужно смотреть по какому каналу чей трафик идет. Еще можно посмотреть нет ли дыр в роутинге. Или длину логических линков обновить. Примерно так. Задач которые используют такую раскрутку роутинга очень много, все они формулируются по разному. I>За время клика нужно только визуализацю делать.
Тогда вопросов вовсе нет — все перечисленные задачи, очевидно, имеют математическую формулировку в терминах реляций. Пишем запрос — и вперёд, на танки. Раз нет требований к производительности, то они гарантированно решаются.
И можно вернуться к разговору о надёжности и непротиворечивости, которые непонятно, как обеспечивать в Nosql решениях.
В итоге мы имеем классическое неравенство: из корректного медленного решения есть способ сделать быстрое. Из быстрого некорректного решения способа сделать корректное — нету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ziaw, Вы писали:
Z>Лайк бывает разный. Например можно хранить просмотры для каждого пользователя и давать рекомендации вроде — люди похожие на вас часто заходят еще и на страницу P. Лично я бы вынес это хозяйство в отдельную базу, чтобы не нагружать основную. Хотя бы для того, чтобы облегчить процедуру бэкапа основной БД. Теперь возникает вопрос, нужен в этой базе ACID или он будет только мешать?
При типичных нагрузках на среднестатистическое приложение, ACID совершенно не повлияет на результативность. Т.е. не будет ни помогать, ни мешать. Z>Я нажал лайк, количество изменилось, кеш должен сброситься. Как он тут поможет?
Вы себе противоречите. Если должен сброситься — то сразу нужен ACID и точный подсчёт количества. А если не нужен точный подсчёт количества, то кэш прекрасно проживёт ещё 60 (300, 15000, etc) секунд. Z>Есть огромная таблица, которая постоянно дописывается. По этой таблице регулярно проходятся агрегатные запросы. Я вижу тут возможный ботлнек от ACID, а ты?
Я вижу непонимание задачи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
Z>>Лайк бывает разный. Например можно хранить просмотры для каждого пользователя и давать рекомендации вроде — люди похожие на вас часто заходят еще и на страницу P. Лично я бы вынес это хозяйство в отдельную базу, чтобы не нагружать основную. Хотя бы для того, чтобы облегчить процедуру бэкапа основной БД. Теперь возникает вопрос, нужен в этой базе ACID или он будет только мешать? S>При типичных нагрузках на среднестатистическое приложение, ACID совершенно не повлияет на результативность. Т.е. не будет ни помогать, ни мешать.
Типично такие нагрузки вообще не делают, нерационально. Хотя вполне востребовано и если это будет стоить дешево, то будет делаться повсеместно.
Z>>Я нажал лайк, количество изменилось, кеш должен сброситься. Как он тут поможет? S>Вы себе противоречите. Если должен сброситься — то сразу нужен ACID и точный подсчёт количества. А если не нужен точный подсчёт количества, то кэш прекрасно проживёт ещё 60 (300, 15000, etc) секунд.
Точный не нужен, пользователь должен увидеть результат своих действий.
Z>>Есть огромная таблица, которая постоянно дописывается. По этой таблице регулярно проходятся агрегатные запросы. Я вижу тут возможный ботлнек от ACID, а ты? S>Я вижу непонимание задачи.
Здравствуйте, Ziaw, Вы писали:
Z>>>Я нажал лайк, количество изменилось, кеш должен сброситься. Как он тут поможет? S>>Вы себе противоречите. Если должен сброситься — то сразу нужен ACID и точный подсчёт количества. А если не нужен точный подсчёт количества, то кэш прекрасно проживёт ещё 60 (300, 15000, etc) секунд.
Z>Точный не нужен, пользователь должен увидеть результат своих действий.
Разные хаки используют.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Во-первых миллионы лайков это для RDBMS простая задача. Даже сотни миллионов. И совершенно без шардинга.
Z>Лайк бывает разный. Например можно хранить просмотры для каждого пользователя и давать рекомендации вроде — люди похожие на вас часто заходят еще и на страницу P. Лично я бы вынес это хозяйство в отдельную базу, чтобы не нагружать основную. Хотя бы для того, чтобы облегчить процедуру бэкапа основной БД. Теперь возникает вопрос, нужен в этой базе ACID или он будет только мешать?
Это же довольно просто проверить. Берем сценарий вроде блогодвижка средней руки или интернет-магазина. Счиатем что у нас 20,000 юзеров и 1,000 лайкаемых элементов (записей\товаров).
Каждый пользователь делает примерно 50 лайков, то есть всего 1М лайков.
Посмотрим как sql справится.
Делаем таблицы:
CREATE TABLE [dbo].[Users]
(
[Id] INT NOT NULL PRIMARY KEY identity,
[Name] NVARCHAR(50) NOT NULL
)
CREATE TABLE [dbo].[Items]
(
[Id] INT NOT NULL PRIMARY KEY identity,
[Name] NVARCHAR(50) NOT NULL
)
CREATE TABLE [dbo].[Likes]
(
[UserId] INT NOT NULL foreign key references Users(id),
[ItemId] INT NOT NULL foreign key references Items(id),
constraint LikesPK primary key clustered([UserId], [ItemId])
)
Фигачим в них данные:
--Populate Items tabledeclare @i int
set @i = 0
while (@i<1000)
begin
insert into Items values(CAST(@i as nvarchar))
set @i = @i + 1
end
go
--Populate Users table: 20,000declare @i int
set @i = 0
while (@i<20000)
begin
insert into Users values(CAST(@i as nvarchar))
set @i = @i + 1
end
go
--Populate Likes table: 1,000declare @i int
declare @j int
--Populate likesset @i = 0
while (@i<20000)
begin
set @j = 0
while (@j<50)
begin
insert into Likes values(@i+1, CAST(RAND()*1000 as int)+1)
set @j = @j + 1
end
set @i = @i + 1
end--add likes to 1M countwhile ((select count(*) from likes) < 1000000)
begin
declare @i int
set @i = (select count(*) from likes)
while (@i < 1000000)
begin
insert into Likes values(CAST(RAND()*20000 as int)+1, CAST(RAND()*1000 as int)+1)
set @i = @i + 1
end
end
Первый цикл генерации лайков повторяющиеся пары дает, поэтому генерит меньше 1М записей. Второй цикл добивает до 1М.
А теперь основной запрос:
dbcc dropcleanbuffers
declare @userId int = 1000
set statistics time on
select top 10 l.ItemId, sum(s.Similarity) as Rating
from (
select l.UserId as LeftUserId, r.UserId as RightUserId, (1/(1+exp(-count(l.ItemId)/10.0))-0.5)*2 as Similarity
from dbo.Likes as l
join dbo.Likes as r on l.itemId = r.ItemId
where l.UserId <> r.UserId
and l.UserId = @userId
group by l.UserId, r.userId
having (1/(1+exp(-count(l.ItemId)/10.0))-0.5)*2 > 0.3
) s
join Likes l
on s.RightUserId = l.UserId
where s.LeftUserId = @userId
group by l.ItemId
order by sum(s.Similarity) desc
set statistics time off
Внутренний select получает похожих пользователей, а внешний строит топ 10 самых лайкаемых похожими пользователями айтемов. Все это делается для одного пользователя с id = @userId.
Первый прогон говорит что надо бы добавить индекс:
CREATE NONCLUSTERED INDEX LikesIdx
ON [dbo].[Likes] ([ItemId])
INCLUDE ([UserId])
Полный сброс, второй прогон:
SQL Server Execution Times:
CPU time = 234 ms, elapsed time = 2535 ms.
2,5 секунд. Это на localDB (SQL Express), который работает на 1 процессоре и 1 гб оперативки на моем ноуте с медленными дисками.
Если все данные в кеше, то 1 сек.
Обрати внимание на CPU Time — это реальное время вычислений, остальное — IO. На мощном сервере IO будет на порядок быстрее.
Размер базы — 50МБ.
Причем эти топ 10 айтемов не будут меняться долгое время, их можно честно кешировать на день. При правильной архитектуре веб-приложения их можно кешировать прямо на клиенте, не занимая память сервера.
Для тех что скажет что это плохо масштабируется:
1) По хорошему расчет похожих пользователей делается в отдельном процессе\сервере и результаты пишутся в базу. Кстати я сделал таблицу похожести пользователей и база была всего 130 мб.
2) Рекомендации можно также хранить и периодически пересчитывать. Тогда запросы вообще сведутся к тривиальным.
Для практики попробуйте обогнать SQL при выполнении этого запроса в рукопашном коде.
G>>Во-вторых 99,9999% программистов такое не пишут и никогда не будут.
Z>Какое это имеет отношение к предмету беседы? Ну и ты не прав насчет рекомендаций, они довольно часто нужны, просто пока очень мало используются по причине сложности алгоритмов для среднего программиста. В любом случае оценка количества у тебя ошибочна, если учесть, что в мире всего миллионов десять программистов. Не получится ли так что и остальные оценки у тебя такие же?
Думаю что я почти угадал. Реальные (не надуманные как в этом посте) проблемы от ACID испытывают порядка 100 программистов в мире, скорее всего они все работают в Bing ил Google.
А что касается алгоритмов рекомендаций, то value от них низкий, а effort большой, поэтому и редко применяют.
G>>В-третьих влияние ACID на скорость сильно преувеличено, ибо веб-приложение с нормальным кешированием его даже не заметит.
Z>Я нажал лайк, количество изменилось, кеш должен сброситься. Как он тут поможет? Есть огромная таблица, которая постоянно дописывается. По этой таблице регулярно проходятся агрегатные запросы. Я вижу тут возможный ботлнек от ACID, а ты?
Пересчитывать рекомендации на каждый лайк нет смысла, они почти не изменятся.
А я сделал тест, вроде как проблем нет. А если нужно количество лайков на элемент, то элементарно делается индексированная вьюха.
Здравствуйте, Ziaw, Вы писали:
Z>Типично такие нагрузки вообще не делают, нерационально. Хотя вполне востребовано и если это будет стоить дешево, то будет делаться повсеместно.
Да ладно. А мне казалось, что в каждом первом веб-магазине есть фича "вместе с этим покупают:", которая построена ровно на описанном вами функционале.
Z>Точный не нужен, пользователь должен увидеть результат своих действий.
Я продолжаю вас не понимать. Вот, допустим, я вижу "This page is liked by 15k users", нажимаю Like, что я должен увидеть? Если 15001 — то это точный подсчёт. Если неточный — то я так и увижу 15k, а результатом моих действий будет флаг "Like", в который превратилась кнопка после нажатия. Для этого вообще не нужен подсчёт никаких агрегатов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А как сделать так, что бы gmail показывал всю почту в фолдере без страничного переключения ?
— это самое тяжёлое ИТ-преступление. После похапэ, конечно. 
