5 Open Source Tools for Web Developers

There’s always something new in open source software. One trend is the sheer volume of projects surrounding JavaScript and Web development.

Courtesy of Datamation here’s five open source development tools for Web developers:

1. Bootstrap

First released by Twitter in 2011, Bootstrap is a front-end framework for Web development that aims to speed the development process. It takes a mobile-first approach and compiles code to pure CSS. Operating System: OS Independent

2. Brackets

This Adobe project is currently one of the most popular on GitHub, though it’s still a preview release. Brackets is a code editor built with Web technologies for developers who are working in Web technologies. Operating System: OS Independent

3. CodeMirror

CodeMirror is a browser-based text editor. Basically, it allows Website developers to embed a code editor in their sites, which is useful if you’re creating a site that offers programming tutorials. In addition to desktop browsers, it also works with many mobile browsers. Operating System: OS Independent

4. Ember.js

There are a lot of JavaScript Web development frameworks out there—Ember calls itself “a framework for creating ambitious Web applications. It aims to make developers more productive immediately. Operating System: OS Independent

5. ZURB Foundation

One of the most popular projects on GitHub, Foundation humbly proclaims itself “The most advanced responsive front-end framework in the world.” With it, web developers can quickly create sites that automatically adjust for the size and type of device being used for access. Operating System: OS Independent

Event Phases in Javascript

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).

http://wp.me/a3Q2qX-25

Demo: http://jsbin.com/exezex/4/edit

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<div> element, and the user actually clicks on a <p> element in the div, then the <p> element will become the event target. The fact that events “bubble” means that you are able to listen for clicks on the <div> (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.

Tuple in C# 4.0

Tuple in C# 4.0

More…

Comparing tuples…

Tuple<int, int> t1 = Tuple.Create(3, 9);
Tuple<int, int> t2 = Tuple.Create(3, 9);
Tuple<int, int> t3 = Tuple.Create(9, 3);
Tuple<int, int> t4 = Tuple.Create(9, 4);

Console.WriteLine("t1 = t2 : {0}", t1.Equals(t2)); //true
Console.WriteLine("t1 = t2 : {0}", t1 == t2); //false
Console.WriteLine("t1 = t3 : {0}", t1.Equals(t3)); // false

Console.WriteLine("t1 < t3 : {0}", ((IComparable)t1).CompareTo(t3) < 0); //true
Console.WriteLine("t3 < t4 : {0}", ((IComparable)t3).CompareTo(t4) < 0); //true

A Programming Blog

A Tuple in C# is an ordered sequence, means each object being of a specific type. It is introduced in C# 4.0 with dynamic programming. It can be useful when returning more than one value from a method.

A Tuple has many items. Each item can have any data type. The Tuple class provides a unified syntax for creating objects with typed fields.

Visual studio provides the intellisense for tuple object depends upon the data type of the item.

Methods

A Tuple can be instantiated in two ways:

1. Constructor

2. Static method

Tuples are commonly used in four ways:

1. To represent a single set of data. For example, a tuple can represent a database record, and its components can represent individual fields of the record.

2. To provide easy access to, and manipulation of, a data set.

3. To return multiple values from a method without using out parameters.

View original post 22 more words

WebConfig – Forms authentication timeout vs sessionState timeout [Asp .Net]

The Forms Authentication Timeout value sets the amount of time in minutes that the authentication cookie is set to be valid, meaning, that after value number of minutes, the cookie will expire and the user will no longer be authenticated i.e., he will be redirected to the login page automatically. The slidingExpiration=true value is basically saying that after every request made, the timer is reset and as long as the user makes a request within the timeout value, he will continue to be authenticated.

If you set slidingExpiration=false the authentication cookie will expire after value number of minutes regardless of whether the user makes a request within the timeout value or not.

Example:

 <authentication mode="Forms">
 <forms loginUrl="~/Auth/SignOn.aspx" timeout="40" slidingExpiration="true" />
</authentication>

The SessionState timeout value sets the amount of time a Session State provider is required to hold data in memory (or whatever backing store is being used, SQL Server, OutOfProc, etc) for a particular session. For example, if you put an object in Session using the value in your example, this data will be removed after 30 minutes. The user may still be authenticated but the data in Session may no longer be present. The Session Timeout value is always reset after every request.

Example:

 <sessionState timeout="30" />

A note about ‘undefined’ in JavaScript

It turns out that undefined is not a JavaScript keyword, instead undefined is a global variable, which in browsers is defined as window.undefined.

It is not uncommon to see code that tests if a variable is undefined like this:

if (someObject.x === undefined) {
    // do something
}

Which is the same as writing

if (someObject.x === window.undefined) {
    // do something
}

If by some chance your window.undefined variable is modified then checks for undefined like this will fail. No sane developer would ever do this intentionally, but it may happen by accident causing hard to find bugs, like this:

var o = {};
window[o.name] = 'unknown'; // BLAM!, window.undefined is now a string

A better way to test for undefined is to use the typeof operator. Typeof an undefined variable will always return the string ‘undefined’.

// Good way to test for undefined
if (typeof someObject.x === 'undefined') {
    // do something
}