Security mechanism in Chrome OS and Browser

Security mechanism in Chrome OS and Browser

Why I hate VB now even it was my native language once…

I started coding in VB4 language and did a lot of coding on VB 6 for many years. Those days, VB was my native language. I was fond of it. I loved it. I used to think in VB

But when I learnt JAVA and then C#, I never VB again. C# is really amazing.

There are a couple of reasons I do not use VB -

1. VB is verbose
2. The intellisense refuses to "let go" unless I tap the Escape key
3. Syntax highlighting sucks. In C#, all types are highlighted - in VB, only intrinsic types are highlighted.
4. It's VB.
5. There are no automatic code formatting options like we get with C#

But still I know there are a couple of things that can be better done in VB.net.

Structured Analysis vs Object Oriented Analysis

Structured Analysis and Object Oriented Analysis are different techniques of developing a computer system.

Structured Analysis

In Structured Analysis, the focus is only on process and procedures.
Modeling techniques used in it are DFD(Data Flow Diagram), Flowcharts etc.
This approach is old and is not preferred

Object Oriented Analysis

Whereas in Object Oriented Analysis, the focus is more on capturing the real world objects in the current scenario that are of importance to the system. [2] It stresses more on data structure and less on procedural structure. Without actually identifying objects, what are you going to interact with, and whose state will you change. In this approach, objects are identified, their relationships among each other, possible states that each object can be in, and finally how all objects collaborate with each other to achieve a broader system goal are identified.
Modeling techniques used in it are UML(Unified modeling Language), that can present both structural and behavioural/procedural aspect of the system. UML includes Class Diagram, State Diagram, Use case diagram, Sequence Diagram, etc.
Using this approach keeps your system more maintainable and reusable, and is a common choice nowadays

 

References

1. System Analysis and Design, Fifth Edition. Author: Shelly Cashman Rosenblatt. Pg20
2. Object Oriented Modeling and Design with UML, Second Edition. Author: Blaha Rumbaugh

Amazon Elastic Compute Cloud (Amazon EC2)

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.

Amazon EC2’s simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon’s proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change. Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use. AmazonEC2 provides developers the tools to build failure resilient applications and isolate themselves from common failure scenarios.

Windows API Code Pack for Microsoft .NET Framework

Windows API Code Pack for Microsoft .NET Framework 


This provides a source code library that can be used to access some features of Windows 7 and Windows Vista from managed code. These Windows features are not available to developers today in the .NET Framework.

The features of the library includes:

• Windows 7 Taskbar
• Jump Lists, Icon Overlay, Progress Bar, Tabbed Thumbnails, and Thumbnail Toolbars
• Windows Shell
• Windows 7 Libraries
• Windows Shell Search API support
• Explorer Browser Control
• A hierarchy of Shell Namespace entities
• Windows Shell property system
• Drag and Drop for Shell Objects
• Windows Vista and Windows 7 Common File Dialogs, including custom controls
• Known Folders and non-file system containers
• Shell Object Watcher
• Shell Extensions API support
• DirectX
• Direct3D 11.0, Direct3D 10.1/10.0, DXGI 1.0/1.1, Direct2D 1.0, DirectWrite, Windows Imaging Component (WIC) APIs
• Windows Vista and Windows 7 Task Dialogs
• Sensor Platform APIs
• Extended Linguistic Services APIs
• Power Management APIs
• Application Restart and Recovery APIs
• Network List Manager APIs
• Command Link control and System defined Shell icons

• Visual Studio 2010 compliance
• Initial xUnit test coverage
• String localization
• Signed assemblies

Requirements:

• Minimum .NET Framework version required to use this library is 3.5 SP1.
  The APIs for Shell Extensions require .NET 4.
• This library targets the Windows 7, though many of the features will work on Windows Vista as well.

Building and using the Library:

• To build the library (except the DirectX related features) in Visual Studio 2008, execute 'Windows API Code Pack Self Extractor.exe' and extract the contents of the ‘Windows API Code Pack 1.1.zip’ file. Build the included ‘WindowsAPICodePack.sln’ file located in the 'WindowsAPICodePack' directory (within the 'source' directory).
• To build the DirectX features, build the 'DirectX.sln' file inside the DirectX directory. Additional information on using the DirectX features of the Code Pack can be found in the 'DirectXCodePack_Requirements.htm' document available as a separate download.

Some relevant blogs:

• Windows Shell programming with Windows API Code Pack
• Introducing DirectX features of Windows API Code Pack
• Direct2D and DirectWrite with Windows API Code Pack

Videos:
Two minute videos demonstrating some features are available here:

