I can't use Chargify, Recurly, Spreedly or any of those apps because I am not based in the US. I am in Jamaica, actually...so many of these companies don't support Jamaica.
But I am trying to roll a custom subscription management solution - but given that this is my first web app - I think it might be too big a task for me to take on.
Are there any gems that can handle this? These are the requirements:
All users registered automatically get on a free plan for X days
Towards the end of X days, they should be prompted to upgrade
If they don't upgrade, at the end of X days their account gets locked/disabled
If their account is disabled, they can upgrade and be taken to a checkout page (powered by 2checkout, because that is who I have to use for now).
Then once they upgrade, and have selected a plan, the system should automatically increase their allocations (# of clients, # of projects, storage space, etc.)
So I don't need the system to actually handle the processing of the credit cards, etc. It's more the logic of the subscription, restrictions on the models, upgrading and downgrading that I need.
The perfect solution would be a well supported Rails gem that I can include in my Gemfile.
If you don't have that, just send any/all possible solutions and I can take it from there.
Thanks.
You can look into Saasy. It's a stand alone Rails app (not a plugin) that you host on a subdomain and communicate with it using SSO/REST protocols. Probably won't fit your need as it is, but you may be able to extend it or get a general idea of how it works.
There is a great solution called Chargify, its one of Heroku available add-ons, you can see it here: https://addons.heroku.com/chargify and http://devcenter.heroku.com/articles/chargify
With a reasonable rate, you can manage all the recurring/subscription billing in your Rails App, I hope this is useful answer.
Related
What considerations are needed when creating a web app that is intended to be used in an industrial plant setting for a company? My specific use case is an industrial facility with several different production plants that would each have its own device for the application interface.
How do companies enforce the usage of such apps on a monitor/tablet? For example, could I prevent them from using other stuff on the tablet?
Importantly, how would security work? They'd share a device. There may be multiple operators that use the app in a given shift. Would they all use the same authentication session (this is not preferable, as I'd like to uniquely identify the active user)? Obviously I could use standard username/passwords with token based sessions that expire, however, this leaves a lot of potential for account hijacking. Ideally, they'd be able to log on very quickly (PIN, perhaps?) and their session would end when they are done.
As long as there is internet connection, I would presume that there isn't much pro/con regarding the use of native applications versus web based or progressive web apps. Is this assumption correct?
What's the best way of identifying which device the application is being run on?
Is this a common thing to do in general? What other technologies are used to create software that obtains input from industrial operators?
--
Update - this is a good higher level consideration of the question at hand, however, it has become apparent why focused, specific questions are helpful. As such, I will follow up with questions that are specific.
Identifying the Area/Device a Web Application is Accessed On
Enforcing Specific Application Use on Tablets
Best Practices for Web App Authentication in Industrial Settings
I'm not able to answer everything in great detail but here are a few pointers. In the environment as you describe we usually see these two options. 1) you tell them what you need, internet, security, if they give you device and how it will be configured 2) they tell you exactly what you need to deliver.
I do not think you can 100% prevent them. We did it by providing the tablet( well laptops in our case) and the OS configuration took care of that, downside we had few devices to support. You seem to hint that there is always an internet connection so I guess you can collect all info about the system and send it back to you daily?
We were allowed to "tap" into their attendance SW and when you entered the facility you were able to use your 4 digit pin to log in if you were out of premisses you could not log in at all. I can imagine the following: you log in with your username and password - this does full verification, after that, you can use 4 digit pin to login for next n hours.
maybe, kinda, depends on what you are doing. Does the browser have all features you need? Our system needs multicast to perform really fast, so we have a native app
touched on this in 1. You could also use device enrolment process. You can also contractually force them that there will be only your software and it may invalidate support contract. It really depends on your creativity. My favourite( and it works - just tell them, there will only be installed my software and if not you will pay me double for support. I only saw one customer who installed some crap on the device when there were told not to
it really depends on what industry you are talking about, every industry is different. We almost always build a custom solution
The enforcement of the device/app usage depends on the customer, if the customer asked for help in the enforcement, then you can provide guide, training and workshops. If the customer serious about the enforcement then it will be a policy that's adapted by all the organization from top to down. Usually seniors will resist a workflow change more than juniors, so top management/executive should deal with that. Real life story: SAP team took 6 months to transform major newspaper workflow, during that few seniors got fired because they refuse to adapt the change.
Security shouldn't handicap the users, usually in industrial environment the network is isolated or at least restricted through VPN to connect multiple sites (plants in your case), regarding the active user: we usually provide guide/training/workshop for the users and inform them that using colleague account or device will prevent the system from tracking your accomplishment/tasks, so each user is responsible to make sure the active account/device is the one assigned to him/her.
It depends, with native you have more controls than web, but if the app is just doing monitoring then most of today apps use web for monitoring and the common way to receive input is REST APIs (even if the industrial devices doesn't support REST API, a middleware could be written to transform the output). If you need more depth about native vs web you need to ask new question with more details about the requirements.
Depends on the tech you are using (native or web), and things I mentioned in point 2: you can use whitelist of devices that's allowed to run the app. overall there are many best ways to track down the device.
How common in general? I think such information can only be achieved by survey, the world full of variations. And having something common not mean its safe or best, our industry keep changing at all levels. So to stay in the loop, we must keep learning and self-updating without reboot.
I have made an android application that enables advertisers to count the posts each one of their followers/followings have liked. this way they'll be able to understand which one of them is more active and which one is not, I also have added another feature for sending like requests to the followers/followings by leaving a like on their most recent post and leaving a comment that tells them "I liked your posts come and like my posts".
I registered a submission and explained everything as they wanted, but they declined my submission :(
Now my question is How should I explain it for them or WHAT CHANGES should I apply to my application so they approve it.
This is their answer:
General issues:
Invalid Use Case: The use case described in your submission notes,
screencast and website is not a valid use case. If you are trying to
build analytics for personal use or one-off projects, note that we do
not support one-off and single use projects. We recommend that you use
a third-party platform that powers this use case. If you are building
a platform for this use case, we will only approve one client ID for
all your integrations. For more information, please see:
https://www.instagram.com/developer/review/ Policy Violation ("Like",
"Follow", "Comment" Exchange Program): Your app shouldn't participate,
enable or promote any “like”, “share”, “comment” or “follower”
exchange programs. In working to build a high quality platform
experience, we ask that you comply with our Platform Policy
(http://wwww.instagram.com/about/legal/terms/api/).
I have to say my application is not a ONE-OFF application, as the number of liked posts vary from time to time, so the user will check this application almost every day.
I also have added another feature for sending like requests to the
followers/followings by leaving a like on their most recent post and
leaving a comment that tells them "I liked your posts come and like my
posts".
This is against the API policy:
Your app shouldn't participate, enable or promote any “like”, “share”,
“comment” or “follower” exchange programs.
I have an app in the iTunes Store and sales have slowed so want to convert it to a free app from a paid app. The new app will contain an option to buy, using In App Purchase. I was considering using a flag / pre processor macro to then allow full features for those that buy using the IAP, and limit features for those who have not.
The problem will be if I add this new pre processor macro to the new update, those who have previously paid for the app will not be able to use full features, as they would not have used the IAP to "unlock" the full app.
Does anyone have any suggestions to overcome this problem.
I have a few ideas, but in my mind they are not fool proof.
Thanks for assistance.
Pondering exactly the same issue here. The only thing i found workable (under most use cases) is to look-up gamestate information at when the new_free_iAP version starts.
If there is no iAP state, AND if games exist, AND the playtime counter > 0, i will make the assumption that the user bought this and will preseed his/her iAP configuration information to indicate that this was iPurchased. The only users left out would be buyers who NEVER started the app.
Not fool proof, but better than none. Ugly state to manage, nasty testing for this. And of course, this is a variable geometry solution : if I did not have reliable persisted state in the current version, i would not know where to start.
I have a logistical question: I'm trying to figure out the best way to manage APIs getting out of sync with an app. The best way to explain it is with an example:
Let's say MyApp Version 1.0 posts to a "submit_feedbacK" API that requires first_name, last_name, and email.
I then submit MyApp Version 2.0 to the App Store. That version is designed to post first_name, last_name, gender, and email to the API. All of these are required fields on the API.
The problem I have:
- If I update the API before the new App is live, it will break Version 1.0
- If I wait until Version 2.0 is live and remotely cripple 1.0, I have to time it correctly.
I'm going to guess that the 'right answer' is to maintain two different APIs. But if both APIs post to the same live database, that makes things a bit awkward.
Does anyone have suggestions on how to model this?
This question may share some aspects with iOS consuming API design.
The right answer is definately to provide two APIs (at least for a short period of time while users adjust). You do not have to maintain two versions at the same time, as once a newer version is released you can maintain that one, and simply provide the old one for legacy users. The only real changes you may have to make to it are things like security patches or major issues. Major changes (such as you deciding to restructure your entire database) may lead to the old version not working any more, however update to newer API versions should be designed to allow previous versions to still function.
The other question I linked you to gives an answer about how you can have different version of your app access the correct version of the API.
Another note is that it may be easier for you (depending on what framework you're using) to design your APIs as engines or subapps, and simply mount them at different end points. I know that this is easily do-able in Rails by using Engines, and in Node with Express using app.use() with sub-applications.
I would use a webservice/http endpoint for the communcation with your app. If you preferer to maintain the same URL in all versions of the app, then include a version number in all the requests/posts to the server so it knows how to handle them. This will also make the development and tests easier as new versions can test against the new api on the server.
So on any function you can call in the webservice/server add a single variable with version number. a BYTE ought to be enough as I think you could start over and "kill support for v1.0" once you hit 256 versions of the same function (if ever).
Once the server receives a request/post with data, you can just code a simple switch/case structure in the server API so support works for both versions.
If they do similar, but eg. swaps the parametres or something, you can handle all these serverside and the BAL/DAL (n-tier structure) can be maintained on the server part of the solution.
Btw. my answer is not just for iOS or smartdevices, but merly a client/server approach for a "work-in-progress" production setup where everything has to be online, while still being under development and maintanance.
Hope it makes sense, otherwise, comment on it and I shall try to explain it further.
just FYI, I use CodeIgniter. I'm using the REST Controller provided at https://github.com/philsturgeon/codeigniter-restserver. I ultimated ended up settling on having different end-points for every version. Basically I'd check out a new repository for each release and put it into a unique directory. (i.e. http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method, etc) Trying to maintain multiple versions of an API under one code-base just sounded too scary. At least when I released a version, I would know it is locked in stone and I don't have to worry about breaking it. (Note: I had to use a special .htaccess tweak to get multiple CodeIgniter instances running from the same domain. I can share it if you like)
When facebook rolls out a new version of their site, they show it to a percentage of users first.
How could I go about doing this cleanly?
Have your users sign up for your Beta.
Select a certain percentage of those who sign up for your Beta. As you make changes, keep incrementally adding some more testers. You don't want to let everyone in at once so you can get testing all the way up until the feature is complete and released. Look at stackoverflow as an example.
You would do this because most of the people who sign up will check out your beta version, then leave. They most likely will not come back / keep testing for you.
It is also better to opt-in than opt-out. Your users may not want to be your test subjects.
With a proxy that diverts some fraction of the sessions to one of two separate running instances. The proxy can be a software proxy on the hosting machine.
Well, depending on the change, if you have a farm of web servers you could apply the change to only some of the servers in the farm. That way only certain users who were "lucky" enough to hit one of the updated servers would see the change. Of course, this approach assumes that your web proxy will always route any given user to the same server (or group of updated servers) in the farm.