Николай Мохов

На Asp.Net (MVC, да, на классический Asp.Net смотреть уже давно нет смысло)
очень большой процент внутренних корпоративных/ентерпрайз сайтов или сайтов вроде stackoverflow, онлайн магазинов.
Именно по этой причине (всё таки стоимость серверного п/о решает) заказы на c#, asp.net mvc достаточно специфические, в отличие от той же java или php, поэтому процентное отношение далеко не в сторону MS- стека.

Мой вам совет - никогда не принимать всерьез гуглотренд, а уж тем более основываться на его данных при выборе своей профессии.
ASP.NET никуда не сходит и живее всех живых, просто ключевые слова стали более узконаправленными: MVC, WebAPI, SignalR и т.д. А в этом году открытие C# компилятора (Roslyn) и исходников ASP.NET стека еще больше подстегнёт спрос на технологию. К тому же огромным плюсом становится тот факт, что WebAPI и SignalR теперь могут спокойно работать вне IIS (благодаря OWIN), а MVC догонит их в следующем апдейте, вместе с vNext, который существенно упростит деплоймент компиляцией на лету и возможностью деплоить приложение вместе со всем фреймворком. А про удобство кодинга VS 2013, R#, Web Essentials, поддержку LESS, SCSS из коробки, Browser Link и еще тонной плюшек я вообще молчу.
В общем, лучше дважды подумайте, прежде чем принимать то или иное решение ;)

Я использую SimpleMembership потому что для меня он прост, я его более или менее знаю, плюсом к тому он достаточно лёгок и гибок. Но с выходом MVC5 рекоммендуют использовать, как посоветовал комментатор выше, ASP.NET Identity. С ним я не работал.
Старый Asp.Net Membership использовать однозначно не рекоммендую, потому что в своём объёме и оптимизации он просто монструозный.

p.s. Вот вам очень полезная ссылка на тему авторизации. Мне в своё время очень помогла да и сейчас помогае

kevin-junghans.blogspot.ru

Основных проблемы две:
1. Как генерируется токен, хранится и удаляется. Есть ли привязка к IP и др.
2. Угон токена через xss или другим способом, поскольку можно напрямую его читать. Наиболее рациональным подходом будет хранить в куки с флагом httponly. Для параноидальности еще можно разбить токен на две части. Одна в куке, другая отправляется вручную в запросе/заголовке.

Но еще лучше использовать http digest аутентификацию.

Мне тут посоветовали Scribe для быстрого сбора событий. Используется facebook'ом, объемы статистики которого малыми не назвать. Scribe может очень быстро принять сообщение, а затем сбрасывать его произвольное время на другой Scribe сервер или в локальный файл. Таким образом отослать событие "ничего" не стоит по времени. События могут быть внутренние (открытие страницы) или принятые от вашего плеера/приложения (play/pause) через (REST) API. Во втором случае лучше не использовать тяжелый стек RoR, а взять что-то крайне легковесное. Ведь там не будет никакой логики, принять данные и сразу в Scribe. Я бы сделал на чистом python/WSGI.

В идеале поставить по scribe процессу на каждый app. сервер, которые будут сливать события на единый выделенный scribe сервер, сливающий все в набор файлов. На этом же сервере можно поставить любую аналитику, которая на вход получит большие файлы с логами, а на выходе необходимую вам статистику (можно на map-reduce, можно и попроще). Ротацию файлов можно поставить на 10 минут, scribe сам за вас их крутит. Готовые агрегаты сливаются в любую БД, скорость ее работы не принципиальна, ведь они пойдут на графики для узкого круга людей.

Тут достаточно просто все.
Исключения помогают проскочить участок кода при выполнении определенных условий.
Причем, при коде без вызовов функций - всегда можно заменить на if/else, но код будет многовложенным (один if в другом). Но такой код естественно давно никто не пишет.

А при коде с вызовом функций это становится и вовсе невозможно (нельзя начало if написать в одном методе, а закрывающую скобку в другом). И нам приходится всю цепочку if передавать по стеку вызовов вверх.

Идея же исключений такая:
1. У нас есть алгоритм, который должен работать по заданной схеме. Мы нигде на уровне выше не проверяем корректность возвращаемых значений или правильность выполнения уровня ниже - он должен выполниться правильно или не выполниться. Это условие рождается из понимания инкапсуляции - каждый отвечает за свой кусок кода.
2. Если в какой момент момент, метод (кусок кода), отвечающий за определенную функциональность понимает, что не может выполнить назначенную ему операцию - он сообщает об этом на уровень выше.
3. Уровень выше может обработать исключительную ситуацию, либо (если не знает как) - передать исключение еще уровнем выше по стеку вызовов.

