Difference between call and apply in javascript

The main difference is:
apply lets you invoke the function with arguments as an array.
call requires the parameters be listed explicitly.

syntax:
 theFunction.apply(valueForThis, arrayOfArgs)
 theFunction.call(valueForThis, arg1, arg2, ...)


 Sample code:
 function theFunction(name, profession) {
 alert("My name is " + name + " and I am a " + profession + ".");
 }

theFunction("John", "fireman");

theFunction.apply(undefined, ["Susan", "school teacher"]);

theFunction.call(undefined, "Claude", "mathematician");

How to find top three highest salary in emp table using sql

The top three highest salary in emp table using sql is

SELECT *FROM ( SELECT *FROM emp ORDER BY Salary desc ) WHERE rownum <= 3;

Java 1.5 Feature : Varargs

In past releases, a method that took an arbitrary number of values required you to create an array and put the values into the array prior to invoking the method.

It is still true that multiple arguments must be passed in an array, but the varargs feature automates and hides the process. Furthermore, it is upward compatible with preexisting APIs.

Public static String format(String pattern,
Object... arguments);
The three periods after the final parameter's type indicate that the final argument may be passed as an array or as a sequence of arguments. Varargs can be used only in the final argument position.

Much more simpler example here..

public class VarArgs {
public static void main(String[] args) {
String[] newArgs = {"a", "b", "c"};
vaMethod(newArgs);
}

public void vaMethod(String[] args) {
System.out.println("You gave me " + args.length + " args! Yay.");
}
}
You can declare it more easily, and not have to construct the array ahead of time:

public class VarArgs {
public static void main(String[] args) {
vaMethod("a", "b", "c");
}

public void vaMethod(String... args) {
System.out.println("You gave me " + args.length + " args! Yay.");
}
}

Java 1.5 Language Features

Generics

This long-awaited enhancement to the type system allows a type or method to operate on objects of various types while providing compile-time type safety. It adds compile-time type safety to the Collections Framework and eliminates the drudgery of casting. Refer to JSR 14.

Enhanced for Loop

This new language construct eliminates the drudgery and error-proneness of iterators and index variables when iterating over collections and arrays. Refer to JSR 201 .

Autoboxing/Unboxing

This facility eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer). Refer to JSR 201 .

Typesafe Enums

This flexible object-oriented enumerated type facility allows you to create enumerated types with arbitrary methods and fields. It provides all the benefits of the Typesafe Enum pattern ("Effective Java," Item 21) without the verbosity and the error-proneness. Refer to JSR 201.

Varargs

This facility eliminates the need for manually boxing up argument lists into an array when invoking methods that accept variable-length argument lists. Refer to JSR 201.

Static Import

This facility lets you avoid qualifying static members with class names without the shortcomings of the "Constant Interface antipattern." Refer to JSR 201.

Metadata (Annotations)

This language feature lets you avoid writing boilerplate code under many circumstances by enabling tools to generate it from annotations in the source code. This leads to a "declarative" programming style where the programmer says what should be done and tools emit the code to do it. Also it eliminates the need for maintaining "side files" that must be kept up to date with changes in source files. Instead the information can be maintained in the source file. Refer to JSR 175.

Client side web site performance

Smaller images,
Omitting quotes in HTML attributes (yes, people went that far!),
Using fixed width tables in IE 5
Balancing server response buffering vs creating the whole page first and then sending it all in one response, etc.

Putting images on different domains (though now other resources are worth considering too)
Compressing the server output using gzip (a bit hit and miss on earlier versions of IIS though)
Cache control using the Expires header
Use CSS (though in those days I used it mostly for font definitions and browser sniffing was needed to load different CSS files!)


Use GZip on all text-based output (which should be optimized anyway via web standards!)

Try to reduce the number of HTTP requests (e.g. combine CSS and JavaScript files during development or during the build process, use CSS sprites, if possible etc)
Help browsers ensure they can cache as many of your files as possible

Let browsers download your page resources in parallel even though HTTP 1.1 limits you to 2 concurrent requests from a domain (through sub-domains, minimizing or eliminating loading CSS and JavaScript in a way that blocks the browser, etc)

Disperse your content through things like content distribution and extra sub-domains (though be aware of extra DNS-lookups that might result)