Desafío Latam
 
  • Actualidad
  • Oportunidades
  • Trabajo Remoto
  • bootcamp
  • Ver Cursos

Optimización

contando con left_join

Haciendo gráficos con Rails

Contando con rails, parte 2.

En el tutorial anterior vimos las diferencias entre size, count y length, en este capítulo vamos a trabajar con count, size, pluck y sufrir con los includes, eager_loads, joins y groups y los vamos a utilizar para generar gráficos.

A modo de repaso tenemos dos modelos, users y tweets, donde un tweet le pertenece a un usuario y cada usuario tiene muchos tweets.

Ahora si queremos saber cuantos Tweets tiene cada usuario, como lo hacemos? Una forma sencilla sería agruparlos y contar

Tweet.group(:user_id).count

Lo que nos daría como resultado:

=> {2=>20, 3=>20, 4=>20, 5=>20, 6=>20, 7=>20, 8=>20, 9=>20, 10=>20, 11=>20}

Graficando la cuenta:

Teniendo el conteo de los Tweets podemos graficarlos.

Una forma sencilla de hacerlo es ocupando la gema de chartkick, que consiste en una especie de wrapper de google charts y de high charts, ahora ¿cuál escoger?, high charts a pesar de ser muy bueno no posee una licencia comercial gratuita a diferencia de google charts, así que para este ejemplo vamos a utilizar google charts.

Gonzalo Sánchez
Gonzalo Sánchez

Director de DesafíoLatam. Ingeniero Civil Informático de la Universidad Federico Santa María. Emprendedor lean, dedicado al desarrollo de una mejor web con ruby on rails. Fanático de los números y las métricas, la música y la fotografía.

www.DesafioLatam.com

Compartir

Compartir
Compartir
Tuitear
  • julio 8, 2015
  • 1
  • 9864
  • ActiveRecord, Rails, Tutoriales
  • Ver más
Select con count

Contando con Rails

Resolviendo el problema de n+1 en la cuenta de datos.

En este tutorial vamos a aprender un poco de eager loading en rails, y como evitar los problemas de n+1 cuando se trata de contar elementos hijos o padres y cuál es la diferencia entre los métodos count, size y length a la hora de contar datos.

Gonzalo Sánchez
Gonzalo Sánchez

Director de DesafíoLatam. Ingeniero Civil Informático de la Universidad Federico Santa María. Emprendedor lean, dedicado al desarrollo de una mejor web con ruby on rails. Fanático de los números y las métricas, la música y la fotografía.

www.DesafioLatam.com

Compartir

Compartir
Compartir
Tuitear
  • julio 7, 2015
  • 2
  • 6209
  • ActiveRecord, Rails, Tutoriales
  • Ver más
Donde poner los scripts de javascripts

Javascript en el Head o en el cierre del body? Estás equivocado

¿Por que se dice que los scripts de javascript deben ir en el cierre?

En la web existen muchas recomendaciones acerca de que deben poner el javascript al final del sitio justo antes del cierre del </body>, la razón argumentada es sencilla, los navegadores leían secuencialmente los scripts y bloqueaban el render de la página hasta haberla leído el script, pero entonces ¿por qué razón Ruby on Rails, que supuestamente es construido por expertos carga javascript dentro de la etiqueta <head> </head> en lugar del cierre de la página?.

¿Entonces por qué Rails los pone al principio?

Hay 2 razones:

La primera es porque todos los navegadores modernos (incluyendo internet explorer 8) a partir del 2008 incorporaron un sistema llamado preload scanning que les permite cargar todos los scripts paralelamente sin causar bloqueos (bueno, realmente los bloqueos todavía existen, pero son parciales y ya ahondaremos más sobre como eliminarlos).

El segundo problema de agregar javascript al inicio consiste en que a veces alguna funcionalidad crítica de la página (o de tu negocio) depende de esos javascript, por ejemplo si pones google analytics al final, en el cierre del body y el usuario sale del sitio antes de terminar cargar la página entonces pierdes la data del usuario, otra de las funcionalidades críticas de Rails viene dada por jquery-ujs, si esto se cargara al final de la página tendríamos un problema con los usuarios que son del tipo Quicky Clicker y presionan el los links antes de que la página termine de cargar.

