Введение 10 лет назад трудно было вообразить, что разработка ASP.NET веб-приложений вне интегрированной среды разработки Visual Studio .NET буде возможна. Но в прошлом году произошли изменения. В апреле 2014 года на конференции разработчиков (Build)  Microsoft анонсировал запуск нового легкого кросс-платформенного кодового редактора для разработки современных веб-приложений под именем Visual Studio Code. Visual Studio Code Visual Studio Code свободна для скачивания с официального сайта.  Работаете ли Вы на Linux, Mac или Windows – не имеет значения. Вы можете скачать и запустить VS код на своей платформе. Установка Visual Studio Code довольно проста, но если Вы застрянете, то всегда можете просмотреть документацию по установке. Visual Studio Code является просто редактором кода на файловой основе и не имеет всех преимуществ полной интегрированной среды разработки Visual Studio .NET. Он легче по дизайну. Тем не менее, у редактора есть множество особенностей, которые поддерживают такие технологии, как IntelliSense для дополнения кода, Peek Definition для быстрого взгляда на функциональный код без навигации,  реорганизацию кода и прочие. Visual Studio Code также поддерживает множество языков, например CoffeeScript, F#, Go, Jade, Java, Handlebars, Powershell и Python, для примера. Вы можете проверить языковую поддержку здесь. Также Visual Studio Code способен поддерживать такие среды выполнения, как ASP.NET 5 и Node.JS. Если Вы их используете для веб-разработки с Microsoft Stack, можете быть уверенны, что ASP.NET 5 (новая версия ASP.NET) сейчас поддерживает кросс-платформенную разработку. Это значит, что можно разрабатывать ASP.NET-приложение в среде Linux, Mac или Windows так же, как и запускать его в любой из них. И Вам даже не нужно иметь интегрированную среду разработки Visual Studio .NET, чтобы сделать это. Visual Studio Code – это все, что вам нужно, чтобы начать работать с ASP.NET 5, и это здорово! Установка ASP.NET 5 & DNX (среды выполнения .NET): ASP.NET 5 был построен с нуля, чтобы убедиться, что он придерживается современной парадигмы веб-приложений, и что приложения, разработанные с его помощью являются «облачными». Ключевыми аспектами ASP.Net 5 являются гибкость и модульность – он предлагает минимальные накладные расходы и позволяет нам выбирать только то, что мы хотим в рамках нашего веб-приложения. DNX расшифровывается как Dot Net eXecution Environment. Что такое Yeoman? Если Вы работали в интегрированной среде разработки Visual Studio .NET, Вам будет интересно: «Есть ли здесь File > New > ASP.NET шаблон проекта?» Visual Studio Code является редактором кода на файловой базе, так что Вы можете просто открыть файл и начать редактирование. Кроме того, нужны поддерживающие средства, чтобы работать с исполняемым шаблоном ASP.NET. Yeoman является популярным консольным инструментом для автоматического построения структуры проекта, а также обеспечивает базовым ASP.NET шаблоном для старта. Yeoman может быть установлен с помощью NPM, но для начала надо установить Node.JS. Если у Вас нет Node в системе, можете установить его. Кроме Yeoman, Вам также нужны другие поддерживающие средства, такие как генератор ASP.NET, исполнитель задач Grunt и Bower. Вы можете выполнить это за одну команду. В командной строке набрать следующую команду и нажать enter: npm install –g yo grunt-cli generator-aspnet bower Теперь Вы можете строить веб-приложения. Создание веб-приложения Разберем пошагово, как  построить структуру проекта нового ASP.NET 5 веб-приложения. 1. Откройте командную строку и перейдите в папку, где Вы хотите создать свое новое веб-приложение. 2. Введите в командную строку следующую команду:  yo aspnet 3. Yeoman отобразит варианты приложений для генератора aspnet. Возможные варианты: консольное приложение веб-приложение основное веб-приложение (без членов/аутентификации) веб-приложение API Nancy ASP.NET приложение библиотека классов тестовый проект Unit Выберите сейчас основное приложение. Используйте клавиши со стрелками для выбора опции и нажмите enter. 4. Дальше нам нужно назвать веб-приложение. Используем HelloWorld как имя нашего образца ASP.NET 5 веб-приложения. Введите имя и нажмите enter. Yeoman построит структуру проекта. 5. Каталог, в котором будет создано наше веб-приложение будет иметь то же имя, что мы дали только что Yeoman. В данном случае - “HelloWolrd”. cd HelloWorld   6. Через командную строку откройте Visual Studio Code code 7. Visual Studio Code запустит проект HelloWorld. Файлы в проекте будут отображаться в окне Проводника. 8. В редакторе Visual Studio Code выберите View > Command Palette option и в командной палитре введите следующую команду: dnx: dnu restore - (HelloWorld) Выше написанная команда restore устанавливает нужные NuGet пакеты, необходимые для запуска веб-приложения. Она запустит командную строку, куда будут загружаться все пакеты. После выполнения будет получено сообщение, что загрузка завершена. Запуск веб-приложения Теперь, когда мы успешно создали веб-приложение, пришло время запустить его и посмотреть на результат. 1. В Visual Studio Code откройте Command Palette, выбрав View > Command Palette. Введите следующую команду для запуска приложения: dnx: kestrel -(HelloWorld,Microsoft.AspNet.Hosting--server Kestrel–config hosting.ini Примечание: Когда Вы начинаете набирать команду, командная палитра подскажет Вам полную команду в списке. Вы можете выбрать команду из списка и команда будет выполнена. 2. Откройте браузер и перейдите по ссылке http://localhost5000 Мы только что создали ASP.NET веб-приложение вне интегрированной среды разработки Visual Studio. Фактически, в настоящее время ASP.NET больше не только в Windows. Мы переходим на кросс-платформу – как с точки зрения разработки, так и размещения. Интеграция Telerik UI для набора ASP.NET MVC Teleric предлагает пользовательский интерфейс, известный как UI для ASP.NET MVC. Он произошел от Kendo UI и предусматривает HTML-помощников, которых называют “Kendo UI wrappers.” Они упрощают работу с элементами управления Kendo UI и ускорят вашу разработку. Представим пошагово добавление пользовательского интерфейса для ASP.NET MVC в наш проект: 1. Откройте файл project.json и в узле (“dependencies”) добавьте Kendo (в настоящее время доступна бинарная версия Kendo Mvc – 2015.2.805). "dependencies":{     ...     "Kendo.Mvc":"*" } 2. Дальше откройте Startup.cs и найдите метод “ConfigureServices”. Добавьте следующий фрагмент в метод. //Register UI for ASP.NET MVC Helpers Services.AddKendo(); 3. Затем откройте ~/Views/_ViewImports.cshtml и импортируйте пространство имен Kendo.Mvc.UI. @using Kendo.Mvc.UI 4. Скопируйте Kendo UI ресурс с клиентской стороны. Для этого Вам нужно установить пакет Kendo UI Professional (Commercial Package). Его можно установить через Bower с помощью следующей команды: bower install https://bower.telerik.com/bower-kendo-ui.git Пакет Kendo UI Professional Bower размещается в частном git-хранилище и требует активировать аккаунт Telerik. Во время установки Вам предложат ввести пароль несколько раз. Bower установит пакет Kendo UI Professional как “kendo-ui” в папку wwwroot/lib. 5. Дальше нам необходимо зарегистрировать скрипты Kendo UI и стили в ~/Views/Shared/_Layout.cshtml. <head>     ...     <link rel="stylesheet" href="~/lib/kendo-ui/styles/kendo.common-bootstrap.min.css" />     <link rel="stylesheet" href="~/lib/kendo-ui/styles/kendo.bootstrap.min.css" />     <link rel="stylesheet" href="~/lib/kendo-ui/styles/kendo.dataviz.bootstrap.min.css" /> head> 6. Теперь  давайте используем виджет Kendo UI в одном из видов. Мы будем использовать виджет Kendo UI DatePicker. Откройте ~/Views/Home.Index.cshtml и добавьте следующий фрагмент: <body>     ...     <script src="~/lib/kendo-ui/js/kendo.all.min.js">script>     <script src="~/lib/kendo-ui/js/kendo.aspnetmvc.min.js">script>     @RenderSection("scripts", required: false) body> 7. Запустите веб-приложение через dnx: kestrel команду, что мы использовали ранее. Результат представлен ниже. Заключение Готово. У нас есть законченное веб-приложение ASP.NET 5, интегрированное с Telerik UI для ASP.NET MVC виджетов, разработанное только использованием Visual Studio Code с поддержкой таких инструментов, как Yeoman и Bower. Надеемся, Вам понравилось! Источник -  http://developer.telerik.com/featured/developing-asp-net-5-web-apps-with-visual-studio-code/

