Just these days, JSR 250 has been approved in the public review ballot. Only IBM voted with "no".
I cannot understand the process entirely. Here are my reasons (also see my former entries JSR 250 (Common Annotations): Opinion and Is JSR 250 already mature?)
Some weeks ago, exactly on 2005-06-25, I send several pages of suggestions to jsr-250-comments@jcp.org (the mail given to do so). No answer, nothing. On 2005.07-21, I asked the spec. leader, Rajiv Mordani, at rajiv.mordani@sun.com to give me an explanation, why there is no answer to a well-meant, reasonable suggestion and contribution to JSR 250. Again, no answer, nothing. This is very frustrating for someone who spent several hours thinking and writing something to enhance the JSR 250 in its current form. I regard the JSR 250 as weak, premature and not acceptable in common. The comment of IBM gives at least *some* hint about the validity of my opinion.
Also, the concrete suggestions stated by individuals in a discussion about the first draft were not recognized and/or not considered.
I await the effect of the JSR to the community eagerly. Will the community accept and use the common annotations? I don't think so. But let's wait...
A frustrated blogger and neutralized JSR participant...
15.7.05
Physics and Computer Science
As I discussed in a former entry, Why Quantum Theory is important for Object Orientation, I see a connection, a conceptual link between physics and computer science.
That I am not alone with this opinion, although it might sound strange at first, could be seen by the article of Günther Meinhold: Einstein 2005: Modell und Wirklichkeit (model and reality), unfortunately for all non-German speaking people in a foreign language ;-)
The author draws the following comparisons, which I might be allowed to translate for showing the main idea behind the article:
Yeahhh! I am not the only one out there believing in physics influencing computer science.
Anyone out there who doesn't love Einstein? Can't think so (he is not the father of the atom bomb, btw., please don't argue this way).
That I am not alone with this opinion, although it might sound strange at first, could be seen by the article of Günther Meinhold: Einstein 2005: Modell und Wirklichkeit (model and reality), unfortunately for all non-German speaking people in a foreign language ;-)
The author draws the following comparisons, which I might be allowed to translate for showing the main idea behind the article:
| Physics | Computer Science |
| Models of real objects | Models of the software product to develop |
| Models demonstrate how Nature works | Models show how the future software product works |
| Physical model | Logical object model |
| Mathematical model | Design object model |
| Mathematical calculation | Creation/Development of source code |
| Mathematical results for measurable physical parameters | Executable source code with testable functionality |
| Experiments and observations as test basis for the models and their results | Test of the functionality of the software against the product requirements |
Yeahhh! I am not the only one out there believing in physics influencing computer science.
Anyone out there who doesn't love Einstein? Can't think so (he is not the father of the atom bomb, btw., please don't argue this way).
10.7.05
Is JSR 250 already mature?
As discussed earlier in a more general manner, I have the feeling that JSR 250 is away from a publishable form. Here are some of my concrete suggestions on how to pimp up the current paper released on June, 21st. I already sent them to the JSR commission as an RTF-document containing of several pages:
- Define what the JSR 250 really is about. There is no commen consensus about which aspects should be covered by the common annotations to be defined in JSR 250.
- I suggest including only annotations that have a generic character and support concerns of common interest that are not too complex (if they were they could be part of a separate JSR).
- Group annotations: It should be quite obvious how to group the currently defined annotations in the public review paper. This should be a first and easy step getting a better feeling on where the journey goes.
- Context-free aspects that could be covered by annotations could be:
- Design Patterns, especially the topics
- name of the pattern
- role within a design pattern
- description of the pattern itself and of its roles
- Design by Contract-related issues
- Architectural layers, such as (just to give an idea)
- persistence
- persistence mapping
- interfaces to third-party systems
- business logic
- domain logic
- transportation / protocols
- view mapping
- view logic
- display
The current version of the JSR 250 public review seems not adequate for manifesting or extending it in a way that it is displaying when reading it. As I suggested, there should be a general refurbishment of the whole paper. We are far from looking at if a single annotation proposed by the JSR’s expert group is useful, should contain additional information or should be renamed.
The problem is of more principle nature: The goal should be defined in round terms, a firm stand should be taken, context-free (or, say, generic) annotations should be considered instead of special ones and the direct support for J2EE specifics should be reconsidered.
Interesting resources:
7.7.05
JSR 250 (Common Annotations): Opinion
The public review of the JSR 250 (Common Annotations for the Java Platform) has been published on June, 21st. After looking thru the list of annotations provided, I felt somewhat puzzled. IMHO, there is no clear line visible, no clear concept recognizable on which the selection of the annotation proposals is based.
I will write another entry soon explaining in more detail what I have written to the JSR 250 expert group as my proposal on how the annotations of this JSR should be choosen.
From my point of view, this JSR should mostly (exclusively?) contain annotations that are of common interest and are context free. One could joke about whether annotations specifically designed for J2EE could ever be of common interest. At least they are not context free.
Context free means in this context (intentional word repetition :-) ) that the thing annotated is context free. Take Design Patterns for example. They provide a context free concept of how to improve the architecture of your software system to allow for easier maintenance and better documentation of it.
I will write another entry soon explaining in more detail what I have written to the JSR 250 expert group as my proposal on how the annotations of this JSR should be choosen.
From my point of view, this JSR should mostly (exclusively?) contain annotations that are of common interest and are context free. One could joke about whether annotations specifically designed for J2EE could ever be of common interest. At least they are not context free.
Context free means in this context (intentional word repetition :-) ) that the thing annotated is context free. Take Design Patterns for example. They provide a context free concept of how to improve the architecture of your software system to allow for easier maintenance and better documentation of it.
Naming conventions for variables
After several years of experience in software development, I found a way of naming variables (attributes, fields, field declarations, as you like) that I feel convenient with.
First of all, in any class representing a business object (i.e., that contains business logic to a certain amount) there should only be private variables. Protected variables don't allow for implementing the Observer pattern! Use getters and setters instead. In few classes it may seem suitable using public fields because those classes are only used as very simple data containers.
My naming conventions for variables have evolved to the following:
First of all, in any class representing a business object (i.e., that contains business logic to a certain amount) there should only be private variables. Protected variables don't allow for implementing the Observer pattern! Use getters and setters instead. In few classes it may seem suitable using public fields because those classes are only used as very simple data containers.
My naming conventions for variables have evolved to the following:
- At class level - for private and protected fields (if any) - I use the prefix m_
- At method level there are two cases:
a) method signature: I use prefix a_
b) method body: No prefix, just the variable name.
Using this kit of simple concepts, it is very easy determining the scope of a variable just by looking at its name very superficially. In a setter method, the naming conventions allows to quickly find assignment errors and helps avoiding "this.", which in most cases (I saw) is regarded as ugly.
After an possible prefix the name of the variable starts with a lowercase letter. If there are multiple words concatenated together, from the second word on each word starts with an uppercase letter, such as: private int m_thisIsMyVariable;
Variables being constants by having the final static modifiers, are written all in uppercase letters. By the way, they are always public (at least if they are declared at class level).
6.6.05
Intentionally failing JUnit tests
In the JUnit mailing list, I followed a discussion about how to implement tests that are failing intentionally with an exception, i.e. the existence of an exception is seen as correct and the other case is a failed test.
Several proposals were made. Let me cite the initial comment on the subject partially:
--------------- snip
Someone in our team writes his tests like this:
try
{
articleProvider.findArticleById("foobar");
}
catch(NoObjectFoundException e)
{
assertTrue(true);
}
He says that e does it because otherwise Checkstyle would complain about the empty catch block.
I do it in this manner:
try
{
articleProvider.findArticleById("foobar");
}
catch(NoObjectFoundException e)
{
// Its okay since we expect it.
}
--------------- snap
I find the "assertTrue(true)" in the catch statement very funny (who codes like this?). It is of course legitimate and correct to take care of Checkstyle, but in this way?
Most (serious) developers in the JUnit mailing list proposed to do it the latter way (putting a comment like //ignore in the catch block), but then you again will get a Checkstyle violation.
What about my solution:
Semicolon itself is an empty statement, there you go...
See JGAP for a sample application.
Several proposals were made. Let me cite the initial comment on the subject partially:
--------------- snip
Someone in our team writes his tests like this:
try
{
articleProvider.findArticleById("foobar");
}
catch(NoObjectFoundException e)
{
assertTrue(true);
}
He says that e does it because otherwise Checkstyle would complain about the empty catch block.
I do it in this manner:
try
{
articleProvider.findArticleById("foobar");
}
catch(NoObjectFoundException e)
{
// Its okay since we expect it.
}
--------------- snap
I find the "assertTrue(true)" in the catch statement very funny (who codes like this?). It is of course legitimate and correct to take care of Checkstyle, but in this way?
Most (serious) developers in the JUnit mailing list proposed to do it the latter way (putting a comment like //ignore in the catch block), but then you again will get a Checkstyle violation.
What about my solution:
try { articleProvider.findArticleById("foobar"); catch(NoObjectFoundException e) { ;// this is OK }The only simple thing I do is adding a semicolon to the catch block.
Semicolon itself is an empty statement, there you go...
See JGAP for a sample application.
22.2.05
JDO: My opinion
Due to the, say, failure of JDO (see the public review ballot) some developers (about a thousand) "signed" the Petition to the Java Community Process Executive Committee.
My opinion about JDO in some short statements is:
JDO is transparent in a different way than, for example, java.io.Serializable is. JDO manipulates class files, not the source code. I don't like this as you could run into difficulties when doing Test-Driven Development (TDD), and I like to see what is there (namely in the source code. There sometimes was a post on Joel on Software, The Law of Leaky Abstraction, about the problems with abstractions.).
JDO seems to be a good solution but not the best I could dream of. Just one remark to the disposedness of SAP, a really big software development company, about JDO: In later releases of the NetWeaver Developer Studio for Java, part of the huge NetWeaver architecture, JDO was not supported. Period. You could hack and get JDO out of it, but who wants to develop software that way?
I would prefer a solution based on a code generator, or, if possible, something similar to java.io.Serializable (althought the latter may be too inconcrete to argue about, as it's only about introducing a marker interface). But a code generator would add the necessary flexibility as well as the necessary capability! And you could TDD your code as you like, do code coverage analysis on source code, which would make things much more fun. Some say, don't test third-party products. But relying on "a" third party toolkit made by people not known the to-believed trusting person is not the best sort of risk management to think about. Only one argument: Open-Source. Although not bad in general, many of these projects have kind of a charme like "Ahh, there is someone who wants to contribute, I don't know him, but he is willing to add something, so let him do. And if I, the project admin, find time, I will check what he really has done". I love open source but I would not trust it generally. There is no support, in contrast to many commercial products (allow me to cut it short here).
My opinion about JDO in some short statements is:
JDO is transparent in a different way than, for example, java.io.Serializable is. JDO manipulates class files, not the source code. I don't like this as you could run into difficulties when doing Test-Driven Development (TDD), and I like to see what is there (namely in the source code. There sometimes was a post on Joel on Software, The Law of Leaky Abstraction, about the problems with abstractions.).
JDO seems to be a good solution but not the best I could dream of. Just one remark to the disposedness of SAP, a really big software development company, about JDO: In later releases of the NetWeaver Developer Studio for Java, part of the huge NetWeaver architecture, JDO was not supported. Period. You could hack and get JDO out of it, but who wants to develop software that way?
I would prefer a solution based on a code generator, or, if possible, something similar to java.io.Serializable (althought the latter may be too inconcrete to argue about, as it's only about introducing a marker interface). But a code generator would add the necessary flexibility as well as the necessary capability! And you could TDD your code as you like, do code coverage analysis on source code, which would make things much more fun. Some say, don't test third-party products. But relying on "a" third party toolkit made by people not known the to-believed trusting person is not the best sort of risk management to think about. Only one argument: Open-Source. Although not bad in general, many of these projects have kind of a charme like "Ahh, there is someone who wants to contribute, I don't know him, but he is willing to add something, so let him do. And if I, the project admin, find time, I will check what he really has done". I love open source but I would not trust it generally. There is no support, in contrast to many commercial products (allow me to cut it short here).
17.2.05
When TDD is not optimal
As a big fan of TDD, I often use it, admittedly mainly in a sort of poisoned form. I am not writing all tests before writing the code. At least half of it I write after "semi-completing" a method or a bunch of methods.
These days I wanted to bring in the functionality of a third-party open source framework into code of mine. But at the beginning I was not sure if the concepts of my framework and the other one would allow a joining. Therefor it had a touch of prototyping merging some logic of the other framework into mine.
If I wrote test cases before or even during this activity, they would probably had been a waste of time, in case the joining would have not worked as I hoped. But on the other hand ensuring the correctness of the newly created logic is number one priority and most important as unknown code always is a danger for a project.
Reflecting, I am quite content with my approach not to write the tests until the current point, where I am nearly finished merging the two frameworks and see that it works in general. There is enough time for that right now, I am likely to say, although I know that some guys would raise their hands and remark about the semi-optimal appraoch chosen. An important aspect seems the experience of the developer involved in the process, from the perspective of software development in general as well as from the special perspective on the code to be extended.
Is there anyone having merged two code bases with writing test cases during or even before the merger? I would be very interested in knowing details.
These days I wanted to bring in the functionality of a third-party open source framework into code of mine. But at the beginning I was not sure if the concepts of my framework and the other one would allow a joining. Therefor it had a touch of prototyping merging some logic of the other framework into mine.
If I wrote test cases before or even during this activity, they would probably had been a waste of time, in case the joining would have not worked as I hoped. But on the other hand ensuring the correctness of the newly created logic is number one priority and most important as unknown code always is a danger for a project.
Reflecting, I am quite content with my approach not to write the tests until the current point, where I am nearly finished merging the two frameworks and see that it works in general. There is enough time for that right now, I am likely to say, although I know that some guys would raise their hands and remark about the semi-optimal appraoch chosen. An important aspect seems the experience of the developer involved in the process, from the perspective of software development in general as well as from the special perspective on the code to be extended.
Is there anyone having merged two code bases with writing test cases during or even before the merger? I would be very interested in knowing details.
15.2.05
Sourceforge in trouble?
For every sourceforge project there is a nice usage statistics reflecting the number of page views and downloads per day (or other time spans if you want).
But since January, 15th, over one month ago, no further statistical data is shown.
Sourceforge knows about this and informs that they are going onto a new statistics system:
"Project statistics data for 2005 that is omitted will not be processed until launch of the new statistics system. This data has been collected, but has not been processed for display. To ensure accuracy and reduce performance impact to users, these dates will be omitted until the new statistics system is launched. There is not currently a date set for the rollout of the new stats system. Please keep an eye here for that date when we release it."
What I wonder about is the amount of time necessary to do so. One month is about beyond any basis for discussion, I strongly believe. There must be a deeper reason and not just small problems that arose when doing the job.
But since January, 15th, over one month ago, no further statistical data is shown.
Sourceforge knows about this and informs that they are going onto a new statistics system:
"Project statistics data for 2005 that is omitted will not be processed until launch of the new statistics system. This data has been collected, but has not been processed for display. To ensure accuracy and reduce performance impact to users, these dates will be omitted until the new statistics system is launched. There is not currently a date set for the rollout of the new stats system. Please keep an eye here for that date when we release it."
What I wonder about is the amount of time necessary to do so. One month is about beyond any basis for discussion, I strongly believe. There must be a deeper reason and not just small problems that arose when doing the job.
1.2.05
Why Quantum Theory is important for Object Orientation
Historical information
Quantum Theory is the most precise complex theory we have today. There is no other theory of such universality and brilliancy. The theory was created by Max Planck in the year 1900. In his earlier years, Planck wanted to study physics and was told that this would not be beneficial as anything of importance had already been discovered. Good for us he did not follow that hollow advice.
After Planck laid the foundation, world-famous Albert Einstein who is being celebrated this year (Einstein year, year of Physics) because of the 100th aniversary of the Quantum Theory and his 50th day of death, extended the great theory "casually". Then, he was employed at the patent office in Bern, Switzerland and was able to think about the problems with Quantum Theory while doing his daily business (which he must have found sort of boring and that used about 1% of his intellectual capacity, I assume). That is someone you would name a genius!
Other great names correlated with the theory are Niels Bohr (danish, outstanding character and physician, mentor of Heisenberg), Werner Heisenberg (founder of the Uncertainty Principle), Erwin Schrödinger (developed wave mechanics as well as Heisenberg did, but from a different perspective as discovered later on) and not to forget Max Born as teacher of many great physicians such as Heisenberg, Robert Oppenheimer (director of the well-known Manhattan project in Los Alamos), Fermi and Edward Teller (father of the hydrogen bomb).
It's all about philosophy
For most people not having a general understanding of Quantum Physics, it's not easy to see that this theory at first is capable of explaining our daily life's experiences (such as velocity, chemical reactions etc.). One must make himself aware that Quantum Physics contains Newton's Theory which is only a special case of Quantum Physics! Secondly, Quantum Theory predicts - and that is common sense and out of discussion in physicians circles - that nothing is determinated, meaning we are ruled by randomness. If you don't believe it you are in company with Einstein but not with Stephen Hawking. At third Quantum Theory is the most precise theory we have. Period. Next, Quantum Theory and Einstein's Theory of Relativity both meet when it comes to trying to explain Black Holes. This is because Quantum Theory copes with very small particles and a Block Hole is something very very small. And it is because Einstein's theory is appropriate for explaining huge mass embodiment, such as a Black Hole.
There is no Reality
Although Quantum Theory is the best theory we have, it is not a correct and complete one. If you don't believe it, I suggest reading some books about it. The theory is all about trying to give us a quite good description of what reality might be and how we could predict future states of our reality. Heisenberg's Uncertainty Principle alone prohibits knowing about reality precisely!
As we can easily see Physics and Object Orientation are both subject to objects. The type of objects does not matter, may they be technical instances or real instances. There are no real instances as said before. Both theories, Physics as a whole, and the OO paradigm are only descriptions of a theory that is commonly seen as "good". Nothing more.
Shortfalls
So, just being logic and asking a provocative question: If:
- Quantum Theory is a very good theory and
- Quantum Theory for sure is much more complex than the theory of Object Orientation and
- both theories are about describing objects as part of our "reality"
then, how could someone think about OOP as a near-perfect paradigm? How could someone think OOP is a really good theory? I don't want to say that OOP is a bad thing, I love it. But as OOP is so extremely simple compared to Quantum Theory, and OOP has its weaknesses, how could we think of that there are no potentials? Many people don't think so, fortunately. But some love OO that much, that they get blind about its pitfalls. Just remember AOP as an attempt to make OOP more powerful and capable. And evertime you try to make something more powerful it will soon get too complicated. So AOP will be doomed to die out in just a few years as will classical OOP. AOP is too impratical to be used by the mass of developers out there. But it is a necessary step recognizing the possibilities and necessities to form a new theory of describing situations in a machine-understandable form.
27.1.05
Resources related to "Information Engineering"
The science I want to call Information Engineering here copes with the evaluation of data in order to to obtain information and the extraction of high-priority information (filtering out data of lower interest) from a plethora of information. Information Engineering helps reduce the problem of information overflow, just remember the latest prominent example of Cassini-Huygens.
The following resources I came up with when investigating the subject. My motivation was the advancement of the Java Genetic Algorithm Package, JGAP, developed by some other people as well as by myself.
Collection of Resources
Also see my other blog about Visions for Evolutionary Algorithms
The following resources I came up with when investigating the subject. My motivation was the advancement of the Java Genetic Algorithm Package, JGAP, developed by some other people as well as by myself.
Collection of Resources
- Articles about Information Architecture Research hosted by Semantic Studios.
- Information Wants to be Liquid. Features Tim Berners-Lee
- Computer Games and AI
- NSA in need of Information Engineering
- Information Architecture Library
Also see my other blog about Visions for Evolutionary Algorithms
Visions for Evolutionary Algorithms
Browing sourceforge and other open-source platforms, you find myriads of free software packages. Many of them have a glance of sophistication. But what about their practical use? An article from these days states that the NSA is in high need of a capable software tool that can identify information having a potential of being valuable. The NSA wants to "connect dots" and needs informatics to do so.
These classification problems are among the most interesting ones I could imagine nowadays (in my role as a computer scientist and "informaniac"). What I think would help bringing up a solution is Evolutionary Algorithms (EA). EA's align with nature, evolution based on Charles Darwin and inheritance from Gregor Mendel. Part of the EA approach is Genetic Algorithms (GA) and Genetic Programming (GP). The currently developed GA framework, JGAP (Java Gentic Algorithms Package), helps accomplishing both concepts. Work is currently undertaken to develop GP by adapting GA and infusing more flexibility to it.
If you are interested in knowing more, feel free to go to the sourceforge site of JGAP to see project information, or use the project homepage submitting several information about GA's of general interest.
A valuable resource about Genetical Engineering can be found in wired magazine with their article Life, Reinvented.
Also related: Games that make leaders: top researchers on the rise of play in business and education
These classification problems are among the most interesting ones I could imagine nowadays (in my role as a computer scientist and "informaniac"). What I think would help bringing up a solution is Evolutionary Algorithms (EA). EA's align with nature, evolution based on Charles Darwin and inheritance from Gregor Mendel. Part of the EA approach is Genetic Algorithms (GA) and Genetic Programming (GP). The currently developed GA framework, JGAP (Java Gentic Algorithms Package), helps accomplishing both concepts. Work is currently undertaken to develop GP by adapting GA and infusing more flexibility to it.
If you are interested in knowing more, feel free to go to the sourceforge site of JGAP to see project information, or use the project homepage submitting several information about GA's of general interest.
A valuable resource about Genetical Engineering can be found in wired magazine with their article Life, Reinvented.
Also related: Games that make leaders: top researchers on the rise of play in business and education
24.1.05
Java UI Frameworks: Far way to satisfaction!
Similar to my former entry, Java Persistence: Failed, I have been stimulated by another entry, this time from Alexey Maslov, who asks Do we need another UI framework?.
In my comment to his entry, I stated that in my eyes, there is no real UI framework existent for Java, being capable of representing a common platform for UI development. Either it is too expensive (I want a framework for free, please. Look at Delphi, SAP etc. where several standardized mechanisms are there to satisfy the developer). Or it is instable, too hard to learn, not capable enough etc.
Sorry, I have not found a single framework fitting my simple needs. When trying out Luxor/XUL at first I thought there is light at the end of the tunnel. But then I soon recongnized the limized features when it comes to event-handling and other non-regular stuff (what is irregular about event-handling, one might ask).
As long as we ask questions such as Why does GridBagLayout get tab order wrong? we have a far way to go to satisfaction!
In my comment to his entry, I stated that in my eyes, there is no real UI framework existent for Java, being capable of representing a common platform for UI development. Either it is too expensive (I want a framework for free, please. Look at Delphi, SAP etc. where several standardized mechanisms are there to satisfy the developer). Or it is instable, too hard to learn, not capable enough etc.
Sorry, I have not found a single framework fitting my simple needs. When trying out Luxor/XUL at first I thought there is light at the end of the tunnel. But then I soon recongnized the limized features when it comes to event-handling and other non-regular stuff (what is irregular about event-handling, one might ask).
As long as we ask questions such as Why does GridBagLayout get tab order wrong? we have a far way to go to satisfaction!
Developers Don't Write Documentation
An article titled Developers Don't Write Documentation can be found at OpenXource. It is written with some wit and is worth reading. As the article's title expresses, it is the opinion of the author that developers shouldn't focus on writing documentation. Documentation is meant here as documentation for the user of the software not technical documentation I assume.
Reasons
Well, I also assume that most developers love to code or construct and develop an architecture but don't like to write that much plain text for the stupid user (ironically, of course). This seems human. When working on a doctorate you notice that thinking about great ideas, getting inspirations, drawing graphics and schemata is refreshing and satisfying most time. But when it comes to clearly structuring the stuff, choosing correct, concise and consistent formulations (3 C's Law?) then the brain soon gets stuck, often.
For coding software the reason could be the break in paradigms between writing code and writing natural language. The latter implies a more or less informal system, a non-consistent grammar, ambiguous expressions and no compiler checking everything. The only thing you have at hand is perhaps the word processor aiding to some extend with simple grammar checks embodying the intelligence of a stupid child (which is astonishing as intelligent software is rare and hard to craft, IMO).
Test-Driven Development
There always is a problem letting an outsider (not a developer) write documentation. How does he know in which way the system works and what the intentions of the developers are? In my eyes, a documenter needs to understand at least a bit of software development. And if he knows too much, he would probably love to code and would not be the right person for documenting.
To get out of the mess a little, I like to suggest the idea of Test-Driven Development (TDD). TDD is not only a possibility of validating your code work as expected but also (or mainly!) a documentation tool. TDD expresses what your code should do. It's the same with Design Patterns, although many people don't recognize the documentation power of both Design Patterns and TDD!
So go write your tests and with that create a basis for other people understand your well-validated masterpiece in order to write documentation for it. Isn't that a valid approach?
Reasons
Well, I also assume that most developers love to code or construct and develop an architecture but don't like to write that much plain text for the stupid user (ironically, of course). This seems human. When working on a doctorate you notice that thinking about great ideas, getting inspirations, drawing graphics and schemata is refreshing and satisfying most time. But when it comes to clearly structuring the stuff, choosing correct, concise and consistent formulations (3 C's Law?) then the brain soon gets stuck, often.
For coding software the reason could be the break in paradigms between writing code and writing natural language. The latter implies a more or less informal system, a non-consistent grammar, ambiguous expressions and no compiler checking everything. The only thing you have at hand is perhaps the word processor aiding to some extend with simple grammar checks embodying the intelligence of a stupid child (which is astonishing as intelligent software is rare and hard to craft, IMO).
Test-Driven Development
There always is a problem letting an outsider (not a developer) write documentation. How does he know in which way the system works and what the intentions of the developers are? In my eyes, a documenter needs to understand at least a bit of software development. And if he knows too much, he would probably love to code and would not be the right person for documenting.
To get out of the mess a little, I like to suggest the idea of Test-Driven Development (TDD). TDD is not only a possibility of validating your code work as expected but also (or mainly!) a documentation tool. TDD expresses what your code should do. It's the same with Design Patterns, although many people don't recognize the documentation power of both Design Patterns and TDD!
So go write your tests and with that create a basis for other people understand your well-validated masterpiece in order to write documentation for it. Isn't that a valid approach?
23.1.05
Test-Driven Development: Useful Techniques, Resources
Test-Driven Development (TDD) is subject of many publications. I feel that it never was seen as a hype. From my point of view, it is a really useful concept helping great in reducing errors. That seems proven, IMO. I used TDD in several projects, currently with JGAP and with a software package based on JRefactory.
I found out that many test cases rely on the same testing techniques, such as:
Type Cast
When testing if the return value of a method call conforms with a certain type, you could write:
Better would be:
The latter ensures that we really get a String type back. The former could also be tue if the toString() method of the type returned is accordingly.
You could also use Type Case if you only wanted to ensure that an element at a given index in the list is not null and conforms to a special type.
Elements in unordered collection
If the result of a method under test is an unorded List or a Map, then it should nevertheless be tested whether obligatory elements exist in the collection and others do not. We can easily accomplish this by firstly building up an internal Map (e.g. java.util.HashMap) by putting in all elements that are expected to be returned by the method unter test.
After that we perform the method call. Then, we iterate over the returned list and call a helper method such as
This method could read like:
public void assertInList(final Map list, String s) {
Don't forget to write
Molecular tests
It is not forbidden to include multiple asserts within one testcase. The advantage of only one assertion (or more generally: check) in a test case is that one could immediately see the point of failure. But with my IDE I could easily figure out the assertion faiiling just one mouse click later. Multipel assertions in one test case help validate more than one thing without the need of constructing again and again the input configuration (instantiatng objects, setting parameters).
Resources
Other publications about TDD:
I found out that many test cases rely on the same testing techniques, such as:
Type Cast
When testing if the return value of a method call conforms with a certain type, you could write:
assertTrue("My String",vector.get(0));Better would be:
assertTrue("My String",(String)vector.get(0)); The latter ensures that we really get a String type back. The former could also be tue if the toString() method of the type returned is accordingly.
You could also use Type Case if you only wanted to ensure that an element at a given index in the list is not null and conforms to a special type.
Elements in unordered collection
If the result of a method under test is an unorded List or a Map, then it should nevertheless be tested whether obligatory elements exist in the collection and others do not. We can easily accomplish this by firstly building up an internal Map (e.g. java.util.HashMap) by putting in all elements that are expected to be returned by the method unter test.
After that we perform the method call. Then, we iterate over the returned list and call a helper method such as
assertInList(final Map list, String s); This method could read like:
public void assertInList(final Map list, String s) {
if (list.containsKey(s)) {
list.remove(s);
}
else {
fail("Object " + s + " not in list!");
}
}Of course, you could extend this helper method for handling types delivered in the java.lang package. Sometimes a developer states java.lang.Comparable and sometimes he omits the package. By extending method assertInList to check for a string concatenated by java.lang and the string originally searched, we could make these instances equal.Don't forget to write
assertEquals(0, list.size());after testing against the obligatory elements to ensure no other (unwanted) element is in the return list under test.Molecular tests
It is not forbidden to include multiple asserts within one testcase. The advantage of only one assertion (or more generally: check) in a test case is that one could immediately see the point of failure. But with my IDE I could easily figure out the assertion faiiling just one mouse click later. Multipel assertions in one test case help validate more than one thing without the need of constructing again and again the input configuration (instantiatng objects, setting parameters).
Resources
Other publications about TDD:
- Scope of Unit Tests
- A Series on Test Driven Develolpment
- Test-Driven Development Is Not About Testing
- TDD for Beginners
- TDD is like teenager sex
- It's time to drop the 'T' from TDD
- Agitator and TDD
- Introduction to Test Driven Development (book excerpt)
- Getting Started (book excerpt)
- Unit Testing: The Foundation of Test-Driven Development (book excerpt)
- TDD and Genetic Programming
- How To Simulate Key Events In Swing JUnit Tests
Java Persistence: Failed
As the rejection of the JSR 243 shows, one of the most promising persistence strategies for Java, JDO, is doomed to fail. One could say that on a later time errors could be corrected. But nowadays we cannot affort waiting too long with most important aspects of an architecture.
I have been concerned about Java persistence in general since I began coping with persistency in Java. For me, there is no really satisfying mechanism available fitting to the (sub-)enterprise level. The current release of SAP NetWeaver for Java shows that JDO is still in its early days, at least the support for it in enterprise architectures. Look at SAP legacy architecture (ABAP): There you have it all at no cost, no need to do these ugly things necessary with JDO, EJB persistence, Hibernate and all the other stuff. I don't have anything against Hibernate, particularly. it's a good piece of open-source software. But in my eyes it's not enough compared to what can be possible.
Look at the approach Yi Zhou developed. Admittedly, I have not read it all, it may be ingenious, I don't know. But if, then at what cost (complexity)?
BTW: Tell me which *integrated* Java architecture to use for commercial projects containing persistence, business logic, view mapping, GUI etc. with a different name than J2EE? I personally don't like J2EE in any way. It's much too complicated, slow, non-agile, somewhat cryptic, redundant in the way you need to code, complicated (Design Patterns... oh my god, most people are happy when knowing about AbstractFactory or Observer...).
What I was wondered all the time how a single person such as Doug Lea made it to the elitary club of JSR reviewers. Good job, Doug. Although it is astonishing that he did not make a comment on his vote and is in sole company with Apple...
I have been concerned about Java persistence in general since I began coping with persistency in Java. For me, there is no really satisfying mechanism available fitting to the (sub-)enterprise level. The current release of SAP NetWeaver for Java shows that JDO is still in its early days, at least the support for it in enterprise architectures. Look at SAP legacy architecture (ABAP): There you have it all at no cost, no need to do these ugly things necessary with JDO, EJB persistence, Hibernate and all the other stuff. I don't have anything against Hibernate, particularly. it's a good piece of open-source software. But in my eyes it's not enough compared to what can be possible.
Look at the approach Yi Zhou developed. Admittedly, I have not read it all, it may be ingenious, I don't know. But if, then at what cost (complexity)?
BTW: Tell me which *integrated* Java architecture to use for commercial projects containing persistence, business logic, view mapping, GUI etc. with a different name than J2EE? I personally don't like J2EE in any way. It's much too complicated, slow, non-agile, somewhat cryptic, redundant in the way you need to code, complicated (Design Patterns... oh my god, most people are happy when knowing about AbstractFactory or Observer...).
What I was wondered all the time how a single person such as Doug Lea made it to the elitary club of JSR reviewers. Good job, Doug. Although it is astonishing that he did not make a comment on his vote and is in sole company with Apple...
Agile Software Development
Agile Principles
After reading the book Lean Software Development by the Poppendiecks (can be found in your popular bookstore) I felt somewhat enlighted. The authors shared their experiences and ideas about good project management and processing. Some of them I liked very much. Here is my personal impression of Agility and XP. It should be clear that XP and Agility are not a magic bullet - the same goes for SOA, see my weblog entry Service-Oriented Architecture: What's up with it?.
Decide As Late As Possible
On one hand a good thing, on the other impractical. Try to tell your customer he should trust you. I know of customers that examine the time reported to be accounted up to the minute. What would be the chances to persuade such a customer to decide as late as possible just because you tell him it is a good thing and it is an agile principle?
Deliver As Fast As Possible
Catchwords are: schedule, cost of delay and tradeoff decisions. From the economical point of view the message behind those terms is apparent. For the software developer it means discomfort in most cases if a deadline will be overdrawn.
See the Whole
Seeing the whole means engaging a bird's eye view. The whole from the point of view of the employees should be to have as much fun as possible during their work. For that personal habits should be followed. Superstition is another element mentioned in the book from the Poppendiecks. Superstition forces us sometimes to do things in a way that could not be followed easily with logic. More than that, the worker wants to see his beliefs reflected during his activity.
Seeing the whole for the company means relationships to other customers and partners. Here, contracts play an important role. Free yourself from the faith fixed-price contracts and paid-per-hour-contracts will be the only possible solutions. As we all know (if not drop a comment) a fixed-price contract is a dangerous mechanism when talking about the nowaday complex world of software technology. On the other hand some customers would nearly feel abnormal if not making a fixed-price contract. Perhaps they want to feel unhappy?
A shared benefits contract would be a good solution. The problem here is measurement. But this is the same problem as how to measure the productivity of a worker.
Resources
For your convenience, browse the following to find out more about Agility:
22.1.05
Service-Oriented Architecure (SOA): Bubbles?
Service-Oriented Architecture (SOA) has been in the media since several months. Which also has to do with the marketing of big companies, commercial blogs or people jumping on using the buzzword (SOA is one, IMO). One can find articles about SOA in all the popular magazines around here in Germany. In other countries this should be true as well. Just take some popular magazines (I could easily name some German ones).
Mind-making thru the media
I have always wondered when any of these magazines resp. papers printed articles written or co-authored by employees of big companies. When reading the articles you soon get the idea that SOA is not a very big deal but more or less a hype. Although SOA is not bad at all, its congeniality is overemphazised too much, IMO. What is so great about SOA? I think, it is a logical consequence nearly every semi-talented softwerker or architect would have "invented" sooner or later for himself in general or regarding the building blocks of the paradigma. Of course the personal inventions would have been not as complex as it seems right know. And I am not talking about whole architectures already offered by big companies. It's mainly about common design principles.
What is a service?
SOA is about fine-granular software entities being autonomous and being able to be integrated within a platform to form an application, sort of. Services, as the acronym SOA indicates, are an integral part of the concept. BTW: Can you tell me what a service is? Ten people, ten different opinions.
But SOA is not a concept as all-embracing as the concept of Object-Orientation itself is. SOA officially is not well defined (everyone understands something different when hearing or reading it or knows just vague about it). SOA is just following common design principles being known for long time (long time in the context of the software market can be some few years, but principles as Loose Coupling, Open-Closed or Interface Segregation are known for longer. Packages could be abstracted to services, then, with packages being more well-defined than services. This was cut short!).
Is SOA embracing anything?
When telling companies "By doing a service-oriented architecture, your applications will be able to integrate within a bigger context, they will be extendable more easily etc." the truth is not matched fully.
Firstly, legacy applications cannot be converted to whatever we want. And if the target architecture is something seen as highly sophisticated (as SOA officially is) the task is getting near impossible.
SOA is daily business, isn't it?
Again, by publishing lead articles in popular channels (mostly semi-academical or just plain) the impression has been risen that SOA is the eighth wonder of the world. This definitively is not the fact. SOA is not bad, it is a good thing. But SOA is not something to emphasize to an extend currently recognizeable. My strong believe drawn from experience with other hypes is that SOA exactly is lining up with other bubbles. Perhaps it takes longer for the community to identify it as a hype than with other hypes. But the root for this lies in the strength of the marketer and the "official complexity" of the subject.
What about performance?
OK, computer get faster every few months. It is also known that software complexity grows faster than hardware evolution can compensate, generally. The excellent article Fuzzy Boundaries: Objects, Components, and Web Services shows that web services could also be seen as high potential performance killers.
I'm not the only one
An interesting blog entry displaying a year 2005 prediction list, contains a statement about SOA:
The term SOA will have been beaten to death and the software industry will invent or recycle some equally vague term to replace it.
The term has zero differentiation value at this point and marketing teams across the globe are looking to coin a replacement that will give them something more interesting to say about their middleware than "we move messages around really well."[...]
Promotion
It is legitimate for any company promoting its products (and slightly smoothing reality sometimes) as it is legitimate for an article writer to sharpen reality from his point of view, trying to align with it as good as possible. As you noticed I have not said much about what SOA really is. From my point of view this is not important in this case as numerous articles (published internally and externally) exist about this matter.
Take care of yourself to not overestimate the importance of some buzzwords thrown in. Being honest, these buzzwords mostly affect non-technicians or people being semi-technically oriented because the truth is very complex and not easy to uncover without comprehensive coping. As most of us remember with the crash of the New Market, the danger of overestimation is greatest when another area of expertise is involved than the own main field of interest. Because we do have to believe someone!
NB
This blog entry first appeared at SDN, this is a modified version.
Mind-making thru the media
I have always wondered when any of these magazines resp. papers printed articles written or co-authored by employees of big companies. When reading the articles you soon get the idea that SOA is not a very big deal but more or less a hype. Although SOA is not bad at all, its congeniality is overemphazised too much, IMO. What is so great about SOA? I think, it is a logical consequence nearly every semi-talented softwerker or architect would have "invented" sooner or later for himself in general or regarding the building blocks of the paradigma. Of course the personal inventions would have been not as complex as it seems right know. And I am not talking about whole architectures already offered by big companies. It's mainly about common design principles.
What is a service?
SOA is about fine-granular software entities being autonomous and being able to be integrated within a platform to form an application, sort of. Services, as the acronym SOA indicates, are an integral part of the concept. BTW: Can you tell me what a service is? Ten people, ten different opinions.
But SOA is not a concept as all-embracing as the concept of Object-Orientation itself is. SOA officially is not well defined (everyone understands something different when hearing or reading it or knows just vague about it). SOA is just following common design principles being known for long time (long time in the context of the software market can be some few years, but principles as Loose Coupling, Open-Closed or Interface Segregation are known for longer. Packages could be abstracted to services, then, with packages being more well-defined than services. This was cut short!).
Is SOA embracing anything?
When telling companies "By doing a service-oriented architecture, your applications will be able to integrate within a bigger context, they will be extendable more easily etc." the truth is not matched fully.
Firstly, legacy applications cannot be converted to whatever we want. And if the target architecture is something seen as highly sophisticated (as SOA officially is) the task is getting near impossible.
SOA is daily business, isn't it?
Again, by publishing lead articles in popular channels (mostly semi-academical or just plain) the impression has been risen that SOA is the eighth wonder of the world. This definitively is not the fact. SOA is not bad, it is a good thing. But SOA is not something to emphasize to an extend currently recognizeable. My strong believe drawn from experience with other hypes is that SOA exactly is lining up with other bubbles. Perhaps it takes longer for the community to identify it as a hype than with other hypes. But the root for this lies in the strength of the marketer and the "official complexity" of the subject.
What about performance?
OK, computer get faster every few months. It is also known that software complexity grows faster than hardware evolution can compensate, generally. The excellent article Fuzzy Boundaries: Objects, Components, and Web Services shows that web services could also be seen as high potential performance killers.
I'm not the only one
An interesting blog entry displaying a year 2005 prediction list, contains a statement about SOA:
The term SOA will have been beaten to death and the software industry will invent or recycle some equally vague term to replace it.
The term has zero differentiation value at this point and marketing teams across the globe are looking to coin a replacement that will give them something more interesting to say about their middleware than "we move messages around really well."[...]
Promotion
It is legitimate for any company promoting its products (and slightly smoothing reality sometimes) as it is legitimate for an article writer to sharpen reality from his point of view, trying to align with it as good as possible. As you noticed I have not said much about what SOA really is. From my point of view this is not important in this case as numerous articles (published internally and externally) exist about this matter.
Take care of yourself to not overestimate the importance of some buzzwords thrown in. Being honest, these buzzwords mostly affect non-technicians or people being semi-technically oriented because the truth is very complex and not easy to uncover without comprehensive coping. As most of us remember with the crash of the New Market, the danger of overestimation is greatest when another area of expertise is involved than the own main field of interest. Because we do have to believe someone!
NB
This blog entry first appeared at SDN, this is a modified version.
21.1.05
5 Books for Java Developers
R.J. Lorimer posted his suggestions for 5 books that should be noticed by Java developers.
As I am coping mainly with software architecture and Design Patterns, my list is sort of related with that. Additionally, I read several books on different topics (e.g. Streamlined Object Modelling) which I would not recommend here.
Here is my list as I have quite different suggestions than R.J.:
Test-Driven Development by Example
The classical book from Kent Beck, well written, giving great insights into the concept of TDD: Even if you don't follow the XP paradigm "test first" but do the tests after the coding (I do it after the skeletton has been finished) it helps very much getting a good start.
Design Patterns: Elements of Reusable Software
The hyperclassical book on Design Patterns. IMO, it is not a really great book concerning the usefulness for Java developers as the examples are presented for Smalltask or C++ mostly. Additionally, it is kind of outdated. But if you want to claim knowing about Design Patterns this is a must-read.
The Pragmatic Programmer
Really cool book with a unique content. Check it out!
Design Patterns for Object-Oriented Software Development
Another book covering the topic of Design Patterns. Centered on frameworks and seeing DP's from a quite different perspective than is usual. More a recommendation for people really trying to dig in deeply with the subject.
The Timeless Way of Building
A non computer science book from the architect Christopher Alexander. Well know in academic circles but a tip for anyone who wants to get a new insight on software archtiecture.
You find these books at your favorite bookstore. I don't want to link to any commercial store here.
As I am coping mainly with software architecture and Design Patterns, my list is sort of related with that. Additionally, I read several books on different topics (e.g. Streamlined Object Modelling) which I would not recommend here.
Here is my list as I have quite different suggestions than R.J.:
Test-Driven Development by Example
The classical book from Kent Beck, well written, giving great insights into the concept of TDD: Even if you don't follow the XP paradigm "test first" but do the tests after the coding (I do it after the skeletton has been finished) it helps very much getting a good start.
Design Patterns: Elements of Reusable Software
The hyperclassical book on Design Patterns. IMO, it is not a really great book concerning the usefulness for Java developers as the examples are presented for Smalltask or C++ mostly. Additionally, it is kind of outdated. But if you want to claim knowing about Design Patterns this is a must-read.
The Pragmatic Programmer
Really cool book with a unique content. Check it out!
Design Patterns for Object-Oriented Software Development
Another book covering the topic of Design Patterns. Centered on frameworks and seeing DP's from a quite different perspective than is usual. More a recommendation for people really trying to dig in deeply with the subject.
The Timeless Way of Building
A non computer science book from the architect Christopher Alexander. Well know in academic circles but a tip for anyone who wants to get a new insight on software archtiecture.
You find these books at your favorite bookstore. I don't want to link to any commercial store here.
14.1.05
Open Source Projects: Which license I chose
Recently I had the need considering the license for a Java open source project administered by myself, JGAP. JGAP is a Genetic Algorithms Package that helps solving problems in a Darwinian way.
To Open-Source or not?
Well, the thing about open source software is, that it is available to anyone accepting the license agreement. And that agreement is the point. Some people may not want to make their work public by giving their source code away just because a stupid piece of code used forces one to do that. In contrast, it should not be allowed to go for gold with open source software just according to the weather today. Meaning, some forces are wanted and should not be omittable by any reason.
But after getting that with the LGPL you either have to submit your source code to public or need to make your software reverse-engineerable it should be clear that no commercial product will want to use LGP'd pieces of code.
Dual licensing
Fortunately, sometimes a serious person asked me to use JGAP for his commercial software package. That was motivation enough thinking about licensing models. I came up with dual-licensing offering one license for open source projects and another one for commercially oriented software.
I chose LGPL for the open source side. There are several other fitting licenses for that case, no problem should arise here.
For the commercial usage of JGAP I decided to use the MPL as I was pointed to a Java project doing this as well. Therefor it should work, I thought and informed myself about MPL and it seemed promising to me.
Now JGAP is set up with LGPL as well as MPL. You can chose LGPL without any restrictions. The MPL can onle be chosen after donating a certain amount to the paypal account of the JGAP project. This seems a fair solution to me. What do you think?
To Open-Source or not?
Well, the thing about open source software is, that it is available to anyone accepting the license agreement. And that agreement is the point. Some people may not want to make their work public by giving their source code away just because a stupid piece of code used forces one to do that. In contrast, it should not be allowed to go for gold with open source software just according to the weather today. Meaning, some forces are wanted and should not be omittable by any reason.
But after getting that with the LGPL you either have to submit your source code to public or need to make your software reverse-engineerable it should be clear that no commercial product will want to use LGP'd pieces of code.
Dual licensing
Fortunately, sometimes a serious person asked me to use JGAP for his commercial software package. That was motivation enough thinking about licensing models. I came up with dual-licensing offering one license for open source projects and another one for commercially oriented software.
I chose LGPL for the open source side. There are several other fitting licenses for that case, no problem should arise here.
For the commercial usage of JGAP I decided to use the MPL as I was pointed to a Java project doing this as well. Therefor it should work, I thought and informed myself about MPL and it seemed promising to me.
Now JGAP is set up with LGPL as well as MPL. You can chose LGPL without any restrictions. The MPL can onle be chosen after donating a certain amount to the paypal account of the JGAP project. This seems a fair solution to me. What do you think?
Subscribe to:
Posts (Atom)