<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Geir Hedemark</title><link>http://disqus.com/people/4734adbb0d1ef923fe9db7050caa80ef/</link><description></description><language>en</language><lastBuildDate>Thu, 15 May 2008 05:03:23 -0000</lastBuildDate><item><title>Re: Four bold claims about SOA</title><link>http://thinkinginsideabiggerbox.disqus.com/four_bold_claims_about_soa/#comment-1798941</link><description>Good post, Johannes, and thanks for the kind words.&lt;br&gt;&lt;br&gt;I have a slightly more positive view on SOA than you do, especially when it comes to ESBs, and if you have chosen to stay clear of the "SOA is WS-*" crowd.&lt;br&gt;&lt;br&gt;Some tasks out there are by nature sequential and/or asynchronous. You can take a big hammer and force these things into a synchronous, object-oriented way of developing, but the mismatch between what you are solving and the tools you are using to create a solution will cause pain. I think that pain may very often be larger than using an ESB. In these cases, I think an ESB is a very good option.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Geir Hedemark</dc:creator><pubDate>Sat, 03 May 2008 02:44:27 -0000</pubDate></item><item><title>Re: Four bold claims about SOA</title><link>http://thinkinginsideabiggerbox.disqus.com/four_bold_claims_about_soa/#comment-1798926</link><description>I mean ESBs, but explained myself very badly.&lt;br&gt;&lt;br&gt;For me, SOA is a quite amorphous term. What I tried to say was that I like the idea of being able to use an ESB for tasks that are asynchronous in nature - stuff like EDIFACT-like messages flowing through your system.&lt;br&gt;&lt;br&gt;I have seen people try to use servlets for handling message-based problems. I don't think servlets are very well suited to publish-consume style tasks. Have a look at JSR 32 if you are wondering what I am on about - this is the servlet API applied to asynchronous messaging.&lt;br&gt;&lt;br&gt;I have also been subjected to opinions that ended up as "we only need ESBs" in my head. I may be to blame here. though. ESBs are not a very good environment to implement request-response style applications - the technology tends to get in the way. We have servlets to do that kind of stuff.&lt;br&gt;&lt;br&gt;There is also a possible mismatch between a rich domain model - where the subclasses has behaviour - and a message-based paradigm, where the intelligence sits in transformers along the path of the messages. I keep feeling that the messages are anemic domain objects getting passed around between transaction scripts, but I am also confident I need to move carefully here, lest I start a holy war. You can move to a rich domain model within the services/transformers themselves, but the technologies I have been using seem to get in the way of doing this - I tend to spend most of my time copying object contents if I force the information into a domain model.There may be something I don't see, though.&lt;br&gt;&lt;br&gt;I really, really want some way of bolting behaviour to the side of a data carrier without having to write boilerplate code. Qi4j or annotations would work, but nobody seems to know these technologies out there yet, so I tend to try not to use them in projects.&lt;br&gt;&lt;br&gt;Hope this helps.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Geir Hedemark</dc:creator><pubDate>Mon, 05 May 2008 09:16:00 -0000</pubDate></item><item><title>Re: Enjoyable development</title><link>http://thinkinginsideabiggerbox.disqus.com/enjoyable_development/#comment-1798976</link><description>I don't know if you have heard of this already, but it follows up on your thoughts on the time it should take to run tests.&lt;br&gt;&lt;br&gt;There is something called flow psychology ( &lt;a href="http://en.wikipedia.org/wiki/Flow_%28psychology" rel="nofollow"&gt;http://en.wikipedia.org/wiki/Flow_(psychology&lt;/a&gt;) ) which describes the conditions that need to be fulfilled if you are to experience "flow" (Which at least for me is a precondition for not being caught my my mail reader). I learnt a lot from that as a project manager.&lt;br&gt;&lt;br&gt;On to a question I have:&lt;br&gt;&lt;br&gt;What would happen if all your tests took less than a second to run? Would you structure your tests differently?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Geir Hedemark</dc:creator><pubDate>Wed, 14 May 2008 03:17:08 -0000</pubDate></item><item><title>Re: Enjoyable development</title><link>http://thinkinginsideabiggerbox.disqus.com/enjoyable_development/#comment-1798981</link><description>I was unclear, once again. Let me clarify.&lt;br&gt;&lt;br&gt;If all of your tests - system tests, unit tests, integration tests, the works, all completed in less than a second - would you structure your test suite differently? Would you still keep your unit tests around? Would you hang on to your CI server?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Geir Hedemark</dc:creator><pubDate>Thu, 15 May 2008 04:09:50 -0000</pubDate></item><item><title>Re: Enjoyable development</title><link>http://thinkinginsideabiggerbox.disqus.com/enjoyable_development/#comment-1798980</link><description>I agree when it comes to performance tests. Those are, by design, meant to take longer.&lt;br&gt;&lt;br&gt;My idea when it comes to functional testing doesn't really lend itself to fitnesse. I want to also veryify that all interfaces to the system do what they should. I can't really see that happening with fitnesse the way I want it to.&lt;br&gt;&lt;br&gt;The good news is that we are almost there. I have created functional test suites which ran a full regression test for a module in less than a minute or so. The drawback was the setup time, which also was on the order of a minute. This minute was caused by spring/hibernate.&lt;br&gt;&lt;br&gt;Good point about the CI server. What if eclipse (or whatever) continually ran your tests, using the second processor everyone seems to have but not use these days, just as your code gets compiled "continually" behind the scenes?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Geir Hedemark</dc:creator><pubDate>Thu, 15 May 2008 05:03:23 -0000</pubDate></item></channel></rss>