I'm in love….

…and her name is ViEmu.

Recently, because of some Spring.Net work that I am doing ( which I will blog about later ) I finally get to write some .Net code. That means I get to play with ngedit’s latest version of ViEmu. Apprently the folks over there have been VERY busy because the current beta ( 1.4 ) is leaps and bounds ahead of their original version. Now included is:

  • Support for regular expressions
  • Support for regular expressions
  • Compatibilities with ReSharper
  • :Ex commands
  • Support for regular expressions

Seriously, the support for regular expressions is one of the biggest features in any add-on that I can think of. I can write this:

:%s/new Integer(\(\d\));/Int32.Parse(\”\1\”);/

to change every occurance of ‘new Integer(#);’ to ‘Int32.Parse(”#”)’;

Or did you know that VS.NET’s search and replace ignores ()’s? So if I was looking for ObjectReference() to change it to just ObjectReference, nothing would return because of the ()’s?

Solved with ViEmu:

:%s/ObjectReference()/ObjectReference/

Or how about the more complex situation of changing a method call ‘ObjectReference((Object) one); into a property setting? Simple:

:%s/ObjectReference((Object) \(.*\));/ObjectReference = \1;/

God I am in heaven…. AND ViEmu is on sale for only $49.95. It’s a bargin for twice that.

Specifics and languages

My colleague Darren Hobbs responded to my blog entry about Java. He wanted to know why I didn’t give specifics, and then goes on to list a few Java langauge specifics that he dislikes.

To clear things up, I wasn’t railing on Java the language. Those conversations are useless. All languages have quirks and things people love & hate. I could go on and on about .NET and its lack of an a truly interface based ADO.NET layer, or Java’s lack of any sort of eventing construct , but I won’t because those types of things are here to stay.

No, what I was previously referring to was the gigantic amount of complexity involved with J2EE. The several different files required to deploy a EJB, the sheer amount of useless ‘layers’, ‘delegates’, and ‘facades’, the enormous memory requirements, the fact that everyone’s answer to many problems it to ‘add jar X, Y, and Z to your class path, etc….

I like spirit of J2EE & Java, just not the actual working environment & platform implementation.

Now I remember why I like .Net, and why developers need to stop being cute.

I am currently on a project where the entire architecture is J2EE based. I know, I know, I am a .Net developer, so what am I doing on a J2EE project?

Two things:

1) I actually used to work for Java companies doing J2EE development, including BEA. This was ages ago, and we didn’t even have IntelliJ. Blah….

2) I was put on the project because it was a spike of SOA within a much larger project. Since I have extensive ( or at least as extensive as I can have seeing how SOA is about a minute old ) experience with SOA, I was pulled on for architecture help.

Little did I know that I would actually be expected to, gulp, CODE!

So, here I am, on a 5 week project coding in J2EE.

Not to start some sort of Java vs. .Net debate, but I really dislike Java & J2EE. Rather, I really dislike programming in it. It’s just a personal preference. 1 day into the project and I remember why I leaped over to MS for development.

And, it’s got nothing to do with tools, although WebSphere is a BEAST. No, it’s more to do with the environment it self. It’s just too complex and what’s worse, is that Java devs KNOW that its too complex, and they refuse to admit that there are better ways to do things. They resort to ‘platform independence’ this or ‘microsoft sucks’ that. That’s all well and fine, but the bottom line is that J2EE is too damn complex.

People are starting to realize that Java isn’t all that it’s cracked up to be. It’s timing to the market was PERFECT. People were looking for a middle ground between VB & C++, and with the .com boom, a web-friendly environment that wasn’t CGI based.

But now, the honeymoon’s over. People are starting to realize that while they feel good having several layers of indirection and countless patterns for BASIC platform usage ( I am looking at you My. Remote-Service-Facade & Mr. Business-Delegate! I am sorry, but when patterns become so ubiquitous as to be used by default when using a platform, something’s missing ), for 90% of applications out there, J2EE is an OVERKILL.

This is all why I love .NET and why I really love Ruby on Rails. Now, easy there, I am not going to jump off into full blown zealotry mode here. I love .NET for their 80/20 rule. For about 80% of the things you need to do, the BCL is fine. For the other 20%, there is enough extensibility that you can do what you want.

Now, as for RoR, the reason I like it is that one of my favorite idioms is represented within the damn framework itself: convention. For a long time, teams have instilled official conventions to their development. Things like ‘name private variable this’ or ‘put all resource here’. There are HUGE value adds to any team because they associate a common context to otherwise complex code and artifacts. Software development is difficult enough without having to decipher individual programmers’ styles and quirks, especially if they are on your own team.

