Having a hard time getting any useful results from various searches on this concept -- probably because it's a. Wrong and/or b. obscure. Essentially, though, I'd like to write an application which works as either a normal web app or with a command-line interface. I've done this in the ancient past for sysadmin-y stuff using Perl, but that had none of the joy that using Ruby/Rails brings.
I am comfortable enough with Rails itself, and also use standalone Ruby for all manner of CLI stuff. What I'm looking for is best practices, if they exist, for extending a Rails application to have CLI functionality.
Perhaps the answer is as simple as using script/runner and doing my own "VC" while using my Rails models... This is what I was planning on doing, but I thought I'd step back and sanity-check that approach first. I'm having a hard time imagining how I'd utilize any of the Rails controller stuff, given that it's so tightly married to HTTP requests, but I'm often surprised by what clever(er) folks come up with.
Thanks for any useful responses.
I think it all depends on whether you want to reuse your controller logic. If you do then you can go down the route of writing a gem/Rake task/standalone Ruby script that makes HTTP requests to the application and receives the responses as JSON/XML/plain text or whatever. Something like HTTParty is ideal for this.
The second alternative is as you describe: drive your Rails models directly from your own script and present the results.
Another approach is that the web interface shells out to the CLI to do anything. Everything worth doing is in the CLI and the web just calls the CLI for all of its needs.
Shelling is a little bit expensive. If it turns out to hurt performance, use popen to load the CLI just once per web session. Then you can feed it commands (write to its stdin via the popen pipe) and get the results (read from its stdout via the popen pipe) without the CLI having to load for each command. If the CLI is of the "I take some arguments, do something, and exit" sort, then add a new mode to it "--stay-resident" or some-such, that switches it to the behavior that the web interface needs.
Related
I am trying to figure out whether I can build a web application completely on Ruby stack.
I am looking for following architecture:
Frontend <--- Websockets with Pub/Sub ---> Backend
On top of that, I really like Rails approach with "convention over configuration". As result, I am looking for some "opinionated" framework which will handle this scenario.
I know that it's easier to achieve with Javascript stack. As example using Sails.js.
However, it's experiment. So, I am not looking for the most efficient solution.
Has anybody build anything like that? What would be a reasonable set of libraries/frameworks to build something like it?
Since you said it's an experiment, I would recommend you to try out Volt. It uses Opal, which transcribes Ruby to JS and has reactive synchronization which Meteor.js is famous for. Also there are a lot of Railisms and you will find yourself in familiar waters very quickly.
Both technologies are not quite there yet, but there is a lot of hype around them and they will for sure play a big role in Ruby's near future.
As #ndn mentioned, Volt is interesting... But, it seems to me that the part I would adopt would be the Opal core for a front end.
Volt is too opinionated for me.
I would like to add my own pet project to the table, Plezi, which can be both an independent framework and can also run together within a Rails app by using the Iodine server.
I feel that Plezi has a much better balance between 'convention over configuration' and code-freedom. It manages the backend by automatically mapping websocket broadcasts/unicasts to their respective controller and method (broadcast :method, arg1, arg2...) and automatically maps Redis channels to controllers (or global multicasting) for easy scaling.
At the same time, Plezi does nothing for the front end and assume nothing regarding the front end. This is by design, both for better security (doesn't auto-trust incoming network data) and to allow for for the variety of possible clients such as native apps (iOS, android), browsers, scripts etc'... This would be where Opal can come in (or RubyMotion).
This is somewhat hard for me to explain properly, sorry in advance if the question is unclear! I am fairly new to both Ruby and the Rails framework but I'm working on a Rails application in which I want to be able to run a self-made program with GUI.
The question is whether or not it is possible to just "have" the program running like it otherwise would in a page in the Rails application, and if so, how?
Yes, usually you can (if the app can be run in multiple instances). But whatever GUI stuff it does on the server won't be of much use to your webclients, it'll just needlessly strain your resources a little bit (or a lot--depending to what graphical operations it does). For web apps, you're better off using non-gui programs or better yet, libraries that you can use from inside ruby without needing to spawn separate processes.
Launching an app incurs a little bit of overhead, which however multiplies by the number of web clients you have.
Up to now I've always used PHP with or without a framework but a month ago I decided to start something new: Ruby and Rails, I found them quite easy and similar to PHP and some PHP frameworks in how they works but using a simpler syntax and many other advantages.
Some days ago I started reading about Node.js, Node.js vs Rails, "why node.js is better"...
I'm a bit confused but my objective is to learn something modern that will not become obsolete in a few months so:
What are the main differences between Rails/Ruby and Node.js and a framework based on it like Express.js (except that one is written in JS and the other in Ruby)?
What are the main advantages/disadvantages of using Node.js and framework based on it instead of a Ruby based solution like Rails?
Thanks!
There aren't enough differences between Node.js and Rails for it to practically matter.
A lot of what Node.js can do can be pulled off in Rails with things like EventMachine and Pusher. So unless you are really familiar with Rails' limitations, and know you'll be pushing the boundaries, you'd be hard pressed to make something a seasoned Rails developer couldn't do.
Having built apps in Node and Express I can say that they alone aren't enough to make a sexy application. They can seem just as old and stale if you don't have an outstanding frontend UI to facilitate the backend possibilities. Instead of comparing backend servers, I think the real future of doing amazing things is in front-end JavaScript frameworks like Backbone.js that use Express/Rails/Node.js on the backend.
I have chosen to go in the direction of Backbone.js with Rails as my backend API server. Because it's so easy to rapidly create a very nice RESTful backend server in Rails. Rails also makes working with CoffeeScript and precompiling/organizing Backbone code a breeze. There are already decent Backbone.js gems out there for Rails.
The Rails core is also able to acknowledge and embrace the fact that frontend JS MVCs are logically a good next step, and they have been working to strengthen the bond between the two. For those same reasons they have also worked to make Rails an even better API server so that it can work with frontend JS easier. Node.js and Express aren't putting as much effort to coordinate with frontend JavaScript MVCs as the Rails community is.
Being good with a JavaScript frontend MVC and Rails as a backend makes you also great for both worlds in terms of getting a job. You will easily be able to hop onto a Node.js project and add value to that team with your superior frontend experience, and you can also roll with the punches on a Ruby on Rails team and add value to them as well.
As official Node.js website explains it:
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
On the other hand Ruby on Rails official website says:
Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
Given this I guess that it is more appropriate to compare Ruby and Node.js, but even this is not quite right given that Ruby is programming language and Node.js is NOT. You could probably compare JavaScript with Ruby but I guess that is not what you meant to ask with this question :)
So, for me, key point in understanding what Node.js truly tries to accomplish is well described on Node.js about page. Key Node.js idea (for me) is described in this sentences:
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
What this should enable you, is that you should be able to easily write highly concurrent programs without even thinking about concurrency using JavaScript syntax and callback functions as basic concurrent runnable units.
Your fear that either Rails or Node.js will be gone in a week is unfounded. Rails has a large community and will be around for a very long time even though currently (early 2012) it's getting a bit of hate thrown its way. Node.js is just getting started and has so much attention I don't think it will have any problems getting to the Rails level some day.
That said I've been evaluating Node.js and Rails as options for a project and the reasons I choose Node.js over Rails are:
"The Rails Way" - In my (admittedly limited) experience with Rails it really seems like you either do it the Rails way or you are going to be in for a world of pain. A big part of the Rails way is to use the ActiveRecord model. The advantage of this is that there are a lot of gems that work with your code happily because they know you'll be using ActiveRecord. The disadvantage is you are mixing your data access & model. I am not a fan of this idea so the Rails way for me still seems a bit.. off.
JavaScript is a key part of client side web development and the idea of using it on the client and server is interesting. I'm not super strong at JavaScript and I can't imagine a better way to get better then to have to use it everywhere.
My project has real time communication needs which while I'm sure can be done in Rails there seems to be quite a bit of positive mention on Nodes ability to handle this with socket.io being the front runner option.
At the end of the day no matter which you choose you will have a great time & learn a ton of new stuff that will change how you write code. If you're not on a big time crunch I'd recommend building a small project management tool in both and see which you prefer.
Either way.. Good Luck!
2 things - performance & productivity.
Performance (more details here)
(source: jslang.info)
Productivity (how fast you can build that app)
Ruby on Rails is specialized and highly productive tool for creating so called Web 1.0 and Web 2.0 applications (99% of internet sites are such apps). In my subjective judgement and experience in this area Rails about 2-4 times more productive than node.js or express.js.
For Web 3.0 apps (realtime things, client-side MVC, etc.) this isn't true, RoR doesn't keep its advantage there.
So choice depends on use case and priorities.
I know a lot more about Node.js than I do about Ruby. That being said, Ruby is much more widely adopted. It is currently a very hot skill to have in the work place. Some may argue with me on this but I think that Node.js is still "under development" and will be for a little bit longer. It has a lot of promise but just hasn't been adopted by many companies and projects yet.
I am writing an application where the webapp will be rails and it will allow a user to input rules/ruby-logic and save them to the database. Later on, Java will come along and grab these rules (if/else/elseif) and will execute them via jruby engine. I am wondering of the negatives and possible side-effects of this? And having two languages here?
I want to do rails front-end because the available plugins, and speed of development of webapps. For example, groovy doesnt have as many plugins and i believe that it's much slower in development.
Am I missing anything, or possible logic that may be hurtful in the future if I choose this solution?
In addition I think since ruby is dynamic it will be easier for the user to input rules via a 'ruby' syntax instead of another third-party library like bean shell.
I feel like most complex applications end up needing several languages eventually, usually interfacing through the DB as you're planning. I'm not sure what constraint leads to you Java on backend rather than ruby (guessing legacy or performance), but if that's a requirement then your plan sounds reasonable.
As far as negatives/side-effects, Jruby seems to lag a bit behind the latest ruby, but that's not generally a big deal as long as you match versions for the UI & backend. I can't think of anything that would be harmful in this off the top of my head, but the devil is always in the details ;-)
I'm wondering if it's possible to distribute a RoR app for production use without source code? I've seen this post on SO, but my situation is a little different. This would be an app administered by people with some clue, so I'm cool with still requiring an Apache/Mongrel/MySQL setup on the customer end. All I really want is for the source to be protected. Encoding seems a popular way to go for distributing PHP apps (eg: Helpspot).
I've found these potential solutions:
Zenobfuscate - not all types of Ruby code is supported however, so that counts that out
Ruby Encoder - may be the best option, as their PHP encoder looks alright (I haven't tried it however) but it's not available yet. I've used IONcube for PHP before and it worked well, but it doesn't seem that IONcube is interested yet.
Slingshot - it was mentioned in the other SO post, but it solves a different problem to mine and the source is still visible.
RubyScript2Exe - from the doco, it's not production ready, so that counts that out.
I've heard that potentially using JRuby and distributing bytecode might be a way to achieve this, but I've never used JRuby so I'm not sure what's involved.
Can anyone offer any ideas and/or known examples? Ideally I'd love to have some kind of automated build scenario as well.
Your best option right now is to use JRuby. A little bit of background: My company (BitRock) works with many proprietary and commercial open source vendors. We help them package their server software, which is typically based on PHP, Java or Ruby together with a web server or application server (Apache, Tomcat), the language runtime and a database (typically Postgres, MySQL) into a self-contained, easy to use installer. We have a large number of PHP-based customers (including HelpSpot, which you mention) but also several Rails-based ones. In the case of the RoR customers the norm is to use JRuby together with Tomcat or Glassfish although in some cases we also bundle a native Ruby interpreter to run specific scripts that rely on libraries not yet ported to JRuby (usually not core to the application). JRuby has matured quickly and in many cases it actually runs their code faster than regular Ruby. You will need to also consider that although porting your code to JRuby is fairly straightforward, you will need to invest some time on that. You may want to check JRuby Stack which is a free installer of everything you need to get started. Good luck!
If you release the source, obfuscated or otherwise, your app will be pirated. See, for example, Mint. It depends on what you're building, but you may find that you're better off releasing the app as a hybrid of sorts: A hosted app with a well-defined API, and a component that runs on the customer's server. As long as the true value of your product lives on the server side, you don't need to obfuscate your code, and you can just release the source code unmodified. Additionally, this may also give you the opportunity to reach clients running, say, PHP rather than Ruby. See, for example, Google Analytics, HopToad, Scout, etc, etc.
You can, but it wouldn't do anything to prevent somebody from reverse-engineering or modifying it. I remember there was an article about similar attempts to obfusticate Perl and how they could be effectively bypassed by a debugger and 5 minutes of effort.
If you can't wait for the delivery of RubyEncoder, then I think ZenObfuscate is the most promising. Though it may require some modifications to your source code, they do say this on their site:
ZenObfuscate costs $2500 for a site license or is individually negotiable for other licensing schemes. Yes, that is expensive. That was on purpose. But don't let that thwart you too much. If your product is really cool and we want to see it succeed, we'll make it work. "Really cool" is not freecell.
Of course, for $2500 (or more), you'd hope to get a few tweaks to the compiler that'd make your codebase fully supported. It might be worth engaging them in the conversation.
You can also take a look at Mingle from ThoughtWorks studios as an example of using JRuby for this.
It's a Ruby on Rails app, they run it using JRuby. They've customized jruby to load encrypted .rb files.
Take a look at JumpBox.
I've had conversations with them on the topic, and they seem to have a solution that will work soon for Rails apps.
I'm wondering if you could just "compile" the ruby code into an executable using something like RubyScript2Exe ?
To be honest I haven't used it but it seems like it could be what you want, even if it just packages up the scripts with the interpreter into a single executable.