Os quiero presentar debugmodeon.com

[Alberto Gimeno]

Hola a todos!

Unos compañeros y yo llevamos unas semanas mes desarrollando una
aplicación sobre App Engine. Esta semana hemos empezado a enseñarla al
mundo. Se trata de una red social para programadores. La dirección es
esta: http://debugmodeon.com

Sería un placer que la visitarais y me contarais vuestra opinión sobre
la idea y cómo está llevada a cabo. Y por supuesto más placer sería
que participarais! ;)

Estamos contínuamente añadiendo nuevas funcionalidades y quedan
bastantes cosas por hacer. Pero ya os podéis hacer una idea del
objetivo de la web y de cómo hemos querido llevarla a cabo.

Un saludo y gracias por adelantado!

PD: al menos dos de los que hemos hecho la web iremos el jueves al
Google Developer Day. Así que si hay alguien que vaya, allí nos
veremos!!

PPD: gracias a Dani Latorre por hacer de relaciones públicas estos
últimos días que hemos promocionado un poco la web :)

[Roberto Abizanda]

Hola,

Yo ya me he apuntado a unos cuantos grupos. A ver qué tal.

Saludos,

Roberto

2008/9/21 Alberto Gimeno <gime...@gmail.com>

--

____________
Antes de imprimir este mensaje, por favor compruebe que es verdaderamente necesario. El Medio Ambiente es cosa de todos.

[Alberto]

La verdad es que me ha gustado bastante la idea y la implementación.
Una cosilla que podríais mejorar es la nube de tags. En Dilandau.com
tengo una serie de títulos de canciones en la página de inicio.
Haciendo pruebas con Google Website Optimizer me di cuenta de que si
ponías muchas canciones la gente hacía muchas búsquedas, y si ponías
pocas también. Poco a poco fui encontrando el número óptimo y fue
sobre 10 ó 9. Tal vez deberíais de experimentar para reducir la nube
de tags y encontrar vuestro número óptimo. Para mi tantos tags se me
hacen complicados de leer y distinguir los importantes.

Espero que os vaya muy bien, me ha gustado bastante.

[Marc Garcia]

Pués parece que ha tenido éxito, porqué ya se ha superado la quota (que según dice Google deberían ser unos 5 millones de pageviews mensuales). A ver si Google empieza pronto a permitir comprar quota adicional.

Sobre la web no puedo decir mucho, ya que le di un vistazo rápido, y ahora ya no está disponible, aunqué a riesgo de parecer maleducado, y de equivocarme, diré que me pareció que no aportaba nada nuevo. Yo para publicar artículos tengo mi blog, y de foros ya existen muchos (o listas de distribución, que vienen a ser un poco lo mismo). Que razón me daríais para usar vuestra página y no lo que ya uso?

Al margen de lo dicho, que espero sea tomado como una consulta, y una crítica constructiva, quisiera pregutar si habéis usado algo especial para la administración (lo que serían las operaciones CRUD). Yo la principal pega que he encontrado al app engine respecto a django que uso actualmente es la falta de una administración autogenerada basada en los modelos. Hace pocos días empecé a programar una aplicación para ello, pretendiendo que a partir de los modelos del app engine, y que con un mínimo (o nada) de personalización tengas tus listados y formularios dónde editar los datos maestros de la aplicación. La gracia sería que estubiera perfectamente decoupled (no conozco la palabra para eso en español), de manera que con un simple módulo también sirviese para el sqlalchemy, o el mismo django. En cuanto tenga una primera versión la publicaré bajo alguna licencia libre, e informaré a esta lista (aunqué no tengo todo el tiempo que quisera para dedicarle, así que supongo que pasaran unas cuantas semanas).

Un saludo,
  Marc

[Alberto Gimeno]

Hola.

La verdad es que no llegamos a entender los errores que da la página
porque según la consola de administración
http://www.flickr.com/photos/gimenete/2882187726/sizes/o/
Las métricas no llegan al 1% (salvo la CPU: 1%).

