We use a Wiki here at http://www.realeum.com to keep track of a lot of developer information - servers, databases, source code branches, JNLP applications, release dates - you name it. We use a Linux box running Jim Doyle's Tomcat port of Rus Heywood's DevWiki (http://www.gis.net/~jimdoyle/devwiki/devwiki-tomc at.shtml).
We don't do much in the way of archiving... we just kind of use it as a bulletin board. It's definitely very useful though.
Declaring variables at the start of a function is NOT a good programming practice. It is, however, a good way to ensure that you forget to delete them once you remove the associated code - and then you have a wasted variable declaration.
Besides, functions/methods should be short enough so that you don't have to have a "variables used" block at the top.
Code reviews are most effective when done immediately - i.e,. pair programming. Read more about it here:
http://pairprogramming.com
I've found that other approaches - i.e., the draconian "no code gets checked in unless it has been through a formal review" just leads to people not wanting to write code. So any crap that makes it through the review stays in the system for a long time because it's such a hassle to jump through the hoops to change it.
There are a bunch of dead/dormant Sourceforge projects because there is NO barrier of entry for starting a SourceForge project.
And that's OK.
Why? How much CPU time is dedicated to a dormant project? Zilch. How much hard drive space is dedicated to a dormant project? Zilch. How much RAM... etc.
On the other hand, there are lots of very successful, very popular projects over there, like:
Here is what's replacing applets. JNLP is great - once you install a JNLP client, it keeps track of installed JREs, versions, CLASSPATH, etc, automatically. We use Java Web Start (Sun's JNLP client) internally to keep a Swing EJB client up to date and are just pleased as punch with it.
That document is good, but has some inaccurate bits:
Java now has weak references, so he can't complain about that
Calling String.subString() returns a completely new String and makes the original String available for garbage collection (unless you've made the original String a literal in which case it's in the VM constant pool (and why would you do that? (three layers deep, how much further can this go (not much)))).
Slashdot Mirror
Hey Steve -
Right, it's just something to watch out for if you're using the zip task.
I ended up working around it by using the exec task to run the native zip command...
Yours,
tom
....I mean, if you use the Ant zip task to bundle up some files, you'll lose any execute permissions that you had on those files.
So if you do an automated deployment of an app that includes some scripts, you'll need to chmod them again before they'll work.
Other than that, Ant rules.
tom
Howdy -
c at.shtml).
We use a Wiki here at http://www.realeum.com to keep track of a lot of developer information - servers, databases, source code branches, JNLP applications, release dates - you name it. We use a Linux box running Jim Doyle's Tomcat port of Rus Heywood's DevWiki (http://www.gis.net/~jimdoyle/devwiki/devwiki-tom
We don't do much in the way of archiving... we just kind of use it as a bulletin board. It's definitely very useful though.
Yours,
Tom
Declaring variables at the start of a function is NOT a good programming practice. It is, however, a good way to ensure that you forget to delete them once you remove the associated code - and then you have a wasted variable declaration.
Besides, functions/methods should be short enough so that you don't have to have a "variables used" block at the top.
Yours,
Tom
Code reviews are most effective when done immediately - i.e,. pair programming. Read more about it here:
http://pairprogramming.com
I've found that other approaches - i.e., the draconian "no code gets checked in unless it has been through a formal review" just leads to people not wanting to write code. So any crap that makes it through the review stays in the system for a long time because it's such a hassle to jump through the hoops to change it.
Yours,
Tom
There are a bunch of dead/dormant Sourceforge projects because there is NO barrier of entry for starting a SourceForge project.
:-)
And that's OK.
Why? How much CPU time is dedicated to a dormant project? Zilch. How much hard drive space is dedicated to a dormant project? Zilch. How much RAM... etc.
On the other hand, there are lots of very successful, very popular projects over there, like:
JBoss
MiKteX
ImportScrubber
OK, just kidding about that last one
Yours,
Tom
Here is what's replacing applets. JNLP is great - once you install a JNLP client, it keeps track of installed JREs, versions, CLASSPATH, etc, automatically. We use Java Web Start (Sun's JNLP client) internally to keep a Swing EJB client up to date and are just pleased as punch with it.
Yours,
Tom
Good point about the locking model, though.
Tom
We're using NT 4 SP 3 on Pentium 75s with 32 MB of RAM and a 540 MB hard drive - with Office 97 installed locally. Unbelievable.
It's strange that OCC hasn't noticed their new home page... the cracked version is still up.