Nuestras cédulas y los servicios web dominicanos

Como desarrollador de aplicaciones para web y Facebook, mi trabajo incluye preparar formularios para captura de datos. Entre los datos solicitados por las empresas que se está volviendo erróneamente común, es la solicitud de la cédula de identificación personal, dato exclusivo, personal, que NO DEBE ENTREGARSE bajo ninguna circunstancia a nadie tal como haríamos con el número de seguridad de nuestras tarjetas de crédito.

Las empresas exigen ese dato supuestamente para confirmar la identidad y edad del usuario. En la web cualquiera puede ser cualquiera y tener cualquier edad. Se entiende la necesidad de las empresas de identificar los usuarios para evitar conflictos, pero la verdad tal cosa no justifica bajo ninguna circunstancia que tenga en su poder un dato tan importante del individuo.

Veamos el caso de Estados Unidos y su Social Security Number, que sería lo que para República Dominicana es la cédula. Quienes han rellenado formularios de concursos en Estados Unidos, confirmarán que no solicitan el social security entre los datos. ¿Para qué necesitan las empresas dominicanas el número de cédula?

Hablemos de un caso hipotético y una solución al mismo: Confirmar que soy la persona ganadora del concurso. Todo desarrollador al momento de guardar los datos del concursante en la base de datos, debe incluir un número de identificación único (ID) que habitualmente se genera de forma automática. Prefiero generar el ID combinando nombres y apellidos (o email en su caso) más un número al azar de 10 carácteres, encriptados con MD5. Eso crea un número único en nuestra base de datos.

Luego del usuario rellenar todos sus datos (excluyendo la cédula como debe ser), se le debe devolver por correo electrónico o algún panel un QR Code con el ID encriptado. De resultar ganador, deberá presentar en papel o en su móvil el QR Code para que la empresa organizadora del concurso pueda validar el ID. Naturalmente, si debe mostrar su cédula para certificar su edad, que se haga al momento de reclamar el premio, pero la empresa NO PUEDE quedarse con ese número ya que de todos modos no le servirá NI LE DEBE SERVIR PARA NADA MAS.

No existen razones para que las empresas exijan la cédula, es un dato personal y no debe compartirse. Espero que de alguna forma esta sugerencia tenga oidos, por respeto a la seguridad de los usuarios de nuestras aplicaciones.

by junihh Posted on April 11, 2012
Posted in Opinión, Tecnología | Tagged , , , , , , , | Comments Off

Las aplicaciones de Facebook y nuestros datos

Muchos recordarán el caso de Zynga en el pasado reciente, la empresa de aplicaciones para juegos sociales de Facebook más exitosa de todos los tiempos, quienes fueron descubiertos pasando datos de sus usuarios a empresas. Tal hecho fué todo un escándalo (sentando un precedente), primero porque actuó ilegalmente sin los permisos de sus usuarios y por infringir leyes de confidencialidad de Estados Unidos.

Ese siempre ha sido el temor de todos, la confidencialidad de nuestros datos, pero es un tema complejo de manejar cuando estos se encuentran en manos de otros individuos. En otro post escribí sobre los errores que cometemos los usuarios acerca del tipo de datos que liberamos. En ese post dejé bastante claro que yo y sólo yo tengo el verdadero control de lo que otros conozcan de mí. ¿Quiero tener un control total de mis datos e imágenes? La respuesta es simple: Cerrar el pico, dejar de escribir cuantas pendejadas se me ocurran, dejar de publicar fotos y dejar de rellenar cuantos formularios me presenten. Simple.

En aquel post no me veía como en la situación presente. En ese momento hasta tenía cerrado mi cuenta de Facebook, pero como la naturaleza obligada de las cosas es el cambio, ahora soy desarrollador de aplicaciones sociales en Facebook. He de dejar algo bien en claro, precísamente por lo que me dedico, ahora soy más cauto que nunca al momento de suscribirme a un servicio (social o de cualquier tipo), todo dependiendo del tipo de datos solicitados.

