You will definitely get it from here!

When a MAC address itself is unique, why do we still need an IP address to uniquely identify a system on a network?

2019-12-01T21:49:00.002+05:30

It is not possible to route a MAC address since it works on a layer above Ethernet. To understand why IP addressing is used in a computer network or over the internet you need to understand how IP routing works.

Basic IP Routing

When your computer (PC1) wants to send a packet to some IP address (IPv4) like x.x.x.x, then the first check is if the destination address is in the same IP network as the PC1 itself. If x.x.x.x is in the same network, then the destination IP can be reached directly, otherwise the packet needs to be sent to the route configured on PC1 and if a route for the destination network / host is not configured explicitly, the packet is routed to the default gateway configured on PC1. Well that was about how IP routing works at a very high-level. Routers also use dynamic routing protocols and algorithms to find the best possible path.

MAC addresses

Once the packet has reached the local network of the destination computer, the communication happens over the Ethernet which is the data link layer. This is where MAC addresses are used to communicate. The sender (which in this case could be a router or the source computer PC1 if it was in the same network) needs to get the MAC address of the destination computer. There is a special protocol ARP (address resolution protocol) that is used for that. Once the sender has retrieved the MAC address of the next hop, he sends the data. Before sending the data packet over the Ethernet, it is divided into shorter pieces called frames.

MAC addresses are needed for communication within the Local Area Network. IP address comes into the picture when the packet has to be routed to a different network.

Why MAC address are used locally only?

With MAC addresses, there is no hierarchy, and thus packet forwarding would not be possible. So, MAC addresses are not used for packet transfer.

And also, a host (e.g., a computer) cannot determine from the MAC address of another host whether that host is on the same network as the sending host, or on a network bridged to that network. This is the weakness of a MAC address and the reason why it is not used for determining the location of a host. Instead, determining a host's location, whether it is on the same network or another network, can only be accomplished by means of the IP address.

To route by MAC addresses, routers would have to account for every machine on the network individually which is a impossible for a network the size of the Internet.

Why we need IP when MACs are so unique?

To explain this in layman’s terms, let us compare IP routing to our postal address and routers to various post offices worldwide. Now let’s say your friend in Virginia, USA mails you a post card to your residence address which is like 101 Ganesh Society, Nariman Point, Mumbai-400001, Maharashtra, India. The post card will be first delivered to India then Maharashtra then Mumbai till it finally reaches your apartment.

Now let’s assume your another friend in India were to post you a postcard from New Delhi and he only knows your Aadhar Id (an unique Id for Indian citizen). Will the post office be able to deliver the post card without even referring your postal address online? The answer is No. This is simply because every post office worldwide relies on each other to deliver the posts.

Now, once again let's use the analogy of post office and unique ID and assume we had to use only the MAC address or a Unique ID or Aadhar Id to deliver information to another computer somewhere across the world. In this case we would require a single gigantic post office somewhere in first place. All the posts would be collected by this giant post office and then distributed to each person across the world. Which would also mean that if this post office was to be setup in New York, the post card from your friend in New Delhi would have to travel to New York before reaching you. This post office might have to handle millions of mails and parcels daily. They would have to maintain postal records for literally each person in the world so that their logistics team may deliver posts to respective people directly (Since there is no other post office to do the job). This may require infinite amount of resources and delivery teams travelling from just one central post office to each house in the world which is again next to impossible.

Similarly in the case of computer networks or an Internet, it is not possible to hook every single computer in the world to one network router or switch. We need to break this into smaller network segments, also known as subnets.

Horizontal and Vertical Scaling

2019-12-01T15:59:00.000+05:30

Horizontal Scaling means that you scale by adding more machines into your pool of resources whereas Vertical Scaling means that you scale by adding more power (CPU, RAM) to an existing machine.

Alternative term for Horizontal and Vertical Scaling is also known as Scale Out and Scale Up respectively.

Scale up: Get more CPU, memory, disk space, and extra features like dedicated virtual machines (VMs), custom domains and certificates, staging slots, autoscaling, and more. You scale up by changing the pricing tier of the App Service plan that your app belongs to.
Scale out: Increase the number of VM instances that run your app. You can scale out to as many as 30 instances, depending on your pricing tier. App Service Environments in Isolated tier further increases your scale-out count to 100 instances. For more information about scaling out, see Scale instance count manually or automatically. There, you find out how to use autoscaling, which is to scale instance count automatically based on predefined rules and schedules.

An easy way to remember this is to think of a machine on a server rack, we add more machines across the horizontal direction and add more resources to a machine in the vertical direction.

In a database world horizontal-scaling is often based on the partitioning of the data i.e. each node contains only part of the data, in vertical-scaling the data resides on a single node and scaling is done through multi-core i.e. spreading the load between the CPU and RAM resources of that machine.

With horizontal-scaling it is often easier to scale dynamically by adding more machines into the existing pool - Vertical-scaling is often limited to the capacity of a single machine, scaling beyond that capacity often involves downtime and comes with an upper limit.

Good examples of horizontal scaling are Cassandra, MongoDB, Google Cloud Spanner (a kind of sharding) etc and a good example of vertical scaling is MySQL - Amazon RDS (The cloud version of MySQL). It provides an easy way to scale vertically by switching from small to bigger machines. This process often involves downtime.

.NET Core: Session Wrapper Design Pattern For ASP.NET Core

2019-11-19T17:33:00.001+05:30

Here, we'll learn about Session Wrapper design pattern to ease the access of Session. We'll make our access of session "Typed". Also, we may apply any validation or constraint in this wrapper class.

Step 1 - Create a Session Manager class

In this example, we are going to store two items in Session (i.e. ID & LoginName).

We are injecting IHttpContextAccessor so that we can access the Session variable.
We are creating properties which are actually accessing Session variable and returning the data or writing the data to Session.
We have added one helping property "IsLoggedIn" which is using other properties to make a decision. We may have more such helping/wrapper properties.

using Microsoft.AspNetCore.Http;

public class SessionManager

