Comments for Opinions on IT and various issues http://microintellia.com/blog Wed, 10 Mar 2010 14:29:54 +0000 http://wordpress.org/?v=2.6 Comment on SOA - it’s more about service management by Various takes on SOA | Opinions on IT and various issues http://microintellia.com/blog/2007/02/24/soa-its-more-about-service-management/#comment-22468 Various takes on SOA | Opinions on IT and various issues Mon, 01 Dec 2008 13:23:22 +0000 http://microintellia.com/blog/?p=76#comment-22468 [...] in your work-force. And this brings me to the MWD article which echoes some thoughts that I wrote a while back when I was saying that interactions between IT services will be driven by the [...] [...] in your work-force. And this brings me to the MWD article which echoes some thoughts that I wrote a while back when I was saying that interactions between IT services will be driven by the [...]

]]> Comment on REST and WS - part 3 by REST and WS - part 5 | Opinions on IT and various issues http://microintellia.com/blog/2007/06/01/rest-and-ws-part-3/#comment-20601 REST and WS - part 5 | Opinions on IT and various issues Thu, 16 Oct 2008 19:31:18 +0000 http://microintellia.com/blog/2007/06/01/rest-and-ws-part-3/#comment-20601 [...] distributed transactions and the need for agreement between multiple parties. As I was saying in a previous post about REST and WS the differences between these 2 camps are more of organizational nature than [...] [...] distributed transactions and the need for agreement between multiple parties. As I was saying in a previous post about REST and WS the differences between these 2 camps are more of organizational nature than [...]

]]> Comment on The Spring Application Platform by Cristian Herling http://microintellia.com/blog/2008/05/18/the-spring-application-platform/#comment-15584 Cristian Herling Thu, 22 May 2008 12:05:01 +0000 http://microintellia.com/blog/2008/05/18/the-spring-application-platform/#comment-15584 Thank you Glyn for taking the time to provide information on the OSGi issue. I'll update the post. Thank you Glyn for taking the time to provide information on the OSGi issue. I’ll update the post.

]]> Comment on The Spring Application Platform by Glyn Normington http://microintellia.com/blog/2008/05/18/the-spring-application-platform/#comment-15583 Glyn Normington Thu, 22 May 2008 11:39:28 +0000 http://microintellia.com/blog/2008/05/18/the-spring-application-platform/#comment-15583 I explained the rational for the new manifest headers here: http://blog.springsource.com/main/2008/05/08/springsource-application-platform-manifest-headers/. SpringSource has been hosting an OSGi Expert Group meeting this last couple of days and I think most of the concerns around the headers are addressed by the fact that the import-library and import-bundle headers are merely syntactic sugar for OSGi standard import-package header. We've got tooling that flags these headers up as non-standard and we're planning to ship a tool which will convert these headers to import-package for anyone who needs to migrate an application from the Platform to another OSGi container. (Oh, and please note that it's the SpringSource, rather than the Spring, Application Platform.) Glyn Normington SpringSource I explained the rational for the new manifest headers here: http://blog.springsource.com/main/2008/05/08/springsource-application-platform-manifest-headers/.

SpringSource has been hosting an OSGi Expert Group meeting this last couple of days and I think most of the concerns around the headers are addressed by the fact that the import-library and import-bundle headers are merely syntactic sugar for OSGi standard import-package header. We’ve got tooling that flags these headers up as non-standard and we’re planning to ship a tool which will convert these headers to import-package for anyone who needs to migrate an application from the Platform to another OSGi container.

(Oh, and please note that it’s the SpringSource, rather than the Spring, Application Platform.)

Glyn Normington
SpringSource

]]> Comment on Determination by Cristian Herling http://microintellia.com/blog/2008/03/05/determination/#comment-14402 Cristian Herling Wed, 12 Mar 2008 02:03:52 +0000 http://microintellia.com/blog/2008/03/05/determination/#comment-14402 It`s crazy what is happening here. 2 days ago we got a foot of snow dropped on us in a few hours. My friend came from Toronto to Montreal and the highway was littered with cars turned upside down. I was on the road and I could not believe how many cars were crashed into the snowbanks waiting to get out. One guy I know had to get out of his car in the middle of the highway to see where the hell is the highway because there was no trace of it left under the snow. I can wait for the summer... It`s crazy what is happening here. 2 days ago we got a foot of snow dropped on us in a few hours. My friend came from Toronto to Montreal and the highway was littered with cars turned upside down. I was on the road and I could not believe how many cars were crashed into the snowbanks waiting to get out.
One guy I know had to get out of his car in the middle of the highway to see where the hell is the highway because there was no trace of it left under the snow.

