Sería ideal que en estos cursos ya se promueva el uso de docker para usar dockerización de la app en entorno local, eso facilitaría muchísimo al pasar a producción en infraestructuras modernas 😃
Introducción
Todo lo que aprenderás sobre Ruby on Rails
¿Qué es Ruby on Rails y por qué usarlo?
Entorno de desarollo
Entorno de desarrollo de Ruby on Rails
Instalación de Ruby, RoR en Linux
Instalación de Ruby, RoR en Mac y Windows
Nuestra primera aplicación
Entender la web con rieles
Primero pasos con Ruby on Rails
Entender el enrutamiento básico
Manipular el patrón MVC
Los secretos de Rails
Assets y Layouts
Agregar el primer conjunto de scaffolds
Cómo funcionan las migraciones
Optimiza tu código con HAML
Agiliza la construcción de formularios con Simple Form
Soporte de varios idiomas para tu aplicación
Debugging: detecta los errores en tu código
Proyecto del curso: primeros pasos
¿Qué vamos a desarrollar?
Diseñando el modelo de datos
Construye los primeros scaffolds del proyecto
Internacionalizando los modelos
Agregando validaciones al modelo
Proyecto del curso: usuarios
Añadiendo el concepto de usuario
Asignando un propietario a la tarea
Añadiendo participantes a la tarea
Creando formularios anidados
Interactuando con Cocoon para anidar formularios
CanCan: ¿puedes hacerlo?
Proyecto del curso: interacciones
Callbacks en Rails
Añadiendo datos semilla
Enviando e-mails a los participantes
Añandiendo notas a la tarea
Añadiendo notas con AJAX
Embelleciendo nuestra aplicación
Cierre
Desplegando a Heroku
Conclusiones del curso
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Johan Tique
Aportes 10
Preguntas 0
Sería ideal que en estos cursos ya se promueva el uso de docker para usar dockerización de la app en entorno local, eso facilitaría muchísimo al pasar a producción en infraestructuras modernas 😃
Todo parte del esquema solicitante-proveedor. O sea, cliente-servidor. Rails no es la excepción a esto y podemos encontrar este tipo de flujos utilizando arquitecturas modernas.
<h3>1er paso - Cliente</h3>↓
<h3>2do paso - Enrutador/Mapeador</h3>↓
<h3>3er paso - Controlador</h3>↓
<h3>4er paso - Modelo</h3>↓
<h3>5er paso - Templating, Formatos y Renderizador</h3>↓
<h3>6to paso - Formato</h3>Esto denota un estilo arquitectónico o MVC (Modelo-vista-controlador)
⭐ Rails trata por convención a las peticiones con la estructura RESTful, este nos provee cierto tipo de métodos prediseñados y preconfigurados para poder acceder a los recursos.
Excelente explicación 👏🏼
La gran mayoría de sitios y aplicaciones en internet trabajan con un arquitectura Cliente - Servidor. Incluso en desarrollos con tecnologías modernas.
El cliente hace una petición, el enrutador hace el papel de una especie de lobby, donde dirigirá la petición a donde está lo que pidió, pero antes se topa con el controlador; el controlador construye la respuesta y la envía (con ayuda del modelo y del renderizador) de regreso.
Este es un estilo arquitectónico conocido como MVC (Model View Controller)
Por convención, Rails trata a las peticiones bajo el estilo arquitectónico RESTful, que provee ciertos métodos prediseñados y preconfigurados para acceder a los recursos. Estos son: index, show, new, create, update y destroy.
Estos métodos se pueden modificar o incluso se pueden crear métodos propios, pero estos son los que la arquitectura RESTful provee por defecto.
Muy importante:
Este video también me ayudó a entender bien el modelo MVC
La mejor explicación que he visto de la arquitectura MVC, nunca me había quedado claro del todo hasta hoy.
es un modelo vista controlador (MVC)
Ruby on Rails: HTTP, MVC and Routes
Les dejo mis aportes de este y otros videos que vi en internet:
1° paso) Envió mensajero, el mensaje tiene unas condiciones determinadas, instrucciones ya mapeadas:
2° paso) El mensajero al llegar al lobby o a portería llega a un enrutador o mapeador
Enrutamiento: el mensajero entrega las instrucciones de a donde ir al portero y este le da el okey
3° paso) El mensajero llega a la casa, es decir al controlador quien recibe las condiciones, lo construye, lo empaqueta y se lo entrega al mensajero. Las condiciones son la forma en la que quiero renderizar el producto.
4° paso) Recibo el paquete de parte del mensajero
La petición URL y el método get es el mapeo que hace el sistema (cuando la petición llega, se enruta y va al controlador: quien tiene una acción y parámetros dentro de la url: las condiciones).
El controlador hace un enlace directo hacia un sistema donde tengo almacenado registros, este sistema se llama modelo, tiene comunicación directa con una base de datos.
Desde el id que he obtenido desde el controlador obtengo referencia directa al recurso que quiero, es decir al insumo para poder fabricar el producto.
Cuando tengo el insumo adopto el formato que viene desde mi petición o desde las condiciones y a partir de allí entrego, en este caso utilizo HTML: sistema para renderizar HTML.
El producto final, en este caso es una pagina terminada, empaquetada que ira de vuelta a la respuesta de mi petición.
MODELO-VISTA-CONTROLADOR:
Controlador: nexo entre modelo y vista, ya que por ejemplo el usuario envía un formulario, el controlador zabra que tiene que crear un modelo y almacenar información dentro de la BD. Al llevar la acción de manera satisfactoria tiene que ir a una vista y hacer que esta vista le notifique al usuario que el registro se llevo de manera adecuada.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?