Nice Java Framework to explore

called "PLAY"

Ref: http://www.playframework.org/

Best way to start learning Java EE (OR) J2EE

Ref: http://www.sitepoint.com/java-6-steps-mvc-web-apps/

Four Destructive Myths Most Companies Still Live By

Ref: http://blogs.hbr.org/schwartz/2011/11/four-destructive-myths-most-co.html?utm_source=twitterfeed&utm_medium=twitter

Myth #1: Multitasking is critical in a world of infinite demand.
This myth is based on the assumption that human beings are capable of doing two cognitive tasks at the same time. We're not. Instead, we learn to move rapidly between tasks. When we're doing one, we're actually not even aware of the other.
If you're on a conference call, for example, and you turn your attention to an incoming email, you're missing what's happening on the call as long as you're checking your email. Equally important, you're incurring something called "switching time." That's the time it takes to shift from one cognitive activity to another.
On average, according to researcher David Meyer, switching time increases the amount of time it takes to finish the primary task you were working on by an average of 25 percent. In short, juggling activities is incredibly inefficient.
Difficult as it is to focus in the face of the endless distractions we all now face, it's far and away the most effective way to get work done. The worst thing you can do as a boss is to insist that your people constantly check their email.
Myth #2: A little bit of anxiety helps us perform better.
Think for a moment about how you feel when you're performing at your best. What adjectives come to mind? Almost invariably they're positive ones. Anxiety may be a source of energy, and even motivation, but it comes with significant costs.
The more anxious we feel, the less clearly and imaginatively we think, and the more reactive and impulsive we become. That's not good for you, and it also has huge implications if you're in a supervisory role.
As a boss, your energy has a disproportionate impact on those you lead, by virtue of your authority. Put bluntly, any time your behavior increases someone's anxiety — or prompts any negative emotions, for that matter — they're less likely to perform effectively.
The more positive your energy is, the more positive their energy is likely to be, and the better the likely outcome.
Myth #3: Creativity is genetically inherited, and it's impossible to teach.
In a global economy characterized by unprecedented competitiveness and constant change, nearly every CEO hungers for ways to drive more innovation. Unfortunately, most CEOs don't think of themselves as creative, and they share with the rest of us a deeply ingrained belief that creativity is mostly inborn and magical.
Ironically, researchers have developed a surprising degree of consensus about the stages of creativity and how to approach them. Our educational system and most company cultures favor reward the rational, analytic, deductive left hemisphere thinking. We pay scant attention to intentionally cultivating the more visual, intuitive, big picture capacities of the right hemisphere.
As it turns out, the creative process moves back and forth between left and right hemisphere dominance. Creativity is actually about using the whole brain more flexibly. This process unfolds in a far more systematic — and teachable — way than we ordinarily imagine. People can quickly learn to access the hemisphere of the brain that serves them best at each stage of the creative process — and to generate truly original ideas.
Myth #4: The best way to get more work done is to work longer hours.
No single myth is more destructive to employers and employees than this one. The reason is that we're not designed to operate like computers — at high speeds, continuously, for long periods of time.
Instead, human beings are designed to pulse intermittently between spending and renewing energy. Great performers — and enlightened leaders — recognize that it's not the number of hours people work that determines the value they create, but rather the energy they bring to whatever hours they work.
Rather than systematically burning down our reservoir of energy as the day wears on, as most of us do, intermittent renewal makes it possible to keep our energy steady all day long. Strategically alternating periods of intense focus with intermittent renewal, at least every 90 minutes, makes it possible to get more done, in less time, more sustainably.
Want to test the assumption? Choose the most challenging task on your agenda before you go to sleep each night over the next week. Set aside 60 to 90 minutes at the start of the following day to focus on the activity you've chosen.
Choose a designated start and stop time, and do your best to allow no interruptions. (It helps to turn off your email.) Succeed and it will almost surely be your most productive period of the day. When you're done, reward yourself by taking a true renewal break.

How to Get Unstuck

Ref:http://java.dzone.com/articles/how-get-unstuck

• Be a generalist: If you know only on thing and this doesn’t work you are stuck. If you know lots of ways you have lots of options to explore. It is less likely that all of them are blocked. Often it helps to think in terms of a different technology about a problem in order to get the idea that gets you unstuck.


• Analyze precisely: More than once somebody asked me for assistance with a bug where the cause of the problem was nicely described in the call stack. So look exactly at the information you have (and the information you think you have). The first step is to actually read and understand error messages, stack traces and log files.


• Ask for help: Work isn’t a competition. It’s team work. So ask a coworker to assist you. Often describing the problem to someone else is enough to solve the problem.


