Corax is a research project that we have, to see how we can build a full text search library on top of Voron. Along the way, we take the chance to find out how Lucene does things, and what we can do better. Pretty much from the get go, Corax is likely to use more disk space than Lucene, probably significantly so. I would be happy if we could get a merely 50% increase over Lucene The reason that this is the case is that Lucene goes to great length to save disk space. From storing all integers in
variable length format, to prefix compression to implicitly referencing data in other files. For example, you can see that when you try reading term positions: TermPositions are ordered by term (the term is implicit, from the .tis file). Positions entries are ordered by increasing document number (the document number is implicit from the .frq file). The downside of saving every little bit is that it is a lot more complex to read the data, requiring multiple caches and complex code path to actually get it properly. It make a lot of sense, when Lucene was created, disk space...(Read whole news on source site)
Information Sharing code across platforms - Immo Landwerth discusses the two options both dramatically improving following announcements at Build, to producing cross platform applications with shared code Migrating from NHibernate to Entity Framework - Jimmy Bogard discusses a recent migration from NHibernate to Entity Framework, discussing the history of the two projects, the equivalences and equivalents between [...]
Originally posted on: http://geekswithblogs.net/TATWORTH/archive/2014/04/23/build-mobile-apps-using-visual-studio-and-telerik.aspxAt http://www.youtube.com/watch?v=pPOKAJyPgjQ, Telerik have provided a very interesting video on starting building mobile applications using Visual Studio and Telerik controls.
There is a seminar recording at http://www.youtube.com/watch?v=fAnlUo50DXk done by an MVP
An important component of the decision to use a framework should be the amount of ceremony and ritual involved. You must carefully weigh what it takes to ramp up on the technology and how common tasks are performed. It does no good to adopt a library that forces you to solve a problem with more effort than it would take using your basic tools. One of my favorite examples to showcase technology is a simple feed reader. Several years ago I recorded a video to demonstrate how to build a Silverlight MVVM Feed Reader from Scratch in 30
I have been merrilly using NCrunch - an "automated concurrent testing tool for Visual Studio" - for almost three years now. I ponied up for a paid license when it made the transition from beta to RTM, and I recently shelled out again for an upgrade to version 2. Why?! Why do this when plenty of test runners are free, or bundled with software I already own such as ReSharper and Visual Studio itself? To answer that question I sorely wanted to write another "list post" as a follow-up to 12 Reasons Why I Love Unit Tests but as my
draft progressed and my thoughts crystallised in front of me on the screen, I realised that all of the points I was trying to convey ultimate boil down to the same one reason: NCrunch Saves Me Time I missed out on the age of the punchcard, thank goodness. I don't think I could have coped with the torpid feedback cycles that software developers of that era had to endure. Bob Martin describes the multi-day process entertainingly in his excellent book The Clean Coder - programs written on coding forms with a #2 pencil, typed up by key-punchers, desk-checked, loaded by the...(Read whole news on source site)