It’s strange to me when I see teams refuse to do something like this. They always have strange answers as to why they don’t follow this std, or that std. Most of the time it boils down to the programmer wanting to be ‘cute’ and show just how smart they are. Instead of doing it one normal, perhaps even vanilla way, they love to whip out their API doc and find some ‘hack’ that reduces the LOC from 10 to 8. Eww….

Now, within RoR, the framework is built on the idea of ‘coding by convention’ into the framework. Things like ‘All controllers go HERE’ and ‘all domain object go HERE’, etc…. Of course, if you want to say ‘screw it’ to the conventions, you are more than welcome to work outside of them. That’s the reason people are falling in love with RoR: simplicity. Developers are starting to realize a lot of the software that they write is fairly boring. Simple CRUD apps. Many times, the app revolves around the DB, and pulling & pushing things to & from it. It’s very nice to work within a platform that directly supports this.

Now that I have rambled on, I want to say one more thing. Not only has RoR baked in the idea of ‘coding by convention’ into the framework, but it’s also a DSL.Most of the syntax revolves around objects & their relationship, and how those relationships map to the DB. This syntax is built as an extension to the Ruby language it self, which is amazing. To think that you can extend a language with specific syntax & idioms that are related to your particular environment…sounds a wee bit like a DSL to me. Think about being able to do this vertically and not just horizontally.

I know, I know, we want to flex our brains at how we can solve problems, but isn’t it nice when we make problem solving easier and we can really flex our brains at the important stuff? I am sure we will be hearing more from DSL’s, RoR, and the revolt against Java.

Exciting times are coming…

Bringing it back to the old school.

An interesting email came across the SOA yahoo group today.

I was recently involved in a workshop looking at the relationship between “service oriented architecture” (SOA) and “component based architecture” (CBA) as enterprise architecture approaches.
 
We took, as an example, a hospital and tried developing both SOA and CBA views. This is roughly what emerged:
 
1. SOA View
——————–
In the SOA view the hospital was viewed as a set of services, which could potentially be provided by different suppliers. Example services were: Hospitality, Catering, Pathology, Theatre, Specialist. (Note that we took a “Business” view of services rather than an “IT” view, along the lines suggested by Pat Helland of Microsoft). We derived a IT architecture from this, by aligning the data and functionality to the services. This led to an architecture in which the data/functionality for a given patient was distributed to different services: “Hospitality” owning information about patient accommodation and nursing routine; “Catering” about dietary requirements; “Specialist” owning medical notes; etc.
 
2. CBA View
——————–
The CBA view (loosely based on the approach recommended in the book “UML Components” by Daniels and Cheeseman) drove the architecture from the core business entities and built services around them. In this approach, basic patient data and functionality was not distributed but owned by a single “Patient” component.
 
This example suggests that SOA and CBA lead to different results when applied to enterprise IT architectures. I would be interested in any views on the following questions:
 
Is this a valid/useful conclusion?
If so, can SOA be regarded as “superior” to CBA as an architectural approach?
 
Any views/comments welcome.
 
Rgds
Ashley

My response was as follows:

I think the central idea lies in your clarification after you list your example services.  You state that you took a “Business” view of services, as opposed to a “IT” view.  Though you don’t explicitly state it, I think that a “IT” view was taken when discussing the CBA route.  One could easily take a “Business” view of components, thuse arriving at the same architecture, albeit at a much lower level of grainularity.

In the end, I think that the superior architectural approach will end up being a mixture of both, SOA at a high, corse grained level that wraps a CBA, at a more fine grained level.

This is, of course, nothing that new.  A similar architectural approach was taken in back in the CORBA days, though the the abstraction was not pushed as high as it is today.  It was thought that a coarse CBA could be used to encapsulate a fine grained OOA.

Thoughts?

Everyone is going to have to start thinking a few abstractions up if they are to get any sorts of benefits from SOA, services, etc….

I have two new favorite phrases for today

The first is: “There’s a lot of crunch in this granola”

No doubt this is another form of the “Secret Sauce” & “It’s the sizzle, not the steak” phrases, but it’s amusing nonetheless.

And the second is: “Testicular Fortitude”

This needs no explanation.

And if Ben is reading, you bet these go right up there with “syntactical sugar” and “copious granularity”.

Now playing: GrayskulWrathball (feat. The Ghost)