jump to navigation

NuGet Causes Needless Headaches With RavenDB, RestSharp and Json.Net September 25, 2012

Posted by ActiveEngine Sensei in .Net, ActiveEngine, Mythology, Open Source, Problem Solving.
Tags: , , ,
add a comment

Just because something is shiny and promises riches doesn’t mean you should put it in your pocketses.  NuGet, while good for getting an assembly for quick and dirty research and development, is a tour to the valley of frustration when you need to focus and deploy a solution with many dependencies.

NuGet has a pretty dialog box so you think you can just “wire up” and go, but this is an illusion my precious.  Sometimes it doesn’t update the Hint path.  Sometimes it forces you to install packages in certain order, as with SignalR, RestSharp and RavenDB.

Think about it – NuGet pulls down files, creates directories and then references to all the paths that were just created.  We can’t do that ourselves by pulling a directory, the adding the reference to old fashioned way, meaning the way that leaves you feeling more in control, not requiring you to spend hours hunting references in package.config files in different folders?  The main premise is to eliminate this practice, right?  What is going to happen when you introduce AppHarbor into the mix where you won’t be able to look and the production server to divine what assemblies are indeed deployed!

What Works Versus What Makes You Feel Cool

Sensei wants to direct you to a solution where a developer needed to use two versions of Json.Net with RavenDB.  His solution:  add dependentAssembly tag to the web.config, upload the file to a sub directory of the bin folder, and move on.

Ok, so it’s not cool, but the job is done.  And that should be the whole point.  Why use tools that put us in this mess in the first place?  Unfortunately NuGet is becoming the primary way to get assemblies.  The road may go ever on but projects have a deadline!!  Poor Smeagul.

Advertisements

A Great Post on Managing Branches in Git September 20, 2012

Posted by ActiveEngine Sensei in AppHarbor, Open Source, Problem Solving.
Tags: , , ,
add a comment

Vincent Driessen has written an amazing post on managing branches in Git, and how to effectively avoid the fire drill that we’ve been through when we have to push a hot-fix into production while preserving new development.  It is titled A Successful Git Branching Model.

This can be very critical if you are using AppHarbor, a .Net cloud platform where you push your source code from Github to AppHarbor and the AppHarbor elves build it and push to a production server if the app passes its unit tests.  AppHarbor maintains a history of builds so that you can -ahem – roll back on the very occasion that you have made a mistake.  But this only speaks to Vincent’s point that if you configure Git with the appropriate branches to handle development, production and hot-fixes you should use the rollback feature less.

Sensei has been spending a lot time working with Git and AppHarbor and one of the next milestone on his journey will be to learn how to disable auto push for the development branch of his project while maintaining the synchronization with the master branch.  This should be the subject of up-coming, shouldn’t it?  Or maybe one of you, the dear readers of this blog has answer they’d like to share?

Some Pitfalls To Avoid With KnockoutJS “options” Binding September 8, 2012

Posted by ActiveEngine Sensei in ActiveEngine, Ajax, KnockoutJS, Mythology, New Techniques, Open Source, Tutorial.
Tags: , , , , , , , , , ,
add a comment

As Sensei has written earlier, KnockOutJS is a great framework for creating rich client side solutions for you web applications.  Simply said it cuts your development down considerably by performing CSS binding for you, while also bringing better structure to your Javascript through the use of the MVVM pattern.  But even the greatest of all wizardry, magery, grammary, magik has its stumbling blocks.  Each tool you use constrains you in some way.  This week Sensei uncovered another puzzle that has left him wondering still if he found the best solution.  Maybe you will have some insight you can share with the “options” binding from Knockout.

Here is the scenario:  You have a <select> ( or a drop down list as us old school Windows devs are found of saying) that you wish to populate with values from an array.  There are two ways that this select list will be used.  The first is when you create a record, and naturally you would like the list to display “New …”.  The second goal is set the value of the <select> to match the value of a current record.  Here is the JS-Fiddle with the first attempt. Selecting from the list sets the value, and you’ll the update at the bottom. Clicking “Simulate Editing Amys Record” will set the value of the list to “Amy” as though you were performing an edit operation.  Here is the view model code:


var ViewModel = function() {
var self = this;

// Simulated seed data from server
this.seedData = ko.observableArray([
{
ID: 1,
firstName: 'John',
value: '333'},
{
ID: 2,
firstName: 'Bob',
value: '333'},
{
ID: 3,
firstName: 'Amy',
value: '333'}]),

// Simulated data from server
self.data = {
title: ko.observable('This is a sample'),
selectedValue: ko.observable("")
}

self.prepForNew = function() {
self.data.selectedValue("");
}

self.changeIt = function() {
self.data.selectedValue("Amy");
}

};

var vm = new ViewModel();
ko.applyBindings(vm);

Now bear with Sensei as he describes the behavior that was so confounding.  We are initializing the <select> by setting data.selectedValue(“”).  The first time the page is displayed we get the behavior that we want.  Click the “Set List for New Record List”.  Nothing happens.  If you trace with Firebug you’ll see that the value is indeed being set, but once it leaves the method it reverts to the current value in the <select>.

Speak, friend, and enter …

Oookkay. Scratch your head. Walk away. Come back, fiddle so more. Rinse, then repeat for about 5 hours.  This shouldn’t be.  In his frenzy Sensei did not consult StackOverflow.  At last an idea came to mind.  Why not add “New …” as the first entry in <select>, give a value of -1 and an ID of -1.  This way at least it is identifiable.  Seems silly but when you have things to accomplish sometimes you just have to eat the sausage instead of thinking about how its made.  Check out the new JS Fiddle before Sensei explains.

Three simple changes have occured.  First we cheate by adding a new object to the array that supports our <select>.  We gave it the “New …” as the first element.

this.seedData = ko.observableArray([
{
//  Here is the default caption object
ID: -1,
firstName: 'New ...',
value: ''},
{
ID: 1,
firstName: 'John',
value: '333'},
{
ID: 2,
firstName: 'Bob',
value: '333'},
{
ID: 3,
firstName: 'Amy',
value: '333'}]),

We yanked out the “optionsCaption: ‘New …” entry in the HTML mark for the view.  Finally the altered the method self.prepForNew to set the value of selectedValue to “New …” with the statement selectedValue(“New …”);  This forces KnockOut to sync to what we want.  Remember that we are working with methods when setting values with Knockout, hence the use of (“New …”);

Sensei is happy to have things working.  Being perplexed over finding out the cause instead of simply creating something simple did fret away the hours.  Like with any new tool, there are nuances that won’t become apparent until you are hit over the head with their pitfalls.

%d bloggers like this: