James world

What are required for Leadership

2012-02-09T13:44:00.000-08:00

Good leader requires two things.
1. Version
2. Smart Followers

A good leader is a person who has a version and also group of skilled and smart people which follow him, and help him to achieve his versions.

A leader without a version is just a manager. A good manager does not need a version, but people skills, and can be a good follower.

A expert or specialist can help leaders to achieve something, but not necessary need either version or people skills.

In some cases, a good leader may not have people skills, and still having many followers, also still can be attractive to smart experts and specialists, like Steven Jobs. But he need a clear version.

In my opinion, Version is the most important factor to be a good leader. As clear and good version will attractive more smart people to follow.

JSF Managed Bean

2012-02-09T13:23:00.000-08:00

Today I made some changes JSF managed beans using annotation instead of XML. Below it is the example.

@ManagedBean(name="themeSwitcherBean") -- Declare it as managed bean
@RequestScoped
public class MyThemeSwitcherBean {

@ManagedProperty(value = "#{userAccountService}") -- How to reference spring bean or other managed bean.
UserAccountService userAccountService;

Eclipse errors and solutions

2012-01-10T08:08:00.000-08:00

1. javax.el.PropertyNotFoundException: /index.xhtml @12,39 value="#{user.name}": Target Unreachable, identifier 'user' resolved to null

reason: it could not load jsf bean.

Solution: a. check project-->properties --> build --> source code, if it is checked.
b. removed the tomcat server.
c. mvn eclipse:eclipse
d. add resources

How to create two doamins in one Tomcat instance

2012-01-09T05:57:00.000-08:00

Virtual Hosting and Tomcat

How to deal with Warning: This page calls for XML namespace primefaces.org/ui declared with prefix p but no taglibrary exists for that namespace.

2012-01-06T13:06:00.000-08:00

Yesterday I did a example using PRISMFACE, JSF2, and I got below error:

Warning: This page calls for XML namespace primefaces.org/ui declared with prefix p but no taglibrary exists for that namespace.

After I copied primeface jar into lib directory, everything is working. So wired.

I think this might be a Maven issue.

Where to put named queries in JPA?

2011-11-16T11:34:00.001-08:00

Please check below link

How to configure multiThread MDB in websphere

2011-11-14T08:27:00.000-08:00

The maximum sessions property determines how many messages an MDB can process simultaneously. The default value for this property is 1, which means that an MDB must finish processing the first message on the queue before it can process the second, and so on (for you programmers, this essentially means that an MDB is single-threaded).

If the application server is not under a heavy load, you might want to increase the throughput of messages. In this situation, you can increase the value of the maximum sessions property to enable an MDB to process more than one message at once (this makes the MDB multi-threaded). It is worth noting, though, that increasing the value of maximum sessions will increase the load on your system, since you will now have multiple instances of the MDB running at the same time!

Details please check below link

Spring reference card

2011-11-11T06:04:00.001-08:00

http://refcardz.dzone.com/refcardz/spring-configuration?oid=sb001

Design Pattern for Java resources

2011-11-11T05:54:00.001-08:00

http://www.dzone.com/links/r/design_patterns_object_oriented_design_repository.html

Why project failed

2011-10-27T06:46:00.000-07:00

Below it is a very interesting article

1. Reduce co-location makes communication difficult.
2. Loss of key players will take months to recovery.
3. new technology learning curve.
4. New team need to time to build.

HTML 5 Magic

2011-10-08T17:57:00.000-07:00

Today I did some research regaridng HTML5, it is really impressive. I have the feeling HTML 5 will be the next wave on web. Below are some features:

1. SVG
2. VIDEO
3. GEOLOCATION
4. Cache and Database
5. Web wroker

Why Software Is Eating The World

2011-10-03T08:46:00.001-07:00

Today I read a article which is very useful to inspire the developers.

Please check the link.

Best way to use Constractor

2011-09-30T12:54:00.000-07:00

I had been working as consultant for about two months already. One interesting thing I found in those days regarding how to use consultant effectively.

1. Hire technical expert as technical leader, so other team members can learn from him. This way is better than hiring a trainer. This works very well if this company run into a new technical area.
2. Hire Junior consultants doing heavy load and lower technical tasks. Also those works are perfect for outsourcing.
3. Team members should include both full-time and contractors. A team contains only contractors will face long term maintainability issues in the long run. Some one in the team should audit the quality.

"Knowledge can be conveyed, but wisdom is only earned by experience of trying"

Check List for new project before coding

2011-09-23T05:59:00.001-07:00

I recently read a article talking about check list before coding, it is very interesting, please check the link

Mutable and Immutable Objects for Java

2011-09-15T06:14:00.001-07:00

Below it is a nice article regarding this topic.

what is portalet and portal (JSR168)

2011-08-11T19:06:00.001-07:00

Please reference this article.

4 mistakes regarding tomcat

2011-08-04T19:17:00.000-07:00

I just read a article regarding tomcat, please check.

About session security

2011-07-20T08:59:00.000-07:00

Today I read a good article regarding session security, I want to share with you.

Please click for article

Below it is the summary.

Always regenerate a session ID (SID) when elevating privileges or changing between HTTP and HTTPS.
Check for suspicious activity and immediately destroy any suspect session.
Store all session information server-side, never store anything except the SID in the client-side cookie.
Confirm SIDs aren't from an external source, and verify the session was generated by your server.
Don't append the SID to URLs as a GET parameter.
Expire sessions on the server side, don't rely on cookie expiration to end a user session.
Use long and unpredictable session IDs.
Properly sanitize user input before setting headers with them.
When a user logs out, destroy their session explicitly on the server.
Check your session configuration.
Force users to re-authenticate on any destructive or critical actions.

Spring singleton and prototype

2011-07-19T17:57:00.000-07:00

Recently I was asked something regarding spring singleton, below are some of my thought.

1. First Spring singleton is not same as java singleton. For example.

SampleBean beanOne = (SampleBean)context.getBean(“sampleBean1”);
SampleBean beanTwo = (SampleBean)context.getBean(“sampleBean2”);

Evern in spring application context, samepleBean1 and sampleBean2 refer to the same implementation, they are still not the same.

In Java singleton, they are the same thing.

2. For exmaple:
SampleBean beanOne = (SampleBean)context.getBean(“sampleBean”);
SampleBean beanTwo = (SampleBean)context.getBean(“sampleBean”);

Under singleton scope, beanOne is the same as beanTwo.
Under prototype scope, beanOne <> beanTwo

tomcat class loading thining

2011-06-21T06:44:00.000-07:00

In the last couple years, I have been working with TOMCAT, we always use fat war file, which each web application use their own lib, there are very few library in common tomcat lib directory.

Good: Different application can use different version library, easy to configure, no library conflict issue.
Bad: I guess memory might be a issue. As every web application will start their own version.

Today I check one of the web application implementation in websphere, in web library, there are lot of common libraries.

Good: I guess most EJB related library should be in common.

Software development methods Funny words

2011-06-16T07:51:00.000-07:00

1. KISS: Keep it simple stupid
2. DRY: Do not repeat yourself
3. YAGNIl: You ain't gonna need it.

For point one and point three, I really experienced a lot in the last 10 years. Most of the time, system is getting complicated just because of poor design, overdesign. Also the system was built a lot of extra nice features which never been used, it also makes simple application complicated.

4. Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.) http://en.wikipedia.org/wiki/Law_of_Demeter

How to mitivate a developer

2011-06-08T14:38:00.000-07:00

Today I read a article which I totally agree with it. Details please check below link.

http://www.theserverside.com/tip/Five-ways-to-motivate-your-development-team

1. Give your developers the resources they need.
2. Recognize a job well done
3. Get rid of dead wood
4. Push for new software releases
5. Let developers develop

use maven to create a basic project

2011-05-18T08:35:00.000-07:00

mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.2 -DgroupId=com.travelsoft.services -DartifactId=HostServices

When Agile/Scrum should NOT be used

2011-05-18T06:30:00.000-07:00

Today I read this article, it is very interesting. And I agree most of the points he list there. Details please check. http://blog.matrixresources.com/blog/when-agilescrum-should-not-be-used

Below are the list of quotes which I think are useful.

1. Non-High Profile Project
2. Stable Technology
3. No Major Process Innovation
4. Requirements are Stable
5. Quick Time to Market not Needed

Resource Characteristics:

1. Inability to Co-located
2. Low Cost Talent Available
3. Team Size Varies
Company Characteristics:

1. Command and Control Company Culture: “dictator” type project management
2. Contracts Require Full Scope and Documentation

Encrypt a password in JPA persistent.xml

2011-05-17T08:10:00.000-07:00

Below is a example how to encrypt password in JPA persistent.

1. Generate a encrypted password (See previous blog)
2. Add below entrance into spring applicationcontext.xml

PBEWithMD5AndDES

JAMES_PWD

4

strongHibernateStringEncryptor

3. change persistent.xml

value="org.jasypt.hibernate.connectionprovider.EncryptedPasswordDriverManagerConnectionProvider"/>

How to encrypt password in spring configuration file

2011-05-17T06:15:00.001-07:00

I just finish a project which use "jasypt" to encrypt the password in spring configuration file. Below are the steps and notes.

1. Regarding Maven entrance, please check below

