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

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!

Para ilustrar este problema, el autor empieza comparando un Script de Ant en XML con un Ant-builder en Groovy:

Ant XML

<project name="prepareBookDirs" default="copy">
  <property name="target.dir" value="target"/>
  <property name="chapters.dir" value="chapters"/>
  <target name="copy">
    <delete dir="${target.dir}" />
    <copy todir="${target.dir}">
      <fileset dir="${chapters.dir}"
        includes="*.doc"
        excludes="~*" />
    </copy>
  </target>
</project>

Ant-builder en Groovy

  TARGET_DIR = 'target'
  CHAPTERS_DIR = 'chapters'
  ant = new AntBuilder()
  ant.delete(dir:TARGET_DIR)
  ant.copy(todir:TARGET_DIR){
      fileset(dir:CHAPTERS_DIR, includes:'*.doc', excludes:'~*)
  }

Como pueden ver, es notablemente más legible el segundo código, no sólo porque es más corto y con menos caracteres superfluos, sino porque se usa el mismo lenguaje para escribirlo, en vez de XML. Como bien dice el autor de la entrada original, el creador de Ant admitió que usar XML es “…probablemente un error”.

Luego, el autor del artículo muestra una tabla donde compara números de código realizado en Java contra Ruby on Rails. Prestar especial atención a las líneas de configuración y al tiempo que lleva realizar el proyecto.

     Metric               Java +              Ruby +
                     Spring/Hibernate         Rails 

  Time to market     4 months, approx.      4 nights,
                      20 hours/week       5 hours/night
  Lines of code          3,293                1,164
  Lines of config        1,161                113
  Number of classes/     62/549               55/126
  methods

Los archivos de configuración en Ruby ocupan el ¡10%! de líneas de lo que ocupan en Java, y el tiempo de desarrollo cambia de 4 meses en el lenguaje de los infames XMLs, a ¡4 noches! en el interpretado. Si bien no sé hasta que punto los números son acertados, por más que las líneas de configuración en ruby aumenten un 200%, aún serían muchísimas menos que las de Java.

En el artículo original, el autor señala la complejidad de frameworks como spring, que llevan a necesitar utilizar gráficas para poder entender la estructura interna de sus archivos de configuración XML. También cuenta lo siguiente, que me pareció ya excesivo, pero que a muchos compañeros de trabajo que conozco les encantaría:

But wait, it comes even better: some people are so enamoured with XML that they are using it as a programming languag, either doing patterns with Spring and XML configuration files, or even inventing an XML-based programming language and writing its interpterer in XSLT (I’m not joking!).

Lo que en español viene a ser algo parecido a esto:

Pero esperen, se pone mucho mejor: algunas personas están tan enamoradas de XML, que lo están utilizandon como un lenguaje de programación, ya sea haciendo patrones con Spring y archivos de configuración XML, o incluso inventando un lenguaje de programación basado en XML y escribiendo su intérprete en XSLT (No es broma!).

Sin comentarios. Creo que con el ejemplo ya sobra, hay gente para todo.

Conclusión

En la entrada original, el autor hace un análisis final que no me pareció necesario incluir en este post (lo van a tener que leer en inglés). Por mi parte, la conclusión es sencilla, XML es un recurso excelente, cuando es usado con moderación y no para cada problema que se cruza en nuestro camino. Prefiero usar archivos de configuración más pequeños, preferiblemente escritos en el mismo lenguaje en que estoy desarrollando (como es el caso de Python o PHP), o llegado el caso, algo más legible como JSON o YAML.

Y para terminar, coincido totalmente con la reflexión del autor de la entrada original:

I think that the loose coupling thing is overrated…

InDefero

Entre sus funcionalidades se cuentan:

• Seguimiento de bugs
• Subida y descarga de archivos
• Documentación y vista general del código
• Cada usuario tiene su propio “tablero”
• Soporte para explorar código (git, Subversion y Mercurial)
• Línea de tiempo del proyecto
• Un motor de búsqueda poderoso
• Visualización de las diferencias en los commits
• Resaltado de la sintáxis online
• Facilidad de comunicación con el usuario final
• Y mucho más…

Requiere un servidor con PHP y soporte para bases de datos PostgreSQL, SQLite o MySQL 4.1+.

“Mi teoría es que los programadores eligen usar lenguajes como Python y Ruby para sus proyectos personales, a pesar de sus debilidades, porque es más divertido programar en esos lenguajes”.

Si bien la conclusión puede parecer un poco “precipitada”, me parece muy lógica y acertada, ya que a los resultados de este experimento le puedo sumar mi experiencia real y la de colegas que han trabajado con cualquiera de estos cuatro lenguajes.

Y ustedes ¿qué opinan de la conclusión? ¿Les parece acertada?

• Las líneas de código comentado no son comentarios – Usa control de versiones, no lleves un registro de los cambios del código comentándolo. El código comentado es código esquizofrénico.
• Deja que tu reputación te preceda – Si trabajas en proyectos de código abierto, blogueas y mantienes una buena red de contactos, conseguirás más ofertas que aquellos que sólo envían currículums por mail para buscar trabajo.
• No des excusas por tu código, déjalo hablar por si mismo – Te pagan para encontrar soluciones usando código, no busques excusas para el mismo. “Funcionó en mi máquina” no es una solución, el cliente no usará tu computadora para correr la aplicación.
• No tomes las críticas a tu código como algo personal - No se trata de tí, sino de una característica de negocios y de la performance de toda la aplicación.
• Tu código es el legado de tu carrera - Aquellos que mantengan tu código una vez que lo hayas dejado, te maldecirán o te agradecerán.
• Escribir código no es lo mismo que programar - Escribir código no es igual a desarrollar software; lo primero requiere pensar y ser creativo mientras que en el segundo caso esto no siempre es necesario.
• Escribir código implica aprender - La ley de Moore establece que la tecnología se “duplica” cada 18 meses, hay que mantenterse actualizado. Si no aprendes nada es que estás haciendo algo mal. Cada proyecto es una oportunidad para aprender.
• Escribir código es comunicar - Muchos leerán el código que escribiste. Usa buenas prácticas así como patrones de diseño conocidos. Esfuérzate por la simplicidad antes que por impresionar, tu código debe comunicar clara y consistentemente su propósito.
• Las herramientas no hacen al desarrollador - Conoce a fondo tus herramientas y úsalas con su máximo poder, pero no permitas que se conviertan en tus muletas. Trabajar con diferentes IDEs no debería detenerte sólo porque no encuentras el asistente de generación de código que necesitas.
• No confíes en tu código - Confiar en tus habilidades al codificar no remplaza la necesidad de realizar tests. No confíes en tu código. No confíes en tus suposiciones. No confíes en los usuarios.
• El código no está escrito en latín - El código no muere una vez terminada la aplicación, tiene que ser refactorizado, modificado y reusado. El código tiene que evolucionar. Tu mayor fortaleza no radica en escribir montañas de nuevas líneas de código, sino en mantener, refactorizar y reagrupar código existente según las exigencias y las especificaciones de la aplicación.
• Respetar la API – Tu API es un contrato del que otros dependerán. Mantén la API limpia y explícita. Mientras menos métodos expongas, menos testeo, mantenimiento y documentación serán necesarios.
• El código significa cosas diferentes para diferentes personas - En última instancia, para los usuarios finales el código simplemente es la habilidad de poder hacer lo que ellos esperan.

Agrego un par de “mi cosecha”:

• No te cases con un lenguaje o tecnología – Hoy en día existen muchísimos lenguajes, frameworks y soluciones disponibles para diferentes finalidades. A la hora de desarrollar una nueva aplicación, es mucho mejor elegir el lenguaje o la tecnología apropiada para ella, antes que intentar adaptar lo único que conoces al propósito del proyecto.
• No mates mosquitos con bombas H – Esto es un corolario del anterior punto. Nunca sobredimensiones las necesidades de una aplicación sólo porque no sabes cómo utilizar la herramienta adecuada, en vez de eso, aprovecha la oportunidad de aprender. De esta forma no sólo harás un mejor desarrollo, sino que también se incrementarán tus conocimientos.

Aclaro que varios puntos fueron levemente modificados e incluso uno fue completamente removido, ya que no me pareció relevante incluirlo. Estoy seguro de que los incluídos son suficientes y están traducidos de forma clara y concisa, si piensas al contrario, ¡házmelo saber!

Vía: Juixe TechKnow | Laws of Source Code and Software Development

Vía: Smashing Magazine | Crucial Concepts Behind Advanced Regular Expressions