Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm new with FIWARE and I'm disoriented by the large amount of information related to this platform, the amount of components called Generic Enablers that exists. I don't know where to start.
Any advice?
Thanks!
The best place to start would be the FIWARE Developer's Website - this gives you an overview as to what FIWARE is and how the various enablers fit together
Core Context Management holds the state of the system and allows other elements to subscribe to changes of state
IoT and Robots provides sensor data and transforms it into the NGSI standard interface
Processing/Analysis/Visualization provides dashboards and complex event processing
The pillar on the right - API management adds security, as well as interface to systems to publish data externally.
Deployment tools helps the instantiation of a FIWARE system easier
If you are looking for more information, the Tour Guide describes each enabler in depth and holds a series of link to Videos, User Guides, presentation and so on.
If you learn-by-doing the Tutorials will present a series of exercises to build up a "Powered by FIWARE" application - it also describes how various Generic enablers fit together. The first six tutorial concentrate on the use of the Orion Context Broker which forms the central block of FIWARE.
Basically the the NGSI v2 standard provides a common interface to allow a series of disparate building blocks to talk to each other using a common language, these are things you're probably going to need in a generic Smart application, but are not unique to your application - you would be providing the "special sauce" by either creating custom sensors sending context data into the system (i.e. the block at the bottom), or complex processing algorithms which are reading and altering the context state (i.e. the block at the top).
If you want to speed development you can buy-not-build and use the existing free open source generic enablers. The whole system is modular so its easier to experiment and add and refactor things as necessary.
In addition to Jason Fox answer,
Every year the FIWARE foundation organizes summits, that are pretty good. There are tutorials and hands on sessions, and all slides I think that are available here. It could also be a good starting point
On the other hand, most of the FIWARE software components (GEs), are available in Docker HUB. Therefore, if you feel comfortable using Docker you could set up a bunch of FIWARE GEs in a few minutes.
Finally, there is this FIWARE-IOT-Stack website, where you can find a kind of FIWARE architecture for IoT. I do not know if it's official, but in my case it was very useful.
Regards!
Related
I'm starting my studies at Fiware subject, however, I'm kinda lost, and I'd like to get some advice where to where to start, I've already read many articles about, but I'd like to star implement something (I already know docker)
If you already know docker, then the FIWARE Step-by-Step Tutorials would be a good place to start, as they demonstrate a series of simple scenarios that cover most of the open-source generic enablers found on the FIWARE Catalogue. Obviously if you want information in more depth, then the FIWARE Academy contains listing of additional materials and videos.
To start using a system in real-life, you are going to need to connect real-life IoT devices, the tutorials here should explain how to get some comms working.
Of course, it will very much depend on the problem you set yourself to solve, but the standard layered architecture will follow the same pattern as this Smart AgriFood example:
That is your devices are using some proprietary IoT protocol which is then indirectly connected to a context broker which is in turn connected to business logic and dashboards which speak NGSI. This set-up gives you total flexibility to swap in and out elements with other enablers or FIWARE Ready commercial products which speak NGSI.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I've found today in my inbox an email from google where they announce that CWS payments API is deprecated
I'm working to create a Chrome extension that I want to release with the in-app payments support to let the user purchase a license to unlock full features. I was oriented to the CWS native payments API, but Google's decision to deprecate the API is a very bad news.
At the moment I've found a nice Wordpress plugin that will manage licensing, I'm thinking of using it to create a licenses backend but I'm not sure about it because it's mainly focused to be used for wordpress themes or plugins, so to implement it on client side for an extension would require some workarounds.
How do you will manage your in app purchases and licensing for Chrome extensions or Electron apps?
Alright, so as I am in the same situation as you are, I did a little bit of research. Here is a summary of my findings and comments on the matter.
There are three things to think about before you get started with the implementation:
The type of payment processing service you want to use;
The way you want to limit features for the free version (and for multiple tiers of plans);
The security of your users information through your extension.
Let's go through each of these one at a time.
1. Type of payment processing
There are two main types of service providers that will allow you to collect payments in you extension. Payment processing platforms are the first type: they allow you to process payments and will generate receipts, but they won't manage the different taxes and regulations of different countries. If you operate solely in one country, or in a few countries where taxes and regulations are the same, this won't affect you.
However, if you have users around the world, especially in Europe, implementing the rules to handle all of the different taxes and regulations can get really complicated and messy. But you have to do it, otherwise you put yourself in a situation where you are at risk of getting fined. That is where the second type comes in: the merchants of record. These are companies that will charge the users on your behalf, removing all of the complexities of taxes and regulations from your plate. They're essentially acting as a reseller of your products. Of course, they take a small cut from your revenue to pay for the weight that they're taking off your shoulders and putting onto their own.
Payment processing platforms will be cheaper (ex.: 2.9% + 0.30$ per transaction for Stripe), while merchant of records take a bigger cut (ex.: 5% + 0.50$ for Paddle). However, if you deal internationally, the 2.1% higher price is likely more advantageous for you, just because it saves you a lot of time and development work.
It's important to note however that merchant of records are unlikely to take on a brand new project, especially for Chrome extensions. That's because the amount of revenue those extensions generate on average is pretty low, and often not really worth it for them. Still, I suggest you hit up a few of them before deciding do go the classic payment processing way, just in case you can get in touch with a salesperson who sees potential in your project and is willing to take you on.
Here are a few merchant of records:
Cleverbridge
2Checkout (offers both MoR and basic payment processing services)
Paddle (does not support new Chrome extensions at the moment)
FastSpring (does not support Chrome extensions anymore, as of 2021)
Here are a few payment processing platforms:
Stripe
Paypal (from my experience, Paypal is a lot less developer friendly than Stripe)
2. Limiting features for free or tiered plans
The way features are limited for non-paying users will differ from one extension to the other.
If the features you want to limit in your extension already rely on a backend, to fetch or process data for example, it would make sense to implement the limitations on the server side. You would simply pass the user's ID, which could be stored in chrome.storage, to each request made to the backend. In addition to that, you could also disable the related elements on the client side, such as hiding or greying out buttons, tabs or fields, to make it clear to the user that those features are locked. You'll want to make sure the limitations are in place on the backend as well however, because otherwise a user could just inspect your extension and enable premium features without paying.
If your extension mostly or only operates on the client-side, then you will have to render the interface conditionally, based on the user's plan. The scripts or interfaces that will be added will most likely have to be returned by a backend, as pretty much anything that is done only on the client-side could potentially be inspected and exploited. In that case, any backend technologies or platforms you are most familiar with can probably be used to set things up.
Keep in mind that most of the payment processing and MoR listed above have APIs and guides on how to implement them securely in apps and websites. However, if you know Wordpress well and can set up a secure communication between your Wordpress and your extension, go ahead. If you want to use an online service like Zapier to link existing authentication and licensing services together, go ahead and do that!
There could be a lot more details in this section - there is a ton of material to cover, so I suggest you look for articles and tutorials online to help guide you in this process if you don't have much experience in the matter.
3. Security
This section won't be long, but it is very important one. No matter which payment processing platform you decide on or how you limit access to features in your extension, it is crucial that you make sure that your users information can never fall into the hands of another user. That includes reverse engineering and exploits of your system.
The more things you decide to handle yourself, the more risk there is, especially if you are not experienced. Keep that in mind when making your decision(s).
That's all for me. I hope that helps a bit!
I know it's probably a lot of information without any detailed "how-to", but without having in-depth knowledge of your product and situation, it is impossible to say what you should do exactly.
P.S.
If that can offer any guidance, here's what I will be doing for my own extension. Seeing as it's already very reliant on a PHP backend, I will add a few features to the backend in order to communicate with the Paddle API. So all of the limitations will be implemented on the backend, and I will add messages and visual indicators on the frontend to inform the free users of what they can and cannot do.
[Edit]
I just received a message from Paddle indicating that they do not support new Chrome extensions at the moment. Sorry for the misleading there.
[Edit: June 2021]
After an update earlier this year, FastSpring has updated their security standards, which makes it unusable within Chrome extensions. After I enquired, their support agents informed me that they do not support Chrome extensions anymore (and that it was only "accidentally" supported before).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Looking for an issue tracker for a medium-sized web application open project with a distributed team. We are planning to run this on our own server. It must be very easy for new users to submit new issues, and it must integrate well with other software.
Our major requirements, in descending order of importance:
open source
capable of very new-user-friendly bug submit
submitting new issue must be as easy as possible, with only a single screen to fill out (after registration), and few fields visible (e.g. just "summary" and "description" would be good)
Google Code is an example of the sort of interface we like; Bugzilla's Bugzilla instance (https://bugzilla.mozilla.org/enter_bug.cgi) is an example of the sort of new bug submit interface that we would NOT like
it's fine if the default submit interface is not new-user-friendly as long as this is easily modifiable using templates/skins. It would be great to have an "advanced view" for bug editing with additional fields (such as who the issue is assigned to), in addition to the simple view for new user bug submission
has API; or, supports other applications concurrently accessing its db backend (we want to query and modify the issues from other, separate software running on another server)
Other desirable criteria, in descending order of importance:
not frustrating in daily use
has a relatively large community
integrates well with hg (mercurial)
amenable to integration with external:
support desk/request tracking software
project management software
auth systems (and/or supports OpenID login)
modular; if we modify the issue tracker, we want to release those improvements as a module that is easy for others to install
amenable to having some sort of simple, easy-to-use issue importance voting system, e.g. stars on Google code; we intend create or modify such a component to plugin to our own external voting system
amenable to integration with SugarCRM
When I say "amenable to", I mean that we are willing to code an extension to the issue tracker ourselves if necessary, however, the issue tracker's architecture should be amenable to that sort of extension.
Issue trackers which also include support desk or project management features are a plus provided that we can choose to integrate external software instead of using the included stuff. We don't need another wiki (we already have one that we like).
According to Google searches (see the comments), the most popular open source issue trackers are trac, bugzilla, mantis, RT (and possibly Launchpad's). I've also included Redmine because I've never seen a recent comparison between any of these issue trackers and Redmine in which someone had something bad to say about Redmine, and on polls Redmine sometimes beats these others. Feel free to suggest others (bearing in mind that one of the criteria is "relatively large community").
There are undoubtedly multiple good issue trackers out there; many of those listed above claim to be extensible and integrable with other software. What would be most helpful would be direct comparisons between issue trackers by people who have used more than one.
How do these compare to each other on extensibility, integratability, and skinnability?
If you have used more than one of these, which of them would you recommend, and which others have you used?
Which of these are already integrated with a large number of auth systems/support desk systems/etc?
Comments explaining why a particular popular open-source issue tracker (especially one of those listed above) is NOT suitable for our situation are very welcome; this will save me time.
thanks!
Redmine. Been using for a while. Simply excellent.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have been writing software for several decades now and these days everything is web.
Before the web we had Client Server apps that were basically thick client applications that spoke directly to the database. They had some disadvantages, such as deployment was cumbersome, Did not scale because DB handled all traffic. Of course back then distribution of apps was limited to being on a desktop on a corporate network. The benefits to these apps were that they had fewer layers and were quick to develop.
There are times when the requirements call for an app behind a firewall with a dedicated database and a relatively small amount of clients. I suggest (sometimes on StackOverflow) the old Client/Server type architecture and everybody looks at me like I have 3 legs and 6 arms.
With modern technologies that allow automatic deployments of apps and the tools we have today. Is there a reason this technology is not viable ? Is it that the new generation of developers only know web stuff ?
I can think of at least two large-ish markets where client-server is still big:
Online games and virtual worlds, such as Battlefield or Second Life. Usually you need a thick client plus a connection to a shared server.
Custom-made scientific software. Complex technical or scientific software, especially if it needs an interactive graphical UI that does direct manipulation, is sometimes written in this fashion too.
I'm sure thick clients are still being developed, even today.
Having said that, choosing a web-based architecture is not about the "new generation of developers" only knowing web stuff, you do get a lot of advantages if you can make your application web-based:
Deployment is dead simple. Even with things like ClickOnce, automatic updates, etc, nothing beats simply refreshing the page to get the latest version
You can use something like Silverlight to get 99% of the benefits of a desktop application (in terms of the ability to run code on the client)
Web applications can be made available remotely much more easily than desktop applications (a lot of companies have remote workers these days, setting up a VPN is a pain if all you want to do is access payroll (or whatever))
But at the end of the day, it's all about the right tool for the job. Web applications don't help when you want to write plugins for Office (Word, Outlook, etc), they don't help if you have to control custom hardware (POS terminals, etc - although you could write that into the server in some cases...), and probably a few more cases as well.
We have some Flex apps that communicate with XML based web services that are pretty close to old school Client Server apps. But rather than using SQL, they speak a custom XML language and render SOAP responses.
We currently develop and deploy numerous client/server applications annually. The development is simple and automated. We are not limited to the database technologies we are able to deploy. Client/server deployments are faster for calculations, form updates and reporting. The Web/Cloud based applications are less responsive than an application running on a client station (thick client).
This is because of the distribution of cpu load. Whereas a server side application requires the server to perform all calculations the client side can run this on the local machine. As any system gets more complex the moments that a user has to wait for results increases. These moments of employee time are more expensive as they involve more of the paid employees. These moments add up within an organization as a great many "man hours" over a year.
The problems with updates are solved within our development tool set. Just as when you may open your favorite browser it notices that the version you are using is not the most recent we embed that same process within our client/server applications. In fact we don't give them a choice to update. Since updates may, many times, require database changes we force the update to happen before the user is allowed to run the software.
To improve visibility of the information contained with our custom client/server systems we offer custom developed web sites that have specific applications such as field dispatch or customer support forum integration into the desktop client/server applications. From my perspective I see a complete integration of client server and responsive web applications taking a better position in the years to come.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Assuming you have been involved in an open source project (GPL'ed) that has been around for as long as 5-10 years, during this time it has been fairly successful - despite a good handful of commercial/proprietary alternatives.
Now, you've come to realize that the long term contributors would like to leverage the project commercially, possibly even in order to make a living or start a company based on it. So that they can exclusively work on it, without depending on other, unrelated, work.
So, what are some of the viable and recommended steps to turn an open source/GPL project into a commercial "success" (in the sense of self-sufficiency), so that long term contributors may preferably be paid to work on the project, without affecting the open source nature of the project itself?
In other words, what are generally some of the more common revenue-creating mechanisms for open source software, and how can these be successfully introduced/implemented - also, what prerequisites/conditions apply?
I saw a company a few years back that took a handful of OSS spam and virus filters, built a web interface to administer them all at once, put it on a 1U server, and sold it as a network security appliance.
It was a nice product for mid sized companies that wanted a single solution for all spam and virus filtering, that auto-updated itself and was easy to administer.
Technically they were just selling the server, and the web admin tool, all the OSS components were freely available, if you wanted to spend the time setting them all up individually.
You should think in terms of the "product halo," which refers to all of the related items and services surrounding a product that are not the product itself. For example, MySQL is open source and freely downloadable, but its product halo could include services like installation, customization, consulting, training, etc. Or Zend contributes heavily to PHP and offers Zend framework, but they also have a number of commercial products surrounding those offerings. Active State creates the Komodo IDE and has an open source version and then a commercial version that extends the open source version. Or take Linux...or any other number of examples. A book that you might find interesting on the topic is Wikinomics.
I think the main issue is the business model adopted by the project owners and the ones who want to turn it into revenue. It will depen on what kind of project is it, such as end-user product or as software API. In the case of end-user projects, Software as a Service seems a very good choice as a business model.
Look out for examples, and case studies on successful projects, such as apache, firefox, sugarCRM...
Focusing on specific niches is also a very important thing.