What are Entity Relationship Diagrams

Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.

Entity Relationship Diagram Notations


Entity
An entity is an object or concept about which you want to store information.



Weak Entity
A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.



Key attribute
A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.


Multivalued attribute
A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.


Derived attribute
A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.


Relationships
Relationships illustrate how two entities share information in the database structure.



Cardinality
Cardinality specifies how many instances of an entity relate to one instance of another entity.

Ordinality is also closely linked to cardinality. While cardinality specifies the occurences of a relationship, ordinality describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.


Recursive relationship
In some cases, entities can be self-linked. For example, employees can supervise other employees.

What is Scalability Testing

Definition

A test designed to prove that both the functionality and the performance of a system will scale up to meet specified requirements.

Comment

Generally, load and stress tests should continue to the point where the system fails and its scalability is proven.

Measurements should be taken during the load and stress testing activities to ensure that the most information possible is available to make a decision on the scalability of the system. The more information that is available, the less risk there is of an unexpected event happening in the future that could turn out to be costly

Difference between Layer and Tier

Layer and Tier are really two very different things:

Layers are a means of logical separation, and are an architectural pattern to separate concerns. Typical layers are the storage / data layer, the data access layer, a business logic layer, and a presentation layer. When deploying an application, these layers might exist either on one machine, or on multiple machines.

When architecting the layers of an application, one must consider various factors:

What is this layer responsible for?
Will this layer translate to a tier at any point?
Are other applications expected to communicate with this layer?
What are the dependencies for this layer?
Tiers are the physical separation of an application. Typically, a regular web application will have a data tier which maps to the database, a business and presentation tier (potentially together) that map to the underlying business logic and web pages respectively, and a front-end tier that maps to the browser. There are scenarios wherein the business and presentation layers are split, so the business layer components reside on a separate node, and the web application itself resides on another node. Tiers necessarily imply layers, but not vice versa.

While layer decisions are driven primarily by separation of concerns, a tiering decision is driven differently. In fact decisions around tiers need to be well thought-out, especially since physical tiers may result in a performance degrade, due to network latency, and marshalling / unmarshalling overheads. For the most part, having the data sit in a separate tier on a database server is fairly well accepted, but the decision of whether or not to separate web pages into a tier separate from business logic components is a question that is often debated. A few points that support this separation are:

If the web server is expected to serve up a large amount of static content, it is more feasible to scale out the web servers independent of the business logic processing, and hence keep them on separate tiers.
If the processing of the businss logic requires a significant amount of processing, and this acts as a bottleneck for the rest of the web page processing, then it is more feasible to scale out the application servers independent of the web servers, and hence keep them on separate tiers.
If the functionality encapsulated by the business logic components is expected to be consumed by clients other than the presentation layer, then it is better to have these hosted on a separate tier, and front-end it with a web service / WCF facade.
If there is a need to have more security for the business functionality, then it is better to host the businss logic components in a separate tier, and separate it from the web server using a firewall.
If, on the other hand, the intent is only to scale out, without a deep need to scale out business and presentation tiers independently, then keeping them in one tier is better: Consider the case when I have five machines, and I use all five to host both my presentation and business tiers. In comparison, if I use two of these for my presentation tier, and three for my business tier, then I still have the same compute power, but now have to contend with the additional overhead of marshal/unmarshal, and latency. I’m hence better off with the single tier in such a case.

All said though, while a physical separation improves scale-out capability and security, it does impose overheads due to the network. The design for tiers needs to take into account the communication between tiers – too chatty, and performance degrades rapidly. The choice of protocol is equally important – the protocol of communication should be the most lightweight, and be as native as possible – so if both the web pages and the business logic components are built on the .Net stack, then a NetTcp binding is more suitable than a Http-based binding.

Google App Engine

Run web apps on Google's infrastructure. http://code.google.com/appengine/

HOW TO ADD CAPTCHA TO BLOGGER.COM BLOGS TO MINIMIZE COMMENT SPAM?

To start, log in to your blogger.com account and click on the "Settings" tab. You'll see a top nav menu like this:
Click on the "Comments" sub-menu and you'll see a pile of different options, with the one you want about 2/3 of the way down the screen:
Select "Yes" here, choose "Save Settings", and you'll now have word capture enabled on your comments and that should, almost like magic, either eliminate your comment spam completely or at least reduce it to an easily manageable trickle of annoyance rather than a tsunami of pain.
Here's how it'll end up looking once you have everything configured:
By the way, if you hear people talk about captcha or comment captcha this is what they're talking about, even if the Blogger folk (who are, of course, owned by Google) refer to it in their interface as "word verification".

Good code snippets for Java Script, HTML, PHP, CSS, Ruby and Objective C

we can find some good code snippets here.. for Java Script, HTML, PHP, CSS, Ruby and Objective C!

http://snipplr.com/popular/.. 

What is cloud computing?

Before cloud computing

Traditional business applications—like those from SAP, Microsoft, and Oracle—have always been too complicated and expensive. They need a data center with office space, power, cooling, bandwidth, networks, servers, and storage. A complicated software stack. And a team of experts to install, configure, and run them. They need development, testing, staging, production, and failover environments.

When you multiply these headaches across dozens or hundreds of apps, it’s easy to see why the biggest companies with the best IT departments aren’t getting the apps they need. Small businesses don’t stand a chance.

Cloud-computing: a better way

Cloud computing is a better way to run your business. Instead of running your apps yourself, they run on a shared data center. When you use any app that runs in the cloud, you just log in, customize it, and start using it. That’s the power of cloud computing.

Businesses are running all kinds of apps in the cloud these days, like CRM, HR, accounting, and custom-built apps. Cloud-based apps can be up and running in a few days, which is unheard of with traditional business software. They cost less, because you don’t need to pay for all the people, products, and facilities to run them. And, it turns out they’re more scalable, more secure, and more reliable than most apps. Plus, upgrades are taken care of for you, so your apps get security and performance enhancements and new features—automatically.

The way you pay for cloud-based apps is also different. Forget about buying servers and software. When your apps run in the cloud, you don’t buy anything. It’s all rolled up into a predictable monthly subscription, so you only pay for what you actually use.

Finally, cloud apps don’t eat up your valuable IT resources, so your CFO will love it. This lets you focus on deploying more apps, new projects, and innovation.

The bottom line: Cloud computing is a simple idea, but it can have a huge impact on your business.

Simple way to install the useful software

Simple way to install the useful software --
http://www.howtogeek.com/howto/4774/getvolery-makes-installing-software-incredibly-simple/

https://getvolery.com/