Disclaimer: We're a collection of scientists that are just now getting into python/ruby.
Project summary: We have analytics and usage data from social networking sites that we are using R and Highcharts (via lazy_high_chart gem) to present analytics to users through a website. The user can interact with this data by specifying which and when they want to investigate a social media segment. So the user defines the subject and the website responds with a slew of metrics.
Problem: So far we have been using straight ruby to pull social networking data (one class), send it to the analytics engine (another class), and present it in plotted glory (final class). However, this is all been proof of principle and console driven so it seems inefficient to push it to a site from this start. Should we have started from the ground up with a rails framework and just built the site with all of these analytic engines built into the site? Or...is it better to have this backend pipeline written in ruby that only interfaces with a rails framework trough yet another object?
A suggestion or pointer to a general document that hints on how to integrate backend data crunching with frontend rails would be great.
Your question is basically how to architecture the system, and this is somewhat hard answer since it usually depends on a lot of things: system requirements, application landscape, project planning, skills, etc.
But just looking at the two alternatives you mentioned, I think there's nothing wrong with creating a fresh Rails application, copying your prototype modules into the lib/ directory and connecting things the standard way. You can use rake tasks to keep the console interface you already have. In the end, your setup looks quite similar to a standard web application. (Usually you have a database doing the "data crunching", in your case it is the R engine.)
I don't know any specific documentation about integration Rails with R, but some research about general system integration with Rails should give you a good starting point. (However, this would only be needed if you really want to build two independent systems.)
Related
I was setting out to start a new Rails 5 API, and realized I also need a content-administration "site" of some sort. The admin tool is very simple, just a UI for very basic CRUD operations.
I have an instinct to create two separate Rails applications - one web application for the content-admin tool, and another web application for the API.
This brings about the problem with sharing data models, which is solvable by using rails engines, or including the models as a gem.
As I was researching solutions, I seemed to observe a pattern of including the content-admin portion within the API app itself. There are some middleware includes and controller inheritances involved in this, but its quite simple to get a content-admin UI to run within the same app as an API. Its much less work, and I dont see much of a problem with scale, since the content-admin UI is lightly utilized and the API is the core of the business.
Is this the accepted convention? I might be gaining a bias due to web search results, but it seems like the simplest and most common approach. I plan to have a separate server for accessing the content-admin vs accessing the API, which is what led me to originally plan this as two separate apps. Now I am thinking I was just getting sucked into the "microservices" hype, and it seems more conventional to just include the content-admin UI with my API app.
On the other side, everything I read about Rails engines is 3-4 years out of date. There is little information (that I am stumbling upon) within the last year or so, and more specifically, little-to-no information concerning Rails 5. I am wondering if this sort of architecture has fallen by the wayside.
Is there a typical convention for Rails 5 API applications that also need a content-admin UI?
The approach I've used before is to have the api running out of /app/controllers/api and then have the ActiveAdmin gem installed, with the admin interface files in /app/admin. You can set up the routes to serve the admin interface at https://api.yourapp.com/admin and the API at https://api.yourapp.com/api/v1/ or similar.
I don't know how much of an accepted convention this is, but it works fine.
So I am starting out on company project that will have several components:
At first...
Job list
Client profile creation and management
User administration and access (login, signup, roles, etc)
later...
Messaging
Schedule
Basic reporting
way later...
Deeper analysis and bi
I'm wondering if it makes sense for each bullet item to be its own rails project, self contained and modular (if that is indeed the case); or if it's just best for it to be in the same app. I could envision a situation where each module could operate so independently of each other that it wouldn't need the rest (except for the user funcionality) and another situation where all modules would be used together.
It seems like to me that many tasks can be handled with a lighter framework like Sinatra (and then situated physically under the rails app). It also seems like it would be a lot of overhead to have several rails apps running on a server. But I am not totally aware of all the pluses and minuses to operating each scenario.
I know this is kind of a general question that is bound to get a lot of "it depends" kind of responses (and rightfully so) I was looking for opinions/examples of how you setup this kind/your kind of project in rails. I am a quasi noob so be gentle.
Thanks in advance!
Generally speaking I would consider a website to be a suitable target for a Rails app. Each part of the app can have its own namespaces within the app, so the app has some structure internally, but they should all be one application. Consider things like sessions, where you want a user to login and use whatever features of the site you want. You want those sessions in one application without a user having to login to different sections.
Saying that, if there is complex or extended functionality that isn't part of the MVC architecture (say talking to an external API, data-mining etc), then you could offset that to a separate project and a include it as a Gem in your application. You would still have one main Rails application that includes those Gems.
You might also want to bundle together a section of your project into a reusable Rails engine that can be loaded into multiple projects. For example, Devise handles user login and management. It is a Rails engine, bundled as a Gem, that you include in your project.
Another example from Meducation (one of my sites). I'm in the process of extracting our email tracking system out into its own Rails engine as I feel its functionality sits alongside Meducation and is not a core part of it. I can then use it in other projects as well.
In your specific example, I think your requirements fit fine in one Rails application.
My team has been developing a bunch of modules in a monolithic Rails app for internal use. The modules are for example leave request, staff info, tasks/todo etc. Each module has its own purpose but somehow is linked to common information such as staff profile and user authentication. Each module has a developer assigned and they commit code to the same Rails app. Currently, it's super hard to maintain the code and scale. Now, I'm doing my research to decompose the app into small distributed apps and make them an ecosystem. Here are the concept I'm looking for:
There should be a master app that maintain the views of other client apps. Better yet, it acts as a platform for other client apps to plug in to it. Staff logs in to this master app to access client app.
Master app should render views of client app using AJAX or other ways (not decided).
Although, I want to decompose the apps, but each app should still be able to query resources/data such as staff profile from other client app in the ecosystem.
Actually, I have not decided about the interaction of each app. Thinking to us RESTful (not decided).
It should support development environment where each developer can develop each app independently. Hence, maintaining their own code in their own git repository. This is probably the main purpose of decomposing the app in the first place.
I'm reading Service-Oriented Design with Ruby on Rails book, but it seems like they focus on decomposing an app into small different services, whereas I want to have small different apps. Just wondering if there's any other ways to do.
Sorry for a long question and asking too much. Just want to know if you have been in the same situation and can guide me to some articles, communities, books so that I can continue more on my research.
Ah the joys of refactoring. It can be a tricky dance trying to structure an application into logical groups so that parts can be decoupled.
I would strongly suggest looking into Engines, with the Engines vs Mountable being very informative. This allows you to build a mini Rails app (aka an Engine) that can be packaged as gem. The custom Engine gems are bundled into a Rails app, providing a complete set of configurable functionality (models, controllers, views, etc).
The usefulness of Service-Oriented Architecture depends a lot on what kind of data you are pushing and pulling around. That being said, Rails is really wired for RESTful, so you get a lot of bang for the buck with that route.
a friend of mine wants to create a simple inventory database that can be deployed on the web.
He has had a lot of experience with Database tools like Paradox. Moreover he has experience with writing Macros and programs with Basic, and even a bit of C++ experience. He uses Windows and Mac OS X, though mostly Windows.
If the requirement of having a web application wasn't there I would recommend MS Access.
Currently I see these options:
A) Ruby on Rails
Pros:
easy to start out (even on Windows?!)
at least from a programmers point of view perfect to create simple CRUD applications
can be deployed at virtually every popular Cloud hoster
I could easily assist if there were problems
Cons
ActiveRecord is from my point of view too technical
Designing forms requires ability to fiddle around with CSS and HTML
B) VB.Net
Pros
he has experience with simliar programming languages
easy to create forms and possible to deploy CRUD apps on the web
Cons
can be deployed only at few hosters (only Azure?)
simple problems can be quite difficult to solve in VisualBasic
C) Cold Fusion, ...?!
Pros/Cons
I have no idea
I am happy to hear about your suggestions.
Thanks, Philip
I have yet to use it, but the http://www.force.com/ platform (which salesforce.com is built upon I guess) is supposed to make it easy to develop data driven apps for more like business analyst roles. There is a cost to host it, but one app isn't that much on a monthly basis and the 30 day free trial would let you figure out if it worked for you or not.
If you are looking for database application frameworks for people who are not software developers, you might look at LightSwitch. It is designed for that particular demographic.
As much as I like Ruby on Rails AND the .Net platform for database-driven apps, they are both designed for developers to use. Going to something designed for your task might just be what your friend needs.
http://www.microsoft.com/visualstudio/en-us/lightswitch
Check out the examples on agiletoolkit, the php framework with jquery and php form examples. It's php with some jquery but to get a basic application up and running against a database, you dont need to know much php at all.
The five lines are the code shown on the left of the image are all thts needed to create a CRUD based on a database table with both a form and a grid with specified columns. It will open a jquery dialog for ADD and EDIT and uses AJAX to update the form.
It also has built in functionality to add one click sorting on the column headings, pagination so you dont get an endless grid on one page but get << < 1 2 3 .. N > >> style links to page through the results set and a search box to filter the results to a specified subset.
Note the colours are added by CSS and can be removed.
The second negative point for Rails ("Designing forms requires ability to fiddle around with CSS and HTML") could be easily mitigated with the use of a gem that generates forms (like formtastic or simple_form).
Apart from Rails I would suggest Monk which is a lighter-than-rails ruby-based web framework. Its components are loosely held together and there are many skeletons (web app templates) to choose from.
Pros
multiple skeletons to choose from
very light/minimal (a new developer will not get lost in the myriad of files and folders that Rails is)
as easy to deploy as Rails (is rack based)
Cons
does not seem to be as well-maintained as Rails
most Ruby stuff don't play well in Windows (AFAIK)
PS: on the second positive bullet of rails (and ruby) I would like to add Heroku which is a GREAT service for getting-started projects.
Building CRUD Apps using ZK Studio is very easy.
CRUD Apps can be built in 5 to 6 steps. Check it out.
Rails is the most innovative and easy approach to creating crud apps ever.
There are plugins like active_scaffold and hobo that allow you to create CRUD apps without having to write almost any code.
I'm going to be collaborating with a Python developer on a web
application. I'm going to be building a part of it in Ruby and he is
going to build another part of it using Django. I don't know much about
Django.
My plan for integrating the two parts is to simply map a certain URL
path prefix (say, any request that begins with /services) to the Python
code, while leaving Rails to process other requests.
The Python and Ruby parts of the app will share and make updates to the
same MySQL datastore.
My questions:
What do people think generally of this sort of integration strategy?
Is there a better alternative (short of writing it all in one language)?
What's the best way to share sensitive session data (i.e. a logged in
user's id) across the two parts of the app?
As I see it you can't use Django's auth, you can't use Django's ORM, you can't use Django's admin, you can't use Django's sessions - all you are left with is URL mapping to views and the template system. I'd not use Django, but a simpler Python framework. Time your Python programmer expanded his world...
One possible way that should be pretty clean is to decide which one of the apps is the "main" one and have the other one communicate with it over a well-defined API, rather than directly interacting with the underlying database.
If you're doing it right, you're already building your Rails application with a RESTful API. The Django app could act as a REST client to it.
I'm sure it could work the other way around too (with the rest-client gem, for instance).
That way, things like validations and other core business logic are enforced in one place, rather than two.
A project, product, whatever you call it, needs a leader.
This is the first proof that you don't have one. Someone should decide either you're doing ruby or python. I prefer ruby myself, but I understand those who prefer python.
I think starting a product asking yourself those kind of questions is a BAD start.
If your colleague only knows prototype, and you only know JQuery, are you going to mix the technologies too? Same for DB? And for testing frameworks?
This is a never ending arguing subject. One should decide, IMHO, if you want so;ething good to happen. I work with a lot of teams, as a consultant, Agile teams, very mature teams for some of them, and that's the kind of stuff they avoid at all cost.
Except if one of you is going to work on some specific part of the project, which REALLY needs one or other of the technologies, but still think the other one is best for the rest of the application.
I think, for example, at a batch computing. You have ALL your web app in ror or django, and you have a script, called by CRON or whatever, computing huge amounts of data outside the web app, filling a DB or whatever.
My2Cts.