Servicios como Facebook guardan datos que manejados apropiadamente pueden decir qué tipo de gustos tienen sus usuarios. Veamos: Toda aplicación que pida los permisos “user_likes” tendrá la capacidad de capturar todas las páginas que siguen cada usuario. Así, si Fefita sigue 4 páginas con temas dedicados a moda, los desarrolladores podrán poner banners con dicho tema de sus propios clientes en sus aplicaciones.

Otro permiso muy solicitado por los desarrolladores es el de correo electrónico (“email”). Luego de capturado este dato, si el desarrollador pasa el listado de correos a sus clientes, podrían enviar spam incontroladamente, ya que recordemos que al momento de solicitar los permisos para el correo también damos permiso al desarrollador para… lo que sea, incluyendo spam sobre moda para Fefita.

Pero volvamos a un punto clave: Los permisos que damos a las aplicaciones que aceptamos en Facebook. Para tener claro cuáles son tales permisos y lo que se obtiene con ellos, sólo tenemos que echar un vistazo a la sección de autenticaciones y permisos en el API. Sobre el uso que se dan a estos es importante destacar la ETICA de la empresa desarrolladora.

Hace unas semanas visitaba el site de una famosa empresa que se iniciaba en el pago de sus servicios a través de la web. Personalmente deseaba que ofrecieran ese método de pago, hasta el momento de ver que entre los datos solicitados se encontraba el número de cédula de identificación personal. No voy a poner en duda a la empresa en cuestión ni a la que desarrolló su sistema, pero sentí temor de apretar el botón de enviar, porque no se de qué forma puedan manejar un dato tan importante como mi cédula para entregarla tan ligeramente.

Los datos que entregamos a Facebook ya no están en nuestras manos luego de rellenado los formularios de perfiles, subidas de imágenes o aceptación de permisos. Desde ese preciso momento, nuestros datos e imágenes PERTENECEN a Facebook o a los desarrolladores de aplicaciones, ya que ambos pueden manejar nuestros datos e imágenes cómo les plazca.

Cerraré repitiendo lo dicho en párrafos anteriores: ¿Quiero tener un control total de mis datos e imágenes? La respuesta es simple: Cerrar el pico, dejar de escribir cuantas pendejadas se me ocurran, dejar de publicar fotos y dejar de rellenar cuantos formularios me presenten.

by junihh Posted on April 11, 2012
Posted in Opinión, Tecnología | Tagged , , , , | 4 Comments

Y el navegador más usado en República Dominicana es…

Hace poco más de tres años creé y mantuve un website dedicado a informar todas las debilidades que sufren todo aquel que use Internet Explorer contra otras navegadores, al que llamé CeroE. Como diseñador web, tenía más que claro cuáles eran tales debilidades, que forzan a todo diseñador a tener que poner en práctica trucos y métodos para lograr un maquetado que luzca similar en todos los navegadores.

No han sido pocas las veces que me he “halado los moños” por la falta de estandarización de Explorer. Con Explorer 9 finalmente Microsoft comenzó a aplicar los estándares QUE DEBIO aplicar desde siempre sugeridos por la W3C, pero se tomó más de 10 años para que la competencia le hiciera entender que no son los únicos navegadores en el mercado.

En el mercado internacional, el único navegador que por mucho tiempo le pisó los talones a Explorer fué Firefox, pero este nunca ha impactado lo suficiente como para que los usuarios cambien. Desde la salida de Google Chrome la competencia se hizo más fuerte para Explorer, porque desde entonces la carrera de Microsoft, Mozilla y Google se volvió una “guerra a muerte”.

Nuestro país siempre ha sido influenciado por el mercado internacional, especialmente después de la popularización de las redes sociales. Facebook ha impuesto un antes y un después en el uso de internet y los más de dos millones de usuarios en República Dominicana valida ese dato.

Hace varios meses atrás Facebook comenzó a recomendar a Explorer 8 como el mínimo. Este navegador, aunque más “moderno”, lamentablemente todavía no cumple las expectativas que aparentemente los mismos usuarios exigían, por lo que comenzaron a inundar a través de las redes invitando a amigos y familiares a usar tal o cual navegador en contra de Explorer.

Tal influencia ha hecho mella en el uso de Explorer en nuestro país. Personalmente creía que aún Explorer era el más usado, hasta que nuestro buen amigo Juan José Calcaño a través de su cuenta Technocracia en Twitter informa unos números sorprendentes. Sólo hay que ver esta gráfica:

