Ayende @ Rahien

Oren Eini aka Ayende Rahien CEO of Hibernating Rhinos LTD, which develops RavenDB, a NoSQL Open Source Document Database.

You can reach me by:

oren@ravendb.net

+972 52-548-6969

, @ Q j

Posts: 6,858 | Comments: 49,164

filter by tags archive
time to read 5 min | 849 words

Andrey has reminded me that there are some advantages to XML, such as the ability to define an XSD and get intellisense, or to use standard stuff such as xinclude, out of preverse sense of curiousity, I tried to do this to an SSIS package:

<?xml version="1.0"?>

<DTS:Executable xmlns:DTS="www.microsoft.com/SqlServer/Dts"

                DTS:ExecutableType="MSDTS.Package.1"

                xmlns:xi="http://www.w3.org/2001/XInclude">

 

  <xi:include href="file:///D:/xinclude.xml"/>

 

</DTS:Executable>

I simple moved everything out to the xinclude.xml, wasn't surprised when it didn't work. A lot of the features of XML require an extra action on the side of the parsing code, such as explicitly asking for resolving XInclude, and most of the time that is never supported by the tools. And while XSD schema + intellisense is nice, do you really want to write something like an SSIS package using plain XML + intellisense?

The Sins of XML

time to read 2 min | 207 words

In case you didn't notice, I don't like XML. To be rather exact, I don't like the way XML is used. If you are writing a document, it is a great way to skip parsing headaches, but seriously, is writing a parser that hard?

Case in point, SSIS packages are just XML, but they are literally binary XML, in that I have no way of really looking inside and figuring out what is going on. Oh, I can probably put it through a prettifier and then try to have a look-see, but that is a costly endevour, and not really practical for anything beyond getting the bloody connection string out of the file.

Just today I was looking at SSIS package, it was changed, but I have no idea what the change was, so I run a diff. It came back with a lot of changes, non of which told me, an occational (reluctant) dabbler of SSIS what the hell had happened.

Just this, the inability to understand what the hell has changed from a diff file, is a serious offence against the maintainability of most of the "no code" approaches (but reams of XML).

Urgh!

In other news, Boo got better support for creating DSLs.

time to read 5 min | 802 words

image_thumb3_thumb_thumbI would really like to understand the attidute behind "no code* (TM) " approach.

* Except a whole lot of of XML that you are not supposed to look at but usually have.

 

The new announcement from Microsoft is hitting all the key points that scream "STOP" in my case:

 

Tomorrow you will build parts, behaviors, navigation, and even business logic (via Windows Workflow Foundation) all in a designer. You will even wire components and dependencies and define how they interact, all without writing or generating any code.

I do believe that I have heard this promise before. About Object Oriented Programming, COM, XML, Web Services, SOA, etc.

Being a developer is about telling the computer what to do. Trying to hide this behind a wizard is nice, but it is not an approach that scales, period.

I am not going to program in this, but it looks like that is what I would need to do if I wanted to understand what is going on.

<CsamlFile xmlns="http://schemas.microsoft.com/winfx/2006/xaml/csaml"
           xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <NamespaceDeclaration Identifier="MyNamespace">
        <ClassDeclaration Identifier="MyClass" 
                          Access="Public">
            <MethodDeclaration Identifier="Main" 
                               Access="Public" 
                               Modifier="Static" 
                               ReturnType="{x:Type void}">
                <InvocationExpression
                  MemberAccess="System.Console.WriteLine">
                    <InvocationExpression.ArgumentList>
                        <Literal Type="{x:Type string}"
                                 Value="Hello, CSAML! ">
                    </InvocationExpression.ArgumentList>
                </InvocationExpression>
            </MethodDeclaration>
        </ClassDeclaration>
    </NamespaceDeclaration>
</CsamlFile> 

Oh wait, there is a designer?

Nice, I saw how that turned out for SSIS, BizTalk, etc when we are talking about even moderate complexity. How do I debug it? There is a special tool? How do I profile it? There is nothing for that?

Can we please stop trying to run away from code? If I want declerative language, I will write a DSL, and it sure as hell wouldn't be in XML.

I am all for smarter frameworks and making our life easier, but I am completely against trying to get to: "all without writing or generating any code"

Newsflash: XML is code, period.

time to read 4 min | 702 words

Lame title, but bear with me.

I have got a set of XML files that conform to an XSD schema, specifically, this one. I want to add additional elements and attributes to the documents, without breaking the schema, and hopefully without changing the code that read the schema.

Basically, I have this:

<class name="Blog" table="Blogs">

       <search:indexed-entity index="indexes/blogs"/>

       <property name="Subtitle">

              <search:field index="tokenized"/>

       </property>

</class>

I have bolded the parts that I want to add to the document. Any suggestions?

time to read 3 min | 499 words

Continuing on the TDD list, this message from Robert Hanson has the best description of the goals of XP that I've ever read.

In an excellent programming environment there is no fear.

  • The customer has told us exactly what he values most. I have no fear that I might be working on something he does not want.
  • The code I'm working on is test driven. I have no fear (or at least, very little fear) that the code might do something I don't want it to do.
  • All other code has unit tests; and I have continuous integration in place. I have no fear that my code will break something without me knowing it; and I have every confidence that if it does break, I can quickly find the problem and fix it, and verify that the fix works and does not break anything else.
  • I have source code control in place; if a change is really catastrophic, I just go back to yesterday's version and start over.
  • I have short iterations, so that I have no fear that if priorities or business needs change, I can adapt to the new requirements without fear.
  • I have a pair, which I change every few hours or at the start of each day. I don't worry that some key piece of knowledge is known by just one person.

And boy, do I wish I actually worked at a place like this.

I wish I worked there too. Check out the replies, they contain some great discussion.

time to read 2 min | 221 words

Recently I've think about trying out some of the cool things that Avalon lets you do.

I'm not a UI programmer (never mind what other people are trying to tell me :-) ), but the things you can do there are so impressive that I really itch to do something with them. The interesting part comes when you throw an XML database into the deal, since using XQuery and friends you may be able to generate the UI in the query level, so you could probably create a lot of interesting stuff just by playing with the data.

I've no idea if Avalon has the ability to generate the UI on runtime, or if it needs a compilation step like ASP.Net (I would tend to think so, but I really don't know any thing about it except that it looks cool). But if it can (and even if it can't) that should be a really cool project.

The Berkley DB XML is a free XML DB that looks nices, and it has .Net API (but not a free one). I'm thinking of buying a book about Avalon and writing some sample applications. And recommendations about that?

Anyone can comment about the general idea?

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Production postmortem (26):
    07 Jun 2019 - Printer out of paper and the RavenDB hang
  2. Reviewing Sled (3):
    23 Apr 2019 - Part III
  3. RavenDB 4.2 Features (5):
    21 Mar 2019 - Diffing revisions
  4. Workflow design (4):
    06 Mar 2019 - Making the business people happy
  5. Data modeling with indexes (6):
    22 Feb 2019 - Event sourcing–Part III–time sensitive data
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats