SlimStat es una aplicación open source de análisis y estadísticas para páginas web.

Está creada con PHP y MySQL, así que se puede integrar fácilmente en nuestros sitios mediante JavaScript (como Google Analytics) o PHP.

Para un determinado período, la aplicación muestra:

• La cantidad de “hits”, visitas y páginas vistas.
• Las URLs y dominios de origen de los links.
• Términos de búsqueda.
• Navegadores, sistemas operativos, países, resoluciones de pantalla.

También hay una opción llamada “paths”, que muestra el camino recorrido por un usuario desde su navegador, página por página.

La gran ventaja de Slimstat ante Google Analitycs es que muestra las estadísticas en vivo, con tan sólo presionar F5.

Hace unos minutos lo he instalado en www.shooteando.com.ar, mediante un proceso extremadamente sencillo que lo dejó funcionando en el acto. Para probarlo “en vivo“, entré varias veces desde esta misma pc y desde una con otra ip [ gracias @rulski =P ] mientras actualizaba con F5 para ver los cambios. Los resultados fueron más que satisfactorios; me mostró la cantidad de “hits” [ 5 en total, 4 desde mi pc ] y las visitas “reales” [ que eran 2 ]. Lo único que le faltaría es permitir que el gráfico se muestre por visitas y no por hits/día, aunque los números en la parte superior sobran para hacerse una idea correcta de la cantidad de visitas “reales”.

Espero que les sea útil y no dejen de comentar si lo probaron o tienen dudas.

Vía WebResourcesDepot

Instalación

Instalar GHRML es tan fácil como hacerlo con casi cualquier otra aplicación de Python, vía setuptools (ejemplo en linux):

easy_install GHRML

Y listo! Ya tenemos GHRML instalado en nuestro directorio de paquetes de Python. Ahora sólo resta indicarle a nuestra app de Django dónde buscar los templates cuando los representemos con este lenguaje de markup. En mi caso, como se trataba de una prueba, simplemente le indiqué el mismo directorio donde se encuentran usualmente los templates del sistema de templates de Django. Esto lo hice agregando al archivo settings.py lo siguiente:

GENSHI_TEMPLATE_DIRS = (
    os.path.join(os.path.basename(__file__), 'templates'),
)

Con esto nos aseguramos de que al llamar al render_to_response de GHRML, encuentre los templates. De otra forma lanzaría un error.

Usando GHRML

Para poder escribir templates mediante este lenguaje, simplemente importamos lo que necesitemos de ghrml.ghrml_django, por ejemplo, la antes mencionada render_to_response:

from ghrml.ghrml_django import render_to_response as render_ghrml

En mi caso particular le puse un alias a render_to_response, ya que seguía usando su versión original para algunas pruebas.

Una vez importado, simplemente reemplazamos los render_to_response que queramos, por los correspondientes render_ghrml, siempre teniendo en cuenta que el template al que apuntamos esté escrito en este lenguaje.

Ventajas y desventajas

Una ventaja obvia de utilizar GHRML es que se simplifica enormemente la tarea y el tiempo de escribir nuestros templates, ya que no sólo “ahorramos” código, sino que Haml resulta muchísimo más fáciles de leer. A esto tenemos que sumar la facilidad de instalación y el hecho de que podemos usar Haml con otros lenguajes (como Ruby o PHP), de forma que no necesitaremos acostumbrarnos a un sistema de templates diferentes para cada framework o lenguaje.

Por otro lado, GHRML tiene algunas “fallas”; por ejemplo, al querer utilizar el “tag” %ul (y %li), sin haber puesto %html y %body en el template que estamos editando, la lista no se renderizará como debe. Además de esto, me he encontrado con un problema muy grave, para el cual – de momento – no tengo solución: los forms no se generan automáticamente. Por ejemplo, cuando quiero hacer form.as_p, como esto renderiza un form en el lenguaje de templates de Django, GHRML no lo reconoce y pone otra cosa en la página (si no me equivoco, renderiza la representación del objeto). Imagino que existirá alguna solución (que no sea armar los forms a “mano”), sino ya me iré acostumbrando a hacerlos un poco más “artesanales”. Otra falencia grave de este lenguaje es la ausencia casi total de documentación, aunque la sintaxis es casi igual a la de Haml, por lo cual se puede aprender a usarlo en la página de documentación de éste.

Una última aclaración: en la página del Trac de GHRML dicen que tiene dependencia con Genshi, por lo cual supongo que las setuptools se encargaron de instalarlo por mí.

¿Alguno de ustedes ha probado GHRML? ¿Han tenido los mismos problemas que yo? Si alguien encontró cómo hacer funcionar lo de los forms, ¡avise!

Por suerte, y gracias al dios de los lenguajes de programación (?), @eljuanchosf llegó para salvarme con Haml en la mano.

