I recently installed a fresh copy of Visual Studio 2017 on a new computer. And I am migrating some code from .NET 4.6 to .NET Core. After some hair pulling over changes in the libraries, it now compiles and runs great.
But when I go to deploy to Azure Websites I get errors that look like this:
The command "bower install" exited with code 9009.
The command "npm install" exited with code 9009.
So what is Bower, and Gulp and why are they interesting in a code migration?
A fluent API can be incredibly helpful when sharing your application with other developers.
Fluent methods are a hot design idea and they can improve the readability of your code. However, they only make sense in specific scenarios.
A fluent interface (as first coined by Eric Evans and Martin Fowler) is a method for constructing object oriented APIs, where the readability of the source code is close to that of ordinary written prose.
A fluent interface is normally implemented by using method cascading (concretely method chaining) to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining ). Generally, the context is
- defined through the return value of a called method
- self-referential, where the new context is equivalent to the last context
- terminated through the return of a void context.
— From Fluent Interface
In the last post, Building Stateful jQuery UI Plugin Using Widget Factory, you were introduced to the working structure of jQuery UI Widgets. You learned that it uses the factory pattern is a way to generate different objects with a common interface. And that it Widget Factory adds features to jQuery plug-in.
jQuery UI Widget Factory is under jQuery UI, but you can use it separately for your own widgets. In this post, you will learn the steps you can take to build your own widget. This posts walks through an implementation of the filterable dropdown from Adam J. Sontag’s and Corey Frang’s post: The jQuery UI Widget Factory WAT?
My motivation in this post is to show what goes where when you are designing your widgets. And provide some direction in the steps you can take when building a widget from scratch.
In this post, you will learn step-by-step to build your own custom, reusable, testable jQuery UI widget.
You will extend the jQuery library with custom UI code and then use it on a page. The initial plug-in will be trivial to demonstrate the jQuery Widget Factory pattern. You will provide properties that you can change to change the look of your widget and you will provide some methods that will respond to user input.
In this post example, you will learn how to create a simple click counter. Click a button, increase the count. The idea is to show you the steps to create a jQuery UI Widget.
The Widget Factory system manages state, allows multiple functions to be exposed via a single plugin, and provides various extension points.
In this post, you will learn step-by-step to build your own custom, reusable, testable jQuery Plugin.
There are times where you will want to reuse code that performs a series of operations on a selection.
For example, you may want to embed information a span element and then have that information displayed in a references section near the end of the document. In this case, the jQuery plugin is stateless.
In the next post, Building Stateful jQuery UI Plugin Using Widget Factory, you will see how to create a stateful jQuery plugin using jQuery Widget. And you will see how the widget is a better solution for plugins that require user interaction, because the Widget factory helps you maintain state.
Azure Content Delivery Network (CDN) is designed to send audio, video, applications, images, and other files faster and more reliably to customers using servers that are closest to each user. If you want to put binary files and blobs closer to your user, then CDN can be the right solution.
The CDN caches publicly available objects at strategically placed locations to provide maximum bandwidth for delivering content to users.
Essentially, when a user wants some content, the first user gets the data from the source server. When you use a CDN, that data is then cached at a site near the user. So subsequent users can get the data from the cache instead of going all the way back to the source server. For example, if a picture stored in a blob is in a European data center in Azure, a user in Portland Oregon would be able to access the file from a server set up in Seattle, making your image load much faster.
Azure Redis Cache helps your application become more responsive even as user load increases and leverages the low latency, high-throughput capabilities of the Redis engine. This separate distributed cache layer allows your data tier to scale independently for more efficient use of compute resources in your application layer.
Redis is an open source, BSD licensed, advanced key-value cache and store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs. Redis supports a set of atomic operations on these data types.
Microsoft Azure Redis Cache is based on this cache and store. It gives you access to a secure, dedicated Redis cache, managed by Microsoft, providing the best of both worlds: the rich features and ecosystem of Redis, and reliable hosting and monitoring by Microsoft.
You can use Redis from most programming languages used today.
Azure Redis Cache leverages Redis authentication and also supports SSL connections to Redis.
The purpose of this article is to help you decide if Azure Redis is the right technology for your project. The Azure documentation is pretty good to help you get started, but is spread all over the place, so this article focuses on the steps to get started, and gives you a peek into what your code looks like. (If you are like me, you can often tell if the technology is a good fit by seeing code.)
NOTE: Of course, you can use Redis without Azure. For more information on that, see Distributed Caching using Redis Server with .NET/C# Client.
Microsoft Azure Cache is a family of distributed, in-memory, scalable solutions that enable you to build highly scalable and responsive applications by providing super-fast access to your data. But what do you choose?
This post provides you with an overview of the options you have when you are considering caching technologies.
Microsoft Azure Cache is available in the following offerings.
Microsoft offers a strong recommended choice for these caches. “Microsoft recommends all new developments use Azure Redis Cache.”
That said, this post discusses each to give you a quick overview. This article also introduces you to one other cache.
Here’s the short answer:
- Use Azure Redis Cache when you want to cache string, hashes, .NET classes, data.
- Use CDN when you want to cache audio, video, applications, images, and other files.
John Munsch explains it like this:
When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.
What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat.
In designing an object-oriented application, a major tenet of design is “loose coupling”. Objects should only have as many dependencies as is needed to do their job – and the dependencies should be few.
There are three primary approaches to implementing DI:
- Constructor injection
- Setter injection (also called Property injection)
- Method injection
Constructor injection uses parameters to inject dependencies. In setter injection, you use setter methods to inject the object’s dependencies. Finally, in interface-based injection, you design an interface to inject dependencies.
In his talk on Some REST Design Patterns (and Anti-Patterns), Cesare Pautasso explains, “REST architectural style is simple to define, but understanding how to apply it to design concrete REST services in support of SOA can be more complex.”
Several SOA Design Patterns:
- Uniform Contract
- Endpoint Redirection
- Content Negotiation
- Idempotent Capability
In this post, you will learn the design methodology, walk through a step by step scenario where the client and server trade information to perform a set of actions, and you will learn more about the SOA design patterns.
In the previous posts, you learned how to design your RESTful API. In this post, you will learn about the best practices of versioning, analytics, how to set up your API root, what your consumers are expecting for results, why and how filtering should work, and caching.
In the post Designing Your RESTful API Part 1: The Nouns, you learned the importance of resources, request headers, and the request body when you defined your RESTful API. In this post, you will learn about the five or so request verbs and what is send back to the client in the response body and the response status code.
Everything is a resource in REST. As you learned in Choosing Between RESTful Web Service, SOAP, Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
In this post, you will learn the how to define your resource identifier. In the following post, you will learn how to use the HTTP verbs and response codes. And along the way you will learn many of the principles of a good RESTful API.
Let me second what As Thomas Hunter II writes:
The easier your API is to consume, the more people that will consume it.
Representational State Transfer (REST) is an architecture style or design pattern for creating web services which allow anything connected to a network to something else on the network using Hypertext Transfer Protocol (HTTP).
Typically we think of a RESTful Web Service as one that will get and set data. It works a lot the same way as a web page, but your user doesn’t see the data until it’s time to be displayed.
REST principles are based on the same underlying principles that govern the Web. Those principles are:
- User agents interact with resources, and resources are anything that can be named and represented. Each resource can be addressed via a unique Uniform Resource Identifier (URI).
- Interaction with resources (located through their unique URIs) is accomplished using a uniform interface of the HTTP standard verbs (GET, POST, PUT, and DELETE). Also important in the interaction is the declaration of the resource’s media type, which is designated using the HTTP Content-Type header. (XHTML, XML, JPG, PNG, and JSON are some well-known media types.)
- Resources are self-descriptive. All the information necessary to process a request on a resource is contained inside the request itself (which allows services to be stateless).
- Resources contain links to other resources (hyper-media).
Or your application may want to be “cloud ready” from the beginning. The vision may begin with a set of servers, each doing a specific task, each that can be scalable to meet demand, provide reliability. As soon as you take that second step, it’s time to look to well known practices.
Microsoft’s Patterns and Practices team has put together architectural guidance to help you design your cloud applications, Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications. Each pattern is provided in a common format that describes the context and problem, the solution, issues and considerations for applying the pattern, and an example based on Azure.
It also discusses the benefits and considerations for each pattern. Most of the patterns have code samples or snippets that show how to implement the patterns using the features of Microsoft Azure.
Although the guidance helps you adopt Azure, the patterns are relevant to all kinds of distributed systems, whether or not they are hosted on Azure or on other cloud platforms.