Recent Announcements

  • Struts Vs Spring Submitted by Raghvendra KumarSpring supports a large number of standards, btw. JSR330, JMS, JSR250, JPA, JSR303, the whole servlet stack, JSF, JMX, a zillion others. Actually, if you look ...
    Posted Dec 5, 2014, 5:02 AM by Bipin Sasi
  • Google's heavy usage of Python, is it just a matter of taste or does it give them a competitive advantage?  it's not that Google uses Python because it employs so many prominent Pythonistas -- rather, most "prominent Pythonista" googlers joined Google, at least in part, because we knew about Python ...
    Posted Mar 7, 2014, 3:50 AM by Bipin Sasi
  • Google Apps Migration for Lotus Notes Google Apps Migration for Lotus Notes (GAMLN) is a native Notes database tool that migrates mail, calendar, contacts, and group information from your Notes accounts to Google Apps. This server ...
    Posted Mar 6, 2014, 12:08 PM by Bipin Sasi
Showing posts 1 - 3 of 5. View more »

Struts Vs Spring

posted Dec 5, 2014, 5:02 AM by Bipin Sasi

Submitted by Raghvendra Kumar

Spring supports a large number of standards, btw. JSR330, JMS, JSR250, JPA, JSR303, the whole servlet stack, JSF, JMX, a zillion others. Actually, if you look at it by the numbers, Spring supports more specifications than a Java EE 6 "web profile" implementation ;-) So, that argument doesn't buy you anything. You can create an entirely Java, entirely standards-oriented application in Spring. In fact, if you use Spring 3.1, you can avoid all XML - web.xml, persistence.xml, ejb-*xml, orm.xml, etc, which is not true of Java EE 6 (and especially of java EE 5 or below). The problem comes when you want to do stuff the standards don't support. Then, you'll need some extra, like Spring MVC.

