Friday, November 11, 2011
Importance of having Breakfast
 |
| Importance of having Breakfast Breakfast can help prevent strokes, heart attack and sudden death. Advice on not to skip breakfast! |
Because the frequency of heart attack, sudden death, and stroke peaks between 6: 00a.m. and noon, with the highest incidence being between 8: 00a.m. and 10:00a.m.What mechanism within the body could account for this significant jump in sudden death in the early morning hours?We may have an Answer.Platelet, tiny elements in the blood that keep us from bleeding to Death if we get a cut, can clump together inside our arteries due to Cholesterol or plaque buildup in the artery lining. It is in the morning hours that platelets become the most activated and tend to form these internal blood clots at the greatest frequency.
Importance of having Breakfast
What is LINQ
LINQ is an acronym for Language Integrated Query, which is descriptive for where
it's used and what it does. The Language Integrated part means that LINQ is part
of programming language syntax. In particular, both C# and VB are languages that
ship with .NET and have LINQ capabilities. Another programming language that supports
LINQ is Delphi Prism. The other part of the definition, Query, explains what LINQ
does; LINQ is used for querying data. Notice that I used the generic term "data"
and didn't indicate what type of data. That's because LINQ can be used to query
many different types of data, including relational, XML, and even objects. Another
way to describe LINQ is that it is programming language syntax that is used to query
data.
Note: In addition to a new language syntax, LINQ can be used via a fluent API that chains methods together. The bulk of this tutorial will concentrate on the C# language syntax that supports LINQ.
Note: In addition to a new language syntax, LINQ can be used via a fluent API that chains methods together. The bulk of this tutorial will concentrate on the C# language syntax that supports LINQ.
What Is HTML5
As
the bedrock to the web, HTML has evolved in many ways from its birth in
1991. While the markup language has had its share of ups and downs, the
advent of what’s being called “HTML5” is a welcome and much anticipated
addition of new semantic capabilities and valuable APIs.
HTML5
is a series of new elements, updates to existing elements and new
JavaScript APIs available through contemporary web browsers. In order to
best describe what HTML5 is, perhaps starting with a few attributes of
what HTML5 is not will help draw the most clear picture.
HTML5 is not the next iteration of XHTML.
In fact many of the rules that you are accustomed to from your
familiarity with XHTML are now changed in HTML5. The promise of XHTML’s
standards compliance and strict validation may be music to the ears of
all of us as software developers, but the pragmatic outcome of broken
layouts and validation errors bubbling up to users created an unforeseen
outcome - programmatic perfection does not translate into a usable web.
XHTML simply isn’t a long-term standard.
The
real world of the web contains scores of ill-formed HTML largely
created by tools and people with less exacting standards than the
conscientious web developer. While this may sound bad, the non-code
enthusiasts are often tasked with creating content for the web and have
no inclination to worry about whether or not every HTML attribute has a
value in their markup, for instance.
HTML5
moves beyond the utopian dream of strict compliance to a schema and
places the highest value on the user of the website over the HTML
craftsman.
“HTML5” no longer exists. In
a strict sense, the term “HTML5” is a misnomer as there are no longer
standalone versions of HTML. In the earliest incarnation of HTML5, there
existed a notion of the next version of HTML being termed HTML5. The
label of “HTML5” took hold in the market and started being used almost
as an umbrella term for “the latest thing” in web development. Recently,
Ian Hickson announced in his blog post, HTML is the New HTML5 (http://blog.whatwg.org/html-is-the-new-html5),
the standards document once known as “HTML5” is now being maintained
under the auspices of the plain name “HTML” as a fluid specification.
The reasoning behind this is because HTML5 became a blanket term for
many different technologies and browser vendors are implementing
different parts of the standard. Therefore, the notion of “detecting
HTML5” or “supporting HTML5” represents faulty thinking. Rather than
looking for HTML5 in its totality, developers are better served by
detecting the individual functionality required from HTML for an
application.
So
if HTML5 isn’t XHTML plus some new dazzling features, what is it?
Simply put, HTML5 is the new HTML standard that includes most of the
features and capabilities of HTML4 along with new semantic markup plus a
number of new JavaScript APIs.
For
clarity’s sake, this article still refers to the combination of markup
enhancements and new JavaScript APIs as HTML5 in order to easily
identify new technologies.
Semantic Markup
The
value of Semantic markup on the web cannot be understated. When you
consider many of the changes related to semantic markup you may realize
that seemingly very little is different. While changing a DIV to a
SECTION may not seem revolutionary, the underlying value is found in the
page’s ability to more clearly describe the intent of the containing
content with new tags over the old ones. Pages that contain inherent
meaning will ultimately perform better in search engines, are easier to
parse on the client and easier for external machines on the web to
interpret and understand.
The
semantic changes are a product of established design patterns. The
contributors to the HTML5 specification include companies like Google,
Microsoft, Apple, all the top browser vendors and literally hundreds of
other organizations. These contributors analyzed the vast array of
markup on the web and looked to create new HTML elements that reflect
the intent of current makeup on the web.
So
while new elements may not seem earth-shattering, the value is to give
more intrinsic meaning to your HTML documents which creates a more open
and usable web. Table 1 lists many of the HTML elements introduced in HTML5.
JavaScript APIs
If
the first part of the equation of HTML5 is the markup, then the second
half is represented by the new JavaScript APIs. In fact, the more you
begin to develop applications in HTML5, the more you realize that most
of the new functionality is in the updated scripting abilities of the
browser.
While browser support for each script API is diverse among the browser landscape, Table 2 describes the promise of each API once fully supported.
Browser Support and the New Age of “Browser Wars”
In
the early days of the web the browser landscape was akin to the Wild
West. Each browser vendor, in an attempt to gain the most market share,
began quickly implementing new features often using proprietary APIs.
This fragmentation in the market created a situation where websites
might only work correctly in a single browser or development teams were
forced to replicate programming efforts in order to provide the same
functionality for different browsers. In short, the situation was a
lose/lose proposition for both web developers and website users.
The
end of the browser wars emerged with the rising influence of the Web
Standards Project which worked hard to get browser makers to agree to
work within the established standards.
So
the distinction today about the push and pull toward complete support
for HTML5 is that each browser maker is implementing against the same
standard. Long gone are the days where in order to implement the same
functionality on a page you had to code for the Netscape API as well as
the Internet Explorer API. Now the APIs are known and standardized, the
dance now is just compensating for the time when a user’s browser may
not have the capabilities of the standard.
To best aid you in reliably developing applications in HTML5 there are two resources that are invaluable:
| & | To Use or Not To Use: SECTION or DIV? Determining the difference between when to use the SECTION element over a DIV may seem a little confusing at first. A valuable rule of thumb to help you decide which element is appropriate is to ask whether or not the element you need to add to the page is intended to establish a logical group around content or if it’s merely being added to support styling of the page. In the case of logical grouping, use the SECTION. To support styling needs, use a DIV. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
What’s New in Visual C# 4.0
Visual C# version 4.0 offers new features that make it easier for you to work in dynamic programming scenarios. Besides dynamic programming, you have support for optional and named parameters, better COM interop support, and contra-variance and covariance. This article will show you how each of these features work and provide suggestions of
how they can be applied to help you be more productive.
To
help you follow the path of C#, this article looks at the history of
C#, today’s use of C#, and helps you understand the future of C# and
what the language intends to provide for you. After you understand the
theme of C# 4.0, you’ll learn about the new features of C# 4.0. Finally,
this article will show you how to create a dynamic object of your own
with late-bound calls to dynamic methods based on conventions.
The
previous major versions of C# were 1.0, 2.0, and 3.0. There was a minor
version 1.1 in April of 2003, but it didn’t significantly change the
theme of the 1.0 release. I’ll discuss these versions in the following
sections.
Microsoft
first announced C# on June 16th 2000. It was the first high-level
programming language that was built specifically to target the .NET
Common Language Runtime. C# 1.0 grew its heritage from C++, but borrowed
features from languages such as Delphi, Java, and others. In C# 1.0,
Microsoft planned to provide an object-oriented, component-based
language that was very simple to use. When Microsoft released C# 1.0 to
manufacturing on February 13th 2002, it was an immediate hit and
steadily grew in popularity.
When
C# 2.0 rolled around, Microsoft finally added all of the features that
should have been in C# 1.0. For example, generics was huge and is an
important part of .NET development today. C# 2.0 also introduced
anonymous methods, iterators, and nullable types. An interesting
addition to C# 2.0, nullable types was a pre-cursor feature for what was
coming in the next version, focusing on data.
Most
developers work with data, which was the primary theme of C# 3.0. The
largest C# 3.0 language addition was Language Integrated Query (LINQ).
Most other language features added in C# 3.0 were primarily to support
LINQ, but the new features; including implicitly typed local variables,
anonymous types, object and collection initializers, lambdas, and
extension methods, can have value on their own in development that
doesn’t involve LINQ.
The
next version of C# will be 4.0, which is the focus of this article. C#
4.0 will primarily focus on dynamic programming. The following sections
of this article explain the dynamic programming features of C# 4.0 as
well as other new features such as optional/named parameters and
covariance/contravariance.
Why Dynamic Programming?
The
dynamic programming story in C# can fall into fulfilling categories of
need in the way of multiple-language integration, simpler reflection,
access to HTML DOM in Web scenarios, and easier COM interop. Some of
these categories of need might not apply to your particular situation,
and that’s okay because there isn’t anything that says that you have to
use a language feature just because it’s there. Therefore, I’ll give you
an idea of how someone with a specific need might find value in C# 4.0
dynamic programming.
| " | C# 4.0 will primarily focus on dynamic programming. | " |
Most
C# developers use multiple tools in a single application to accomplish
complex tasks. If you’re writing WPF desktop applications, you’re using
C# and XAML. It is quite possible that you might find some open source
code that solves a problem, but it might be written in another language
such as VB or F#. One of the benefits of .NET since its inception is the
ability to have cross-language interoperability and the runtime is even
called the “Common Language” Runtime (CLR). In recent years, Microsoft
has created dynamic languages, such as IronRuby and IronPython, but
developers don’t have an easy way to perform interop with dynamic
languages. If you have this need, then you’ll welcome the ease with
which C# dynamic programming makes interop between C# and dynamic
languages possible.
When
performing reflection to run a method on an object, there are several
hoops to jump through, including obtaining a reference to an object
type, getting a reference to a member info object, determining the type
of bindings to use, and then invoking the member. While reflection has
an undeniable coolness factor, it still feels like a hack and that’s
where C# 4.0 dynamic methods can help. Later in this article, I’ll show
you how to just call the object member.
If
you write Silverlight applications, you might have the need today or in
the future to access the HTML DOM containing your Silverlight control.
C# dynamic programming makes this task easier.
Performing
COM interop with C# has always been cumbersome; partly because of the
need to write extra syntax for conversions, optional parameters, and
more. This has left some C# developers with a touch of VB envy because
VB has easier COM interop support. One of the purposes of dynamic
programming in C# is to help the C# programmer write cleaner syntax in
COM interop scenarios.
I’ve
spent some time explaining some of the potential benefits of dynamic
programming because it’s so new that the value might not jump out at you
immediately. In following sections, I’ll share the how so that you can match it up with the why that
you might care about. Before diving into dynamic programming, let’s
look at a couple other new features of C# 4.0, optional and named
parameters.
| " | If you’re of the same mind, then you’ll probably be pleased that C# 4.0 supports optional parameters. | " |
For
many C# developers, the long wait for optional parameters is over with
C# 4.0. An optional parameter lets you provide a default value and the
caller has a choice of whether or not they want to provide an argument.
In current and earlier versions of C#, you could simulate optional
parameters like this:
// Overload with no parameterpublic static string SayHello(){ return "Hey, You!";}// Overload with normal parameterpublic static string SayHello(string name){ return "Hey, " + name + "!";}
The
SayHello method above is overloaded with both an empty parameter list
and a parameter list with a single string parameter. To the user of this
code, the name parameter appears to be optional and both of the
following calls work fine:
// Name is optionalvar greetYou = SayHello();// Can provide name if you wantvar greetJoe = SayHello("Joe");
If
you had methods with more parameters and wanted to provide a more
flexible coding experience, you would provide more overloads. Many
developers have said that this is cumbersome and leaves more code to
maintain. If you’re of the same mind, then you’ll probably be pleased
that C# 4.0 supports optional parameters. The snippet below shows an
optional parameter, replacing the previous two overloads:
// Method with optional parameterpublic static string SayHello(string name = "You"){ return "Hey, " + name + "!";}
As
shown in the previous snippet, the syntax to call an optional parameter
requires assigning a default value to the parameter. In the listing
above, "You" will be assigned to name if the caller does not provide a value.
A feature related to optional parameters is named parameters, which is discussed next.
Named Parameters
One
of the primary purposes of named parameters is that they resolve
ambiguity between parameters. For example, the following method contains
two parameters that are strings:
public static void AddClubMember( string name, string email = "", DateTime? dateJoined = null){ // Not yet implemented}
The types of the first two parameters of the AddClubMember method above are both string, except that name is not optional, but email is optional. This example also demonstrates that you can default parameters to null.
AddClubMember( email: "joe@dot.net", name: "Joe", dateJoined: DateTime.Now);}
The
call to AddClubMember above uses named parameters where the name is the
same as the parameter name in the method declaration with an appended
colon. Notice that I’ve shuffled the parameter order to demonstrate that
you can change the order of parameters.
| " | Named parameters are particularly useful when you have multiple optional parameters of the same type. | " |
Named
parameters are particularly useful when you have multiple optional
parameters of the same type. In that case, you name the parameter that
you want to set, telling C# which parameter your argument matches. The
code below demonstrates a problem where named parameters are necessary:
AddClubMember( "joe@dot.net", dateJoined: DateTime.Now);}
If
you recall, the first parameter of the AddClubMember method is name, a
required parameter of type string. Since the first argument above is a
string, C# will match that argument to the name parameter. Clearly, the
value above is an email address, which presents you with a logical error
that won’t be detected at either compile time nor run time when that
line executes.
Posts
