Hi John (and other members) Unlike Yaro, I'm here to learn more about ruote, and its eco-system, so please bear with my newbie questions and scenarios.
I'm a senior Ruby developer for a small Ruby shop in South Africa, thats taking on bigger and bigger projects. Part of my current research is to identify commonalities in our current projects and consolidate them into our own internal gems that can be shared and easily maintained across the projects. Reasons for this should be self-explanatory, so I'm onto two common scenarios we're seeing across the projects. 1) Rails -> Queue Service -> Background Process 2) Background Process -> DB/REST -> Rails Phew, that was hectic. To very briefly sum it up as follows: 1) Rails -> Queue Service -> Background Process This is not unique to us, so hopefully this is useful to someone else too. We have a process where the user takes certain actions in a Rails app that starts to set of a fortunate series of events. We constantly find our self writing "intelligent" queue clients (that sit on top of SQS or a ActiveRecord queue). The main problem we have here is that the queue clients become so intelligent that they cannot be removed from the project as a common library, but they're not part of the project since they only abstract whatever implementation we use. The code is neither here or there. The processes are not business processes per se, but still have to be triggered by certain events and then delegated to backend processes for "running". Our current queue implementations work, but we end up writing several different daemons for processing the work, and the skeleton code of the daemons are almost identical apart from the require's, pidfiles and output/work directories. In the end they call a class that runs our actual code. Rough explanation, sure you get the just of it. If I understand ruote correctly, I can implement a single daemon that runs a specific engine (based on parameters) and spawn the daemon as many times as I need. I can then trigger the workflow from inside Rails and have the engine pick it up. That engine, can if needs be, pass it on to another and so forth, depending on the complexity of the process. 2) Background Process -> DB/REST -> Rails Almost the invert, but not really. Its more well defined background processes that feed Rails (or its datastore) with data. As an example, we're working on several internal projects that mash up external data sources into an easier experience for the user. One live example is www.loadwatch.co.za, that aggregates various government and parastatal website information, as well as news feeds, together into a single site for use for by South Africans. We're working on similar projects that focus on other fields where information is not readily accessible without complicated Google terms. This is kinda a hot topic for us, and we're excited about the prospects in this field. In this scenario I'm almost thinking having multiple crawlers feeding a central engine, which in turn delegates the information off to the specific applications for presentation by users. The central engine would do all the language processing, filtering, stemming, translations,etc, before deciding where to send it to for further mashing and end-user consumption. -- This line left blank intentionally -- So its processes, they're well defined, and work. The code that runs them have gone through so many permutations I don't even want to think about it, and we still haven't reached "process nirvana". I'm hoping a foray into ruote will prove promising for these and other issues we're facing as a young dev team. Given the number of actors (and perceived ease of adding new ones) we should be able to cover all our existing angles (SQS, ActiveRecord, DRb, REST) as well as some neat refactoring. Scaling and distribution should also be a breeze due to the ability to make an "engine housing" that can just be spawned wherever to help take on some of the work. Sidenote, we're using the rufus-scheduler in several of our projects with great success, thanks for the hard work on that baby. Looking forward to an interesting conversation on the topic, and please pardon me if I mess up the terminology for certain things. I'm still digesting most of the lacking documentation/examples on the site :) Chow -- Kenneth Kalmer [EMAIL PROTECTED] [EMAIL PROTECTED] stats http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
