Month: April 2010

My first take on Roo framework

sajid2045 Uncategorized 1 Comment

I recently started playing with Spring Roo Framework. I had two main objective.

  • See if its a suitable replacement for “Appfuse” when I start a new project
  • Learn best practices for building spring application from the spring guys

At first I was ‘WOW’ ed by the dynamic code generation and when I saw the app running, but as soon as I “perform eclipse” and imported the code in my workspace, I was disheartened. It is a great effort from the spring team but I am not gonna like it.

Why you may ask? I have couple of reasons, but the most important one is , Spring tried to inject their cutting edge features, aspect-j notations into the generated source. I am not against aspects but when I have more “Aspect-J” codes than my regular codes, I become worried. Worried about how I am going to maintain it, is there good enough IDE for it, are the regular java developers who will be working on the codes going to like/learn the new AspectJ concepts? Again, I am against overuse of annotation. I am ok with Hibernate annotations or validation annotations or transactional annotations, but its too much for me when I write annotations on the controller and map my http requests against it.

I am a big fan of spring , not because it gives me magical transaction management or supercool Controller annotations but because it lets me dependency inject my POJO beans into one another. This is an awesome tool for any designer. But with the latest Roo effort from Spring, I am worried about the future of spring framework. It seems like they are focusing on Rapid Application Development too much.

Anyone who has worked on a product for a decent amount of time will soon realize that the initial development time of the code is only 30-40% of the total lifecycle of the code (or even less). You have to update the code, add twisted domain logic which is never predictable by any annotation driven framework, perform bug fix on the code and the list goes on. By adding all these “Magic” into the code, you are going to leave the new developer (who will eventually take over the code from you) in the wonderland.

I liked the Spring Roo’s shell though. And the JPA POJO generation is also cool..but thats about it. Why don’t the spring guys make a better PetClinic application instead of overdoing annotations?

My version of erlang ‘Ring’ problem

sajid2045 erlang 1 Comment

I have been reading ‘Erlang Programming‘ , like a good student, I decided to solve the ring exercise:

Here is the problem in my words:

Create a linked list of N Ring where each Ring is an erlang process. When you pass a message to the head Ring , it should propagate the message to the  next Ring and that propagates to the next ring and so on. I added additional clause  — “Each ring should report its successful message delivery to the previous ring and the previous ring should print successful message delivery from its child rings.

Here is the code:

-module(ring).
-compile(export_all).


createRing(N) ->
    Self = self(),
    Head = spawn(fun() -> ring(N, Self) end),   
    Head.

ring(N, PreviousRing) when N > 0 ->
    Self = self(),
    io:format('~w #ring created PID: [~w] ListenerPid: [~w] ~n',[N, Self, PreviousRing]),
    NextRing = spawn(fun() ->
			     ring(N-1 , Self) end),
    loop(N ,NextRing, PreviousRing);

ring(N, PreviousRing) ->
    io:format('last ring reached! ~w ~n',[N]),
    NullRing = spawn(fun() -> 
			     receive
				 Any ->
				     io:format('dummy ring received ~w ~n', Any)
			     end
		     end),
    loop(N, NullRing, PreviousRing).



loop(N, NextRing, PreviousRing) ->
    receive
	{send_message, Message} ->
	    io:format('ring # ~w with pid: #~w received ~w ~n',[N, self(), Message]),
	    NextRing ! {send_message, Message},
	    PreviousRing ! {ok, self()},
	    loop(N, NextRing, PreviousRing);
	{ok, NextRing} ->
	    io:format('~w with pid# ~w successfully sent message ~n',[N-1, NextRing]),
	    loop(N, NextRing, PreviousRing);
	{quit} ->
	    io:format('quiting ring: ~w with Pid: ~w ~n',[N, self()])
    end.


sendMessage(Head, M) when M > 0 ->
    Head ! {send_message, M},
    sendMessage(Head, M - 1);
sendMessage(Head, M) ->
    io:format('sending last message ~n'),
    Head ! {send_message, M}.

I have had my share of multi-threaded programming in Java, thanks to the telephony applications I’v worked on. Just imagine the pain you would have to go through to implement this in Java / C++ !