Насчет обоев Bing — скорей всего устроено так же, как и в WP8. Раз в сутки картинка на экране блокировки сама меняется на другую. Картинки — те же, что и на главной www.bing.com/, но обрезанные (вручную сотрудниками Bing) под размер экрана телефона. Картинки очень красивые, функция довольно приятная.
Спасибо, может пригодиться. Попробовал сделать тестовую программу аналогичную вашей.
Пару дополнений:
1. Собирается под .Net 3.5 (Full)
2. Можно собрать из исходников под .Net 4.0 Client Profile, если закомментировать всё, что относится к Oracle (если известно заранее, что Oracle не понадобится)
3. Можно устанавливать через NuGet nuget.org/packages/DataConnectionDialog
Это написано в пункте 3.3.4.1 Exceptions
Вольный пересказ — команда считается неудачной, возможно надо прекратить выполнение кода и надо обязательно вывести отладочную информацию. Данные и структуры таблиц поменяться не должны.
Помимо документации, есть еще стандарт ANSI SQL, и он должен быть главнее документации по БД. По поводу деления на ноль, стандарт прямо говорит, что должен происходить Exception.
«If the value of a divisor is zero, then an exception condition is raised: data exception-division by zero.»
Выглядит симпатично :)
А не подскажите, что там за схема с платной подпиской? А то смутила надпись 3 days free, а сама схема разблокировки/оплаты не очень понятна с первого взгляда.
Друзья, мы запустили кампанию народного финансирования Дару-дара! За 80 дней мы хотим собрать средства, которые позволят нам радикально улучшить и преобразить наш сервис. И сегодня мы просим сообщество Хабрахабра поддержать нашу краудфандинговую кампанию, помочь нам собрать нужную сумму.
А мне по первому абзацу показалось, что вы хотите привлечь внимание к сбору средств. Извините, что ошибся.
Помощь → Правила сайта
Чем не является Хабр
Хабр — не для попрошаек. Карма и рейтинг зарабатываются на Хабре только честным способом, то есть своими топиками и комментариями. Не стоит размещать чужие посты, выпрашивать инвайты или карму, устраивать «аттракционы невиданной щедрости», «топики добра» (или зла) и публиковать призывы поднять друг другу карму по любому поводу. Устраивать сборы средств тоже не стоит.
На мой взгляд, статья неполная без анализа затрат на увеличение конверсии — учитывается только стоимость прироста пользователей. Конверсия не может увеличится в два раза по нажатию волшебной кнопки соверешенно бесплатно, затраты на ее увеличение могут оказаться вполне существенными. Мне кажется, модель следует улучшить. Например так.
Дано:
— начальная посещаемость
— начальная конверсия
— стоимость привлечения новых пользователей (функция от количества пользователей, как в статье)
— стоимость увеличения конверсии (функция от размера конверсии, в статье момент не освещен)
— фиксированный бюджет на увеличение прибыли
Вопрос:
— как распределить бюджет между задачами по увеличению конверсии и увеличению числа посещений?
Сила влияет на ускорение. Чтобы вода пришла в движение нужна скорость. Чтобы из ускорения получить скорость нужно некоторое время. Поэтому и возникает задержка при проваливании. Но она очень маленькая — см. временную шкалу
Довольно распространенное заблуждение состоит в том, что порядок уведомления подписчиков не гарантируется.
Однако, это не так, ведь подписка на событие приводит в конечном счете к Delegate.Combine, который как раз гарантирует порядок вызова. То есть подписчики будут уведомляться в том порядке, в котором они подписывались.
Безусловно, рассчитывать на конкретный порядок — плохой стиль и надо пересмотреть дизайн приложения, но иногда бывают случаи, когда эта особенность полезна.
Такие рассуждения, конечно, интересны, но хотелось бы услышать более конкретные результаты типа «Я написал чат сначала на повторяющихся запросах раз в секунду от каждого клиента, и у меня он выдерживал N одновременных пользователей. Потом я написал тоже самое на WebSocket и получил M одновременных пользователей.»
Тоже сразу пришел в голову такой вариант. Дабы оценить точность методов посчитал среднее отклонение от Math.Round() по всему диапазону:
— первый метод — 1.09
— последний метод автора — 0.00012
public IEnumerable CountFrom(int start, int limit)
{
for (int i = start; i <= limit; i++)
yield return i;
}
Недавно задумался, не лучше ли будет написать:
public IEnumerable CountFrom(int start, int limit)
{
List res = new List();
for (int i = start; i <= limit; i++)
res.Add( i );
return res;
}
Из плюсов второго подхода мне видится более понятный синтаксис - ясно, во что это превратится после компиляции. Из минусов - полный просчет коллекции может и не понадобится в будущем, с итератором (первый вариант) получается отложенная инициализация. Неясен правда вопрос производительности.
А какие есть еще отличия по использованию этих двух кусков кода?
Перебор динамической части пароля можно заменить перебором алгоритма формирования. А его сложность будет сильно зависеть от конкретной реализации (сколько различных правил знает серверная часть) и количества компонент выбранных пользователем.
Мне слабо верится, что пользователи будут выбирать достаточно много компонент (хотя бы десяток), чтобы стойкость к подбору алгоритма формирования приблизилась к стойкости символьных паролей.
Пару дополнений:
1. Собирается под .Net 3.5 (Full)
2. Можно собрать из исходников под .Net 4.0 Client Profile, если закомментировать всё, что относится к Oracle (если известно заранее, что Oracle не понадобится)
3. Можно устанавливать через NuGet nuget.org/packages/DataConnectionDialog
Вольный пересказ — команда считается неудачной, возможно надо прекратить выполнение кода и надо обязательно вывести отладочную информацию. Данные и структуры таблиц поменяться не должны.
«If the value of a divisor is zero, then an exception condition is raised: data exception-division by zero.»
А не подскажите, что там за схема с платной подпиской? А то смутила надпись 3 days free, а сама схема разблокировки/оплаты не очень понятна с первого взгляда.
А мне по первому абзацу показалось, что вы хотите привлечь внимание к сбору средств. Извините, что ошибся.
Чем не является Хабр
Хабр — не для попрошаек. Карма и рейтинг зарабатываются на Хабре только честным способом, то есть своими топиками и комментариями. Не стоит размещать чужие посты, выпрашивать инвайты или карму, устраивать «аттракционы невиданной щедрости», «топики добра» (или зла) и публиковать призывы поднять друг другу карму по любому поводу. Устраивать сборы средств тоже не стоит.
Дано:
— начальная посещаемость
— начальная конверсия
— стоимость привлечения новых пользователей (функция от количества пользователей, как в статье)
— стоимость увеличения конверсии (функция от размера конверсии, в статье момент не освещен)
— фиксированный бюджет на увеличение прибыли
Вопрос:
— как распределить бюджет между задачами по увеличению конверсии и увеличению числа посещений?
Однако, это не так, ведь подписка на событие приводит в конечном счете к Delegate.Combine, который как раз гарантирует порядок вызова. То есть подписчики будут уведомляться в том порядке, в котором они подписывались.
Безусловно, рассчитывать на конкретный порядок — плохой стиль и надо пересмотреть дизайн приложения, но иногда бывают случаи, когда эта особенность полезна.
ФАС наказала «большую тройку» за дорогие звонки на стационарные телефоны
— первый метод — 1.09
— последний метод автора — 0.00012
А этот метод со сдвигом в конце — 0.43
public IEnumerable CountFrom(int start, int limit)
{
for (int i = start; i <= limit; i++)
yield return i;
}
Недавно задумался, не лучше ли будет написать:
public IEnumerable CountFrom(int start, int limit)
{
List res = new List();
for (int i = start; i <= limit; i++)
res.Add( i );
return res;
}
Из плюсов второго подхода мне видится более понятный синтаксис - ясно, во что это превратится после компиляции. Из минусов - полный просчет коллекции может и не понадобится в будущем, с итератором (первый вариант) получается отложенная инициализация. Неясен правда вопрос производительности.
А какие есть еще отличия по использованию этих двух кусков кода?
Мне слабо верится, что пользователи будут выбирать достаточно много компонент (хотя бы десяток), чтобы стойкость к подбору алгоритма формирования приблизилась к стойкости символьных паролей.