org.jasypt
jasypt
1.7.1

2. Develop a program to encrypt password.

StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
encryptor.setAlgorithm("PBEWithMD5AndDES");
encryptor.setPassword("JAMES_PWD"); // could be got from web, env variable...
return encryptor.encrypt(input) ;
3. Create a environment variable to hold temporary password
APP_ENCRYPTION_PASSWORD = JAMES_PWD

4. Change your spring configuration file to read property from file.

class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">

class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">

-->

class="org.jasypt.spring.properties.EncryptablePropertyPlaceholderConfigurer">

classpath:connection.properties

Comments after reading Test First development blog

2011-04-26T09:05:00.000-07:00

Today, I read this very interesting blog regarding Test first development, link is below.
http://xebee.xebia.in/2011/04/26/take-aways-from-dr-venkats-session-on-test-first-development/

There are something really draw my attentions:

1. the importance of creating an environment to make people do the right thing than to force them to do it. The right environment can be created through leading by example and assertive communication
2. Hiring by attitude, and train for skill.
3. he gave a magnificent example by citing a movie "A Few Good Men". He told that during an argument inside the court in the movie, someone quoted a rule. And then, Tom Cruise came with the rule book in his hand asking the other person to show him rules for each and everything that he did ( "You eat 3 times a day, can you show it in the rule book. Oh God, How can you eat 3 times a day when its not written in the rule book").
4. in the end, he said, sometimes its almost impossible to correct things and then you can say to yourself that its just a job. In my home, I can do and will do things exactly the way I like, however, in a job, this might not be the case.

How to get file from filename

2011-04-20T08:43:00.000-07:00

Recently I had a issue regarding how to read a file, as in eclipse environment and actually server environment, the relative directory is different, it caused a lot of problem, below it is a example which works for both environment.

File file ;
URL url = this.getClass().getClassLoader().getResource(fileName);

try {
file = new File(url.toURI());
} catch(URISyntaxException e) {
file = new File(url.getPath());
}

or to a string

URL loadedResource = this.getClass().getClassLoader().getResource(fileName);

InputStream inputStream = loadedResource.openStream();

BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
StringBuilder sb = new StringBuilder();
String line = null;
while ((line = reader.readLine()) != null) {
sb.append(line + "\n");
}
inputStream.close();
return sb.toString();

How to get salary increase by Eric spiegel

2011-04-12T11:37:00.001-07:00

5) A developer’s best chance at achieving a maximum salary increase is to negotiate during the hiring process. Once you are on board, you are at the company’s mercy unless you bail

Very interesting idea I have to agree

Failure and innovative

2011-04-11T10:30:00.001-07:00

Woody Allen :

If you are not failing every now and again, it is a sign you are not doing anything very innovative.

The only real failure in life is one not learned from

Command and control

2011-03-29T08:46:00.001-07:00

Smart people does not like to be controlled. And also can not be controlled.

People who close to work can make better decision than most of the managers.

Comments on how to Manage developers

2011-03-08T10:30:00.000-08:00

Below are some ideas and experience I want to blog about how to be a good developer manager

1. Manager is not about managing people, no one want to be managed. Good manager should know manage himself first, create a better environment for developers to manage themselves too. Lead by example and show people the direction, let others to follow themselves.

2. You have to know your team better.
a. Knows who is key people in the group, identify the key people is very important, you will know whom you should invest more time and money into.
b. Knows who is the expert but not a team player, who perform best inside a team, who perform best individual.
c. Knows each one's color (color theory)
d. Understand your team's ability and capacity. Do not try to stretch too much, as it will demotivate people.

3. Treat people with respect, never manipulate other people. If you do not want others do to you, do not do it to other people.

4. Social activity, such as lunch each Friday together if it is possible.
5. Learning activity, ask one developer to do a presentation each week. Helps to exchange the knowledge between developers.

6. Provide best equipment to developers will help them to high productivity.

7. Provide best working environments you can get, do not underestimate any complains about desk, noise, or other small things, as that could cause big issues to some people.

8. Prepare some group contest, or mind games once a month? or two weeks to enhance team work.

9. Only assign 80% of your capacity most of the time, if some developers tell you they are not in the mood, then you have room to give them some time to step back. Making sure they are working in high spirit. As developers productivity are not measured by hours.

Hiring strategy

2011-03-01T07:28:00.000-08:00

hire-above-the-mean (or Lake Wobegon). Always hire people better than yourself.(???)

a. Always hire developers better than we have currently (IQ + EQ) at the same level.
b. When we measure the skill, we also need to consider the future grow.
c. For Senior position, skill + experience = 60%, EQ = 20%, 20%= future grow
For Intermediate position, skill + experience = 40%, EQ = 30%, 30%= future grow
For Junior position, skill + experience = 20%, EQ = 30%, 50%= future grow

Low EQ means low team spirit. Depends on the position, some senior position which does not require high EQ, and those experts can and prefer individually, if we have those positions, then EQ is not really required.

Reference below link for more details.

http://lifeofaprogrammanager.blogspot.com/2006/06/good-reading-for-development-managers.html

Regarding how to prioritize a bug fix

2011-02-28T06:48:00.000-08:00

Today I read a very interesting article regarding regression testing.

Details please check http://www.ericsink.com/articles/Four_Questions.html

Every bug you found in your application, before you work on a fix, you should ask yourself below four questions:

Question One: When this bug happens, how bad is the impact? (Severity)

Question Two: How often does this bug happen? (Frequency)

Question Three: How much effort would be required to fix this bug? (Cost)

Question Four: What is the risk of fixing this bug? (Risk)

Reference: Normalization or Denormalization

2010-09-01T10:51:00.001-07:00

Databases: Normalization or Denormalization. Which is the better technique?

by ovais.tariq

This has really been a long debate as to which approach is more performance orientated, normalized databases or denormalized databases. So this article is a step on my part to figure out the right strategy, because neither one of these approaches can be rejected outright. I will start of by discussing the pros and cons of both the approaches.
Pros and Cons of a Normalized database design.

Normalized databases fair very well under conditions where the applications are write-intensive and the write-load is more than the read-load. This is because of the following reasons:

* Normalized tables are usually smaller and have a smaller foot-print because the data is divided vertically among many tables. This allows them to perform better as they are small enough to get fit into the buffer.
* The updates are very fast because the data to be updated is located at a single place and there are no duplicates.
* Similarly the inserts are very fast because the data has to be inserted at a single place and does not have to be duplicated.
* The selects are fast in cases where data has to be fetched from a single table, because normally normalized tables are small enough to get fit into the buffer.
* Because the data is not duplicated so there is less need for heavy duty group by or distinct queries.

Although there seems to be much in favor of normalized tables, with all the pros outlined above, but the main cause of concern with fully normalized tables is that normalized data means joins between tables. And this joining means that read operations have to suffer because indexing strategies do not go well with table joins.

Now lets have a look at the pros and cons of a denormalized database design.
Pros and cons of denormalized database design.

Denormalized databases fair well under heavy read-load and when the application is read intensive. This is because of the following reasons:

* The data is present in the same table so there is no need for any joins, hence the selects are very fast.
* A single table with all the required data allows much more efficient index usage. If the columns are indexed properly, then results can be filtered and sorted by utilizing the same index. While in the case of a normalized table, since the data would be spread out in different tables, this would not be possible.

Although for reasons mentioned above selects can be very fast on denormalized tables, but because the data is duplicated, the updates and inserts become complex and costly.

Having said that neither one of the approach can be entirely neglected, because a real world application is going to have both read-loads and write-loads. Hence the correct way would be to utilize both the normalized and denormalized approaches depending on situations.
Using normalized and denormalized approaches together.

The most common way of mixing denormalized and normalized approaches is to duplicate related columns from one table into another table. Let me show you by example:

Suppose you have a products table and an orders table.
The normalized approach would be to only have the product_id in the orders table and all the other product related information in the products table.

But that would make the query that filters by product_name and sorts by order_date inefficient because both are stored in different tables.

In a fully normalized schema, such a query would be performed in the following manner:

SELECT product_name, order_date
FROM orders INNER JOIN products USING(product_id)
WHERE product_name like 'A%'
ORDER by order_date DESC

As you can see MySQL here will have to scan the order_date index on the orders table and then compare the corresponding product_name in the products table to see if the name starts with A.

The above query can be drastically improved by denormalizing the schema a little bit, so that the orders table now includes the product_name column as well.

SELECT product_name, order_date
FROM orders
WHERE product_name like 'A%'
ORDER by order_date DESC

See how the query has become much simpler, there is no join now and a single index on columns product_name, order_date can be used to do the filtering as well as the sorting.

So can both the techniques be used together? Yes they can be, because real word applications have a mix of read and write loads.
Final words.

Although, denormalized schema can greatly improve performance under extreme read-loads but the updates and inserts become complex as the data is duplicate and hence has to be updated/inserted in more than one places.

One clean way to go about solving this problem is through the use of triggers. For example in our case where the orders table has the product_name column as well, when the value of product_name has to be updated, then it can simply be done in the following way:

* Have a trigger setup on the products table that updates the product_name on any update to the products table.
* Execute the update query on the products table. The data would automatically be updated in the orders table because of the trigger.