• Know where to look for help: I’m quite surprised when people get stuck with a problem and I can solve it by asking google. Of course google is only the first step. For technical questions stackoverflow is a great source. Many libraries, frameworks and systems have their own specialized forums, mailing lists and wikis. Oh and don’t forget their bug trackers.


• RTFM: I know it is boring to read documentation. But if you working with a technology every day you should read the main pieces of documentation. Yes I’m thinking of such interesting works like the Java Language Specification or Oracle Database Concepts or HTTP: The Definitive Guide.


• Know whom to ask when your team mates can’t help: If you encounter someone who seems to be knowledgeable about a domain, make sure you have her email address available. And don’t be afraid to ask. Most people consider it a real nice compliment when somebody whom they only met once asks them a difficult technical question.


• Use the source: A lot of the stuff we use today is open source. So when Hibernate doesn’t behave as you think it should or if Mockito does cool things which might be useful for your DSL, get the source code and get a look at it. If you don’t spend lots of time with it, you probably won’t really understand the source code, but often it will give you hints on what you might do to solve the problem.


• Solve a different problem: Sometimes thinking about something else, taking a break and going for a work is all that it takes for a solution or at least a new idea to surface. Just make sure you have something to write with you.

What today's software developers need to know

--

Ref:  http://www.javaworld.com/javaworld/jw-09-2011/110915-modern-programming-skills.html


--

Don't Rewrite Your Application

Ref: http://java.dzone.com/articles/dont-rewrite-your-application

When stuck with a legacy code base you’ll hear the claim “We’ll have to rewrite this from scratch in order to fix it!” It sounds promising. You start with a clean slate. You can do all the good stuff without all the mistakes. The only problem: It doesn’t work. Here is why.

1. What every you might think of the code base and the developers that created it: They weren’t stupid nor evil. So chances are the results of your work will look just as ugly in two years from now.
2. You don’t know the requirements: Part of the reason legacy code bases are ugly is that requirements change. There is no reason for you to assume this won’t stop.So chances are the results of your work will look just as ugly in two years from now.
3. You don’t have the time: As long as the rewrite isn’t done, you’ll need to maintain and probably evolve the current application. If it is of any importance, you can’t ignore it for the months to come. If you can you should do so without wasting your time with a rewrite.

Instead of rewriting the application refactor it. Learn to properly estimate the effort needed for implementing new features in a clean way. Add some time to make the code immediately around that new feature a little cleaner as well. Use that as estimate. This way the application will become a little cleaner with every update. Nobody needs to spend a huge lump of money without a good chance on a reasonable ROI. Instead you spend a little money and get what you paid for. The interesting effect of this approach is: The part of the code changed often will become cleaner fast. And nobody should be concerned to much with code that doesn’t change anyway.

If you can’t implement new features in a clean way I claim: You aren’t really able to implement the whole application in a clean way from scratch either.

There are only a few cases in which I’m willing to believe a rewrite is benefical:

1. Change of basis technology: Is the legacy code written in Cobol and you will loose the last machine running that? Is it  a rich client and it must become an internet application? You might not have a choice.
2. Change of scope: Is 80% of code not needed anymore due to some changes in requirements? And you have to implement just as much for new features? You are doing a rewrite anyway.
3. Tiny application: When the rewrite is done end of the week, I guess it is Ok to do it. But I still recommend doing it using refactorings. It will teach you the technique for the next larger legacy application.
4. Somebody is willing to pay for the rewrite, but not for the effort needed to keep new code clean. It sounds extremely stupid to me, but I was told this happens …

From http://blog.schauderhaft.de/2011/02/20/dont-rewrite-your-application/

Oracle System Queries for Retrieving Oracle Database Object Information

Oracle System Queries for Retrieving Oracle Database Object Information

Ref: http://www.razorsql.com/articles/oracle_system_queries.html


The following contains information on how to retrieve database information for Oracle objects such as tables, views, indexes, packages, procedures, functions, and triggers. The queries all query the Oracle system views located in the SYS schema.

Tables

This is a query to get all Oracle tables that can be viewed by the current user.

select TABLE_NAME, OWNER from SYS.ALL_TABLES order by OWNER, TABLE_NAME

The query can be filtered to return tables for a given schema by adding a where OWNER = 'some_schema' clause to the query.



Schemas

This is a query to get all Oracle schemas in an Oracle database instance.

select USERNAME from SYS.ALL_USERS order by USERNAME



Views

This is a query to get all Oracle views that can be viewed by the current user.

select VIEW_NAME, OWNER from SYS.ALL_VIEWS order by OWNER, VIEW_NAME

