Enterprise Architecture, TOGAF and Solution Architects — Quite often people wonder where a Solution Architect fits within the TOGAF Framework and it is not obvious that there is a single answer. I suggest we look first at a generic profile for a Solution Architect. Companies such as Oracle, Cisco, SAP and others have roles called Solution Architect but with little apparent agreement to what that role is.
Read this article - http://soa.sys-con.com/node/1099170
This article gives a good understanding of the various software architecture roles and responsibilities. I got a clear idea of the role of a solution architect as opposed to an enterprise architect.
Friday, September 11, 2009
Tuesday, September 8, 2009
Thursday, July 30, 2009
The case against checked exceptions
For a number of years now I have been unable to get a decent answer to the following question: why are some developers so against checked exceptions. I have had numerous conversations, read things on blog, read what Bruce Eckel had to say (the first person I saw speak out against them).
I am currently writing some new code and paying very careful attention to how I deal with exceptions. I am trying to see the point of view of the "we don't like checked exceptions" crowd and I still cannot see it.
Every conversation I have ends with the same question going unanswered... let me set it up:
In general (from how Java was designed),
Error is for things that should never be caught (VM has a peanut allergy and someone dropped a jar of peanuts on it)
RuntimeException is for things that the programmer did wrong (programmer walked off the end of an array)
Exception (except RuntimeException) is for things that are out of the programmers control (disk fills up while writing to the file system, file handle limit for the process has been reached and you cannot open any more files)
Throwable is simply the parent of all of the exception types.
A common argument I hear is that if an exception happens then all the developer is going to do is exit the program.
Another common argument I hear is that checked exceptions make it harder to refactor code.
For the "all I am going to do is exit" argument I say that even if you are exiting you need to display a reasonable error message. If you are just punting on handling errors then your users won't be overly happy when the program exits without a clear indication of why.
For the "it makes it hard to refactor" crowd, that indicates that the proper level of abstraction wasn't chosen. Rather than declare a method throws an IOException, the IOException should be transformed into an exception that is more suited for what is going on.
I don't have an issue with wrapping Main with catch(Exception) (or in some cases catch(Throwable) to ensure that the program can exit gracefully - but I always catch the specific exceptions I need to. Doing that allows me to, at the very least, display an appropriate error message.
The question that people never reply to is this:
If you throw RuntimException subclasses instead of Exception subclasses then how do you know what you are supposed to catch?
If the answer is catch Exception then you are also dealing with programmer errors the same way as system exceptions. That seems wrong to me.
If you catch Throwable then you are treating system exceptions and VM errors (and the like) the same way. That seems wrong to me.
If the answer is that you catch only the exceptions you know are thrown then how do you know what ones are thrown? What happens when programmer X throws a new exception and forgot to catch it? That seems very dangerous to me.
I would say that a program that displays a stack trace is wrong. Do people who don't like checked exceptions not feel that way?
So, if you don't like checked exceptions can you explain why not AND answer the question that doesn't get answered please?
Edit: I am not looking for advice on when to use either model, what I am looking for is why people extend from RuntimeException because the don't like extending from Exception and/or why they catch an exception and then rethrow a RuntimeException rather then add throws to their method. I want to understand the motivation for disliking checked exceptions.
More details please refer - http://stackoverflow.com/questions/613954/the-case-against-checked-exceptions
I am currently writing some new code and paying very careful attention to how I deal with exceptions. I am trying to see the point of view of the "we don't like checked exceptions" crowd and I still cannot see it.
Every conversation I have ends with the same question going unanswered... let me set it up:
In general (from how Java was designed),
Error is for things that should never be caught (VM has a peanut allergy and someone dropped a jar of peanuts on it)
RuntimeException is for things that the programmer did wrong (programmer walked off the end of an array)
Exception (except RuntimeException) is for things that are out of the programmers control (disk fills up while writing to the file system, file handle limit for the process has been reached and you cannot open any more files)
Throwable is simply the parent of all of the exception types.
A common argument I hear is that if an exception happens then all the developer is going to do is exit the program.
Another common argument I hear is that checked exceptions make it harder to refactor code.
For the "all I am going to do is exit" argument I say that even if you are exiting you need to display a reasonable error message. If you are just punting on handling errors then your users won't be overly happy when the program exits without a clear indication of why.
For the "it makes it hard to refactor" crowd, that indicates that the proper level of abstraction wasn't chosen. Rather than declare a method throws an IOException, the IOException should be transformed into an exception that is more suited for what is going on.
I don't have an issue with wrapping Main with catch(Exception) (or in some cases catch(Throwable) to ensure that the program can exit gracefully - but I always catch the specific exceptions I need to. Doing that allows me to, at the very least, display an appropriate error message.
The question that people never reply to is this:
If you throw RuntimException subclasses instead of Exception subclasses then how do you know what you are supposed to catch?
If the answer is catch Exception then you are also dealing with programmer errors the same way as system exceptions. That seems wrong to me.
If you catch Throwable then you are treating system exceptions and VM errors (and the like) the same way. That seems wrong to me.
If the answer is that you catch only the exceptions you know are thrown then how do you know what ones are thrown? What happens when programmer X throws a new exception and forgot to catch it? That seems very dangerous to me.
I would say that a program that displays a stack trace is wrong. Do people who don't like checked exceptions not feel that way?
So, if you don't like checked exceptions can you explain why not AND answer the question that doesn't get answered please?
Edit: I am not looking for advice on when to use either model, what I am looking for is why people extend from RuntimeException because the don't like extending from Exception and/or why they catch an exception and then rethrow a RuntimeException rather then add throws to their method. I want to understand the motivation for disliking checked exceptions.
More details please refer - http://stackoverflow.com/questions/613954/the-case-against-checked-exceptions
HTTP vs HTTPS performance
Are there any major differences in performance between http and https? I seem to recall reading that https can be up to 1/5 times slower than http. Is this valid with the current generation webservers/browsers? If so, are there any whitepapers to support it?
For more details pl visit this site - http://stackoverflow.com/questions/149274/http-vs-https-performance
For more details pl visit this site - http://stackoverflow.com/questions/149274/http-vs-https-performance
Wednesday, July 29, 2009
A Preview of GWT 2.0
Google Web Toolkit (GWT) is an open source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java. It is licensed under the Apache License version 2.0. The GWT’s mission statement focuses on radically improving the web experience for users, by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.
Google is set to launch GWT 2.0 later this year. The progress of GWT has been slow but steady over the years. Let us explore the road traveled so far and what lies ahead
The miles travelled…
Google promises much more with the GWT2.0 version scheduled to release later this year. Its various versions have been made available in the following sequence, with 2.0 following…
GWT 1.0 May 17, 2006
GWT 1.1 August 11, 2006
GWT 1.2 November 16, 2006
GWT 1.3 February 5, 2007
GWT 1.4 August 28, 2007
GWT 1.5 August 27, 2008
GWT 1.6 April 07, 2009
GWT 1.7 July 13, 2009
The launch…
And in comes the GWT 2.0 scheduled to be launched later this year. There is a lot on offer for this new version as Google promises to improvise it. GWT 2.0 contains huge improvements, including dynamic script loading, a new catalog of compiler optimizations, and a new approach to hosted mode debugging that uses the native browser.
The hosted mode is a key to productive development and it helps in debugging, editing etc. The problem is that the hosted mode browser is too special e.g. on Linux, hosted browser is an ancient Mozilla, hard to simulate interactions with other technologies (e.g. Flash) and it is impossible to debug browsers on non-dev OSes (e.g. IE from Mac). The GWT solves these problems by making hosted mode work with most native browser and make it work across the network.
Another huge advantage will be the compiler enhancements that come with the new kit. This new version promises much faster compilations, size, speed and obscurity benefits.
A new feature is the developer-guided code splitting. Often the compiled script size can be a problem because it holds all the code and can grow very big. Hence, the initial download can be too slow; UI hangs during script parsing etc. GWT 2.0 provides a solution, in code splitting by using- runasync. It is intentionally developer-guided and async. It intentionally forces you to think about failure paths. The split point doesn’t necessarily split. The compiler decides how to cluster code and it is guaranteed to be correct, ordering-wise.
Another new feature is the ClientBundle which generalizes ImageBundle to arbitrary resource types. With ClientBundle not only images are bundled together, all the resources (like CSS) are getting bundled. The obvious advantage is that only one file has to be downloaded, hence, less HTTP requests and faster download. Additionally, resources like CSS are getting optimized for size. At the Google I/O presentations it was also mentioned that in later versions ClientBundle probably also handles binary resources using Base64.
In GWT 2.0 there is the possibility to create a RPC blacklists which tell the RPC subsystem to skip types that you know aren’t ever sent across the wire and so doesn’t get compiled and stuffed into the code base. GWT 2.0 also promises a faster, easier and more predictable layout (at last). The standards mode provides new leverage including constraint-based layout that actually does what you say and also you’ll never have to hook the window resize event again. There is an updated set of Panels in GWT 2.0.
Version 2.0 will bring GWT a huge step forward and boost performance for developers and clients. It is not official, but 2.0 maybe also brings a new XML based markup language to define the layout. My guess is that the syntax will be close to HTML. Let’s hope that the new version attracts more GWT developers and which hopefully results in more widget libraries and extensions.
For more details please visit http://www.hemju.com/2009/07/24/a-preview-of-gwt-2-0/
Google is set to launch GWT 2.0 later this year. The progress of GWT has been slow but steady over the years. Let us explore the road traveled so far and what lies ahead
The miles travelled…
Google promises much more with the GWT2.0 version scheduled to release later this year. Its various versions have been made available in the following sequence, with 2.0 following…
GWT 1.0 May 17, 2006
GWT 1.1 August 11, 2006
GWT 1.2 November 16, 2006
GWT 1.3 February 5, 2007
GWT 1.4 August 28, 2007
GWT 1.5 August 27, 2008
GWT 1.6 April 07, 2009
GWT 1.7 July 13, 2009
The launch…
And in comes the GWT 2.0 scheduled to be launched later this year. There is a lot on offer for this new version as Google promises to improvise it. GWT 2.0 contains huge improvements, including dynamic script loading, a new catalog of compiler optimizations, and a new approach to hosted mode debugging that uses the native browser.
The hosted mode is a key to productive development and it helps in debugging, editing etc. The problem is that the hosted mode browser is too special e.g. on Linux, hosted browser is an ancient Mozilla, hard to simulate interactions with other technologies (e.g. Flash) and it is impossible to debug browsers on non-dev OSes (e.g. IE from Mac). The GWT solves these problems by making hosted mode work with most native browser and make it work across the network.
Another huge advantage will be the compiler enhancements that come with the new kit. This new version promises much faster compilations, size, speed and obscurity benefits.
A new feature is the developer-guided code splitting. Often the compiled script size can be a problem because it holds all the code and can grow very big. Hence, the initial download can be too slow; UI hangs during script parsing etc. GWT 2.0 provides a solution, in code splitting by using- runasync. It is intentionally developer-guided and async. It intentionally forces you to think about failure paths. The split point doesn’t necessarily split. The compiler decides how to cluster code and it is guaranteed to be correct, ordering-wise.
Another new feature is the ClientBundle which generalizes ImageBundle to arbitrary resource types. With ClientBundle not only images are bundled together, all the resources (like CSS) are getting bundled. The obvious advantage is that only one file has to be downloaded, hence, less HTTP requests and faster download. Additionally, resources like CSS are getting optimized for size. At the Google I/O presentations it was also mentioned that in later versions ClientBundle probably also handles binary resources using Base64.
In GWT 2.0 there is the possibility to create a RPC blacklists which tell the RPC subsystem to skip types that you know aren’t ever sent across the wire and so doesn’t get compiled and stuffed into the code base. GWT 2.0 also promises a faster, easier and more predictable layout (at last). The standards mode provides new leverage including constraint-based layout that actually does what you say and also you’ll never have to hook the window resize event again. There is an updated set of Panels in GWT 2.0.
Version 2.0 will bring GWT a huge step forward and boost performance for developers and clients. It is not official, but 2.0 maybe also brings a new XML based markup language to define the layout. My guess is that the syntax will be close to HTML. Let’s hope that the new version attracts more GWT developers and which hopefully results in more widget libraries and extensions.
For more details please visit http://www.hemju.com/2009/07/24/a-preview-of-gwt-2-0/
Tuesday, July 28, 2009
Debunking Performance Myths: Java Vs C / C++
For all those who have passionately argued over performance and memory management aspects of Java and C++, an interesting article discussing some modern JVM features that significantly improve performance of Java applications.
For more details pl visit this site - http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
For more details pl visit this site - http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
Subscribe to:
Posts (Atom)