Things Great Engineers (almost) never say

Ref: http://java.dzone.com/articles/things-great-engineers-almost

• “I’ve used _____ but I have no idea how it works” – Great engineers gained their skills through probing and curiosity.  They go ‘under the hood’ of the products they use just to understand how things work, even if that information will never be very useful to them.  It is unclear whether this need to dig deeper is a choice or a compulsion, but it seems that it is a trait of the best talent.
• “______ works, I just don’t know how to explain it” –
• “I will need ______ (tool/condition) to complete this task” –
• “I’ve learned all I want/will ever need to know about ________ “ –
• “There is no solution” –
• “I hate programming” -
• “I’m an expert in _____”
• “I don’t understand the business” –
  
• “I don’t pay particular attention to industry trends” –

How System.currentTimeMillis() works in JAVA

Ref: http://www.ageofcode.com/java-articles/14-how-does-systemgettimeinmilliseconds-work

This article delves into the deceptively simple method System.currentTimeMillis(). It tries to provide some insight into the meaning of the value it returns. In so doing it explains what is meant by the "current time" in Java. It also examines this concept in relation to the timezone and daylight savings configuration of the computer on which it is produced.
The javadoc for the method System.currentTimeMillis() explains the concept exactly; it says that the value is:

"the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC".

I have always found this definition particularly unfriendly and difficult to grasp, it leaves a lot unsaid. If you are unsure about what it means then I believe that the following text may help.
The diagram above represents two time synchronized computers in two different timezones whose "wall" clocks show different times. At the represented moment in time, computer A in America (Atlantic Standard Time) shows 5:00 o'clock in the morning and computer B in Australia (Western Standard Time) shows 4:00 o'clock in the afternoon.
If we were to call System.currentTimeMillis() on both of these computers in the same instant then the values returned from both calls would be theoretically equal to each other. This is shown in the diagram, where the value for System.currentTimeMillis() is the same for both computers
What actually happens is that each of the computers independently calculates what the current date and time is in UTC and then uses the derived value to determine the number of milliseconds which have elapsed since the epoch. Theoretically there is only ever one correct UTC time so they should both arrive at the same answer.
The calculation uses the system clock, the timezone and daylight savings configurations as inputs as well as no doubt taking into account some platform specific factors. Implementations are native so they will definitely vary across platforms and JVMs.
The mistake I used to make, and a mistake I think a lot of people make, is to assume that the System.currentTimeMillis value is provided in terms of the timezone that the computer is in (i.e. wall clock time), rather than in UTC. If this was the case, the value returned by computer B in Australia would be larger than the one returned by computer A in America. This misunderstanding is very damaging as it affects the way one understands the java.util.Date and java.util.Calendar classes too.
If you think about it, the way it actually works makes a lot of sense. It means that we can directly compare the time in milliseconds from two computers regardless of their timezones.
The following table presents the contrived data with the computers in America and Australia in more detail. It also adds some data for a computer in Greenwich in London. The last column indicates whether or not the "Automatically adjust clock for daylight savings changes" option has been set to on or off (This option is available on Windows).
Read More

Is Java Dead or Invincible?

Ref: http://java.dzone.com/articles/java-dead-or-invincible

ORACLE Find SID of a currently connected Schema/Instance

Ref: http://stackoverflow.com/questions/6288122/checking-oracle-sid-and-database-name

The following query is useful to find SID from the connected session.

select sys_context('userenv','instance_name') from dual;

Using JMeter with WebSphere MQ