Gráfica estadística de navegadores en República Dominicana

  • Google Chrome = 44.29%
  • Internet Explorer = 25.8%
  • Firefox = 25.12%
  • Safari = 3.31%
  • Opera = 1.24%
  • Otros = 0.25%

Con estos números se sienta un precedente en nuestro país. Sólo con la suma de Chrome y Firefox (69.41%), Explorer se puede considerar prácticamente fuera de uso. Estoy más que seguro que ese 25% con Explorer son aquellos usuarios que usan el internet de sus empleos, el resto son usuarios más duchos con los navegadores.

Me alegro de este cambio. Debido a mi trabajo aún deberé luchar para que esos usuarios de Explorer puedan ver mis proyectos, pero es un número bastante influyente en la toma de decisiones por parte de nuestros clientes.

Explorer 9 ha sido un cambio dramático, pero tardío. Recuperar ese mercado que se ha mudado a Firefox o Chrome será un proyecto bastante difícil para Microsoft, aunque como próximamente se acerca el lanzamiento de Windows 8, se abre una brecha para “renacer” en el gusto del público. La buena noticia es que será con un navegador más estándar con las recomendaciones de la W3C, lo que garantizará menos halones de moño a mi trabajo.

by junihh Posted on March 8, 2012
Posted in Opinión, Tecnología | Tagged , , , , , , , | 2 Comments

Guardando data en localStorage

Junto con la llegada de HTML5 hemos visto muchas mejoras en la forma cómo guardar datos en el navegador local del usuario, tales como localStorage y sessionStorage, viniendo este último a reemplazar a los obsoletos cookies.

Tanto los cookies, como los sessionStorage y localStorage tienen limitaciones en la longitud de data que podemos disponer. Así, los cookies sólo permiten guardar hasta 4095 bytes, mientras que los sessionStorage y los localStorage soportan entre 8MB y 10MB dependiendo del navegador (justo la verdadera belleza de estos), de manera que podemos transferir data entre páginas temporalmente mientras el usuario navega nuestro site (sessionStorage) o podemos dejar data guardada localmente por tiempo indefinido -o hasta que el usuario limpie su navegador- (localStorage).

Ahora, enfoquémonos en la data guardada por tiempo indefinido. Para este efecto podríamos usar Web SQL o Indexed Database, pero sería demasiado si sólo necesitamos datos básicos tales como nombre, apellido, nacionalidad u otros, así que usaremos localStorage.

Conozcamos los métodos para manejar la data con localStorage:

Para guardar la data tenemos dos alternativas:

localStorage.setItem('nombre_storage','Mi data guardada');
localStorage.nombre_storage = 'Mi data guardada';

Para leer nuestro storage la temática es similar a la anterior:

console.log(localStorage.getItem('nombre_storage')); // Devuelve: 'Mi data guardada'
console.log(localStorage.nombre_storage); // Devuelve: 'Mi data guardada'

Para borrar el storage en cuestión:

localStorage.removeItem('nombre_storage');

Para conocer la cantidad de storages guardados en nuestro navegador (todos, incluidos los creados por otros websites):

console.log(localStorage.length);

Para borrar todos los storages (incluidos los creados por otros websites):

localStorage.clear();

Ahora vamos a lo mejor de localStorage: guardar objetos. Como parte del DOM, localStorage es un objeto, pero lamentablemente no permite guardarlos directamente, así que debemos convertir dicha data a cadena.

Asumamos que tenemos el siguiente objeto:

var dat = {
	nombre: 'Junior',
	apellido: 'Hernandez',
	edad: '[indecible]',
	nacionalidad: 'Dominicano',
	residencia: 'Santo Domingo'
};

Convertimos la data a cadena usando JSON.stringify:

var datStr = JSON.stringify(dat);
localStorage.setItem('junidata',datStr);

Luego, para recuperar la data en condición de objeto nuevamente la reconvertimos con JSON.parse:

var datObj = JSON.parse(localStorage.junidata);
console.log(datObj.nacionalidad); // Devuelve: Dominicano