Cualquier crítica constructiva es bienvenida. Por ello no se es
maleducado :). Lo que pensamos es que por ejemplo cualquier persona
también puede colgar sus fotos en cualquier web, pero flickr te da más
posibilidades, visibilidad, más capacidad para "conectar" con otras
personas,... Pues lo mismo con el tema que tratamos, la programación.
Evidentemente también existen listas de correo, webs etc. de temas
concretos. Lo que nosotros queremos ser es "la larga cola" de los
contenidos de programación e informática en general. Por ejemplo
existen páginas de Java (javaHispano.org es un ejemplo), pero en ellas
se habla poco de otras tecnologías que un desarrollador web Java
debería conocer. CSS, javascript, prototype/jquery/..., SEO,... Luego
hay temáticas que no encajan del todo en ningún sitio. Por ejemplo hay
páginas de Flash que han empezado a tener contenidos de Flex y páginas
de Java que han hecho lo mismo... Debug_mode=ON pretende ser una
plataforma para unir gente con mismos intereses. Tienen cabida tanto
contenidos generalistas como temáticas poco habituales, o simplemente
grupos localizados de gente (LUGs, JUGs). Pretendemos que esa
información que en blogs o páginas pequeñas podría estar dispersa, con
nuestra web quede organizada. Y también que gracias a ello se fomente
la creación de contenidos. Un amigo me dijo el otro día que quería
escribir de varias cosas, pero que no quería crear un blog para
escribir cuatro artículos...

Vamos, creo que el simil con flickr es claro. Si cuelgo fotos en
flickr tengo más posibilidades de contactar con fotógrafos que les
guste hacer fotos similares a las mias. Técnica (HDR, blanco y negro,
photoshop,...), temática (retratos, paisajes, arquitectura,...). En
debug_mode=ON pretendemos facilitar que personas con mismas
inquietudes tengan más facilidad para compartir conocimientos y
debatir.

Sobre la administración, App Engine cuenta en la consola de
administración que permite gestionar la información del datastore.
Como un mini-phpmyadmin. No obstante nos hemos programado nuestras
páginas internas de administración para gestionar comentarios,
artículos, etc. Pero no hemos usado nada especial.

Un saludo y gracias por tus comentarios!


2008/9/23 Marc Garcia <garci...@gmail.com>:

--
Alberto Gimeno Brieba
Presidente y fundador de
Ribe Software S.L.
http://www.ribesoftware.com
ri...@ribesoftware.com

Contacto personal
eMail: gime...@gmail.com
GTalk: gime...@gmail.com
msn: gime...@hotmail.com
página web: http://gimenete.net
web favorita: http://debugmodeon.com
teléfono móvil: +34 625 24 64 81

[Marc Garcia]

Pués con las explicaciones oportunas sí que entiendo mejor la gracia de la web. Supongo que últimamente todo el mundo intenta lanzar webs que revolucionan el mundo, y al ver una web que sencillamente intenta contribuir y organizar la información en internet se hace poco... ;) A parte justo hace pocos días que empecé a usar github, que también se hace llamar red social para programadores, y que es algo bastante nuevo hasta dónde conozco yo, y entré en debugmodeon esperando algo así.

Lo de las quotas es algo complicado. No solo deniegan las peticiones a partir de que excedes tus limites de 24h, sinó que te deniegan peticiones si consideran que estás teniendo una punta que provocará que excedas tu quota dentro de esas 24 horas. Puedes mirar lo poco que explican aquí (seguro lo habrás visto ya): http://code.google.com/appengine/articles/quotas.html

Creo que de momento lo único que puedes hacer es aligerar un poco la home, que parece que es lo que te hace exceder la quota. La verdad es que es una lástima que triumfes con una web, y que se fastidie de este modo. En fin, a ver si hay suerte y lo solucionais pronto.

Un saludo,
  Marc

[Alberto Gimeno]

Hola.

Hemos puesto un mensaje estático en la página, para evitar "la mala
imagen" de tener una página caída. Así al menos damos una explicación.
En cuanto a la home, tenemos 3 consultas a la base de datos, son
simples y están cacheadas con memcache. No veo ningún modo de
optimizarlo más. Bueno, cacheando el HTML de la página... Pero vamos,
creo que la página debería ir bien sin optimizar hasta tal extremo.
Como digo son 3 consultas sencillas y cacheadas...

Hemos visto que hay más gente a la que le pasa:
http://groups.google.com/group/google-appengine/browse_thread/thread/6ff62bbb2ee9f373?hl=en
App Engine por lo que parece en seguida se queja si las peticiones
consumen demasiados ciclos de CPU. El problema es lo que consideran
"demasiados". Este extracto lo explica muy claramente:

