Development with Touch - Key Board Optional

Now its time to start development with Touch


https://www.touchdevelop.com/

Cheers!!
Prabath Randy.

VS 2012 SPA is on Track

HI All

    We were so Sad that we lost Single page Application Template within 2012 RC which was there with Visual Studio 2011 Beta.

Finally we got it from Fall 2012 update - http://www.asp.net/vnext/overview/fall-2012-update

Cheers!!!

Happy SPA.

TransMedia Applicaton with (SPA)

Yesterday MARTIN FOWLER has Written an Article about Mobile Application towards the future , what we have already started. J

Mobile applications have been a hot item in software development over the past couple of years. Like many software delivery companies, ThoughtWorks get a lot of requests from clients asking us to build a mobile application for them. However most of the time a company asks us (or anyone) to build a mobile application they are starting off on the wrong foot. I'd argue that for most situations, even though you want users to interact with a mobile device, you should never think of building a mobile application. Instead you need to think about building a single application that presents across multiple devices: mobile, desktop, tablet - or whatever device your users might use.

A common mistake is to think of different apps for different delivery devices.

Instead think of a single app with different presentations on different devices.

Extracted from - http://martinfowler.com/bliki/TransMediaApplication.html

Pair Programming

Our Chief Scientist "johannes Brodwall" always enforce us to practice pair programming and I found this article interested regarding pair programming. 

Seven Secrets of Successful Pair Programming

We are towards right Direction

If you have great sense on right direction no need to worry how to do it upfront.

                                                                                                                                 

In our case we Started to use HTM5 and Javascript as our web platform ( Specially focus on Single page Architecture ) 10 months ago and now all the globe is towards to it and giving us best support on it. 

Please review this . - http://www.webplatform.org/

We are an open community of developers building resources for a better web, regardless of brand, browser or platform. Anyone can contribute and each person who does makes us stronger. Together we can continue to drive innovation on the Web to serve the greater good. It starts here, with you.

and refer -  Core Mobile Web Platform Community Group

                   http://akasharchy.blogspot.com/2012/10/w3c-comminity-for-html5-mobile-platform.html

Cheers!!

Prabath Randy

Is HTML5 the Future

On Wednesday, Cross took part in panel discussion dubbed "Is HTML5 the future?" at the Apps World conference in London and was right away asked to address the comments made by Facebook founder and CEO Mark Zuckerberg last month when he said that Facebook's biggest mistake was betting too much on HTML5 as opposed to native mobile apps.

"I think we have to separate HTML5 on the desktop Web from HTML5 on the mobile Web. On the desktop it is like done. It is awesome, and it's the future. On mobile it could be the future, but like any good technology it needs to prove itself," said Cross.

Extracted From - http://www.dotnetexpertguide.com/2012/10/aspnet-mvc-4-cookieless-domain-for-bundling-and-static-resources.html

W3C Comminity For HTML5 Mobile platform

The Future of mobile - http://www.w3.org/community/coremob/

Game Changer for Windows - run Android apps on windows

AMD AppZone Player, Powered by BlueStacks

http://blogs.amd.com/fusion/2012/09/27/announcing-amd-appzone-player-powered-by-bluestacks/

So what happens when a company is brave enough to introduce Scrum into a CMMI:5 environment

Here's what Jeff found:

- Productivity doubled in less than six months reducing total project costs by 50%.

- Defects were reduced by 40% in all Scrum projects (despite the fact this company already had one of the lowest defect rates in the world.)

- Planning costs were reduced by about 80%.

- User satisfaction and developer satisfaction were much higher than comparable waterfall implementations.

- Projects were linearly scalable, something never seen before. The productivity of individual developers remains the same as the project increases in size.

Extracted From - http://www.richard-banks.org/2007/09/agile-vs-cmmi-comparison.html

Good Single page application Intro in Wiki

Hi guys this got updated 1st of September

http://en.wikipedia.org/wiki/Single-page_application

with learning tutorials - http://johnpapa.net/building-single-page-apps-with-knockout-jquery-and-web-api-ndash-the-story-begins


Cheers!!

Google BigQuery

Google BigQuery is a web service that lets you do interactive analysis of massive datasets—up to billions of rows. Scalable and easy to use, BigQuery lets developers and businesses tap into powerful data analytics on demand


https://developers.google.com/bigquery/


this is good for specially with  small organization to analyze their data without buying any OLAP systems.

Which JavaScript Framework should I Used for Single Page Architecture?

Following Comparison from Steven Sanderson.

Disagreement: What’s flexible, what’s integrated.

