Si lo traduzco se pierde el chiste .

Los emotíconos son:

:3
:(:)
:(|)
V.v.V
-<@%
~=[,,_,,]:3

Si los envías verás algo como:

Pero es más divertido si los ejecutas tú mismo, el gatito es el mejor

El Seguimiento de Pila se puede realizar con PHP o Javascript.

Para PHP usamos dos funciones, la primera es debug_print_backtrace() que lo que hace es imprimir la pila de construcción, y debug_backtrace() que retorna la pila para que manualmente sea impresa más adelante.

Veamos un Ejm, supóngase el siguiente código:

<?php

class Test
{	
	public function __construct(){
		echo "-- Constructor -- "."\n";
		$x = 4;
		$y = 7;
		$this->sumItems($x, $y);
	}
	
	public function sumItems($x = 0, $y = 0){
		echo "Suma: ".($x + $y)."\n\n";
		echo "Debug Print Backtrace:\n";
-		debug_print_backtrace();
		echo "\n";
		echo "Debug Backtrace:\n";
		print_r(debug_backtrace());
	}
}

$test = new Test;

Vemos en el Script, una clase llamada Test, con un Constructor, dentro del cual se hace un llamado a otra función llamada sumItems() que recibe dos parámetros ($x y $y) y luego los suma. Dentro de ésta función se efectúa la ejecución de las dos funciones de Seguimiento de Pila

Si ejecutamos el Script, tendremos un resultado como este:

-- Constructor --
Suma: 11

Debug Print Backtrace:
#0  Test->sumItems(4, 7) called at [/home/Yefb/Webdevel/Tests/posts/backtrace.php:9]
#1  Test->__construct() called at [/home/Yefb/Webdevel/Tests/posts/backtrace.php:22]

Debug Backtrace:
Array
(
    [0] => Array
        (
            [file] => /home/Yefb/Webdevel/Tests/posts/backtrace.php
            [line] => 9
            [function] => sumItems
            [class] => Test
            [object] => Test Object
                (
                )

            [type] => ->
            [args] => Array
                (
                    [0] => 4
                    [1] => 7
                )

        )

    [1] => Array
        (
            [file] => /home/Yefb/Webdevel/Tests/posts/backtrace.php
            [line] => 22
            [function] => __construct
            [class] => Test
            [object] => Test Object
                (
                )

            [type] => ->
            [args] => Array
                (
                )

        )

)

Fijémonos:
En el primer bloque encontramos las impresiones que se efectúan a lo largo del Script.
En el segundo bloque vemos el resultado de la función debug_print_backtrace() en el cual vemos cómo en dos pasos el Script llega hasta la función sumItems, especificando desde dónde se han llamado las funciones y qué parámetros se le han pasado.

En el tercer Bloque, vemos el resultado de imprimir con print_r() el resultado de la función debug_backtrace(). Como vemos es más detallado que el primero, ya dependerá de tus necesidades cuál usar.

Para hacer ésto con Javascript, tendremos que hacer uso de la consola de Firebug y/o Google Chrome, y ejecutar la función console.trace().

Veamos un Ejemplo:

function backtrace(){
	var item = 'Item';
	backtrace2(item);
}

function backtrace2(item){
	console.log(arguments);
	console.trace();
}

backtrace();

Dicho código hace casi lo mismo que el ejemplo en PHP.
Acá tenemos la respuesta:

["Item"]
backtracejs.js (línea 7)
backtrace()backtracejs.js (línea 3)
backtracejs.js()backtracejs.js (línea 11)

En la primera línea de la impresión (["Item"]) tenemos la respuesta de ejecutar console.log(arguments), y luego tenemos el resultado de ejecutar console.trace(), es decir la pila de construcción del Script.

Tranquilos, yo los perdono.