I can wait for the summer…

]]> Comment on Determination by Tim http://microintellia.com/blog/2008/03/05/determination/#comment-14357 Tim Mon, 10 Mar 2008 18:13:17 +0000 http://microintellia.com/blog/2008/03/05/determination/#comment-14357 Geez. And I was complaining about the rain in New York!! Geez. And I was complaining about the rain in New York!!

]]> Comment on Communication problems in dynamic languages by Cristian Herling http://microintellia.com/blog/2008/01/21/communication-problems-in-dynamic-languages/#comment-13644 Cristian Herling Mon, 11 Feb 2008 14:30:33 +0000 http://microintellia.com/blog/2008/01/21/communication-problems-in-dynamic-languages/#comment-13644 I guess this is a good development, it makes available a new set of capabilities (blocks, closures, etc...) to JEE developers. We will have to see how this unfolds, I think that everything will revolve around adoption rates. Personally I would not commit to Scala until I see some backing for it. I would use it for small projects or small things or I would integrate it here and there in an application, but I would not build a whole application on top of it until it reaches some level of adoption. It may be that Scala, a nice language as far as I can see it, may not live too long, mainly due to various market forces. It would not be the first technological gem to get thrown down the tube.... I guess this is a good development, it makes available a new set of capabilities (blocks, closures, etc…) to JEE developers.
We will have to see how this unfolds, I think that everything will revolve around adoption rates. Personally I would not commit to Scala until I see some backing for it. I would use it for small projects or small things or I would integrate it here and there in an application, but I would not build a whole application on top of it until it reaches some level of adoption. It may be that Scala, a nice language as far as I can see it, may not live too long, mainly due to various market forces.
It would not be the first technological gem to get thrown down the tube….

]]> Comment on Communication problems in dynamic languages by Derek Mahar http://microintellia.com/blog/2008/01/21/communication-problems-in-dynamic-languages/#comment-13603 Derek Mahar Sun, 10 Feb 2008 07:17:40 +0000 http://microintellia.com/blog/2008/01/21/communication-problems-in-dynamic-languages/#comment-13603 The Scala programming language (http://www.scala-lang.org/) is a statically typed language that combines the most appealing features, such as blocks and closures, of dynamically typed languages like Ruby. It is also fully interoperable with the Java environment. Scala demonstrates that a programmer can be equally productive using a statically typed language. The Scala programming language (http://www.scala-lang.org/) is a statically typed language that combines the most appealing features, such as blocks and closures, of dynamically typed languages like Ruby. It is also fully interoperable with the Java environment. Scala demonstrates that a programmer can be equally productive using a statically typed language.

]]> Comment on Testing… by Tim http://microintellia.com/blog/2008/01/22/testing/#comment-13267 Tim Wed, 30 Jan 2008 19:03:49 +0000 http://microintellia.com/blog/2008/01/22/testing/#comment-13267 Hey Cristian, I like the new site look. Very easy to read... And I was about to ask you what you were up to :) Hey Cristian, I like the new site look. Very easy to read… And I was about to ask you what you were up to :)

]]> Comment on XP Testing by Cristian Herling http://microintellia.com/blog/2007/10/11/xp-testing/#comment-11779 Cristian Herling Sat, 01 Dec 2007 15:00:04 +0000 http://microintellia.com/blog/2007/10/11/xp-testing/#comment-11779 "I’ve actually worked in Agile shops that used both Pair Programming and TDD, and the quality of the people and code was the exact opposite of what you describe (hope you don’t mind a differing opinion). " This ie exactly what I was trying to say in my posts about Agile development, that they require very skilled people and that not all of their technique apply outside their shops. TDD will probably work for various people, but it will not work for every team out there, most TDD practitioners don`t seem to realize that. "With regards to TDD, the idea with is not to avoid design, but to enforce the contracts in that design." You enforce the contracts of a design once you have designed and coded a particular component, not before you write a line of code. Testing enforces the contracts of a design regardless of when you do it: before coding (TDD-style) or later (as most other people) When I wrote this post I was pretty angry at the patronizing attitude of people in the Agile camp, they act as though they know everything which, needless to say, it is not the case. Gotta go, babies crying... “I’ve actually worked in Agile shops that used both Pair Programming and TDD, and the quality of the people and code was the exact opposite of what you describe (hope you don’t mind a differing opinion). ”
This ie exactly what I was trying to say in my posts about Agile development, that they require very skilled people and that not all of their technique apply outside their shops.
TDD will probably work for various people, but it will not work for every team out there, most TDD practitioners don`t seem to realize that.

“With regards to TDD, the idea with is not to avoid design, but to enforce the contracts in that design.”
You enforce the contracts of a design once you have designed and coded a particular component, not before you write a line of code. Testing enforces the contracts of a design regardless of when you do it: before coding (TDD-style) or later (as most other people)

When I wrote this post I was pretty angry at the patronizing attitude of people in the Agile camp, they act as though they know everything which, needless to say, it is not the case.

Gotta go, babies crying…

]]> Comment on XP Testing by Tim http://microintellia.com/blog/2007/10/11/xp-testing/#comment-11768 Tim Sat, 01 Dec 2007 02:50:53 +0000 http://microintellia.com/blog/2007/10/11/xp-testing/#comment-11768 Hey Christian, how are you? You realise that your opinions on Pair Programming and TDD go against people like Kent Beck. I've actually worked in Agile shops that used both Pair Programming and TDD, and the quality of the people and code was the exact opposite of what you describe (hope you don't mind a differing opinion). The people I've worked with who used these techniques were by far some of the best developers I've come across. And the systems we assembled had better quality and design than most other places I have seen. With regards to TDD, the idea with is not to avoid design, but to enforce the contracts in that design. And where measurements have been taken, code quality (robustness, defects) from projects that have used paired programming far exceed projects that didn't use it. There's an interesting talk with Kent talking about using agile techniques to improve software health. Kent Beck, Developer Testing http://itc.conversationsnetwork.org/shows/detail301.html Hey Christian, how are you? You realise that your opinions on Pair Programming and TDD go against people like Kent Beck. I’ve actually worked in Agile shops that used both Pair Programming and TDD, and the quality of the people and code was the exact opposite of what you describe (hope you don’t mind a differing opinion). The people I’ve worked with who used these techniques were by far some of the best developers I’ve come across. And the systems we assembled had better quality and design than most other places I have seen. With regards to TDD, the idea with is not to avoid design, but to enforce the contracts in that design. And where measurements have been taken, code quality (robustness, defects) from projects that have used paired programming far exceed projects that didn’t use it.

There’s an interesting talk with Kent talking about using agile techniques to improve software health.

Kent Beck, Developer Testing
http://itc.conversationsnetwork.org/shows/detail301.html

]]> Comment on The assembly line by naisioxerloro http://microintellia.com/blog/2006/09/19/the-assembly-line/#comment-11702 naisioxerloro Wed, 28 Nov 2007 18:33:16 +0000 http://microintellia.com/blog/?p=34#comment-11702 Hi. Good design, who make it? Hi.
Good design, who make it?

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10196 Bill Burke Mon, 22 Oct 2007 16:26:22 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10196 There could be a binding layer in between to decouple things. Like what I showed with web beans. I'm not a Google Guice expert, but you should take a look at that to see how they do things. There could be a binding layer in between to decouple things. Like what I showed with web beans. I’m not a Google Guice expert, but you should take a look at that to see how they do things.

]]> Comment on Annotations used for deployment by Cristian Herling http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10044 Cristian Herling Tue, 16 Oct 2007 21:50:02 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10044 Yeah, the compiler would detect it. However, I still think that embedding framework-specific information in annotations has its drawbacks, please see the Later Edit portion of this post. Yeah, the compiler would detect it.
However, I still think that embedding framework-specific information in annotations has its drawbacks, please see the Later Edit portion of this post.

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10039 Bill Burke Tue, 16 Oct 2007 14:34:25 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10039 Unless you're adding methods, the compiler should be able to detect any underlying class changes. No? Unless you’re adding methods, the compiler should be able to detect any underlying class changes. No?

]]> Comment on Annotations used for deployment by Cristian Herling http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10038 Cristian Herling Tue, 16 Oct 2007 13:27:00 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10038 Yes, the delegate is a pretty neat idea. It may need to be kept up-to-date as the underlying class changes, for example if you add new methods, but it is a solution that does its job most of the time. Yes, the delegate is a pretty neat idea. It may need to be kept up-to-date as the underlying class changes, for example if you add new methods, but it is a solution that does its job most of the time.

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10018 Bill Burke Mon, 15 Oct 2007 21:57:08 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10018 If you are so concerned about decoupling, just write a delegate. its a one click in Intellij, don't know about eclipse. Still faster than XML. If you are so concerned about decoupling, just write a delegate. its a one click in Intellij, don’t know about eclipse. Still faster than XML.

]]> Comment on Annotations used for deployment by Cristian Herling http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10015 Cristian Herling Mon, 15 Oct 2007 21:16:43 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10015 Probably trying to express the same thing in XML was more verbose but it would have de-coupled your code from the framework into which it was inserted (in this case WS-BA). The feeling that I have about the WS standards is that they are trying to layer themselves on top of the components that they are remoting. If this is what is required then the WS standard should be de-coupled from the component itself and annotations are actually coupling the WS to your component. As you mentioned there is an effort in remoting an object without annotations (namely writing all that XML), but my impression is that this effort is both a necessary barrier of entry to remoting (necessary in my opinion because it would force you to remote only your coarse grained components) and a way to de-couple your component from the remoting process itself (the remoting process could take many faces: the same component could be remoted via WS for 'enterprise' use, via REST for access by the PHP crowd, etc...). If you have some time please tell me what you think about this. Thanks for taking the time to read my post. Probably trying to express the same thing in XML was more verbose but it would have de-coupled your code from the framework into which it was inserted (in this case WS-BA).
The feeling that I have about the WS standards is that they are trying to layer themselves on top of the components that they are remoting. If this is what is required then the WS standard should be de-coupled from the component itself and annotations are actually coupling the WS to your component.

As you mentioned there is an effort in remoting an object without annotations (namely writing all that XML), but my impression is that this effort is both a necessary barrier of entry to remoting (necessary in my opinion because it would force you to remote only your coarse grained components) and a way to de-couple your component from the remoting process itself (the remoting process could take many faces: the same component could be remoted via WS for ‘enterprise’ use, via REST for access by the PHP crowd, etc…).

If you have some time please tell me what you think about this. Thanks for taking the time to read my post.

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10012 Bill Burke Mon, 15 Oct 2007 17:10:01 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10012 And finally...thanks for the mental exercise on this, I think you've given me some material for a new blog to explore your concerns. And finally…thanks for the mental exercise on this, I think you’ve given me some material for a new blog to explore your concerns.

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10011 Bill Burke Mon, 15 Oct 2007 17:08:23 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10011 Sorry, one more thing about annotations over XML... Annotated classes/interfaces can be introspected with reflection apis. XML'lized metadata does not have a built-in, common, way of finding and iterating over its bound metadata. Sorry, one more thing about annotations over XML…

Annotated classes/interfaces can be introspected with reflection apis. XML’lized metadata does not have a built-in, common, way of finding and iterating over its bound metadata.

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10009 Bill Burke Mon, 15 Oct 2007 16:56:41 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10009 Just a thought.... One idea that might get you to the same place as annotation inheritance is meta-annotations. Take a look at what is going on in Guice and <a href="http://in.relation.to/Bloggers/GavinsBlog/Tag/Web+Beans+Sneak+Peek" rel="nofollow">Web Beans.</a> Just a thought….

One idea that might get you to the same place as annotation inheritance is meta-annotations. Take a look at what is going on in Guice and Web Beans.

]]> Comment on Annotations used for deployment by Bill Burke http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10008 Bill Burke Mon, 15 Oct 2007 16:39:36 +0000 http://microintellia.com/blog/2007/10/15/annotations-used-for-deployment/#comment-10008 And you'd rather have XML creep instead? No thanks. Annotations are type-safe, require no special IDE plug-ins for auto-completion, and if designed correctly, are autodocumenting (as well as useful in documenting the behavior of your code). I suggest that, as an exercise, you redo the annotated example with an XML-based one. Which one is more verbose. Which one takes longer to write. Which is more productive. "No wonder so many people prefer XML..." Which people? Even pre-annotations and JDK 5, the sheer number of XDoclet users proved that users want their metadata defined in one place. FYI, the BA annotations are JBoss specific. WS-BA is just a web services standard. No Java bindings described. And you’d rather have XML creep instead? No thanks. Annotations are type-safe, require no special IDE plug-ins for auto-completion, and if designed correctly, are autodocumenting (as well as useful in documenting the behavior of your code). I suggest that, as an exercise, you redo the annotated example with an XML-based one. Which one is more verbose. Which one takes longer to write. Which is more productive.

“No wonder so many people prefer XML…”

Which people? Even pre-annotations and JDK 5, the sheer number of XDoclet users proved that users want their metadata defined in one place.

FYI, the BA annotations are JBoss specific. WS-BA is just a web services standard. No Java bindings described.

]]> Comment on Java and dynamic languages by Cristian Herling http://microintellia.com/blog/2007/07/04/java-and-dynamic-languages/#comment-7938 Cristian Herling Thu, 05 Jul 2007 14:54:13 +0000 http://microintellia.com/blog/2007/07/04/java-and-dynamic-languages/#comment-7938 > "It’s another step up in complexity, but the payoff comes when you can make scripts that endlessly test" My opinion is that this step in complexity will be dealt with by not getting too complex about it and that the pieces written in DLs and that these pieces of code will remain close to 'script'-status in a Java application. Who knows, maybe DLs will be used on side-projects tied in some form or manner to a Java application, however the costs of using a DL should be considered. > "Erlang is a functional language, so I’m not sure that the paradigm would fit well into Java" I picked Erlang as a DSL targeting concurrency, I was wondering if it could be plugged into a Java application so that you could leverage its concurrency capabilities if you need to. > “It’s another step up in complexity, but the payoff comes when you can make scripts that endlessly test”
My opinion is that this step in complexity will be dealt with by not getting too complex about it and that the pieces written in DLs and that these pieces of code will remain close to ’script’-status in a Java application. Who knows, maybe DLs will be used on side-projects tied in some form or manner to a Java application, however the costs of using a DL should be considered.

> “Erlang is a functional language, so I’m not sure that the paradigm would fit well into Java”
I picked Erlang as a DSL targeting concurrency, I was wondering if it could be plugged into a Java application so that you could leverage its concurrency capabilities if you need to.

]]> Comment on Java and dynamic languages by Tim http://microintellia.com/blog/2007/07/04/java-and-dynamic-languages/#comment-7932 Tim Thu, 05 Jul 2007 00:30:49 +0000 http://microintellia.com/blog/2007/07/04/java-and-dynamic-languages/#comment-7932 Hey Cristian, interesting post. I've gotten into DSLs in a big way. I've designed my own DSL and it's interpreted, so it can also be considered a DL. Check out the titles "Bookkeeping Release Pre-Alpha" and "Bookkeeping BKeeping and the BKell" at this link: http://frye.blogs.com/thebox/software/index.html I've found DLs (not just my own) to be a very powerful way of programming and automating large chunks of complex code. It's another step up in complexity, but the payoff comes when you can make scripts that endlessly test, configure and run your software in a well-defined and repeatable manner. I mean, the cost of adopting any language has to be weighed against the benefit it brings to your software project. PS Erlang is a functional language, so I'm not sure that the paradigm would fit well into Java. Hey Cristian, interesting post. I’ve gotten into DSLs in a big way. I’ve designed my own DSL and it’s interpreted, so it can also be considered a DL. Check out the titles “Bookkeeping Release Pre-Alpha” and “Bookkeeping BKeeping and the BKell” at this link:
http://frye.blogs.com/thebox/software/index.html

I’ve found DLs (not just my own) to be a very powerful way of programming and automating large chunks of complex code. It’s another step up in complexity, but the payoff comes when you can make scripts that endlessly test, configure and run your software in a well-defined and repeatable manner. I mean, the cost of adopting any language has to be weighed against the benefit it brings to your software project.

PS Erlang is a functional language, so I’m not sure that the paradigm would fit well into Java.

]]> Comment on The demise/change of the template design pattern? by Cristian Herling http://microintellia.com/blog/2007/05/07/the-demise-change-of-the-template-design-pattern/#comment-5634 Cristian Herling Tue, 08 May 2007 16:55:30 +0000 http://microintellia.com/blog/2007/05/07/the-demise-change-of-the-template-design-pattern/#comment-5634 You can have by-pass the super-class limitation in Java by composition (which done via an IoC is pretty easy to do). The template design pattern`s main limitation is that it defines the life-cycle thru inheritance, while there are work-arounds this limitation they are not easy to implement. If you define the lifecycle by defining it in an interface you can easily extend that life-cycle by sub-classing the lifecycle interface, with the original template design pattern you may run into some problems. I didn’t have time to look into extending the life-cycle of the original template design pattern, but I think it is not pretty… You can have by-pass the super-class limitation in Java by composition (which done via an IoC is pretty easy to do). The template design pattern`s main limitation is that it defines the life-cycle thru inheritance, while there are work-arounds this limitation they are not easy to implement.
If you define the lifecycle by defining it in an interface you can easily extend that life-cycle by sub-classing the lifecycle interface, with the original template design pattern you may run into some problems. I didn’t have time to look into extending the life-cycle of the original template design pattern, but I think it is not pretty…

]]> Comment on The demise/change of the template design pattern? by Tim http://microintellia.com/blog/2007/05/07/the-demise-change-of-the-template-design-pattern/#comment-5593 Tim Tue, 08 May 2007 11:42:42 +0000 http://microintellia.com/blog/2007/05/07/the-demise-change-of-the-template-design-pattern/#comment-5593 Hey Cristian, this is an interesting post as there have been efforts in the past to remove the "Interpreter" pattern from the Design Patterns book (I don't know if that succeeded). I'm always slow to get rid of working designs. Even if you move abstract methods to an interface, your implementation is still bound by that contract. But I suppose you just want to inherit from different sources. Part of the problem is the Java typing system. Even if your class has many interfaces (how multiple inheritance is done in Java), there can be only 1 super class from where you can pull behaviour. Try looking at loosely typed languages like Ruby and Javascript. They definitely have the multiple inheritance and dynamic behaviour powers that you crave. Hey Cristian, this is an interesting post as there have been efforts in the past to remove the “Interpreter” pattern from the Design Patterns book (I don’t know if that succeeded). I’m always slow to get rid of working designs. Even if you move abstract methods to an interface, your implementation is still bound by that contract. But I suppose you just want to inherit from different sources. Part of the problem is the Java typing system. Even if your class has many interfaces (how multiple inheritance is done in Java), there can be only 1 super class from where you can pull behaviour. Try looking at loosely typed languages like Ruby and Javascript. They definitely have the multiple inheritance and dynamic behaviour powers that you crave.

]]> Comment on Microsoft on SOA by Cristian Herling http://microintellia.com/blog/2007/04/23/microsoft-on-soa/#comment-3671 Cristian Herling Tue, 01 May 2007 20:11:21 +0000 http://microintellia.com/blog/2007/04/23/microsoft-on-soa/#comment-3671 Yeah, it looks like MS focuses on management rather than on infrastructure (application servers /databases/operating systems implementing sophisticated functionality). MS is pretty much on the low-end of enterprise infrastructure, I guess they are trying to establish themselves in an emerging field in which there is no clear winner and in which they could claim a lead more easily. Strong backing could probably make this strategy bear fruit. Time will tell... Yeah, it looks like MS focuses on management rather than on infrastructure (application servers /databases/operating systems implementing sophisticated functionality). MS is pretty much on the low-end of enterprise infrastructure, I guess they are trying to establish themselves in an emerging field in which there is no clear winner and in which they could claim a lead more easily. Strong backing could probably make this strategy bear fruit.
Time will tell…

]]> Comment on Microsoft on SOA by Neil Ward-Dutton http://microintellia.com/blog/2007/04/23/microsoft-on-soa/#comment-3668 Neil Ward-Dutton Mon, 30 Apr 2007 20:22:47 +0000 http://microintellia.com/blog/2007/04/23/microsoft-on-soa/#comment-3668 Hey, glad you liked the podcast! I agree that MS actually has a really nice story, in particular around how the whole lifecycle of a set of services can be managed (relatively) seamlessly. What's interesting is that MS doesn't really talk very much about this, which is strange because it's quite a strong differentiator in comparison to IBM, BEA, etc etc etc. Hey, glad you liked the podcast! I agree that MS actually has a really nice story, in particular around how the whole lifecycle of a set of services can be managed (relatively) seamlessly. What’s interesting is that MS doesn’t really talk very much about this, which is strange because it’s quite a strong differentiator in comparison to IBM, BEA, etc etc etc.

]]> Comment on The Ubiquitous Language by Cristian Herling http://microintellia.com/blog/2007/04/05/the-ubiquitous-language/#comment-930 Cristian Herling Fri, 13 Apr 2007 17:15:20 +0000 http://microintellia.com/blog/2007/04/05/the-ubiquitous-language/#comment-930 I have the impression that distilling domain knowledge into a DSL may be an extra barrier to development: you will first to learn the domain and then learn the DSL. It is an extra step, I am not sure whether it pays off to take it. Another problem with DSLs is that they are languages, potentially used by a large number of people (just check out how many are using Spring's namespaces extensions which in themselves are DSLs). Changing a language is pretty slow (you need to get feed-back from a large number of people, propagating changes, ensuring back-ward compatibility, etc...), as a result there is the danger that the DSL will end up out of sync with the domain it is supposed to model. I have the feeling that DSLs work pretty well for domains that don't change so often and that are pretty limited in scope. Book-keeping is probably so standardized by now that its potential for change is small and even if the domain itself is pretty big it could be argued that you could encapsulate book-keeping into a DSL. I have the impression that distilling domain knowledge into a DSL may be an extra barrier to development: you will first to learn the domain and then learn the DSL. It is an extra step, I am not sure whether it pays off to take it.
Another problem with DSLs is that they are languages, potentially used by a large number of people (just check out how many are using Spring’s namespaces extensions which in themselves are DSLs). Changing a language is pretty slow (you need to get feed-back from a large number of people, propagating changes, ensuring back-ward compatibility, etc…), as a result there is the danger that the DSL will end up out of sync with the domain it is supposed to model.
I have the feeling that DSLs work pretty well for domains that don’t change so often and that are pretty limited in scope. Book-keeping is probably so standardized by now that its potential for change is small and even if the domain itself is pretty big it could be argued that you could encapsulate book-keeping into a DSL.

]]> Comment on The Ubiquitous Language by Tim http://microintellia.com/blog/2007/04/05/the-ubiquitous-language/#comment-927 Tim Fri, 13 Apr 2007 00:30:12 +0000 http://microintellia.com/blog/2007/04/05/the-ubiquitous-language/#comment-927 A common vocabulary of business terms (the ubiquitous language) may not be useful for development. But what about distilling user's domain knowledge into a Domain Specific Language (DSL)? They force you to fully encapsulate business data and processes into something machine parsable. I've designed and used one, "BKeeping" (http://frye.blogs.com/thebox/2007/04/bookkeeping_bke.html) in a double-entry bookkeeping application. It's worth a look. A common vocabulary of business terms (the ubiquitous language) may not be useful for development. But what about distilling user’s domain knowledge into a Domain Specific Language (DSL)? They force you to fully encapsulate business data and processes into something machine parsable. I’ve designed and used one, “BKeeping” (http://frye.blogs.com/thebox/2007/04/bookkeeping_bke.html) in a double-entry bookkeeping application. It’s worth a look.

]]> Comment on The assembly line by Cristian Herling http://microintellia.com/blog/2006/09/19/the-assembly-line/#comment-171 Cristian Herling Mon, 29 Jan 2007 19:23:45 +0000 http://microintellia.com/blog/?p=34#comment-171 Thanks, I'll try to keep it up. Thanks, I’ll try to keep it up.

]]> Comment on The assembly line by Florian http://microintellia.com/blog/2006/09/19/the-assembly-line/#comment-167 Florian Mon, 29 Jan 2007 05:25:28 +0000 http://microintellia.com/blog/?p=34#comment-167 Hi, I found your blog via google by accident and have to admit that youve a really interesting blog :-) Just saved your feed in my reader, have a nice day :) Hi,
I found your blog via google by accident and have to admit that youve a really interesting blog :-)
Just saved your feed in my reader, have a nice day :)

]]> Comment on Object Linking and Embedding by The thoughts of an IT professional : Some benefits of open APIs and mash-ups http://microintellia.com/blog/2006/08/10/object-linking-and-embedding/#comment-153 The thoughts of an IT professional : Some benefits of open APIs and mash-ups Mon, 15 Jan 2007 00:54:35 +0000 http://microintellia.com/blog/?p=16#comment-153 [...] I was talking to Derek about what would open APIs mean for the big corporations providing them. In particular we were talking about the last paragraph in this Jon Udell post: I don’t think ads are the endgame for Gmail. The real monetizable asset will be the APIs that we’re all going to help them create, and the value-adding services that Google will be able to build on top of them. Well, I don’t thing that the value adding services will add that much value if the come from Google. One value-adding service currently being developed would be a mash-up of GMail, GOffice and GSpreadsheet (or whatever their names are) which would try to port the behavior of MS Office on-line. Quite frankly, I don’t think that they will get really far, apart from associating some document types with some applications. What would be actually cool would be to take this GApps and create very customized applications which would target a particular business process (as I was suggesting here). The value would be in this mash-up, rather than in the free applications which compose it. But this cannot be done by Google, because they don’t scale in diversity (they don’t scale in terms of developer and customer-relations hours to dedicate to customize their own apps) to target this incredibly fragmented market. Google, at best, can provide templates for various business processes across various business lines, templates which would be used by small entrepreneurs (which could pay a fee for using such a template) and customized ferociusly. Google could turn into a huge repository of business processes templates, but I would be surprised if they do it because the revenues this business would generate would pale in comparison to their search engine’s revenues. They would not be even a drop in the bucket. It would make sense for a small-timer to do this, it would pay off. [...] [...] I was talking to Derek about what would open APIs mean for the big corporations providing them. In particular we were talking about the last paragraph in this Jon Udell post: I don’t think ads are the endgame for Gmail. The real monetizable asset will be the APIs that we’re all going to help them create, and the value-adding services that Google will be able to build on top of them. Well, I don’t thing that the value adding services will add that much value if the come from Google. One value-adding service currently being developed would be a mash-up of GMail, GOffice and GSpreadsheet (or whatever their names are) which would try to port the behavior of MS Office on-line. Quite frankly, I don’t think that they will get really far, apart from associating some document types with some applications. What would be actually cool would be to take this GApps and create very customized applications which would target a particular business process (as I was suggesting here). The value would be in this mash-up, rather than in the free applications which compose it. But this cannot be done by Google, because they don’t scale in diversity (they don’t scale in terms of developer and customer-relations hours to dedicate to customize their own apps) to target this incredibly fragmented market. Google, at best, can provide templates for various business processes across various business lines, templates which would be used by small entrepreneurs (which could pay a fee for using such a template) and customized ferociusly. Google could turn into a huge repository of business processes templates, but I would be surprised if they do it because the revenues this business would generate would pale in comparison to their search engine’s revenues. They would not be even a drop in the bucket. It would make sense for a small-timer to do this, it would pay off. [...]

]]> Comment on C programming is not OOP by The thoughts of an IT professional : Supply and demand in a computing environment http://microintellia.com/blog/2006/08/16/c-programming-is-not-oop/#comment-148 The thoughts of an IT professional : Supply and demand in a computing environment Tue, 09 Jan 2007 00:11:28 +0000 http://microintellia.com/blog/?p=12#comment-148 [...] I was talking in a previous post about how the demand for interceptions in an application was not met properly by the supply until AOP came about and created a scalable process that could handle interceptions efficiently. I am thinking that you could generalize this case and state that this mis-match between the demand for a behavior or feature and the supply for that behavior or feature betrays an ineffiency in the computing environment (language + IDEs + frameworks + containers + etc…) that tried to address the issue. In the example above implementing interceptions following strict OOP concepts was certainly possible, but it was unfeasible. In a market environment high demand that cannot be met by supply usually translates into a high price. In the above example the high price would have been the cost of developing and, even more, maintaining, the system in which interceptions were implemented in pure OOP fashion. In the example of OOP done in C the cost would have been the cost of coordinating a team of programmers and the cost of turning a programmer into a human compiler. [...] [...] I was talking in a previous post about how the demand for interceptions in an application was not met properly by the supply until AOP came about and created a scalable process that could handle interceptions efficiently. I am thinking that you could generalize this case and state that this mis-match between the demand for a behavior or feature and the supply for that behavior or feature betrays an ineffiency in the computing environment (language + IDEs + frameworks + containers + etc…) that tried to address the issue. In the example above implementing interceptions following strict OOP concepts was certainly possible, but it was unfeasible. In a market environment high demand that cannot be met by supply usually translates into a high price. In the above example the high price would have been the cost of developing and, even more, maintaining, the system in which interceptions were implemented in pure OOP fashion. In the example of OOP done in C the cost would have been the cost of coordinating a team of programmers and the cost of turning a programmer into a human compiler. [...]

]]> Comment on Interceptors and scalability by The thoughts of an IT professional : Supply and demand in a computing environment http://microintellia.com/blog/2007/01/08/interceptors-and-scalability/#comment-147 The thoughts of an IT professional : Supply and demand in a computing environment Mon, 08 Jan 2007 23:36:38 +0000 http://microintellia.com/blog/?p=59#comment-147 [...] « Interceptors and scalability [...] [...] « Interceptors and scalability [...]

]]> Comment on Spring config as code by Cristian Herling http://microintellia.com/blog/2006/10/08/spring-config-as-code/#comment-4 Cristian Herling Mon, 09 Oct 2006 07:17:11 +0000 http://microintellia.com/blog/?p=35#comment-4 When you are using code (Groovy files) for configuring your application it is a safe bet that configuration is becoming very complex to the point where it cannot be expressed only in "traditional" ways (XML files, property files, etc...). The difference between code and configuration is becoming blurred indeed... When you are using code (Groovy files) for configuring your application it is a safe bet that configuration is becoming very complex to the point where it cannot be expressed only in “traditional” ways (XML files, property files, etc…). The difference between code and configuration is becoming blurred indeed…

]]> Comment on Spring config as code by Ben Hale http://microintellia.com/blog/2006/10/08/spring-config-as-code/#comment-3 Ben Hale Sun, 08 Oct 2006 19:47:45 +0000 http://microintellia.com/blog/?p=35#comment-3 You're right on the money about the fact that Spring is decoupled from XML. In fact for quite a long time, Spring has actually supported using property files for configuration. I think however, that it is very telling that no one uses it. Given the choice, users have overwhelmingly chosen XML. That being said that we definitely heard the complaints about our XML configuration. And thanks to the fact that we're decoupled from XML, plugging in the XSD support and namespaces was trivial. Not only is it easy to plug in other flavors of XML, but there a plans to allow configuration based on Java classes, Groovy files, etc. and they'll all go in with the same ease (knock on wood). You’re right on the money about the fact that Spring is decoupled from XML. In fact for quite a long time, Spring has actually supported using property files for configuration. I think however, that it is very telling that no one uses it. Given the choice, users have overwhelmingly chosen XML. That being said that we definitely heard the complaints about our XML configuration. And thanks to the fact that we’re decoupled from XML, plugging in the XSD support and namespaces was trivial. Not only is it easy to plug in other flavors of XML, but there a plans to allow configuration based on Java classes, Groovy files, etc. and they’ll all go in with the same ease (knock on wood).

]]>