Related
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.
I have a Clojure back-end that I want to put a Rails front-end to. How should I connect them, and how specifically do I do it?
Off the top of my head, there are two ways:
run Jruby on rails, in the same process as the clojure app
run normal Ruby on Rails, and connect it to the clojure backend through a message queue, web hooks, and through a joint DB.
Both seem to have disadvantages. In the former, it seems that running jruby will limit the gems we can reuse and otherwise cost us productivity when library authors have not made something perfectly compatible. In the latter, I imagine we'll miss out on code reuse - possibly having to implement the same thing twice in some cases - and that the more complicated interfaces (web hooks instead of just function calls for example) will cost us.
Finally, in the case of JRuby, it's unclear how to actually connect the two. Both come with management scripts: rake and leiningen, and specific repository layouts. I don't really how to start joining them together. Advise and war stories welcome.
I think if it were me, I'd definitely use message queues to communicate between those services—though JRuby really is a good choice on the front-end as well (I think most gems are fairly compatible at this point, even those with native extensions.) Ultimately, you can use elements of both approaches.
What you're talking about is a fairly typical SOA set up, and that's one of the great things about SOA—you can leverage different languages and platforms where they do best. Trying to use clojure within a jruby-on-rails setup is likely to lead to much pain and misery, and IIRC it'll taint some of the benefits of using clojure in the first place.
Unfortunately I don't have any war stories that precisely match up to what you're trying to do, but I'm in the middle of such an architecture right now and its working out great, using RabbitMQ to let MRI 1.9 talk to backend workers running JRuby. Not sure how you'd consume messages in clojure, but I imagine there's got to be docs on it somewhere, and you'll be able to maintain clean separation. If you were to run your front end on jruby, you can still share code between the jruby process and clojure backend without having to put them in the same process.
I haven't done anything yet with Clojure + JRuby, but I have tried out JRuby + Scala/Java.
Scala/Java side works as the service layer and JRuby on Rails sits on top of it. Both projects are managed separately: Scala/Java project is compiled via Maven into a JAR which is then added as a dependency to the Rails application.
This seems to work quite nicely and I guess Clojure would work even better, because Clojure collections implement the interfaces that JRuby consumes, in Scala I had to tweak the service layer interfaces.
Disclaimer: I haven't done this with Ruby, but have quite a bit of experience mixing Clojure and Java modules in the same application and it works pretty well.
If you can make it work, I'd strongly recommend going the JRuby route for the following reasons:
Less dependencies for deployment - you just need the JVM and your relevant jars/wars
You'll get better performance by using in-process communication than you will with queues etc.
Architecturally it will be simpler and easier to maintain
You'll get access to all the Java library ecosystem from JRuby - depending on your precise needs, this could easily make up for the gems you lose through compatibility issues
You'll be able to use the same classes and common libraries from both environments
As for project layouts, I expect the simplest approach will be to create two different projects, package one as a jar and include it as a library for the other.
I've been playing around with Rails (version 3) for a few months now and I understand the framework fairly well. However, I have yet to develop a large website which offers lots of database access and user interaction.
I'm fairly skeptical of the following:
The Speed and Scalability of Ruby (I've heard that its up to 10 times slower than most other server-side languages).
The extra background processing that Rails as a framework (multiple levels of abstration).
The lack of enterprise-level web apps that run on Rails (the only ones that I can think of Groupon, Github and Hulu).
The complexity of the environment (nginx > mongrel > rails > ruby > website).
The behind-the-scenes SQL operations (I know that these can be optimized, but I'm sure that I'll miss some).
For these reasons, I'm unsure whether to continue using Rails or to switch to something that is built ontop a more performant language .. say Java Spring.
Please advise :)
There are tons of large sites and infrastructures in production that use Rails. This question has also been asked to death over the years of Rails being actively used for all manner of web apps, large and small.
Short version is that it is not the fastest language around but despite that scales fine if you know what you are doing. And you should have enough money to hire people that know what they are doing if you actually have any problems of scale.
Scaling any webapp is hard, use the language/framework you know. Programmer happiness is king.
You can get good performance with Ruby. Easy:
require 'inline'
inline :C do |builder|
builder.c <<-C_CODE
void run() {
// Write your entire application in C here
}
C_CODE
end
run
Problem solved ;)
Not the speed and scaling discussion again?
In webdevelopment the things that are the slowest is the network communication (receiving the request, getting al your data back), the database (getting all your data from the database), and most of the times it is not about the computation time at all.
While it is true that Ruby and Ruby on Rails seem more focused on programmer happiness, I think that every decent web-application built in .NET or Java has as many levels of abstraction.
The complexity of the environment? I think you mean deploying? There are a lot of options, but the most used options are Passenger (very easy deployment on top of an apache or nginx), or Torquebox.
Torquebox for the moment is the fastest, best scaling solution (based on JBoss Application server), and several big names in the Ruby community are calling Jruby the implementation of choise to deploy your applications. While AFAIK the commonest deploy still is using REE (Ruby Enterprise Edition) and Passenger.
Unless you know you are going to have to do serious mathematical, cpu-intensive operations, I think the question you should ask yourself is: which framework/language will give me the quickest result?
If you are very proficient in Java/Spring, that might be the answer for you. But if your only worry is performance in general, I would say: do not hesitate and go for Ruby on Rails. It is a pure joy to develop in. The ruby community is really awesome if you would encounter any issues: support is just a post away.
And to conclude, I want to add a few very big sites using Rails: LinkedIn is using rails (and jruby), and Twitter still is using Rails for their frontend.
is it better to develop ruby on rails in a) windows b) linux or c) mac. why ?
edited :
the reason why i am asking this is that i heard that developing ruby on rails in windows is not as stable/good compared when you used ruby on rails in mac. (not sure though if that is true or not).
plus the fact that David Heinemeier Hansson (creator of Ruby on Rails) seems to be using Mac, so initial impressions seems to be Ruby on Rails applications and Mac goes well together.
I strongly advise you don't develop on Windows. Why? First, there are a lot of things that break on Windows with every upgrade and the majority of gem or plugin creators don't use windows so they don't care about windows and don't run tests on it(there are several big name people who have flat out said that windows is NOT their problem it's yours). You'll find the *nix vs Windows problems will bite you in the ass again and again. Pathnames slashes, minor differences in ssh implementations, console and font problems, rubygems, capistrano, etc...
What will end up happening after a while is that you will always have this voice in the back of your head every time you have to debug something saying "Is this a problem only on Windows?" and that little voice is a cost to you..using up some of your battery every single day.
Macs are more expensive in terms of upfront dollars (which sadly I don't have) and linux platforms are more expensive terms of spending a day or two trying to get your wireless to work but those are upfront one time costs. The nagging insecurity of using Windows for Rails development is an ongoing cost. At least until the community starts rejecting things that are not truly cross platform.
As an example look at cucumber. For some reason a test framework is dependent on a particular console configuration not available in windows. So to use it in Windows you have to change the font in your console and change the code page in your console. Otherwise the letter "a" disappears from all the output. Why? Because it works fine for *nix systems and gives you pretty colours (I think this is a huge flaw and very very poor design choice even if you ignore windows).
You'll also feel like the guy who farted in the elevator every time you bring up a windows issue.
I say all this as some who has to use windows for his development platform at the moment. Hey, what's that smell?
[late edit: Ruby is also about 3 times slower on windows. This will impact your willingness run your tests all the time and hurt your TDD feedback cycle]
Shouldn't matter, whatever you're most comfortable with. I've done all three.
I suppose Windows is a little uncomfortable because of not being unix-based, the CLI is a bit more clunky.
(But if you use a tool like NetBeans, you don't really even need the CLI much)
I recommend against using windows when developing an app that will later be deployed on a linux system. If you're developing an app for practice, Windows is fine.
The issue is that if you're aiming at linux, then you'll want to have a full stack on your development machine: a web server, a dbms, perhaps memcached, etc. While it is possible to load all of that onto windows (I've done it), it will take longer than on a linux machine, will be slower and you'll have more difficulty finding assistance when something doesn't work.
Also, you can run into gem and plugin support issues on windows. Eg \ instead of / for directory paths and other weirdness. While rubyists will try to be helpful, windows support is sometimes limited since most RoR work is done on Mac or Linux machines.
Eg Capistrano has had problems running on Windows (they may be fixed now).
As an alternative, you can use Windows as your desktop machine, but use a linux machine as your development server for running the app. Any old pc will run linux just fine. Use samba to remotely access and edit the files from your windows machine. The linux machine does not need a display, you'll only use it remotely.
Just change your app's config/environments/development.rb to include
config.action_controller.consider_all_requests_local = true
so you can see stack traces from your browser running on your windows machine.
Regards,
Larry
Ruby on Rails works well on all platforms, but tool support varies. For instance, TextMate is a favorite editor amongst Rubyists, and it's Mac only. You'll be able to find lots of helpful tools for working with RoR in TextMate, so it might be best to do RoR development on a Mac.
I use Mac and Linux myself.
A Unix based system will offer you a path of lest resistance as all gems are available/compilable on these systems, which isn't as easy on a Windows machine. It's not impossible on Windows but you'll spend more time getting it to work rather in some cases rather than doing work.
Of those Unix systems my preferred is a Mac, it's got all the Unix power as well as all the interface niceties that can be lacking from your linux system, and of course I couldn't live without my daily dose of TextMate, so Mac it is.
I started life as a programmer in 1981 on early Unix systems. I stayed a pure Unix person through 1995. Then 'stuff' happened, (business ownership), and Windows came into my life.
So in 2007 I start learning RoR, pure Windows. I deployed on Joyent, which is Solaris. I've successfully developed two large apps, developed on Windows, and deployed on Solaris/Apache/Mongrel, without major incident.
The only Windows issue I ever remember is that I had to force filesystem reads and writes into binary mode to fix a 'development' vs. 'deployment' issue.
I honestly don't see any problem with developing on Windows and Deploying on Unix. But I had an extensive Unix background, I'm not sure the story would have been the same had I not know Unix.
Also, I'll only ever work on the RoR apps I build for my business. I'll never need to build any other RoR apps, I'll never develop any plugins, never have to take over another project, never have anyone INSIST I include something only available in something that doesn't work well with my Windows development environment, etc...
I'd say this:
If you are responsible for developing a Web app for your employer, and that employer is Windows based, that SHOULD NOT preclude you from considering RoR as platform. The app would have to be deployed by a third party, unless your employer is large enough and the project important enough to warrant in house Unix systems.
So if you know SQUAT about Unix, you MAY need a little help along the way. If you go with a third party Rails host, check out their support forums, make sure there are people willing and able to talk a non-Unix person through any deployment/setup and maintenance issues.
I'll give you an example, on Joyent, if I want to run a migration, I have to go through their Database GUI thingy, log into the database, then 'execute' a command. OK, so I get a simple text_field where I enter input destined for a Unix shell, which is:
cd /user/myhome/sites/mysite && rake db:migrate RAILS_ENV=production
That might not have been so easy to figure out had I not had the Unix background.
As of Ruby 1.9.2 and Rails 3.2, Windows is a lot slower for autotest and spork (one full cycle took ~15 seconds on average compared to mere seconds on Linux for the same project), but I enjoy better gui-centric git tools and functionality (TortoiseGit, WinSCP) among other things since I am much more familiar with Windows. I have verified that the essential features I need are working on both platforms, so I find breakage to be a lesser issue compared to speed.
Doesn't matter, If you're a purist then your dev environment should as closely match your production enviroment as possible with regard to Operating System and version of the Ruby and Rails. But really it doesn't matter much.
Some gems work on Mac but not some flavors of Linux (such as gitjour when I last tried it).
Using a Mac might be good or bad, depending on whether you want to know that whatever you develop will be able to work on any other OS.
I've done light rails development on both OSX and Linux (Ubuntu), and I found the differences to be almost imperceptible (in terms of ruby and rails... obviously the desktop environments are a lot different between the two OS's).
As others have said, most ruby/rails tutorials, gems, plugins, etc. are oriented toward Unix type systems, so I would assume there may be some annoying hiccups trying to do ruby/rails development in Windows, unless of course you're using IronRuby. :-)
A low hassle alternative for setting up a Unix environment for Rails development is to run one of the easier to use Linux distributions, like Ubuntu or Fedora under virtualization software like VMWare, VirtualBox, VirtualPC, etc.
I agree with many of the previous posts that Rails on Windows can be an issue. Its simply the case that many people developing for Rails are on Macs or Linux and as a result Windows bugs are not found, this is particularly an issue with plugins.
One issue with Rails is IDEs. TextMate on the Mac seems to be a popular choice, yet Linux and Windows options are pretty fragmented. Normally I wouldn't worry about this, but I have found that Rails becomes much more manageable when you have IDE support. In general there are lots of files located in a reasonably complex directory structure so having an IDE which allows you to easily find files your looking for is an awesome productivity boost.
Another thing you may want to consider is what your deployment environment looks like. For example, may people deploy there Rails apps on Linux servers. In that case, you may be able to skirt around bugs by developing on OS X, but unfortunately those bugs will crop up when you go to deploy your new software. That is the last place you want to be debugging code. Of course you should be testing your code in a staging environment first, but all too often people skip this step.
While searching for the answer to this question due to always having to hack my way around windows to things to work while developing in Ruby, I can say that if you have the option, use Linux or Mac. I've officially started using Ubuntu 9.04 as of today and here are the reasons why:
1) Can't do any ssh things like use Capistrano, vlad, create gems for rubyforge, etc. You can do these things using cygwin, but it's such a pain in the arse to use cygwin and windows working for everything.
2) The final straw was when trying to kick off background tasks in a rails app only to realize that windows can't fork processes.... didn't even bother with cygwin for this one, just switched to Ubuntu so I don't have to keep working around these issues.
Ubuntu 9.0.4 is pretty hot though, quite impressed so it may not be so bad.
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.