Vamos con una serie de artículos explicando algunas técnicas que nos serán útiles a la hora de trabajar con lenguajes de lado Cliente, principalmente Javascript.
En éste artículo voy a cubrir algunas técnicas de depuración con Firebug de Firefox; más adelante veremos las características especiales del Inspector de Google Chrome/Chromium y Opera Dragonfly. Con Explorer también se puede, pero no pienso dedicarle un artículo teniendo en cuenta que casi ninguno de mis lectores tiene tan mal gusto o es tan masoquista como para usarlo .

Los ejemplos que enseñaré funcionan casi Estándar en cualquier inspeccionador.

Comunicación con la Consola Javascript:

• Logueo/Envío de variables a la consola:
  Podemos enviar variables a la consola usando las función console.log(), console.debug() también sirve.
  Por ejemplo, si tenemos un Objecto y queremos imprimirlo por pantalla, no lo podemos mostrar con  document.write() o window.alert() porque nos imprimirá algo como “[object Window]“.
  Usando la consola, escribimos console.log(window) y obtendremos algo como esto:
   
  Donde se muestra el objeto Window con su propiedad location.href, si haces Click sobre él, se abrirá la pestaña DOM mostrando todas las características del Objeto, sus métodos y propiedades con valor.
• Logueo de Errors/Warnings/Infos por Consola:
  Puede resultar muy útil hacer logueos especiales por la consola de Firebug.
  Supongamos el siguiente código:
  

  var numero = window.prompt("Ingrese un número entre 1 y 3");
  
  if(numero){//Si se ha ingresado un numero
      //Ahora condicionamos el loggeo a mostrar
  	switch(numero){
  		case "1":{
  			console.debug("Valor 1 en Debug");
  			break;
  		}
  		case "2":{
  			console.warn("Valor 2 en Warning");
  			break;
  		}
  		case "3":{
  			console.info("Valor 3 en Info");
  			break;
  		}
  		default:{
  			console.error("Fuera de Rango o NAN");
  			break;
  		}
  	}
  
  }else{//Mostramos un error pues no se ha ingresado un valor
  	console.error("No se ha ingresado un número");
  }
  

  Este código lo que hace es solicitarle al usuario un número y mostrará un mensaje en la consola diferente dependiendo del número que se ingrese.
  Nótese que hago uso de los métodos Error, Warn, Debug e Info del Objeto Console.
  Para que sea “divertido” te recomiendo que pruebes tú mismo el Script, preferiblemente en Firefox con Firebug, pues Chrome/Chromium no diferencian el método Info y Opera DragonFly sólo reconoce el Log/Debug.

  Como puedes ver, es mucho mejor depurar variables por la consola, pues muestra más detalle sobre ésta, además de los condicionales  mensajes que podemos imprimir.
  Para terminar ésta primera parte vamos a ver el caso hipotético de que estemos tratando de ejecutar un scripts que llame al Objeto Console en navegadores que no lo tengan disponible/habilitado, en éste caso, el navegador tirará un error Javascript que detendrá el resto de la ejecución. Para evitar ésto, deberemos hacer uso del siempre útil try…catch:

  try{
  //Funciones que invoquen a la consola
  }catch(e){}//Capturamos el error pero no hacemos nada con él
  

  Ya veremos algunas otras cosas interesantes en los próximos artículos. De momento, por favor, deja de depurar con window.alert

Actualizacion: Al parecer no puedo dejar morir mi amado Infornética, así que luego de la despedida, lo vuelvo a despertar para continuar con mis entradas de Desarrollo Web. Arrebatos existenciales que nos da a veces .

Hola estimados lectores.

Como dice el título del post, termino el blog de manera definitiva.

Porqué esto?

Es sencillo, la temática se estaba perdiendo poco a poco, lo que en un inicio era un Blog de noticias informáticas, fué tomando un sentido Técnico y mi audiencia ya se estaba llenando de integrantes del mundo Linuxero. No quiero que el Blog pierda su escencia, por lo que dejaré éste Blog de manera indefinida y seguiré escribiendo mis entradas en mi Blog Personal.