However, when denormalizing the schema, do take into consideration, the number of times you would be updating records compared to the number of times you would be executing SELECTs. When mixing normalization and denormalization, focus on denormalizing tables that are read intensive, while tables that are write intensive keep them normalized.

Oracle Locks

2010-08-17T13:24:00.000-07:00

1. Pessimistic Locking = select for update no wait
2. Optimistic Locking Using a Version Column,
3. Optimistic Locking Using a Checksum, CPU time

DEADLOCK is because foreign key is not indexed.

delete a parent will cause lock child table.

update or delete primary key will cause the same issue, when using ORM, the sql generated might do that.

5 low-risk, high-reward experiments for IT

2010-05-19T06:56:00.000-07:00

Just read one article which is very interesting.

http://www.infoworld.com/d/developer-world/5-low-risk-high-reward-experiments-it-454

Low-risk IT experiment No. 1: APIs
Low-risk IT experiment No. 2: Social networks
Low-risk IT experiment No. 3: Mobile apps
Low-risk IT experiment No. 4: Geocoding
Low-risk IT experiment No. 5: NoSQL

Scalability

2010-05-13T08:47:00.001-07:00

A Word on Scalability
By Werner Vogels on March 30, 2006 5:21 PM | Permalink | Comments (7) | TrackBacks (3)

Scalability is frequently used as a magic incantation to indicate that something is badly designed or broken. Often you hear in a discussion “but that doesn’t scale” as the magical word to end an argument. This is often an indication that developers are running into situations where the architecture of their system limits their ability to grow their service. If scalability is used in a positive sense it is in general to indicate a desired property as in “our platform needs good scalability”.

What is it that we really mean by scalability? A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to resources added. Increasing performance in general means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.

In distributed systems there are other reasons for adding resources to a system; for example to improve the reliability of the offered service. Introducing redundancy is an important first line of defense against failures. An always-on service is said to be scalable if adding resources to facilitate redundancy does not result in a loss of performance.

Why is scalability so hard? Because scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, such that adding resources actually results in improving the performance or that if redundancy is introduced the system performance is not adversely affected. Many algorithms that perform reasonably well under low load and small datasets can explode in cost if either requests rates increase, the dataset grows or the number of nodes in the distributed system increases.

A second problem area is that growing a system through scale-out generally results in a system that has to come to terms with heterogeneity. Resources in the system increase in diversity as next generations of hardware come on line, as bigger or more powerful resources become more cost-effective or when some resources are placed further apart. Heterogeneity means that some nodes will be able to process faster or store more data than other nodes in a system and algorithms that rely on uniformity either break down under these conditions or underutilize the newer resources.

Is achieving good scalability possible? Absolutely, but only if we architect and engineer our systems to take scalability into account. For the systems we build we must carefully inspect along which axis we expect the system to grow, where redundancy is required, and how one should handle heterogeneity in this system, and make sure that architects are aware of which tools they can use for under which conditions, and what the common pitfalls are.

How we solved – GC every 1 minute on Tomcat

2010-05-07T07:04:00.000-07:00

Then I researched the JVM Options and found this option

-XX:+DisableExplicitGC

zt: How to Keep Crappy Programmers

2010-04-28T07:51:00.000-07:00

This is a follow-up to the popular How to Find Crappy Programmers. If you’re interested in having a team of crappy programmers, instead of those annoyingly bright and passionate good ones, you probably want to start there.

Despite your best efforts, some good programmers slip through the cracks – how can you get rid of them while keeping your coveted crappy programmers around?

1. Focus on Punctuality and Butt-In-Seat Time

Never mind that a good programmer can produce more valuable work in a 30-hour workweek from home than a crappy programmer can toiling 60 hours in the office. There’s no point in getting useful software in a timely manner if you don’t get the all-important face time.

Good products are nice, but there’s nothing more fulfilling in a manager’s life than seeing a roomful of people, heads-down, typing away in tiny cubicles at 8:00 am in the morning. Coming in at 9:30 am is wholly unacceptable – those guys are just having too much fun.

You get people on salary so that they aren’t on the clock, and that way you don’t have to pay extra when they work longer than 8 hour days. Then again, don’t be afraid to insist that they work at least 8 hour days all the time. Who cares if they have nothing to do, or if they have already gotten way more done than the guy next to them, surfing the internet? It’s butt-in-seat time, baby.

2. Set Their Salary Based on Their Age or Time at the Company

Setting salary based on your age makes a lot of sense since you, the manager, are probably old. That way you get more money. Since that’s illegal, you should base the pay on “years of experience” which equates to age for everyone who didn’t go on a 5-year+ sabbatical. Don’t worry, that’s pretty much only working moms, and you probably don ‘t want to pay them much either.

You might have an employee who’d rather be paid based on their productivity or the value of their work or even their skill level. Blasphemy! Clearly, that person is just looking for a free ride, without having to pay their dues. Say it with me people: “We care about everything except for the actual work you produce.”

3. Reduce Time Spent Coding

It’s important for developers to spend a lot of time in meetings. That way they can get a complete understanding of the minutia in the business side of things. And also, it’s more fun to have a big audience when you ramble on in meetings. Don’t worry that we won’t have any time left to do actual work (ie. coding), we’ll just come in early and stay late to get that part done.

Another fun thing is having your programmers do your desktop support. Really, anytime your Outlook or your iPhone is acting up, feel free to call them over to troubleshoot the issue. It’s so handy having geeks around.

4. Monitor and filter their Internet usage

Developers just can’t be trusted, everyone knows that. We are always hacking things and downloading illegal music and that sort of thing. So, you should definitely install a program to monitor their internet usage. You could also block sites that you deem to be a waste of time, but then that might tip your hand that you’re monitoring them.

For that matter, you ought to go ahead and dictate what development environment and tools they have to use. After all, you picked the setup with the longest feature list (not to mention the sales guy took you to lunch) so those developers shouldn’t have anything to complain about. Anyone who wants to use anything else is just a prima donna.

5. Make Them Build Crappy Software

This is the most important one of all. A crappy programmer can only make crappy software. However, a good programmer has the ability to make both good software and crappy software, right? Wrong!

Good programmers hate writing crappy software. They’re always yammering on about code design and trying to test everything, what a pain.

Force them to write inline queries, develop in VB on the command line and fix bugs in 1,000 line methods. They may fight it at first, but pretty soon they either leave or become a crappy programmer also. You’ll know that they’ve come over to the dark side when you see that empty look in their eyes and when they see a Dilbert cartoon they laugh … maniacally.

The reality is that not everyone is interested in managing good programmers. Sure they get things done and know a lot about technology … yadda yadda. They also challenge your assumptions and push to improve the system and that’s just not going to work in your business.

The fact that it’s been done that way before and hasn’t imploded yet (or lately) is good enough for you. You can use these handy tips to keep your crappy programmers while firmly excluding the good ones.

Testing what Errors

2010-03-05T06:59:00.000-08:00

http://agile.dzone.com/news/alternatives-acceptance

* Programmer errors occur when a programmer knows what to program but doesn't do it right. His algorithm might be wrong, he might have made a typo, or he may have made some other mistake while translating his ideas into code.

* Design errors create breeding grounds for bugs. According to Barry Boehm (PDF), 20% of the modules in a program are typically responsible for 80% of the errors. They're not necessarily the result of an outright mistake, though. Often a module starts out well but gets crufty as the program grows.

* Requirements errors occur when a programmer creates code that does exactly what she intends, but her intention was wrong. Somehow she misunderstood what needed to be done. Or, perhaps, no one knew what needed to be done. Either way, the code works as intended, but it doesn't do the right thing.

* Systemic errors make mistakes easy. The team's work habits include a blind spot that lets subtle defects escape. In this environment, everybody thinks they're doing the right thing--programmers are confident that they're expressing their intent, and customers are confident that programmers are doing the right thing--yet defects occur anyway. Security holes are a common example.

How to split a log file in tomcat

2010-03-01T06:23:00.000-08:00

Tomcat log file splitter procedure:

1. Replace tomcat-juli inside bin\

2. Copy commons-logging-1.1.1, log4j.jar, and tomcat-juli-adapters to lib directory

3. Change log4j.p file in lib

4. Delete logging.properties in conf directory

Difference between junior or Senior developer

2010-03-01T06:21:00.000-08:00

Width and Depth.

Senior can see the forest, not only trees. They have more tools in their skill set. They know where to find a bug, not only fix a one.

How to mitivate developers.

2010-01-04T07:34:00.000-08:00

here is the detail.

Difference between labor and professional

2009-12-07T11:04:00.001-08:00

The difference between a laborer and a professional is that a laborer takes orders from his boss, and a professional provides input to his superiors. Laborers are hired to take direction. Professionals are hired to ensure that the direction chosen makes sense.

A guide to Java SimpleDateFormat in examples

2009-11-18T11:32:00.001-08:00

http://www.javablogging.com/java-simpledateformat-examples/

November 17, 2009 - Author: ppow

Today I want to show you some examples of how you can use SimpleDateFormat class in your code. I hope some of them will be new and surprising!

The basic example

First the most basic usage of the class. Lets use it to format Date object into a simple string showing day, month and a year:

1:
2:
3:
4:
5:
6:

SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("dd/MM/yy");
String dateAsString = simpleDateFormat.format(new Date());

System.out.println(dateAsString);
// Result: "12/11/09"

Slightly more advanced

Obviously we can use more complicated patterns than that (see SimpleDateFormat JavaDoc for the full list). Besides adding more data to be shown we can also add some regular text – to do that in a pattern you need to escape the text with an apostrophe. So here is a fancy way of printing the time and date:

1:
2:
3:
4:
5:
6:

SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("hh:mm 'o''clock on' MMMM dd yyyy");
String dateAsString = simpleDateFormat.format(new Date());

System.out.println(dateAsString);
// Result: "06:49 o'clock on November 12 2009"

Now with Locale

SimpleDateFormat is Locale dependent, so by providing one you can get the Date string localized for specific language or country. This is a date in French:

1:
2:
3:
4:
5:
6:

SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("dd MMMM yyyy zzzz G", Locale.FRENCH);
String dateAsString = simpleDateFormat.format(new Date());

System.out.println(dateAsString);
// Result: "12 novembre 2009 Heure du méridien de Greenwich ap. J.-C."

Parse String to Date

Good thing about the SimpleDateFormat class is that it can be used not only for formatting, but also for parsing string into a Date object. In this example the used pattern is exactly the same as used by Date.toString() method. With it we can parse the strings created by Data.toString() back into dates:

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

// SimpleDateFormat that works exactly like Date.toString()
SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("E MMM dd HH:mm:ss zzz yyyy", Locale.ROOT);
Date today = new Date();

String dateAsString_format = simpleDateFormat.format(today);
String dateAsString_native = today.toString();
// Both strings are: "Thu Nov 12 18:49:36 GMT 2009"

Date parsedDate = simpleDateFormat.parse(dateAsString_native);
System.out.println(parsedDate.toString());
// Result: "Thu Nov 12 18:49:36 GMT 2009"

Setting the default time zone

Notice that when you parse a string into a Date the result may be ambiguous. For example the string “11:23 1 Jan 2001″ is a different moment in time depending whether you live in Japan or Canada. By default Java resolves this by using your local time zone obtained from the default Locale.

Since the time zone may not be a part of the parsed string you may want to set it manually instead using the default one. You can do this with setTimeZone() method:

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("dd-MM-yyyy", Locale.ENGLISH);
Date date = simpleDateFormat.parse("13-07-1999");
System.out.println(date);
// Result: "Tue Jul 13 00:00:00 GMT 1999"

simpleDateFormat.setTimeZone(TimeZone.getTimeZone("PST"));
date = simpleDateFormat.parse("13-07-1999");
System.out.println(date);
// Result: "Tue Jul 13 08:00:00 GMT 1999"

Setting the century

Similar ambiguity occurs when parsing two-digit year dates. Whether “01/01/59″ is the new year’s day of 1959 or 2059 can be set by specifying the century to the SimpleDateFormat object. To be specific with set2DigitYearStart() method you can specify the 100 year period in which the parsed date will be placed. By default the 100 year period is [today - 80 years, today + 20 years]. See the example:

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:

SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("dd MMMM yy", Locale.ENGLISH);
Date date = simpleDateFormat.parse("1 November 45");
System.out.println(date);
// By default the year 45 will be taken from period 1929 - 2029
// Result: "Thu Nov 01 00:00:00 GMT 1945"

Date startOf19thCentury = new GregorianCalendar(1801,1,1).getTime();
Date startOf21stCentury = new GregorianCalendar(2001,1,1).getTime();

simpleDateFormat.set2DigitYearStart(startOf19thCentury);
date = simpleDateFormat.parse("1 November 45");
System.out.println(date);
// After invoking set2DigitYearStart() the period is now 1801 - 1901
// Result: "Thu Nov 01 00:00:00 GMT 1845"

simpleDateFormat.set2DigitYearStart(startOf21stCentury);
date = simpleDateFormat.parse("1 November 45");
System.out.println(date);
// This time the period is 2001 - 2101
// Result: "Thu Nov 01 00:00:00 GMT 2045"

Make the parsing more strict

By default the parse method of SimpleDateFormat is very forgiving. If the provided string is not entirely compatible with the pattern, SimpleDateFormat instead of giving up tries with many tricky heuristics to guess what would be the correct answer. In many situations this behavior is more than welcome, but if you do not like this you can disable it. With setLenient() method you can make the parsing obey exactly the pattern and throw an exception if string is invalid.

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

SimpleDateFormat simpleDateFormat =
       new SimpleDateFormat("dd MMMM yyyy", Locale.ENGLISH);
Date date = simpleDateFormat.parse("31 April 1999");
System.out.println(date);
// Since April has only 30 days the parser will assume
// user meant April 30th + one day = May 1st
// Result: "Sat May 01 00:00:00 GMT 1999"

// Make the parsing more strict
simpleDateFormat.setLenient(false);
// This throws java.text.ParseException: Unparseable date: "31 April 1999"
date = simpleDateFormat.parse("31 April 1999");

10 Java Regular Expression Examples You Should Know

2009-11-18T11:00:00.000-08:00

http://www.mkyong.com/regular-expressions/10-java-regular-expression-examples-you-should-know/

Manager manage the system, not the people

2009-10-21T06:49:00.000-07:00

Here is the article.

Manager should create a system which:

1. People can do their job efficient.
2. People can get and give feedback.
3. People can grow.

How to get property value using spring

2009-10-14T07:50:00.000-07:00

Today I read a useful posting regarding using property file.

Article

Agile vs Lean

2009-10-07T07:39:00.000-07:00

The 4 principles of Lean Development are:

-Add Nothing But Value (Eliminate Waste)
-Center On The People Who Add Value
-Flow Value From Demand
-Optimize Across Organizations

The Agile Manifesto says:

-Individuals and interactions over processes and tools
-Working software over comprehensive documentation
-Customer collaboration over contract negotiation
-Responding to change over following a plan

waterfall vs rup vs scrum vs lean

2009-10-07T07:20:00.000-07:00

Recently I got a very interesting blog regarding difference between above project methods.

Here’s a VERY simple overview of the main differences between Waterfall Development, Iterative Waterfall Development, Scrum/Agile Development and Lean.

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
You leave the testing until the end, which means you’re leaving issue discovery until late in the day
You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment. It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way.

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

Why software is expensive

2009-10-06T06:45:00.000-07:00

I just read a post from http://itscommonsensestupid.blogspot.com/2009/10/why-software-is-expensive.html, it is very interesting, below it is the points.

Software is expensive because there are huge overhead costs associated with software development. Computer equipments are expensive. And the fact that software developers need to stay on the cutting edge of the technology means that they need to always upgrade their hardware. Also, software methodologies and tools change very often, software developers need to invest a lot of time and money to just to keep up with the development so that they can provide better service to their clients next time.
For those of you who think that hardware cost is "just of small fraction of the total cost", let me tell you that hardware is not cheap in third world countries; a mere acer laptop is costing as much as a programmer's one month salary here in Malaysia.
Software is expensive because there are a lot of research going into it. Some express puzzle at software developer apparent "low productivity" (20 lines of code per day). Assuming that you are charging USD 50 per hour, your rate is USD 20/line. This is awfully expensive to the business owners who measure productivity in terms of quantity produced. What they miss out is that programming productivity is all about writing less code to get your job done. A programmer could spend one billable month reinventing the wheel and produce a 10 million line-of-code ORM that is buggy, or spend one non-billable month to look for an open source implementation that is mature and well-developed, and endure the complain of low productivity. The way business owners complain about "research time" is encouraging the wrong type of behavior.
Software is expensive because the product owners don't know what they want. Imagine if you go to an architect, asking him to provide a blue print, and after he comes out with that you ask him to change it according to your latest taste-- even though it is contrary to the original specification, and you repeat this process,.. No one would dare to do this, but everyone seems to have no problem asking the software developers to change their code at last minute and expect everything to work just fine and the product ships in time and worse of all, is not willing to pay extra.
Software is expensive because it is customized only for you. The reason why Microsoft Office and Windows Vista is so cheap, is because the development cost is spread over million of users. The consequence of this is that there is no competitive advantage associated with the ordinary office or Windows Vista users. Your customized application, on the other hand, is designed especially for you, and you-- and no one else-- can enjoy the returns and benefits bring forth by the application.

URI, URL, URN

2009-09-29T08:22:00.001-07:00

Have you ever carefully noticed the string in the address bar of your browser? What is it? Is it a URI or URL or URN? Some of us can’t differentiate between URI and URL and URN. Some non technical persons even don’t know the terms URI and URN. They just call that string a URL. Let’s understand this concept in deep.

Full Forms:

URI - Uniform Resource Indicator
URL - Uniform Resource Locator
URN - Unifrorm Resource Name

Definition:

URI: A URI indicates the name and the address of the resource on the web. The URI is further subdivided into URL and URI. It means URL and URI are the components of URI. definition

URL: A URL is the address of some resource on the web. A URL defines how the resource can be obtained and from where it can be obtained.

URN: A URN is the name of some resource on the web. A URN does not imply the availability of the identified resource and never tells about how the resource can be obtained.

So, one can say URI = URL + URN

Example:

