
If you are ever looking for a nice UML class designer look no further than NClass. I used this for a project to port a large code base from .NET to Java. The program was able to reverse engineer UML from compiled .NET code. Love it.
If you are ever looking for a nice UML class designer look no further than NClass. I used this for a project to port a large code base from .NET to Java. The program was able to reverse engineer UML from compiled .NET code. Love it.
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.oracle.com/technology/weblogic/servers/wls810/dtd/weblogic810-web-jar.dtd">
<weblogic-web-app>
<container-descriptor>
<servlet-reload-check-secs>-1</servlet-reload-check-secs>
</container-descriptor>
</weblogic-web-app>
<jsp-descriptor>
<jsp-param>
<param-name>pageCheckSeconds</param-name>
<param-value>-1</param-value>
</jsp-param>
</jsp-descriptor>
waiting for monitor entry [c4f7f000..c4f7fc28]
at weblogic.servlet.internal.ServletStubImpl.checkForReload(ServletStubImpl.java:771)
When I setup a connection pool or database tool with a new database profile I like to test that it works, here are some vendor specific SQL you can use to test your db connection.
Cloudscape | #SQL SELECT 1 |
#DB2 | #SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES |
#Informix | #SQL SELECT COUNT(*) FROM SYSTABLES |
#Microsoft SQL Server | #SQL SELECT COUNT(*) FROM SYSOBJECTS |
#MySQL | #SQL SELECT 1 |
#Oracle | #SQL SELECT 1 FROM DUAL |
#PointBase | #SQL SELECT COUNT(*) FROM SYSTABLES |
#PostgreSQL | #SQL SELECT 1 |
#Progress | #SQL SELECT COUNT(*) FROM SYSTABLES |
#Sybase | #SQL SELECT COUNT(*) FROM SYSOBJECTS |
This is useful because you don't often know what tables exist in a database to test a query with, you can't assume select * from person would work if no person table was created. These queries are for the builtin system database resource in the specific vendor database types, they should exist even on a freshly installed or blank database server.
OutputStreamWriter out = null;
try {
try {
out = new OutputStreamWriter(new FileOutputStream(outputFile),"UTF-8");
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(e.getMessage,e);
}
try {
out.append(yourStringDataToWriteToOutputFile);
out.flush();
} catch (IOException e) {
throw new RuntimeException(e.getMessage,e);
}
} catch (FileNotFoundException e) {
throw new RuntimeException(e.getMessage,e);
} finally {
try {
out.close();
} catch (IOException e) {
throw new RuntimeException(e.getMessage,e);
}
}
I am in the middle of a frantic ATG code push. The QA cycle (as usual) was a painfully short 2 days. Since the project is pretty large and was months in development, many areas of the UI were changed. Some of the changes were accepted by the QA and business team, but other changes were found to be too wonky to rollout live to thousands of agents. It was inevitable that the business side would request à la carte features from the overal design implemented to roll live (due to the short qa and hard deadline). Problems arise when removing (descoping) a rejected UI change which breaks other features because of dependencies.
I was able to deliever a rapid turnaround on descoping large functional sections of a code push. I did this by keeping a record of each file that was add/changed/removed for the project as well as correlated which business requirement(s) were the motivation behind the file's change.
Traceability saved the day.
I have not been as diciplined in the past with keeping track of changes for a project, let along keeping record of how the changes correlate to the busines requirements. Now, having done this, it is something that has helped me in the following specific ways:
Not every project may be large enough to require record keeping like this. Keeping track of this stuff is boring but the benefits of doing it really make it worth the effort for me. (Just like documenting my knowledge has.)
If you were to lose all your email messages today, how high of a disaster would that be for you:
Scale where 1 is "no big deal" and 10 being "I am ruined, RUINED!!!"
If I am tempted to save an email after I have read it, I stop and think:
"Why do I want to save this? "
"Oh, it is because I will/might need this info again later."
"Well, if that is the case, it should then be put in a secure place or made into a blog post, forum post, document, etc.. on a knowledge site."
I don't always put important learned information in a blog post or in a secure archive, and sometimes I am searching my email for something that I didn't put in a place I could easily find later... However, I think the more consistently I avoid storing knowledge in my email box (either in folders, sent items, trash, etc..) the better off I will be. It takes some time up front to move knowledge to the place it belongs but it takes even more time to scour your email folders for the one bit of info out of your email-haystack when you need later. If I do have to search and find information in my email, then I always move that data into a better place, because the fact I needed the information twice indicates I will need it yet again.
In my opinion we should treat email as an ephemeral messaging tool, not as a personal knowledge compendium. So until Google Wave gets broad adoption, email is like a sticky note on your desk, neither should be used to preserve important knowledge.
Addendum: Email is a bad choice, but some do survive using it as a knowledge base tool. However, the absolute worst place to maintain important knowledge would be your IM chat history. IM chat toools are great and I use them to ask and answer questions, but I kick myself when I am looking through old chat history for a nugget of information to reuse that I neglected to preserve better. I also am frustrated when managers/coworkers repeatedly ask me questions in chat that I have answered weeks or months previously. I am trying to establish the habit to put the answers I give/receive in IM chat on a wiki or (maybe an email..) or somewhere more permanent so that I can refer back to the more stable place later. IM chat is a double-edged sword, it is fast and convenient in the short term, but you can be hurt long term by failing to capture knowledge from your chat sessions.
and, after many attempts, the vendor has told me they will not add it to the product.
Very bad reasons to customize:
From day one, installing and rolling out an enterprise software system to replace an existing process (or set of processes) will be subjected to tremendous resitance to change by every department affected by the project. Picture a single person (you) on one side of a rope and the entire company pulling the rope the other direction to get an idea of a typical resistance scenario. Recognising this early and planning for it is critical for a project to be successful.
Furthermore, until the software is rolled out and actually used by the actual agents or customers in an actual work setting or production environment, any beliefs about how the interface will be (mis)understood are just plain guesses. Often they are not intelligent guesses. Often what I have seen is contrived, based on assumptions or imperfect mental models, or, worst of all, problems derrived from sandbox environments where the edge cases get lots of attention and the meatier workflow is left unnoticed or ignored. Until users are forced into the new software, kicking and screaming, the real usability issues will remain hidden. So why fix the UI when you don't know for certain what precisely is broken?
Finally, your existing systems do what they do, any attempt to integrate them with the new system is a change resistance on your part to allow the new system to stand alone as it was intended to operate. You can't always know the impact on the existing system an integration will have, nor should you expect to fully understand the negative impact the existing system will have when it is connected.
Bottom line is the vendor sales agent will probably tell you anything can be done and is possible, and technically they are correct. Just because a sales person says your ideas are great and wonderful does not mean they actually are. Would a car dealer tell you that putting snow tires on your band new convertable mustang was a stupid idea? not if they thought it would cost them the sale! Custom auto shops are glad to take your money to drop a truck's suspension rendering the vehicle a crippled novelty rather than the expertly designed and highly functional vehicle you test drove. Enterprise software is not that different.