Лук Oil проводило беспроигрышную...Религия

Семаджик

А почему-бы в Семаджике не сделать вот такую вещичку? ->
Все записи, которые ты пишешь, сохраняются в файл (это уже есть), а потом ты можешь смотреть историю, не подключаясь в Сети и не расходуя трафика (не заголовки, а именно сами записи!).

Comments (13):

    • honeyman
    • 12.06.2005 17:03
    • Нижний Новгород / Нижегородская область
    Очевидно же для любого проектировщика ПО — ибо будет постоянная путаница между режимами «показывать закэшированные записи» и «обращаться за записями к серверу LJ». А содержимое записей в этих двух режимах может заметно отличаться…
    Т.е., куча сложностей при копеечном выигрыше в трафике (не так уж много Semagic и жрёт).
    • ты не понял. ввести режим, когда Семаджик хранит в своеобразной структуре весь твой журнал (в offline). если ты его меняешь - то и там всё меняется.

      например, у меня 4 Мб файлов уже. и чтоже? если мне качать их, чтобы просмотреть (или искать что-нибудь), то понадобится время и деньги на трафик. а если я второй раз захочу посмотреть? третий? а? а тут он всё хранит в типа БД (даже и картинки может там локально сохранять!!) это очень удобно!
      • > ты не понял.
        Боюсь, не понял не я.

        > ввести режим, когда Семаджик хранит в своеобразной структуре весь твой журнал (в offline). если ты его меняешь - то и там всё меняется.

        А при каждом заходе в интернет вся структура (в твоём варианте) пересинхронизируется? В твоём случае — все четыре мегабайта?
      • > ты не понял.
        Боюсь, не понял не я.

        > ввести режим, когда Семаджик хранит в своеобразной структуре весь твой журнал (в offline). если ты его меняешь - то и там всё меняется.

        А при каждом заходе в интернет вся структура (в твоём случае — 4 мегабайта) пересинхронизируется? В твоём случае — все четыре мегабайта?
        • honeyman
        • 12.06.2005 17:23
        • Нижний Новгород / Нижегородская область
        > ты не понял.
        Боюсь, не понял не я.

        > ввести режим, когда Семаджик хранит в своеобразной структуре весь твой журнал (в offline). если ты его меняешь - то и там всё меняется.

        А при каждом заходе в интернет вся структура (в твоём случае — 4 мегабайта) пересинхронизируется?
        • не нужно всё синхронизировать! о чём ты вообще?!
          ты хотя бы пользовался им?
            • honeyman
            • 12.06.2005 17:34
            • Нижний Новгород / Нижегородская область
            > не нужно всё синхронизировать! о чём ты вообще?!
            А, похоже, ты до сих пор не понял.

            Поясняю:

            1. Semagic позволяет удалять и редактировать старые записи;
            2. Semagic позволяет создавать новые записи и подставлять в них старую дату, т.е. вставлять запись между уже имеющихся.
            И самое интересное:
            3. Semagic может использоваться с одним и тем же эккаунтом сразу в нескольких местах.
            Впрочем, пункт 3 — это основная проблема, первые два всего лишь дополнительно усложняют её.

            А теперь, если хочешь, можешь попробовать описать логику синхронизации Semagic-овой базы своих записей и реального содержимого сервера, которая бы позволяла следующий тесткейс: установленным на работе Semagic-ом удалить одну запись, добавить другую, отредактировать третью и вставить четвёртую в записи за вчерашний день, после чего прийти домой и установленным дома Semagic-ом попробовать поискать среди своих записей.

            Я догадываюсь, что автору Semagic-а даже и не пришло и не придёт в голову делать навороченную распределённую базу данных, поддерживающую подобные механизмы, только для того, чтобы сэкономить несколько килобайт трафика на один запрос.
            • первые две - это не проблемы. это всё проще простого.. ;)

              а вот третье - это твои проблемы. я пользуюсь одним Семаджиком. и я тебе говорю о записях локальных на компе! если уж у тебя сотни компов и ты там и сям работаешь в сети и пишешь в жж - это твои проблемы! допустим, решением будет - переписывать на Flash-диск (или на cd) эту БД и на работе копировать. и наоборот.
              в общем, не вижу здесь ни одной проблемы!

              и поэтому это будет сделано, пусть и не разработчиками...
                • honeyman
                • 12.06.2005 18:02
                • Нижний Новгород / Нижегородская область
                > а вот третье - это твои проблемы.
                Не-а. Это проблемы автора :) Как ему сделать так, чтобы эта база была валидной, сколько бы её экземпляров её ни существовало в скольких установленных копиях Semagic-а.

                А, да, чуть не забыл: писать сообщения в LJ можно ещё и без Semagic-а, посредством тучи всевозможных способов, от гейтов ail2lj и до веб-интерфейса. Предлагаешь запоминать, каким способом ты делал запись, для всех своих записей :) ?

                > если уж у тебя сотни компов
                Достаточно двух, чтобы о синхронизации пришлось серьёзно подумать. И чтобы между ними для несинхронизованных баз сообщений начинала бы возникать путаница.

                > переписывать на Flash-диск (или на cd) эту БД и на работе копировать. и наоборот.
                А если хоть однажды забыл её перекопировать — придётся пересинхронизировать (ибо она тут же перестала быть валидной). Всю. А для этого придётся делать механизм синхронизации. Бедный автор.

                > в общем, не вижу здесь ни одной проблемы!
                Тогда попробуй, реализуй, причём так, чтобы это не могло вызвать ни одной проблемы у пользователей. Исходники Semagic-а открыты. Раз тут нет проблем — тогда имплементация должна быть тривиальной.

                Хотя я, как человек, разбирающийся в проектировании и программировании существенно больше твоего, предупреждаю тебя заранее, что полноценное решение избыточно сложно. А решения уровня ItWorksForMe для программ с таким количеством пользователей, как Semagic, не подходят.

                PS Есть, кстати, одно потенциально неплохое решение. Вместо/помимо конечных записей, журналировать на сервере LJ все транзакции по созданию/редактированию/удалению своих записей. И при коннекте Semagic-а вспоминать, какая последняя транзакция известна Semagic-у, и заставлять сервер послать Semagic-у все более свежие транзакции. Но это как минимум требует изменений в коде и интерфейсах LJ. В случае, если механизм транзакций делать дополнительно к механизму выдачи конечных получившихся записей, оставляю тебе сосчитать, во сколько примерно раз придётся увеличивать дисковые массивы на LJ; если делать вместо механизма выдачи конечных записей, и формировать их из серии транзакций — оставляю тебе посчитать, во сколько раз медленнее будет работать LJ.
                • это нужно только для просмотра, понимаешь?
                  для местного просмотра сохранённых записей.
                  мне начхать на то, что там добавлено откуда-то.
                  а уж пройтись этому просмотрщику (по команде пользователя) и проверить, какие записи появились или изменились и скачать их - это запросто сделать! а если ты точно уверен, что пишешь только со своего одного Семаджика, то эту кнопку и не тронешь. вот и всё решение проблемы твоей раздутой! и лопнула она как мыльный пузырь ;)
                    • honeyman
                    • 12.06.2005 19:01
                    • Нижний Новгород / Нижегородская область
                    > это нужно только для просмотра, понимаешь?
                    > для местного просмотра сохранённых записей.
                    Ага.
                    Кстати, это должно быть вместо имеющейся в Semagic-е истории записей, лазающей за сведениями на сервер, или дополнительно к ней?

                    > мне начхать на то, что там добавлено откуда-то.
                    Тебе начихивать просто — ты не автор Семаджика, и тебя, в случае неудачной реализации, пинать не будут.

                    > а уж пройтись этому просмотрщику (по команде пользователя) и проверить, какие записи появились или изменились и скачать их - это запросто сделать!
                    Ты очень оптимистичен.
                    Проходить по какому периоду? С начала существования ЖЖ? — это весьма долго; в указанном пользователем диапазоне? — а что, если он пишет настолько часто и разнообразно, что не помнит, какие диапазоны надо синхронизировать? Как предложишь обходить эти use-case-ы, чтобы пользователь ничего не потерял?
                    Появились/удалились — проверить ещё можно. А вот чтобы проверить, изменилась ли запись, её придётся скачать. Что ты там говорил про 4 мегабайта :) ?

                    > а если ты точно уверен, что пишешь только со своего одного Семаджика,
                    Достаточно мало распространённая ситуация.

                    > то эту кнопку и не тронешь.
                    Ага. Кнопку. А если ты забыл её нажать, а после чего полчаса искал одну свою старую запись, переформулируя запросы по-всякому и забыв, что её писал из интернет-кафешки, то… тебя ждут негативные эмоции. Которых программа вызывать не должна.

                    > и лопнула она как мыльный пузырь ;)
                    От того, что ты посчитал, что проблемы нет, она не исчезла. Она существует вне зависимости твоего мнения о ней.
                    Кстати, способ аргументирования «если не можешь опровергнуть — отвергни» хорошо описан в «Заметках о женской логике» Беклемишева.




                    Решение с кэшированием записей является частным случаем более общей проблемы проектирования. Как известно, при проектировании каждая сущность во избежании проблем должна храниться один и только один раз (например, когда ты пишешь программу, и в разных местах у тебя встречается один и тот же код, ты его обычно выносишь в новую функцию; когда при создании таблицы в базе данных ты замечаешь, скажем, что каждому значению одной колонки соответствует конкретное значение другой колонки, ты переводишь таблицу в нормальную форму более высокого порядка).
                    В случае, если одна и та же сущность дублируется в разных местах, начинаются проблемы: приходится учитывать ситуации, когда эти сущности выходят из состояния идентичности/эквивалентности, оценивать последствия этого и предотвращать это (например, если у тебя есть каталог с документами и бэкап этого каталога, то эти сущности с виду эквивалентны, но в любой момент могут разойтись — либо документы изменятся, либо бэкап попортится. И поэтому для поддержания идентичности бэкапы снимать приходится регулярно, а особо паранойидальные люди ещё и регулярно проверяют, не испортились ли хранящиеся у них бэкапы).
                    Поэтому наиболее простым стабильным состоянием хорошо спроектированной системы является такое, при котором каждая его индивидуальная и независимая сущность хранится отдельно, а все зависимые выводятся через определённо не зависимые. В то же время, иногда систему сознательно проектируют с дублированием сущностей: обычно это либо делается либо ради оптимизации каких-то пользовательских характеристик (например, производительности — посредством всевозможных кэшей), либо для увеличения надёжности (бэкапы; дублирование важных систем в критических областях использования, как, например, в авиации, на опасных производствах; RAID-массивы). Но такое решение, как уже понятно из написанного выше, заведомо существенно усложняет систему и вызывает необходимость во множестве дополнительных механизмов обеспечения целостности (идентичности копий) (в объёмах, зависящих от степени опасности последствий расхождения идентичности сущностей).
                      • honeyman
                      • 12.06.2005 19:02
                      • Нижний Новгород / Нижегородская область
                      Примеры дублирования сущностей можешь увидеть в жизни на каждом шагу; для каждого из них можно оценить опасность расхождения в дублировании. «Принцип двойной записи» в бухучёте (и любимое развлечение бухгалтеров — сведение баланса); статические карты городов, нарисованные несколько лет назад и уже давно не отражающие действительность; извечный дуализм слабоформализуемого Стандарта и неавтоматической Реализации Стандарта (за примерами — к HTML и Майкрософту); информация о размере файла на файловой системе, одновременно и записанная в описании файла, и выводимая через количество его кластеров (и в результате в случае неудачного выключения питания или сбоя драйвера несовпадающая в корне).


                      Поэтому в Semagic-е реализовано, наверное, наилучшее решение этой проблемы — все данные о записях хранятся в единственном месте, на сервере LJ, а клиент просто обращается за ними.

                      PS Ей-богу, не вижу проблемы в нескольких килобайтах на обращение к серверу за списком записей за определённый срок. Тем более что поиск среди записей нынче тоже может реализовываться server-side (blogs.yandex.ru) (хотя поисковые сервера и наглядно демонстрируют недостатки принципа дуплицирования информации вместо хранения её в едином месте и динамического вывода представления, позволяя себе иметь устарелые и неактуальные копии искомой информации).
                      • ты сам ответил на свой вопрос - Ей-богу, не вижу проблемы в нескольких килобайтах на обращение к серверу
                        хотя выше полностью приводил противоположное мнение - Что ты там говорил про 4 мегабайта :) ?

                        допустим, можно просматривать на сервере все сообщения за этот день и за предыдущий. трафику это много не нагонит. и загружать все новые или изменённые.

                        это будет отдельная функция - именно как просмотр страниц (с картинками) твоего журнала. может быть, ты ещё и картинки хочешь хранить на сервере? ;) у меня вот, например, уже 20 Мб за некоторый период..и что же? они же у меня есть на компе, мои же картинки. указать ему, что вот этот путь заменяется на вот этот локальный - для просмотра местного.

                        это совершенно не связано с тем, что выдаётся по Ctrl-H.
                        это будет именно показ записей типа вот так:

                        Карточки [30 Nov 2003| 12:22am ]
                        Вот было время, помешался я на MTV чупа-чупс. Там были вложены карточки с фотографиями ведущих.
                        И вот я задумал найти Шелест. Ольга Шелест. Она недавно вела передачу "Утро" на НТВ...
                        Ну вот - сколько же я накупил этих карамелек, не пересчитать! :-)
                        На работе этими фотками обвешал свой ящик.. И вот наконец нашёл её!

                        Шелест
                        post comment
                        :-| [30 Nov 2003| 02:01am ]
                        [ mood | заболевшее ]
                        [ music | The Cure - Love Song ]
                        Что-то я совсем расклеился..
                        У кого есть клей?
                        1 comment | post comment
                        p>