I had an idea about querying and projecting over big streams of messages serialized with Google Protocol Buffers. If one needs only a few fields to his/her projection, why don’t make it implicit and prepare an optimal way of deserializing only these fields? That’s the way Protobuf-linq has been born. It’s simple, fast and eager to help you iterate over big streams of data.
Check it out!
Author Archives: scooletz
Ripple on your NuGet
Recently I’ve been involved in a project which consists of many teams collaborating to deliver a big project. The application architecture gives this teams an opportunity to work with their code in a module scope. There’s no one big Visual Studio solution, all modules are scoped in their own slns. Living in a world like this means, that your CI, package management and local deployment must be fast, effective and easy to use.
Ripple is a project from the FubuMVC family. It’s an alternative NuGet client, so all the changes in behavior are made on the client side. It makes it a perfect fit for a scenario where one can mix up a local NuGet feeds for their internal packages and official ones. What about its advantages?
The very first difference is a versioning. Ripple extracts packages into non versioned folders. It means that your projects will no longer be changed, when a new version of a package arrives. It helps a lot, especially in environments with packages being frequently published.
Ripple makes a distinction between referenced packages. There are float and fixed packages. Float packages are these changing rapidly. It’s meant that all your packages should be floating during development. The fixed packages are rock solid versions of libraries used by your system. They will not be updated, unless the force option are used.
The Ripple is still being developed. The most important thing it’s that it is active and thriving. If you develop applications in .NET with a plenty of solutions which are meant to publish packages, then give Ripple a try. It’s worth it.
Backbone & underscore beauty
Recently I’ve joined a project which is based on the Single Page Application paradigm. This means no page refreshes after the first load, after login and a plenty of client side scripting. To enhance the project speed a stack of client side libraries is used including, RequireJS (for module management), Underscore, Backbone and Backbone Marionette. There are more of them, but the last three are very interesting because of their paradigm.
Underscore, Backbone and Marionette are not frameworks. They are libraries, great libraries providing a few tools to deal with a web app development. They do not make you to use all of they features components (as ‘features’ are overloaded, framework term). You can pick wisely and use only a few of the provided tools. Of course there is a risk of creating a monster, an unusable app, but it’s up to you and your paradigms, what to use and what to implement on your own. Strongly encourage you to get accustomed to them, especially all of them have a beatiful common denominator, they provide the annotated codebase (code as documentation) which can be found here: Underscore, Backbone, Marionette.
Use libraries, don’t let frameworks use you!
