Ну тогда Айк был техническим директором. Может он и не особенно думал о том, что когда нибудь его назначат главой компании и он окажется в центре внимания. Просто ему нужно было быть осторожнее и тише в своих позициях если метил высоко. Быть более гибким в своих взглядах — так принято вести себя людям на таком высоком посту.
Вовсе не всем плевать на цвет кожи. Чернокожее население и сейчас гораздо беднее белого и если в крупных городах это уже не так заметно, то в провинции «скрытый национализм» по прежнему очень активен. Считалось например что у Маккейна перед Обамой есть большие шансы стать президентом именно поэтому.
Что касается афроамериканской культуры — она стала популярной вовсе не из-за роста толерантности. А просто потому что она уникальна и по своему замечательна.
А с гомосексуализмом в Штатах конечно лучше чем у нас, но куда хуже чем с разным цветом кожи. Не имеют они никаких «особенных прав». Нет практики создания баланса сотрудников при найме для избежания ущемления прав. Наоборот гомосекуалисты имеют меньше прав в обществе: в частности нет права на законный брак (в большей части штатов).
И воспринимать это так типа они вот зажрались — еще и брак требуют — по моему странная позиция. По крайней мере она требует аргументации.
Пока что эти меньшинства пытаются добиться хотя бы равных прав (право на семью). И у них это с большим скрипом получается.
Насчет какой то там особой защиты от критики большинства речь даже не идет.
Это лишь вопрос формулировки.
Если брак возможен только между мужчиной и женщиной — то он невозможен для однополых пар — то есть они автоматически лишены права вступать в законный брак.
Он не сторонник разнополых браков. Он противник однополых. Это не одно и тоже.
Он именно что критиковал поправку к конституции, которая разрешает однополые браки. И отмена этой поправки является ущемлением их прав. Они могли быть лишены возможности вступать в законный брак как их гетеросексуальные сограждане.
Я не думаю, что его позиция лучше или хуже. Просто она непопулярна в толерантном обществе. Поэтому вызвала критику. И ничего плохого в критике нет. Другое дело, что будучи главой международной компании непопулярный человек будет вредить бизнесу этой компании.
Мир не сошел с ума. Вот так он устроен — нравится вам это или нет.
Вы ответьте на вопрос. Какое право есть у меньшинств, но отсутствует у большинства в данном случае?
Я вот ни одного такого права не знаю. Надеюсь вам не надо объяснять, что если у гетеросексуалов есть право быть в браке, а у гомосексуалов нет — то и ежу понятно у кого тут больше прав.
Прикол в том, что если обрабатывать все возможные проблемы всех элементов — то вам придется затратить куда больше ресурсов на реализацию. Это часто бывает очень не дешевым решением. И к тому же эти ресурсы трудно спрогнозировать. Да еще очень легко забыть что нибудь обработать. Потому что все возможные варианты крешей вы все равно не придумаете.
Сам по себе подход Fast Fail и требование к «мягкому» поведению юая в случае падений вполне могут сосуществовать вместе. Они пересекаются постольку поскольку это является следствием особенностей архитектуры системы. Если она достаточно модульна — то использование Fast Fail не вызовет проблем. Иначе — ее можно улучшить.
Например у меня был как то проект новостного сайта — там было требование в случае падений каких то элементов на странице (серверные контролы) они должны просто пропадать с экрана не меняя или ломая верстку и сайт в целом. Решилось это простым наследованием всех контролов от от одного базового класса с обработкой ошибок и базовыми клиентскими механизмами. Конечно при этом легко было включить Fast Fail на девелоперском и тестовом окружении. И отключить его (включив обработку ошибок) на продакшене. То есть мы могли вылавливать ошибки рано и при этом выполнять требования бизнеса по стабильности на настоящем развернутом сайте.
Цена вопроса — несколько десяток строк кода и пару часов работы.
Конечно конкретное решение в каждом случае будет зависеть от архитектуры конкретно вашей системы.
Но общий подход к решению описанной вами проблемы такой: выделить модули (например ваши сложные видимо жаваскриптовые элементы) и внедрить комплексную обработку падений для всех таких модулей. Которую вы можете сконфигурировать на Fast Fail при девелопменте и определить более сложное поведение на другом окружении.
Однако это ваше специальное поведене в случае падений элементов нужно конечно тестировать отдельно — так как это тоже часть бизнеса.
Не вижу никакого противоречия в терминологии. Что вы имеете ввиду?
Вы правы — в вебе часто работает Forgive — а вот хорошо это или плохо — вопрос хороший. Лично я считаю, что например в случае с HTML — это просто наследие, от которого мы не можем отказаться из-за уже созданных приложений. Для меня было бы сказкой — если бы разметка «падала» в случае поломки — тогда не понадобилось бы затрачивать такие усилия по определению UI проблемы в авто тестах на UI. Вообще дополнительные валидации динамического кода на статическую корректность — это необходимость.
В большинстве динамических языков (PHP, Javascript и т.д.) есть исключения останавливающие выполнение работы программы. И если они применяются для разработки интерпрайз решений — то уход от Forgive подхода — обычно необходимый и правильный шаг.
В оконном софте тоже есть поведение верно? И там тоже есть операции которые подразумевают какой то результат. Вот как раз Fast Fail и подразумевает что операция не будет завершена если произошло исключение. Я еще раз повторю — что это не значит что нужно убивать приложение. Забудьте уже про этот стереотип. Но обработка ошибок тут будет комплексная на уровне приложения, а не локализованная. Можно сделать так, что этом внешне это не затронет других фич. Это не проблема.
Софт конечно не состоит полностью из процессов — вы правы. Он состоит из процессов (поведения) и деклараций (UI например) - это просто модель :). Поведение обычно занимает значимую часть бизнеса приложение — чаще всего большую часть. Вышеописанные подходы актуальны прежде всего для поведения. Ваш пример про банки — это транзакции. Это не то же самое о чем говорю я. Транзакции подразумевают возможность отката. Тут же откат не нужен. Мы просто избегаем некотролируемого поведения вот и все. Не только в данной операции, но и во всех дальнейших, которые от нее могут так или иначе зависеть.
Fast Fail для интерпрайз решений — это настоящая best practic — он позволяет избежать рисков на продакшене и выявлять и фиксать проблемы быстрее. Чаще всего прежде чем это попадет к пользователю. Потому что чем позже выявляется дефект — тем он дороже.
Но я допускаю, что в наколеночных поделках это может быть не так важно.
Не знаю как там у Гагарина или где то еще в космосе.
Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко. Это практически всегда специфика предметной области. Типичная ошибка в программе как правильно приводит к неопределенному поведению, которое дальше уже нельзя контролировать. А значит нужно остановить.
Исключения в прикладной софтверной индустрии не часты. Поэтому мы и можем сказать что хорошо, а что плохо.
А то, что принцип Fast Fail по ошибке воспринимают как необходимость «уронить» все приложение — это отдельная песня.
Что касается вашей последней фразы — знаете — знания и практические шаблоны как раз и создают для того, чтобы не включать мозг. Потому что его можно задействовать где то еще — не задумываясь над каждой строчкой — нужно ли тут применять Forgive. А вместо этого уделив больше внимания чему нибудь другому на проекте на каком нибудь более высоком уровне абстракции.
Fail Fast — не означает что нужно обязательно приложению падать. Речь о том, чтобы прервать выполнение текущей операции, чтобы избежать неопределенности ее дальнейшего выполнения. В реальности случаи, когда можно забыть о том, что произошла ошибка и исполнять код дальше — очень редки в софтверной индустрии. Хотя код такой пишут очень часто. Особенно грешат этим создатели автоматизированных скриптов. Поэтому можно более менее уверенно говорить что в общем Fail Fast это хорошо, а Forgive это плохо.
Хотя конечно есть исключения.
Что же касается того, нужно ли обрабатывать ошибки на местах — то есть нужно ли тратить ресурсы на обработку описанной вами ситуации — то совершенно другая тема. В целом главный вопрос в том — является ли ошибка внешней или внутренней по отношению к программе. Если она внешняя — значит это тоже часть интерфейса (возможного поведения) внешнего использованного сервиса (у вас драйвера) и нужно конечно ее обрабатывать и правильно на нее реагировать.
Политика это тоже реальная жизнь. Она влияет на каждого человека вполне напрямую. И это влияние огромно.
То, что у нас малоразвитый рынок электронной коммерции — это реальность. И от этого надо отталкиваться, а не говорить что у нас он «разный» или что надо делится опытом. Нет у нас никакого опыта. Только копии их сервисов 5 летней давности.
Отталкиваясь от правильных начальных условий можно делать правильные прогнозы на будущее и принимать правильные решения.
А вот хорошо это или плохо и кто виноват — обсуждают уже на политических форумах. И здесь это не интересно.
Ох не напоминайте про Почту России и ЕМС пожалуйста. Как вспомню опыт взаимодействия с ними — так вздрогну.
Мне кстати с амазона как то товар заказанный в штатах за 5 дней привезли. Прямо на работу.
Не обратил внимания каким сервисом доставки они у нас пользуются. Думаю скоро и у нас это получит развитие.
При чем тут политика. Штаты просто более развитый рынок. Как и Китай например. Все что происходит там — повторяется и у нас через несколько лет.
Тут речь он об обмене опытом. А о том, что смотря на развитые рынки мы можем более менее уверенно прогнозировать что будет на нашем в скором времени.
Хотя хотелось бы конечно чтобы прогресс был шел наоборот от нас туда.
Сорри — последняя статья за 2012 год. Не актуальное положение дел.
Но как видите в 2013 году был объявлен очередной конкурс. И как будто бы наконец с N-ого раза сумели таки что то приличное разработать.
Естественно то, насколько это качественное решение знают только контролирующие органы. Никакой публичной информации не смог найти.
Выглядит так — как будто им уже сказали — ну начните внедрять хоть что нибудь.
Вот тут более менее описано текущее положение дел. Вывод этой статьи простой — место российской операционной системы по-прежнему вакантно, ни одна из систем по тем или иным причинам не признана как национальная, а любые проекты, которые не основаны на ядре Linux и окружении GNU, по своим возможностям и стабильности никак не дотягивают до реальных применений.
1) Сама по себе гипертрофированная толерантность не нужна в толерантном обществе. Но в штатах и европе оно пока еще не слишком то толерантно. Есть еще так называемый скрытый национализм (это про негров), скрытая ненависть к сексуальным меньшинствам. Ее пока еще не изжили. Про россию я вообще молчу. Поэтому все так как оно есть. Через пару поколений уляжется.
2) Да — руководитель крупной международной компании должен подавать пример и это публичная фигура. Как и президент.
Сейчас у некоторых компаний больше влияния чем у иных стран. В том числе и на умы людей.
Компании часто страдают от действий CEO. Особенно если у них есть акционеры. Каждый скандал может стоить большой головной боли и отразится на курсе акций. Поэтому директор компании не должен своими действиями провоцировать шум и внимание или просто быть скандальной персоной.
По моему это очевидно.
Финансирование — это выделение денег. Вы не вниматлельно прочитали мою фразу.
Я имел ввиду политику в более общем смысле. Не полноценную политическую деятельность.
Но в целом я согласен — правильнее было бы сказать про его публичную позицию.
Что касается афроамериканской культуры — она стала популярной вовсе не из-за роста толерантности. А просто потому что она уникальна и по своему замечательна.
А с гомосексуализмом в Штатах конечно лучше чем у нас, но куда хуже чем с разным цветом кожи. Не имеют они никаких «особенных прав». Нет практики создания баланса сотрудников при найме для избежания ущемления прав. Наоборот гомосекуалисты имеют меньше прав в обществе: в частности нет права на законный брак (в большей части штатов).
И воспринимать это так типа они вот зажрались — еще и брак требуют — по моему странная позиция. По крайней мере она требует аргументации.
Насчет какой то там особой защиты от критики большинства речь даже не идет.
Если брак возможен только между мужчиной и женщиной — то он невозможен для однополых пар — то есть они автоматически лишены права вступать в законный брак.
Он именно что критиковал поправку к конституции, которая разрешает однополые браки. И отмена этой поправки является ущемлением их прав. Они могли быть лишены возможности вступать в законный брак как их гетеросексуальные сограждане.
Я не думаю, что его позиция лучше или хуже. Просто она непопулярна в толерантном обществе. Поэтому вызвала критику. И ничего плохого в критике нет. Другое дело, что будучи главой международной компании непопулярный человек будет вредить бизнесу этой компании.
Мир не сошел с ума. Вот так он устроен — нравится вам это или нет.
Я вот ни одного такого права не знаю. Надеюсь вам не надо объяснять, что если у гетеросексуалов есть право быть в браке, а у гомосексуалов нет — то и ежу понятно у кого тут больше прав.
Например у меня был как то проект новостного сайта — там было требование в случае падений каких то элементов на странице (серверные контролы) они должны просто пропадать с экрана не меняя или ломая верстку и сайт в целом. Решилось это простым наследованием всех контролов от от одного базового класса с обработкой ошибок и базовыми клиентскими механизмами. Конечно при этом легко было включить Fast Fail на девелоперском и тестовом окружении. И отключить его (включив обработку ошибок) на продакшене. То есть мы могли вылавливать ошибки рано и при этом выполнять требования бизнеса по стабильности на настоящем развернутом сайте.
Цена вопроса — несколько десяток строк кода и пару часов работы.
Конечно конкретное решение в каждом случае будет зависеть от архитектуры конкретно вашей системы.
Но общий подход к решению описанной вами проблемы такой: выделить модули (например ваши сложные видимо жаваскриптовые элементы) и внедрить комплексную обработку падений для всех таких модулей. Которую вы можете сконфигурировать на Fast Fail при девелопменте и определить более сложное поведение на другом окружении.
Однако это ваше специальное поведене в случае падений элементов нужно конечно тестировать отдельно — так как это тоже часть бизнеса.
Вы правы — в вебе часто работает Forgive — а вот хорошо это или плохо — вопрос хороший. Лично я считаю, что например в случае с HTML — это просто наследие, от которого мы не можем отказаться из-за уже созданных приложений. Для меня было бы сказкой — если бы разметка «падала» в случае поломки — тогда не понадобилось бы затрачивать такие усилия по определению UI проблемы в авто тестах на UI. Вообще дополнительные валидации динамического кода на статическую корректность — это необходимость.
В большинстве динамических языков (PHP, Javascript и т.д.) есть исключения останавливающие выполнение работы программы. И если они применяются для разработки интерпрайз решений — то уход от Forgive подхода — обычно необходимый и правильный шаг.
В оконном софте тоже есть поведение верно? И там тоже есть операции которые подразумевают какой то результат. Вот как раз Fast Fail и подразумевает что операция не будет завершена если произошло исключение. Я еще раз повторю — что это не значит что нужно убивать приложение. Забудьте уже про этот стереотип. Но обработка ошибок тут будет комплексная на уровне приложения, а не локализованная. Можно сделать так, что этом внешне это не затронет других фич. Это не проблема.
Софт конечно не состоит полностью из процессов — вы правы. Он состоит из процессов (поведения) и деклараций (UI например) - это просто модель :). Поведение обычно занимает значимую часть бизнеса приложение — чаще всего большую часть. Вышеописанные подходы актуальны прежде всего для поведения. Ваш пример про банки — это транзакции. Это не то же самое о чем говорю я. Транзакции подразумевают возможность отката. Тут же откат не нужен. Мы просто избегаем некотролируемого поведения вот и все. Не только в данной операции, но и во всех дальнейших, которые от нее могут так или иначе зависеть.
Fast Fail для интерпрайз решений — это настоящая best practic — он позволяет избежать рисков на продакшене и выявлять и фиксать проблемы быстрее. Чаще всего прежде чем это попадет к пользователю. Потому что чем позже выявляется дефект — тем он дороже.
Но я допускаю, что в наколеночных поделках это может быть не так важно.
Но я в своей практики встречаю ситуации, когда код программы можно выполнять дальше с определенным поведением после ошибки оооооочень редко. Это практически всегда специфика предметной области. Типичная ошибка в программе как правильно приводит к неопределенному поведению, которое дальше уже нельзя контролировать. А значит нужно остановить.
Исключения в прикладной софтверной индустрии не часты. Поэтому мы и можем сказать что хорошо, а что плохо.
А то, что принцип Fast Fail по ошибке воспринимают как необходимость «уронить» все приложение — это отдельная песня.
Что касается вашей последней фразы — знаете — знания и практические шаблоны как раз и создают для того, чтобы не включать мозг. Потому что его можно задействовать где то еще — не задумываясь над каждой строчкой — нужно ли тут применять Forgive. А вместо этого уделив больше внимания чему нибудь другому на проекте на каком нибудь более высоком уровне абстракции.
Хотя конечно есть исключения.
Что же касается того, нужно ли обрабатывать ошибки на местах — то есть нужно ли тратить ресурсы на обработку описанной вами ситуации — то совершенно другая тема. В целом главный вопрос в том — является ли ошибка внешней или внутренней по отношению к программе. Если она внешняя — значит это тоже часть интерфейса (возможного поведения) внешнего использованного сервиса (у вас драйвера) и нужно конечно ее обрабатывать и правильно на нее реагировать.
То, что у нас малоразвитый рынок электронной коммерции — это реальность. И от этого надо отталкиваться, а не говорить что у нас он «разный» или что надо делится опытом. Нет у нас никакого опыта. Только копии их сервисов 5 летней давности.
Отталкиваясь от правильных начальных условий можно делать правильные прогнозы на будущее и принимать правильные решения.
А вот хорошо это или плохо и кто виноват — обсуждают уже на политических форумах. И здесь это не интересно.
Мне кстати с амазона как то товар заказанный в штатах за 5 дней привезли. Прямо на работу.
Не обратил внимания каким сервисом доставки они у нас пользуются. Думаю скоро и у нас это получит развитие.
Тут речь он об обмене опытом. А о том, что смотря на развитые рынки мы можем более менее уверенно прогнозировать что будет на нашем в скором времени.
Хотя хотелось бы конечно чтобы прогресс был шел наоборот от нас туда.
Но как видите в 2013 году был объявлен очередной конкурс. И как будто бы наконец с N-ого раза сумели таки что то приличное разработать.
Естественно то, насколько это качественное решение знают только контролирующие органы. Никакой публичной информации не смог найти.
Выглядит так — как будто им уже сказали — ну начните внедрять хоть что нибудь.
2010 год.
Как заявлял летом 2010 года замглавы минкомсвязи Илья Массух, первая версия национальной ОС должна появиться до конца 2011 года. Предположительно, она будет на 90 процентов основана на исходном коде ОС на базе ядра Linux
2011 год.
Прототип национальной ОС разработают за 5 млн рублей и 16 дней
Про Bolgen OS я вообще молчу.
Вот тут более менее описано текущее положение дел.
Вывод этой статьи простой — место российской операционной системы по-прежнему вакантно, ни одна из систем по тем или иным причинам не признана как национальная, а любые проекты, которые не основаны на ядре Linux и окружении GNU, по своим возможностям и стабильности никак не дотягивают до реальных применений.
Доверие нужно заслужить.
2) Да — руководитель крупной международной компании должен подавать пример и это публичная фигура. Как и президент.
Сейчас у некоторых компаний больше влияния чем у иных стран. В том числе и на умы людей.
Компании часто страдают от действий CEO. Особенно если у них есть акционеры. Каждый скандал может стоить большой головной боли и отразится на курсе акций. Поэтому директор компании не должен своими действиями провоцировать шум и внимание или просто быть скандальной персоной.
По моему это очевидно.
А для Цукерберга это недальновидный шаг. Вполне еще ему аукнется. Просто в этот раз сошло с рук. Он же богат помимо всего прочего и любимец публики.
Публичность она такая. Если метишь в президенты будь анонимусом.
Я имел ввиду политику в более общем смысле. Не полноценную политическую деятельность.
Но в целом я согласен — правильнее было бы сказать про его публичную позицию.