Введение Когда в 2008 году компания Microsoft придумала ASP.NET MVC, у многих возник вопрос: «Зачем нужна ещё одна технология ASP.NET?». Многие считают, что ASP.NET MVC не обязательно использовать, заменив на Web Forms ASP.NET. Однако, это неправда. Оба имеют свои плюсы и минусы. В статье мы рассмотрим преимущества этих двух технологий – и каждый сможет определиться, какая из них ему ближе. Мы также объясним понятия ASP.NET, ASP.NET Web Forms, MVC, ASP.NET MVC. Опытным разработчикам в ASP.NET MVC данная статья поможет переосмыслить свои концепции. Web-технологии Когда речь идёт о web-технологиях, на ум приходит классический ASP, PHP, JSP, ROR, ASP.NET Web Forms, ASP.NET MVC и другое. Классический ASP - web-технология, созданная корпорацией Microsoft. У классического ASP было два недостатка: слишком большой, неудобный исходный код и ненадёжность. К примеру, у Вас есть текстовые поля и кнопка. Нажав на кнопку, можно проверить данные, хранящиеся на сервере. Успешная проверка означает, что данные хранятся в базе, а в обратном случае выведется определённое сообщение об ошибке. В чём проблема такого сценария? Вам нужно совершить много действий. Приложение ASP.NET ASP.NET – приложение Microsoft, его структура построена на всеязыковой среде выполнения для построения динамических веб-сайтов – для создания можно использовать такие языки: C#, VB.NET и другие. ASP.NET поддерживает две модели: Web Forms и ASP.NET MVC. ASP.NET Web Forms Корпорация Microsoft первой вывела ASP.NET Web Forms из ASP, таким образом они решили множество проблем путём создания высокого уровня абстрагирования. Web Forms включает в себя postback (постит данные на заданную страницу) и ViewState. И самое интересное в том, что для ASP.NET Web Forms не требуется написания вручную ни единой строчки кода. ASP.NET 4.0 В ASP.NET 4.0 придумали, как преодолеть некоторые трудности: появилась возможность отключать и контролировать размер ViewState; с URL routing можно предоставить собственный URL вместо физического пути; в ASP.NET 4.0 мы имеем лучший контроль над ID элементов и, таким образом, интеграция с платформой JavaScript стала проще. Шаблон MVC MVC – архитектурный шаблон. Многие используют его с Java-технологией. MVC – не новое понятие, созданное Microsoft. Однако, в MVC ASP.NET нужно разобраться. До этого стоит уточнить для себя некоторые определения – в том числе, что такое MVC. Архитектурный шаблон – то, что решает наш вопрос на суб-системном уровне или на коротком уровне модуля. Речь идет о проблеме, связанной с архитектурой проекта. Это говорит о том, как можно разделить системы, а в частности - почему. Создаются библиотеки классов, компоненты, веб-сервисы, чтобы решить данный вопрос. MVC – архитектурный шаблон, позволяющий уловить тонкую связь между input-логикой, бизнес-логикой и UI-логикой. Платформа ASP.NET MVC ASP.NET MVC – еще одна платформа web-приложений от Microsoft. В ней устранены недостатки, имеющие место в предыдущих, подобного типа платформах. Эта платформа построена на всеязыковой среде выполнения (CLR) и полностью основана на MVC-архитектуре. Источник: http://www.codeproject.com/Articles/528117/WebForms-vs-MVC#Visual_in_Web