Listo, a partir de ahora podemos guardar toda la data del usuario como un objeto y consultarla desde el mismo navegador, salvaguardando recursos de nuestros servidores. Claro, es importante destacar que los datos sensibles del usuario no pueden ser dejados a la ligera sin ser encriptados, así que mucho cuidado con ese detalle. ;-)

by junihh Posted on February 22, 2012
Posted in JavaScript | Tagged , , , | Comments Off

Usemos JSON

AJAX es una de las alternativas más comunes para la consulta de datos. Trabajar con javascript me resulta divertido, pero no pienso lo mismo de PHP. Vamos, PHP no es tan divertido cuando tenemos que consultar datos y refrescar la página, porque esta acción requiere mucho más procesamientos y validaciones que si usamos AJAX-PHP-JSON.

“Si tenemos la herramienta perfecta, puedes mover el mundo” decía mi padre y al trabajar con AJAX para consultas, realmente necesitamos pocas herramientas (funciones en todo caso). Primero veamos esa función que hace la magia del lado del usuario:

function xAJAX (app,rqs,fnt,isString)
{
        var xh = (window.XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject('Microsoft.XMLHTTP');
 
    	xh.open ('POST',app,true);
    	xh.setRequestHeader ('Content-type','application/x-www-form-urlencoded');
    	xh.onreadystatechange = function ()
    	{ 
    		if(xh.readyState == 4 && xh.status == 200) fnt( (isString) ? xh.responseText : JSON.parse(xh.responseText) );
    	};
 
    	xh.send (rqs);
};

¿Simple, no? Como vemos, a dicha función le debemos pasar cuatro parámetros, así que expliquemos para qué sirven cada uno:

  • app: Es la URL al PHP que hace las consultas a la base de datos.
  • rqs: Son los parámetros que necesitamos consultar, aplicado de la forma común variable1=valor1&variable2=valor2&variable3=valor3…
  • fnt: Una función anónima que se ejecuta luego que los datos solicitados están disponibles.
  • isString: Por su naturaleza PHP devuelve texto (string), pero como la idea de JSON es usarlo a modo de objeto en javascript, necesitamos parcear el texto devuelto. Dentro de la función tenemos “JSON.parse” que se encarga de ese procesamiento, pero si de todos modos necesitamos que la función devuelva texto, tenemos esta variable booleana (true/false). La función xAJAX siempre devolverá un objeto a menos que el usuario defina ese parámetro como true, entonces devolverá texto.

Ahora aplicamos la función en nuestro HTML de prueba:

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="es" xml:lang="es">
<head>
	<title>AJAX - Respuesta Object o String</title>
</head>
<body>
 
	<input type="button" id="btn-object" value="Request Object" />
	<input type="button" id="btn-string" value="Request String" />
 
<script type="text/javascript">
/* < ![CDATA[ */
 
	function xAJAX (app,rqs,fnt,isString)
	{
	        var xh = (window.XMLHttpRequest) ? new XMLHttpRequest() : new ActiveXObject('Microsoft.XMLHTTP');
 
	    	xh.open ('POST',app,true);
	    	xh.setRequestHeader ('Content-type','application/x-www-form-urlencoded');
	    	xh.onreadystatechange = function ()
	    	{ 
	    		if(xh.readyState == 4 && xh.status == 200) fnt( (isString) ? xh.responseText : JSON.parse(xh.responseText) );
	    	};
 
	    	xh.send (rqs);
	};
 
 
	var btObj = document.getElementById('btn-object')
	var btStr = document.getElementById('btn-string');
 
 
	btObj.onclick = function()
	{
		xAJAX ('app.php','exe=objeto&userid=12345',function(resp)
		{
			console.log( resp );
		});
	};
 
	btStr.onclick = function()
	{
		xAJAX ('app.php','exe=texto&userid=12345',function(resp)
		{
			console.log( resp );
		},true);
	};
 
/* ]]> */
</script>
</body>
</html>

Para este ejemplo tenemos a “btObj” que devuelve un objeto y “btStr”, que devuelve un string. Veamos como va la cosa del lado de PHP:

< ?php

$exe = $_POST['exe'];
$userid = $_POST['userid'];

$query = mysql_query( "SELECT nombre,apellido,email,pais,nacionalidad FROM tabla_usuarios WHERE id='$userid' LIMIT 1" );
$queryRow = mysql_fetch_assoc($query);

$nombre = $queryRow['nombre'];
$apellido = $queryRow['apellido'];
$email = $queryRow['email'];
$pais = $queryRow['pais'];
$nacionalidad = $queryRow['nacionalidad'];

if ( $exe == 'objeto' )
{
	$dat = array(
		"nombre" => $nombre,
		"apellido" => $apellido,
		"email" => $email,
		"pais" => $pais,
		"nacionalidad" => $nacionalidad
	);
	echo( json_encode($dat) );
}

if ( $exe == 'texto' )
{
	$dat = $nombre . " || ";
	$dat .= $apellido . " || ";
	$dat .= $email . " || ";
	$dat .= $pais . " || ";
	$dat .= $nacionalidad;
	echo($dat);
}

?>

Primero solicitamos los datos con xAJAX, diciendo a “app.php” que filtre con “exe” qué tipo de dato debe devolver (objeto o texto). A la misma vez paso con “userid” el id que debe consultar en la base de datos. En el caso de “btStr” defino a “isString” como true para que devuelva texto.

Los datos devueltos se imprimen en la consola del navegador (Chrome, Safari, Firefox Firebug, Opera Dragonfly).

¿Verdad que es simple cuando tienes las herramientas perfectas? ;-)

by junihh Posted on January 8, 2012
Posted in JavaScript, PHP | Tagged , , , , | 5 Comments

Preferir librerías de javascript o no: El dilema constante

Bueno, creo que este será uno más de esos tantos artículos sobre si conviene usar librerías de javascript como jQuery, MooTools u otros contra javascript puro, pero quiero dejar público mi opinión sobre el tema.

Se que jQuery y MooTools son las librerías usadas más comúnmente. No puedo dejar de darle crédito al hecho que por ser usado por una enorme comunidad, guardan el gran argumento de las correcciones a bugs y añadidos que permiten el soporte de múltiples navegadores, independientemente al sistema operativo que el usuario tenga.

Otra ventaja argumentativa es la cantidad de plugins disponibles, que aumentan drámaticamente la productividad y en su defecto, la entrega del proyecto. Es razonable puesto que no se hace necesario romperse la cabeza analizando cómo lograr tal o cual efecto si viene dado lo que me interesa lograr… y de gratis en la mayoría de los casos.

Siempre han sido argumentos válidos. Yo mismo he tenido conflictos con ciertas cosas que funcionan en un navegador y en otros no. En este caso tenemos el ejemplo de objeto.innerText, que curiosamente no funciona en el por muchos adorado Firefox (más curioso aún, sí funciona en Explorer 6 y 7). Es un bug que viene de años y Mozilla aún no determina solucionarlo, lo que forza a tener que aplicar objeto.textContent si necesitamos tomar el texto contenido en un objeto.

Razones hay demás para el uso de librerías, ¿pero de verdad son razones válidas? Mi respuesta es NO. Se que suena tajante, pero sin restar importancia a los argumentos mencionados, aprender a escribir javascript y aprender a lidiar con los problemas que presenta toma tiempo. Lo bueno del tiempo es que luego que aprendemos a escribir javascript nos volvemos productivos… aún sin una librería de javascript o plugin.

Vamos, una librería es una colección de funciones corregidas quién sabe qué cantidad de veces para mejorar su performance y/o eliminar errores. Lo mismo pasa con una función escrita en javascript puro. Si escribo una función que haga un efecto en particular, al reutlizar la misma función en otro proyecto quizás encuentre un error o se me ocurra otra alternativa para mejorarlo. Mientras más lo uso mejor… y es la misma función.

Pero no hablemos mucho, mejor un ejemplo. Imaginemos que tengo un grupo de fotografías en una página con la clase “.foto” y necesito que estas se disuelvan a 30% cuando se cargue la página. Escribimos algo así:

$(document).ready(function () 
{
  	$(".foto").fadeTo(1, 0.3);
});