• Explorer Browser
• Common File Dialog

Download the API code-pack here:

http://code.msdn.microsoft.com/WindowsAPICodePack

The Truth About Value Types in C#

Eric Lippert of Microsoft has written en excellent blog post in which he unveil many doubted truths and let us know many of the facts of C# language and its CLR/ C LI implementation. Every developer must read it.

This post clears one of the common miss-conception of developers: Value types are always allocated on stack.

I am giving an excerpt of of that post.

You can read full post here at his blog:
http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx

1. It is usually stated incorrectly: the statement should be "value types can be stored on the stack", instead of the more common "value types are always stored on the stack".
2. It is almost always irrelevant. We've worked hard to make a managed environment where the distinctions between different kinds of storage are hidden from the user. Unlike some languages, in which you must know whether a particular storage is on the stack or the heap for correctness reasons.
3. It is incomplete. What about references? References are neither value types nor instances of reference types, but they are values. They've got to be stored somewhere. Do they go on the stack or the heap? Why does no one ever talk about them? Just because they don't have a type in the C# type system is no reason to ignore them.

The way in the past I've usually pushed back on this myth is to say that the real statement should be "in the Microsoft implementation of C# on the desktop CLR, value types are stored on the stack when the value is a local variable or temporary that is not a closed-over local variable of a lambda or anonymous method, and the method body is not an iterator block, and the jitter chooses to not enregister the value."

The sheer number of weasel words in there is astounding, but they're all necessary:

• Versions of C# provided by other vendors may choose other allocation strategies for their temporary variables; there is no language requirement that a data structure called "the stack" be used to store locals of value type.
• We have many versions of the CLI that run on embedded systems, in web browsers, and so on. Some may run on exotic hardware. I have no idea what the memory allocation strategies of those versions of the CLI are. The hardware might not even have the concept of "the stack" for all I know. Or there could be multiple stacks per thread. Or everything could go on the heap.
• Lambdas and anonymous methods hoist local variables to become heap-allocated fields; those are not on the stack anymore.
• Iterator blocks in today's implementation of C# on the desktop CLR also hoist locals to become heap-allocated fields. They do not have to! We could have chosen to implement iterator blocks as coroutines running on a fiber with a dedicated stack. In that case, the locals of value type could go on the stack of the fiber.
• People always seem to forget that there is more to memory management than "the stack" and "the heap". Registers are neither on the stack or the heap, and it is perfectly legal for a value type to go in a register if there is one of the right size. If if is important to know when something goes on the stack, then why isn't it important to know when it goes in a register? Conversely, if the register scheduling algorithm of the jit compiler is unimportant for most users to understand, then why isn't the stack allocation strategy also unimportant?

Having made these points many times in the last few years, I've realized that the fundamental problem is inthe mistaken belief that the type system has anything whatsoever to do with the storage allocation strategy. It is simply false that the choice of whether to use the stack or the heap has anything fundamentally to do with the type of the thing being stored. The truth is: the choice of allocation mechanism has to do only with the known required lifetime of the storage.

Once you look at it that way then everything suddenly starts making much more sense. Let's break it down into some simple declarative sentences.

• There are three kinds of values: (1) instances of value types, (2) instances of reference types, and (3) references. (Code in C# cannot manipulate instances of reference types directly; it always does so via a reference. In unsafe code, pointer types are treated like value types for the purposes of determining the storage requirements of their values.)
• There exist "storage locations" which can store values.
• Every value manipulated by a program is stored in some storage location.
• Every reference (except the null reference) refers to a storage location.
• Every storage location has a "lifetime". That is, a period of time in which the storage location's contents are valid.
• The time between a start of execution of a particular method and the method returning normally or throwing an exception is the "activation period" of that method execution.
• Code in a method can require the use of a storage location. If the required lifetime of the storage location is longer than the activation period of the current method execution then the storage is said to be "long lived". Otherwise it is "short lived". (Note that when method M calls method N, the use of the storage locations for the parameters passed to N and the value returned by N is required by M.)

Now we come to implementation details. In the Microsoft implementation of C# on the CLR:

• There are three kinds of storage locations: stack locations, heap locations, and registers.
• Long-lived storage locations are always heap locations.
• Short-lived storage locations are always stack locations or registers.
• There are some situations in which it is difficult for the compiler or runtime to determine whether a particular storage location is short-lived or long-lived. In those cases, the prudent decision is to treat them as long-lived. In particular, the storage locations of instances of reference types are always treated as though they are long-lived, even if they are provably short-lived. Therefore they always go on the heap.

And now things follow very naturally:

• We see that references and instances of value types are essentially the same thing as far as their storage is concerned; they go on either the stack, in registers, or the heap depending on whether the storage of the value needs to be short-lived or long-lived.
• It is frequently the case that array elements, fields of reference types, locals in an iterator block and closed-over locals of a lambda or anonymous method must live longer than the activation period of the method that first required the use of their storage. And even in the rare cases where their lifetimes are shorter than that of the activation of the method, it is difficult or impossible to write a compiler that knows that. Therefore we must be conservative: all of these storage locations go on the heap.
• It is frequently the case that local variables and temporary values can be shown via compile-time analysis to be unused after the activation period ends, and therefore can be treated short-lived, and therefore can go onto the stack or put into registers.

Once you abandon entirely the crazy idea that the type of a value has anything whatsoever to do with thestorage, it becomes much easier to reason about it. Of course, my point above stands: you don't need to reason about it unless you are writing unsafe code or doing some sort of heavy interoperating with unmanaged code. Let the compiler and the runtime manage the lifetime of your storage locations; that's what its good at.

Eric Lippert is a senior software design engineer at Microsoft. He has been working full time in the developer division since 1996, where he has assisted with the design and implementation of VBScript, JScript, JScript .NET, Windows Script Host, Visual Studio Tools for Office and C#.

Winners of the Developer.com Product of the Year 2009

Technology

Winner: RIAs (Rich Internet Applications)

• Agile Development
• AOP (Aspect-Oriented Programming)
• Cloud Computing
• SOA (Service-Oriented Architecture)
• Social Networking

Framework

Winner: Spring Framework and the Hibernate Framework When Integrated Together

• Apache Wicket Framework
• Merb 1.0 Framework
• Microsoft® .Net Framework 3.5
• Rails Framework

Development Tool

Winner: NetBeans Platform

• ComponentOne® Studio® Enterprise
• Eclipse Platform
• Visual Studio® 2008
• VMware Workstation 6.5

Development Utilities

Winner: NetBeans Profiler

• ANTS Profiler v3™
• JUnit
• Visual Assist X
• VisualVM

Web Service

Winner: REST (Representational State Transfer)

• Amazon Web Services
• Force.com™
• Microsoft® Live™.com Services
• zembly

Wireless/Mobile

Winner: NetBeans Mobility Pack for Connected Device Configuration (CDC) 5.5

• Android
• iPhone SDK
• Visual Studio® 2008
• Sybase PocketBuilder™

Database Tool

Winner: MySQL™ workbench

• Altova DatabaseSpy® 2008
• LINQ (Microsoft® .NET Language Integrated Query)
• SQL Server® 2008 Reporting Services
• Oracle SQL Developer

Java Tool

Winner: NetBeans IDE

• Eclipse SQL Explorer
• Glassfish Application Server
• Hudson
• javacc™

JSR

Winner: JSR 220: Enterprise JavaBeans™ 3.0

• JSR 241: The Groovy Programming Language
• JSR 249: Mobile Service Architecture 2
• JSR 286: Portlet Specification 2.0
• JSR-296: Swing Application Framework

.NET Tool

Winner: Mono 2.0

• Altova® XMLSpy®
• Microsoft® Windows Communication Foundation (WCF)
• Microsoft® Windows Presentation Foundation (WPF)
• NAnt

Open Source

Winner: NetBeans

• Android
• Drupal CMS
• Eclipse
• Merb 1.0 Framework
• Mono 2.0

Security

Winner: OpenSSO Enterprise

• AppArmor ("Application Armor")
• Crowd
• Metasploit
• Untangle Gateway

Overview of JQuery

The idea behind jQuery is to simplify the task of getting a selected subset of DOM elements to work with. In other words, the jQuery library is mostly intended to run queries over the page DOM and execute operations over returned items. But the query engine behind the library goes far beyond the simple search capabilities of, say, document.getElementById (and related functions) that you find natively in the DOM. The query capabilities of jQuery use the powerful CSS syntax which gives you a surprising level of expressivity. For example, you can select all elements that share a given CSS class, have a given combination of attribute values, appear in a fixed relative position in the DOM tree, and are in particular relationship with other elements. More importantly, you can add filter conditions and chain all queries together to be applied sequentially.

The root of the jQuery library is the function defined as follows:

var jQuery = window.jQuery = window.$ = function( selector, context ) 
{
   return new jQuery.fn.init( selector, context );
};

Nearly any jQuery script is characterized by one or more calls to the $ function -- an alias for the root jQuery function. Any line of jQuery code is essentially a query with some optional action applied to the results.

When you specify a query, you call the root function and pass it a selector plus an optional context. The selector indicates the query expression; the context indicates the portion of the DOM where to run the query. If no context is specified, the jQuery function looks for DOM elements within the entire page DOM. The jQuery root object performs some work on the provided arguments, runs the query, and then returns a new jQuery object that contains the results. The newly created jQuery object can, in turn, be further queried, or filtered, in a new statement as well as in chain of statements; for example:

$("div.Tooltip")

The call selects all DIV tags with a CSS class attribute of Tooltip. Written that way, however, the code has no significant effect. The$ function selects one or more DOM elements and that's all of it. It just returns a new jQuery object that contains the DOM elements. The resulting set is known as the "wrapped set". You can grab the size of this set by calling the size method, as shown below:

alert($("div.Tooltip").size());

Any function you invoke on the wrapped set is called for each element in the set. For example, consider the following code:

$("div.Tooltip:hidden").fadeIn(500);

The query selects all DIV elements currently hidden where the class attribute equals Tooltip. Each of these hidden DIV elements is then displayed using a fade-in algorithm that takes half a second to complete.

You can also loop over each element in the wrapped set using the each function:

$("div.Tooltip:hidden").each(
    function() {
      this.fadeIn(500);
    }
);

The each function gets a JavaScript callback function and plays that function for each element. The difference between the function each and a manual JavaScript loop lies in the fact that the function each automatically maps the this object (as in the snippet) to the element in the collection being processed. The callback function, however, also receives an integer parameter being the 0-based index of the iteration. If you are interested in using this piece of information, you just add a parameter to the definition of the callback passed to each.

$("div.Tooltip:hidden").each(
    function(index) {
        :
    }
);

As you can see, most of the time by simply calling the function directly on the wrapped set you obtain the same effect as writing the loop yourself. The each function is reserved for special situations where you need to employ some application-specific logic to determine the action to take.

An extract from this article from Dr. Dobbs Journal.

What if you could use .NET on really small devices?

The .NET Micro Framework is .NET for small and resource constrained devices. It offers a complete and innovative development and execution environment that brings the productivity of modern computing tools to this class of devices.

.NET Micro Framework is an open source platform that expands the power and versatility of .NET to the world of small embedded applications. Desktop programmers can harness their existing .NET knowledge base to bring complex embedded concepts to market on time (and under budget). Embedded Developers can tap into the massive productivity gains that have been seen on the Desktop.

 

1.5 million devices
are currently running on
the .NET Micro Framework.

 

 

.NET Micro Framework Devices

The typical .NET Micro-Framework device has a 32 bit processor with or without a memory management unit (MMU) and could have as little as 64K of random-access memory (RAM).  The .NET Micro Framework supports rich user experience and deep connectivity with other devices.

Such devices include: consumer devices, consumer medical, home automation, industrial automation, automotive, sideshow devices / PC peripherals.

For more on what the.NET Micro Framework is, please go to www.microsoft.com/netmf.

Learn more about .Net Micro F/W here:

http://www.microsoft.com/netmf/default.mspx
http://www.netmf.com/Home.aspx

Web Farm Framework to Provision and Scale a Web Farm

The Microsoft Web Farm Framework is a free product we are shipping that enables you to easily provision and mange a farm of web servers.  It enables you to automate the installation and configuration of platform components across the server farm, and enables you to automatically synchronize and deploy ASP.NET applications across them. 

The Microsoft Web Farm Framework enables you to easily define a “Server Farm” that you can add any number of servers into.  Servers participating in the “Server Farm” will then be automatically updated, provisioned and managed by the Web Farm Framework. 

What this means is that you can install IIS (including modules like UrlRewrite, Media Services, etc), ASP.NET, and custom SSL certificates once on a primary server – and then the Web Farm Framework will automatically replicate and provision the exact same configuration across all of the other web servers in the farm (no manual or additional steps required). 

You can then create and configure an IIS Application Pool and a new Site and Application once on a primary server – and the Web Farm Framework will automatically replicate and provision the settings to all of the other web servers in the farm.  You can then copy/deploy an ASP.NET application once on the primary server – and the Web Farm Framework will automatically replicate and provision the changes to all of the web servers in the farm (no manual or additional steps required).

The Web Farm Framework eliminates the need to manually install/manage things across a cluster of machines.  It handles all of the provisioning and deployment for you in a completely automated way.

Read detailed description of Web Farm Framework on Scott Guthrie’s blog:
http://weblogs.asp.net/scottgu/archive/2010/09/08/introducing-the-microsoft-web-farm-framework.aspx

Download it from here:
http://www.iis.net/download/WebFarmFramework