Para el que me quiera seguir o leer, en éste nuevo sitio, escribo artículo sobre GNU/Linux, Desarrollo Web y aplicaciones Open Source.

También, me pueden “seguir los pasos” vía Twitter.

Saludos!

Ya como todos o muchos de ustedes saben, (A la fecha de hoy) soy un usuario “Novatillo” de GNU Linux, a finales de Noviembre del 2010 tomé la decisión y migré casi totalmente a éste Maravilloso Sistema Operativo.

Como toda buena persona que se inicia en éste SO, empecé con Ubuntu porque ví comentarios y opiniones que decían que era la mejor distro para empezar.

No había tenído casi ningún problema con Ubuntu, excepto los micrófonos de mi equipo, que nunca fuí capaz de configurarlos… por casualidad, leí sobre LinuxMint y muchas personas decían que era un Ubuntu mejorado así que me animé a probar esta distro. Me fué de maravilla con Mint,

mucho mejor que con Ubuntu, de hecho pude configurar mis micrófonos (No me pregunten cómo, porque fué suerte de principiante ).

Estaba contento con Mint, ya tenía todo configurado incluyendo mi entorno de Desarrollo Web, pero sentía que algo me faltaba, quería más acción… en los foros de Mint leí un artículo de una persona que exhortaba a los colegas a probar Arch a ver quién se atrevía. Como cosa rara en mí, me picó la curiosidad de una manera tremenda, leí sobre Arch en foros, opiniones… la Wikipedia… todo indicaba que era la distro que esperaba por múltiples razones, entre ellas, la complejidad de instalación y los famosos comentarios “…Aprendí mucho con la instalación de Arch…”. Sabía que era un reto y que aprendería en el camino muchas cosas, ah! y lo más importante, le iba a perder el “miedo” a la consola.

Típico, como en todo caso, mi primer intento con Arch, fué un fracaso y me quedé con Mint por unos días… en esos días, probé OpenSuse, Mandriva y otras, volví a Mint, inexplicablemente, volví a Ubuntu… pero no, yo quería retos. Me documenté un poco más y me aventuré con Arch hasta que pude instalarlo con KDE funcionando.

El comentario “…Aprendí mucho con la instalación de Arch…” se aplicaba a mi caso. Desafortunadamente, configurando cosas por aquí y cosas por allá, dañé todo el sistema como al mes de estar trabajando con ésta maravilosa distro, tenía que volverlo instalar, otro desvelo .

Por cosas del destino, no pude volver a instalar Arch, pues, mi único acceso a conexión era Wireless, y mis conocimientos no me alcanzaban para configurarlo sin conectar el equipo por cable al router, así que me metí con Fedora a ver qué tal.

DIOS! Fedora me gustó tanto como Arch! Yum no llega a la talla de Pacman, pero sí que es buen Gestor de Paquetes, y sus plugins Presto, Download Order y Fastest Mirror me ayudaron mucho a enamorarme de ésta distro. Su enfoque es perfecto, aunque difiere del de Arch (Principio KISS), se acomoda mucho a lo que necesito, para Desarrollo Web, es muy buena distro (Aunque con cualquiera puedes trabajar como programador web cómodamente, son gustos. ).

Un día, después de semanas usando Fedora, dañé el sistema (Se nota que soy inquieto, no? ), así que tuve que formatear mi equipo, no tenía el ISO de Fedora a la mano, así que volví a Ubuntu (Increíble) y no duró un día en mi equipo porque ante cualquier cosa que hacía me daba “Pantalla Negra”, instalé Mint y no duró medio día, no por mala distro, si no por Apt-Get que ya no me gustaba (Ni me gusta). Me creí “guapito” y volví con Arch, pero desafortunadamente, no pude configurar el Wireless, así que volví a Fedora una vez tuve la ISO nuevamente. Fedora + Gnome, un poco feo, pero mi equipo volaba.

