Interesting argument! I personally do not like XML as a serialisation format since it's verbose and JSON (or YAML) is better suited.
I agree that config files can be a challenge to edit, especially once they get big but they can be changed with tools automatically if required e.g. PowerShell. How would you edit the build process if necessary based on some input parameters? It's hard to automate and change the config of a GUI application automatically.
TeamCity does look interesting and I know of other development shops that use it an prefer it over CruiseControl, which because it was the first to market (in terms of passing the tipping point) has unfortunately stuck around and people are not looking further than what they can see.
Ahh, XML, yes. The reason I never got round to using CruiseControl.net, because I just did not want to spend the time to dig through the config file (to be fair, they have a commercial tool called Cruise that has a proper Editor, so it's fair game).
I like the "XML" that XAML is, although it's arguable if that still is 'pure' XML, and I think the XML that MSBuild uses is straight-forward aswell.
XML starts to get messy somewhere around nesting 4 levels deep, but it is not that bad really. But still, it's inefficient for "simple" things like CI or Build. Those tasks should be simple to set up, because in the end they are simple and standardized tasks.
Small correction: CruiseControl.NET does not require you edit XML. My team uses it, and there's a visual tool called Cruise Control Config that lets you visually edit your build settings. (That said, it's a half-baked tool; requires the mouse to use - no keyboard shortcuts - and has some bugs.)
if a tool is the best in what it really does, staying away from it just because it has configuration in XML is over the top. its like cutting off your nose to spite your face. And XML is just text so if its a problem, you can automate the creation of that XML, write some script to convert your SANECONFIG -> PRODUCTS_XML and back again. Also if you really want to stay away from XML, then no more XHTML either. no web development allowed!!
JSON is a tool for donkeys. Forget also grammar, syntax, lexical. Forget that you are an human. Learn WhorePress, JumboMia, BitchObject then make software for airplanes, banking, insurance.
I think there's a fine line to be ridden here from a cost/benefit perspective. How often are you really touching any of that XML? Once a CI build is set up in CC.NET, for example, you really don't need to do anything beyond just letting it run. Same thing with getting things running in your NAnt, MSBuild, or other scripts - once they're set up, they're pretty well no-touch unless you're doing some pretty major structural changes. If the XML is too big or complicated, maybe it's time to look at why it's so complicated - just like you would with any other area in your system.
I use MSBuild for the master build script in our system and it rarely has to be modified. It's simple, we use a convention-over-configuration approach, and all that equals easy maintenance. That said, I also use TeamCity and it's well worth the price of admission. Gotta find that balance.
Visually editing configs suxx even more than xml... you should be able to work on good old plain text files, where you can easily automate and change stuff without loading up a huge editor...
I must admit, I find the content of this post to be counter productive itself... In full agreement, XML blows, and the reasons are plentiful. Yet, instead of chastising, and standing up on a soap box shouting belittling statements, why not provide what and how people can move away from xml configs in a CI environment. That woudl have been productive. You did mention TeamCity, and I am a TeamCity junkie, but I have yet been able to get "all" the build metrics that are important to me out of it in a stand alone scenario. MSBuild or Nant are required if you want to be thorough in your automation. TeamCity v5 (darjeeling) has brought things closer with the incorporation of NCover and PartCover intergration, yet, this straps you to a specific CI server... I have to admit, I feel the XML actually allows you to be more lean and flexible in your dev environments. What are your thoughts?
Mr. Madison, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul.
Reader Comments (11)
Interesting argument! I personally do not like XML as a serialisation format since it's verbose and JSON (or YAML) is better suited.
I agree that config files can be a challenge to edit, especially once they get big but they can be changed with tools automatically if required e.g. PowerShell. How would you edit the build process if necessary based on some input parameters? It's hard to automate and change the config of a GUI application automatically.
TeamCity does look interesting and I know of other development shops that use it an prefer it over CruiseControl, which because it was the first to market (in terms of passing the tipping point) has unfortunately stuck around and people are not looking further than what they can see.
Ahh, XML, yes. The reason I never got round to using CruiseControl.net, because I just did not want to spend the time to dig through the config file (to be fair, they have a commercial tool called Cruise that has a proper Editor, so it's fair game).
I like the "XML" that XAML is, although it's arguable if that still is 'pure' XML, and I think the XML that MSBuild uses is straight-forward aswell.
XML starts to get messy somewhere around nesting 4 levels deep, but it is not that bad really. But still, it's inefficient for "simple" things like CI or Build. Those tasks should be simple to set up, because in the end they are simple and standardized tasks.
Small correction: CruiseControl.NET does not require you edit XML. My team uses it, and there's a visual tool called Cruise Control Config that lets you visually edit your build settings. (That said, it's a half-baked tool; requires the mouse to use - no keyboard shortcuts - and has some bugs.)
Aside from that, great post, Roy!
if a tool is the best in what it really does, staying away from it just because it has configuration in XML is over the top. its like cutting off your nose to spite your face. And XML is just text so if its a problem, you can automate the creation of that XML, write some script to convert your SANECONFIG -> PRODUCTS_XML and back again.
Also if you really want to stay away from XML, then no more XHTML either. no web development allowed!!
JSON is a tool for donkeys. Forget also grammar, syntax, lexical. Forget that you are an human. Learn WhorePress, JumboMia, BitchObject then make software for airplanes, banking, insurance.
I think there's a fine line to be ridden here from a cost/benefit perspective. How often are you really touching any of that XML? Once a CI build is set up in CC.NET, for example, you really don't need to do anything beyond just letting it run. Same thing with getting things running in your NAnt, MSBuild, or other scripts - once they're set up, they're pretty well no-touch unless you're doing some pretty major structural changes. If the XML is too big or complicated, maybe it's time to look at why it's so complicated - just like you would with any other area in your system.
I use MSBuild for the master build script in our system and it rarely has to be modified. It's simple, we use a convention-over-configuration approach, and all that equals easy maintenance. That said, I also use TeamCity and it's well worth the price of admission. Gotta find that balance.
Stop beings such a dumb-ass, Roy!
(I won't explain or give you a justification for my opinion. Just stop being a dumb-ass.)
Visually editing configs suxx even more than xml... you should be able to work on good old plain text files, where you can easily automate and change stuff without loading up a huge editor...
I must admit, I find the content of this post to be counter productive itself...
In full agreement, XML blows, and the reasons are plentiful.
Yet, instead of chastising, and standing up on a soap box shouting belittling statements, why not provide what and how people can move away from xml configs in a CI environment. That woudl have been productive. You did mention TeamCity, and I am a TeamCity junkie, but I have yet been able to get "all" the build metrics that are important to me out of it in a stand alone scenario. MSBuild or Nant are required if you want to be thorough in your automation. TeamCity v5 (darjeeling) has brought things closer with the incorporation of NCover and PartCover intergration, yet, this straps you to a specific CI server... I have to admit, I feel the XML actually allows you to be more lean and flexible in your dev environments. What are your thoughts?
Mr. Madison, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul.
Look bro, you need essay writer