I happened to have a talk about the previous post to Raja. The implementation had its own problems and changes.
Firstly : The Service Layer of the app, the part which communicates with the queue, must be separated from the controller. We don't want the controller to have a heavy load. The service layer will not know the part of the application that communicates with it and the controller will not know who its contacts. This ensures that even if the service layer has implementation changes, it will not affect the controller thus making it entirely a different entity. I guess this kind of distinction will only come with age and experience. The Facade Pattern is the base.
Secondly: The application is better off with cache implementations. Mainly because the queues are designed to serve a purpose. Communication between apps. The Cache will also be maintained by a service layer and the access via the controller will either be fetched from the cache or if expired from the database. To have a uniformity between the kind of platforms accessing the application (say Adobe AIR and the browser accessing the Mongrel server), we could have an identifying parameter parameter passed along with the url which tells the controller the type of client and the resultant format of output (say XML/ JSON/RHTML).
I feel I have lifted myself a step now !! Thanks Raja .
Tuesday, March 4, 2008
Monday, March 3, 2008
Comet Ruby On Rails
The stuff that we do in the company is quite cool. It lets me, personally, to go through many technologies and implement many ideas. Concepts in theory is not great unless you start to implement those. A new thing that we are trying to accomplish is the functionality that a Comet Server gives, an HTTP push. This must be implemented in Ruby On Rails. Now the point here is that as HTTP is a connectionless protocol, we cannot pass stuff from the server to the client (unless the client requests). To have this functionality, we must either do a polling technique, where in the client constantly accesses the server for information or a live connection (may be a flash connection). Now another techniques which goes against this HTTP connectionless concept is the one that Comet deals with. A long lasting HTTP connection, either streaming or long.
Juggernaut is a Ruby On Rails plug-in which has this kind of functionality. It uses a flash open socket connection to get this server side push. Now this is great but the main problem that I felt is the firewall problem. Most of the firewalls do allows connections from other ports to go through them. Juggernaut also say that we could connect through the 443 port (http ssl) and that would solve the firewall issue. For a general need this is great.
My requirement was a little specific and I needed more stuff to get this stuff working. That was when I got to see the Active Messaging plug-in that Ruby On Rails had. A plug-in which could take in data from an Event Driven Architecture based product (say Queue / Messaging) and consume results in a Provider/ Subscriber model. The application also needed a lot of database optimization ( it will have to survive a lot of select statements). So an intermediated queue is perfect.
This is what it might look like.
The only problem that I am facing is that by default the Active MQ is supposed to be a first Come First Serve queue. Now this does not serve my purpose as there might be many clients subscribing to the out queue. What I need is durable subscribers and that problem has been addressed in their thread.
This is a great way of accessing data (messages) as it is inherently the publisher/subscriber pattern (which I need) and the interoperability between different application could also be possible (a flex app accessing not HTTP information ?). Load balancing could also be done on queues !!
Juggernaut is a Ruby On Rails plug-in which has this kind of functionality. It uses a flash open socket connection to get this server side push. Now this is great but the main problem that I felt is the firewall problem. Most of the firewalls do allows connections from other ports to go through them. Juggernaut also say that we could connect through the 443 port (http ssl) and that would solve the firewall issue. For a general need this is great.
My requirement was a little specific and I needed more stuff to get this stuff working. That was when I got to see the Active Messaging plug-in that Ruby On Rails had. A plug-in which could take in data from an Event Driven Architecture based product (say Queue / Messaging) and consume results in a Provider/ Subscriber model. The application also needed a lot of database optimization ( it will have to survive a lot of select statements). So an intermediated queue is perfect.
This is what it might look like.
The only problem that I am facing is that by default the Active MQ is supposed to be a first Come First Serve queue. Now this does not serve my purpose as there might be many clients subscribing to the out queue. What I need is durable subscribers and that problem has been addressed in their thread.
This is a great way of accessing data (messages) as it is inherently the publisher/subscriber pattern (which I need) and the interoperability between different application could also be possible (a flex app accessing not HTTP information ?). Load balancing could also be done on queues !!
Wednesday, February 27, 2008
No More Advices
I thought having an open mind is the most important thing a professional needs in this business. But the essence is avoiding questions and answers and caring about nothing at all. Even when you are asked for an opinion, you just avoid it. Don't hurt anyone with what your conversation, even if you have a point. You don't have to prove yourself to anyone other that you. And thats the secret behind every major developer's career. Why impose when you could suggest and then let the other person decide ?
Friday, February 22, 2008
MVC for HTML ?
Today I Stumbled Upon a great piece of lecture given by Jason Seifer from the Rails Envy group about Unobtrusive Javascript. The piece of video was a great insight on how to write apps which are purely MVC. Now the question is how does this have MVC ?
The terminologies according to Wikipedia
The comparison with Model/View/Controller is kind of wayward here. I would have it called Media/View/Controller for the better. The Media being the Cascading Style Sheets which hold the Presentation, the View being the HTML which acts as the Content and the Controller being the Javascripts which acts as the Behavior.
People have widely adopted the CSS style of coding ie. having the presentation separated and put into files that could be included in the HTML file. This accounts for better structure and traceability. If I were to change the font, I know the centralized and only place to change it. I won't want to change all the 'style' attributes of the tags in my HTML files. Of course the developer would have to understand how bad IE sucks when he tries to implement all those CSS hacks (necessary hacks) to make the page look the same in IE. But after the ACID test results (which Firefox WILL pass !!), I suppose developers will have a better time in the future.
Now I have not seen the same effort go into creating the Javascript files. Developers still write native Javascript using the attributes (events) and they end up in replicating code and making the HTML page obtrusive and ugly. Having all the code base in simple 'js' files allows the programmer re usability of code which results in what Jason states as 'Unobtrusive Javascript'. I personally have been using the excellent Prototype Javascript library for all my projects (including Workstreamr) and the results have been great.
A typical situation when the Javascript becomes obtrusive is when you add javascripts to events like click. Say we are content with the code being 'obtrusive'. With Firefox (the best browser in the world) it works fine. No memory leaks, nothing. But with IE this has the famous memory leak problem. If we were to have a site which has say one page and all the content being loaded in an Ajaxy way, then we will have problems with this. This code wont Garbage Collect unless you navigate away from the page (or refresh). Why use this primitive technique when prototype provides elegant event handling functionalities ?
What I would rather do is attach an id with the element ( say a span/div) and then use the event attaching functionality provided by Prototype. This may be implemented in a main js file accordingly (as per your requirements) and the call may happen from inside the page called (say an AJAX call ?). Using the OOP structure of Javascript is also a great add on. As a developer I felt so happy when I tried to use those concepts in my Javacript files. So the main Javascript file may have a Class which defines your application and routines inside the Object created will have the methods used in the application ( like a status update on the side of the app ?).
References :
Rails Envy
MVC
Ruby On Rails
This is the movie. I hope Jason won't mind this knowledge sharing !!
The terminologies according to Wikipedia
- Modal - The domain-specific representation of the information on which the application operates
- View - Renders the model into a form suitable for interaction, typically a user interface element.
- Controller - Processes and responds to events, typically user actions, and may invoke changes on the model.
- Content
- Presentation
- Behavior
The comparison with Model/View/Controller is kind of wayward here. I would have it called Media/View/Controller for the better. The Media being the Cascading Style Sheets which hold the Presentation, the View being the HTML which acts as the Content and the Controller being the Javascripts which acts as the Behavior.
People have widely adopted the CSS style of coding ie. having the presentation separated and put into files that could be included in the HTML file. This accounts for better structure and traceability. If I were to change the font, I know the centralized and only place to change it. I won't want to change all the 'style' attributes of the tags in my HTML files. Of course the developer would have to understand how bad IE sucks when he tries to implement all those CSS hacks (necessary hacks) to make the page look the same in IE. But after the ACID test results (which Firefox WILL pass !!), I suppose developers will have a better time in the future.
Now I have not seen the same effort go into creating the Javascript files. Developers still write native Javascript using the attributes (events) and they end up in replicating code and making the HTML page obtrusive and ugly. Having all the code base in simple 'js' files allows the programmer re usability of code which results in what Jason states as 'Unobtrusive Javascript'. I personally have been using the excellent Prototype Javascript library for all my projects (including Workstreamr) and the results have been great.
A typical situation when the Javascript becomes obtrusive is when you add javascripts to events like click. Say we are content with the code being 'obtrusive'. With Firefox (the best browser in the world) it works fine. No memory leaks, nothing. But with IE this has the famous memory leak problem. If we were to have a site which has say one page and all the content being loaded in an Ajaxy way, then we will have problems with this. This code wont Garbage Collect unless you navigate away from the page (or refresh). Why use this primitive technique when prototype provides elegant event handling functionalities ?
What I would rather do is attach an id with the element ( say a span/div) and then use the event attaching functionality provided by Prototype. This may be implemented in a main js file accordingly (as per your requirements) and the call may happen from inside the page called (say an AJAX call ?). Using the OOP structure of Javascript is also a great add on. As a developer I felt so happy when I tried to use those concepts in my Javacript files. So the main Javascript file may have a Class which defines your application and routines inside the Object created will have the methods used in the application ( like a status update on the side of the app ?).
References :
Rails Envy
MVC
Ruby On Rails
This is the movie. I hope Jason won't mind this knowledge sharing !!
Subscribe to:
Posts (Atom)