<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
  <channel>
    <title>DotNetKicks.com : Stories kicked by damageboy</title>
    <description>Stories kicked by damageboy</description>
    <link>http://www.dotnetkicks.com/</link>
    <language>en-us</language>
    <copyright>Atweb Publishing Ltd.</copyright>
    <docs>http://backend.userland.com/rss</docs>
    <generator>DotNetKicks.com - .NET links, community driven</generator>
    <ttl>30</ttl>
    <item>
      <title>Lang.NET 2009 Keynote (Includes Pre-Beta1 VS2010 demo)</title>
      <description>Jason Zander Lang.NET Keynote...
See short Visual Studio 2010 demo inside (Video) &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.dotnetkicks.com/kick/?url=http%3a%2f%2flangnetsymposium.com%2f2009%2ftalks%2f01-JasonZander-Keynote.html"&gt;&lt;img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http%3a%2f%2flangnetsymposium.com%2f2009%2ftalks%2f01-JasonZander-Keynote.html" border="0" alt="kick it on DotNetKicks.com" /&gt;&lt;/a&gt;
</description>
      <link>http://www.dotnetkicks.com/visualstudio/Lang_NET_2009_Keynote_Includes_Pre_Beta1_VS2010_demo</link>
      <guid isPermaLink="true">http://www.dotnetkicks.com/visualstudio/Lang_NET_2009_Keynote_Includes_Pre_Beta1_VS2010_demo</guid>
      <pubDate>Mon, 27 Apr 2009 22:31:16 GMT</pubDate>
    </item>
    <item>
      <title>Command line option parsing using Lambda functions with NDesk.Options</title>
      <description>I had been doing a lot of work on monodocer, and the warning about Mono.GetOptions being obsolete was getting annoying. So after killing an afternoon coming up with a similar reflection-based alternative, it dawned on me that (1) any such alternative would not be &amp;quot;simple&amp;quot;, and (2) using such a library would have a high code overhead. After thinking back on the previous option parsing libraries I've used, I remembered Perl's Getopt::Long library, which permits short and concise declarations of the options a program supports.  &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.dotnetkicks.com/kick/?url=http%3a%2f%2fwww.ndesk.org%2fOptions"&gt;&lt;img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http%3a%2f%2fwww.ndesk.org%2fOptions" border="0" alt="kick it on DotNetKicks.com" /&gt;&lt;/a&gt;
</description>
      <link>http://www.dotnetkicks.com/opensource/Command_line_option_parsing_using_Lambda_functions_with_NDesk_Options</link>
      <guid isPermaLink="true">http://www.dotnetkicks.com/opensource/Command_line_option_parsing_using_Lambda_functions_with_NDesk_Options</guid>
      <pubDate>Fri, 22 Aug 2008 02:52:49 GMT</pubDate>
    </item>
    <item>
      <title>.NET Port of Google Protocol Buffers</title>
      <description>My efforts porting Google's Protocol Buffers are now pretty complete in terms of functionality, so I've been looking at improving the performance. The basic idea is that you specify your data types in a .proto file, and then generate C# from that. The generated C# allows you to manipulate the data, and serialize/deserialize it. When you generate the code, it can be optimised either for size or speed. The &amp;quot;small&amp;quot; code can end up being much smaller than the &amp;quot;fast&amp;quot; code - but it's also significantly slower as it uses reflection when serializing and deserializing. &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.dotnetkicks.com/kick/?url=http%3a%2f%2fgithub.com%2fjskeet%2fdotnet-protobufs%2ftree%2fmaster"&gt;&lt;img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http%3a%2f%2fgithub.com%2fjskeet%2fdotnet-protobufs%2ftree%2fmaster" border="0" alt="kick it on DotNetKicks.com" /&gt;&lt;/a&gt;
</description>
      <link>http://www.dotnetkicks.com/opensource/NET_Port_of_Google_Protocol_Buffers</link>
      <guid isPermaLink="true">http://www.dotnetkicks.com/opensource/NET_Port_of_Google_Protocol_Buffers</guid>
      <pubDate>Fri, 22 Aug 2008 02:48:51 GMT</pubDate>
    </item>
    <item>
      <title>Solving the Problem with Events: Weak Event Handlers</title>
      <description>One of the greatest frustration of working with delegates and events is that they can potentially cause memory leaks if they aren't unhooked. In this article, we will solve this problem in a variety of ways to get the best performance, memory use and syntax. &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.dotnetkicks.com/kick/?url=http%3a%2f%2fdiditwith.net%2fPermaLink%2cguid%2caacdb8ae-7baa-4423-a953-c18c1c7940ab.aspx"&gt;&lt;img src="http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url=http%3a%2f%2fdiditwith.net%2fPermaLink%2cguid%2caacdb8ae-7baa-4423-a953-c18c1c7940ab.aspx" border="0" alt="kick it on DotNetKicks.com" /&gt;&lt;/a&gt;
</description>
      <link>http://www.dotnetkicks.com/csharp/Solving_the_Problem_with_Events_Weak_Event_Handlers</link>
      <guid isPermaLink="true">http://www.dotnetkicks.com/csharp/Solving_the_Problem_with_Events_Weak_Event_Handlers</guid>
      <pubDate>Sat, 24 Mar 2007 17:01:01 GMT</pubDate>
    </item>
  </channel>
</rss>
