Perpanjangan Paket Data Tri (3)

Memperpanjang paket data Tri memang agak lebih ribet dibandingkan paket data dari operator lain, khususnya untuk kasus kuota yang sudah habis sebelum masa aktif paket tersebut habis. Berikut ini cara topup dan "memaksa" kuota yang sudah anda topup segera bisa digunakan sebelum masa aktif paket tersebut habis: 

1. Beli voucher topup untuk paket yg anda pakai. Dalam kasus saya, saya membeli dari ATM, pada struk dari ATM muncul nomor kode untuk topup. Karena nomor kode topup tertera pada struk, jangan buang struk anda setelah transaksi di ATM.

2. Dari modem atau HP anda, kirim SMS ke 234 dengan isi "mau 1GB" jika paket yang anda inginkan adalah paket 50rb (1.25GB). Untuk denominasi paket lain, silahkan ganti 1GB dengan jenis paket anda. 

3. Reboot (Matikan kemudian nyalakan) HP anda untuk memastikan topup yang anda baru saja lakukan langsung diaktifkan oleh Tri (3). 

Saya sebelumnya harus menanyakan "trik SMS" ini ke customer service Tri sebab setelah topup 50rb, paket yang saya gunakan tetap tidak aktif. Ini berbeda dengan Indosat yang hanya akan meminta anda mematikan kemudian menyalakan modem atau HP jika anda baru saja topup paket data yang anda gunakan. 

Kazushige Goto is Now with Intel

Probably, you've never heard of Kazushige Goto previously. He's the man behind the Goto BLAS library (http://www.cs.utexas.edu/~flame/goto/signup_first.html). Goto BLAS library previously featured in some of the fastest floating point monsters (also known as Supercomputers). Read http://www.utexas.edu/features/2006/goto/index.html for details about his past work.

Now, he is with Intel http://www.linkedin.com/pub/kazushige-goto/40/230/b61. This shows how serious Intel is about HPC these days. I bet he works on  the new Xeon Phi lines of product. It's handy to have man like Goto because of his insights into very low-level execution of HPC routines.

XmlDocument Class ImportNode() method

The XmlDocument.ImportNode() method is probably one of the most misunderstood function in the XmlDocument class in C# (.NET). Programmers probably expects the function to import a set of nodes from one XML document instance to another instance and place the nodes inside the target XML document instance. However, that's not what happened. Reading from MSDN (http://msdn.microsoft.com/en-us/library/system.xml.xmldocument.importnode.aspx):

Importing a node creates an XmlNode object owned by the importing document, with Name and NodeType identical to the source node. The new object also has the attributes related to namespaces (Prefix, LocalName, and NamespaceURI).

After reading the statement at MSDN above, what you should be aware is the ImportNode() method doesn't place the imported set of node in the target XML document. The method merely import the set of node from the context of the source XML document to the target XML document. What I mean by context here have to do with XML namespace. You cannot just place a "rogue" set of nodes without namespace in the target XML document, you have to give a context to the set of nodes, i.e. valid XML namespace, etc. In most cases this is probably what you want to do:

                
foreach (XmlNode currentNode in facts.DocumentElement.ChildNodes)
{
    node = doc.ImportNode(facts.DocumentElement.ChildNodes.Item(i), true);
    doc.DocumentElement.AppendChild(node);
    i++;
}

The code above copies every single child element of the root element of the facts XmlDocument object (source) to the doc XmlDocument (destination) root element.

So, next time you deal with the ImportNode() method, remember that what it does is related to the XML document instance context.

Caching XSD Schemas in Your .NET Application

If your .NET application deals with linked XSD files, you might find it very inefficient to re-load the linked XSDs every time the application starts. One of the real world example of this is the XBRL taxonomy schemas, which is linked to numerous XSDs defining different parts of the XBRL standard. Now, how do you cache the XSDs schemas locally? For the caching to work, you need to use .NET 4.0 because the caching-related classes is only available in .NET 4.0. Now, let me show you how I make the caching works in Gepsio (one of the open source XBRL implementation):

1. Goto the project (JeffFerguson.Gepsio project) and change the "Target Framework" to ".NET Framework 4".
2. Add the following code to XbrlSchema.cs file: 

using System.Net.Cache; // This line added for caching support

//...

public class XbrlSchema
    {
//...
private XmlUrlResolver thisXmlUrlResolver;

//...
 internal XbrlSchema(XbrlFragment ContainingXbrlFragment, 
                     string SchemaFilename, string BaseDirectory)
     {
         thisContainingXbrlFragment = ContainingXbrlFragment;
         this.Path = GetFullSchemaPath(SchemaFilename, BaseDirectory);

         try
  {
    var schemaReader = XmlTextReader.Create(this.Path);
    thisXmlSchema = XmlSchema.Read(schemaReader, null);
    thisXmlSchemaSet = new XmlSchemaSet();

///---- START caching with XmlUrlResolver
           thisXmlUrlResolver = new XmlUrlResolver();
           thisXmlUrlResolver.CachePolicy = new  
                     RequestCachePolicy(RequestCacheLevel.CacheIfAvailable);
           thisXmlSchemaSet.XmlResolver = thisXmlUrlResolver;
///----- END caching with XmlUrlResolver 

           thisXmlSchemaSet.Add(thisXmlSchema); 
    thisXmlSchemaSet.Compile();

//...

Well, actually I found the call to the XmlSchemaSet object (thisXmlSchemaSet) to be particularly the biggest bottleneck with Visual Studio profiler when dealing with lots of XBRL instance files because XmlSchemaSet always download the XSD dependencies from xbrl.org.

A side note: the CachePolicy member of the XmlUrlResolver class is not available in .NET Framework version < 4.0 . That's the reason why you have to switch the project to .NET Framework 4.0.

Perhaps, you're not aware of this: the call to XmlSchemaSet.Add() will traverse every linked XSD schemas   until all of them are resolved. Now, if the location of the schemas are remote, that incurs very high penalty to the speed of your application and that wastes unnecessary bandwidth. In this case, schema caching comes to the rescue.