The query can be filtered to return views for a specific schema by adding a where OWNER = 'some_schema' clause to the query.



Packages

This is a query to get all Oracle packages that can be viewed by the current user.

select OBJECT_NAME, OWNER from SYS.ALL_OBJECTS where UPPER(OBJECT_TYPE) = 'PACKAGE' order by OWNER, OBJECT_NAME

To query for package bodies, substitute PACKAGE BODY for PACKAGE.

The query can be filtered to return packages for a specific schema by adding a where OWNER = 'some_schema' clause to the query.



Procedures

This is a query to get all Oracle procedures that can be viewed by the current user.

select OBJECT_NAME, OWNER from SYS.ALL_OBJECTS where upper(OBJECT_TYPE) = upper('PROCEDURE') order by OWNER, OBJECT_NAME

The query can be filtered to return procedures for a specific schema by adding a where OWNER = 'some_schema' clause to the query.



Procedure Columns

This is a query to get the columns in an Oracle procedure.

select OWNER, OBJECT_NAME, ARGUMENT_NAME, DATA_TYPE, IN_OUT from SYS.ALL_ARGUMENTS order by OWNER, OBJECT_NAME, SEQUENCE



Functions

This is a query to get all Oracle functions for the current user.

select OBJECT_NAME, OWNER from SYS.ALL_OBJECTS where upper(OBJECT_TYPE) = upper('FUNCTION') order by OWNER, OBJECT_NAME

The query can be filtered to return functions for a specific schema by adding a where OWNER = 'some_schema' clause to the query.



Triggers

This is a query to get all Oracle triggers for the current user.

select TRIGGER_NAME, OWNER from SYS.ALL_TRIGGERS order by OWNER, TRIGGER_NAME

The query can be filtered to return triggers for a specific schema by adding a where OWNER = 'some_schema' clause to the query.



Indexes

This is a query to get all Oracle indexes.

select INDEX_NAME, TABLE_NAME, TABLE_OWNER from SYS.ALL_INDEXES order by TABLE_OWNER, TABLE_NAME, INDEX_NAME

ORACLE SEQUENCE COLUMN BASED ON ORDER BY OF OTHER COLUMN

Ref: http://forums.oracle.com/forums/thread.jspa?threadID=1026326



I have a table which is having lots of rows . I wish to update column (recno) with a sequential number from 1 to 75,000 order by mycolumn.

Password retrieval Websphere

Ref:
WebSphere Password Decoder

Most of the times we cannot recall the database passwords configured in Websphere AS.
If you ever need to decode a password use the following tip.

Passwords are stored in resource.xml or security.xml in encoded (not encrypted) form.
To decode, WAS provides a class which does that.
java -classpath /deploytool/itp/plugins/com.ibm.websphere.v61_6.1.200/ws_runtime.jar com.ibm.ws.security.util.PasswordDecoder "{password with {xor}}"

For WAS versions 7 and more,
java -Djava.ext.dirs=/deploytool/itp/plugins/com.ibm.websphere.v7_7.0.1.v20090422_1423/wasJars/ -cp securityimpl.jar com.ibm.ws.security.util.PasswordDecoder "{password with {xor}}"

Remember that you need double quotes around password and it works only for older than 7.0 versions.

The Mysteries of Business Object

Ref: http://javaboutique.internet.com/tutorials/businessObject/
The Mysteries of Business Object



Definition : Business Objects represent tangible entities within an application that the users create,access and manipulates while performing a Use Case. The Business Objects within a system are typically stateful, persistent and long-lived. Business Objects contain business data and models the business behavior.

--

How to Embed Existing Files into Open Office Text document

There is a procedure to link the file in to Microsoft Office document as a Display Icon which is available at http://www.associatedcontent.com/article/321749/how_to_embed_existing_files_into_microsoft.html

Here I would like to explain how to do the same using OpenOffice.org suite

Step 1:

Click on the Insert section of tool bar and you will be able to an option with name Object. After clicking on Object you would be able to see OLE Object as further option and click on it.

Simply Insert --> Object--> OLE Object

Step 2:

Now a window opens something like below, then click on Further Objects and Click OK button.

Step 3: You are almost done after this step.

Now you have to select Create From File Option and then select the document to embed and click OK button.Same is show below. By now the file will be embedded in the sheet.

Finally the doc will look like below...

--

Thanks

Fedora -- Create Duplicate or Clone root user account

If yo want a two root accounts for the Fedora OS you can achieve the way proposed below (Be careful doing these things):

http://www.labtestproject.com/create_root_user_account


--