Amazon Silk Browser

19-02-2015 23-03-21

Willing to know what it is and how its differ??

Its all-new web browser powered by Amazon Web Services (AWS) and available exclusively on the just announced Kindle Fire for now.

Amazon Silk deploys a split-architecture.  All of the browser subsystems are present on your Kindle Fire as well as on the AWS cloud computing platform.  Each time you load a web page, Silk makes a dynamic decision about which of these subsystems will run locally and which will execute remotely.  In short, Amazon Silk extends the boundaries of the browser, coupling the capabilities and interactivity of your local device with the massive computing power, memory, and network connectivity of our cloud.




What is HTTP/2??

Before we dig into HTTP/2..You should know about SPDY protocol..


SPDY (pronounced “SPeeDY”) is a networking protocol whose goal is to speed up the web. SPDY augments HTTP with several speed-related features that can dramatically reduce page load time:

  • SPDY allows client and server to compress request and response headers, which cuts down on bandwidth usage when the similar headers (e.g. cookies) are sent over and over for multiple requests.
  • SPDY allows multiple, simultaneously multiplexed requests over a single connection, saving on round trips between client and server, and preventing low-priority resources from blocking higher-priority requests.
  • SPDY allows the server to actively push resources to the client that it knows the client will need (e.g. JavaScript and CSS files) without waiting for the client to request them, allowing the server to make efficient use of unutilized bandwidth.

The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required.


HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.

The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

HTTP/2 is nearly done standardization; it has been approved by the IESG(The Internet Engineering Steering Group (IESG) is responsible for technical management of IETF( Internet Engineering Task Force) activities and the Internet standards process.), and should soon enter the RFC(Request For Comment) Editor’s publication queue.

You can see RFC for HTTP 1.1 here

HTTP/2 is comprised of two specifications:

Links to refer:

Understanding Karma

Initially i thought karma helps to write unit-test its wrong..its only a test case runner where we can see some results/reports of unit test cases… 🙂



Everything else need for writing unit-test case is jasmine alone.

Anyways as we are trying to understand karma..lets go to the point…

npm install --save-dev karma //allows you to install karma in your local project

If we’re using the yeoman generator with our apps, this is already set up for us. Just you have to run

karma init

To kick it off, we’ll use the karma init command which will generate the initial template that we’ll use to build our tests:

$ karma init karma.conf.js

It will ask us a series of questions and when it’s done, it will create a configuration file.

When it’s done, it will create a file in the same directory where we ran the generator that looks similar to the following:

// Karma configuration
module.exports = function(config) {
    // base path, that will be used to resolve files and exclude
    basePath: '',

    // testing framework to use (jasmine/mocha/qunit/...)
    frameworks: ['jasmine'],

    // list of files / patterns to load in the browser
    files: [

    // list of files / patterns to exclude
    exclude: [],

    // web server port
    port: 8080,

    // level of logging
    // possible values: LOG_DISABLE || LOG_ERROR || LOG_WARN || LOG_INFO || LOG_DEBUG
    logLevel: config.LOG_INFO,

    // enable / disable watching file and executing tests whenever any file changes
    autoWatch: false,

    // Start these browsers, currently available:
    // - Chrome
    // - ChromeCanary
    // - Firefox
    // - Opera
    // - Safari (only Mac)
    // - PhantomJS
    // - IE (only Windows)
    browsers: ['Chrome'],

    // Continuous Integration mode
    // if true, it capture browsers, run tests and exit
    singleRun: false
//plugins required to generate report
plugins: [
 'karma-coverage', //this we used to generate report

//this is the directory where you can check the results/reports
coverageReporter: {
 type: 'html',
 dir: 'coverage/'

 junitReporter: {
 outputFile: 'test-results.xml',
 suite: ''

 preprocessors: {
 // source files, that you wanna generate coverage for
 // do not include tests or libraries
 // (these files will be instrumented by Istanbul)
 // 'src/*.js': ['coverage']
 'app/**/!(_test).js': ['coverage']

// test results reporter to use
reporters: ['progress', 'junit', 'coverage']  ,
// enable / disable colors in the output (reporters and logs)
    colors: true,
// level of logging
    logLevel: config.LOG_INFO,


Now that we have our karma.conf.js file generated, we can kick off karma by issuing the following command:

$ karma start karma.conf.js

With this you can see files that are generated in coverage folder in your project directory. Run index.html in coverage folder to see the report. Thats it 🙂
Links to refer:!/day/19