If i say “My name is Roy”, then it will be a URN, just telling the name of a person not the proper location.
If i say “I live in New York”, then it will be a URL, telling me the location of a person.
If i say “My name is Roy and I live in New York”, then its proprer URI.

Ambiguity: Its the matter of ambiguity whether the term URL is deprecated or not. Some argue yes and some no. Some say that the more correct term is URI, used in technical documentation. All URIs are means to access a resource on the Internet and are a technical short hand used to link to the resource. URIs always designate a method to access the resource and designate the specific resource to be accessed. So should we use the term URI instead of most popular term URL?

Conclusion:

URI is an abstract concept while URL and URN are the concrete implementations of a URI and one should always know the difference among all the three.

What is difference between n-tiered and n-layered

2009-09-28T11:14:00.000-07:00

Tiered is physical separation, for example client tier, database tier, application server tier
Layered is logical separation, for example presentation layer, business layer, DAO layer.

OOP principal

2009-09-17T05:59:00.000-07:00

The first five principles are principles of class design. They are:

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.

The next six principles are about packages. In this context a package is a binary deliverable like a .jar file, or a dll as opposed to a namespace like a java package or a C++ namespace.

The first three package principles are about package cohesion, they tell us what to put inside packages:

REP	The Release Reuse Equivalency Principle	The granule of reuse is the granule of release.
CCP	The Common Closure Principle	Classes that change together are packaged together.
CRP	The Common Reuse Principle	Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

ADP	The Acyclic Dependencies Principle	The dependency graph of packages must have no cycles.
SDP	The Stable Dependencies Principle	Depend in the direction of stability.
SAP	The Stable Abstractions Principle	Abstractness increases with stability.

What is architecture

2009-09-09T08:27:00.000-07:00

Fowler statement:

In most successful software project, the expert developer working on the project have a shared understanding of the system design. The shared system design is called "Architecture". The shared understanding includes how the system is divided into components and how those components interacts through interfaces. Those components are usually composed of small components, but the architecture only includes those components and interfaces that understandable by all developers. Architecture is about important stuff, whatever is.

Booch said:

All architecture are design, but not all design is architecture. Architecture represents the significant design decision that shapes a system where significant is measured by the cost of change.

The goal of architecture is eliminate the impact and cost of change.

Making everything easy to change makes the entire system complex.

Insteresting reading points

2009-08-24T07:08:00.000-07:00

A. Once you have a direction, you stick to it. But no matter how far you traveled to a wrong direction, turn around.
B. If the only tool you have is a hammer, then everything looks like a nail.
C. Nothing is permanent than temporary patch in a system.

Attribute vs element, XML schema

2009-08-18T12:11:00.000-07:00

Data goes to element, metadata goes to attribute

powerbuilder path

2009-08-17T12:57:00.000-07:00

jonview_socket

T:\jonview_soket\jonview_socket.pbl;
T:\jonview_soket\proxy_socket_call.pbl;

jonview_remote

T:\jonview_remote\jonview_remote.pbl;
T:\jonview_remote\remote_call.pbl;
T:\jonview_remote\remote_fun.pbl;
T:\jonview_remote\remote_call_new.pbl;
T:\jonview_remote\remote_fun_new.pbl;

jonviewhostclient

T:\jonviewclient\client\jonviewclient\jonviewhostclient.pbl;
T:\jonviewclient\client\jonviewclient\voucher.pbl;
T:\jonviewclient\client\jonviewclient\jonview_report.pbl;
T:\jonviewclient\client\jonviewclient\jonview_report_win.pbl;
T:\jonviewclient\client\jonviewclient\jonview_report2.pbl;
T:\jonviewclient\client\jonviewclient\jonviewclient_proxy.pbl;
T:\jonviewclient\client\jonviewclient\library.pbl;
T:\jonviewclient\client\jonviewclient\jonview_common.pbl;

jonviewhostserver_trion

T:\jonviewhost_xml\jonviewhostserver_allian.pbl;
T:\jonviewhost_xml\xml_exchange.pbl;
T:\jonviewhost_xml\jonviewproxy.pbl;
T:\jonviewhost_xml\jonview_common.pbl;
T:\jonviewhost_xml\jonview_xml_parent.pbl;
T:\jonview_web\common\jonview_public_common.pbl;
T:\jonview_web\common\jonview_public_product.pbl;
T:\jonview_web\common\jonview_public_trion.pbl;
T:\jonview_web\common\jonview_public_h2h.pbl;
T:\jonview_web\common\jonview_public_string.pbl;
T:\jonview_web\common\jonview_public_login.pbl;
T:\jonview_web\common\jonview_public_tariff.pbl;
T:\jonviewhost_xml\jonview_xml_download.pbl;

jonviewhostserver_xml

T:\jonviewhost_xml\jonviewhostserver.pbl;
T:\jonviewhost_xml\jonview_xml_parent.pbl;
T:\jonviewhost_xml\xml_exchange.pbl;
T:\jonviewhost_xml\jonviewproxy.pbl;
T:\jonviewhost_xml\jonview_allian_proxy.pbl;
T:\jonviewhost_xml\jonview_common.pbl;
T:\jonview_web\common\jonview_public_common.pbl;
T:\jonview_web\common\jonview_public_product.pbl;
T:\jonview_web\common\jonview_public_trion.pbl;
T:\jonview_web\common\jonview_public_h2h.pbl;
T:\jonview_web\common\jonview_public_string.pbl;
T:\jonview_web\common\jonview_public_login.pbl;
T:\jonview_web\common\jonview_public_tariff.pbl;
T:\jonviewhost_xml\jonview_xml_download.pbl;

jonviewhostserver

T:\jonviewhost_all\jonviewhostserver.pbl;
T:\jonviewhost_all\jonview_core_proxy.pbl;
T:\jonviewhost_all\jonview_common.pbl;
T:\jonview_web\common\jonview_public_paxspecial.pbl;
T:\jonview_web\common\jonview_public_nvo.pbl;

jonviewhostserver_voucher

T:\jonviewclient\jonviewhostserver_voucher.pbl;
T:\jonviewclient\jonviewhostserver_father.pbl;
T:\jonviewclient\jonview_common_fun.pbl;
T:\jonviewclient\voucher.pbl;
T:\jonview_web\common\jonview_public_common.pbl;
T:\jonview_web\common\jonview_public_product.pbl;
T:\jonview_web\common\jonview_public_string.pbl;

jonviewhostserver_report

T:\jonviewclient\jonviewhostserver_report.pbl;
T:\jonviewclient\jonviewhostserver_father.pbl;
T:\jonviewclient\jonview_common.pbl;
T:\jonviewclient\jonview_common_fun.pbl;
T:\jonviewclient\jonview_report2.pbl;
T:\jonviewclient\jonview_report.pbl;

jonviewhostserver(jonviewclient)

T:\jonviewclient\jonviewhostserver.pbl;
T:\jonviewclient\jonviewhostserver_father.pbl;
T:\jonviewclient\jonview_core_proxy.pbl;
T:\jonviewclient\jonview_common.pbl;
T:\jonviewclient\jonview_common_fun.pbl;
T:\jonviewclient\jonviewhost_xmlproxy.pbl;
T:\jonviewclient\jonviewhost_pdfproxy.pbl;
T:\jonview_web\common\jonview_public_common.pbl;
T:\jonview_web\common\jonview_public_product.pbl;
T:\jonview_web\common\jonview_public_string.pbl;

jonview_trion

T:\jonview_trion\jonview_trion.pbl;
T:\jonview_trion\jonview_trion_common.pbl;
T:\jonview_trion\jonview_proxy.pbl;
T:\jonview_web\common\jonview_public_string.pbl;
T:\jonview_web\common\jonview_public_common.pbl;
T:\jonview_web\common\jonview_public_reference.pbl;
T:\jonview_web\common\jonview_public_product.pbl;
T:\jonview_web\common\jonview_public_trion.pbl;
T:\jonview_web\common\jonview_public_h2h.pbl;
T:\jonview_web\common\jonview_public_login.pbl;
T:\jonview_web\common\jonview_public_paxspecial.pbl;
T:\jonview_web\common\jonview_public_report.pbl;
T:\jonview_web\common\jonview_public_itinerary.pbl;
T:\jonview_web\common\jonview_public_transportation.pbl;
T:\jonview_web\common\jonview_public_nvo.pbl;
T:\jonview_web\common\jonview_public_tariff.pbl;

jonview_pdf

T:\jonview_pdf\jonview_pdf.pbl;
T:\jonview_pdf\proxy_mail.pbl;

jonview_public

T:\jonview_web\public\jonview_public.pbl;
T:\jonview_web\public\jonview_public_alternate.pbl;
T:\jonview_web\common\jonview_public_common.pbl;
T:\jonview_web\common\jonview_public_login.pbl;
T:\jonview_web\common\jonview_public_tariff.pbl;

how to fix activeMq inactive errors.

2009-08-17T07:41:00.000-07:00

Change configuration file under transportConnectors tag
from
transportConnector name="openwire" uri="tcp://localhost:61616" discoveryUri="multicast://default"
to
transportConnector name="openwire" uri="tcp://localhost:61616?wireFormat.maxInactivityDuration=0"

Inversion of control and dependency injection

2009-08-13T07:38:00.000-07:00