No sé si será porque mi equipo sufrió más de 30 formateadas en menos de tres meses, pero un día dejó de funcionar y a los días revivió (Se tomó un descanso merecido) y decidí darle un último formato, ésta vez sería Fedora + KDE. Como siempre, Fedora vuela en mi equipo, pero hay algo que no me gusta… KDE no se lleva bien con mi Acer Aspire 5542, no sé porqué, hago cualquier cosa y “Pantalla Negra”. KDE es un escritorio Genial, me encata, es muy bonito, pero eso de la Pantalla Negra es desesperante, me da miedo tocar cualquier cosa porque temo que se me va a poner negro todo.

Debo decidir… La Belleza de KDE 4.6 sumado a la Pantalla Negra o la Estabilidad de Gnome sumado a su poca “Belleza”.

Si alguno de Uds queridos lectores sabe la razón de la pantalla negra, mejor que mejor, no quiero quitar KDE, pero mi equipo es para trabajar y no me convienen esos parones a cada rato . Tengo que comprar en los siguiente meses un Desktop, y si tengo acceso a Internet Cableado, sin duda dentrá ArchLinux y posiblemente una partición para Fedora, no lo puedo dejar atrás.

En conclusión a éste largo escrito, quiero decir… ArchLinux y Fedora son dos distros Grandiosas. Para Geeks, Aventureros, Novatos, Expertos, Locos, Amantes del GNU Linux. Creo que ha valido la pena pasar por tantas distros para darme cuenta de que para mi caso y mis necesidades profesionales y personales, éstas son las indicadas.

Respeto a Ubuntu y las otras distros, pero por cosas del destino, no se adecuaron a lo que quería o esperaba.

Se viene Gnome 3 ¿Será bueno seguir con KDE 4.6 o me aventuro?

Actualización:

- Ya me decidí por Gnome 3

- Completo entorno de Desarrollo Web en Fedora

Si eres usuario de Windows, este es uno de los programas que siempre debes tener a la mano, te puede sacar de tremendos apuros.

Recuva es un Software de la misma casa del Archifamoso CCleaner, que te ayudará a recuperar esos datos que por una u otra razón se hayan borrado de tu memoria USB o Disco duro accidentalmente y que desees recuperar.

La cuestión es sencilla, simplemente, después de instalado y abierto el programa, insertas la memoria en tu equipo y haces que Recuva te la detecte y la examine en busca de los archivos extraviados, tiene una interfaz intuitiva, por lo que es relativamente fácil seguir los pasos adecuados.

Recuva, luego de un proceso de Scan, te va a mostrar los archivos que has eliminado y el estado en el cual se encuentran, si se pueden recuperar o si ya son caso perdido .

cuando hayas elegido el archivo que requieres, lo seleccionas y luego le dices al programa que te lo recupere, así de fácil!

Nota: No les paso Screen porque estoy bajo Linux y no lo he instalado en mi equipo .

Continuando con los dilemas a la hora de escoger nuestras herramientas para trabajar el desarrollo web, vengo con otra de las consultas que más se hacen en la web :

¿Qué Framework Javascript Uso?

Es una pregunta muy dificil de responder, yo estuve  a punto de rendirme y no usar ninguno, trabajar a punta de Javascript Puro! .

jQuery, Mootools, Dojo, Prototype, Ext.Js, YUI…cual usar?

Les voy a hablar teniendo en cuenta los primeros tres. Los tres últimos, no los menciono, porque no los he usado ni me llama la atención hacerlo basándome en su bajo Performance, son muy pesados (O lentos?) según pruebas que he hecho.

