Últimas Publicaciones

El futuro de nuestros escritorios

Hoy, cualquier persona que trabaje en una oficina, realiza sus tareas con una computadora, la mayoría tenemos una computadora en nuestros hogares, y los que usamos una computadora, queremos realizar nuestras tareas rápidamente. Nadie quiere perder tiempo abriendo una aplicación, o buscando entre una pila de aplicaciones abiertas, el procesador de texto al que queremos acceder. Soy de lo que piensan que una computadora tiene que ser como cualquier electrodoméstico: si necesitas leer el manual para usarlo, no sirve. La computadora debe ser rápida, nos debe ayudar, no entorpecer o ralentizar.
Todos los sistemas operativos gráficos populares, utilizan un sistema de “ventanas” para brindar acceso a las aplicaciones. Este enfoque está muy arraigado, es muy simple y eficiente, por lo que es difícil que sea erradicado. Sin embargo, la capa superior: el escritorio, no funciona tan bien.
Microsoft, Apple y los sistemas de ventanas para los sistemas operativos tipo UNIX, desde hace mucho tiempo, vienen luchando con sus escritorios para hacerlos más amigables, pero nadie, hasta ahora, pudo ofrecer una interfase gráfica con la que el usuario pudiera sentirse cómodo. Esto es: que la curva de aprendizaje fuera lo más empinada posible (corto tiempo de aprendizaje), que fuera casi intuitivo, rápido, que ofreciera la información estrictamente necesaria y que solamente con un click, el usuario pueda tener toda la información disponible, en una pantalla simple e intuitiva.

Marcando los pasos de la evolución

Xerox fue la compañía que desarrolló la primer interfase gráfica: la Xerox Star o Xerox 8010. La interfase de la Xerox Star fue la que marcó el camino para todos los sistemas operativos con interfase gráfica que conocemos.
Posteriormente, varias empresas, siguiendo esos pasos iniciales, solamente mejoraron sus interfases, fuertemente marcadas por la Xerox Star, en base a lo que los procesadores y las placas gráficas le permitían (efectos gráficos, transparencias, más colores, bordes de ventanas redondeados, etc), pero ninguna interfase gráfica desarrolló nada innovador, que le diera al usuario la posibilidad de desenvolverse más rápida y cómodamente que lo que la original Xerox Star le permitía. Hasta ahora los cambios fueron tímidos. una barra de tareas, un dock, pero lo que realmente acelera nuestro trabajo, nuestro acceso a la información y su procesamiento, no se hizo presente hasta ahora, las interfases gráficas no han aportado nada.

GNOME, el revolucionario

