Monday, October 14, 2002

RESTful SOAP SOAP 1.2 webmethod feature. Glen Daniels: Enable SOAP 1.2 webmethod feature. Use it like this: Call call = new Call("http://localhost/~glen/soap.xml"); call.setSOAPVersion(SOAPConstants.SOAP12_CONSTANTS); call.setScopedProperty("soap12.webMethod", "GET"); call.invoke(); SOAPEnvelope env = call.getResponseMessage().getSOAPEnvelope(); RESTful SOAP.  +1. [Sam Ruby] Groovy stuff. So maybe in Jelly we could have a SOAP GET tag like   <soap:get url="http://localhost/~glen/soap.xml"/> to allow SOAP based GETs appear similar to doing straight HTTP. 4:24:30 PM    comment []

Jelly vs Rickard: 1-1 Jelly vs Rickard: 1-1. Hah! I figured it out! This doesn't work: <j:if test="true==true"> but this does: <j:if test="${true==true}"> Now I just have to figure out why I have to wrap the expression into an expression... At least it works. [Random thoughts] I'd just like to appologise up front for the lack of good documentation for Jelly; we'll hopefully get this sorted out real soon. Briefly Jelly works by default like JSTL and Ant whereby expressions are wrapped in ${}. Once inside the ${} you can do any Jexl expression, which are pretty similar to the Velocity expression language and a superset of the expression language in JSP. ${bean.property} ${bean.property.anotherPropery} ${bean.getProperty()} ${bean.someMethod(anotherbean.property, 'someString')} etc. Reading the JSTL documentation on the JSP expression language might help until Jelly's documentation is up to scratch. 2:55:41 PM    comment []

The Red-Hat Green-Hat Game TM (nothing to do with Linux) The Red-Hat Green-Hat Game[per thou] (nothing to do with Linux) I think the modern equivalent of 40,000 page specifications is lots of test cases that demonstrate what the software should do; document requirements through test code. There's an interesting part in the article where the software team is divided into two teams coders who write the code testers who try and break the code And there's a healthy competition between the two. If the test cases are written in software this could amount to one team of people writing test cases to try break the code and another team trying to write bullet proof code to get past the test cases. I think both teams could learn alot from each other. In particular the testers should really be developers who know how to develop unit and integration testing software. Far too often in the software world testing teams are viewed as people who 'push buttons' rather than people who develop test cases to automatically test software. I wonder if it'd help if software teams took turns being in both camps? Say 2 weeks a month they spend purely writing test cases to try break a part of the system, the next 2 weeks they spend writing code on another part of the system to try get past the test cases put in place by the other team. This could lead to some healhy competition. [James Strachan's Radio Weblog] This IS a really effective way of writing development systems which I frequently put in place in teams on a much smaller level using pair-programming. However I use it for writing finer grained unit-tests rather than acceptance tests. RULES: Get two developers in front of the same machine and give one of them a red hat to wear and another a green hat. Mr Red's role is to write a small unit-test that fails. In doing so, he clearly expresses the proposed interface and intention of the new code. As soon as he's happy with his failing test, he slides the keyboard over to Mrs Green. Mrs Green's intention is to do just enough work to make the test pass at which point the keyboard is passed back over to Mr Red. Repeat cycle. This red/green cycle typically takes anywhere between one and ten minutes before they keyboard is passed back to Mr Red. Every so often (a few times a day) the developers switch hats. The competition is fierce. Mr Red defines the best possible API as possible and the most evil tests. Mrs Green solves the problem set by Mr Red in the most elegant way she can. Benefits: If one developer has a better understanding of what needs to be done or is more familiar with the system than the other, they can express this easily in tests. The other then has a concrete specification to work to and can explore/experiment until they achieve the goal. This is particularly effective for bringing new members of a team up to speed on a system very quickly or bridging a skills gap. Both developers are at maximum concentration all the time. It makes it hard for one developer to go off on a tangent whilst the other one stops paying attention, because they need to tackle the problem as a team to achieve the goal. This filters out lone-ranger coders - and the slackers! Competition is fierce but friendly between the two. The harder they compete, the better the result. The roles are very distinct and clear. At the end of the task, both developers walk away with the same knowledge about what the system is supposed to do and how it does it. The tester and implementor are working together - there's no chance of misinterpretation. Testing and implementing must happen in very small blocks and immediate feedback must be available. The best way to achieve this is through pair programming. The great thing about this is that it's so easy to get started with. Oh, and you don't actually need hats. [Joe's Jelly] This sounds great Joe. One thought; IMHO open source software is often of a very high standard, often the quality is better than alot of commercial software I've seen. Most of this is due to having an open design and development model (everything happens on public archived email lists) and that code is heavily tested with JUnit and that so many people look at the code that common bugs get fixed quite fast. I wonder if the Red-Green Hat Game could work on open source projects where the team is spread across the internet? I've spent a bit of time doing kind-of pair programming via IRC which can be fun. 10:34:54 AM    comment []

JCP - Just Call us Politicians JCP - Just Call us Politicians. Rickard pointed me to Cameron Purdy's JCache rant. Interesting reading - perhaps the worst thing about the JCP is the apparent inability for anyone to influence the process outside of Sun? PS Cameron is a smart guy, I'm sure his blog will go from strength to strength! [rebelutionary] I totally agree with Cameron on this. JSRs should be developed in the open. Anyone should be able to comment on JSRs, while they are still under development and see the discussions that their comments cause. Right now any comments you send to a JSR from your perspective typically just go into a black hole. I'm on quite a few JSRs, including the JCache JSR (and developed the first non-Oracle JCache implementation at my employer, SpiritSoft). I think its very sad that JSRs don't operate in the public. Sun's reasoning behind this is that typically various companies on the expert group need to give away details of their intellectual property and so only want to do this in private amonst other people who have also signed NDAs. This NDA issue is a real problem in big business, but then maybe this highlights that standards should mostly be created by individuals, in a totally open manner (like most open source projects) rather than being vehicles for big business to gain competitive advantage. I've often wondered if a new standards body could form, following the Apache style guidelines to running open source projects, where standards are created in an open manner using a meritocracy. 7:53:58 AM    comment []