Empecé (como muchos) usando jQuery, lo aprendí en muy poco tiempo, en unas horas, ya estaba yo trabajando con menús slider, desvanecimientos, movimientos, FadeIn, FadeOut, Toggles, selectores CSS avanzados, llamados Ajax por POST o GET …etc. Es un Framework muy bueno para trabajar el DOM, además de que tiene un rendimiento bueno, una comunidad extensísima, muchos plugins y casi cualquier desarrollador web lo conoce (Un punto a favor si tenemos en cuenta el tema de las ofertas laborales). Es el Framework usado por WordPress (No sé porqué, pero antes usaban Mootools) y otros muchos proyectos Open Source.

Si quieres aprender algo rápido, funcional y totalmente garantizado, además de una extensísima “cartelera” de plugins, jQuery es para ti.

Al tiempo, quise probar Mootools, me pareció interesante eso de ser modular y que es orientado a Objetos, de hecho, usé a Mootools  como Framework en un proyecto que tenía como ingrediente principal el JS y los llamados AJAX.

Mootools, hace facil el trabajo con clases y objetos, tener una aplicación totalmente Objetual es una ventaja de la cual no podemos disfrutar usando solo jQuery. Además del tema de las herencias, implementaciones, métodos y propiedades, algo que sin duda nos disminuye mucho el trabajo a la hora de programar. Desafortunadamente, eso tiene un precio, Mootools tiene una curva de aprendizaje un poco más larga, para conseguir algo hay que escribir un poco más que lo que se haría con jQuery, y además tiene un performance un poco más bajo que éste y no hay tantos plugins disponibles en la red.

Recomiendo que aprendas Mootools si te gusta lo objetual y estás dispuesto a escribir todo tú (Pues no hay muchos plugins). Además, si eres programador Joomla, es mejor manejar Mootools, pues éste es el Framework que usa, y lo carga por defecto. No es la mejor manera de trabajar ponerlo a que cargue dos Frameworks diferentes, uno porque es necesario y otro porque es el que conocemos. Aunque hay componentes que usan jQuery y que obligan a la aplicación a que cargue los dos. Si Joomla usara jQuery, todo sería más fácil, pero un poco más desordenado, pues, he visto la forma como éste CMS implementa Mootools y es de tomar como ejemplo el orden que maneja.

Con Dojo no me fogueado mucho, pues, es un Framework para uso un poco avanzado, es el más grande de todos y el que tiene mejor performance. Es el Framework mejor implementado por Zend Framework (Mi favorito) y no tiene una comunidad muy extensa, por ende, pocos plugins ha de tener.

De todos modos, es un Framework que tengo obligado, pues, como programador de Zend Framework, me conviene más , además, he visto las funciones que tiene y me sorprende todo lo que hace (Como el dibujo de gráficos vectoriales en 2D).

De momento, mi recomendación rotunda es que OBLIGADO debes aprender jQuery y Mootools. Los otros son opcionales, pero los primeros, obligatorios.

Segundo dilema solucionado.

¿Algún otro?

Mi Post Anterior cuenta mi experiencia la primera vez que intenté instalar Arch Linux.

Debo confesar, que lo escribí en medio de un sentimiento de frustración, pues, siempre me he caracterizado por ser una persona con mucha inquietud por las cosas y me sentido casi siempre capaz de hacer las cosas por intuición, así pude instalar el sistema base de Arch en aquella ocasión, pero no pasé de ahí, pues, mi intuición o comprensión al leer las instrucciones en la Wiki se me acabaron, necesitaba más conocimientos. Estudié un poco el tema, leí un excelente artículo de Post instalación de Arch Linux que me recomendaron y cuando me sentí listo, manos a la obra!

Desde mi punto de vista como novato, al iniciar la instalacion de Arch (/arch/setup) todo se va solo, es decir, no necesitas mucha ayuda para sacarlo adelante, el apoyo viene cuando te pones en tarea de configurar el entorno gráfico.

Les cuento qué hice…

Luego de la instalación y haber reiniciado el equipo, hice un “Pacman -Syu” para actualizar el sistema, algo que me ha tomado otra media hora y todo bien hasta ahí.

