Historias
Slashboxes
Comentarios
 
Búsqueda

Construir y escalar aplicaciones en Rails: lecciones aprendidas

editada por Yonderboy el 23 de Febrero 2009, 18:02h   Printer-friendly   Email story
desde el dept. haciendo-camino-al-andar
Programación
mig21 nos cuenta: «Vía Hacker News leo Building and Scaling a Startup on Rails: 12 Things We Learned the Hard Way, que repasa las dificultades se encontró el autor construyendo una aplicación web con rails y hacer que respondiera apropiadamente en su crecimiento. Algunos son lógicos, como buscar las consultas más lentas, y otros más llamativos, como usar memcached en una fase tardía del ciclo de vida de la aplicación. Muchos de los consejos son válidos también para otros entornos de desarrollo.»

Historias relacionadas

[+] Un proyecto ciudadano para aumentar la transparencia del Parlamento Vasco: Parlio 17 comentarios
Con motivo del Rails Rumble de 2009, la gente de Linking Paths y La Personalité han creado el proyecto Parlio, que consiste básicamente en una recombinación de datos públicos sobre la actividad en el Parlamento Vasco, extraídos mediante técnicas de scraping del propio sitio web del Parlamento Vasco y estructurados de una forma sencilla y accesible, con el objetivo de fomentar la transparencia política. El proyecto Parlio será continuado por Pro Bono Público, una asociación "que busca ayudar a la promoción y la difusión de estándares, datos y plataformas tecnológicas abiertas entre las instituciones públicas". El resultado muestra se puede añadir valor sobre los datos públicos, incluso aunque éstos provengan de fuentes no estructuradas ni abiertas. El único problema, como dicen en su propia web, es que si modifican la estructura de los datos habría que actualizar el sistema para ajustarse a ella.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Construir y escalar aplicaciones en Rails: lecciones aprendidas | Log in/Crear cuenta | Top | 11 comentarios | Buscar hilo
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

  • Resumen

    (Puntos:5, Informativo)
    por caente (22894) el Lunes, 23 Febrero de 2009, 19:01h (#1129940)
    ( http://blog.dimeder.com/ | Última bitácora: Martes, 20 Abril de 2010, 22:46h )
    Hay un resumen bien resumido en highscalability [highscalability.com]
    • Re:Resumen de kilburn (Puntos:1) Lunes, 23 Febrero de 2009, 20:42h

  • Re:La verdad del chuletón

    (Puntos:1)
    por miguelsan (22769) el Martes, 24 Febrero de 2009, 08:30h (#1130023)
    ( http://barrapunto.com/ | Última bitácora: Jueves, 29 Abril de 2010, 22:49h )
    > ¿porque nadie se anima a portar el codigo de barrapunto a Rails?

    ¿Porque no hay dios que lo entienda?
    [ Padre ]

  • Re:La verdad del chuletón

    (Puntos:2)
    por gwolf (501) <gwolfNO@SPAMgwolf.org> el Martes, 24 Febrero de 2009, 13:10h (#1130052)
    ( http://www.gwolf.org/ )

    Aunque me gusta mucho Rails y los lenguajes derivados, creo que todos tenemos que aceptar la aplastante_realidad.
    Creo que esa realidad es que no lo has evaluado seriamente :)

    En esta época da igual si sale Grails Vista o Krails XP.Net, porque mientras ambas herramientas peleaban por un ridículo porcentaje de aceptación inferior al 1 %, los lenguajes más populares como PHP o ASP se convirtieron en soluciones estándares.
    No estás comparando cosas equivalentes. PHP es un lenguaje, al igual que Ruby. Rails es un framework completo, que te simplifica muchísimas facetas del desarrollo de tu sistema, y te ayuda a evitar caer en las problemáticas más comunes del código PHP/ASP: El código espagueti, la programación inmantenible. Rails (y CakePHP, y Django, y Catalyst, y Jifty, y Monorail, y Grails, y cuantos frameworks para cuantos lenguajes se te ocurran) te "invitan fuertemente" (no te obligan, pero te lo ponen tan fácil que no tiene sentido oponer resistencia) a basarte en patrones MVC limpios y a estructurar tus sistemas limpiamente como OO.

    La realidad es que Rails tiene poco para ofrecer al programador de sistemas libres. Para empezar no existen herramientas profesionales que permitan sacarle provecho al lenguaje, ya que la mayoria de entornos de desarrollo estan centrados en PHP.
    Umh... Llevo 10 años dedicándome al desarrollo Web. ¿Te refieres a IDEs? Porque hay, y no pocos. ¿Te refieres a plugins e integración con otros sistemas? No faltan. ¿Diferentes metodologías de integración con diversos servidores Web? Más variedad incluso que PHP (por ejemplo, montar en PHP un esquema de servidor de aplicaciones con diferentes usuarios no es un "caso de uso" común, aunque es una característica muy importante)... Explica más a qué te refieres.

    Pero la cereza del pastel...

    La prueba del fracaso de Rails la encontramos en la creciente e imparable popularidad de PHP y la cantidad de soluciones existentes para esta plataforma, tales como PHPNuke o Meneame. La propuesta de Rails es sugerirle al usuario que reinvente la rueda una y otra vez en vez de usar las soluciones existentes. Un coñazo, vamos.
    ¡¿?! PHPNuke está muerto hace tiempo, aunque engendró a varios hijos. Es un ejemplo comunmente citado de mal código, de programación insegura, y de un mantenedor capaz de destruir a su propia comunidad. Y justamente la propuesta de Rails se centra en la filosofía DRY: Don't Repeat Yourself. No reinventes la rueda.

    ¿ Y tu ? ¿ Eres de los que estan dispuestos a partir de 0 con Rails o prefieres empezar sobre algo que ya existe y funciona como PHP? ¿En ese caso porque nadie se anima a portar el codigo de barrapunto a Rails? Dejad de vender humo y centremonos en lo que realmente funciona hoy poy hoy.
    jajaj, y justo pones como ejemplo a Barrapunto... ¡Que está escrito en Perl! Y sí, sus autores serán los primeros en reconocer que es código muy complejo y de dificil mantenimiento. Eso sí, mucho más completo (y complejo) que tu software más común de manejo de blogs.
    [ Padre ]
  • 4 respuestas por debajo de tu umbral de lectura actual.