The caller eventually get the results, but how and when is out of its control. The callee decide when and how. This is a technique separating execution of a certain task from its implementation.

1. decoupling execution and its implementation
2. Every system focus on what it is designed for.
3. Every system does not what other system will do or should do.
4. Changing one system will not affect others.

Techniques:

1. Factory pattern.
2. setter injection
3. Constructor injection.
4. Services Locater
5. Interface injection

Dependency Injection is decoupling high level modules from low level services.

template VS stragety

2009-08-10T13:04:00.000-07:00

he Template pattern is similar to the Strategy pattern. These two patterns differ in scope and in methodology.

Strategy is used to allow callers to vary an entire algorithm, like how to calculate different types of tax, while Template Method is used to vary steps in an algorithm. Because of this, Strategy is more coarsely grained. The Template allows finer-grained controls in the sequent of operations, and yet allows the implementations of these details to vary.

The other main difference is that Strategy uses delegation while Template Method uses inheritance. In Strategy, the algorithm is delegated to the another xxxStrategy class that the subject will have a reference to, but with Template you subclass the base and override methods to make changes.

Strategy pattern example:
Class MainSubject
{

ITaxStrategy taxCalculator = GetStrategy(taxType);
//strategy is member class.
taxCalculator.Calculate();

private GetStrategy(string taxType)
{
if (taxType == "incometax")
return new IncomeTaxStrategy();
else if (taxType == "propertytax")
return new PropertyTaxStrategy();
}

}

Class IncomeTaxStrategy : ITaxStrategy
{

public Calculate()
{
//calculate based on income tax rates.
}

}

Class PropertyTaxStrategy : ITaxStrategy
{

public Calculate()
{
//calculate based on property tax
policies.
}

}

Template pattern example:

abstract Class TaxCalculator
{

public CalculateTax()
{
CalculateIncome();
tax =+ CalculateTax();
tax =+ CalculateRelief();

}
abstract CalculateTax();
abstract CalculateRelief();

}