Luego “Pacman -S Xorg” para instalar el servidor gráfico, tenía que probar que estaba funcionando, pero no me acordaba cómo y no sabía usar Links (El navegador que trae Arch) para averiguarlo, así que seguí derecho y ejecuté “Pacman -S kde” para tener mi entorno de escritorio instalado. La descarga de KDE se ha demorado al menos unas 2 horas en mi equipo.

Cuando descargué KDE, modifiqué los Daemos en /etc/rc.conf y agregué a “hal, fam, kdm”, además modifiqué el archivo /etc/inittab para cambiarle unas líneas:

Esto:

id:3:initdefault:
# Boot to X11
#id:5:initdefault:

Por esto:

#id:3:initdefault:
# Boot to X11
id:5:initdefault:

Y  esto:

x:5:respawn:/usr/bin/xdm -nodaemon
#x:5:respawn:/usr/sbin/gdm -nodaemon
#x:5:respawn:/usr/bin/kdm -nodaemon
#x:5:respawn:/usr/bin/slim >& /dev/null

Por esto:

#x:5:respawn:/usr/bin/xdm -nodaemon
#x:5:respawn:/usr/sbin/gdm -nodaemon
x:5:respawn:/usr/bin/kdm -nodaemon
#x:5:respawn:/usr/bin/slim >& /dev/null

Eso sí, debo reconocer que entendía a medias esto, pero sabía que era algo que tenía que ver con el arranque de KDE . A mí lo que me importaba era tener a Arch instalado! No iba a volver a perder tiempo, ya llevaba toda una noche en ese paseo (Desde las 12AM hasta las 6) y quería que valiera la pena el esfuerzo.

Reinicié el equipo y arrancaba KDE, pero Menuda Sorpresa! Sólo iniciaba sesión en modo seguro!

Busqué mucho en internet y no pude dar con la respuesta, pensé que había hecho algo mal con la instalación, y luego de dos días sin poderlo solucionar, decidí reinstalar (Si, ya lo sé, fui muy tonto ). Esta vez, la instalación se me fue más rápido, pues ya lo había hecho y por ende tenía más confianza de las cosas. Desafortunadamente, el problema volvió a aparecer, ya no podía creer que me había equivocado en la instalación!

Algo me decía que en alguna parte del sistema debía haber archivos “.LOG” que me dieran la respuesta (No conocía /var/log ), así que hice una búsqueda de todos los archivos con esa extensión y vi que todos estaban en la carpeta /var/log, vi uno que me llamaba la atención llamado Xorg.0.log, lo abrí y vi varias líneas que hacían referencia a un error crítico, copié esas líneas y las pegué en Google y en un foro decía que hacían falta dos archivos por instalar: xf86-video-ati (Mi driver de la tarjeta gráfica) y xorg-input-drivers.

Luego de instalarlos y reiniciar, WOW!!!! Tenía KDE arrancando bien! Casi se me salen las lágrimas .

Faltaba algo, configurar el Wireless, esa fué otra pelea que me ha tomado medio día, pero cuando lo logré, me dí cuenta de que estaba trabado en una estupidez, me fué mejor instalando el Network Manager para KDE y listo, ahora sí tenía Wireless funcionando en mi equipo portátil.

Actualmente, tengo algunos problemas con LAMP, pero han de ser bobadas, solo es cuestión de dedicarles el tiempo que merecen.

En estos días que he estado trabajando con Arch, he aprendido un montón de cosas que ni me imaginaba cuando estaba con LinuxMint .

Por eso amo a Arch Linux y nunca me arrepentiré del tiempo que me ha tomado su instalación y configuración, es más, dudo que la deje para pasarme a otra distro algún día. El tiempo dirá .

Anímate a usar Arch! Es un viaje indescriptible, cuéntanos tu experiencia con esta distro. Yo lo pude instalar llevando sólo dos meses con Linux.

Mucha suerte con tu aventura.