"1. Requests can become a high amount CPU one very easily. A little
complex request will consume more than 3K mcycles. And what do I mean
a little complex? If you do more than 2 put, or you do a url fetch, or you do a
query based on an order to select more than 50 model, or you do a put
on a model more than 20 fields, it is that complex. In my case, 80% of the
requests are that complex and I don't think it can be optimized
anymore since I do need to do put and url fetch."

En fin, esperaremos a que pase la avalancha de visitas y la volveremos
a poner en marcha en cuanto podamos.

Gracias de nuevo por tus comentarios :)

[Alberto Gimeno]

Hemos cambiado el mensaje de la home. Contiene el texto del artículo
con el que nos auto-definimos. Creo que ahí se entiende muy bien la
idea de la web.

un saludo!

2008/9/23 Alberto Gimeno <gime...@gmail.com>:

[Marc Garcia]

Buenas,

veo que la web vuelve a estar operativa, no sé si ya está solucionado el problema, o es questión de suerte. En todo caso, comentabamos ayer con Ubaldo, que es posible que una de las cosas que estén afectando al exagerado (según google) consumo de cpu, sea el uso de las templates de django.

Te paso algunos links, dónde se pueden ver benchmarks de distintos template engines en django [1]. Yo usaría mako de referencia, al ser que está pensado en terminos de performance.

También te paso un link dónde comparan jinja (http://jinja.pocoo.org/), con las templates de django, desde un punto de vista ya muy técnico, y a pesar de que no lo he leido detenidamente da la impresión que realmente en django están haciendo las cosas realmente mal desde un punto de vista de la performance. El artículo [2].

No te puedo hablar por experiencia, pero se supone que jinja es muy similar a django en cuanto a sintaxis, por lo que si tenéis tiempo sería interesante migrar la home a jinja, y hacer profiling de ambos casos, a ver cual es el impacto del sistema de templates en el global del procesamiento de la request. Si lo hacéis por aquí estaremos encantados de saber los resultados; podéis publicar un artículo en debugmodeon.com ;)

También creo que sería interesante ver si estáis usando django o webapp, y si estáis usando django para qué. En mi opinión no es una buena idea usar django en app engine. Aunqué django en sí, y al margen de las templates, creo que es suficientemente eficiente en muchos casos, creo que todo el monkey patching usado en el django helper tienen que estar penalizando bastante las aplicaciones que lo usan.

Espero que os sea de utilidad, y solucionéis el problema rápido.

Un saludo,
  Marc


[1] http://genshi.edgewall.org/wiki/GenshiPerformance
http://www.makotemplates.org/#speedchart
http://www.slideshare.net/zeeg/django-con-high-performance-django-presentation/ (diapositiva 12 especialmente)
[2] http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-django-and-why-django-should-have-a-look-at-it/

[Alberto Gimeno]

Hola Marc. De nuevo muchísimas gracias.

Ayer por la noche volvimos a poner la página a ver qué tal se
comportaba, pero esta mañana ya está dando errores de over quota.

En nuestra aplicación sólo usamos django para las plantillas. Creo
Jinjoo creo nos puede ayudar mucho. Puede ser clave. La sintaxis es
prácticamente la misma que en django por lo que veo. Te lo agradezco
muchísimo.

Un saludo!

2008/9/24 Marc Garcia <garci...@gmail.com>:

[Ubaldo Huerta]

Me alegro mucho del exito inicial :)))))))))) No se si saben que
mañana hay un google developer day en Madrid
http://code.google.com/intl/es_ALL/events/developerday/2008/agenda.html,
parece que hay gente competente del groupo de App Engine. El codelab
es sobre como hacer un wiki http://code.google.com/p/google-app-engine-codelab/downloads/list

Es muy probable que si le llevas code snipets te puedan ayudar, o
postealos en el google app engine groupo. Que cantidad de requests/sec
estas recibiendo?

Otra idea es ver en este ejemplo como mete html output en memcache.
http://bloog.billkatz.com/

Yo voy a ir, porque tengo unos temas de geohashing, etc que resolver.
Voy en el ave que sale de Sants a las 6 AM

-U