Más sobre Preload Scanning

Preload Scanning no evita completamente el bloqueo, su implementación cambia dependiendo del navegador, pero en términos básicos consiste en un light weight process que se levanta para seguir leyendo archivos css, imágenes u otros scripts cuando se topa con un script. Pero esta lectura es sólo de forma parcial, por lo que sigue siendo recomendado en muchos casos poner javascript al final.

Otra forma de optimizar el proceso es ponerlo en el head junto con los atributos async o defer, este thread de stackoverflow es bastante aclarativo sobre las diferencias, sin embargo como todo lo asincrónico se recomienda implementar con cuidado.

¿Que dice google al respecto?

Técnicamente el guideline oficial de google developers dice que debes evitar en lo posible bloquear, en otras palabras cargar javascript, si lo haces, hazlo al final, ocupa async y defer cuando puedas y si el script es pequeño, es mejor tenerlo dentro del html (esto último si que me lo esperaba) debido que al evitar el llamado disminuyes la latencia de los requests.

Sugerencias finales:

Nada de lo leído quiere decir que uno pueda poner en cualquier parte cualquier script, muchos de ellos tienen dependencias, otros necesitan el DOM cargado y como no están bien programados hay que agregarlos necesariamente al final, a fin de cuentas el preload scanning lo que lo logra es evitar que la lectura de un script de javascript bloquee la lectura del HTML.

En resumen:

si las funcionalidad es crítica en el head, sino en el cierre del body, si el javascript consiste sólo en un par de líneas puede ir inline para optimizar la carga.

Referencias:

http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/

http://railsapps.github.io/rails-javascript-include-external.html

http://stackoverflow.com/questions/436411/where-is-the-best-place-to-put-script-tags-in-html-markup

https://developers.google.com/speed/docs/insights/BlockingJS

 

Gonzalo Sánchez
Gonzalo Sánchez

Director de DesafíoLatam. Ingeniero Civil Informático de la Universidad Federico Santa María. Emprendedor lean, dedicado al desarrollo de una mejor web con ruby on rails. Fanático de los números y las métricas, la música y la fotografía.

www.DesafioLatam.com

Compartir

Compartir
Compartir
Tuitear
  • junio 9, 2015
  • 8
  • 127613
  • Javascript
  • Ver más


Cambia tu vida en menos de 1 año

Fórmate en los roles más demandados y mejor pagados

Lunes 6 de marzo

Martes 21 de febrero

Lunes 6 de Marzo

Lunes 17 de abril

Lunes 17 de Abril

Etiquetas

activeadmin API APP aprender bootcamp consejos data science desarrollo devise digital diseño diseño ux/ui educación emprendimiento eventos experiencia freelance front end fullstack Google hackathon Herramientas útiles Html Infraestructura Javascript lenguajes de programación Motivación mujeres oportunidades Optimización programación python Rails remoto Ruby Ruby on Rails tecnología testimonio Tips trabajo remoto trabajos programadores trabajos remoto Tutoriales ui ux

Entradas recientes

  • Error 404, y otros errores de estado http que debes conocer
  • Programación en liceos, codificando un nuevo futuro
  • ¿Qué es Full Stack? Conoce que hace y su sueldo
  • Javascript vs Python, ¿Cuál es mejor?
  • 6 cursos gratuitos de Google para ti

Categorías

Actualidad Android boot camp bootcamp Consejos Consejos para emprendedores Creación de Juegos curso programacion Data Science Desafíos Desarrollo web Diseño Diseño Web Docente Educación Emprendimientos tecnológicos empresas Entrevista laboral Eventos Front End Fullstack git Graduados Hackathones informáticos Javascript Marketing Digital Motivación Mujeres Oportuidades Oportunidades Profesionales TI Programación python Rails Seguridad Informática tecnologia Tendencia Testimonios Tips Trabajo Remoto Tutoriales Ui Uncategorized Ux
  • 62 famosos sitios hechos en Rails

    163219 views
  • trabajos remotos

    Top 32 sitios para encontrar trabajos remotos

    157302 views
  • Trabajo Freelance

    Trabajo Freelance: Top 15 sitios para encontrarlos

    146881 views

Obtén noticias y promociones


Desafio Latam Copyright 2017. All Rights Reserved