In today's post, I want to talk about the differences between the aspx and cshtml page. The main difference between  the two is that aspx page is a server side dynamic page and the cshtml page is a Razor view engine page. The aspx page is subject to the page life cycle events that ASP.NET is known for. The cshtml pages work with a model data structure for the data to be edited or rendered in the page. Both aspx and cshtml page can use Controller and model as well as viewmodels.
When using an aspx page, the syntax for populating the fields of the model is with the <% and that for the cshtml is using the @Html. The @notation comes from the Razor engine.
The page life cycle events in the aspx allows for fine grained control of the server page and controls. This means that some of the controls can process their states independently and leads to organization of code based on controls on the page. The cshtml page can also organize based on partial and full pages. However each view is associated with a viewmodel or model.
The Razor syntax enables the HTML generation with terse code. This is a view engine. This is more suited for stateless http requests and responses.
The web forms on the other hand enable state to be maintained between requests.
In terms of testing, it is easier to test cshtml rather than aspx because the view is separated from the ther concerns.
Similarly, the idea of the code behind occurs only in the aspx pages where the logic is moved out from the view declaration. However it is still a tightly coupled architecture and requires integrated testing for the pages to work correctly. The has often been troublesome.
The aspx page and the cshtml page can both include client side scripts and content however the aspx pages clutter the view with almost duplicate server side controls and notation as opposed to cshtml which is cleaner in the sense that it has only HTML5 notation. Much of this is evident in the absence of any server side controls in cshtml.
Similarly, the aspx page allows writing custom controls and logic that add to the variety and complexity of the view whereas with the separation of model and view and HTML only syntax the cshtml is far more clean.
Lastly, there is a convenience to store and render state with aspx that is unparalleled in cshtml. If anything the state can be consolidated across application instance and with web farms. This is done via models and model state in cshtml to some degree .

In today's post,
I want to talk about the differences between the aspx and cshtml page. The main difference between the two

is that aspx page is a server side dynamic page and the cshtml page is a client side static page. The aspx

page is subject to the page life cycle events that ASP.NET is known for. The cshtml pages work with a model

data structure for the data to be edited or rendered in the page. Both aspx and cshtml page can use

Controller and model as well as viewmodels.
When using an aspx page, the syntax for populating the fields of the model is with the <% and that for the

cshtml is using the @Html. The @notation comes from the HTML5.
The page life cycle events in the aspx allows for fine grained control of the server page and controls. This

means that some of the controls can process their states independently and leads to organization of code

based on controls on the page. The cshtml page can also organize based on partial and full pages. However

each view is associated with a viewmodel or model.

Combining user accounts with client registration pages for an API implementation web site integrates the developer and the user. Development requires an account to test the user page and registration combines the step for the two. Besides both are the company's assets. A client registration page has details such as an account for registering, a display name which is the name that others will see, an e-mail where the validations are sent to. Validations are required to confirm that the data entry is not automated. Other details include the password for the account and password security requirements enforcement, the details for the name of the application, the web site, what the application will do. The application description is important because it informs what the application intends to do. This we use to validate the client applications when it is being approved.
Also a callback URL that is registered. This callback URL is important for all OAuth client validations and hence this is critical to the OAuth logins from the client. The OAuth spec demands that the client redirect URLs be validated so this is important.

I'm listing the various data mining algorithms.
These are as follows:
Classification algorithms : A classification algorithm predicts one or more discrete variables, based on the other attributes in the dataset.
A regression algorithm predicts one or more continuous variable such as profit or loss, based on other attributes in the dataset.
A segmentation algorithm divides data into groups or clusters or items that have similar properties.
Association algorithms finds correlations between different attributes in a dataset. This is used for creating association rules.
Sequence analysis algorithms summarize frequent sequences or episodes in data
An algorithm can create a mining model that comprises of
a set of clusters that describe groupings within the data set
a decision tree that predicts an outcome
a mathematical model that forecasts sales
a set of rules that describe how items are grouped together.
Algorithms can be picked based on the purpose at hand.
Decision tree algorithm can be used to predict a discrete or continuous attribute. It can also be used to find groups of common items in transactions.
A Naive Bayes algorithm works best to predict a discrete attribute.  A neural network algorithm could be used too. A clustering algorithm also works well to predict a discrete attribute. However, it is better suited for grouping of similar items. A sequence clustering algorithm can be used to find groups of similar items as well as to predict a sequence.
A time series algorithm and a linear regression algorithm works best to determine a continuous attribute.
Association algorithm works well to find groups of common items by establishing correlations between attributes.

Token Ring with requests

