Slashdot Mirror

Oh, $DIETY.... Not taken Scientific Programming in College, I assume? Okay, I'm 35, and I have known about this shit since College, and frankly, even young whippersnappers should know about it. But.. Here's some reading for you

What Every Computer Scientist Should Know About Floating-Point Arithmetic If you don't want to read, but I really URGE you to: it's the "non-precision" is intrinsic to the representation of floats and the errors propagate quite quickly. This has absolutely nothing to do with the example you give, because that is pretty much irrelevant. Besides, it's just illustrates your limited vision due to your local currency. Pennies? How quaint... Yens (for example) don't know these fractional units. My currency before the euro didn't either. (That's one thing, I'd like most programmers to have: get involved in a real international project, with multiple locales, multiple currencies, multiple translations... You'll immediately see how badly most programs are on that level).

Money in Java is the article I usually point programmer rookies to if the above article goes above their head.

Granny's Pearls of Wisdom. For those who never saw Java Ranch.

There is a quote on the java ranch site that is very applicable here: "[Thompson's Rule for first-time telescope makers] It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror." If they shoot for Mars first, it will never happen.

I use [the Post Redirect Get] paradigm 100% of the time.

Likewise, both for the ease for a user and for the cleanliness of the UI. I _know_ what the program is going to do at any given point. There have been many good articles on the PostRedirectGet pattern. The argument against it is the increase in bandwidth. However, considering the rather small size of gets and redirects, compared to the mass of a post or full-page response, this is chump change.

I'd also recommend Javaranch for people beginning Java, I discovered it when I was going for certification and it helped immensely.

Maybe, but I'll say that it's not a bad thing to be able to know Java.

There are benefits and there are drawbacks with Java, as there are with other languages. The drawback with Java is that you don't have any control over memory management, but the benefit is that it's easy to program in if you have been working with C and C++. And you will at least not suffer from some weird bugs that you can get in C or C++.

For beginners in Java I usually recommend JavaRanch.

And to develop I recommend Eclipse. It works fine and can give you instant feedback on many issues. Of course - it has some quirks too, but so does every tool.

And if you want to select a more extreme language I would recommend Erlang. It has a completely different approach than normal procedural languages, but sometimes it makes more sense.

Can we get around to fixing some of these Gotchas?

Oh, what's that? Backwards compatibility? Oh dangit, nevermind...

It might have something to do with some well-known Java Gotchas.

As one of my wise instructors / software architect once said: "Java is a language that was designed by two guys in their garage."

Made me think of Grannies Perls of Wisdom I read on Java Ranch (I first found it about 6 or 7 years ago...): "Testing can show the presence of bugs, but not their absence."

When it comes to programming there are actually two things to learn:

• Knowledge of the language and runtime libraries.
• Knowledge of the development tools.

Anyway - when teaching a programming language there are two parts to consider too, and one is the language sematics and another is how to break down the language in useful modules. You can actually cut even more into the art of programming, but I think it is essentially to teach how to think modules since newbie programmers tends to think in a huge blob resulting in the famous spaghetti programming syndrome.

One advantage of an IDE like Eclipse is that it has support for breaking out code to a separate java method with a simple operation. Other IDE:s may have similar functions.

And don't forget to mention programming style, which is important, especially the generic variable naming shortcuts that can be taken (i,j,k,i0,i1 etc) for index variables instead of longname index variables that tends to clutter the code.

When it comes to code formatting I think that the guidelines offered by JavaRanch is a good start. Most formatting rules can actually be applied cross-language. Any decent IDE will allow you to do code formatting and can be configured to the preferred style.

Cobertura, at least, reports 100% branch coverage on this example as well since there are no statements in the non-existant "else" clause.