On Sep 24, 9:38 am, "Alberto Gimeno" <gimen...@gmail.com> wrote:
> Hola Marc. De nuevo muchísimas gracias.
>
> Ayer por la noche volvimos a poner la página a ver qué tal se
> comportaba, pero esta mañana ya está dando errores de over quota.
>
> En nuestra aplicación sólo usamos django para las plantillas. Creo
> Jinjoo creo nos puede ayudar mucho. Puede ser clave. La sintaxis es
> prácticamente la misma que en django por lo que veo. Te lo agradezco
> muchísimo.
>
> Un saludo!
>

> 2008/9/24 Marc Garcia <garcia.m...@gmail.com>:

> >http://www.slideshare.net/zeeg/django-con-high-performance-django-pre...
> > (diapositiva 12 especialmente)
> > [2]
> >http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-djang...

>
> > Alberto Gimeno wrote:
>
> > Hemos cambiado el mensaje de la home. Contiene el texto del artículo
> > con el que nos auto-definimos. Creo que ahí se entiende muy bien la
> > idea de la web.
>
> > un saludo!
>

> > 2008/9/23 Alberto Gimeno <gimen...@gmail.com>:

>
> > Hola.
>
> > Hemos puesto un mensaje estático en la página, para evitar "la mala
> > imagen" de tener una página caída. Así al menos damos una explicación.
> > En cuanto a la home, tenemos 3 consultas a la base de datos, son
> > simples y están cacheadas con memcache. No veo ningún modo de
> > optimizarlo más. Bueno, cacheando el HTML de la página... Pero vamos,
> > creo que la página debería ir bien sin optimizar hasta tal extremo.
> > Como digo son 3 consultas sencillas y cacheadas...
>
> > Hemos visto que hay más gente a la que le pasa:

> >http://groups.google.com/group/google-appengine/browse_thread/thread/...

> > App Engine por lo que parece en seguida se queja si las peticiones
> > consumen demasiados ciclos de CPU. El problema es lo que consideran
> > "demasiados". Este extracto lo explica muy claramente:
>
> > "1. Requests can become a high amount CPU one very easily. A little
> > complex request will consume more than 3K mcycles. And what do I mean
> > a little complex? If you do more than 2 put, or you do a url fetch, or you
> > do a
> > query based on an order to select more than 50 model, or you do a put
> > on a model more than 20 fields, it is that complex. In my case, 80% of the
> > requests are that complex and I don't think it can be optimized
> > anymore since I do need to do put and url fetch."
>
> > En fin, esperaremos a que pase la avalancha de visitas y la volveremos
> > a poner en marcha en cuanto podamos.
>
> > Gracias de nuevo por tus comentarios :)
>

> > 2008/9/23 Marc Garcia <garcia.m...@gmail.com>:

> > 2008/9/23 Marc Garcia <garcia.m...@gmail.com>:

>
> > Pués parece que ha tenido éxito, porqué ya se ha superado la quota (que
> > según dice Google deberían ser unos 5 millones de pageviews mensuales). A
> > ver si Google empieza pronto a permitir comprar quota adicional.
>
> > Sobre la web no puedo decir mucho, ya que le di un vistazo rápido, y ahora
> > ya no está disponible, aunqué a riesgo de parecer maleducado, y de
> > equivocarme, diré que me pareció que no aportaba nada nuevo. Yo para
> > publicar artículos tengo mi blog, y de foros ya existen muchos (o listas de
> > distribución, que vienen a ser un poco lo mismo). Que razón me daríais para
> > usar vuestra página y no lo que ya uso?
>
> > Al margen de lo dicho, que espero sea tomado como una consulta, y una
> > crítica constructiva, quisiera pregutar si habéis usado algo especial para
> > la administración (lo que serían las operaciones CRUD). Yo la principal pega
> > que he encontrado al app engine respecto a django que uso actualmente es la
> > falta de una administración autogenerada basada en los modelos. Hace pocos
> > días empecé a programar una aplicación para ello, pretendiendo que a partir
> > de los modelos del app engine, y que con un mínimo (o nada) de
> > personalización tengas tus listados y formularios dónde editar los datos
> > maestros de la aplicación. La gracia sería que estubiera perfectamente
> > decoupled (no conozco la palabra para eso en español), de manera que con un
> > simple módulo también sirviese para el sqlalchemy, o el mismo django. En
> > cuanto tenga una primera versión la
>

> ...
>
> read more »