Захотелось и мне высказать свои мысли на эту тему, особенно после прочтения идей по исправлению уравнения Дрейка. Хотя, это скорее развитие идеи великого фильтра с небольшой поправкой, что он не один, а на каждой ступени эволюции. Но всё ж начну с методологии уравнения Дрейка, упомянув, что я подразумеваю, что вселенная, вероятно, кишит жизнью, но в виде микробов, а разумные существа могут не встретиться в целом скоплении галактик.
Пользователь
Метод формализованных моделей как альтернатива нейронным сетям
7 мин
На этот вброс меня подталкивает доминирование статистических методов, особенно нейронных сетей — да, я именно так их буду классифицировать. С одной стороны я ничего не имею против них, но в то же время чувствуется явный перекос, иногда даже нейронные сети едва ли не отождествляют с неопределённым понятием искусственного интеллекта, хотя так ли хуже SVM, HMM и т.д. В вопросе обработки естественных языков я всегда был сторонником лингвистических методов в противовес статистическим, но чувствуется их существенный недостаток — трудоёмкость моделирования вручную по сравнению с машинным обучением. А может для лингвистических методов машинное обучение тоже применимо?
Локальные учётные записи в Microsoft Azure Mobile Services
4 мин
Туториал
Ещё одна недостаточно описанная тема про Microsoft Azure Mobile Services — авторизация, которая к тому ж налажена лишь в последних версиях. Разумеется, с самых ранних версий было перечисление MobileServiceAuthenticationProvider, позволявшее простым способом выполнить авторизацию одним из заданных методов. Но вряд ли этот набор — всегда самое удобное решение для пользователей. Тут возможно два направления расширения — добавление новых вариантов механизма OpenId или свой механизм авторизации. Далее будет рассмотрен второй вариант.
Back-end на основе Microsoft Azure
5 мин
Хочу рассказать ещё об одной теме, по которой материалов пока что чрезвычайно мало. Речь пойдёт о разработке back-end'а на основе Microsoft Azure Mobile Services. Хотя вводных статей на эту тему немало, легко заметить, что традиционный пример с TodoItems (которым подавляющее большинство введений ограничиваются) содержит потенциальные проблемы для большого проекта.
Самый главный минус демонстрационного проекта заложен в особенностях EntityDomainManager, который вынуждает отправлять через JSON те же классы, что используются в ORM (допустим, используем Entity Framework). Во-первых, сериализуемый класс должен наследоваться от EntityData, получается, что в базе данных оказываются не всегда нужные и удобные поля (например, он идентифицируется строкой, но хорошо ли строить индексы всегда на строках?). Во-вторых, EF располагает к наследованию класса только для схемы code first, не предусматривающей в текущей версии mapping'а на хранимые процедуры (вновь вопрос о быстродействии БД). И, в конце концов, а где тогда слой логики? Ведь структура БД не обязательно тождественна внешнему интерфейсу.
По этим причинам рассмотрим другой метод. Оговорю также тот факт, что введения в основы здесь не будет, предполагается, что краткое введение читателю уже известно.
Самый главный минус демонстрационного проекта заложен в особенностях EntityDomainManager, который вынуждает отправлять через JSON те же классы, что используются в ORM (допустим, используем Entity Framework). Во-первых, сериализуемый класс должен наследоваться от EntityData, получается, что в базе данных оказываются не всегда нужные и удобные поля (например, он идентифицируется строкой, но хорошо ли строить индексы всегда на строках?). Во-вторых, EF располагает к наследованию класса только для схемы code first, не предусматривающей в текущей версии mapping'а на хранимые процедуры (вновь вопрос о быстродействии БД). И, в конце концов, а где тогда слой логики? Ведь структура БД не обязательно тождественна внешнему интерфейсу.
По этим причинам рассмотрим другой метод. Оговорю также тот факт, что введения в основы здесь не будет, предполагается, что краткое введение читателю уже известно.