i

I expect this feature has been around for quite a while already, but this is the first time I have seen it: stealthy browser object model improvements letting a web page figure out how many milliseconds ago it was loaded. It presumably works in any web browser that is Chrome or that runs the Google Toolbar:

function msSincePageLoad() {
try {
var t = null;
if (window.chrome && chrome.csi)
t = chrome.csi().pageT;
if (t === null && window.gtbExternal)
t = window.gtbExternal.pageT();
if (t === null && window.external)
t = window.external.pageT;
} catch (e) {};
return t;
}


In Chrome it (chrome.csi().pageT, that is) even reports the time with decimals, for sub-millisecond precision.

Anyone who has ever worked in a production environment knows that your users will find errors you have not even dreamed of. They will find your broken links, they will find your missing files, and yes they will find every database connectivity issue you hoped would never occur. Thankfully we are all great developers and sysadmins so we log everything we possibly can to find and remove these errors.

This is great at first but after a while log files become enormous and eat up lots of disk space. The problem multiplies when you start getting into a clustered environment (more than 1 server). You now have to read & maintain logs on 2+ machines which will most likely lead to neglecting your error fixing duties. Fortunately MongoDB recently hit the scene.

MongoDB
MongoDB is a scalable, high-performance, open source, document-oriented database. It’s ability to accept huge amounts of data very quickly make it perfect for application logging. It has built in support for auto-sharding & replication so when your application takes off mongodb will scale with you. It uses a JSON based storage system meaning you can give the database an object (from any programming language with support) and when you pull it back out of the database it will be the exact same as when you put it in. No conversion, no hassle, no bullshit.

# Fire Log Spark

Fire Log is a spark that lets you browse all the log files in your application/logs directory.

- You can filter what types of items you would like to view DEBUG, ERROR, INFO
- You can delete logs files from Fire Log to clear out your logs
- Fire log uses a view that you can easily customize in sparks/fire\_log/[version]/views/fire\_log_view.php
- You can change if tags are stripped in logs or not from the config
- Language file for all text used

AltFontPrev is a JavaScript bookmarklet that allows you to preview how any website would look if a particular font was not available or a different font chosen. Each font used to style elements on the page is listed under its selector and, when clicked, is moved from being a fall-back to being the primary font.

As well as choosing a font from the existing CSS declarations, you can type a custom font to override everything. Hopefully this will help you choose alternative fonts when perfecting your site’s typography.

window.onerror = function(mes,file,num){
alert([
"file : " + file,
"line : " + num,
"message : " + mes
].join("\n"));
return true;
}


with XMLHttpRequest
http://la.ma.la/misc/js/debugscreen/

function var_dump(obj) { if(typeof obj == "object") { return "Type: "+typeof(obj)+((obj.constructor) ? "\nConstructor: "+obj.constructor : "")+"\nValue: " + obj; } else { return "Type: "+typeof(obj)+"\nValue: "+obj; } }//end function var_dump

Dragg the following two links to your browser's toolbar (tested with Firefox 1.5 and IE 6) :
49.cl
49.sh

When you are writing some javascript embedded in a webpage and you want to debug your code, this gives you way to log things without alerting them.

Example :

// part of embedded javascript code
log49 = [];//log49 is global variable.
var num = 1;
log49.push('num = '+num); // log the state of num
num = num+1;
log49.push('second num ='+num); // again.



Then the two bookmarklets let you reset or view the log in runtime.
49.cl lets you reset the log by clearing the list stored in the global variable log49.
49.sh shows you the log by joining and alerting the value of log49.

I saw this bookmarklet here and it's beautiful. When you start it, it puts a textarea at the bottom of your page and you can type javascript in it, then eval()-uate it. Perfect! Only ... it doesn't work in frames. So I did the same thing but when you have frames (works without frames as well). The way mine works is - you first select some text in a frame, then you click the bookmarklet. A new textarea, ready to execute javascript will be placed in this frame (or iframe) that you selected. Also in this case when you type document.something, it refers to the document in the frame, not the frameset.
If you don't select any text and click the bookmarklet, it will place the textarea in the topmost document, so it will work for frame-free pages as well.

So here's the bookmarklet.
textarea eval

And here's a page where you can test.
Bookmarklet 2 - dump anything

After having my beautiful textarea, I wanted to be able to dump variables, like print_r() or var_dump() but for Javascript. I googled and I found this little script. All I did then is to make it a bookmarklet. How it works? You select the bookmarklet, it gives you a prompt, where you type whatever you want to dump, like document.location for example. Then it shows you an alert with all properties of this thing you typed. (Don't try to dump document though, or something else that recurses, because the script won't handle the recursion and will freeze)

