Существует более комфортное решение данной задачи, которое, в частности внедрили у нас в офисе на маршрутизаторе с ценой до $100.
Исходные данные:
два канала к ISP, при чем разной природы: один скоростной ethernet со статикой, второй — резервный pppoe линк через adsl модем с плавающим ip.
Цель: обеспечить схему бесперебойной работы терминального сервера наружу.
Средство: покупка VPN PPTP туннеля с постоянным честным ip (за совсем недорого), настройка на офисном маршрутизаторе поднятие PPTP туннеля и получение этого самого IP.
Готово.
Пользователь на самом деле подключался на ip предоставленный pptp туннелем, а этот самый pptp туннель поднимался на любом из живых каналов. Чистый profit.
у меня story на русском были написаны, сейчас пример вытащу
Функционал: Админ может добавлять, удалять и изменять статьи
Что бы админ мог управлять статьями
Как администратор сайта
Я должен иметь возможность удалять, добавлять и изменять статьи
Как пользователь
Я должен видеть отредактированные статьи
Предыстория:
Допустим админ существует
И админ авторизован
Сценарий: добавление новой статьи
И видит список статей в админзоне
Если создать новую статью с заголовком "bbb" url "my-new-article" и телом "bla-bla-bla"
То увидим в списке статей заголовок "bbb"
Сценарий: редактирование существующей статьи
И существует статья с заголовком "bbb" url "my-new-article" и телом "bla-bla-bla"
Если admin редактирует статью "bbb" и сохраняет тело "no-blabla"
То пользователь должен увидить тело статьи "no-blabla" по адресу "/articles/my-new-article"
Сценарий: удалить существующую статью foo
И существует статья foo с url foo
И статья с url foo опубликована
Если админ удаляет статью с урл foo
То юзер в списке статей не видит статью "foo"
When /^admin edit article (.*) and save content (.*)$/ do |url, content|
visit edit_admin_article_url(Article.find_by_url(url))
fill_in 'article[body]', :with=>content
click_button "Сохранить статью"
response.should be_success
end
Given /^статья с url (.*) опубликована$/ do |url|
@article = Article.find_by_url(url)
@article.published.should be_true
visit "/articles/#{url}"
response.should be_success
end
When /^админ удаляет статью с урл (.*)$/ do |url|
delete admin_article_url(Article.find_by_url(url))
end
Then /^юзер в списке статей не видит статью "(.*)"$/ do |article|
visit "/articles"
assert_not_contain article
end
Given /^посетитель открывает страницу "([^\"]*)"$/ do |page|
visit page
end
When /^посетитель нажмет на ссылку "([^\"]*)"$/ do |link|
click_link link
end
Then /^посетитель нажмет на ссылку (.*)$/ do |link|
assert_contain link
click_link link
end
Then /^перейдет на страницу статьи (.*)$/ do |title|
@article = Article.find_by_title(title)
visit article_url(@article.url)
end
Given /^посетитель открывает страницу статей$/ do
visit articles_path
end
Then /^увидит полный текст "(.*)" статьи с названием (.*)$/ do |body, title|
assert_contain(body)
assert_contain(title)
end
Тема ITSM, которую вы затронули, мне очень близка по роду занятий.
Именно ИТ аутсорсинг в первую очередь должен быть заинтересован в оказании услуг согласно ITIL, ибо 95% аутсорсеров для малого и среднего бизнеса исповедуют «ремонтный подход», то есть тот, при котором побежали туда где поломалось, однако этот подход приводит к совершенно немасштабируемому ИТ бизнесу. И этому действительно есть очевидные объяснения. Так как именно спрос рождает предложение, в данном случае это бизнес, который заказывает услуги у аутсорсера и не требует/не готов/не понимает как понять/посчитать качество получаемой услуги, то и соответствующего предложения от аутсорсера не будет.
А теперь о практике. Среднестатистический клиент не привык мыслить в терминах «получаемых услуг и SLA», пока что клиент понимает только «у меня 15 компьютеров и 3 сервера, сколько это будет стоить?». На переговорах бывает очень нелегко донести саму мысль об ITSM, получаемых услугах и стандартах качества руководителю предприятия.
К счастью, мыслящие руководители/директора явление нередкое. К слову, очень люблю переговоры с различными директорами/учредителями, как правило это люди умные и интересные.
Наш украинский рынок к ITIL попросту не созрел, но тем не менее, по-немногу набирает обороты и двигается вперед, хочется надеяться, что это лишь вопрос времени.
Важно иметь правила и соглашения с самим собой, как работать с файлом и куда его отправить.
Как раз не так давно писал про файловое GTD: it-premium.com.ua/articles/gdt-with-files
а за Windows Server 2003 Access-based Enumeration спасибо.
*смахивая скупую мужскую*
прямо как вновь подержался за свой MK-61 в детстве nexus.org.ua/weblog/message/727/
Исходные данные:
два канала к ISP, при чем разной природы: один скоростной ethernet со статикой, второй — резервный pppoe линк через adsl модем с плавающим ip.
Цель: обеспечить схему бесперебойной работы терминального сервера наружу.
Средство: покупка VPN PPTP туннеля с постоянным честным ip (за совсем недорого), настройка на офисном маршрутизаторе поднятие PPTP туннеля и получение этого самого IP.
Готово.
Пользователь на самом деле подключался на ip предоставленный pptp туннелем, а этот самый pptp туннель поднимался на любом из живых каналов. Чистый profit.
Функционал: Админ может добавлять, удалять и изменять статьи
Что бы админ мог управлять статьями
Как администратор сайта
Я должен иметь возможность удалять, добавлять и изменять статьи
Как пользователь
Я должен видеть отредактированные статьи
Предыстория:
Допустим админ существует
И админ авторизован
Сценарий: добавление новой статьи
И видит список статей в админзоне
Если создать новую статью с заголовком "bbb" url "my-new-article" и телом "bla-bla-bla"
То увидим в списке статей заголовок "bbb"
Сценарий: редактирование существующей статьи
И существует статья с заголовком "bbb" url "my-new-article" и телом "bla-bla-bla"
Если admin редактирует статью "bbb" и сохраняет тело "no-blabla"
То пользователь должен увидить тело статьи "no-blabla" по адресу "/articles/my-new-article"
Сценарий: удалить существующую статью foo
И существует статья foo с url foo
И статья с url foo опубликована
Если админ удаляет статью с урл foo
То юзер в списке статей не видит статью "foo"
When /^admin edit article (.*) and save content (.*)$/ do |url, content|
visit edit_admin_article_url(Article.find_by_url(url))
fill_in 'article[body]', :with=>content
click_button "Сохранить статью"
response.should be_success
end
Given /^статья с url (.*) опубликована$/ do |url|
@article = Article.find_by_url(url)
@article.published.should be_true
visit "/articles/#{url}"
response.should be_success
end
When /^админ удаляет статью с урл (.*)$/ do |url|
delete admin_article_url(Article.find_by_url(url))
end
Then /^юзер в списке статей не видит статью "(.*)"$/ do |article|
visit "/articles"
assert_not_contain article
end
Given /^посетитель открывает страницу "([^\"]*)"$/ do |page|
visit page
end
When /^посетитель нажмет на ссылку "([^\"]*)"$/ do |link|
click_link link
end
Then /^посетитель нажмет на ссылку (.*)$/ do |link|
assert_contain link
click_link link
end
Then /^перейдет на страницу статьи (.*)$/ do |title|
@article = Article.find_by_title(title)
visit article_url(@article.url)
end
Given /^посетитель открывает страницу статей$/ do
visit articles_path
end
Then /^увидит полный текст "(.*)" статьи с названием (.*)$/ do |body, title|
assert_contain(body)
assert_contain(title)
end
Именно ИТ аутсорсинг в первую очередь должен быть заинтересован в оказании услуг согласно ITIL, ибо 95% аутсорсеров для малого и среднего бизнеса исповедуют «ремонтный подход», то есть тот, при котором побежали туда где поломалось, однако этот подход приводит к совершенно немасштабируемому ИТ бизнесу. И этому действительно есть очевидные объяснения. Так как именно спрос рождает предложение, в данном случае это бизнес, который заказывает услуги у аутсорсера и не требует/не готов/не понимает как понять/посчитать качество получаемой услуги, то и соответствующего предложения от аутсорсера не будет.
А теперь о практике. Среднестатистический клиент не привык мыслить в терминах «получаемых услуг и SLA», пока что клиент понимает только «у меня 15 компьютеров и 3 сервера, сколько это будет стоить?». На переговорах бывает очень нелегко донести саму мысль об ITSM, получаемых услугах и стандартах качества руководителю предприятия.
К счастью, мыслящие руководители/директора явление нередкое. К слову, очень люблю переговоры с различными директорами/учредителями, как правило это люди умные и интересные.
Наш украинский рынок к ITIL попросту не созрел, но тем не менее, по-немногу набирает обороты и двигается вперед, хочется надеяться, что это лишь вопрос времени.
Как раз не так давно писал про файловое GTD: it-premium.com.ua/articles/gdt-with-files
Чистый inbox — залог здоровья.
Дайте же хотя бы DNS унести!
Но нет, подтверждения на трансфер не дождаться :(
nexusnotes.ru/2009/12/mobile-internet-kiev/
www.tuneupmedia.com/
За сервис fruux спасибо, открыл для себя новое :)