Haml fue ideado para acelerar los tiempos de desarrollo y a la vez lograr un lenguaje de markup agradable a la vista. No por nada de su idea principal es:

Markup should be beautiful.

Luego de ver un ejemplo, se puede comprobar la sencillez y “limpieza” que este lenguaje le puede dar a nuestros templates. El ejemplo siguiente está extraído del tutorial que se puede ver en la página principal de Haml.

<div id='content'>
  <div class='left column'>
    <h2>Welcome to our site!</h2>
    <p><%= print_information %></p>
  </div>
  <div>
    <%= render :partial => "sidebar" %>
  </div>
</div>

#content
  .left.column
    %h2 Welcome to our site!
    %p= print_information
  .right.column
    = render :partial => "sidebar"

Pero el hecho de que me gustara tanto Haml traía consigo un nuevo problema; empecé a “odiar” el lenguaje de templates de Django y PHP embebido en HTML (en realidad a éste último ya lo odiaba). Así que puse manos al teclado y busqué implementaciones de Haml para estos lenguajes, encontrando resultados mucho más rápido y fácil de lo que esperaba.

Para poder tener un lenguaje similar a Haml en Django, podemos utilizar GHRML, el cual está basado en Genshi Markup Templates. En el caso de PHP, existe un parser llamado phphaml, el cual nos permite escribir los templates casi de la misma forma que lo hacemos en el Haml original. Pueden ver ejemplos de estos en sus respectivas páginas.

¿Conocen otras implementaciones de Haml para Django o PHP? ¿Son mejores que las encontradas por mi? ¡No duden en dejar sus comentarios recomendándolas!

gRaphaël es capaz de crear gráficos de torta, barra, líneas y puntos, tanto estáticos como interactivos. Estos gráficos son generados mediante VML y soporta los browsers más populares, como Firefox 3.0+, Safari 3.0+, Opera 9.5+ e Internet Explorer 6.0+.

Como pueden ver en el siguiente código (extraído de la página de gRaphaël), es extremadamente sencillo de usar:

// Creates canvas 640 × 480 at 10, 50
var paper = Raphael(10, 50, 640, 480);
// Creates pie chart at with center at 320, 200, radius 100
// and data: [55, 20, 13, 32, 5, 1, 2, 10]
r.g.piechart(320, 240, 100, [55, 20, 13, 32, 5, 1, 2, 10]);

Pueden ver excelentes demos, como el gráfico de torta interactivo y el de puntos en la misma página de gRaphaël.

De las respuestas que se fueron dando en forma de comentarios, se pueden sacar algunas conclusiones (basadas sólo en opiniones de los lectores):

• Django y RoR son más rápidos (en general) que cualquier framework basado en PHP
• Tanto Django como RoR tienen una curva de aprendizaje rápida, más aún comparándolos con frameworks como Struts, JSF, etc.
• Django es más rápido que RoR (yo no lo dije!!! =P)
• Ambos tienen la ventaja de tener muchísimas herramientas y aplicaciones “pluggables” ya desarrolladas (blogs,  foros,  redes sociales,  etc.)
• Django tiene una documentación excelente (adhiero!)
• Faltan IDEs que se integren mejor con estos frameworks
• Muchos desarrolladores no tienen la más pálida idea de lo que hablan
• Algunos comparan la complejidad de RoR con J2EE+Spring+etc. (vamos rubyonrailistas ¡a desmentir esto!), por lo que recomiendan otros frameworks basados en Ruby, como Sinatra, Rack, Ramaze o Camping.
• Odio el sistema de comentarios de Barrapunto ¬¬

Si bien se puede apreciar que las opiniones son varias y algunas bastante polémicas, creo que un usuario dio en el clavo al decir algo como lo siguiente, con lo que estoy completamente de acuerdo:

Creo que hay que mirarlo de otra manera… no hay una solución definitiva, ni porque una sea mejor el resto pasan a ser malas.

Luego agregó que se debería trabajar con lo que ya se sabe (si sabes Java, entonces algo como JSF; si sabes PHP, quizás Symfony…), y llegado este punto ya dejamos de concordar.

Siempre es bueno aprovechar la oportunidad de aprender, de expandir nuestros horizontes, de generar un poco de movimiento en las neuronas para que no nos queden atrofiadas en un sólo lenguaje, en una sola tecnología, en una forma de pensar cerrada y sin posibilidad de cambio. Nuestro ambiente es algo que evoluciona constantemente; nuevos lenguajes, nuevas tecnologías, nuevas formas de enfrentar y solucionar los problemas. Tenemos que estar siempre atentos y listos para adaptarnos a lo que sea que se nos cruce en el camino. Si allá por los 50′s/60′s, los programadores se hubieran cerrado a su lenguaje sin aceptar nada de lo nuevo que vendría, hoy sólo programaríamos en FORTRAN.

