We are just trying the new Team Foundation Service and we want to migrate our data to it.
In our old (local server) installation of TFS2010 we have several collections. But we can't find a way to add collections in the Service interface.
Is there a possibility to do so?
This is not currently possible in Team Foundation Service.
There is a request for this feature in UserVoice. Go and vote on it to help it get prioritised.
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3473653-let-us-create-multiple-collections-on-team-foundat
Related
I am coming from a background in Web Development. Have had some classes in MS access about 3 years ago. Currently I am working on a project primarily built using Access. Eventually the program will be expanded to interface with the same database that Access uses in the cloud. Which will then lead to development on a web project.
My question is its 2017 and I am aware that you can make web calls in Access , but just because I can doesn't mean I should right ? My client/boss would like to implement a credit card processing payment system into his Access application. However I am pushing for this to be something built from the web development side project that will take place later using an API. Any Access developers out there able to suggest whether its a good idea to wait to build this feature later when development has begun on the web project ? Is it okay or secure to make web calls using Access ? Or is there any alternatives to an existing merchant service that can interface with Access ? Any advice on this topic would be greatly appreciated. Thanks in advance.
Access (VBA) has COM support, and makes heavy use of it. Any existing merchanting solution that works with COM can work with Access.
If your desired merchant solution doesn't, you can create COM classes and libraries in C#, C++, VB.Net and probably some more programming languages.
If it's a good idea? That heavily depends on your demands. I don't know what the advantage of an Access database over a program is for you.
Note that if you're using ASP.Net for your web solution, you might use a common class to check and authorize payments, and you might want to develop both simultaneously.
I am looking for way to create simple multiuser Dashboard for OpenStack as alternative to Horizon. Idea is keep Horizon for administrators and manage users in another aplication with possibility to create (with admin confirmation) custom system.
My idea is create a web aplication (Node.js) which would communicate with OpenStack REST API because we need some extra feature (messaging, LDAP/AC Auth).
I also looked for some projects like alternative to Horizon, but cant find anything .
My question is, what is better idea? Create custom solution or use some already created Dashboard(which one?) and only modify it?
Take a look at this open source project:
https://github.com/cyverse/atmosphere
https://github.com/cyverse/troposphere
So its frontend is based on ReactJS and BackboneJS and the backend is the Django and DRF which consumes the OS python client API.
As for your question, it depends. The horizon project has a very good plugin registration service that let you easily create custom dashboards and you don't have to worry about many other details.
However, create a new dashboard on your own also sounds cool but it needs a lot more effort and time than using the horizon.
HTH
We are migrating from WebSphere BPM 8.0.1.3 to 8.5.6, our plan is to move application by application rather than in a big-bang. The idea would be that when we move an application to the new server, we would create an IHS rule which redirects the related URLs to the new server. That would mean that we keep some applications running on the old server while some are already migrated to the new one.
Is this possible to achieve? Or any other idea alternate to re writing IHS rules? Like make use of WebServer plugins?
Unfortunately, I don't think that your current approach is going to work well for you. I've outlined the various options for IBM BPM upgrades here. I see several major problems with your approach, all of which come down to the fact that many of the URLs used by IBM BPM contain no details about the context for the request.
The first issue I see IBM uses a portal for a given user's work. That is all their tasks across the various BPM solutions will appear in the same web UI. This URL is not different across the Process Applications in the install. This means that all your users are trying to get their task list by going to a url like - https://mybpmserver/portal. There isn't a way to understand the process app a given user may be working with in this context, so you don't know who to redirect to the new server.
The second issue is that users are able to work with multiple process apps, so even if the context was known in the above url, you would enter complexities with respect to users working in 2 different process apps unless both have been migrated.
The third issue is that BPM is essentially a state engine. IBM does not supply a way to "migrate" that state from an old install to a new install on a per Process App (PA) basis, you have to migrate all or none. Assuming "none" because it feels like you want to follow the drain approach in my article, then you have the problem that the URLs for executing a task do not have the PA context and therefore you won't know which server to direct which task to. That is for a given PA you will have tasks on both the old server which existed before the upgrade, and the new server which were created after the upgrade, but the URLs for these tasks will look essentially the same.
There are additional issues, but the main one comes down to properly understanding how the run time BPM engines work. Some of the above issues may be mitigated if you have a separate UI layer for presenting the tasks the users (my company make a portal replacement that can do this) which would permit it to understand the context of the tasks, but if you have this, then you can get the correct behavior in that code and not worry about WAS configuration settings.
You could use the plugin-cfg.xml merge tool on the two generated plugin-cfg.xml's. That way the WAS Plugin would always know which server had which applications.
I want my application to be in 2 phases. 1 part will simply fetch data in json format from an API and store it to a SQL database(or maybe a NO-SQL) and the other half(the web part) will read the data and implement customize alerts. So, basically i need to create a worker for the fetch process. But I'm confused between worker role and web role in Azure. Kindly help me what's the best possible way to implement this design?
You can just merge both in the same web role - the part of code running in IIS (the ASP.NET project created when you create a web role from a Visual Studio template) will handle web requests and the part running the "role entry point" will run the fetch process. Unless you absolutely need to scale them separately this will give you a simpler and more manageable solution.
Have you looked at this tutorial? It gives possible use cases and tutorials for both web and worker roles.
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-dotnet-multi-tier-app-storage-1-overview/
I want to develop back-end of iphone app using recess for services layer component. This app will also have web app using same services layer component. I want to develop wep app using some CMS(Drupal) . I m confuse about databases . Since services layer will have its own database and drupal will have its own. But it is never a good idea to use two databases for same application.
Kindly suggest alternatives.
Thanks in advance
Recess allows you to specify which database server to connect to. To accomplish your goal of a shared database, configure Recess to use the same database as Drupal. I recommend at least using a different user account to store your Recess data. That will still allow you to merge/migrate data down the road, should you need it. (Although to me, that sounds highly unlikely.)
Alternatively, consider Recess and Drupal to be different applications, which they are.