@RoyOsherove

        RSS Feed

 Comments RSS Feed

     


Subscribe to the Team Leadership mailing list on Google Groups

Email:

Visit this group
Latest Entries

Subscribe to RSS headline updates from:
Powered by FeedBurner

Friday
Sep252009

Be Productive and Stop Using XML

« Be Productive and Go Mouseless | Main | Why managing a software team can be more effective than "regular" management »

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.

September 25, 2009 | Unregistered CommenterHardeep Virdee

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.

September 25, 2009 | Unregistered CommenterMichael Stum

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!

September 25, 2009 | Unregistered CommenterJudah Himango

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!!

September 25, 2009 | Unregistered CommenterKarl Prosser

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.

September 25, 2009 | Unregistered CommenterDominique Rabeuf

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.

September 25, 2009 | Unregistered CommenterTravis Illig

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.)

September 27, 2009 | Unregistered CommenterVegard Sandvold

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...

September 27, 2009 | Unregistered CommenterPiotr Zolnierek

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?

September 28, 2009 | Unregistered CommenterJeff Spicoli

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.

December 31, 2009 | Unregistered CommenterAndyT

Look bro, you need essay writer

April 28, 2010 | Unregistered Commenterlk

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>