ВоITи и выITи

At any place I work there are was a moment with discussion about using of break. continue and goto operators. I read a lot about goto in books and even McConnel "Solid code" wrote about how it is bad. And in all these places, in code styles, style guides and books, there are only one point: missing the main line of code or loosing the control. But I belive that with correct splitting of the program to smaller parts (methods, functions, classes) and with solid architecture there are no such a big deal about loosing control by using just break or continue. Sometimes it makes code shorter and easier. Recently I read very good article (or is this a book?)  What every programmer should know about memory  I found good example of why we should not use operators which lead to assembly JUMP from the real performance point of view: ( here is ) and it is called Prefetching. "Code has the advantage that it is linear between jumps. In these periods the processor can prefetch

Где бы мне ни приходилось работать, везде в какой-то момент возникает дискуссия на тему использования или неиспользования операторов break, continue и, конечно же, goto. О goto я читал в книгах, по-моему даже МакКоннел "Совершенный код", или что-то вроде. В руководствах по кодированию (code style, code guide) и в книгах довод один: запутанность кода. Однако при правильном разбиении кода на методы и нормальной архитектуре, по-моему, break и continue приводит только к большей понятности кода. И вот, читая интереснейший цикл статей "Что каждый программист должен знать о памяти" я нарвался на доступное объяснение чем плох любой переход (JUMP) с точки зрения производительности (ссыль http://rus-linux.net/lib.php?name=/MyLDP/hard/memory/memory-6-3.html ): "Код имеет то преимущество, что между переходами он линеен. В такие периоды процессор может эффективно делать предварительную загрузку памяти. Переходы нарушают эту идеальную картину из-за того

Недавно я перевёл свой проект с рельс ASP.NET MVC 3 на рельсы распоследней ASP.NET MVC 5. В статье я подробно описал как при этом использовать свои собственные таблицы БД и классы моделей, но остаться в рамках реализации стандартного механизма ASP.NET Identity. Одним из плюсов свежей версии я назвал поддержку OAuth 2.0 "из коробки". Однако, когда я дошёл до необходимости связывания MVC проекта с WebAPI встал вопрос о реализации аутентификации и авторизации пользователей. И здесь начались слёзы... Я очень советую всем посмотреть недавно вышедший курс по безопасности в Web API 2.0: WebAPI 2.0 Security Ссылку на скачивание с rutracker найдёте сами =). Это экспресс-курс, в котором описывается базовая настройка SSL, введение в основные виды аутентификации в ASP.NET, безопасность JavaScript клиентов, а также Token Based Authentication. Ну и конечно же описание проблем WebAPI 1.0 и решений этих проблем в WebAPI 2.0. Однако, по ходу курса непременно затрагивается вопрос работы O

Not so far I moved my ASP.NET MVC 3 project to latest&greatest ASP.NET MVC 5. In my previous article I was writing about this process and how to use own datatables for ASP.NET Identity 2.0 model. One of the points for latest version was OAuth 2.0 "out of the box". But now I have to implement authentication in my Web API project part and read a lot about it...and here is tears... I recommend to see one of the latest courses about Security in Web API 2.0:  WebAPI 2.0 Security You may see this course available on  rutracker  =). This is express-course but it is very usefull and telling about SSL settings in your web server, main authentication mecanisms and capabilities in ASP.NET, client-side security in JavaScript, and also Token Based Authentication. Also there are good describing of problems in WebAPI 1.0 and how it was solved in WebAPI 2.0. During this course there are touched OAuth 2.0 a lot and there are gived link to another useful course  Introduction to OAuth2,