jump to navigation

Develop A Theme For Your Project – Spock Can Help April 28, 2013

Posted by ActiveEngine Sensei in ActiveEngine, Mythology, New Techniques, Personal Development, Problem Solving, software economics.
Tags: , , , , , , ,
add a comment

Evil_SpockMany times Sensei has said you have to have a theme song for your projects. You may have certainly noticed that Sensei is old school, prog-rock and somewhat metal oriented. Spock’s Beard is a recent discovery and the group has direct roots with Transatlantic.

This latest album is a great source of inspiration, so if you have a ten minute walk ahead of, fire it up and it will get your head straight for serious productivity, creativity, or pure coding marathons.

The Speed of Thought, Part Duh!!! (Or Driving Stick Shift with Javascript) April 18, 2013

Posted by ActiveEngine Sensei in ActiveEngine, Coaching, Humor, jQuery, KnockoutJS, Mythology, Problem Solving, Scripting.
Tags: , , , , ,
add a comment

scream_baron_blood_01Sensei is a libertarian – so you can interpret that to mean few rules, respect others freedom, government and busy bodies “leave me the hell alone”, stay-outta-my-way-attitude-person is his motto.  That means the only way to drive is with the stick.  Automatic is for the soccer moms.  Javascript is like driving manual transmission – sometimes you grind the gears.

You’re hero just spent a half hour pouring over some Knockout.js code, wondering why his observableArray went MIA on each push.  Can you see why?

var Question = function (id, question, sortOrder) {
this.Id = id;
this.Question = ko.observable(question);
this.SortOrder = ko.observable(sortOrder);
};

It’s not Javascript’s fault, it’s Sensei’s fault. Now you can see why he writes in the third person, ’cause it’s easier to remove yourself from these type of dumb mistakes when you can treat your persona as separate person!! If you see the issue, leave a comment before I post the resolution.

Learning Techniques: What the Research Says April 18, 2013

Posted by ActiveEngine Sensei in ActiveEngine, Mythology, New Techniques, Personal Development, Problem Solving.
add a comment

A great study in learning techniques how effective they are.

Learning Techniques: What the Research Says.

The Speed of Thought April 17, 2013

Posted by ActiveEngine Sensei in ActiveEngine, Approvaflow, Business Processes, Coaching, Fluent, Mythology, Personal Development, Problem Solving.
Tags: , , , , , , , ,
add a comment

faradaypennytwinsOf late, Sensei needs to keep a clear head.  That has meant learning to segment ideas and really, really, really focus on streamlined features.  This is hard.  Not because Sensei has a plethora of great ideas.  That would be a nice problem to have.  Many times in software development you end up this guy:

This is the state where you have things you want to accomplish, yet even when you pair things down to the “essential”, other essential, critical factors must be taken into consideration before you create a mess.  This is life calling, and that string which suspends that giant sword that you noticed hovering over your head is about to snap.  There is a good chance that you need more discipline, better execution tactics, far better honed chops, you name the metaphor.  Sensei has been at this game for over 22 years, and still the speed that thought takes to become reality is way too slow.

With great sarcasm you can remind your self that some of the best work lays ahead, but the reality is that you still need to fight to be fluent, you have to claw your way to a Zen state of mind / no-mind.  So chose, the art of bushido or the art of BS.  Or maybe work smarter and enjoy life.

Before Sensei leaves you, ponder this:  does “being done” mean that you’ve dropped off a product but have to get on the phone in order to make changes, and maybe now that you are struggling why couldn’t you figure out to take time when it was more critical to be fluent with your productivity?

 

A Life Time In a Day April 5, 2013

Posted by ActiveEngine Sensei in ActiveEngine, Coaching, Mythology, Problem Solving.
Tags: ,
3 comments

If you are lucky, you can experience a life through the course of a day. Consider it the antithesis of ground hogs day. Instantaneous history, melancholy,!and certainty all at once. You are here, where do you go?

20130405-174801.jpg

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.

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.

Training the Young and Fluency July 28, 2010

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Coaching, Fluent, Mythology, Personal Development.
Tags: , , , ,
1 comment so far

Repeat with Sensei, if you will, the Wolf Creedo:

The Wolf Credo:
Respect the elders
Teach the young
Cooperate with the pack
Play when you can
Hunt when you must
Rest in between
Share you affections
Voice your feelings
Leave your mark.*


What have you done to nurture your team?  Are you the resident Elvis, and if the newbies make the cut they’ll graduate from a Mort to be the next King, hand plucked by you from millions and millions of people?  Can I get a little ka-ra-te with that?