Pero sólo necesito que haga tal efecto, no necesito nada más de jQuery. Es un problema, porque la versión minimizada pesa 94KB, cosa irracional a mi parecer si sólo necesito el efecto de desvanecimiento. Bueno, existen otras librerías más pequeñas como Zepto.js y XUI, pero aún así no nos permiten cosas puntuales, sino que hay que cargar todo lo que la librería ofrece.

Ese es mi tema, usar cosas puntuales para lo que necesitamos en lugar de cargar TODA UNA LIBRERIA. No olvidemos que una librería tiene X peso en KBs y si añadimos un plugin, este se suma al peso de la librería. Preferiría aplicar lo siguiente:

function trns (ob,tr)
{
	ob.style.MozOpacity = (tr / 100);
	ob.style.KhtmlOpacity = (tr / 100);
	ob.style.opacity = (tr / 100);
	ob.style.filter = 'progid:DXImageTransform.Microsoft.Alpha(opacity=' + tr + ')';
	ob.style.filter = 'alpha(opacity=' + tr + ')';
	ob.style.zoom = 1;
};
 
function fadeOutClass (clase,porciento)
{
	var obAll = document.getElementsByTagName('*'), vlInt = 8, vlFX = 10, porciento = Number(porciento);
 
	for (var x = 0, c = obAll.length; x < c; x++)
	{
		if (String(obAll[x].className).indexOf(clase) != -1) fx( obAll[x] );
	};
 
	function fx (ob)
	{
		var trns = 100, int;
		xTrns(ob,trns);
 
		int = setInterval(function()
        	{
        		if (trns < porciento)
        		{
        			clearInterval(int);
        			xTrns(ob,porciento);
        		} else
        		{
        			ob.trns += (0 - trns) / vlFX;
        			xTrns(ob,trns);
        		};
        	}, vlInt);
	};
};
 
fadeOutClass('foto',30);

Listo, hace lo que necesito y es extramadamente ligero, saltándose los exagerados 94KB de toda la librería de jQuery.

Otro tema que he notado de amigos desarrolladores que usan librerías de javascript es que sólo saben escribir basados en ellas y no conocen lo que está debajo. Me parece curioso que no sepan escribir algo que de hecho escriben, pero la justificación es obvia debido a que jQuery es un lenguaje de programación en sí mismo, como lo es Ruby on Rails, aquella famosa librería para Ruby que esconde todo lo “feo” o lo que el lenguaje básico no hace.

Mi sugerencia: Está bien que escribas basado en jQuery, quizás te pueda parecer más productivo y sacar tu proyecto a tiempo, pero date tiempo de aprender lo que está debajo de la librería para tener más control de lo que haces y no verte forzado a depender de lo que otros hagan (plugins), sin recibir a cambio el soporte técnico en caso de dificultad. Al final sales ganando.

De todos modos una pregunta de cierre: ¿Cuál es la belleza o romanticismo de escribir código si no lo escribes tú? Yo prefiero escribir mis funciones y código propio porque es lo que disfruto de mi trabajo. Espero no incluir jQuery u otras librerías entre mis recursos de trabajo.

by junihh Posted on January 4, 2012
Posted in JavaScript | Tagged , , , , , | 2 Comments

Películas en Mac: Lo que necesitas

Si eres fanático de las películas como yo y gustas disfrutarlas en tu Mac, acá te dejo las utilidades que necesitas para tener una mejor experiencia de usuario y pasar cómodamente el momento. Hablemos de las utilidades que uso para mejorar el volumen del sonido, controlar el equipo desde la silla sin tocar el teclado y mi reproductor favorito.

Mira

Si eres un afortunado que dispone de un Apple Remote, alguna vez te habrás preguntado cómo poder personalizar los botones. Por defecto, los botones de izquierda y derecha sólo permiten saltar a la siguiente película o la anterior en la lista de reproducción, lo que resulta molesto comparado con los mandos de TV.

Con Mira podemos personalizar el Remote por aplicación. Esto es ventajoso, porque el comando de avanzar o retroceder la película en VLC no es igual que en MPlayerX o iTunes, así que podemos reemplazar esos molestos comandos de siguiente-anterior, por avanzar-retroceder 10 segundos o cualquier otro. Esta utilidad trae un amplio catálogo de comandos predefinidos, pero también incluye una herramienta para escribir la combinación de teclas que necesitamos.