{

private readonly ISession _session;

private const String ID_KEY = "_ID";

private const String LOGIN_KEY = "_LoginName";

public SessionManager(IHttpContextAccessor httpContextAccessor)

{

_session = httpContextAccessor.HttpContext.Session;

}

public int ID

{

get

{

var v = _session.GetInt32(ID_KEY);

if (v.HasValue)

return v.Value;

else

return 0;

}

set

{

_session.SetInt32(ID_KEY, value);

}

public String LoginName

{

get

{

return _session.GetString(LOGIN_KEY);

}

set

{

_session.SetString(LOGIN_KEY, value);

}

public Boolean IsLoggedIn

{

get

{

if (ID > 0)

return true;

else

return false;

}

Step 2

Registering IHttpContextAccessor and SessionManager in Startup file.

services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

services.AddScoped<SessionManager>();

Step 3

Injecting SessionManager in your classes. Here is an example of Controller class but in the same way, it can be injected in non-controller classes too.

private readonly SessionManager _sessionManager;

public HomeController(SessionManager sessionManager)

{

_sessionManager = sessionManager;

}

Step 4

Using SessionManager to access Session Data,

_sessionManager.ID = 1;

_sessionManager.LoginName = dto.Login;

if(_sessionManager.IsLoggedIn == true)

{

ViewBag.Login = _sessionManager.LoginName;

return View();

}

Conclusion

This wrapper pattern helps using Session without worrying about KeyNames & Makes access easier. It also helps you apply different conditioning and constraints in a wrapper class.

Reference: csharpccorner.com

.NET Core: All About Sessions In ASP.NET Core

2019-11-19T17:25:00.001+05:30

We'll quickly discuss how we used to use Sessions before ASP.NET Core and then we'll see how to access Sessions in ASP.NET Core.

Session In Pre-ASP.NET Core era

You get Session functionality by default (without adding any package)
Previously, you would have accessed Session by -

Session variable in your Controllers/Forms
System.Web.HttpContext.Current.Session in places where you don't have direct access to the Session variable.

Anything you store in session is stored as Object. You store values in Key/Value format.

Session["mydata"] = 10;

Or to access on those places where Session is not available (e.g. Non-Controller classes)

System.Web.HttpContext.Current.Session["mydata"] = 10;

Quite difficult to mock Session Object for Unit Testing

Session in ASP.NET Core 2.2

Now, Session is not available by default.
You need to add the following package. Meta package by default provides you this.

In Startup.ConfigureServices, you need to add the following to register services with DI Container.

services.AddDistributedMemoryCache();//To Store session in Memory, This is default implementation of IDistributedCache

services.AddSession();

In Startup.Configure, you need to add the following (before UseMVC) to add Session Middleware.

app.UseCookiePolicy();

app.UseSession();

app.UseMvc(routes =>

Make sure the following is also there (It is added by default when you use ASP.NET Core MVC Template).

app.UseCookiePolicy();

ASP.NET Core 2.2 onwards adds Cookie Consent (true) in the Startup file. When an application runs, the user needs to accept Cookie Consent on screen. When the user accepts the policy on the page, it creates a consent cookie. It is to follow GDPR and to give control to the user if the user wants to store cookies from a site or not. If the user doesn't accept that, Session does not work because Session requires a cookie to send/receive session Id. You may face this issue while working with ASP.NET Core MVC default template.

How to access Session in Controller?

You will notice that you don't have "Session" variable available now. Controller now has a property "HttpContext" which has "Session" variable. So, you can access session in controller by using the following code.

var a = this.HttpContext.Session.GetString("login");

HttpContext.Session.SetString("login", dto.Login);

How to access Session in Non-Controller class?

Now, you don't have System.Web.HttpContext.Current.Session in ASP.NET Core. To access session in non-controller class –

First, register the following service in Startup.ConfigureServices;

services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();

Now, register a class (example - TestManager) where you want to access the Session in Startup.ConfigureServices;

services.AddScoped<TestManager>();

Note
You may use AddTransient or AddSingleton according to your logic.

Now, in TestManager class, add the following code.

private readonly IHttpContextAccessor _httpContextAccessor;

private readonly ISession _session;

public TestManager(IHttpContextAccessor httpContextAccessor)

{

_httpContextAccessor = httpContextAccessor;

_session = _httpContextAccessor.HttpContext.Session;

}

The above code is receiving IHttpContextAccessor object through dependency injection and then, it is storing Sessions in a local variable.

How to access Session in View file?

Add the following at the top of your View file.

@using Microsoft.AspNetCore.Http

@inject IHttpContextAccessor httpContextAccessor

Then, you may access the Session variable in your View like following.

@httpContextAccessor.HttpContext.Session.GetString("login")

What else is changed regarding Session?

Session is non-locking now.
A session is not created until you have at least one value in it
You need to use functions to get & set data. Array syntax is not supported now.
Now, ISession only provides Get & Set method which takes & returns data in Byte Array format.
If you want to store data in the String format, you may add the following in your file and use extension methods.

using Microsoft.AspNetCore.Http;

It exposes the new extension methods.

SetInt32

GetInt32

SetString

GetString

Under the hood, these covert the data into bytes.

You may also write your own extension methods. For example, the following Extension Methods help you store & retrieve any complex type.

public static class SessionExtensions

{

public static void Set<T>(this ISession session, string key, T value)

{

session.Set<(key, JsonConvert.SerializeObject(value));

}

public static T GetObject<T>(this ISession session, string key)

{

var value = session.GetString(key);

return value == null ? default(T) : JsonConvert.DeserializeObject<T>(value);

}

Summary

Session concepts are similar to what we've seen in earlier .NET Frameworks. The real difference is that now, it is cleaner & more flexible to use.

Reference: csharpccorner.com

Project Management - Ten Popular Myths About Leadership and How to Overcome Them

2019-11-19T17:19:00.001+05:30

Close your eyes for a second and conjure-up a mental image of a leader. What do you see? Do you picture a politician, CEO or military leader? It’s easy to see why these type of images come to someone's mind. Leaders are often viewed as someone who is decisive, smart and outgoing. In some cases, leaders may appear just a little bit intimidating.

The problem with an image that suggests an aggressive persona of authority is that it can prevent some potentially strong leaders from pursuing leadership roles or reaching their full potential. It's easy to misconstrue and have a misconception of what a leader is and isn’t.

With that in mind, let’s identify 10 of the most popular myths about leadership so that you can discover new opportunities and effectively take charge of your team.

1. Entrepreneurial leadership.

There’s an assumption that all entrepreneurs are natural-born leaders. The reality is that just because you had a fantastic and timely idea doesn’t mean that you’re capable of organizing, operating, and scaling a business -- even if that become a multi-million dollar business.

Even though you’re the “founder” of your business, don’t automatically believe that you’re in the best position to be its leader. Leadership isn’t tied to a job description. It’s having a vision and getting others to buy into it, growing talent, listening, and influencing others. Those are all qualities that can come from an outside CEO hire, like what LinkedIn did with Jeff Weiner, to the lowest levels of your organization.

If you don’t feel that you possess strong leadership qualities, then it’s best to check your ego at the door and hand the reins over to who does maintain the best skills in leadership.

Related: The Entrepreneur as Leader

2. Leaders can’t show vulnerability.

Perhaps one of the most prevalent myths is that leaders, no matter the situation, must dig-in and stand their ground. If they accept fault, change direction, or listen to others, then that’s a sign of weakness. Of course, this couldn’t be further from the truth.

Strong leaders own their mistakes so that they can learn from them. They’re receptive to feedback -- even when it’s negative. They don’t have all the answers. And, they show-off their humanity by listening and caring for their employees.

3. A great leader is cold, fierce and omnipotent.

I’m sure at some point you’ve worked with a leader who is a know-it-all. They act tough, talk a big game, and separate themselves from the rest of the team. Now, think about your performance while under this individual? I bet you weren’t as productive and motivated as you could have been, right?

Employees want their leaders to care for them genuinely. They want to feel respected. And, the employee wishes for their thoughts and concerns to be listened to with kindness. The best way to sharpen these leadership skills is by boosting emotional intelligence. Increasing your emotional IQ will help you become more self-aware, empathetic, and a better communicator. As a result, you’ll build a strong rapport with your team.

4. Extroverted leaders are preferred.

What’s the difference between extroverts and introverts? Most people believe an extrovert is how they act in social settings. Extroverts are thought to be more outgoing and confident. Introverts are considered shy and withdrawn. However, being extroverted or introverted has more to do with how we process information.

Extroverts work through problems by discussing them and seeking the advice and input from others. Introverts process their thoughts and conflicts internally. Because of these differences, it shouldn’t be surprising that extroverts are drawn to leadership roles. Being a leader means engaging with other people, right?

The reality is that not all extroverts are cut-out to be leaders. A lot of successful individuals, such as Warren Buffett, Bill Gates, Barack Obama, and Marissa Mayer, are introverts. Just because you’re not the head of a department or comfortable in crowds doesn’t mean that you should sell yourself short. You may still possess the right leadership skills to inspire others.

5. There’s not enough time to develop leadership skills.

As with any skill worth having, it takes time to develop. Using the "no time" is a poor excuse. We all have the same 24-hours in a day. And, we’re all swamped. Somehow, plenty of other leaders can deepen their leadership skills without a problem.

The problem isn’t that there aren’t enough hours in the day. It’s that you aren’t managing your time correctly. For example, waking-up 30-minutes earlier, batching related work, or delegating less critical tasks to others could free-up extra time. You can then use this time to read, take a course, or work with a coach or mentor.

6. Leadership is synonymous with management.

Assuming that leadership is synonymous with good management is another common myth about leadership. Adequate direction and guidance cannot always be equated with a good commander. There are some reasonably significant distinctions between these two roles, such as:

Leaders create a vision; managers establish goals.
Managers maintain the status quo, while leaders are agents of change.
Leaders are self-aware and unique. Managers copy others and adapt and adopt others' leadership style.
Managers control or avoid risk and problems, while leaders are willing to take risks.
Leaders keep focused on the big picture. Managers work on short-term goals.
Leaders learn something new every day; managers rely on their existing talents.
Managers build systems, while leaders construct relationships.
Leaders coach; managers assign tasks and provide guidance.
Managers have employees. Leaders, on the other hand, have loyal and dedicated fans.

If you have a team with multiple or complex goals, it’s important to know the difference between leadership and management. You can then develop either your leadership or management skills -- depending on which you’re lacking. You may also want to consider finding someone to complement the skills that are scarce.

7. All leaders are trailblazers.

Being a trailblazer isn’t necessarily a bad thing. Trailblazers, after all, are ambitious, competitive, calculated risk-takers, and goal-oriented. At the same time, they’re also an independent and the driving force behind a business. An independent and driving force can make working with others a challenge.

For example, while you’re out impressing clients, investors, and customers through speaking engagements and pitches -- there’s no one back rallying the troops. While trailblazers can definitely get people to jump on-board with their vision, leaders know when to step back. A true leader or manager will recognize talent and work alongside this team in order to propel everyone towards a shared mission and vision.

8. My team members always tell me the truth.

They may not be lying to you completely. But, your team is probably only giving you half-truths -- especially if you are a hard character to deal with. You may be a complicated, emotionally depleted individual -- thus it should be easy to understand why you have problems being a leader. If an employee shares bad news with you and you overreact, then why would they open up to you again?

Your employees should be able to be 100 percent transparent with you -- but if you punish them, do you think they’ll repeat that same mistake? It’s not always easy to hear the truth. But, without all the information, you can’t make a more informed decision -- nor can you grow as a leader.

To encourage your team to tell you the truth, build a culture of calmness where you control your emotions. What’s more, focus on what to do next instead of pointing fingers and giving people a second chance. Make it easy to receive and provide feedback. Think about furnishing an online survey or focus groups conducted by a third party. When you have an outside source for company "tips" that ensures anonymity -- so that a team member doesn't have to be afraid of repercussions.

9. The best leaders roll up their sleeves and get their hands dirty.

Obviously, "getting your hands dirty" doesn’t mean hiding in your office. There may times when you should be working side-by-side with employees -- as long as it’s on the right activities. As a leader, you should be primarily focused on tasks like decisions, priorities, and accountabilities. Non-leadership tasks should be automated, delegated, or outsourced so that you’re not draining yourself mentally or physically.

Remember -- lead with your work and not by prioritizing the work of others.

10. Leaders must always be “on.”

Finally, there’s a misconception that leaders are must be “on” 24/7/365. The truth is that everyone, regardless of the leadership position, needs a break from work. Checking your email throughout the weekend or when or vacation is a guaranteed way to burn yourself.

You need time away in order to reflect and focus on what matters, such as spending time with your family, exercising, or learning new information. By taking breaks, you can clear your head and de-stress. As a result, you’ll become a more energized, focused, and creative leader.

Remember to think about the user (Customer Experience)

2019-11-19T17:13:00.001+05:30

How The OSI Works

2019-11-18T19:41:00.001+05:30

Diagram of the OSI Model
Refer to it as you read the 'Step-by-Step' section below,

HOW THE OSI MODEL WORKS - STEP BY STEP

Network-capable Applications produce DATA.
Each layer in the OSI Model adds its own information to the front of the data it receives from the layer above it. This information in front of the data is called a header and contains information specific to the protocol operating at that layer. The process of adding the header is called encapsulation. Encapsulated data is transmitted in Protocol Data Units(PDUs). There are Presentation PDU's, Session PDU's, Transport PDU's etc. Thus, PDU's from an upper layer are encapsulated inside the PDU of the layer below it.
PDU's are passed down through the stack of layers (called 'the stack' for short) optionally repeating the encapsulation process until they can be transmitted over the Physical layer. The physical layer is the wire connecting all the computers on the network.
The OSI standards specify that a layer on host #1 speaks the same language as the same layer on host #2 or any other host on the network. Thus, all hosts can communicate via the Physical layer. This communication between layers is represented by the symbols in the diagram above. For example, the Transport layer on Host 1 should speak the same language as the Transport layer on Host 2.
DATA passed upwards is un-encapsulated before being passed further up (represented by the colored brackets [[[[[[ ).
All information is passed down through all layers until it reaches the Physical layer (represented by the vertical red arrows).
The Physical layer chops up the PDU's and transmits the PDU's over the physical connection (copper wire, fiber optic cable, radio link etc.). The Physical layer provides the real physical connectivity between hosts over which all communication occurs (represented by).

SUMMARY

Data from an upper layer is supposed to be passed down and inserted into the payload of a PDU in the layer below it. In the real world, the process of encapsulation (adding a header) doesn't always occur at all layers and sometimes things get chopped into smaller pieces so they will be easier to send and receive. Data passed over the Internet gets the first header from the application, then from Transmission Control Protocol (TCP), then Internet Protocol (IP) adds a header and passes it down to a physical connection. After that point, the hardware (Ethernet on LANs) chops the IP data into pieces and slaps its own header on it. Ethernet and other 802.x protocols also place a CRC at the end of the frame in the form of a frame check sequence. Although IP doesn't conform exactly to the model above, the model is still a good reference point for discussing Internet based network technologies and protocols.

The OSI Model's Seven Layers

2019-11-18T18:39:00.003+05:30

APPLICATION LAYER
The OSI model defines the application layer as being the user interface. The OSI application layer is responsible for displaying data and images to the user in a human-recognizable format and to interface with the presentation layer below it.

Examples of applications that utilize the network are:

Telnet
FTP
Instant Message software (AIM, MSN, ICQ, Yahoo)
Microsoft Windows File Shares
Web Browsers (Internet Explorer, Firefox, Google Chrome, Safari)
Network games of Doom, Quake, Unreal (first-person 3D shooter video games)
IRC (mIRC)

PRESENTATION LAYER
The presentation layer handles the conversion of data between a Standards-based or platform independent formats to a format understood by the local machine. This allows for data to be transported between devices and still be understood.

The presentation layer performs the following functions:

Communication with the application layer above.
Translation of data conforming to cross-platform standards into formats understood by the local machine.
Communication with the session layer below.
Examples of Presentation Layer Functions
Conversion of a Sun .RAS raster graphic to JPG.
Conversion of ASCII to IBM EBCDIC
Conversion of .PICT on a MAC to .jpg
Conversion of .wav to .mp3

SESSION LAYER
The session layer tracks connections, also called sessions. The session layer should keep track of multiple file downloads requested by a particular FTP application, or multiple telnet connections from a single terminal client, or web page retrievals from a web server.

With TCP/IP this functionality is handled by application software addressing a connection to a remote machine and using a different local port number for each connection.

The session layer performs the following functions:

Communication with the Presentation layer above.
Organize and manage one or more connections per application, between hosts.
Communication with the Transport layer below.

Example,
Sessions are used to keep track of individual connections to remote servers. Your web browser is an excellent example of the use of sessions.

Your web browser (an application layer object) opens a web page. That page contains text, graphics, Flash objects and perhaps animation. The graphics, the Flash object and the animation are all stored as separate files on the web server. To access them, a separate download must be started. Your web browser opens a separate session to the web server to download each of the individual files. The session layer keeps track of which packets and data belong to which file and keeps track of where they go (in this case, to your web browser).

In most modern Internet applications, the session, presentation and application layers are usually rolled together inside the application itself, thus, your web browser performs all functions of the session, presentation and application layers.

TRANSPORT LAYER
If networking software performs reliable data transfer functions, then the detection of errors, and re-transmission of data to recover those errors or lost data will occur in software managing this layer. The transport layer may use a variety of techniques such as a Cyclic Redundancy Check, windowing and acknowledgements. If data is lost or damaged it is the transport layer's responsibility to recover from that error.

Communicate with the Session layer above.
Reassemble transport Protocol Data Units into data streams
Reliable protocols operating at this layer will
Detect errors and lost data
Recover lost data
Manage re-transmission of data.
Segmentation of data streams into transport Protocol Data Units.
Communicate with the Network layer below.

Examples of transport layer protocols include:

Transmission Control Protocol (Reliable)
User Datagram Protocol (Unreliable)

NETWORK LAYER
It is the network layer's job to figure out the network topology, handle routing and to prepare data for transmission. The network layer is concerned with the following primary functions:

Communication with the Transport layer above.
Encapsulation of Transport data into Network layer Protocol Data Units.
Management of connectivity and routing between hosts or networks.
Communication with the data link layer below.

Examples of network layer protocols include:

Internet Protocol
Internet Control Message Protocol (ICMP or "ping")
Internet Gateway Management Protocol (IGMP)
IPX/SPX

DATA LINK LAYER
The data link Layer is the second layer of the OSI model. The data link layer performs various functions depending upon the hardware protocol used, but has four primary functions:

COMMUNICATION with the Network layer above.
SEGMENTATION of upper layer datagrams (also called packets) into frames in sizes that can be handled by the communications hardware.
BIT ORDERING. The data link layer organizes the pattern of data bits into frames before transmission. The frame formatting issues such as stop and start bits, bit order, parity and other functions are handled here. Management of big-endian / little-endian issues are also managed at this layer.
COMMUNICATION with the Physical layer below

This layer provides reliable transit of data across a physical link. The data link layer is concerned with physical addressing, network topology, physical link management, error notification, ordered delivery of frames, and flow control.

It should be noted that in most modern network interface adaptors, the Physical and Datalink functions are performed by the network interface adaptor.

Example,
Ethernet Network Adaptors uses a Media Access Control (MAC) address, which is a physical address that (somewhat) uniquely identifies a network card to the physical network. The Ethernet Adaptor's primary job at the data link layer is to transmit Ethernet frames onto the wire. It places its own MAC address in the frame, followed by the destination MAC address to which it wishes to communicate, sets various other values in the Ethernet frame (protocol type etc.) and then transmits on the wire. The CSMA/CD protocol that Ethernet uses to control access to the common network bus could be said to occur at the data link layer of the OSI model or could also be called a data link function.

PHYSICAL LAYER
The OSI Model's layer 1, the Physical Layer, outlines the characteristics of the physical medium between networked devices--cabling, wiring, fiber strands and the air. Transmission and receipt of data from the physical medium (copper wire, fiber, radio frequencies, barbed wire, string etc.) is managed at this layer.

The Physical Layer receives data from the data link Layer, and transmits it to the wire. The physical layer controls the electrical and mechanical functions related to the transmission and receipt of a communications signal. It also manages the encoding and decoding of data contained within the modulated signal.

Note that for two devices to communicate, they must be connected to the same type of physical medium (wiring). 802.3 Ethernet to 802.3 Ethernet, FDDI to FDDI, serial to serial etc. Two end stations using different protocols can only communicate through a multi-protocol bridge or a router.

The physical layer is responsible for:

Communication with the data link layer above it.
Fragmentation of data into frames
Reassembly of frames into data link Protocol Data Units.
Transmission to the physical media
Receiving from the physical media
It should be noted that in most modern network interface adaptors, the physical and data link functions are performed by the adaptor.

Example Physical Protocols

CSMA/CD - Carrier Sense Multiple Access / Collision Detect
CSMA/CA - Carrier Sense Multiple Access / Collision Avoid
FDMA - Frequency Division Multiple Access
MSK - Minimum Shift Keying
GFMSK - Gaussian-Fitered Minimum Shift Keying
TDMA - Time Division Multiple Access
CDMA - Code Division Multiple Access
B8ZS - Binary 8 Zero Substitution
2B1Q - 2 Binary 1 Quaternary
PCM - Pulse Code Modulation
QAM - Quadrature Amplitude Modulation
PSK - Phase Shift Keying
SONET - Synchronous Optical NETworking

What is the OSI Model

2019-11-18T17:50:00.000+05:30

Open Systems Interconnect (OSI) Model

The International Standards Organization (ISO) developed a theoretical model of how networks should behave and how they are put together. This model is called the Open Standards Interconnect (OSI) Model.

The OSI Model is a theoretical, seven-layered model of how networks work. The OSI Model is a theoretical model of networking that organizes network functions into seven layers,

Physical layer
Datalink layer
Network layer
Transport layer
Session layer
Presentation layer
Application layer

It specifies the communication interfaces between the OSI Model's layers and between network endpoints utilizing an OSI Model-based protocol suite.

The OSI Model is a way of thinking about how networks work.

The OSI Model is a theoretical model

The OSI Model is not a technology.
The OSI Model is not a protocol.
The OSI Model is not a program or software.

The OSI Model sorts network communication functions into seven layers.

Layer functions are not specified and should be transparent to other layers.
Layer Communications (how layers communicate with each other) ARE specified in the model
Layer behavior should be invisible to other layers

The OSI Model was developed as the ISO designed their own suite of networking protocols (the ISO OSI Protocol Suite). The OSI Model is always in the middle of any discussions of networking and network and sometimes computer troubleshooting. The OSI model is used so commonly as a point of reference that you really should learn the OSI Model's seven layers and learn how the OSI Model explains this layered approach to networking.

Engineers working on a network problem will frequently say "Well, it's a data link layer problem", clearly referring to the data link layer of the OSI Model and more specifically, the physical network connection, not the networking software or the applications. The OSI Model's layers are so well known that they are referred to by number: "Well, looks like we have a layer 2 problem here". If you don't know the OSI Model, you will have great difficulties as a network engineer, or even talking to one.

See also,

OSI Model vs TCP/IP Model

2019-11-18T11:32:00.004+05:30

There are two network models that describe how networks work. The OSI Model, the older model, was designed for the OSI protocol stack. While different organizations were battling over standards, Vint Cerf and Bob Khan worked out the TCP/IP software from which the TCP/IP Model was co-designed. The diagram below shows how the two networking models compare, and how the logical and physical networking protocols relate to the layers in each of the two models.

There are seven layers in the OSI Model, only four in the TCP/IP model. This is because TCP/IP assumes that applications will take care of everything beyond the Transport layer. The TCP/IP model also squashes the OSI's Physical and Data Link layers together into the Network Access Layer. Internet Protocol really doesn't (and shouldn't) care about the hardware underneath, so long as the computer can run the network device and send IP packets over the connection.

See also,

Salesforce Standard Objects and Sales Process

2017-03-28T22:14:00.003+05:30

A sales process is a series of repeatable steps that the sales team will take with a prospect to sell them the product. Sales Funnel is commonly used term for a Sales Process, I feel that a sales funnel is different though as it basically based on activity rates, basically the more you do the more that you will hopefully close. Another commonly used term is Sales Pipeline, and I think it’s a really good term that fits. Building a good sales process will take a lot of time and effort but it will improve your business.

Defining a Sales Process is important so that managers can accurately forecast and create realistic pipeline reporting. A properly defined process reduces wastes and is able to scale. In the past, companies simply used to pay high commissions and let the sales staff figure out how to prospect and make the sales that’s proven to work okay in times of rapid growth but it makes on boarding new hires difficult, and predicting revenue incredibly difficult.

Salesforce, out of the box, has a lot of the necessary tools to implement a simple Sales Process. Most of Salesforce’s standard objects are related to the sales stage

Leads are a person that has contact information that you should be able to sell to. Leads have three main sets of standard fields: Business Info, Contact Info, and Address Info. One of the most important fields for future data analysis and understanding whether your company’s marketing is effective is the Lead Source.

Usually after talking to the lead or reviewing what the lead has done the Sales Rep will qualify them. Leads should be qualified into Accounts, Contacts, and Opportunities as soon as possible. If your company is planning on doing a lot of heavy automation, you may want to automatically convert leads in apex.

Accounts are the businesses that you have some sort of relationship with. This could be a customer, a partner or something else. I recommend setting up different record types based on the Type field. Usually it makes sense to set the Record type in a trigger or process builder whenever the Type field has been changed. Record Types allow different page layouts to be setup, allow for different workflows or processes.

Contacts are the people that are in the business that you need to monitor and be in touch. Most often, these will only be the people that Sales and Support need to get in contact with.

Opportunities are deals in progress. Opportunities are very different from Leads, you can read about the differences in the blog article What’s the Differences Between a Lead and an Opportunity. Opportunities have quite a few standard fields which are used in the Sales Process. For example, one of the most important fields is the Opportunity Stage.

This Stage field should define the probability of a sale taking place from the sale’s persons perspective and should be used to determine what the Sales Rep should be doing with the Opportunity. Companies spend a significant amount of energy and expense trying to determine what the stages are and what should be done at each stage.

Make sure that it’s very clear to the sales team when they should be changing the Sales Stage because the wrong stages being set will create inaccurate forecasts. In addition, as your company grows you will probably start looking into implementing marketing automation solution. Commonly used Sales Stages are variations of the following:

Awareness: In this stage the prospect has become aware of your company and the solution you are providing. Usually your website will do most of the talking in this stage.
Interest: the sales rep will try to drum up interest. It usually makes sense to send them some white papers, suggest an ebook, and provide educational webinars.
Evaluation: In the Evaluation Stage they are comparing your company to your competitors, so it makes sense to have Case Studies, Samples (if Applicable), and conduct demos.
Decision: Sales Rep is going to provide some customer testimonials, additional proof, etc.
Quote / Negotiation: In this sales stage the Sales Rep is going to send a customized quote, and probably provide some final literature about ROI.
Closed/Won: This is the final stage of the process, this is where the buyer confirms they want the product are are ready to pay. In the case of B2B sales, this will probably involve purchase orders.
Closed/Lost: this isn’t really the ideal stage, but sometimes there’s just somebody your company can’t sell to. Make sure your company is Tracking Why a Opportunity or Lead has been lost.

Make sure that you have as few sales stages as necessary, so that it’s not impossible to see what’s happening when looking at the forecast and pipeline reporting.

Regardless of the stages that you decide to use, we always need to remember that the focus needs to be on the customer and what they actually need and when they need it. Marketing and the right amount of comment at the right time can help win an opportunity. In the case of a really long sales cycle, make sure the sales team are leaving notes for themselves. It’s not uncommon for Opportunities to get stuck in a stage for a while.

Probability is the likelihood that the opportunity will be sold. It’s used to calculated the Expected Revenue.

Expected Revenue is a formula field that’s equal to Amount * Probability. It doesn’t really make a lot of sense when you look at one opportunity, but across multiple opportunities in the Sales Pipeline and Forecasting Reports it gives a pretty good idea of how much revenue will be won.

Forecast Category is used in the Pipeline Reporting.

There’s some boolean formula fields that can be used in reporting. “Closed” and “Won” are pretty self explanatory. Closed will be true if the Stage Type is “Closed/Lost” or “Closed/Won” and Won will be true if the Stage is “Closed/Won”.

Difference between a Lead and Opportunity

2017-03-28T22:13:00.001+05:30

A lead is basically a person that has contact information that you should be able to sell to, they have been created because they have contacted you in someway with some sort of need whether this be that they filled out a contact form on your website or they exchanged business cards with somebody at a trade show. A lead does not have to be somebody that has purchasing authority, it could simply be somebody that has reached out the organization. Always make sure that the Lead Source has been set and that there’s a clear way of knowing what they have done.

An Opportunity is a deal that you could win or lose. Simply put, an opportunity is basically a lead that has been qualified (in Salesforce terms converted) for some reason. Most organizations convert the lead as soon as they believe its possible to sell to that lead. Qualification criteria could be anything really.

Companies have different beliefs on what an Opportunity is. Having a clear definition of what a lead is versus what an opportunity is clarifies reporting and expectations and can help improve the relationship between sales and marketing.

In most companies leads follow a process like this to become qualified

Basic Contact Information has been received – Lead is created.
Sales person or marketing automation reaches out and confirms there’s some sort of interest in the product or company. (Established Need)
Sales person confirms that this person / company has authority to make a purchasing decision.
Opportunity is created & Close Date for Deal is Established.
Quote / Deal Won.

In Salesforce, one of the core differences between a lead and an opportunity is that the lead has contact information and is relatively basic. Very few of the standard objects have a relationship with a lead, the opportunity has quite a few standard objects that are related to it. When a Lead is converted, whether it’s converted manually or automatically, a new account, contact, and opportunity can be created.

Difference between Salesforce.com and Force.com

2017-03-28T21:55:00.003+05:30

Even though it's very straight forward, difference between Salesforce.com and Force.com has always remained a core question for every newbies. I am hoping this post will help you in understanding the basic difference between this jargon.

Force.com is the platform that the Salesforce CRM and your customization run on. The Force.com platform consists of a multi-tenant architecture that runs on application services, web servers and of course database servers. Salesforce is using Java, and Oracle for significant parts of the Force.com Platform.

Force.com is also a platform as a service (PaaS) that can be purchased separately and won’t include a lot of the key CRM functionality like Leads, and Opportunities. Lately, Salesforce has started to advertise an additional cloud called the “AppCloud” which includes services like Heroku which is another server that Salesforce owns.

Salesforce.com is generally used to refer to the CRM functionality only, so this would be the “sales cloud”, “service cloud”, and marketing related clouds. Salesforce is running on the Force.com Platform.

Salesforce1 is the mobile application that Salesforce has developed which is available on Android and iOS. It’s possible for developers to add functionality which can be used in the mobile phone application.

Google Chrome Extensions for Salesforce Developers

2017-03-28T21:48:00.002+05:30

Salesforce Inspector

Salesforce Inspectors advertises itself as “Productivity tools for Salesforce administrators and developers to inspect data and metadata directly from the Salesforce UI” and it sure is. I have used this Chrome Extension so many times for confirming whether fields have help text, field labels and see how things are connected.

Install it from here.

Salesforce Navigator

Salesforce Navigator is a super handy little extension that allows developers and admins to search for just about anything in the metadata without having to do lots of clicking.

Install it from here.

Salesforce API FieldNames

This extension replaces all of the field labels with the API Names on page layouts. I find this is really useful for figuring out what employees are meaning when debugging triggers or fields being changed.

Install it from here.

Sandbox Favicon

Sandbox Favicon replaces the favicon with an S which helps remind developers and Salesforce Admins that they’re currently in a sandbox instead of production. I don’t know how many times I’ve went to do something and realized it was production or a sandbox. Over time, this extension has really helped.

Install it from here.

Salesforce Lightning Inspector

As everything related to Salesforce is slowly starting to switch to Salesforce Lightning, it makes sense to include the Google Chrome DevTools Extension that Salesforce has put together. The extension helps with understanding how events are being fired, and handled along with allow Lightning Components to be inspected.

Install it from here.

Force.com Utility Belt

I mainly use this Chrome Extension for the Documentation references, and for the converting from 15 digit Ids to 18 Digit Ids. Jeff Douglas wrote this extension a long time ago, so it’s usefulness has worn out over time.

Install it from here.

Salesforce Trigger - Best Practices

2015-03-11T17:19:00.001+05:30

In this article I will cover some basics of when to use a before-trigger vs. an after-trigger as well as how to make sure your triggers support bulk DML (Data Manipulation Language) operations and some best practices for creating triggers. There will be a part II to this article that will cover unit testing and some common trigger examples. But I do want to be clear, this is not an article about how to program so you will need to have a basic understanding of the Apex Coding Language and the tools used to develop these triggers such as the Force.com IDE.

I want to start with first explaining some basics about Apex Triggers. Apex Triggers are event handlers. When a record associated with the trigger is inserted, updated, deleted, or undeleted the Salesforce.com system will "fire" or execute the trigger event. Salesforce will actually execute a trigger in two different contexts: before and after. Before-trigger events are executed before a record has been committed to the database, while after-trigger events are executed after a record is committed to the database.

When to use Before-Triggers

Before-trigger events occur before a record’s changes are committed to the database. This particular event is ideal for performing data validation, setting default values, or performing additional logic and/or calculations. Please keep in mind that in the case of before-insert events, because the event is executed before the record is committed to the database it will not have a record id.

Before-triggers in my opinion are the most efficient and are going to be your goto method for most of the triggers you will write for a couple of reasons. The first being that you can perform data validation and reject a record before it is committed to the database, meaning there is no cost to performance by the system having to roll back an update. Second, you can update fields or set default values for a record without having to initiate another DML command.

For example the code below illustrates setting a default value on a record. No DML required.

trigger setDefaultAccountValues on Account (before insert, before update) {

for (Account oAccount : trigger.new) {

oAccount.Industry = ‘Cloud Computing’;

}

…and that is it. As you can see I simply just set the value of the field I want to change or default. Salesforce will take care of the rest.

When to use After-Triggers
After-trigger events occur after a record has been committed to the database, which means that records being inserted will have a record id available. This particular event is ideal for working with data that is external to the record itself such as referenced objects or creating records based on information from the triggered object.

Update: It was pointed out in the comments that the order of execution I described isn't entirely correct. Technically the record isn't truly committed to the database until after the after-trigger event, assignment rules, auto-response rules, and workflow rules are executed. Triggers execute as part of a transaction which means that any inserts/updates to the database can be rolled back. It is why you can throw an error in an after-trigger event that will prevent a record from being created even though it already has an Id assigned.

For more specific details on this topic you can visit the following online article titled Triggers and Order of Execution.

For example the code below illustrates creating an Opportunity after an Account is created.

trigger createNewAccountOpportunity on Account (after insert) {

List listOpportunities = new List();

for (Account oAccount : trigger.new) {

Opportunity oOpportunity = new Opportunity();

oOpportunity.Name = oAccount.Name;

oOpportunity.AccountId = oAccount.Id;

oOpportunity.Stage = ‘Proposal’;

oOpportunity.CloseDate = System.today() + 30; //Closes 30 days from today

listOpportunities.add(oOpportunity);

}

if (listOpportunities.isEmpty() == false) {

Database.update(listOpportunities);

}

As you can see from the code we were able to generate an Opportunity from an Account that was just created and because we needed the Account Id to do this we needed to use an after-trigger. We also borrowed some values from the Account itself to help populate the required fields on the Opportunity, but notice we didn’t query for those values…more on that later in the article.

Another key best practice for after-trigger events is that while it is possible to perform a DML operation on the record that initiated the trigger event, it should be avoided. If you think it through, when you perform a DML operation on a record from a trigger event the system will need to execute all triggers on that object again, not only does this impact performance but it puts us at risk of creating an infinite loop. Salesforce deals with this by only executing your triggers a certain number of times.

Later in this article we will discuss some best practices around how best to setup your execution criteria so that you can hedge against infinite loops and improve performance. Simply put after-trigger events are not the best place to perform DML operations on the triggered record and if you come across a situation where you feel it is necessary I would make sure that you are well aware of the impact that will have when the system recursively executes your trigger events.

Understanding Trigger Context

The context of a trigger is very important. We already discussed the before and after update contexts but there is also the context of what data is available to you at the time of trigger execution. In particular I am referring to the ++Trigger++ object. If you go back and review the examples I provided earlier in this article you will notice the use of a variable called “trigger”. This is a reference to an object that holds some information about the record or records that initiated the trigger. It also holds some information about the record as it existed before the update, allowing you to make decisions based on a records previous values. To get some background on what kind of information the trigger context variable provides you can review the Apex Trigger Context Documentation.

The trigger.new variable holds the information about the record(s) that was just inserted or updated (please make note that if you are looking for the data that was deleted that you will instead need to use the trigger.old variable to access that data). Salesforce does a bit of magic when it compiles your trigger by looking at the fields that you are referencing and making sure that data is available at runtime. So there is no need to actually attempt to query the information yourself. Just use the fields in your code and trust that Salesforce will take care of the rest.

The after-trigger event example I provided previously demonstrates how you can simply loop through the records in the trigger.new and reference Account fields without the need to query for the data explicitly. Just note that this does not work for data that is related to a record. For example, the sample code below illustrates an attempt to reference information on the user record that is related to an Opportunity as an owner. Interestingly, this does not produce an error instead you just get a null value for the profile name.

trigger exampleInvalidTrigger on Opportunity (before insert, before update) {

for (Opportunity oOpportunity : trigger.new) {

if (oOpportunity.Owner.Profile.Name == ‘Executive’) {

oOpportunity.IsExecutiveOpportunity = true;

}

trigger exampleValidTrigger on Opportunity (before insert, before update) {

Map mapUsers = new Map([SELECT Id, Profile.Name FROM User]);

for (Opportunity oOpportunity : trigger.new) {

User oOwner = mapUsers.get(oOpportunity.OwnerId);

if (oOwner.Profile.Name == ‘Executive’) {

oOpportunity.IsExecutiveOpportunity = true;

}

As you can see from the second example we had to query for the profile information in order to use it. Just note that this was just as an example and you will not want to load all users into a map as I did. There are other ways to get this information more efficiently that I will discuss in the next section.

Bulk Mode Triggers
In all of the examples I have illustrated so far you will notice that they all involve looping through a collection of records made available through the trigger.new property. This is because all triggers execute in batch mode, meaning whether it is single record or a hundred you will always need to use the trigger.new collection and thus you should prepare your trigger to be able to handle a batch of records. This forces us to think about how we write our triggers. We have to take care on how we query additional information and also keep in mind how many script statements we are executing per record.

Let’s start by revisiting the example from the previous section. If you recall, I had a requirement to only execute my code if the Opportunity Owner’s Profile Name was set to ‘Executive’. I could have written the trigger like this

trigger badExample on Opportunity (before insert, before update) {
for (Opportunity oOpportunity : trigger.new) {
User oOwner = [SELECT Id, Profile.Name FROM User WHERE Id = :oOpportunity.Id];

if (oOwner.Profile.Name == ‘Executive’) {
oOpportunity.IsExecutiveOpportunity = true;

}
}
}

The above example will actually work for triggers that have one or two opportunities in the trigger.new collection. However, as soon as the number of records increases beyond 100 you will start to get errors indicating that you executed “Too many SOQL queries”. Even if you only expect less than 100 records to be updated at a given time the limit context is counted across the entire transaction. This means that if you have 3 triggers on an object that each run 50 queries then the 3rd trigger to execute will throw an exception. So you will want to keep the number of queries you execute to a minimum. To get a better understanding of the types of limits that you need to be aware please refer to the online Apex Governor Limits Documentation.

The best way I have found to limit the number of queries is to load the data I need into a map so that I can make a single query call and reference that data by record id as needed.

trigger exampleGoodButInefficientTrigger on Opportunity (before insert, after update) {

Map mapUsers = new Map([SELECT Id, Profile.Name FROM User]);

for (Opportunity oOpportunity : trigger.new) {

User oOwner = mapUsers.get(oOpportunity.OwnerId);

if (oOwner.Profile.Name == ‘Executive’) {

oOpportunity.IsExecutiveOpportunity = true;

}

The example above is a good but inefficient example. I loaded all of the users into a map which means I only used one query but I really shouldn’t be loading an entire data set into memory like this. There are other limits to worry about such as heap size (the amount of memory your method is consuming) that we should be conscience of. Here is a better way to do the same thing.

trigger exampleBetterTrigger on Opportunity (before insert, after update) {

Set ownerIds = new Set();

for (Opportunity oOpportunity : trigger.new) {

ownerIds.add(oOpportunity.OwnerId);

}

Map mapUsers = new Map([SELECT Id, Profile.Name FROM User WHERE Id IN :ownerIds]);

for (Opportunity oOpportunity : trigger.new) {

User oOwner = mapUsers.get(oOpportunity.OwnerId);

if (oOwner.Profile.Name == ‘Executive’) {

oOpportunity.IsExecutiveOpportunity = true;

}

Now this example is much better. It loops through the list of opportunities first to figure out what owner ids are being used, collects them into a set collection, and then uses that information to only return users that are being used as owners in the opportunity collection. That way we limit the number of records we have in the map reducing our memory footprint and avoiding any map size limit exceptions.

But we can still do better. The problem is we are doing an extra loop. Again we don’t want to do anything we don’t have to do to keep our code as lean and simple as possible. One way we can avoid doing that initial loop is to let a query do the work for us. This requires the use of a more advanced query technique involving sub-queries. Here is an example of what the query should look like

SELECT Id, Profile.Name FROM User WHERE Id IN :(SELECT OwnerId FROM Opportunity WHERE Id IN :oppIds)
The first part of the query is fairly standard you simple define which fields you want to select and from which object. The more advanced part is in the where clause. Here we use a sub-query to select and return only the owner ids from the opportunity object where the opportunity id matches an id in the oppIds id collection. Here is this query in use.

trigger exampleBestTrigger on Opportunity (before insert, after update) {

Set oppIds = trigger.newMap.keySet();

Map mapUsers = new Map([SELECT Id, Profile.Name FROM User WHERE Id IN (SELECT OwnerId FROM Opportunity WHERE Id IN :oppIds)]);

for (Opportunity oOpportunity : trigger.new) {

User oOwner = mapUsers.get(oOpportunity.OwnerId);

if (oOwner.Profile.Name == ‘Executive’) {

oOpportunity.IsExecutiveOpportunity = true;

}

Now that is much better. In this example we make a single query call and only one loop. But let me draw your attention one other trick in the example above; the map data type. You will notice that I am passing the query to the map when I create it. Traditionally, you would expect the syntax to look similar to the next example.

Map mapUsers = new Map();

List listUsers = [SELECT Id, Name FROM Users];

for (User oUser: listUsers) {

mapUsers.put(oUser.Id, oUser);

}

As you can see this requires a loop of the query result to add the values into the map. But in my code I made use of a little Salesforce.com magic. The constructor for a Map is able to take a list of sObjects and generate a map for you. So when I use the following syntax Salesforce.com does the work for me and I can avoid doing that extra loop

List listUsers = [SELECT Id, Name FROM Users];

Map mapUsers = new Map(listUsers);

…or if I want to do this in a single line of code I can do the following.

Map mapUsers = new Map( [SELECT Id, Name FROM Users] );
You will find that Maps are going to be a powerful tool in making your code more efficient and less prone to cause limit exceptions. I encourage you to jump over to the Apex Map Data Type Documentation and read more about the various methods and capabilities of maps.

Using Trigger Criteria

In the previous example you saw how we tested the users profile to determine if we wanted to update a field. This is a very important strategy to make note of. In most cases your trigger logic doesn’t need to execute every time an update occurs. More often you are looking for certain conditions to exist before performing your logic. As we did in the last example we simply accessed the users profile name and looked for the value ‘Executive’ and only if that criteria was met do we update the field. However, what if we wanted our trigger to execute when a certain field was changed? The next example will demonstrate that exact scenario.

To set this up let us consider a use case where the Other Address field on a contact must match the contact’s account billing address. This would mean that when the account billing address is changed that we would then need to update any contacts associated with that account. Because this involves changing multiple child records it isn’t something that can be solved with a workflow rule and field updates. However, you can use a workflow rule and field updates to set the other address on the contact to the account’s billing address when the contact is created, which allows us to focus on changes to the account billing address. Let’s start with the code and then we can break it down.

trigger updateContactOtherAddress on Account(after insert, after update) {

if (trigger.isUpdate) {

//Identify Account Address Changes

Set setAccountAddressChangedIds = new Set();

for (Account oAccount : trigger.new) {

Account oOldAccount = trigger.oldMap.get(oAccount.Id);

boolean bIsChanged = (oAccount.BillingStreet != oOldAccount.BillingStreet || oAccount.BillingCity != oOldAccount.BillingCity);

if (bIsChanged) {

setAccountAddressChangedIds.add(oAccount.Id);

}

//If any, get contacts associated with each account

if (setAccountAddressChangedIds.isEmpty() == false) {

List listContacts = [SELECT Id, AccountId FROM Contact WHERE AccountId IN :setAccountAddressChangedIds];

for (Contact oContact : listContacts) {

//Get Account

oAccount = trigger.newMap.get(oContact.AccountId);

//Set Address

oContact.OtherStreet = oAccount.BillingStreet;

oContact.OtherCity = oAccount.BillingCity;

oContact.OtherState = oAccount.BillingState;

oContact.OtherPostalCode = oAccount.BillingPostalCode;

}

//If any, execute DML command to save contact addresses

if (listContacts.isEmpty() == false) {

update listContacts;

}

As you can see there are many parts to this trigger. So let’s first look at the context. The trigger is setup to run when a record is inserted and updated. However, because this particular requirement is to update contacts we can ignore any triggers that were made as a result of an insert since an account has to exist before contacts can be associated to it. You will also notice that I chose “after” events rather than “before” events. This is because we are not performing any DML against the account so we are safe from causing the trigger to execute multiple times. Also, we want to only bother updating contacts if the account has been successfully committed to the database.

Now we can start to look at the meat of the trigger. Remember all triggers run in a batch context so we have to assume that a trigger that is fired is the result of multiple accounts being updated at once - typically due to a batch upload or mass update. This means that an update could occur for any number of reasons that has nothing to do with an address change. So the first loop of this trigger is to go through the list of accounts and identify which accounts had an address change.

If you recall from the documentation along with the trigger.new property there are other properties that we make use of here, in particular: trigger.oldMap and trigger.newMap. These properties are Map data types that contain a key value pair of account id to account object and in the case of trigger.oldMap this contains the account information as it existed before the record was updated. This allows us to test if the account address fields match or have been changed. To do this I access the old account object from the map by the account id. I then compare the address fields to determine if they have changed (Note for the sake of space I only compared two address fields but in a real-world scenario you will want to compare all relevant address fields). Once I identify that the address has been changed then I add that account id to a set collection so that I can use it later to get contacts that will be affected by the change.

You will notice that along the way I am testing to see if there is any data in each collection. This is so that I don’t run the risk of executing any code in the event that a trigger did not contain any accounts where the address had changed. In the case that changes did occur then I query the related contacts by the set of account ids I collected earlier. I then loop through that collection, access the account by id from the trigger.newMap (since that contains the users updates), set the contact other address fields accordingly, and then finally initiate an update command to update the contacts.

An Ignorant Trigger is Always Best Practice

Yes, an ignorant trigger is what we should be striving for, in fact, the dumber the trigger the better. What I mean by this is if you look at the examples we have been working with thus far they have all had their logic defined in the trigger method itself. There are number of reasons that this is less than desirable:

The only way to unit test the trigger logic is to issue a DML command
The logic defined in the trigger is not re-usable
You can’t control the order of operation for objects that have more than one trigger

Let’s go right down the line. The first reason is that the only way to unit test the logic of a trigger is to initiate a DML operation. That means that you are limited in the types of unit test scenarios you can create. You are basically limited to creating tests for only scenarios where a record can be inserted or updated. You can’t break your logic into smaller functions and test each individually. This is particularly important in triggers that will be performing some complex logic or performing calculations.

Second, is that the logic you define in a trigger isn’t re-usable. In many cases you can simply rely on the trigger taking care of applying logic to a particular object but what if you need to apply that logic to an object before it is saved or what if you need to reuse parts of the logic; like say a method that performs a calculation.

Finally, and this is a big one, you have no control over the order that a given trigger is executed at runtime. If you have multiple triggers on an object you can’t have any dependencies on a field that another trigger is expected to update. Salesforce.com does not guarantee in which order each of these triggers will fire. Don’t assume anything.

To address all of these concerns I recommend applying a listener or observer pattern to trigger event methods (the terminology isn’t as important as the solution but from here on I will refer to it as the listener pattern). Essentially, we are downgrading the trigger method to do nothing more than to listen for records being inserted, updated, deleted, or undeleted and then pass that information on to one or more methods. First, let’s take a look at the sample below so that we can get some context on what this looks like.

trigger AccountBeforeEventListener on Account (before insert, before update) {

if (trigger.isInsert) {

AccountUtil.setDefaultValues(trigger.new);

AccountUtil.setIndustryCode(trigger.new);

}

public class AccountUtil {

public static void setDefaultValues(List listAccounts) {

for (Account oAccount : listAccounts) {

if (oAccount.Industry == null) {

oAccount.Industry = ‘Cloud Computing’;

}

public static void setIndustryCode(List listAccounts) {

for (Account oAccount : listAccounts) {

if (oAccount.Industry == ‘Cloud Computing’) {

oAccount.Industry_Code__c = ‘CC’;

}

I adapted the first example from this article into the listener pattern so it should look familiar. As you can see all of the logic that was originally in the trigger has been moved to a class called AccountUtil with two static methods called setDetaultValues and setIndustryCode. You will notice that I still kept the logic to determine if a trigger is an insert or update command and that is intentional. The trigger really is the best place to decide what context you are dealing with and then send that message on appropriately. In this case, we only want to execute the command for insert trigger events.

There are a couple of things I want to call attention to about this solution. The first is that with this solution I can call multiple methods in a specific order. Looking at the two methods the first one sets the default industry, if the user didn’t already set it, and the second sets the industry code based on the industry value. Had we left this to chance and created a trigger for each of these methods there is a possibility that the setIndustryCode trigger could run before the defaults trigger and you wouldn’t get the results you expected.

The second item I wanted to call attention to is how the creation of these two methods in a separate class did not impact our context. We are still able to update the fields on an account and not have to issue any DML commands. This is because when the data is passed to the methods from the trigger it is done by reference. Meaning the argument is just a pointer to where that collection of Accounts is stored in memory. So any changes you make from the method are available to the trigger or any other method.

The next question you should be asking then is how many triggers should we have per object. Most would say one. However, I like to step away from convention every now and then to satisfy my own logic. I prefer that before-trigger events and after-trigger events have their own triggers. For me it’s about the psychology of before-trigger being a unique type of event verses an after-trigger event. There really is no good reason for this other than I like it this way. You can actually just have a single method that can divide up the work between before and after events but I prefer keeping things at a much simpler level. Below are some examples of each and you can make your own decision on how you want to manage this.

//Single Trigger for Before and After Events

trigger AccountEventListener on Account (before insert, after insert, before update, after update) {

if (trigger.isBefore) {

if (trigger.isInsert || trigger.isUpdate) {

//DO SOMETHING

}

else if (trigger.isAfter) {

if (trigger.isInsert || trigger.isUpdate) {

//DO SOMETHING

}

//Before Event Trigger

trigger AccountBeforeEventListener on Account (before insert, before update) {

if (trigger.isInsert || trigger.isUpdate) {

//DO SOMETHING

}

//After Event Trigger

trigger AccountAfterEventListener on Account (after insert, after update) {

if (trigger.isInsert || trigger.isUpdate) {

//DO SOMETHING

}

As you can see all of the examples will produce the same results and it really is just a matter of preference.

Record Level Access in Salesforce

2015-03-05T13:47:00.000+05:30

Data Access in Salesforce

To meet your company’s security needs, it’s important to understand what data access means to your users and to you.

Data Access: User’s Perspective

If you put yourself in your users’ shoes, you won’t necessarily know or care how you’re getting access to records, but you might want to understand what having access means within the context of your organization. The following graph can help users visualize the different kinds of access that can be configured in Salesforce.

For example, if a user has access to an account field, then they have access to both the account field and the account object itself. However, a specific account record, such as “Account A”, might not be accessible to that user due to additional access control applied via sharing rules or other tools.

Data Access: Architect’s Perspective

As an architect, you must both understand your user’s perspective and know how to grant users only the appropriate level of access to the data that they should be able to access.

From an architect’s perspective, data access in Salesforce falls into two main categories: object-level access, which includes field-level access, and record-level access.

Object-level access determines whether a user has access to a particular object, which fields they can see on that object, and which actions they can perform. You configure object level access on user profiles.

Restricting access

The “Read,” “Create,” “Edit,” and “Delete” object permissions determine which actions a user can perform on any of the object's records to which they have access. Field-Level Security allows you to prevent certain users from seeing sensitive or confidential information contained in records they can see.

Opening up access

The “View All” and “Modify All” object permissions give users access to all of an object’s records, regardless of record-level access settings.

Record-level access (called “Sharing” in Salesforce) determines which records a user can see for a particular object, using the following tools:

Organization-wide defaults
Role hierarchy
Territory hierarchy
Sharing rules
Teams
Manual sharing
Programmatic sharing

Because you have so many options for managing record-level access — and because some of these options are affected by organizational dependencies — determining which records users can access can quickly become complicated. Additionally, you might also be changing your sharing configuration frequently in response to new business requirements. This can trigger record access changes that ripple through your organization. These changes have an even greater impact in very large organizations, where it can take some time to

recalculate access for a large number of users, and adjust the tables that record their access rights. For these reasons, it’s important to understand how Salesforce calculates and grants access at the database level.

Record Access Calculation

Every time a user attempts to open a record, run a report, access a list view, or search for data using the user interface or API, Salesforce checks the configuration of its record access features to determine which records the user can access. These configurations can be elaborate, especially in large organizations with hundreds of hierarchy nodes, thousands of sharing rules, millions of data rows, and portals for customers and business partners. Processing such dissimilar data and complex relationships would require far more time than

the 300-millisecond Salesforce benchmark for rendering pages.

Rather than applying every sharing rule, traversing all hierarchies, and analyzing record access inheritance in real time, Salesforce calculates record access data only when configuration changes occur. The calculated results persist in a way that facilitates rapid scanning and minimizes the number of database table joins necessary to determine record access at run time.

Access Grants

When an object has its organization-wide default set to Private or Public Read Only, Salesforce uses access grants to define how much access a user or group has to that object’s records. Each access grant gives a specific user or group access to a specific record. It also records the type of sharing tool — sharing rule, team, etc. — used to provide that access. Salesforce uses four types of access grants: explicit grants, group membership grants, inherited grants, and implicit grants.

Explicit Grants

Salesforce uses explicit grants when records are shared directly to users or groups. Specifically, Salesforce uses explicit grants when:

A user or a queue becomes the owner of a record.
A sharing rule shares the record to a personal or public group, a queue, a role, or a territory.
An assignment rule shares the record to a user or a queue.
A territory assignment rule shares the record to a territory.
A user manually shares the record to a user, a personal or public group, a queue, a role, or a territory.
A user becomes part of a team for an account, opportunity, or case.
A programmatic customization shares the record to a user, a personal or public group, a queue, a role, or a territory.

Note: If your organization doesn’t have an efficient sharing architecture, it might encounter performance problems when you use automated processes that generate a very large number of explicit grants, such as major sales realignments.

Group Membership Grants

Grants that occur when a user, personal or public group, queue, role, or territory is a member of a group that has explicit access to the record. For example, if a sharing rule explicitly grants the Strategy group access to the Acme record, and Bob is a member of the Strategy group, Bob’s membership in the Strategy group grants him access to the Acme record.

Inherited Grants

Grants that occur when a user, personal or public group, queue, role, or territory inherits access through a role or territory hierarchy, or is a member of a group that inherits access through a group hierarchy.

Implicit Grants

Grants that occur when non-configurable record-sharing behaviors built into Salesforce Sales, Service, and Portal applications grant access to certain parent and child records. For example, with this default logic, sometimes referred to as built-in sharing, users can view a parent account record if they have access to its child opportunity, case, or contact record. If those users have access to a parent account record, they can also access its child opportunity, case, and contact records.

Reference: Record Level Access in Salesforce

Salesforce : Tips and Tricks

2014-07-28T16:24:00.002+05:30

Deploying from Sandbox - Loss of Permissions, Page Assignments, Field Security etc.

When you add profiles to assign permissions in a change set, it only impacts the components of the change set. Change sets are never destructive, so they can't remove permissions you've assigned in production. You are safe to include the profiles during the change set deploy.

Just be aware some Profile settings are always transferred when you include the profile in the change set (e.g. Profile's system permissions). To avoid overwriting the production profile settings from sandbox, simple solution is to first send change set with anything (e.g. Account custom field) which is the same on prod and sandbox + all profiles from prod to sandbox - this will apply the production permissions to sandbox - and then you can send your change set from sandbox to prod. As sandbox has already been updated to prod status, you won't overwrite anything and only add new stuff to the profiles on prod.

Long story short, the only permissions that get deployed for a specified profile are exactly related to the other items in your deploy. If you have a 1 field, 1 visualforce page, and 1 page layout, only the permissions related to those 3 objects will be pushed to the target org and the remainder of the permissions will be in tact. It will not overwrite other permissions.

Delete Upto 10000* Records From Objects

delete [select Id from testObject where flag='test' LIMIT 10000]
Database.delete("[select Id from testObject where flag='test' LIMIT 10000]", false);

* DML statements can only process up to 10,000 records at a time

Difference between Lookup and Master-Detail in Salesforce

2014-07-27T15:03:00.005+05:30

There are several differences and several similarities as well.

Similarities:

They both create a one (parent) to many (children) relationship. One Account could have many Opportunites on it.
They both create a related list on the parent object listing the children.
Both kinds of relationships are created from the child object in salesforce.com by creating a field that represents the relationship.

Differences:

Unless you specify explicitly when creating the relationship, a child in a master-detail reclationship typically cannot be re-parented. With a lookup relationship you just click the magnifying glass next to the lookup field from the child record. (Standard salesforce.com objects are sort of an exception here.)
With a master-detail relationship, when you delete the parent record, the child records are deleted as well. With a lookup relationship, the child records are orphaned.
With a master-detail relationship, you are able to use the "rollup summary" type of formula field on the master record. This allows you to sum/average/count records and fields on the records of the child object. For example you could have a count field on the account object that tells you how many opportunities there are for that account.
Using a master-detail relationship the child is always created from the parent record. With a lookup field you can set filters to reduce the number of parent records viewed when clicking the magnifying glass to perform the lookup. This allows you to create the child object first, then link it to the parent record later.

Here is a link to the ERDs describing the salesforce.com data model:

http://www.salesforce.com/us/developer/docs/api/Content/data_model.htm

Example of when to use each:

Custom Opportunity object with custom Opportunity Parts object. For this I would use Master-Detail. That way if the Opportunity is deleted, the parts records related to the Opportunity would also be deleted. Data related to the parts could be rolled up to the Opportunity and since it's very unlikely you'd ever have to reassign an opportunity part it would work well.
Custom Hierarchy object. Use record types to define the levels of the hierarchy and a lookup field from Hierarchy object to itself to create the links. If you delete a higher level of the hierarchy it wouldn't delete all the lower levels, and you can reassign as the shape of the hierarchy changes.
Custom Request object and Standard User object. I'd use a lookup field to the user object if you want to relate a user other than the CreatedBy user. For example if the request needs to be approved by the user's manager, you could have a lookup field from the Request to the User object that is filled with the manager's name either by workflow rule or by the user. If the user's manager changes, the prior requests won't be deleted.

How to make a Method Thread Safe?

2014-01-19T12:30:00.001+05:30

In multi-threaded applications where multiple threads make calls to the methods of a single object, it is necessary that those calls be synchronized. If code is not synchronized, then one thread might interrupt another thread and the object could be left in an invalid state. A class whose members are protected from such interruptions is called thread-safe.

Although, there is no rule that makes the code thread safe, the only thing you can do is make sure that your code will work no matter how many times is it being actively executed, each thread can be interrupted at any point, with each thread being in its own state/location, and this for each function (static or otherwise) that is accessing common objects.

If a method (instance or static) only references variables scoped within that method then it is thread safe because each thread has its own stack:

In this instance, multiple threads could call ThreadSafeMethod concurrently without issue.

public class Thing
{
    public int ThreadSafeMethod(string parameter1)
    {
        int number; // each thread will have its own variable for number.
        number = parameter1.Length;
        return number;
    }
}

This is also true if the method calls other class method which only reference locally scoped variables:

public class Thing
{
    public int ThreadSafeMethod(string parameter1)
    {
        int number;
        number = this.GetLength(parameter1);
        return number;
    }

    private int GetLength(string value)
    {
        int length = value.Length;
        return length;
    }
}

If a method accesses any (object state) properties or fields (instance or static) then you need to use locks to ensure that the values are not modified by a different thread.

public class Thing
{
    private string someValue; // all threads will read and write to this same field value

    public int NonThreadSafeMethod(string parameter1)
    {
        this.someValue = parameter1;

        int number;

        // Since access to someValue is not synchronised by the class, a separate thread
        // could have changed its value between this thread setting its value at the start 
        // of the method and this line reading its value.
        number = this.someValue.Length;
        return number;
    }
}

You should be aware that any parameters passed in to the method which are not either a struct or immutable could be mutated by another thread outside the scope of the method.

To ensure proper concurrency you need to use locking.

For further information see lock statement C# reference, Monitoring and ReadWriterLockSlim.

Lock is mostly useful for providing one at a time functionality, ReadWriterLockSlim is useful if you need multiple readers and single writers.

An Introduction To DOM Events

2013-12-17T16:32:00.001+05:30

Click, touch, load, drag, change, input, error, resize — the list of possible DOM events is lengthy. Events can be triggered on any part of a document, whether by a user’s interaction or by the browser. They don’t just start and end in one place; they flow though the document, on a life cycle of their own. This life cycle is what makes DOM events so extensible and useful. As developers, we should understand how DOM events work, so that we can harness their potential and build engaging experiences.

Throughout my time as a front-end developer, I felt that I was never given a straight explanation of how DOM events work. My aim here is to give you a clear overview of the subject, to get you up to speed more quickly than I did.

I will introduce the basics of working with DOM events, then delve into their inner workings, explaining how we can make use of them to solve common problems.

Listening For Events

In the past, browsers have had major inconsistencies in the way they attach event listeners to DOM nodes. Libraries such as jQuery have been invaluable in abstracting away these oddities.

As we move ever closer to standardized browser environments, we can more safely use the APIs from the official specification. To keep it simple, I will describe how to manage events for the modern Web. If you are writing JavaScript for Internet Explorer (IE) 8 or below, I would advise using a polyfill or framework (such as jQuery) to manage event listeners.

In JavaScript, we can listen to events using this:

element.addEventListener(<event-name>, <callback>, <use-capture>);

event-name (string)
This is the name or type of event that you would like to listen to. It could be any of the standard DOM events (click, mousedown, touchstart,transitionEnd, etc.) or even your own custom event name (we’ll touch on custom events later).
callback (function)
This function gets called when the event happens. The event object, containing data about the event, is passed as the first argument.
use-capture (boolean)
This declares whether the callback should be fired in the “capture” phase. (Don’t worry: We’ll explain what that means a little later.)

var element = document.getElementById('element');

function callback() {
  alert('Hello');
}

// Add listener
element.addEventListener('click', callback);

Removing Listeners

Removing event listeners once they are no longer needed is a best practice (especially in long-running Web applications). To do this, use theelement.removeEventListener() method:

element.removeEventListener(<event-name>, <callback>, <use-capture>);

But removeEventListener has one catch: You must have a reference to the callback function that was originally bound. Simply callingelement.removeEventListener('click'); will not work.

Essentially, if we have any interest in removing event listeners (which we should in “long-lived” applications), then we need to keep a handle on our callbacks. This means we cannot use anonymous functions.

var element = document.getElementById('element');

function callback() {
  alert('Hello once');
  element.removeEventListener('click', callback);
}

// Add listener
element.addEventListener('click', callback);

Maintaining Callback Context

An easy gotcha is callbacks being called with the incorrect context. Let’s explain with an example.

var element = document.getElementById('element');

var user = {
 firstname: 'Wilson',
 greeting: function(){
   alert('My name is ' + this.firstname);
 }
};

// Attach user.greeting as a callback
element.addEventListener('click', user.greeting);

// alert => 'My name is undefined'

USING ANONYMOUS FUNCTIONS

We expected the callback to correctly alert us with My name is Wilson. In fact, it alerts us with My name is undefined. In order for this.firstName to return Wilson,user.greeting must be called within the context (i.e. whatever is left of the dot when called) of user.

When we pass the greeting function to the addEventListener method, we are only passing a reference to the function; the context of user is not passed with it. Internally, the callback is called in the context of element, which means thatthis refers to element, not to user. Therefore, this.firstname is undefined.

There are two ways to prevent this context mismatch. First, we can calluser.greeting() with the correct context inside an anonymous function.

element.addEventListener('click', function() {
  user.greeting();
  // alert => 'My name is Wilson'
});

FUNCTION.PROTOTYPE.BIND

The last method isn’t so good because now we don’t have a handle on the function when we want to remove it with .removeEventListener(). Plus, it’s pretty ugly. I prefer to use the .bind() method (built into all functions, as of ECMAScript 5) to generate a new function (bound) that will always run in the given context. We then pass that function as the callback to.addEventListener().

// Overwrite the original function with
// one bound to the context of 'user'
user.greeting = user.greeting.bind(user);

// Attach the bound user.greeting as a callback
button.addEventListener('click', user.greeting);

We also have a reference to the callback at hand, which we can use to unbind the listener if need be.

button.removeEventListener('click', user.greeting);

Check the support page for Function.prototype.bind and polyfill if you need it.

The Event Object

The event object is created when the event first happens; it travels with the event on its journey through the DOM. The function that we assign as a callback to an event listener is passed the event object as its first argument. We can use this object to access a wealth of information about the event that has occurred:

type (string)
This is the name of the event.
target (node)
This is the DOM node where the event originated.
currentTarget (node)
This is the DOM node that the event callback is currently firing on.
bubbles (boolean)
This indicates whether this is a “bubbling” event (which we’ll explain later).
preventDefault (function)
This prevents any default behaviour from occurring that the user agent (i.e. browser) might carry out in relation to the event (for example, preventing a click event on an element from loading a new page).
stopPropagation (function)
This prevents any callbacks from being fired on any nodes further along the event chain, but it does not prevent any additional callbacks of the same event name from being fired on the current node. (We’ll talk about that later.)
stopImmediatePropagation (function)
This prevents any callbacks from being fired on any nodes further along the event chain, including any additional callbacks of the same event name on the current node.
cancelable (boolean)
This indicates whether the default behaviour of this event can be prevented by calling the event.preventDefault method.
defaultPrevented (boolean)
This states whether the preventDefault method has been called on the event object.
isTrusted (boolean)
An event is said to be “trusted” when it originates from the device itself, not synthesized from within JavaScript.
eventPhase (number)
This number represents the phase that the event is currently in: none (0), capture (1), target (2) or bubbling (3). We’ll go over event phases next.
timestamp (number)
This is the date on which the event occurred.

Many other properties can be found on the event object, but they are specific to the type of event in question. For example, mouse events will include clientXand clientY properties on the event object to indicate the location of the pointer in the viewport.

It’s best to use your favorite browser’s debugger or a console.log to look more closely at the event object and its properties.

Event Phases

When a DOM event fires in your app, it doesn’t just fire once where the event originated; it embarks on a journey of three phases. In short, the event flows from the document’s root to the target (i.e. capture phase), then fires on the event target (target phase), then flows back to the document’s root (bubbling phase).

CAPTURE PHASE

The first phase is the capture phase. The event starts its journey at the root of the document, working its way down through each layer of the DOM, firing on each node until it reaches the event target. The job of the capture phase is to build the propagation path, which the event will travel back through in the bubbling phase.

As mentioned, you can listen to events in the capture phase by setting the third argument of addEventListener to true. I have not found many use cases for capture phase listeners, but you could potentially prevent any clicks from firing in a certain element if the event is handled in the capture phase.

var form = document.querySelector('form');

form.addEventListener('click', function(event) {
  event.stopPropagation();
}, true); // Note: 'true'

If you’re unsure, listen for events in the bubbling phase by setting theuseCapture flag to false or undefined.

TARGET PHASE

An event reaching the target is known as the target phase. The event fires on the target node, before reversing and retracing its steps, propagating back to the outermost document level.

In the case of nested elements, mouse and pointer events are always targeted at the most deeply nested element. If you have listened for a click event on a

element, and the user actually clicks on a element in the div, then the element will become the event target. The fact that events “bubble” means that you are able to listen for clicks on the

(or any other ancestor node) and still receive a callback once the event passes through.

BUBBLING PHASE

After an event has fired on the target, it doesn’t stop there. It bubbles up (or propagates) through the DOM until it reaches the document’s root. This means that the same event is fired on the target’s parent node, followed by the parent’s parent, continuing until there is no parent to pass the event onto.

Think of the DOM as an onion and the event target as the core of the onion. In the capture phase, the event drills into the onion through each layer. When the event reaches the core, it fires (the target phase), and then reverses, working its way back up through each layer (the propagation phase). Once the event has returned to the surface, its journey is over.

Bubbling is useful. It frees us from listening for an event on the exact element it came from; instead, we listen on an element further up the DOM tree, waiting for the event to reach us. If events didn’t bubble, we would have to, in some cases, listen for an event on many different elements to ensure that it is caught.

The majority of, but not all, events bubble. When events do not bubble, it is usually for a good reason. If in doubt, check the specification.

Stopping Propagation

Interrupting the path of the event at any point on its journey (i.e. in the capture or bubbling phase) is possible simply by calling the stopPropagation method on the event object. Then, the event will no longer call any listeners on nodes that it travels through on its way to the target and back to the document.

child.addEventListener('click', function(event) {
 event.stopPropagation();
});

parent.addEventListener('click', function(event) {
 // If the child element is clicked
 // this callback will not fire
});

Calling event.stopPropagation() will not prevent any additional event listeners from being called on the current target if multiple listeners for the same event exist. If you wish to prevent any additional listeners from being called on the current node, you can use the more aggressiveevent.stopImmediatePropagation() method.

child.addEventListener('click', function(event) {
 event.stopImmediatePropagation();
});

child.addEventListener('click', function(event) {
 // If the child element is clicked
 // this callback will not fire
});

Prevent The Browser’s Default Behavior

The browser has default behaviors that will respond when certain events occur in the document. The most common event is a link being clicked. When a clickevent occurs on an element, it will bubble up to the document level of the DOM, and the browser will interpret the href attribute and reload the window at the new address.

In Web applications, developers usually want to manage the navigation themselves, without causing the page to refresh. To do this, we need to prevent the browser’s default response to clicks and instead do our own thing. To do this, we call event.preventDefault().

anchor.addEventListener('click', function(event) {
  event.preventDefault();
  // Do our own thing
});

We can prevent many other default behaviors in the browser. For example, we could prevent presses of the space bar from scrolling the page in an HTML5 game, or we could prevent clicks from selecting text.

Calling event.stopPropagation() here will only prevent callbacks that are attached further down the propagation chain from being fired. It will not prevent the browser from doing its thing.

Custom Events

The browser is not the only thing that is able to trigger DOM events. We can create our own custom events and dispatch them on any element in the document. This type of event would behave just the same as a regular DOM event.

var myEvent = new CustomEvent("myevent", {
  detail: {
    name: "Wilson"
  },
  bubbles: true,
  cancelable: false
});

// Listen for 'myevent' on an element
myElement.addEventListener('myevent', function(event) {
  alert('Hello ' + event.detail.name);
});

// Trigger the 'myevent'
myElement.dispatchEvent(myEvent);

Synthesizing “untrusted” DOM events on elements (for example, click) to simulate user interaction is also possible. This can be useful when testing DOM-related libraries. If you’re interested, the Mozilla Developer Network has a write-up on it.

Note the following:

The CustomEvent API is not available in IE 8 and below.
The Flight framework from Twitter makes use of custom events to communicate between modules. This enforces a highly decoupled, modular architecture.

Delegate Event Listeners

Delegate event listeners are a more convenient and performant way to listen for events on a large number of DOM nodes using a single event listener. For example, if a list contains 100 items that all need to respond to a click event in a similar way, then we could query the DOM for all of the list items and attach an event listener to each one. This would result in 100 separate event listeners. Whenever a new item is added to the list, the click event listener would have to be added to it. Not only does this risk getting expensive, but it is tricky to maintain.

Delegate event listeners can make our lives a lot easier. Instead of listening for the click event on each element, we listen for it on the parent ul element. When an li is clicked, then the event bubbles up to the ul, triggering the callback. We can identify which li element has been clicked by inspecting the event.target. Below is a crude example to illustrate:

var list = document.querySelector('ul');

list.addEventListener('click', function(event) {
  var target = event.target;
 
  while (target.tagName !== 'LI') {
    target = target.parentNode;
    if (target === list) return;
  }

  // Do stuff here
});

This is better because we have only the overhead of a single event listener, and we no longer have to worry about attaching a new event listener when an item is added to the list. The concept is pretty simple but super-useful.

I wouldn’t recommend using such a crude implementation in your app. Instead, use an event delegate JavaScript library, such as FT Lab’s ftdomdelegate. If you’re using jQuery, you can seamlessly use event delegation by passing a selector as the second parameter to the .on() method.

// Not using event delegation
$('li').on('click', function(){});

// Using event delegation
$('ul').on('click', 'li', function(){});

Useful Events

LOAD

The load event fires on any resource that has finished loading (including any dependent resources). This could be an image, style sheet, script, video, audio file, document or window.

image.addEventListener('load', function(event) {
  image.classList.add('has-loaded');
});

ONBEFOREUNLOAD

window.onbeforeunload enables developers to ask the user to confirm that they want to leave the page. This can be useful in applications that require the user to save changes that would get lost if the browser’s tab were to be accidentally closed.

window.onbeforeunload = function() {
  if (textarea.value != textarea.defaultValue) {
    return 'Do you want to leave the page and discard changes?';
  }
};

Note that assigning an onbeforeunload handler prevents the browser from caching the page, thus making return visits a lot slower. Also, onbeforeunloadhandlers must be synchronous.

STOPPING WINDOW BOUNCE IN MOBILE SAFARI

At the Financial Times, we use a simple event.preventDefault technique to prevent mobile Safari from bouncing the window when it is scrolled.

document.body.addEventListener('touchmove', function(event) {
 event.preventDefault();
});

Be warned that this will also prevent any native scrolling from working ( such asoverflow: scroll). To allow native scrolling on a subset of elements that need it, we listen for the same event on the scrollable element and set a flag on the event object. In the callback at the document level, we decide whether to prevent the default behavior of the touch event based on the existence of theisScrollable flag.

// Lower down in the DOM we set a flag
scrollableElement.addEventListener('touchmove', function(event) {
 event.isScrollable = true;
});

// Higher up the DOM we check for this flag to decide
// whether to let the browser handle the scroll
document.addEventListener('touchmove', function(event) {
 if (!event.isScrollable) event.preventDefault();
});

Manipulating the event object is not possible in IE 8 and below. As a workaround, you can set properties on the event.target node.

RESIZE

Listening to the resize event on the window object is super-useful for complex responsive layouts. Achieving a layout with CSS alone is not always possible. Sometimes JavaScript has to help us calculate and set the size of elements. When the window is resized or the device’s orientation changes, then we would likely need to readjust these sizes.

window.addEventListener('resize', function() {
  // update the layout
});

I recommended using a debounced callback to normalize the callback rate and prevent extreme thrashing in the layout.

TRANSITIONEND

Today we use CSS to power the majority of transitions and animations in our applications. Sometimes, though, we still need to know when a particular animation has finished.

el.addEventListener('transitionEnd', function() {
 // Do stuff
});

Note the following:

If you’re using @keyframe animations, use the animationEnd event name, instead of transitionEnd.
Like a lot of events, transitionEnd bubbles. Remember either to callevent.stopPropagation() on any descendant transition events or to check the event.target to prevent callback logic from running when it’s not supposed to.
Event names are still widely vendor-prefixed (for example,webkitTransitionEnd, msTransitionEnd, etc). Use a library such asModernizr to get the event name’s correct prefix.

ANIMATIONITERATION

The animationiteration event will fire every time a currently animating element completes an iteration. This is useful if we want to stop an animation but not midway through.

function start() {
  div.classList.add('spin');
}

function stop() {
  div.addEventListener('animationiteration', callback);

  function callback() {
    div.classList.remove('spin');
    div.removeEventListener('animationiteration', callback);
  }
}

If you’re interested, I’ve written about the animationiteration event in a little more detail on my blog.

ERROR

If an error occurs when a resource loads, we might want to do something about it, especially if our users are on a flaky connection. The Financial Times uses this event to detect any images that might have failed to load in an article and instantly hide them. Because the “DOM Level 3 Events” specification has redefined the error event to “not bubble,” we can handle the event in one of two ways.

imageNode.addEventListener('error', function(event) {
  image.style.display = 'none';
});

Unfortunately, addEventListener does not address all use cases. My colleagueKornel has kindly pointed me to an example that demonstrates that the only way, sadly, to guarantee the execution of image error event callbacks is to use (the often frowned upon) inline event handlers.

<img src="http://example.com/image.jpg" onerror="this.style.display='none';" />

The reason for this is that you cannot be sure that the code that binds the errorevent handler will be executed before the error event actually happens. Using inline handlers means that when the markup is parsed and the image is requested, our error listeners will be attached.

Database Sharding

2013-10-16T17:28:00.001+05:30

Database Sharding

The Rise of Database Sharding

The concept of Database Sharding has been gaining popularity over the past several years, due to the enormous growth in transaction volume and size of business application databases. This is particularly true for many successful online service providers, Software as a Service (SaaS) companies, and social networking Web sites.

Database Sharding can be simply defined as a "shared-nothing" partitioning scheme for large databases across a number of servers, enabling new levels of database performance and scalability achievable. If you think of broken glass, you can get the concept of sharding - breaking your database down into smaller chunks called “shards” and spreading those across a number of distributed servers.

The term "sharding" was coined by Google engineers, and popularized through their publication of the Big Table architecture. However, the concept of "shared-nothing" database partitioning has been around for a decade or more and there have been many implementations over this period, especially high profile in-house built solutions by Internet leaders such as eBay, Amazon, Digg, Flickr, Skype, YouTube, Facebook, Friendster, and Wikipedia.

The focus of this paper is on the need for Database Sharding, the options available for database partitioning, and the key considerations for a successful sharding implementation.

What Drives the Need for Database Sharding?

Database Sharding is a highly scalable approach for improving the throughput and overall performance of high-transaction, large database-centric business applications. Since the inception of the relational database, application engineers and architects have required ever-increasing performance and capacity, based on the simple observation that business databases generally grow in size over time. Adding to this general trend is the extreme expansion of business data due to the evolution of the Internet economy, the Information Age, and the prevalence of high-volume electronic commerce.

As any experienced database administrator or application developer knows all too well, it is axiomatic that as the size and transaction volume of the database tier incurs linear growth, response times tend to grow logarithmically. This is shown in the following diagram:

Figure 1. The growth in database transactions and volumes has a large impact on response times.

The reasons for the performance and scalability challenges are inherent to the fundamental design of the database management systems themselves. Databases rely heavily on the primary three components of any computer:

CPU
Memory
Disk

Through benchmark tests that we have performed, we know that each of these elements on a single server can only scale to a given point, and then other measures must be taken. While it is clear that disk I/O is the primary bottleneck, as database management systems have improved they also continue to take greater advantage of CPU and memory. In fact, we have observed that it is the matching of these three factors that determines maximum performance. In other words, you cannot add an unlimited number of CPUs (or processing cores) and see a commensurate increase in performance without also improving the memory capacity and performance of the disk drive subsystem. It is also common to see a diminishing return as resources are added to a single database server. These factors are especially true in mixed-use business transaction systems; systems that perform a high volume of read and write transactions, as well as supporting generalized business reporting tasks.

Therefore, as business applications gain sophistication and continue to grow in demand, architects, developers and database administrators have been presented with a constant challenge of maintaining database performance for mission critical systems. This landscape drives the need for Database Sharding.

Database Partitioning Options

It has long been known that database partitioning is the answer to improving the performance and scalability of relational databases. Many techniques have been evolved, including:

Master/Slave: This is the simplest option used by many organizations, with a single Master server for all write (Create Update or Delete, or CRUD) operations, and one or many additional Slave servers that provide read-only operations. The Master uses standard, near-real-time database replication to each of the Slave servers. The Master/Slave model can speed overall performance to a point, allowing read-intensive processing to be offloaded to the Slave servers, but there are several limitations with this approach:
- The single Master server for writes is a clear limit to scalability, and can quickly create a bottleneck.
- The Master/Slave replication mechanism is "near-real-time," meaning that the Slave servers are not guaranteed to have a current picture of the data that is in the Master. While this is fine for some applications, if your applications require an up-to-date view, this approach is unacceptable.
- Many organizations use the Master/Slave approach for high-availability as well, but it suffers from this same limitation given that the Slave servers are not necessarily current with the Master. If a catastrophic failure of the Master server occurs, any transactions that are pending for replication will be lost, a situation that is highly unacceptable for most business transaction applications.
Cluster Computing: Cluster computing utilizes many servers operating in a group, with shared messaging between the nodes of the cluster. Most often this scenario relies on a centralized shared disk facility, typically a Storage Area Network (SAN). Each node in the cluster runs a single instance of the database server, operating in various modes:
- For high-availability, many nodes in the cluster can be used for reads, but only one for write (CRUD) operations. This can make reads faster, but write transactions do not see any benefit. If a failure of one node occurs, then another node in the cluster takes over, again continuing to operating against the shared disk facility. This approach has limited scalability due to the single bottleneck for CRUD operations. Even the reads will ultimately hit a performance limit as the centralized shared disk facility can only spread the load so much before diminishing returns are experienced. The read limitations are particularly evident when an application requires complex joins or contains non-optimized SQL statements.
- More advanced clustering techniques rely on real-time memory replication between nodes, keeping the memory image of nodes in the cluster up to date via a real-time messaging system. This allows each node to operate in both read or write mode, but is ultimately limited by the amount of traffic that can be transmitted between nodes (using a typical network or other high-speed communication mechanism). Therefore, as nodes are added, the communication and memory replication overhead increases geometrically, thus hitting severe scalability limits, often with a relatively small number of nodes. This solution also suffers from the same shared disk limitations of a traditional cluster, given that a growing, single large database has increasingly intensive disk I/O.
Table Partitioning: Many database management systems support table partitioning, where data in a single large table can be split across multiple disks for improved disk I/O utilization. The partitioning is typically done horizontally (separating rows by range across disk partitions), but can be vertical in some systems as well (placing different columns on separate partitions). This approach can help reduce the disk I/O bottleneck for a given table, but can often make joins and other operations slower. Further, since the approach relies on a single server instance of the database management system, all other CPU and memory contention limitations apply, further limiting scalability.
Federated Tables: An offshoot of Table Partitioning is the Federated Table approach, where tables can be accessed across multiple servers. This approach is necessarily highly complex to administer, and lacks efficiency as the federated tables must be accessed over the network. This approach may work for some reporting or analytical tasks, but for general read/write transactions it is not a very likely choice.

The common drawback with each of these approaches is the reliance on shared facilities and resources. Whether relying on shared memory, centralized disk, or processor capacity they each suffer with scalability limitations, not to mention many other drawbacks, including complex administration, lack of support for critical business requirements, and high availability limitations.

Database Sharding, The "Shared-Nothing" Approach

Database Sharding provides a method for scalability across independent servers, each with their own CPU, memory and disk. Contrasted with other traditional methods of achieving greater database performance, it does not suffer from many of the typical limitations posed by these other approaches. The concept of a "shared-nothing" database implementation has been under research or discussion for 15+ years, but it appears that the business application market is just now finding the more general need for such capability due to the exponential increase in data volumes over the past several years.

The basic concept of Database Sharding is very straightforward: take a large database, and break it into a number of smaller databases across servers. The concept is illustrated in the following diagram:

Figure 2. Database Sharding takes large databases and breaks them down into smaller databases.

The obvious advantage of the shared-nothing Database Sharding approach is improved scalability, growing in a near-linear fashion as more servers are added to the network. However, there are several other advantages of smaller databases, which should not be overlooked when considering a sharding solution:

Smaller databases are easier to manage. Production databases must be fully managed for regular backups, database optimization and other common tasks. With a single large database these routine tasks can be very difficult to accomplish, if only in terms of the time window required for completion. Routine table and index optimizations can stretch to hours or days, in some cases making regular maintenance infeasible. By using the sharding approach, each individual "shard" can be maintained independently, providing a far more manageable scenario, performing such maintenance tasks in parallel.
Smaller databases are faster. The scalability of sharding is apparent, achieved through the distribution of processing across multiple shards and servers in the network. What is less apparent is the fact that each individual shard database will outperform a single large database due to its smaller size. By hosting each shard database on its own server, the ratio between memory and data on disk is greatly improved, thereby reducing disk I/O. This results in less contention for resources, greater join performance, faster index searches, and fewer database locks. Therefore, not only can a sharded system scale to new levels of capacity, individual transaction performance is benefited as well.
Database Sharding can reduce costs. Most Database Sharding implementations take advantage of lower-cost open source databases, or can even take advantage of "workgroup" versions of commercial databases. Additionally, sharding works well with commodity multi-core server hardware, far less expensive than high-end multi-CPU servers and expensive SANs. The overall reduction in cost due to savings in license fees, software maintenance and hardware investment is substantial, in some cases 70% or more when compared to other solutions.

There is no doubt that Database Sharding is a viable solution for many organizations, supported by the number of large online vendors and SaaS organizations that have implemented the technology (giants such as Amazon, eBay, and of course Google).

Practicalities of Database Sharding

If Database Sharding is highly scalable, less costly, and improves performance, why hasn't adoption of the technology been more widespread? Is it feasible for your organization?

The reality is that Database Sharding is a very useful technology, but like other approaches, there are many factors to consider that ensure a successful implementation. Further, there are some limitations and Database Sharding will not work well for every type of business application. This chapter discusses these critical considerations and how they can be addressed.

Database Sharding Challenges

Due to the distributed nature of individual databases, a number of key elements must be taken into account:

Reliability. First and foremost, any production business application must be reliable and fault-tolerant, and cannot be subject to frequent outages. The database tier is often the single most critical element in any reliability design, and therefore an implementation of Database Sharding is no exception. In fact, due to the distributed nature of multiple shard databases, the criticality of a well-designed approach is even greater. To ensure a fault-tolerant and reliable approach, the following items are required:
- Automated backups of individual Database Shards.
- Database Shard redundancy, ensuring at least 2 "live" copies of each shard are available in the event of an outage or server failure. This requires a high-performance, efficient, and reliable replication mechanism.
- Cost-effective hardware redundancy, both within and across servers.
- Automated failover when an outage or server failure occurs.
- Disaster Recovery site management.
Distributed queries. Many types of queries can be processed far faster using distributed queries, performing parallel processing of interim results on each shard server. This technique can achieve order-of-magnitude improvements in performance, in many cases 10X or more. To enable distributed queries in a seamless manner for the application, it is important to have a facility that can process a segment of the query on each individual shard, and then consolidate the results into a single result set for the application tier. Common queries that can benefit from distributed processing are:
- Aggregation of statistics, requiring a broad sweep of data across the entire system. Such an example is the computation of sales by product, which ordinarily requires evaluation of the entire database.
- Queries that support comprehensive reports, such as listings of all individual customers that purchased a given product in the last day, week or month.
Avoidance of cross-shard joins. In a sharded system, queries or other statements that use inner-joins that span shards are highly inefficient and difficult to perform. In the majority of cases, it has been found that such inner-joins are not actually required by an application, so long as the correct techniques are applied. The primary technique is the replication of Global Tables, the relatively static lookup tables that are common utilized when joining to much larger primary tables. Tables containing values as Status Codes, Countries, Types, and even Products fall into this category. What is required is an automated replication mechanism that ensures values for Global Tables are in synch across all shards, minimizing or eliminating the need for cross-shard joins.
Auto-increment key management. Typical auto-increment functionality provided by database management systems generate a sequential key for each new row inserted into the database. This is fine for a single database application, but when using Database Sharding, keys must be managed across all shards in a coordinated fashion. The requirement here is to provide a seamless, automated method of key generation to the application, one that operates across all shards, ensuring that keys are unique across the entire system.
Support for multiple Shard Schemes. It is important to note that Database Sharding is effective because it offers an application specific technique for massive scalability and performance improvements. In fact it can be said that the degree of effectiveness is directly related to how well the sharding algorithms themselves are tailored to the application problem at hand. What is required is a set of multiple, flexible shard schemes, each designed to address a specific type of application problem. Each scheme has inherent performance and/or application characteristics and advantages when applied to a specific problem domain. In fact, using the wrong shard scheme can actually inhibit performance and the very results you are trying to obtain. It is also not uncommon for a single application to use more than one shard scheme, each applied to a specific portion of the application to achieve optimum results. Here is a list of some common shard schemes:

Session-based sharding, where each individual user or process interacts with a specific shard for the duration of the user or process session. This is the simplest technique to implement, and adds virtually zero overhead to overall performance, since the sharding decision is made only once per session. Applications which can benefit from this approach are often customer-centric, where all data for a given customer is contained in a single shard, and that is all the data that the customer requires.
Transaction-based sharding determines the shard by examining the first SQL Statement in a given database transaction. This is normally done by evaluating the "shard key" value used in the statement (such as an Order Number), and then directing all other statements in the transaction to the same shard.
Statement-based sharding is the most process intensive of all types, evaluating each individual SQL Statement to determine the appropriate shard to direct it to. Again, evaluation of the shard key value is required. This option is often desirable on high-volume, granular transactions, such as recording phone call records.

Determine the optimum method for sharding the data. This is another area that is highly variable, change from application to application. It is closely tied with the selection of the Database Shard Scheme described above. There are numerous methods for deciding how to shard your data, and its important to understand your transaction rates, table volumes, key distribution, and other characteristics of your application. This data is required to determine the optimum sharding strategy:

Shard by a primary key on a table. This is the most straightforward option, and easiest to map to a given application. However, this is only effective if your data is reasonably well distributed. For example, if you elected to shard by Customer ID (and this is a sequential numeric value), and most of your transactions are for new customers, very little if anything will be gained by sharding your database. On the other hand, if you can select a key that does adequately and naturally distribute your transactions, great benefits can be realized.
Shard by the modulus of a key value. This option works in a vast number of cases, by applying the modulus function to the key value, and distributing transactions based on the calculated value. In essence you can predetermine any number of shards, and the modulus function effectively distributes across your shards on a “round-robin” basis, creating a very even distribution of new key values.
Maintain a master shard index table. This technique involves using a single master table that maps various values to specific shards. It is very flexible, and meets a wide variety of application situations. However, this option often delivers lower performance as it requires an extra lookup for each sharded SQL Statement.

As you can see, there are many things to consider and many capabilities required in order to ensure that a Database Sharding implementation is successful and effective, delivering on its objectives of providing new levels of scalability and performance in a cost-effective manner.

When Database Sharding is Appropriate

Database Sharding is an excellent fit for many types of business applications, those with general purpose database requirements. It can also be used effectively for Data Warehousing applications, and as there are many available products and technologies to accomplish this, we will not focus on this element here.

The general purpose database requirements that are a fit for sharding include:

High-transaction database applications
Mixed workload database usage
- Frequent reads, including complex queries and joins
- Write-intensive transactions (CRUD statements, including INSERT, UPDATE, DELETE)
- Contention for common tables and/or rows
General Business Reporting
- Typical "repeating segment" report generation
- Some data analysis (mixed with other workloads)

To determine if Database Sharding is applicable to your specific application or environment, the most important thing to evaluate is how well your database schema lends itself to sharding. In essence, Database Sharding is a method of “horizontal” portioning, meaning that database rows (as opposed to columns) for a single schema table are distributed across multiple shards. To understand the characteristics of how well sharding fits a given situation, here are the important things to determine:

Identify all transaction-intensive tables in your schema.
Determine the transaction volume your database is currently handling (or is expected to handle).
Identify all common SQL statements (SELECT, INSERT, UPDATE, DELETE), and the volumes associated with each.
Develop an understanding of your "table hierarchy" contained in your schema; in other words the main parent-child relationships.
Determine the "key distribution" for transactions on high-volume tables, to determine if they are evenly spread or are concentrated in narrow ranges.

With this information, you can rapidly gain an assessment of the value and applicability of sharding to your application. As an example, here is a simple Bookstore schema showing how the data can be sharded:

Figure 3. Example Bookstore schema showing how data is sharded.

In the Bookstore example, the Primary Shard Table is the 'customer' entity. This is the table that is used to shard the data. The 'customer' table is the parent of the shard hierarchy, with the 'customer_order' and 'order_item' entities as child tables. The data is sharded by the 'customer.id' attribute, and all related rows in the child tables associated with a given 'customer.id' are sharded as well. The Global Tables are the common lookup tables, which have relatively low activity, and these tables are replicated to all shards to avoid cross-shard joins.

While this example is very basic, it does provide the basic considerations for determining how to shard a given database application. By using this evaluation approach, you can determine if sharding is applicable to your particular environment, and what benefits can be realized by implementing Database Sharding.

Create VHD using DISKPART

2012-11-22T18:15:00.000+05:30

Create Virtual Harddisk Using DISKPART

Open the Elevated Command Prompt with Administrator Privileges and type the following commands:

DISKPART

CREATE VDISK FILE="c:\win7\win7.vhd" MAXIMUM=20000
SELECT VDISK FILE="c:\win7\win7.vhd"
ATTACH VDISK
CREATE PARTITION PRIMARY
ASSIGN LETTER=X
FORMAT QUICK LABEL=Windows7
EXIT

This will create the VHD file of primary partition. You will see the newly attached disk in Disk Management with Drive Letter X:

Attaching and Detaching VHD in Windows 7

Right Click on My Computer and Click 'Manage' that will open up Computer Management, in that click on Disk Management. Just like previous part.

Then Right Click on Disk Management and select 'Attach VHD'. This will open new windows 'AttachVirtual Hard Disk'

Click on OK and that will attach the existing Virtual Hard Disk. Now, if you don't want to make write anything on the VHD, we will select the 'Read-only' check box.

And subsequently we will have the attached VHD in explorer.

How to Detach VHD?

To detach the VHD simply Right Click on the 'Disk 1' (Blue Color) and select 'Detach VHD'

After clicking on 'Detach VHD' you will be prompt you with 'Detach Virtual Hard Disk' message. Click on OK to detach. Also, if you want delete the VHD permanently you can select the Checkbox.

This way we have seen how can we create new VHDs, attach/detach existing VHDs using Disk Management and Diskpart utility.

Factory Method Design Pattern

2012-10-06T15:11:00.005+05:30

Factory Method

Intent

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Also Known As

Virtual Constructor

Motivation

Frameworks use abstract classes to define and maintain relationships between objects. A framework is often responsible for creating these objects as well.

Consider a framework for applications that can present multiple documents to the user. Two key abstractions in this framework are the classes Application and Document. Both classes are abstract, and clients have to subclass them to realize their application-specific implementations. To create a drawing application, for example, we define the classes DrawingApplication and DrawingDocument. The Application class is responsible for managing Documents and will create them as required—when the user selects Open or New from a menu, for example.

Because the particular Document subclass to instantiate is application-specific, the Application class can't predict the subclass of Document to instantiate—the Application class only knows when a new document should be created, not what kind of Document to create. This creates a dilemma: The framework must instantiate classes, but it only knows about abstract classes, which it cannot instantiate.

The Factory Method pattern offers a solution. It encapsulates the knowledge of which Document subclass to create and moves this knowledge out of the framework.

Application subclasses redefine an abstract CreateDocument operation on Application to return the appropriate Document subclass. Once an Application subclass is instantiated, it can then instantiate application-specific Documents without knowing their class. We call CreateDocument a factory method because it's responsible for "manufacturing" an object.

Applicability

Use the Factory Method pattern when

a class can't anticipate the class of objects it must create.
a class wants its subclasses to specify the objects it creates.
classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

Structure

Participants

Product (Document)

defines the interface of objects the factory method creates.

ConcreteProduct (MyDocument)

implements the Product interface.

Creator (Application)

declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object.
may call the factory method to create a Product object.

ConcreteCreator (MyApplication)

overrides the factory method to return an instance of a ConcreteProduct.

Collaborations

Creator relies on its subclasses to define the factory method so that it returns an instance of the appropriate ConcreteProduct.

Consequences

Factory methods eliminate the need to bind application-specific classes into your code. The code only deals with the Product interface; therefore it can work with any user-defined ConcreteProduct classes.

A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object. Subclassing is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution.

Here are two additional consequences of the Factory Method pattern:

Provides hooks for subclasses. Creating objects inside a class with a factory method is always more flexible than creating an object directly. Factory Method gives subclasses a hook for providing an extended version of an object.

In the Document example, the Document class could define a factory method called CreateFileDialog that creates a default file dialog object for opening an existing document. A Document subclass can define an application-specific file dialog by overriding this factory method. In this case the factory method is not abstract but provides a reasonable default implementation.

Connects parallel class hierarchies. In the examples we've considered so far, the factory method is only called by Creators. But this doesn't have to be the case; clients can find factory methods useful, especially in the case of parallel class hierarchies.

Parallel class hierarchies result when a class delegates some of its responsibilities to a separate class. Consider graphical figures that can be manipulated interactively; that is, they can be stretched, moved, or rotated using the mouse. Implementing such interactions isn't always easy. It often requires storing and updating information that records the state of the manipulation at a given time. This state is needed only during manipulation; therefore it needn't be kept in the figure object. Moreover, different figures behave differently when the user manipulates them. For example, stretching a line figure might have the effect of moving an endpoint, whereas stretching a text figure may change its line spacing.

With these constraints, it's better to use a separate Manipulator object that implements the interaction and keeps track of any manipulation-specific state that's needed. Different figures will use different Manipulator subclasses to handle particular interactions. The resulting Manipulator class hierarchy parallels (at least partially) the Figure class hierarchy:

The Figure class provides a CreateManipulator factory method that lets clients create a Figure's corresponding Manipulator. Figure subclasses override this method to return an instance of the Manipulator subclass that's right for them. Alternatively, the Figure class may implement CreateManipulator to return a default Manipulator instance, and Figure subclasses may simply inherit that default. The Figure classes that do so need no corresponding Manipulator subclass—hence the hierarchies are only partially parallel.

Notice how the factory method defines the connection between the two class hierarchies. It localizes knowledge of which classes belong together.

Implementation

Consider the following issues when applying the Factory Method pattern:

Two major varieties. The two main variations of the Factory Method pattern are (1) the case when the Creator class is an abstract class and does not provide an implementation for the factory method it declares, and (2) the case when the Creator is a concrete class and provides a default implementation for the factory method. It's also possible to have an abstract class that defines a default implementation, but this is less common.

The first case requires subclasses to define an implementation, because there's no reasonable default. It gets around the dilemma of having to instantiate unforeseeable classes. In the second case, the concrete Creator uses the factory method primarily for flexibility. It's following a rule that says, "Create objects in a separate operation so that subclasses can override the way they're created." This rule ensures that designers of subclasses can change the class of objects their parent class instantiates if necessary.

Parameterized factory methods. Another variation on the pattern lets the factory method create multiple kinds of products. The factory method takes a parameter that identifies the kind of object to create. All objects the factory method creates will share the Product interface. In the Document example, Application might support different kinds of Documents. You pass CreateDocument an extra parameter to specify the kind of document to create.

The Unidraw graphical editing framework [VL90] uses this approach for reconstructing objects saved on disk. Unidraw defines a Creator class with a factory method Create that takes a class identifier as an argument. The class identifier specifies the class to instantiate. When Unidraw saves an object to disk, it writes out the class identifier first and then its instance variables. When it reconstructs the object from disk, it reads the class identifier first.

Once the class identifier is read, the framework calls Create, passing the identifier as the parameter. Create looks up the constructor for the corresponding class and uses it to instantiate the object. Last, Create calls the object's Read operation, which reads the remaining information on the disk and initializes the object's instance variables.

A parameterized factory method has the following general form, where MyProduct and YourProduct are subclasses of Product:

class Creator{public: virtual Product* Create(ProductId);}; Product* Creator::Create (ProductId id) { if (id == MINE) return new MyProduct; if (id == YOURS) return new YourProduct; // repeat for remaining products... return 0;}

Overriding a parameterized factory method lets you easily and selectively extend or change the products that a Creator produces. You can introduce new identifiers for new kinds of products, or you can associate existing identifiers with different products.

For example, a subclass MyCreator could swap MyProduct and YourProduct and support a new TheirProduct subclass:

Product* MyCreator::Create (ProductId id) { if (id == YOURS) return new MyProduct; if (id == MINE) return new YourProduct; // N.B.: switched YOURS and MINE if (id == THEIRS) return new TheirProduct; return Creator::Create(id); // called if all others fail}

Notice that the last thing this operation does is call Create on the parent class. That's because MyCreator::Create handles only YOURS, MINE, and THEIRS differently than the parent class. It isn't interested in other classes. Hence MyCreator extends the kinds of products created, and it defers responsibility for creating all but a few products to its parent.

Language-specific variants and issues. Different languages lend themselves to other interesting variations and caveats.

Smalltalk programs often use a method that returns the class of the object to be instantiated. A Creator factory method can use this value to create a product, and a ConcreteCreator may store or even compute this value. The result is an even later binding for the type of ConcreteProduct to be instantiated.

A Smalltalk version of the Document example can define a documentClass method on Application. The documentClass method returns the proper Document class for instantiating documents. The implementation of documentClass in MyApplication returns the MyDocument class. Thus in class Application we have


clientMethod    document := self documentClass new.

documentClass
documentClass    self subclassResponsibility

In class MyApplication we have


documentClass    ^ MyDocument

which returns the class MyDocument to be instantiated to Application.

An even more flexible approach akin to parameterized factory methods is to store the class to be created as a class variable of Application. That way you don't have to subclass Application to vary the product.

Factory methods in C++ are always virtual functions and are often pure virtual. Just be careful not to call factory methods in the Creator's constructor—the factory method in the ConcreteCreator won't be available yet.

You can avoid this by being careful to access products solely through accessor operations that create the product on demand. Instead of creating the concrete product in the constructor, the constructor merely initializes it to 0. The accessor returns the product. But first it checks to make sure the product exists, and if it doesn't, the accessor creates it. This technique is sometimes called lazy initialization. The following code shows a typical implementation:

class Creator {public: Product* GetProduct();protected: virtual Product* CreateProduct();private: Product* _product;}; Product* Creator::GetProduct () { if (_product == 0) { _product = CreateProduct(); } return _product;}

Using templates to avoid subclassing. As we've mentioned, another potential problem with factory methods is that they might force you to subclass just to create the appropriate Product objects. Another way to get around this in C++ is to provide a template subclass of Creator that's parameterized by the Product class:


class


Creator {public:    virtual Product* CreateProduct() = 0;};template 
template 
class StandardCreator: public Creator {public:    virtual Product* CreateProduct();};template 
template 
Product* StandardCreator::CreateProduct () {    return new TheProduct;}

With this template, the client supplies just the product class—no subclassing of Creator is required.


class MyProduct : public Product {public:    MyProduct();    // ...};



StandardCreator myCreator;
StandardCreator myCreator;

Naming conventions. It's good practice to use naming conventions that make it clear you're using factory methods. For example, the MacApp Macintosh application framework [App89] always declares the abstract operation that defines the factory method as Class* DoMakeClass(), where Class is the Product class.

Sample Code

The function CreateMaze () builds and returns a maze. One problem with this function is that it hard-codes the classes of maze, rooms, doors, and walls. We'll introduce factory methods to let subclasses choose these components.

First we'll define factory methods in MazeGame for creating the maze, room, wall, and door objects:


class MazeGame {
public:
    Maze* CreateMaze();
 // factory methods:
     virtual Maze* MakeMaze() const
        { return new Maze; }
    virtual Room* MakeRoom(int n) const
        { return new Room(n); }
    virtual Wall* MakeWall() const
        { return new Wall; }
    virtual Door* MakeDoor(Room* r1, Room* r2) const
        { return new Door(r1, r2); }
};

Each factory method returns a maze component of a given type. MazeGame provides default implementations that return the simplest kinds of maze, rooms, walls, and doors.

Now we can rewrite CreateMaze to use these factory methods:


Maze* MazeGame::CreateMaze () {
    Maze* aMaze = MakeMaze();
    Room* r1 = MakeRoom(1);
    Room* r2 = MakeRoom(2);
    Door* theDoor = MakeDoor(r1, r2);
    aMaze->AddRoom(r1);
    aMaze->AddRoom(r2);
    r1->SetSide(North, MakeWall());
    r1->SetSide(East, theDoor);
    r1->SetSide(South, MakeWall());
    r1->SetSide(West, MakeWall());
    r2->SetSide(North, MakeWall());
    r2->SetSide(East, MakeWall());
    r2->SetSide(South, MakeWall());
    r2->SetSide(West, theDoor);
    return aMaze;
}

Different games can subclass MazeGame to specialize parts of the maze. MazeGame subclasses can redefine some or all of the factory methods to specify variations in products. For example, a BombedMazeGame can redefine the Room and Wall products to return the bombed varieties:


class BombedMazeGame : public MazeGame {
public:
    BombedMazeGame();
    virtual Wall* MakeWall() const
        { return new BombedWall; }
    virtual Room* MakeRoom(int n) const
        { return new RoomWithABomb(n); }
};

An EnchantedMazeGame variant might be defined like this:


class EnchantedMazeGame : public MazeGame {
public:
    EnchantedMazeGame();
    virtual Room* MakeRoom(int n) const
        { return new EnchantedRoom(n, CastSpell()); }
    virtual Door* MakeDoor(Room* r1, Room* r2) const
        { return new DoorNeedingSpell(r1, r2); }
protected:
    Spell* CastSpell() const;
};

Known Uses

Factory methods pervade toolkits and frameworks. The preceding document example is a typical use in MacApp and ET++ [WGM88]. The manipulator example is from Unidraw.

Class View in the Smalltalk-80 Model/View/Controller framework has a method defaultController that creates a controller, and this might appear to be a factory method [Par90]. But subclasses of View specify the class of their default controller by defining defaultControllerClass, which returns the class from which defaultController creates instances. So defaultControllerClass is the real factory method, that is, the method that subclasses should override.

A more esoteric example in Smalltalk-80 is the factory method parserClass defined by Behavior (a superclass of all objects representing classes). This enables a class to use a customized parser for its source code. For example, a client can define a class SQLParser to analyze the source code of a class with embedded SQL statements. The Behavior class implements parserClass to return the standard Smalltalk Parser class. A class that includes embedded SQL statements overrides this method (as a class method) and returns the SQLParser class.

The Orbix ORB system from IONA Technologies [ION94] uses Factory Method to generate an appropriate type of proxy (see Proxy ) when an object requests a reference to a remote object. Factory Method makes it easy to replace the default proxy with one that uses client-side caching, for example.

Related Patterns

Abstract Factory is often implemented with factory methods. The Motivation example in the Abstract Factory pattern illustrates Factory Method as well.

Factory methods are usually called within Template Methods (325). In the document example above, NewDocument is a template method.

Prototypes (117) don't require subclassing Creator. However, they often require an Initialize operation on the Product class. Creator uses Initialize to initialize the object. Factory Method doesn't require such an operation.

Facade Design Pattern

2012-10-06T14:42:00.001+05:30

Facade

Intent

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Motivation

Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.

Consider for example a programming environment that gives applications access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder that implement the compiler. Some specialized applications might need to access these classes directly. But most clients of a compiler generally don't care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low-level interfaces in the compiler subsystem only complicate their task.

To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class. This class defines a unified interface to the compiler's functionality. The Compiler class acts as a facade: It offers clients a single, simple interface to the compiler subsystem. It glues together the classes that implement compiler functionality without hiding them completely. The compiler facade makes life easier for most programmers without hiding the lower-level functionality from the few that need it.

Applicability

Use the Facade pattern when

you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.
there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.
you want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

Structure

Participants

Facade (Compiler)

knows which subsystem classes are responsible for a request.
delegates client requests to appropriate subsystem objects.

subsystem classes (Scanner, Parser, ProgramNode, etc.)

implement subsystem functionality.
handle work assigned by the Facade object.
have no knowledge of the facade; that is, they keep no references to it.

Collaborations

Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem object(s). Although the subsystem objects perform the actual work, the facade may have to do work of its own to translate its interface to subsystem interfaces.
Clients that use the facade don't have to access its subsystem objects directly.

Consequences

The Facade pattern offers the following benefits:

It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use.
It promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting its clients. Facades help layer a system and the dependencies between objects. They can eliminate complex or circular dependencies. This can be an important consequence when the client and the subsystem are implemented independently.

Reducing compilation dependencies is vital in large software systems. You want to save time by minimizing recompilation when subsystem classes change. Reducing compilation dependencies with facades can limit the recompilation needed for a small change in an important subsystem. A facade can also simplify porting systems to other platforms, because it's less likely that building one subsystem requires building all others.

It doesn't prevent applications from using subsystem classes if they need to. Thus you can choose between ease of use and generality.

Implementation

Consider the following issues when implementing a facade:

Reducing client-subsystem coupling. The coupling between clients and the subsystem can be reduced even further by making Facade an abstract class with concrete subclasses for different implementations of a subsystem. Then clients can communicate with the subsystem through the interface of the abstract Facade class. This abstract coupling keeps clients from knowing which implementation of a subsystem is used.

An alternative to subclassing is to configure a Facade object with different subsystem objects. To customize the facade, simply replace one or more of its subsystem objects.

Public versus private subsystem classes. A subsystem is analogous to a class in that both have interfaces, and both encapsulate something—a class encapsulates state and operations, while a subsystem encapsulates classes. And just as it's useful to think of the public and private interface of a class, we can think of the public and private interface of a subsystem.

The public interface to a subsystem consists of classes that all clients can access; the private interface is just for subsystem extenders. The Facade class is part of the public interface, of course, but it's not the only part. Other subsystem classes are usually public as well. For example, the classes Parser and Scanner in the compiler subsystem are part of the public interface.

Making subsystem classes private would be useful, but few object-oriented languages support it. Both C++ and Smalltalk traditionally have had a global name space for classes. Recently, however, the C++ standardization committee added name spaces to the language [Str94], which will let you expose just the public subsystem classes.

Sample Code

Let's take a closer look at how to put a facade on a compiler subsystem.

The compiler subsystem defines a {BytecodeStream} class that implements a stream of Bytecode objects. A Bytecode object encapsulates a bytecode, which can specify machine instructions. The subsystem also defines a Token class for objects that encapsulate tokens in the programming language.

The Scanner class takes a stream of characters and produces a stream of tokens, one token at a time.

class Scanner {
public:
    Scanner(istream&);
    virtual ~Scanner();
     virtual Token& Scan();
private:
    istream& _inputStream;
};

The class Parser uses a ProgramNodeBuilder to construct a parse tree from a Scanner's tokens.

class Parser {
public:
    Parser();
    virtual ~Parser();
     virtual void Parse(Scanner&, ProgramNodeBuilder&);
};

Parser calls back on ProgramNodeBuilder to build the parse tree incrementally. These classes interact according to the Builder pattern.

class ProgramNodeBuilder {

public:

    ProgramNodeBuilder();
     virtual ProgramNode* NewVariable(
        const char* variableName
    ) const;
     virtual ProgramNode* NewAssignment(
        ProgramNode* variable, ProgramNode* expression
    ) const;
     virtual ProgramNode* NewReturnStatement(
        ProgramNode* value
    ) const;
     virtual ProgramNode* NewCondition(
        ProgramNode* condition,
        ProgramNode* truePart, ProgramNode* falsePart
    ) const;
    // ...
     ProgramNode* GetRootNode();
private:
    ProgramNode* _node;
};

The parse tree is made up of instances of ProgramNode subclasses such as StatementNode, ExpressionNode, and so forth. The ProgramNode hierarchy is an example of the Composite pattern. ProgramNode defines an interface for manipulating the program node and its children, if any.

class ProgramNode {public:
    // program node manipulation
    virtual void GetSourcePosition(int& line, int& index);
    // ...
     // child manipulation
    virtual void Add(ProgramNode*);
    virtual void Remove(ProgramNode*);
    // ...
     virtual void Traverse(CodeGenerator&);
protected:
    ProgramNode();
};

The Traverse operation takes a CodeGenerator object. ProgramNode subclasses use this object to generate machine code in the form of Bytecode objects on a BytecodeStream. The class CodeGenerator is a visitor (see Visitor ).

class CodeGenerator {
public:
    virtual void Visit(StatementNode*);
    virtual void Visit(ExpressionNode*);
    // ...
protected:
    CodeGenerator(BytecodeStream&);
protected:
    BytecodeStream& _output;
};

CodeGenerator has subclasses, for example, StackMachineCodeGenerator and RISCCodeGenerator, that generate machine code for different hardware architectures.

Each subclass of ProgramNode implements Traverse to call Traverse on its child ProgramNode objects. In turn, each child does the same for its children, and so on
recursively. For example,ExpressionNode defines Traverse as follows:

void ExpressionNode::Traverse (CodeGenerator& cg) {
    cg.Visit(this);
     ListIterator i(_children);
     for (i.First(); !i.IsDone(); i.Next()) {
        i.CurrentItem()->Traverse(cg);
    }
}

The classes we've discussed so far make up the compiler subsystem. Now we'll introduce a Compiler class, a facade that puts all these pieces together. Compiler provides a simple interface for compiling source and generating code for a particular machine.

class Compiler {
public:
    Compiler();
     virtual void Compile(istream&, BytecodeStream&);
};
void Compiler::Compile (
    istream& input, BytecodeStream& output
) {
    Scanner scanner(input);
    ProgramNodeBuilder builder;
    Parser parser;
     parser.Parse(scanner, builder);
     RISCCodeGenerator generator(output);
    ProgramNode* parseTree = builder.GetRootNode();
    parseTree->Traverse(generator);
}

This implementation hard-codes the type of code generator to use so that programmers aren't required to specify the target architecture. That might be reasonable if there's only ever one target architecture. If that's not the case, then we might want to change the Compiler constructor to take a CodeGenerator parameter. Then programmers can specify the generator to use when they instantiate Compiler. The compiler facade can parameterize other participants such as Scanner and ProgramNodeBuilder as well, which adds flexibility, but it also detracts from the Facade pattern's mission, which is to simplify the interface for the common case.

Known Uses

The compiler example in the Sample Code section was inspired by the ObjectWorks\Smalltalk compiler system [Par90].

In the ET++ application framework [WGM88], an application can have built-in browsing tools for inspecting its objects at run-time. These browsing tools are implemented in a separate subsystem that includes a Facade class called "ProgrammingEnvironment." This facade defines operations such as InspectObject and InspectClass for accessing the browsers.

An ET++ application can also forgo built-in browsing support. In that case, ProgrammingEnvironment implements these requests as null operations; that is, they do nothing. Only the ETProgrammingEnvironment subclass implements these requests with operations that display the corresponding browsers. The application has no knowledge of whether a browsing environment is available or not; there's abstract coupling between the application and the browsing subsystem.

The Choices operating system [CIRM93] uses facades to compose many frameworks into one. The key abstractions in Choices are processes, storage, and address spaces. For each of these abstractions there is a corresponding subsystem, implemented as a framework, that supports porting Choices to a variety of different hardware platforms. Two of these subsystems have a "representative" (i.e., facade). These representatives are FileSystemInterface (storage) and Domain (address spaces).

For example, the virtual memory framework has Domain as its facade. A Domain represents an address space. It provides a mapping between virtual addresses and offsets into memory objects, files, or backing store. The main operations on Domain support adding a memory object at a particular address, removing a memory object, and handling a page fault.

As the preceding diagram shows, the virtual memory subsystem uses the following components internally:

MemoryObject represents a data store.
MemoryObjectCache caches the data of MemoryObjects in physical memory. MemoryObjectCache is actually a Strategy that localizes the caching policy.
AddressTranslation encapsulates the address translation hardware.

The RepairFault operation is called whenever a fault interrupt occurs. The Domain finds the memory object at the address causing the fault and delegates the RepairFault operation to the cache associated with that memory object. Domains can be customized by changing their components.

Related Patterns

Abstract Factory can be used with Facade to provide an interface for creating subsystem objects in a subsystem-independent way. Abstract Factory can also be used as an alternative to Facade to hide platform-specific classes.

Mediator is similar to Facade in that it abstracts functionality of existing classes. However, Mediator's purpose is to abstract arbitrary communication between colleague objects, often centralizing functionality that doesn't belong in any one of them. A mediator's colleagues are aware of and communicate with the mediator instead of communicating with each other directly. In contrast, a facade merely abstracts the interface to subsystem objects to make them easier to use; it doesn't define new functionality, and subsystem classes don't know about it.

Usually only one Facade object is required. Thus Facade objects are often Singletons.

HTML5 Browser Compatibility

2012-09-13T15:58:00.000+05:30

Over the past few years, HTML5 has gone from mythical creature to vivid reality and has taken its share of hits from skeptics and experts alike as to its readiness and viability. Now, in 2012, HTML5 is ready for use with all modern browsers, including IE9. It has also been developed to gracefully degrade, even without help from JavaScript or CSS resets.

Even still, you may be concerned about providing full backwards compatibility, or unsure of what will work in one browser and not another. HTML5 has commonly been blamed for the issues presented by jQuery and CSS3, both newer technologies and standards evolving alongside HTML5, but not actually a part of it. To get a grip on HTML5 browser compatibility, you must first understand the way browsers look at each of these languages.

HTML5 is a revision of the HTML markup specification, containing several best practices and rules by which browser makers and web developers can find common ground. It was first drafted and accepted by the W3C in 2006, closing in 2009 and deemed ready for use, with full candidate approval likely this year. It contains new layout elements, which you have likely seen, such as

Both of these specifications aim to get web development to a more semantic and meaningful place in terms of producing a set of easy to understand standards that are designed to work well with one another. Because HTML5 is not tied to CSS3, it can be used in a wide variety of applications without suffering the compatibility issues some cutting-edge CSS3 selectors may pose.

Coming to Terms

We’ve all heard the terms several times, but the concept of graceful degradation, progressive enhancement, backwards compatibility and browser support can sound like total nonsense if you are new to design or focus on front-end design most of the time. Fortunately, much has been written on these topics and a few very useful tools have been created to make it easier for us to cope. Let’s start with the basics of what these things are.

Is Browser Compatibility That Important?

I’ve seen designers argue that there is no point in spending unneeded energy supporting outdated browsers. Why bother when modern webkit browsers account for nearly 75% of all browser usage? Unfortunately, it’s hard to convince clients that want to reach the most viewers possible or support an audience who depend on older technology. A large part of the world still lacks the financial resources or technical ability to upgrade. You must also consider users with accessibility needs. HTML5 and CSS3 solve a huge compatibility gap by attempting to standardize how browsers display the web which, in time, will reduce the additional effort spent on crafting compatibility solutions into design.

Graceful Degradation vs Progressive Enhancement

Opera’s Christian Heilmann defines graceful degredation as “providing an alternative version of your functionality or making the user aware of shortcomings of a product as a safety measure to ensure that the product is usable.” Put into practice, this would encompass providing fallback support in the form of conditional statements for IE, special JavaScripts or Flash audio and video where new HTML5 elements are used.

Backwards Compatibility is a similar term meaning much the same thing, referring to an older browser’s ability to display your application or website, or accommodate it’s functionality.

In comparison, Progressive Enhancement is a process that starts with a baseline of usable functionality, and then increases the richness of the user experience through various testing methods. Therefore, it is the initiative while graceful degradation is the interim solution.

Browser Compatibility Now

As previously mentioned, the new HTML5 tags are supported in all modern browsers. Where it gets complicated is when you begin to implement HTML5 native browser features and canvas elements, many of which still need JavaScript to be fully supported. Many CSS3 selectors are also either dependent on JavaScript or not safe for mobile browsers.

HTML5 Elements Support:

Internet Explorer 9 & 10
Firefox 7 and higher
Chrome 14 and higher
Safari 5 and higher
Opera 11 and higher
Mobile Safari 3.2 and higher
Opera Mobile 5 and higher
Android 2.1 and higher

Below are a few more resources to help you get an idea of where the web is at with CSS3 and HTML5. Add these to your toolkit to save yourself time and frustration when working on your next HTML5 project.

FindMeByIP

HTML5 Canvas shares the same modern browser support for graphic rendering as HTML5 elements, which is great news if you plan to implement a canvas slideshow, text effects or Canvas animations into your app or website. FindMyByIP features a handful of at-a-glance charts for checking specific HTML5 and CSS3 features against various browsers, although it does not offer solutions for what to do if something isn’t supported. If you need to check advanced features, APIs or JavaScript features in addition to HTML5 and CSS3, check out caniuse.com.

HTML5 Please

After checking the chart at FindMeByIP, or if you have a specific feature in mind, head over to HTML5Please to lookup the element or selector and get straightforward advice on whether you should use it or not, and what can be done to help provide graceful degradation via polyfills (additional scripts).

Browsershots

This website allows you to test a live website in just about every browser and OS combination possible, giving you a screenshot of each selection to give you an idea of how your site will render in various browsers. Browsershots won’t tell you what markup, scripts or styles are incompatible, but the visual cues allow you to quickly pinpoint problem areas and begin planning for a solution.

Spoon

Similar to Browsershots, Spoon is a free service for testing websites across a wide variety of browsers, including mobile browsers and release candidates such as Firefox Aurora and Chrome 18. Your site is loaded up in a virtual browser rather than returned in a screenshot, so you are better equipped to debug.

Getting it Together

So now that the difference between HTML5 and CSS3 has been established, and we better understand why compatibility is important and how to test for it, let’s take a look at how to accomplish it.

HTML5 Shiv

Taking advantage of the new capabilities of HTML5 and CSS3 can mean sacrificing control over the experience in older browsers. HTML5 shivs/shims/bims/bams/whatevers are scripts you can use to make up for the lack of feature detection in older browsers, allowing your cutting-edge websites and applications to work exactly right no matter what browser or device your visitors use.

Implementing one of these scripts into and HTML5 website is pretty easy. All it takes is linking the script in the document head:

<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>

Note that we no longer need the "type=" attribute, which is depreciated in HTML5.

Script Resources:

CSS Reset

The pioneer of the CSS Reset, Eric Meyer explains,"The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on. The general reasoning behind this was discussed in a May 2007 post, if you’re interested. Reset styles quite often appear in CSS frameworks, and the original “meyerweb reset” found its way into poular CSS frameworks such as Blueprint, among others. " Implementing the reset provides fallbacks for styles and selectors that aren’t recognized by older browsers. You can plop them right into the beginning of your main stylesheet, use @import, or link them in the document head above your main stylesheet.

CSS Reset Resources:

Eric Meyer’s CSS Reset →
HTML5Reset.org →
HTML5 Doctor Reset → (Super HTML5ified by Richard Clark)

IE Conditional Tags

HTML5 enabling scripts and CSS reset stylesheets are only needed by older browsers, so there is no point in loading them for everyone. Thankfully, Internet Explorer supports conditional tags, which can be used to detect a specific version of IE to feed it a special stylesheet, script or message. For example:

<!--[if IE 6]>

<p>I am truly sorry for your loss of experience.

May you be delivered into the arms of a webkit browser soon.</p> 

<![endif]-->

<link rel="stylesheet" href="reset.css" />

<link rel="stylesheet" href="style.css" />

<!--[if lt IE 9]>

<script src="js/libs/modernizr-2.0.6.min.js"></script>

<![endif]-->

Conditional statements can take a number of operators to fine-tune control. In my above example, "if lt IE 9" means "if less than Internet Explorer 9," meaning any version of IE lower than 9 will benefit from the script.

Learn More:

Visual Designing with HTML5

Browser compatibility is just one of the many complex factors involved in hand-coding your own websites that can be taken care of with the right tools. The new HTML5 Website Builder from Wix is a completely free online tool for designing valid, rich HTML5 websites using a visual drag-and-drop editor, giving you the power of complete creative freedom. It is extremely easy to master and comes with an extensive library of animations, widgets and graphics to get you started designing with HTML5 right now. You can rapidly design and style any layout from the ground up and add HTML5 audio, video, slideshows and more without extensive and time-consuming hand-coding. Check it out here.

Conclusion

Hopefully this introduction to HTML5 and browser compatibility has provided you with a starting outline for designing a better experience for your visitors and clients. The HTMl5 specification is in the home stretch and adoption is expected to grow by leaps and bounds over the next few years, but there will always be a percentage out there somewhere that need consideration. As the web evolves, you can be sure that the need for graceful degradation and progressive enhancement will never go away, the techniques and requirements will simply change.

Is there something I missed? Tell us about it in the comments!