It seems like a coexistence of SQL and NoSQL worlds is possible now. The folks from DeNA succeeded in creating a hybrid of both approaches. The MySQL plugin HandlerSocket turns the InnoDB engine into a NoSQL database. HandlerSocket allows to benefit from mature RDBMS storage engines and the lightweight NoSQL protocol that abandons the SQL processing. The results are very promising: with 750,000 queries per second the HandlerSocket achieves a considerably better throughput than the standard MySQL (105,000 qps).
For details on this benchmark and more information about HandlerSocket see Yoshinori Matsunobu's blog: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html.
And last but not least: HandlerSocket ist open source. You can grab the code from github: https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL.
Friday, March 4, 2011
Tuesday, March 1, 2011
Magic GUIDs, ReSharper and more...
Here are some tricks I discovered today:
- Magic GUIDs: Creating unit tests in Visual Studio is quite easy when you are doing it 'the right way'. But sometimes when I want to write tests first and create a new project for them I mistakenly choose the class library project type instead of a unit test project. However these are two different project types so when I try to run my tests from the class library project the Visual Studio won't find them. Fortunately you can convert an existing visual studio class library project to unit tests project: http://blog.drorhelper.com/2008/12/how-to-convert-net-class-library-to-ms.html
- ReSharper: There is a great new feature in ReSharper 5.0 called value tracking.
- Another nice ReSharper feature useful when you want to restructure you code: Move code elements up and down: [Ctrl]+[Alt]+[Shift]+[Up|Down]. You can move single lines but also entire methods.
- Sourcemaking: A website with lots of stuff about design pattern, antipatterns and refactoring: http://sourcemaking.com/
Labels:
programming,
tools,
visual studio
Monday, February 7, 2011
Dynamic base address for a WCF service
Last week I've learned a nice 'trick' that allows to specify a dynamic base address for a WCF service in the configuration file. When you want to run a WCF service you need to specify the base address for the service host. You can do this in a config file or directly in your code when creating a ServiceHost instance: http://msdn.microsoft.com/en-us/library/ms733749.aspx.
Now if you are deploying your service to many machines you must either adjust the host name for each machine during/after the installation or you set the host name to 'localhost'. The problem with the last option is that if you are also exposing metadata then the MEX client will get some endpoint addresses with 'localhost' as host name and will try to call this service on its local machine unless you adjust the host name while creating a proxy.
A handy solution for this problem is to use a so called 'weak wildcard' for the host name part of the base address:
Edit: The solution works only with base-addresses not with endpoint addresses!
Now if you are deploying your service to many machines you must either adjust the host name for each machine during/after the installation or you set the host name to 'localhost'. The problem with the last option is that if you are also exposing metadata then the MEX client will get some endpoint addresses with 'localhost' as host name and will try to call this service on its local machine unless you adjust the host name while creating a proxy.
A handy solution for this problem is to use a so called 'weak wildcard' for the host name part of the base address:
<system.serviceModel>
<services>
<host>
<baseAddresses>
<add baseaddress="net.tcp://*:1234/svc" />
</baseAddresses>
</host>
</services>
</system.serviceModel>
That's it. The framework will replace the wild card with the name of the host the service is actually running on.Edit: The solution works only with base-addresses not with endpoint addresses!
Labels:
.net,
programming,
WCF
Wednesday, January 19, 2011
WF: The most useful event.
Few weeks ago a discovered the WorkflowRuntime.ServicesExceptionNotHandled event. This event can save you a lot of time debugging strange behavior of workflow instances. In my case all instances of a workflow didn't complete after an 'insignificant' change in the workflow class. No exceptions have been thrown by the runtime or the workflow code and the workflow instance just didn't failed or complete. After some 'googling' I came across the ServiceExceptionNotHandled event. So I registered a handler and traced the not handled exception. It turned out that the persistence service has thrown an exception each time it tried to save the workflow state in the database because one member of this workflow was not serializable. Without that event I would still be debugging that workflow :)
Saturday, September 18, 2010
Making custom trace listeners more configurable.
The .NET System.Diagnostics namespace provide some classes that can be used to trace the execution of your programm. There are some default listeners in the Diagnostics namespace which can be used to write the trace messages to a file, the event log, etc. You can also write your own trace listeners by extending/overwriting the TraceListener class. These trace listeners can be registered at runtime:
Trace.Listeners.Add(new ConsoleTraceListener());
Or you can specify listeners you want to use in the
system.diagnostics section of your .config file:<listeners>
<add initializedata="MyEventLog"
name="EventLogListener"
type="System.Diagnostics.EventLogTraceListener">
</add>
</listeners>
If you use the .config file it would be nice to extend the xml tag by custom attributes. To do so you need to override the
GetSupportedAttributes() method in your TraceListener-implementation. In this method you just need to return the names of the custom attributes you want to use in the .config file. For example if you have a custom trace listener that separates trace entries by a delimiter:protected override string[] GetSupportedAttributes() {
return new string[] { "delimiter" };
}
Now you can specify the delimiter in you .config file:<listeners>
<add delimiter=":"
initializedata="delimitedOutput.txt"
name="delimitedListener"
type="MyNamespace.MyDelimitedTraceListener">
</add>
</listeners>
To get the value of the custom attribute you can use the Attributes property of the base class in your TraceListener implementation:foreach (DictionaryEntry de in this.Attributes) {
if (de.Key.ToString().ToLower() == "delimiter") {
source = de.Value.ToString();
}
}
Labels:
.net
Sunday, August 29, 2010
Reloaded
After a long time I decided to revive my blog. So here are some news and other stuff I found interesting during the last week:
- insideHPC reports that Microsoft is about to release a HPC platform called Dryad. It seems like "Dryad" will bring together some of the Microsoft research projects like: the runtime (Dryad), a distributed file system (TidyFS), a scheduler for distributed clusters (Quincy), etc...
- Phil Haack shows how to test events using Rhino Mocks: Using Rhino Mocks To Unit Test Events on Interfaces. Old but nevertheless interesting and new to me :)
- Stephen Toub schows how to implement a Stream pipeline in .NET.
- Udi Dahan gave a nice presentation about high availability. The video is available on the teched site. Some stuff to think about.
- Microsoft released the beta of Visual Studio Lightswitch. A Visual Studio edition for RAD.
Saturday, August 29, 2009
Windows Installer Transforms
If you have ever tried to install more than one instance of you application on a single windows machine you probably know that the windows installer permits only one instance of a product code to be installed for a machine or a user. The "brute force" solution is to create a second msi package and use this one for the installation of the second instance. But since the Windows Installer 3.0 there is another option. You can use the transforms feature to install multiple instances of an application using a single msi package. Below I've listed the steps to create and apply a transform using VS and the Windows SDK:
- Compile you setup project to generate the base msi package.
- Rename the generated msi file to say mykillerapp_base.msi and copy it to another location.
- Change the product code (or maybe also the product name) and recompile your setup project.
- Copy the first msi package (mykillerapp_base.msi) to the directory with the second msi file generated in previos step.
- Run msitran to generate the transform:
msitran -g mykillerapp_base.msi mykillerapp.msi setup.mst - Install the first msi package.
- Install the second instance:
msiexec /i mykillerapp_base.msi TRANSFORMS=setup.mst MSINEWINSTANCE=1
That's it. ;)
Labels:
installer,
msi,
transforms,
windows
Subscribe to:
Posts (Atom)