среда, 30 мая 2012 г.
вторник, 15 мая 2012 г.
РЖД непорядочность
Хочу обратить внимание пользователей сайта rzd.ru, на непорядочное отношение компании по отношению к клиентам.
Недавно я купил там два билета on-line для родственника. Распечатав бланк заказа, понял, что ошибся с датой отправления поезда в одном из билетов. Пришлось купить третий билет, вместо ошибочного.
Далее предлагаю посмотреть результат переписки со службой поддержки:
Вот такая отписка и больше ничего. Как будто я просил их подтвердить ещё раз что останусь без уплаченных денег. Всё что хотелось бы получить в ответ: "Ваша проблема будет донесена до руководства и будет обсуждаться. Постараемся учесть ваши пожелания". Фраза "Меняемся для Вас" видимо для красоты написана. Наверно отсутствие конкуренции даёт РЖД возможность так относиться к людям.
Updated:
Спустя некоторое время, когда поезд ушёл, в прямом смысле этого слова, половину денег всё же вернули. Оправдывает ли это работу службы РЖД с клиентами решайте сами.
Updated:
РЖД с некоторого времени дало возможность возвращать билеты онлайн, в чем можно убедиться зайдя на их сайт. Все-таки здравый смысл возобладал. Условия возврата я не глядел, думаю вы сами сможете с ними ознакомиться. С чем я их и вас, как их клиентов, и поздравляю.
Здравствуйте.
На сайте rzd.ru я ошибочно приобрёл билет на другого человека. Осознав ошибку в этот же день, я попытался узнать в справочной как мне вернуть его.
После звонка в справочную выяснилось, что вернуть его мне лично в кассу невозможно, не смотря на то что деньги были уплачены с моей карты.
Человек, на которого покупался билет, не сможет вернуть его до отправки поезда, так сложились обстоятельства. Доверенность оформить на меня он тоже не может. Стало быть возврат денег невозможен.
Хотелось бы, чтоб вы внесли корректировки в работу сайта и облегчили жизнь вашим клиентам, включив электронную отмену билета, ведь присваивать деньги за неоказанную услугу как-то нехорошо.
Номер заказа:
735XXXXXXXXX45
С уважением, XXX.
Уважаемый XXX!
Благодарим Вас за обращение в Единый Информационно-Сервисный Центр ОАО «РЖД».
Ответ на Ваш запрос находится во вложенном файле.
Вы можете оценить качество обслуживания по ссылке: ССЫЛКА ДЛЯ ОЦЕНКИ
С уважением,
Мария Наумова,
ЕИСЦ ОАО «РЖД». Меняемся для Вас.
www.rzd.ru
тел. 8-800-775-00-00
быстро, доступно, бесплатно, круглосуточно
Вот такая отписка и больше ничего. Как будто я просил их подтвердить ещё раз что останусь без уплаченных денег. Всё что хотелось бы получить в ответ: "Ваша проблема будет донесена до руководства и будет обсуждаться. Постараемся учесть ваши пожелания". Фраза "Меняемся для Вас" видимо для красоты написана. Наверно отсутствие конкуренции даёт РЖД возможность так относиться к людям.
Updated:
Спустя некоторое время, когда поезд ушёл, в прямом смысле этого слова, половину денег всё же вернули. Оправдывает ли это работу службы РЖД с клиентами решайте сами.
Updated:
РЖД с некоторого времени дало возможность возвращать билеты онлайн, в чем можно убедиться зайдя на их сайт. Все-таки здравый смысл возобладал. Условия возврата я не глядел, думаю вы сами сможете с ними ознакомиться. С чем я их и вас, как их клиентов, и поздравляю.
воскресенье, 22 апреля 2012 г.
суббота, 14 апреля 2012 г.
NRKTK - Razocharovanie goda
По-началу подумал, что ребята выложили что-то из своего старого репертуара :) Нет, просто стиль почти не поменялся. Всё тот же вокал из мегафона. На мастеринг денег наверно опять не хватило. Заценивайте новый альбом группы.
Razocharovanie goda by NRKTK
Razocharovanie goda by NRKTK
вторник, 10 апреля 2012 г.
Неприкасаемые (Intouchables)
Если вдруг вы не посмотрели еще этот французский фильм, обязательно сделайте это. По-крайней мере будет о чём вспомнить по прошествии года. Как написано в титрах фильм основан на реальных событиях. Обещаю, что грустить об инвалиде не придётся, но и смеяться в истерике вы не будете. Рейтинг IMDb: 8.40, Кинопоиск: 8.858.
Чистой комедией, сродни тем что освоили Луи де Фюнес или Сами Насери, это кино назвать совсем нельзя, как вобщем-то и драмой. Мои ожидания фильм оправдал, а ваши? *)
Чистой комедией, сродни тем что освоили Луи де Фюнес или Сами Насери, это кино назвать совсем нельзя, как вобщем-то и драмой. Мои ожидания фильм оправдал, а ваши? *)
четверг, 29 марта 2012 г.
Установка vmware workstation под OpenSuse
Чтобы поставить Vmware Workstation на СюСю нужно:
1. слить vm-дистрибутив отседа:
Updated: part2
1. слить vm-дистрибутив отседа:
http://downloads.vmware.com/d/details/wkst_802_lx/dCVkYnRAQGVidHQldw==
kernel-source, make, gcc, gcc-c++, binutils, patch
chmod +x *.bundle
sudo ./
> ./usr/bin/vmware
Logging to /tmp/vmware-mgaev/modconfig-8102.log
ERROR: modinfo: could not find module vmmon
ERROR: modinfo: could not find module vmnet
ERROR: modinfo: could not find module vmblock
ERROR: modinfo: could not find module vmci
ERROR: modinfo: could not find module vsock
ERROR: modinfo: could not find module vmmon
ERROR: modinfo: could not find module vmnet
ERROR: modinfo: could not find module vmblock
ERROR: modinfo: could not find module vmci
ERROR: modinfo: could not find module vsock
....
sudo vmware-modconfig --console --install-all
> ./usr/bin/vmware
Updated: part2
вторник, 20 марта 2012 г.
Работа с различными VCS
Много есть различных статей на тему использования Version Control System или Revision Control System. И я решил немного написать о тех VCS с которыми имел дело.
Первая из них, и на мой взгляд наиболее юзабельная, для коллективной разработки Team Foundation System от Microsoft. Про то как устроена серверная часть знают далеко не все, и я не исключение. Думаю не стоит заострять на этом внимание рядовых разработчиков. Нам, разработчикам, интересен именно клиентский софт и интеграция с IDE. В случае с TFS клиенту предоставляются такие варианты: интеграция с Visual Studio, интеграция с контекстным меню Explorer-а, плагин для Eclipse, возможно еще что-то. Примерный перечень команд виден со скрина:
Типичный алгоритм работы:
1. "Get Latest Version", либо "Get Specific Version".
2. Делаем "Checkout for Edit...". Там выбираются файлы с которыми вы будете работать, можно их заблокировать для того, чтобы их никто больше не брал для редактирования (это делает редко). В IDE всегда есть возможность посмотреть кто на данный момент с какими файлами работает. И всегда есть возможность сравнить вашу версию файлов с версией любой ревизии. Ревизии идут по порядку.
3. Меняем код.
4. Делаем "Check In Pending Changes...", если он активный. И скорей всего вас попросят сделать "Get Latest Version", либо он сам приедет с сервера, либо вам придётся это сделать, чтобы продолжить работу.
5. При возникновении конфликтов, а конфликты возникают далеко не часто. Обычно они разрешаются системой автоматически. При checkout-е система запоминает, когда вы взяли файлы, и на основании этого понимает какие изменения произошли позже, какие раньше. Итак, при возникновении конфликтов, вы можете разрешить их в любой удобной для вас программе, если вас не устраивает встроенный в IDE merge/compare редактор. Итогом разрешённого конфликта будет сохранение файла под его естественным именем.
6. Делаем "Check In Pending Changes...".
Вторая VCS хорошо известна всем. И интеграция с ней есть везде. SVN с перечнем команд:
Типичный алгоритм работы:
1. Checkout - просто скачивается весь или часть репозитория. Либо Update, в случае если он у вас уже есть и вы его давненько скачали. Ревизии идут по порядку.
2. Меняем код.
3. В эклипсе очень удобно ткнуть Synchronize. При этом у вас появится окно, где можно будет увидеть существуют ли какие-либо конфликты с тем что находится на сервере. Если такие имеются, то вы можете скажем откатить изменения на каких-либо поменяных вами локально файлах.
4. Делается Commit, который скидывает всё что вы наделали на сервер.
5. При возникновении конфликтов происходит/делается Update, и вы можете их разрешить опять же в различных merge/compare тулзах, если вас не устраивают встроенные средства IDE. Результатом разрешения конфликта становится файл, под своим естественным названием помеченный как merged.
6. Делается Commit, который скидывает всё что вы наделали на сервер.
Третья система контроля версий Git. Интеграция IDE с ней появилась относительно недавно, и везде очень "по разному". От первых двух она отличается тем, что вам сразу без вариантов предлагают двухуровневую схему наката изменений. Кто-то считает, что в этом заключается одно из преимуществ git-а перед остальными. Вы можете обходиться вообще без сервера. Локальная копия репозитория может жить автономно. Скриншот не вмещает всего многообразия операций:
Нетипичный для Git, но типичный для вышеупомянутых VCS режим работы:
1. Делается Clone репозитория. Далее делается Checkout интересующей ветки. Обычно это master - ветка (origin/master). Ревизий как таковых нет, есть commit-ы.
2. Меняем код.
3. Делаем Commit, при этом изменения улетают в локальный репозиторий.
4. Делаем Push, чтобы изменения локальной ветки master улетели на сервер.
5. Возникли конфликты! Делаем Pull - изменения с сервера прилетают в локальный репозиторий. Тут-то мы их и мерджим. Результатом работы merge является файл под своим именем, помеченный как stage.
6. Как финальная стадия merge-операции делается Commit. Или Commit & Push.
7. Вобщем вы решили конфликты у себя локально, а теперь будьте любезны скинуть всё это добро на сервер. Делаем Push.
Более рассказывать про иные VCS я не сподоблюсь. Как видно из этого описания, работа с SVN и с TFS происходит примерно одинаково. За исключением того, что SVN всё-таки более ущербен, хотя-бы потому что у него в каждой папке вашего "родного" содержимого спрятаны свои служебные каталоги. УЖОСНАХ. Ну а последняя VCS заставляет разработчика быть более квалифицированный в процессах слияния. Ну кому нужны проблемы с разрешением конфликтов и осознавание того, в какой ветке вам нужно работать?? Да никому. Написал код, слил на сервер - ура, свободен. А в Git люди тащутся от того как они эти изменения вносят. Это на самом деле работа релиз-менеджера. Релизы разделены по отдельным веткам. И он решает нужно ли вносить ваши изменения в ту или иную ветку. Ну а для вас, как разработчика, существует одна текущая, и она же последняя ветка.
С нетерпением ждите следующего поста, про Git. Там я опишу, как можно, всё-таки не поседев, уживаться с этим зверем.
Первая из них, и на мой взгляд наиболее юзабельная, для коллективной разработки Team Foundation System от Microsoft. Про то как устроена серверная часть знают далеко не все, и я не исключение. Думаю не стоит заострять на этом внимание рядовых разработчиков. Нам, разработчикам, интересен именно клиентский софт и интеграция с IDE. В случае с TFS клиенту предоставляются такие варианты: интеграция с Visual Studio, интеграция с контекстным меню Explorer-а, плагин для Eclipse, возможно еще что-то. Примерный перечень команд виден со скрина:
Типичный алгоритм работы:
1. "Get Latest Version", либо "Get Specific Version".
2. Делаем "Checkout for Edit...". Там выбираются файлы с которыми вы будете работать, можно их заблокировать для того, чтобы их никто больше не брал для редактирования (это делает редко). В IDE всегда есть возможность посмотреть кто на данный момент с какими файлами работает. И всегда есть возможность сравнить вашу версию файлов с версией любой ревизии. Ревизии идут по порядку.
3. Меняем код.
4. Делаем "Check In Pending Changes...", если он активный. И скорей всего вас попросят сделать "Get Latest Version", либо он сам приедет с сервера, либо вам придётся это сделать, чтобы продолжить работу.
5. При возникновении конфликтов, а конфликты возникают далеко не часто. Обычно они разрешаются системой автоматически. При checkout-е система запоминает, когда вы взяли файлы, и на основании этого понимает какие изменения произошли позже, какие раньше. Итак, при возникновении конфликтов, вы можете разрешить их в любой удобной для вас программе, если вас не устраивает встроенный в IDE merge/compare редактор. Итогом разрешённого конфликта будет сохранение файла под его естественным именем.
6. Делаем "Check In Pending Changes...".
Вторая VCS хорошо известна всем. И интеграция с ней есть везде. SVN с перечнем команд:
Типичный алгоритм работы:
1. Checkout - просто скачивается весь или часть репозитория. Либо Update, в случае если он у вас уже есть и вы его давненько скачали. Ревизии идут по порядку.
2. Меняем код.
3. В эклипсе очень удобно ткнуть Synchronize. При этом у вас появится окно, где можно будет увидеть существуют ли какие-либо конфликты с тем что находится на сервере. Если такие имеются, то вы можете скажем откатить изменения на каких-либо поменяных вами локально файлах.
4. Делается Commit, который скидывает всё что вы наделали на сервер.
5. При возникновении конфликтов происходит/делается Update, и вы можете их разрешить опять же в различных merge/compare тулзах, если вас не устраивают встроенные средства IDE. Результатом разрешения конфликта становится файл, под своим естественным названием помеченный как merged.
6. Делается Commit, который скидывает всё что вы наделали на сервер.
Третья система контроля версий Git. Интеграция IDE с ней появилась относительно недавно, и везде очень "по разному". От первых двух она отличается тем, что вам сразу без вариантов предлагают двухуровневую схему наката изменений. Кто-то считает, что в этом заключается одно из преимуществ git-а перед остальными. Вы можете обходиться вообще без сервера. Локальная копия репозитория может жить автономно. Скриншот не вмещает всего многообразия операций:
Нетипичный для Git, но типичный для вышеупомянутых VCS режим работы:
1. Делается Clone репозитория. Далее делается Checkout интересующей ветки. Обычно это master - ветка (origin/master). Ревизий как таковых нет, есть commit-ы.
2. Меняем код.
3. Делаем Commit, при этом изменения улетают в локальный репозиторий.
4. Делаем Push, чтобы изменения локальной ветки master улетели на сервер.
5. Возникли конфликты! Делаем Pull - изменения с сервера прилетают в локальный репозиторий. Тут-то мы их и мерджим. Результатом работы merge является файл под своим именем, помеченный как stage.
6. Как финальная стадия merge-операции делается Commit. Или Commit & Push.
7. Вобщем вы решили конфликты у себя локально, а теперь будьте любезны скинуть всё это добро на сервер. Делаем Push.
Более рассказывать про иные VCS я не сподоблюсь. Как видно из этого описания, работа с SVN и с TFS происходит примерно одинаково. За исключением того, что SVN всё-таки более ущербен, хотя-бы потому что у него в каждой папке вашего "родного" содержимого спрятаны свои служебные каталоги. УЖОСНАХ. Ну а последняя VCS заставляет разработчика быть более квалифицированный в процессах слияния. Ну кому нужны проблемы с разрешением конфликтов и осознавание того, в какой ветке вам нужно работать?? Да никому. Написал код, слил на сервер - ура, свободен. А в Git люди тащутся от того как они эти изменения вносят. Это на самом деле работа релиз-менеджера. Релизы разделены по отдельным веткам. И он решает нужно ли вносить ваши изменения в ту или иную ветку. Ну а для вас, как разработчика, существует одна текущая, и она же последняя ветка.
С нетерпением ждите следующего поста, про Git. Там я опишу, как можно, всё-таки не поседев, уживаться с этим зверем.
Подписаться на:
Сообщения (Atom)