How to reset auto-increment column in MySQL

utilize this command: ALTER TABLE $table AUTO_INCREMENT = 1
ex. ALTER TABLE bugs.bugs AUTO_INCREMENT = 1

Top 15 Ant Best Practices

http://www.onjava.com/pub/a/onjava/2003/12/17/ant_bestpractices.html

Cannot enter X Window

# mount /mnt/cdrom
# cp /mnt/cdrom/ /tmp
# tar zxvf vmware-linux-tools.tar.gz
# cd 到vm開頭的目錄
# ./vmware-install.pl # startx

Java FTP client libraries reviewed

http://www.javaworld.com/javaworld/jw-04-2003/jw-0404-ftp.html

Java FTP components

http://www.enterprisedt.com/index.html

Ten Common Misconceptions About Spring...

http://www.oreillynet.com/onjava/blog/2006/08/ten_common_misconceptions_abou.html

The Five Variables of Project Management

Update: Picked up on a thread on TheServerSide, so there may be some more discussion over there.

In my experience (and more so that of my more experienced colleagues) there are five variables over which you can exert control to decide when – and with what functionality – you can deliver your software.

Scope

In simple terms, if you deliver less functionality, it will take you less time. The problem is that often the decision as to what not to deliver happens during the development process itself. This means that prioritisation of functionality from the outset is important. if half way through you need to cut scope, but the only stuff you have left is the stuff your users simply must have, and you spent the last three months delivering things they’d only like to have, your options are limited. Priorities can change, but core functionality tends not too – concentrate on delivering that and you’ll make it easier for yourself in the long run.

Time

Typically the thing over which technical people have the least control (anecdotally it seems as though the go-live date for software is defined more by sales and marketing than by need), but you can decide to deliver later to get what you want.

People

Adding more people to a project can make it faster – to a point. However in software adding people very rarely tends to result in a linear increase in productivity. Hiring the right people can be more efficient, but is far from easy.

Some organisations take the ‘lots of dumb people being told what to do by one or two smart people’ route, others the ‘a few smart people all knowing what to do’. I’m sure most of us (myself included) believe we hope for the later. I’ve certainly seen examples in the consultancy world where an organisation with a lower charge rate but lots of people ends up costing much more deliver than a small number of people with higher charge rates.

Process

Reworking one’s process in order to be more efficient is an obvious thing to do, but hard to achieve. Depending on the flexibility of your organisation changing your process might not be easy, even if you know what it is to change. Changes mid-project – for example in order to deliver faster – tend to be limited, small changes. Retrospecitves can be a good tool for identifying what the team thinks is required, but don’t discount seeking outside help – someone from another team might have a different take on things.

A far more common type of process change occurs when people make what is often claimed to be short-term sacrifices in terms of software quality to deliver on time. Changes could involve writing less developer tests, spending less time performing manual tests, stop pairing, or spend less time ensuring consistent technical vision. When these changes really are short-term, and time is set aside afterwards to repair the damage done, this may be a viable technique. However those organisations which tend to drop quality in order to deliver faster tend to use this technique more than any other, and frequently never spend time playing catch up – leading to a team spending most of their time running from one disaster to another.

Risk

Risk Management is something I’m personally becoming aware of. Making sure you have situations in which potential risks can be raised is important (a daily stand-up might be one). Periodically risks should be assessed, in terms of how likely they are to occur, and also in terms of how much damage they can create.

Some risks can be mitigated, some eliminated entirely, and others cannot be addressed by you. In any case once prioritised in terms of likelihood and potential damage, they can be mitigated or communicated to your business sponsor accordingly.

Ten things programmers might want to know about marketers

Seth Godin wrote up "Ten things programmers might want to know about marketers," trying to bridge the gap between the engineer and the marketing dork who spoils his effort. Quick summary: marketing is unrepeatable, and indeterminate.

The ten things are:

1. Marketing is not rational. Programming is. Works the same way every time. Marketing doesn't, almost in a Heisenbergian way. If it worked before, it probably won't work again.
2. Marketing is even more difficult to schedule than bug fixes. Marketing expenses are easily timed, of course, but the results are not. That's because there's a human at each end of the equation.
3. Most marketers have no clue whatsoever what to do. So we do unoriginal things, or stall, or make promises we can't keep.
4. Just because Sergey is both a brilliant programmer and a brilliant marketer doesn't mean that all brilliant programmers are good at marketing.
5. People often prefer things that are inelegant, arcane or even broken. Except when they don't.
6. Truly brilliant coding is hard to quantify, demand or predict. Same is true with marketing.
7. There is no number seven.
8. Unlike mediocre programmers, mediocre marketers occasionally get lucky. When they do, they end up with a success they can brag about for a generation. But that doesn't mean they know how to do it again.
9. Just because some marketers are dorks doesn't mean your marketer is a dork. Some programmers aren't so great either. Be patient.
10. Without marketing, all your great coding is worthless. Push your marketer to be brave and bold and remarkable. Do it every day. Your code is worth it.

[Problem] Cannot Start OracleOraHome92Agent

Scenario
As we wanna start OracleOraHome92Agent service, it always cannot be initialized normally.


Root Cause
It's service internal error or windows internal


Solution
delete the *.q files which locate at %oracle_home%\network\agent