Diferencias de visión entre el programador y los usuarios
Escrito por CristianDeluxe | Archivado en Programación, diseño web
Me ha hecho mucha gracia esto, me ha gustado tanto que incluso la he traducido.
Seguro que todos los que programamos, nos sentiremos identificados con esta imagen:
Aparte de ser divertido es incluso educativo.
Muchas veces nos centramos en muchos elementos que el usuario final no va a valorar, el usuario no quiere conocer que hay “detrás” de la aplicación, sino en lo que es capaz de hacer, o digamos de mostrarle.
La imagen original la he sacado del blog Gran Angular.
Tags: diferencias, humor, programador, usuario, visión
Guardando ajustes para nuestra aplicación con CakePHP
Escrito por CristianDeluxe | Archivado en diseño web
Si te gusta desarrollar páginas aplicaciones web con PHP y aún no usas ningún framework de los varios que hay, no se a qué estás esperando, no voy a exponer aquí las múltiples ventajas de usar un framework, o cuál es mejor, todo se lo puedes preguntar a Google.
Yo personalmente uso CakePHP, y algunas veces, necesitamos guardar los ajustes de nuestra aplicación, por ejemplo: claves API, emails, datos de contacto, etc..
Navegando por The Bakery (de entrada casi obligatoria para cualquier desarrollador de CakePHP) me encontré con este artículo escrito por Cameron Perry en el que explicaba cómo guardar en nuestra base de datos todos los ajustes en un array serializado.
Es casi lo que necesito, pero no me gusta la idea de tenerlo todo en un array, es un atraso, teniendo bases de datos potentísimas como es MySQL, por lo que me puse manos a la obra y modifiqué el trabajo de Cameron.
La idea básicamente es la misma, pero en vez de guardar todos los ajustes juntos en una columna voy a guardar cada uno por separado, esto nos permitirá que los admins de nuestra aplicación puedan cambiar los ajustes como ellos quieran.
Vamos a ponernos manos a la obra.
1) Crear nuestra tabla en la base de datos
El primer paso obviamente es crear la tabla donde se almacenarán todos los ajustes, podemos hacerlo con una simple consulta como esta:
-
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
-
`key` VARCHAR(48) NOT NULL,
-
`value` TEXT,
-
PRIMARY KEY (`id`),
-
UNIQUE KEY `key` (`key`)
-
)
2) Crear el modelo, el controlador y las vistas
Utilizando “cake bake” creamos rápidamente el modelo, el controlador y las vistas.
Una vez creado, modifica el archivo de modelo, en este caso “setting.php” (normalmente está en la carpeta “app/models”), con lo siguiente:
-
var $name = 'Setting';
-
var $key = 'Opc'; // Se puede cambiar por lo que quieras
-
var $custom_settings = array();
-
-
// Recibe los datos de configuración de la base de datos
-
function getcfg(){
-
// Consigue los datos de configuración de la base de datos y los mete en un array
-
$cfgs = $this->find('all', array('fields'=>array('id','key','value')));
-
-
// Si no es un array salimos
-
if( !is_array($cfgs) ) return;
-
-
// Procesamos cada configuración
-
foreach($cfgs as $cfg) {
-
-
// Crea el array para usarlo más tarde
-
$data_array = array(
-
'id' => $cfg['Setting']['id'],
-
'key' => $cfg['Setting']['key'],
-
'value' => $cfg['Setting']['value'] );
-
$this->custom_settings[] = $data_array;
-
-
// Escrebe el array en la configuración de CakePHP
-
Configure::write($this->key . '.' . $cfg['Setting']['key'], $cfg['Setting']['value']);
-
}
-
}
-
}
3) Modificar el archivo AppController
Bien, lo siguiente es modificar el archivo AppController, si aún no lo has creado ¿a qué esperas?, debe estar en “app/app_controller.php”.
-
-
var $uses = array('Setting');
-
-
function beforeFilter(){
-
// Procesa nuestras configuraciones de la base de datos
-
$this->Setting->getcfg();
-
}
-
}
4) ¡Usarlo!
Pues ya está todo listo, ahora podemos usar nuestros ajustes en cualquier sitio, un ejemplo de cómo hacerlo es:
-
SI has cambiado el valor de la variable key en el paso 2 debes cambiarlo aquí también, por ejemplo, si has definido $key como "MyApp" tienes que leer la configuración así:
-
<pre lang="php">echo "Mi configuración" . Configure::read('MyApp.title'); //devuelve 'Mi pedazo de página';
Como ves CakePHP te deja hacer lo que tengas en la mente, y nunca está de más trabajar sobre el código que otra persona ha realizado, es uno de los principios fundamentales del open source, coger algo que ya está hecho y adaptarlo a sus necesidades. ¡Tú también puedes hacer lo mismo!
Checkboxes y botones de radio con estilo con jQuery
Escrito por CristianDeluxe | Archivado en diseño web
Si quieres cambiar tus viejos y aburridos checkboxes y botones de radio por otros con mucho más estilo puedes probar con esta extensión para jQuery.
El funcionamiento es muy simple:
-
$("input").checkize({
-
checked:"images/checked.gif",
-
checked_down:"images/checked_down.gif",
-
checked_hover:"images/checked_hover.gif",
-
-
unchecked:"images/unchecked.gif",
-
unchecked_down:"images/unchecked_down.gif",
-
unchecked_hover:"images/unchecked_hover.gif"
-
});
-
});
Puedes ver una demo funcionando aquí: http://totmacher.eu/jquery/radio/demo/
Fuente en modo texto: http://totmacher.eu/jquery/radio/src/jquery.checkize.js
Descargar código de ejemplo + fuente en un .zip: http://totmacher.eu/jquery/radio_v0.2.zip
Fuente: Love and Theft
Tags: botones, buttons, Checkboxes, extension, formularios, jquery, radio
Escritorio de Leopard creado con jQuery
Escrito por CristianDeluxe | Archivado en diseño web
Los chicos de Nettuts nos traen un completo tutorial que nos muestra cómo crear el escritorio de Leopard con jQuery, una librería de javascript, sin duda una muestra más de que cada vez las webs se van acercando más a las aplicaciones de escritorio.
Ya se ha hecho algo parecido pero en vez de emular a Mac emula a Windows y está creada con la librería Ext JS.
Podéis ver una demo pulsando en el siguiente enlace:
Demo de escritorio de Leopard creado con jQuery
Y el tutorial lo podéis encontrar pulsando aquí.
Enlaces:
Tags: ajax, javascript, jquery, leopard, mac, windows
Probando la carga de tu aplicación web con Apache Bench
Escrito por CristianDeluxe | Archivado en diseño web
Nuestra aplicación
Todos los que programamos, ya sea aplicaciones web o simplemente aplicaciones, independientemente de la plataforma, solemos hacerlo con mucho cariño, sobre todo si es un proyecto que nos interesa, ya sea por los resultados o por el simple hecho de tener un reto y aprender de él.
Generalizando un poco, se podría decir que los programadores engullimos grandes cantidades de información, tutoriales, artículos… para implementar todas las mejoras posibles (Optimizaciones, protecciones de seguridad, caché… ), sobre todo si la vamos a mostrar al público en general (como es el caso de una aplicación web).
Llega el esperado momento de terminar, hasta ahora todo está correcto, tenemos nuestra aplicación funcionando en nuestra máquina y parece que casi todos los bugs están solucionados, normalmente (si no estamos en un entorno profesional) es el mismo programador y algún colega de confianza, el que prueba la aplicación en su propio PC.
¿Dónde surge el problema?
Como en el entorno de desarrollo probamos nuestra aplicación con pocos usuarios no podemos comprobar cuanta CPU y memoria va requerir nuestra aplicación en un entorno real y en situaciones límite.
Un ejemplo es, que algún contenido de nuestra web aparezca en un blog popular o que sea portada en sitios como menéame, donde podamos recibir cientos de visitas en escasos minutos.
Hay algunas webs programadas por los “newbies” que por ejemplo sacan un listado con todos los registros de la base de datos, esto no puede parecer un problema cuando estás programando y tienes un par de registros de prueba, pero una vez que nuestra base de datos crezca… pues imagina las consecuencias de varios usuarios a la vez intentando recuperar 12.000 registros de la base de datos… ¿Resultado? Sobrecarga de nuestro servidor y probablemente muchos usuarios no podrán acceder al contenido.
Por ello es recomendable que monitorizemos nuestra aplicación y sepamos qué partes consumen más CPU, y cuales se podrían optimizar para conseguir un mayor rendimiento.
Un ejemplo de optimización sería una tienda de coches online (es lo primero que se me ha ocurrido), si un cliente quiere comprar coches de la marca “Seat”, en vez de sacar el listado con todos las demás marcas, podemos filtrar ese resultado ajustándonos a lo que el cliente requiere. Con ello reduciremos carga de CPU al servidor, haremos que nuestra aplicación vaya mucho más ligera y todo ello influirá en el tiempo que los usuarios tienen que esperar .
¿Cómo puedo medir el rendimiento?
Con todas las distribuciones de Apache se incluye la herramienta Apache Bench. La utilidad de este programa es enviar varias peticiones simultáneas a nuestro servidor y así poder comprobar el tiempo que tarda en cargar y procesar cada página, el número de peticiones que se han podido servir, la carga del servidor y otros datos interesantes.
Apache Bench es, por decirlo de alguna manera, “independiente” del resto, es decir, no tiene porqué ser Apache, puedes usarlo con cualquier servidor, como LigHTTPD o con cualquiera que soporte el protocolo HTTP.
Normalmente se recomienda usar en un entorno local para obtener resultados más fiables y seguramente no querrás probarlo en tu servidor de producción
.
¿Cómo se usa Apache Bench?
Apache Bench (ab) normalmente viene incluida con nuestro Apache, si estás en un entorno linux probablemente ya tengas Apache instalado, en cambio en Windows no viene incluido, por lo que si aún no lo tienes instalado te recomiendo XAMPP, puedes descargarlo en la página del proyecto.
Si abrimos el programa (ab.exe en Windows) sin ningún comando nos aparecerá la ayuda del programa:
C:\xampp\apache\bin\>ab
ab: wrong number of arguments
Usage: ab [options] [http://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make
-t timelimit Seconds to max. wait for responses
-p postfile File containing data to POST
-T content-type Content-type header for POSTing
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
De momento los comandos que nos interesan son: -n y -c.
El comando -n seguido de un número indica la cantidad de peticiones a realizar. Un número entre 100 y 1000 es un buen valor para comenzar
El comando -c seguido de un número indica las peticiones simultáneas que se realizarán. Este valor puede variar bastante dependiendo de qué esperas de tu aplicación. En nuestro caso pondremos un valor de 30.
Para nuestra prueba usaremos la siguiente dirección: “http://localhost” que es la dirección local por defecto cuando instalamos Apache, para lanzar ab usaremos lo siguiente:
ab -n 1000 -c 30 http://localhost/
Lo que le estamos pidiendo al programa es que realize 30 peticiones simultáneas por segundo hasta completar las 1000 peticiones. El programa nos muestra lo siguiente:
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Finished 1000 requests Server Software: Apache/2.2.8 Server Hostname: localhost Server Port: 80 Document Path: / Document Length: 1789 bytes Concurrency Level: 30 Time taken for tests: 26.828125 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 2020000 bytes HTML transferred: 1789000 bytes Requests per second: 37.27 [#/sec] (mean) Time per request: 804.844 [ms] (mean) Time per request: 26.828 [ms] (mean, across all concurrent requests) Transfer rate: 73.50 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 3.1 0 15 Processing: 125 797 170.9 796 1297 Waiting: 125 797 170.8 796 1296 Total: 125 798 170.9 796 1312 Percentage of the requests served within a certain time (ms) 50% 796 66% 859 75% 906 80% 921 90% 1015 95% 1078 98% 1140 99% 1187 100% 1312 (longest request)
Si deseas más información puedes consultar la ayuda oficial.
Tags: apache, diseño web, herramientas



