Mirn: в 3-м комментарии примерно об этом речь. Если брать среднее, медиану, складывать, умножать и пр. - мы теряем информацию о порядке пикселей. Например, 0110 или 1001 дадут одно и то же усреднение, а если пиксели рассматривать как биты двоичного числа, это будут разные числа. При вычислении определителя, аналогично, порядок цифр важен, он разнообразит результат.
evgeniy_lm: если веса постоянны, и сами не являются случайными, получается мы, условно говоря, умножаем случайный сигнал на число (или на вектор). Просто гистограмма распределения растянется, случайность-то как добавится? это как при броске монетки, считать результат не 0/1, а 0/100, только вот значений все равно 2, т.к. числа от 0 до 100 при этом мы никак не получим. Этого можно добиться только увеличивая количество монеток.
Спасибо. Только непонятно, почему нужно брать группы, и что сделать - взять среднее между ними?
Если я построю гистограмму распределения пикселей по яркости - получится что-то близкое к нормальному?
Сергей: дело в том, что письма ведь как-то нужно сформировать, т.е. у них не фиксированный текст, есть общий шаблон, но в него вписываются данные, индивидуальные для пользователя. Если WebJob принимает на вход список адресов и текст письма, то этого недостаточно..
Юрий: не сомневаюсь, что это интересно, только рассказ (судя по первым 10 минутам) слишком проекто-специфичен, это же не туториал по asp.net WebAPI, а рассказ про конкретный проект. Для меня, увы, 2 часа - это роскошь, ищу более конкретные и концентрированные ответы.
Кирилл Таран: но у этого роута ведь будет тот или иной тип HTTP-запроса? В принципе, можно ведь интерпретировать отправку писем по расписанию как некий пул заданий, и тогда через PUT туда планировщик добавляет заказ "разошли письма". Там только с аутентификацией я пока не понял, как из под Azure прокинуть туда токен.
Я просто еще не сталкивался с аутентификацией в Azure, не знаю как это работает. Если есть WebAPI, все его контроллеры требуют авторизации (видимо, через токен), и один из них - отправка почты. Пока не понимаю, что это, просто POST, обращение по которому приводит к отправке писем? Ну вот там може токен, а в Azure при создании расписания нет такой опции, там только логин+пароль. Рассылать письма должен сервер. Ну, грубо говоря, каждое утро все подписчики получают по письму. Вся логика в том самом WebAPI, у него есть список адресов, он крутится в Azure, там же есть, как я понял, система рассылки почты, и там же планировщик.
#1 Например, складируемые на сервере (который WebAPI) данные нужно как-то обработать, сгенерить по ним отчет, или график. Чтобы не писать этот код дважды, хочу сделать это только в WebAPI, а сайт будет это как-то дергать
#2 Я вот тоже только с Enterprise работал всегда (чаще WCF + WPF, поэтому тут уже поплыл), поэтому и вопрос возник.
#3 Понимаю, что не CRUD, но ведь идеология rest подразумевает, что все есть ресурс. И даже действие - это тоже URI. Вот я и задумался, какой у вызова методов (т.е. действий) эквивалент в rest API.
У меня нет такой цели, найти типовое решение) Вопрос инициирует обсуждение, в котором люди делятся опытом, историями, интересными наблюдениями - картина расширяется, появляются новые мысли.
Майк: тут немного о другом речь: есть в принципе емкая по мозговым ресурсам работа, ее не выполнишь на автомате (как в случае формошлепства, рутины всякой). Она может нравиться, развивать, увлекать - но мозгом нужно интенсивно работать. И реально ли потом еще и дома над проектом думать. Одно дело, когда ты просто молодой студент, нужен опыт, гореть работой - ок. Когда жизненные поиски и опыт приводят к собственной идее, нежеланию работать на дядю, но силенок пока маловато чтобы быть работодателем - приходится в 2-х местах включать мозг по полной. И сколько лет в таком режиме человек выдержит?
Майк: есть общие вещи, а что-то индивидуально. Я например могу сделать рывок только в последний момент, иначе не получается. Сижу, смотрю сериалы, играю и пр., а потом в последнюю ночь пишу диплом) Только под грузом дедлайна получается мобилизоваться. Тут ведь еще такой момент: многие вещи требуют долго осмысления (а в моих проектах по исследованию времени и разработке соответствующего софта - подавно). Проработать 2 часа, или час + 5 отдыха + еще час - вещи совсем разные, в фоновом режиме много мыслей прорабатывается, и иногда просто необходио отвлечься.
Тут ведь еще один момент есть: при истощении падает КПД труда. И иногда более эффективно просто лечь спать, и часок поработать утром, чем до середины ночи "тупить" (извиняюсь за выражение) в монитор. Почему-то очень тяжело отправить себя спать вовремя...