Each technology has different levels of prescriptiveness:

	Views	URL routing	Data storage
AngularJS	Built-in DOM-based templates (mandatory)	Built-in (optional)	Built-in system (optional)
Backbone	Choose your own (most used handlebars.js, a string-based template library)	Built-in (optional)	Built-in (overridable)
Batman	Built-in DOM-based templates (mandatory)	Built-in (mandatory)	Built-in system (mandatory)
CanJS	Built-in string-based templates (mandatory)	Built in (optional)	Built in (optional)
Ember	Built-in string-based templates (mandatory)	Built-in (mandatory)	Built-in (overridable)
Knockout	Built-in DOM-based templates (optional, can do string-based too)	Choose your own (most use sammy.js or history.js)	Choose your own (e.g., knockout.mapping or just $.ajax)
Meteor	Built-in string-based templates (mandatory)	Built-in (mandatory?)	Built-in (Mongo, mandatory)
Spine	Choose your own string-based templates	Built-in (optional)	Built-in (optional?)

As expected, whenever a library leaves a decision open, they argue it is better overall to guarantee composablity with arbitrary 3^rd-party libraries. And the obvious counter-argument is that integration can be more seamless if built-in. Again, based on my conversations, the audience was split and opinions went in all directions — usually based on how much other technology stack an individual was wedded to.

Quote from Tom Dale of Ember: “We do a lot of magic, but it’s good magic, which means it decomposes into sane primitives.“

Extracted From - http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/

Another Comparison 

The Contenders

Here is a table showing all of the frameworks support for the above features. Click through the title for more detail.

Framework	UI Bindings	Composed Views	Web Presentation Layer	Plays Nicely With Others
Backbone.js	✗	✗	✓	✓
SproutCore 1.x	✓	✓	✗	✗
Sammy.js	✗	✗	✓	✓
Spine.js	✗	✗	✓	✓
Cappuccino	✓	✓	✗	✗
Knockout.js	✓	✗	✓	✓
Javascript MVC	✗	✓	✓	✓
Google Web Toolkit	✗	✓	✗	✗
Google Closure	✗	✓	✓	✗
Ember.js	✓	✓	✓	✓
Angular.js	✓	✗	✓	✓
Batman.js	✓	✗	✓	✓

Extracted from - http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

I am still not in a position of choosing any of them for my single page architecture applications whereas my sense with Angular.js.

will see. 

cheers !!!

Battle of Java Script Frameworks and libraries by Steve

TL;DR Executive Summary

• For many web developers, it’s now taken for granted that such client-side frameworks are the way to build rich web apps. If you’re not using one, you’re either not building an application, or you’re just missing out.
• There’s lots of consensus among the main frameworks about how to do it (Model-View-* architecture, declarative bindings, etc. — details below), so to some extent you get similar benefits whichever you choose.
• Some major philosophical differences remain, especially the big split between frameworks and libraries. Your choice will deeply influence your architecture.
• The conference itself was stylish and upbeat, with a lot of socialising and conversations across different technology groups. I’d like to see more like this.

Technologies: Agreement and Disagreement

As each SPA technology was presented, some fairly clear patterns of similarity and difference emerged.

Agreement: Progressive enhancement isn’t for building real apps.

All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code.

Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more).

Agreement: Model-View-Whatever.

All the technologies made use of model-view separation. Some specifically talked about MVC, some about MVVM, and some specifically refused to define the third piece (just saying it’s models, views, and some kind of application thing that makes them work together). The net result in each case was similar.

Agreement: Data binding is good.

All except Backbone and Spine have a built-in notion of declarative data binding in their views (Backbone instead has a “bring your own view technology” design).

Agreement: IE 6 is dead already.

In a panel discussion, most framework creators said their IE support focus was limited to version 7+ (in fact, Ember and AngularJS only go for IE8, and Batman requires an ES5 shim to run on IE older than v9). This is the way of things to come: even jQuery 2 is set to drop support for IE older than v9.

The only stalwarts here appear to be Backbone and Knockout which support IE6+ (I don’t know about Backbone’s internals, but for KO this means transparently working around a lot of crazy edge-case IE6/7 rendering and eventing weirdnesses).

Agreement: Licensing and source control.

Every single one is MIT licensed and hosted on GitHub.

Disagreement: Libraries vs frameworks.

This is the biggest split right now. You could group them as follows:

Libraries	Frameworks
Backbone (9552) Knockout (2357) Spine (2017) CanJS (321)	Ember (3993) AngularJS (2925) Batman (958) Meteor (4172) — unusual, see later

