I'm writing a program in Adobe AIR and need to lock it so that it only works on one computer per license bought.
I was originally planning on writing it myself and, with some great help from SO users in my last question, decided to make a call to an external program depending on the architecture and OS. However, due to time constraints - and a wish to easily keep the cross-platform advantage of AIR - I'm wondering whether there's a way to do it from within AIR such as a 3rd party library.
Any ideas would be welcome.
I am in the process of researching this same thing for an AIR application, below are the service providers I am researching or have shortlisted:
www.activation-cloud.com/site/servicess
www.digitaldeliveryapp.com
www.payloadz.com
www.sharify.it - This has been in beta for 3 years and still is.
www.nitrolm.com - This company focuses on renewable licenses and doesn't offer a solution for one-time or lifetime licenses.
www.zarqon.net
www.wyday.com/limelm - I'm heavily leaning towards this company, I am just not impressed with the screenshots of their Account Control panel.
www.sentinelcloud.com - Extremely robust and offersNo pricing online.
Since it has been a while since you posted this question... please share anything you have learned or how you solved it.
Related
Ok this is more informative question than on a coding question. However this is a two part question.
When building the flavors for example an MP3 player.. you would have free and premium. I started designing a flavor app of an MP3 player to start learning Flavors and Build variants.
What i am trying to understand is when building the flavor is all of the design for the flavors built in Project then each flavor is specific. Premium features for Premium and free features for free. I understand that.
However what i am not understanding about the design is when i design my login with firebase how do i call the flavor thats appropriate. For testing purposes lets forget firebase. Here is an example:
MainActivity has two buttons. One will point to the free and the other paid. So if i press the free button do provide an intent that points to the flavor as this:
val i = Intent(......buildConfig.flavors.free)
Or would i place the package name in where the buildConfig would go. This is not actual code this is just an example.
Keep in mind i have never built a flavored app. So this is a learning point for me.
My original idea was have a free version as default with an in app purchase. You use the in app purchase and if the purchase is successful then the premium would take effect.. the only differences in the actual deaign would be those premium features are enabled.
So the first question would be: Is there really a difference between same design flavors versus in app purchases?
The second question is: when building a flavor app with the same design. Do you have to use flavors, example Free/paid, if the design never changes.
Like i said this is a learning process and all my apps on google play is just a flavorless app with adMob banner ad. So i an wanting to venture out to a more simple aspect than having two apps on google play one app for the free and another app for premium.
I think it would be easier to do flavors. However i have never done a flavored app and all the research i have done does not give clear instructions. They all stop after the gradel file implementation.
So any direction would help with is flavors a must or is it more headache to deal with in my case for learning purposes versus real world application.
I apologize in advance. I'm almost certain this question may not be appropriate here, but there doesn't seem to be a specific place on SO for such questions, so I've decided that as a last ditch effort, I'll ask on the main site. Please don't be (too) angry with me....
I'm looking for a specific IoT project, that was developing modules connected by BLE. They were independent modules, say just a speaker, on a coin-sized die connected to each other or a computer via BLE. The project seems to have been succesfully funded on Kickstarter, with an SDK and shipping to the backers, but I can't find them again. I've been searching for a day and a half, but I can't remember for the life of me what they're called. I've searched through my chrome bookmarks, but the computer I was using at the time was a lab system, so I most likely wasn't logged into Google, and those systems are wiped every week. The project was probably from 2014, and they kinda advertised themselves as an easy way to learn HW/SW, and the SDK might have had Code block drag and drop, like Scratch. No combination of search terms that I can think of on Google is bringing up the results I want. Please help, if you know this project, or a specific way to find it.
I'm fairly certain this question will get moved, but before it does, I hope SO's vast and vastly informed community will be able to help me or point me in the right direction....
After days of searching and going through possibly most of the IoT style projects out there, I finally found the one I was looking for: it's SAM Labs. If anyone wants to know, it's probably one of the cheaper options for creating a limited use remote application.
There are a couple of questions on Stackoverflow asking whether x (Ruby / Drupal) technology is 'enterprise ready'.
I would like to ask how is 'enterprise ready' defined.
Has anyone created their own checklist?
Does anyone have a benchmark that they test against?
"Enterprise Ready" for the most part means can we run it reliably and effectively within a large organisation.
There are several factors involved:
Is it reliable?
Can our current staff support it, or do we need specialists?
Can it fit in with our established security model?
Can deployments be done with our automated tools?
How easy is it to administer? Can the business users do it or do we need a specialist?
If it uses a database, is it our standard DB, or do we need to train up more specialists?
Depending on how important the system is to the business the following question might also apply:
Can it be made highly available?
Can it be load balanced?
Is it secure enough?
Open Source projects often do not pay enough attention to the difficulties of deploying and running software within a large organisation. e.g. Most OS projects default to MySql as the database, which is a good and sensible choice for most small projects, however, if your Enterprise has an ORACLE site license and a team of highly skilled ORACLE DBAs in place the MySql option looks distinctly unattractive.
To be short:
"Enterprise ready" means: If it crashes, the enterprises using it will possibly sue you.
Most of the time the "test", if it may really be called as such, is that some enterprise (=large business), has deployed a successful and stable product using it. So its more like saying its proven its worth on the battlefield, or something like that. In other words the framework has been used successfully, or not in the real world, you can't just follow some checklist and load tests and say its enterprise ready.
Like Robert Gould says in his answer, it's "Enterprise-ready" when it's been proven by some other huge project. I'd put it this way: if somebody out there has made millions of dollars with it and gotten written up by venture capitalist magazines as the year's (some year, not necessarily this one) hottest new thing, then it's Enterprise-ready. :)
Another way to look at the question is that a tech is Enterprise-ready when a non-tech boss or business owner won't worry about whether or not they've chosen a good platform to run their business on. In this sense Enterprise-ready is a measure of brand recognition rather than technological maturity.
Having built a couple "Enterprise" applications...
Enterprise outside of development means, that if it breaks, someone can fix it. I've worked with employers/contractors that stick with quite possibly the worst managing hosting providers, data vendors, or such because they will fix problems when they crop up, even if they crop up a lot it, and have someone to call when they break.
So to restate it another way, Enterprise software is Enterprisey because it has support options available. A simple example: jQuery isn't enterprisey while ExtJS is, because ExtJS has a corporate support structure to it. (Yes I know these two frameworks is like comparing a toolset to a factory manufactured home kit ).
As my day job is all about enterprise architecture, I believe that the word enterprise isn't nowadays about size nor scale but refers more to how a software product is sold.
For example, Ruby on Rails isn't enterprise because there is no vendor that will come into your shop and do Powerpoint presentations repeatedly for the developer community. Ruby on Rails doesn't have a sales executive that takes me out to the golf course or my favorite restaurant for lunch. Ruby on Rails also isn't deeply covered by industry analyst firms such as Gartner.
Ruby on Rails will never be considered "enterprise" until these things occur...
From my experience, "Enterprise ready" label is an indicator of the fear of managers to adopt an open-source technology, possibly balanced with a desire not to stay follower in that technology.
This may objectively argued with considerations such as support from a third party company or integration in existing development tools.
I suppose an application could be considered "enterprise ready" when it is stable enough that a large company would use it. It would also imply some level of support, so when it does inevitable break.
Wether or not something is "enterprise ready" is entirely subjective, and undefined, and rather "buzz word'y".. Basically, you can't have a test_isEnterpriseReady() - just make your application as reliable and efficient as it can be..
I know just the question is a bit of heresey, but I'm curious...
Sure, there are the express editions. But when Microsoft is effectively competing for 'hearts and minds' in an OSS world, it seems more than a bit counterproductive to charge devs who wholeheartedly support .NET high subscription fees for Microsoft software. It's hard to imagine that, in the context of Microsoft's overall sales, dev licenses represent such a significant revenue stream as to justify the downsides.
So my question is: do you know of any instances where MSDN subscription rates have deterred a team from adopting .NET for a project - where cost played a role in a decision to go OSS instead?
I think MS has made huge inroads to making .Net cheaper to access and work with. With competent Express versions of Visual Studio and Sql Server, the only thing you need to pay for is Windows itself (both in your dev environment and server/production environment).
The only thing holding .Net back now is it may not be the right tool for every job regardless of cost.
It does to me. It makes me ask maybe I should try and become a Microsoft MVP because they get all the software for free.
You can't buy Expression Blend and Design for anything but the highest level on the License and that just ticks me off.
I don't think so, especially with the empower program for small ISVs -- $375 gets you 5 MSDN licenses and other goodies. After that there are Microsoft Action Packs as well as the entire partner program.
I've always gotten legal, free copies of Visual Studio. You can either download the Express versions which will handle most people's needs or go to the Launch events where they literally give out copies to everyone who shows up.
.NET Framework is a free download, so really the only thing left is a box running Windows.. and I'd be willing to bet that you've got one of those kicking around somewhere.
There's no reason to purchase an MSDN subscription.
It's not a barrier to entry, but it certainly represents a glass ceiling. You get a lot of things with the Express editions, but not EVERYTHING. There's a lot of little perks that come with the Pro versions - addins for instance +cough+ Resharper +cough+. I'd say you need Visual Studio 20xx Pro at a minimum to do any mid-range to Enterprise level development.
The cost of MS developer tools was the sole reason behind my Year of Linux. It's tough seeing all the free development tools for Linux, OS X and Java. If my job didn't depend on keeping up to date with .NET, I'd leave it for dead in a heartbeat.
In my view MSDN subscriptions are not a huge deterrant, as not only are there express editions, there are also trial versions of most products, and I think a basic MSDN subscription is not that expensive.
However licencing costs and licencing complexity of certain developer tools as well as certain products can be a huge obstacle which unfortunately is often not thought about at the beginning of projects.
I am aware of a number of projects which have chosen alternative technologies due to licencing costs and licencing complexity.
I'm currently on the Empower program but I'll be paying the full fare when it runs out
for the same reason I pay A$800/year for an AutoCAD subscription - it easily saves me more time & hassle than it costs in the long run by having everything I need at my fingertips.
I think I'm getting value for money when I consider both the licenses as well as the community - most of which I suppose is free anyway.
I consider it a legitimate cost of running my business and it's tax-deductible anyway.
I am trying to restart my career, my life, etc and my previous MSDN Universal sub expired in 2005. At the time it expired, I stopped working for a while. That coincided with Microsoft changing the cost and structure of that subscription program. To acquire a similar subscription today is out of the question. I do not have the funds. I am currently developing with old technology (VB6 and ASP) and will do so until I have the funds to purchase the MSDN sub that I want. I have downloaded the "express" versions of VS 2008 and SQL 2008 but, lets be frank, any serious developer is going to want to utilize the features that arent available in "express". In exploring this issue here on StackOverflow, I have seen others talk about the Empower program. It looks promising and I shall investigate it.
But, yes, the barrier to entry is the cost. Hopefully Empower lowers that, for a while. I agree with the requirement that after it expires I will need to pay full fare. I think thats only fair.
A while ago another question referred to the (possibly urban tale) statistic that
... the average lifespan of software is about 3 years
At the time I came up with the following reasons (and I'm sure there are more possibly better ones):
A new major system (ERP, CRM, etc.) is implemented and it has an "integrated" module to replace the old app.
Same, but no integrated app - but the existing app is not adaptable (the people left, technology has changed, current IT policies have changed, users don't like the existing app.)
The company you acquired the basic app from, to customize it for your needs has disappeared.
Or you don't get along well with them any more.
The technology for the existing app is "obsolete" (according to the framework vendor/Microsoft/consultant/industry expert/new IT manager who has management's ear.)
"We're phasing out (Windows 95/Windows 98/Windows 2000/Windows XP/NT) and we need matching technology in our apps".
"We've learned a lot from (App Version n) and we'll do a lot better the second/third/fourth/n+1th time."
Job justification for developers/IT manager/Division VP/consulting company.
The users hate it.
We've merged/acquired a competitor/been acquired by a competitor and theirs is better.
Some of these are unavoidable (e.g. your company gets bought), but overall this is surely smething that needs to be avoided. Does your organization intentionally fight this syndrome? What effective strategies would you recommend?
That's why an application needs to be easy to expand, and you should be able to easily add-in all the buzzwords.
If you have a solid base code, most of the buzzwords are related to the UI (Vista Controls, Ajax, .net, ASP.net 3.5)...
You could be running COBOL in the back-end ( I wouldn't).
A new major system is implemented - There's nothing you can do.
current IT policies have changed, - The app should be adaptable.
users don't like/hate the existing app - why? cosmetic changes in the UI can fix this most of the time.
The company you acquired the basic app from, to customize it for your needs has disappeared. - I wouldn't do that, I'd prefer to write it myself.
The technology for the existing app is "obsolete" (according to the framework vendor/Microsoft/consultant/industry expert/new IT manager who has management's ear.) - same as the above, if the back-end is solid, you should follow these in the front-end.
"We're phasing out (Windows 95/Windows 98/Windows 2000/Windows XP/NT) and we need matching technology in our apps". - a simple compatibility test and minor UI elements solve this.
I'll also say that this is different when you compare in-house to commercial apps, if you're doing an in-house app, change guarantees your job (if you know what you're doing). If you're doing a commercial app, change is an opportunity to make more money, new features would get you upgrades from existing clients and new clients who are looking for the buzzwords, these buzzword could become your advantage when compared to a competitor.
The average lifetime of software I write at the moment is probably a few days. (I write a lot of scripts, so I might be an aberration. ;-) But the core system I work with is probably 15 to 20 years old now. The underlying OS is about 30 years old. There is nothing inherently wrong with either old or young software. In fact, software ages best when it's possible to adapt it to new uses.
Having layers of abstraction between functional parts make it easier to replace functionality in a system. For instance, we've gone through several different tape libraries on our system and now we are considering going to disk archives in the future. Since the "archive" portion of our system sits behind an abstraction layer, we can replace it fairly easily without replacing the rest of the system.
When possible, it's also best to use standard parts. That way, if you run into some limitation, it's likely others will have the same problems and more likely someone will come up with a fix.
Continuous improvement - add useful features at regular intervals
No show-stopping bugs in new versions - testing, testing, testing...
be nice to your clients and treat them with respect (most users really don't want to change their ERPs every three years so if you have a good realtions with them they'll be on your side)
Stay current with new technologies and integrate them in your application when needed
When gathering requirements and someone says "Situation X will always be the case, no exceptions", make it configurable. It will always change, no exceptions.
Most companies don't make it for 5 years. Their software implementations wouldn't be expected to last as long.