Desde que instalamos la utilidad encontramos un buen listado de aplicaciones comunes, pero podemos agregar más como MPlayerX en mi caso. Además de los botones siguiente-anterior y pausa-correr, podemos personalizar el botón MENU y subir-bajar. Estos últimos los tengo para subir y bajar el volumen, aunque a menú no le tengo nada asignado.

Más info: Twisted Melon

MPlayerX

En el renglón de reproductores de video en diferentes formatos en Mac sólo podemos contar dos: VLC y MPlayerX. Realmente existen muchos más, pero pienso que de todos estos son los mejores.

Durante mucho tiempo preferí VLC. Soporta muchos formatos entre los que se cuentan los RMVB, muy comunes para películas compartidas en Megaupload y otros por su alto nivel de comprensión del video con mínimos daños en la calidad de la imagen. Lamentablemente VLC es un PESIMO reproductor de ese formato y no sería para menos, porque quien haya visto alguna vez películas stop-motion, comparará estas con la forma como se ven los vídeos… aunque estos no sean stop-motion.

Las cosas cambiaron con el advenimiento de la Mac App Store. Poco más de dos meses después de su lanzamiento el desarrollador de MPlayer reescribió su software y mejoró hasta tal punto que a mi modo de ver se convirtió en el mejor reproductor de su tipo. Las películas en RMVB se reproducen con el mismo frame-rate que cualquier otra película en AVI, MP4, MKV u otra.

Incluye un buen manejador de colores, ecualizador, buen manejo del mouse para controlar el volumen del sonido, subtítulos y una interface muy elegante similar a QuickTime X. Lo único que odio de ese reproductor es la falta de un listado de reproducción similar al de VLC. El método que usa para reproducir múltiples películas (como en los casos que constan más de una parte) es arrastrando estos al ícono en el Dock mientras MPlayerX está abierto. Es un disparate ese método, pero es la única alternativa disponible hasta que el desarrollador integre una ventana para listados más acabado.

Más info: Niltsh

Boom

Muchos usuarios ven películas online en sus navegadores, refiriéndome específicamente a Megavideo, Cuevana y otros servicios en los que los usuarios comparten las películas. Personalmente no gustaba de esos servicios por las limitaciones que aplican y el no poder controlar la reproducción con mi Apple Remote y Mira. Como cosas de la vida llegó Netflix a latinoamérica con su enorme catálogo de películas, disponible las 24 horas del día al módico precio de US$7.99 mensual (RD$342.77). Esa oferta era irrechazable, especialmente porque me ofrecían el primer mes completamente gratis para probar el servicio.

Durante ese mes quedé enganchado y con él dejé a un lado la opinión de no ver películas en el navegador. No me quedaba otra alternativa, ya que no cuento con algún otros dispositivo de reproducción donde esté disponible Netflix aparte al navegador. Pero con la reproducción online se vino otro problema muy común: El volumen del audio puede ser muy bajo o en ciertas escenas el volumen es muy bajo pese a que el volumen de la Mac esté al máximo. Con la reproducción local no es problema, porque no es más que alterar un poco el ecualizador y listo, pero con las películas a través del navegador es “casi” imposible hacer algo.

Pero léase “casi”. Conocí a Boom, por el momento el único “booster” de sonido para Mac, aunque para Windows abundan. Al lanzarlo agrega un pequeño ícono en el top-bar con un barra para controlar el nivel del sonido. Advierto que el efecto del volumen es muy efectivo, tanto que podríamos dañar las bocinas si usamos la utilidad al máximo con mucha frecuencia. Cuando lo uso me aseguro de tener el volumen de la Mac al máximo y a Boom a no más de un 30%, pero no necesitan más allí para ver la película.

Cuando abrimos la ventana de la utilidad vemos que nos ofrece un ecualizador. Trae algunos perfiles como Movie, Music, Vocals, entre otros, pero podemos personalizar a gusto. También nos permite hacer boosting a archivos de audio y vídeos, pero la verdad no es de mi agrado, prefiero controlar el nivel del volumen o calidad del sonido con el ecualizador de iTunes o MPlayerX.

Más info: Global Delight Technologies Pvt. Ltd

Otras utilidades