Т.е. резюмирую: у нас есть код, который должен в 90% случаев обрабатываться по одному алгоритму и в 10% случаях могут возникать ситуации, когда этот алгоритм в одной конкретной части кода - пойдет по другому сценарию.
Т.е. ваша задача писать код именно таким образом, чтобы исключения были лишь подстраховкой, а не частью основного алгоритма.

Интересный момент реализации исключений в lisp: там можно выполнить код вызвавший исключение повторно (например попытаться подключиться к базе второй раз средствами самого исключения).

if-elsе (switch) используется в случаях-
"если не так, то попробуем с другой стороны",
то есть, это выбор вариантов исполнения.
а exception-
"если не так, то никак (потому, что ....)",
то есть остановка исполнения, и старт каких либо заключительных действий (например, записать ошибку в лог и отправить пользователю красивую картинку/заглушку).
таким образом, "if" - это штатный режим, а а exception- аварийный

Отвечаю по C#. Исключение должно выбрасываться в любом случае, если метод не может выполнить задачу, которая ему назначена. Метод CreateUser() не смог создать пользователя? Исключение! Метод Connect() не смог подключиться за заданный интервал времени? Исключение. Если не ошибаюсь, так писал Рихтер.

Ну приведу простой пример. У вас есть функция которая должна открывать соединение с базой данных/читать из файла/подключаться к сокету... словом любая функция возвращающая некий ресурс, при помощи которого в дальнейшем будет осуществляться доступ к чему-то там.

Функция должна вернуть какой-то результат, причем определенного типа. Что вы будете делать в случае ошибки? А как уведомить разработчика что именно пошло не так?

Для этого ввели механизм исключений. Если в функции что-то идет не так, можно сформировать исключение со всей имеющейся по ошибке информации и выбросить его.

Если вы используете конструкцию try/catch в использующем эту функцию коде, то вместо крэша у вас вызовется один из обработчиков catch (вы можете спускаться по иерархии классов, задавая различное поведение для разного рода ошибок), возможно произведете какие-то уточнения в данных, переспросите пользователя и программа продолжит работу совершенно нормально.

Смотря Что Вам больше нравится - WinForms - своё потихоньку отживают.
WPF - более интересно в плане GUI, как минимум масштабируемостью окон/шрифтов для разных разрешений экрана, иногда очень идиотских.
Modern-UI - плитки и прочие радости Win8+, с маркетплейсом.
Web - C# + Asp.Net MVC + какойнить Jquery/Bootstrap - вполне сейчас тенденция для выноса приложений в веб
Мобильное - тоже, что и с Win8+, только в стандартизированных разрешениях экрана.
Еще игры, например Unity-based. Интересная штука, можно начать с какихнить Tower-Defence игрулек с минимумом графики.

А теперь чисто для себя - 16 лет стажа администрирования, из них немного стажа в написании админских скриптов на PowerShell, bash.
Последние пару лет вечерами с нуля, без знаний C#, html/css/web и прочего, где-то за полтора-два месяца фуллтайма 5х8, если пересчитать, пишу домашнюю бухгалтерию на Asp.Net MVC с Jquery + Twitter Bootstrap с MS SQL как хранилищем данных (тоже без особых его знаний).
Сейчас всё это живет в MS Azure при участии в программе Microsoft BizSpark.
Если я скажу, что в 31 подался в C# Junior - я Вас сильно удивлю?

Читай задание, пиши на C#
https://github.com/karan/Projects

Напиши мне бота для автоматического трейдинга на биткоиновых биржах :) Не, правда, придумай себе какую-нибудь реальную задачу и пиши. Всё что угодно можно начать с нуля.

Могу сказать насчет удобства — постоянно приходится его искать в самый неподходящий момент. Хочется запушить изменения — опа, ключ надо, вставать, рыться в джинсах и т.п. :)
Ну и, конечно, это не заменяет существующий способ авторизации, а как добавление к нему. Украли сумку с нотебооком? Скорее всего там же и ключ лежит.
В общем, на мой взгляд, оно того не очень стоит, отказался бы, если мог.

Посмотрите в сторону LastPass. Плагины есть для всех браузеров
Сам ушел с KeePass и ни чуть не жалею…