What makes you an Elvis, and are you a bloated drunk Elvis at the end, or the bad-ass version 1970 version who can jump start anything?  Elvis in 1970 practiced the Wolf Creedo.  Watch the documentory Elvis the Way It Is 2001, just the first half hour.  This short half hour will show you Elvis, after years of being away from touring, ready to return to touring again in attempts to re-start his career.  The first half hour of the movie focuses on the few weeks of rehearsals before the debut concert.  Elvis had a fluent, incredible means of communicating with his band members and back up singers.  With a glance, a gesture, a wink, a new song would spring up.  Maybe Elvis would say a quick word, hum a note, and suddenly a bass line would kick in, and not more than three beats later, the entire band and Elvis are playing a tune complete with improves.  While playing Little Sister, Elvis nods, and issues “Get Back” and off the group goes playing Get back from the Beatles.  Congruent would be best word to describe the synchronization that each member had.

Elvis nurtured that vibe.  They all keyed off of him, for to the band he was Elvis, not the King.  He lead by being a focal point, but not necessarily an ostentatious leader.  When you watch the practice sessions where Elvis worked on the orchestrations of each song it is clear that he could communicate what he wanted, and worked with his band members to produce the product he envisioned.

But in order to function like this unit, each member has to practice.  You, as pack leader, have to pick the scales, the arpeggios, the rudiments that you want to be second nature so that your team, the young ones and old warriors can produce what you want, fluently.

*Credit:  Del Getz and Associates

Fail Often, Fail Fluently March 27, 2010

Posted by ActiveEngine Sensei in ActiveEngine, Agile, Fluent, Mythology, Problem Solving, software economics.
add a comment

What do you when your Scenario or User story just sucks? You’ve haggled with your peers over how to implement, the user has changed tunes and come over to your side of things by realizing that they want two things at the same time, but now that you’ve listened to everybody and re-worked your logic, you’ve just spend 6 or 7 extra hours testing. Now, you doubt that anybody really knows what the original intent of your use case was because there are so many different variants and vagaries from all the meetings, emails, hallway tests.

Now succumb to the brain death of Sarbanes-Oxley. Where is the traceability in all the discussion threads? How do you prove that you have what you want and that transactions are preserved and yada-yada-yada it just works? Before the project you thought that your team was like these guys:

But in reality you are this crew:

Sensei won’t pretend that there is a cool Zen technique to avoid hard work or failure. Maybe this type of failure of communication is a test of your core skills and your “fluency”. Look at the Elvis’ team. They’re practicing. They’ve been over the material again and again and again. That’s three again’s for each of the yada’s. To get to that point where they can adjust to his direction they’ve done much on their own time acquiring skills. Years of practice and adjustment.

Your project is like that path to acquiring a skill set, gaining mastery, being fluent. You have to build for flexibility, for

change. You CAN NOT give in to YAGNI just because this week you think you know all the answers. You won’t create a fan base that way. And just because something is written down does not mean that it’s set in stone. Remember Moses and the stone tablets? Even though he could part the waters he still had to go up the hill twice.  Things will go wrong, but if you put in the time your adjustments, while painful after a long haul, won’t be that bad.  6 hours could have been 6 days.  Be thankful you have good partners.

Why Your Code is a One Way Time Machine October 19, 2009

Posted by ActiveEngine Sensei in ActiveEngine, Agile vs Waterfall, Mythology, Problem Solving, software economics.
5 comments

What type of duress are you under?  The unfortunate among us have been sentenced to slavery by our evil nemesis from the past.  We all have this enemy, and at one time or another have succumbed to the enemy’s evil plot.  The enemy from the past is YOU.

2424601413_3ecda752e5_bWhen you sit down to create a solution, you need to balance solving the problem with being able to maintain and implement changes to the logic you have selected.  All logic changes, and there are very few times when you have the finite scope defined to be able to accommodate new ideas.  “Rewrite!” is the cry of many who have written good solutions that have solved the problem but more than likely are not very maintainable.  “Broken Cardinality” is the bane of all DBA’s, and this is very serious indeed.  Sensei can’t help you with that – go beat your business analyst who didn’t drive home the rules of relational databases!

What Sensei will say is put your tools after you think you’ve solved your users problems in a two week sprint, step back and project into the future:  will this code be readable; can you augment the logic without altering the methods; will you be happy with yourself at midnight trying to fix something?  Addressing these concerns helps you maintain your solution.

The real challenge is to help yourself next year.  The-future-you needs your help, but The-future-you will hate you if you misconstrue YAGNI in your design phase with avoid-refactoring-at-all-costs while you code.  Forget the sprint.  Putting something into a customers hands too soon masks the complexity of what you have done for them and undersells your true talents.  They’ll be happier if you can quickly implement changes without impacting the existing environment.  Congrat’s – The-future-you just bought a beer!