From this article:
Notice that all XML nodes in the document are converted to standard PowerShell properties, whether a node has children (e.g. catalog) or is a leaf node (e.g. price), or whether a leaf node is an element (e.g. author) or an attribute (e.g. id). In particular (as the last two examples above illustrate), element values and attribute values are treated exactly the same with standard “dot” notation.
This sill also help us suck work with DataSets, converting them to XML and then accessing the data as properties.
Thursday, January 16, 2014
Tuesday, January 14, 2014
Microsoft encourages bad developer practices
Look at this: http://sdt.bz/content/article.aspx?ArticleID=65362&page=1
“To give you a concrete scenario or example, let’s assume that you’re working on building an Azure website during the day, and you go home in the evening and suddenly the one thing that was bugging you about your website you want to go fix, and you suddenly know in your head, ‘Hey, these are three lines of code that I need to go add to make it work the way I want it to make it work.’ You can fire up a browser, use Visual Studio Online, get access to the source code, which is stored in Visual Studio Online, and then be able to edit your project with those three lines of change that you want to make, and boom, you are there. And you can deploy using Visual Studio Online right from there.”
What could go wrong? The developer fixes the issue and introduces three more, without integrating with other developers, testing, etc. deploys the stuff from his Visual Studio Online to production, breaking the site.
Why is Microsoft investing into the tools for deployment from the Visual Studio? They only encourage bad coding practices... This ability should be removed from the Visual Studio, instead we should be only deploy from the drop folder, after the code is integrated and built, all tests passed and the code is certified to be ready for prod. Instead of building tools to deploy from the Visual Studio Microsoft should make it easy to build deployment pipeline.
“To give you a concrete scenario or example, let’s assume that you’re working on building an Azure website during the day, and you go home in the evening and suddenly the one thing that was bugging you about your website you want to go fix, and you suddenly know in your head, ‘Hey, these are three lines of code that I need to go add to make it work the way I want it to make it work.’ You can fire up a browser, use Visual Studio Online, get access to the source code, which is stored in Visual Studio Online, and then be able to edit your project with those three lines of change that you want to make, and boom, you are there. And you can deploy using Visual Studio Online right from there.”
What could go wrong? The developer fixes the issue and introduces three more, without integrating with other developers, testing, etc. deploys the stuff from his Visual Studio Online to production, breaking the site.
Why is Microsoft investing into the tools for deployment from the Visual Studio? They only encourage bad coding practices... This ability should be removed from the Visual Studio, instead we should be only deploy from the drop folder, after the code is integrated and built, all tests passed and the code is certified to be ready for prod. Instead of building tools to deploy from the Visual Studio Microsoft should make it easy to build deployment pipeline.
Subscribe to:
Posts (Atom)