¿Qué piensan ustedes? ¿Qué framework prefieren? ¿Cómo encaran los cambios en el ambiente de desarrollo de sistemas?

160+ Mega Web Design Tutorial Roundup

En resumidas cuentas, me han ahorrado el trabajo, quedandome sólo publicar el siguiente link:

Organize Your Next PHP Project the Right Way

Que lo disfruten! =)

Hasta ahora no me había llamado mucho la atención este navegador, pero de a poco está mejorando y creo que es muy posible que sobrepase a Firefox si la versión 3.5 de éste no sale pronto (o si no es lo que esperamos).

Al leer sobre las extensiones, me entero de que van a estar hechas sobre HTML, JS y CSS, una idea que me parece excelente y que Firefox también está intentando adoptar con JetPack. Esta forma de hacer las extensiones ampliaría la cantidad de desarrolladores que las crean, ya que el proceso es igual al que seguimos cuando hacemos una página web. Otra cosa interesante de este sistema, es que no es necesario reiniciar el browser para que funcionen.

Para ponerme a ver como crear estas extensiones, me he descargado la versión de desarrollo de Google Chrome, que según el “Acerca de…” es la 3.0.182.3 (OMG), y he visto muchas mejoras interesantes, pero sobre todo en la Consola JavaScript, la cual pinta mucho mejor que FireBug.

Si cuando todo esto funcione, también sale para Linux, quizás me termino cambiando de browser.

• Soporte multilenguaje.
• Soporte avanzado para: CSS, HTML, JavaScript, XML, Perl, PHP, Python, Ruby, Tcl, RHTML, Template-Toolkit, HTML-Smarty and Django.
• Autocompleción y tips para: CSS, HTML, JavaScript, Perl, PHP, Python, Ruby, Tcl, XML and XSLT.
• Soporte de archivos multi lenguaje (Ej: CSS y JavaScript embebidos en HTML).
• Soporte para librerías de terceros.
• Características básicas como: Auto indentación y “desindentación”, selección de bloques, búsqueda incremental, reflujo de código, y más.
• Chequeo y coloreo de sintaxis.
• Mapeo de atajos del teclado de Vi y Emacs.
• Previsualización de HTML/CSS/XML/JS.
• “Code Snipets”: trozos de código reusables personalizados.
• Edición multi documento con pestañas.
• Administrador de proyectos con carpetas reales y virtuales.
• Toolbox que permite guardar virtualmente “todo”: code snipets, macros, menúes, templates, etc.
• Soporta agregados XPI (como Firefox y Thunderbird)

Tomando todo lo anterior como ventajas, paso ahora a nombrar las que creo que podrían ser algunas de sus desventajas:

• Dado que está basado en XUL (el sdk de Mozilla con el que está hecho Firefox), puede llegar a volverse un poco lento de a ratos si la pc no es muy potente. Si bien el uso de memoria es bastante intensivo, no llega a ocupar tanta memoria como otros IDEs.
• No posee explorador de archivos locales ni remotos, sino que sólo se maneja mediante los proyectos. De cualquier forma esto es fácilmente solucionable mediante un agregado.
• No posee debugger, el que sí está incorporado en la versión Komodo IDE, la cual es paga.

Agregados recomendados

Para completar las herramientas de Komodo Edit, le recomendaré tres agregados muy útiles:

• JSTReeDrive: Agrega un explorador de archivos tanto locales como remotos en la barra de la izquierda. Permite administrar los archivos, guardar favoritos y visualizar imágenes. La versión local funciona perfecto. La remota (vía FTP) no la he probado, pero me han comentado que no funciona muy bien, esperemos que mejore en las próximas versiones.
• HTML ToolKit: Muy buena colección de herramientas que facilita el desarrollo de páginas wev. Lean sus características en la página del agregado.
• Source Tree: Permite explorar las funciones y métodos de nuestro código mediante un árbol (muy similar al outline de eclipse). Si bien la idea es muy buena, luego de probarlo un par de días no parece funcionar del todo bien.

Resumiendo, Komodo Edit es un entorno ideal para desarrollo web utilizando HTML, PHP, CSS y JavaScript, a la vez que puede servir igual de bien para trabajar con Python y Django. Si bien no posee un debugger para este lenguaje, siempre hay otras formas de lograr la misma funcionalidad (por ej: combinándolo con IPython).

Más allá del hecho de tener un par de contras, creo que las ventajas son más que suficientes como para darle una oportunidad. De momento es el que mejor me ha respondido. ¿Tienen algún mejor IDE para recomendar? ¡Espero sus propuestas!

Vía: Página oficial de Komodo Edit