Background: I have a Java application that many programming clients interface with. Recently, a few clients wanted me to develop an API to allow them to inherit my application's Java classes in their Ruby documents without having to change their developing environment to Jruby - they want it to remain Ruby on Rails.
In this post, it was mentioned that this could be accomplished by using XML or JSON as a middle-man between Java and Ruby on Rails.
Question: Is the XML/JSON method the best practice? If so, which do you find to be preferable (XML or JSON)? If not, what is a better practice?
Once a best practice is determined, some in-depth (as in-depth as you're willing to go) explanation as to how I should approach this would really be helpful.
Thank you so much
XML or JSON is really a matter of taste when talking server-level APIs. Both are text formats that can be trasmitted via HTTP, and either one can be consumed by a Rails application.
Related
We want to add the routes defined by an LDAP authorization application (a pure API application) to our core rails application, under the path /ldap-auth.
We have the option to use any technology we want for the LDAP authorization application -- we could write it with rails-api, Sinatra, even pure rack -- though we lean toward rails for codebase consistency. The key point is that it's a self-contained application, with its own tests and release schedule.
What would be the most idiomatic rails technology for this use case? Reading the guides it seems that a rails Engine or a mounted Rails API app are the natural possibilities.
My questions are:
What factors should guide my choice of one over the other?
The Engine guide states that "engines and applications can be thought of as almost the same thing, just with subtle differences, as you'll see throughout this guide." However, even after reading through the guide, it's still unclear to me why one would choose to use an engine, versus mounting an ordinary rails app. I'd appreciate clarification on this point.
Finally, if we do decide to go with a mounted rails API application, we'd like to keep it in the same repo. Where is the most idiomatic place to the code? Under /lib?
What is the simplest way of understanding about mongoDB? i know there's something called as NuMongo wrapper to to interact with mongoDB, but yet its not yet clear in my head. Can some please share the knowledge ?
Thanks
Directly accessing a MongoDB database from a mobile device is probably not a good idea. The main limitation is that the Mongo wire protocol has no encryption.
You can build an application server as middleware, in almost any language you like.
That said, ObjCMongoDB (of which I'm author) has support for iOS, so if you decide you want to give it a go anyway, you can.
If you want to write an application server on Mac OS using Objective-C, you can also use ObjCMongoDB for that, along with something like CocoaHTTPServer.
An very simple way is to set up a Rails Application with some mongoDB PlugIn, e.g. mongomapper and in Rails you can define the web service to communicate with the iPhone.
These links are very good to understand Rails and mongomapper:
Rails Guides
MongoMapper Documentation
Some ruby gems like jekyll, toto and webby offer out of the box blog-type integration into your ruby app. Another way of developing a rich web blog-type application is to build and model the application yourself using pure ruby and rails practices. (e.g creating an Article and User model). The first offers out of the box features the 2nd option offers more customization and control.
In people's experience on Stack Overflow, which would be the best route and what would people consider when making the decision to use a gem out of the box versus going alone?
All of the gems you mentioned take static, markdown/textile/etc files and turn them into HTML websites. They take different approaches to it, with jekyll spitting out the finished website for hosting, toto doing the converting and routing on request, and webby doing the same as jekyll mostly.
If you're using Rails, it's important to note that none of these will integrate into your application well. They're built to more-or-less operate on their own.
Generally speaking, if a gem has the functionality you need, use it. They are not equivalent to plugins you find for Wordpress and Drupal where they are typically low-quality, buggy, poorly documented, etc. More often than not, gems simply add a couple modules that you can integrate into your application how you like.
On the other hand, a basic blog is pretty quick and simple in Rails, especially considering you've got a handy walkthrough guide straight from the Rails documentation on how to do it.
If you're new to Rails and want tight integration with your app, it's probably best to bake your own blog features.
This will take some time to do, but its worth it to learn how things really work.
If you're more seasoned, just look at the gem's API and documentation and decide if it does what you want it to do and if you're comfortable with how to integrate it. If so, it'll save you time.
One other consideration: who will be using the blog? Is it for internal use, and programmers will be the ones updating it? If that's the case, then you can make it very easy by not worrying about a lot of aesthetic polish in the back-end. Conversely, if you're making an app that includes a blogging component for the general public you might want it to feel more polished. In this case a gem might save you a lot of time.
It depends on your application.
I've looked up plenty of information on Rails, but I still can't say I'm quite sure of what it is. If I'm developing a web app, what functionality would I get that I couldn't from html/js/php? Would every project benefit from rails, or do you need a certain goal in mind?
Ruby on Rails is a web application framework. Technically there isn't anything that Rails can do that HTML/JS/PHP can do. The point of Rails it to make developing websites easier, faster, and hopefully more maintainable. If you are familiar with PHP, then Rails is somewhat equivalent to Symfony, Kohana or Yii.
I'd recommend trying out some of these tutorials if you haven't already.
Rails for Zombies - you won't even have to setup rails on your machine
Ruby on Rails tutorial book
Railscasts - for once you get more into it
Ruby on Rails is a web framework built for programmer productivity and happiness. It's built on top of the Ruby language which means you get access to all the cool libraries ("gems") other people have written such as file upload libraries and ones that interact with web services such as AWS.
You use HTML and JavaScript with it just like you would in every other web framework out there. The difference? It's not built on top of a hack of a language such as PHP. Good Ruby code is elegant and very readable, and you will find this out in your usage of the framework.
The Getting Started guide explains it very well: http://guides.rubyonrails.org/getting_started.html.
What it is is a framework. It's a set of APIs, a toolkit if you may, to build web applications.
Ruby is a programming language like Python, Perl, C, C++, Java, C#, PHP etc. It's closer to Perl and Python than to other due to its interpretive nature (a scripting language if you may).
RubyOnRails is a framework built on top of Ruby to build web apps. Arguably like Servlets is used to build web apps on Java or .Net is used on C#, or Django on Python or CakePHP on PHP etc. It's an amalgamation of APIs, code generation tools, testing code etc put together.
It's popular because of it's elegance, it's choice of following conventions over configuration (you write less config code or glue code). Once you get the hang of it, there is less ceremony involved before you get from idea in your head to working production application with RubyOnRails (popularly referred to as Rails).
I've been using online tutorials to learn ROR. I've used www.lynda.com video lessons to get a basic idea what Rails is all about, and for practice I used Rails version 2.0.2, during my training period. But now I'm into a development team in a starter company where there are no senior/experienced programmers to assist me and we're working on gitorious source code modification using Rails 2.3.8. I'm facing a lot of difficulties to understand the source code and some of the major differences I could notice is as follows:
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8(I don't understand what this is, as I'd never come across this during my training period using Rails 2.0.2)
In gitorious source directory, in addition to Controllers, Models, Views and Helpers there are two more directories namely, Processors and Metals. I don't understand what their significance is.
Extensive usage of .yml files. What are those for? In rails 2.0.2, all I came across was the database.yml. Now, in gitorious, I see gitorious.yml. How are all these so customized? I mean, how do rails app(controllers, models, etc..) communicate with gitorious.yml?
With respect to all these questions, how do I move a level or two up, to call myself an "intermediate Rails programmer" from "Rails novice programmer"? and how do I stay updated of new api, deprecations, in all upcoming Rails transitions?
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8
Yes, the way scaffolding works has changed - I can't remember exactly when it changed, but I can certainly believe the change happened between 2.0 and 2.3.
When you generated a scaffold the old way, it would just include 'scaffold' commands in the controller, which would render up a default interface for each of the actions until you replaced them with your own HTML templates.
The new way actually generates the HTML templates as files: so, in the views directory, there will be a directory containing ERb (HTML with embedded Ruby). You can then go and edit those directly.
It also renders XML - this is done by default, but you can choose what other formats are produced. Rails lets you produce multiple output formats for each controller action - so that you can easily produce RESTful web services. So, you obviously produce XML by default, but you may want to produce machine other formats too: XML (including RSS/Atom), JSON (and JSON-P etc.), RDF, YAML. I use this to produce CSV and Excel so users of the site can get data exported to their spreadsheet package.
In gitorious source directory, in
addition to Controllers, Models, Views
and Helpers there are two more
directories namely, Processors and
Metals. I don't understand what their
significance is.
processors/ is used by ActiveMessaging - it contains ActiveMessaging processors - basically code that gets called as part of communication with a message queue that ActiveMessaging is hooked up to.
metal/ contains code that can best be characterized as 'middleware' - basically, to deploy a Rails application you use a library called Rack which abstracts away the interface between the server and the app itself. It allows you to use the same web server and other infrastructure and switch between different Ruby frameworks - so, if you are using Rails or Sinatra or Merb, Rack lets them all communicate with the same server.
Now, Rack allows you to write 'Metal' code, which is code that gets run directly on the server without the framework getting in the way. The reason you write Metal code is for performance - when Metal code is running, it is running directly rather than with the weight of the Rails framework getting in the way. This way, you can get better performance. I haven't ever had to write any Metal code, so I can't really explain it beyond that.
Extensive usage of .yml files. What
are those for? In rails 2.0.2, all I
came across was the database.yml. Now,
in gitorious, I see gitorious.yml. How
are all these so customized? I mean,
how do rails app(controllers, models,
etc..) communicate with gitorious.yml?
.yml files are files in the YAML format. In Rails, these are mostly used for configuration. Just as XML files are used by Java applications for configuration, .rc files are used in Unix for configuration and .ini files are (were?) used for various apps on Windows for configuration, you can store data in the YAML file which the Rails app uses for configuration. Because of the simplicity of the format, a lot of Ruby and Rails apps use YAML for configuration files.
Ruby has a built-in YAML module that loads these in using methods in the YAML module including YAML.load, YAML.load_file, YAML.load_documents etc. To see how they are being loaded in, I suggest the easiest thing is to find the string "YAML." in the project - or, indeed, the name of the yml files.
With respect to all these questions,
how do I move a level or two up, to
call myself an "intermediate Rails
programmer" from "Rails novice
programmer"? and how do I stay updated
of new api, deprecations, in all
upcoming Rails transitions?
I would suggest that a fair amount of conservatism is appropriate with Rails updates. I'm still using Rails 2.3.3 on a production site, and that's fine. I should probably upgrade to 2.3.8, but I tend to not run with the bleeding edge on production projects.
As for the best way to learn, I'd suggest that you work through Railscasts - these are excellent short screencasts that describe all sorts of useful techniques and help you learn lots about the Rails framework. When you need to do something, obviously there is the API docs - which are okay. The Rails Guides are pretty good and worth reading.
As for books, there's Agile Web Development with Rails - which is a pretty good tutorial. There's also The Rails Way, which is a massive desk reference and in my experience one of the only good ways to learn about some of the minutiae. You might also want to check the StackOverflow question What’s the best resource for learning Rails for a raw beginner? - because although you obviously aren't a raw beginner, the resources recommended are up-to-date and useful for going from novice to intermediate and on upwards. Good luck!