JavaDoc: The unloved child. A pragmatic approach.
One of the things I think it done better in Java than in just about any other language I have used is documentation via Javadoc. I frequently use Javadoc-generated documentation for the Java SE, for the Java EE, and for other products in the Java ecosystem such as JFreeChart and Groovy (which has three!: GDK, Javadoc for Java Classes, and Groovydoc for Groovy and Java Classes). I find using others' Javadoc to generally make it easier to use their APIs (assuming correct documentation!) and I like the ability to have ready access to API documentation online and in my favorite IDE. I also enjoy being able to document how to use my APIs, packages, and classes, in package descriptions. This allows the clients of my APIs to see examples of how to use my API and nicely includes the documentation in the same area/file as the source code itself. In the post JavaDoc: The unloved child. A pragmatic approach., Markus Eisele concisely describes why Javadoc is useful and suggests some tips for making writing and maintaining of Javadoc comments more effective.
XML: Contrary to popular belief, it doesn't always kill babies
We software developers (as a whole) seem to be prone to violent swings between positions on things. Derek Thurn's post XML: Contrary to popular belief, it doesn't always kill babies does a nice job of pointing out how this happened with XML (loved and revered for a while and now not discussed in polite company). As with most of these extreme shifts, neither extreme was appropriate. XML was overhyped for a while and was used in many unnatural ways, but now developers in general (if the blogosphere is at all indicative) seem to wish to avoid XML without regard to the problem. I believe the appropriate position is somewhere in between. Thurn's post briefly discusses situations where alternatives like JSON and YAML are preferable to XML and the outlines two situations where he believes XML is appropriate (and I agree). I also like that Thurn states "XPath turned out to be a godsend" (something I have found as well in my work with XQuery and other things areas where XPath support is useful). It's also very difficult to argue with Thurn's use of SOAP as an example of "terrible things" people have done with XML.
10 Reasons to Say “No” to Cloud Computing?
I like posts that challenge the Lemming Effect. The previously discussed XML post challenges the potential lemming behavior of avoiding XML regardless of whether the situation warrants it or not and is an example of bucking the lemmings' general direction avoiding something (negative reaction). On the other side, it can be just as useful to avoid thoughtless following of lemmings to adopt something (positive reaction). I like 10 Reasons to Say “No” to Cloud Computing? because the author starts out with this:
I have been writing about the benefits of migrating to the Cloud in previous articles but it is also important to highlight in which circumstances the Cloud Computing route may not be the appropriate one.
When I first read this paragraph, I was afraid this post was going to be another one of those that would have ten reasons such as "you want to do things the hard way" and "you like a good challenge." Fortunately, this post turned out to be what was really advertised. The ten reasons are good ones to think about and I also appreciate the author's pointing out that "Cloud Computing is NOT an all-or-nothing decision." No tool or methodology can be all things to all people all the time and I suspect anyone who claims their favorite to do just that. It is much more useful to read from an evangelist of an approach about where that approach fits or does not fit and this post fits into that more useful category. Some people think cloud computing is not a good idea, but it (or portions of it) can be useful when applied correctly in the appropriate situations.
Two recent articles of interest related to Java security are RSA: Java is the Most Vulnerable Browser Plug-in and Google extensions could aid Java security.
In "RSA: Java is the Most Vulnerable Browser Plug-in," Sean Michael Kerner reports that Qualys CTO Wolfgang Kandek stated that 42% of monitored web users had "vulnerable out-of-date" Java plug-ins and that this plug-in was the most frequently out-of-date and vulnerable of those measured. Other plug-ins that were vulnerable due to being frequently out of date include Adobe Reader, Apple QuickTime, and Adobe Flash. As I read this, the ranking is not of how vulnerable one plug-in is as compared to another, but how vulnerable they are because they are out-of-date. Kerner also points out that Cisco had reported that Java vulnerabilities are now more exploited than those in Adobe Acrobat and Reader.
Joab Jackson writes that Google Contracts (Contracts for Java or cofoja), which is often advertised as and thought of as an approach for making it easier to appropriately use methods (above and beyond what the previously mentioned Javadoc provides), can also help make Java code more secure. He states that this project based off of Modern Jass can provide some of the same security benefits to Java that Eiffel developers claim are inherent in Eiffel's support for Design by Contract (DbC).
There are far too many interesting and insightful posts about software development to keep up with all of them. In this post, I've tried to summarize and publicize some recent posts that I believe are worth a look if you have not read them already.