Class IncomeTaxCalculator : TaxCalculator
{

override CalculateTax() { //calculate income tax. }
override CalculateRelief() { //calculate personal relief }

}

Class PropertyTaxCalculator : TaxCalculator
{

override CalculateTax() { //calculate property tax. }
override CalculateRelief() { //do nothing; no relief. }

}

String.substring is dangerous

2009-07-29T08:56:00.001-07:00

String.substring() will create a new string and old one can not be garbage collected. Please use below.

     String sub = new String( oldString.substring(0, 4) );

Good Developer

2009-07-28T06:35:00.000-07:00

A good Developer should be able to learn, adapt, and apply but not be
limited to past experience.

What is the difference between class adapter and object adapter design pattern

2009-07-27T11:35:00.001-07:00

Object adapter contains adaptee , and class adapter inherits from adaptee.
If you have multiple adaptees, then you have to use object adapter.

// Object adapter version

public class ReportGenerator implements OldReporter {

private NewReportWriter newReporter = new NewReportWriter();

public void writeHeader(String headerData) {

newReporter.generateHeaderLines(headerData);

}

// Class adapter version

public class ReportGenerator extends NewReportWriter

implements OldReporter {

public void writeHeader(String headerData) {

generateHeaderLines(headerData);

}

design pattern Singleton

2009-07-24T06:56:00.000-07:00

public class SimpleSingleton {
private SimpleSingleton singleInstance = null;
//Marking default constructor private
//to avoid direct instantiation.
private SimpleSingleton() {
}
//Get instance for class SimpleSingleton
public static SimpleSingleton getInstance() {
if(null == singleInstance) {
singleInstance = new SimpleSingleton();
}
return singleInstance;
}
}

in multi-thread environment, please use:

public static synchronized SimpleSingleton getInstance() { }

How to do as architect

2009-07-23T13:15:00.000-07:00

1. Management of non-functional requirement
a. help the stakeholders to list all non-functional requirement:
performance, security, scalability, availability, maintainability, audit, extensibility and I18N

2. Architecture definition
Every system has a architecture, but not every has a architecture defined. The architecture definition process lets you think about how you're going to take the requirements plus any constraints imposed upon you and figure out how you're going to solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project.

3. Technology selection

4. Architecture evaluation
Risk, benefit.

5. Architecture collaboration
Go through it and make sure everybody involved understand it and buy in.

6. Ownership of big picture.

7. leadership
Taking responsibility, providing technical guidance, making technical decisions and having the authority to make those decisions

8. Coaching and mentoring
Sharing experience with other members.

9. Design, development and testing

10. Quality assurance

hands-on software architect

2009-07-23T12:43:00.000-07:00

http://www.codingthearchitecture.com/pages/book/role.html

String, Stringbuilder, and stringbuffer

2009-07-21T07:14:00.000-07:00

String is good for substring, not add extra time.
For concat(), string builder is better, but JVM automatically does it for you.
Stringbuilder is not thread-safe
Stringbuffer is thread-safe.

TDD steps

2009-07-21T06:52:00.000-07:00

1. Write the test
2. Write the comments inside the test to describe the function
3. Write sub-test for each function inside the test.
4. Run the test, make the testing running automatically.
5. Write the code.
6. re-factory the test.

reading comments: Lazy Load

2009-07-20T11:48:00.000-07:00

Lazy Load is one of the object relational behavioral patterns. With lazy load, an object does not contain all of the data you need but knows how to get it when it is needed. This pattern is commonly found in most of the OR mappers, e.g. Hibernate.

lazy initialization
With lazy initialization, every access to the field is checked against a special value, e.g. null value. If the value is not found, then the object needs to perform some logic, e.g. lookup from database, before returning.

virtual proxy
A virtual proxy is an object that looks like the object that should be in the field, but actually doesn’t contain anything. Only when one of it’s methods is called does it load the correct object from the database.

value holder
A value holder is used as a generic Lazy Load. It is an object that wraps some other object. To get the underlying object you ask the value holder for the value, and the first access will pull the data from the database.

XmlBeanFactory vs ClassPathXmlApplicationContext

2009-07-20T11:04:00.000-07:00

In my previous blog, I explained how to use ClassPathXmlApplicationContext. Today when I debug a application, I found below issues regarding XmlBeanFactory.

When we use XmlBeanFactory, TX annotation is not working. and it does not even load when you say in XML file.

So if you want to use annotation, please use ClassPathXmlApplicationContext. I believe in WEB application, tomcat system actually uses ClassPathXmlApplicationContext. So in order to make your code testing separately, please do not use XmlBeanFactory.

Below it is the example of XmlBeanFactory and ClassPathXmlApplicationContext

XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource(
"applicationContext2.xml"));
InvoiceProcessDao process = (InvoiceProcessDao)factory.getBean("invoiceProcess");

ApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext3.xml");
InvoiceProcessDao process = (InvoiceProcessDao)ctx.getBean("invoiceProcess");
process.checkPayment();
System.out.println(" Over") ;

Junit best pratise

2009-07-13T05:45:00.000-07:00

JUnits - Do’s and Dont’s

Posted by: Mahesh Tabib on July 10, 2009 DIGG

After the Junit cleanup last whole month, here are my few cents.

A JUnit test case can contain multiple tests. Each test is implemented by a method. The declaration of a test method must comply to a set of conventions in order to help JUnit and associated tools to automate the discovery and execution of tests. These conventions are:
1. The name of the method must begin with “test”, like in “testValidateOperator”,
2. The return type of a test method must be null,
3. A test method must not throw any exception,
4. A test method must not have any parameter.

There are a few details of which you should be aware of when writing JUnit tests. First of all, when executing a test case, JUnit will instantiate the test case class as many time as there are test methods. That is, each test method will be executed on a different instance of the test case class. Before calling the test method, JUnit will call the setUp() method. The tearDown() method will be called after the test method completes – successfully or not. The setUp() and tearDown() methods should be used to create and then clean up the test environment.

Good practices to be followed while writing a JUnit:

• Write tests for methods that have the fewest dependencies first. If you start by testing a high-level method, your test may fail because a subordinate method may return an incorrect value to the method under test. This increases the time spent finding the source of the problem, and you will still have to test the subordinate method anyway to be sure it does not contain other bugs.

• Tests should be logically simple as possible, preferably with no decisions at all. Every decision added to a test method increases the number of possible ways that a test method can be executed. Testing is meant to be a controlled environment; the only thing you want to change is the input to the method under test, not the test method itself.

• Wherever possible, use constant as expected values in your assertions instead of computed values. Consider these two assertions:

returnVal = getDiscountCode(input);
assertEquals(returnVal, computeDiscountCode(input));
assertEquals(returnVal, “023”);

In order for computeDiscountCode() to return the proper result it probably has to implement the same logic as the getDiscountCode(), which is what you are trying to test for in the first place. Further, suppose you fixed a defect in the getDiscountCode (). Now you have to change computeDiscountCode () in the same manner. The second assertion is easier to understand and maintain.

• Each unit test should be independent of all other tests.
A unit test should execute one specific behavior for a single method. Validating behavior of multiple methods is problematic as such coupling can increase refactoring time and effort. Consider the following example:

void testAdd()
{
int return1 = myClass.add(1,2);
int return2 = myclass.add(-1,-2);
assertTrue (return1 – return2 == 0);
}

If the assertions fails in this case, it will be difficult to determine which invocation of add() caused the problem.

• Each unit test should be clearly named and documented.
The name of the test method should clearly indicate which method is being tested because improperly named tests increase maintenance and refactoring efforts. Comments should also be used to describe the test or any special conditions.

• All methods, regardless of visibility, should have appropriate unit tests.
Public, private and protected methods that contain data and decisions should be unit tested in isolation.

• One assertion per test case.
Avoid using multiple assertions in one test case. For example, if a test case with five assertions fails on the first assertion, then the remaining four are not executed. Only when the first assertion is corrected will the other assertions execute. If assertion two fails, then that also must be corrected before the remaining three assertions are verified. Although the unit test file may be large, it will be easier to find and fix defects.

• Create unit tests that target exceptions.
Exceptions are thrown when a method finds itself in a state it cannot handle. These cases should be tested just like a method’s normal state of operations. If a method is declared to throw one or more exceptions, then unit tests must be create that simulate the circumstances under which those exceptions could be thrown. The unit tests should assert that the exceptions are thrown as expected.

Please let me know if this helps. Happy coding Junits…!!

SOA Security post

2009-07-08T08:16:00.000-07:00

http://domagojtechtips.blogspot.com/2007/08/cxf-spring-and-ws-security-putting-it.html
http://cwiki.apache.org/CXF20DOC/ws-security.html

Notes for Data Warehousing

2009-07-07T12:03:00.000-07:00

1. Type of Data
a. Operational Data ( OLTP)

Data that works
Frequent updated and queried
Normalized for efficient search and update
Fragmented and local relevance.
Point query, query access individual tables.

Examples:
What is the salary of John?
What is the phone number of the person who is in charge of Depta
How many people are rated as excellent?

b. Historical Data (OLAP)

Data that tells
Very infrequent update
Integrated data set with global relevance.
Analytical queries that require huge amounts of aggregation.
performance issue, need quick response time.

Examples:
How is the trend in the past 2 years?
How is summary of something?

2. What is Data Warehousing?

An infrastructure of manage historical data
Designed to support OLAP queries involving gratuitous use of aggregation
Post retrival processing(reporting)

3. OLTP --> Data cleaning and Integration --> Data Warehousing

4. Data Marts:

Segments of OLTP
Data Warehouse is a collection of data marts

5. Data Cleaning

a. Dirt Data

Lack of standardization
Missing or duplicate data
Inconsistent.

b. Issue of Data cleaning

Can not be fully automated
GIGO
Require data considerable knowledge
Complex

c. Steps of cleaning process.

Data analysis
Definition of transformation rule
Rules verification
Transformation
Backflow: re-populate data

5. Integration
Schema: Forming an integrated schema structure from different data source, cleaning data and managing from different DS.

Reading: Tomcat security for clear password

2009-07-07T11:52:00.000-07:00

How to Secure Tomcat Database Passwords for Java

In production environments there are features of Tomcat that don't pass security audit reviews

October 3, 2007 11:45 AM EDT

Reads:

30,463

Tomcat is a great reference implementation of the Java EE specification and is intended for desktop use by developers who are starting to learn about Java EE or those who work on enterprise applications and need an EE server for development. However because Tomcat is free it finds its way into production environments. In this environment there are features of Tomcat that don't pass security audit reviews. One of these features is the use of clear text passwords in the server.xml file to create data sources. The purpose of this article is to show how encryption of the username and password can be implemented thus closing a potential security vulnerability.

Configuring a container managed data source with Tomcat is easy and well documented under the "JDBC DataSources" section of Tomcat's documentation (this article uses Tomcat 5.0.28). The data source configuration information is stored in TOMCAT/conf/server.xml. The resource is defined using the tag.

name="jdbc/TestDB"
auth="Container"
type="javax.sql.DataSource"
/>

The name attribute defines where the resource is bound in JNDI. The auth attribute will have either the value Application or Container. Container means Tomcat will provide the username and password to connect to the resource whereas Application means the application will provide them. Container is specified because the username and password will be entered in server.xml. The type attribute is the fully qualified name of the class returned when the resource is looked up using JNDI.

Next the resource needs to be configured. This is the purpose of the tag. For a JDBC resource, a basic configuration is presented in Listing 1.

The name attribute has the value jdbc/TestDB, which must match a tag. The "factory" name/value pair tells Tomcat the fully qualified name of the class that implements javax.naming.spi.ObjectFactory. This class is responsible for returning objects of the type defined by the type attribute of the tag. The rest of the name/value pairs of tags are passed to the "factory" in a javax.naming.Reference object.

Finally, the application has to be configured to use this data source. This is done by referencing the data source in /META-INF/context.xml of the application's WAR. A tag is added to context.xml.

global="jdbc/TestDB"
name="jdbc/SpiderMan"
type="javax.sql.DataSource"
/>

The type attribute is the fully qualified name of the class returned when the resource is looked up using JNDI. The global attribute must match a tag in server.xml. The name attribute defines where the resource is bound in JNDI. From an application's point of view, the location specified by the name attribute is relative to java:comp/env. Each application can have its own conventions for JNDI lookup names and the tag is the bridge between how an application does a resource lookup and where the resource is actually located. It's good practice to have the application use an atypical lookup name. This makes your application more portable to other EE servers because it's not accidentally bound to the conventions of one EE server's resource placement.

CIO, CResources

For development environments or personal use this configuration is acceptable, however, in a production environment the clear text username and password in is a security vulnerability. If a production server is compromised, the intruder would have easy access to production data. With privacy concerns and Sarbanes-Oxley requirements the harder it is for an intruder to gain access to such data the better.

While Yahooing! I was surprised to discover I couldn't find any instructions addressing this issue. Most search results related to debating if securing the clear text username and password is even necessary. The general consensus seemed to be this security is not necessary for two reasons. One, if an intruder compromises a production server in a way that would allow read access to server.xml then the clear text username and password is the least security concern. Two, Tomcat is a reference implementation so it shouldn't be used in a production environment. Although these are lively debates and can spark great topics of conversation they do not address the issue. What I need is a way to get rid of the clear text username and password.

I will present three possible solutions to this issue. The first two are custom solutions involving application updates while the third takes advantage of Tomcat's built-in extensibility, requires no application updates and so is a much more attractive solution.

The first solution is to bypass Tomcat altogether and not configure a data source. With no data source there's no clear text username and password in server.xml so the problem is solved. However applications still need database connections. With no container-managed database pool each application will have to do its own pooling. This brings up all sorts of problems. Applications will need knowledge of the database and how to access it, unnecessary plumbing code is needed to manage the pool, data access objects will no longer be coded to EE specs making them less portable, no built-in or plug-in transaction management resulting in more plumbing code, an ever-growing number of connections as more applications are developed, performance degradation during high-traffic periods as connections become scarce, support overhead from managing many individual configurations, and the list goes on. It's possible each of these problems can be solved but as you solve them your code moves further and further from the EE specs. Because of all these problems, this is not an attractive solution.

The second solution is to move the responsibility for database authentication from Tomcat to the application. Recall the auth attribute of the tag. If the value is Application, the application is responsible for providing the username and password. The Tomcat administrator can delete the username and password parameters from server.xml and the Developer would code the username and password into the application. Typically the first time JNDI is used to look up a DataSource is when the username and password are set. The code in Listing 2 gives an idea of what this would look like for Tomcat. Although the example doesn't use any kind of encryption it's not difficult to plug in an encryption strategy. This solution also has problems. The application is now responsible for either knowing the username and password or knowing the encryption strategy. The application also needs to know the real class implementing DataSource (in the case of Commons DBCP) so the username and password can be provided. This could make the application not portable to another EE server. So this is not an attractive solution either.

The third solution is to take advantage of Tomcat's built-in extensibility. Inside the tag Tomcat offers the ability to specify the fully qualified name of the Java class that implements the javax.naming.spi.ObjectFactory interface. This class is responsible for returning implementations of javax.sql.DataSource. By default Tomcat uses org.apache.commons.dbcp.BasicDataSourceFactory and this class requires to have clear text username and password values. So why not create a class that extends BasicDataSourceFactory and is configured with an encrypted password instead? For the purposes of this article I'll use a simple Base64 encoding but the concept can be easily extended to any other method.

The source code for BasicDataSourceFactory has two important methods. They are:

public Object
getObjectInstance(
Object o
, Name n
, Context c
, Hashtable h)

public static DataSource
createDataSource(
Properties p
)

Tomcat creates an instance of BasicDataSourceFactory by calling its no-argument constructor. When a DataSource is needed the getObjectInstance(...) method is called. The BasicDataSourceFactory class implements this method in the following way. First it typecasts the Object parameter to Reference. Then all of the name/value pairs are removed from the Reference object and set in a Properties object. Finally, the Properties object is passed to the createDataSource(...) method where it's assumed the username and password exist in the Properties object as clear text.

To secure Tomcat database usernames and passwords, create a new class named EncryptedDataSourceFactory that extends BasicDataSourceFactory. This new class is going to override the getObjectInstance(...) method. The new method is implemented in the following way. First it will remove the encrypted username and passwords from the Reference object. Next, it will decrypt them. Then it will put the decrypted values into the Reference object. Finally it will call the getObjectInstance(...) method of the super class so it can take care of creating the DataSource. See the source code in Listing 3.

In the source code the "username" string of the setUsername() method and the "password" string of the setPassword() method refer to the value of:

CIO, CTO & Developer Resources

username
postgres_user

password
postgres_pass

These strings have corresponding constants in the BasicDataSourceFactory class but the constants are declared private so can't be used. The find() method throws an exception if not found because decryption will fail if there's nothing to decrypt. The decrypt() method uses a Base64 decoder that isn't secure but adequately demonstrates the concept. Finally the replace() method removes the encrypted values and puts in the decrypted values. When getObjectInstance(...) of the super class is called, it has the clear text passwords and is completely unaware that the values in server.xml are actually encrypted.

Using EncryptedDataSourceFactory is simple. First drop the org.moss.jdj.jdbc-yyyy.mm.dd.x.jar file into TOMCAT/server/lib. Next, get a Base64 encoding of the username and password. A simple Yahoo! search of "online base64 encoder" will find sites that will do it. Finally, edit server.xml and replace the username and password values with their corresponding Base64 equivalents and set the factory value to org.moss.jdj.dbcp.EncryptedDataSourceFactory. Start up Tomcat and see it in action.

Using Tomcat's built-in extensibility like this is an attractive solution. It fulfills security audit requirements by removing clear text usernames and passwords but it also lets applications be coded to EE specs. Using this solution doesn't put any unnecessary or unwanted responsibility in applications. Applications can be developed to fulfill business requirements and don't have to worry about plumbing code like initializing or shutting down a database connection pool properly, maintaining a custom transaction system to roll back on errors, or implementing an encryption strategy. Plus, when the time comes to move away from Tomcat the applications will be ready. The code in Listing 3 will be thrown away but small amounts of throwaway code is much better than the effort needed to go back and update applications.

Reading "To ESB or not to ESB"

2009-07-07T08:59:00.000-07:00

To ESB or not to ESB

Ross Mason
July 6th, 2009

Many of us have had to ponder this question. Technology selection is notoriously difficult in the enterprise space since the criteria and complexity of the problem is often not fully understood until later in the development process.
There is an interesting post from ThoughtWorker Erik Dörnenburg with the unfortunate title “Making the ESB pain Visible”. Erik provides a real-world example of when not to use an ESB citing that -

Based on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced “nothing but pain.” But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect’s dream, developer’s nightmare?

Later, Erik quite rightly points out that an ESB should not have been used in this scenario. This is a fairly common problem for ESBs and other enterprise technology like BPM/BPEL where the technology is not chosen for the right reasons and then the technology gets blamed when the project struggles. Given that much of the enterprise software disillusionment today stems from the incorrect usage of the technology I thought I’d offer some rough guidelines for selecting an ESB.

ESB selection checklist

Mule and other ESBs offer real value in scenarios where there are at least a few integration points or at least 3 applications to integrate. They are also well suited to scenarios where loose coupling, scalability and robustness are required.
Here is a quick ESB selection checklist –

Are you integrating 3 or more applications/services? If you only need to communicate between 2 applications, using point-to-point integration is going to be easier.
Will you really need to plug in more applications in the future? Try and avoid YNNI in your architecture. It’s better to keep things simple re-architect later if needed.
Do you need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.
Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? Many applications do not need these capabilities.
Do you need to publish services for consumption by other applications? This is a good fit for Mule as it provides a robust and scalable service container, but in Erik’s use case all they needed was an HTTP client from their front-end Struts application.
Do you have more than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down in to smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.
Do you really need the scalability of an ESB? It’s very easy to over-architect scalability requirements of an application. Mule scales down as well as up making it a popular choice for ‘building in’ scalability. However, there is a price to be paid for this since you are adding a new technology to the architecture.
Do you understand exactly what you want to achieve with your architecture? Vendors often draw an ESB as a box in the middle with lots of applications hanging off it. In reality, it does not work like that. There is a lot details that need to be understood first around the integration points, protocols, data formats, IT infrastructure, security etc. Starting small helps to keep the scope of the problem manageable and keep the fuckupery to a minimum. Until you understand your architecture and scope it properly you can’t really make a decision as to whether an ESB is right for you.
Generally, always validate a product solution for your needs. Don’t choose an ESB or any other technology because –
- It will look good on my resume
- I don’t need the features today but there is a remote chance that I _might_ in future
- I had a great golfing weekend with the head of sales

This checklist is not exhaustive, but will help clarify when not to use an ESB. Once you have decided that an ESB is a good fit for your project you’ll want to add additional selection criteria such as connectivity options, robustness, error management, service repository, performance, data support, etc. The important thing to remember is that there is no silver bullet for good architecture and you need to know your architecture before making a technology decision.

With this checklist in mind it’s easy to see that Erik’s example never needed an ESB in the first place.

However, if the architecture looked something more like this, then an ESB would have probably been a good fit.

Choosing Mule

Obviously, as the creator of Mule I have some bias for wanting everyone to use Mule. However, it is critical to the continued success of the Mule project and to MuleSource that users understand when not to use an ESB. Open source makes a lot of sense for enterprise software because projects need time to try out the technology and refine their proposed architecture. Having access to the product and source code helps a huge amount in this discovery process and allows the customer to make an informed decision.

In fact the MuleSource business model hinges on the ability of the user to self-select Mule and approach us only when they need development or production support. This has been working very well for everyone involved. Customers get to do a proof of concept (PoC) with our product knowing that if they end up using it for a mission critical application that they can get professional 24×7 support. For MuleSource it means that our customers buy from us rather than us selling to them, so they always get what they want – this is a far cry from the old proprietary upfront license model that used to hold the enterprise market hostage.

JPA field access vs property access

2009-06-26T12:08:00.000-07:00

For field access, you do not need have set or get method. You specify field. But for property, you use set and get to set value.

After reading "IT Managers confession"

2009-06-25T10:37:00.000-07:00

Today I found a very interesting book about IT manager, below are the some points I got from that book:

Good team knows how to handle their manager, train the manager to do things their way.
As a manager, if you do not like someone and you can not get rid of him/her, then it is better promote him/her to another position, so he/she can leave the group. But keep the good people with you.
Find a Yancey man who can speak for you. He has excellent communication skill , he can talk regular language to customers and stake holders. But you need him to follow you, speak your mind not his own mind. That is hard.
Looking Busy:

arrival early and leave late does not mean you hard, you can leave in the middle.
Using MS project to create a lot of report.
A lot of meeting and crisis management.
Ask your developer to send everything for you to approval.
visit other department regularly.
find any chances to complain too many emails.

Spring JPA annotation transaction.

2009-06-23T07:01:00.000-07:00

It has been weeks I could not figure out why I can not use annotation based transaction control, and it forced me to use programmatic transaction control. Today I found this post from theserverside, which explains everything.

it's caused by the use of the BeanFactory instead of an ApplicationContext, which is used inside the unit test, behind the scene when using the AbstractJpaTests base class.

If you change your Main class to

Code:

public class Main {

public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("context/testContext.xml");
PersonDAO dao=(PersonDAO)ctx.getBean("personDAO");

Person p=new Person();
p.setFirstName("testName");
dao.save(p);
}
}

it will work.

The reason for that is a slightly different behavior between a BeanFactory and an ApplicationContext when it comes to BeanPostProcessors. From the Spring reference manual:

It is important to know that a BeanFactory treats bean post-processors slightly differently than an ApplicationContext. An ApplicationContext will automatically detect any beans which are defined in the configuration metadata which is supplied to it that implement the BeanPostProcessor interface, and register them as post-processors, to be then called appropriately by the container on bean creation. Nothing else needs to be done other than deploying the post-processor in a similar fashion to any other bean. On the other hand,
when using a BeanFactory implementation, bean post-processors explicitly have to be registered, with code
like this:

ConfigurableBeanFactory factory = new XmlBeanFactory(...);
// now register any needed BeanPostProcessor instances
MyBeanPostProcessor postProcessor = new MyBeanPostProcessor();
factory.addBeanPostProcessor(postProcessor);
// now start using the factory

This explicit registration step is not convenient, and this is one of the reasons why the various
ApplicationContext implementations are preferred above plain BeanFactory implementations in the vast majority of Spring-backed applications, especially when using BeanPostProcessors

That's the whole reason, why your PersistenceAnnotationBeanPostProcessor never got loaded and therefore couldn't do its work!

From dzone.com: Three Questions About Each Bug You Find

2009-06-16T06:35:00.001-07:00

Three Questions About Each Bug You Find

I really love this timeless Tom Van Vleck article from 1989. It teaches us to ask ourselves:

Three Questions About Each Bug You Find

Those questions being:

Is this mistake somewhere else also?
What next bug is hidden behind this one?
What should I do to prevent bugs like this?

When I first read these rules, I was foolish enough to think:

'Cute, But Too Obvious! i do this intuitively all the time.'

But watch yourself closely! I've caught myself out on occasion, and maybe you will too.

I'm making an effort to be more explicit about the three questions. Maybe i'll end up fixing related problem

My first blog

2009-06-11T13:06:00.000-07:00

Today it is the first time I have a blog, I guess I will spend some of my spare time at this blog in the future.