I am writing an application that uses FireWatir to do a bunch of different actions. The problem is that I want to trigger these actions from many separate ruby files.
So for example, one ruby script will launch a new FireFox browser instance, than a totally different script will have that instance goto a specific website, and another will log into gmail.
I want all of these scripts to affect the same browser window. That way I can have one script take me to a specific website, and wait for another script to be triggered to do something else.
Please tell me that this is possible.
Chad,
I think that is possible. I am not sure that it's necessary or efficient, but I know that it's possible. The key is to make sure that you attach to the right browser instance. If you will only have one, that could be much simpler.
If you identify the problem that you are trying to solve with these multiple scripts then maybe one or more of the experienced framework designers can point you to existing solutions to the problem. There are some pretty awesome solutions that exist already. At the end of the day, we face the same issues.
Good luck,
Dave
I ended up getting around this issue by using socketing. Had a ruby script acting as the server that was waiting for requests from another group of ruby scripts that could be triggered whenever.
Related
So, my cohorts and I have been doing some development with Phonegap +jQueryMobile for an application we've been planning to rollout. We switched off doing this natively for iOS and Android, since its mostly html anyway, and phone gap seemed like a great way to do this without having to write a whole bunch of platform specific code (although we're more or less newbs when it comes to this type of development.)
Previously, all the html, javascript, etc, was going to be housed in the app itself. For the most part, this seemed to work for us, and we advanced our design/testing/etc accordingly. However, things have changed in our approach. For each of our customers (once they go through a log-in/authentication) has a 'starting' html file (essentially 'their' index.html) that is specific to said customer. This was different from before where everyone had the same files.
Now I've played around with storing certain scripts on the web server to try and off-set opening the html running on the server, but it's not really that useful when trying to integrate some of the functionality like the camera or some of the other plugins we're trying to use. It's essentially a form-based application, so this is the ONLY file that will change from customer to customer. Also, this will not be something that changes frequently. For the most part, it will be setup for a customer ONCE AND ONLY ONCE, and it truly is unlikely to change.
Is there a way to more or less pull down this html file from a web server to replace the one that is stored internally in the app, and then load that version? Would doing something like that (if its even possible) violate Apple's or Google's App guidelines? Or is what I'm describing not even possible in the framework?
The only other thing I can think of would be to change the stored 'index.html' file to not load any of the form itself, but rather make ajax (or equivalent) calls to do so, but I've been told by our developer working the web design side of things that it would be a huge pain.
Any insight/knowledge would be appreciated.
If you really need to do this (I don't quite understand why), I think your best bet is to go the AJAX route. At least Apple does not look kindly on applications that update themselves without going through the App Store submission process.
You can do the same index.html for all and a script config.js that be the responsible of load/unload resources/html of each user at app start.
All you need to do then is save that config JSON values in localstorage and go.
I have a RoR application that given a set of N URLs to parse, will perform N shell calls for a given PhantomJS (actually is a CasperJS) script.
So,
Right now I have something like this:
urls_to_parse = ['first.html', 'second.html',...]
urls_to_parse.each do |url|
parse_results = \`casperjs parse_urls.js '#{url}'\`
end
I have never done this before. Launching shell scripts from a RoR/Ruby application, so I am wondering if this is a good approach and what alternative may I have. So, why I use PhantomJS in combination with RoR?
I basically have an API (RoR app) that keeps receiving urls that need to be parsed. They need to be parsed in a headless browser manner. The page actually needs to be rendered (that's why I don't use Nokogiri or any other HTML parser).
I am concerned about putting this up to production performance wise, and before going forward I would like to know if I am doing this correctly, or I can do it in a better way.
It's possible I thought about doing the same thing, but even with a headless browser I would be really concerned about the speed and bandwidth your server is going to need to have. I use capser in conjuction with Python and it works very well for me. I read stdout spit back from firing the casper scripts, but I don't parse and scrape on the fly like you're talking about doing. I would imagine it's okay, but ideally you already have a cached database of results when people search. Maybe if it is a very very basic search you'll be okay, but I don't know.
We are planning to make a "large" website for I'd say 5000 up to many more users. We think of putting in lots of real time functionality, where data changes instantly propagate to all connected clients. New frameworks like Meteor and DerbyJS look really promising for this kind of stuff.
Now, I wonder if it is possible to do typical backend stuff like sending (bulk) emails, cleaning up the database, generating pdfs, etc. with those new frameworks. And in a way that is productive and doesn't suck. I also wonder how difficult it is to create complex forms with them. I got used to the convenient Rails view helpers and Ruby gems to handle those kind of things.
Meteor and DerbyJS are both quite new, so I do expect lots of functionality will be added in the near future. However, I also wonder if it might be a good idea to combine those frameworks with a "traditional" Rails app, that serves up certain complex pages which do not need realtime updates. And/or with a Rails or Sinatra app that provides an API to do the heavy backend processing. Those Rails apps could then access the same databases then the Meteor/DerbyJS app. Anyone thinks this is a good idea? Or rather not? Why?
It would be nice if anyone with sufficient experience with those new "single page app realtime" frameworks could comment on this. Where are they heading towards? Will they be able to handle "complete" web apps with authentication and backend processing? Will it be as productive/convenient to program with them as with Rails? Well, I guess no one can know that for sure yet ;-) Well, any thoughts, guesses and ideas are welcome!
For things like sending bulk emails and generating PDFs, Derby let's you simply use normal Node.js modules. npm now has over 10,000 packages, so there are packages for most things you might want to do on the server. Derby doesn't control your server, and it works on top of any normal Express server. You should probably stick with Node.js code as much as possible and not use Rails along with Derby. That is not to say that you can't send messages to a separate Rails app, but since you already have to have a Node.js app running to host Derby, you might as well use it for stuff like this.
To communicate with such server-side code, you can use Derby's model events. We are still exploring how this kind of code works and we don't have a lot of examples, but it is something that we will have a clear story around. We are building an app ourselves that communicates with an email server, so we should have some real experience with this pretty soon.
You can also just use a normal AJAX request or send a message over Socket.IO manually if you don't want to use the Derby model to do this kind of communication. You are free to make your own server-side only routes with Express along with your Derby app routes. We think it is nice to have this kind of flexibility in case there are any use cases that we didn't properly anticipate with the framework.
As far as creating forms goes, Derby has a very powerful templating system, and I am working on making it a lot better still. We are working on a new UI components feature that will make it possible to build libraries of self-contained UI widgets that can simply be dropped into a Derby app while still playing nicely with automatic view-model bindings and data syncing. Once this feature is completed, I think form component libraries will be written rather quickly.
We do expect to include all of the features needed for a normal app, much like Rails does. It won't look like Rails or work like Rails, but it will be similarly feature complete eventually.
For backend tasks (such as sending emails, cleaning up the database, generating pdfs) it's better to use resque or sidekiq
Now, I wonder if it is possible to do typical backend stuff like
sending (bulk) emails, cleaning up the database, generating pdfs, etc.
with those new frameworks. And in a way that is productive and doesn't
suck. I also wonder how difficult it is to create complex forms with
them. I got used to the convenient Rails view helpers and Ruby gems to
handle those kind of things.
Also, my question is not only about background jobs, but also about stuff one can might do during a request, like generating a pdf, or simply rendering complex views with rails helpers or code from gems. –
You're mixing metaphors here - a single page app is just a site where the content is loaded without doing a full page reload, be that a front end in pure js or you could use normal html and pjax.
The kind of things you are describing would be done in a background task regardless of the fornt-end framework you used. But +1 for sidekiq if you're using ruby.
As for notifying all the other users of things that have changed, you can look into using http://pusher.com or http://pubnub.com if you don't want to maintain a websocket server.
I have a site where users are uploading files with a form and it posts and its great, but one customer insists on using FTP instead. I have determined three options for handling this, and I was wondering if anyone has any insight on which is best (or if there is a different overflow I should be asking this on), or if there is a fourth better option.
Solution 1: Learn Linux. I could probably write a cron job that looks in the directory to which they're uploading every 5 minutes and then post the files it finds into my site.
Solution 2: Create a timer driven service in grails that looks in the directory every 5 minutes. This is what I'm going to start trying.
Solution 3: This would be hard, but I'm sure it would be possible to have grails pretend to be a FTP server allowing the ftp dump to be like a post. I have no idea where to start this solution, so unless there is a plugin this isn't happening.
You can use the Grails Quartz plug-in to schedule a task, if you want to pursue option two in your list.
I would go for option 2 and use the Quartz plugin as suggested (rather than cron). Handling files in Groovy are simple and you have lots of examples such as this from mrhaki.
If you think the processing of files will have more complex requirements you could try out something like Apache Camel with this example from the same mrhaki. Though I believe Spring has its own framework that may be a better fit, you'll have to investigate that yourself if you go down that road.
Grails is a web framework so options 2 and 3 are less than ideal. If having the file that is ftped immediately available in your application option 1 is the quickest and simplest solution of the 3 I think.
Another option is to find an open source FTP server (there are several) and modify it to import the document into your system directly. This will allow your client to use the protocol they prefer (FTP) and still get the file into your application in real time.
Still another option is to provide an FTP like client that will use your grails application as the server. Whether this is suitable or not depends on why the client insists on using FTP which you should determine up front to make sure your solution works for them.
The rails books and web pages I've been following have all stuck to very simple projects for the sake of providing complete examples. I'm moving away from the small project app and into a realm of non-browser clients and need to decide where to put code that is shared by all involved parties.
The non-browser client is a script that runs on any machine which can connect to the database. Browser clients write commands into the database, which the script examines and decides what to do. Upon completion, the script then writes its result back. The script is not started by the RoR server, but has access to its directory structure.
Where would be the best place for shared code to live, and how would the RoR loader handle it? The code in question doesn't really belong in a model, otherwise I'd drop it in there and be done with it.
I'd put the shared code in the Rails project's /lib directory and consider making it a custom Rake task.
It really depends on how much you use this shared code. If you use it everywhere, then throw it in the lib folder (as has already been stated here). If you are only using it in a few places, you might want to consider making a plugin out of it and loading it only in the places that use it. It's nice to only load what you need (one of the reasons I'm loving merb).