Friday, May 31, 2013

Spatially Aware voice chat

help prioritize audio queues, reduce echoing (volume as function of distance)

Thursday, September 20, 2012

Bitcoin to grow 10x per 18 months.

Analysis shows Bitcoin to grow tenfold every18 months in the initial next few years.

Saturday, July 21, 2012

MtGox Pay button

I was curious how the MtGox pay button worked, and hoped it allowed you to accept credit card payments for deposit into gox, but was disappointed.

  1. your payee will need to have a gox account 
  2. can only pay you in bitcoin (you can specify a dollar/currency amount, but it's converted to bitcoin) 
  3. it reveals your username which might reveal your real name. 

oh well. for a free service, I'm not complaining. just thought you'd like to know.

reference: https://mtgox.com/merchant



Thursday, July 12, 2012

Bitcoin up sharply

BTC shot up today around midnight UTC today.



Some mild speculation as to the cause include Kim DotCom's request for a safe place to store and transfer funds for his legal defense, or attempts to manipulate the price and drive it higher.

I'm in the latter camp.  Stay tuned.

Thursday, August 18, 2011

Troubleshooting common errors and bugs in DataTables

This content has moved

http://sugar.armed.us/2013/06/14/troubleshooting-datatables/

Debugger basics for DataTables


We all write bugs. It's inescapable. It's as certain as Death and Taxes. What matters is how you deal with your code to root out bugs and squash them.

Debugging skills are fundamental to programming and this blog entry hopes to highlight several useful approaches and tools to discovering and fixing errors in your DataTables application.

We'll first go over a few methods of getting feedback from your program, then go over portions of debug tools that are almost universally provided with browsers. In a follow-up blog, I will list common issues and reasons - this section will be good for troubleshooting and hopefully help you fix your own bugs and not leave you stranded waiting for someone else to rescue you.

Simple Alert

Probably the easiest way to add debug help to your code is by including alert() calls or writing to a page or an element on the page. This is obviously most suitable for test environments and not your production release, but it's still a very useful and simple approach.

Using the debugger and console logging is a better idea and achieves the same thing, but let's consider the simplicity of this approach.

The idea of using alert is incredibly simple, but still useful because it can tell you several things: the value of variables or the state of your program, and how far along in your program the page got before it crashed.  The alert() function, of course, pops up a modal dialog box to alert the user with a value.


$(document).ready(function() {
    $('#example').dataTable( {
        "fnRowCallback": function( nRow, aData, iDisplayIndex, iDisplayIndexFull ) {
            /* Bold the grade for all 'A' grade browsers */
            alert ('the grade of row ' + iDisplayIndex + ' is ' + aData[4]);
            if ( aData[4] == "A" )
            {
                $('td:eq(4)', nRow).html( '<b>A</b>' );
            }
            return nRow;
        }
    } );
} );


In this example above, every time the fnRowCallback is triggered (for every row) we will get a popup alert telling us the index and the value of the grade column for that row.  This could be helpful if we were trying to make some values bold if the grade were 'A' and it wasn't working; if the the alert box gave us a value that wasn't a grade at all, it might have turned out that we were using the wrong column number.

A drawback to using alert() is that it's really going to interfere with the flow of the program because all code execution pauses until the user clicks OK (or dismisses the dialog).  And if we use this approach within a loop or with a callback function that gets called a large number of times, we might sit there clicking on dialog boxes all day.  Another approach would be to write the feedback to a DOM element and not require user interaction.  We can append the value of text to a DIV element we add to the page instead (note that I'm adding a BR to the end of each line):

// assuming we have a DIV with id = "output_div"

$(document).ready(function() {
    $('#example').dataTable( {
        "fnRowCallback": function( nRow, aData, iDisplayIndex, iDisplayIndexFull ) {
            /* Bold the grade for all 'A' grade browsers */
            $('#output_div').append('the grade of row ' + iDisplayIndex + ' is ' + aData[4] + '<br>\n');
            if ( aData[4] == "A" )
            {
                $('td:eq(4)', nRow).html( '<b>A</b>' );
            }
            return nRow;
        }
    } );
} );


