Kartones Blog

As Pedro has just posted, we've finally launched a new section for the portal, Demos.Kartones.Net (available too from the home), which contains and will contain all web mashups and demos that we make (now being able to use .NET FW 3.5 even cooler ones!).

It is mostly the work of Pedro and has been done with Silverlight 1.0 and JSON. It already contains some of our past demos.

If any of our community bloggers wants to have their demo published just contact me and I'll upload to the subsite ;)

Buddyscript is capable of managing xmls with ease, and accessing external databases for example with a web service.

But sometimes we may need to have non-trivial xmls locally, and those xmls may have complex structures not so easy to handle.

This is the graphical representation of a sample xml that may not be easy to read:

This is a possible xml content:

<?xml version="1.0" encoding="utf-8"?>
<fields>
  <field>
    <field1>1</field1>
    <field2>
      <value>121</value>
      <value>122</value>
      <value>123</value>
    </field2>
    <field3>13</field3>
  </field>
  <field>
    <field1>2</field1>
    <field2>
      <value>221</value>
      <value>222</value>
      <value>223</value>
    </field2>
    <field3>23</field3>
  </field>
</fields>

The buddyscript code to read this xml you could incorrectly think that it might be something like this:

datasource Table1XMLFileLoader() => Field1, Field2, Field3
  file
    table1.xml
  simple xml
      fields
        field {loop=content}
          field1
          field2
            value {loop=content}
          field3

The problem is that if you execute this code, the agent can incorrectly loop the values, because it doesn't supports multiple anidated loops. This gets worse with three or more "looping fields". The XML should only have one looping tag/element.

So, how to fix this limitation? Well, I do it applying what I call xml normalization: Like with a DB normalization, re-estructure your xml in multiple files, splitted so that each sub-table now only has as simple 1-1 relations (but they can be repeated as many times as wanted, that'sd the trick ;)

This is the graphical representation of the normalized xmls:

This are our normalized xmls:

Table1_1.xml

<?xml version="1.0" encoding="utf-8"?>
<fields>
  <field>
    <field1>1</field1>
    <field2>121</field2>
  </field>
  <field>
    <field1>1</field1>
    <field2>122</field2>
  </field>
  <field>
    <field1>1</field1>
    <field2>123</field2>
  </field>
  <field>
    <field1>2</field1>
    <field2>221</field2>
  </field>
  <field>
    <field1>2</field1>
    <field2>222</field2>
  </field>
  <field>
    <field1>2</field1>
    <field2>223</field2>
  </field>
</fields>

Table2_2.xml

<?xml version="1.0" encoding="utf-8"?>
<fields>
  <field>
    <field1>1</field1>
    <field3>13</field3>
  </field>
  <field>
    <field1>2</field1>
    <field3>23</field3>
  </field>
</fields>

And finally the buddyscript code to read them, this time correctly:

datasource Table1_1XMLFileLoader() => Field1, Field2
  file
    table1.xml
  simple xml
      fields
        field {loop=content}
          field1
          field2

datasource Table1_2XMLFileLoader() => Field1, Field3
  file
    table1.xml
  simple xml
      fields
        field {loop=content}
          field1
          field3

We can now do simple querys against each of the sub-tables and cross the results (with <field1>) to obtain one or more registers (original Table1 <field>) with multiple subfields (origintal Table1 <field2>).

When we use XMLs, they come with UTF-8 encoding, so there is no problem in storing into them international characters, like for example the spanish word "España".

We may have for example an XML with a list of countries written in spanish, and why not with first capital letter (for writing directly a country from the xml to the conversation window without uppercasing first letter ;).

We create a subpattern and load it with that xml data:

subpattern CountriesSubPattern get Name, Name in CountriesTable {score=MACRO_STRONG_SCORE}

Testing our Agent we will detect that he doesn't understands "España" as a valid country.

The problem is that loading XMLs we might have incorrectly setup the index property of the DataTable's parameter, or how the subpattern needs to receive the user input.

datatable CountriesTable {expire="in 1 day"}
  load Name {index=case-insensitive} from datasource
    CountriesXMLFileLoader()

subpattern CountriesSubPattern get Name, Name in CountriesTable {style=raw}

For international characters, like spanish ones, we need "style=raw", because otherwise the Agent will use the thawed version (in the 4.3 SDK, "España" transforms into "espan a").

Note: This was a problem we recently had with the 4.3 version of the SDK, and just using XML files.
Using the Beta 5.0 SDK with a non-xml subpattern like the following the matching is perfect without adding properties:

subpattern CountriesSubPattern
+ españa
+ inglaterra

+ COUNTRY=CountriesSubPattern {score=MACRO_STRONG_SCORE}
- COUNTRY is a country

I've only been working for near 6 years, but I've been in 4 different companies and lots of customers, so I've "tasted" very heterogeneous "work ecosystems".

I love my work, and I enjoy a lot developing, so whenever I can, I try to add a humour component to my daily work in order to make it even more enjoyable.

This is specially useful when you have tedious tasks, or a tight schedule, or you enter in a crunch-time phase. I've worked with teams in a "hostile environment" and the results were clearly worse than in happy, nice ones.

Now that at ilitia we've got a "Windows Live Team" (small one but I hope to have it increased soon), I try to keep it "in good shape" by making all sort of jokes and encouraging my pals to do the same.

A good thing is that working developing Windows Live Agents is fun "by itself": When your agent doesn't works is not like getting an exception in .NET and your application crashing. Your agent may "be shy" (not respond to something expected), may be "drunk" or "lost" (answering wrong things) or it may even "come alive" (when does something really unexpected :)

Also, we sometimes like to play painting images and creating fake logos to have some fun. Here there are a few ones:

Living the Enjuto Mojamuto way of life!

 
Our "Windows Live Team" unofficial signature logo :)

The A-Team "mashup" (in Spanish)

So, if you don't already do it, try to add humour to your work and you will notice the advantages ;)

Work happy, work better!

Yesterday an update for iZ, our first WLA was uploaded and applied.

The agent now writes in red color! :D

Now, seriously, we've made some improvements. One good thing about internet is that you can get early feedback from the users. We received bad feedback from one of the mayor national newspapers, in part due to the previous spanish WLA, Robin, who was a complete failure and a bad start.
The negative feedback argumented that the agent could not find proposals, and as we've noticed, having a so large initial help/salutation most users don't read it and don't know the don't start searching proposals.

So, what I've done is modify the "catch-all" conversation pattern (called if the agent doesn't have an answer), and make a "silent call" to the proposal search system. If what the user has typed is recognized as a valid keyword and there are proposals related, user is sent to search mode automatically and the proposals start to show.

Now searching is quite easier, because you can start a conversation and type "vivienda" (housing), and the agent will find more than 35 related proposals as if you first had typed "buscar" (search) or some similar pattern.

It is great to be able to improve you agent capabilities so easily, in part due to a correct programming (the whole search system is very extensible and works in multiple steps, so can be adapted to different situations) but in part too because this is like a web portal (which you can update anytime) and not like a desktop application (in which a change means new update or redistributable, which not all users will apply).