Is there something that talks about the seperation of church and tech?
Even if there was, we are in a time of ignoring those types of things anyway ;)
I had to laugh when I saw that Codehaus now has a project called Ashcroft:
Regardless of your political beliefs, as an agile and test-infected Java developer, we’d like you to consider the benefits of adhering to strict, some might say “dictatorial”, limits on the way that you write your unit tests.
We should clarify, right up front, that these restrictions apply only to unit tests and not system tests or integration tests, which are also of great importance to the success of any project. However, your unit tests, at least one for each class in your codebase, should be clean, decoupled from one another, and run ultra-fast. We think you should be able to run thousands of unit tests and get your green bar in a few seconds. Achieving that kind of performance takes major discipline on the part of the developer, and Ashcroft helps you learn that discipline by failing tests which stray from best practices.
Sad but true. There has been a lot of talk on unit tests in the last couple of days too:
Martin Fowler: JunitNewInstance
Matt Raible: One-time setUp() with TestSetup
Cedric Beust: TestSetup and evil static methods
I went to see Erik Hatcher talk about Tapestry at the local JUG last night.
It was a good talk, as Erik does a good job and explaining what is good and bad at a developers level (no foofy high level marketing-speak :)
If you have used Tapestry, it is painful to look at JavaServer Faces applications. I had a really interesting conversation with Erik about how a framework is needed ON TOP of JSF, to give you a nice way to work.
How will we get this framework?
- Tapestry Server Faces: In theory, since JSF has a lot of extension points, a Tapestry layer could be placed on top of the JSF event handling model. It would look like Tapestry. Feel like Tapestry, but would be running in JSF (I don’t know what Tapestry would gain from doing all of this work though)
- A Faces Impl: Something like MyFaces can come a long and write a layer on top of the JSF crud. They are already doing a good job on making some things easier… and this would be taking it to the next level
- Struts: Some would argue that Struts as it exists is @deprecated (as Erik puts it). It could evolve to become glue on top of the base JSF framework
- JSF itself: They could make the spec and the RI decent. Shocking I know.
- Some New Thing: Of course, some bright spark can come along and out-do everyone :)
I wonder if this approach could work. Could we have a usable layer on top of JSF? Would JSF tools be able to work with this world too? Or will we always be stuck in a lowest common denominator?
As every vendor comes out, they have their own set of widgets, so you end up working on “Oracle JSF” versus “JSF” anyway. I know, in theory you could use Oracle components on some other server…. but in reality: it is about the tools, and sometimes that doesn’t work that great.
In this vein, it was good to see the JSF Component Metadata Proposal from Oracle.
I really hope that there will be a JSF world where my HTML isn’t hidden away under ugly taglibs. This is the web. We work with HTML. Let my designers see it!
Cedric Beust has moved from BEA to Google.
Cedric is another top notch developer that Google has grabbed, so I can’t wait to see what comes out from all of these guys soon.
Congratulations to Ced, and have a great time googlin’
Adrian Colyer is talking about writing robust pointcut expressions.
This seems to be something that SEEMS simple at first, but actually requires some thought.
One of the problems is that you can easily get away with an expression that “works” in the sense that for your little test, at this moment in time, it does what you were thinking.
This ability can lead to hacking :)
It is like mucking with Regex when you first get started. You often have a couple of cases, and you muck around with the regex line noise until it works for those 2 cases. However, in the future, it breaks on another 5 cases.
Does TDD and process help? Yes and No. It can help, but it all comes down to how lazy you are being, and how well you are thinking. If you have good tests to begin with it can definitely help. “Oops, I changed this pointcut and now this test isn’t working”. Future-proofing isn’t easy, but it shows that it IS OK to think a little about your application, instead of whipping out a solution that passes a test in front of your eyes.
Spring goes professional with SpringFramework.com.
A few people have leaked this info already, but, there is now a company backing up The Spring Framework.
Rod Johnson, Juergen Hoeller, Bruce Tate, Colin Sampaleanu, Keith Donald, and many others are behind the new endeavour which will offer training, consulting and support for Spring.
It is great that these core developers can try to take things to the next level for Spring.
I saw a post from James Strachan with Protique in his .signature
It looks like he is starting a group that will get behind the Active* open source projects that he is part of:
Good luck mate.
I was talking to a friend who is in different field. He had a long conversation with his coworkers about standardization in their line of work.
Although it can definitely be a good thing, he was discussing how it also tends to hamper a lot of efforts. It fits in with the notion of Best Practices. When someone signs off on these they are suddenly the holy grail (at a lot of places).
While it is great to mine experiences, we have to remember that best practices are really:
Best Practices So Far, And Please Remember the Context and the various Forces
This is a constant battle that we all face. We want to capture good things that we do and share that knowledge, but we don’t want to pigeon hole solutions so we don’t have the creativity to come up with a solution that is BETTER.
Oh those crazy Perl guys. They are still working away on Perl 6, and books are already coming out.
Perl 6 and Parrot has a sample chapter which delves into the innards of the Parrot Assembly, and the slightly higher up in the stack Parrot intermediate representation (PIR).
If you are bored of the high level stuff, have some fun reading about this low level stuff instead :)
It appears that Sun has asked that the J2SE, J2ME, and J2EE apis be taken out of JDocs.com.
This is why Sun has almost no grass roots support (apart from through the likes of people like Simon Phipps and Tim Bray ;).
They are always so into the analysis of what people are doing, and never think about the damn developer. JDocs.com is something for developers. It is about community, and coming together to help out fellow Java guys. Why can’t Sun just see this and help out? Hell. They should have done this themselves!!!!
Microsoft would be FUNDING JDocs.com right now, not telling them to take out “their” content. Man, they can make people mad.
So, now we have JSR 175, and we can create all of these annotations. But this is of little use without the semantic understanding that comes with noting down what @Foo(Bar=”whee”) actually means.
Who gets to define these annotations? Each expert group could do this, but what about overlaps?
It looks like Rajiv Mordani of Sun wants to nip this in the bud and has created JSR 250: Common Annotations for the Java Platform which aim to:
This JSR well develop annotations for common semantic concepts in the J2SE and J2EE platforms that apply across a variety of individual technologies. With the addition of JSR 175 (A Metadata Facility for the JavaTM Programming Language) in the Java platform we envision that various JSRs will use annotations to enable a declarative style of programming. It would be unfortunate if these JSRs each independently defined their own annotations for common concepts. It would be especially valuable to have consistency within the J2EE 5.0 component JSRs, but it will also be valuable to allowconsistency between J2EE and J2SE. It is the intention of this JSR to define a small set of common annotations that will be available for use within other JSRs. It is hoped that this will help to avoid unnecessary redundancy or duplication between annotations defined in different JSRs. The exact set of annotations will be developed in consultation with the various specifications leads who are currently planning to use annotations within their JSRs.
It will be interesting to know what they are actually thinking here.