We can add a little code to allow us to leave a lot of our debugging code in the file but turn it off when we don't want it.  With the JQuery code writing to the div, this can be as simple as deleting the DIV element or making it non-visible with .hide() or css { display: none }. For alerts, we could add a global variable and only output debug statements if it is true.


$('#output_div').hide(); // don't show the debugging div

$(document).ready(function() {
    $('#example').dataTable( {
        "fnRowCallback": function( nRow, aData, iDisplayIndex, iDisplayIndexFull ) {
            /* Bold the grade for all 'A' grade browsers */
            $('#output_div').append('the grade of row ' + iDisplayIndex + ' is ' + aData[4] + '<br>\n');
            if ( aData[4] == "A" )
            {
                $('td:eq(4)', nRow).html( '<b>A</b>' );
            }
            return nRow;
        }
    } );
} );


//// OR

var DEBUG = true;

$(document).ready(function() {
    $('#example').dataTable( {
        "fnRowCallback": function( nRow, aData, iDisplayIndex, iDisplayIndexFull ) {
            /* Bold the grade for all 'A' grade browsers */
            if (DEBUG) alert ('the grade of row ' + iDisplayIndex + ' is ' + aData[4]);
            if ( aData[4] == "A" )
            {
                $('td:eq(4)', nRow).html( '<b>A</b>' );
            }
            return nRow;
        }
    } );
} );



Let's get more sophisticated