Numbers in brackets are a point-in-time snapshot of the number of GitHub watchers, as a crude indicator of relative influence.

What does this mean?

• Libraries slot into your existing architecture and add specific functionality
• Frameworks give you an architecture (file structure, etc.) that you are meant to follow and, if you do, are intended to handle all common requirements

By far the most passionate advocate of the framework model is Ember, whose creator Yehuda Katz is formerly of the Rails and SproutCore projects (similar philosophy). His argument was that anything less is just not ambitious enough and isn’t seriously advancing the state of the art. The counter-argument is that libraries are more focused, and hence can be easier to learn, adopt, customize, and help minimise project risk because your architecture isn’t so deeply tied to a specific external project. Based on my conversations, I’d say the audience was split and supported both sides of this debate.

Note that AngularJS is arguably somewhere in between library and framework: it doesn’t require a particular layout of files at development time (library-like), but at runtime it provides an “app lifecycle” that you fit your code into (framework-like). I’m listing it as a framework because that’s the terminology the AngularJS team prefers.

Disagreement: What’s flexible, what’s integrated.

Each technology has different levels of prescriptiveness:

	Views	URL routing	Data storage
AngularJS	Built-in DOM-based templates (mandatory)	Built-in (optional)	Built-in system (optional)
Backbone	Choose your own (most used handlebars.js, a string-based template library)	Built-in (optional)	Built-in (overridable)
Batman	Built-in DOM-based templates (mandatory)	Built-in (mandatory)	Built-in system (mandatory)
CanJS	Built-in string-based templates (mandatory)	Built in (optional)	Built in (optional)
Ember	Built-in string-based templates (mandatory)	Built-in (mandatory)	Built-in (overridable)
Knockout	Built-in DOM-based templates (optional, can do string-based too)	Choose your own (most use sammy.js or history.js)	Choose your own (e.g., knockout.mapping or just $.ajax)
Meteor	Built-in string-based templates (mandatory)	Built-in (mandatory?)	Built-in (Mongo, mandatory)
Spine	Choose your own string-based templates	Built-in (optional)	Built-in (optional?)

As expected, whenever a library leaves a decision open, they argue it is better overall to guarantee composablity with arbitrary 3^rd-party libraries. And the obvious counter-argument is that integration can be more seamless if built-in. Again, based on my conversations, the audience was split and opinions went in all directions — usually based on how much other technology stack an individual was wedded to.

Quote from Tom Dale of Ember: “We do a lot of magic, but it’s good magic, which means it decomposes into sane primitives.“

Disagreement: String-based vs DOM-based templates

(As shown in the above table.) For string-based templates, almost everyone used Handlebars.js as the template engine, which seems to dominate this space, though CanJS used EJS. Arguments in favour of string-based templates include “it’s faster” (debatable) and “theoretically, the server can render them too” (also debatable, as that’s only true if you can actually run all of your model code on the server, and nobody actually does that in practice).

DOM-based templates means doing control flow (each, if, etc.) purely via bindings in your actual markup and not relying on any external templating library. Argument include “it’s faster” (debatable) and “the code is easier to read and write, because there’s no weird chasm between markup and templates, and it’s obvious how CSS will interact with it“.

In my view, the strongest argument here came from the AngularJS guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. AngularJS is from Google, so they are already working on this with Chromium and standards bodies.

Disagreement: Levels of server-agnosticism

Batman and Meteor express explicit demands on the server: Batman is designed for Rails, and Meteor is its own server. Most others have a goal of being indifferent to what’s on your server, but in practice the architecture, conventions, and some tooling in Ember leans towards Rails developers. Ember absolutely works on other server technologies too, though today it takes a little more manual setup.

The technologies — quick overview

Here’s a rundown of the basic details of each technology covered:

Backbone

• Who: Jeremy Ashkenas and DocumentCloud
• What:
  • Model-View in JavaScript, MIT licensed
  • Most minimal of all the libraries — only one file, 800 lines of code!
  • Extremely tightly-scoped functionality — just provides REST-persistable models with simple routing and callbacks so you know when to render views (you supply your own view-rendering mechanism).
  • The best-known of them all, with the most production deployments on big-name sites (perhaps easy to adopt because it’s so minimal)
• Why:
  • It’s so small, you can read and understand all of the source before you use it.
  • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • Jeremy seems to exist in a kind of zen state of calm, reasonable opinions about everything. He was like the grown up, supervising all the arguing kids.
• Where: GitHub and own site
• When: In production for nearly 2 years now

Meteor

• Who: The Meteor development group, who just raised $11.2 Million so they can do this full-time
• What:
  • Crazy amazing framework from the future, barely reminiscent of anything you’ve ever seen (except perhaps Derby)
  • Bridges a server-side runtime (on Node+Mongo) with a client-side one, so your code appears to run on both, including the database. WebSockets syncs between all client(s) and server.
  • Does “live deployments” every time you edit your code – client-side runtimes are updated on the fly without losing their state
  • Makes more sense if you watch the video
  • Like everyone I spoke to at the event, I really want this to succeed — web development needs something this radical to move forwards
• Why: You’ve had enough of conventional web development and now want to live on the bleeding edge.
• Where: GitHub and own site
• When: It’s still early days; I don’t know if there are any production Meteor sites yet except built by the core team. They’re totally serious about doing this, though.

Ember

• Who: Yehuda Katz (formerly of jQuery and Rails), the Ember team, and Yehuda’s company Tilde
• What:
  • Everything you need to build an “ambitious web application”, MIT license
  • Biggest framework of them all in both functionality and code size
  • Lots of thought has gone into how you can decompose your page into a hierarchy of controls, and how this ties in with a statemachine-powered hierarchical routing system
  • Very sophisticated data access library (Ember.Data) currently in development
  • Intended to control your whole page at runtime, so not suitable for use in small “islands of richness” on a wider page
  • Pretty heavily opinionated about files, URLs, etc., but everything is overridable if you know how
  • Design inspired by Rails and Cocoa
  • Tooling: They supply project templates for Rails (but you can use other server platforms if you write the code manually)
• Why: Common problems should have common solutions — Ember makes all the common solutions so you only have to think about what’s unique to your own application
• Where: GitHub and own site
• When: Not yet at 1.0, but aiming for it soon. API will solidify then.

AngularJS

• Who: Developed by Google; used internally by them and MIT licensed.
• What:
  • Model-View-Whatever in JavaScript, MIT licensed
  • DOM-based templating with observability, declarative bindings, and an almost-MVVM code style (they say Model-View-Whatever)
  • Basic URL routing and data persistence built in
  • Tooling: they ship a Chrome debugger plugin that lets you explore your models while debugging, and a plugin for the Jasmine testing framework.
• Why:
  • Conceptually, they say it’s a polyfill between what browsers can do today and what they will do natively in a few years (declarative binding and observability), so we should start coding this way right now
  • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
• Where: GitHub and own site
• When: In production now (has been at Google for a while)

Knockout

• Who: The Knockout team and community (currently three on the core team, including me)
• What:
  • Model-View-ViewModel (MVVM) in JavaScript, MIT licensed
  • Tightly focused on rich UIs: DOM-based templates with declarative bindings, and observable models with automatic dependency detection
  • Not opinionated about URL routing or data access — combines with arbitrary third-party libraries (e.g., Sammy.js for routing and plain ajax for storage)
  • Big focus on approachability, with extensive documentation and interactive examples
• Why:
  • Does one thing well (UI), right back to IE 6
  • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
• Where: GitHub and own site
• When: In production for nearly 2 years now

Spine

• Who: Alex MacCaw
• What:
  • MVC in JavaScript, MIT license
  • Worked example originally written for an O’Reilly book grew into an actual OSS project
  • Is a kind of modified clone of Backbone (hence the name)
• Why: You like Backbone, but want a few things to be different.
• Where: GitHub and own site
• When: It’s past v1.0.0 now

Batman

• Who: the team at Shopify (an eCommerce platform company)
• What:
  • MVC in JavaScript, almost exclusively for Rails+CoffeeScript developers, MIT licensed
  • Most opinionated of them all. You must follow their conventions (e.g., for file layout and URLs) or, as they say in their presentation,”go use another framework“
  • Full-stack framework with pretty rich models, views, and controllers and routing. And observability mechanism of course.
  • DOM-based templating.
• Why: If you use Rails and CoffeeScript, you’ll be right at home
• Where: GitHub and own site
• When: Currently at 0.9. Aiming for 1.0 in coming months.

CanJS

• Who: the team at Bitovi (a JavaScript consulting/training company)
• What:
  • MVC in JavaScript, MIT licensed
  • REST-persistable models, basic routing, string-based templating
  • Not widely known (I hadn’t heard of it before last week), though is actually a reboot of the olderJavaScriptMVC project
• Why: Aims to be the best of all worlds by delivering features similar to the above libraries while also being small
• Where: GitHub and own site
• When: Past 1.0 already

Extracted From - http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/