Niantic's system lets you add new VPS data to their system - it takes them 4 hours to validate it, and then it becomes publicly available.
I would like to use Google's Geospatial API instead but need to add our own VPS information because there are areas that aren't covered that I need in the system. Private or public I don't care, I just want the ability.
Is this something that exists?
Cannot find documentation on this.
Related
I've built a database in Neo4j and use Rails with Neo4jrb as an easy way to manipulate the database. For reasons I explain below, below I call this a knowledgebase (kb) instead of database.
I starting working with a friend who wants to provide access to the kb for users of his app. So I built an API in rails so he can access it.
Now my friend and I are talking about building a membership site with subscription payments. So I figured I needed to figure out how to build Stripe subscription payments into my app. I found this great tutorial by RailsApps which in terms of functionality does exactly what I need, it relies on a gem called Payola which makes Stripe integration easy. Payola is great but it works with ActiveRecord, not Neo4j. I was thinking I'd have to figure out how to do what Payola does with Neo4j.
But now I have the idea of just building a separate app using the RailsApp+Payola approach, and then just hooking that app up to my kb's API.
The reason I say knowledgebase is because its purpose is to structure knowledge within a particular domain. I use the graph database Neo4j because the graph-based data model suits this goal, for example (object of type A) -[has a certain influence on]-> (object of type B).
So I like my idea of using a separate app for managing users and subscriptions because then I avoid mixing app specific data with domain knowledge in the database.
So I guess my concern is, what might I be missing? Will speed be a concern if this membership site has to access an API every time a page loads? Would there be unusual security concerns?
It's perfectly fine to use another database next to neo4j. You should always use the database that fits your needs I think :)
I'm in the process of setting up a centralised data management system + CAS for a series of apps that currently have duplicated data across many databases that is a nightmare to manage.
I've got the CAS system implemented nicely with rubycas-server and rubycas-client, but I'm running into problems when it comes to actually sharing the user data and other models between client apps. For example:
CAS/Central system (share a DB) expose a base User as JSON
App1 extends user with information about favourite colours
App2 just cares about having a user
I want to be able to let App1 add the data it cares about the object returned from the API, without burdening App2 with that info.
I'm currently playing around with writing a gem for the client apps which can consume the JSON (with ActiveResource or ROAR, not sure which yet), however the client apps need to decorate/extend their models with additional data which is currently managed via ActiveRecord. So I'm not sure what the best way to go about extending those gem provided instances would be.
So far I've experimented a bit with having the gem contain a bunch of modules which the ActiveRecord models can then include, but this has issues when needing to deal with class methods (not insurmountable but any means). I've tried looking around for resources/guides for best practices in this sort of situation, but haven't been able to find anything.
tl;dr summary: Multiple client apps need to use and extend data provided by a JSON api. What's the recommended practice for doing this?
This might be a nonsensical question, but I have this task to create a rails app that shares session information, specifically login/authorization info, with an installation of a phpBB that some other person has customized to be more than just a BB.
Basically I need to rely on the user's phpBB login to authorize access to the rails app. I really don't want to have the user maintain two logins to use this conceptual single app.
I read a lot of documentation on phpBB and didn't find anything like exposed services or an API, but I'm hoping I just missed something obvious.
I've been considering adding a method to expose some hash or something to link the two applications rather than try to squeeze possibly different implementations of session.
Quick context, this work needs to be done fast and cleanly and I've never developed in php and rails is super fast so I am investigating the idea of integrating the two sides.
I might be off in the weeds, so don't be afraid to say so :)
thanks!
Have you checked phpbb-auth?
https://github.com/mattfawcett/phpbb-auth
I have 2 Symfony applications (1 using 1.2.x, another using 1.4.x and both using Propel) that need to share some specific session information. Although I have no experience with memcached, my sense--after some reading--is that it may be able to serve as an external (FAST) repository that each app could read and write to. Unfortunately, I can't find much information about how to use it with Symfony in any capacity, much less in the quasi-cache, quasi-messaging server I'm envisioning.
My questions, I suppose, are:
Am I mistaken in believing that memcached be used in this manner and access by multiple systems?
How can I configure Symfony to access a memcached repository?
Thanks.
This explains one approach fairly well (you don't need the view cache stuff, just the second half about making a singleton available and configuring it):
http://dev.esl.eu/blog/2009/06/05/memcached-as-singleton-in-symfony/
edit: now 404, but still available here
You can then use:
sfMemcache::getInstance()->set()
and
sfMemcache::getInstance()->get()
(same as the methods here as sfMemcache subclasses Memcache).
As long as both apps point to the same memcache, you should be able to share data between them like this.
I am trying to build a CMS I can use to host multiple sites. I know I'm going to end up reinventing the wheel a million times with this project, so I'm thinking about extending an existing open source Ruby on Rails CMS to meet my needs.
One of those needs is to be able to run multiple sites, while using only one code-base. That way, when there's an update I want to make, I can update it in one place, and the change is reflected on all of the sites. I think that this will be able to scale by running multiple instances of the application.
I think that I can use the domain/subdomain to determine which data to display. For example, someone goes to subdomain1.mysite.com and the application looks in the database for the content for subdomain1.
The problem I see is with most pre-built CMS solutions, they are only designed to host one site, including the one I want to use. So the database is structured to work with one site. However, I had the idea that I could overcome this by "creating a new database" for each site, then specifying which database to connect to based on the domain/subdomain as I mentioned above.
I'm thinking of hosting this on Heroku, so I'm wondering what my options for this might be. I'm not very familiar with Amazon S3, or Amazon SimpleDB, but I feel like there's some sort of "cloud database" that would make this solution a lot more realistic, than creating a new MySQL database for each site.
What do you think? Am I thinking about this the wrong way? What advice do you have to offer in this area?
I've worked on a Rails app like this, and the way it was done there was named-based virtual hosts, with db entries for each site running. Each record was scoped to a site if necessary (blog posts, etc.) while users would have access to all sites running out of that db. Administrator permissions could be global or scoped to one or more sites.
You're absolutely correct when you say you'll reinvent the wheel a million times during the project. Plugins will likely require hacking on top of the CMS itself.
In my situation, it ended up being a waste of almost a million dollars of company money to build that codebase to run multiple sites while still being able to cater to the whims of each client site. It worked, but was not very maintainable due to the number of site-specific hacks that subsequently entered the codebase. You may be able to make it work if you don't have to worry about catering to specific client sites running on your platform.
In the end, you're going to need a layer of indirection to handle the different sites regardless of methodology. We ended up putting it in the database itself. If you go with the different-db-for-each-site method you mentioned, you'll put that layer in your code instead. I'm not sure which one is the better method.
I hope you're able to pull this off. I failed.
Also, as I learned today, Heroku offers postgres instead of mysql for rails apps.
There's James Stewart's Theme Support Plugin for Rails 2.3, and lucasefe's themes_for_rails gem for Rails 3+.
I just started using the 2.3 version and it's working well so far.