Автор статьи: Влад Кобылянский, архитектор программного обеспечения, разработчик и консультант по технологиям малого бизнеса (Майами, Флорида).   Вопрос: Что сегодня происходит с PHP фреймворками? В феврале 2017 года я так ответил на этот вопрос: «В основном все крутится вокруг двух PHP фреймворков -  Laravel и Symfony. Особой нужны в использовании CakePHP, Zend, CodeIgniter, Yii и т. д. нет, если вы начинаете новый проект. Только если вы уже знаете эти фрэймворки или у вас в команде есть разработчики которые привыкли работать с ними, тогда причины их использования обоснованы. Когда начинается реальная разработка, вы должны иметь возможность находить инструменты, плагины, ответы на общие проблемы. С сообществами Laravel и Symfony, с постоянным развитием новых «модулей» или функций, не будет ощущения, что вы остались «в стороне». Одни Laracast (даже если вы не работаете в Laravel) чего стоят! Они просто фантастичны. Когда заходит речь об интеграции с iron.io или другими SaaS сервисами, поддержке широкого спектра источников данных или о среде разработки – Laravel и Symfony и их расширения намного более продвинуты. Еще одним достоинством  Lumen, является быстрая разработка и прототипирование API для Laravel. При этом это никак не ограниченно для построения больших приложений.Вообще говоря, сегодня мы определенно видим переход к контейнерной архитектуре, где MVC играет гораздо меньшую роль. Все это касается микросервисов, оркестровки и создания приложений как «функций» (AWS Lambda и подобных сервисов). Возможно, пришло время освежить наши навыки Node/JS и GoLang?»   Хотя я в целом доволен этим ответом, сейчас я думаю, что некоторые моменты пришло время пересмотреть. Прежде чем перейти к таким странным темам, как GoLang, давайте взглянем на тенденции PHP MVC фреймворков. Я бы сказал, что тенденции, которые мы наблюдали в прошлом, остаются. Laravel продвигается вперед, в то время как большинство остальных фреймворков отстает. В популярности Symfony наблюдается небольшой всплеск, вероятно, из-за долгожданного выпуска Symfony 3. Я попробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не привели к статистически значимым тенденциям. На этот раз я добавил CodeIgniter, потому что он оказалася очень популярным. Я получил ряд вопросов о CodeIgniter. Если коротко, CI сейчас не в конкуренции, потому что это не 100% фреймворк MVC. Иначе, чем организованной коллекцией POPO, я это не назову. Для наглядности представляю вам цитату из руководства CodeIgniter: «CodeIgniter имеет довольно свободный подход к MVC, поскольку не требуются Models. Если вам не нужно дополнительное разделение или вы обнаружите, что поддерживающие Models требуют большей сложности, чем вы хотите, вы можете их проигнорировать и создать свое приложение с помощью Controllers и Views.» Когда дело доходит до построения структуры, я просто не согласен с таким подходом. Возможно, это достойный шаблон (отсюда и популярность CodeIgniter), однако должна быть какая-то дисциплина, навязанная фреймворком, иначе конечный продукт в итоге превращается в беспорядочный спагетти-код, завернутый в какой-то «шаблон». Далее, Symfony 3 привнес некоторые достойные улучшения в разработку и целый ряд новых «фич». Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. ZF3, к примеру, добавил ряд улучшений, таких как поддержка PHP7 (наконец!) и даже стал микро-фреймворком... но, в их руководстве так и говорится: «Для пользователей Zend Framework 2 MVC, различия с ZF3 незначительны...» Я действительно надеялся, что они скажут, что различия есть, что было замечательное архитектурное усовершенствование, замечательные новые модули, которые помогают вам разрабатывать все по-современному. Но, увы, по большей части ZF3 по-прежнему похож на ZF2. Long Story Short Вот как я вижу мир PHP фреймворков сегодня: Symfony или Laravel (выбор зависит от того, какую задачу вам нужно решить) Все остальное Laravel на первом месте. Объем доступной информации, Laracasts, таланты разработчиков во всем мире, простые реализации шаблонов, интегрированные наборы инструментов тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, развитие Homestead (Vagrant) – все перечисленное способствует фреймворку действительно выделяться и для новых, и для опытных разработчиков. Однако модели Eloquent могут стать непослушными и довольно большими по размеру, а сервисов Laravel (не путать с микросервисами) можно создать очень много, и вот тут люди начинают думать о реализации Repository, которому здесь не место. Так родился Monolith. Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость в репозиториях, или, возможно, вы видите слишком много независимых анонимных функций, тогда используйте Symfony + Doctrine. Рассматриваю ли я Symfony как шлюз для монолитных приложений? В какой-то степени, да. В целом, я бы не назвал это резким изменением с прошлого года. Тем не менее, нам нужно взглянуть на общую картину: правильно разработанное приложение выходит за рамки чистого MVC; речь идет об инфраструктуре, конвейере развертывания, разъединённой архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть внимательным, чтобы избежать Monolith. Приход микросервисов Раньше я упоминал о распространенности микросервисов и необходимости улучшать навыки GoLang или Node. А в статье о PHP MVC было бы глупо не упомянуть о явно растущем движении к микросервис-ориентированной архитектуре (MOA); и это движение набирает обороты, поверите вы или нет. Хотя эти два понятия не являются взаимоисключающими, не нужно находить параллели между ними, ведь они действительно представляют собой разные философии. В качестве примера, размещение вашего приложения MVC в одном контейнере и MySQL в другом, а затем объединение их вместе, не обязательно представляет собой надлежащую MOA. Это, безусловно, лучший подход, чем пытаться установить MAMP, XAMPP или что-либо еще, чтобы заставить ваш компьютер работать с приложением. Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах и, возможно, в некоторых случаях стратегии развертывания, но вы застрянете с монолитным MVC в вашем приложении/контейнере. Уничтожение Monolith Микросервисы – это как раз о «разрушении». В то время как MVC обращается к вашей структуре кода и организации, обеспечивая надежный подход к разделению проблем, эта концепция еще больше расширяется контейнерами/сервисами/MOA. Вместо того, чтобы просто отделять виды (Views) от моделей (Models), вы теперь разделяете каждый «кусок» или логическую единицу вашего приложения на индивидуальную службу, предназначенную для правильной работы с собственными обязанностями. Если у вашего MVC-приложения есть контроллер «Поиск», действия и соответствующие методы модели, то у нас уже есть пример монолитного приложения. Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессов. В качестве примера: Router сервис Request сервис Query сервис DataSource сервис Response сервис Но не все эти «сервисы» являются частью стека MVC? Конечно нет. Они являются строительными блоками нашего Monolith. С MOA каждый сервис работает в рамках собственной среды, а мы, как архитекторы, можем разработать лучший подход к решению конкретного запроса. В качестве примера, если я должен был бы написать службу обработки изображений в среде Laravel, я использовал бы что-то вроде расширения PHP-GD2, что может быть не самым эффективным способом обработки изображений. Служба C++, которая обрабатывает мои запросы в обработке изображений, может быть намного быстрее и определенно более надежной при масштабировании. И мы могли бы сделать вывод службы обработки изображений и отправить ее в службу DataStore, службу CloudStorage и службу Queue Email. Решение этой же задачи с кучей скрытых заданий и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев – это то, как разработчики делали это раньше (2 года назад). Время двигаться вперед. Масштабируемость Здесь возникают проблемы (или заканчиваются, в зависимости от того, куда вы держите курс). С одной стороны, очень сложно масштабировать Monolith: если вы создадите все больше и больше логики в одном и том же наборе MVC, вы застрянете с хорошо структурированным приложением ужасной сложности. С другой стороны, если вы построите тысячу микросервисов на разных языках, как вы будете управлять этим беспорядком? Существуют различные инструменты компоновки контейнеров (например, Kubernetes, Swarm, Mesos), услуги по развертыванию контейнеров (GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Есть удачные истории в построении инфраструктуры с использованием Docker или других контейнерных технологий (т. е. GKE). Большинство из этих историй исходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, дефолтов, администраторов баз данных и инженеров. Тем не менее, сейчас идут бесчисленные дискуссии о том, как развернуть хорошо организованный и элегантный MOA. В любом случае, вы не решите эту проблему самостоятельно, и пока вы не достигнете относительно большого масштаба, эта проблема действительно нуждается в решении. Может быть, сейчас не самое время усердствовать. Золотая середина на сегодняшний день (даже для тех, кто занимается приложениями меньшей сложности или не такими требованиями к трафику) заключается в том, чтобы разгрузить многие типичные сервисы сторонним провайдерам. Почти все доступно сейчас как сервис. Фоновые задания, обработка изображений, аутентификация, аналитика данных, ведение журнала, отправка электронной почты, системы очереди не обязательно должны строиться в одном стеке MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную стоимость (т.е. поиск Algolia) или, возможно, специально созданную докерную службу, работающую в облачном пространстве, которая выполняет эту обработку изображений. Я думаю, важно, чтобы вы не начали перепроектировать весь проект с начала, не сбрасывать все, что у вас уже есть, а выпускать докеры, где это можно сделать. Существуют способы постепенного развертывания вашего проекта/продукта путем разъединения, изучения узких мест в системе (и т.д.) и последующим применением разделения проблем в этих проблемных областях. Вывод 2017 год принес нам много дискуссий и производственных развертываний, основанных на контейнерах и MOA. Мои размышления о Docker, используя GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде ... Я считаю, что разработчикам нужно оставаться в тренде. Если микросервисы и дальше будут развиваться в том же русле, в котором это происходит сейчас, то почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки небольших контейнерных приложений. Node и GoLang позволяют создавать небольшие сервисы, которые являются частью более крупного проекта, связывают созданные сервисы и выпускают их как контейнеры Docker, если это необходимо в вашей работе. Тем не менее, все эти передовые решения и языки не уменьшают значимость и востребованность языка PHP. Разработчикам еще нужны будут стеки MVC и работа с  API. MOA пока не помогает решить архитектурные проблемы на стороне frontend, UI или Views, хотя при этом контейнеры помогают нам избежать работы с Monolith на backend. Мы можем создать чрезвычайно надежное backend-приложение, но оно среагирует на JSON, который каким-то образом должен быть представлен в клиентском приложении. Имеет ли значение, если результирующий объект ответа поступает из РНР кода, URL или от модулей принятия решений и обработки, разделенных интерфейсом обмена сообщениями? Это зависит от Ваших потребностей и требований к вашему приложению. Мой совет: в этом году учите Laravel, следите за Docker, GoLang и фокусируйтесь на конвейере развертывания. Продвижение от локального небольшого проекта к продакшену должно быть достаточно плавным, особенно при создании приложений MVC.   Оригинал статьи

Переход от AngularJS к Angular 2 был огромным шагом вперед. При этом изменилось абсолютно все, без обратной совместимости. В то же время, Angular 4 добавила новые возможности, но при этом была обратно совместимой с Angular 2 (Версия Angular 3 была пропущена из-за @angular/router, который на момент релиза был 3.x, в то время как остальные пакеты 2.x. Для того, чтобы избежать путаницы и перевести все пакеты к одной версии, третья версия была пропущена). Angular 5 - это следующее обновление, в котором изменения затронули механизмы, работающие «под капотом». Многие пользователи ITVDN задают вопрос об актуальности учебных программ видеокурса Angular Essential, который записан с использованием версии 2 и видеокурса Angular Advanced (версия 4). Angular 5 не является чем-то абсолютно новым, это улучшение существующего Фреймворка. Чтобы понять и начать использовать возможности, которые появились в пятой версии, необходимо знать основы, которые не изменились, начиная со второй версии. Что нового в Angular 5? Улучшенный компилятор. В Angular 4 компилятор перекомпилировал все файлы при каждом изменении. В Angular 5 компилятор работает только с теми файлами, в которых есть изменения, а это значит, что время на компиляцию проекта в целом значительно снизилось. Оптимизированная сборка. В Angular CLI при использовании production build совместно с версией Angular 5 по умолчанию будет применяться build optimizer, который с помощью семантического анализа кода приложения сможет значительно уменьшить его размер. Акцент на упрощение разработки PWA (Progressive Web Apps). PWA - это приложения, которые объединяют в себе лучшее, что есть в веб-приложениях и лучшее, что есть в мобильных приложениях. PWA работают независимо от выбранного браузера; адаптируются под устройство - десктоп, планшет, телефон; могут работать без подключения к Интернет или при перебоях со связью; выглядят как приложение, установленное на устройство; благодаря Service Worker содержат актуальную обновленную информацию; являются безопасными, так как работают через HTTPS; используют возможности, подобные push уведомлениям; Installable – позволяют пользователю добавить приложение на домашний экран устройства. Поддержка TypeScript 2.4. Angular 5 поддерживает версию TypeScript 2.4, что дает возможность использовать новые возможности TS: перечисления, основанные на строках, улучшения проверки типов при работе с generic-типами, week-type-detection и прочее https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-4.html Pipes, адаптированные под локализацию. Обновленные Pipes для Date, Currency, Number и Percent, нет необходимости использовать i18n. https://github.com/angular/angular/blob/master/CHANGELOG.md#i18n-pipes Новые события Router. Используя события ActivationStart и ActivationEnd или ChildActivationStart и ChildActivationEnd, можно организовать отображения индикаторов загрузки при смене маршрута. HttpClient. Новый HttpClient был добавлен в версии 4.3, старый http клиент помечен как depreceted в новой версии. В Angular 6 старый клиент будет удален. Из преимуществ нового клиента можно выделить самостоятельное извлечение JSON без необходимости явного применения метода map и возможность применять interceptors. https://angular.io/guide/http Валидация форм. Теперь при работе с формами, c помощью свойства updateOn, можно определить, в какой момент будет происходить проверка – на событие blur или submit (вместо проверки на каждое событие input). Замена ReflectiveInjector на StaticInjector. Изменен механизм для внедрения зависимостей. Для нового StaticInjector не нужен полифил Reflect (но при использовании JIT данные полифил все равно нужно будет использовать), что может уменьшить размер приложения. Angular CLI 1.5 использует Angular версии 5. Улучшение NgZone. NgZone стала еще быстрее, также библиотеку можно отключить для применения другой библиотеки для улучшения производительности. Улучшенный RxJS. Поддержка обновлена до версии 5.5.2 и выше. Поддержка новых pipable operators https://github.com/ReactiveX/rxjs/blob/master/doc/pipeable-operators.md Angular 5 получился компактней и быстрее, чем его предшественники, и не обошелся без новых возможностей. Запуск следующей версии Angular планируется на 28 марта 2018 года. Будем ждать улучшений и новых возможностей от команды Angular.

Введение Данная статья содержит подсказки и советы, как правильно запустить ASP.NET vNext на Linux.  Если Вы используете метод чистой установки, вам следует установить Mono 3.4.1 или более позднюю версию. Вы можете сделать это путем составления источников. Также установка Mono возможна с помощью менеджера пакетов.  1. Доступ к Ubuntu с помощью удаленного рабочего стола Если Ubuntu работает на облаке Windows Azure, а показать его нужно на Surface RТ, необходимо получить доступ к Ubuntu с помощью удалённого рабочего стола. Вот замечательное руководство по работе с удалённым рабочим столом с Ubuntu: Как установить xrdp в Ubuntu 14.04 Если Вам не нужно запускать браузер, то удалённый рабочий стол Вам не понадобится. Чтобы увидеть веб-приложения, работающие на Linux, Вам нужно открыть некоторые порты или использовать туннель для Linux. 2. Установка K Runtime Выполните следующие команды в терминале: curl https://raw.githubusercontent.com/aspnet/Home/master/kvminstall.sh | sh && source ~/.kre/kvm/kvm.sh Это позволит установить K Runtime Manager (KVM), K Runtime (Kre) и K Package Manager (KPM), также следует запустить приложения ASP.NET vNext. 3. Установите последнею версию KRE Теперь давайте установим последнею версию KRE. Выполните такую команду в терминале:  kvm upgrade Эта команда вызывает KVM для загрузки и установки последней версии KRE. 4. Натройка NuGet.config Вполне возможно, что NuGet не имеет никакого представления об источнике пакета ASP.NET vNext. Вы можете найти NuGet.config в: /home//.config/NuGet Если он имеет только пустые и закрытые теги конфигурации, то для изменения содержимого выполняйте: xml version="1.0" encoding="utf-8"?> <configuration>   <packageSources>     <clear />     <add key="AspNetVNext" value=https://www.myget.org/F/aspnetmaster/ />     <add key="NuGet.org" value="https://nuget.org/api/v2/" />   packageSources> configuration> 5. Получите Ваше приложение из Git Затем нужно получить источник ASP.NET vNext приложения для Вашей машины. Возможно, Вы используете Git. Чтобы скачать примеры приложений ASP.NET vNext, Вам нужно выполнить команду: git clone https://github.com/aspnet/Home.git 6. Восстановление пакетов Отправляйтесь к корневой папке вашего приложения ASP.NET vNext и, чтобы восстановить пакеты, используйте для запуска: kpm restore Теперь KPM восстанавливает все пакеты, необходимые для запуска приложения. Эта информация считывается из project.json файлов в приложениях корневых папок. 7. Запустите приложение Пришло время для запуска приложения: k kestrel Эта команда вызывает KRE и использует Kestrel как веб-сервер. Источник: http://gunnarpeipman.com/2014/10/running-asp-net-5-on-linux/

Существует несколько причин для создания суперпростых и легких HTTP сервисов, которые еще называются «микросервисами». Нет нужды говорить обо всех операционных и архитектурных преимуществах такого подхода к построению системы, так как это не раз обсуждалось на разных ресурсах. Я хотел бы показать пару техник построения весьма простых и компактных HTTP сервисов на основе ASP.NET Core без использования каких-либо фреймворков и с минимальным разрастанием кода. Предпосылки То, что я буду обсуждать в данной статье, базируется на пакете ASP.NET Core 1.2, который на момент написания еще не был в релизе. Я использую CI, поданную в ASP.NET Core, поэтому мой Nuget.config выглядит таким образом: Когда версия 1.2 добавится в Nuget, этого больше не потребуется. ASP.NET HTTP endpoints без MVC ASP.NET Core позволяет определить HTTP endpoints непосредственно на спецификации OWIN, которая построена вокруг, не используя полномасштабную структуру MVC и ее контроллеры для обработки входящих запросов. Так было с самого начала – вы могли использовать компоненты промежуточного программного обеспечения для обработки входящих HTTP запросов и короткую схему ответа непосредственно клиенту. Во многих проектах на основе профиля ASP.NET Core уже используется такая техника, например, Identity Server 4.  Это не новая концепция – нечто подобное существовало (хотя и в ограниченной форме) в классическом ASP.NET с HTTP модулями и HTTP обработчиками. Позднее, в Web API можно было определить обработчики сообщений для обработки HTTP запросов без необходимости определения контроллеров. И, наконец, в OWIN и в Project Katana это также было возможно через подключение к пользовательским компонентам промежуточного ПО. Другой альтернативой является точное определение пользовательского IRouter и прикрепление от него различных endpoints. Основное различие между этим подходом и подключением пользовательских компонентов промежуточного ПО в том, что маршрутизация сама по себе представляет единое промежуточное ПО. Это также дает нам возможность для гораздо более сложного сопоставления URL шаблона и определения ограничения маршрута – то, что Вам нужно было бы обрабатывать вручную в случае промежуточного программного обеспечения. ASP.NET Core 1.2 скоро представит ряд новых методов расширения на IRouter, которые сделают создание простых и компактных HTTP endpoints еще проще. Станет возможным заполнить более ранние версии ASP.NET Core этой функциональностью путем простого копирования новых расширений в ваш проект. Настройка базы для простого и компактного HTTP API Это project.json для нашего микросервиса. Он содержит только самые базовые пакеты. Мы используем здесь абсолютный минимум: • Kestrel и IIS интеграция выступают в качестве хоста сервера • пакет маршрутизации • пакеты протоколирования и конфигурации Для того, чтобы привести и наш код к абсолютному минимуму, мы можем даже бросить концепцию Startup класса для нашей API установки, и просто писать весь код бэкэнда API в одном файле. Вместо того, чтобы закреплять все в типичные Startup точки расширения, такие как методы Configure() и ConfigureServices(), мы повесим все на WebHostBuilder. WebHostBuilder довольно часто игнорируется разработчиками ASP.NET Core, потому что генерируется шаблоном в качестве точки входа внутри класса Program, и, как правило, нам не нужно даже изменять его – поскольку он по умолчанию указывает на класс Startup, где происходит почти вся работа по настройке и конфигурации. Тем не менее, он также предоставляет аналогичные зацепки, которые есть у Startup, поэтому можно просто определить все непосредственно на WebHostBuilder. Наша базовая API конфигурация приведена ниже. Она еще ничего не делает с точки зрения воздействия HTTP endpoints, но она полностью функциональна со стороны процесса подготовки создания (маршрутизатор подключен), входа в консоль и захвата конфигурации из JSON и переменных окружения. Мне нравится этот подход, поскольку он поразительно краток. Примерно в 20 строках кода мы имеем отличную базу для легкого HTTP API. Естественно, мы могли бы обогатить ее более широкими возможностями по необходимости – например, добавить в наши собственные сервисы или добавить проверку маркера с использованием соответствующих пакетов интеграции из Microsoft.Security или IdetntityServer4. Добавление HTTP endpoints в наше решение Финальный шаг – это добавление HTTP endpoints. Мы сделаем это, используя вышеупомянутый расширяющий метод, который будет представлен в ASP.NET Core 1.2. Для демонстрации нам необходима любая модель и сымитированные данные, чтобы использовать стандартный Contact и примеры ContactRepository. Код ниже запускается в расширяющем методе Configure() на WebHostBuilder, о чем уже было упомянуто ранее. Он показывает HTTP обработчики для получения всех контактов и получения контакта по ID. Этот код должен быть достаточно самостоятельным в описании – мы делегируем справочную операцию в хранилище и затем просто выводим результат в HTTP ответе. Расширяющий метод-маршрутизатор также дает нам доступ к значениям данных маршрута, делая простым управление сложных URI. К тому же, мы можем использовать обычные шаблоны маршрутов ASP.NET Core со всей мощью ограничений, которые очень удобны, например, так как вы и ожидаете, contacts/{id:int} не будут поставлены в соответствие для нецелочисленных ID. Я также помог себе, добавив удобный расширяющий метод для написания ответного потока. Финальный шаг – это добавление в HTTP endpoints изменения состояния серверной части: POST (добавить) новый контакт PUT контакт (изменить существующий) DELETE (удалить) контакт Нам потребуется дополнительный расширяющий метод, чтобы упростить это, потому что необходимо дессерилизовать запрос тела потока в JSON и нам хотелось бы проверить аннотацию данных нашей модели, чтобы гарантировать, что запрос от клиента является валидным. Очевидно, что будет глупо повторять код раз за разом. Этот расширяющий метод приведен ниже и в нем используются JSON.NET и System.ComponentModel.DataAnnotations.Validator. Заметьте, что метод вернет клиенту ‘400 Bad Request’, если модель не окажется валидной. Например, требуемое поле будет пропущено – мы также получим ошибку валидации. Далее показано определение HTTP endpoints: Вот и все – вы можете улучшить этот код, добавив в него, например, удобные методы чтения и выбора значений из RouteDataDictionary. Также не вызовет проблем усиление кода аутентификацией и даже внедрение в него новой авторизационной политики ASP.NET Core. Полный код нашего «микросервиса» (без вспомогательных расширяющих методов, которые, я предполагаю, вы в любом случае захотите собрать воедино и заново использовать) показан ниже – и мне нравится полученный результат. Я считаю, что это весьма привлекательный, лаконичный способ построения простого и компактного API в ASP.NET Core. Исходники доступны на Github. Оригинал статьи тут: http://www.strathweb.com/2017/01/building-microservices-with-asp-net-core-without-mvc/

Это действительно пугающая мысль. Ведь сегодня Вы работаете, выполняете задания, развиваетесь, а завтра вас «попросят»? Словно ваш труд не имел никакого значения. Как же это могло произойти? Что пошло не так? Разработчики проходят через это каждый день. Большинство разработчиков ничего не украли у своих работодателей, они не сделали ничего неэтичного, они были приятными и дружелюбными. Когда их просили о помощи, они всегда шли навстречу. Так чего еще хочет работодатель?! Как оказалось, намного больше. И вот разработчики уволены. Никто не указал им на конкретные ошибки, которые им нужно было бы избежать. Поэтому большинство продолжает совершать те же самые ошибки, сжигая мосты и разрушая свою карьеру. Совершаете ли вы какие-либо из этих ошибок? 1. Доверять своим клиентам, чтобы понять их потребности При разработке приложения ваши клиенты (читайте ваш работодатель) редко начинают с четкого представления о том, что им нужно. Все расплывчато и неясно. Как вам известно, именно с этого и начинается большинство приложений, проектов и идей. Вы можете не знать, что вашему клиенту нужен особый подарок – им нужно понимание. Поэтому вам необходимо сделать выбор. Каким разработчиком вы собираетесь стать? Вы Исполнитель, который просто делает то, что ему говорят? Или вы являетесь Незаменимым консультантом, на которого полагается ваша команда? Потому что Исполнители заменяемы. Работодатели находят разработчика, который может выполнять работу. Они говорят ему, чего хотят, и разработчик делает это. Простая формула, да? Пока ваш клиент не найдет кого-то еще. Того, кто может сделать то же самое, но быстрее и за меньшие деньги. Неудивительно, что большинство разработчиков программного обеспечения становятся неконкурентоспособными к моменту, когда они достигают 40 лет. Может быть, работодатели думают, что это дело для молодых Или что люди старше 40 лет устарели Возможно, эти разработчики не знакомы с новой технологией Слишком много разработчиков являются простыми Исполнителями. Если вы Исполнитель – причина увольнения не имеет значения. В какой-то момент вашей карьеры вы просто будете навсегда заменены. С другой стороны, незаменимыми консультантами являются... Незаменяемые. Такие разработчики дают своим клиентам понимание, в котором те нуждаются. Когда проект на старте, такие разработчики стремятся вникнуть в суть. Они спрашивают о пользователях и особенностях, которые клиенты хотят видеть в проекте, спрашивают об их мотивации, обо всем, что только может прийти в голову. Такие разработчики ценятся везде, где бы они ни находились. Они рок-звезды на работе Или они вносят свой вклад в сообщество с открытым исходным кодом Часто они учат и обучают других Куда бы они ни пошли, они отдают и помогают другим. Такое отношение создает огромный контраст между ними и их коллегами, которые являются простыми исполнителями. Они делают других лучше. Делают отрасль чуть-чуть лучше. Это невозможно игнорировать. Их отдача становится их секретным оружием. Когда они оказывают помощь, они доносят информацию другим о том, что: Они эксперты. Они знают, о чем они говорят. Другие признают их компетентность. Если разработчик Незаменимый, тогда он – звезда. Если вы именно такой, тогда ваша ценность стремительно растет. А теперь лучшая часть – любой разработчик, каждый разработчик, может быть Незаменимым консультантом. 2. Не доверять своим клиентам, чтобы понять его потребности. Я только что сказал, что доверять клиентам – это плохая идея. Теперь я говорю, что и не доверять им – это ошибка? Дело в том, что все вопросы за пределами основной работы разработчика – бизнес в целом, продажи, стратегия, маркетинг – это сферы, в которых он должен полагаться на своего клиента (то есть вашего работодателя). Есть 2 типа реакции разработчиков при возникновении таких вопросов. Первый – это определенная степень апатии и равнодушия. Как только возникает незнакомая тема, такие разработчики тушуются или отключаются. Такое отношение говорит прямо: мне все равно. Второй – это знатоки. Есть разработчики, которые «думают», что разбираются абсолютно во всех вопросах. Они не хотят учиться у тех, кого они считают «ниже» своего уровня, или же делают это неправильно. Оба таких разработчика не понимают один важный нюанс. Люди вокруг вас могут почувствовать такое отношение. Вместо ценного вклада они получают апатию или презрение. Они мысленно замечают это и в дальнейшем будут действовать соответственно. Откуда я знаю, что я прав? От вас. Вы принимаете к сведению такое же отношение и к себе. Сколько раз вы рекомендовали приятеля или друга для проекта? Сколько из ваших друзей устроились на работу по вашим рекомендациям или при вашей помощи? Как часто вы замечаете «того» сотрудника, который отказывается документировать свою работу? Понимаете, о чем я? У вас есть стандарты. Как есть они и у других. Разработчики «Рок-звезды» задают вопросы. Они проявляют инициативу. Они работают, чтобы понять, как могут помочь остальным (в управлении, финансах, маркетинге и т.д.). У таких разработчиков есть глубокое понимание того, как их работа затрагивает всех остальных. Это редкое, но невероятно ценное качество. 3. Использование фразы «это невозможно сделать» как запасной вариант Написание кода, по своей сути, является решением проблемы. Вы это уже знаете. Как и все остальные. Как разработчик, вы всегда спасаете ситуацию и превращаете идеи других в настоящую реальность. Разработчики -  буквально инженеры будущего. Поэтому, когда не-разработчик слышит фразу «это невозможно сделать», он не верит вам. Да и почему он должен поверить? Ведь снова и снова вы делали невозможное возможным. Раньше вы всегда находили способ выполнить работу. Вы обыскивали форумы, тестировали открытый исходный код, отправляли вопросы на Stack Overflow – вы делали все, что нужно было делать. И пока вы не сдавались, вы побеждали. Когда не-разработчик слышит «это невозможно сделать», то в действительности он слышит: «Я не хочу». Ничто не раздражает так не-разработчика больше, чем слова: «это невозможно». Почему? Потому что это звучит так, будто Вы даже не хотите попробовать. Поэтому сначала коллеги просят вас найти способ. Потому что они верят в вас. Конечно, иногда это раздражает. Это расстраивает, когда на вас бросают задачи и ожидают, что все будет сделано. Они думают, что все очень легко и просто. Вы же знаете, что это не так. Ваши коллеги, как дети - они не знают, как это работает, просто вы волшебник, который делает зрелищные вещи. И они любят Вас за это. Некоторые вещи действительно невозможны. Вся проблема в том, как сообщить о реальной невозможности. Вы обращаетесь к не-разработчику, гневаясь? Ворча и жалуясь за спиной? Распространяя плохое отношение вокруг? Или, как разработчик, вы ищите компромисс? Вы предупреждаете их о негативных последствиях, которые связаны с тем, чего они хотят, и предлагаете решение? 4. Снисходительность и презрение «Я ненавижу маркетинг». «Менеджеры глупые». «Продавцы хуже всех». «Мой босс-идиот снова просит меня сделать что-то глупое». Вы когда-нибудь думали подобным образом? Я знаю, что да, потому что я думал. Это совершенно естественно. На самом деле, многие люди так думают. Если Вы являетесь частью какой-то подгруппы, скорее всего, вы тоже так думаете. В нашей культуре это даже поощряется. Богатые против бедных Разработчики vs маркетологи Фриланс vs клиенты Люди, с которыми мы взаимодействуем, не являются частью нашей группы разработчиков? Они чувствуют и знают, как мы на самом деле относимся к ним. Вот почему это проблема. Вы и ваши коллеги должны быть в одной команде, только в этом случае не появляются «мы» и «они». Невидимые барьеры, которые делят вашу команду. Политика и борьба за влияние становятся нормой, поскольку каждый борется за свою работу. Бонусы, рост и стимулы начинают исчезать. Отношение, от которого веет снисходительностью и презрением, делает две вещи. Это отдаляет Вас от других людей. Вы становитесь «тем человеком», с которым ужасно работать. Это медленно душит существующие отношения. Друзьям становится все труднее защищать вас, общение с вами начинает негативно сказываться на ваших коллегах. Они ничего не скажут напрямую – просто будут молча отдаляться. Как только вы потеряете друзей и союзников, все начнет рушится, пока в конце концов вы не уйдете с работы. 5. Ложные обещания и незавершенная работа «Я сделал». «Получилось вроде неплохо». Вероятно, вы и сами получали подобные обещания и ответы. Вы знаете, что «это сделано» может не отвечать действительности. Это распространенная ошибка. Разработчик сообщает своему менеджеру, что команда закончила свою работу. "Все работает!" И менеджер делает то, что делают большинство хороших менеджеров. Он доверяет им и готовится проверить их работу. Или, в некоторых случаях, он не выполняет проверку. Заведомо плохая идея, но он доверяет своим разработчикам. Он верит в них, поэтому рискует. Потому что его боссы дышат ему в затылок. Может быть, его работа на очереди или покупатель настаивает на доставке. Все, что угодно. Как бы то ни было, вскоре менеджер обнаруживает, что разработчик, которому он доверял и на которого рассчитывал, подвел его. Он никогда не забудет эту ошибку. Ему будет трудно снова доверять этому разработчику. Это также может изменить его убеждения относительно разработчиков в целом. Несправедливо, конечно, но это реальность. Если он умный, он проверяет и перепроверяет работу этого разработчика. Если он действительно умный, он проверяет работу каждого. Но это замедляет работу. Вместо того, чтобы доверять всем в команде, чтобы проявить себя и добиться своей цели, он попытается все проверить. Страх и неуверенность менеджера начинают расти. До определенного дня… Когда вас посчитают ненадежным сотрудником. Мы все сделали эти ошибки И они еще не разрушили нашу карьеру. Хороший факт о людях: они дают второй шанс. И третий. И четвертый. Вы будете удивлены, сколько шансов вам готовы дать, когда вы компетентны и стараетесь быть лучше. В какой-то момент люди теряют терпение. Они больше не хотят работать с теми, кто продолжает повторять свои ошибки, они не хотят мириться с этими проблемами. Когда так происходит, обычно виновных увольняют. Повторите эти ошибки достаточное количество раз - и ваша карьера разработчика будет закончена. Ваш послужной список будет преследовать вас. Бывший коллега предупредит всех на новой работе, что от вас следует держаться подальше. Великие разработчики не делают этих ошибок. Это правда. Если Вы дочитали так далеко, есть большая вероятность, что вы один из них. Главная проблема – это ваше отношение, а не борьба со своими ошибками. Если вы работаете над тем, чтобы стать лучше, вы добьетесь успеха. Если вы, узнав об этих ошибках, отреагировали негативно – в форме цинизма, горечи или обиды – тогда вы в зоне риска. А как насчет других разработчиков? Тех, кто продолжает бороться с этими ошибками? Будьте терпеливы с ними. Если они открыты к обсуждению, научите их. Поделитесь этой статьей. Помогите им стать лучше. Не оставляйте их одних. Получите помощь, если Вы сами боретесь с этими проблемами. Потеря вашей карьеры – пугающая мысль Представьте, что каждый день вы работаете и находитесь там, где необходимы. Где ваши коллеги доверяют вам. Где они видят в вас Незаменимую часть своей команды. Как бы вы себя чувствовали в таком окружении? Хорошо, правда? Вы получаете желаемые результаты от своей карьеры, вы - рок-звезда на работе, и вы контролируете свое профессиональное будущее. Если вы действительно работаете. Навыки кодинга являются обязательными, но, как мы увидели, их недостаточно. Станьте рок-звездой. 

Введение Microsoft Azure является облачно-вычислительной платформой и инфраструктурой, предоставленной корпорацией Microsoft. Эта платформа выполняет такие функции, как построение, развертывания и управления приложениями и услугами, и они могут быть доступны по всему миру. Azure доступен как Платформа, как сервис (PaaS) и Инфраструктура, как сервис (IaaS). Чтобы сделать развертывание приложения.NET на Microsoft Azure, Visual Studio 2012 и Visual Studio 2013 предоставляет Вам необходимые инструменты. Вы можете загрузить полную версию Visual Studio 2013 года здесь. Чтобы использовать Azure, сначала нужно посетить сайт manage.windowsazure.com и подписаться на эту услугу. Вы также можете получить бесплатную пробную подписку, чтобы начать работу. После входа на портал, на следующем рисунке продемонстрированы некоторые службы/функции, которые можно получить: В этой статье мы будем использовать приложение, созданное с помощью Angular.js, MVC, WEB API для выполнения CRUD-операций. Мы будем публиковать приложения на Azure в качестве веб-сайта. Загрузите исходный код и откройте это приложение в Visual Studio 2013. Создание сервера базы данных с помощью SQL Azure Чтобы успешно запустить веб-сайт, Вы должны развернуть базу данных, используемую нашим веб-сайтом в облаке. Чтобы развернуть базу данных Azure, нужно создать сервер базы данных, используя Azure SQL. Шаг 1: Выберите SQL DATABASES, и Вы увидите страницы базы данных, как показано здесь: Выберите Servers, это позволит создать новую базу данных SQL SERVER. Нажмите кнопку  "CREATE A SQL SERVER DATABASE", ниже появится окно: Введите необходимые данные. После ввода данных выберите галочку в нижнем углу, чтобы создать базу данных сервера: Кликаем на кнопку "MANAGE" внизу страницы, это позволит Вам добавить сервер доступа в правила брандмауэра, так чтоб был получен доступ к приложению. Эти правила добавят IP-адрес вашей машины в правила брандмауэра. Чтоб узнать имя экземпляра сервера базы данных, кликаем по имени базы данных для отображения информационной панели. Прокрутите вниз страницы панели мониторинга для отображения MANAGE URL. Она начинается от https://.database.windows.net. Часть URL после https://, имя экземпляра базы данных. Шаг 2: Чтобы Соединиться с сервером базы данных, скопируйте часть URL после http://, и от локального экземпляра SQL Server, кликаем по Connect на объектном проводнике, и в Connect To Server окно вводит детали базы данных как показано здесь: Это выведет на экран Сервер базы данных Azure SQL экземпляр в объектном проводнике на локальном экземпляре SQL Server. Введите необходимые параметры. SERVICE TIERS позволит выбрать уровень базы данных, таких как BASIC | STANDARD | PREMIUM. Выберите уровень BASIC. Выберите SEERVER как сервер базы данных, его мы создали ранее. Создаваемая база данных будет такая, как показано на изображении: Кликните по кнопке MANAGE внизу страницы, она создаст правило Брандмауэра для того, чтобы установить доступ базы данных: Далее откроется следующая страница, где информация об Администраторе Базы данных обязательна к заполнению: Клик на Log On выведет на экран следующую страницу:  Кликните по “Design”, чтобы составить таблицы, Views и Stored Procedures. Кликаем по “New Table” и создаем список сотрудников, как показано: Введите простые записи в эту таблицу, используя ссылку New Query. Внесение изменений в Web.config файл MVC-приложения Откройте приложения MVC в Visual Studio 2013 и внесите следующие изменения в строку подключения. data source=; initial catalog=Application; user id=; password=; MultipleActiveResultSets=True; App=EntityFramework" "providerName="System.Data.EntityClient" />   (В качестве альтернативы Вы можете запустить Entity Framework в проект, в папку Models для создания строки подключения) Создание Веб-Сайта С Помощью Windows Azure Portal Нажмите кнопку на сайте, чтобы отобразить параметры создания веб-сайта. Нажмите на ссылку CREATE A WEBSITE. Это приведет к появлению следующих вариантов для создания веб-сайта:     Далее Вы можете ввести информацию о URL. Введённый URL уникальный и будет проверен Azure. Если это имя не будет корректное, то URL будет .azurewebsites.net. Центр обработки данных должен быть выбран согласно Вашему выбору. Как только Центр обработки данных выбран, тогда все другие ресурсы, необходимые веб-сайту, например, Базы данных SQL, должны быть размещены в том же Центре обработки данных, так как это поможет в управлении затратами. Как только будет создан Веб-сайт, портал покажет детали:     Чтобы получить детали о веб-сайте, кликните по его имени, ниже будет выведена инструментальная панель на экран, она поможет в управлении и мониторинге веб-сайта.     Чтобы опубликовать наш веб-сайт, созданный с помощью VS tools в Visual Studio, мы должны загрузить профиль публикации. Он может быть загружен и скачан по ссылке, как продемонстрировано на изображении. Публикация веб-сайта в Visual Studio Откройте SPA Application в Visual Studio 2013. Кликните правой кнопкой по названию проекта, чтобы вывести на экран контекстное меню Publish Option.     Эта опция выведет на экран следующее окно:     Данное окно имеет следующие параметры: Microsoft Azure веб-сайтов - поддержка прямого входа на Windows Azure на основе подписки. Import - позволяет импортировать веб-сайт и публиковать профиль, который загружается с портала Azure. Custom - позволяет создать новый профиль, публиковать для развертывания веб-сайта.   Нажмите на кнопку "Import" и будет отображено следующее окно для импорта профиля публикации:     После нажатия "OK", будет отображено следующее окно с деталями веб-развертывания:     Кликните “Next”. Так как мы уже развернули базу данных по Azure SQL, и последовательность подключений к базе данных уже обновлена в web.config файле, следующее окно покажет строку подключения:     Выберите “Далее”, чтобы отобразить список файлов, которые будут опубликованы:     Кликните по кнопке “Publish”, веб-сайт будет опубликован со всеми требуемыми ссылками.  Как только веб-сайт будет успешно опубликован, он может быть просмотрен.     Примечание: в этой статье не использовался CSS и, следовательно, неправильно расположение таблиц. Добавьте свои CSS, чтобы украсить страницу. Таким образом происходит развертывание веб-сайта на Azure. Источник: http://www.dotnetcurry.com/showarticle.aspx?ID=1064

Мир IT привлекает многих: высокая зарплата, удалённая работа, интересные задачи. Но перед тем как начать обучение, немало людей останавливаются… из-за страха. И часто причина — в мифах, которые давно не имеют ничего общего с реальностью. В этой статье мы развенчаем пять самых распространённых мифов, которые мешают новичкам начать путь в программировании. Миф 1  «Чтобы стать программистом, нужно быть математическим гением» Этот стереотип до сих пор пугает многих. На самом деле, для старта в ИТ нужно логическое мышление, а не знание высшей математики. Да, в некоторых направлениях (например, Data Science или GameDev) математика важна. Но в Web-разработке, QA, DevOps, Backend-проектах ты можешь работать, даже если в школе не любил алгебру. Факт: согласно исследованию IBM, 72% ИТ-специалистов имеют гуманитарное образование, а не техническое. Миф 2  «Обучение длится годами» Традиционное высшее образование — это 4–5 лет, но в ИТ всё иначе. Онлайн-курсы, буткемпы, интенсивы позволяют получить базу за 6–12 месяцев. На платформе ITVDN студенты изучают HTML, CSS, JavaScript, Python или C# в своём темпе и получают практические навыки, которые востребованы работодателями. Даже после нескольких месяцев обучения можно найти стажировку или пройти тестовое задание. Миф 3 «Программирование — это только для “ботаников”» Существует представление, что программист — это замкнутый человек, который общается только с компьютером. На самом деле, это творческая и командная профессия. В ИТ ценятся коммуникация, инициатива, умение находить решения. Многие разработчики начинали как фитнес-тренеры, учителя, маркетологи или менеджеры. Программирование — это навык, который может освоить каждый. Миф 4  «Без университета тебя никто не возьмёт» Современные компании ценят скиллы, а не дипломы. Если у тебя есть GitHub, выполненные проекты, сертификаты, знание английского — это уже даёт преимущество на старте. Большинство студентов ITVDN не имеют ІТ-диплома, но после обучения успешно проходят собеседования и получают первую работу. Во время рекрутинга самое важное — практика, мышление и портфолио, а не формальное образование. Миф 5 «Чтобы стать программистом, нужно сразу знать все языки» Это один из самых вредных мифов. На самом деле, достаточно выбрать один язык для начала — и на его основе построить фундамент.  Например: Python — отлично подходит для аналитики, автоматизации, backend JavaScript — идеален для веб-разработки C# / .NET — популярен в корпоративных приложениях Позже ты сможешь добавить другие языки, но сначала важно научиться думать как программист. Мифы — это психологические барьеры. Они рождаются из незнания, чужого опыта или устаревших представлений.  А правда такова:  ✅ В программирование можно прийти с нуля  ✅ Даже если тебе далеко не 20  ✅ Без технического образования  ✅ И без “гениального” уровня IQ  Главное — мотивация, правильная программа и поддержка, которые помогут пройти путь от первого кода до первого оффера.

Сейчас трудно представить себе любого девелопера без использования фреймворков. Здесь вы найдёте 5 лучших и наиболее признанных фреймворков для Python-разработчиков. Что такое framework? Говоря простым языком, фреймворк — набор инструментов для программиста. Фреймворк существенно упрощает разработку за счёт готовых решений и чётко выделенной структуры разработки приложений, сайтов. При использовании фреймворка вы значительно сэкономите себе время, ведь вам не придётся тратить его на решение рутинных задач программирования. Вместо этого вы сможете уделить внимание непосредственно разработке, сократив потраченное время с нескольких недель до пары дней. При использовании framework’a вы будете совершать меньше ошибок из-за невнимательности, и ваш синтаксис станет лучше. Кроме того, каждый framework оснащён собственной системой безопасности, которая защитит вас от случайной поломки программы. Большинство фреймворков являются бесплатными и имеют открытый код, хотя некоторые придётся покупать. Представляем вашему вниманию 5 лучших фреймворков для разработки на Python. Django «Классический» Python-framework, Django серьезно упрощает разработку за счёт большого количества доступных функций и паттернов. Имеет открытый код и предлагает большое количество возможных решений. Django относится к так называемым full-stack фреймворкам, которые универсальны и содержат все стандартные функции и шаблоны. К ним относится: аутентификация, маршрутизация, миграция баз данных, ORM и прочие. Django можно использовать для администрирования содержимого сайтов, аутентификации, RSS. Он отлично подойдёт для создания сайтов. Фреймворк работает с основными БД: MySQL, SQLite, PostgreSQ, Oracle. При необходимости можно установить специальные драйверы для подключения других баз данных. В целом этот фреймворк можно считать универсальным для Python-разработчиков. Он имеет большую базу шаблонов и на ура справляется со стандартными задачами, а также может помочь в решении нестандартных. Имеет полностью переведённую на русский язык техническую документацию. С хорошим переводом. Flask Платный мини-фреймворк, который предоставляет прочную основу для создания веб-приложений. Вмещается в один файл и легко устанавливается, пригодится в создании мелких и средних проектов, но не подойдёт для крупных из-за недостатка шаблонов и готовых решений. Предоставляет готовые шаблоны для маршрутизации, поддержку безопасных кукисов, WSGI 1.0. Имеет встроенный дебаггер и сервер для HTTP-разработки. Сервер поддерживает fapws3, GAEM, CherryPy, BJoem. Pyramid Бесплатный фреймворк типа «всё включено», разработан для приложений на основе Питона. Универсален и подойдёт как для создания небольших, так и больших проектов. Легок в установке, понятен, не тормозит. Имеет минималистичный дизайн. Имеет большое количество готовых шаблонов, в основном рассчитанных на разработчиков API. Умеет генерировать URL, помогает при аутентификации и авторизации пользователей, удобен для создания однофайловых приложений. Отлично подходит для тестирования и отладки. Twisted Создан для решения специальных задач сетевых разработчиков.  Быстр, бесплатен, сокращает время разработки сервисов в несколько раз. Создан на базе Deferred, которая упрощает обслуживание сетевых запросов и обработку ошибок.  Одно из главных оружий сетевого разработчика. Не подойдёт для разработки типичных веб-приложений из-за своих шаблонов и структуры. Twisted используется для разработки небольших асинхронных программ. Поддерживает большинство сетевых форматов: TCP, UDP, SSL/TLS, Domain sockets; умеет работать с сетевыми протоколами: HTTP, NNTP, XMPP, IMAP, IRC, FTP, SSH и прочими. Ещё больше модулей и форматов можно подключить с помощью драйверов. Имеет дополнительные структуры: Unit test (с поддержкой системы Deferred), Processor pools и т.д. Tornado Асинхронный фреймворк и одновременно сетевая библиотека по типу Twisted. Справляется с классической проблемой С10k (то есть может обрабатывать свыше 10 000 поступающих сетевых запросов). Представляет из себя солянку из Django, Flask и Twisted, но при этом быстрее их. Имеет встроенные шаблоны для аутентификации и авторизации, с поддержкой внедрения других шаблонов (например, Google), не блокирующийся HTTP-клиент.  Справляется с длинными запросами (long polling’ами), имеет поддержку web-сокетов. Используется разработчиками, которые создают масштабные сетевые приложения с большой нагрузкой и высокими требованиями к производительности. Каждый год количество новых фреймворков постоянно растёт, но некоторые из них уже несколько лет держатся на плаву, периодически изменяясь. Эти пять уже признаны чуть ли не классикой, и начать изучение мира фреймворков стоит именно с них. Потом вы сможете перейти на более специфические, предназначенные для решения определённых задач. Если вы изучаете программирование на Python и хотите освоить самые популярные фреймворки, смотрите видеоуроки ITVDN для Python-разработчиков, а также смотрите записи вебинаров на YouTube канале ITVDN.