As I develop primarily in and for WordPress, I have a few small Plugins in the test environment active, which ease my view on certain data, and which specifically save errors or issues in WordPress. A small list with short explanation of Plugins, even if I don't use all of them, but there might be one or two in this list you like.

* WP Developer Assistant - because it has some reports and feature, which are very handy
* CodeStyling Localization - because you can create a Plugin multilingual, it's easy to create new language files
* Log Deprecated Calls - not always in use, but can be useful
* Error Reporting
* Debug Queries - Analysis of queries
* Debug Objects - Evaluates many values
* Adminer - for the fast access to your webspace or as Plugin directly in your WordPress
* FirePHP - as Plugin for WordPress to access specific content without crawling through your source code
* WordPress Hook Sniffer - interest idea; bad is the replacing of the core-file plugin.php

That should be enough, even there are many more for sure. The decisive factor, in my view are not the Plugins, but the environment with xDebug and the settings that WordPress offers as standard in this context. Therefore, I can only recommend to have the following lines in the wp-config.php of the environment.

1. sys_getloadavg()
2. pack()
3. cal_days_in_month()
4. _()
5. get_browser()
6. debug_print_backtrace()
7. metaphone()
8. natsort()
9. levenshtein()
10. glob()

The arguments object in JavaScript is a local variable in any function that provides some nice features we can use in our code. Here is the list of its properties and related properties of the Function object.

arguments itself returns an object that looks like an array (but not really an array) of the arguments passed to the function.

Prior to JavaScript 1.4 the Function object also had a similar arguments property, which is now deprecated.

However the Function object comes with a few other useful properties that we can still use to get argument related data.

Modern web applications almost all make use of AJAX to enhance their user appeal. However, AJAX can be hard to debug, especially when all the traditional tools do little to help. When doing standard PHP coding CodeIgniter (CI) offers a profiler which will be appended to the bottom of generated pages. This gives you information on the request that was recently processed, including any POST or GET values passed to the script, how long execution took and how long any SQL queries took as well as what those queries actually were. During development I find this information indispensable to make sure my SQL queries are correct and things are working as I want.

However, when coding up AJAX aspects of the application this doesn’t work very well, any page fragments fed back to the JavaScript will have the profiler stuck at the bottom, and since these fragments are usually inserted inside DIVs the profiler cannot be read in it’s entirety, or it breaks the layout, or more likely, both of the above. Therefore I set out to find a way of making it AJAX compatible, so that it would always end up at the bottom of the page, even when it was originally returned appended to a page fragment. In the end this turned out easier than anticipated.

As coders, I’m sure we all know the value of good error handling. So I thought a quick post about how Codeigniter deals with those pesky errors would be a good post.

The way I see it, there are 2 types of errors we have to work with. The ones which are displayed out in nice friendly text to your users, and the type which are hidden and shown only to you as the coder to figure out where something has gone wrong. CI provides the means to do both, thankfully.

To put it simply, Krumo is a replacement for print_r() and var_dump(). By definition Krumo is a debugging tool (initially for PHP4/PHP5, now for PHP5 only), which displays structured information about any PHP variable.

A lot of developers use print_r() and var_dump() in the means of debugging tools. Although they were intended to present human readble information about a variable, we can all agree that in general they are not. Krumo is an alternative: it does the same job, but it presents the information beautified using CSS and DHTML.

AJAX improves user experience by moving more code to the browser. Frameworks accelerate development, but lead to opaque application behavior and new performance issues.
dynaTrace AJAX Edition aims to solve these issues:

* Understand performance as real users experience it
* Differentiate between browser or server bottlenecks
* Trace asynchronous JavaScript executions for the full round-trip
* Analyze JavaScript, AJAX remoting, network and rendering performance in real-time
* Save performance data for interactive offline analysis
* Transform Selenium/Watir tests into performance tests and integrate them with your CI environment

So I wanted to add a new build phase to my Xcode Project to run some shell script. It didn’t want to work and I’ve tried to find out why it didn’t work so I’ve tried some Logging. That turned out to be a bit tricky first as i’ve set Xcode to hide all messages and only show warnings and errors. To work around this you simply need to create warnings or errors. That’s pretty easy actually as you only need to write “warning: ohoh” or “error: meh” and Xcode will automatically annotate the message as warning or error: