четверг, 15 апреля 2010 г.
Аллоды Онлайн с капиталистическим оскалом
Скачал недавно очередное обновление к Аллоды Онлайн, решил поиграть, месяца два не заходил в игру, некогда было.
Отмечу, что скачать пришлось гигабайт обновлений. Что там на гигабайт обновилось для меня загадка или rsync это не для них?
После обновления в клиенте программы перед запуском появилась надпись: "Хочешь качаться быстрее? Свитки знания и наставления помогут тебе!".
Да да, подумал я, опять втюхивают игровые предметы за игровые кристаллы, которые я до сих пор не знаю как получить, разве что только за реальные деньги.
На форумах то и дело ругаются, что очередной патч урезал какую-либо возможность нормально прокачать персонажа, или играть в составе группы и все только с одной единственной целью, чтобы покупали игровые предметы за реальные деньги.
Игроков уже довели до потеции о Передаче операторских прав на игру (подписалось уже 6 тысяч человек, причем тысяча только за последнюю неделю). С каждым новым патчем, судя по сообщениях в форумах и этой петиции, все больше появляется желающих покинуть игру.
Меня же, не смотря на все это, вывело из себя следующее.
В этой игре я приторговывал чем мог на игровом аукционе. А иначе, барыжил как мог, скупал на все свои игровые деньги руны, и потом продавал их дороже. Так я сколотил свое состояние не выйдя за пределы ворот игрового города. Надо заметить на торговлю тоже уходит время, ведь надо выставить все на аукцион. Слот с аукциона снимается обычно через сутки, и игровой предмет отправлялся в игровую почту на мое имя с сообщением о том, что предмет на аукционе никто не купил.
В общем зашел я в игру через два месяца и вижу, что в моей почте нет ни одного письма и соответственно ни одного игрового предмета, которые я непосильным трудом добыл и не смог продать на аукционе, так как игровые предметы привязаны к письмам, и оказывается письма удаляются через 30 дней, причем вместе с вашими шмотками! Тут я понял, что я тоже попал как многие другие игроки в этой игре.
Запрос в службу технической поддержки тоже ничего увы не дал :(, там локанично послали на официальный форум, на котором я не смотря на регистрацию на форуме, не могу написать ни одного сообщения, чтобы банально убедится в том, что я услышан.
В последнее время появилось много инфы о том, что хотят ввести срок годности к предметам, очень цинично. В одном интервью, разработчики когда-то говорили, что тем кто будет редко играть, будет весьма удобно КУПИТЬ в лавке редкостей игровое преимущество. Жаль они тогда не сказали, что они хотят этот способ игры сделать основным.
Кроме того, многим игрокам без какого-либо предупреждения раздают вечный бан за использование багов игры. Повторюсь, вообще без предупреждения. На мой взгляд это уже перебор, учитывая что кого-то банили даже спустя 20 дней после нарушения.
Даже не смотря на то, что читеров сам не люблю, считаю что это очень суровое наказание для бетта версии игры с огромной кучей не исправленных багов, могли бы немного понизить уровень в качестве наказания, или вернуть уровень персонажа до момента использования бага.
Личные впечатления: графика мне понравилась, игровый мир, дух и атмосфера есть, квестов пока маленький уровень хватает, но отношение владельцев игры к игрокам, а тем более такое, убивает всякое желание когда-либо в нее играть еще, во всяком случае пока что либо не изменится. В течении всего времени с момента открытого старта игры все время было видно как настойчиво напоминают вложить денежки.
Правда от меня не получат ни копейки, хватит и того что купил игру.
Вообще, ситуация мне очень напоминает игру LRC (Lada Racing Club), тоже тогда купил как полагается (было много обещаний, рекламы), но потом был не приятно удивлен, что получил Г. за свои деньги.
Отмечу, что скачать пришлось гигабайт обновлений. Что там на гигабайт обновилось для меня загадка или rsync это не для них?
После обновления в клиенте программы перед запуском появилась надпись: "Хочешь качаться быстрее? Свитки знания и наставления помогут тебе!".
Да да, подумал я, опять втюхивают игровые предметы за игровые кристаллы, которые я до сих пор не знаю как получить, разве что только за реальные деньги.
На форумах то и дело ругаются, что очередной патч урезал какую-либо возможность нормально прокачать персонажа, или играть в составе группы и все только с одной единственной целью, чтобы покупали игровые предметы за реальные деньги.
Игроков уже довели до потеции о Передаче операторских прав на игру (подписалось уже 6 тысяч человек, причем тысяча только за последнюю неделю). С каждым новым патчем, судя по сообщениях в форумах и этой петиции, все больше появляется желающих покинуть игру.
Меня же, не смотря на все это, вывело из себя следующее.
В этой игре я приторговывал чем мог на игровом аукционе. А иначе, барыжил как мог, скупал на все свои игровые деньги руны, и потом продавал их дороже. Так я сколотил свое состояние не выйдя за пределы ворот игрового города. Надо заметить на торговлю тоже уходит время, ведь надо выставить все на аукцион. Слот с аукциона снимается обычно через сутки, и игровой предмет отправлялся в игровую почту на мое имя с сообщением о том, что предмет на аукционе никто не купил.
В общем зашел я в игру через два месяца и вижу, что в моей почте нет ни одного письма и соответственно ни одного игрового предмета, которые я непосильным трудом добыл и не смог продать на аукционе, так как игровые предметы привязаны к письмам, и оказывается письма удаляются через 30 дней, причем вместе с вашими шмотками! Тут я понял, что я тоже попал как многие другие игроки в этой игре.
Запрос в службу технической поддержки тоже ничего увы не дал :(, там локанично послали на официальный форум, на котором я не смотря на регистрацию на форуме, не могу написать ни одного сообщения, чтобы банально убедится в том, что я услышан.
 |
| Альбом: Все или ничего (The Longest Yard) |
В последнее время появилось много инфы о том, что хотят ввести срок годности к предметам, очень цинично. В одном интервью, разработчики когда-то говорили, что тем кто будет редко играть, будет весьма удобно КУПИТЬ в лавке редкостей игровое преимущество. Жаль они тогда не сказали, что они хотят этот способ игры сделать основным.
Кроме того, многим игрокам без какого-либо предупреждения раздают вечный бан за использование багов игры. Повторюсь, вообще без предупреждения. На мой взгляд это уже перебор, учитывая что кого-то банили даже спустя 20 дней после нарушения.
Даже не смотря на то, что читеров сам не люблю, считаю что это очень суровое наказание для бетта версии игры с огромной кучей не исправленных багов, могли бы немного понизить уровень в качестве наказания, или вернуть уровень персонажа до момента использования бага.
Личные впечатления: графика мне понравилась, игровый мир, дух и атмосфера есть, квестов пока маленький уровень хватает, но отношение владельцев игры к игрокам, а тем более такое, убивает всякое желание когда-либо в нее играть еще, во всяком случае пока что либо не изменится. В течении всего времени с момента открытого старта игры все время было видно как настойчиво напоминают вложить денежки.
Правда от меня не получат ни копейки, хватит и того что купил игру.
Вообще, ситуация мне очень напоминает игру LRC (Lada Racing Club), тоже тогда купил как полагается (было много обещаний, рекламы), но потом был не приятно удивлен, что получил Г. за свои деньги.
вторник, 6 апреля 2010 г.
Чаво Сбера по поводу неплатежеспособности по кредиту
У Cбербанка нашел раздел часто задаваемых вопросов, может кому интересно будет (от 6 апреля 2010 года):
3. Будет ли предоставлена отсрочка по погашению кредита заемщикам, потерявшим работу в связи с мировым финансовым кризисом?
В данный момент Сбербанком России рассматривается вопрос о возможном предоставлении отсрочек по платежам гражданам, попавшим под сокращения. На сегодняшний день вопрос и механизм осуществления данной процедуры еще не решен.
13. Что происходит с неплатежеспособными клиентами по ипотеке?
На самый крайний случай, когда исчерпаны все меры воздействия на неплательщика, у банка остается право обратить взыскание на заложенный объект недвижимости. Средства, вырученные от его продажи, направляются в счет погашения задолженности по кредиту. Если при этом остаются излишки средств, они возвращаются заемщику.
По другим банкам (петрокомерц, втб, газпромбанк, альфа банк) с ходу ответов на подобные вопросы не нашел. Может конечно плохо искал :)
3. Будет ли предоставлена отсрочка по погашению кредита заемщикам, потерявшим работу в связи с мировым финансовым кризисом?
В данный момент Сбербанком России рассматривается вопрос о возможном предоставлении отсрочек по платежам гражданам, попавшим под сокращения. На сегодняшний день вопрос и механизм осуществления данной процедуры еще не решен.
13. Что происходит с неплатежеспособными клиентами по ипотеке?
На самый крайний случай, когда исчерпаны все меры воздействия на неплательщика, у банка остается право обратить взыскание на заложенный объект недвижимости. Средства, вырученные от его продажи, направляются в счет погашения задолженности по кредиту. Если при этом остаются излишки средств, они возвращаются заемщику.
По другим банкам (петрокомерц, втб, газпромбанк, альфа банк) с ходу ответов на подобные вопросы не нашел. Может конечно плохо искал :)
вторник, 23 марта 2010 г.
Mercurial и Git
Про них наверное только ленивый не писал, вот и я решил тоже отметиться.
В свое время активно использовал на работе cvs, для контроля изменений на сайте.
На следующей работе использовал perforce и clearcase. На другой работе использовал subversion, затем mercurial, в уме держу git. Надеюсь понятно, что взгляд на системы контроля версий вполне широкий. Да и с утилитами diff, patch очень хорошо знаком.
Во первых, всегда удивляет, что пытаются сравнивать обе системы с svn, cvs, clearcase, но не между собой, когда только между собой их и можно сравнивать. С другими системами просто идеологически нельзя сравнивать. Все остальные не являются распределенными и не зависимыми от сервера. Разве что в плане функциональности сравнивать, где слияние удобнее или еще какие фишки (например, файл конфигурации в clearcase).
Как только вы теряете контакт с сервером вы никто, даже зафиксировать свои изменения не сможете, но в Mercurial и Git можете. И это главное преимущество этих двух систем Mercurial и Git перед всеми остальными.
Пока вы сидите в офисе друг напротив друга, сервачок жужит где-то рядом, все отлично работает в subversion или clearcase, слияние и ответвление, красивые графики в trac, что откуда и куда влилось и вылилось (не без напильника конечно).
Но все это идеально работает до вашей первой командировки в составе команды, когда вечером всей команде срочно требуется править код, так сказать в зависимости от суровых реалий. Когда нет не то что связи с центральным сервером, но даже некогда разбираться с wifi и bluetooth между ноутбуками, а самое верное средство обмена по прежнему флешка.
Причем subversion очень любит запоминать ip адрес сервера и даже простое вливание дампа репозитория сервера на новое место(ноутбук) не поможет, пока не зальете исходники с нового сервера(который встал на ноутбук). В результате, только какой нить merge по локальным файлам и помогает. А по приезду обратно, все начинают мучительно вливать килотонны своих изменений в subversion попутно вспоминая, что же за неделю было сделано и зачем.
Вот после пары, тройки таких командировок стал интересоваться Mercurial, но использовать стал много позже.
Во вторых, Mercurial на момент нашего интереса был более развит под windows, чем Git, сейчас у Git с этим тоже уже нет проблем. Но хочется отметить отличия. Mercurial в основном написан на Python с мелкими вкраплениями на C. В отличие от Git, который целиком написан на с и имеет много зависимостей с архитектурой linux, иначе бы не отвязывали так долго. Соответственно установить mercurial на хостинге с существующим python проще. Но Git в хороших традициях linux/unix состоит из набора консольных программ, чтобы их можно было легко использовать в скриптах на bash, tcl/tk. Соответственно, с Mercurial интереснее взаимодействовать через python, а с Git через обычный ввод/вывод.
В третьих, собственно интерес к Git был однажды снова подогрет после прочтения презентации про Git Линусом Торвальдсом и сравнения двух этих систем на code.google.com.
В качестве фишки, которой меня манил Git, был индекс похожести (similarity index). Дело все в том, что Git ведет не историю отдельных файлов, а сразу историю всех изменений в файловой системе в целом. Если вы переименуете один файл в другой, то Git это легко найдет, так как хэш sha1 двух файлов будет один и тот же, только изменится название файла. Это весьма важная вещь, знать откуда у тебя на самом деле взялся файл, особенно, если он был копией другого уже существующего файла (это конечно можно сделать административно :D).
Но как известно хотелось большего. Цитирую из презентации: "Одно из особенных свойств git — отслеживание изменений всего содержимого, и это отличает git даже от Mercurial, несмотря на то, что они очень похожи. "
В общем, в тайне надеялся, что в Git реализовано отслеживание перемещения кусков кода из одного файла в другой или их размножение путем копирования в рамках одного файла. То есть, увидеть, что какой-то кусок кода был взят из другого проекта, и потом немного исправлен. Я понимаю, несколько утопично, особенно если представить, что for копируется везде где только можно, с легкими изменениями в рамках одной строки :D.
Но увы моя мечта не сбылась, все что удалось добиться сейчас от Git, так это то, что Git может показать, что файл с такой-то вероятностью является копией другого файла, так как его после копирования изменили до неузнаваемости. Да и то для этого надо передать серию волшебных ключиков.
Это максимум что удалось добиться. Кстати, чтобы git легко находил копии файлов рекомендуется на каждый чих делать фиксацию изменений, иначе копию можно изменить до не узнаваемости :D на момент фиксации.
Сейчас я считаю утопичным мое желание, так как оно мне в общем-то ничего не дает, и заодно сильно усложняет сам git, так как задача поиска одинаковых кусков кода по исходникам весьма не простая.
Во всяком случае видеть ее реализацию хотелось бы пожалуй уже немного в другой форме. Например, в утилите blame, когда по участку кода, можно было бы попросить найти, то место откуда код был взят, а не только кто автор. Чтобы проследить эволюцию кода. Также хотелось бы видеть эволюцию кода не только вниз но и вверх, может мою функцию кто нибудь у себя улучшил, а я не знаю, или наоборот в коде предке уже ошибку исправили, а я все еще пользуюсь старой копией ошибочного кода из другого проекта (по идее такоей код надо выделить в подпроекты).
В последних, хотелось бы обратить внимание на то, что Mercurial больше подходит для не больших проектов, к тому же он в самом деле проще в освоении, чем Git в котором только для того, чтобы научиться просмотреть изменения, мне понадобилось перечитать кучу документации и потратить уйму времени, не менее часа. Но Git предоставляет достаточно много опций и утилит облегчающих контроль большого проекта.
Например, способ с помощью которого легко найти проблемный commit, который испортил сборку всего проекта не проверяя каждый commit в отделььности, а лишь только сообщая какой из тысячи commit-ов после теста оказался проблемным или не проблемным. Не простая задача, и таких мелочей в Git много.
Например, возможность добавления в уже зафиксированное изменение забытых файлов, которые вы просто забыли добавить, не создавать же для этого в репозитории отдельное изменение.
В свое время активно использовал на работе cvs, для контроля изменений на сайте.
На следующей работе использовал perforce и clearcase. На другой работе использовал subversion, затем mercurial, в уме держу git. Надеюсь понятно, что взгляд на системы контроля версий вполне широкий. Да и с утилитами diff, patch очень хорошо знаком.
Во первых, всегда удивляет, что пытаются сравнивать обе системы с svn, cvs, clearcase, но не между собой, когда только между собой их и можно сравнивать. С другими системами просто идеологически нельзя сравнивать. Все остальные не являются распределенными и не зависимыми от сервера. Разве что в плане функциональности сравнивать, где слияние удобнее или еще какие фишки (например, файл конфигурации в clearcase).
Как только вы теряете контакт с сервером вы никто, даже зафиксировать свои изменения не сможете, но в Mercurial и Git можете. И это главное преимущество этих двух систем Mercurial и Git перед всеми остальными.
Пока вы сидите в офисе друг напротив друга, сервачок жужит где-то рядом, все отлично работает в subversion или clearcase, слияние и ответвление, красивые графики в trac, что откуда и куда влилось и вылилось (не без напильника конечно).
Но все это идеально работает до вашей первой командировки в составе команды, когда вечером всей команде срочно требуется править код, так сказать в зависимости от суровых реалий. Когда нет не то что связи с центральным сервером, но даже некогда разбираться с wifi и bluetooth между ноутбуками, а самое верное средство обмена по прежнему флешка.
Причем subversion очень любит запоминать ip адрес сервера и даже простое вливание дампа репозитория сервера на новое место(ноутбук) не поможет, пока не зальете исходники с нового сервера(который встал на ноутбук). В результате, только какой нить merge по локальным файлам и помогает. А по приезду обратно, все начинают мучительно вливать килотонны своих изменений в subversion попутно вспоминая, что же за неделю было сделано и зачем.
Вот после пары, тройки таких командировок стал интересоваться Mercurial, но использовать стал много позже.
Во вторых, Mercurial на момент нашего интереса был более развит под windows, чем Git, сейчас у Git с этим тоже уже нет проблем. Но хочется отметить отличия. Mercurial в основном написан на Python с мелкими вкраплениями на C. В отличие от Git, который целиком написан на с и имеет много зависимостей с архитектурой linux, иначе бы не отвязывали так долго. Соответственно установить mercurial на хостинге с существующим python проще. Но Git в хороших традициях linux/unix состоит из набора консольных программ, чтобы их можно было легко использовать в скриптах на bash, tcl/tk. Соответственно, с Mercurial интереснее взаимодействовать через python, а с Git через обычный ввод/вывод.
В третьих, собственно интерес к Git был однажды снова подогрет после прочтения презентации про Git Линусом Торвальдсом и сравнения двух этих систем на code.google.com.
В качестве фишки, которой меня манил Git, был индекс похожести (similarity index). Дело все в том, что Git ведет не историю отдельных файлов, а сразу историю всех изменений в файловой системе в целом. Если вы переименуете один файл в другой, то Git это легко найдет, так как хэш sha1 двух файлов будет один и тот же, только изменится название файла. Это весьма важная вещь, знать откуда у тебя на самом деле взялся файл, особенно, если он был копией другого уже существующего файла (это конечно можно сделать административно :D).
Но как известно хотелось большего. Цитирую из презентации: "Одно из особенных свойств git — отслеживание изменений всего содержимого, и это отличает git даже от Mercurial, несмотря на то, что они очень похожи. "
В общем, в тайне надеялся, что в Git реализовано отслеживание перемещения кусков кода из одного файла в другой или их размножение путем копирования в рамках одного файла. То есть, увидеть, что какой-то кусок кода был взят из другого проекта, и потом немного исправлен. Я понимаю, несколько утопично, особенно если представить, что for копируется везде где только можно, с легкими изменениями в рамках одной строки :D.
Но увы моя мечта не сбылась, все что удалось добиться сейчас от Git, так это то, что Git может показать, что файл с такой-то вероятностью является копией другого файла, так как его после копирования изменили до неузнаваемости. Да и то для этого надо передать серию волшебных ключиков.
git diff --find-copies-harder --pickaxe-all --color HEAD~2 diff --git a/6.txt b/10.txt similarity index 80% copy from 6.txt copy to 10.txt index f8e89fb..cf9ebe7 100644 --- a/6.txt +++ b/10.txt @@ -1,3 +1,4 @@ +888 111 222 333 @@ -5,4 +6,3 @@ 555 666 777 -888 diff --git a/7.txt b/7.txt new file mode 100644 index 0000000..1bfd9c2 --- /dev/null +++ b/7.txt @@ -0,0 +1,5 @@ +111 +222 +333 +444 + diff --git a/8.txt b/8.txt new file mode 100644 index 0000000..92263e5 --- /dev/null +++ b/8.txt @@ -0,0 +1,5 @@ +444 +555 +666 +777 +888 diff --git a/6.txt b/9.txt similarity index 80% copy from 6.txt copy to 9.txt index f8e89fb..cf9ebe7 100644 --- a/6.txt +++ b/9.txt @@ -1,3 +1,4 @@ +888 111 222 333 @@ -5,4 +6,3 @@ 555 666 777 -888
Это максимум что удалось добиться. Кстати, чтобы git легко находил копии файлов рекомендуется на каждый чих делать фиксацию изменений, иначе копию можно изменить до не узнаваемости :D на момент фиксации.
Сейчас я считаю утопичным мое желание, так как оно мне в общем-то ничего не дает, и заодно сильно усложняет сам git, так как задача поиска одинаковых кусков кода по исходникам весьма не простая.
Во всяком случае видеть ее реализацию хотелось бы пожалуй уже немного в другой форме. Например, в утилите blame, когда по участку кода, можно было бы попросить найти, то место откуда код был взят, а не только кто автор. Чтобы проследить эволюцию кода. Также хотелось бы видеть эволюцию кода не только вниз но и вверх, может мою функцию кто нибудь у себя улучшил, а я не знаю, или наоборот в коде предке уже ошибку исправили, а я все еще пользуюсь старой копией ошибочного кода из другого проекта (по идее такоей код надо выделить в подпроекты).
В последних, хотелось бы обратить внимание на то, что Mercurial больше подходит для не больших проектов, к тому же он в самом деле проще в освоении, чем Git в котором только для того, чтобы научиться просмотреть изменения, мне понадобилось перечитать кучу документации и потратить уйму времени, не менее часа. Но Git предоставляет достаточно много опций и утилит облегчающих контроль большого проекта.
Например, способ с помощью которого легко найти проблемный commit, который испортил сборку всего проекта не проверяя каждый commit в отделььности, а лишь только сообщая какой из тысячи commit-ов после теста оказался проблемным или не проблемным. Не простая задача, и таких мелочей в Git много.
Например, возможность добавления в уже зафиксированное изменение забытых файлов, которые вы просто забыли добавить, не создавать же для этого в репозитории отдельное изменение.
среда, 17 февраля 2010 г.
SynchroTron TiddlyWiki или распределенная совместная работа с wiki без сервера почти как в Mercurial или Git
Недавно подсел на TiddlyWiki, wiki которой не нужен сервер, php, базы данных, нужен только клиент в виде браузера IE6.0 и выше, Firefox-1.5 и выше.
Опишу кратенько фишки, которые мне понравились:
1) не нужен сервер, только браузер;
2) все в одном html файле c javascript в нем же;
3) можно указать адрес другой TiddlyWiki сиcтемы, просмотреть список всех статей и плагинов, выбрать нужные и импортировать к себе в вашу локальную wiki;
4) большое количество разномастных плагинов.
И фишки, которые не понравились:
1) все в одном файле, как следствие пухнет, но есть плагин, который позволяет раскидать статьи по нескольким html файлам (в файлах должна быть таже TiddlyWiki), с загрузкой данных из них по требованию, сам не пробовал, но как решение данного недостатка думаю в самый раз;
2) некоторые вещи связанные с интерфейсом, но это все изменяемо.
Использовать ее удобно как wiki описание к проекту. Вы кладете html файл к вашим исходниками, можете закинуть даже в систему контроля версий и получаете wiki систему в которой можете описывать ваш проект, вести его и так далее. На мой взгляд, то что надо. И для этого не надо ставить Apache+Python|PHP|Perl+SQLite|MySQL|PostgreSQL и быть привязанным к серверу, как коза веревкой к колу.
Но мне этого показалось мало, в последнее время я немного был увлечен распределенными системами контроля версий Mercurial и Git. И думал, как бы было удобно, если бы эта wiki имела интеграцию с ними. Я имею ввиду для отслеживания изменений в самой wiki, а не для вывода состояния репозитория в Mercurial или Git как в Trac, и при этом иметь такое же удобство ведения ответвлений как в этих системах.
Я быстренько это дело по-google-ил, и случайно нашел нечто немного другое, но оказавшееся тем, что фактически я и искал.
Наткнулся я на проект SynchroTron (скачать, описание) - Javascript библиотека позволяющая вам осуществить diff, diff3, merge и контроль версий прямо на javascript от вот этой замечательной компании Osmosoft. Кстати, они разрабатывают проект TiddlyWeb, основная задача которого обеспечить доступ к TiddlyWiki через удобное HTTP API, серверная часть там реализована на Python. Мне эта часть была не особо нужна, но раз ее уже придумали, то просто отлично и это еще один повод позаниматься TiddlyWiki подробнее.
Но я отвлекся, суть работы diff на javascript в том, что вы передаете пару фрагментов текста, вызываете diff и получаете различия в виде json массива:
Кстати у google в этом плане оказывается тоже есть наработки и думаю если поискать внимательно на sf.net, то парочка еще точно найдется.
Дальше больше, эту тему они развили здесь Diff for Javascript, revisited, где json массив стал походить не на обычный побуквенный diff, а на вывод в формате patch, в котором указывается также смещение и длинна измененного текста, такой вариант уже будет легко приспособить, чтобы покрасить нужные буквы в нужный цвет при отображении разницы одного текста от другого, вот пример ответа:
Но на этом они не остановились, они реализовали merge, теперь в json находится померженный текст, с указанием конфликтных мест слияния:
Грубо говоря, они создали весьма удобные в использовании функции. Кстати снова не забудем google, ведь у них тоже есть нечто подобное.
Там же вы найдете презентацию Distributed Version Control in JavaScript or any other language that takes your fancy. Tony Garnock-Jones tonyg@lshift.net
LShift Ltd.
в которой присутствуют работающие ссылки на демо страницы.
Думаю те кто использует Mercurial или Git взглянув на следующий скриншот сильно заинтересуются, увидев знакомые ветвистые деревья, есть некоторое сходство :D, но есть разница. Все это на javascript.
Другими словами, в SynchroTron они сделали систему контроля версий на Javascript, которая управляет наборами JSON структур (файлов же нет на javascript :)). Все что я здесь указал кратенько там рассказано, только по английски. Так же там указаны javascript библиотеки, которые они использовали для реализации той иной задачи, думаю это любопытно для тех кто пишет на javascript.
В результате всего этого я все таки наткнулся также на следующую статью: Adding distributed version control to TiddlyWiki, тут у меня задражали пальцы при наборе ссылки, неужели все это дело они уже успели еще до кучи впихнуть в TiddlyWiki? В общем так оно и случилось :)
Добро пожаловать на SynchroTron TiddlyWiki.
Cамое интересное вы увидите на вкладке Versions, которую надо выбрать, она справа от центра.
На следующем рисунке
вы увидите дерево ревизий. Выбрав checkout на одной из ревизии вы увидите, что содержимое статей в wiki изменяется, а также изменяется и состав статей. Дерево отсортировано всегда хронологически.
Самые пытливые заметят пункт Merge и слияние двух веток в одной ревизии. Да, да, да! Это банальное слияние состояний вашей wiki.
Но самые пытливые из пытливых отметят еще и пункт Import! С его помощью вы можете указать другую локальную TiddlyWiki, откуда вы можете импортировать новые и возможно даже измененные существующие уже в вашей TiddlyWiki статьи. После импорта у вас появится ответвление, с которым вы можете смержиться.
Все отличающиеся не конфликтные статьи просто изменяться, а все конфликтные откроются и будет предложено исправить все конфликты вручную, но ведь это wiki, править надо именно wiki текст, а не голый html!
На следующем рисунке вы увидите результат моего эксперимента по импорту статей из второй wiki в первую. Вторая wiki, ранее была создана копированием из первой, потом в первой и второй wiki в строке 222 и 555 в первой и второй теме соответственно были изменены цифры (в 1-й wiki на 7, а во 2-й wiki на 8), чтобы получить конфликт при слиянии сразу в двух темах. На рисунке вы собственно видите, предложение поправить конфликт после импорта первой и второй темы из второй wiki в первую.
Чтобы воспользовваться этим в своей TiddlyWiki достаточно у себя выбрать пункт import указать адрес http://hg.opensource.lshift.net/synchrotron/raw-file/default/tiddlywiki/tiddlydvcs.html и импортировать к себе все пункты, после чего вкладка Versions появится и у вас :) И вы получите wiki движок с распределенной системой контроля версий wiki в одном флаконе и для работы с ним нужен только браузер, а для обмена статьями в таком случае, только html файл c изменившимися статьями.
Совсем недавно наткнулся на еще одну статью полностью на английском языке про это же самое, но только собрано все на одной странице и конкретизировано.
Опишу кратенько фишки, которые мне понравились:
1) не нужен сервер, только браузер;
2) все в одном html файле c javascript в нем же;
3) можно указать адрес другой TiddlyWiki сиcтемы, просмотреть список всех статей и плагинов, выбрать нужные и импортировать к себе в вашу локальную wiki;
4) большое количество разномастных плагинов.
И фишки, которые не понравились:
1) все в одном файле, как следствие пухнет, но есть плагин, который позволяет раскидать статьи по нескольким html файлам (в файлах должна быть таже TiddlyWiki), с загрузкой данных из них по требованию, сам не пробовал, но как решение данного недостатка думаю в самый раз;
2) некоторые вещи связанные с интерфейсом, но это все изменяемо.
Использовать ее удобно как wiki описание к проекту. Вы кладете html файл к вашим исходниками, можете закинуть даже в систему контроля версий и получаете wiki систему в которой можете описывать ваш проект, вести его и так далее. На мой взгляд, то что надо. И для этого не надо ставить Apache+Python|PHP|Perl+SQLite|MySQL|PostgreSQL и быть привязанным к серверу, как коза веревкой к колу.
Но мне этого показалось мало, в последнее время я немного был увлечен распределенными системами контроля версий Mercurial и Git. И думал, как бы было удобно, если бы эта wiki имела интеграцию с ними. Я имею ввиду для отслеживания изменений в самой wiki, а не для вывода состояния репозитория в Mercurial или Git как в Trac, и при этом иметь такое же удобство ведения ответвлений как в этих системах.
Я быстренько это дело по-google-ил, и случайно нашел нечто немного другое, но оказавшееся тем, что фактически я и искал.
Наткнулся я на проект SynchroTron (скачать, описание) - Javascript библиотека позволяющая вам осуществить diff, diff3, merge и контроль версий прямо на javascript от вот этой замечательной компании Osmosoft. Кстати, они разрабатывают проект TiddlyWeb, основная задача которого обеспечить доступ к TiddlyWiki через удобное HTTP API, серверная часть там реализована на Python. Мне эта часть была не особо нужна, но раз ее уже придумали, то просто отлично и это еще один повод позаниматься TiddlyWiki подробнее.
Но я отвлекся, суть работы diff на javascript в том, что вы передаете пару фрагментов текста, вызываете diff и получаете различия в виде json массива:
diff("the quick brown fox jumped over".split(/\s+/), "the quick fox jumps over".split(/\s+/))
[{common:["the","quick"]}, {file1:["brown"], file2:[]}, {common:["fox"]}, {file1:["jumped"], file2:["jumps"]}, {common:["over"]}]
Кстати у google в этом плане оказывается тоже есть наработки и думаю если поискать внимательно на sf.net, то парочка еще точно найдется.
Дальше больше, эту тему они развили здесь Diff for Javascript, revisited, где json массив стал походить не на обычный побуквенный diff, а на вывод в формате patch, в котором указывается также смещение и длинна измененного текста, такой вариант уже будет легко приспособить, чтобы покрасить нужные буквы в нужный цвет при отображении разницы одного текста от другого, вот пример ответа:
[{file1:{offset:2, length:1, chunk:["brown"]}, file2:{offset:2, length:0, chunk:[]}}, {file1:{offset:4, length:1, chunk:["jumped"]}, file2:{offset:3, length:1, chunk:["jumps"]}}, {file1:{offset:6, length:1, chunk:["a"]}, file2:{offset:5, length:2, chunk:["some", "lazy"]}}]
Но на этом они не остановились, они реализовали merge, теперь в json находится померженный текст, с указанием конфликтных мест слияния:
js> uneval(Diff.diff3_merge(derived1, base, derived2, true)); [{ok:["the", "quick", "fox", "jumps", "over"]}, {conflict:{a:["some", "lazy"], aIndex:5, o:["a"], oIndex:6, b:["some", "record"], bIndex:6}}, {ok:["dog"]}]
Грубо говоря, они создали весьма удобные в использовании функции. Кстати снова не забудем google, ведь у них тоже есть нечто подобное.
Там же вы найдете презентацию Distributed Version Control in JavaScript or any other language that takes your fancy. Tony Garnock-Jones tonyg@lshift.net
LShift Ltd.
в которой присутствуют работающие ссылки на демо страницы.
Diff Demo | LShift Ltd. Google |
Diff3 or Merge Demo | LShift Ltd. Google |
DVCS Demo | LShift Ltd. Google (?oops) |
Думаю те кто использует Mercurial или Git взглянув на следующий скриншот сильно заинтересуются, увидев знакомые ветвистые деревья, есть некоторое сходство :D, но есть разница. Все это на javascript.
 |
| Альбом: Все или ничего (The Longest Yard) |
Другими словами, в SynchroTron они сделали систему контроля версий на Javascript, которая управляет наборами JSON структур (файлов же нет на javascript :)). Все что я здесь указал кратенько там рассказано, только по английски. Так же там указаны javascript библиотеки, которые они использовали для реализации той иной задачи, думаю это любопытно для тех кто пишет на javascript.
В результате всего этого я все таки наткнулся также на следующую статью: Adding distributed version control to TiddlyWiki, тут у меня задражали пальцы при наборе ссылки, неужели все это дело они уже успели еще до кучи впихнуть в TiddlyWiki? В общем так оно и случилось :)
Добро пожаловать на SynchroTron TiddlyWiki.
Cамое интересное вы увидите на вкладке Versions, которую надо выбрать, она справа от центра.
На следующем рисунке
 |
| Альбом: Все или ничего (The Longest Yard) |
вы увидите дерево ревизий. Выбрав checkout на одной из ревизии вы увидите, что содержимое статей в wiki изменяется, а также изменяется и состав статей. Дерево отсортировано всегда хронологически.
Самые пытливые заметят пункт Merge и слияние двух веток в одной ревизии. Да, да, да! Это банальное слияние состояний вашей wiki.
Но самые пытливые из пытливых отметят еще и пункт Import! С его помощью вы можете указать другую локальную TiddlyWiki, откуда вы можете импортировать новые и возможно даже измененные существующие уже в вашей TiddlyWiki статьи. После импорта у вас появится ответвление, с которым вы можете смержиться.
Все отличающиеся не конфликтные статьи просто изменяться, а все конфликтные откроются и будет предложено исправить все конфликты вручную, но ведь это wiki, править надо именно wiki текст, а не голый html!
На следующем рисунке вы увидите результат моего эксперимента по импорту статей из второй wiki в первую. Вторая wiki, ранее была создана копированием из первой, потом в первой и второй wiki в строке 222 и 555 в первой и второй теме соответственно были изменены цифры (в 1-й wiki на 7, а во 2-й wiki на 8), чтобы получить конфликт при слиянии сразу в двух темах. На рисунке вы собственно видите, предложение поправить конфликт после импорта первой и второй темы из второй wiki в первую.
 |
