My high school baseball coach (Dick Bankston) told me once:
Tom, I wasn't a great baseball player. I was OK, but not great. But I worked very hard and got the most that I could out of what talent I had. So I was able to play Div III college ball and have fun without being disappointed about not being able to go professional. I knew I had done the best I could with what I had.
He was a good guy and I thought his attitude was pretty cool.
Quite so. I recently threw away about 400 lines of Java code from PMD and replaced it with 10 XPath expressions. Less code, same unit tests, same results. All good stuff.
Hmm.... but the level of effort required to start an OSS project is nil. I mean, anyone can put up a web page saying "I'm writing an open source PhotoShop!" and then let it sit.
So counting noses and calculating percentages in the open source world doesn't really get you very far...
Fair enough, there's certainly a place for both ways of doing it... and you can always refactor stuff into classes if it becomes necessary to bolt on XML-RPC or SOAP or whatever...
Hmm.... I don't question your experience... but I've found that if a server app is written using classes and such it's much easier to go back and plug in a SOAP wrapper to the "business objects".
For example, GForge has a bunch of classes that we've wrapped via SOAP, so now a Java client can do something like:
Client c = new Client("my.gforge.host", "myproject");
client.login("tom,"fiddlesticks");
Bug[] bugs = client.getOpenBugs();
I'm running 1.01 on my workstation and it's fast as all git out. On the other hand:
[tom@hal javacc]$ cat/proc/cpuinfo | grep Xeon model name : Intel(R) Xeon(TM) CPU 2.80GHz model name : Intel(R) Xeon(TM) CPU 2.80GHz model name : Intel(R) Xeon(TM) CPU 2.80GHz model name : Intel(R) Xeon(TM) CPU 2.80GHz [tom@hal javacc]$
Hm.... that's true in some sense. I mean, the user/group creation is done via a cronjob; it's not manual, but it's not immediate, either. I suppose you could set the cronjob to run every 5 minutes, but there would still be a lag.
I haven't used the LDAP code, so I can't speak to that...
Got suggestions? Head on over to GForge and send 'em in... also, what do you think of the GForge default theme?
Yours,
Tom
Re:Sourceforge / Savannah / Debian SF/ GForge HUH?
on
Debian's Own SourceForge
·
· Score: 2, Informative
Hmmm.... I'm not sure what you mean. GForge does support CVS access (albeit via a series of cron jobs that create the repositories and CVSROOT/readers files and such) and LDAP integration (although I've never used it since storing user info in the database works fine).
The above sentence is not a LISP expression, although it comes close.
Right on. It also lets you bolt on an XML-RPC or SOAP interface later on, which is what we've done with GForge.
Tom
Re:Sourceforge / Savannah / Debian SF/ GForge HUH?
on
Debian's Own SourceForge
·
· Score: 3, Informative
GForge is definitely the "main line" of SourceForge development now... with many new features, including nascent SOAP support, better task management, and an active development community, it's definitely worth a look-see if you need a project management tool.
Here's the GForge install I support - CougaarForge.
I enjoy seeing these articles. I think it's neat that a government would make such a decision, and I'd be especially interested in follow up articles that would say "we ran into these problems which we solved using this program".
And you're right, it wouldn't be as interesting if it were Win2K. I suppose that's because Win2K isn't a community effort...
Here's another scenario: you write a class, it gets reviewed by someone and they suggest you use a Factory pattern. You rewrite it to use Factory, and then it gets reviewed by someone else and they say "why are you adding in that Factory pattern? that just makes it more complicated to use - you're over abstracting!". Both reviewers are right in a way... it all depends on how the class is being used.
There's a nice discussion of alternatives to code reviews here.
True, many bug reports can be translated as "I didn't read the manual".
Nevertheless - there are good ways to handle these. On the info-cvs list there's a fellow who deals with this sort of thing by posting a link to the appropriate FAQ entry or manual page. For example, today someone asked "hey, this -z3 parameter to cvs isn't documented!". Rather than flaming the fellow, Larry just posted a one line response to the exact section of the CVS manual that talks about compression levels. Concise, helpful, and the user will probably get the point that "ah, perchance I should look thru the manual more next time." All good.
Slashdot Mirror
Yup, he was a good guy - everybody had a lot of respect for him. Pretty cool.
Yours,
tom
> These cells will combine on-the-fly
Will they use a Class.forName() or a dynamic proxy? Or maybe they'll all implement Combinable?
My high school baseball coach (Dick Bankston) told me once:
Tom, I wasn't a great baseball player. I was OK, but not great. But I worked very hard and got the most that I could out of what talent I had. So I was able to play Div III college ball and have fun without being disappointed about not being able to go professional. I knew I had done the best I could with what I had.
He was a good guy and I thought his attitude was pretty cool.
Tom
Quite so. I recently threw away about 400 lines of Java code from PMD and replaced it with 10 XPath expressions. Less code, same unit tests, same results. All good stuff.
Yours,
Tom
> 95% of OSS projects are neither
Hmm.... but the level of effort required to start an OSS project is nil. I mean, anyone can put up a web page saying "I'm writing an open source PhotoShop!" and then let it sit.
So counting noses and calculating percentages in the open source world doesn't really get you very far...
Yours,
Tom
This is so true. Your client code should look something like:
Client client = new XMLRPCClient("host", "userid", "passwd");
client.doStuff();
Abstract all the underlying protocol stuff behind that Client interface and your code will be much easier to read and understand...
Tom
Fair enough, there's certainly a place for both ways of doing it... and you can always refactor stuff into classes if it becomes necessary to bolt on XML-RPC or SOAP or whatever...
Yours,
Tom
Hmm.... I don't question your experience... but I've found that if a server app is written using classes and such it's much easier to go back and plug in a SOAP wrapper to the "business objects".
For example, GForge has a bunch of classes that we've wrapped via SOAP, so now a Java client can do something like:
Client c = new Client("my.gforge.host", "myproject");
client.login("tom,"fiddlesticks");
Bug[] bugs = client.getOpenBugs();
Fun stuff!
Yours,
Tom
And 2 GB of RAM... happy days!
I'm running 1.01 on my workstation and it's fast as all git out. On the other hand:
/proc/cpuinfo | grep Xeon
[tom@hal javacc]$ cat
model name : Intel(R) Xeon(TM) CPU 2.80GHz
model name : Intel(R) Xeon(TM) CPU 2.80GHz
model name : Intel(R) Xeon(TM) CPU 2.80GHz
model name : Intel(R) Xeon(TM) CPU 2.80GHz
[tom@hal javacc]$
tom
Hm.... that's true in some sense. I mean, the user/group creation is done via a cronjob; it's not manual, but it's not immediate, either. I suppose you could set the cronjob to run every 5 minutes, but there would still be a lag.
I haven't used the LDAP code, so I can't speak to that...
Yours,
Tom
It will in the not so distant future... see Lo-lan-do's post here:
http://alioth.debian.org/forum/message.php?msg_id= 105
Yours,
Tom
Got suggestions? Head on over to GForge and send 'em in... also, what do you think of the GForge default theme?
Yours,
Tom
Hmmm.... I'm not sure what you mean. GForge does support CVS access (albeit via a series of cron jobs that create the repositories and CVSROOT/readers files and such) and LDAP integration (although I've never used it since storing user info in the database works fine).
The above sentence is not a LISP expression, although it comes close.
Yours,
Tom
Right on. It also lets you bolt on an XML-RPC or SOAP interface later on, which is what we've done with GForge.
Tom
GForge is definitely the "main line" of SourceForge development now... with many new features, including nascent SOAP support, better task management, and an active development community, it's definitely worth a look-see if you need a project management tool.
Here's the GForge install I support - CougaarForge.
Yours,
Tom
Tom
sed -e 's/23/22/g'
Assuming you meant SSH...
Point... counterpoint!
I enjoy seeing these articles. I think it's neat that a government would make such a decision, and I'd be especially interested in follow up articles that would say "we ran into these problems which we solved using this program".
And you're right, it wouldn't be as interesting if it were Win2K. I suppose that's because Win2K isn't a community effort...
Yours,
Tom
"Dead Souls" is great stuff. If you like that, you might also want to read some of the books by Mikhail Bulgakov - "Heart of a Dog", especially.
Yours,
Tom
Wellll.... maybe.... but I think that for many Java projects, at least, a culture of JUnit tests is developing.
Seeing a JUnit report page like this certainly gives me a bit more confidence in a project...
Tom
Yup, code reviews are fraught with pitfalls.
Here's another scenario: you write a class, it gets reviewed by someone and they suggest you use a Factory pattern. You rewrite it to use Factory, and then it gets reviewed by someone else and they say "why are you adding in that Factory pattern? that just makes it more complicated to use - you're over abstracting!". Both reviewers are right in a way... it all depends on how the class is being used.
There's a nice discussion of alternatives to code reviews here.
tom
True, many bug reports can be translated as "I didn't read the manual".
Nevertheless - there are good ways to handle these. On the info-cvs list there's a fellow who deals with this sort of thing by posting a link to the appropriate FAQ entry or manual page. For example, today someone asked "hey, this -z3 parameter to cvs isn't documented!". Rather than flaming the fellow, Larry just posted a one line response to the exact section of the CVS manual that talks about compression levels. Concise, helpful, and the user will probably get the point that "ah, perchance I should look thru the manual more next time." All good.
Yours,
Tom
We use BRU on a couple Linux servers here; seems to work well. Backups are quick and restoring isn't too much of a pain...
Tom
PMD isn't a database... it's a static code analysis tool.
Yours,
Tom