Sunday, February 23, 2014
Interacting with the Web - Node JS
Outline
- Using Node as a web client
- Building a web server
- Real-time integration using Socket.IO
Making web requests in Node
- “options” can be one of the following:
- A URL string
- object specifying values for host, port, method, path, headers, auth, etc.
- The returned ClientRequest can be written/piped to for POST requests
- The ClientResponse object is provided via either callback (shown above) or as a “response” event on the request object.
- http.get() available as a simplified interface for GET requests.
Building a Web Server in Node
- Each request is provided via either callback (shown above) or as a “request” event on the server object
- The ServerRequest can be read from (or piped) for POST uploads
- The ServerResponse can be piped to when returning stream-oriented data in a response
- SSL support is provided by a similar https.createServer()
Making web requests in Node
- “options” can be one of the following:
- A URL string
- object specifying values for host, port, method, path, headers, auth, etc.
- The returned ClientRequest can be written/piped to for POST requests
- The ClientResponse object is provided via either callback (shown above) or as a “response” event on the request object.
- http.get() available as a simplified interface for GET requests.
Building a Web Server in Node
- Each request is provided via either callback (shown above) or as a “request” event on the server object
- The ServerRequest can be read from (or piped) for POST uploads
- The ServerResponse can be piped to when returning stream-oriented data in a response
- SSL support is provided by a similar https.createServer()
Monday, February 10, 2014
Tools and techniques for debugging Ajax apps
Motivatio
- Issues with building & debugging ASP.NET Ajax Extension sites
- Visual Studio
- Browser tools
- Helper utilities
- Tracing tools
- Modifying requests, analyzing responses
- Writing trace messages
- Assert/Fail
- The big ‘A’ in Ajax makes debugging tricky as deterministic behavior is elusive
- The request/response nature of Ajax applications means tracing data is necessary for debugging. This requires some trace mechanism (not just the browser and IDE)
- Dynamic typing means code is often harder to understand and predict —and the loss of compiler validation complicates things
Why is debugging Ajax apps so hard?
- Asynchrony
- The big ‘A’ in Ajax makes debugging tricky as deterministic behavior is elusive
- Data flow
- The request/response nature of Ajax applications means tracing data is necessary for debugging. This requires some trace mechanism (not just the browser and IDE)
- Dynamic typing
- Dynamic typing means code is often harder to understand and predict —and the loss of compiler validation complicates things
Debugging in Visual Studio 2008
- In the past, debugging JavaScript has been problematic…
JavaScript debugging in VS 2005
- Support for debugging in Visual Studio 2005 is not as seamless:
- Enable script debugging in IE
- Add debuggerkeyword in source to trigger breakpoints
- Start debugging (F5)
Script exploration in VS 2005
- Visual Studio 2005 also includes a script explorer
- Enable script debugging in IE
- Start debugging (F5)
- Debug menu | Other Windows | Script Explorer
- Double-click to open scripts
- You can set breakpoints & debug as usual
- if command doesn't appear, select Tools | Customize | Debug, then drag Script Explorer command to the menu…
Firefox JavaScript Debugging
- Firefox has built-in support for JavaScript debugging & DOM inspection
- Tools | Error/JavaScript Console
- Tools | DOM Inspector
- Many extensions also available
Firefox JavaScript Console
Firefox DOM Inspector
Firebug script debugger
- Firebug is an extension for Firefox
- Monitors script errors & signals when there is a problem
- Tracking of XMLHttpRequests
- Script debugger with breakpoints
- Inspector / command line
- Source viewer
Web Development Helper
- IE browser extension
- Localhostdiagnostics including ViewStatedisplay, items in cache, application shutdown
- HTTP logging
- DOM inspector
- Rich script error information
ASP.NET Development Helper
Summary
- ASP.NET AJAX Extensions simplify building AJAX-enabled sites
- However, debugging is trickier than traditional POST-back sites
- Asynchronous nature of Ajax
- Dynamic nature of JavaScript
- Visual Studio 2008 offers good support for JavaScript debugging
- Use additional tools for tracing & testing
- Multitude of tools available for IE and Firefox...
Reduce ASP.NET Payload with View State Caching
Dramatically improve ASP.NET response times by reducing the payload returned to web clients. ASP.NET applications have to deal with View State becoming a performance overhead. And, NCache helps you cache View State on the web servers and send a much smaller payload to the user's browser containing only a unique token for this ViewState.
Why Cache View State?
View State is an encrypted text string containing the state of web form controls and widgets and is sent to the user's browser to preserve this state across post-backs. For forms with lot of controls, DataGrid control, or some other complex controls, the View State can become quite large. Here are some reasons why you should consider caching the View State.
- View State is large (tens of kb) on large forms & DataGrid
- Large View State slows down page download time
- Large View State slows down post-back request time
- Can cache View State on WFE servers & send only a token to user
- View State cache is distributed to all WFE servers in the farm
How NCache Caches View State?
View State is included in the response of a web request as a hidden form field called __VIEWSTATE. On all page visits during the save view state stage, the Page class gathers the collective view state for all of the controls in its control hierarchy and serializes the state to a base-64 encoded string. Below is an example of a View State.
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"value="/wEPDwUJNzg0MDMxMDA1D2QWAmYPZBYCZg9kFgQCAQ9kFgICBQ9kFgJmD2QWAgIBDxYCHhNQcm...
ZpZ2F0aW9uTWVudQ8PZAUKQWxsIGluIE9uZWQiMPVaPthHdSA3rH8zgoNOvWxd4w==" />
Once NCache caches this View State, it replaces the "id" and "value" fields with its own data. Here is an example of that.
<input type="hidden" name="__NCPVIEWSTATE" id="__NCPVIEWSTATE"value="vs:cf8c8d3927ad4c1a84da7f891bb89185" /> <input type="hidden"name="__VIEWSTATE" id="__VIEWSTATE" value="" />
Notice, how it is preserved the original "__VIEWSTATE" hidden field so everything works as if there was no View State. But, it has inserted its own "__NCPVIEWSTATE" field that it will read when a post-back request comes from the user to the web server. NCache uses the "value" as the key to fetch the corresponding original View State from the in-memory cache and serves it to the ASP.NET page so it can populate the web form with data from the View State.
And, since the in-memory cache is distributed and synchronized across all WFE servers, even if the post-back request goes to a different WFE server in the farm than the original server where the View State was created, NCache is able to find the View State value in the cache.
Sunday, February 9, 2014
Visual Studio 2013 Ultimate Activation Key
Here is Visual Studio 2013 Ultimate Activation Key :::::
BWG7X-J98B3-W34RT-33B3R-JVYW9
BWG7X-J98B3-W34RT-33B3R-JVYW9
Function Overloading in Web Services
Introduction
The function overloading in Web Service is not as straightforward as in class. While trying to overload member function, we make two or more methods with the same name with different parameters. But this will not work in web services and will show runtime error because WSDL is not supported by the same method name.
Overloading Web Services
While trying to overload Web Methods in Web Services and after doing the build, it will work successfully. But when we try to run or consume, it will show an error message. We can show this using an example.
namespace TestOverloadingWebService
{
[WebService(Namespace = "http://tempuri.org/", Description=" Function
overloading in Web Services ")]
public class OverloadingInWebService : System.Web.Services.WebService
{
[WebMethod()]
public int Add(int a, int b)
{
return (a + b);
}
[WebMethod()]
public float Add(float a, float b)
{
return (a + b);
}
}
}
In the above example, we made one web service having class
OverloadingInWebService
. In the Web Service, we have added attribute Description
, which is used to describe the web service purpose to client. In the above Web Service, we have two overloaded WebMethod
s:public int Add(int a, int b)
and
public float Add(float a, float b)
While running this Web service, it will show the following runtime error.
Solution for the Above Error
The procedure to solve this problem is very easy. Start each method with a Web Method attribute. Add
Description
property to add a description of web method and MessageName
property to change web method name.[WebMethod(MessageName = "" , Description = "" )]
namespace TestOverloadingWebService
{
[WebService(Namespace = "http://tempuri.org/", Description=" Function
overloading in Web Services ")]
public class OverloadingInWebService : System.Web.Services.WebService
{
[WebMethod(MessageName = "AddInt", Description = "Add two integer
Value", EnableSession = true)]
public int Add(int a, int b)
{
return (a + b);
}
[WebMethod(MessageName = "AddFloat", Description = "Add two Float
Value", EnableSession = true)]
public float Add(float a, float b)
{
return (a + b);
}
}
}
Reason for the Above Error
The Overloading is supported by web services. But when WSDL (Web Service Description Language) is generated, it will not be able to make the difference between methods because WSDL does not deal on the base of parameters. By passing web methods –‘
MessageName Property
’, it changes the method name in WSDL. See the WSDL given below, the operation name is Add
but the input method name is AddInt
as well as output method name is also same (AddInt
). The same will apply for Float also.
While running this Web service, it will show the following runtime error.
Solution for the Above Error
The procedure to solve this problem is very easy. Start each method with a Web Method attribute. Add
Description
property to add a description of web method and MessageName
property to change web method name.[WebMethod(MessageName = "" , Description = "" )]
namespace TestOverloadingWebService
{
[WebService(Namespace = "http://tempuri.org/", Description=" Function
overloading in Web Services ")]
public class OverloadingInWebService : System.Web.Services.WebService
{
[WebMethod(MessageName = "AddInt", Description = "Add two integer
Value", EnableSession = true)]
public int Add(int a, int b)
{
return (a + b);
}
[WebMethod(MessageName = "AddFloat", Description = "Add two Float
Value", EnableSession = true)]
public float Add(float a, float b)
{
return (a + b);
}
}
}
Reason for the Above Error
The Overloading is supported by web services. But when WSDL (Web Service Description Language) is generated, it will not be able to make the difference between methods because WSDL does not deal on the base of parameters. By passing web methods –‘
MessageName Property
’, it changes the method name in WSDL. See the WSDL given below, the operation name is Add
but the input method name is AddInt
as well as output method name is also same (AddInt
). The same will apply for Float also.<wsdl:operation name="Add">
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Add
two integer Value</wsdl:documentation>
<wsdl:input name="AddInt" message="tns:AddIntSoapIn" />
<wsdl:output name="AddInt" message="tns:AddIntSoapOut" />
</wsdl:operation>
<wsdl:operation name="Add">
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Add
two Float Value</wsdl:documentation>
<wsdl:input name="AddFloat" message="tns:AddFloatSoapIn" />
<wsdl:output name="AddFloat" message="tns:AddFloatSoapOut" />
</wsdl:operation>
History
- 9th October, 2008: Initial post
Magic tables in SQL Server
The tables "INSERTED" and "DELETED" are called magic tables of the
SQL Server. We can not see these tables in the data base. But we can access these
tables from the "TRIGGER"
When we insert the record into the table, the magic table "INSERTED" will be created
In that table the current inserted row will be available. We can access this
record in the "TRIGGER".
Following code Explains the magic table "INSERTED"
CREATE TRIGGER LogMessage ON EMP FOR INSERT AS DECLARE @EMPNAME varchar(50) SELECT @EMPNAME= (SELECT EMPNAME FROM INSERTED) INSERT INTO LOGTABLE(UserId,Message) values (@EMPNAME,'Record Added') GOWhen we delete the record from the table, the magic table "DELETED" will be created
In that table the current deleted row will be available. We can access this
record in the "TRIGGER".
Following code Explain the magic table "DELETED"
CREATE TRIGGER LogMessage ON EMP FOR DELETE AS DECLARE @EMPNAME varchar(50) SELECT @EMPNAME= (SELECT EMPNAME FROM DELETED) INSERT INTO LOGTABLE(UserId,Message) values (@EMPNAME,'Record Removed') GOThe magic tables "INSERTED" and "DELETED" are main concept of the "TRIGGER".
By using these tables we can do lot of useful functionalities. The above code is
used to update the "LOGTABLE". Like wise we can maintain stock..
Saturday, February 8, 2014
Introducing Extension Methods
Repository Pattern
Why?
Separate business code from data access
- Separation of concerns
- Testability
Intent
Encapsulate data access
- Data appears to live inside an in-memory collection
Demo
Applicability
Consequences
Increased level of abstraction- More classes, less duplicated code
- Maintainability, flexibility, testability
- Shielded from infrastructure
- Harder to optimize
Related Patterns
- Unit of Work
- Specification
- Identity Map
- Decorator
Subscribe to:
Posts (Atom)