| Альбом: Все или ничего (The Longest Yard) |
Чтобы воспользовваться этим в своей TiddlyWiki достаточно у себя выбрать пункт import указать адрес http://hg.opensource.lshift.net/synchrotron/raw-file/default/tiddlywiki/tiddlydvcs.html и импортировать к себе все пункты, после чего вкладка Versions появится и у вас :) И вы получите wiki движок с распределенной системой контроля версий wiki в одном флаконе и для работы с ним нужен только браузер, а для обмена статьями в таком случае, только html файл c изменившимися статьями.
Совсем недавно наткнулся на еще одну статью полностью на английском языке про это же самое, но только собрано все на одной странице и конкретизировано.
среда, 10 февраля 2010 г.
Видеозапись семинаров
Посмотрел тут на видео одного из семинаров, не буду говорить на какую тему, но без слез не взглянешь, уж лучше бы просто выложили электронные презентации, чем так позорится. Люди, не надо позволять себя снимать на вашей первой презентации. Думаю, что только человек проведший не один семинар на ту же самую тему может достойно выступить и рассказать внятно свою тему. Остальное, не подготовленные семинары ни на ком не опробованные.
пятница, 5 февраля 2010 г.
О памяти
Мне кажется, что мысли так редко приходящие мне в голову, забываются со вренем лишь только потому, что они не сгруппированы, не приводят к какой-то завершенной большой и изящной, четко оформленной мысли или суждению о предмете. То есть, набор ни с чем не связанных мыслей подобен хаосу, который просто невозможно не забыть. Может поэтому свои мысли стоит записывать.
Подписаться на:
Сообщения (Atom)
Сообщения
