> Они, наверно, могли сказать, что товар с витрины не продается, а на складе кончились.
Не могут так сказать. Товар на витрине всегда продается, если есть ценник с его наименованием, собственно ценой и печатью, какой бы последний экземпляр это ни был бы.
Конструктивный:
1. определиться с требованиями к хостингу (зачем облачность вообще?)
2. определиться с провайдерами, подходящими под требования (если подходящий один — лучше определиться, какие требования не особо критичные, чтоб иметь запасной вариант).
3. определить наиболее соответствующего по цене/качеству.
4. ???
5. PROFIT!!!
Альтернативы Azure есть? Если есть — почему на них не перейдете?
Требования, которым полностью удовлетворяет Azure, и которым не удовлетворяет вроде больше никто (могу ошибаться, но тут принцип важен):
— облачность
— поддержка .NET
Если любой из этих пунктов уберете — список подходящих существенно расширится, как и расширится ценовой диапазон. Возможно, более дешевые решения доставят некоторые неудобства — но тут уже возникает вопрос, готовы ли вы платить за комфорт, или сэкономленные деньги важнее неудобств.
Неконструктивный путь: начать писать письма «почему так дорого». Правда, может, в ФАС сразу?
Дальше, я не представляю пока задач, для которых вам может прямо сейчас понадобиться облачный хостинг, и которые не могут окупить стоимость Azure.
Если вы не собираетесь его использовать на 100% (а судя по всему, не собираетесь) — может, он не нужен? Может, проще выделенный сервер (или часть выделенного сервера) арендовать? Думаю, в пределах 20$ можно найти минимум несколько приличных VDS.
Единственный разумный способ повлиять, как мне кажется — отказаться от использования необоснованно дорогой технологии (если ее дороговизна и вправду необоснованна). Если технология востребованна по той цене, по которой ее продают — никто цену не снизит.
Я кагбэ о том, что любой из этих пунктов может быть как риском, так и не риском — все зависит от проекта, команды и ситуации в какой то момент времени. Абсолютные оценки тут не подходят.
Опять же, в зависимости от команды может быть очень даже эффективно тратить 160 человеко-часов в месяц. И эффективно ли их тратить вообще в принципе (или сколько их тратить, и тратить ли вообще) — это вопрос, который в данной статье не рассматривается. Здесь говорится про то, как их тратить.
Т.е. если у вас нет рисков на проекте — не тратьте. Достаточно 15-ти минутных совещаний — не тратьте час. Ну и т.д., здравый смысл никто не отменял.
1. В зависимости от сложности проекта и опытности команды иногда случается так, что время и силы, затрачиваемые на сборку, возрастают.
2. Работа на Mac может быть из разряда «nice to have». Вспомнить о том, что мака до сих пор нет, иногда полезно. Если на поздней стадии вспомнили — вполне себе риск (а раньше не вспомнят, потому что раньше это «не риск»).
3. Статус у тикетов могут не обновлять, потому что, например, есть более приоритетные тикеты. Если у команды есть подозрение, что большинство из этих тикетов не вполне соответствуют текущему состоянию дел, и можно их сильно подвинуть в приоритете — стоит их протестировать и обновить статус.
4. Админ (или тот, кто выполняет его роль) может входить в команду проекта (а иногда и не один) ;-)
5.…
В общем, что то мне надоело писать. Суть — вы придираетесь, могут быть и такие риски вполне, они вполне понятны и нормально так раскрывают суть подхода — т.е. задачу свою в качестве примера выполняют на пять баллов.
Также, вы утверждаете, что все риски надо планировать, тогда они не случатся. Но вот беда в том, что все запланировать сразу не получится, и обязательно что то вылезет. Так вот автор нам как бы рассказывает о том, как надо строить работу, чтоб последствия от непредусмотренных ситуаций были минимальными. С этой задачей (ну, как мне кажется) статья тоже очень даже хорошо справляется.
Хехех, судя по описанию глюков и названию банка, там ДБО BS-Client какой то древней версии =)
У БССа вроде получше были решения — по крайней мере, они с распространенными браузерами работали нормально (в большинстве случаев и ActiveX нужен не был).
Ну хз, я испытывал неудобства по поводу восстановления данных в случае мертвой операционки значительно реже (точнее, никогда, т.к. операционка никогда не умирала так, чтоб «насовсем»), чем неудобства от закончившегося места на системном разделе при почти свободном «пользовательском» (и наоборот), т.к. в виндах есть тенденция к росту объема занимаемого места на системном разделе со временем (реестр, разные версии дллок, всякие апдейты и прочее). Так что если ОС не переставлять чаще, чем раз в год-полтора-два — то столкнуться с такой ситуацией вполне вероятно. Хотя, тема «бить или не бить» по холиварности та еще.
Блин, плюс не могу поставить, но поддерживаю. В винде нет смысла бить на разделы винты. Да и вообще нет особого смысла бить на разделы (ну, если не планируешь каждую неделю ОС переставлять).
На самом деле, если следовать стандарту, то на первый попавшийся элемент завязываться плохо, надо проверить, что мы получили (nodeType или nodeType + nodeName), и в случае чего перейти к следующему, nextSibling не такой уж дорогой (и в большинстве случаев только один будет).
Разметка может поменяться, и все накроется.
Element.prototype.getFirstChildElement = function()
{
var result = this.firstChild;
while( result != null && result.nodeType != document.ELEMENT_NODE )
{
result = result.nextSibling;
}
return result;
}
alert( document.getElementsByTagName('div')[0].getFirstChildElement().tagName ); // неплохо на null проверить
Достойный уровень жизни не поможет, да и торренты удобней, нежели покупка. С торрентами как? Пришел, увидел, скачал, послушал-посмотрел.
А даже в интернет-магазинах как? Перерыл гугл, нашел вменяемый магазин, пришел, увидел, заказал, нашел наименее геморройный способ оплаты (у меня ни вебмани, ни яндекс.денег, ни кредитки нет), нашел, где можно оплатить, оплатил, подождал, пока бабло придет, скачал, послушал-посмотрел.
С обычными еще хуже — пришел, долго ищешь, не находишь, идешь в следующий, находишь, оплачиваешь, приносишь домой, грабишь, слушаешь.
Не понятно, что вы имеете в виду под проектированием. В моём понимании прототип — часть проектирования, поэтому выбор «прототип или проектирование» вообще не имеет смысла.
В моем понимании проектирование — выработка свойств системы на основе анализа постановки задачи.
Этот самый процесс может быть выделен в отдельный этап (как, например, в классическом «водопаде»), а может быть и не выделен, а происходить регулярно, параллельно с процессом разработки (как, например, в случае agile-методологий).
А понятие «не такой уж» и «такой уж» слишком субъективны, чтобы можно было что-то возразить. Если из-за плохого проектирования время разработки увеличилось на 2 дня — это много или мало? А на 1000 проектов по 2 дня?
Ну, а если время разработки увеличилось на 2 дня, но сократился месяц «хорошего» проектирования? А на 1000 проектов? В том то и дело, что все субъективно.
BTW, замечу (на всякий случай) что разговор идет не о пользе/вреде проектирования вообще, а о целесообразности выделения детального проектирования системы в отдельный этап на небольших (в пределах 2-3 человекомесяцев) проектах.
Да, в гугл-коде можно добавлять фичреквесты, буду смотреть периодически туда.
max-at-work.narod.ru/jquery.tree.test.html
Не могут так сказать. Товар на витрине всегда продается, если есть ценник с его наименованием, собственно ценой и печатью, какой бы последний экземпляр это ни был бы.
Конструктивный:
1. определиться с требованиями к хостингу (зачем облачность вообще?)
2. определиться с провайдерами, подходящими под требования (если подходящий один — лучше определиться, какие требования не особо критичные, чтоб иметь запасной вариант).
3. определить наиболее соответствующего по цене/качеству.
4. ???
5. PROFIT!!!
Альтернативы Azure есть? Если есть — почему на них не перейдете?
Требования, которым полностью удовлетворяет Azure, и которым не удовлетворяет вроде больше никто (могу ошибаться, но тут принцип важен):
— облачность
— поддержка .NET
Если любой из этих пунктов уберете — список подходящих существенно расширится, как и расширится ценовой диапазон. Возможно, более дешевые решения доставят некоторые неудобства — но тут уже возникает вопрос, готовы ли вы платить за комфорт, или сэкономленные деньги важнее неудобств.
Неконструктивный путь: начать писать письма «почему так дорого». Правда, может, в ФАС сразу?
Дальше, я не представляю пока задач, для которых вам может прямо сейчас понадобиться облачный хостинг, и которые не могут окупить стоимость Azure.
Если вы не собираетесь его использовать на 100% (а судя по всему, не собираетесь) — может, он не нужен? Может, проще выделенный сервер (или часть выделенного сервера) арендовать? Думаю, в пределах 20$ можно найти минимум несколько приличных VDS.
Единственный разумный способ повлиять, как мне кажется — отказаться от использования необоснованно дорогой технологии (если ее дороговизна и вправду необоснованна). Если технология востребованна по той цене, по которой ее продают — никто цену не снизит.
Опять же, в зависимости от команды может быть очень даже эффективно тратить 160 человеко-часов в месяц. И эффективно ли их тратить вообще в принципе (или сколько их тратить, и тратить ли вообще) — это вопрос, который в данной статье не рассматривается. Здесь говорится про то, как их тратить.
Т.е. если у вас нет рисков на проекте — не тратьте. Достаточно 15-ти минутных совещаний — не тратьте час. Ну и т.д., здравый смысл никто не отменял.
2. Работа на Mac может быть из разряда «nice to have». Вспомнить о том, что мака до сих пор нет, иногда полезно. Если на поздней стадии вспомнили — вполне себе риск (а раньше не вспомнят, потому что раньше это «не риск»).
3. Статус у тикетов могут не обновлять, потому что, например, есть более приоритетные тикеты. Если у команды есть подозрение, что большинство из этих тикетов не вполне соответствуют текущему состоянию дел, и можно их сильно подвинуть в приоритете — стоит их протестировать и обновить статус.
4. Админ (или тот, кто выполняет его роль) может входить в команду проекта (а иногда и не один) ;-)
5.…
В общем, что то мне надоело писать. Суть — вы придираетесь, могут быть и такие риски вполне, они вполне понятны и нормально так раскрывают суть подхода — т.е. задачу свою в качестве примера выполняют на пять баллов.
Также, вы утверждаете, что все риски надо планировать, тогда они не случатся. Но вот беда в том, что все запланировать сразу не получится, и обязательно что то вылезет. Так вот автор нам как бы рассказывает о том, как надо строить работу, чтоб последствия от непредусмотренных ситуаций были минимальными. С этой задачей (ну, как мне кажется) статья тоже очень даже хорошо справляется.
У БССа вроде получше были решения — по крайней мере, они с распространенными браузерами работали нормально (в большинстве случаев и ActiveX нужен не был).
Peace! =)
Разметка может поменяться, и все накроется.
Element.prototype.getFirstChildElement = function() { var result = this.firstChild; while( result != null && result.nodeType != document.ELEMENT_NODE ) { result = result.nextSibling; } return result; } alert( document.getElementsByTagName('div')[0].getFirstChildElement().tagName ); // неплохо на null проверитьА даже в интернет-магазинах как? Перерыл гугл, нашел вменяемый магазин, пришел, увидел, заказал, нашел наименее геморройный способ оплаты (у меня ни вебмани, ни яндекс.денег, ни кредитки нет), нашел, где можно оплатить, оплатил, подождал, пока бабло придет, скачал, послушал-посмотрел.
С обычными еще хуже — пришел, долго ищешь, не находишь, идешь в следующий, находишь, оплачиваешь, приносишь домой, грабишь, слушаешь.
Куча лишних звеньев в цепочке, в общем.
В моем понимании проектирование — выработка свойств системы на основе анализа постановки задачи.
Этот самый процесс может быть выделен в отдельный этап (как, например, в классическом «водопаде»), а может быть и не выделен, а происходить регулярно, параллельно с процессом разработки (как, например, в случае agile-методологий).
Ну, а если время разработки увеличилось на 2 дня, но сократился месяц «хорошего» проектирования? А на 1000 проектов? В том то и дело, что все субъективно.
BTW, замечу (на всякий случай) что разговор идет не о пользе/вреде проектирования вообще, а о целесообразности выделения детального проектирования системы в отдельный этап на небольших (в пределах 2-3 человекомесяцев) проектах.