Ref: http://www.ibm.com/developerworks/websphere/library/techarticles/0808_vandekuil/0808_vandekuil.html

 Looks liks IBM removed the link and the info in that link can be find in below web archive page but without images :(

http://web.archive.org/web/20120110133537/http://www.ibm.com/developerworks/websphere/library/techarticles/0808_vandekuil/0808_vandekuil.html

Introduction
JMeter is frequently used to automate Web site testing, and it can send messages over JMS. This article shows you how to send messages from JMeter to IBM® WebSphere® MQ. This knowledge can help you automate your testing, for example, by enabling you to insert messages into MQ using JMS. WebSphere MQ can then process these messages and expose them through a Web service or an HTML page. With the JMS request, you can test a complete flow without human intervention, as well as schedule tests automatically and collect the results of the test into HTML reports. How does this process work? Here is an overview of the procedure and the tasks involved:

Open Office Macro Horizontal Odd-Even Row Compare

 Sub HorizonatalCompareOddEvenRows()  
   vSelection = ThisComponent.CurrentSelection  
   oSelect=ThisComponent.CurrentSelection.getRangeAddress  
   oSelectColumn=ThisComponent.CurrentSelection.Columns  
   oSelectRow=ThisComponent.CurrentSelection.Rows  
   CountColumn=oSelectColumn.getCount  
   CountRow=oSelectRow.getCount  
  oSelectSC=oSelectColumn.getByIndex(0).getName  
   oSelectEC=oSelectColumn.getByIndex(CountColumn-1).getName  
   oSelectSR=oSelect.StartRow+1  
   oSelectER=oSelect.EndRow+1  
   NoCell=(CountColumn*CountRow)  
   If CountColumn=1 AND CountRow=1 Then  
    MsgBox("Cell " + oSelectSC + oSelectSR + chr(13) + "Cell No = " + NoCell,, "SelectedCells")  
   Else  
    MsgBox("Range(" + oSelectSC + oSelectSR + ":" + oSelectEC + oSelectER + ")" + chr(13) + "Cell No = " + NoCell,, "SelectedCells")   
   End If  
   colorArray = Array(RGB(255,141,6), RGB(255,141,36), RGB(255,141,66), RGB(255,141,96), RGB(255,141,126))  
   colorAraySize = UBound(colorArray)  
 For colIndex = 0 To CountColumn-1  
   For rowIndex = 0 To CountRow-2  
           If (rowIndex mod 2) = 0 Then  
               vSel = vSelection.GetCellbyPosition(colIndex,rowIndex)  
               vNext = vSelection.GetCellbyPosition(colIndex,rowIndex+1)  
               s = vSel.getString()  
               s2 = vNext.getString()  
                 If Len(s) > 0 AND Len(s2) > 0 Then  
                   'Print s, s2, "(",colIndex,",",rowIndex,")","(",colIndex,",",(rowIndex+1),") Comp result",StrComp( s, s2)  
                   If StrComp(s, s2) <> 0 Then  
                    index = rowIndex mod colorAraySize  
                    vNext.CellBackColor = colorArray(index)  
                   Else  
                    'vSel.CellBackColor = RGB(255,255,255)  
                   End If  
                 Else  
                   'Print "Nothing is selected"  
                 End If  
           End If    
   Next  
 Next  
 End Sub  

Application logging guide lines - 2

Ref: http://www.bugfree.dk/blog/2009/07/22/basic-logging-guidelines/

Basic logging guidelines

Next to unit testing I believe in logging to improve the quality of an application. Instrumenting code with logging (or tracing for that matter) should be an integral part of writing production code. Yet, I’ve often found it not to be the case or that what got logged only made sense to the developer who wrote the entry.
Not logging implies that debugging the application outside the development environment is largely based on guesswork. That’s interesting given that most applications spend the majority of their life running outside the development environment.

Life in the sandbox

I suspect the absence or low quality of log statements can be, at least partially, explained by developers not finding them useful during development. The debugger available there is generally inferior to the print-lining approach of logging. That said, I’d argue that many developers don’t concern themselves enough with how their code behaves in a production environment. Rather than investing a small amount of time in adding log statements up-front, their focus is solely on satisfying functional customer requirements.
A related case could be made for exception handling. For instance, rather than asserting the validity of an argument up-front and throwing an appropriate exception, the code may later fail with a NullReferenceException. Not throwing the exception up-front, close to where the actual error occurred, one will have a hard time tracking down the issue. Especially since a stack trace with symbols and line numbers is rarely available in a production environment.
For someone having to resolve the issue, almost any clue as to the cause would be most welcomed. Without a clue that someone would walk around in the dark in the hope of stumbling into a solution.

End users aren’t the only users

As software developers we have to acknowledge that end users aren’t the only users of our software. System administrators, developers, and the like should also be factored in during development. Especially since the cost of instrumenting code at key places, early on, doesn’t add significantly to the overall development cost. Focusing on what can go wrong and communicating it well saves time, money, and frustration down the line. And as a bonus you might create better self-documenting code.
That said it’s important to strike a balance between logging too little and too much information. A log should be detailed enough to reveal patterns of use. Ideally, the log should read like a story with short sentences detailing what’s about to happen, what did or didn’t happen, and possibly why.
I’m not suggesting that we turn logging into a runtime version of literate programming. But simply that sufficient contextual information be provided, i.e., instead of logging “URL = ‘bugfree.dk’”, consider the more elaborate “Retrieving URL for indexing: ‘http://bugfree.dk’”.

Keep your statements clean

On the other hand, log statements shouldn’t be immune to the DRY principle. So make sure to have the logging framework automatically capture common bits of contextual information, such as the date and time of the entry and the class and method within which the log statement originated. On a similar note, don’t explicitly log when a method is entered or existed. Instead, treat such a case as a cross-cutting concern and take an Aspect Oriented approach to logging it.
Lastly, not every method requires (extensive) logging. Figuring out when and what to log is key. Debugging the application, fixing bugs, and experience should provide guidance into what’s useful to log.