Of course, "branch coverage" means at least two things when used casually (you know, like when you're hanging out with your friends this weekend).

[See http://www.javaranch.com/newsletter/200401/IntroTo CodeCoverage.html for one non-proprietary intro to the lingo].

It's at most 50% path coverage, or 50% decision coverage, but 100% "basic branch coverage" and 100% code coverage.

What we really want is something akin to path coverage. Do any of the free tools calculate that for us?

Somewhere like JavaRanch is probably a better place to ask this sort of question.

I usually use this board for any questions I have about AJAX or plain old DHTML. One of the moderators is in the process of coauthoring a book about AJAX, and has some blogs on the subject as well.

I usually use this board for any questions I have about AJAX or plain old DHTML. One of the moderators is in the process of coauthoring a book about AJAX, and has some blogs on the subject as well.

Debug only code - comments can lie.

The parent was copied from here. Mod it down for plagiarism.

There's a site called JavaRanch, which has some useful forums for the serious Java developer. If you participate in their "Open Source Projects" forum, you'll be entered into a draw to win a copy of the book.

Also, one of the authours (Ted Husted) will be on-line to answer questions. Note that you need to register - No Anonymous Cowards!

The "How to write Unmaintainable Code" article on the web is an excellent resource for documentation - much as "Web Pages that Suck is an excellent guide for web designers.

Your organisation - even if it's just 1 man and a dog - should already have a style guide in place. Don't have one? Well then it's easy, there are plenty of good ones on the Net, for Java, C++,Lisp,MATLAB, Ada and many others.

A good list of C and C++ styleguides is here. Just pick one. The important thing is to make sure everyone uses the same one, exactly which one is more a religious issue than anything else. That's an over-simplification, some really are better than others, but at least all the ones on that list have been tried, tested and peer-reviewed.

As for my own opinions, a few issues

• Make variable names meaningful. If you do this, then most of your comments will be metadata, e.g why you did something, and who and when a change was made, rather than what is being done. If you're doing something tricky or unusual, then having a pseudocode preamble can be worthwhile.
• If you can, try to use a relatively high-level language like Ada rather than a low-level one like C. But this is almost never under your control. The Javadoc auto-documentation tool is one of the biggest plusses that Java has over other languages - so if programming in Java, Use It!!

The reviews for the book and comments on Amazon, TheServerSide.com, JavaRanch are very encouraging. Thank you all. And, thanks to SlashDot for reviewing the book on this forum...

I'd like to thank some other folks.

This book would not be possible without the great set of tools written for building and testing J2EE. I'd like to publicly thank James Duncan Davidson et al, Mike Clark, Vincent Massol et al, Kent Beck and Erich Gamma.

James Duncan Davidson et al created Ant. The de facto build tool for Java. This is the glue for building applications and making continuos integration doable with Java.

JUnit is the regression-testing framework written by Erich Gamma and Kent Beck. After looking at this code base you can see this framework screams with design patterns and solid OOP, and is central to Extreme Programming development with Java. It is as if these guys wrote *the definitive books* on Design Patterns and Extreme Programming--oh yeah they did!

Russell Gold wrote HttpUnit, which makes functional web applications easy and fun. (It can also be combined with Cactus.)

Mike Clark extended JUnit to provide JUnitPerf, which does load testing and performance testing. This code is an excellent example of how to extend JUnit. Mike Clark is also a really nice guy.

Vincent Massol et al for creating the Cactus (was J2EEUnit). I use this tool every day at work to unit test JSP Tags and EJBs. This is a truly novel tool. (BTW Nicholas Lesiecki, the co-author of the book, is an active committer on this project.)

Vincent Massol of Cactus contributed to the creation of the book. He reviewed the chapter on Cactus. His acknowledgement was accidentally omitted from the book during publication.

I am not implying that anyone mentioned above endorses the book or name dropping. I just wanted to thank them for contributing their time and effort to create these tools and then just give them away! Without them this book would not exist.

The book has been a bestseller under software development on Amazon most of this year. Thank you. We are blown away with the success of the book.

Check out these threads about the book if you get a chance....

Thread TheServerSide.com

Nick and I answered a lot of questions about the book at the JavaRanch as well...

Thread at JavaRanch
I've posted some more background information about the book here...

Book Web Site

I'll check back and try to answer any questions about the book. Thanks again.

The web site will soon have a sample chapter on it. Later, when we write the second edition, the book web site will have early drafts for review.

--Rick Hightower Co-Author of Java Tools for Extreme Programming

"...This book is a fine introduction to a whole bunch of really useful tools to boost your Java and especially J2EE programming.... This book was almost too useful to review. ... If you want to get up to speed quickly and practically on a load of useful, powerful, tools - get this book. Everyone I've shown it to has wanted their own copy ... "

--Frank Carver

Check out the full review at http://www.javaranch.com/bunkhouse/bunkhouseDesign . sp

This review became book review of the month at JavaRanch!

Topic: JavaRanch lives!

The original article is no longer available at javaranch, and there's a followup article here. It looks like all will be well... on the Sun / JavaRanch front anyway.

Here's another Java style guide