In the previous post, we described a token ring. The token continues to circulate whether there is demand for the shared resource or not. If the participants in the token ring respond only to requests, then there is more efficiency. The messages will now be for token and for the request. Tokens circulate in one direction and the requests circulate in the opposite direction.
A more general token based approach uses a spanning tree to pass the token. The advantage with the spanning tree is that it can be applied to any graph.
It works this way:
1) Every process knows where the token is
2) requests are sent towards the token
3) The tokens travel along the same path as requests, but the opposite direction
The process know where the token is by going to the root of the tree. The tree is directed and the token is always at the root.
Process sends only one request and may need to keep a list of pending requests from its children. The key question here is how to make sure the that the token is getting closer with each forward. For this we maintain a metric or invariant so that each forward reduces the metric say timeline. we could rely on the costs we calculated between neighbors in the minimum spanning tree. The tokens and the requests follow the edges of the spanning tree. Therefore, if we were to use the entire graph instead of the minimum spanning tree, we could find more optimal  path. However, for that too we consider the graph as acyclic. We include the concept of an invariant and point the edges towards the token.The tree is generalized to a partial order.
The token tree examples above remind of the dining philosophers problem.
This problem is stated this way. Five philosophers are sitting around a table. Between each philosopher is a single fork and in order to eat a philosopher must hold both forks. 
The philosophers transition between three states - thinking, hungry and eating. The neighbors do not eat at the same time. This guarantees safety. And when every philosopher eats, this guarantees progress. 
One solution will be to require permission to eat from all of one's neighbors. However for this solution, deadlock is possible because each process could wait for the next one in cycle.
The solution can be improved with grabbing all forks at once and releasing them after a finite time. However, even in this solution some philosophers could starve.
A better solution could be to break the symmetry. Here one of the philosophers grabs the left fork while all others try to grab the right fork,. This way the symmetry can be broken and some of the philosophers can eat. while others eat in subsequent cycles thus guaranteeing progress. 
If we generalize to an undirected graph, we can break the symmetry by giving edges a direction. When we do this, we must be careful not to introduce a cycle otherwise we introduce a symmetry.
We can add a structure on the graph such that it is acyclic. All the edges point along the same way typically up and thus we draw a partial order where the edges represent priority. Conflicts for a shared resource are resolved based on this priority. After a process wins and eats, its priority is reduced so that the neigbors get a chance to eat.

 

Token based solutions to Mutual Exclusion Layer in distributed systems

When a collection of processes share the same common resource, they may require mutual exclusive access to this shared resource. The problem is to design a program that acts as a "mutual exclusive layer" that resolves the conflict between the processes.
A trivial solution could be to write a single central program that maintains a queue of outstanding requests. Requests are granted one at a time. This guarantees safety and progress.
However, the centralized program could be a bottleneck.
So let us step back and consider a more general problem where mutual exclusion is an example. This is the problem of maintaining a distributed variable value.
Let us say the variable x needs to be updated. Different processes keep a local copy and manage it with broadcasts.
Each process keeps as part of its state the following:
copy of x,
the logical clock,
queue of modifying requests ( with their logical time stamps )
list of known times, one for each other process.
The process executes a request when the request has the minimum logical time of all the requests and all the known requests are later than that time.
The processes are connected in a well defined fixed topology that is the processes are finite and well-connected. We will consider the processes as arranged in a ring.
Now lets consider the use of a single indivisible token. A token is a very useful concept. It can neither be created nor destroyed.
A process is allowed to enter the critical section only if it holds the token. Every process that tries to enter a critical section also gets a token,
In a token ring the token moves constantly in a clockwise direction.
If the processes want to enter the critical section, it simply waits for the token.
The algorithm to use is therefore
To use resource:
     hungry  = true;
when token arrives:
    if hungry
           use resource
     send token on clockwise direction

Courtesy : Introduction to Distributed Systems
book by Dr, Paul Sivilotti

I had a chance to review Urban airship developer guide. They have Push APIs that  lets us select the audience, define the notification payload, specify the device types, deliver the notification.
Authentication is done based on application key and secret. The application secret is restricted to certain low-security APIs JSON format is supported. The base URL is go.urbanairship.com Push response has push_ids, the ids are GUIDS Devices have their pushTokens. Audience selectors include device IDs, segments, location, logical operators etc and is consolidated into a single attribute.  The audience selector helps in cases such as broadcast. Scheduling is done with a separate endpoint /api/schedules.
A push object describes everything about the push, including the audience and push payload. A push payload is composed of upto five attributes. audience, notification, device_types, options and message.
Device information APIs are based off of device_token and includes information such as last registration, badge, quite time etc.
Devices don't necessarily have to be a specific platform. It can be iOS, Android etc.
The location API for urban airship is interesting. They search for a location by name but results can also be filtered by boundary type such as city, province or country. The location can be searched based on latitude and longitude as well. Specifying the boundary type with latitude and longitude such as city, postal code etc is recommended.
Device registration is done with device tokens for iOS, APIDs for Androids and Blackberry PIN
The reports API gives the number of billable users for the month, broken out by iOS and Android.
Tag API can be used for creating, deleting or updating tags for an application.