I would like to ship some new features just for a specific group of users to better test it in production and then release it progressively to everyone, should i put IFs in my code and assign specific policies to users in the database?
Is there a better way to do it?
The normal way to handle this is have two versions of your software. The "main" version is the one most people are on, but you also release an "experimental" version which has the new features.
There are various ways to manage the software, but you should look to use strong version management practices in your source code repository, perhaps using some good branching techniques. You should avoid the two versions from diverging too much.
You can choose to invite certain users to the "experimental" version, or have them opt in but give the necessary caveats that things might not work as well, and if you have any SLAs then you might want to caveat them. If you are hoping users will provide you with feedback then make sure there is a good mechanism for that and that the users are aware of it.
If you have client software then uses will need to get hold of the new version themselves. If your software is purely server side (eg a web application or SAAS platform) then you might look at a routing layer eg in the load balancer which automatically sends users to the normal or experimental version depending on whether they are part of the relevant group.
This is a common scenario in software and you should be able to do some good research. I suggest you start by looking into A/B testing.
Related
I am in the process of creating a payment gateway for drupal / wordpress / magento. I already have clients who want to use my plugin. Because this is a paid piece of work, I want to protect it from being used on other websites.
I have also seen that many vendors who sell themes, modules and plugins are required to put in the API key.
How can I do the same. What do I need on my server side. I know how to create modules, but I don't know to sell them securely and deliver regular updates.
If there is a book regarding this please let me know.
I'm not familiar with any books on the subject, but I'll tell you what I've seen as one of a founders of a component / plug-in marketplace that has many such plug-ins.
There are a few approaches -
Some plugins do not require an API key at all. Either the plug-in is only available after purchase, or has some limitations on the free downloadable version that encourages people to pay for the commercial version. This approach relies more on people's integrity and low motivation to try and hack the free version into the commercial one, especially if they are not technical users (as many CMS users are).
Set up a check against your server that happens periodically. You do not need a full blown API for this, just set up an endpoint on your server that the plug-in can send the API key and according to the response allows the use of the plug-in. You need to plan it so that this check doesn't happen every time the plug-in is run, especially if it a plug-in that runs on the public site and not only in the administration panel - it will seriously degrade the performance of the site using it and create unnecessary load on your server. Use some kind of time based checked - either absolutely or from the time of the last check.
In addition to or instead of doing an API check, some people will obfuscate their code to make it harder to modify and bypass the check. This often requires that the server has a module installed that can parse the obfuscated files - this requirement often makes it less viable for most people. You can see some examples of obfuscators in another question.
Personally, I lean more toward the first option, as someone determined enough will break whatever protection you put (people break much more complicated solutions in no time). This is one of the problems of delivering source-code instead of binaries (and those are broken just as easily by more experienced hackers). Let those who are willing pay, and the others just let them do what they want as you won't be able to create something truly secure anyway.
I'm working for a company where I develop systems purely for internal use. There are only a few developers but we use redmine for issue tracking & feature requests. However, the only people with access to the issue tracker are team leaders, everyone else is meant to feed their suggestions through their team leader.
The idea is that this will reduce developer workload and give management more control over the features being developed. The reality is that we get emails sent directly to us from people experiencing small bugs, or feature requests.
Is this a sane way to manage user feedback or a known bad practice? I've not seen any articles which discuss managing internal issue tracking, so thought I'd ask you.
You can allow your users to access Redmine and create them a special role where they can only create new issues with a new status then the project managers or the team leaders can priorize the issues and assign them to the right people.
It will imply that your users have to be trained to use the tool to create efficient reports and search before creating a new one. But if it's an internal project it will be "easier" because you can train everybody.
It sounds sane to me. If you have end-users giving you feedback then that's a good thing. I've no experience with redmine but if there's a learning-curve associated with it then end-users may be reluctant to bother giving feedback at all. Also, you may end up with defect targets such as 'it has to triaged with X days, and fixed by Y days'. By having such an informal feedback process you avoid this. Also, your team could take a somewhat Agile approach and write bugs/feature requests onto scorecards and stick them on a wall so everybody can see them, including managers - who get to see how end-users are really using your product, and choose to fix/implement them as your team sees fit, with the priority that you choose yourselves.
Of course, your source control system will have the history of all fixes and new features!
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
I am about to write a tender. The solution might be a PHP based CMS. Later I might want to integrate an ASP.NET framework and make it look like one site.
What features would make this relatively easy.
Would OpenId and similar make a difference?
In the PHP world Joomla is supposed to be more integrative than Druapal. What are the important differences here?
Are there spesific frameworks in ASP.NET, Python or Ruby that are more open to integration than others?
The most important thing is going to be putting as much of the look-and-feel in a format that can be shared by any platforms. That means you should develop a standard set of CSS files and (X)HTML files which can be imported (or directly presented) in any of those platform options. Think about it as writing a dynamic library that can be loaded by different programs.
Using OpenID for authentication, if all of your platform options support it, would be nice, but remember that each platform is going to require additional user metadata be stored for each user (preferences, last login, permissions/roles, etc) which you'll still have to wrangle between them. OpenID only solves the authentication problem, not the authorization or preferences problems.
Lastly, since there are so many options, I would stick to cross-platform solutions. That will leave you the most options going forward. There's no compelling advantage IMHO to using ASP.NET if there's a chance you may one day integrate with other systems or move to another system.
I think that most important thing is to choose the right server. The server needs to have adequate modules. Apache would be good choice as it supports all that you want, including mod_aspnet (which I didn't test, but many people say it works).
If you think asp.net integration is certanly going to come, I would choose Windows as OS as it will certanly be easier.
You could also install reverse proxy that would decide which server to render content based on request - if user request aspx page, proxy will connect to the IIS and windoze page, if it asks for php it can connect to other server. The problem with this approach is shared memory & state, which could be solved with carefull design to support this - like shared database holding all state information and model data....
OpenID doesn't make a difference - there are libs for any framework you choose.
You have a good software product, so why would you make it SOA compatible?
You may want to do this to provide a looser coupling between your data services and your application layer. This will give more flexibility to reuse the service components for other products and allow you to change the underlying service architecture if need be without the need for your application to even know about the change.
Having said all that, I would first want to have an actual business use case that warrants making the switch before making the change. Changing simply to keep up with the latest buzzwords is just a waste of money. If you're starting a new project, however, you may want to consider a service-based architecture if it makes sense for your application.
In my opinion, only one good reason: you need interoperability between different platforms or technologies. Otherwise, save yourself a lot of grief and "just" make a well-mudlarized architecture - tell your boss it is SOA if that's what he wants to hear. Don't do it because you might move to or use other platforms in the future - you don't have an interoperability problem yet.
If you want your product to be integratable with other applications and your customers have actually voiced this wish / requirement then I would consider it, but otherwise it might be a big waste of time and money, especially if doing it might cause some lengthly architectural refactoring to make it work. But with no clear reason, it probably doesn't make sense to follow a trend just because others maybe doing it. Your customers will let you know when this is necessary.
That's a very difficult question to answer without more detail about your "good software product", but speaking in sweeping generalities:
If you implement an SOA scheme on your product, more developers will be able to consume the API services provided by your product because web services work across almost any development platform.
If your product is already a web application that publishes certain data, you might discover that you have readers/consumers of your data that are interested in doing analysis or building additional applications that you never thought of or may not ever have the available time to build.
The fact is: you don't need to.
SOA structure is very complicated to achieve. It requires care and organization style that I believe most companies will not have. (I'm glad if yours has such organization).
Tomas Erls talks about Contemporary SOA and Web Service First Generation. WS-I is the traditional web service style such as asp.net web services. Actually this traditional web services doesn't mean any service oriented; And what happens is people build simple web services and call them SOA.
Contemporary SOA, I believe, is an entire system structured based on services. Inside this "ecosystem", services would call each other to perform some tasks.
SOA analysis is painful and you need care. To build an ecosystem like that, you need to be prepared from the first moment.
Engineering service interfaces (contracts) is also paradigm. If you put some Lean Thinking at your belt, you should cut some desire to make state-of-art design.
If your system already works, fine! If someone will need integration in possible future which you don't know yet about it, don't do it now. But if your system is born to be consumed, them you think about it.
Best