Using alert() or an output div is pretty crude and you can accomplish the same thing with debugging tools already built into your browser or readily available as an add on (Chrome comes with a top notched debugger; FireFox has a great plugin called FireBug which is also top-notched that can be found at http://getfirebug.com/ ; IE comes with a rudimentary script debugger but you can upgrade to an improved Script Editor if you have MS Office 2003 and FrontPage 2002 installed or the much more powerful Visual Studio debugger if you own that package. i recommend installing Companion.JS which supports the console object.. see http://www.jonathanboutelle.com/how-to-debug-javascript-in-internet-explorer which also has a slideshow tutorial for IE debugging or http://www.my-debugbar.com/wiki/CompanionJS/HomePage for Companion.JS; for other browsers, check their webpages or documentation )


To make things work on IE, make sure your Internet Options settings are set to  allow enable Javascript debugging (see http://www.jonathanboutelle.com/how-to-debug-javascript-in-internet-explorer or http://blogs.msdn.com/b/ie/archive/2004/10/26/247912.aspx)

To use the Script Editor, you should have installed MS Office 2003 or FrontPage 2002.  I had to force this Script Editor to be installed; I did this by going into Excel, clicking on Tools/Macro Editor/Microsoft Script Editor and following the dialog to install the feature.

With the external Script Editor installed, you should view the debugger by going to View/External script debugger/Open  This did not work for me so I installed Companion.JS


Accessing the debugger is obviously important.  Here's some ideas how to get the debugger open.


Chrome - ctrl-shift-j  or right click a page and select "Inspect Element"

FireFox with FireBug - ctrl-F12 or click FireBug button on toolbar or right click a page and select "Inspect Element"

IE - F12 or select Tools/Developer Tools

IE with Companion.JS - click Companion.JS button on toolbar


The simplest approach to take with the debugger is outputting values similar to the alert() and output div methods above.  Most debuggers implement a console object with a .log() function.  This method of output is like writing to a div but vastly better because it gives you the entire object and lets you open up sub-objects and arrays to examine all the parts.  This is incredibly useful for getting to know the parts available in the DataTables oSettings object.


console.log( $('#example').fnSettings() );

// if your debugger is open you will have access to a copy of the oSettings object. but regular users who aren't running the debugger will never be exposed to this operation


a snapshot of my debugger's Console panel looking at the oSettings object


IE doesn't natively support the console object, so using console.log() calls, and leaving them in the code, will break things for your IE users.  This might be fixed in IE 9, but other IE users are still affected.



Anatomy of the debugger

This section will describe the common parts of a browser's Javascript debugger.  Chrome and Firefox's debuggers are very similar - for IE and other products you will have to make some adjustments to find the different elements.  My examples are from Chrome.



Elements / HTML / Source - view the web page source.  Many debuggers show the computed css values for elements selected and tell you where the attributes are defined.  It's also common for the debugger to highlight the element on the screen to make it easy to correlate an element.  When you right click an element on a web page and choose "Select Element" you are usually brought right to the element in the Elements / HTML / Source pane. It's also common for the debugger to show you a path heirarchy to the element (i.e. html > body > div > table) which allows you to click on one of those tags to jump to and select the entire element.

div "search_results" is selected and highlighted in the top viewport


Resources - All the files associated with this page



Network - Network resources AND TIMINGS!


If you click on one of the network resource files, for instance a server side script like my bookstore_json.php, you can view the parameters sent to the server and the XHR JSON response. 


Scripts - View the source code for any related scripts.  You can set breakpoints and "step through" your code line-by-line to find errors.  We will discuss this later. You can also set Watch expressions for variables you are interested in inspecting.
I have set a breakpoint at line 146. The code will pause there and let me step through my program.

Timeline - Advanced timeline and speed analysis

Profiles - Performance analysis

Audits - Feedback on best practices or warnings for your page

Console - real-time environment to view elements from console.log() or evaluate code and objects on your page
I actually changed a row/column value with JQuery with the console

Since the console is so useful, in Chrome you can open it in conjunction with any of the other panels in a split-screen mode by pressing the >= looking icon.
Split screen with Resources and Console panels

Break dancing

When the simpler debugging methods of using alert() or console.log() aren't revealing the root of your bug, and you've already examined the resources or network return values for AJAX calls and can't find anything out of the ordinary, you can use the debugger to go line-by-line and examine various variables and objects until you find the cause.

In the scripts panel, you can set breakpoints.  You can also set breakpoints by using the Javascript command debugger which will halt your program ONLY IF a debugger has attached itself and is viewing it - so it won't affect your regular users.

Remember that breakpoint I set in bookstore.js on line 146?  When I run my webpage, the debugger stops right there.  Just by mousing over various variables I can examine them.


I can use the buttons to resume, step over (run a line but if it's a function call don't go into the function), step into (run a line and if it's a function call go into the function), step out (run the rest of this function and pause after returning to whoever called it), or clear all breakpoints.

Because Javascript is an interpreted language, run on the client machine, you can walk through anyone's code, including DataTables, JQuery, etc., if you like.  Of course, some functions in Javascript are "native" functions that are provided by the system and written in C or other languages and you can't step into those, but you can step through any Javascript code.

PHP debugging?

The Javascript debugger is, of course, only going to let you debug Javascript code, and if you're using server side processing or AJAX sourced data you have some results that were generated with another language like PHP or ASP.  One thing you can do to examine how well your script is running is by adding objects, arrays, and variables to your return JSON.  DataTables needs you to return a few mandatory elements, but it doesn't know or care if you add extra things to it.  If you are having trouble getting your query to return the right values, you can add the query to your JSON result and examine it in the Javascript debugger's network panel.


//PHP server side script
    /*
     * Output
     */
    $output = array(
        "sEcho" => intval($_GET['sEcho']),
        "iTotalRecords" => $iTotal,
        "iTotalDisplayRecords" => $iFilteredTotal,
        "aaData" => array(),
        "sQuery" => $sQuery    // ADD $sQuery to the return JSON
    );

There are packages that allow similar debugging tools in FireFox and possibly other browsers for PHP code. I haven't used this yet, but http://www.firephp.org/ is one such project. All data is sent via response headers and will not interfere with the content on your page. However, make sure to only use this in your test environment, not on production pages.