Spring supports an MVC framework - which Java EE doesn't. If you want to do a web application using pure Java EE, you only have servlets and JSPs or pure JSF. If you want to be more productive, you'll end up using an extra project (one that's not "standard") like Spring MVC, GWT, Wicket, or Seam or even just straight PrimeFaces. Seam's a bad choice for a lot of reasons (heavy session use, horrible track record wrt backwards incompatibility between 1 and 2, and 2 and 3, etc. For the best reasons to avoid Seam 3, see this blog from JBoss where the Seam project lead admits Seam 3 isn't very useful for developers... also, check out the comments.)

So, that leaves you back to Struts vs. Spring MVC. And, as others have pointed out, it's an easy choice: Spring MVC's constantly updated and backwards compatible (for all the talk of "standards," the "standard" Java EE APIs buy you nothing in terms of safety of investment: a mildly sophisticated J2EE application written in 2004 won't compile or run on today's Java EE 6, where as a Spring application written in 2002 will run just fine today.)

Spring MVC has tight integration with all the other Spring libraries and Spring MVC's easy. for a good example on getting started, check out http://blog.springsource.com/2011/01/04/green-beans-getting-started-with-spring-mvc/ Spring MVC supports everything that Struts 1 (or 2) supports, and a lot more that builds on top of it for when you need more specialized support: SPring Web Flow for wizards, REST support, Spring WS for SOAP based web services, Spring BlazeDS for Flex integration, etc: all of it builds on top of Spring MVC and can be layered on top of the clean foundation it provides.



Google's heavy usage of Python, is it just a matter of taste or does it give them a competitive advantage?

posted Mar 7, 2014, 3:50 AM by Bipin Sasi   [ updated Mar 7, 2014, 3:50 AM ]

 it's not that Google uses Python because it employs so many prominent Pythonistas -- rather, most "prominent Pythonista" googlers joined Google, at least in part, because we knew about Python's prominence there but historically Google's choice of Python predated even them.

 It all got started, I believe, because the very earliest Googlers  made a good engineering decision: "Python where we can, C++ where we must" -- they used (a subset of) C++ for the parts of the software stack where very low latency and/or tight control of memory were crucial, and Python, allowing more rapid delivery and maintenance of programs, for other parts. At the time, late '90s, the choice for the latter role was essentially between Python and Perl: other scripting languages were either unripe (I don't think Ruby was around yet, for example) or had other issues and limitations. Perl was more mature (especially in terms of its ecosystem of available add-ons via CPAN), but Python was deemed to be more readable and maintainable, and interfacing to C++ libraries (via SWIG) was easier.

Java came in later, covering an intermediate niche -- and more recently of course Go was developed (though I don't believe there's much production work in it yet, as it's still evolving and maturing). Some specialized languages such as sawzall are also in the mix for very specific tasks, and of course Javascript is very important for browser-side work.

Other languages, including the ones that Greg mentioned back in '06, are either "kind of accidental" or used for other specific tasks (e.g., Objective C for clients on iPhones or Macs) -- e.g., when Google hired its first system administrators, those employees inevitably came with very strong mastery of Perl and Bash, and often used either of those languages to develop some complex internal system; recoding those in Python (for easier deployment and maintainability) has often happened. Others (such as C#) may have been in the mix temporarily due to acquisitions, but, again, recoding in one of the "main Google languages" is always a pretty high priority (in C#'s case, recoding would typically be mostly in Java, as the two languages address similar areas in terms of levels of abstraction).

At Google, python is one of the 3 "official languages" alongside with C++ and Java. Official here means that Googlers are allowed to deploy these languages to production services. (Internally Google people use many technologies including PHP, C#, Ruby and Perl). Python is well suited to the engineering process at Google. The typical project at Google has a small team (3 people) and a short duration (3 months).

"Python has been an important part of Google since the beginning, and remains so as the system grows and evolved. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language"

Google Apps Migration for Lotus Notes

posted Mar 6, 2014, 12:08 PM by Bipin Sasi

Google Apps Migration for Lotus Notes (GAMLN) is a native Notes database tool that migrates mail, calendar, contacts, and group information from your Notes accounts to Google Apps.

This server-side migration tool offers administrators:

  • Scheduled migrations and migration templates
  • Automatic provisioning of Google Apps accounts
  • Tools for migration notifications, reporting, and logging
  • High data integrity for migration of mail, calendar, contact information from Lotus Notes to Google Apps

 

System Requirements

  • Google Apps for Business or Education.
  • IBM Lotus Domino Server Release 6.5 or later. The migration tool must be installed on a Microsoft Windows 2003 or higher server. Mail files may reside on any operating system that supports Lotus Notes.
  • A single Notes Client with Domino Administrator installed.
  • Administrator access to the mail files being migrated through a trusted user or server ID.
  • Microsoft Core XML Services 6.0 when using ServerXMLHttp to feed Notes content to Google

When moving from Lotus to a Cloud solution, the Email solution to an equivalent – such as Gmail, is obvious. The Domino applications however, which are primarily workflow and transaction driven, do not have an equivalent solution.

While many may debate that Google’s Sites, Forms and App Engine are viable options for moving Domino Apps, they are not the right alternative for Domino if you consider the type of applications that reside on Domino and how the Lotus Domino Applications are developed.


Other Available options are Flawed

1. Focus on Runtime : Lotus Notes is more than Just a Run-time platform. It has a powerful Development Environment that is targeted to ease & intuitiveness. Migrating to a platform that overlooks the Citizen Development aspects is short-sighted. 

2. Costly and Slow : Most current approaches require a lot of effort and money rebuilding the applications in environments such as Java, xPages, .Net. The automated migration is half-cooked & works only in percentages.




How Google Apps Emerged as a Leader ?

posted Mar 6, 2014, 12:07 PM by Bipin Sasi   [ updated Mar 6, 2014, 12:07 PM ]


Google Apps has achieved the ripe old age of 7.  Brought to life in August 2006, the original offering had 4 basic services – gMail, gCalendar, Docs and PageMaker.  To express how fast and how much Google Apps has expanded beyond that – well, that’s as tough as explaining how GOOGLE INC, founded only 15 years ago (1998) has expanded:

  • from 2 founders to over 30,000 employees worldwide
  • gone from $0 to $50,000,000,000 (Billion) annual revenue in 15 years
  • and warrants a stock price >$1,000  per share 

Google is accustomed to rapid and significant change, so in just 7 years it has morphed Google Apps from a suite of modest apps to an entire Digital Ecosystem.  It now provides all three “As A Service” layers of CLOUD computing: Infrastructure (IAAS) / Platform (PAAS) / Software (SAAS).

Essentially it has transformed PC’s into PDC’s (Personal Data Center) and for a company can serve as a complete secured and professionally administered offsite Data Center.  One that can be scaled up or down on demand – that’s a long way from providing a few productivity apps.

Some important facts : 
  • In 2012 the majority of businesses are adopting cloud computing – 38% have already adopted cloud computing and a further 29% are making plans to adopt it. 89% of financial decision-makers are aware of their organizations’ plans to adopt cloud computing and 66% have been involved in the decision as to whether cloud computing should be adopted in their organization
  • Gartner found that Google’s cloud-based productivity suite (ie. Docs, Sheets, Slides, etc.) is taking market share from Microsoft. Google Apps had about 10 percent of the cloud-office market in 2007, 20 percent in 2009, and between 33 percent and 50 percent in 2012.
  • The Google Apps Marketplace, Chrome Web Store and Drive installable applications have emerged to help organizations fully realize the potential of Google Apps and make their use of the platform easier and more secure.   
  • 72 of the top 100 US universities use Google Apps including Princeton, Brown, Northwestern, Georgetown and Vanderbilt
  • Google is doing to Microsoft as Microsoft has done to countless competitors: releasing products that are pretty good, improving incrementally and making them so affordable that, at some point, it’s hard to justify not making the switch. That’s especially true when most of your company’s employees have Gmail and Google Apps accounts and aren’t shy about using them for business.
( The article was contributed by Ashish Gupta/ Google Apps Developer /VRD Network )

Accessing Google Cloud SQL from Apps Script

posted Feb 12, 2014, 10:29 AM by Bipin Sasi

Connection to Google Cloud SQL instance From Google Apps Script : Google Apps Script has the ability to make connections to databases via JDBC with the Jdbc Service.

Authorization : In order to connect to an instance the user must be a member of the associated Google APIs Console project. Optionally, a user name and password can be specified to apply more fine-grained permissions. To learn more about access control, see access control documentation

Accessing Google Cloud SQL Databases: We can connect to these databases in Apps Script, using the special method getCloudSqlConnection. This method works the same way as getConnection, but only accepts Google Cloud SQL connection strings.

var conn = Jdbc.getCloudSqlConnection("jdbc:google:rdbms://instance_name/database_name");

 

Once connected you can use the same code you would use to work against any MySQL database.

Writing to a Database: This code will insert a record in person table in database

 

function insert() {
  var fname="First Name"
  var lname="Last Name"
  var conn = Jdbc.getCloudSqlConnection("jdbc:google:rdbms://instance_name/database_name");
  var stmt = conn.createStatement()
  var query="insert into person(FNAME,LNAME) values('"+fname+"','"+lname+"')"
  stmt.execute(query)
  stmt.close()
  conn.close()
 }

 

Reading from a Database: This code will read from database.

function read() {
  var conn = Jdbc.getCloudSqlConnection("jdbc:google:rdbms://instance_name/database_name");
  var stmt = conn.createStatement()
  var query="select FNAME, LNAME from person"
  var rs= stmt.executeQuery(query)
  while(rs.next()){
    Logger.log("First Name : "+rs.getString(1)+" , "+"Last Name : "+rs.getString(2))
  }
  rs.close()
  stmt.close()
  conn.close()
 }

 

 

Sample source code :

 

 

Code.gs

function doGet() {

var app=UiApp.createApplication();

 var conn = Jdbc.getCloudSqlConnection("jdbc:google:rdbms://instance/tablename");

  var stmt = conn.createStatement();

  stmt.setMaxRows(10000);

  var start = new Date();

 

   var rs = stmt.executeQuery("  SELECT * FROM authors");

 

  var grid=app.createGrid(21,4);

  var row = 1;

  while (rs.next()) {

 

      Logger.log(rs.getString(1));

       Logger.log(rs.getString(2));

        Logger.log(rs.getString(3));

     

     grid.setWidget(row, 1, app.createLabel(rs.getString(1)));

     grid.setWidget(row,2, app.createLabel(rs.getString(2)));

     grid.setWidget(row, 3, app.createLabel(rs.getString(3)));

 

     row++;

  }

  rs.close();

  stmt.close();

  conn.close();

  app.add(grid);

  return app;

};

1-5 of 5