Desde su versión 1.0 de 1999, GNOME viene aportando más a las interfases gráficas que sus pares, y en esta versión pronta a salir, no podía dejar de maravillarnos. GNOME 3 (http://gnome3.org/) definirá como se trabajará en los entornos gráficos. GNOME3 es una mezcla entre la potencia de los entornos gráficos para escritorio y la versatilidad de los diseñados para tablets o netbooks.
El escritorio de GNOME3 es simplista en extremo, una barra superior nos muestra, a la derecha, el nombre del usuario con sus opciones, (en la imagen se ve el menú de opciones desplegado), y a continuación, algunos indicadores comunes, como estado de la batería, señal de WiFi, red, y sonido, al centro, la fecha y la hora, que al hacerle click, se abre un panel de información y accesos al calendario, y a la izquierda, se ve el botón de actividades. No pidamos más, el escritorio de GNOME es minimalista al extremo, diseñado para la productividad.
La mayoría de los manejadores de ventanas de Linux, brindan la posibilidad de acceder a varios escritorios virtuales, entre los cuales se puede cambiar pulsando una combinación de teclas, generalmente CTRL y algunas de las teclas de dirección, en el caso de GNOME 3, los escritorios están apilados, para pasar de uno al otro, debe presionarse simultáneamente la tecla CTRL y alguna de las flechas superior o inferior. En cada escritorio podremos tener abiertas aplicaciones.
Cuando estamos trabajando en un entorno gráfico (propiamente llamado desktop manager), colocamos en el escritorio, los accesos a las aplicaciones a las que accedemos más comúnmente. Pero esto tiene el inconveniente que si tenemos alguna aplicación (ventana) que cubre el escritorio o por lo menos, la parte del escritorio donde se encuentra este acceso, debemos minimizar la aplicación.
Otro inconveniente que afecta a la productividad, es el cambiador de ventanas (Alt+Tab), cuando cambiamos de ventanas y tenemos varios navegadores abiertos, tendremos que cambiar a cada una de estas ventanas para ver su contenido, y así, llegar a la que necesitamos.
Y un gran inconveniente lo tenemos cuando intentamos encontrar una aplicación después de haber instalado todos los programas que necesitamos, que generalmente son muchos. El primer paso es clickear sobre el menú inicio, el segundo es posicionar el mouse sobre “Todos los programas” y esperar a que se abra la enorme lista que abarca dos columnas, el tercer paso, con suerte, es abrir el menú de la aplicación y en ese momento (siempre y cuando nuestra aplicación no se encuentre en “Accesorios”) clickeamos sobre su acceso para que se abra.
Todo esto lo realizamos mientras el sistema operativo se toma su tiempo para cumplir con cada uno de nuestros pedidos.
En GNOME 3, tendremos todo esto, en una interfase simple, rápida y clara con solo llevar el puntero del mouse a la esquina superior izquierda. Esto nos mostrará una especie de “centro de actividades” donde podremos manejar los escritorios, las aplicaciones en ejecución, la lista de programas instalados en una lista muy ordenada y una columna con los accesos a las aplicaciones más comúnmente utilizadas.
En este ”centro de actividades” podemos ver, a la izquierda, la barra con las aplicaciones más comúnmente accedidas, en el centro, una vista en miniatura en tiempo real de las aplicaciones corriendo en el escritorio actual, y a la derecha, cada uno de los escritorios ocupados con aplicaciones.
En la parte superior, cerca de la barra de la izquierda, veremos dos botones, Ventanas y Aplicaciones, (Windows y Applications), con cada uno de estos botones, podremos acceder a una sección diferente del “centro de actividades“. Inicialmente, al llevar el puntero a la esquina superior izquierda, accederemos a la sección de Ventanas.
Al clickear sobre el botón Aplicaciones, accederemos a la sección de aplicaciones, desde la que podremos lanzar cualquier aplicación de dos maneras: Seleccionando desde el menú de la derecha, el tipo de aplicación a la que queremos acceder, o buscándola por su nombre o tipo.
En la parte superior derecha del “centro de actividades” se encuentra el cuadro de búsqueda. Mediante este cuadro, podremos encontrar documentos o aplicaciones rápidamente. Este cuadro de búsqueda, nos mostrará los resultados categorizados.
En http://gnome3.org/tryit.html pueden descargar un Live CD para disfrutar de las ventajas que este “desktop manager“, nos dará oficialmente en abril de este año, el salto tecnológico más importante, desde la aparición de la Xerox Star.
Les dejo un par de videos para que puedan ver el comportamiento de GNOME 3. Sin duda, este entorno determinará como interactuaremos con nuestras computadoras, por que, todos sabemos, que, por suerte, las grandes empresas, copiarán esta forma de trabajar.

¿Les dije que todo esto es Linux? :D

GNOME 3.0 – Un nuevo concepto de interface gráfica

gnome_logo

Con fecha de lanzamiento programada para marzo del 2011, GNOME toma la punta en el concepto funcional de las interfaces gráficas con su nuevo GNOME Shell, que será completamente funcional y estándar en GNOME 3.0

Una interface gráfica orientada a las actividades, extremadamente pulida y simple, para no perder tiempo. Un salto de GNOME que obviamente hará temblar, no solo a KDE sino a Windows, y hasta al Leopard de la Mac.

Y la historia se vuelve a repetir. Como todas las innovaciones del mundo UN*X, y en los últimos años, de Linux, Apple y Windows copiarán este concepto y lo publicitarán como propio.

Volviendo a GNOME Shell, ya hay videos que explican perfectamente este concepto, por lo que me ahorraré palabras. Les dejo algunos.

 

 

 

 

 

PHP – ¿Como ligar nuestro código a una máquina?

php

Cuando entregamos un desarrollo podemos permitir que sea instalado en una cantidad indeterminada de máquinas o podemos entregar unidades, facturar cada una de las copias instaladas. Sin embargo, el control fue siempre unos de los puntos débiles de las licencias. Todo desarrollo es vulnerable, todo software es “crackeable”, solamente podemos hacer lo más duro posible el camino.

Hay varios métodos para controlar las licencias de software, una de las más populares es las que les contaré. Supongo que este método debe tener un nombre… puede ser… diría que seguro, pero no importa.

El método sin nombre

Básicamente tenemos que contar con una base de datos, un servidor con Apache y PHP con safe_mode = off

Creamos una tabla que tenga al menos dos campos para almacenar cadenas de texto, uno para almacenar un identificador único de cada copia de nuestra aplicación, y el otro para almacenar el identificador de la máquina donde está instalada dicha copia.

La copia, al instalarse, extrae el identificador de la máquina y lo envía al servidor junto con el identificador de la copia, el servidor almacena el identificador de la máquina en el registro donde se ubica el identificador de la copia, siempre que el campo de identificador de la máquina esté vacio (que sea la primer instalación). Cada vez que se ejecuta, extrae el identificador de la máquina y lo envía al servidor junto con su identificador de copia, si el servidor reporta que el par existe, continúa la ejecución, si no, se cancela.

Este método parece ser uno de los más seguros, sobre todo si los datos con el servidor se intercambian con un encriptado fuerte para impedir la posibilidad de la intercepción. Sin embargo, no todos nuestros clientes instalarán nuestro soft en máquinas con acceso a internet, de hecho, dentro de las empresas, lo más probable es que la máquina donde se instale nuestro soft tenga un acceso muy limitado o nulo a internet. En estos casos no queda otra posibilidad que la de intercambiar llaves, es decir, que el soft, en el momento de la instalación entregue llaves que el usuario nos enviará por eMail, y le responderemos con otra llave que el soft interpretará como válida, es decir: la validación se hará por eMail. Obviamente este método es menos seguro por que tendremos que almacenar el identificador generado en la máquina (obviamente fuertemente encriptado) y consultarlo en cada ejecución.

Pero me estoy diversificando, retomo el camino.

Estamos apuntando a PHP.

¿Como ligar nuestro código a una máquina en PHP?

Para “ligar” nuestro código a una máquina específica, necesitamos obtener los datos de los componentes de hardware de esa máquina. ¿Por qué? Por que los componentes de hardware casi nunca cambian, mucho menos si tomamos los seriales del disco rígido donde se encuentra instalado nuestro soft o del procesador.

PHP es un lenguaje que no tiene acceso de bajo nivel al hardware que lo soporta, y como todo lo “fijo” en una máquina es hardware, es virtualmente imposible obtener un identificador de máquina con PHP, al menos que PHP esté corriendo con la opción safe_mode en off.

Entonces, ¿como obtenemos los datos del hardware?

Debemos ejecutar algún comando propio del sistema que nos brinde los datos necesarios.

Hay dos formas:

  1. En Windows, utilizando las comillas invertidas
  2. En UN*X, con la función shell_exec

Uno de los comandos más comunes en todos los sistemas operativos que puede brindarnos algún dato de hardware es el de configuración de la interface de red, que nos mostrará la dirección MAC (identificador mundialmente único) de la/ placa/s de red. En Windows: ipconfig, en UN*X: ifconfig

Usaremos estos comandos por que son comandos utilizados por muchas aplicaciones y el sistema se basa en ellos para el correcto funcionamiento de las conexiones de red, esto significa que las posibilidades de que estos comandos sean reemplazados por comandos creados por un usuario para engañar a nuestro soft, son remotas. El sistema fallaría.

Veamos el código

<?php

//***************************************************************************

// Para sistemas Windows
function extraerMACWindows()
{
    // booleano para indicar que el siguiente campo es la MAC
    $MACexiste = false;

    // ejecutamos el comando y almacenamos su salida
    $cadmac = `ipconfig /all`;

    // almacenamos cada línea en un string del array
    $macseparada = split("\n",$cadmac);

    // recorremos cada línea del array
    foreach ($macseparada as $valor)
    {
        // separamos cada línea en nombre y valor
        $valorSeparado = split(":",$valor);
        // leemos cada campo: nombre y valor
        foreach ($valorSeparado as $linea)
        {
            // si es la dirección MAC…
            if ($MACexiste)
            {
                // retornamos la cadena
                return trim ( $linea );
            }
            // si en el nombre encontramos el título de la dirección MAC
            // indicamos que el siguiente valor es la dirección MAC

            $ttlEsp = “dirección física”;
            $ttlIng = “physical address”;
            if ( strstr ( strtolower ( trim($linea) ), $ttlEsp ) ||
                 strstr ( strtolower ( trim($linea) ), $ttlIng ) )
                $MACexiste = true;
        }
    }

    // si llegamos a este punto, hubo un error
    // en la extracción de los datos

    echo " ";
}

//***************************************************************************

// para sistemas UN*X
function extraerMACLinux()
{
    // booleano para indicar que el siguiente campo es la MAC
    $MACexiste = false;

    // ejecutamos el comando y almacenamos su salida
    $cadmac = shell_exec("/sbin/ifconfig");

    // almacenamos cada línea en un string del array
    $macseparada = split( "\n", $cadmac );

   // recorremos cada línea del array
    foreach ( $macseparada as $valor )
    {
        // separamos cada línea en nombre y valor
        $valorSeparado = split ( " ", trim($valor) );
        // leemos cada campo: nombre y valor
        foreach ( $valorSeparado as $linea )
        {
            // si es la dirección MAC…
            if ( $MACexiste )
            {
                // retornamos la cadena
                return trim ( $linea );
            }

            // si en el nombre encontramos el título de la dirección MAC
            // indicamos que el siguiente valor es la dirección MAC

            if ( trim( $linea ) == "HWaddr" )
                $MACexiste = true;
        }
    }

    // si llegamos a este punto, hubo un error
    // en la extracción de los datos
    echo " ";
}

//***************************************************************************

function extraerMAC()
{
    // para sistemas Windows
    $mac = extraerMACWindows();

    // para sistemas UN*X
    $mac = extraerMACLinux();
    if( strlen ( $mac ) > 0 )
        return $mac;
    else
        return "ERROR";
}

//***************************************************************************

echo extraerMAC();

?>

Vuestra primer tarea de aquí en más es reducir las dos funciones extraerMACxxx() a una.

Recuerden que lo más importante de esto es que conviertan todo su código a bytecode, si no, estas funciones no tendrían sentido.

PHP – bytecode – protegiendo nuestro código

php

Hoy domingo, día de descanso en mis tareas laborales, solamente un fanático puede dedicarse a escribir un artículo sobre sus herramientas de trabajo. La programación y los sistemas son mi pasión, no me imagino viviendo en una sociedad donde no existan las computadoras… aunque… creo que a todos los que trabajamos en sistemas, si nos sacan las computadoras nos dedicaríamos a las matemáticas. Bueno, por lo menos no nos suicidaríamos.

Mientras suena Iván Noble, y con el servidor prendido, les voy a contar como proteger nuestro código PHP

Basta de “cháchara” decía el gordo embustero y vayamos al grano.

En una Web donde prevalecen los CMS, deberíamos proteger a muerte nuestro código PHP que nos da de comer. Pero ¿como proteger el código de un lenguaje interpretado? Simple: facilitándole el trabajo al intérprete.

Funcionamiento del intérprete PHP

Dibujo1

Cuando el navegador Web realiza una petición de una página PHP, Apache le entrega la petición al intérprete PHP, este levanta la página peticionada, la convierte a bytecode, ejecuta ese bytecode y entrega el resultado a Apache para que lo entregue al navegador.

El intérprete convierte (pre-compila) el archivo PHP a bytecode para acelerar la ejecución. Este archivo bytecode es ilegible, y esto es lo que debemos conseguir para, de alguna manera, encriptar nuestro código.

Pre-compilando los archivos PHP, además de hacer ilegible nuestro código, aceleramos la ejecución al desligar al intérprete de la tarea del compilado.

¿Como convertimos nuestro código PHP a bytecode?

Existen dos métodos completamente gratuitos y absolutamente confiables: Zend Optimizer+ y Monas Encoder. El primero solamente interpreta el archivo en bytecode, el segundo compila a bytecode y además interpreta.

Zend Optimizer+

logo Zend es la empresa creadora del lenguaje PHP. Zend ofrece un compilador a bytecode llamado Zend Guard a un costo de U$S 600 por año. Obviamente descartamos esta opción, pero todo zapato tiene su horma. Existe un sitio llamado Free PHP Encoder que convierte (de alguna manera) nuestro código a bytecode. En esta página podemos subir simultáneamente todos los archivos que queramos convertir a bytecode, el sitio nos devolverá nuestros archivos con variables que tienen asignados caracteres aparentemente aleatorios y un archivo llamado decoder.php (en bytecode) que distribuiremos con el resto de nuestro código. Los archivos generados por este sitio pueden serán interpretados por el Zend Optimizer+

Por otro lado, Zend se dio cuenta de los malabares que había que hacer para incorporar el Zend Optimizer+ a su Zend Server, por lo que en la nueva versión de su Zend Server CE incorporó por omisión el Zend Optimizer+

El Zend Server es un producto ideal para distribuir un servidor Apache+PHP de fácil y rápida instalación, tan fácil y rápida que cualquier usuario inexperto podía ponerlo en funcionamiento en 10 minutos. Incluso es el servidor perfecto para distribuir con los instaladores de nuestro software si nuestra aplicación requiere de un servidor Apache+PHP.

Monas Encoder

Monas es Trotsky para Zend. Es simple, liviano, más rápido que Zend Optimizer+ y gratuito! También te ceba mates y te despierta para ir a trabajar.

Si queres saber quién hizo este par de módulos, no te esfuerces, el autor dice “hmm … what should i said about my self ?” cuando preguntan por él. Solamente hay una dirección: bdnt.monas @ gmail . com

De la página de Monas, descargamos el archivo monas-v1.0-win32.rar para Windows o monas-v1.0-linux32.rar para Linux. La instalación y el uso no pueden ser más simple:

  1. Descomprimimos los módulos y el archivo generador en PHP
  2. Copiamos los módulos al directorio de módulos de PHP
  3. Copiamos el archivo generador gui.php al directorio htdocs de Apache
  4. Editamos el archivo php.ini
    En la sección de extensiones agregamos esta línea:
    extension=monas_encoder.dll
  5. Ejecutamos el archivo gui.php incluido en el paquete de Monas para convertir el directorio donde se encuentran los archivos PHP con nuestro código y obtener los archivos en bytecode con todas sus dependencias… un detalle de seriedad
  6. En el archivo php.ini, Comentamos la línea extension=monas_encoder.dll y agregamos una línea como la siguiente:
    extension=monas.dll
  7. Ejecutamos nuestro código

Esto es todo.

Si necesitamos distribuir un servidor Apache+PHP con nuestros programas, también podemos optar por xamplite, un conjunto muchísimo más liviano que Zend y no necesita instalador, descomprimimos y ejecutamos.

Terminando

Existen otras formas de hacer nuestro código ilegible, se trata de los ofuscadores. Estos, en algunos casos reemplazan las cadenas no literales del usuario con cadenas alfanuméricas aparentemente sin sentido, otros utilizan funciones de encriptamiento del código, y como lógicamente se supone, el archivo resultante es una única función de desencriptado. Lo único que consiguen los ofuscadores es darle un poco más de trabajo al que quiera obtener el código original. Nada recomendable.

Les dejo algunos ejemplos para que vean los resultados:

Basta por hoy, salió el sol, 15º y muchas ganas de despejarme, sigamos en unos días. En la próxima vamos a ver como “ligar” nuestro código a una máquina específica para que no pueda ser distribuido sin nuestro permiso.

Borland C++Builder – La elegancia y la fidelidad del estandard

El entorno de desarrollo (IDE – Integrated Development Environment) C++Builder, originalmente de Borland Enterprise (http://www.borland.com/), ahora de Embarcadero (http://www.embarcadero.com/, quien le compró a Borland la división CodeGear, encargada del desarrollo y mantenimiento del C++Builder) posee el RAD (Rapid Application Development) mejor estructurado, con la curva de aprendizaje más empinada y con el mayor respeto al estándar ANSI C++, lo que significa que cualquier programador que tenga conocimientos teóricos del lenguaje C++ puede adaptarse rápidamente a este RAD. También es para resaltar el hecho de que el compilado del código dentro del entorno es hasta un 500% más rápido que su contraparte, VC++ y el código generado (EXE) posee un algoritmo que hace su ejecución mucho más veloz y su tamaño mucho más pequeño.

Un poco de historia

Lanzado en 1997, después del exitoso y aclamado Delphi, y con un entorno similar a éste. Muchos componentes de Delphi pueden utilizarse en C++.
En 1999 Borland anuncio la versión 4.0, poco tiempo después anuncio que su producto hermano Borland C++ seria discontinuado en favor del C++Builder.
En 2000 salió publicada la versión 5.0 y en 2002 la versión 6.0. Para aquella época las versiones de C++Builder salían un año o un poco más de su contraparte Delphi.
En 2003 Borland publica C++BuilderX (CBX), que usaba el entorno de desarrollo (Galileo) de un producto hermano: JBuilder y tenia poca similitud con C++Builder o Delphi, pues proponía como framework a wxWindows (en lugar de OWL, OWLNext o VCL). Este producto estaba dirigido a grandes organizaciones y no tuvo mucha aceptación.
Al final del 2004 Borland anuncio que continuara desarrollando el C++Builder e incluirlo junto con la suite de desarrollo de Delphi development suite, abandonando el C++BuilderX.
Cerca de un año después del anuncio Borland publico ‘Borland Developer Studio 2006′ que incluía el Borland C++Builder 2006 que proveía un administrador de configuración mejorado y varias correcciones. Borland Developer Studio 2006 es un paquete que incluida Delphi, C++Builder, y C#Builder.
En 2006 Borland’s Developer Tools Group, la división encargada del C++Builder, fue transformada en una organización independiente (subsidiaria) denominada CodeGear.
En 2007 Borland publico C++Builder 2007, proveyendo completo soporte para la API de Microsoft Vista, soporte mejorado a ANSI C++, y hasta 500% más rápida performance en el proceso de compilación desde el IDE, suporte para MSBuild, arquitectura de base de datos DBX4, “VCL for the Web” que permite el desarrollo visual de aplicaciones AJAX, y la librería OWLNext. El soporte de la API de Microsoft Vista incluye aplicaciones ‘temadas’ y soporte a la interfaz Aero y Vista Desktop. CodeGear RAD Studio 2007 incorporo C++Builder 2007 y Delphi. También en 2007 Borland revivio la línea “Turbo” y lanzo dos ediciones “Turbo” de C++Builder: Turbo C++ Professional, y Turbo C++ Explorer (no disponible actualmente de CodeGear), basado on Borland C++Builder 2006.
En 2008 CodeGear fue adquirida por Embarcadero Technologies, quien continuo el desarrollo.
C++Builder 2009 fue publicado en Agosto del 2008, las características agregadas más importantes fueron el soporte completo a Unicode tanto en la VCL como en la RTL, adopción anticipada del standard C++0x, soporte al ITE (Entorno de Traducción Integrado), componentes Ribbon y la inclusión de la librería Boost.
C++Builder 2010 fue publicado en Agosto del 2009, fue el primer entorno de desarrollo que incluyo soporte a Windows7, permitiendo desarrollar aplicaciones que soportan la interfaz ‘Multitouch’.
Codegear ha anunciado sus planes de desarrollo que incluirían soporte a OSX y Linux.
Extraído de Wikipedia
NOTA: Borland, en el 2000 comenzó a soportar el desarrollo en Linux mediante su RAD Kylix.
¿Por qué Codegear C++Builder? Por que, dentro del entorno Windows, es el mejor RAD disponible para los desarrolladores de C++ que quieran estabilidad, respeto por el ANSI C++ y una curva de aprendizaje extremadamente empinada.