No quiero dejar de mencionar otras utilidades que no deben faltar en tu Mac:

Perian: Es un extra para QuickTime buy popular. Permite reproducir en el QuickTime Player o en el Finder formatos que por si mismo QuickTime no soporta, como AVI, DIVX o FLV. Es bueno tenerlo porque podemos disponer de una prevista de la película, sin necesidad de abrir nuestro reproductor de películas favorito.

HandBrake: Creo que uno de los mejores (sino el mejor) convertidor de videos y ripeador de DVD’s que podemos contar en Mac. Es un infaltable, especialmente para aquellos que tienen iPod o iPhone.

Kigo Video Converter: Otro convertidor de videos, pero con un más amplio catálogo de formatos que HandBrake. Es el mejor convertidor de RMVB y WMV a otros formatos en Mac, pero para esto necesita la ayuda de un codec basado en MPlayer que instalamos adicionalmente.

Adapter: Otro convertidor en formatos muy variados, pero con la salvedad de poder descargar videos de YouTube y poder guardarlos en otros formatos o exportar el audio de estos.

NOTA FINAL: Mira y Boom son utilidades de pago, pero luego de usarlos por buen tiempo puedo afirmar que valen cada centavo que cuestan, así que eso no sea una limitante. Ambos ofrecen períodos de prueba. En el caso de Boom pueden descargarlo de acá para aprovechar el período de 10 días.

by junihh Posted on December 27, 2011
Posted in Mac | Tagged , , , , , , , , , , , , , | Comments Off

Capturar las variables pasadas por url con javascript

No gusto de pasar variables con datos importantes por el location bar por razones de seguridad, pero trabajando en un proyecto, me tocó el caso que debía usar javascript en lugar de PHP para capturar las variables enviadas. Hasta ese momento no había necesitado del efecto, así que busqué -infructuosamente- el cómo hacerlo. Los ejemplos que encontré me resultaban inútiles, porque eran muy específicos para los casos estudiados. Acá mi versión de cómo capturar tales parámetros.

Veamos el siguiente ejemplo:

http://junihh.com/?usuario=junihh&nacionalidad=dominicano

El ejemplo consta de sólo dos variables, pero en la forma como lo parcearemos podremos leer cuantos parámetros se pasen, similar a como funciona GET de PHP. Necesitamos tomar el valor de “usuario”, así que lo guardamos en una variable llamada “vr”. Luego tomamos la url del location bar y de esta sólo los parámetros pasados, que inician a partir de “?”.

var vr = 'usuario'; /* parámetro que se necesita */
var src = String( window.location.href ).split('?')[1];

Luego guardamos los parámetros en un array, tomando como referencia el símbolo “&” que se usa para concatenar cada variable de la cadena:

var vrs = src.split('&');

A partir de este punto ya todo el proceso será más simple. Ahora necesitamos iterar entre cada objeto de “vrs” por la variable que se necesita (vr). En este ejemplo usaremos el bucle “for” y en cada lapso nos aseguramos de revisar que existe un pedazo de texto similar al nombre de la variable que buscamos (“usuario”):

for (var x = 0, c = vrs.length; x < c; x++) 
{
        if (vrs[x].indexOf(vr) != -1)
        {
        	return decodeURI( vrs[x].split('=')[1] );
        	break;
        };
};

Si se encuentra tal parámetro, se detiene el for y devuelve el valor buscado. Ahora organicemos todo como una función para poder aplicarlo más fácilmente a nuestros proyectos:

function locationVars (vr)
{
        var src = String( window.location.href ).split('?')[1];
        var vrs = src.split('&');
 
        for (var x = 0, c = vrs.length; x < c; x++) 
        {
        	if (vrs[x].indexOf(vr) != -1)
        	{
        		return decodeURI( vrs[x].split('=')[1] );
        		break;
        	};
        };
};

Entonces lo probamos:

console.log( locationVars('usuario') ); /* devuelve: junihh */
console.log( locationVars('nacionalidad') ); /* devuelve: dominicano */

Listo. Puede ser servido frío y con mucho aderezo. ;-)

by junihh Posted on November 29, 2011
Posted in JavaScript | Tagged , , , , , | 7 Comments