What is a good naming conventention for web role-, worker role- (and vm role) projects in Visual Studio( 2010) ?
(edit):
And what about the deploy ? The name of the web role will affect your deployed app named in the Cloud....
I don't think it matters a lot. Number of roles in the project is usually very small. Oftentimes, the web and vm roles maybe user-visible via URL's, (blahblah.cloudapp.net). So I would name them by functionality and ease of reading and not prefix them or post-fix them with a special "worker", or "web", or "vm" keywords, as you are probably thinking.
Its entirely arbiratry(sp). And unless you're adding a degree of automated monitoring and management doesn't have any significant impact.
My personal preferrence is to name them appropriately based on the unit of work, following whatever naming convention is appropriate for your shop.
The bigger question is the management of services and subscriptions, which gets a bit more complex.
I'd suffix them with ".Web" or ".Worker". Visual Studio does something similar with Silverlight projects, if you let VS generate your Silverlight host app.
Related
I have some experience developing in the xs classical apps in the SAP Cloud platform neo evironment. And plan to migrate to xsadvanced in the cloud foundary landscape. I have a few fundamental doubts which sadly i could not get answers to even after reading the documentation.
If i understand correctly XSA is cloud foundary extented by SAP to support SAP HANA 2.0 as a service via the HDI Container, allowing the tradional xsjs to run as a node.js container and bunch of other SAP specefic serivces ?
the MTA (mutlti target application) development promoted by SAP looks neat however i have a few questions when it comes to working in a env where multiple developers work with the same MTA in the "dev" space for example.
the typical MTA is combined of a web module where the UI part resides , node module to hold the services and a db module that is the entire HDI container which holds tables,views and the actual data .
the developers dont work with WebIde and use VSS code and cf CLI.
Question 1 : if i want each developer to have an isolated MTA when developing , then each developer must push the same MTA app with a different name when he works with works for some feature development ? (preferably some feature brach that gets pushed as a new app) . every line of code change then needs a push to CF
Question 2: Pushing the app with the same schema name in MTA file creates a new schema for the second developer in the same HDI cointainer (i am not sure if this correct however this what i understand from : here
But the second schema will remain empty and many not contain data, do we then take care about data replication from schema 1 to schema 2. wont this explode the space usage ?
As i said, i did not find documentation about how multiple developers can work on the same MTA app in the shared space so any guidance will help
thank you
Multiple developers are able to work on the same MTA app, because of git functionality and different workspaces dedicated for each developer. More to that, you can even personally have even more that one workspace, which means you can have different features developed by yourself separately.
When you build your container or run your application in your space, each time get a unique schema name or application url, this means you can work independently.
A bit tricky part is when you want to join your commited code with other developers. Basically, it depends of how big your project is. If you have a large project, it's better to control merges using Code Review and Unit tests, or maybe you are in a small project and work on different files, which means you can merge your code easily to master branch by yourself.
Many software development teams use the term production to refer to the live environment accessed by their users. Rails for example uses this nomenclature. The string production is also used by express.
The dictionary definition of production however doesn't seem to easily lend its self to this usage. Is there an alternate definition I'm missing, or did some earlier project establish this standard?
In a factory, the "production line" is where the actual product is made (or you could say "the goods are produced")
Hence "production" is "where we make the thing we sell to the user". Move that idea to comapnies where the thing being sold is a service and the principle holds...
We have a Visual Studio solution that comprises multiple production and test projects. The solution uses several web services.
The way things are organized at the moment, each project that needs access to a web service has a "Service Reference" for that web service added to it. This means that there are multiple (usually only two) references to every web service: one in the production code, one in the test code.
However, we are finding a problem: when the other web-services get updated, we often forget to update ALL the service references to them (usually in the test projects that use them).
Someone suggested that we add a new project to the solution that contains ALL the service references and that NO OTHER project should have a service reference included.
Are there any "gotchas" with this proposed approach?
Is it a good idea? And why (not)?
We use the same approach as well, however there's a very inconvenient gotcha - you can't have multiple service-references from the same application.
So we ended up having to create the service-references manually using the svcutil, but other than that, we're pretty happy with the change.
I have several Visual Studio Extensions (VSX) that I need to communicate with each other. (For instance activate features, share saved files, access project items from one to another.) I could utilize the registry but I have a very bad feeling about that. I was thinking of a commonly placed XML file but I'm afraid of not having the proper permissions to access it. Could you help me find the best practice for sharing data between (live) extensions?
I would store the information somewhere under %LOCALAPPDATA%. Both extensions would have access to it and it is per-user (it evaluates to something like C:\users\[username]\AppData\Local).
From this SO question, you can use the following to get a reference to this path:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
General way of making two extensions to talk is by offering services. Packages offer and consume services.
Take a look at this
This is very similar to Where should cross-platform apps keep their data?, but expanding on it a bit.
There is some good advice on where the parent directory for data should be, but not so much on what a given app's directory should be.
For example, let's say we have a cross-platform application, written by My Corp, within My Brand, called My App. Assume there are other products in My Brand which presumably want their own data, and other brands in My Corp as well. Where should its data and/or configuration go on Windows? On Unix? Mac OS9? Mac OSX? Other?
e.g., on Windows, would the data go in "...\Application Data\My Corp\My Brand\My App", while on Mac OS X the data would go into ~/Library/Application Support/My Corp/My Brand/My App" and on Unix it would go into "~/.mycorp/mybrand/myapp"? (I would imagine other platforms would use the mangling of unix, even if the base directory may be different.)
If there is no real convention, does this seem reasonable? Any suggestions for Mac OS9?
Just to start the reflection:
You have to make a clear difference between:
application state data
settings
data (can be common for several applications)
The latter may eventually be in a database, or could be managed by one or several applications, or encapsulated by a communication bus in order to avoid all the other applications to dialog between themselves to access those data.
The data representing the state of an application can go in 'Application Data' as mentioned in the question "where cross-platform apps keep their data ?".
But the settings... It depends if you application need to be launched with several "configurations":
one for each platform: in case you must manage them in the development stage, and package that file in the release stage, in order to store it in 'Application Data'
many for one platform, like with different Heap sizes, or different settings representing different operations to be executed by your same app. And that leads to an explosion of setting files (also stored in various sub-directory of 'Application Data')
That is where the idea of abstracting those data into a Setting Provider is a good idea.
Actually, we have so many different configurations for our settings we store them into a database on a separate production machine. That way all the apps can access them, but more importantly, we can access and change them in real time, without having to stop / restart the applications for each modification, or without having to go to each deployment platform.